Proces tworzenia projektu
systemu informatycznego
Zagadnienia
Proces projektowania systemu
Metody tworzenia projektu
Strategie projektowania
Podejście obiektowe
Dekompozycja funkcjonalna
Cechy jakościowe projektu systemu
Projektowanie – co to jest?
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
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
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.
Proces formalizacji projektu
Koñcowa postaæ projeku Nieformalny
szkic projektu
Nieformalny projekt
Sformalizowany projekt
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
Produkty poszczególnych faz
Specyfikacja algorytmów Projekt algorytmów
Specyfkacja struktur danych
Projekt struktur danych
Specyfikacja komponentów Projekt komponentów
Specyfikacja interfejsów Projekt interfejsów
Specyfikacja systemu Abstrakcyjna specyfikacja
Architektura systemu Projekt architektury
Produkt wyjściowy
Faza
Hierarchiczna struktura projektu
System level
Sub-system level
(C) 1995 Ian Somerville
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
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
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
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
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/ClipAr ts/INFLAT~1.JPG
file:///D:/Utils/ClipArts/PRESEN
~1.JPG
Wiedza, doświadczenie
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
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ę
Przykład: kompilator, podejście funkcjonalne
Analyse Build
symbol table Scan
source
Generate code
Symbol table
Output errors Source
program Tokens Tokens Syntax
tree
Object code
Error indicator Symbols Symbols
Error messages
Source program
Token stream
Symbol table
Syntax
tree Gr ammar Err or
messages
Abstract code
Object code
Scan Add
Check
Get
Build Print
Generate
Przykład: kompilator, podejście
obiektowe
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
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ść
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)
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ą
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
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
Bazowa
Pochodna 1
Pochodna 2
Spójność
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
Powiązanie
Zmienne dzielone bądź wymiana informacji
sterujących prowadzi do mocnego powiązania
(ang. tight coupling)
Mocne powiązanie
Luźne powiązanie
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
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
Zrozumiałość
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
Adaptowalność
Możliwość śledzenia zmian w projekcie (ang. traceability)
P O R
D A
B
F C
D
Poziom interakcji obiektów
Poziom dekompozycji obiektów
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
Adaptowalność a dziedziczenie
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
Podsumowanie (1/2)
