Strategie projektowania

Strategia odgórna

Strategia odgórna wykorzystuje podejście modułowe do opracowania projektu systemu. Nazywa się tak, ponieważ zaczyna się od modułu najwyższego lub najwyższego poziomu i przesuwa się w kierunku modułów najniższego poziomu.

W tej technice identyfikowany jest moduł najwyższego poziomu lub moduł główny służący do tworzenia oprogramowania. Główny moduł jest podzielony na kilka mniejszych i prostszych podmodułów lub segmentów w zależności od zadania wykonywanego przez każdy moduł. Następnie każdy podmoduł jest dalej dzielony na kilka podmodułów następnego niższego poziomu. Ten proces dzielenia każdego modułu na kilka podmodułów trwa do momentu, gdy moduły najniższego poziomu, których nie można dalej dzielić, nie zostaną zidentyfikowane.

Strategia oddolna

Strategia oddolna opiera się na podejściu modułowym do opracowania projektu systemu. Nazywa się tak, ponieważ zaczyna się od modułów najniższego poziomu lub najbardziej podstawowych i przesuwa się w kierunku modułów najwyższego poziomu.

W tej technice

• Identyfikowane są moduły na najbardziej podstawowym lub najniższym poziomie.

• Moduły te są następnie grupowane razem w oparciu o funkcję wykonywaną przez każdy moduł, tworząc kolejne moduły wyższego poziomu.

• Następnie moduły te są dalej łączone, tworząc kolejne moduły wyższego poziomu.

• Ten proces grupowania kilku prostszych modułów w celu utworzenia modułów wyższego poziomu trwa do momentu osiągnięcia głównego modułu procesu rozwoju systemu.

Strukturalny projekt

Projektowanie strukturalne to metodologia oparta na przepływie danych, która pomaga w identyfikacji danych wejściowych i wyjściowych rozwijanego systemu. Głównym celem projektowania strukturalnego jest minimalizacja złożoności i zwiększenie modułowości programu. Konstrukcja strukturalna pomaga również w opisaniu funkcjonalnych aspektów systemu.

W projektowaniu strukturalnym specyfikacje systemu służą jako podstawa do graficznego przedstawienia przepływu danych i sekwencji procesów związanych z tworzeniem oprogramowania za pomocą DFD. Po opracowaniu DFD dla systemu oprogramowania, następnym krokiem jest opracowanie schematu struktury.

Modularyzacja

Projekt strukturalny dzieli program na małe i niezależne moduły. Są one zorganizowane z góry na dół, a szczegóły są pokazane na dole.

W związku z tym w projektowaniu strukturalnym stosuje się podejście zwane modularyzacją lub dekompozycją, aby zminimalizować złożoność i rozwiązać problem przez podzielenie go na mniejsze segmenty.

Advantages

• Krytyczne interfejsy są najpierw testowane.
• Zapewnia abstrakcję.
• Umożliwia jednoczesną pracę wielu programistów.
• Umożliwia ponowne wykorzystanie kodu.
• Zapewnia kontrolę i poprawia morale.
• Ułatwia identyfikację konstrukcji.

Wykresy strukturalne

Wykresy strukturalne są zalecanym narzędziem do projektowania modułowych systemów odgórnych, które definiują różne moduły rozwoju systemu i relacje między każdym modułem. Pokazuje moduł systemu i ich relacje między nimi.

Składa się ze schematu składającego się z prostokątnych pól, które reprezentują moduły, łączące strzałki lub linie.

• Control Module - Jest to moduł wyższego poziomu, który kieruje modułami niższego poziomu, tzw subordinate modules.

• Library Module - Jest to moduł wielokrotnego użytku i można go wywołać z więcej niż jednego punktu na wykresie.

Mamy dwa różne podejścia do projektowania wykresu strukturalnego -

• Transform-Centered Structured Charts - Są używane, gdy wszystkie transakcje podążają tą samą ścieżką.

• Transaction–Centered Structured Charts - Są używane, gdy wszystkie transakcje nie podążają tą samą ścieżką.

Cele stosowania schematów blokowych struktury

• Aby zachęcić do projektowania z góry na dół.

• Aby wspierać koncepcję modułów i zidentyfikować odpowiednie moduły.

• Aby pokazać rozmiar i złożoność systemu.

• Określenie liczby łatwych do zidentyfikowania funkcji i modułów w ramach każdej funkcji.

• Wskazanie, czy każda możliwa do zidentyfikowania funkcja jest bytem zarządzalnym, czy też powinna zostać podzielona na mniejsze komponenty.

Czynniki wpływające na złożoność systemu

Aby stworzyć dobrą jakość oprogramowania systemowego, konieczne jest opracowanie dobrego projektu. Dlatego podczas opracowywania projektu systemu główny nacisk kładziony jest na jakość projektu oprogramowania. Projekt oprogramowania dobrej jakości to taki, który minimalizuje złożoność i koszty wytwarzania oprogramowania.

Dwie ważne koncepcje związane z rozwojem systemu, które pomagają określić złożoność systemu, to coupling i cohesion.

Sprzęganie

Sprzężenie jest miarą niezależności komponentów. Określa stopień zależności każdego modułu rozwoju systemu od drugiego. W praktyce oznacza to, że im silniejsze sprzężenie między modułami w systemie, tym trudniejsze jest wdrożenie i utrzymanie systemu.

Każdy moduł powinien mieć prosty, przejrzysty interfejs z innymi modułami i minimalną liczbę elementów danych należy współdzielić między modułami.

Wysokie sprzęgło

Tego typu systemy mają połączenia z jednostkami programowymi zależnymi od siebie. Zmiany w jednym podsystemie mają duży wpływ na inny podsystem.

Niskie sprzęgło

Tego typu systemy składają się z niezależnych lub prawie niezależnych komponentów. Zmiana w jednym podsystemie nie wpływa na żaden inny podsystem.

Środki sprzęgające

• Content Coupling - Kiedy jeden komponent faktycznie modyfikuje inny, to zmodyfikowany komponent jest całkowicie zależny od modyfikacji jednego.

• Common Coupling - Gdy ilość sprzężeń jest nieco zmniejszona poprzez zorganizowanie projektu systemu tak, aby dane były dostępne ze wspólnej składnicy danych.

• Control Coupling - Gdy jeden składnik przekazuje parametry sterujące działaniem innego składnika.

• Stamp Coupling - Gdy struktury danych są używane do przekazywania informacji z jednego komponentu do drugiego.

• Data Coupling - Gdy przekazywane są tylko dane, komponenty są łączone za pomocą tego sprzęgła.

Spójność

Spójność jest miarą bliskości relacji między jej składowymi. Definiuje stopień zależności między komponentami modułu. W praktyce oznacza to, że projektant systemów musi zapewnić, że -

• Nie dzielą niezbędnych procesów na pofragmentowane moduły.

• Nie łączą one niezwiązanych ze sobą procesów reprezentowanych jako procesy w DFD w bezsensowne moduły.

Najlepsze moduły to takie, które są spójne funkcjonalnie. Najgorsze moduły to te, które są przypadkowo spójne.

Najgorszy stopień spójności

Kohezja przypadkowa występuje w komponencie, którego części nie są ze sobą powiązane.

• Logical Cohesion - Jest to sytuacja, w której kilka logicznie powiązanych funkcji lub elementów danych jest umieszczonych w tym samym komponencie.

• Temporal Cohesion - Dzieje się tak, gdy komponent używany do inicjalizacji systemu lub ustawiania zmiennych wykonuje kilka funkcji po kolei, ale funkcje te są powiązane przez czas.

• Procedurally Cohesion - Dzieje się tak, gdy funkcje są zgrupowane razem w komponencie, aby zapewnić tę kolejność.

• Sequential Cohesion - Dzieje się tak, gdy wyjście z jednej części komponentu jest wejściem do następnej części.