Czym jest to co modelujesz w oprogramowaniu? Model dziedziny systemu jako wymaganie.

Niestety fir­my ofe­ru­ją­ce goto­we opro­gra­mo­wa­nie, poka­zu­ją jedy­nie menu, na któ­rym zoba­czy­my np. Cennik, ale bez wie­dzy jak wyglą­da wnę­trze, nie ma żad­nej moż­li­wo­ści oce­ny przy­dat­no­ści kon­kret­ne­go pro­gra­mu (nie licząc prób­nej eks­plo­ata­cji). To wyj­dzie naj­czę­ściej (jego wewnętrz­ny model i ogra­ni­cze­nia jakie powo­du­je) dopie­ro pod­czas wdro­że­nia, a to już za póź­no. Pojawia się tak zwa­na kasto­mi­za­cja jako zale­ce­nie w efek­tach ana­li­zy przed­wdro­że­nio­wej (wyko­na­nej dopie­ro po zawar­ciu umo­wy przez dostaw­ce pro­gra­mu czy­li już za póź­no!). Ale teraz to już po pro­stu tak zwa­na rzeź­nia. Przejście, w goto­wym opro­gra­mo­wa­niu, pomię­dzy opi­sa­ny­mi niżej mode­la­mi wyma­ga jego grun­tow­nej prze­rób­ki, lub nego­cja­cji: z któ­rych wyma­gań kupu­ją­cy zrezygnuje.

Przeciętny sys­tem ERP to naście setek funk­cjo­nal­no­ści, nie da się racjo­nal­nie (ale da się w ogó­le, widu­je takie spe­cy­fi­ka­cje) i nie ma sen­su two­rzyć takiej listy. Sposobem mini­ma­li­zu­ją­cym ryzy­ko złe­go wybo­ru jest dobra ana­li­za biz­ne­so­wa w celu wychwy­ce­nia tych obsza­rów fir­my, któ­re są jej spe­cy­fi­ką oraz opra­co­wa­nie dla tego obsza­ru mode­lu dzie­dzi­ny, a nie listy funk­cjo­nal­no­ści. Nowe funk­cjo­nal­no­ści spo­koj­nie moż­na dodać”, jest to łatwe, pod warun­kiem, że model dzie­dzi­ny sys­te­mu i jego imple­men­ta­cja jest wła­ści­wy”. W dru­gą stro­nę kom­plet­nie to nie działa. 

Bardzo czę­sto obser­wu­ję w pro­jek­tach pew­ne nie­do­mó­wie­nie”, pole­ga ono na nazy­wa­niu bytów” w opro­gra­mo­wa­niu tak jak coś rze­czy­wi­ste­go. W czym pro­blem? Po kolei, bo pro­blem, że tak powiem jest sze­rzej dostrzegany”:

The ?Real? World. The pro­blem with the ?real? world is that you are limi­ted by the laws of phy­sics. (za Don?t try to model the real world, it doesn?t exist. – Udi Dahan).

There are dif­fe­rent ope­ra­tions on the hard disk in dif­fe­rent spa­ces: in the phy­si­cal spa­ce, such as the motor rota­tion and the magne­tic head move­ment; in the com­pu­ta­tio­nal spa­ce, such as the data acces­sing; in the con­cep­tu­al spa­ce, such as the thin­king acti­vi­ties. There is a natu­re of the three spa­ces: each spa­ce has its own ope­ra­tions by its own mechanisms.

(za Some Basic Topics and Judgment of Ownership to the Three Spaces ? THINK IN MODELS ).

Udi Dahan suge­ru­je zasta­na­wia­nie się nad tym, jaki jest kon­tekst uży­cia, np. jeże­li szklan­ka jest pro­duk­tem to mode­lu­je­my ją przez pry­zmat tego, że to coś co ma nazwę, cenę itp., jako kon­tekst ogra­ni­cza­ją­cy wier­ność mode­lo­wa­nia wska­zu­je np. pra­wa fizy­ki. TY (autor blo­ga THINK IN MODELS) poszedł w stro­nę trzech prze­strze­ni (nazw): fizycz­na, poję­cio­wa (con­cep­tu­al) i apa­lik­cyj­na (com­pu­ta­tio­nal). Jak widać jest pro­blem w nazwa­niu (zro­zu­mie­niu) rela­cji pomię­dzy mode­lem poję­cio­wym a bytem w opro­gra­mo­wa­niu. Myślę, że zało­że­nie brzmią­ce, że model dzie­dzi­ny repre­zen­tu­je” świat rze­czy­wi­sty jest mylą­cy, jeże­li nie okre­śli­my kon­tek­stu i prag­ma­ty­ki. Pokażę to na innym przykładzie:

Celem jest opra­co­wa­nie mode­lu dzie­dzi­ny sys­te­mu, jest to ser­ce sys­te­mu (przy­po­mi­nam [[wzo­rzec MVC]]). Praca ręcz­na” to np. wpro­wa­dza­nie danych do kart maga­zy­no­wych. Mamy krze­sło oraz kar­to­te­kę pro­duk­tu zawie­ra­ją­cą wybra­ne cechy tego krze­sła: poza nazwą (krze­sło), zapew­ne będzie cena, kolor itp.

Teraz pora na ana­li­zę biz­ne­so­wą i mode­lo­wa­nie dzie­dzi­ny sys­te­mu. Tworzymy kla­sę Dane pro­duk­tu oraz Usługa (to enig­ma­tycz­na nazwa kla­sy ale…), któ­ra będzie wie­dzia­ła” co wol­no robić i jak, z kar­ta­mi produktów.

Klasa Dane pro­duk­tu jest reali­za­cją praw­dzi­wej kar­to­te­ki w sys­te­mie, kla­sa Usługa repre­zen­tu­je pew­ną umie­jęt­ność użyt­kow­ni­ka (zapew­ne jakieś żmud­ne obli­cze­nia i spraw­dze­nia, to ele­ment auto­ma­ty­za­cji, war­tość doda­na two­rzo­ne­go opro­gra­mo­wa­nia). Tak więc w mode­lu dzie­dzi­ny poja­wi się repre­zen­ta­cja kar­to­te­ki pro­duk­tu a nie pro­dukt! Komputer wspie­ra zarzą­dza­nie maga­zy­nem, ale nie zarzą­dza towa­ra­mi w nim, tyl­ko zastę­pu­je (uspraw­nia) ręcz­nie pro­wa­dzo­ne kartoteki.

W opi­sa­nej meto­dzie ana­li­za pole­ga na zro­zu­mie­niu tego co tak na praw­dę repre­zen­tu­je sobą pro­jek­to­wa­ne opro­gra­mo­wa­nie. Nie two­rzy­my więc kla­sy Produkt, bo pro­duk­tem tym jest krze­sło, któ­re jest i będzie real­nym krze­słem. Tworzymy kla­sę Dane pro­duk­tu, bo tak na praw­dę obiekt reali­zu­je (zastę­pu­je w apli­ka­cji) papie­ro­wą kar­tę, dane kon­kret­ne­go pro­duk­tu. Usługa to ta część pro­gra­mu, któ­ra wyko­na coś za użyt­kow­ni­ka (wyrę­czy go, wes­prze go).

Tą meto­dą ana­li­zy i mode­lo­wa­nia nie popa­da­my w pro­blem mode­lu poję­cio­we­go repre­zen­tu­ją­ce­go (tu) krze­sło, bo krze­sła nie odwzo­ru­je­my w kodzie, co naj­wy­żej coś co je repre­zen­tu­je w pew­nym kon­tek­ście (jego opis a może model 3D w pro­gra­mie CAD/CAM ale nie drew­nia­ne krzesło).

Tak więc nie Produkt a Opis pro­duk­tu, nie User a Dane użyt­kow­ni­ka, nie Pracownik a Dane pra­cow­ni­ka itp. A usłu­gi? Koniecznie Twórca kart pro­duk­tu, Zarządca kar­to­te­ki itp, bo kar­ta sama się nie utwo­rzy, jeże­li te kar­ty powsta­ją zgod­nie z jakimś sce­na­riu­szem (pro­ce­du­rą), to Usługa go nad­zo­ru­je, Wie jaki to sce­na­riusz i reali­zu­je go lub pomo­że w tym użyt­kow­ni­ko­wi programu.

Tyle o mode­lach, a teraz pole­cam stu­dio­wa­nie DDD ([[Domain Driven Design]]) …:) bo ana­li­za i mode­lo­wa­nie dzie­dzi­ny sys­te­mu to cięż­ka i trud­na pra­ca pole­ga­ją­ca na zro­zu­mie­niu i uchwy­ce­niu isto­ty rze­czy. Dlatego leży na mojej pół­ce, na bar­dzo eks­po­no­wa­nym miej­scu [[książ­ka Kazimierza Ajdukiewicza: Język i pozna­nie]]. Należy wła­ści­wie inter­pre­to­wać sło­wa (zna­cze­nia jakie niosą).

Jakie są prak­tycz­ne efek­ty takich prze­my­śleń? Poniżej pewien hipo­te­tycz­ny model manu­fak­tu­ry meblowej:

W tym przy­pad­ku: model krze­sła jako wzo­rzec jego kon­struk­cji agre­gat Krzesło skła­da­ją­cy się z czte­rech nóg, sie­dzi­ska i opar­cia (tu fak­tycz­nie mode­lu­je” krze­sło). W maga­zy­nie (Zarządca maga­zy­nu) mamy ele­men­ty skła­do­we kzre­seł (w rozu­mie­niu dane o tych czę­ściach w maga­zy­nie) i goto­we wyro­by. Do skła­da­nia ofert potrzeb­ny jest Cennik, tu potrzeb­ne są dane pro­duk­tu (a nie one same). Zarządzanie cen­ni­ka­mi korzy­sta z usług Zarządcy maga­zy­nu w celu pozy­ska­nia wie­dzy o dostęp­no­ści pro­duk­tów, ale nie koniecz­nie taki para­metr jak cena musi być u Magazyniera!

Ten model ope­ru­je poję­ciem egzem­pla­rza w maga­zy­nie (obiek­tów jest tyle ile egzem­pla­rzy w maga­zy­nie). Jest to kon­cep­cja może rza­dziej sto­so­wa­na w meblar­stwie, ale czę­sto np. w AGD (koniecz­ność ope­ro­wa­nia nume­rem seryj­nym egzem­pla­rza) do obsłu­gi gwarancji.

Inne roz­wią­za­nie:

Podstawowa róż­ni­ca to rezy­gna­cja z obsłu­gi egzem­pla­rzy na rzecz kar­to­tek pro­duk­tów. W tym przy­pad­ku mode­lu­je­my kar­tę z ilo­ścią rze­czy w maga­zy­nie (kar­ta taka jest jed­na dla każ­de­go produktu).

To tyl­ko pro­sty przy­kład, któ­ry obra­zu­je, że nie ist­nie­je coś takie­go jak refe­ren­cyj­ny model” dla każ­de­go (pra­wie każ­de­go). Specyfika pra­cy danej fir­my może się prze­nieść na pro­jekt. Co cie­ka­we, oba mode­le nie są wymien­ne (mimo bar­dzo podob­ne­go wyglą­du np. w doku­men­ta­cji). Jeżeli pierw­szy model (egzem­pla­rze) będzie­my pró­bo­wa­li wdra­żać w fir­mie posłu­gu­ją­cej się kar­to­te­ką będzie pro­blem, któ­rej kla­sy użyć jako kar­to­te­ki? Kosztowna kasto­mi­za­cja? Drugi model jest bez­u­ży­tecz­ny tam, gdzie wyma­ga­na jest wie­dza o egzem­pla­rzach (np. do celów reklamacji).

Na koniec dodam: imple­men­ta­cja tego sys­te­mu z uży­ciem bazy rela­cyj­nej SQL i znor­ma­li­zo­wa­nie jej znisz­czy ten model i ogra­ni­czy (o ile nie unie­moż­li­wi) jego przy­szły roz­wój lub zmia­ny . Tu są i mają być redun­dan­cje oraz brak trwa­łych połą­czeń (aso­cja­cje). Jedyne aso­cja­cje to kom­po­zy­cja. Związek pomię­dzy cen­ni­kiem a sta­nem w maga­zy­nie pole­ga wyłącz­nie na zapy­ta­niu” (rela­cja uży­cia w UML) Zarządcy maga­zy­ny ile ma krzeseł.

(Powyższe mode­le to poglą­do­we kon­struk­cje, nie nale­ży ich trak­to­wać jako kom­plet­ne pro­jek­ty. Gorąco pole­cam książ­kę: [[Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approa, Heinz Züllighoven, Morgan Kaufmann; 1 edi­tion, October 13, 2004]])

Po co to? Bo zły model to złe oprogramowanie.…

Duży sys­tem ERP to set­ki i tysią­ce jego przy­pad­ków uży­cia, nie ma sen­su ich spe­cy­fi­ko­wa­nie podob­nie jak nie ma sen­su pyta­nie o nie przy­szłych użyt­kow­ni­ków tego sys­te­mu bo nie są w sta­nie ich wyli­czyć. Ma jed­nak sens zro­zu­mie­nie tego jak fir­ma dzia­ła. Po raz kolej­ny posłu­żę się meta­fo­rą [[Martina Fowlera]]: grę w sno­oke­ra moż­na opi­sać rela­cjo­nu­jąc (zapi­su­jąc) set­ki kolej­nych par­tii, ale i tak nigdy nie wyspe­cy­fi­ku­je­my nawet ułam­ka moż­li­wych zagrań. Zdecydowanie lep­szą meto­dą jest przyj­rze­nie się kil­ku par­tiom i wychwy­ce­nie cech bili, ich ilo­ści, wymia­rów sto­łu oraz reguł gry, bo to będzie zgod­ne nie tyl­ko z histo­rią ode­gra­nych par­tii sno­oke­ra ale z każ­da przy­szłą partią.

Dlatego zamiast pro­wa­dze­nia żmud­nych wywia­dów i two­rze­nie nie­sku­tecz­nej listy setek szcze­gó­ło­wych opi­sów moż­li­we­go uży­cia opro­gra­mo­wa­nia, lepiej jest zro­zu­mieć orga­ni­za­cję, stwo­rzyć jej model (dzie­dzi­ny) i wyspe­cy­fi­ko­wać jakie usłu­gi ma to opro­gra­mo­wa­nie świad­czyć użyt­kow­ni­ków teraz (bo tak nale­ży rozu­mieć poję­cie przy­pad­ku uży­cia sys­te­mu). Poprawny model dzie­dzi­ny pozwo­li tak­że na obsłu­gę przy­szłych wyma­gań mimo, że nie zna­my ich teraz. Podobnie jak stół bilar­do­wy: nie zna przy­szłych ude­rzeń ale wie­my, że na pew­no zosta­ną obsłu­żo­ne”.

Na koniec nowy doda­tek, cytat z pew­ne­go bloga :):

Podstawową war­to­ścią biz­ne­so­wą jest nasza apli­ka­cja. To tutaj jest miej­sce na logi­kę biz­ne­so­wą i na umiesz­cze­nie wszyst­kie­go tego co chce­my aby apli­ka­cja robi­ła. To jak dostar­czy­my tą apli­ka­cję użyt­kow­ni­ko­wi jest spra­wą wtór­ną ? dostar­czy­my w sen­sie jak użyt­kow­nik będzie kon­su­mo­wał nasz pro­dukt. (Koncepcja ela­stycz­nej archi­tek­tu­ry | arek onli­ne | Arkadiusz Benedykt).

Inne artykuły na podobny temat

Komentarze

  1. Patryk Zieliński 9 sierpnia 2012 at 03:02

    Na wstę­pie powiem tak: cie­ka­wy arty­kuł. Świetny model dzie­dzi­ny. Dość moc­no inte­re­su­je się DDD i powiem szcze­rze nie wszyst­ko jest dla mnie jesz­cze jasne, ale teraz wła­snie zro­zu­mia­łem BC”(Bounded Context) (a przy­naj­mniej zda­je mi się że zrozumiałem).
    Dany byt może obja­wiać się w róż­nej for­mie w zależ­no­ści od kontekstu.
    Popraw mnie jeśli się myle, ale to jest repre­zen­ta­cja krzesła:
    Krzesło w kon­tek­ście warsz­ta­tu sto­lar­skie­go skla­da sie z nóżek, sie­dzi­ska. Jest po porstu efek­tem pra­cy warsztatu.
    Krzesło w kon­tek­ście cennika(produktu sprze­da­wa­ne­go) jest tyl­ko cena opi­sem i nazwą. Z punk­tu sprze­da­ją­ce­go nie inte­re­su­je nas z cze­go skła­da się krze­sło i jak się je tworzy.
    Kresło w kon­tek­ście maga­zy­nu jest tyl­ko repre­zen­ta­cja ilo­sci w kar­to­te­ce krze­seł. Magazyniera nie inte­re­su­je prze­zna­cze­nie rze­czy ani czym w rze­czy­wi­sto­ści są rze­czy skła­do­wa­ne w maga­zy­nie. Interesuje go tyl­ko ilość tych rzeczy.
    Później docho­dzą rela­cje mie­dzy kon­tek­sta­mi i trans­for­ma­cje mię­dzy kon­tek­sta­mi dane­go bytu.

    • Jarek Żeliński 9 sierpnia 2012 at 15:44

      Właśnie tak 🙂 za jed­nym wyjąt­kiem: zmia­na (w tym posze­rze­nie lub zawę­że­nie) kon­tek­stu wyma­ga nie trans­for­ma­cji (zmia­ny mode­lu – agre­ga­tu) a uży­cia jego innej (hipo­te­tycz­nie peł­nej) czę­ści. Czyli krze­sło to nogi, sie­dzi­sko i opar­cie – ZAWSZE, posze­rza­my kon­tekst więc i model (apli­ka­cję) o sklep: wzbo­ga­ca­my już ist­nie­ją­cy agre­gat o cenę i kolor, itp. Jeżeli zmia­na kon­tek­stu uży­cia przed­mio­tu” w apli­ka­cji wyma­ga­ła by zmia­ny mode­lu to zna­czy, że był zły! To dla­te­go nie nale­ży nicze­go w mode­lu dzie­dzi­ny uprasz­czać. Dlatego opro­gra­mo­wa­nie opar­te na bazie danych w mode­lu rela­cyj­nym z nor­ma­li­za­cją jest tak kosz­tow­ne w mody­fi­ka­cji (a nie raz mody­fi­ka­cja jest już nie­moż­li­wa). Same dane w bazie rela­cyj­nej znor­ma­li­zo­wa­nej, są nie­mal­że bez­u­ży­tecz­ne: np. nie da się z mode­lu rela­cyj­ne­go po jego nor­ma­li­za­cji odtwo­rzyć fak­tu­ry jeże­li nie mamy wie­dzy jak ta fak­tu­ra po odtwo­rze­niu powin­na wyglą­dać i z cze­go się składać.

  2. Pytacz 24 października 2021 at 20:06

    Witam. To ja mam takie pyta­nie. Załóżmy, że ma powstać sys­tem, któ­ry będzie wspo­ma­gał moni­to­ro­wa­nie pomia­ru pozio­mu wód w róż­nych zbior­ni­kach wod­nych. W ode­rwa­niu od tech­no­lo­gii (CIM) wyglą­da to tak. Ktoś two­rzy opis/dane kon­kret­ne­go punk­tu pomia­ru (nazwa zbior­ni­ka wod­ne­go, loka­li­za­cja gps miej­sca gdzie pomiar będzie doko­ny­wa­ny) . W związ­ku z tym two­rzy się bazę zawie­ra­ją­ca dane o wszyst­kich tych punk­tach. Następnie każ­dy z tych punk­tów jest fizycz­nie mie­rzo­ny (idzie czło­wiek i mie­rzy poziom wody). Pomiar może się odby­wać w róż­nych inter­wa­łach (codziennie/raz na tydzień/raz w mie­sią­cu). W kon­se­kwen­cji pomia­ru powsta­ją dane tego pomia­ru (id punk­tu pomia­ru, data pomia­ru, poziom wody). W związ­ku z tym poja­wia się też baza zawie­ra­ją­ca dane o wszyst­kich pomia­rach. Jakie kla­sy powin­ny powstać wg. Pana na mode­lu dzie­dzi­ny sys­te­mu i jakie związ­ki powin­ny je łączyć. Czy na dia­gra­mie powin­ny się poja­wić nastę­pu­ją­ce kla­sy: dane punk­tu pomia­ru, baza danych punk­tów pomia­ru, oso­ba two­rzą­ca punkt pomia­ru, oso­ba zarzą­dza­ją­ca bazą danych punk­tów pomia­ru, oso­ba doko­nu­ją­ca pomia­ru, dane pomia­ru, oso­ba zarzą­dza­ją­ca bazą danych o pomia­rach, baza danych o pomia­rach. Dobrze myślę?

    • Jarosław Żeliński 24 października 2021 at 21:01

      Generalnie świat real­ny, jeże­li jest gdzieś odwzo­ro­wy­wa­ny, to w doku­men­tach. Mamy więc doku­men­ty opi­su­ją­ce zbior­ni­ki. Jeżeli są doko­ny­wa­ne pomia­ry jakichś para­me­trów tych zbior­ków to powsta­ją doku­men­ty z tych pomia­rów (ProtokółPomiaru). Pytanie o kla­sy jest złe, bo kla­sa w UML to albo poję­cie słow­ni­ko­we albo ele­ment struk­tu­ry sys­te­mu, więc o co Pan pyta?. Jeżeli ma Pan na myśli model struk­tu­ry apli­ka­cji, to mamy: OpisZbiornika, ProtokółPomiaru, DanePracownika i żad­nych aso­cja­cji bo to nie baza rela­cyj­na. Potrzebny jest jesz­cze kom­po­nent reali­zu­ją­cy sce­na­riusz pomia­ru: 1. wyznacz zbior­nik, 2. wyznacz pra­cow­ni­ka, 3. Utwórz pro­to­kół pomia­ru. Narysowanie sko­men­to­wa­ne­go pro­jek­tu takiej archi­tek­tu­ry z uży­ciem UML, to już nie­co wię­cej pra­cy: ZAMÓW. Mamy rok 2021 i chmu­ry, repo­zy­to­ria NoSQL. Proponuję zmie­rzyć się z zada­niem: stwo­rzyć opro­gra­mo­wa­nie bez pro­jek­tu bazy danych, bez uży­cia SQL i bez two­rze­nia rela­cyj­ne­go mode­lu danych. Tak sie to robi dzi­siaj :). W pra­wym pane­lu u dołu jest do pobra­nia doku­men­ta­cja Biblioteka, tam Pan zoba­czy cos podobnego. 

  3. Pytacz 24 października 2021 at 21:16

    Miałem na myśli: Model dzie­dzi­ny sys­te­mu. Dziękuję za rozjaśnienie 🙂

    • Jarosław Żeliński 24 października 2021 at 21:37

      Ano wła­śnie ;). Bo Model dzie­dzi­ny sys­te­mu” to model kom­po­nen­tu archi­tek­tu­ry apli­ka­cji reali­zu­ją­ce­go logi­kę dzie­dzi­no­wą (kom­po­nent Model w rozu­mie­niu wzor­ca MVC). Nie jest żad­na baza danych :).

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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