Software Design

Proces tworzenia projektu
systemu informatycznego
Semestr IV
Inżynieria Oprogramowania
WSZiB
Zagadnienia



Proces projektowania systemu
Metody tworzenia projektu
Strategie projektowania



Semestr IV
Podejście obiektowe
Dekompozycja funkcjonalna
Cechy jakościowe projektu systemu
Inżynieria Oprogramowania
WSZiB
Projektowanie – co to jest?
Semestr IV
Inżynieria Oprogramowania
WSZiB
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...




Semestr IV
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
WSZiB
Etapy tworzenia projektu

Zrozumienie problemu


Identyfikacja możliwych rozwiązań


Opis komponentów projektu za pomocą jednej bądź wielu notacji:
graficznej, formalnej, ...
Proces ten powtarza się dla każdego zidentyfikowanego
komponentu


Semestr IV
Ewaluacja zidentyfikowanych rozwiązań oraz wybór
najodpowiedniejszego; to ostatnie jest wynikiem doświadczenia
projektanta oraz dostępnych zasobów
Opis rozwiązania


Konieczne jest rozpatrzenie wielu różnych punktów widzenia aby
zidentyfikować wymagania projektu
Aż będzie możliwe stworzenie szczegółowej specyfikacji każdego
komponentu
Kryterium stopu  ?
Inżynieria Oprogramowania
WSZiB
Proces projektowania



Semestr IV
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
WSZiB
Proces formalizacji projektu
Nieformalny
szkic projektu
Nieformalny
projekt
Sformalizowany
projekt
Koñcowa postaæ
projeku
Semestr IV
Inżynieria Oprogramowania
WSZiB
Fazy projektowania






Semestr IV
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
WSZiB
Produkty poszczególnych faz
Semestr IV
Faza
Produkt wyjściowy
Projekt architektury
Architektura systemu
Abstrakcyjna specyfikacja
Specyfikacja systemu
Projekt interfejsów
Specyfikacja interfejsów
Projekt komponentów
Specyfikacja
komponentów
Projekt struktur danych
Specyfkacja struktur
danych
Projekt algorytmów
Specyfikacja algorytmów
Inżynieria Oprogramowania
WSZiB
Hierarchiczna struktura projektu
System level
Sub-system
level
(C) 1995 Ian Somerville
Semestr IV
Inżynieria Oprogramowania
WSZiB
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


Semestr IV
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
WSZiB
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


Podziału na specyficzne metodyki/notacje (OMT, Booch,
Coad-Yourdon) określającego

Semestr IV
podstawową zawartość dokumentów projektowych i wymagań
poszczególne, wykorzystywane formy reprezentacji
Inżynieria Oprogramowania
WSZiB
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

Semestr IV
Często oferują one możliwość generacji kodu na podstawie
projektu
Inżynieria Oprogramowania
WSZiB
Metodyki komponentowe




Semestr IV
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
WSZiB
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/PRESEN
~1.JPG
file:///D:/Utils/ClipAr
ts/INFLAT~1.JPG
Wiedza, doświadczenie
Metodyka
Semestr IV
Rozwiązanie/projekt
Inżynieria Oprogramowania
WSZiB
Sposoby opisu projektu




Semestr IV
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
WSZiB
Strategie projektowania

Podejście funkcjonalne


Podejście obiektowe

Semestr IV
Projekt systemu powstaje w oparciu o
funkcjonalny punkt widzenia. Stan systemu jest
scentralizowany i współdzielony przez wszystkie
funkcje operujące w danym stanie
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
WSZiB
Przykład: kompilator, podejście
funkcjonalne
Source
program
Tokens
Scan
source
Syntax
tree
Tokens
Build
symbol
table
Symbols
Analyse
Symbols
Object
code
Generate
code
Error
indicator
Symbol
table
Output
errors
Error
messages
Semestr IV
Inżynieria Oprogramowania
WSZiB
Przykład: kompilator, podejście
obiektowe
Scan
Source
program
Add
Token
stream
Symbol
table
Check
Syntax
tree
Get
Grammar
Build
Print
Error
messages
Generate
Object
code
Abstract
code
Generate
Semestr IV
Inżynieria Oprogramowania
WSZiB
Strategia mieszana


Semestr IV
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
WSZiB
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


Omawiane atrybuty odnoszą się do projektów
tworzonych za pomocą różnych podejść

Semestr IV
Projekt powinien dać się “łatwo modyfikować i rozszerzać”
Obiektowego jak i funkcjonalnego
Inżynieria Oprogramowania
WSZiB
Spójność




Semestr IV
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
WSZiB
Poziomy spójności

Spójność przypadkowa (słaba)


Powiązanie logiczne (słabe)


Komponenty aktywowane w tym samym czasie są
zgrupowane razem
Spójność proceduralna (słaba)

Semestr IV
Składowe wykonujące podobne funkcje (zadania) są
zgrupowane razem
Spójność czasowa (słaba)


Składowe danego komponentu zebrane razem bez żadnego
kryterium
Elementy danego komponentu tworzą pojedynczą
sekwencję sterującą
Inżynieria Oprogramowania
WSZiB
Poziomy spójności (c.d.)

Spójność komunikacyjna (średnia)


Spójność sekwencyjna (średnia)


Dane wyjściowe składowej komponentu są danymi
wejściowymi innej składowej
Spójność funkcjonalna (silna)

Semestr IV
Wszystkie składowe komponentu operują na tych samych
danych wejściowych bądź produkują te same dane
wyjściowe
Do wykonania pojedynczej funkcji potrzebna jest każda ze
składowych komponentu
Inżynieria Oprogramowania
WSZiB
Poziomy spójności (c.d.)


Bazowa

Spójność

Pochodna 1
W odniesieniu do systemów OO można zdefiniować
jeszcze jedną klasę spójności
Spójność obiektowa (silna)
W przypadku występowania dziedziczenia spójność
obiektu ulega obniżeniu


Pochodna 2

Semestr IV
Każda operacja dostarcza funkcjonalność która umożliwa
modyfikowanie bądź odczytywanie atrybutów obiektu
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
Inżynieria Oprogramowania
WSZiB
Powiązanie




Semestr 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
Zmienne dzielone bądź wymiana informacji
sterujących prowadzi do mocnego powiązania
(ang. tight coupling)
Inżynieria Oprogramowania
28
WSZiB
Mocne powiązanie
Semestr IV
Inżynieria Oprogramowania
WSZiB
Luźne powiązanie
Semestr IV
Inżynieria Oprogramowania
WSZiB
Powiązanie a dziedziczenie


Semestr 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!
Inżynieria Oprogramowania
WSZiB
Zrozumiałość

Powiązana z innymi cechami projektu






Semestr IV
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
Inżynieria Oprogramowania
32
WSZiB
Adaptowalność

Projekt jest adaptowalny jeśli:





Semestr IV
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)
Inżynieria Oprogramowania
33
WSZiB
Możliwość śledzenia zmian w
projekcie (ang. traceability)
C
F
B
D
A
Poziom interakcji obiektów
D
P
O
R
Poziom dekompozycji obiektów
Semestr IV
Inżynieria Oprogramowania
WSZiB
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.

Semestr IV
Taka hierarchia powinna być okresowo przeglądana i
restrukturyzowana
Inżynieria Oprogramowania
35
WSZiB
Podsumowanie (1/2)





Semestr 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
Inżynieria Oprogramowania
36
WSZiB
Podsumowanie (2/2)

Semestr 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ń.
Inżynieria Oprogramowania
36
WSZiB