Struktura blokowa programu. Zasady układu bloków

Jak działa układ blokowy?

Przed uruchomieniem układu, gotowy układ psd witryny jest cięty na bloki (warstwy) w edytorze graficznym. Wycięte zdjęcia tła umieszczane są w osobnym folderze, który zostanie dołączony osobno do każdej warstwy:

Możesz dowiedzieć się więcej o wszystkich właściwościach CSS z dokumentacji technicznej języka.

Pełny kod przykładu index.html:

Zawartość pliku style.css:

body (tło: # f3f2f3; kolor: # 000000; rodzina czcionek: Trebuchet MS, Arial, Times New Roman; rozmiar czcionki: 12px;) #container (tło: # 99CC99; margines: 30px auto; szerokość: 900px; wysokość : 600px;) #header (tło: # 66CCCC; wysokość: 100px; szerokość: 900px;) #nawigacja (tło: # FF9999; szerokość: 900px; wysokość: 20px;) #menu (tło: # 99CC99; float: lewo; szerokość: 200px; wysokość: 400px;) #treść (tło: # d2d0d2; pływak: prawo; szerokość: 700px; wysokość: 400px;) #wyczyść (wyczyść: oba;) #stopka (tło: # 0066FF; wysokość: 80px; szerokość: 900px ;)

Tak wygląda nasz przykładowy układ witryny oparty na blokach w oknie przeglądarki.

Przystępując do opracowywania każdego programu COP należy pamiętać, że jest to duży system, dlatego należy podjąć kroki w celu jego uproszczenia. Aby to zrobić, program jest rozwijany w częściach, które nazywane są modułami oprogramowania. Ta technika programowania nazywana jest programowaniem modułowym.

Moduł jest niezależną częścią programu, która ma określone znaczenie i zapewnia określone funkcje przetwarzania niezależnie od innych modułów programu. Każdy moduł programu jest programowany, kompilowany i debugowany oddzielnie od innych modułów programu, a zatem fizycznie oddzielony od innych modułów programu. Każdy moduł oprogramowania może być włączony do różnych programów, jeżeli spełnione są warunki jego użytkowania opisane w dokumentacji jego użytkowania. Te. przemyślany moduł pozwala uniknąć powielania w programowaniu.

Każdy system oprogramowania ma swoją własną strukturę, opracowaną dla wygody:

• 1. rozwój
• 2.programowanie
• 3.debug
• 4. dokonywanie zmian

Ponadto struktura PS umożliwia:

• 1.przydziel pracę wykonawcom, zapewniając ich wczytywanie i wymagany czas realizacji
• 2. Budowanie kalendarza prac projektowych i koordynowanie ich w procesie tworzenia PI.
• 3. kontrolować koszty pracy i koszty prac projektowych.

Podczas tworzenia systemu oprogramowania przydzielane są moduły wielokrotnego użytku, są wpisywane i ujednolicane, co zmniejsza czas i koszty pracy związane z opracowywaniem systemu oprogramowania jako całości.

Niektóre systemy oprogramowania wykorzystują gotowe moduły z bibliotek standardowych procedur, funkcji, obiektów i metod przetwarzania danych.

Typowa struktura PS:

moduł programu do debugowania multimediów

Stół. Typy modułów

Właściwości modułu:

• 1.jedno wejście i jedno wyjście - na wejściu moduł programu otrzymuje określony zestaw danych początkowych, wykonuje obróbkę danych i zwraca wynik
• 2. kompletność funkcjonalna – moduł wykonuje listę operacji dla realizacji każdej funkcji w całości.
• 3. niezależność logiczna - wynik pracy modułu zależy tylko od danych początkowych, a nie od pracy innych modułów.
• 4. słabe powiązania informacyjne z innymi modułami oprogramowania – wymiana informacji między modułami powinna być maksymalnie zminimalizowana.
• 5. Obserwowalne pod względem wielkości i złożoności.

Każdy moduł składa się ze specyfikacji i korpusu modułu.

Specyfikacja - zasady korzystania z modułu.

Ciało jest sposobem realizacji procesu przetwarzania.

Zasada modułowego programowania PS:

• 1. Ustalenie składu i podporządkowania funkcji
• 2. zdefiniowanie zestawu modułów oprogramowania realizujących te funkcje

Przy opracowywaniu algorytmu należy wziąć pod uwagę:

1. Każdy moduł jest wywoływany do wykonania przez moduł nadrzędny i po zakończeniu zwraca kontrolę do modułu wywołującego.

Metody opracowywania struktury programu.

Zwyczajowo stosuje się strukturę podobną do drzewa jako modułową strukturę programu, w tym drzewa z połączonymi gałęziami. Moduły są umieszczone w węzłach drzewa, a strzałki pokazują podporządkowanie modułów (tzn. w tekście modułu, z którego pochodzi, znajduje się link do modułu, do którego należy).

Modułowa struktura programu musi również zawierać zestaw specyfikacji modułów składających się na ten program. Specyfikacja modułu oprogramowania zawiera:

• 1.syntaktyczna specyfikacja jego wejść, pozwalająca na zbudowanie odwołania do niego w używanym języku programowania
• 2. specyfikacja funkcjonalna modułu (opis wszystkich funkcji realizowanych przez ten moduł).

Istnieją różne metody projektowania struktury programu. Zwykle stosuje się 2 metody:

• 1. Metoda rozwoju oddolnego
• 2. metoda odgórnego rozwoju

Metoda rozwoju oddolnego.

Po pierwsze, modułowa struktura programu budowana jest w formie drzewa. Następnie moduły programowe są programowane jeden po drugim, zaczynając od modułów najniższego poziomu, w takiej kolejności, że dla każdego modułu programowalnego są już zaprogramowane wszystkie moduły, do których ma on dostęp. Po zaprogramowaniu wszystkich modułów programu są one testowane i debugowane jeden po drugim, w zasadzie w tej samej (rosnącej) kolejności, w jakiej zostały zaprogramowane. Na pierwszy rzut oka taka kolejność tworzenia programu wydaje się całkiem naturalna: każdy moduł jest wyrażony podczas programowania przez już zaprogramowane bezpośrednio podrzędne moduły, a podczas testowania wykorzystuje już zdebugowane moduły. Niezalecane, ponieważ:

• 1.do zaprogramowania dowolnego modułu nie są wymagane żadne teksty, używane przez niego moduły - do tego wystarczy, że każdy używany moduł jest tylko określony (w takim stopniu, który pozwala na zbudowanie do niego poprawnej referencji), a dla testując ewentualnie używane moduły, zastąp je symulatorami (nasadkami).
• 2.Każdy program do pewnego stopnia podlega pewnym względom wewnętrznym, ale globalnym dla jego modułów (zasady implementacji, założenia, struktury danych itp.), co stanowi o jego integralności koncepcyjnej i kształtuje się w procesie jego rozwoju. W rozwoju oddolnym ta globalna informacja dla modułów niższego poziomu nie jest jeszcze w pełni jasna, więc bardzo często trzeba je przeprogramować.
• 3. Podczas testowania oddolnego, dla każdego modułu (oprócz głównego) konieczne jest stworzenie programu (modułu) nadrzędnego, który musi przygotować niezbędny stan środowiska informacyjnego dla testowanego modułu i wykonać wymagany zadzwoń do niego. Prowadzi to do dużej ilości "debugowania" programowania i jednocześnie nie daje żadnej gwarancji, że testowanie jednostek zostało przeprowadzone dokładnie w warunkach, w jakich będą wykonywane w programie roboczym.

Odgórna metoda rozwoju.

Po pierwsze, modułowa struktura programu budowana jest w formie drzewa. Następnie programuje się moduły programowe jeden po drugim, zaczynając od modułu najwyższego poziomu (nagłówka), przechodząc do programowania dowolnego innego modułu tylko wtedy, gdy moduł, który go adresuje, został już zaprogramowany. Po zaprogramowaniu wszystkich modułów programu są one testowane i debugowane jeden po drugim w tej samej (malejąco) kolejności.

Pozytywne strony

• 1. Przy takiej kolejności rozwoju programu wszystkie niezbędne informacje globalne są generowane w odpowiednim czasie, tj. bardzo nieprzyjemne źródło błędów przy eliminacji modułów programistycznych.
• 2. Znacznie ułatwione jest również testowanie jednostek podczas odgórnego testowania programu. Najpierw testowany jest główny moduł programu, który reprezentuje cały testowany program, a zatem jest testowany w „naturalnym” stanie środowiska informacyjnego, w którym program zaczyna działać. W tym przypadku wszystkie moduły, do których ma dostęp głowica, zostają zastąpione ich symulatorami. Symulator modułu to prosty fragment programu sygnalizujący sam fakt dostępu do symulowanego modułu z przetworzeniem wartości jego parametrów wejściowych niezbędnych do poprawnej pracy programu i wydaniem, jeśli to konieczne, odpowiedniego zapisanego wyniku z góry. Po zakończeniu testowania i debugowania głowicy i każdego kolejnego modułu następuje przejście do testowania jednego z modułów, które są obecnie reprezentowane przez symulatory, jeśli takie istnieją. W tym celu symulator modułu wybranego do testowania jest zastępowany samym tym modułem i dodawane są symulatory tych modułów, do których dostęp ma moduł wybrany do testowania. W takim przypadku każdy taki moduł będzie testowany w „naturalnych” stanach środowiska informacyjnego, które powstają w momencie uzyskania dostępu do tego modułu podczas wykonywania testowanego programu. W ten sposób dużą ilość programowania "debugującego" zastępuje się programowaniem dość prostych symulatorów modułów użytych w programie. Ponadto symulatory są przydatne do zabawy wraz z procesem wyboru testu poprzez określenie pożądanych wyników z symulatorów.

Rozważane metody nazywane są klasycznymi. W nich modułowa struktura drzewa programu musi zostać opracowana przed rozpoczęciem programowania modułów. Takie podejście budzi jednak szereg zastrzeżeń: jest mało prawdopodobne, aby przed programowaniem modułów możliwe było opracowanie struktury programu o wystarczającej dokładności i zawartości.

Przy konstruktywnym i architektonicznym podejściu do tworzenia programów, w procesie programowania modułów powstaje struktura modułowa.

Konstruktywne podejście (modyfikacja od góry do dołu)

Modułowa, drzewiasta struktura programu powstaje w procesie programowania modułu. Najpierw programuje się moduł główny, wychodząc od specyfikacji programu jako całości, a specyfikacja programu jest jednocześnie specyfikacją jego modułu głównego, ponieważ ten ostatni w pełni przejmuje odpowiedzialność za realizację funkcji programu . W procesie programowania modułu głowicy, jeśli ten program jest wystarczająco duży, podświetlane są funkcje wewnętrzne, w zakresie których programowany jest moduł głowicy. Oznacza to, że dla każdej funkcji, która ma zostać przydzielona, ​​tworzona jest specyfikacja dla fragmentu programu, który ją implementuje, który później może być reprezentowany przez jakieś poddrzewo modułów. Należy zauważyć, że tutaj moduł główny (być może jedyny) tego poddrzewa również bierze odpowiedzialność za wykonanie dedykowanej funkcji, więc specyfikacja dedykowanej funkcji jest również specyfikacją modułu głównego tego poddrzewa. W module head programu, aby uzyskać dostęp do wybranej funkcji, konstruowane jest wywołanie modułu head określonego poddrzewa zgodnie z jego utworzoną specyfikacją. W ten sposób w pierwszym kroku tworzenia programu (przy programowaniu jego modułu głównego) tworzona jest początkowa górna część drzewka, np. ta pokazana na rys. 7.1.

Ryż. 7,1

Podobne akcje wykonuje się podczas programowania dowolnego innego modułu, który jest wybrany z aktualnego stanu drzewa programu spośród określonych, ale jeszcze nie zaprogramowanych modułów. W wyniku tego wykonywana jest kolejna deformacja drzewa programu, np. ta pokazana na rys. 7.2.

Podejście architektoniczne (modyfikacja od dołu do góry)

Modułowa struktura programu powstaje podczas programowania modułu. Ale jednocześnie stawia się kolejny cel rozwojowy: podniesienie poziomu używanego języka programowania, a nie tworzenie konkretnego programu. Oznacza to, że dla danego obszaru tematycznego identyfikowane są typowe funkcje, z których każda może być wykorzystana do rozwiązywania różnych problemów w tym obszarze, a poszczególne moduły oprogramowania są określane, a następnie programowane do realizacji tych funkcji. Ponieważ proces przydzielania takich funkcji wiąże się z gromadzeniem i uogólnianiem doświadczenia w rozwiązywaniu problemów w danym obszarze tematycznym, zwykle prostsze funkcje są najpierw przydzielane i implementowane przez osobne moduły, a następnie stopniowo pojawiają się moduły wykorzystujące wcześniej przydzielone funkcje. Taki zestaw modułów jest tworzony z założeniem, że niektóre z tych modułów mogą być akceptowalne przy tworzeniu konkretnego programu z danego obszaru tematycznego w ramach konstruktywnego podejścia.

Pozwala to na obniżenie kosztów pracy przy tworzeniu konkretnego programu poprzez podłączenie do niego wcześniej przygotowanych i przetestowanych w praktyce struktur modułowych niższego poziomu. Ponieważ takie struktury można ponownie wykorzystać w różnych konkretnych programach, podejście architektoniczne może być postrzegane jako sposób na zwalczanie powielania w programowaniu. W związku z tym moduły oprogramowania tworzone w ramach podejścia architektonicznego są zwykle parametryzowane w celu zwiększenia stosowalności takich modułów poprzez dostrojenie ich do parametrów.

Ryż. 7,2

Metoda realizacji odgórna. Każdy zaprogramowany moduł jest natychmiast testowany przed przystąpieniem do programowania kolejnego modułu.

Moduł jest funkcjonalnie niezależną częścią programu zawierającą zestaw powiązanych ze sobą zmiennych, stałych, funkcji i procedur zaprojektowanych w celu realizacji dowolnej jego funkcjonalności. Moduł można debugować niezależnie od innych modułów programu iw ten sposób organizować wspólną pracę kilku programistów na jednym programie, podzielonym na moduły.

Za pomocą modułów można tworzyć biblioteki procedur, które można przechowywać zarówno jako kod źródłowy, jak i kod obiektowy (kod gotowy do kompilacji i łączenia z innymi modułami). W Delphi skompilowany kod obiektowy modułu jest przechowywany w plikach z rozszerzeniem „.dpu”.

Struktura modułu jest podobna do struktury programu Pascal. Nagłówek modułu jest wymagany i zaczyna się od słowa UNIT (zamiast PROGRAM, jak w normalnym programie):

Jednostka<имя модуля>;

Nazwa modułu musi być taka sama jak nazwa pliku Pascal. Kiedy Delphi automatycznie generuje różne moduły, sprawia, że ​​nazwa modułu odpowiada nazwie pliku.

W przeciwieństwie do programu może brakować treści modułu (sekcji instrukcji). Służy do inicjalizacji zmiennych modułu i jest wykonywana przed wykonaniem instrukcji programu głównego. Moduł zawiera dwie obowiązkowe części: interfejsową i wykonawczą.

Część interfejsowa modułu nazywana jest również otwartą, a część wykonawczą zamkniętą. Deklaracje w sekcji front-end są często określane jako interfejs publiczny, a deklaracje w sekcji implementacji są często określane jako interfejs prywatny. Wszystkie zmienne i funkcje zadeklarowane w sekcji interfejsu są dostępne dla wszystkich modułów i programów łączących ten moduł. Wszystkie zmienne i funkcje zadeklarowane w sekcji implementacji są dostępne tylko w tym module. Taki podział zakres wykonane specjalnie w celu ukrycia przed użytkownikiem tych pośrednich etapów obliczeń, których nie musi znać, a które może nieumyślnie lub celowo zepsuć. Zapewnia to niezawodną ochronę dla wszystkich funkcji i zmiennych, które są przeznaczone tylko do użytku wewnętrznego, chociaż nie zawsze jest to wygodne i musisz napisać dodatkowe funkcje, aby uzyskać dostęp do zmiennych wewnętrznych.

Część interfejsu zaczyna się od słowa Interfejs. Interfejs łączy program główny z modułem lub moduł z innymi modułami. Część interfejsowa określa obiekty (procedury, funkcje, zmienne, stałe, typy) dostępne dla każdego użytkownika tego modułu.

Wśród procedur i funkcji modułu mogą znajdować się te pomocnicze, których twórca modułu może nie uwzględnić w opisie interfejsu, wówczas będą one ukryte przed użytkownikami i nie będą dostępne do wykorzystania poza modułem.

Jeżeli moduł wykorzystuje w swojej pracy możliwości (procedury, funkcje, zmienne) innych modułów, to jest to zaznaczone na początku modułu za pomocą konstrukcji USES, po czym wskazane są nazwy wszystkich modułów podłączonych do tego modułu, np. przykład:

Używa M1, M2 ...;

Ponadto część interfejsu opisuje stałe, typy, zmienne, procedury i funkcje, których można użyć podczas wywoływania tego modułu, a procedury i funkcje są określone jako nagłówki, bez treści. Same organy postępowania opisane są w dalszej części modułu – części zamkniętej – wykonawczej. W części front-endowej bardzo ważne jest udokumentowanie wszystkich przypisań dla każdego elementu części front-endowej, wszystkich parametrów, stałych i typów za pomocą komentarzy, aby użytkownicy modułu mogli z niego łatwo korzystać.

Część interfejsu kończy się wraz z początkiem części wykonawczej. Sekcja wykonania zaczyna się od słowa kluczowego Implementation. Zawiera ciała wszystkich procedur i funkcji opisanych w części dotyczącej interfejsu. Może zawierać lokalne etykiety funkcji i sekcje instrukcji. Po słowie Implementacja może nastąpić również słowo Uses z listą modułów, które są używane w części wykonawczej. Dalej są etykiety, typy, stałe, zmienne, procedury i (funkcje modułu.

Po części wykonania może nastąpić opcjonalna część inicjowania danych, zaczynając od słowa kluczowego Initialization. Zawiera operatory, które są wykonywane przy pierwszym dostępie do modułu,

Na końcu modułu może znajdować się opcjonalna część uzupełniania, zaczynająca się od słowa kluczowego Finalization, które zawiera instrukcje wykonywane po każdym zakończeniu modułu. Moduł kończy się słowem kluczowym „end”. z obowiązkową kropką na końcu.

W skrócie składnia do opisu modułu wygląda tak:

Jeśli zmienne o tej samej nazwie są używane w różnych modułach, należy użyć prefiksu, aby uzyskać dostęp do zmiennej modułu:

<имя модуля>. <имя переменной>.

Przykład 10.1. Rozważmy możliwości połączenia modułów. Program może być krótszy poprzez umożliwienie modułom korzystania ze swoich wewnętrznych elementów.

znak "> ścisłe połączenie między modułami (lub wysoki stopień spójności modułów), w tym przypadku niemożliwe staje się ich oddzielne stosowanie, co narusza zasady programowania modułowego.

Jeśli wykonasz połączenie krzyżowe w sekcjach interfejsu, kompilator naprawi błąd. Połączenia krzyżowe modułów można wykonać tylko w sekcjach implementacyjnych, ale lepiej tego unikać ze względu na wynikającą z tego współzależność modułów.

Zwykle przy projektowaniu programów podział projektu na moduły następuje już na samym początku tworzenia systemu informatycznego. Ten proces nazywa się modularyzacją. Z reguły robi to analityk systemowy projektu i jego zespół. Uważa się, że rozmiar modułu powinien mieścić się w zakresie 30-300 wierszy tekstu źródłowego. Widoczność modułu jest znacznie poprawiona dzięki wykorzystaniu komentarzy w nagłówku (początku) modułu oraz szczegółowemu opisowi jego funkcji. Na pierwszy rzut oka wystarczy przeczytać komentarze-nagłówki, praktycznie nie zwracając uwagi na resztę tekstu.

Zwykle wynik modularyzacji jest przedstawiany jako wykres relacji modułów i (lub) podsystemów. Podstawą („root”) tego wykresu jest program główny. Każdy wierzchołek wykresu reprezentuje moduły, a łuki łączące wierzchołki pokazują wzajemne połączenie modułów.

W pobliżu wierzchołków grafu napisane są elementy interfejsu: nazwy procedur, funkcji, stałych, zmiennych zadeklarowanych w otwartej części modułu, które szerzej opisane są w komentarzach do modułu w postaci pełnego opisu część interfejsu. Nad łukami znajdują się nazwy używane w powiązanym module (zwykle nadrzędnym). W takim przypadku połączenie może się krzyżować, tj. moduł A wykorzystuje elementy interfejsu modułu B i. przeciwnie, moduł B wykorzystuje elementy interfejsu modułu A. Jak już wspomniano, taki projekt jest niepożądany, ale możliwy. W tym przypadku zastosowane elementy interfejsu są napisane nad i pod łukiem łączącym moduły. Podajmy przykład takiego wykresu (ryc.10.1
).

Tutaj program główny P jest podzielony na trzy główne moduły M1, M2, MZ. Spośród tych modułów program wykorzystuje elementy interfejsu A, B, C (z modułu pierwszego), D (z modułu drugiego), F, G, K, L (z modułu trzeciego). Każdy z tych modułów jest podzielony na mniejsze, na przykład M2 jest podzielony na M2.1, M2.2, M2.3 itd. Na tym diagramie widać na przykład powiązania między modułami M2 i M3, a także między M2.2 i M2.3.

Po zakończeniu modularyzacji każdy moduł zostanie rozprowadzony do kodowania wśród programistów w celu samodzielnego kodowania i debugowania. Jednak w takich przypadkach często dochodzi do sytuacji, gdy moduł nadrzędny ma korzystać z procedur i funkcji modułów podrzędnych, ale moduły podrzędne nie zostały jeszcze zakodowane przez innych programistów. Na przykład moduł MZ używa elementów K, L z modułów podrzędnych, ale te moduły nie są jeszcze gotowe. A co z programistą, który implementuje kod modułu MZ? Wyjściem z tej sytuacji jest napisanie w module nadrzędnym procedur (lub funkcji) „stubs”, które pod względem nazwy i parametrów całkowicie pokrywają się z elementami K, L. Stubs pozwalają skompilować i uruchomić program w trybie debugowania.

"Stub" - procedura jest reprezentowana przez dokładną specyfikację tytułu (nazwa i parametry) oraz pustą treść. "Stub" - funkcja jest reprezentowana przez dokładną specyfikację nagłówka (nazwa i parametry) i ma tylko jeden operator w treści, który zwraca wartość funkcji. Na przykład treść funkcji skrótowej L może wyglądać tak:

formuła "src =" http://hi-edu.ru/e-books/xbook691/files/ris-page173.gif "border =" 0 "wyrównaj =" absmiddle "alt =" (! LANG:

Przy dobrej modularyzacji graf połączeń modułów z reguły jest drzewem, a elementy interfejsu są używane wzdłuż grafu od liści drzewa do węzłów wyższego poziomu. Jednak nie zawsze jest to możliwe i musisz przeanalizować i zoptymalizować wykres. Do analizy jakości wyników modularyzacji wykorzystuje się dwie cechy: łączność modułów i konkatenację modułów, które omówiono poniżej.

Łączność modułów zdefiniowana jako miara niezależności części składowych modułu. Im wyższa łączność modułu, tym lepszy wynik projektowania. Rodzaje łączności (współczynnik łączności podano w nawiasach):

• funkcjonalny (silna łączność) - 10;
• sekwencyjny - 9;
• komunikatywny - 7;
• proceduralny - 5;
• tymczasowy - 3;
• logiczne - 1;
• przypadkowo (słabo połączone) - 0.

Moduł z łączność funkcjonalna nie można podzielić na dwie inne za pomocą połączenia tego samego typu. Jeżeli moduł zawiera podprogramy do sterowania strumieniami wejścia-wyjścia i zawiera główną część do przetwarzania tych danych, to moduł wykonuje pojedyncze zadanie funkcjonalne. Z reguły taki moduł jest realizowany jako sekwencja operacji w postaci jednego cyklu i posiada funkcjonalną łączność.

Moduł posiadający spójna łączność, można rozbić na kolejne części pełniące niezależne funkcje, ale wspólnie realizujące jedną funkcję. Jeśli ten sam moduł jest używany do oceny, a następnie do przetwarzania danych, ma spójną łączność. Moduł sekwencyjny realizowany jest jako sekwencja operacji lub sekwencja cykli.

Jeśli moduł składa się z niezależnych modułów, które mają wspólną strukturę danych, to ma spójność komunikacyjna. Ogólna struktura danych jest podstawą do zorganizowania ich w pojedynczy moduł. Jeśli moduł ma na celu uproszczenie pracy ze złożoną strukturą danych, izolację tej struktury, to ma łączność komunikacyjną. Taki moduł jest przeznaczony do wykonywania kilku różnych i niezależnie wykorzystywanych funkcji (przechowywania i wyszukiwania danych). Jeśli moduł jest zaprojektowany do izolowania wyboru algorytmów, ma funkcjonalną łączność. Taki moduł może przetwarzać dane o strukturze izolowanej, ale gdy zostanie wywołany, uważa się, że spełnia jedną funkcję. Moduły najwyższego poziomu hierarchicznej struktury programu muszą mieć spójność funkcjonalną lub sekwencyjną. W przypadku modułów usługowych (pomocniczych) preferowana jest łączność komunikacyjna. Jeśli moduły mają spójność proceduralną, czasową, logiczną lub losową, oznacza to, że nie są dobrze zaplanowane. Modyfikacja istniejącego programu często skutkuje tego typu połączeniami.

Łączność proceduralna znajduje się w module, którego struktury kontrolne są zorganizowane tak, jak pokazano na schemacie blokowym programu. Taka struktura modułowa może powstać przy podziale długiego programu na części zgodnie z przekazami sterującymi, ale bez definiowania podstaw funkcjonalnych przy wyborze punktów podziału. Jeżeli w celu zmniejszenia rozmiaru moduł zostanie podzielony na dwa niezależne moduły (jeden do przetwarzania deklaracji procedur i danych, a drugi do wykonywania struktur kontrolnych), to każdy z nich ma łączność proceduralną. Za najlepsze rozwiązanie należy uznać takie, w którym moduł źródłowy odnosi się do kilku innych modułów (zwykle trzech lub czterech), z których każdy pełni inną funkcję.

Moduł zawierający części, które są funkcjonalnie rozłączone, ale niezbędne w tym samym czasie przetwarzania, łączność tymczasowa (łączność według klasy). Zdarzają się przypadki, gdy cały zestaw funkcji wymaganych w momencie wejścia do programu jest realizowany przez niezależny moduł aktywacyjny. Zamiast używać jednego niezależnego modułu do aktywacji na początku programu i drugiego do pasywnego zakończenia programu, funkcje powinny być rozdzielone między różne moduły.

Jeżeli operatory są definiowane w module tylko na podstawie podobieństwa funkcjonalnego (jeżeli wszystkie operatory są przeznaczone do odczytu lub zapisu danych), a także do ustawiania parametrów modułu, stosowany jest algorytm przełączania. Taki moduł ma logiczna spójność, ponieważ jego części nie są z niczym powiązane, ale mają niewielkie podobieństwo do siebie, na przykład moduł składający się z różnych procedur obsługi błędów. Z drugiej strony, moduł przeznaczony do zapisywania różnych komunikatów o błędach do pliku ma spójność komunikacyjną, jeśli z jego pomocą można uzyskać wszystkie informacje wyjściowe z plików komunikatów o błędach.

Jeśli operatory modułu są połączone w dowolny sposób, na przykład, gdy trzeba określić ich lokalizację w obszarze pamięci, taki moduł ma przypadkowa łączność.

Trzy najsłabsze typy łączności zwykle wynikają ze złego projektu programu, więc należy poszukiwać łączności funkcjonalnej, sekwencyjnej, komunikacyjnej lub proceduralnej.

Moduły sprzęgające zdefiniowana jako miara względnej niezależności modułów. Niezależne moduły można modyfikować bez przerabiania innych modułów. Słaba przyczepność jest bardziej pożądana ponieważ oznacza to wysoki poziom niezależności modułu. Moduły uważa się za całkowicie niezależne, jeśli każdy z nich nie zawiera informacji o drugim. Im więcej informacji o innych modułach jest w nich wykorzystywanych, tym są one mniej niezależne i tym bardziej są ze sobą powiązane. Informacje te pochodzą z krzyżowego użycia nazw modułów, przypisania wywoływanych sekwencji, niejawnego użycia kodów wejściowych i wyjściowych oraz z danych zdefiniowanych przez struktury obszarów pamięci dzielonej. Im bardziej oczywiste jest współdziałanie dwóch połączonych ze sobą modułów, tym łatwiej jest określić niezbędną regulację jednego modułu w zależności od zmian dokonanych w pozostałych. Duża izolacja i bezpośrednia interakcja modułów prowadzi do trudności w określeniu granic zmian w jednym module, co wyeliminowałoby błędy w innych. Poniżej przedstawiono przybliżone miary adhezji modułów (w różnych źródłach szacunkowe stopnie adhezji różnią się) (tabela 10.1).

Notatka wyjaśniająca.

Trafność programu.

Nowość programu.

Cel

Zadania:

-

Program jest obliczany

Warunki programu:

Tryb aktywności

1 rok studiów - początek;

Formy zajęć:

Metody nauczania:

Technologie pedagogiczne:

Oczekiwane rezultaty.

Uczeń:

· Będzie umiał posługiwać się różnymi technikami pracy z papierem;

· Zdobycie praktycznych umiejętności pracy z narzędziami;

· Zostanie przeszkolony do pracy z różnymi materiałami i narzędziami przy wytwarzaniu zarówno najprostszych wyrobów technicznych, jak i projektowania trójwymiarowych modeli pojazdów, mebli czy budynków.

· Będzie umiał poruszać się w technice czytania elementarnych schematów i rysunków;

· Będzie dążyć do rozwijania wyobraźni i myślenia przestrzennego.

Rozwinie gust artystyczny i harmonię między formą a treścią obrazu artystycznego

· Rozwinięte zostaną umiejętności projektowe, myślenie techniczne, kreatywne podejście do pracy;

· Rozwinie cierpliwość i wytrwałość niezbędną do pracy z papierem.

Program I roku studiów