Analiza i projektowanie aplikacji Konsultacje 518 B4 Wrocław Pon. 11-13 Czw 9-11 www.ioz.pwr.wroc.pl/pracownicy/l_rekuc 1
Literatura Wrycza s. Marcinkowski B. Wyrzykowski K. Język UML 2.0 w modelowaniu SI. Helion 2006 Kruchten Ph. RUP od strony teoretycznej. WNT 2007 Śmiałek M. Zrozumieć UML 2.0 Metody modelowania obiektowego. Helion 2005 Schmuller J. UML dla każdego.helion 2003r. Booch G. Rumbaugh J.Jacobcon I. UML przewodnik użytkownika. Inżynieria oprogramowania.wnt Warszawa 2001 Fowler M. Architektura systemów zarzadzania przedsiębiorstwem. Wzorce projektowe. Helion, 2005 Fowler M.Kendall S. UML w kropelce. LTP 2002r. www.omg.org Enterprise Architect narzędzie modelowania www. sparxsystems.com.au 2
Plan wykładu 1 1. Wprowadzenie. Modele w wytwarzaniu aplikacji dla przedsiębiorstw. Specyfika aplikacji dla przedsiebiorstw Modele i ich rola Podejście obiektowe Proces wytwarzania w uproszczeniu Jezyk UML ogólna charakterystyka 2. Model przypadków użycia (PU) -1 Ogólne pojęcia modelu Model biznesowych PU 3
Specyfika aplikacji dla przedsiębiorstw Operują zazwyczaj na danych trwałych, utrzymywanych przez wiele lat. Duża ilość danych. Zarządzanie danymi jeden z głównych wymogów do aplikacji. Jednoczesny (współbieżny) dostęp do danych wielu osób. Duża liczba ekranów interfejsu użytkownika. Potrzeba integracji z innymi aplikacjami. Zmienna logika biznesowa. Złożoność I odpowiedziałność Jak wytwarzać SI dla przedsiębiorstw? 4
Środowisko SI KOD Kodkodkodkod Kodkodkodkod Kodkod Kodkodkodkod Kodkodkodkod Kodkodkodkod Kodkodkodkod kodkod Kodkodkodkod Kodkodkodkod Kodkod kodkod Kodkodkodkod kodkod Kodkodkodkod kodkod Kodkod kodkod Modele Wykorzystane źródło: Śmiałek M. Zrozumieć UML2.0 Metody modelowania obiektowego HELION, 2005. 5
Modele w wytwarzaniu systemów informatycznych Model abstrakcja systemu, która reprezentuje kompletne (z pewnego punktu widzenia), spójne (wewnętrznie niesprzeczne) uproszczenie rzeczywistości. W metodyce RUP (ZP): model przypadków użycia systemu (model wymagań); model analizy, model projektowy, model implementacji, model rozmieszczenia. Elementy modelu artefakty, niektóre z nich są wyrażane w diagramach Cel: stworzyć system, który zaspokoji rzeczywiste potrzeby, będzie łatwo zmienialny i łatwy w użytkowaniu. Jak? Zastosowanie modeli pozwala zapanować nad złożonością i świata biznesowego i oprogramowania (w modelach przedstawiamy tylko to, co istotne z danego punktu widzenia; z jakich punktów widzenia należy popatrzeć tworząc system określa metodyka). Związek miedzy modelami biznesowymi a informatycznymi pozwala na szybkie wprowadzenie zmian w oprogramowanie przy zmianach w biznesie (techniczne rozwiązania powinny byc wynikiem przekształcenia wymagań odwzorowujących cele biznesowe, wtedy zmiana celów jest łatwo przekładana na zmianę w rozwiązaniu) Modele pozwalają porozumieć się specjalistom z różnych dziedzin 6
Podejście obiektowe. Obiekty i klasy Obiekt: byt, który ma tożsamość, granice, właściwości (stan), zachowanie. Obiekt łączy w sobie dane i funkcje. Obiektami są: Jan Nowak, krzesło w sali, nuta "do", miasto "Wrocław" itp.; Obiektami nie są: kolor "zielony", "śnieg" itp. (nie posiadają określonych granic i tożsamości). Klasa: definicja wspólnych cech grupy obiektów, które mają takie same właściwości, zachowanie, znaczenie. Program napisany obiektowo składa się deklaracji klas. Klasy łączą sie w komponenty. Konto Cel analizy i projektowania aplikacji - ustalić: z jakich klas (komponentów) powinien się składać program, co każda klasa powinna wiedzieć (jakie mieć atrybuty) i co powinna umieć robić (jakie mieć operacje). 7
Uproszczony kaskadowy proces budowy oprogramowania Analiza środowiska Wymagania Analiza Projektowanie Implementacja Cel: zrozumienie organizacji i wyrażenie w modelach. Produkty: model środowiska ( architektura, procesy, słownik). Wizja SI... Cel: pozyskanie wymagań i wyrażenie w modelu. Produkty: model PU, dodatkowa specyfikacja, rozbudowany słownik. Cel: odkrycie klas i ich odpowiedzialności. Produkty (elementy modelu analizy): klasy analizy, realizacja PU w kategoriach klas analizy, pakiety i wstępny zarys architektury SI. Cel: stworzyć podstawę do implementacji. Produkty(elementy modelu projektowego): precyzyjnie okresleone klasy, komponenty, interfejsy klas i komponentów, projekt IU i BD. Wdrożenie i eksploatacja 8
UML( Unified Modeling Language) OMG 1.4, 1.5 --> 2.0 Dlaczego zmiany? Nowa rola modeli procesów biznesowych: - Model wykonalny w WF, procesy oparte o usługi sieciowe. - Kod z modelu! UML 2 13 diagramów. Struktura: klas, struktur złożonych, komponentów, obiektów, rozmieszczenia, pakietów. Zachowanie: czynności, interakcji, maszyna stanów, przypadków użycia. 9
Diagram UML Struktury Zachowania Klas Obiektów Komponentów Pakietów Składowych Przypadków Użycia Czynności Maszyny stanów Interakcji Rozmieszczenia Dwa aspekty modelowanej rzeczywistości: Struktura (statyka) Zachowanie (dynamika) 10
Model Przypadków Użycia Reprezentuje użytkowanie systemu. Stosuje sie do systemu biznesowego i/lub informatycznego. Aktor: spójny zbiór ról użytkującego system (rola: zachowanie bytu w pewnym kontekście): może reprezentować osobę lub inny system, jest poza systemem i poza kontrolą systemu, ma nazwę i krótki opis. Przypadek Użycia (PU) systemu: proces interakcji jednego lub wielu aktorów z systemem (być może wielowariantowy): jest inicjowany przez aktora (z reguły); polega na wykonywaniu czynności przez aktorów i system w zadanej kolejności, zmierza do dostarczenia aktorowi godnego uwagi wyniku (osiągnięcia celu aktora), ma nazwę i opis (mniej lub bardziej szczegółowy). 11
Diagram PU - graficzna reprezentacja modelu PU - elipsa z nazwą PU wewnątrz lub obok. Nazwa PU1 Aktor - "ludzik" z nazwą aktora. Nazwa aktora1 Nazwa aktora1 Nazwa PU2 System Nazwa PU1 Nazwa PU2 Nazwa aktora2 Linie lub strzałki łączące symbole przypadków użycia i aktorów reprezentują ich powiązanie (komunikację). Strzałka pokazuje kierunek inicjowania (np. od aktora do PU oznacza, że dany aktor inicjuje dany PU). System może być zaznaczony jako prostokąt (opcjonalnie). 12
Diagram PU może być: ogólnym przeglądowym diagramem przedstawiającym wszystkich aktorów i wszystkie PU; ogólnym diagramem aktorów, przedstawiającym związki między aktorami; diagramem przeglądowym aktora pokazującym wszystkie powiązania tego aktora z PU; ogólnym diagramem PU pokazującym zgrupowania logicznie powiązanych przypadków użycia i aktorów; diagramem przeglądowym PU pokazującym wszystkie powiązania tego PU z aktorami i innymi PU. 13
Dwa rodzaje modeli PU Model biznesowych PU Biznesowe PU - to procesy organizacji Cel budowania modelu: zrozumieć organizacje, znaleźć aktorów i PU SI, odkryć ważne pojęcia, dokumenty Klasy Model PU systemu inform. 14
Model biznesowych Przypadków Użycia Cel: przedstawić otoczenie i jego związki z procesami organizacji. Aktor: ktoś lub coś na zewnątrz organizacji, ale biorący udział w jej działalności lub zainteresowany jej wynikami. Przykłady: Klient, Dostawca, System sprawdzania kart płatniczych, inny dział firmy. Przypadek Użycia (biznesowy) = proces organizacji: zbiór ciągów akcji dostarczający obserwowalny wynik. Model PU odwzorowuje gospodarczą działalność organizacji na bardzo wysokim poziomie abstrakcji (bez szczegółów realizacji). Model PU dla organizacji pozwala określić granicę środowiska SI! 15
: Student Dziekanat zarządzanie rejestracją Złożenie indeksu Sprawdzenie statusu Odebranie indeksu Przeprowadzenie rejestracji na sem estr : Czas : System rekrutacyj ny Wykorzystane źródło: Śmiałek M. Zrozumieć UML2.0 Metody modelowania obiektowego HELION, 2005. 16
Biuro T urystyczne Klient Świadcz usługę tu rystyczn ą Pozyskuj obiekt turystyczny Dysponent Przyjm ij rezygnację Rozwiąż um owę Termin wydania katalogu Firma Osoba Wydaj katal og 17
18
Poziom szczegółowości modelu PU Modelowanie PU jest procesem iteracyjnym i polega na kolejnym uściśleniu (a niekiedy i znalezieniu nowych) aktorów i PU. Nie każdy PU musi być szczegółowo opisany. Niektóre PU wystarczy tylko nazwać lub opisać deklaratywnie, przedstawić prototyp interfejsu użytkownika itp. 19
Przykład opisu PU (biznesowego) PU 4 Negocjacja oferty Ubezpieczenia Grupowego Klient po przedstawieniu oferty stworzonej przez Koordynatora ds. Sprzedaży Ubezpieczeń Grupowych ma możliwość ewentualnej zmiany warunków zapytania ofertowego oraz negocjowania ostatecznej formy ubezpieczenia. Analizując wymagania klienta towarzystwo ma możliwość ustalenia konsensusu oraz stworzenia ostatecznej oferty na warunkach niestandardowych. 20
Opis (specyfikacja) PU Opis przypadku użycia jest opisem interakcji systemu i aktorów, która polega na kolejnym podejmowaniu akcji przez system i aktorów. Interakcja ma więc pewien przebieg określony przez kolejność akcji. Zakłada się, że każdy przypadek użycia może mieć wiele różnych przebiegów, w zależności od sytuacji, jakie pojawiają się w trakcie interakcji aktorów z systemem. Spośród wielu przebiegów wybiera się jeden najbardziej typowy i nazywa się go podstawowym lub bazowym. Pozostałe przebiegi nazywa się alternatywnymi. Zamiast terminu przebieg stosuje się także termin scenariusz. 21
Opis (specyfikacja) PU c.d. W UML nie ustalono standardu na formę opisu PU, ale przyjęto opisywać na dwa sposoby: specyfikując wszystkie możliwe sytuacje, jakie mogą zajść w przebiegu PU, używając przy tym konstrukcji warunkowych i powtarzania; ten sposób nadaję się przy mało skomplikowanych PU; stosując tylko sekwencje opisuje się przebieg podstawowy oraz przebiegi alternatywne; każdy przebieg jest wtedy przedstawiany jako uporządkowana sekwencja akcji. 22
Rysunek symbolicznie przedstawia warianty realizacji PU przebieg podstawow y warunek wstępny przebieg alternatywn y warunek końcowy warunek końcowy warunek końcowy Warunek wstępny: stan otoczenia i/lub systemu, który warunkuje rozpoczęcie PU(musi istnieć mozliwość jego sprawdzenia przed rozpoczęciem PU) Warunek końcowy: poprawny stan systemu po zakończeniu PU.(niekiedy brzmienie jest zgodne z celem PU, może być wtedy opuszczony). Jeśli niektóre warunki wstępne i/lub końcowe muszą być spełnione we wszystkich PU, to umeszcza się wspólną odpowiednią odnotację. 23
Przykład 1. Opis PU z uwarunkowaniami ID: PU12 Aktorzy: Klient Przypadek użycia: Znajdź produkt. Warunek wstępny: klient jest zarejestrowany. Przebieg zdarzeń: 1.Klient wybiera "szukaj produkt" 2. System żada podania kryteriów wyszukania. 3. Klient podaje kryteria. 4. System wyszukuje produkty, spelniające kryteria. 5. Jeśli system znajduje produkty, to 5.1 Dla każdego znalezionego produktu 5.1.1 System wyświetla krótki opis produktu. 5.1.2 System wyświetla zestaw składników produktu. 5.1.1 System wyświetla cenę produktu. 6. w przeciwnym przypadku 6.1 System informuje klienta o tym, że nie znaleziono odpowiednich produktów. Warunki końcowe: Przebieg alternatywny: 1. W dowolnym momencie Klient może przejść na inną stronę. 24
Opis złożonych PU Jeden przebieg wybiera się jako podstawowy. Przebieg - jedna wybrana ścieżka w drzewie możliwych realizacji PU. W przebiegu nie ma rozgałęzień. Każde rozgałęzienie rodzi inny przebieg alternatywny, opisywany osobno. Przypadek użycia: WypłataGotówki ID: oznaczeniepu11 Aktorzy: Warunek wstępny: Przypadek użycia: WypłataGotówki Przebieg alternatywny:nieważnyidentyfikatorklie nta ID: oznaczeniepu Przebieg zdarzeń: 1.... Warunki końcowe: Przebiegi alternatywne: 1. Nieważny Identyfikator Klienta. 2. Nieważna karta kredytowa. Aktorzy: Warunek wstępny: Przebieg zdarzeń: 1. PU zaczyna się w kroku... PU11, kiedy... 25
SuperBankomat. Model przypadków użycia ID PU3 Nazwa: Wypłata gotówki Cel: Wypłata gotówki klientowi na podstawie karty płatniczej. Aktorzy: Klient, System CKP. Warunek wstepny: Ekran prezentuje menu główne. Przebieg podstawowy: 1.PU rozpoczyna klient wkładając kartę płatniczą. Następuje realizacja PU2 Identyfikacja tożsamości klienta (include). 2.Bankomat proponuje wybór opcji. 3.Klient wybiera opcję Wypłata gotówki. 4.Bankomat pyta o kwotę. Zazwyczaj jest lista kwot do wyboru ( 'hot-keys'). Kwota może również być wprowadzona z klawiatury. 5. Bankomat wysyła Identyfikator karty, kwotę, datę, godzinę i numer rachunku do Systemu CKP jako transakcję System CKP odpowiada poleceniem "wykonaj". 6. Bankomat wydaje pieniądze. 7. Bankomat zwraca kartę. 8. Bankomat drukuje pokwitowanie. Przebiegi alternatywne: A1. Brak gotówki w bankomacie. Jeżeli w bankomacie zabrakło pieniędzy, pobranie gotówki jest niemożliwe; alternatywny ciąg następuje po kroku 4 w głównym przebiegu. [Powinno pojawić się ostrzeżenie na ekranie informujące o braku pieniędzy. Ostrzeżenie powinno być dostrzegalne przez klienta jeszcze zanim włoży on kartę. A2.Niewłaściwa kwota. Następuje w kroku 4 przebiegu podstawowego, jeżeli klient wybierze kwotę, która nie może zostać wypłacona banknotami znajdującymi się w bankomacie; wówczas system wyświetli ostrzeżenie i poprosi klienta o zmianę kwoty. Sytuacja może się powtarzać aż do momentu wprowadzenia właściwej kwoty (zazwyczaj jest to wielokrotność liczby 20). 26
Pojęcia: Pakiet jest elementem modelu służącym do grupowania innych elementów, ma symbol graficzny i nazwę; jest jedynym "właścicielem" należących do niego elementów modelu; jest "przestrzenią nazw" dla posiadanych elementów. Zagnieżdżone pakiety mogą tworzyć hierarchię. stereotyp zawiera Nazwa pakietu, może być też w mniejszym prostokącie <<jednostka org>> <<entity>> encji Zaopatrzenie Role 27
ud Urząd gminy - aktorzy biznesowi Klient urzędu Rada gminy Urząd woj ew ódzki Sołectwo Petent Jednostka gospodarcza Podległa instytucja użyteczności publicznej ud Use Case Model Petent + Dokonaj wydzierzawienia nieruchomosci + Dokonaj zakupu mieszkania kom unalnego + Ustal granicę podziału dla nieruchomości + Uzyskaj inform ację z rejestru decyzji dla inwestycji objętych ustawą Prawo ochrony środowiska + Uzyskaj inform ację z rejestru decyzji o warunkach zabudowy i zagospodarowaia terenu + Uzyskaj inform ację z rejestru dzierżawców najemców + Uzyskaj inform ację z rejestru m iejscowych planów zagospodarowania przestrzennego + Uzyskaj pozwolenie na pobór wody z źródła własnego + Uzyskaj pozwolenie na posiadanie psa rasy niebezpiecznej
Pytania kontrolne 1. Czy aktor to zawsze osoba? 2. Jaki związek łączy aktora a PU? 3. Czy wiele osób fizycznych może reprezentować jeden aktor? 4. Czy jedna osoba fizyczna może być w roli wielu aktorów? 5. Czy ten sam aktor może wystąpić na wielu diagramach? 6. Czy z jednym aktorem może być związanych wiele PU? 7. Czy z jednym PU może być związanych wielu aktorów? Jeśli tak, to co to oznacza? 8. Jaka jest relacja między diagramem a modelem? 9. Jakie są zalety podejścia obiektowego? 10. Co daje wykorzystanie modeli w wytwarzaniu oprogramowania? 29