E. Stemposz. Rational Unified Process, Wykład 10, Slajd 1 wrzesień 2002 Powrót Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 10 Przepływ prac: Analiza i projektowanie Wykładowca: dr inż. Ewa Stemposz Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 2 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 3 wrzesień 2002 Powrót Analiza kontra projektowanie (1) Podstawowym celem przepływu prac Analiza i projektowanie jest zamiana wymagań w specyfikację sposobu implementowania systemu. Podstawowym zadaniem jest „określenie najlepszej strategii dla sposobu implementowania systemu”, co osiąga się 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: używalność, niezawodność, wydajność, wsparcie dla pielęgnacji, 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.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 4 wrzesień 2002 Powrót 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).

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 5 wrzesień 2002 Powrót Pracownicy (1) Architekt Model analityczny Model projektowy InterfejsDokument architektury oprogramowania Artefakty systemów czasu rzeczywistego Zdarzenie Sygnał Protokół odpowiedzialny za

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 6 wrzesień 2002 Powrót Pracownicy (2) Realizacja przypadku użycia: opis sposobu realizacji 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

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 7 wrzesień 2002 Powrót 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. Inni pracownicy zaangażowani w aktywności związane z przepływem prac Analiza i projektowanie, to 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).

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 8 wrzesień 2002 Powrót 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 (w tym pakietów podsystemów). Pakiety 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 listę argumentów oraz typ wartości zwracanej. Artefakty dla systemów czasu rzeczywistego: kapsuły.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 9 wrzesień 2002 Powrót 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]

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 10 wrzesień 2002 Powrót 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 definiowana jest architektura − 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) 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 ich realizację − analiza interakcji między klasami może wpłynąć na modyfikację realizacji.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 11 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 12 wrzesień 2002 Powrót 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.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 13 wrzesień 2002 Powrót 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.