Czy reguła biznesowa to wymaganie?

Wielokrotnie spotkałem się z sytuacjami, w których reguły biznesowe oraz wymagania wobec IT były traktowane jako różne rodzaje tej samej koncepcji. A to niedobrze, gdyż z wielu powodów nie powinno się tych pojęć tak traktować, jako że prowadzi to do…o czym poniżej.

Definicji reguł biznesowych jest całkiem sporo. Co ciekawe, nawet wśród tych samych autorów, definicje zmieniają się z czasem. Mi najbardziej odpowiada ta, zaproponowana przez Business Rules Group.

Business Rule is a directive that is intended to influence or guide business behavior. 

Business Rules Group, 1998

Definicja wyraźnie wskazuje, że celem specyfikowania reguł biznesowych jest jawne określenie zasad, które powinny być brane pod uwagę podczas prowadzenia działań biznesowych. Rozpatrując reguły biznesowe z punktu widzenia siatki Zachmana, należy uznać, iż stanowią element drugiej z perspektyw, na równi z modelem pojęć, czy modelem przebiegów procesów biznesowych.

Spróbujmy przeanalizować zależności łączące reguły biznesowe z innymi aspektami architektury biznesowej, w tym architektury IT. Załóżmy, że zajmujemy się tematem zakładania rachunku bankowego w instytucji finansowej. Hipotetycznie, możemy przyjąć, że o założenie rachunku bankowego może wnioskować tylko osoba pełnoletnia. Aby to założenie biznesowe zapisać w terminach reguł biznesowych, posłużymy się stylistyką RuleSpeak. Reguła mogłaby wówczas przyjąć brzmienie:

Wniosek o założnie rachunku bankowego MOŻE złożyć TYLKO osoba, która jest pełnoletnia.

Co taka reguła oznacza z punktu widzenia architektury biznesowej. Po pierwsze, mamy tutaj odwołania do dwóch pojęć oraz jednego faktu je łączącego. Pojęcia to Wniosek o założenie rachunku bankowego oraz Osoba. Fakt, to składa. Dbając o porządek w repozytorium architektury biznesowej, powinniśmy mieć odnotowane te zależności, co mogłoby przyjąć następującą postać.

Przykładowy model pojęć
Rysunek 2 Reguła biznesowa odwołująca się do modelu pojęć

Niektóre narzędzia służące do tworzenia modeli architektury biznesowej automatycznie rozpoznają, czy we wprowadzanej treści reguły biznesowej znajdują się odwołania do modelu pojęć i łączą zidentyfikowane frazy z pojęciami. Przykłd tego typu funkcjonalności dostępnej w narzędziu Visual Paradigm prezentuje Rysunek 2.

Mając już regułę biznesową opartą o model pojęć, możemy zastanowić się, co w praktyce mogłaby oznaczać część definicji reguły biznesowej, nawiązująca do jej wpływu na działania biznesowe. Spójrzmy najpierw na jeden z najbardziej typowych elementów architektury biznesowej – modele procesów biznesowych. Zwykle prezentują one działania realizowane przez ich uczestników oraz kolejność realizacji działań. Dla przykładu, Rysunek 3 prezentuje początek hipotetycznego procesu biznesowego, mającego na celu założenie rachunku bankowego. Proces jest inicjowany przedłożeniem przez osobę wnioskującą wypełnionego wniosku. Pracownik Biura Obsługi Klienta następnie weryfikuje ten wniosek i jeśli wszystko jest poprawnie wypełnione przekazuje go do dalszej realizacji. Zakładając na początek, że nie posiłkuje się tutaj żadnym systemem, obowiązkiem pracownika będzie zdobycie kompetencji pozwalających na pełną weryfikację wniosku. Między innymi pod kątem pełnoletniości.

Jak można byłoby zinterpretować to z punktu widzenia tworzonego modelu? Na przykład, tak jak na poniższym rysunku – możemy uznać, iż wprowadzona przez nas reguła biznesowa powinna być powiązana z tym krokiem procesu, gdyż w jego ramach może zostać … złamana. Wprawdzie reguły istnieją niezależnie od kroków procesów, aczkolwiek warto je łączyć tylko z tymi, w których mają jakiekolwiek znaczenie.

Rysunek 3 Reguła biznesowa powiązana z krokiem procesu biznesowego

A co w sytuacji, gdybyśmy wraz z planowaniem nowego przebiegu procesu zamierzali wdrożyć system informatyczny, który wesprze pracę uczestników procesu? Musielibyśmy jakoś umieć wkomponować w powstający, docelowy model funkcjonowania organizacji oczekiwania wobec IT. W metodyce AION, pierwszy etapem specyfikowania tego typu wymagań, jest ich zogniskowanie wokół tych kroków procesu, które wymagają wsparcia. Rysunek 4 prezentuje diagram wymagań, zgodny z podejściem AION dla omawianego przykładu. Na bazie kroku biznesowego, w którym miałaby nastąpić rejestracja wniosku w systemie, zdefiniowane zostało wymaganie dotyczące konieczności weryfikacji wniosku względem reguł biznesowych. Warto zwrócić uwagę, iż w treści wymaganie nie zostały wprowadzone warunki, względem których wniosek należy zweryfikować. Zamiast takiego zabiegu (wprowadzałby on redundancje informacji do modelu), wprowadzono zależność łączącą wymaganie z istniejącą regułą biznesową. Gdyby reguł było więcej, w dalszym ciągu pozostałoby jedno wymaganie, które byłoby skojarzone z większa liczbą reguł biznesowych. Tak wyspecyfikowane wymaganie jest następnie powiązane relacją <<satisfy>> z przypadkiem użycia, który w analizie systemowej będzie prezentował sposób realizacji wymagania. Oczywiście, aby przykład był kompletny, do modelu powinno się wprowadzić więcej wymagań związanych z krokiem. W przypadku niniejszego wpisu koncentrujemy się jednakże jedynie na zależnościach pomiędzy wymaganiem a regułą biznesową, więc uzupełnianie nie wydaje się być konieczne.

Rysunek 4 Diagram wymagań prezentujący zależności pomiędzy elementami architektury biznesowej oraz systemowej w omawianym przykładzie
Rysunek 5 Diagram przypadków użycia dla omawianego przykładu

Jak należałoby rozszerzyć model, gdyby się okazało, iż funkcjonalność związaną z wprowadzaniem wniosku chcielibyśmy udostępnić w kanałach elektronicznych, przerzucając ciężar prac z pracownika BOK na Klienta instytucji? Z pewnością należałoby uzupełnić model procesów o scenariusz, w którym Klient wykorzystuje dobrodziejstwa IT, dzięki czemu w procesie nie występuje już Pracownik BOK. Zapewne, w dalszym ciągu obowiązek pełnoletności powinien być spełniony, więc, wykorzystamy już istniejącą regułę biznesową do tego, by skojarzyć ją z nowym krokiem biznesowym. Wyprowadzając z kroku wymagania dla nowego systemu, zdefiniujemy nowe wymaganie do weryfikacji, ale powiążemy je z istniejąca regułą, gdyż ona się nie zmieniła. Dzięki takim zabiegom, mamy jedną regułę biznesową i wiele miejsc w modelu, które się w różnych kontekstach do niej odwołują. Utrzymywanie powiązań pomiędzy elemenatmi w modelu znacząco ułatwi analizę wpływu zmiany reguły biznesowej na architekturę biznesową i IT.

Czy reguły biznesowe to wymagania? Nie. Czy są z nimi związane? Mogą być.

Od historyjek do epików wstępująco (ang. bottom-up)

Moda na Edżajl trwa i na razie nic nie zwiastuje rychłego zakończenia trendu. Jednym z tego efektów jest konieczność wpisania elementów procesów wytwórczych opartych o bardziej zaawansowane narzędzia w proste elementy skramomopochodne. Oczywiście, przed takimi wyzwaniami (ponieważ rzecz dzieje się w korporacji, więc o problemach nie ma mowy) i mi przychodzi stawać. I stąd niniejszy wpis.

W stosowanym od lat podejściu, usprawnienie określonego obszaru biznesowego zwykle skutkuje powstaniem obrazu docelowego procesu biznesowego. W zależności od sytuacji, może to być zarówno duża reorganizacja procesów, jak i drobna ich modyfikacja. Efekt, z analitycznego punktu widzenia, jest we wszystkich przypadkach taki sami – powstaje komplet – procesy biznesowe oraz stojący za nimi aparat pojęciowy (model pojęć).

Jeżeli w ślad za zmianami w procesach podążać mają zmiany w rozwiązaniach IT, model jest uzupełniany o kolejny wymiar – oczekiwania wobec funkcjonalności IT zdefiniowane w kontekście poszczególnych kroków procesu. Dlaczego tak? Uzasadnieniem dla takiego podejścia jest chęć uniknięcia wymagań precyzowanych w bliżej nieokreślonym kontekście (często na wyrost). Bazując na krokach, rozważamy konkretny, nieduży zakres procesu i tym samym, co pozwoli na łatwiejsze uzasadnienie istnienia wymagania i korzyści z niego wynikających. Technicznie, technika skutkuje powstaniem diagramu wymagań, na którym z krokiem skojarzone są wymagania. W przypadku języka SysML, diagram taki mógłby wyglądać, jak poniżej.

Diagram wymagań ilustrujący koncepcję łączenia kroków w procesie i wymagań

Jak widać, definicja wymagań może nawiązywać do proponowanej stylistyki historyjkowej, nie tracąc nic na swojej mocy. Wprawdzie fragment JAKO nazwa roli jest redundantny i jest powieleniem relacji krok procesu – tor reprezentujący rolę, na której się znajduje, ale przy dostatecznej stabilności przebiegu procesu, redundancja nie powinna sprawiać problemu.

Zwykle, po wykonaniu tych działań, kolejnym elementem procesu wytwórczego jest powiązanie wymagań z opisem funkcjonalności systemów, które będą uczestniczyły w ich realizacji (np. przypadki użycia, usługi, itp.). W przypadku podejścia edżajlowego, wymagane jest jednakże zgrupowanie wymagań w kategorie, nazywane epikami. Z punktu widzenia procesu wytwórczego opartego o modele jest to krok zbędny, ale oczekiwania procesu edżajlowego są w tym momencie bezwzględne – historyjka musi być elementem epiku.

Epik to element grupujący. Kryteria grupowania są subiektywne. Pojawia się więc pytanie – jak zgrupować wymagania w zbiory? Ponieważ takie podejście, jakie proponuję jest jakby wbrew zstępującemu procesowi edżajlowemu (najpierw epiki, potem historyjki), więc wskazówek w edżajlowych bazach wiedzy nie znalazłem. Ale, z pomocą przychodzi znana od dziesiątek lat technika diagramu podobieństw (ang. affinity diagram). Wykorzystajmy ją wprost. Bez jakichkolwiek modyfikacji. Uzyskamy pożądane epiki. Jeśli ktoś nie zna techniki – załączam odnośnik do krótkiego wykładu na Jutjub.

Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

OCeeL, teoretyczna teoria, czy praktyczna praktyka?

Zupełnie niespodziewanie przeprowadziłem dzisiaj ponad godzinną rozmowę ze studentem podejmującym decyzję o temacie pracy magisterskiej. Pytanie, z jakim zadzwonił, można streścić jednym zdaniem Czy OCL to już odległa historia, czy coś, czym warto się jeszcze zająć? Ponieważ dziś sobota, więc nie spodziewałem się telefonu w takiej sprawie, ale doszedłszy do siebie, już chciałem odpowiedzieć, że jak to historia? , ale powstrzymałem się i zapytałem a skąd pytanie? Odpowiedź była do przewidzenia – wszyscy mówią, że to czysta teoria i tak nikt nie pracuje.

To jak się pracuje?

Takim pytaniem postanowiłem podrążyć temat. I usłyszałem, że po pierwsze, OCL to już programowanie, po drugie, bez sensu jest dokumentować każdą linijkę kodu, i po trzecie, dlaczego analityk ma narzucać programiście, co ma robić.

OCL to już programowanie

Tak może powiedzieć tylko ktoś, kto nie ma pojęcia, czym jest OCL. Wytłumaczywszy studentowi, że OCL ma się tak do programowania, jak wzór w Wordzie do zapisów w silniku reguł biznesowych, usłyszałem – o dziwo – odpowiedź tak mi się wydawało.

Dokumentowanie a analiza

Na temat tego typu sformułowań można byłoby książkę napisać. Analiza to nie dokumentowanie! Analiza to proces tworzenia koncepcji rozwiązania. To co pozostaje po wykonanej analizie, można nazwać dokumentacją, ale jest to poniekąd efekt uboczny a nie cel. Tutaj student poprosił o wyjaśnienia, ale na koniec stwierdził, że rozumie (a dokładniej, zakminił).

Wpływ na programistę

Dlaczego analityk ma narzucać programiście, co ma robić? Hmmm…dlatego, że taka jego rola. Odpowiedzialnością analityka jest doprowadzenie do powstania koncepcji rozwiązania. W tym celu musi komunikować się z szeroko pojętym zestawem interesariuszy. W ich skład wchodzi zarówno tak zwana strona biznesowa jak i technologiczna, z programistami włącznie. Nie zmienia to faktu, że to analityk jest odpowiedzialny za stworzenie koncepcji. Ta koncepcja jest następnie przekazywana do zaprogramowania. Bez narzucania metod, ale z narzuceniem celu.

Ale przecież programista może stwierdzić, że można to zrobić lepiej! Oczywiście, że może. Ale to analityk powinien finalnie potwierdzić koncepcję. Zdanie programisty, to zdanie jednego z interesariuszy. Analityk musi uwzględnić zdanie wszystkich, którzy mają wpływ. I dokonywać korekt każdoroazowo, gdy taka konieczność nastąpi. Czyli do samego końca procesu produkcyjnego.

Ten temat zajął nam najwięcej czasu. Mam jednakże wrażenie, że rozmówca ostatecznie zrozumiał znaczenie OCL w całym procesie wytwórczym. Zresztą, nie tylko OCL. 

Ale dlaczego warto pisać o takiej rozmowie?

Kto poddał w wątpliwość?

To jest powód powstania niniejszego wpisu. Wątpliwość bowiem podniósł opiekun przyszłej pracy. Pracownik naukowy. Osoba, która powinna rozumieć. Poszerzać horyzonty studentów. Inspirować. Nie poddawać się modom. 

To był jakiś dzban (tak się chyba teraz mówi o osobach, które nie w pełni rozumieją, co mówią), pomyślałem. Zaproponowałem, aby student jeszcze raz porozmawiał z opiekunem i wyjaśnił powody dla których chciałby się zająć OCeeLem.

Niesmak pozostał. A wraz z nim pytanie dokąd zmierza świat naukowy?


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Architektura mikrousługowa a analiza systemowa

mikrousługi.jpgAby jakoś zrównoważyć narzekania na korporacyjnego edżajla, drugi dzisiejszy wpis będzie bardziej inżynierski. Ostatnimi czasy mam okazję pracować nad systemami o architekturze mikrousługowej. Oczywiście jako analityk. I z tego analitycznego punktu widzenia, można powiedzieć, że architektura, jak architektura, za jednym wyjątkiem. Wydaje się bowiem, iż w przypadku tej konkretnej architektury, mniejszego znaczenia nabiera klasyk analizy, czyli analityczny model danych, rozumiany jako jednolita struktura opisująca dane, jakimi należy się posługiwać, aby można było zrealizować deklarowane funkcjonalności systemu.

Dlaczego? O tym będzie poniższy wpis.

Usługa

Mikrousługa, z analitycznego punktu widzenia, to usługa jak każda inna. Powinna mieć opisane zachowanie (jak realizuje kontrakt) oraz strukturę danych wejściowych (żądanie) i wyjściowych (odpowiedź). Koncepcyjnie (realizacja może wyglądać różnie w zależności od narzędzia do modelowania, metodyki i wynikających z niej standardów poziomu szczegółowości opisu), model usługi powinien zawierać powiązane ze sobą elementy przedstawione na rysunku poniżej.

Struktura opisu mikrousługi

Struktura opisu mikrousługi

Klient usługi

Załóżmy dla uproszczenia, że analityczną warstwą kliencką usługi będzie klasyczny przypadek użycia. Przebieg realizacji przypadku użycia, będzie zapewne opisany diagramem aktywności lub sekwencji (specyfika stosowanej metodyki). Bez względu na rodzaj diagramu, w momentach, w których zaistnieje zapotrzebowanie na dane, wymagane będzie odwołanie do usługi. Przykład takiej sytuacji prezentuje poniższy rysunek.

Wywołanie mikrousługi z przebiegu przypadku użycia

Wywołanie mikrousługi z przebiegu przypadku użycia

Moment wywołania usługi jest reprezentowany stosowną akcją, która w rożnych narzędziach do modelowania będzie troszkę inaczej wyglądała. Teoretycznie, na pinie wejściowym powinny się znaleźć dane zgodne co do typu z typem REQUEST z modelu opisu usługi. Pin wyjściowy jest zgodny, co do typu, z RESPONSE z modelu opisu usługi. Problem z pinem wejściowym zgodnym z teorią byłby taki, że należałoby albo dodać osobną akcję, która tworzy strukturę żądania na bazie dostępnych danych, albo transformację na przepływie danych, która dokonałaby przekształceń. W naszym podejściu stosujemy delikatne obejście – aby nie komplikować przejść i nie rozbudowywać diagramu o dodatkowe akcje, przypisanie danych pod cechy żądania opisujemy jako pre-condition w akcji wywołania usługi. W języku OCL przyjmuje to następującą postać.

pre:

let req: REQUEST.oclInNew() and
req.cecha1 = daneWejścioweAkcji.cechaA and 
...

Wynik wywołania usługi jest dostępny w pinie wyjściowym akcji. Tak pozyskane dane mogą być wykorzystywane w ramach przypadku użycia. Dostęp do nowych danych wymaga analogicznego wywołania kolejnej usługi.

Specyficzną cechą tego podejścia jest fakt, iż jeśli nawet w różnych usługach zwracamy logicznie te same dane, to faktycznie są one tylko takie same, gdyż znajdują się w różnych obiektach, czy strukturach danych. Specyfika ta powoduje, iż jeden logiczny model danych dla tego typu aplikacji aplikacji byłby tworem czysto abstrakcyjnym, którego zakresem zastosowań byłby jedynie model. Co więcej, odwoływanie się do niego w ramach przebiegów przypadków użycia byłoby okupione dużym wysiłkiem wynikającym z konieczności wiązania danych z mikrousług z jednolitym modelem danych.

Tego typu sytuacja nie ma zwykle miejsca w tradycyjnych, nazwijmy to, architekturach, w których aplikacja składa się z własnego frontendu i własnych danych. W takim kontekście, model danych służy zwykle jako punkt wyjścia dla konstrukcji modelu trwałego (najczęściej relacyjnej bazy danych), czy też, po konwersji do formatu XMI, jako wsad do tworzenia plików mapujących narzędzi OR-mapping. Z modelu logicznego można także generować skryptami MDA fragmenty docelowego kodu źródłowego, w szczególności deklaracje klas, konstruktory, destruktory oraz operacje trawersujące asocjacje.

Nie mając tego typu korzyści, wydaje się, że nie warto inwestować pracy w czysto abstrakcyjną warstwę opisu. Coś oczywiście tracimy, ale zyskujemy bezcenny czas.

 

 

Ilustracja: https://pl.freepik.com/darmowe-zdjecie/abstrakcyjne-geometrycznej-tła-z-futurystyczne-projektu_1104905.htm Designed by Kjpargeter


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Model informacyjny w systemach klasy frontend

Frontend XSPrzez ostatnich kilka miesięcy mam okazję uczestniczyć w analizie biznesowej oraz systemowej systemu klasy frontend. Z jednej strony, system jak system, z drugiej, to co w nim wydaje się ciekawe to model danych. Oczywiście, z punktu widzenia języka specyfikacji, w dalszym ciągu jest to stary, dobry, sprawdzony diagram klas języka UML. Natomiast, to co w nim najciekawsze, to liczności.

Ale po kolei. Systemy omawianej kategorii sporą część danych prezentowanych na ekranach czerpią z innych systemów korzystając najczęściej z dedykowanych interfejsów. Różne funkcjonalności, mogą nieść ze sobą wymagania na określone dane, także w ramach jednej klasy. Dla przykładu, załóżmy, że w momencie wprowadzania wniosku o wydanie duplikatu prawa jazdy, osoba wprowadzająca wniosek ma za zadanie podanie swojego numeru PESEL, na podstawie którego system frontend, o hipotetycznej nazwie System Obsługi Dokumentów Drogowych (SODODRO), wysyła żądanie do Systemu Ewidencji Obywateli (SEO) i pobranie podstawowych danych o osobie, na które składają się imię, nazwisko, data urodzenia i miejsce zamieszkania. Przykładowa definicja klasy mogłaby wyglądać, jak poniżej.

klasy1

Podstawowe dane Obywatela

Takie dane są prezentowane osobie składającej wniosek, która po potwierdzeniu ich poprawności otrzymuje możliwość podania powodu ubiegania się o wystawienie duplikatu. Jednocześnie, dane te zostają przepisane do wniosku, stając się jego integralną częścią. W momencie kierowania wniosku do realizacji, odnotowywany jest moment jego złożenia oraz nadawany jest unikalny identyfikator wniosku. Przykładowy diagram klas systemu SODORO dla opisywanej sytuacji przedstawia poniższy rysunek.

 

klasy2

Model klas dla funkcjonalności składania wniosku

Wniosek jest zapisywany w systemie SOW (System Obsługi Wniosków) poprzez usługę zapiszWniosek. System SODORO musi przekształcić dane do struktury danych wejściowych usługi, co jest już odzwierciedlane w przebiegu przypadku użycia (jeżeli ta technika jest stosowana do opisu funkcjonalności systemu).

Inna funkcjonalność systemu SODORO, pozwala na wyświetlenie wszystkich wniosków złożonych przez określonego obywatela. W efekcie wywołania tej funkcjonalności, system SODORO wywołuje usługę dajWnioskiObywatela systemu SOW i w efekcie otrzymuje kolekcję wniosków, opisanych cechami: moment złożenia, identyfikator wniosku. Oznacza to, iż model informacyjny systemu musi uwzględnić fakt, iż w niektórych sytuacjach dane wniosku będą zubożone w stosunku do jego pełnej zawartości informacyjnej, co musi skutkować jawnym wprowadzeniem opcjonalności w modelu klas.  Atrybutom imię składającego, nazwisko składającego, data urodzenia składającego, PESEL składającego oraz miejsce zamieszkania składającego przypisano liczności [0..1]. Podobny zabieg został zastosowany dla roli składający asocjacji składa. Co więcej, w związku z faktem, iż dane wniosku są odczytywane bez kontekstu obywatela go składającego, należy usunąć znacznik wnioskowalności atrybutów. Przykład takiej modyfikacji przedstawia poniższy rysunek.

klasy3

Osłabione liczności w modelu klas

Wraz ze wzrostem opisywanej funkcjonalności może następować dalsze osłabianie wymagalności poszczególnych cech klas oraz końców asocjacji łączących klasy. Docelowy model, może więc teoretycznie przyjąć formę diagramu, w którym zdecydowana większość właściwości klas jest opcjonalna, dzięki czemu model stanie się adekwatny do kontekstu pojedynczych funkcjonalności.

Sytuacja taka może sprowokować pytanie, jaka jest wartość takiego modelu? Czy nie lepiej byłoby tworzyć modele pod pojedyncze funkcjonalności, i uznać, iż nie ma czegoś takiego jak jednolity model informacyjny systemu klasy frontend? Przyznam, że sam miałem jakiś czas temu takie dylematy, ale na chwilę obecną stwierdzam, iż model taki ma sens. Po pierwsze, prezentuje on spójny obraz tego, czego można się spodziewać po posiadanych danych. Po drugie, pozwala on na unifikację danych wykorzystywanych przez system frontend, niezależnie od tego, skąd te dane są zaczytywane (oczywiście, pod warunkiem, że można przekształcić dane z systemów źródłowych do struktury systemu frontend). A gdyby tak przyglądnąć się modelowi z punktu widzenia narzędzi integracyjnych, czy BPMS, można byłoby dojść do wniosku, że jest to nic innego, jak model kanoniczny. A takowy przecież sens ma.

Prace analityczne trwają, więc być może mój pogląd na sprawę się zmieni. Gdyby tak się stało, postaram się podzielić swoją opinią na powyższy temat ponownie.

A przed zakończeniem…

P.S. Sposób odnotowywania zapisu wniosku

Przebiegi przypadków użycia, w ramach których m.in. następują wywołania do systemów zewnętrznych, są opisywane w metodyce AION diagramami aktywności, w których odwołanie do współdzielonej funkcjonalności (zachowania, w terminologii UML) jest reprezentowane akcją wywołania zachowania (ang. call behavior action).  Sytuacje wywoływania usług zewnętrznych systemów doczekały się w metodyce wzorca analitycznego, na który składa się przede wszystkim aktywność zawierająca dwuetapowe wywołanie. Strukturę takiej aktywności, dostosowaną do omawianego przykładu, prezentuje poniższy rysunek. Pierwsza etap, to przekształcenie informacji zapisanych w modelu informacyjnym systemu wywołującego usługę, do struktury danych wymaganej do wywołania usługi. We wzorcu etap ten reprezentuje akcja Przygotowanie danych. Precyzyjne opisanie zasad przekształcania wymaga zastosowania prostych konstrukcji języka OCL (patrz P.S. 2). Drugi etap, to wywołanie samej usługi systemu zewnętrznego, reprezentowane akcją wywołania zachowania o nazwie Wywołanie usługi. Pinem wejściowym dla tej akcji jest struktura danych będąca pinem wyjściowym wcześniejszej akcji.

activity

Opis aktywności zawierającej ciąg działań wymaganych do wywołania zewnętrznej usługi

Odwołanie do wywołania usługi zewnętrznej w przebiegach poszczególnych przypadków użycia jest reprezentowane także akcją wywołania zachowania, ale w tym przypadku wywoływana jest aktywność opisana omówionym wzorcem. Przykład wywołania prezentuje poniższy rysunek.

 

use case flow

Wywołanie wzorca wywołania usługi z przebiegu przypadku użycia

 

P.S. 2 Sposób przygotowania wyrażenia OCL transformującego dane z modelu informacyjnego aplikacji frontend na struktury parametru wywołania usługi

Język OCL może znaleźć zastosowanie między innymi do jawnego pokazania konwersji danych ze struktur modelu informacyjnego systemu frontend do struktur wywołania usługi. Poniższy rysunek prezentuje przykładowe wyrażenie OCL. Pierwsza część wyrażenia, rozpoczynająca się od słowa context stanowi deklarację kontekstu definiowania ograniczenia. Kontekstem takim, zgodnie z UML, może być klasa, albo określone zachowanie. Odwołanie się do akcji jest konwencją AION, która moim zdaniem jest naturalnym rozszerzeniem koncepcji zawartych w UML.

Druga część wyrażenia, rozpoczynająca się od słowa post opisuje warunek, który musi być spełniony po zakończeniu realizacji akcji. Pierwsza linia wyrażenia  – result.oclIsNew() – wskazuje, iż elementem wyjściowym wywołania jest nowopowstały obiekt. Dalsze składowe wyrażenia pokazują zasady transformacji.

 

ocl

Przykład zastosowania OCL do jawnego pokazania konwersji struktur danych

 

 

Ilustracją wpisu jest zdjęcie pobrane z serwisu Freepik.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.