Tym razem mała polemika czyli kontrpropozycja. Celem artykułu nie jest krytyka cudzego projektu, daleki jestem od tego. Celem jest pokazanie, że są rożne metody analizy i projektowania. Czytelnik sam dokona porównania i ewentualnej oceny. Drugim celem jest wskazanie pewnych metod modelowania, spełniających obiektowy paradygmat i obiektowe metody analizy i projektowania, w odróżnieniu od metod mających nadal podstawy w analizie strukturalnej. Najpierw cytat z pewnego portalu (źródło pod cytatem):
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:
źr. Diagram klas ? ?reinżynieria? (etap 1) ? Modelowanie procesów biznesowych.
Tam więc mamy opis, czasem nazywany magicznie: “user story”. Na bazie opisu powstał diagram klas. Tak właśnie wygląda wiele analiz wymagań. Ta jest całkiem przyzwoita, większość kończy na zarejestrowaniu tego “user story” i przeredagowaniu go do jakiejś określonej strukturalnej postaci nazwanej następnie Wymagania Użytkownika. Kłopot w tym, że – jak wielu pewnie z czytelników już się przekonało – tak określone wymagania i projekt są w trakcie implementacji permanentnie zmieniane w takt odkrywania rzeczy, oczywistych dla użytkownika, o których nam w swoim “user story” nie powiedział.
Jak już chyba każdy mój czytelnik wie, preferuje metody formalne. Tak wiec zamiast modelować od razu “system” i brać się za jego implementację (pierwszy prototyp? zwinne tworzenie oprogramowania itp….) biorę na tapetę to “user story” i sprawdzam jego spójność. Jak? Ano tworze model procesu, który to “user story” opisuje. I co powstaje?
Jak widać, “user story” jest dziurawe jak ser szwajcarski. Pojawiły się nowe zdarzenia i dokumenty wraz ze statusami. Uzupełnieniem tego diagramu powinny być wzory dokumentów oraz ograniczenia np. produkt umieszczony na Zamówieniu musi być blokowany na czas jego przetwarzania. Etap obsługi płatności powoduje zdjęcie blokady lub zdjęcie z magazynu, zależnie od finału transakcji.
Teraz dopiero przychodzi pora na analizę o tworzenie diagramu klas a konkretnie modelu dziedziny. Kandydatami na klasy są dokumenty, zdarzenia i ewentualnie role (aktorzy, a raczej dane o nich). Kandydatem na klasę są także reguły biznesowe i ich “wykonawcy”. Teraz jest moment na zdeklarowanie się co do stylu analizy i projektowania. Po pierwsze jako bazy używam wzorca MVC i metodyki opisującej jak tworzyć element o nazwie Model w MVC czyli Domain-Driven Design, której twórcą jest Eric Evans.
Po co to robię? Dlaczego podnoszę pracochłonność analizy wymagań i projektuję model koncepcyjny do testów? Ano po to by błędy i niespójności odkryć teraz, bo na etapie implementacji ich usuwanie będzie nawet 100 razy droższe. Czy takie błędy są w projektach o uproszczonych analizach biznesowych (lub wręcz pominiętych?) Ci co mają takie projekty za sobą wiedzą doskonale, że są i to prawie zawsze…
W następnej części przypadki użycia, diagram klas czyli model dziedziny oraz ich testowanie.
W artykule podsuwa Pan sluszne tezy. Natomiast diagram procesu wyglada tak jakby stosowal Pan w mysli logike diagramu aktywnosci UML, zas do zobrazowania wybral Pan notacje odchodzaca w strone BPMN. Skad ta niekonsekwencja? Czyzby probowal Pan sie dopiero przekonac do nowej notacji, sposobu myslenia?
Nie do końca mogę się z tym zgodzić ;). Diagramem aktywności UML było by trudno (zapewne się da ale ciekaw jestem późniejszej jego zrozumiałości w gronie “biznesowym”) opisać dialog B2B rozróżniając przepływ sterowania od komunikatów (pomiędzy podmiotami na rynku nie ma sterowania, są tylko przekazywane informacje! bo nie ma tu relacji przełożony-podwładny) i przepływu danych, dlatego celowo używam na tym etapie BPMN (który się do tego doskonale nadaje). Nie widzę tu żadnej niekonsekwencji (gdzie ona?). Istotne było pokazanie współbieżności czynności i zdarzenia synchronizujące. Jak napisałem: pierwszy etap to część biznesowa, tu jest to modelowanie i testowanie procesu zakupu realizowanego przez klienta. Na tym etapie nie ma żadnego UML (celowo, a notację BPMN testuję i używam prawie od momentu jego pojawienia się). Nie użyłem celowo nawet pojęcia “formularz WWW” gdyż proces ten co do zasady opisuje “cel czynności i jej scenariusz” a nie implementację.
Tak więc celem tego diagramu na tym etapie było tylko (i aż) przetestowanie spójności treści “user story” i uzupełnienie jej o brakujące elementy. Ten etap nazywany jest często proof-of-concept na etapie opisu biznesowego. Faktem jest, że diagram jest dość szczegółowy jak na proces biznesowy ale od czego są dekompozycje, one prowadzę do tego poziomu szczegółowości jeśli jest taka potrzeba.
oj, to chyba już nie będę drążył… Activity UMLowe jak najbardziej stosuje pools, komunikację, nie trzeba wcale używać przepływów sterowania. Ostatnio (w przeciągu miesiąca) czytałem artykuł o tym jak to niepotrzebnie UML się tu zbliża (widocznie to nie Pan pisał).
Niemniej – przekonał mnie Pan, że moja obserwacja nie miała podstaw 😉 W pewnym sensie więc mam odpowiedź na moje pytanie. Dziękuję 🙂
Tak dla porządku: nie neguję możliwości diagramu aktywności w obszarze procesów biznesowych, nie używam go do modelowania procesów głownie dlatego, że BPMN po pierwsze generuje kod XPDL (UML nie) i jeżeli mam się zastanawiać jakiej notacji użyć w danym momencie po protu nie zastanawiam się tylko na etapie analizy biznesowej zawsze używam BPMN, jest to czysta wygoda i moja i zamawiającego tym bardziej, że projekty z zakresu inżynierii oprogramowania to nie jedyne moje projekty biznesowe :).
Zastanawiam się czy stosuje Pan (czy warto stosować) diagramy procesów biznesowych zarówno, by opisać wszystkie ważne procesy ze świata zamawiającego, w celu ich zrozumienia, jak i później do przetestowania user stories? Czy one się czymś różnią (poza przedstawianym zakresem)? A może to to samo?
Czy oba potwierdza Pan z zamawiającym? Wydawałoby się, że zatwierdzimy to, co jest zapisem naszego zrozumienia, a zapisu projektowania już nie. Jednak gdzie dokładnie leży ta granica, która mówi o tym, co zatrzymać dla siebie jako część procesu analizy i nie zamęczać klienta?
osobiście z powodów “semiotycznych” (semiotyka) używam jednej notacji (system znaków itp.) do jednego problemu, używam BPMN tylko do modelowania “biznesu”, scenariusze UC opisuję w punktach i diagramem sekwencji. Dzięki temu czytelnik ma “percepcyjny” rozdział dziedzin (biznes – BPMN, system UML).
Bardzo proszę o pokazanie diagramu procesu.
Aktualnie widzę jedynie: “[singlepic id=64 w=580 h=580 float=center]”
To niestety pozostałości po reinstalacji, których nie wychwyciłem. Uzupełniłem brakujący diagram. W raze pytań proszę tu pisać.