Diagram klas – „reinżynieria” (etap 2)

Kolejnym etapem tworzenia diagramu klas, przedstawionego w poprzednim wpisie (Diagram klas – reinżynieria (etap 1)) jest uzupełnienie go o atrybuty oraz metody. Poniższy diagram zawiera takie przykładowe uzupełnienie:

Diagram klas – „reinżynieria” (etap 1)

Wcześniej zostały zaprezentowane dwa diagramy klas (pierwszy i drugi), które prezentowały w różny sposób, mniej lub bardziej poprawny, pewną dziedzinę. Na diagramach zostały wskazane metody, atrybuty oraz zostały opisane związki. Po dyskusjach na wcześniej wspomnianym forum, przemyślałem propozycje i postanowiłem, że stworzenie tego diagramu klas to będzie dobry przykład podejścia o charakterze reengineeringu lub benchmarkingu, zależy jak na to spojrzeć. Zacznę od początku, a to jest cecha bliska reengineeringu. Zastosuję wskazówki, wnioski z dyskusji, porównania się z doświadczeniami innych, co przypomina benchmarking (o różnicy między tymi dwoma podejściami, w zakresie procesów, postaram się napisać w kolejnym wpisie).

Kilka słów o tym, co chciałbym przedstawić:

  • mamy klienta (klientów), który składa zamówienia on-line u dostawcy pewnych produktów,
  • u dostawcy dostępne jest wiele produktów, o różnych cenach, parametrach, wadze itp.,
  • zamówienie może się składać z od jednego do wielu produktów,
  • za zamówienie klient może dokonać płatności na 3 różne sposoby: kartą kredytową, przelewem lub gotówką.

Mamy więc: Klienta, Zamówienie, Produkt oraz Płatność, co na diagramie można przedstawić następująco:

Diagram klas (UML) po raz 2

W związku z tym, że poprzedni diagram klas wywołał dyskusję na pewnym forum nt. jego zawartości, konstrukcji, zastosowanych elementów, atrybutów oraz realizacji między nimi, przygotowany został nowy diagram (poniżej). Dyskusja jak najbardziej konstruktywna (miejmy nadzieję, że dla wszystkich czytelników), została zapoczątkowana przez Analityka Biznesowgo, którego wizyta na moim blogu mnie bardzo zaskoczyła. Zamieszczam poniższy diagram z komentarzem i czekam na dalszy ciąg. Na tym blogu zawarte są treści, które są analizowane i później proponowane są nowe rozwiązania – taka jest idea tego bloga („modelowanie trochę od innej strony…”). Tym razem zostałem w swoich planach wyprzedzony z analizą przykładu.

Kilka komentarzy:

  • nie zastosowano w nim kompozycji, ponieważ jest za mocną relacją, nie oddaje rzeczywistości. W szczególności w tego typu dziedzinie Klient może istnieć samodzielnie, nie musi złożyć zamówienia, może tylko przeglądać. Podobnie produkt może istnieć samodzielnie. Diagram dotyczy dziedziny zamówień przez internet i wtedy produkt w dziedzinie istnieje przed klientem i przed zamówieniem;
  • atrybut „płeć” jest jak najbardziej przydatnym elementem w prezentowaniu Klienta, w szczególności w diagramach, które odpowiadają systemom zakładającym takie coś jak personalizacja, czy badanie zachowań klientów. Nie ma tego na diagramie, bo to nie było celem samym w sobie;
  • niektóre atrybuty rzeczywiście były zbędne lub umieszczone w nieprawidłowej klasie. W związku z tym, niektóre usunąłem, a niektóre przeniosłem;
  • zmienione zostały klasy uczestniczące w relacji dziedziczenia;
  • na diagramie warto byłoby dodać, dla jasności sytuacji, klasy użytkownika oraz interfejs koszyk, żeby lepiej zilustrować charakter;
  • można dodać klasę faktura;

Diagram klas (UML)

Na diagramach prezentujących warstwę reiżnynierii zostały zamieszczone informacje o następujących obiektach:

  • DaneKlienta – zaprezentowane jako klasa „Klient” na poniższym diagramie;
  • DaneZamowienia – zaprezentowane jako klasa „Zamowienie” na poniższym diagramie;
  • DaneDostawy – zaprezentowane jako klasa „Dostawa” na poniższym diagramie;

Były one używane do realizacji określonych czynności. Na poniższym diagramie – tzw. diagramie klas (ang. class diagram)zostały one zaprazentowane jako klasy wraz z przykładowymi atrybutami (ang. attribute) oraz operacjami (ang. operation). Dodatkowo zostały umieszczone dodatkowe klasy – np. Płatność – silnie powiązane z tą dziedziną. Między poszczególnymi klasami zostały określone związki. Przy niektórych podana liczebność. Inne natomiast są w relacji uogólnienia.

Powyższy diagram ma charakter przykładowy. Kolejna wersja diagramu z komentarzami znajduje się tutaj.

Czy można pokazać więcej?

Zanim spróbuję odpowiedzieć na pytanie postawione w tytule. Kilka słów komentarza. Przyjęcie pewnych założeń – np. mamy system ERP – powoduje inne spojrzenie na prowadzoną analizę i nie pozwala w pewnych sytuacjach na znalezienie najlepszego rozwiązania, czy może zaprezentowania jak najlepiej efektu, który chcielibyśmy osiągnąć. Może aktualne mechanizmy zastosowane w systemie ERP są niewystarczające, co może być skutkiem ubocznym prowadzonej analizy. Tzw. dostosowywanie się do istniejących narzędzi powoduje, że w jakiś sposób dostosowujemy nasze myślenie, czy docelowy obraz procesów do już znanych mechanizmów. Nie pozwala na spojrzenie szersze, czy nawet wzbudzenie inicjatywy ze strony osób zaangażowanych w projekt. Mało tego czasami zdarza się, że koszty dostosowania się do istniejącego systemu są tak duże, że sam pomysł realizacji usprawnienia czy zmiany przestaje być korzystny albo nie jest wykonalny w akceptowalnym czasie. Zależności między wymaganiami/jakością, czasem realizacji oraz budżetem to już inna kwestia, nad którą nie chciałbym się teraz rozwodzić…

Tymczasem mała dygresja z innego podwórka. W bankowości bardzo często budując strategię sprzedaży staje się przed wyborem: elastyczne procesy i produkty czy standaryzacja produktów. Wydaje się może, że nie jest to kwestia powiązania, ale jak się przyjrzeć bliżej… Opis wymagań abstrahujący od sposobu wykonania, czy ograniczeń na pewnym etapie działania może przynieść w ostateczności bardziej elastyczne rozwiązanie. Stosowanie gotowego rozwiązania i trzymanie się cały czas jego wymagań jest to jakby trzymanie się/powielanie standardów postępowania. Wszystko zależy od tego, co chcemy osiągnąć.

Spójrzmy na poniższy diagram (zamieszczony na stronie it-consulting.pl/blog we wpisie „Diagram klas – czyli „reinżynieria” analizy biznesowej c.d. model dziedziny”):

Diagram klas – czyli „reinżynieria” analizy biznesowej c.d. model dziedziny

 

Diagram powstał jako odpowiedź na mój diagram z wpisu o „Reinżynierii” diagramu klas. Zgadzam się z komentarzem, że mój diagram jest pewnym modelem pojęciowym. Pokazuje jednak pewne zależności między elementami i zatrzymuje się na pewnym etapie ogólności pozwalającym na dyskusję: jakie informacje są potrzebne o produktach? w jaki sposób obsłużyć płatność? czego brakuje? który element jest wykorzystywany przez użytkownika, a co dzieje się automatycznie? Itd. W kolejnych iteracjach mogły zostać dodane kolejne elementy. Zaletą moim zdaniem jest to, że abstrahuje od rozwiązania informatycznego, pokazując pewne informacje logiczne. Wadą jest to, że brakuje wstępnego opisu przypadków użycia, aby przybliżyć dziedzinę. We wpisie o dynamice próbowałem pokazać pewne zachowania, które mogą nastąpić, schodząc na niższy poziom analizy.

Na wcześniejszym diagramie  brakuje mi przestawienia tego w jaki sposób wybierane są produkty i spośród jakich produktów są wybierane. Z doświadczenia wiem, że taka informacja na etapie prezentacji analizy jest cenną informacją. W przypadku nowej aplikacji internetowej pokazuje potencjalny zakres wykorzystywanych źródeł informacji. W przypadku istniejącej aplikacji pokazuje jakie informacje będą potencjalnie wykorzystywane w interakcji z użytkownikiem. Trzymając się zaproponowanego rozwiązania możemy to pokazać jak na poniższym diagramie.

Na diagramie zostały pozostawione operacje tylko z „Zarządcy”. Dodane jednak zostały, trzymając się metody „Role, odpowiedzialność, współpraca”, z zastosowaniem wzorca „Tablica”:

  • tzw. „źródła wiedzy” („Promocje”, „Inni kupowali”, „Wcześniej zakupione”);
  • tzw. „tablica” („Baza produktów”);
  • tzw. „sterownik” („Wyszukiwarka produktów”);

Można by pójść dalej, analizując różne statusy zamówienia i skutki dla systemu, użytkownika. Podobnie można się zastanowić, czy „tablicy” nie zastąpić przez dostawcę usług („interfejs do ERP”).

Podsumowując, myślę, że odpowiedź na pytanie zawarte w tytule jest twierdząca. Stosując zaproponowane metody można pokazać więcej, w szczególności trzymając się pewnego poziomu uogólnienia.

Dynamika – szczegółowość opisu

Trochę zainspirowany komentarzem do jednego z poprzednich wpisów, prowadzącym do artykułu „Diagram klas – czyli „reinżynieria” analizy biznesowej” (z it-consulting.pl/blog), a trochę w wyniku krystalizacji pomysłu na kolejny wpis, postanowiłem spojrzeć na diagram klas z poprzedniego wpisu w sposób bardziej dynamiczny. Jest to o tyle ważne, że sposób prezentacji diagramu klas i wykorzystane konstrukcje wpływają później na sposób implementacji takiego rozwiązania, przedstawiającego w bardziej lub mniej szczegółowy wymagania użytkownika. Chciałbym się skupić na elemencie „Zamówienia” wraz z operacjami wykonywanymi na nim.

Zastanówmy się najpierw czego oczekuje użytkownik systemu do składania zamówień od tego elementu. Odpowiedź nasuwa się sama, chce zaspokoić, w szczególności, dwie swoje potrzeby:

  • potrzebę dodania produktu do zamówienia oraz
  • potrzebę (ewentualnego) usunięcia produktu z zamówienia

Po prostu wyszukuje produkt i dodaje go do zamówienia, bądź wchodzi do „zamówienia” (listy dodanych produktów) i usuwa dany produkt. Świadomie nie wpisałem powyżej zmiany ilości, ponieważ tak naprawdę zwiększenie/zmniejszenie ilości produktu można zinterpretować jako dodanie/usunięcie produktu. Zostańmy jednak przy operacjach dodaj/usuń.

Użytkownik wybiera daną opcję i nie interesuje go co się dzieje wewnątrz systemu. Poniższy diagram w notacji BPMN jest próbą zaprezentowania tego, co mogłoby się dziać.


Diagram obrazuje, że system może kilka różnych czynności wykonać po wybraniu opcji przez użytkownika. Kilka kwestii wymaga jednak komentarza. Na poziomie Klienta zostały przedstawione operacje na najwyższym poziomie tożsame wręcz przyciskom w systemie. Natomiast na poziomie Systemu pojawiają się operacje wskazane na diagramie klas. Użytkownik dodaje produkt do zamówienia, określając jego ilość, a system tworzy pozycję na zamówieniu, dla danego produktu wraz z odpowiednią ilością. Pozycje zamówienia w tym wypadku nie są współdzielone (zastosowano kompozycję).

Można byłoby dalej dodać mechanizmy zabezpieczające przed dodaniem większej ilości produktu niż jest dostępna. Można także określić operacje proklienckie.  Wraz z kolejnymi zamówieniami sytuacja klienta w systemie oraz określonych produktów w pewnym sensie się zmienia. Zwiększając precyzję opisu wymagań można wskazywać kolejne ograniczenia czy też możliwości.

Rozbudowa opisu może przejść od typowej „narracji” (przykład w poprzednim wpisie), przez konkretne „scenariusze” (repezentowane przez tabele, diagramy) po „komunikację” (między elementami, wymianę komunikatami, co częściowo zostało pokazane w niniejszym wpisie).

Proces oparty o stany

Wyobraźmy sobie, że parking opisany ostatnio we wpisie, wykonuje oprócz wskazanych 3 podstawowych działań (przyjęcie samochodu, przyjęcie opłaty i wypuszczenie samochodu), jeszcze jedną bardzo ważną rzecz. Mianowicie, wskazuje w momencie wjazdu na parking, gdzie jest najbliższe wolne miejsce. Niby rzecz trywialna, ale wymaga odpowiedniego przygotowania – zarówno od strony infrastruktury (kontrola zajętych miejsc, identyfikacja gdzie są samochody wcześniej wpuszczone, które jeszcze nie zaparkowały), jak i informatycznej (odpowiedni system zarządzania miejscami parkingowymi, kontrolą stanów miejsc i ich zmianą, a także prezentacją graficzną parkingu).

stany450px

Z jednej strony mamy zmianę stanu miejsca parkingowego, a z drugiej weryfikację położenia, gdzie jest wolne miejsce. Takie procesy zostały zaprezentowane na powyższym diagramie. W momencie realizacji procesu (na diagramie Określ mapę dojazdu) z prezentacją najbliższego wolnego miejsca (na diagramie Wyświetl mapę dojazdu) system musi wziąć pod uwagę stany miejsc parkingowych wynikajacych z:

  • zajęcia miejsca parkingowego (zmiana stanu na zajęty),
  • opuszczenia miejsca parkingowego (zmiana statusu na wolny),
  • przemieszczania się samochodów wpuszczonych na parking (w dowolnym momencie dane miejsce może zmienić stan),
  • lokalizacji samochodów wpuszczonych na parking (np. są na 2 poziomie, a miejsce akurat jest na 1 poziomie).

Chcąc uniknąć ryzyka, że wskazane najbliższem miejsce okaże się zajęte, można także wskazywać miejsce alternatywne. Dodatkowo już po wjeździe na parking w widocznych miejscach mogłyby być umieszczone ekrany wskazujące na najbliższe wolne miejsce parkingowe (cykliczne wykonywanie pierwszego procesu). Ułatwieniem w zarządzaniu takim parkingiem mogłoby być to, że nie da się cofnąć do innego miejsca parkingowego, nie przejeżdżając przez punkt startowy, który dodatkowo jest kontrolowany przez system.

W podanym przykładzie podane procesy opierają się na świadomym wykorzystaniu stanów poszczególnych miejsc parkingowych (oznaczone za pomocą funkcji w klasach UML na diagramie). Stany miejsc występują naprzemiennie i trudno jest określić jakie są ramy czasowe dla rozpoczęcia procesu i jego zakończenia. Dla danego miejsca stan może się nie zmienić godzinami lub zmienić się raz i pozostać taki przez wiele godzin. Takie cechy są charakterystyczne dla procesów sterowanych stanami – ang. state-driven process. Skierowanie samochodu na dane miejsce jest możliwe tylko, gdy jest ono wolne. Zmiana stanu odbywa się poprzez odnotowanie wjazdu samochodu na dane miejsce.

Co dostarczają kroki procesu?

Ostatnio spotkałem się z pojęciem diagramu procesu, który na bazie kroków procesu równocześnie wskazuje, co one dostarczają. Jest to tzw. Process-Deliverable Diagram (w skrócie PDD). Jest to diagram, który łączy w sobie elementy z dwóch obszarów:

  • kroków/czynności składających się na proces, zaprezentowanych za pomocą diagramu czynności (ang. activity diagram) z notacji UML,
  • obiektów dostarczanych przez proces, zaprezentowanych za pomocą diagramu klas (ang. class diagram) z notacji UML;

pdd2

Pierwszym procesem, który przyszedł mi na myśl, gdy przeczytałem o tym diagramie, był proces realizacji projektu, zaprezentowany na powyższym przykładowym diagramie. Począwszy od inicjalizacji projektu, przez realizację jego kolejnych działań po wdrożenie, na każdym etapie dostarczany (ang. deliver) jest określony “produkt”. Produkty w całości lub częściowo są wykorzystywane na kolejnych etapach procesu. Te produkty można potraktować jako produkty końcowe procesu. Mogą być np. podstawą kolejnych zmian, przeprowadzania szkoleń, wyjaśniania reklamacji, analizy luk procesu.

Podobne rozwiązanie zostało zastosowane przy prezentacji wejść i wyjść w ramach realizacji procesu rekrutacji.

Proces w czarnej skrzynce

Dotychczas system karty aglomeracyjnej traktowałem jak tzw. czarną skrzynkę (ang. black box). Interesowały mnie tylko te działania, które mają skutek na wyświetlane komunikaty i reakcje na działania użytkownika. Wskazywałem początek trasy, koniec trasy i otrzymywałem zwrotnie odpowiedni komunikat.

Zastanówmy się jednak jak proces przedstawiony w jednym z poprzednich wpisów, a dokładnie o komunikatach dla odbiorcy wygląda w systemie karty. Można powiedzieć, że ma na pewno operacje: przyjmij punkt trasy, wyświetl komunikat, nalicz opłatę. Można sobie wyobrazić, że ma również sprawdź czy nastąpiła przesiadka (momencie odczytu punktu trasy), sprawdź czas między punktami trasy (aby określić, czy to jest kontynuacja trasy czy niezależna podróż).

Karta450

Na powyższym diagramie górna jego część prezentuje wybrane działania i ich skutek. Dodatkowo zostały wpisane obiekty, które są tworzone. Obiekty te są odpowiednikiem klas zaprezentowanych poniżej, za pomocą UML. Przedstawiony diagram obrazuje co potencjalnie może się dziać w ramach systemu i jakie struktury są w tym celu potrzebne. Na przykład, po „przyjmij punkt trasy” następuje sprawdzenie, czy to początek, czy koniec, sprawdzenie czy nastąpiła przesiadka, następnie zapis informacji z jego parametrami, następnie naliczenie opłaty i wyświetlenie komunikatu.

Krok „Określ rodzaj punktu”, po określeniu numeru linii i numeru przystanku, sprawdza, dla obecnie zapisanej trasy, (jeżeli istnieje), jaki rodzaj może to być punktu – początek, koniec czy przesiadka – są to rodzaje Punktu trasy, stąd zastosowane dziedziczenie. Określa te parametry, które zostają zapisane jako element trasy. Następnie następuje w kroku „Nalicz opłatę” żądanie Określ opłatę(), które w zależności od parametrów trasy, nalicza opłatę do końca linii, aktualizuje opłatę dla przesiadki lub określa końcową opłatę za przejechany odcinek. Naliczona opłata lub różnica do zwrotu zostaje odnotowana w saldzie karty poprzez operację ZmienSaldo().

Atrybut Linia określa na jakiej linii a atrybut przystanek określa kiedy i na jakim przystanku nastąpiło wskazanie punktu trasy. Atrybut Linia jest potrzebny do określenia czy nastąpiła przesiadka, a Przystanek (numer, czas) wskazuje, czy może traktować kolejny punkt jako przesiadkę czy niezależne rozpoczęcie trasy. Trasa określana jest przez poszczególne Punkty trasy. „Aktualna trasa” jest zapisywana dla danej Karty raz w systemie.