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.

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.