Archive for the ‘UML’ Category

h1

Proces oparty o stany

Październik 18, 2015

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.

Reklamy
h1

Wzorcowa pizza

Lipiec 7, 2012

Wyobraźmy sobie, że jesteśmy w pizzerii i mamy ochotę zjeść pizzę. Nie wiemy jeszcze jaką, ale będzie to pizza. Można powiedzieć, że danie to jest pewien sposób abstrakcyjne, bliżej nieokreślone, do momentu, gdy zapoznamy się z menu i dowiemy się jakie są możliwości. Spośród rodzajów pizzy, np. Amerykańska, Wegetarianska, Hawajska, Rzeznicka itp., będziemy wybierać konkretną na podstawie jej składników, które w niej będą. Przeglądamy menu i decydujemy się na konkretne składniki – na przykład Ser, Szynka, Salami lub Ananans, Ser itd.

Wymienione składniki też są w pewien sposób abstrakcyjne, nie wiemy jak będą ułożone, ile ich będzie, jak będą duże, ale wiemy, że będzie to określony składnik.
Mamy więc od strony Klienta: wybraną pizzę składająca się z wymienionych składników.
Restauracja wie jaka pizza z jakich się składa elementów, ale dopiero w momencie przygotowania nastąpi ich wybór.

Powyższy przykład, opierając się na wyborze abstrakcyjnych składników z jednej strony, a dostarczenia konkretnych produktów z drugiej, można przedstawić za pomocą wzorca projektowego fabryka abstrakcyjna (ang. abstract factory).
Wzorzec ten składa się z elementów, zaprezentowanych na powyższym przykładowym diagramie UML:

  • Fabryka abstrakcyjna (ang. abstract factory) – interfejs dla klienta do wyboru konkretnych rodzajów pizzy. Na diagramie oznaczony jako „AF”.
  • Fabryka konkretna (ang. concrect factory) – określa elementy konieczne do stworzenia danej pizzy z elementów składowych. Na diagramie oznaczony jako „CF”.
  • Produkt abstrakcyjny (ang. abstract product) – interfejst dla klienta do wyboru rodzaju składników pizzy. Na diagramie oznaczony jako „AP”.
  • Produkt (ang. product) – konkretna realizacja oczekiwana przez klienta – dany składnik pizzy. Na diagramie oznaczony jako „P”.
  • Klient (ang. client) – używa powyższych elementów (wybiera pizzę, składniki). Na diagramie oznaczony jako „C”.

Klient inicjuje wybór pizzy, wybierając jej składniki, fabryka tworzy, w zależności od wybranej pizzy, odpowiednie zestawienie składników. Te zależności obrazują strzałki użytkowania (ang. uses) elementów na diagramie.

h1

Proces akceptacji – sposób sterowania

Marzec 5, 2011

Zastanawiałem się po przeczytaniu komentarzy do poprzedniego wpisu nad rozwiązaniem dla procesu akceptacji dokumentu. Wydaje się, że są dwa możliwe rozwiązania:

  1. System wspiera proces akceptacji i decyduje o tym do kogo trafia dokument po wykonaniu danej akcji. Określa również kiedy proces jest zakończony. Na poniższym diagramie górna część (Diagram A) prezentuje takie podejście. System po akcji użytkownika „Zatwierdź” lub „Odrzuć” wykonuje „Określenie osoby” i ewentualnie „Przesyła dokument”. Operacja „Prześlij dokument” może wystąpić bądź nie. Podobnie w wyniku „Określ osobę” może zostać zakończony proces.
  2. Użytkownik decyduje o osobach uczestniczących w procesie. Po wykonaniu „Akceptuj” lub „Odrzuć” użytkownik decyduje, czy przesłać dokument dalej, skonsultować go, czy całkowicie odrzucić. Rolą systemu w takiej sytuacji jest śledzenie i odnotowywanie zmian. Taka sytuacja jest przedstawiona na dolnej części poniższego diagramu (diagram B).

Na powyższym diagramie (diagram przypadków użycia w UML) za pomocą powiązań <<include>> oraz <<extend>> przedstawiono specyfikę następujących przypadków użycia:

  • „Określ osobę” – użyto powiązania<<include>>, które oznacza, że zawsze podczas „Zatwierdź dokument” oraz „Odrzuć dokument” występuje „Określ osobę”.
  • „Prześlij dokument” – użyto powiązania <<extend>>, które oznacza, że jedynie w określonych sytuacjach (przy spełnieniu ustalony warunków), zostanie wywołane „Prześlij dokument”.
h1

Co pokazać na diagramie procesu?

Luty 21, 2011

Ostatnio na forum analizy biznesowej śledziłem wątek dotyczący kaskadowego procesu akceptacji (ang. waterfall acceptance business process) zainicjowanego przez inicjatora w następujący sposób (po przetłumaczeniu): „… sposób zaprezentowania procesu, który zawiera wiele kroków akceptacji wykonywanych przez różnych aktorów biznesowych. Każda z ról (4 lub 5) z występujących w procesie może zaakceptować lub odrzucić (odesłać do poprzedniej roli) dokument. Przebieg procesu nie może zostać zmodyfikowany […] Diagram ma być czytelny…”. Cały wątek znajduje się na forum Modern Analyst.

W powyższym opisie można wskazać następujące elementy:

  • inicjator poszukiwał sposobu na prezentację procesu;
  • w procesie uczestniczy kilka osobnych osób;
  • dokument niezaakceptowany jest odsyłany do poprzedniej roli;

Na poniższym diagramie zaprezentowano (przetłumaczone) dwie propozycje rozwiązania powyższego problemu. Ta po lewej przygotowana została przez inicjatora wątku. Z kolei ta po prawej, została przedstawiona przez jednego z uczestników wątku. Obydwa diagramy przytoczone bez zmian w przebiegu – zaprezentowane w jednorodnej notacji (diagram aktywności UML).

Pierwszy z nich wskazuje wprost do kogo wraca dokument po jego odrzuceniu przez danego uczestnika procesu. Natomiast drugi nie pokazuje tego wprost – wymagane jest zapoznanie się z opisem procesu. Myślę, że nie jest to korzystne, ponieważ proces akceptacji to przede wszystkim przebieg dokumentu między recenzentami/akceptantami i samym inicjatorem. Jednakże zaletą takiego przedstawienia jest uproszczenie diagramu oraz wskazanie, że kolejni uczestnicy (poza inicjatorem) wykonują podobne czynności. Wdrażając rozwiązanie w systemie będą to prawdopodobnie „wywołania” tego samego przypadku użycia. Taki przypadek użycia będzie musiał przede wszystkim „wiedzieć”, gdzie odesłać i gdzie przesłać dalej dokument, a także kiedy zakończyć proces.

Warto sobie zadać pytania:

  • dla kogo ma zostać przygotowana prezentacja procesu?
  • do czego zostanie wykorzystana prezentacja procesu?

Odpowiedzi na te pytania determinują poziom szczegółowości procesu i sposób prezentacji. Każda z odpowiedzi: „ma pokazywać kto”, „ma pokazywać co” lub „ma pokazywać jak” może wymusić inny sposób prezentacji. Jedyne co wiemy o oczekiwaniach, to wymóg czytelności diagramu. Wydaje się, że diagram po lewej stronie jest bardziej czytelny, dzięki zastosowaniu podziału na „partycje”, wskazanie stanów dokumentów oraz wykonywanych akcji.

h1

Status – informacja dla klienta czy dostawcy?

Styczeń 22, 2011

Zanim odpowiem na pytanie postanowione w komentarzu do poprzedniego wpisu, chciałbym przedstawić jeszcze jeden przykład. Przykład będzie dotyczyć statusów zamówienia w systemie składania zamówień przez klienta. Informacja o statusie może być przydatna zarówno dla klienta, który chce być informowany na jakim etapie jest zamówienie, jak i dla dostawcy, który może na tej podstawie tworzyć raporty. Można także pójść dalej i przechowywać dwa rodzaje statusów – zewnętrzne (biznesowe) i wewnętrzne (systemowe). Obydwa statusy mogą wynikać z wymagań.

Zastanówmy się w takim razie w jakich statusach może być zamówienie w analizowanym systemie składania zamówień:

  • zainicjowane/utworzone (z pierwszym dodanym produktem, klient może dodać kolejne produkty lub zaprzestać na jednym);
  • złożone (klient wysłał zamówienie do realizacji);
  • oczekujące na realizację (klient zrealizował płatność na złożone zamówienie lub potwierdził złożenie zamówienia);
  • w trakcie realizacji/realizowane (gdy realizacja zamówienia została rozpoczęta i jest w trakcie, w systemie obsługi opartym o kolejkowanie, można powiedzieć, że zamówienie zostało podjęte);
  • wykonane (przedmiot zamówienia został przekazany do klienta);
  • anulowane (klient wycofał zamówienie z różnych powodów już po złożeniu zamówienia);
  • wstrzymane (realizacja zamówienia została zatrzymana z różnych przyczyn);
  • usunięte (klient usunął zamówienie przed jego złożeniem);

Poniższy diagram (stanów) w UML prezentuje przejścia między poszczególnymi statusami (stanami Zamówienia).

h1

Obsługa wyjątków w wymaganiach

Styczeń 15, 2011

W trakcie funkcjonowania procesów biznesowych, systemów czy aplikacji komputerowych mogą wystąpić sytuacje zwane wyjątkami (ang. exceptions). Mogą one być związane bezpośrednio z czynnościami wykonywanymi przez użytkownika/uczestnika procesu, a także wynikać z problemów z funkcjonowaniem wykorzystywanych narzędzi. W szczególności możemy mówić o:

  • nieautoryzowanych żądaniach,
  • błędnie wprowadzonych danych,
  • niedostępności narzędzi, usług, baz danych,
  • czasie odpowiedzi przekraczającym ustalone parametry biznesowe,
  • awariach wydajności,
  • utracie połączenia
  • itp.

Podczas projektowania aplikacji istotne jest to, aby w wymaganiach wskazać sposób obsługi sytuacji wyjątkowych. Strategie mogą być różne – począwszy od raportowania każdego błędu do użytkownika i przenoszeniem na niego odpowiedzialności poradzenia sobie z sytuacją, poprzez wspieranie użytkownika w rozwiązywaniu problemu, po implementację mechanizmów, które automatycznie próbują rozwiązać zaistniałą sytuację.

Na diagramach przedstawionych (wskazanych) w poprzednim wpisie pojawił się element komunikacji Zarządcy z InterfejsemERP czy pośrednio z BaząProduktów. Patrząc jedynie na ten element można mówić o różnych sytuacjach.

Na powyższym diagramie (diagram sekwencji w UML) zaprezentowano dwa wyjątki: timeout i failure. W przypadku tego pierwszego można by wskazać, że ma powtarzać wywołanie na przykład 3 razy i dopiero przy kolejnej nieudanej próbie informować użytkownika i zapisywać sytuację w bazie. Obsługa wyjątków jest istotna w systemach wykorzystujących usługi lub pracujących na dużych bazach danych. Na diagramie nie wskazano WczesniejZakupione, InniKupowali oraz Promocje, aby zachować pewien poziom ogólności. Jednakże warto przypomnieć, że wskazane elementy uczestniczą w interakcji między WyszukiwarkaProduktow a BazaProduktow. Nie została również pokazana sytuacja, gdy dane pochodzące od użytkownika były błędne.

h1

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

Listopad 17, 2010

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: