Posts Tagged ‘UML’

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

Co dostarczają kroki procesu?

Wrzesień 23, 2015

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.

h1

Etapy benchmarkingu na przykładzie

Luty 3, 2011

Załóżmy, że mamy sklep internetowy w którym można wykonać standardowe czynności związane z tworzeniem zamówienia i jego realizacją. Na jego przykładzie omówię etapy benchmarkingu (wskazane wcześniej w definicji benchmarkingu).

Etap 1. Identyfikacja (obszaru do porównania z liderami rynkowymi)

Podczas analizy sklepu zidentyfikowano jeden z elementów, który nie jest konkurencyjny względem innych sklepów dostępnych w internecie, nie wspiera sprzedaży produktów i nie ułatwia podejmowania decyzji zakupowych. Elementem tym jest sposób wyszukiwania i prezentacji danych o produkcie.

Etap 2. Analiza (wybranego obszaru, określenie jego cech specyficznych, analiza różnic)

Prezentacja danych o produkcie w naszym przykładowym sklepie internetowym zawiera: zdjęcie, dane o produkcie, cenę, specyfikację oraz opinie. Standardem na rynku jest publikowanie również produktów podobnych, kupowanych przez innych razem z danym produktem, produktów uzupełniających. Na diagramie (diagram aktywności w UML) zaprezentowany został proces „PRZED ZMIANĄ”.

Etap 3. Projektowanie (rozwiązania dla analizowanego obszaru)

W ramach projektowania rozwiązania określone zostaje w jaki sposób można uzupełnić dane o produkcie. Opisywane są wymagania biznesowe dla ewentualnej zmiany oraz rozbudowywane procesy sprzedażowe, jak i systemowe oparte o sklep internetowy. W ramach jednego z poprzednich wpisów („Czy można pokazać więcej?„) został zaprezentowany wzorzec Tablica, który oddaje specyfikę elementu, który należałoby wdrożyć.

Projektowanie może zostać zlecone zarówno dostawcy zewnętrznemu, jak i być wykonane wewnętrznymi zasobami. W tym etapie należy określić jakie dane i skąd należy wykorzystać, a także jakie nowe czynności muszą zostać wprowadzone do istniejących procesów, aby taki mechanizm przewidzieć. W tym etapie są określane również cele dla projektowanego rozwiązania. Czynności wykonywane przez Klienta pozostają takie same. Zmieniają się tylko czynności wykonywane przez system bądź dostawcę.

Na diagramie (diagram aktywności w UML) został zaprezentowany proces „PO ZMIANIE” (nowe elementy na zielono). Planując zmiany w systemach, istotne jest przeprowadzenie właściwej analizy przedwdrożeniowej, o czym można przeczytać więcej w artykule „Analiza przedwdrożeniowa – czym jest” (na stronie it-consulting.pl/blog).

Etap 4. Wdrożenie (rozwiązania i zebranie danych do oceny)

W trakcie wdrożenia następuje implementacja zaprojektowanego rozwiązania. Nowe procesy są stosowane. Po wdrożeniu następuje zbieranie danych do oceny rozwiązania, aby później była możliwa dalsza analiza. Na podstawie analizy mogą zostać zarekomendowane kolejne ulepszenia procesu. Jest to specyfika benchmarkingu, jako ciągłego udoskonalania procesów, rozwiązań.

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

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:

h1

Diagram klas (UML) po raz 2

Październik 18, 2010

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;

h1

Diagram klas (UML)

Październik 16, 2010

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.