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. Narysować prosty diagram przypadków użycia (tylko proste relacje, bez include i extend ) dla systemu NextGen POS. Ć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).
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. 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.
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. Ć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ć). Narysować bardzo prosty diagram sekwencji dla procesu biznesowego przetworzenia sprzedaży (PU process sale; kasjer i system, ew. klient). 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.
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).
Ć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). Narysować diagram czynności, zawierający jak najmniej czynności, dla procesu biznesowego przetworzenia sprzedaży (PU process sale; tory: klient, kasjer i system). 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. [zob. szkic główny] 2. Rozpisać czynność obsługi płatności ze sprawdzeniem warunku na opłatę gotówką. Może być hierachicznie i wtedy nowy tor wewnątrz osobnego diagramu lub dorysować nowy tor przy pierwotnym diagramie. [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 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. 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.