Tekst źródłowy strony Programowanie strukturalne

'''Programowanie strukturalne''' – [[paradygmat programowania]] opierający się na podziale [[kod źródłowy|kodu źródłowego]] [[program komputerowy|programu]] na procedury i hierarchicznie ułożone bloki z wykorzystaniem struktur kontrolnych w postaci [[Instrukcja wyboru|instrukcji wyboru]] i pętli. Rozwijał się w opozycji do programowania wykorzystującego proste instrukcje warunkowe i [[Instrukcja skoku|skoki]]. Programowanie strukturalne zwiększa czytelność i ułatwia analizę programów, co stanowi znaczącą poprawę w stosunku do trudnego w utrzymaniu „[[spaghetti code]]” często wynikającego z użycia instrukcji [[Instrukcja skoku|goto]].

Początki programowania strukturalnego przypadają na Lata 60. XX wieku, a ważnym głosem w dyskusji o programowaniu strukturalnym był list [[Edsger Dijkstra|Edsgera Dijkstry]] [[Goto Statement considered harmful]].

[[Język programowania]] zgodny z paradygmatem programowania strukturalnego nazywa się językiem strukturalnym.

== Cechy charakterystyczne ==
=== Struktury kontrolne ===
Podstawowe struktury kontrolne jakie wymienia [[Twierdzenie Böhma-Jacopiniego|twierdzenie o programowaniu strukturalnym]], z których możliwe jest zbudowanie dowolnego programu to:
* '''Sekwencja''' – wykonanie ciągu kolejnych instrukcji
* '''Wybór''' – w zależności od wartości predykatu wykonywana jest odpowiednia instrukcja. W językach programowania zazwyczaj reprezentowana przez słowa kluczowe [[Instrukcja warunkowa|<code>if..then..else</code>]].
* '''Iteracja''' – wykonywanie instrukcji póki spełniony jest jakiś warunek. Reprezentowana w różnych wariantach jako [[Pętla (informatyka)|pętle]] oznaczane między innymi przez: <code>while</code>, <code>repeat</code>, <code>for</code> lub <code>do..until</code>.
Każda ze struktur kontrolnych może być też rozumiana jako pojedyncza instrukcja. Według pierwotnych założeń struktury kontrolne powinny posiadać jedno wejście i jedno wyjście.

=== Podprogramy ===
[[Podprogram]]y pozwalają na wydzielenie pewnej grupy instrukcji i traktowania ich jako pojedynczej operacji, są dodatkowo mechanizmem abstrakcji.

=== Bloki ===
W językach programowania bloki odpowiadają sekwencjom instrukcji, umożliwiając budowanie programu przez komponowanie struktur kontrolnych – w miejscu, w którym umieścimy blok z instrukcjami jest on traktowany jak pojedyncza instrukcja.

W kodzie źródłowym programów bloki są wyróżniane na różne sposoby, przykładowo ograniczone przez <code>if..fi</code> jako blok dla instrukcji <code>if</code> w [[ALGOL|ALGOLU 68]], czy dowolne bloki instrukcji obejmowanie poprzez <code>BEGIN..END</code> w [[Pascal (język programowania)|Pascalu]], [[PL/I]], przy pomocy wcięć w [[Python]]ie czy [[Haskell]]u lub poprzez nawiasy klamrowe w języku [[C (język programowania)|C]] i pochodnych.

== Historia ==
=== Przed programowaniem strukturalnym ===
Pierwsze komputery były programowane wprost z użyciem [[Język maszynowy|kodu maszynowego]]<ref>{{Cytuj stronę |url = https://sites.google.com/site/michaeldgodfrey/vonneumann/vnedvac.pdf?attredirects=0&d=1 |tytuł = First Draft of a Report on the EDVAC |autor = John von Neumann |opublikowany =  |język =  |data dostępu = 2015-02-05 |archiwum = https://web.archive.org/web/20150406152253/https://sites.google.com/site/michaeldgodfrey/vonneumann/vnedvac.pdf?attredirects=0&d=1 |zarchiwizowano = 2015-04-06 }}</ref> lub z wykorzystaniem [[asembler]]a. Pierwsze asemblery przypadają na połowę lat 50. W 1954 roku [[Nathaniel Rochester]] napisał asembler dla [[IBM 701]], natomiast w 1955 Stan Poley stworzył SOAP – asembler dla komputera [[IBM 650]], początkowo programowanego wyłącznie przy pomocy kodu maszynowego<ref>{{Cytuj stronę |url = http://www.columbia.edu/cu/computinghistory/650.html |tytuł = The IBM 650 Magnetic Drum Calculator |autor = |opublikowany = |język = |data dostępu = 2015-02-05}}</ref>. Kontrola przepływu w programie odbywała się głównie przy pomocy warunkowych i bezwarunkowych instrukcji skoku, w ówczesnych komputerach IBM określanych jako <code>branch</code> lub instrukcje transferu<ref>{{Cytuj stronę |url = http://bitsavers.trailing-edge.com/pdf/ibm/650/24-4000-0_SOAPII.pdf |tytuł = SOAP II |autor = IBM |opublikowany = |język = |data dostępu = 2015-02-05}}</ref><ref name="MIT-IBM">{{Cytuj stronę |url = http://bitsavers.trailing-edge.com/pdf/mit/computer_center/Coding_for_the_MIT-IBM_704_Computer_Oct57.pdf |tytuł = Coding for the MIT-IBM 704 Computer |autor = |opublikowany = |język = |data dostępu = 2015-02-05}}</ref>.

Wprowadzony w roku 1957 [[Fortran|FORTRAN]], pierwszy poważny [[Język wysokiego poziomu|język programowania wysokiego poziomu]], główny nacisk kładł na formuły arytmetyczne. Występujące w nim struktury (a raczej instrukcje) kontrolne nie wykraczały daleko poza możliwości instrukcji skoku w asemblerach<ref name="MIT-IBM" /> – język, poza skokiem bezwarunkowym, udostępniał przypisywalne (<code>assigned goto</code>) i obliczalne (<code>computed goto</code>) instrukcje skoku, oraz zbliżone do obliczalnego goto wyrażenie arytmetycznego (nie logicznego) <code>if</code>. Skoki były wykonywane do etykiet reprezentowanych przez wartości liczbowe. Dodatkowo występowała też prosta pętla.

=== ALGOL ===
Opublikowany w roku 1958 [[ALGOL]] 58 oraz jego dwa lata późniejsza, mocno rozwinięta wersja ALGOL 60, wprowadziły wiele kluczowych konstrukcji programistycznych, istotnych nie tylko z punktu widzenia programowania strukturalnego. Był to pierwszy język, w którym pojawił się koncept instrukcji złożonych – [[Instrukcja blokowa|bloków]] – służących do grupowania instrukcji. Blok jest traktowany jako pojedyncza instrukcja i możliwe jest użycie go w miejscu dla niej przeznaczonym.

Język ALGOL wprowadził również fundamentalne dla programowania strukturalnego konstrukcje: logiczne instrukcje warunkowe [[Instrukcja warunkowa|<code>if..then</code>]] z opcjonalnym [[Instrukcja warunkowa|<code>else</code>]], pętle <code>for</code> oraz instrukcję wyboru <code>switch</code>. Pozwolił też na deklarowanie procedur, w tym zagnieżdżonych w sobie, wraz z odpowiednim [[Zasięg (programowanie)|zasięgiem]] identyfikatorów. Instrukcja goto dalej pozostawała jednak ważnym elementem składniowym języka.

=== Podstawa teoretyczna ===
Jako fundament teorii programowania strukturalnego określa się twierdzenie o programowaniu strukturalnym. Jego autorstwo przypisuje się najczęściej [[Corrado Böhm|’Böhmowi]] i [[Giuseppe Jacopini]]emu, wskazując jako źródło ich pracę ''Flow Diagrams, Turing Machines And Languages With Only Two Formation Rule''s z maja 1966 roku<ref>{{Cytuj pismo |nazwisko = Harel |imię = David |tytuł = On Folk Theorems |url = http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/OnFolkTheorems.pdf |czasopismo = Communications of the ACM |wolumin = 23 |wydanie = 7 |strony = 379–389 |data = lipiec 1980 |issn = |doi = 10.1145/358886.358892}}</ref>. W swojej pracy pokazali oni, że dowolny program zawierający skoki (czyli dowolny graf przepływu), może zostać znormalizowany do odpowiadającego mu ustrukturyzowanego grafu – zbudowanego z trzech podstawowych struktur: <math>\Pi,</math> <math>\Delta</math> oraz <math>\Omega,</math> wyrażającym odpowiednio: sekwencję, wybór oraz iterację. Ponieważ grafy przepływu mogą wyrażać dowolne [[Funkcja obliczalna|funkcje obliczalne]], to oznacza, że możemy też takie wyrazić przy pomocy tych podstawowych konstrukcji. W dalszej części pracy opisany jest język [[P′′]] – pierwszy strukturalny język, dla którego udowodniono [[Kompletność Turinga|zupełność w sensie Turinga]].

Twierdzenie Böhma i Jacopiniego nie mówi o tym w jaki sposób tworzyć dobre programy strukturalne lub je analizować. Prace nad tymi zagadnieniami odbywały się głównie na przełomie lat 60 i 70, z istotnym wkładem dokonamy przez [[Edsger Dijkstra|Edsgera Dijkstrę]], [[Robert W. Floyd|Roberta W. Floyda]], [[Charles Antony Richard Hoare|Tony’ego Hoare’a]], [[Ole-Johan Dahl|Ole-Johana Dahla]], oraz [[David Gries|Davida Griesa]].

=== Dyskusja ===
Już na etapie projektowania języka ALGOL, w roku 1959, Heinz Zemanek rozważał ograniczenie użycia instrukcji goto, jednak jego uwagi zostały wtedy zignorowane<ref name="Dijkstra-GOTO">{{Cytuj pismo |nazwisko = Dijkstra |imię = Edsger |tytuł = Go to statement considered harmful |url = https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF|czasopismo = Communications of the ACM |wolumin = 11 |wydanie = 3 |strony = 147–148 |data = marzec 1968 |issn = |doi = 10.1145/362929.362947}}</ref>. Niedługo później Hoare proponował ograniczenie użycia skoków tylko do wyjść alarmowych, natomiast w roku 1966 razem z [[Niklaus Wirth|Wirthem]] proponowali ograniczenia w postaci instrukcji wyboru <code>case</code><ref name="Dijkstra-GOTO" /><ref>{{Cytuj pismo |nazwisko = Hoare |imię = C.A.R. |tytuł = A contribution to the development of ALGOL |czasopismo = Communications of ACM |wolumin = 9 |wydanie = |strony = 413–432 |data = czerwiec 1966 |issn = |autor2 = Niklaus |nazwisko2 = Wirth |autor =}}</ref>.

W debacie pomiędzy programistami dotyczącej popularyzacji programowania strukturalnego i ograniczeniu programowania opartego na goto najistotniejszym punktem jest praca Edsgera Dijkstry z 1974 roku ''A Case against GO TO Statemant ''opublikowana pod tytułem [[Goto Statement considered Harmful.|Goto Statement considered Harmful]]. Autor w sposób zdecydowany wyraża się przeciwko użyciu tej instrukcji:
{{Cytat
 |treść = Instrukcja go to powinna zostać usunięta z wszystkich „wysokopoziomowych” języków programowania (to znaczy z wszystkich poza – prawdopodobnie - czystym kodem maszynowym)<ref name="Dijkstra-GOTO" />.
}}

Odwołuje się też do twierdzenia Böhma i Jacopiniego, które umożliwia pokazanie, że goto jest instrukcją zbędną. Podaje przyczyny, przez które programy używające skoków są trudne w analizie. Dijkstra proponuje też odpowiednie ograniczenia na struktury kontrolne, jak na przykład [[Instrukcja opuszczenia]], tak by dalej pozwalały na odpowiednią analizę, jeśli zestaw podstawowych instrukcji okazałby się zbyt ograniczający.

Jednym z pierwszych dużych komercyjnych projektów wykorzystujących programowanie strukturalne, który odniósł duży sukces było wykonane przez [[Harlan Mills|Harlana Millsa]] z IBM systemu indeksującego zbierane informacje dla [[The New York Times|New York Times]].

Mimo kolejnych sukcesów związanych z aplikacją technik programowania strukturalnego, jak i rozwojowi teorii jej poświęconej, spora liczba [[Programista|programistów]] wciąż opierała się ograniczeniu lub wyeliminowaniu instrukcji goto z użycia<ref>{{Cytuj książkę |nazwisko = Plauger |imię = P.J. |tytuł = Programming on Purpose, Essays on Software Design |rok = 1993 |wydawca = Prentice-Hall |miejsce = |strony = 25 |isbn = 978-0-13-721374-0}}</ref>. [[Donald Knuth]] w 1974 roku opublikował pracę ''Structured Programming with GoTo Statements''<ref>{{Cytuj stronę |url = http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf |tytuł = Structured Programming with GoTo Statements |autor = Donald Knuth |opublikowany =  |język =  |data dostępu = 2015-02-08 |archiwum = https://web.archive.org/web/20131023061601/http://cs.sjsu.edu/~mak/CS185C/KnuthStructuredProgrammingGoTo.pdf |zarchiwizowano = 2013-10-23 }}</ref>, w której opisywał sytuacje gdzie użycie skoku upraszcza rozwiązanie bez wpływu na trudność w jego analizie.

W roku 1987 na łamach [[Communications of the ACM]] po liście Franka Rubina ''„GOTO Considered Harmful” Considered Harmful''<ref name="marzec">{{Cytuj pismo |nazwisko =Rubin |imię =Frank |tytuł = „GOTO Considered Harmful” Considered Harmful |czasopismo = Communications of the ACM |wolumin = 30 |wydanie = 3 |strony = 195–196 |data = marzec 1987 |issn =}}</ref> na nowo rozgorzała dyskusja dotycząca słuszności użycia goto, zarówno z głosami poparcia dla Rubina i użycia skoków, jak i mocnymi głosami przeciwko (razem z tytułami, stopniowo zawierającymi w coraz większej liczbie frazę „Considered Harmful”)<ref name="maj">{{Cytuj pismo |nazwisko = |imię = |tytuł = „'GOTO Considered Harmful’ Considered Harmful” Considered Harmful? |czasopismo = Communications of the ACM |wolumin = 30 |wydanie = 5 |strony = 351–355 |data = maj 1987 |issn =}}</ref><ref name="czerwiec">{{Cytuj pismo |nazwisko = |imię = |tytuł = „'GOTO Considered Harmful’ Considered Harmful” Considered Further |czasopismo = Communications of the ACM |wolumin = 30 |wydanie = 6 |strony = 475–478 |data = czerwiec 1987 |issn =}}</ref>. Rubin twierdził:

{{Cytat
 |treść = Wiara, że GOTO są złe, stała się doktryną religijną, niepodważalną żadnymi dowodami<ref name="marzec" />
}}

Zdaniem edytora była to największa wymiana listów w historii forum<ref name="czerwiec" />. Dyskusję uciął ostry list Dijkstry, poniekąd zawiedzionego poziomem dyskusji, jak i samymi próbami ponownej popularyzacji instrukcji goto<ref name="sierpien">{{Cytuj pismo |nazwisko = |imię = |tytuł = GOTO, One More Time |czasopismo = Communications of the ACM |wolumin = 30 |wydanie = 8 |strony = 659–662 |data = sierpień 1987 |issn =}}</ref><ref>{{Cytuj stronę |url = http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1009.html |tytuł = On a somewhat disappointing correspondence |autor = Edsger Dijkstra |opublikowany = |język = |data dostępu = 1987-05-25}}</ref>.

=== Wpływ na języki programowania ===
Popularyzacja programowania strukturalnego zaowocowała wprowadzeniem konstrukcji programowania strukturalnego, często inspirowanych ALGOLEM, do języków programowania, które wcześniej ich nie posiadały, takich jak FORTRAN, [[COBOL]] czy BASIC.

== Częste odstępstwa ==
O ile można obserwować zanik użycia goto, to istnieje niewiele czysto strukturalnych języków programowania. Najczęściej poza podstawowymi strukturami kontrolnymi pojawia się możliwość wczesnego wyjścia, łamiąc tym samym zasadę pojedynczego wyjścia z każdej struktury. Obsługa wyjątków również wykracza poza założenia programowania strukturalnego.

=== Wczesne wyjście ===
Najczęściej spotykana jest możliwość wyjścia z danej pętli lub podprogramu. Na poziomie podprogramu jest to zwykle instrukcja <code>[[Instrukcja powrotu|return]]</code>. W przypadku pętli są to instrukcje <code>[[Instrukcja opuszczenia|break]]</code> (przerwij daną pętlę) lub <code>[[Instrukcja kontynuacji|continue]]</code> (przerwij daną iterację i przejdź do następnej). W czystym kodzie strukturalnym można napisać równoważne programy z wykorzystaniem dodatkowych instrukcji warunkowych, jednak może istotnie zwiększyć złożoność programów. Język [[C (język programowania)|C]] jest jednym z wczesnych przykładów wprowadzenia tego typu konstrukcji. Niektóre nowe języki programowania wprowadzają instrukcje „etykietowanego break”, które pozwalają opuścić więcej niż jeden poziom zagnieżdżonych pętli w pojedynczym kroku.

Wczesne wyjścia mogą powodować pewne trudności przy tworzeniu programów, związane na przykład z koniecznością zwalniania zaalokowanych zasobów przy każdym miejscu, w którym może być wykonany powrót z danego podprogramu. Występują różne podejścia: [[Pascal (język programowania)|Pascal]] unika tych problemów nie dopuszczając tego typu konstrukcji, natomiast języki obiektowe wysokiego poziomu, takie jak [[C++]] czy [[Java]] zawierają odpowiednie mechanizmy ([[Resource Acquisition Is Initialization|RAII]] lub [[odśmiecanie pamięci]]) mające na celu ułatwienie pracy programiście.

[[Kent Beck]], [[Martin Fowler]] wraz ze współautorami swoich książek na temat [[refaktoryzacja|refaktoryzacji]] stwierdzają, że mocno zagnieżdżone bloki instrukcji warunkowych mogą być trudniejsze w zrozumieniu niż bardziej spłaszczona struktura z wieloma punktami wyjścia.

{{Cytat
 |treść = Pojedynczy punkt wyjścia nie jest tak naprawdę użyteczną regułą. Kluczem jest przejrzystość: Jeśli metoda jest prostsza z jednym punktem wyjścia, użyj jednego, w przeciwnym przypadku, użyj wielu<ref>{{Cytuj książkę |autor = Jay Fields |tytuł = Refactoring: Ruby Edition |wydawca = Pearson Education |data = 2009 |strony = 274–279 |isbn = 978-0-321-60350-0 |imię2=Shane |nazwisko2 = Harvie |imię3=Martin |nazwisko3 = Fowler |imię4=Kent |nazwisko4 = Beck}}</ref>
}}

[[Herb Sutter]] i [[Andrei Alexandrescu]] również stwierdzają, że zasada pojedynczego wyjścia nie ma zastosowania w C++, jest tak za sprawą obsługi wyjątków i destruktorów, przez co każda funkcja może mieć wiele niejawnych punktów wyjścia<ref>{{Cytuj książkę |nazwisko = Sutter |imię = Herb |tytuł = C++ Coding Standards: 101 Rules, Guidelines, and Best Practices |wydawca = Pearson Education |data = 2004 |isbn = 978-0-13-265442-5 |nazwisko2 = Alexandrescu |imię2 = Andrei}}</ref>.

Odmienne zdanie wyraża natomiast [[Bertrand Meyer]], który w 2009 opisał <code>break</code> i <code>continue</code> jako „stare <code>goto</code> w owczej skórze” i mocno odradzał ich użycie<ref>{{Cytuj książkę |autor = Bertrand Meyer |tytuł = Touch of Class: Learning to Program Well with Objects and Contracts |wydawca = Springer Science & Business Media |data = 2009 |strony = 189 |isbn = 978-3-540-92144-8}}</ref>.

=== Obsługa wyjątków ===
Badacze spierają się co do użycia [[Wyjątek|wyjątków]] w kontekście programowania strukturalnego, jako że łamią one zasadę pojedynczego wyjścia. Cytując wcześniejsze badania (1999–2004) i podając własne, [[Westley Weimer]] i [[George Necula]] stwierdzają, że problem z wyjątkami polega na tym, że „tworzą ukryte ścieżki przepływu sterowania, o których programistom ciężko wnioskować”<ref>{{Cytuj pismo |nazwisko = Weimer |imię = Westley |nazwisko2 = George |imię2 = Necula |autor = Exceptional Situations and Program Reliability |czasopismo = ACM Transactions on Programming Languages and Systems |wydanie = 2 |wolumin = 30}}</ref>.
Pojawiają się propozycje by sprowadzić wyjątki do pojedynczego wyjścia, jak i opinie, by pozostawić pełną dowolność w ich użyciu, jako że reguła pojedynczego wyjścia powstała przed pojawieniem się i popularyzacją wyjątków, a opakowywanie wyjątków by uczynić zgodnymi z regułą jednego wyjścia dodaje zbędne poziomy zagnieżdżenia utrudniając zrozumienie programów<ref>{{Cytuj stronę |url = http://pragprog.com/magazines/2012-04/the-pragmatic-defense |tytuł = The Pragmatic Defense: Making Defects Easier to Find |autor = Jim Bonang |data = kwiecień 2012 |data dostępu = 2015-02-08 |archiwum = https://web.archive.org/web/20170710032214/https://pragprog.com/magazines/2012-04/the-pragmatic-defense |zarchiwizowano = 2017-07-10 }}</ref><ref>{{Cytuj stronę |url = http://blogs.msmvps.com/peterritchie/2008/03/07/single-entry-single-exit-should-it-still-be-applicable-in-object-oriented-languages/ |tytuł = Single-Entry, Single-Exit, Should It Still Be Applicable In Object-oriented Languages? |autor = Peter Ritchie |data = 2008-03-07 |data dostępu = 2015-02-08}}</ref>.

== Zobacz też ==
* [[Paradygmat programowania]]
* [[Programowanie obiektowe]]
* [[Graf przepływu sterowania]]

== Przypisy ==
{{Przypisy}}

== Bibliografia ==
* {{Cytuj pismo |nazwisko = Böhm |imię = Corrado |nazwisko2 = Jacopini |imię2 = Giuseppe |tytuł = Flow diagrams, Turing machines and languages with only two formation rules |czasopismo = Communications of the ACM |wydanie = 5 |wolumin = 9 |strony = 366–371 |data = maj 1966 |doi = 10.1145/355592.365646}}
* {{Cytuj pismo |nazwisko = Dijkstra |imię = Edsger |tytuł = Go to statement considered harmful |url = https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF|czasopismo = Communications of the ACM |wolumin = 11 |wydanie = 3 |strony = 147–148 |data = marzec 1968 |issn = |doi = 10.1145/362929.362947}}

{{Kontrola autorytatywna}}

[[Kategoria:Paradygmaty programowania]]