W dwóch ubie­gło­rocz­nych arty­ku­łach pisa­łem o mode­lach poję­cio­wych oraz o związ­kach w UML. Opisałem je od stro­ny nota­cyj­nej. Dzisiaj o ich zastosowaniu. 

Generalnie zagad­nie­nia mode­li poję­cio­wych, abs­trak­cji i meta­mo­de­li oraz związ­ków mię­dzy nimi są dość trud­ne (wbrew pozo­rom, więk­szość ludzi ma pro­blem z abs­trak­cyj­nym myśle­niem), jako narzę­dzia są bar­dzo przy­dat­ne w ana­li­zie i projektowaniu.

Rzecz w tym, że sys­te­my ana­li­zo­wa­ne ist­nie­ją, co zna­czy ni mniej ni wię­cej tyl­ko to, że ​„są dobre bo są i dzia­ła­ją”. Gorzej jest gdy sys­tem, nie raz nie­try­wial­ny, jest na eta­pie pro­jek­to­wa­nia. Wtedy o tym jest ​„dobry” prze­ko­na­my się dopie­ro gdy go stwo­rzy­my (lub podej­mie­my taką pró­bę). Odkrycie, że jed­nak nie jest dobry bywa kosztowne.

Najczęstszymi wada­mi pro­jek­tów sys­te­mów są wewnętrz­na nie­spój­ność, nie­kom­plet­ność i wewnętrz­ne sprzecz­no­ści. Jak ich unik­nąć na eta­pie pro­jek­to­wa­nia? Jest rada: pro­jek­to­wać od ogó­łu do szcze­gó­łu, sta­le prze­strze­gać śla­do­wa­nia, pra­co­wać na abs­trak­cjach i meta­mo­de­lach. To pozwo­li zapa­no­wać nad zło­żo­no­ścią pro­jek­tu (sys­te­mu). Nie da się tego robić ​„ręcz­nie” dla­te­go bez dobre­go opro­gra­mo­wa­nia CASE takie pro­jek­ty są raczej ska­za­ne na nie­po­wo­dze­nie lub znacz­ne dodat­ko­we koszty. 

Przykład

Na pro­stym przy­kła­dzie poka­żę jak i kie­dy uży­wać róż­nych, bar­dzo waż­nych związ­ków i pozio­mów abs­trak­cji. Przykładem będzie pies i kojec. Najpierw model poję­cio­wy, któ­ry zagwa­ran­tu­je jed­no­znacz­ność cało­ści oraz zro­zu­mie­nie problemu. 

Bardzo czę­sto popeł­nia­nym błę­dem jest ​„prze­cią­ża­nie” dia­gra­mów i (lub) mie­sza­nie kon­tek­stów. Polega to na mie­sza­niu na jed­nym dia­gra­mie mode­li poję­cio­wych i struk­tu­ral­nych (pisa­łem też o tym w arty­ku­le o dia­gra­mach klas). Model poję­cio­wy to słow­nik pojęć i zależ­no­ści pomię­dzy poję­cia­mi (w nota­cji SBVR są to wyłącz­nie fak­ty łączą­ce te poję­cia w jeden kon­tekst). W tym przy­kła­dzie mamy taki oto model:

Tworzenie mode­lu poję­cio­we­go ma jed­no klu­czo­we zada­nie: zagwa­ran­to­wać spój­ność i jed­no­znacz­ność nazew­nic­twa w resz­cie pro­jek­tu. A nazwy dosta­ją: kla­sy, atry­bu­ty, ope­ra­cje, akto­rzy, war­to­ści atry­bu­tów klas, obiek­ty, itp.. Utrzymanie tu porząd­ku, wbrew pozo­rom, nie jest łatwe. Na mode­lach poję­cio­wych sto­su­je­my wyłącz­nie dwa związ­ki: dzie­dzi­cze­nie czy­li zwią­zek uogólnienia/specjalizacji (wska­zu­je typy) oraz aso­cja­cje czy­li nazwa­ne związ­ki mię­dzy poję­cia­mi. Tak więc typy ras to owcza­rek, pudel, ratler zaś pomię­dzy psem a rasą jest taki zwią­zek, że nazwa rasy opi­su­je pew­ne cechy psa. Mamy tak­że typy lego­wisk (buda, kojec) i zwią­zek psa z lego­wi­skiem. Każda z tych nazw (pojęć) powin­na mieć ści­słą defi­ni­cję (w doku­men­ta­cji osob­na tabe­la, zestawienie).

Teraz pora na projekt.

Projekt jest pro­sty wiec jego ele­men­ty zmie­ści­ły się na jed­nym dia­gra­mie. Tu mamy dia­gram obiek­tów (moż­na na nim umiesz­czać tak­że kla­sy). Większe pro­jek­ty to więk­sza licz­ba dia­gra­mów bar­dziej specjalizowanych. 

Tak więc meta­mo­del to kla­sy­fi­ka­to­ry i związ­ki mię­dzy nimi. Klasyfkator (kla­sa) zastę­pu­je np. set­ki psów i ich koj­ców. Metamodel poka­zu­je w posta­ci uogól­nio­nej związ­ki mię­dzy obiek­ta­mi nasze­go świa­ta, tu poka­za­no, że zwie­rze korzy­sta z koj­ca. Jak widać, uży­to nazwy kojec a nie lego­wi­sko, dla­cze­go? Bo z jakie­goś powo­du wie­my, że to jed­nak kojec i uży­to tej nazwy do nazwa­nia kla­sy. Konkretna sytu­acja to pies rasy ratler korzy­sta­ją­cy z koj­ca w posta­ci podusz­ki (u kon­kret­nych Kowalskich). Burek (tak sie wabi pies) to ratler, jest instan­cją kla­sy zwie­rzę. Poduszka u Kowalskich to instan­cja koj­ca. Rynkowy pro­dukt Kojec ALFADOG to reali­za­cja Kojca, któ­re­go kon­kret­nym przy­pad­kiem wyko­na­nia jest ów kojec u Kowalskich. Klasa Kojec ALFADOG repre­zen­tu­je kon­kret­ny typ koj­ca (pro­dukt ryn­ko­we) na bazie spe­cy­fi­ka­cji wyma­gań jaką jest tu kla­sa Kojec na metamodelu. 

Już taki pro­sty model to nie mało zależności:

Diagram obra­zu­je związ­ki pomię­dzy dia­gra­ma­mi i obiek­ta­mi na nich, moż­na poprze­stać na związ­kach pomię­dzy kla­sa­mi, obiek­ta­mi itp. Jednak peł­ny obraz śla­do­wa­nia i kon­tro­la tego śla­do­wa­nia pozwa­la zapew­nić spój­ność, kom­plet­ność i nie­sprzecz­ność dowol­nie duże­go pro­jek­tu. Czy war­to to robić? Ręcznie nie ma sen­su z powo­du pra­co­chłon­no­ści, mając dobre narzę­dzie CASE nasza godzi­na pra­cy nad korek­tą mode­li to ekwi­wa­lent nie raz dzie­sią­tek godzin deve­lo­pe­ra po wykry­ciu nie­spój­no­ści w two­rzo­nym opro­gra­mo­wa­niu lub wdra­ża­nej zmia­nie orga­ni­za­cyj­nej w fir­mie. Powyższy dia­gram to ana­li­za wpły­wu obiek­tu Burek na pozo­sta­łe ele­men­ty pro­jek­tu. Narzędzie CASE robi to auto­ma­tycz­nie w kil­ka sekund… Aktualizacja całe­go pro­jek­tu po zmia­nie jed­ne­go z nich tak­że wyko­ny­wa­na jest automatycznie. 

Na zakończenie 

Takie ana­li­zy i pro­jek­ty to (u mnie) ok. 70% to pro­jek­tu pro­gra­mi­stycz­ne, pozo­sta­łe to ana­li­zy doty­czą­ce pro­jek­to­wa­nia reor­ga­ni­za­cji, two­rze­nia wdra­ża­nia nowych reguł biz­ne­so­wych (zarzą­dza­nia zarzą­du, two­rze­nie pra­wa a kra­ju). To co tu opi­sa­łem, to tak na praw­dę sze­ro­ko poję­ta ana­li­za sys­te­mo­wa. Modelowanie to jedy­na moż­li­wość ode­rwa­nia się od tysię­cy deta­li świa­ta real­ne­go. Bez tego czło­wiek nie jest w sta­nie nicze­go sku­tecz­nie ana­li­zo­wać czy pro­jek­to­wać z uwa­gi na zbyt duży poziom zło­żo­no­ści. UML (i nie tyl­ko) to narzę­dzie do two­rze­nia abs­trak­cji i meta­mo­de­li, bez cze­go żad­na dobra ana­li­za sie obejść nie może.