Proces tworzenia projektu systemu...
Transcript of Proces tworzenia projektu systemu...
Inżynieria Oprogramowania WSZiBSemestr IV
Zagadnienia Proces projektowania systemu Metody tworzenia projektu Strategie projektowania
Podejście obiektowe Dekompozycja funkcjonalna
Cechy jakościowe projektu systemu
Inżynieria Oprogramowania WSZiBSemestr IV
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
Inżynieria Oprogramowania WSZiBSemestr IV
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 ?
Inżynieria Oprogramowania WSZiBSemestr IV
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.
Inżynieria Oprogramowania WSZiBSemestr IV
Proces formalizacji projektu
Koñcowa postaæprojeku
Nieformalnyszkic projektu
Nieformalnyprojekt
Sformalizowanyprojekt
Inżynieria Oprogramowania WSZiBSemestr IV
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
Inżynieria Oprogramowania WSZiBSemestr IV
Produkty poszczególnych faz
Specyfikacja algorytmówProjekt algorytmów
Specyfkacja struktur danych
Projekt struktur danych
Specyfikacja komponentów
Projekt komponentów
Specyfikacja interfejsówProjekt interfejsów
Specyfikacja systemuAbstrakcyjna specyfikacja
Architektura systemuProjekt architektury
Produkt wyjściowyFaza
Inżynieria Oprogramowania WSZiBSemestr IV
Hierarchiczna struktura projektu
System level
Sub-systemlevel
(C) 1995 Ian Somerville
Inżynieria Oprogramowania WSZiBSemestr IV
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
Inżynieria Oprogramowania WSZiBSemestr IV
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
Inżynieria Oprogramowania WSZiBSemestr IV
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
Inżynieria Oprogramowania WSZiBSemestr IV
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
Inżynieria Oprogramowania WSZiBSemestr IV
Niedoskonałości metodyk 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/INFLAT~1.JPG
file:///D:/Utils/ClipArts/PRESEN~1.JPG
Metodyka Rozwiązanie/projekt
Wiedza, doświadczenie
Inżynieria Oprogramowania WSZiBSemestr IV
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
Inżynieria Oprogramowania WSZiBSemestr IV
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
Inżynieria Oprogramowania WSZiBSemestr IV
Przykład: kompilator, podejście funkcjonalne
AnalyseBuild
symboltable
Scansource
Generatecode
Symboltable
Outputerrors
Sourceprogram
Tokens Tokens Syntaxtree
Objectcode
ErrorindicatorSymbols Symbols
Errormessages
Inżynieria Oprogramowania WSZiBSemestr IV
Sourceprogram
Tokenstream
Symboltable
Syntaxtree
Grammar Errormessages
Abstractcode
Objectcode
Scan Add
Check Get
Build Print
Generate
Generate
Przykład: kompilator, podejście obiektowe
Inżynieria Oprogramowania WSZiBSemestr IV
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
Inżynieria Oprogramowania WSZiBSemestr IV
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
Inżynieria Oprogramowania WSZiBSemestr IV
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)
Inżynieria Oprogramowania WSZiBSemestr IV
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ą
Inżynieria Oprogramowania WSZiBSemestr IV
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
Inżynieria Oprogramowania WSZiBSemestr IV
Poziomy spójności (c.d.) 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
Bazowa
Pochodna 1
Pochodna 2
Spój
ność
Inżynieria Oprogramowania WSZiBSemestr IV
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
28
Powiązanie
Zmienne dzielone bądź wymiana informacji sterujących prowadzi do mocnego powiązania (ang. tight coupling)
Inżynieria Oprogramowania WSZiBSemestr IV
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!
Powiązanie a dziedziczenie
Inżynieria Oprogramowania WSZiBSemestr IV
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
Zrozumiałość
Inżynieria Oprogramowania WSZiBSemestr IV
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
Adaptowalność
Inżynieria Oprogramowania WSZiBSemestr IV
Możliwość śledzenia zmian w projekcie (ang. traceability)
P O R
D
A
BF
C
D
Poziom interakcji obiektów
Poziom dekompozycji obiektów
Inżynieria Oprogramowania WSZiBSemestr IV
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
Adaptowalność a dziedziczenie
Inżynieria Oprogramowania WSZiBSemestr IV
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
Podsumowanie (1/2)
Inżynieria Oprogramowania WSZiBSemestr IV
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
Podsumowanie (2/2)