Swego czasu pisałem o tym, że np. klasa przechowująca informacje o pracowniku raczej powinna nazywać się DaneOPracowniku a nie Pracownik. Dlaczego? Bo projekt systemu zawierający informacje o pracownikach i klientach, a także treść wielu dokumentów, powinien pozwalać zrozumieć co jest „w systemie” a co w „rzeczywistości” (pracownik jest żywym organizmem, oprogramowanie co najwyżej zarządza danymi opisującymi tego pracownika).
Ku mojemu zaskoczeniu ale także radości, niemalże ten sam problem poruszył Ron Ross (bloger i autor książki BUILDING BUSINESS SOLUTIONS: Business Analysis with Business Rules):
To make a long story short, business models talk directly about real-world things (as business people do); systems models talk about surrogates for real-world things (as system designers do). Not the same thing! (za Business Model vs. System Model: eCommerce ? Ron Ross on Business Rules).
W uproszczeniu: model biznesowy opisuje realny świat, model systemu (oprogramowania) opisuje jego [[surogat]]. Warto o tym nie zapominać. Podobne podejście prezentowane jest przez autorów książki: Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approach). Tu pojawia się metafora opisująca oprogramowanie (system) jako „narzędzia i materiały”. Tu także wewnątrz systemu nie ma Pracownika a jedynie jego Kartoteka.
Warto jednak pamiętać, ze w systemach biznesowych np. dokument ma (może mieć) wersje papierową i elektroniczną. W przypadku owego pracownika już nie, pracownik (jak każdy człowiek) ma tylko wersję „żywą” (pomijamy tu kwestie gier komputerowych, które także są oprogramowaniem). Tak więc system zapewne „ma w sobie” np. fakturę czy umowę ale na pewno nie pracownika czy klienta.
Szybkie podsumowanie
Każdy model oprogramowania, a specyfikacja wymagań jest także takim modelem, powinien być opatrzony jego kontekstem i pragmatyką. Przede wszystkim systemy biznesowe to nie gry komputerowe, tu mamy (system przetwarza) dokumenty, dano o czymś lub kimś, ale nie ludzi, nie pojazdy.
Zaniedbanie tej pozornie błahej różnicy (kłania się [[semiotyka i teoria komunikacji]]) prowadzi to dużych nieporozumień, a nie raz do wręcz bełkotliwej treści w rodzaju: system ma pozwalać na usuwanie pracowników z poszczególnych wydziałów firmy. Nie! Co najwyżej system powinien pozwalać na tworzenie nowych zakresów obowiązków lub umów o pracę na podstawie wzorów umów lub treści umów poprzednio zawartych (plus wzory lub modele tych dokumentów).
OK.
..Ale rozróżnijmy reprezentację osoby pracownika, od jego danych. Dane pracownika można sobie trzymac w obiektach Kartoteka. Nawet nie on je bedzie posiadal, ale moze Kierownik departamentu, w którym pracuje Pracownik. A nawet nie Kierownik, a jego SzafaZKartotekami.
Ale, byt Pracownik jak najbardziej ma sens. Przecież tu jest zdefiniowane jego zachowanie (część jedynie z real world, ale jednak).
Pracownik.pijeKaweRano().. przeciez nie KartotekaPracownika.pijeKaweRano()
Może to być jakieś minimum odzwierciedlające real world business model, ale być musi.
Również Pracownik korzystajacy z systemu informatycznego, przebywa w danym momencie w jakiejś jego części. Coś robi, przechodzi po działach, zleca wykonanie akcji.
Pracownik lubi innego Pracownika. Nawiazują się między nimi różne relacje.
Ma sens odzwierciedlenie 1:1 real world => system objects. Nie widzę przeszkód, aby model biznesowy zaimplementować w systemie odzwierciedlając 1:1 obiekty biznesowe na systemowe.
Nic nas również nie zwalnia z dzielenie systemu wg odpowiedzialności (aka SRP). Jeśli dane pracownika zasługują na oddzielny byt, to jak najbardziej.
Przejrzałem źródłowy blog. W zasadzie dużo z tego nie wynika, oprócz jasno określonych definicji business/system. Z tego z pewnością nie można wysunąć wniosków, że nie ma Pracownika 😉
Ogólnie jest to przykład mylenia Modeli Dziedziny systemu z „modelem jakiejś rzeczywistości”. Dodam pytanie: co modelujemy projektując oprogramowanie?
Cytuję: „Ale, byt Pracownik jak najbardziej ma sens. Przecież tu jest zdefiniowane jego zachowanie (część jedynie z real world, ale jednak).
Pracownik.pijeKaweRano().. przeciez nie KartotekaPracownika.pijeKaweRano()”
Ok, ale o jaki model chodzi? O obiektowy model jakiejś rzeczywistości? Wtedy owszem, ma sens Pracownik.pijeKaweRano(). Ale jeżeli projektujemy np. system HR to taki element kompletnie nie ma sensu, z powodów chyba oczywistych: system HR to nie gra komputerowa o nazwie „Moja Korporacja” a System mający zastąpić papierowe metody dokumentowania danych o pracowniku, więc Pracownik Pije kawę, ale w swoim pokoju. System HR co najwyżej zawiera dane o tym pracowniku (w tym np. numer tego pokoju) ale System HR nie służy do graficznego zobrazowania na ekranie faktu picia kawy przez tegoż pracownika.
„Nie widzę przeszkód, aby model biznesowy zaimplementować w systemie odzwierciedlając 1:1 obiekty biznesowe na systemowe.” A ja widzę, bo system biznesowy to nie gra komputerowa. Druga ważna uwaga: model biznesowy i model dziedziny to zupełnie odrębne pojęcia. Model biznesowy opisuje to co robi firma (w tym jej pracownicy a raczej role jakie pełnią bo nie obchodzi mnie konkretny Kowalski a co najwyżej to „co robi Dyrektor Handlowy”. Model Dziedziny Systemu to model tego co System ma zastąpić, w końcu to nowe narzędzie pracy, czyli Model Dziedziny to model narzędzia jakiego użyje Aktor.
Wskazałem na ten blog, bo poruszył ważną kwestię zaś mój post to nie tłumaczenie czy interpretacja tego wpisu a moje wnioski i doświadczenie. Moim zdaniem wiele szkód w projektach programistycznych przynosi mylenie (może nawet mieszanie) stron: świat aktorów (poza Systemem) i świat systemu (to czym jest System). Bardzo przydatny diagram przypadków użycia ma magiczny i najważniejszy chyba element: prostokąt System. Tak więc co, jaką klasę, będzie zawierał System: Pracownik czy KartotekaPracownika? Pracownik to Aktor Systemu, jest poza nim (bo to aktor), System zawiera elementy przetwarzane (skoro Pracownik jest Aktorem to nie jest Obiektem w Systemie, to zasada wyłączonego środka dla przestrzeni pojęciowych).
Bo tak na prawdę: co ma zrobić programista współtworzący System HR z klasą i operacją: „Pracownik.pijeKaweRano()”?
Hmm.. wiele nieprawidlosci, wiele… chyba ktoś musi wrócić do realnego projektowania i realizacji (implementacji) modelów ze świata rzeczywistego 🙂
a) oczywiście, że obiekty/klasy. A co innego? To pasuje najbardziej do odzwierciedlenia świata, acz i tak ułomne w jego odzworowaniu.
b) nie wiem czym systemy HR się charakteryzują, ale jak najbardziej jeśli przetwarzają dane ludzi i ich doświadczenie zawodowe, przeszłych pracodawców, ich hobby, to wszystkie te modele ze świata biznesowego mają 1:1 odpowiednik w modelu systemowym (klasach danego języka programowania).
To czy ktoś, gdzieś, u kogoś pracował programuje/projektuje się najzwyczajniej i najnormalniej tworząc te (Pracodawca, Osoba, Stanowisko) klasy, te usecase’y ..
c) To, że system HR prezentuje się „widokowo” jako system zarządzania dokumentami (tak?), w niczym nie przeszkadza. To tylko warstwa prezentacji dla osób obsługujących system. To tylko to, co wypluwa drukarka.
Ale aby to zaprezentować, konieczne jest 1:1 zaprojektowanie systemu _wewnątrz_, tak jak działa i wygląda biznes. Inaczej się nie da.
Skrótów i uproszczeń robić nie wolno i nie ma sensu.
d) A co złego jest w grze komputerowej? Może dalej za bardzo skupiasz się na prezentacji? Tam również jest jakis model biznesowy zaprojektowany (infantylny, ale jakiś)
e) relacja między Janem Kowalskim, który jest Dyrektorem Handlowym, jest oczywista, i oba mają byt w świecie rzeczywistym, jak i w systemie
f) jeśli założymy, że nie mogę implementować „jakoś” p.wypijKawę(), bo wlanie wody do monitora zwiąże się z przykrością wizyty co najmniej inspektora BHP, to również nie mogę i Pracownik i Osoba – bo to nie smerfy i się na dysk twardy nie zmieszczą.
Ale to bez sensu.
Przy takim ograniczeniu, zostają nam faktycznie BitoweKartotekiWRamieLubDyskuOOsobie… ojej! Wyjeżdżam stąd pierwszym autobusem
🙂
I na koniec odpowiedź na pytanie: modelujemy świat realny. Robimy to programując, bo takie nam Bóg dał narzędzia, a nie inne.
Ułomności nieumiejętności zrobienia tego możemy odłożyć na bok i założyć, że się da to zrobić.
Jak już czytać, to http://www.leansoftwarearchitecture.com/ Copliena
a. konkretne oprogramowanie, jako narzędzie pracy, odwzorowuje narzędzie pracy a nie jego użytkownika bo ten może być być tylko po jednej stronie monitora…
b. systemy HR charakteryzują się tym, że pomagają w prowadzeniu spraw kadrowych, innymi słowy zastępują papierową dokumentację (jej część) i automatyzują np. naliczanie wynagrodzenia, tak więc pytanie o cel projektu brzmi: ma powstać oprogramowanie wspomagające zarządzanie danymi o pracownikach czy pracownikami?
c. oczywiście, że nie ma sensu robienie skrótów, ale jest coś co się nazywa w niektórych technikach projektowania „bounded context” (DDD), dla systemu HR nie modelujemy więc „całego świata” a jedynie to co jest związane z zadaniami (odpowiedzialnością) tego systemu, a to nie jest uproszczenie tylko selekcja.
d. nie ma nic złego w grach komputerowych, po protu do czego innego służą,
e. w świecie realnym jest Dyrektor Handlowy, zapewne jest aktorem systemu HR, w Systemie mamy jego dane i historie zatrudnienia ale nie jego samego,
f. jak wyżej.
Obracamy się w sferze problemu „jak nazwać klasę reprezentującą imię, nazwisko, datę urodzenia i potrafiącą wyliczyć aktualny wiek tej osoby”, ja ją nazwę „InformacjeOOsobie”, owszem można ją nazwać „Osoba”. W czym tkwi problem? Ano organizacja używa słowa Osoba w stosunku do żywych ludzi (swoich pracowników, klientów itp.), po drugie Aktorem Systemu (jest jego użytkownikiem) jest także Osoba. Patrząc na to z perspektywy organizacji zaczyna zacierać się znaczenie słowa Osoba. Do tego „wczoraj” Pani Kadrowa używała na swoim biurku „KartotekiOsobowejPracownika” a od jutro ktoś mówi jej, że ma przed sobą Pracownika. Wdrożenie takie staje się dla wielu beneficjentów nowego oprogramowani przeżyciem traumatycznym. Po drugie MUSZĄ się nauczyć nowego znaczenia wielu „starych” pojęć, a to tylko utrudnia cały proces wdrożenia. Nie rozumiem co znaczy „BitoweKartotekiWRamieLubDyskuOOsobie”.
W kwestii książek ja dla odmiany gorąco polecam ściśle obiektowe i bardzo praktyczne podejście w:
– E.Evansa (DDD) – o modelowaniu dziedziny systemu w konwencji „modelowania tego co reprezentuje i przetwarza dane oprogramowanie”
– Heinz Züllighoven, Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approach – o pięknej metaforze tworzenia oprogramowania: program to „narzędzia i materiały” w rękach użytkownika
– Rebecca Wirfs-Brock, Alan McKean, Projektowanie obiektowe. Role, odpowiedzialność i współpraca, doskonała książka o analizie obiektowej i projektowaniu.
– Fowler albo Go4, Wzorce Projektowe, wskazówki rozwiązywania wielu problemów projektowych, ze szczególnym uwzględnieniem wzorców analitycznych domenowych.
– gorąco polecam także przeczytanie jednak krótkiego artykułu, który cytowałem na początku tego postu.
Zapewne różnimy się bardzo stylem analizy i projektowania. Autobusów mamy wiele, cele i drogi ich osiągania różne… nie ma problemu 🙂
Ciekawe..
To na co chcę zwrócić uwagę, to, że prezentacja w postaci kartotekiPracownika dla Pani Ewy, której traumy nikt nie chce doświadczyć nie ma nic wspólnego z tym jak modelujemy system wewnątrz.
Ta klasa tylko kwestia warstwy prezentacji.
Kto powiedział, że sposób realizacji wnętrzności systemu ma mieć wpływ na to jak prezentujemy to na ekranie/drukarce dla Pani Ewy.
Mnie interesuje jak przenosić świat realny w systemowy i nie widzę tu żadnych ograniczeń wspomnianych.
A wnętrzności systemu programujemy my, i aby to robiło się najłatwiej, było jak najbliżej realnym wymaganiom, i less bugs, i był gdzieś kod, który i osoba biznesowa może łatwo przeczytać/zmodyfikować (z pomocą IT) – to i nazwy i obiekty muszą być jak najbardziej 1:1
W moim systemie „KartotekaPracownika”, to byłaby jedynie wartstwa prezentacji. A do tego, aby ja wygenerować potrzebowałbym klas/obiektów: Pracownik, Osoba, Kraj (polska), UrządMiasta (do trzymania peseli, nazwisk i imion), Czas (do trzymania eventów, kiedy osoba się urodziła).
Z tego wynika, że u mnie nie ma potrzeby w systemie posiadania klasy InformacjeOOsobie, jako, że jest to jedynie kwestia prezentacji i tylko w tej warstwie występuje, powiedzmy jako szablon/template do generowania pliku html/pdf.
Aby ją wygenerować na ekran, pytamy „urządMiasta.podajPesel(osoba)”, „czas.narodziny.kiedy(osoba)”, itd..
Tak to wygląda w świecie rzeczywistym 🙂
Można sobie uprościć, że to ja mam pesel, ale w rzeczywistości ja o nim wiem przez to, że gdzieś, ktoś mi go wygenerował w Urzędzie Miasta.
Podbnie z imionami..
I wiele, wiele innych atrybutów, które przez lata wylądowały w klasie Person, co jest oczywistym złamaniem SRP, a nawet samego RP 😉
Ogólnie to tylko, moim zdaniem – pragmatyka modelu dziedziny. Można, nie ma zakazu, zbudować model dziedziny zawierający klasę Osoba, rzecz w tym, że (cytat z linkowanego artykułu) jest to jednak tylko „surogat”, bo prawdziwa Osoba jest człowiekiem z krwi i kości, zapewne korzysta z tego oprogramowania… Prezentacja danych „imię i nazwisko” na ekranie (poza sformatowaniem) wymaga wywołania operacji JakSięNazywasz klasy Osoba, lub w konwencji, którą preferuję, wywołanie operacji PodstawoweDaneOsoby klasy KartotekaPracownika. Pojęcie „real world” ma sens ;), jeżeli oprogramowanie HR zastępuje papierowy system kadrowy, to czym tu jest „real world”? Klasą reprezentującą papierową kartotekę, która zastępuję nowym oprogramowaniem…
Przykład z PESEL jest OK, bo pytanie o PESEL mogę zadać osobie jak i Urzędowi, pytanie czy pytam o to żywego kowalskiego czy Urząd, czy klasę/komponent SystemPESEL, to samo pytanie można zadać różnym „bytom”. Kto ma PESEL? Ja nie, jest atrybutem mojego dowodu osobistego, pomijając ewentualne zapamiętanie go, jak ktoś zapyta mnie mnie o PESEL, muszę najpierw „zapytać” o to mój dowód. Tyle w kwestii „real world”. W moich projektach nie ma klas DowódOsobisty, jest klasa DaneDowoduTożsamości z atrybutami rodzajDokumentu, numerSerii (i pewnie inne).
Obracamy się wokół tego jaką konwencję modelowania stosujemy… ja o tej, którą stosuje (nie ja jeden) powiem, że jest inna niż Twoja, nie że lepsza czy gorsza… co najwyżej bronie tezy, że „real world” w oprogramowaniu polega na tym, że oprogramowanie jest narzędziem w rękach człowieka podobnie jak kalkulator, papier, ołówek, papierowe formularze itp. a nie symulatorem firmy dla której projektuję oprogramowanie, no chyba, że faktycznie ma być symulatorem ale wtedy nazywa się GRA BIZNESOWA lub SYMULATOR BIZNESU.
SRP (o ile rozumiem: Single Responsibility Principle) jest bardzo wygodne i pomocne w projektowaniu, zaś zamiana mojego dowodu osobistego, paszportu, teczki z papierami i mojej szafy w pokoju na jeden obiekt z dziesiątkami atrybutów to właśnie szkodliwe nadmierne uproszczenie, które o ile pamiętam krytykowałeś.