Wprowadzenie

Ukazują się różne opracowania na temat tytułowej transformacji. Jednym z takich opracowań jest tekst Transformacja Modeli Pana Piotra Carewicza z firmy 300 D&C, opublikowany w periodyku Analiza Biznesowa  Lato 2015 firmowanym przez Warszawski oddział IIBA. Pozwolę sobie na pewną polemikę z przedstawionym tam  procesem transformacji modelu procesów biznesowych BPMN na Przypadki Użycia notacji UML. Autor powołuje się na OMG.org i specyfikacje BPMN i UML. Dlatego dla porządku przytoczę kluczowe definicje.

10.3 Activities
An Activity is work that is performed within a Business Process. An Activity can be atomic or non-atomic
(compound). The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, which
allows the inclusion of re-usable Tasks and Processes in the diagram. However, a Process is not a specific graphical
object. Instead, it is a set of graphical objects. The following sub clauses will focus on the graphical objects SubProcess
and Task. Activities represent points in a Process flow where work is performed. They are the executable elements of a BPMN Process. (źr. BPMN formal 13-12-09)

Aktywność to element w procesie reprezentujący wykonaną określoną pracę. Atomowa (elementarna) aktywność to czynność w procesie, której nie dzielimy już na mniejsze elementy składowe.

18.1.3.1 Use Cases and Actors
A UseCase may apply to any number of subjects. When a UseCase applies to a subject, it specifies a set of behaviors
performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject.
A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase
specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure. These Behaviors, involving interactions between the Actors and the subject, may result in changes to the state of the subject and communications with its environment. A UseCase can include possible variations of its basic behavior, including exceptional behavior and error handling. (źr. UML 2.5 formal 13-12-09)

Przypadek użycia jest więc konkretnym zachowaniem systemu (subject) dającym jako efekt wartościowy (oczekiwany) rezultat dla aktora.

Transformacja wg. OMG

Dla dokonania jakiejkolwiek transformacji, należy przyjąć konkretną pragmatykę (kontekst) gdyż obie notacje (UML i BPMN) dają pewną swobodę jej użycia (jak widać powyższe definicje dają pewien margines swobody użycia tych symboli). Z pomocą może przyjść nam biznesowa definicja procesu  biznesowego: aktywność przekształcająca stan wejścia w stan wyjścia procesu, tworząca wartościowy produkt dla aktora (roli w procesie). Taka aktywność jest realizowana (może być) zgodnie z jakąś procedurą.  Przypadki użycia są ograniczane ich stanem początkowym i końcowym, mają aktora, mają jeden lub więcej alternatywnych scenariuszy. Warto tu zwrócić uwagę, że stan początkowy i końcowy przypadku użycia oraz wejście i wyjście elementarnego procesu biznesowego, to analogiczne – odpowiadające sobie –  pojęcia. Pojęcie “atomowy” (w literaturze spotykane słowo to także “elementarny”)  oznacza:

elementarny proces biznesowy: zadanie wykonywane przez jedna osobę, w jednym miejscu i określonym czasie, w odpowiedzi na określone zdarzenie biznesowe; zadanie to prowadzi do uzyskania mierzalnej wartości biznesowej; po jego wykonaniu dane są w spójnym stanie; (przypadki użycia powinny realizować elementarne procesy biznesowe, cytat z: UML i wzorce projektowe, Craig Larman)

Kluczowym wymaganiem dla transformacji jest zdefiniowanie pojęcia, które będzie łącznikiem (będzie transformowane z “czegoś” na “coś”, będzie wspólnym elementem w obu modelach) pomiędzy modelem procesów biznesowych a modelem przypadków użycia. Tu z pomocą przychodzi  architektura SOA. SOA to wzorzec łączący model procesów biznesowych z modem aplikacji:

Generalnie koncepcja SOA bazuje na uznaniu, że “atomowe” procesy biznesowe są wspomagane (support) pojedynczymi usługami aplikacyjnymi. Tu znowu powołamy się na OMG.org i specyfikację profilu UML jakim jest SoaML:

6.1.5 Key Concepts of Basic Services
A key concept is, of course, service. Service is defined as the delivery of value to another party, enabled by one or more capabilities. Here, the access to the service is provided using a prescribed contract and is exercised consistent with constraints and policies as specified by the service contract. A service is provided by a participant acting as the provider of the service-for use by others.

6.2.6 Business Motivation […] There are other ways of capturing requirements including use cases. A Service Contract, which is also a classifier, can realize UseCases. In this case, the actors in the use case may also be used to type roles in the service contract, or the actors may realize the same Interfaces used to type the roles. (źr. OMG SoaML, formal-12-05-10)

Tak wiec mamy przełożenie: atomowy proces w BPMN, aktywność która wraz z jej wejściem i wyjściem, jest przyporządkowywana do pojedynczej usługi aplikacyjnej reprezentowanej w UML jako przypadek użycia, który ma swój stan początkowy i końcowy. Zarówno atomowy proces jak i przypadek użycia nie są już dzielone na mniejsze elementy, bo “gradację” podziału “w dół” ogranicza to, że w toku spójnej pracy jednego człowieka (aktor) ma powstać wartościowy dla aktora rezultat (produkt). Innymi słowy atomowym procesem i zarazem przypadkiem użycia, będzie np. utworzenie faktury sprzedaży, gdyż niekompletna faktura nie stanowi żadnej wartości biznesowej. Wszelkie działania w toku tworzenia faktury są elementami scenariusza jednego przypadku użycia, a wcześniej procedury realizacji jednej aktywności tworzącej tę fakturę.

Jak więc wygląda transformacja? Tu posłużę się fragmentem strony pomocy pakietu Visual-Paradigm, jednej z niewielu aplikacji CASE zachowującej pełną zgodność ze specyfikacjami OMG:

(aplikacja Visual-Paradigm tworzy taką transformacje automatycznie dla modelu procesu).

Kilka uwag do tekstu Pana Carewicza

Diagram przypadków użycia nie jest modelem “systemowym”, jest kontraktem pomiędzy  zamawiającym oprogramowanie a jego dostawcą, stanowi specyfikację wymagań, gdzie pod pojęciem “wymaganie” rozumiemy to, jakie usługi ma to oprogramowanie oferować (do czego będzie ono wykorzystywane przez aktora):

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. (UML v.2.5)

W modelu MDA (Model Driven Architecture) diagram przypadków użycia  stanowi “pomost” pomiędzy modelem biznesowym CIM (Computation Independet Model) a modelem logiki działania i architektury PIM (Platform Independent Model). Model PIM to realizacje przypadków użycia bazujące na modelu dziedziny.

18.1.3 Semantics
18.1.3.1 Use Cases and Actors
[…] Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure. (UML v.2.5)

Kluczem jest ostatnie zdanie: przypadki użycia definiują zachowanie systemu bez odnoszenia się do jego wewnętrznej struktury. Innymi słowy model przypadków użycia nie służy do modelowania architektury (wewnętrznej struktury) oprogramowania. W UML 2.5 jawnie wydzielony trzy obszary semantyczne modelowania, które potwierdzają powyższe:

Jednak dla zachowania uniwersalności i kompatybilności wstecz zachowano w UML 2.5 pojęcia – stereotypy – <<Extend>> i <<Include>>, które  “wyjawiają” wewnętrzną strukturę aplikacji, jednak UML 2.5 zastrzega:

The specific manner in which the location of an ExtensionPoint is defined is intentionally unspecified. This is because UseCases may be specified in various formats such as natural language, tables, trees, etc. […]  The included UseCase must be available for the behavior of the including UseCase to be completely described. (UM v.2.5. R.18.1.3.)

Czyli stereotypy związku użycia dla przypadków użycia, oznaczone związkiem <<extend>> lub  <<include>>, zostały w UML 2.5 dla zachowania możliwości używania diagramów przypadków użycia i kontynuowania ich  opisu w firmie opisowej (tekst, tabele, innego formy słowne a nie graficzne). Są to reliktowe konstrukcje z czasów gdy na początku lat 90-tych powstawał UML (były to trzy odrębne notacje trzech twórców): autor diagramu przypadków użycia nie znał diagramów strukturalnych (diagramy klas, komponentów) i musiał jakoś “pokazać” elementy architektury kodu. Stosowanie tych  konstrukcji w sytuacji gdy modelem realizacji przypadków użycia będą diagramy sekwencji bazujące na modelu dziedziny (modele struktury), nie ma żadnego uzasadnienia i wprowadza zbędny zamęt i nadmierne, niczym nie uzasadnione, rozdrobnienie modelu (pomijam, że na tym etapie – umowa z zamawiającym – przedwcześnie narzuca decyzje architektoniczne).

Autor tekstu wprowadził także kolejny podział przypadków użycia (stereotypy) na “cel użytkownika”, przypadki “wspierające”, “pomocnicze”, “podfunkcje”. Niestety nie zostały one (te pojęcia) precyzyjnie zdefiniowane, wprowadzają do całej “metody” chaos pojęciowy. Z kontekstu można wywodzić, że jest to jakaś forma wyniesienia na poziom modelu przypadków użycia, poszczególnych kroków ich scenariuszy (wyszukanie zgłoszenia, zapisanie informacji o zmianie zgłoszenia do dziennika) czy wręcz (o zgrozo!) linii kodu, jednak cel tego jest niejasny, poza znaczną komplikacją diagramu, który jako kontrakt z kupującym, powinien być prosty i czytelny dla “biznesu”. Wyciąganie na poziom “usług systemu” niemalże pojedynczych linii przyszłego programu nie znajduje w moich oczach żadnego uzasadnienia (po raz kolejny przypominam, że przypadki użycia to wymagania a nie model kodu), poza tym, że przybliża taki model do produktów analizy strukturalnej z lat 80-tych (pytanie po co?).

Autor powołuje się także na notację BPMN słusznie wskazując, że do transformacji na przypadki użycia tworzymy “proces prywatny”, nie przeznaczony do wykonania (non-executable) w rozumieniu “nie tworzony w celu bezpośredniego uruchomienia” np. w jakimś “silniku procesowym”. I tu kończy się konsekwencja, gdyż zaleca stosowanie detalicznych czynności i znaczników specyficznych dla modeli wykonywalnych (oznaczenia w lewym górnym roku).  Otóż do transformacji na przypadki użycia tworzymy model CIM (OMG MDA) a tu nie “brniemy” w detaliczne szczegóły, gdyż te będą realizowane w  aplikacji. Model CIM to procesy biznesowe “computation independent model” w notacji BPMN, poziom szczegółowości modelu biznesowego CIM,  do transformacji, kończymy na wspomnianych na początku “atomowych procesach biznesowych”, to która z aktywności tych procesów stanie się wymaganiem (przypadkiem użycia aplikacji) zależy od umowy na zakres projektu i od niczego więcej. Wymóg jakoby czynności wysłania i odebrania komunikatu musiały być obligatoryjnie wydzielane wydaje się dziwny. Np. czytamy:

Send Task
A Send Task is a simple Task that is designed to send a Message to an external Participant (relative to the Process). Once the Message has been sent, the Task is completed.

skoro więc czynność wysłania komunikatu jest dedykowana do jednego zdarzenia jakim jest wysłanie komunikatu, zaś na modelu procesów biznesowych “nie-wykonywalnych” taki poziom szczegółowości nie jest niczym uzasadniony (wysłanie potwierdzenia to z reguły ostatni krok procedury a w scenariuszu przypadku użycia, ostatni krok tego scenariusza) to pomysł ten wydaje się nie mieć żadnego uzasadnienia. Po drugie “wysłanie komunikatu” odwzorowane jako przypadek użycia nie ma żadnego sensu w świetle tego czym jest przypadek użycia w UML.

Nie wiem też jak, z pomocą jakiej transformacji, Pan Carewicz uzyskał na diagramie przypadków użycia dziedziczących po sobie aktorów.

Na zakończenie

Z przykrością muszę napisać, że artykuły takie jak tekst Pana Piotra Carewicza (firma 300 D&C) wprowadzają zamęt. Nie mają, jak pokazałem, podstaw semantycznych, nie mają uzasadnienia w samych notacjach, nie raz wręcz kolidują z nimi, prowadzą do powstawania bardzo rozbudowanych i kosztownych w opracowaniu dokumentów, nie wnoszących swoją szczegółowością żadnej wartości dodanej, a użycie takiej dokumentacji jest praktycznie nie możliwe, gdyż jak widać jest ona niespójna a nadmiar szczegółów podanych na tak wczesnym etapie jak planowanie wymagań, prowadzi do bardzo dużej ilości aktualizacji w toku realizacji projektu. Zdaje sobie sprawę, że Pan Carewicz próbuje sobie jakoś poradzić z użyciem UML do metody wymiarowania oprogramowania COSMIC, której jest orędownikiem, ale moim zdaniem to jednak ślepa uliczka.

Powyższe, nie mające uzasadnienia w UML, konstrukcje, można spotkać także w materiałach publikowanych przez firmę SPARX, producenta oprogramowania Enterprise Architect. Osobiście, i nie tylko ja (np. Czas nie jest aktorem), odradzam te materiały i sugeruję jednak oryginalne specyfikacje. Samo narzędzie firmy SPARX, mimo, że bardzo tanie i popularne, niestety jest bardzo pracochłonne. Tyle w kwestii samej transformacji. Ocenę metody opisanej przez Pana Carewicza z firmy 300 D&C pozostawiam czytelnikom.

Polecam także t dwa filmiki 🙂