--Pozostałe aktorzy

Transkrypt

--Pozostałe aktorzy

Analiza i projektowanie aplikacji
Dr inż. Ludmiła Rekuć
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
Kodkodkodkod
Kodkod
Kodkodkodkod
Kodkod
Kodkod
Kodkodkodkod
Kodkodkodkod
Kodkod
Kodkod
Kodkodkodkod
KodkodKodkod
Kodkodkodkod
Kodkod
Kodkodkodkod
kodkod
KodkodKodkod
Kodkodkodkod
Kodkod
kodkod
KodkodKodkod
Kodkodkodkod
kodkod
Kodkod
Kodkodkodkod
kodkod
Kodkod
kodkod
Środowisko
SI
KOD
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
Konto
łączą sie w komponenty.
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
Przypadków Użycia
Obiektów
Czynności
Komponentów
Maszyny stanów
Pakietów
Interakcji
Składowych
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
Nazwa
PU2
Nazwa
aktora1
System
Nazwa
PU1
Nazwa
aktora1
Nazwa
PU2
Aktor - "ludzik" z nazwą aktora .
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
Dzi e ka n a t
za rzą d za n i e re j e stra cj ą
S p ra wd ze n i e
sta tu su
Zł o że n i e i n d e ksu
O d e b ra n i e i n d e ksu
P rze p ro wa d ze n i e
re j e stra cj i n a
se m e str
: Czas
: System
rekrutacyj ny
Wykorzystane źródło: Śmiałek M. Zrozumieć UML2.0 Metody
modelowania obiektowego HELION, 2005.
16
Bi u ro
T u rystyczn e
Klient
Ś wi a d cz u sł u g ę
tu rystyczn ą
P rzyj m i j re zyg n a cj ę
Termin
wydania
katalogu
Po zysku j o b i e kt
tu rystyczn y
Dysponent
Ro zwi ą ż u m o wę
Firma
Osoba
Wyd a j ka ta l o g
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
Przypadek użycia: Znajdź produkt.
ID: PU12
Aktorzy: Klient
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:
Przypadek użycia: WypłataGotówki
Przebieg
alternatywny:NieważnyIdentyfikatorKlie
nta
Warunek wstępny:
ID: oznaczeniePU
Przebieg zdarzeń:
1.
...
Warunki końcowe:
Aktorzy:
Przebiegi alternatywne:
1. Nieważny Identyfikator Klienta.
2. Nieważna karta kredytowa.
Przebieg zdarzeń:
1. PU zaczyna się w kroku ... PU11,
kiedy...
...
Warunek wstępny:
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 biznesow i

Rada gminy Urząd woj ew ódzki
Klient urzędu
Sołectwo

Petent
Jednostka
Podległa instytucj a

gospodarcza
użyteczności
publicznej

ud Use Case Model

Petent

+ Doko naj wydzierzawieni a nie rucho m osci
+ Doko naj zakupu m ie szkani a kom unalnego
+ Ustal grani cę podzi ału d la ni eruchom ości

+ Uzyskaj i nform acj ę z re jestru decyzji dla inwestycji obj ętych ustawą Prawo ochrony środowiska
+ Uzyskaj i nform acj ę z re jestru decyzji o warunka ch zabudowy i zagospodarowai a terenu
+ Uzyskaj i nform acj ę z re jestru dzierżawców naje m ców

+ Uzyskaj i nform acj ę z re jestru m iej scowych plan ów zagospodarowani a przestrze nnego

+ Uzyskaj pozwol enie na pobór wody z źródł a własnego

+ Uzyskaj pozwol enie na posi adanie 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