Wykład 10Przepływ prac: Analiza i projektowanie Rational Unified Process Studia Podyplomowe IT w Biznesie

(1)

Studia Podyplomowe IT w Biznesie

Rational Unified Process Wykład 10

Przepływ prac: Analiza i projektowanie

Wykładowca:

dr inż. Ewa Stemposz ewag@ipipan.waw.pl

Polsko-Japońska Wyższa Szkoła Technik Komputerowych

Warszawa

(2)

Zagadnienia Zagadnienia Zagadnienia

Analiza kontra projektowanie Pracownicy

Artefakty

Przepływ prac: Analiza i projektowanie Wsparcie narzędziowe

Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The Rational Unified Process An Introduction, Addison-Wesley, 1999.

(3)

Analiza kontra projektowanie (1)

Podstawowym celem przepływu prac Analiza i projektowanie jest zamiana wymagań w specyfikację sposobu implementowania systemu: „określenia najlepszej strategii dla jego implementacji”.

Osiąga się to poprzez:



ustanowienie stabilnej architektury - bazy dla budowy systemu łatwego do zrozumienia i rozwijania,

 przystosowanie projektu do środowiska implementacji,

 uwzględnienie własności systemu, takich jak: wydajność, skalowalność, itp.

Analiza: Zadaniem analizy jest transformacja wymagań na system w postać, która jest dobrze mapowana do obszaru zainteresowań projektantów, czyli do zbioru klas i podsystemów. Ta transformacja opierana jest w RUP o przypadki użycia i wymagania niefunkcjonalne.

Analiza skupia się na funkcjonalności systemu i ignoruje zarówno wymagania

niefunkcjonalne, jak i ograniczenia środowiska implementacji. Można powiedzieć,

że analiza prowadzi do uzyskania „prawie idealnego” obrazu systemu.

(4)

Analiza kontra projektowanie (2)

Projektowanie: Zadaniem projektowania jest przystosowanie wyników analizy do wymagań niefunkcjonalnych i ograniczeń środowiska implementacji.

Projektowanie jest uszczegółowieniem analizy. Aktywności skupione są na optymalizacji projektu systemu, w konkretnym środowisku implementacji, z jednoczesnym zapewnieniem pełnego pokrycia dla funkcjonalności.

Jak szczegółowy powinien być projekt systemu?

 Projekt powinien być „szczegółowy na tyle”, by w trakcie implementacji nie powstawały niejednoznaczności. Stopień szczegółowości jest uzależniony od doświadczenia programistów i złożoności projektu.

Uwaga: Projekty bardzo szczegółowe, implementowane poprzez bezpośrednie

transformacje konstrukcji projektu w kod, pozwalają na znaczne zmniejszenie

liczby błędów (zostaje usunięty jeden krok transformacji).

(5)

Pracownicy (1)

Architekt

Model analityczny

Model projektowy

Interfejs Dokument architektury oprogramowania

Artefakty systemów czasu rzeczywistego

Zdarzenie

Sygnał

Protokół odpowiedzialny za

(6)

Pracownicy (2)

Realizacja przypadku użycia: opis sposobu realizacji konkretnego przypadku użycia (w oparciu o istniejący model projektowy), z reguły - w terminach współpracujących obiektów.

Projektant

Realizacja przypadku użycia

Klasa Pakiet projektowy

Podsystem

odpowiedzialny za Projektant

kapsuł Systemy czasu rzeczywistego

odpowiedzialny za Projektant

bazy danych

Model danych odpowiedzialny za

Kapsuła: wzorzec projektowy reprezentujący kompletny wątek w systemie. Kapsuły komunikują się między sobą za pośrednictwem portów.

Protokół: określa zasady komunikowania się w obrębie pewnego zbioru portów: porządek portów, wymieniane komunikaty, itd.

Kapsuła

(7)

Pracownicy (3)

Architekt: Do zadań architekta należy specyfikacja każdej z perspektyw architektonicznych: dekompozycja na elementy składowe, grupowanie elementów i określenie interfejsów między najważniejszymi zgrupowaniami. W przeciwieństwie do innych rodzajów pracowników, ogląd architekta jest raczej

„szerszy niż głębszy”.

Projektant: Definiuje odpowiedzialności, atrybuty, operacje i związki jednej lub kilku klas i określa, jak te elementy będą realizowane w środowisku implementacji. Ponadto, projektant może być odpowiedzialny za jeden lub kilka pakietów projektowych czy pakietów podsystemów (czyli za wszystkie klasy zawarte w danym pakiecie).

Inni pracownicy zaangażowani w aktywności związane z przpływem prac Analiza i projektowanie: projektant bazy danych i projektant kapsuł

Projektant bazy danych: Potrzebny, gdy projektowany system zawiera bazę danych.

Projektant kapsuł: Potrzebny, gdy projektowany system ma być systemem

czasu rzeczywistego - odpowiada za używane technologie (dobór właściwych

technologii i odpowiedni sposób ich wykorzystywania).

(8)

Artefakty (1)

Główne artefakty przepływu prac Analiza i projektowanie:

 Model projektowy,

 Opis architektury systemu.

Model projektowy: Składa się z klas, pakietów i podsystemów. Pakiety i podsystemy traktowane są jako rodzaj środka organizacyjnego pozwalającego na zmniejszenie złożoności modelu wynikowego.

Model analityczny: Artefakt, efekt aktywności związanych z analizą. Będąc rodzajem abstrakcji (generalizacji modelu projektowego), skupia się wyłącznie na funkcjonalności systemu. Dalsze uszczegóławianie modelu jest przeprowadzane w trakcie projektowania.

Interfejsy: Specyfikują zbiór operacji możliwych do wykonania na elemencie modelu. Interfejsy specyfikowane są poprzez sygnatury operacji dostępnych dla danego elementu modelu. Sygnatura każdej operacji jest opisywana przez liczbę i rodzaj argumentów oraz typ wartości zwracanej.

Arefakty dla systemów czasu rzeczywistego: kapsuły.

(9)

Przepływ prac: Analiza i projektowanie (1)

Definiuj potencjalną architekturę

[Wczesne iteracje

fazy opracowywania] Uszczegóławiaj

architekturę

Analizuj zachowania

Projektuj

komponenty Projektuj komponenty

czasu rzeczywistego

Projektuj bazę danych [Dla czasu

rzeczywistego]

[Pozostałe]

[Opcjonalnie]

[Iteracje w fazie Opracowywania]

(10)

Przepływ prac: Analiza i projektowanie (2)

Aktywności przepływu prac Analiza i projektowanie różnią się nieco w zależności od fazy: w iteracjach należących do fazy opracowywania architektura jest definiowana - rozwijane są obszary najważniejsze dla projektu ze względu na funkcjonalność i mitygację największych ryzyk. Późniejsze aktywności, w iteracjach należących do fazy konstrukcji, są poświęcone rozwijaniu innych obszarów, tak aby uzyskać maksymalnie stabilną platformę architektoniczną.

Definiuj potencjalną architekturę: Podstawowym celem jest utworzenie szkieletu architektonicznego poprzez określenie (1) wstępnego zbioru elementów istotnych architektonicznie, stanowiących podstawę dla dalszych rozważań, ustalenie (2) wstępnego zbioru mechanizmów architektonicznych oraz (3) wstępnej propozycji dla podziału na warstwy (ogólnie - wstępnej propozycji organizacji systemu), (4) realizacje tych przypadków użycia, które będą podlegały dalszym pracom w danej iteracji.

W oparciu o wybrane przypadki użycia, należy zidentyfikować klasy modelu

analitycznego zaangażowane w realizację przypadków użycia - analiza interakcji

między klasami może wpłynąć na modyfikację realizacji.

(11)

Przepływ prac: Analiza i projektowanie (3)

Uszczegóławiaj architekturę: Można tu wyróżnić aktywności wykonywane przez architekta (identyfikuj mechanizmy architektoniczne, identyfikuj elementy projektowe w oparciu o już istniejący zbiór elementów, opisz architekturę czasu wykonania, opisz rozmieszczenie elementów) i aktywności związane z przeglądami architektury, za które jest opowiedzialny recenzent architektury.

Główne cele aktywności Uszczegóławiaj architekturę:

 Zapewnienie przejścia - w możliwie jak najbardziej naturalny sposób - z aktywności związanych z analizą do aktywności związanych z projektowaniem, poprzez identyfikację elementów projektowych z elementów analitycznych oraz identyfikację mechanizmów projektowych z odpowiednich mechanizmów analitycznych.

 Zapewnienie spójności i integralności architektury przez dbanie o to, by

elementy zidentyfikowane w danej iteracji były integrowane z elementami

zidentyfikowanymi wcześniej i by komponenty (czy inne elementy projektowe

o odpowiednio wysokim potencjale ponownego użycia) były wykrywane

możliwie jak najwcześniej, tak by zredukować nakłady na projektowanie.

(12)

Przepływ prac: Analiza i projektowanie (4)

 Określenie organizacji modelu implementacji tak, by przejście z modelu projektowego do modelu implementacji było bezszwowowe.

 Opisanie organizacji systemu czasu wykonania.

Analizuj zachowania: Składa się z aktywności wykonywanych przez projektanta (analizuj przypadki użycia), przez architekta (identyfikuj elementy projektowe) i przez recenzenta (związane z przeglądami projektu). Główny cel:

transformacja opisu zachowania systemu dostarczonego w postaci przypadków użycia na zbiór elementów stanowiących bazę dla modelu projektowego - nacisk jest tu położony na wymagania funkcjonalne.

Projektuj komponenty: Składa się z aktywności wykonywanych przez projektanta (projektuj przypadki użycia, projektuj klasy, projektuj podsystemy), i przez recenzenta (związane z przeglądami projektu).

Projektuj komponenty czasu rzeczywistego: Cel tej aktywności jest podobny

do aktywności poprzedniej, lecz włączane są aktywności związane z

projektowaniem kapsuł, tak by zdefiniować współbieżne wątki w systemie i

określić protokoły wymiany informacji.

(13)

Przepływ prac: Analiza i projektowanie (5)

Projektuj bazę danych: Składa się z aktywności wykonywanych przez projektanta bazy danych (projektuj bazę danych), przez projektanta (projektuj klasy) i przez recenzenta (związane z przeglądami projektu). Cel: identyfikacja trwałych klas, zaprojektowanie odpowiedniej dla tych klas struktury bazy danych oraz określenie mechanizmów wspierających przechowywanie i dostęp do trwałych danych tak, by spełniać ograniczenia nakładane na wydajność.

Wsparcie narzędziowe

 UML - język do opisu modeli. Narzędziem wspierającym pozyskiwanie, zarządzanie i prezentowanie modeli jest Rational Rose. Rational Rose wspiera kilka wybranych języków programowania, pozwalając na synchronizację projektu i kodu. Rose Real Time umożliwia prezentację wykonania zaimplementowanego fragmentu projektu.