Proces tworzenia projektu systemu informatycznegoartemis.wszib.edu.pl/~jackolo/doc/wyklad/Inzynieria_Oprogramowania... · Proces projektowania systemu ... Ogólnej klasyfikacji (strukturalna,

Inżynieria Oprogramowania WSZiBSemestr IV

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 Kryterium stopu ?


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

Nieformalnyszkic projektu

Nieformalnyprojekt

Sformalizowanyprojekt


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ó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


Hierarchiczna struktura projektu

System level

Sub-systemlevel

(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/ClipArts/INFLAT~1.JPG

file:///D:/Utils/ClipArts/PRESEN~1.JPG

Metodyka Rozwiązanie/projekt

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ę poprzez wymianę komunikatów


Przykład: kompilator, podejście funkcjonalne

AnalyseBuild

symboltable

Scansource

Generatecode

Symboltable

Outputerrors

Sourceprogram

Tokens Tokens Syntaxtree

Objectcode

ErrorindicatorSymbols Symbols

Errormessages


Sourceprogram

Tokenstream

Symboltable

Syntaxtree

Grammar Errormessages

Abstractcode

Objectcode

Scan Add

Check Get

Build Print

Generate

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ść Obiektowego jak i funkcjonalnego


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ą

sekwencję sterującą


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

wielokrotnego dziedziczenia

Bazowa

Pochodna 1

Pochodna 2

Spój

ność


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)


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

32

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 zmiany (ang. traceability)

33

Adaptowalność


Możliwość śledzenia zmian w projekcie (ang. traceability)

P O R

D

A

BF

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

35

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

36

Podsumowanie (1/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

Podsumowanie (2/2)

Proces tworzenia projektu systemu informatycznegoartemis.wszib.edu.pl/~jackolo/doc/wyklad/Inzynieria_Oprogramowania... · Proces projektowania systemu ... Ogólnej klasyfikacji (strukturalna,

Documents