Niedawno napisałem:

oprogramowanie reprezentuje narzędzie pracy, więc projekt tego oprogramowania raczej powinien zawierać pojęcie (klasę) Kartoteka Pracowników a nie Pracownicy. (Dlaczego nie podoba mi się klasa Pracownik?).

To stały temat wielu dyskusji z programistami. Ostatnio, po pewnym szkoleniu, w ramach wsparcia po szkoleniu jakie zawsze świadczę, znowu padło pytanie:

Czy zdarza Ci się robić analizy/projekty, gdzie byty występują pod nazwami innymi niż używanymi potocznie przez Biznes.

Z tym – używane pojęcia – jest regularnie duży problem, dlatego od pewnego czasu ortodoksyjnie stosuję budowanie “przestrzeni pojęciowej” dla projektu ([[Semantics of Business Vocabulary and Business Rules]]). Buduję słownik pojęć, listę reguł biznesowych (to nie to samo co reguły decyzyjne) oraz tak zwany diagram faktów, który służy do testowania (i dokumentowania słownika) – upewnienia się, że pojęcia nie kolidują ze sobą a ich definicje nie nakładają się na siebie oraz, że lista jest dziedzinowo kompletna. Po co to? Właśnie po to,

by żadne zdefiniowane słowo nie miało w projekcie (w wymaganiach, w kodzie) więcej niż jednego znaczenia i by znaczenie każdego zefiniowanego pojęcia nie budziło żadnych wątpliwości

(co nieco o słownikach terminów: Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć).

Jedna  uwaga na początek: jeżeli “byty” (klasy) w kodzie (projekcie) oprogramowania występują pod innymi nazwami niż w rzeczywistości, to jest to absolutna porażka, bo programista zupełnie traci kontakt z klientem i (lub) dokumentacją opisująca wymagania. Jeżeli już koniecznie programista musi ulżyć sobie w ambicji używania wyłącznie j.angielskiego w kodzie, powinien ten kod być bogato komentowany, by nie było wątpliwości jakie znacznie niesie np. nazwa klasy czy atrybutu (tym bardziej, że np. słowo name to nie tylko nazwisko…..)

 

http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
źr. http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471

Słownik pojęć (często występuje w dokumentach jako czysto polskie słowo glossariusz ;)) bywa często przedmiotem burzliwych negocjacji,  bo nie raz (a w zasadzie zawsze ;))  biznes stosuje slang, w którym to samo słowo ma różne znaczenie, zależnie od kontekstu użycia. Może to mieć sens w języku mówionym gdy pełna treść wypowiedzi daje ten kontekst, ale na poziomie analizy i projektu każde pojęcie musi mieć jedno unikalne znacznie mimo braku kontekstu (tym bardziej, że np. nazwy klas nie są elementami pełnych zdań ani opowieści :)).

Pamiętam projekt, w którym wiceprezes pewnej firmy na każde działanie takie jak nowa umowa, nowy projekt,  nowy klient, używał słowa “temat”, nikt nie miał odwagi powiedzieć mu, że nie raz nie rozumie o czym on mówi … Ja – obcy – się odważyłem 🙂 i uporządkowaliśmy to, był opór ;). Pamiętam, że dyplomatycznie poprosiłem go by zbudował hierarchię “tematów” nazywając każdy element tej hierarchii jednym lub dwoma słowami słowami i pomogło :), Słownik pojęć to negocjacje 🙂

Evans (DDD ) zapoczątkował bardzo ciekawe podejście, ono się rozwija. Co ciekawe Evans nie wymyślił idei a system wzorców DDD. Wspólny język to dwa elementy: używanie biznesowych nazw (bez skrótów) na elementy rzeczywiste i klasy w systemie, ale także używanie np. pojęcia “fabryka” przez biznes i przez developera jako “kontener” na pewien rodzaj kompetencji (wiedza o tym jak powstają pewne obiekty biznesowe).

Elementy wzorca DDD to nie tylko bloki kodu, to także elementy (klasyfikatory) wiedzy o biznesie. Faktura VAT to agregat – struktura informacji, to tylko wiedza o tym co ten dokument zawiera, ale FabrykaFaktur to odrębna wiedza o tym jak ten dokument jest tworzony. Należy świadomie udokumentować oba byty: dokument i recepta jego tworzenia. Dlaczego osobno? Bo po pierwsze wystawione faktury żyją własnym, życiem i obciążanie każdej z nich (np. tysiąc faktur miesięcznie) całą wiedza jak powstała nie ma większego sensu. Po drugie zmiana przepisów nie powinna się odbić na dokumentach już wystawionych ani dociążyć nowo powstających.

Biznes także musi zrozumieć, że ma dwa różne elementy opisu swoich działań: praca z dokumentami i tworzenie dokumentów. Jednak uznanie tego faktu to jedno, nie wierzę w to, że biznes się tego nauczy, bo nie nauczył się formalnego opisu lub modelowania procesów podczas wdrożeń ISO, jednak uważam, że biznes nie ma takiej potrzeby. Moim zdaniem od dobrego analityka nie ma ucieczki, to inna kompetencja. Nie ma ucieczki od projektantów mody mimo istnienia kobiet chcących mieć ładne sukienki i bardzo dobrych krawców. Nikt tu nikogo nie zastąpi.

 

Czy Model dziedziny ma stan?

(to część bardziej techniczna)

W kwestii czegoś takiego jak Stan Modelu w MVC (czy model biznesowy ma stan?) jestem ostrożny z używaniem pojęcia “stan”, popatrzmy na gry komputerowe… Czym jest stan?  Stan na pewien moment w czasie (snapshot) czy stan “biznesowy” trwający minuty, godziny a nie raz dłużej? Model to system: zespół elementów współdziałających. Z perspektywy biznesu, reaguje on na akcje (stabilny ekran oczekiwania na OK, to permanentny maszynowy przebieg sprawdzania stanu przycisków). Osobiście traktuję klasy Modelu jako samodzielne żyjące byty, konstrukcja metod musi zagwarantować brak błędów i radzić sobie z tym co “stałe” dla użytkownika i “zmienne” dla systemu (zegar bez sekundnika jest z perspektywy minut martwym przedmiotem a mimo to “chodzi”).

Podejście do MVC, które praktykuję: Model powinien realizować 100% funkcjonalności i dać się testować bez warstwy V i C. Konkretnym stanem  raczej charakteryzuje się konkretny obiekt a nie cały system. Cały system można zapewne opisać maszyną stanową ale po co, skoro są ich niezliczone ilości? Model żyje jak mrowisko, wystarczy zrozumieć mrówki, mrowisko to skutek na który za bardzo nie mamy wpływu.

Model DDD “analityczny” to metamodel implementacji, Evans traktuje go jako “bloki kodu”  zrozumiałe przez biznes, idąc dalej: analityk traktuje DDD jako wiedzę o biznesie w postaci zrozumiałej przez developera. Obie strony uznają, że ta struktura jest wzajemną “umową”. Jestem zwolennikiem takiego podejścia do DDD :), Evans się z tym w moich oczach nie kłoci, on w zasadzie nie pisał o analizie biznesowej :). Wielu programistów, autorów  doskonałych książek, zakłada, że “analizę wymagań ma poprawnie wykonaną”, co by to nie miało znaczyć :), ale to ogromne uproszczenie bo tu – błędy – tkwi większość ryzyk projektu.

Więcej o słownikach i regułach biznesowych:

(OMG, Glossary, Business Rules, http://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules oraz http://en.wikipedia.org/wiki/Business_rule, http://www.visual-paradigm.com/support/documents/bpvauserguide/2017/2181/57043_creatingfact.html).

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 3 komentarzy

  1. jokoz

    Jeszcze nigdy się tak nie negocjowałam jak przy słowniku pojęć. Chyba Twój tekst polecę do poczytania wszystkim stronom negocjacji.

  2. Sławomir Sobótka

    Warto wspomnieć o jednej ze strategicznych technik DDD: Bounded Context. W dużym skrócie: model (słownictwo) ma znaczenie tylko w kontekście domeny.
    Z uwagi na “ubóstwo” języka polskiego/angielskiego (kilkaset tysięcy słów) będzie dochodzić do powielania pojęć, nie unikniemy tego. Ale jeżeli wydzielimy osobne BC, wówczas eliminujemy dwuznaczności. Przykładowo: “produkt” w module sprzedaży, magazynowym i wysyłki to coś z goła odmiennego – jedynie brzmienie jest (przypadkiem) takie samo.

    1. Jarek Żeliński

      Kontekst jest także istotny z powodów czysto komunikacyjnych, jednak może nim być – tym kontekstem – konkretna aplikacja, organizacja albo nawet cała branża a nawet dziedzina wiedzy. To zależy od tego w jakich warunkach pracujemy. Jeżeli tworzymy oprogramowanie na rynek (uniwersalne) głównym kontekstem jest przyszły cel i dziedzina jego użycia. Jednak tworząc oprogramowanie dedykowane dla danej firmy, tym kontekstem jest ta właśnie firma, z jej specyfiką – także pojęciową. Na to może się nałożyć kwestia regulacji formalnych lub zwyczajowych w danej branży co nie eliminuje istnienia lokalnego słownictwa w konkretnej firmie.

      Tak zwany Business Vocabulary (SBVR w OMG.org) to problem budowania systemu reguł biznesowych, które: muszą być tworzone z pojęć jednoznacznych oraz muszą być jako zdania w naturalnym języku zrozumiałe i jednoznaczne w danej grupie ludzi (organizacji). To nie może być przedmiotem kompromisu bo ryzykujemy nieporozumienia w danej firmie, a narzucenie ludziom używania nowych “lepszych” pojęć, tylko z powodu nowego projektu raczej nie zadziała.

      Bounded Context (BC) jak najbardziej jest potrzebny, jednak należy pamiętać, że dla powodzenia projektu musimy zabezpieczyć wykonywalność pełnego tłumaczenia pojęć jednej przestrzeni nazw (np. BC oprogramowania) na drugą np. słownik pojęciowy organizacji w której to oprogramowanie ma być używane. Tu wkraczamy w teorię komunikacji i semiotykę.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.