Proces tworzenia projektu systemu informatycznego. Inżynieria Oprogramowania

Transkrypt

1 Proces tworzenia projektu systemu informatycznego

2 Zagadnienia Proces projektowania systemu Metody tworzenia projektu Strategie projektowania Podejście obiektowe Dekompozycja funkcjonalna Cechy jakościowe projektu systemu

3 Projektowanie co to jest?

4 Projektowanie co to jest?... Proces polegający na zastosowaniu różnorodnych technik oraz wytycznych w celu zdefiniowania systemu na takim poziomie szczegółowości aby możliwa była jego fizyczna realizacja... Jako przykład... Architekci (nie inżynierowie) budowlani odpowiadają za ogólny kształt budynku Architektura i inżynieria uzupełniają się wzajemnie Inżynier odgrywa kluczową rolę w procesie budowania domu; ale kierunek prac pochodzi od architekta Jeśli chcemy zaprojektować dom radzimy się architekta a nie inżyniera

5 Etapy tworzenia projektu Zrozumienie problemu Konieczne jest rozpatrzenie wielu różnych punktów widzenia aby zidentyfikować wymagania projektu Identyfikacja możliwych rozwiązań Ewaluacja zidentyfikowanych rozwiązań oraz wybór najodpowiedniejszego; to ostatnie jest wynikiem doświadczenia projektanta oraz dostępnych zasobów Opis rozwiązania Opis komponentów projektu za pomocą jednej bądź wielu notacji: graficznej, formalnej,... Proces ten powtarza się dla każdego zidentyfikowanego komponentu Aż będzie możliwe stworzenie szczegółowej specyfikacji każdego komponentu Kryterium stopu?

6 Proces projektowania Każdy projekt można modelować za pomocą skierowanego grafu wierzchołkami są powiązane relacjami komponenty z atrybutami System powinien posiadać opis na kilku różnych poziomach abstrakcji Zwykle projektowanie odbywa się w postaci częściowo pokrywających się faz (iteracji). Wynikiem kolejnych faz są coraz bardziej szczegółowe opisy systemu.

7 Proces formalizacji projektu Nieformalny szkic projektu Nieformalny projekt Sformalizowany projekt Koñcowa postaæ projeku

8 Fazy projektowania Projekt architektury Identyfikacja podsystemów Abstrakcyjna specyfikacja Specyfikacja podsystemów Projekt interfejsów Opis interfejsów podsystemów Projekt komponentów Podział podsystemów na komponenty Projekt struktur danych Projekt struktur danych przechowujących informacje Projekt algorytmów Dla poszczególnych funkcji systemu

9 Produkty poszczególnych faz Faza Projekt architektury Abstrakcyjna specyfikacja Projekt interfejsów Projekt komponentów Projekt struktur danych Projekt algorytmów Produkt wyjściowy Architektura systemu Specyfikacja systemu Specyfikacja interfejsów Specyfikacja komponentów Specyfkacja struktur danych Specyfikacja algorytmów

10 Hierarchiczna struktura projektu System level Sub-system level (C) 1995 Ian Somerville

11 Projektowanie metodą top-down W założeniu projektowanie rozpoczyna się od najwyższych komponentów w hierarchii i podąża w dół kolejnymi poziomami W praktyce duże systemy nigdy nie są projektowane ściśle za pomocą metody top-down Projektanci wykorzystują wielokrotnie doświadczenie jak i komponenty w trakcie procesu projektowania W podejściu obiektowym często gotowe obiekty stanowią szkielet w oparciu o który powstaje projekt systemu. Nie występuje tu pojęcie pojedynczego wierzchołka od którego zaczyna się projekt

12 Metodyki projektowania Metodyka projektowa To zestaw technik, notacji, strategii oraz modeli wspierających proces modelowania (odwzorowania świata rzeczywistego na model software owy) Określa systematyczny sposób wywodzenia projektu z danych wymagań Metodyki można dzielić używając Ogólnej klasyfikacji (strukturalna, OO, oparta o diagram stanów) określającej podstawową zawartość dokumentów projektowych i wymagań Podziału na specyficzne metodyki/notacje (OMT, Booch, Coad-Yourdon) określającego poszczególne, wykorzystywane formy reprezentacji

13 Metodyki projektowania Metodyki strukturalne to zestawy notacji służące do opisu projektu jak i wytyczne dot. tworzenia projektu Przykład: Structured Design (Yourdon) Są stosowane z powodzeniem ponieważ opierają się o standardową notację i wymuszają zgodność projektu z określonym standardem Wspierane przez narzędzia CASE Często oferują one możliwość generacji kodu na podstawie projektu

14 Metodyki komponentowe Różne metodyki/notacje obrazują dany system z różnych perspektyw Diagramy przepływu danych (data flow diagrams) demonstrują operacje na danych Diagramy entity-relation opisują logiczne struktury danych Diagramy strukturalne opisują komponenty systemu oraz ich wzajemne interakcje

15 Niedoskonałości metodyk file:///d:/utils/clipar ts/inflat~1.jpg Są to raczej ogólne wytyczne, nie ścisłe metody postępowania. Różni projektanci stworzą zupełnie różne projekty w oparciu o tą samą specyfikację i metodykę W początkowej (twórczej) fazie projektu nie są zbyt pomocne. Oferują za to pomoc w strukturyzowaniu i dokumentowaniu projektu file:///d:/utils/cliparts/presen ~1.JPG Wiedza, doświadczenie Metodyka Rozwiązanie/projekt

16 Sposoby opisu projektu Notacje graficzne. Wykorzystywane do prezentacji zależności pomiędzy komponentami Języki opisu programu. (ang. Program Description Languages) Rodzaj pseudokodu na tyle elastycznego aby móc wyrażać w nim abstrakcyjne idee Nieformalny tekst. Opis w języku naturalnym Przy projektowaniu dużych i złożonych systemów mogą być wykorzystywane wszystkie te notacje

17 Strategie projektowania Podejście funkcjonalne Projekt systemu powstaje w oparciu o funkcjonalny punkt widzenia. Stan systemu jest scentralizowany i współdzielony przez wszystkie funkcje operujące w danym stanie Podejście obiektowe System jest prezentowany jako zbiór oddziaływujących ze sobą obiektów. Stan systemu jest zdecentralizowany, każdy obiekt zarządza swoim własnym stanem. Obiekty są to instancje odpowiednich klas, komunikacja odbywa się poprzez wymianę komunikatów

18 Przykład: kompilator, podejście funkcjonalne Source program Tokens Tokens Syntax tree Object code Scan source Build symbol table Analyse Generate code Symbols Symbols Error indicator Symbol table Output errors Error messages

19 Przykład: kompilator, podejście obiektowe Source program Scan Token stream Add Symbol table Check Get Syntax tree Build Grammar Print Error messages Generate Abstract code Object code Generate

20 Strategia mieszana Pomimo pojawiających się co jakiś czas sugestii że dane podejście projektowe jest najlepsze w praktyce oba podejścia: funkcjonalne i obiektowe uzupełniają się wzajemnie Doświadczeni praktycy wybierają najodpowiedniejsze podejście dla każdego z osobna projektowanego podsystemu

21 Jakość projektu Jakość projektu systemu jest pojęciem względnym - jest wypadkową specyficznych priorytetów dla danej organizacji Pojęcie dobrego jakościowo projektu może oznaczać projekt systemu najtańszego, najwydajniejszego, najbardziej niezawodnego, itp. Omawiane dalej atrybuty jakości dotyczą pielęgnowalności projektu Projekt powinien dać się łatwo modyfikować i rozszerzać Omawiane atrybuty odnoszą się do projektów tworzonych za pomocą różnych podejść Obiektowego jak i funkcjonalnego

22 Spójność Mówi o tym w jakim stopniu dany komponent tworzy logiczną całość Dany komponent powinien implementować pojedynczą logiczną strukturę bądź funkcję Spójność jest pożądaną cechą projektu gdyż w przypadku konieczności zmiany danej funkcjonalności zmiana ta będzie umiejscowiona w jednym miejscu Identyfikuje się 7 różnych poziomów spójności (Constantine & Yourdon, 1979)

23 Poziomy spójności Spójność przypadkowa (słaba) Składowe danego komponentu zebrane razem bez żadnego kryterium Powiązanie logiczne (słabe) Składowe wykonujące podobne funkcje (zadania) są zgrupowane razem Spójność czasowa (słaba) Komponenty aktywowane w tym samym czasie są zgrupowane razem Spójność proceduralna (słaba) Elementy danego komponentu tworzą pojedynczą sekwencję sterującą

24 Poziomy spójności (c.d.) Spójność komunikacyjna (średnia) Wszystkie składowe komponentu operują na tych samych danych wejściowych bądź produkują te same dane wyjściowe Spójność sekwencyjna (średnia) Dane wyjściowe składowej komponentu są danymi wejściowymi innej składowej Spójność funkcjonalna (silna) Do wykonania pojedynczej funkcji potrzebna jest każda ze składowych komponentu

25 Poziomy spójności (c.d.) Spójność Bazowa Pochodna 1 Pochodna 2 W odniesieniu do systemów OO można zdefiniować jeszcze jedną klasę spójności Spójność obiektowa (silna) Każda operacja dostarcza funkcjonalność która umożliwa modyfikowanie bądź odczytywanie atrybutów obiektu W przypadku występowania dziedziczenia spójność obiektu ulega obniżeniu Nie można postrzegać obiektu klasy jako odrębnej jednostki izolowanej od otoczenia Do pełnego zrozumienia funkcjonalności danej klasy konieczne jest zapoznanie się z wszystkimi nadklasami Szczególnie złożone w przypadku występowania wielokrotnego dziedziczenia

26 Powiązanie Miara tego jak mocno połączone są ze sobą poszczególne komponenty systemu Luźne powiązanie (ang. loose coupling) oznacza że zmiany wprowadzone w danym komponencie nie mają wpływu na pozostałe Luźne powiązanie można osiągnąć poprzez decentralizację stanu systemu (jak w podejściu OO) oraz zaprojektowanie komunikacji pomiędzy komponentami w postaci przekazywania komunikatów bądź parametrów Zmienne dzielone bądź wymiana informacji sterujących prowadzi do mocnego powiązania (ang. tight coupling) 28

27 Mocne powiązanie

28 Luźne powiązanie

29 Powiązanie a dziedziczenie Systemy OO są luźno powiązane ze swojej natury ponieważ nie występują stany dzielone oraz obiekty komunikują się między sobą używając mechanizmu przekazywania komunikatów Z drugiej strony klasa danego obiektu jest ściśle powiązana ze swoją nadklasą. Zmiany wprowadzone w danej nadklasie propagują się do wszyskich jej podklas. Tego typu zmiany powinny być szczególnie uważnie weryfikowane!

30 Zrozumiałość Powiązana z innymi cechami projektu Spójność. Czy komponent może być zrozumiany w izolacji? Nazewnictwo. Czy używane nazwy są znaczące? Dokumentacja. Czy projekt jest dobrze udokumentowany? Złożoność. Czy wykorzystywane są złożone algorytmy? Bardziej nieformalnie przez złożoność rozumie się wiele powiązań pomiędzy różnymi częściami projektu. Przez to projekt staje się trudny do zrozumienia Większość metryk powiązanych z projektami to miary złożoności 32

31 Adaptowalność Projekt jest adaptowalny jeśli: Jego komponenty są luźno ze sobą powiązane Jest dobrze udokumentowany oraz dokumentacja jest aktualna (!) Występuje czytelna relacja pomiędzy poziomami projektu o różnym stopniu szczegółowości (czytelność projektu) Każdy z komponentów jest izolowanym obiektem (spójność) Przy adaptacji projektu musi istnieć możliwość śledzenia powiązań pomiędzy poszczególnymi komponentami projektu tak aby można było przeanalizować konsekwencje wprowadzenia danej zmiany (ang. traceability) 33

32 Możliwość śledzenia zmian w projekcie (ang. traceability) A B C D F Poziom interakcji obiektów D P O R Poziom dekompozycji obiektów

33 Adaptowalność a dziedziczenie Dziedziczenie znacząco ulepsza adaptowalność projektu. Poszczególne komponenty mogą być adaptowane poprzez utworzenie podklasy oraz jej modyfikację W miarę rozrastania się hierarchii klas staje się ona coraz bardziej złożona, w krańcowych przypadkach nieczytelna oraz duplikująca poszczególne funkcjonalności. Taka hierarchia powinna być okresowo przeglądana i restrukturyzowana 35

34 Podsumowanie (1/2) Projektowanie jest procesem twórczym Główne aktywności projektowe to: projekt architektury, specyfikacja systemu, projekt komponentów, projekt struktur danych oraz projekt algorytmów Stosując dekompozycję funkcjonalną rozpatruje się system jako zbiór jednostek funkcjonalnych Stosując dekompozycję obiektową rozpatruje się system jako zbiór obiektów Projektowanie funkcjonalne oraz obiektowe są nawzajem uzupełniającymi się technikami. Na różnych poziomach abstrakcji projektu zwykle wykorzystuje się różne techniki 36

35 Podsumowanie (2/2) Spójność mówi nam jak silnie są z sobą powiązane składowe danego komponentu. Powiązanie informuje o tym jak silnie są ze sobą połączone różne komponenty. Przy tworzeniu projektu należy dążyć do silnej spójności i powstania luźnych powiązań. 36