Niedawno pisałem o UML v.2.51 i zasygnalizowałem, że
diagram aktywności daje kontekst dla pojęć z grupy ?activities? (aktywności i czynności oraz ich syntaktyczne asocjacje), diagram klas daje kontekst dla ?klasyfikatorów strukturalnych?, itd. (Źródło: UML version 2.5 | | Jarosław Żeliński IT-Consulting)
Dzisiaj kilka słów na temat modelowania procesów biznesowych w UML.
Cztery lata temu poruszałem temat użycia UML do modelowania procesów biznesowych z użyciem modelu Eriksson-Penker’a:
Można się także dość często spotkać z definicją sześcioelementową Erikssona-Penkera ([[Eriksson-Penker Business Modeling Profile]]). Tu mamy: Powyższy model bazuje na uznaniu, że proces biznesowy: ma cel, ma specyficzne dane na wejściu, ma specyficzne dane na wyjściu, wymaga zasobów, stanowi ?wiele czynności do wykonania?, angażuje różne ?departamenty? w firmie (poziomy przepływ), tworzy jakąś wartość dla klienta (wewnętrznego lub zewnętrznego). Problem jaki ja mam z tym wzorcem to: wymaga niestandardowych pojęć w UML. Profilowanie polega na rozbudowie taksonomii znaczeń (stereotypy pokazują jakie podtypy tworzymy dla danego typu), niestety obiekt jako instancja klasy nie wytrzymuje w moich oczach definicji czegoś tak abstrakcyjnego jak cel biznesowy(<>). Symbol procesu (tak zwany pagon) także nie jest pojęciem z UML. Pojęcie Information jest tak pojemne, że w moich oczach jest workiem, który pomieści wszystko, a cechą dobrej notacji (formalnego języka, także otwartego) jest jednak wzajemne wykluczanie się definicji pojęć danej przestrzeni nazw (czyli jeżeli coś jest np. Wejściem to już nie może być Informacją), na tej zasadzie nie rozumiem też różnicy pomiędzy celem procesu a jego wyjściem albo Aktorem z Zasobem (w końcu ludzie to zasoby ludzkie). (Źródło: Czym jest Piąty element ? Audyt organizacji czyli analiza biznesowa | | Jarosław Żeliński IT-Consulting)
Generalnie więc jest to pomysł łamiący zasady notacji… (promowany przez firmą SPARX, producenta aplikacji Enterprise Architect). Dość często spotykam się z tezą, że: UML posiada bardzo istotną w kontekście praktycznego zastosowania cechę ? jest elastyczny. W zależności od potrzeby, każdemu jego elementowi może zostać nadane nowe znaczenie, tworząc tym samym nowy element możliwy do wykorzystania podczas modelowania.2 Niestety jest to bzdura. UML ma bardzo ściśle zdefiniowana semantykę. Owszem jest rozszerzalny, ale rozszerzenie notacji to nie zmiana znaczenia symboli. Teza, że „każdemu jego elementowi notacji UML może zostać nadane nowe znaczenie” to ciężka herezja (zresztą dotyczy to każdej notacji).
Popatrzmy jednak na UML, wersja 2.5 po uporządkowaniu (wcześniej też dostępne były te możliwości). Mamy w w niej dwa rodzaje pojęć modelujących „zachowania”: aktywności i czynności (zadania). Oba pojęcia używane na Diagramach Aktywności. Aktywność jest pojęciem szerszym, ogólniejszym, zadanie to elementarny krok jakiejś „procedury” (podobnie zresztą jak w BPMN). W UML pojęcie aktywności jest przeznaczone do modelowania procedur w oprogramowaniu. Może także być wykorzystywane do modelowanie procesów biznesowych w organizacjach (patrz wytłuszczenia):
15 Activities
15.1 Summary
An Activity is a kind of Behavior (see sub clause 13.2) that is specified as a graph of nodes interconnected by edges. […] 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. Activities may be applied to organizational modeling for business process engineering and workflow. In this context, events often originate from inside the system, such as the finishing of a task, but also from outside the system, such as a customer call. Activities can also be used for information system modeling to specify system level processes. […]
15.6.3.1 Activity Partitions
An ActivityPartition is a kind of ActivityGroup for identifying ActivityNodes that have some characteristics in common. ActivityPartitions can share contents. They often correspond to organizational units in a business model. They may be used to allocate characteristics or resources among the nodes of an Activity.
W UML 2.5 jawnie rozdzielono pojęcia Activities i Actions. Aktywności należy rozumieć jako procedury (abstrakcje jakichś działań), czynności zaś jako atomowe operacje (kolejne kroki procedur). Dla porównania kolejny fragment specyfikacji UML:
16 Actions
16.1 Summary
An Action is the fundamental unit of behavior specification in UML. An Action may take a set of inputs and produce a set of outputs, though either or both of these sets may be empty. Some Actions may modify the state of the system in which the Action executes. Actions are contained in Behaviors, specifically Activities (as ExecutableNodes, see Clause 15) and Interactions (see Clause 17). These Behaviors determine when Actions execute and what inputs they have. However, the abstract syntax and semantics of Actions are very dependent on Activities, because they specialize elements and semantics from Activities to accept inputs and provide outputs and to define Actions that coordinate other Actions (Structured Actions, see sub clause 16.11). In addition, the concrete syntax for Actions only appears in Activity diagrams (all the examples in this Clause use Activity notation), and some of the notation for Actions is specified in Clause 15. This Clause focuses on the syntax and semantics of Actions specifically, rather than the Behaviors that contain them, but must be read in conjunction with Clause 15.
Tak więc jeżeli chcemy „legalnie” modelować procesy biznesowe z użyciem UML, to byłby to diagram aktywności z użyciem pojęć Activities i ActivityPartitions. Procedury (i algorytmy) modelujemy z użyciem pojęcia Action. Porównując ten diagram i te pojęcia z BPMN widać wyższość tej drugiej notacji. Po pierwsze BPMN, operując pojęciami zdarzenie i bramka zdarzeniowa, doskonale daje sobie radę z modelowaniem faktów w biznesie, po drugie – jak pokazuje praktyka – semantyka i grafika BPMN jest łatwa do zrozumienia dla odbiorcy biznesowego, czego dowodzi szybki wzrost popularności BPMN wśród „ludzi biznesu” i nadal znikomy zakres stosowania UML w tej grupie.
Na koniec jeszcze jedna rzecz: kompletnie nie rozumiem używania pojęcia Przypadków Użycia UML do modelowania procesów biznesowych. Nie znajduje ono żadnego uzasadnienia w semantyce UML. W specyfikacji UML czytamy:
18 UseCases
18.1 Use Cases
18.1.1 Summary UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase?s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors. A UseCase is a specification of behavior. An instance of a UseCase refers to an occurrence of the emergent behavior that conforms to the corresponding UseCase. Such instances are often described by Interactions.
Tak więc Przypadek Użycia to WYŁĄCZNIE konkretne zachowanie (reakcja na bodziec) systemu definiowanego (specyfikowanego). Specyfikacje tych zachowań to interakcje. Ciągnące się od lat w kręgach wywodzących się z metod RUP (Rational Unified Process3) pojęcie Biznesowych Przypadków Użycia jest w moich oczach, i nie tylko, zakałą branży. Od czasu gdy powstał UML 0.9 jako jeden zestaw metod modelowania, nigdy w specyfikacji UML OMG nie było mowy o Biznesowych Przypadkach Użycia. Pojęcia te są tak samo niezgodne z UML jak wcześniej wymienione pomysły SPARX i profil Eriksson-Penker’a. Jeżeli możemy coś ze sobą porównać to elementarny proces biznesowy i przypadek użycia, ale pod jednym warunkiem: że odwzorowujemy (mapujemy) konkretny elementarny (atomowy) proces biznesowy w aplikacji na konkretny przypadek użycia, o czym pisałem w artykule o transformacji procesów biznesowych na przypadki użycia.
Tak więc stosowanie UML do modelowania procesów biznesowych jest możliwe z użyciem diagramu aktywności i pojęć activities. Stosowanie przypadków użycia UML do modelowania procesów biznesowych nie ma żadnego semantycznego uzasadnienia, co widać jak na dłoni w specyfikacji UML. Tak więc zostawmy UML do zorientowanego obiektowo modelowania systemów i BPMN do procesowo zorientowanych modeli organizacji. Obiektowe modele organizacji jak najbardziej mają sens, są to modele dziedziny modelowanej organizacji, wykorzystywane jako model logiki biznesowej w tworzeniu oprogramowania.
