Wstęp
Od czasu do czasu jestem pytany o to, kiedy używać diagramu aktywności UML. Od 2015 roku specyfikacja UML wskazuje, że diagramy te są narzędziem modelowania metod czyli logiki kodu (dla Platform Independent Model): aktywności (activities) to nazwy metod, zadania/kroki (actions) to elementy kodu (przykłady w dalszej części).
Gdy powstawał UML, diagramy aktywności były używane także do modelowanie procesów biznesowych. W roku 2004 opublikowano specyfikację notacji BPMN, która w zasadzie do roku 2015 “przejęła” po UML funkcję narzędzia modelowania procesów biznesowych. W 2015 roku formalnie opublikowano specyfikację UML 2.5, gdzie generalnie zrezygnowano z używania UML do modeli CIM. Obecnie Mamy ustabilizowaną sytuację w literaturze przedmiotu: BPMN wykorzystujemy w modelach CIM (modele biznesowe), UML w modelach PIM i PSM jako modele oprogramowania (a modele systemów: SysML, profil UML).
Tak więc obecnie:
Nie używamy diagramów aktywności do modelowania procesów biznesowych. Do tego służy notacja BPMN!
Diagram aktywności może być modelem kodu na wysokim lub niskim poziomie abstrakcji, operujemy wtedy odpowiednio aktywnościami (activity) lub działaniami (actions). Te ostatnie to w zasadzie reprezentacja poleceń programu.
Nie ma czegoś takiego jak “proces systemowy”, oprogramowanie realizuje “procedury”.
Projektując oprogramowanie zgodnie ze SPEM , powstaje Platform Independent Model. W praktyce już na tym etapie programujemy, bo tworzymy logikę i obraz przyszłego kodu. Taka forma dokumentowania pozwala także lepiej chronic wartości intelektualne zamawiającego.
Problem
Bardzo często, na początkowym etapie projektowania, chcemy pokazać nie tylko architekturę, ale także koncepcję działania systemu, mimo tego, że nie dopracowaliśmy jeszcze detali. Mamy komponenty ale nie mamy jeszcze ich operacji. Chcemy jednak udokumentować nasz pomysł, pokazać i omówić, zanim opracujemy detale (bo jesteśmy agile).
Od początku (powinniśmy mieć) umowę czyli zakres projektu:
Wiemy kto: aktor, będzie używał aplikacji: system, i wiemy jaką usługę ma ona świadczyć aktorowi: Use Case.
UWAGA! Usługa systemu to nie cel aktora. Celem aktora jest np. “kontrola sprzedaży” albo “nadzór sprzedawców”, a realizowana (wymagana) usługa systemu to “raport marży”.
Pozostaje opracować pomysł na realizację tego rozwiązania, a detale opracowane będą później . Więcej o tym jak opisać detale: Przypadki użycia i ich detale oraz Paradygmat obiektowy i Przypadki Użycia.
Dokumentowanie rozwiązania
Kolejny krok to opracować szkielet architektury:
Zgodnie z wzorcami i najlepszymi praktykami, dzielimy system na elementy o wąskiej i dobrze określonej specjalizacji, projektujemy komponenty odpowiedzialne za: realizację scenariusza obsługi aktora (Use Case), realizację logiki biznesowej (Logika) oraz za zachowywanie danych (Repozytorium ) (patrz także ). I chcemy na razie szybko pokazać nasz pomysł na to jak to ma działać:
Na diagramie aktywności powyżej, partycje reprezentują komponenty naszego systemu. Odpowiedzialności (role) poszczególnych komponentów opisują nazwy aktywności jakie im przyporządkowano. Całość pokazuje jaki komponenty, w jakiej kolejności i jak (za odpowiadają), zrealizują naszą usługę. Ten diagram pełni role opisową, pokazuje odpowiedzialność komponentów oraz przebieg procedury realizacji usługi aplikacji.
W kolejnym etapie pracy nad modelem możemy dodatkowo pokazać przepływ obiektów niosących dane (Formularz), uzupełniamy więc powyższy diagram:
Znakomita większość wymagań biznesowych i funkcjonalnych jest realizowana jako treść formularza (struktura dokumentu) wraz z logiką rządzącą ich treścią (tak zwane walidacje) i związkami między atrybutami dokumentów:
Powyższy diagram to nasz dokument niosący dane (Formularz), będący zarazem modelem danych (w metodach obiektowych nazywamy to także agregatem). Jeżeli pojawia sie wymaganie np. “System ma informować dłużnika SMS-em o saldzie rachunku”, to oznacza to (realizacja tego wymagania), że w dokumencie (zestaw danych) Karta Klienta, ma sie pojawić także pole (atrybut) “numer telefonu komórkowego”, a nasz system (diagram przypadków użycia) ma mieć dodatkowego aktora jakim jest serwer SMTP i wskazujemy, który komponent zrealizuje to zadanie.
W metodach (paradygmat) obiektowych nie tworzymy relacyjnych modeli danych i nie używamy SQL na etapie analizy i projektowania.
Po uzupełnieniu projektu Formularza o detale (atrybuty) otrzymujemy (diagram poniżej prawa strona: Document):
Kolejny etap analizy i projektowania, czyli pora na kolejne detale: precyzyjny scenariusz, jego celem jest test logiki procedury i uzupełnienie powyższych klas o wymagane do tego operacje:
Operacje klas to nazwy ich wywołań na powyższym diagramie. Na tym etapie, projektujemy detale komunikacji komponentów, projektując tę komunikację wyznaczyliśmy operacje dla poszczególnych klas. Powyższy diagram to projekt i zarazem test logiki realizacji usługi, modelowanej jako przypadek użycia aplikacji. Po opracowaniu tego modelu mamy więcej danych o komponentach, znamy też już ich operacje i ich parametry:
Mamy już więc architekturę oraz operacje klas, dla realizacji nazwanej na diagramie Przypadków Użycia usługi aplikacyjnej. Całość jest spójna, bo diagram sekwencji jest projektem i zarazem dowodem poprawności i spójności komunikacji klas.
Kolejny etap to dokumentowanie metod operacji (algorytm), tu metoda operacji “Zachowaj” klasy “Repozytorium” (to także procedura ale niższym poziomie abstrakcji):
I tym sposobem opracowaliśmy projekt realizacji jednej usługi naszej aplikacji. Można już zlecić jej implementację (kodowanie), a w tym czasie zająć się analizą i projektowaniem kolejnej. To się nazywa orientacja na mikroserwisy i iteracyjno-przyrostowe konstruowanie oprogramowania. Metoda analizy i projektowania od ogółu do szczegółu, z podziałem na komponenty, nie jest nowa. Pierwsze opisy podziału dużych systemów na separowane komponenty to lata 90-te a projektowanie zorientowane na odpowiedzialność klas to początki lat 2000 . Rosnąca złożoność oprogramowania i wymagania na krótki czas dostarczenia produktu, w zasadzie nie pozwala już na inny styl projektowania i implementacji, bez tego cofamy sie do metod z lat 70-tych zwanych “waterfall”.
Podsumowanie
Jednym z największych kosztów projektów jest prototypowanie “na żywym ciele”, czyli rozpoczynanie pracy od razu na kodzie. Etap analizy i projektowania z użyciem UML jest co najmniej o rząd wielkości tańszy. Opracowanie powyższego modelu przez osobę mającą doświadczenie i dobre narzędzie (ja używam Visual Paradigm) zajmuje ok. godziny (to jest oczywiście poprzedzone analizą biznesową czyli określono i zrozumiano problem).
Diagramy aktywności doskonale się sprawdzają na etapie poprzedzającym opracowanie detali (diagram sekwencji). Można opracować, przetestować i skonsultować koncepcję realizacji usługi (pomysł), bez straty czasu na bardziej wymagający diagram sekwencji.
Po drugie diagram aktywności w opisanej tu postaci, jest tworzony (etykiety) z użyciem języka naturalnego (co bardzo polecam), dzięki czemu sponsor projektu i interesariusze, są w stanie aktywnie uczestniczyć nawet na tym etapie projektu, co znakomicie usprawnia proces zgłaszania uwag, zanim dojdziemy do najkosztowniejszego etapu czyli do zaangażowania programistów.
Stosowanie schematów blokowych jak wyżej, prowadzi do powstania bardzo precyzyjnej specyfikacji. Nie raz już wykazano, że opisy wymagań wykonane językiem naturalnym bez sformalizowanych schematów blokowych, tak zwane historyjki użytkownika czy wymagania pisane językiem naturalnym, są tak bardzo niejednoznaczne, że są uznawane za jedną z kluczowych przyczyn porażek projektów informatycznych .
Projekt udokumentowany powyższymi metodami stanowi precyzyjny logiczny opis, jest to Opis Techniczny Oprogramowania. Taki dokument jest chroniony prawem autorskim, jego treść to logika biznesowa, czyli precyzyjnie opisane know-how sponsora projektu. Developer tworzący implementację na podstawie takiej dokumentacji, tworzy utwór zależny, co znaczy, że ma autorskie prawa osobiste do napisanego kodu, ale nie ma prawa do dysponowania nim. Innymi słowy w umowie zwykłą formalnością jest to, że programista w ramach wynagrodzenia pokrywającego koszt powstania kodu, przekazuje prawa majątkowe do niego (albo po prostu nie dostanie tego zlecenia, patrz także artykuł Ochrona wartości intelektualnych i know-how w organizacji).
Polecam także opis z przykładami (PDF dostępny dla użytkownik Premium):
Diagramy aktywności.
– Kiedy używamy action, kiedy activity (i ich typy).
– Parametry przekazywanie obiektów,
– sygnały przerwania, itp.
Dodatkowo czy diagram aktywności ma pokazywać algorytm metody
jednej klasy czy wszystkich, które są w łańcuchu odpowiedzialności.
W Specyfikacji OMG UML z 2017 roku jest zapis: “Activities may be applied to organizational modeling for business process engineering and workflow.” Jak się to ma do tezy, że nie modelujemy już procesów biznesowych diagramem aktywności? Kto taką tezę propaguje?
W dodatku, każdy ma prawo modelować czym potrafi oraz przy użyciu takich diagramów, jakie są zrozumiałe dla odbiorcy. Tak więc moc takiego “zalecenia” byłaby adekwatna do potencjalnie ogłoszonego zalecenia “nie chodzimy już w klapkach, chodzimy w sandałach”…
Ten zapis jest wyjęty z kontekstu, cały UML jest obecnie wyłącznie notacją do modelowania oprogramowania. Cały ten akapit brzmi:
“An Activity is a kind of Behavior (see sub clause 13.2) that is specified as a graph of nodes interconnected by edges. A
subset of the nodes are executable nodes that embody lower-level steps in the overall Activity. Object nodes hold data
that is input to and output from executable nodes, and moves across object flow edges. Control nodes specify
sequencing of executable nodes via control flow edges. Activities are essentially what are commonly called ?control and
data flow? models. Such models of computation are inherently concurrent, as any sequencing of activity node execution
is modeled explicitly by activity edges, and no ordering is mandated for any computation not explicitly sequenced.
Activities may describe procedural computation, forming hierarchies of Activities invoking other Activities, or, in an
object-oriented model, they may be invoked indirectly as methods bound to Operations that are directly invoked.”
Specyfikację intepretujemy w całości, a nie fragmentami.
“W dodatku, każdy ma prawo modelować czym potrafi oraz przy użyciu takich diagramów, jakie są zrozumiałe dla odbiorcy. Tak więc moc takiego ?zalecenia? byłaby adekwatna do potencjalnie ogłoszonego zalecenia ?nie chodzimy już w klapkach, chodzimy w sandałach??”
Notacje formalne nie służą do umawiania się z odbiorcami bo same z siebie są umową, tak jak Kodeks Drogowy: jest identyczny dla każdego a nie “jak my się umawiamy z innymi kierowcami”. Po to OMG standaryzuje notacje by “nie umawiać się z odbiorcami”. Po drogach jeździmy tak jak każe Kodeks Drogowy a nie “tak jak potrafimy”.
Notacje mają taki sam status jak Normy, więc jeżeli audytor spornej dokumentacji stwierdzi w niej niezgodności ze specyfikacją, ma prawa uznać dokumentacją za wadliwą.
Zacytuje jednego z członków OMG: UML to nie kolejna biblioteka symboli PowerPoint.
Zdanie które zacytowałam również jest w tej specyfikacji i jak je w takim razie należy rozumieć?
Gdyby nawet notowanie procesów było zabronione za pomocą UML, to i tak będzie to prawo martwe… jak to się w przyrodzie z przepisami zdarza. Oczywiście można modelować procesy w idealnej do tego notacji (BPMN), tylko z uwagi na jej skomplikowanie, diagram może być niezrozumiały dla odbiorcy. Powstaną idealne, skomplikowane i … nikomu niepotrzebne diagramy (czego sama była świadkiem w praktyce). To notacja ma służyć człowiekowi, a nie człowiek notacji.
“Gdyby nawet notowanie procesów było zabronione za pomocą UML, to i tak będzie to prawo martwe?”
Nie jest i nigdy nie było zabronione, w OMG nikt niczego nie zabrania.
Wszystkie symbole BPMN z ich opisem to rozdz. 7. specyfikacji, zajmujący łącznie 28 stron. Rozdziały specyfikacji UML: 15.Action i 16.Activities, zajmują łącznie 192 strony. Nadal Pani uważa, że dla odbiorcy BPMN jest bardziej skomplikowany i trudniejszy niż diagramy aktywności UML?
Żebyśmy się dobrze zrozumieli: mówię o rzeczywistości i praktycznym wieloletnim doświadczeniu i obserwacji w pracy nad diagamami z klientami. Nie ma tutaj znaczenia to, co ja “uważam”, co jest dla mnie wygodniejsze, co bardziej lubię, czy jak bym sobie życzyła. Diagram aktywności jest prosty w odbiorze i intuicyjnie rozumiany. W przypadku złożonych procesów, gdzie konieczne są pewne detale – bardziej adekwatny jest BPMN ale powstaje bariera zrozumienia.
Ponownie proszę o odpowiedź na pytanie, jak rozumieć to zdanie ze Specyfikacji OMG w zestawieniu z Pana twierdzeniem, iż modelowanie procesów diagramem aktywności jest niezgodne ze specyfikacją : ?Activities may be applied to organizational modeling for business process engineering and workflow.?
Jeżeli rozmawiamy o doświadczeniu, to łamanie norm jest jest jedną z głównych przyczyn porażek projektów. Gdyby diagramy UML były “łatwe dla biznesu” BPMN by nigdy nie powstał, bo po co…
“Ponownie proszę o odpowiedź na pytanie, jak rozumieć to zdanie ze Specyfikacji OMG w zestawieniu z Pana twierdzeniem, iż modelowanie procesów diagramem aktywności jest niezgodne ze specyfikacją : ?Activities may be applied to organizational modeling for business process engineering and workflow.?”
Odpowiedź w akapitach poprzedzających ten, który Pani cytuje. a także w następnych:
“15.2 Activities
15.2.1 Summary
An Activity is a Behavior specified as sequencing of subordinate units, using a control and data flow model.”
A także tu;
“15.2.3 Semantics
15.2.3.1 Activities
The execution of one ActivityNode within an Activity may affect, and may be affected by, the execution of other
ActivityNodes in the Activity. Such edges are represented by ActivityEdges that interconnect the ActivityNodes. The
effect of one ActivityNode on another is specified by the flow of tokens over the ActivityEdges between the
ActivityNodes.”
Generalnie Aktywności reprezentują wykonywalne elementy kodu, a Czynności pozwalają modelować ich szczegóły.
Bo UML (obecnie) służy tylko do modelowania systemów (modele PIM), a także do modelowania wykonywalnego kodu (modele PSM). Owszem zaszłości miał “szersze” (UML powstał w latach 90-tych jako zlepek 3. notacji) ale mamy już rok 2021 i ogromne “porządki” w specyfikacji w roku 2015.
Niestety EA firmy SPARX to relikt czasów początku UML (od lat są na runku znacznie lepsze produkty). Jego popularność to efekt tego, że jest stary, a nie tego że jest dobry.
Sparx Systems (A Contributing Member of the Object Management Group (OMG)) w Specyfikacji EA z lipca tego roku również nie odżegnuje się od diagramów aktywności dla celów modelowania procesów biznesowych. Opisując Activity podaje: “An Activity organizes and specifies the participation of subordinate behaviors, such as sub-Activities or Actions, to reflect the control and data flow of a process. Activities are used in Activity diagrams for various modeling purposes, from procedural-type application development for system design, to business process modeling of organizational structures or workflow.”
Sparx proponuje też zastosowanie uproszczonego diagramu aktywności dla celów modelowania procesu biznesowego: “You can create Analysis diagrams (Simplified Activity diagrams) containing the elements most useful for business process modeling, using the ‘New Diagram’ dialog”.
Proszę również spojrzeć na przykład, który Sparx zamieścił jako ilustrację zastosowania diagramu aktywności (https://sparxsystems.com/resources/user-guides/15.2/model-domains/uml-models.pdf str. 32): czymże jest obszar ‘Contact Sales Staff’ na tym diagramie, jeśli nie procesem biznesowym?
Produkt firmy SPARX (EA) ma poważne problemy z kompatybilnością z UML/XMI a ich publikacje nie są normami.
Artykuł uzupełniono o statystykę pojęć UML i BPMN w literaturze.
Więcej o diagramach aktywności: https://jaroslawzelinski.biz/asp-products/diagramy-aktywnosci/