Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski

Transkrypt

1 INŻYNIERIA OPROGRAMOWANIA wykład 6A: ANALIZA i PROJEKTOWANIE wg RUP dr inż. Leszek Grocholski ( na podstawie książek o RUP ) Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski

2 OBIEKTOWE wg RUP PLAN PREZENTACJI 3. Analiza versus projektowanie wg RUP 4. Jak szczegółowy powinien być projekt? 5. Pracownicy i artefakty 6. Model projektowy 7. Model analityczny 8. Rola interfejsów 9. Artefakty systemów czasu rzeczywistego 10. Projektowanie oparte na komponentach 11. Przepływ pracy ( workflow) 12. Narzędzia wspomagające 13. Podsumowanie Leszek Grocholski II Uni. Wroc. 2

3 CELEM PRZEPŁYWU PRACY ANALIZA i PROJEKTOWANE wg RUP jest przetłumaczenie wymagań na dokumentacje, która opisuje jak zaimplementować system. Ażeby dokonać tego tłumaczenia, trzeba zrozumieć wymagania i przetransformować je do postaci projektu systemu. Co więcej, należy przy tej okazji zaproponować najlepszą strategię implementacji systemu. Wcześniej w przedsięwzięciu należy podjąć decyzje co do zdrowych podstaw systemu w postaci jego architektury. Leszek Grocholski II Uni. Wroc. 3

4 ANALIZA i PROJEKTOWANIE podstawy Korzystając z architektury można zaprojektować system, który jest łatwy do zrozumienia, zbudowania i ewoluowania. Potem trzeba tak dopasować projekt, aby pasował on do środowiska implementacyjnego. Następnie należy zaprojektować środowisko implementacyjne zapewniające: efektywne przetwarzanie, stabilność, skalowalność, testowalność i spełnienie innych wymagań jakościowych. Leszek Grocholski II Uni. Wroc. 4

5 Analiza versus projektowanie ( Analysis versus Design ) Celem analizy jest przetransformowanie wymagań na system do formy, która dobrze pasuje do przestrzeni pojęć projektanta oprogramowania tzn. zbioru klas i podsystemów. Transformacja ta jest sterowana przypadkami użycia i dodatkowo niefunkcjonalnymi wymaganiami na system. Analiza skupia się na zapewnieniu tego, że system spełniał wymagania funkcjonalne. W uproszczeniu analiza ignoruje większość wymagań niefunkcjonalnych na system i również ograniczenia narzucane przez środowisko implementacyjne. W wyniku tych założeń analiza określa bliski ideałowi obraz systemu. Leszek Grocholski II Uni. Wroc. 5

6 Analiza versus projektowanie ( Analysis versus Design ) cd. Celem projektowania jest, z drugiej strony zaadoptowanie wyników analizy do ograniczeń narzuconych przez wymagania niefunkcjonalne, środowisko implementacyjne, wymagania wydajnościowych itd. Projektowanie przefiltrowywuje rezultaty analizy. Skupia się na optymalizowaniu projektu systemu przy zapewnieniu spełnienia przez niego wymagań. Leszek Grocholski II Uni. Wroc. 6

7 Jak daleko musi pójść projektowanie? ( How Far Must Design Go?) Projektowanie musi zdefiniować system na takim poziomie, aby możliwa była jego jednoznaczna implementacja. To oczywiste sformułowanie ma różne znaczenie, w zależności od przedsięwzięcia i organizacji. W niektórych przypadkach, projekt musi być dopracowany do poziomu na którym możliwa jest systematyczna transformacja od projektu do kodu. Leszek Grocholski II Uni. Wroc. 7

8 Pracownicy i Artefakty (Workers and Artifacts ) RUP wyraża analizę i projekt w terminologii pracowników, artefaktów i przepływu pracy. Pokazuje, jakie artefakty produkowane są przez których pracowników oraz zakresy odpowiedzialności pracowników. Architekt prowadzi i koordynuje techniczne czynności i artefakty w przedsięwzięciu. Ustanawia ogólną strukturę i wygląd dla każdej perspektywy architektonicznej: dekompozycji widoków, grupowania elementów i interfejsów między głównymi grupami. W kontraście ze spojrzeniami innych pracowników, spojrzenie jest raczej jednym płytkim oddechem a nie głębokim łyknięciem powietrza. Leszek Grocholski II Uni. Wroc. 8

9 Leszek Grocholski II Uni. Wroc. 9

10 PRACOWNICY cd.. Projektant Projektant definiuje: odpowiedzialności, operacje, atrybuty powiązania jednej lub wielu klas i determinuje jak one powinny zostać dostosowane do środowiska implementacyjnego. W dodatku projektant może być odpowiedzialny za jeden lub więcej pakietów projektowych i projektowych podsystemów, włączając w to klasy wchodzące w skład pakietów czy podsystemów. Inni Leszek Grocholski II Uni. Wroc. 10

11 PRACOWNICY cd.. Projektant bazy danych jest potrzebny kiedy projektowany system zawiera bazę danych. Projektant Kapsuł ( Capsule Designer ) dla systemów czasu rzeczywistego Odmiana projektanta, który koncentruje się na zapewnieniu, że system jest zdolny odpowiadać na zdarzenia zgodnie z wymaganiami czasowymi, poprzez odpowiednie użycie bieżących technik projektowych. Kontroler Architektury i Projektu ( Architecture Reviewer i Design Reviewer ) przegląda architekturę i projekt. Leszek Grocholski II Uni. Wroc. 11

12 KLUCZOWE DLA ANALIZY I PROJEKTOWANIA ARTEFAKTY: Model Projektowy ( Design Model ), który jest najważniejszym dokumentem dla wytwarzanego systemu. Dokument Architektury Systemu ( Software Architecture Dokument SAD), którego zadaniem jest uchwycenie wielu spojrzeń architektonicznych na system. Leszek Grocholski II Uni. Wroc. 12

13 MODEL PROJEKTOWY (THE DESIGN MODEL ) Składa się on ze zbioru elementów diagramów współpracy ( collaboration diagrams ) oddających sposób zachowania systemu. Zachowania z kolei są pochodną informacji uzyskanych z modelu PU i wymagań niefunkcjonalnych. Model projektowy składa się diagramów współpracy klas, które mogą być agregowane w pakiety i podsystemy w celu pomocy w zorganizowaniu modelu i dostarczenia modułów składowych bloków modelu. Leszek Grocholski II Uni. Wroc. 13

14 MODEL ANALIZY ( ANALITYCZNY ) ( THE ANALYSIS MODEL) W niektórych firmach w tych gdzie systemy żyją wiele dekad lub gdzie istnieje wiele wariantów systemu osobny model analityczny jest uważany za użyteczny. Taki model analityczny jest abstrakcją czy generalizacją projektowego. Model taki nie zawiera większości szczegółów opisujących sposób działania systemu a dostarcza jedynie przeglądu funkcjonalności systemu. Dodatkowa praca potrzebna do zachowania jednoznaczności modeli analitycznego i projektowego musi być równoważona korzyściami z posiadania widoku systemu reprezentującego jedynie najbardziej ważne szczegóły sposoby działania systemu. Leszek Grocholski II Uni. Wroc. 14

15 ROLE INTEREJSÓW ( THE ROLE OF INTERFACES ) Interfejsy są używane systemów celu wyspecyfikowania zachowań oferowanych przez klasy, podsystemy systemów komponenty, w niezależny od implementacji tych zachowań. Specyfikują one za zbiór operacji wykonywanych przez elementy modelu system. Obejmują również ilość rodzaj parametrów zwracanych przez podsystemy. Każde 2 elementy systemu posiadające te same interfejsy są zamienialne. Interfejsy poprawiają elastyczność projektu dzięki ograniczenia zależności pomiędzy częściami systemu. Czynią go łatwiejszym do wprowadzania zmian. Leszek Grocholski II Uni. Wroc. 15

16 ARTEFAKTY SYSTEMÓW CZASU RZECZYWISTEGO ( ARTEFACTS FOR REAL TIME SYSTEMS ) Systemy czasu rzeczywistego to systemy, które charakteryzują się szczególnymi wymaganiami czasowymi: krytycznymi czasami reakcji, często z dużymi wymaganiami dot. rozmiarów przetwarzanych danych. Wiele z tych ograniczeń jest krytyczne. Leszek Grocholski II Uni. Wroc. 16

17 RUP opisuje następujące krytyczne artefakty: Kapsuła : specjalny wzorzec projektowy, reprezentujący wykapsułkowany wzorzec sterowania w systemie. Kapsuły maja porty, przez które komunikują się z innymi kapsułami. Protokół: specyfikuje sposób w jaki zbiór portów się komunikuje wymianę komunikatów i ich uporządkowanie w czasie i przestrzeni. Zdarzenie: jest specyfikacją wystąpienia czegoś w czasie i przestrzeni lub mniej formalnie wystąpienie czegoś na coś system musi zareagować. Sygnał: jest asynchronicznym zdarzeniem które może spowodować przejście pomiędzy stanami maszyny stanowej pewnego obiektu. Leszek Grocholski II Uni. Wroc. 17

18 PROJEKTOWANIE BAZUJĄCE NA KOMPONENTACH ( COMPONENT BASED DESIGN) Komponenty są elementami modelu implementacyjnego i są używane do podkreślenia tego, że system jest implementowany z małych kawałków. Komponent oferuje jeden lub więcej interfejsów zależy jedynie od interfejsów z innymi komponentami. Używanie komponentów pozwala na projektowanie, implementacje, dostawę i zamianę wielu części systemu niezależnie od jego reszty. Elementy modelu projektowego korespondują do komponentów podsystemów, które to są niezależnymi częściami systemu, mogącymi być projektowane i implementowane niezależne. Podsystemy oferują interfejsy i zależą od interfejsów innych elementów modelu. Leszek Grocholski II Uni. Wroc. 18

19 PRZEPŁYW PRACY ( WORKFLOW ) Następny slajd ilustruje w formie diagramu czynności UML, iteracje w przepływie pracy analiza i projektowanie. Każdy stan czynności reprezentuje szczegółowy przepływ pracy np.: Definiowanie kandydującej architektury. Każdy szczegółowy przepływ pracy składa się ze swoich czynności. Niektóre szczegółowe przepływy pracy są zależne od fazy : w iteracjach dot. fazy opracowania definiowana a następnie doskonalona jest architektura, podobnie jest z najważniejszymi obszarami i ryzykami aplikacji są tematem analizy i projektowania. W następującej po niej iteracji fazy budowy, kładziony jest nacisk na dodanie aplikacji większej funkcjonalności w oparciu o coraz bardziej stabilną platformę architektoniczną. Leszek Grocholski II Uni. Wroc. 19

20 wg RUP Leszek Grocholski II Uni. Wroc. 20

21 Definiowanie kandydującej architektury ( Define Candidate Architecture ) * Utworzenie początkowego szkicu architektury systemu. Aktywność definiuje: początkowy zbiór znaczących dla architektury projektowanych elementów ( podstawa analizy ), początkowy zbiór algorytmów analitycznych, początkowe uwarstwienie i organizacja systemu oraz realizacje PU przewidziane do wykonania w danej iteracji. * Zidentyfikowanie klas analitycznych na podstawie znaczących dla architektury przypadków użycia. * Uaktualnianie realizacji PU poprzez analizę współdziałania klas analitycznych. Leszek Grocholski II Uni. Wroc. 21

22 DOSKONALENIE ARCHITEKTURY ( REFINE the ARCHITECTURE ) Ten szczegółowy przepływ pracy składa się z czynności: identyfikowanie zadań i celów projektowych, identyfikowanie elementów, scalanie istniejących elementów projektu, opis architektury czasu rzeczywistego ( opis dystrybucji informacji ), opis wszystkich artefaktów wykonywanych przez architekta, doskonalenie w/w, przegląd architektury wykonywany przez kontrolera projektu. Leszek Grocholski II Uni. Wroc. 22

23 ANALIZA ZACHOWAŃ (ANALYZE BEHAVIOR ) Na ten szczegółowy przepływ pracy składają się następujące czynności: analiza PU przeprowadzona przez projektanta, identyfikacja elementów projektu wykonywana przez architekta systemu i przegląd projektu wykonywany przez kontrolera projektu. Celem tego szczegółowego przepływu pracy jest transformacja opisu zachowań dostarczonego przez PU w zbiór komponentów, które stanowić będą podstawę projektu. Należy zauważyć, że analiza zachowań koncentruje się mniej na niefunkcjonalnych wymaganiach systemu a bardziej na tym bardziej na tym jak zapewnić dostarczenie przez system wymaganych funkcjonalności. Leszek Grocholski II Uni. Wroc. 23

24 Projektowanie Komponentów ( Design Components ) Na ten szczegółowy przepływ pracy składają się czynności: projektowanie PU, projektowanie klas i projektowanie podsystemu, wykonywane przez projektanta komponentów i przegląd projektu wykonywany przez kontrolera projektu. Projektowanie komponentów czasu rzeczywistego ( Design Real Time Components ) Dotyczy projektów które, będą używać jako artefaktów kapsuły pierwszej rangi elementy projektowe w kontekście systemów czasu rzeczywistego. Leszek Grocholski II Uni. Wroc. 24

25 PROJEKTOWANIE BAZY DANYCH ( DESIGN THE DATABASE) Jest to opcjonalny szczegółowy przepływu pracy wymagany, kiedy system korzysta w dużego rozmiaru bazy danych składowanych w bazie danych. Projektowanie bazy danych składa się z następujących działań: projektowanie bazy ( wykonywanej przez projektanta bazy danych), projektowania klas (wykonywanego przez projektanta ), przegląd projektu ( przeprowadzany przez kontrolera projektu ). Leszek Grocholski II Uni. Wroc. 25

26 WSPOMAGANIE NARZĘDZIOWE Modele wykonywane są w UML u. narzędziem tworzenia, zarządzania i prezentacji modeli jest IBM Rational Architect. Architect umożliwia wykonywanie inżynierii wstecz ( round trip engineering ) w paru wybranych językach programowania, zapewnienie perfekcyjnej synchronizacji modeli, kodu różnych wersji systemu od projektowania do kodowania czy na odwrót. IBM Rational Architect dostarcza narzędzi mentorskich w postaci wskazówek do tworzenia modeli w UML i korzystania z systemu. Pakiet Reel Time umożliwia natychmiastowe wykonywanie modeli. Pakiet Soda pozwala na automatyczne generowanie dokumentów czy raportów, ekstrakcje i formatowanie informacji z wielu innych źródeł, takich jak Architect czy Requiste Pro. Leszek Grocholski II Uni. Wroc. 26

27 PODSUMOWANIE Analiza i projektowanie stanowią pomost między wymaganiami a implementacją. Ten przepływ pracy wykorzystują przypadki użycia do identyfikowania zbioru obiektów, który jest sekwencyjnie przekształcany do coraz doskonalszych klas, podsystemów i pakietów. Odpowiedzialności w analizie projektowania są podzielone pomiędzy architekta ( tworzy wielkie obrazy ), projektanta ( szczegóły) projektanta bazy danych ( szczegóły), które wymagają szczegółowej wiedzy o wymaganiach i stanie przedsięwzięcia ( ponowne użycie!). Leszek Grocholski II Uni. Wroc. 27

28 PODSUMOWANIE cd Wynikiem analizy i projektowania jest model projektowy, który może być wyabstrahowany używając 3 perspektywy architektoniczne. Perspektywa logiczna reprezentuje dekompozycje systemu na zbiór logicznych elementów ( klas, podsystemów, pakietów, ich wzajemnych oddziaływań). Perspektywa procesowa ( dynamiczna ) odwzorowywuje te elementy na procesy ( diagram czynności i komunikacji ) oraz wątki w systemie. Perspektywa wdrożeniowe przyporządkowuje realizacje procesy do komponentów oraz do węzłów, w których one działają czy są instalowane. W niektórych przypadkach oddzielny model analityczny może być użyteczny w celu dokonania przeglądu jego funkcji czy zbudowania abstrakcyjnego modelu systemu. Leszek Grocholski II Uni. Wroc. 28

29 INŻYNIERIA OPROGRAMOWANIA Dziękuję za uwagę Leszek Grocholski II Uni. Wroc. 29