W toku nie­jed­nej ana­li­zy moż­na spo­tkać się z sytu­acją gdy stan­dar­do­we podej­ście pole­ga­ją­ce na bada­niu doku­men­tów i ana­li­zie zstę­pu­ją­cej (od ogó­łu do szcze­gó­łu, ang. top-down) może być trud­ne lub wręcz nie moż­li­we. Dotyczy to ana­li­zy sys­te­mów sła­bo udo­ku­men­to­wa­nych lub wręcz nie­udo­ku­men­to­wa­nych, gdzie jedy­ne dostęp­ne dane to obser­wa­cja lub rela­cja obser­wa­to­ra (uczest­ni­ka, itp. czy­li rela­cja z dru­giej ręki). Jest to sytu­acja podob­na to serii (pakie­tu) zebra­nych ​„user sto­ry” (w nomen­kla­tu­rze meto­dyk zwin­nych histo­ryj­ki użyt­kow­ni­ka), nie­for­mal­nych rela­cji. Jak ugryźć taką sytuację?

Z pomo­cą przy­cho­dzi poję­cie spe­cy­fi­ka­cji instan­cji w UML, zapew­ne brzmi to strasz­nie ale nie jest tak źle. Cóż to jest ta spe­cy­fi­ka­cja instan­cji? Co mówi spe­cy­fi­ka­cja (UML v.2.5):

9.8 Instances
9.8.1 Summary
InstanceSpecifications repre­sent instan­ces of Classifiers in a mode­led sys­tem. They are often used to model exam­ple con­fi­gu­ra­tions of instan­ces. They may be par­tial or com­ple­te repre­sen­ta­tions of the instan­ces that they cor­re­spond to.

Generalnie rzecz w tym, by poka­zać to co wie­my czy­li kon­kret­ne nazwa­ne egzem­pla­rze ​„tych rze­czy” o któ­rych ktoś mówi lub któ­re obser­wu­je­my. To egzem­pla­rze i ich spe­cy­fi­ka­cja (nazwy, cechy itp.). Innymi słowy

dia­gram obiek­tów słu­ży do poka­za­nia kon­kret­ne­go, obser­wo­wal­ne­go sta­nu rzeczy

Jeżeli więc z jakie­goś powo­du nie może­my ope­ro­wać uogól­nie­nia­mi (kla­sy) bo nie posia­da­my odpo­wied­niej wie­dzy lub jest ona zbyt ubo­ga, ana­li­zę moż­na pro­wa­dzić ​„od dołu” czy­li mając szcze­gó­ły uogól­niać je. Poważną zale­tą tej meto­dy jest łatwość wery­fi­ka­cji mode­lu przez ​„klien­ta”. Większość ludzi nie radzi sobie z abs­trak­cja­mi (np. meta­mo­de­le): mode­le budo­wa­ne z uży­ciem dia­gra­mów klas to uogól­nie­nia: opi­su­ją kla­sy a nie kon­kret­ną rze­czy­wi­stość. Diagramy obiek­tów (instan­cje klas) to nic inne­go jak mode­le ​„kon­kret­nych sytu­acji” z życia.

Tak więc napi­szę tu kil­ka słów o bar­dzo mało popu­lar­nym dia­gra­mie UML: dia­gra­mie obiek­tów (spe­cy­fi­ka­cje instancji).

Powyższe przy­kła­dy to mode­le kon­kret­nych sytu­acji: mamy tu (od góry) kon­kret­ną uli­cę, kon­kret­ny adres, dwie oso­by i zwią­zek mię­dzy nimi (ojciec-syn) oraz tak zwa­ną war­tość (nazwa­ne kon­kret­ne war­to­ści to tak­że obiek­ty). Diagram obiek­tów zawie­ra więc prak­tycz­nie wyłącz­nie kon­kret­ne, nazwa­ne byty w opi­sy­wa­nej rze­czy­wi­sto­ści. Prawdę mówiąc bar­dzo wie­le, o ile nie więk­szość, sche­ma­tów blo­ko­wych wyko­ny­wa­nych w tak zwa­nych doku­men­tach biz­ne­so­wych i pre­zen­ta­cjach, to pew­ne nie­for­mal­ne dia­gra­my obiek­tów. Wszędzie tam gdzie na sche­ma­cie blo­ko­wym są kon­kret­nie nazwa­ne uni­kal­ne ele­men­ty łączo­ne róż­ny­mi for­ma­mi linii i strza­łek, moż­na mówić o przed­sta­wie­niu kon­kret­nej ​„zma­te­ria­li­zo­wa­nej” sytuacji.

Typowym przy­kła­dem są sche­ma­ty orga­ni­za­cyj­ne. Poniżej jed­na z wie­lu dostęp­nych w sie­ci Internet struk­tur orga­ni­za­cyj­nych: są to kon­kret­ne nazwy orga­nów (np. Rada Nadzorcza), komó­rek orga­ni­za­cyj­nych i sta­no­wisk, np. jak na poniż­szym diagramie.

Powyższy dia­gram do dość powszech­na for­ma doku­men­to­wa­nia struk­tu­ry orga­ni­za­cyj­nej. Poniżej wer­sja tej struk­tu­ry (okro­jo­na) w posta­ci dia­gra­mu obiektów:

Są to dokład­nie te same ​„blocz­ki”, na dia­gra­mie tym (UML, dia­gram obiek­tów) każ­dy ele­ment to ​„instan­cja (kla­sy)”. Na tym eta­pie odwzo­ro­wu­je­my jedy­nie to co wie­my w for­mie jaką zna­my. Kolejny etap to szu­ka­nie zasad i klu­czo­wych dla nich pojęć, skla­sy­fi­ko­wa­nie obiek­tów odwzo­ro­wa­nych na diagramie:

Powyższy dia­gram to dia­gram fak­tów (spe­cy­fi­ka­cja SBVR/OMG). Jest to model poję­cio­wy, skła­da się z pojęć słow­ni­ka (pojęć biz­ne­so­wych) i fak­tów łączą­cych te poję­cia, na ich pod­sta­wie two­rzo­ne są kla­sy i atry­bu­ty, do któ­rych przy­po­rząd­ko­wy­wa­ne są poszcze­gól­ne obiek­ty mode­lu ana­li­zo­wa­ne­go (dia­gra­mu obiektów):

Powyżej obiek­to­wy model Struktury orga­ni­za­cyj­nej po uzu­peł­nie­niu o kla­sy­fi­ka­to­ry (każ­dy obiekt na dia­gra­mie został przy­po­rząd­ko­wa­ny do okre­ślo­nej kla­sy). Teraz moż­na opra­co­wać struk­tu­rę metamodelu:

Powyższy dia­gram to meta­mo­del tego co przed­sta­wia dia­gram obiek­tów (pier­wot­nie poka­za­na struk­tu­ra orga­ni­za­cyj­na). Teraz poja­wia się pyta­nie: co ma wyko­nać pro­gra­mi­sta (o ile takie jest zada­nie). Na tym eta­pie zro­zu­mie­li­śmy czym jest struk­tu­ra orga­ni­za­cyj­na i udo­ku­men­to­wa­li­śmy to, ale nadal nie roz­wią­za­li­śmy pro­ble­mu: jak to zaim­ple­men­to­wać (powyż­sze nie jest żad­nym wyma­ga­niem imple­men­ta­cji dla programisty).

Teraz mamy dwa wyj­ścia (pew­nie są też inne): potrak­to­wać powyż­sze jako meta­mo­del struk­tu­ry orga­ni­za­cyj­nej, użyć go, po uzu­peł­nie­niu o ogra­ni­cze­nia, jako ​„recep­ty” dla ​„fabry­ki struk­tu­ry orga­ni­za­cyj­nej”, uzu­peł­nić o kla­sy two­rzą­ce tę struk­tu­rę (wspo­mnia­ną fabry­kę) i dokoń­czyć ​„model dzie­dzi­ny sys­te­mu”, albo poprze­stać na tym eta­pie, spi­sać ​„regu­ły biz­ne­so­we” i w tej for­mie prze­ka­zać deve­lo­pe­ro­wi (wte­dy on sam musi roz­wią­zać pro­blem meto­dy imple­men­ta­cji). Jedno jest pew­ne: nie jest to abso­lut­nie żaden model danych.

Tak więc ana­li­za ​„od szcze­gó­łu do ogó­łu” cza­sa­mi bywa bar­dzo pomoc­na. Pozwala wyjść od kon­kret­ne­go rze­czy­wi­ste­go ​„sta­nu świa­ta” i opra­co­wać na jego pod­sta­wie model poję­cio­wy i meta­mo­del. To bar­dzo pomoc­na tech­ni­ka. Warto pamię­tać, że to co nie raz nazy­wa­ne jest ​„mode­lem dzie­dzi­ny” jed­nak nim nie jest.