UML 1 – diagramy interakcji

Transkrypt

UML 1 – diagramy interakcji
UML 1 – diagramy interakcji
Materiał na ćwiczenia z rysowania diagramów interakcji wchodzących w skład UMLa.
Forma ćwiczeń.
Każdy ze studentów otrzymuje materiały w postaci referencji do odpowiednich diagramów oraz
krótki opis przykładowego systemu NextGenPOS (Larman, „Applying UML patterns...”) wraz z
wymienioną funkcjonalnością oraz wyodrębnionymi aktorami (głównymi oraz wspierającymi).
Dodatkowo, znajduje się tam pełen opis przypadku użycia (PU) przetworzenia zapłaty. Ćwiczenia
polegają, na krótkim przypomnieniu danego diagramu, po czym zespoły modelują przy ich pomocy
nasze biznesowy przykład (proces), począwszy od ogólnego diagramu przypadków użycia, przez
diagramy sekwencji, czynności i stanów dla wspomnianego PU. Każdy diagram jest rysowany
przez jedną osobę na tablicy, po czym omawiany przez wszystkich oraz rozszerzany (zob.
konkretne ćwiczenia). Do ćwiczeń załączone są przykładowe diagramy z książki, które należy
traktować tylko i wyłącznie jako szkice do rozwiązań.
Załączniki.
Do rozdania studentom:
●
referencja UML – obecnie są trochę przestarzałe (nie w wersji 2.0), ale w miarę dobrze
wyglądające, rysunki. Zapewne lepiej by było rozdać slajdy z wykładu o UMLu (o ile będą
dostępne; wykład był niedawno) lub po prostu wymagać znajmości/przedstawić samemu
odpowiednie elementy diagramów. Uwagi odnośnie konkretnych typów diagramów przy
ćwiczeniach;
●
przykład NextGenPOS – przeklejone (w języku ang.) z książki Larmana, w związku z czym
mogą być pogwałcone jakieś prawa autorskie i dlatego jeśli ktoś czuje taką potrzebę może
odebrać rozdawane materiały po zajęciach.
Ćwiczenie 1 – diagram przypadków użycia
Uwagi do referencji UML:
Generalizacją się nie zajmujemy. Ogólna rada: ograniczać się do max. include ; extend jak
mamy pewność, że to dobre miejsce do zastosowania – rysowanie diagramu (zwłaszcza PU) ma
usprawnić pracę zainteresowanych/komunikację z zainteresowanymi.
Główne zadanie:
Narysować prosty diagram przypadków użycia (tylko proste relacje, bez include i extend ) dla
systemu NextGen POS.
Uwagi:
Ćwiczenie sprowadza się praktycznie do połączenia ze sobą kropek przy pomocy kresek (nazwy
przypadków użycia i aktorzy są wymienieni w załączniku), zastanawiając się, który aktor bierze
udział, w którym PU.
Przypadki cash-in i cash-out to zameldowanie się i odmeldowanie kasjera z szufladą przy terminalu.
Być może rozliczany będzie również wtedy z godzin pracy, stanu kasy (vide aktor wspierający HR).
Szkic rozwiązania:
Rozszerzenia do zadania:
Wykorzystanie relacji include i extend . Opis tego jak przekłada się diagram na strukturę
dokumentu przypadków użycia (vide kierunki strzałek: przy include mamy referencje z PU,
przy extend odwrotnie).
1. Klient dodał wymaganie funkcjonalne dotyczące możliwości wypożyczania w sklepie (PU
process rental), dla którego jest tworzony system – dodać ten przypadek użycia do naszego
diagramu, wyodrębniając wspólne z przypadkiem przetworzenia sprzedaży (opis w
załącznikach) „podprzypadki” użycia.
Uwagi:
Nie dokonywać dogłębnej analizy PU process sale, co najwyżej nagłówki poszczególnych
rozszerzeń, o co w nich mniej więcej chodzi, jak bardzo są skomplikowane i na tej
podstawie wyodrębnić wspólne części poprzez include .
Szkic rozwiązania:
2. Kiedy jeszcze może się przydać include (poza powtarzaniem nietrywialnych części wielu
PU)?
Odpowiedź:
Modelowanie „asynchronicznych” (mogących rozszerzać podstawowy przebieg w
dowolnym momencie) przypadków użycia takie jak interwencja menadżera.
3. Klientowi przypomniało się o kuponach rozdawanych okazjonalnie (jako np. prezent
świąteczny), za które można nabyć towary (do odpowiedniej kwoty). Dodać ten przypadek
użycia do diagramu jako rozszerzenie przypadku przetworzenia sprzedaży.
Szkic rozwiązania:
Ćwiczenie 2 – diagram sekwencji
Uwagi do referencji UML:
●
Przestarzałe notacje dla pętli i warunków (teraz są specjalne, czytelniejsze ramki loop ,
opt , region/ref ).
●
Paski aktywacji są opcjonalne (jeżeli nie wnoszą żadnej informacji można po prostu się nimi
nie przejmować).
Główne zadanie:
Narysować bardzo prosty diagram sekwencji dla procesu biznesowego przetworzenia sprzedaży
(PU process sale; kasjer i system, ew. klient).
Uwagi:
Diagramy sekwencji rysuje się przede wszystkim dla wyeksponowania komunikacji w modelu
(poziom pakietów i/lub klas). Tu ćwiczymy głównie notację i różne reprezentacje tego samego
procesu.
Szkic rozwiązania:
Rozszerzenia do zadania:
1. Dodać elementy (linie życia i komunikacja) związane z kalkulatorem podatków (rozważyć
liczenie na bieżąco czy po zakończeniu nabijania rzeczy?) oraz systemami płatności i
księgowości jeżeli klient nie płaci gotówką (ramki opcji).
Szkic rozwiązania:
Ćwiczenie 3 – diagram czynności
Uwagi do referencji UML:
●
Dodatkowa notacja dla hierarchicznego definiowania diagramów (czynność jest całym
diagramem; przykład jest na diagramie stanów).
●
Dodatkowa notacja związaną z dataflow (plus ew. stereotyp datastore ).
●
Tory nie muszą być tylko na górze (można wykorzystać oba wymiary do wydzielania
czynności wchodzących w zakres różnego rodzaju odpowiedzialności).
Główne zadanie:
Narysować diagram czynności, zawierający jak najmniej czynności, dla procesu biznesowego
przetworzenia sprzedaży (PU process sale; tory: klient, kasjer i system).
Uwagi:
W przeciwieństwie do diagramów sekwencji, diagramy czynności są głównie stosowane do
modelowania przepływów pracy/procesów biznesowych (bliskie pokrewieństwo z sieciami
Petriego).
Warunek „jak najmniej czynności” określony po to aby podejść do sprawy
iteracyjnie/kompozycjonalnie/hierarchicznie: najpierw na jak najogólniejszym poziomie, później
uszczegóławiać (próbując narysować wszystko naraz wychodzą straszne kulfony).
Ważne aby czynności na diagramie były mniej więcej tego samego kalibru/na tym samym poziomie
abstrakcji (nie np. system rozpoczyna nową sprzedaż wraz z system obsługuje płatność).
Szkic rozwiązania (ciut za dużo póki co – patrz roszerzenia):
Rozszerzenia do zadania:
1. Rozszerzyć diagram o dane: wózek, rzecz, rachunek.
Szkic rozwiązania:
[zob. szkic główny]
2. Rozpisać czynność obsługi płatności ze sprawdzeniem warunku na opłatę gotówką.
Uwagi:
Może być hierachicznie i wtedy nowy tor wewnątrz osobnego diagramu lub dorysować
nowy tor przy pierwotnym diagramie.
Szkic rozwiązania:
[zob. szkic główny – tam już jest rozpisane w prostej postaci]
3. Jak starczy czasu: Rozpisać na osobnym diagramie pętle kasowania poszczególnych rzeczy
(system rejestruje, aktualizuje listę oraz łączną kwotę) wraz z podjęciem przez kasjera
decyzji o zakończeniu sprzedaży.
Ćwiczenie 4 – diagram stanów
Główne zadanie:
Narysować diagram prosty diagram stanów dla procesu biznesowego przetworzenia sprzedaży (PU
process sale), z opcjonalną autoryzacją płatności jeśli nie była to sprzedaż gotówkowa.
Uwagi:
Notacja graficzna prawie identyczna z notacją dla diagramu czynności.
Podkreślić, że te diagramy nie stosuje się raczej do modelowania procesów biznesowych. Raczej do
rzeczy niskopoziomowych typu kontrolery procesów, urządzeń, protokołów.
Szkic rozwiązania: