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ów biznesowych trochę od innej strony… « Dynamika – szczegółowość opisu Czy można pokazać więcej? Styczeń 11, […]