Inżynieria oprogramowania
wykład 11
Zasady projektowania oprogramowania
1
Informacje podstawowe
projektowanie jedna z najważniejszych
czynności procesu powstawania
oprogramowania, niezależnie od modelu procesu
wytwórczego
projekt techniczna reprezentacja (model)
budowanego obiektu/systemu
projekt może być porównywany z wymaganiami
użytkownika oraz poddawany kontroli jakości wg
przyjętych kryteriów
2/26
Główne zagadnienia projektu
projekt danych przetworzenie informacji zawartych w
modelu danych na struktury danych, oparte na opisach
obiektów i związków między nimi
projekt architektury opis zależności między
najważniejszymi częściami programu, przygotowany na
podstawie specyfikacji wymagań, modelu systemu i
związków między modułami oraz procedurami
projekt interfejsów metody wymiany informacji między
modułami programu oraz z innymi systemami i
użytkownikami (oparte na diagramach przepływu danych)
projekt modułów i procedur szczegółowy opis działania
procedur, oparty na specyfikacji przepływu sterowania i
diagramach STD
3/26
Zasady projektowania
oprogramowania
architektura powinna być oparta na łatwych do określenia
wzorcach projektowych, zbudowana z modułów
spełniających kryteria jakości i umożliwiających
implementacjÄ™ i testowanie
projekt powinien cechować się modularnością (opis
podziału na moduły realizujące funkcje i podfunkcje)
oddzielny opis danych, architektury, modułów, interfejsów
struktury danych w projekcie powinny odpowiadać
strukturom obiektów systemu
najlepiej do tworzenia projektów wykorzystywać
sprawdzone metody
projekt powinien być oparty na ustaleniach sporządzonych
na etapie analizy wymagań
4/26
Cechy dobrego projektu
jednorodność i spójność (dobrze opisane
związki między modułami i interfejsami)
struktura projektu powinna ułatwiać
wprowadzanie zmian
projekt powinien uwzględniać możliwość
wystÄ…pienia nieprzewidzianych sytuacji
należy regularnie dokonywać oceny jakości
projektu i poddawać przeglądom (w celu
uniknięcia błędów, zgodność z założeniami)
5/26
Pojęcia związane z projektowaniem
abstrakcja
uściślanie
modularność
architektura oprogramowania
hierarchia sterowania
dzielenie na części
struktury danych
procedury
ukrywanie informacji
6/26
Abstrakcja
definicja
Ä„ð uproszczenie rozpatrywanego problemu, polegajÄ…ce na ograniczeniu
zakresu cech manipulowanych obiektów wyłącznie do cech kluczowych
dla algorytmu, a jednocześnie niezależnych od implementacji (wg
pl.wikipedia.org)
Ä„ð pozwala rozważać problemy na wybranym poziomie szczegółowoÅ›ci, bez
wnikania w nieistotne szczegóły (A.Wasserman: Principles of systematic
data design and implementation, Software design techniques, IEEE
Computer SocietyPress, 1983)
rodzaje
Ä„ð abstrakcja proceduralna nazwany ciÄ…g zadaÅ„, pozwalajÄ…cy wykonać
pewne zadanie
Ä„ð abstrakcja danych nazwany zestaw informacji opisujÄ…cych obiekt
danych, języki programowania udostępniają możliwość definiowania
abstrakcyjnych typów danych (szablony)
Ä„ð abstrakcja przepÅ‚ywu sterowania opis sterowania bez szczegółów
7/26
Uściślanie
jest procesem wyjaśniania działania programu
jest metodą projektowania typu  od ogółu do
szczegółu
polega na stopniowym zmniejszaniu poziomu
abstrakcji poprzez uściślanie i dekompozycję aż
do instrukcji w języku programowania
(najniższy poziom) *
uściślanie i abstrakcja uzupełniają się
wzajemnie
* N. Wirth: Program development by stepwise refinement, CACM, 1971
8/26
Modularność
podział programu na moduły  oddzielne składniki realizujące pewne
zadania, ale tworzące razem spójną całość
podejście człowieka do rozwiązywania problemów
wykorzystuje się tu metodę  dziel i zwyciężaj  skomplikowany
problem łatwiej rozwiązać dzieląc go na mniejsze (przykład:
rekurencja  sortowanie przez scalanie oraz szybkie, wyszukiwanie
połówkowe), typowe podejście człowieka: złożony problem
składający się z połączonych podproblemów wydaje się bardziej
trudny do rozwiązania niż podproblemy oddzielnie
dzielenie programu na moduły ma sens ale tylko w pewnym zakresie
9/26
Wpływ modularności na koszty
tworzenia oprogramowania
koszt całkowity
koszt integracji
zakres minimalnych
kosztów
koszt modułu
liczba modułów
10/26
pracochłonność lub koszt
Wpływ modularności na koszty
tworzenia oprogramowania - analiza
koszt tworzenia oprogramowania związany z podziałem
na moduły składa się z 2 głównych składników
Ä„ð koszt wytworzenia modułów
Ä„ð koszt integracji modułów
koszt wytworzenia modułów zmniejsza się przy
wzroście liczby modułów, głównie dzięki zmniejszaniu
wielkości modułów
koszt integracji rośnie przy wzroście liczby modułów,
zwiększa się pracochłonności integracji
koszt całkowity posiada pewien optymalny zakres ze
względu na liczbę modułów
należy unikać zbyt małej oraz zbyt dużej liczby
modułów
11/26
Architektura oprogramowania
ogólna struktura oprogramowania i sposób powiązania
części w integralny system *
projekt architektury oprogramowania powinien zawierać: *
Ä„ð cechy strukturalne skÅ‚adniki systemu (moduÅ‚y, obiekty,
zapytania), sposoby ich połączenia i wymiany informacji
Ä„ð cechy pozafunkcjonalne opis wpÅ‚ywu struktury na speÅ‚nienie
wymagań związanych z efektywnością, niezawodnością,
bezpieczeństwem, łatwością ewentualnej modyfikacji, itp.
Ä„ð rodziny podobnych systemów wykorzystanie sprawdzonych
wzorców stosowanych do projektowania podobnych systemów,
uwzględnienie ponownego wykorzystania składników architektury
* M. Show, D. Garlan: Formulations and formalisms in software architecture, Lecture
Notes in Computer Science, Springer-Verlag, 1995
12/26
Modele opisu architektury
oprogramowania
modele strukturalne opis programu jako zestawu
pewnych składników
modele wzorców opis systemów na wyższym
poziomie abstrakcji jako struktury składającej się z
wzorców projektowych występujących w podobnych
systemach
modele dynamiczne opis zmian w strukturze lub
konfiguracji systemu w zależności od zdarzeń
zewnętrznych
modele procesów projektowanie procesów i
procedur postępowania
modele funkcji opis hierarchii funkcji realizowanych
przez system
modele mogą być tworzone za pomocą języków opisu architektury (ADL)
13/26
Hierarchia sterowania
nazywana strukturÄ… programu
stanowi opis połączenia modułów programu z którego
wynika hierarchiczna struktura przepływu sterowania
nie uwzględnia: kolejności wykonywanych zadań,
podejmowanych decyzji, operacji wykonywanych
wielokrotnie
sposoby przedstawiania:
Ä„ð diagramy drzewiaste
Ä„ð notacja Warniera-Orra
Ä„ð diagramy Jacksona
14/26
Diagram drzewiasty hierarchii
przepływu sterowania - przykład
rozgałęzienie wyjściowe 
M
liczba wywoływanych
modułów
a b c
moduł c jest
nadrzędny dla
modułów k i l
d
e j
k l
h
f g
m n
o
rozgałęzienie
i
p
wejściowe-liczba
modułów
wywołujących
dany moduł
szerokość (zasięg sterowania)
15/26
głębokość  liczba
poziomów sterowania
Poziomy i pionowy podział architektury
hierarchicznej na części
poziomy podział na funkcje wykonujące różne zadania
( np.: wczytywanie danych wejściowych, przetwarzanie
danych, zwracanie, danych wyjściowych), ułatwia
testowanie, pielęgnację, zmniejsza negatywne skutki
błędów, ułatwia rozszerzanie programu
pionowy (faktoryzacja) podział na moduły na
sterujÄ…ce (rzadko przetwarzajÄ… dane) i  robocze
(przyjmują dane, przetwarzają i zwracają), pozwala unikać
zbyt wielu skutków ubocznych zmian (zmiany w modułach
podrzędnych powodują małą ilość skutków ubocznych,
zmiany w modułach umiejscowionych wysoko mogą
powodować skutki uboczne w modułach niżej w hierarchii)
16/26
Podział poziomy - przykład
M
a b c
d
e j
k l
h
f g
m n n
funkcja 1 funkcja 2 funkcja 3
17/26
Podział pionowy - przykład
M
moduły
sterujÄ…ce
a b c
d
e j
k l
moduły
h
f g
m n n
 robocze
18/26
Struktury danych
opis związków logicznych między danymi
określają organizację danych, metody dostępu i
sposoby przetwarzania danych
podstawowe struktury danych
Ä„ð skalary pojedyncze elementy, dostÄ™p poprzez podanie
adresu w pamięci, rozmiary zależne od środowiska
programistycznego (np. bool = 1B, int=4B itd.)
Ä„ð wektory ciÄ…gi skalarów
Ä„ð tablice wektory wielowymiarowe
Ä„ð listy elementami sÄ… skalary, wektory lub tablice, w pamiÄ™ci
niekoniecznie obok siebie, każdy element zawiera właściwe
dane i informacje o położeniu elementu następnego
Ä„ð drzewa wielokrotnie powiÄ…zane listy (struktura
hierarchiczna)
19/26
Procedury
opis sposobu przetwarzania informacji
zawiera: kolejność wykonywania zadań,
miejsca podejmowania decyzji, powtórzenia
wielokrotne czynności, czasem również
używane struktury danych
struktura procedur zwiÄ…zana jest z architekturÄ…
programu
projekt procedur powinien zawierać odniesienia
do procedur z modułów podrzędnych
20/26
Ukrywanie informacji
moduły powinny być tak projektowane aby
procedury i dane tego danego moduły były
widoczne dla innych modułów tylko jeżeli jest to
konieczne
uwzględniając powyższe zapobiega się
powstawanie skomplikowanej sieci
niepotrzebnych zależności
korzyści z ukrywania informacji mogą pojawić się
przy wprowadzaniu zmian skutki
ewentualnych błędów nie wpływają na działanie
całego systemu
21/26
Projektowanie systemów
modularnych
niezależność funkcjonalna małe moduły, nie
wymieniające zbyt dużej ilości informacji z innymi
modułami, odpowiedzialne za realizację jednej określonej
funkcji systemu, zalety: łatwy podział pracy zespołów,
łatwiejsze testowanie i pielęgnacja (ograniczone skutki
zmian), możliwość wielokrotnego użycia, niezależność
można mierzyć badając spoistość i sprzężenia
spoistość moduł spoisty odpowiada za realizację
jednego konkretnego zadania i nie wymienia zbyt dużo
informacji z innymi modułami, nie przekłada się jednak
bezpośrednio na jakość projektu
sprzężenia związki między modułami oprogramowania,
należy unikać zbyt wielu sprzężeń sprzyjających tzw.
przenoszeniu się błędu między modułami
22/26
Rodzaje sprzężeń
brak moduły podrzędne do różnych modułów nadrzędnych
informacyjne (słabe) wywołanie modułu podrzędnego wraz
przekazanie pewnej listy argumentów
znacznikowe (słabe) przekazywane dane mają pewną strukturę
przekazywanÄ… wraz z danymi
sterujące (silniejsze) przekazywane dane służą wyborowi dalszego
działania, występują bardzo często
zewnętrzne (silne) powiązanie z urządzeniami zewnętrznymi,
protokołami komunikacyjnymi, itp., powinno być ich jak najmniej
globalne (silne) moduły korzystają ze wspólnych danych,
przechowywanych np. w pamięci lub plikach dyskowych trudne
diagnozowanie błędów
zawartości (najsilniejsze) moduł korzysta z danych
przechowywanych w innym module lub wywołuje jego wewnętrzne
procedury z pominięciem interfejsów należy ich unikać
23/26
Heurystyka projektowania
modularnego - zasady
zmiana ustalonych struktur powinna powodować zwiększenie
spoistości i unikanie sprzężeń (podział i łączenie modułów w celu
poprawy niezależności funkcjonalnej)
unikanie szerokich rozgałęzień wyjściowych (płaska struktura),
wykorzystywanie rozgałęzień wejściowych na niższych poziomach
hierarchii
zasięg skutków działania modułu (moduły których działanie jest
uzależnione od działań danego modułu) nie powinien przekraczać
zasięgu sterowania (moduły pośrednio lub bezpośrednio podrzędne)
modułu
ograniczanie złożoności i nadmiarowości interfejsów modułów
(przyczyna błędów) i zapewnianie ich spójności
zwiększanie przewidywalności działania modułów (takie same dane
wejściowe powodują otrzymanie zawsze takich samych danych
wyjściowych
unikanie sprzężeń zawartości łatwiejsza kontrola i pielęgnacja
24/26
Dokumentacja projektowa
zakres prac projektowych opracowany na podstawie
specyfikacji systemu i specyfikacji wymagań
projekt danych struktura danych i plików zewnętrznych
projekt architektury opracowany na podstawie modelu
analitycznego, zawiera diagramy hierarchii modułów
opis interfejsów
opis modułów, procedur i podprocedur
opis składników programu w połączeniu z wymaganiami
(sprawdzenie projektu pod kątem stawianych wymagań i
określenie kluczowych składników dla wymagań)
wstępna wersja zestawu testów
sposób wdrożenia systemu u klienta
dodatkowe dane opisy algorytmów, zastępcze procedury
działania, wstępna wersja podręcznika użytkownika i inne
istotne
25/26
Dziękuję za uwagę
z
ródło:  Praktyczne podejście do inżynierii oprogramowania , R.S. Pressman
26