Studia Podyplomowe IT w Biznesie Rational Unified Process

1. Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa Studia Podyplomowe IT w BiznesieRational Unified Process Wykład 10Przepływ prac: Analiza i projektowanie Wykładowca: dr inż. Ewa Stemposz ewag@ipipan.waw.pl

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 Artefakty systemów czasu rzeczywistego odpowiedzialny za Zdarzenie Protokół Model analityczny Model projektowy Interfejs Dokument architektury oprogramowania Sygnał

6. Pracownicy (2) Realizacja przypadku użycia Klasa Pakiet projektowy Podsystem Model danych Projektant Projektant bazy danych Systemy czasu rzeczywistego Projektant kapsuł odpowiedzialny za odpowiedzialny za odpowiedzialny za Kapsuła 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. 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.

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) [Iteracje w fazie Opracowywania] [Wczesne iteracje fazy opracowywania] Uszczegóławiaj architekturę Definiuj potencjalną architekturę Analizuj zachowania [Opcjonalnie] [Pozostałe] [Dla czasu rzeczywistego] Projektuj komponenty Projektuj komponenty czasu rzeczywistego Projektuj bazę danych

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. • SoDa pozwala na automatyczne tworzenie i formatowanie dokumentów i raportów poprzez wydobywanie informacji z kilku innych narzędzi, np. z Rational Rose czy Requisite Pro.