Back to the roots

Close-up of two white pieces of chalk on blackboardSzkolenia i konsultacje z zakresu analizy prowadzę już ponad 20 lat. Pomijając mój debiut, w trakcie którego posługiwałem się rzutnikiem slajdów oraz wydrukami na folii, zawsze towarzyszył mi PowerPoint. Stylistyka slajdów oraz ich charakter ewoluowały wraz z trendami (a te ładnie co roku opisuje m.in. SlideShare). I wydawało mi się, że od prezentacji nie ma odwrotu (pomijając konkretne narzędzie), aż tu wpadł mi w ręce artykuł o profesorach lwowskich, ich wiedzy, pasji i umiejętności fechtowania słowem i rysunkiem, która na godziny przykuwała uwagę słuchaczy.

I pomyślałem sobie, że może warto się zmierzyć z wyzwaniem. Że może warto sprawdzić się i wyjść na szkolenie jedynie z „kredą” i pomysłem w głowie. I przed takim wyzwaniem właśnie staję. Dwa dni praktycznych warsztatów z analizy biznesowej. Proces wytwórczy na poziomach CIM i PIM, kilka języków modelowania do wprowadzenia (BPMN, UML SysML, ArchiMate), dobór jedynie tych elementów języków, które są istotne z punktu widzenia prezentowanej metodyki, rzeczywisty, szeroki problem do warsztatowych rozważań. I to wszystko tylko z kredą i tablicą we współczesnym wydaniu. Ani jednego slajdu.

Przygotowując się do warsztatów już widzę, jak ogromna to różnica w stosunku do prezentacji, która prowadzi. Kto by pomyślał, że poczuję jeszcze tak intensywny dreszczyk emocji. Już czuję, że warto.


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.

Pańskie oko w korporacji…a w zasadzie jego brak

Notebook and coffee with copy space on a wooden background. selective focus

O dawna wiadomo, że pańskie oko konia tuczy. Nie do końca jest jednak pewne, czym skutkuje pańskiego oka brak. Niniejszy wpis jest swoistą kontynuacją luźnych myśli na temat korporacji, wynikających z moich osobistych, analitycznych obserwacji.

Moje ostatnie dłuższe pobyty w korporacjach prowadzą jednakowoż do wniosku, iż brak jasno określonego Pana, który pańskim okiem swym, nastawionym na weryfikację kierunku rozwoju jego własności, powoduje, iż zarówno kierunek ten jak i tempo rozwoju mogą się zewnętrznemu obserwatorowi wydać co najmniej odbiegające od spodziewanego. Rozdrobnieni właściciele, weryfikujący skuteczność działania organizacji raportami giełdowymi, nie mający możliwości zweryfikowania w jaki sposób zarządza się ich środkami, powodują, iż w dużej mierze gospodarne zarządzanie jest efektem etyki menedżerów. A menedżerowie to przede wszystkim ludzie. Z ich ambicjami, problemami, animozjami, sympatiami, pragnieniami. Ludzie Ci stają bardzo często przed wyborami:

  • zburzyć status quo i zacząć działać inaczej (lepiej z punktu widzenia strategii organizacji), czy pozostać w układzie, który nie jest optymalny, ale stabilny,
  • podjąć ryzykowną decyzję, która może skutkować utratą pozycji, czy stabilnie iść utartym szlakiem,
  • podjąć decyzję, która pchnie firmę do przodu, czy taką, która utrudni życie wewnętrznemu rywalowi,
  • piąć się do góry, bez względu na koszty, czy zająć się działaniami w obszarze własnych kompetencji,
  • działać, czy trwać?

Dylematów różnej natury można mnożyć w nieskończoność. W nieskończoność można także mnożyć KejPIaje, KejeRaIe, którymi można w nieskończoność mierzyć skuteczność działań. Ale aby były rzetelne, potrzebne są wiarygodne dane i poprawne wyliczenia. Potrzebne są także osoby tym zainteresowane, posiadające jednocześnie zdolność do weryfikacji ich rzetelności. Gdy ich brakuje, dzieją się Rzeczy Różne.

Co to ma do analizy biznesowej? Ano to, że analiza pokazuje między innymi Różne Rzeczy. I co z  nimi robić, gdy Pańskiego oka brak?  Można robić różne rzeczy, a przy okazji narobić sobie wrogów. A korporacja będzie, niezależnie od tego, trwać.

Tu, przy okazji, dotykamy problemu etyki analityka… ale to już na osobny wpis.


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