Krótki wpis o śladowaniu

Często jestem pyta­ny: a co to jest to śla­do­wa­nie”? Artykuł adre­su­je nie tyl­ko ana­li­ty­kom, ale tak­że oso­bom zle­ca­ją­cym wyko­na­nie ana­li­zy, pro­jek­tu i ich doku­men­ta­cji. W arty­ku­le poda­je przy­kła­dy bazu­ją­ce na obiek­to­wych meto­dach i wzor­cach ana­li­tycz­nych jed­nak nie jest to wie­dza wyma­ga­na do jego zrozumienia.

Po kolei…

Jedną z cech doku­men­ta­cji wyso­kiej jako­ści, jest wywo­dze­nie (kon­stru­owa­nie) każ­de­go wyma­ga­nia i pozo­sta­łych ele­men­tów mode­li od ogó­łu do szcze­gó­łu (meto­da ana­li­zy top-down) i wery­fi­ko­wa­nie ich w dru­gą stro­nę (meto­da ana­li­zy bot­tom-up). Nazywane jest to coraz czę­ściej jako tak zwa­ne śla­do­wa­nie (zależ­ność «tra­ce» na mode­lach popu­la­ry­zo­wa­na przez orga­ni­za­cję IIBA). Śladowanie pozwa­la przede wszystkim:

  1. uza­sad­nić każ­de wymaganie,
  2. uza­sad­nić każ­dy ele­ment pro­jek­tu implementacji,
  3. zwe­ry­fi­ko­wać kom­plet­ność i spój­ność całej dokumentacji,
  4. zapo­biec nie kon­tro­lo­wa­ne­mu roz­ro­sto­wi zakre­su projektu,
  5. umoż­li­wia oce­nę ren­tow­no­ści pro­jek­tu per każ­de wyma­ga­nie niezależnie.

Cóż to jest śladowanie? 

Przede wszyst­kim potrzeb­ny jest szczyt”, korzeń drze­wa śla­do­wa­nia. Powinien nim być cel biz­ne­so­wy pro­jek­tu, jak nie trud­no się domy­śleć, dla jed­ne­go pro­jek­tu powi­nien być zde­fi­nio­wa­ny jeden cel głów­ny, on wyzna­cza kie­ru­nek. Możliwe są cele skła­do­we, pod­rzęd­ne, ale jeden głów­ny jest wymagany.

Jednym z pod­sta­wo­wych ele­men­tów stra­te­gii osią­ga­nia celów biz­ne­so­wych jest ulep­sza­nie pro­ce­sów biz­ne­so­wych w orga­ni­za­cji. w tym celu wyko­nu­je się audyt orga­ni­za­cji, któ­re­go pro­duk­tem jest jej peł­ny model, ten zawie­ra mię­dzy inny­mi, jako skła­do­we, mode­le pro­ce­sów biznesowych.

Każdy pro­ces biz­ne­so­wy to jed­na lub sze­reg powią­za­nych czyn­no­ści. Wymagania są koja­rzo­ne (wywo­dzo­ne) z tych czyn­no­ści, któ­re pla­nu­je­my uspraw­nić np. z pomo­cą narzę­dzia jakim jest pla­no­wa­ne nowe lub roz­bu­do­wy­wa­ne oprogramowanie.

W przy­pad­ku opro­gra­mo­wa­nia dedy­ko­wa­ne­go, to jest two­rzo­ne­go na zamó­wie­nie, tymi wyma­ga­nia­mi są ocze­ki­wa­ne usłu­gi, tak zwa­ne przy­pad­ki uży­cia, opro­gra­mo­wa­nia (sys­te­mu). Są one wywo­dzo­ne z tych czyn­no­ści, któ­re nowe opro­gra­mo­wa­nie ma wspie­rać. Tak się okre­śla zakres pro­jek­tu, któ­ry jak widać, też wywo­dzo­ny jest z mode­lu (pro­ce­sów).

Kolejny pro­jek­to­wa­ny ele­ment to model dzie­dzi­ny sys­te­mu. Zawiera on obiek­ty biz­ne­so­we oraz ele­men­ty odpo­wie­dzial­ne za reali­za­cje każ­dej usłu­gi nowe­go opro­gra­mo­wa­nia. Są to kla­sy (i obiek­ty) w mode­lu dzie­dzi­ny. Każdy przy­pa­dek uży­cia jest wywo­dzo­ny z czyn­no­ści w pro­ce­sie, kla­sy ste­ru­ją­ce są wywo­dzo­ne z przy­pad­ków uży­cia, kla­sy repre­zen­tu­ją­ce obiek­ty prze­twa­rza­ne, są wywo­dzo­ne z doku­men­tów i zdarzeń.

Dalej z przy­pad­ków uży­cia wywo­dzo­ne są dia­gra­my sekwen­cji mode­lu­ją­ce sce­na­riu­sze zacho­wa­nia sys­te­mu w reak­cji na dzia­ła­nia użyt­kow­ni­ka (tak zwa­ne­go akto­ra). Klasy na mode­lach sekwen­cji są wywo­dzo­ne z mode­lu dziedziny.

Jeżeli model pro­ce­sów biz­ne­so­wych zawie­ra defi­ni­cje reguł biz­ne­so­wych, wywo­dzo­ne są z nich kla­sy lub ich ope­ra­cje, odpo­wie­dzial­ne za prze­strze­ga­nie” tych reguł.

Śladowanie w opi­sa­nej powy­żej kon­wen­cji ma nastę­pu­ją­ca postać:

Jak widać nad­zo­ro­wa­nych jest (śla­do­wa­nie) wie­le logicz­nych sko­ja­rzeń. Tego rodza­ju dia­gra­mów w pro­jek­cie jest nie mało, nie raz kil­ka­dzie­siąt i wię­cej, logicz­nych połą­czeń (czer­wo­ne linie prze­ry­wa­ne obra­zu­ją­ce śla­do­wa­nie) są więc set­ki. Jak nie­trud­no się domy­śleć, ręcz­ne” śle­dze­nie tych powią­zań jest prak­tycz­nie nie moż­li­we. (podob­nie zresz­tą jak ręcz­ne opra­co­wy­wa­nie zło­żo­nych rapor­tów finan­so­wych z tysię­cy danych).

Bez spe­cjal­ne­go narzę­dzia utrzy­ma­nie wyso­kiej jako­ści pro­jek­tu jest prak­tycz­nie nie moż­li­we przy zacho­wa­niu roz­sąd­ne­go nakła­du pra­cy. Narzędzia te to pakie­ty opro­gra­mo­wa­nia wspo­ma­ga­ją­ce pro­jek­to­wa­nie CASE (ang. com­pu­ter aided sys­tems engi­ne­ering lub com­pu­ter aided softwa­re engi­ne­ering, oso­bi­ście pre­fe­ru­je to pierw­sze roz­wi­nię­cie tego skrótu).

Jak zapew­ne czy­tel­ni­cy już zauważyli,…

…mode­le bez sys­te­mu śla­do­wa­nia są prak­tycz­nie nie­we­ry­fi­ko­wal­ne, ich jako­ści nie da się oce­nić a ich sto­so­wa­nie jest wyso­ce ryzy­kow­ne o ile w ogó­le sensowne.

Po co to wszystko? 

Jak wspo­mnia­no na począt­ku, do zapa­no­wa­nia na zło­żo­no­ścią pro­jek­tu i jego ren­tow­no­ścią. Kolejny powód to moż­li­wość wery­fi­ka­cji kom­plet­no­ści wyma­gań. Odkrywanie wyma­gań dopie­ro w trak­cie reali­za­cji pro­jek­tu (wery­fi­ka­cja wyma­gań dopie­ro z pomo­cą kolej­nych jego pro­to­ty­pów) to powszech­nie zna­ny zabój­ca projektów”.

Dobrze opra­co­wa­ny, kom­plet­ny model orga­ni­za­cji, jego wyko­na­nie poprze­dza opi­sa­ny powy­żej model, łączy w sobie:

  1. model moty­wa­cji biz­ne­so­wej,
  2. model struk­tu­ry organizacyjnej,
  3. model pro­ce­sów biz­ne­so­wych (wymie­nio­ny już powyżej),
  4. model reguł biz­ne­so­wych.

Elementy każ­de­go z tych mode­li są ze sobą powią­za­ne: role w pro­ce­sach są wywo­dzo­ne ze sta­no­wisk w mode­lu orga­ni­za­cyj­nym, ana­li­zo­wa­ne pro­ce­sy są wywo­dzo­ne ze stra­te­gii w mode­lu moty­wa­cji, regu­ły biz­ne­so­we są koja­rzo­ne z czyn­no­ścia­mi w pro­ce­sach i wywo­dzo­ne z aktów praw­nych i wewnętrz­nych zarządzeń.

Mając tak opra­co­wa­ny kom­plet­ny model orga­ni­za­cji, zawie­ra­ją­cy śla­do­wa­nie, i odpo­wied­nie opro­gra­mo­wa­nie CASE moż­na prze­pro­wa­dzić ana­li­zę oddzia­ły­wa­nia, np. spraw­dzić na jakie oso­by w orga­ni­za­cji prze­nie­sie się zmia­na wybra­nych reguł biz­ne­so­wych. Mając model sys­te­mu infor­ma­tycz­ne­go sko­ja­rzo­ny z pro­ce­sa­mi, moż­na spraw­dzić wpływ awa­rii poszcze­gól­nych pod­sys­te­mów na pro­ce­sy biz­ne­so­we i ich skut­ki dla fir­my. Takich ana­liz moż­na wyko­nać wie­le, nie było by to moż­li­we bez tak skon­stru­owa­ne­go modelu.

Dlatego, pod­sta­wo­wą war­to­ścią popraw­nie wyko­na­nych mode­li orga­ni­za­cji i uży­cia wła­ści­wych narzę­dzi, jest nie tyl­ko opra­co­wa­nie wyma­gań np. na opro­gra­mo­wa­nie. Możliwe jest testo­wa­nie reak­cji ele­men­tów struk­tu­ry orga­ni­za­cji na zda­rze­nia np. awa­rie. Możliwe jest opra­co­wa­nie pro­jek­tów inte­gra­cji, wymia­ny opro­gra­mo­wa­nia. Możliwe jest spraw­dze­nie na co ma wpływ np. nie­ocze­ki­wa­na nie­obec­ność pra­cow­ni­ka. To tyl­ko wybra­ne przy­kła­dy, jed­nak moż­li­we jest to wyłącz­nie pod warun­kiem posia­da­nia popraw­nie wyko­na­ne­go modelu.

Wartość doda­na takiej ana­li­zy może być bar­dzo duża. Jeżeli podej­mu­je się decy­zje o inwe­sty­cjach rzę­du setek tysię­cy a nie raz dzie­sią­tek milio­nów zło­tych to wspar­cie tych decy­zji ana­li­za­mi, któ­rych war­tość jest o rząd albo dwa rzę­dy mniej­sza ma głę­bo­ki sens…

Jedno wymaganie – kilka perspektyw

Wpadł mi nie­daw­no do skrzyn­ki mailo­wej kolej­ny arty­kuł ser­wi­su Modern Analyst, cytat:

If you cre­ate only one view of the requ­ire­ments, you must belie­ve it. You have no other cho­ice. If you deve­lop mul­ti­ple views, tho­ugh, you can com­pa­re them to look for discon­nects that reve­al errors and dif­fe­rent inter­pre­ta­tions. (źr. Why Create Multiple Requirements Views? > Business Analyst Community & Resources | Modern Analyst > Business Analyst Articles & Systems Analysis Articles | Modern Analyst).

Autor suge­ru­je by łączyć wyma­ga­nia funk­cjo­nal­ne z przy­pad­ka­mi uży­cia, testa­mi, mode­la­mi. W dużym uprosz­cze­niu: jeże­li mamy tyl­ko jed­ną per­spek­ty­wę wyma­gań (np. w posta­ci listy wyma­gań funk­cjo­nal­nych i poza­funk­cjo­nal­nych) musi­my im wie­rzyć bo nie mamy ich wery­fi­ka­to­ra (nie mamy inne­go wyj­ścia). Troszkę to łącze­nie każ­dy z każ­dym” chy­ba jed­nak nie ułatwia:

źr. http://​www​.moder​na​na​lyst​.com/

Problem kom­plet­no­ści i spój­no­ści wyma­gań jest dość trud­ny do roz­wią­za­nia. Wymagania nie­kom­plet­ne i nie­spój­ne potra­fią zaś zabić pro­jekt, wady spe­cy­fi­ka­cji (takie jak nie­kom­plet­ność i nie­spój­ność) skut­ku­ją odkry­wa­niem ich w trak­cie pro­jek­tu, rośnie w nie­kon­tro­lo­wa­ny spo­sób zło­żo­ność projektu.

Jeżeli wypra­cu­je­my wię­cej per­spek­tyw, może­my je skon­fron­to­wać i porów­nać, wykry­wa­jąc ewen­tu­al­ne nie­ści­sło­ści i błę­dy. Także [[BABoK]] (rodem z [[IIBA]]) zale­ca utrzy­my­wa­nie tak zwa­nej śla­do­wal­no­ści, to jest wywo­dze­nia np. wyma­gań na opro­gra­mo­wa­nie z wyma­gań biz­ne­so­wych, a tych z celu pro­jek­tu. Nadal jed­nak mamy tyl­ko jed­no źró­dło dla każ­de­go wyma­ga­nia. To rodzi pew­ne ryzy­ko, gdyż brak wery­fi­ka­to­ra powo­du­je, że ryzy­ko błę­du pozostaje.

Od kil­ku lat sto­su­je meto­dę pole­ga­ją­cą na testo­wa­niu lub spe­cy­fi­ko­wa­niu reli­za­cji wyma­gań. Rok 2008, na zakoń­cze­nie arty­ku­łu IEEE830-1998 ? czy pro­du­ku­je dobre wyma­ga­nia? napisałem:

Metodyka, któ­rą stosuję

  1. Wymagania funk­cjo­nal­ne to przy­pad­ki uży­cia sys­te­mu; Przypadki uży­cia sys­te­mu to czyn­no­ści wyse­lek­cjo­no­wa­ne z mode­lu pro­ce­sów na bazie zakre­su projektu.
  2. Wymagania nie­funk­cjo­nal­ne to ogra­ni­cze­nia nakła­da­ne na poszcze­gól­ne przy­pad­ki uży­cia (mogą być gru­po­wa­ne np. mak­sy­mal­ny czas odpo­wie­dzi sys­te­mu nie może prze­kro­czyć 1 s. z wyjąt­kiem rapor­tów, gdzie mak­sy­mal­ny czas odpo­wie­dzi to 1 minuta)
  3. Wymagania dzie­dzi­no­we opi­sy­wa­ne są mode­lem dzie­dzi­ny sys­te­mu (dia­gram klas lub ERD)

c.d. kie­dyś nastąpi?

Tak więc mamy ciąg dal­szy :). Wspomniałem o wyma­ga­niach dzie­dzi­no­wych. Osobiście trak­tu­ję je wła­śnie jako trze­cią nogę” wspie­ra­ją­cą model wyma­gań. Funkcjonalność (usłu­ga sys­te­mu) mówi nam cze­go ocze­ku­je użyt­kow­nik, jed­nak usłu­ga sys­te­mu” opi­su­je sys­tem jako tak zwa­ną czar­ną skrzyn­kę”. Jeżeli uzu­peł­ni­my opis wyma­gań ele­men­ta­mi mode­lu dzie­dzi­ny, doda­my wery­fi­ka­tor w posta­ci opi­su wnę­trza tej czar­nej skrzyn­ki (wyma­ga­my nie tyl­ko two­rze­nia fak­tu­ry VAT” ale defi­niu­je­my jej struk­tu­rę, to się nazy­wa opis bia­łej skrzynki”).

Jak wspo­mnia­łem swe­go cza­su, opra­co­wu­jąc wyma­ga­nia na goto­we i zaawan­so­wa­ne opro­gra­mo­wa­nie nie ma sen­su jego pro­jek­to­wa­nie. Zbyt szcze­gó­ło­wa spe­cy­fi­ka­cja zbli­ża nas do pro­jek­tu, a my chce­my jed­nak coś goto­we­go (ma być taniej i szybciej).

Standardowo, spe­cy­fi­ku­jąc wyma­ga­nia, nale­ży sku­pić się na tym do cze­go będzie­my uży­wa­li opro­gra­mo­wa­nia a nie na tym jak ono to robi. Jednak do cze­go” ozna­cza co będzie­my two­rzyć i prze­twa­rzać”. Co więc robić? Proszę popatrzeć:

Tak więc wymaganie:

  1. koja­rzy­my z reali­zu­ją­cym je mode­lem (przy­pad­kiem uży­cia, pro­ce­sem, ele­men­tem dziedziny),
  2. koja­rzy­my z testem spraw­dza­ją­cym czy zosta­ło speł­nio­ne (z pomo­cą dobra­ne­go sce­na­riu­sza testowego).

Powszechnie posłu­gu­je­my się wyma­ga­nia­mi funk­cjo­nal­ny­mi. Czym jest wyma­ga­nie dzie­dzi­no­we? Wyobraźmy sobie, że chce­my opi­sać wszyst­kie meto­dy i sce­na­riu­sze wysta­wie­nia fak­tu­ry VAT. Będzie ich bar­dzo dużo, zapew­ne moż­li­we będą takie, któ­rych nie wymy­śli­li­śmy”. Bezpieczniej jest opi­sać fak­tu­rę VAT wraz z regu­ła­mi rzą­dzą­cy­mi jej poszcze­gól­ny­mi pola­mi, zamiast uznać ją za czar­ną skrzyn­kę” i pró­bo­wać opi­sać meto­dą jak moż­na jej użyć”.

Młotek moż­na opi­sać tym do cze­go będzie uży­wa­ny” (przy­pad­ki uży­cia) lub jak wyglą­da”. Nie raz dru­ga meto­da jest bez­piecz­niej­sza, jed­nak jest to już pro­jek­to­wa­nie i nale­ży to robić świa­do­mie. Czy to źle? Nie, bo nie raz zapro­jek­to­wa­nie jest mniej ryzy­kow­ne niż opis do cze­go” (zamiast zło­żo­ne­go opi­su wie­lu zasto­so­wań młot­ka, pro­ściej jest go narysować).

Zawsze, przy każ­dym wyma­ga­niu, nale­ży pod­jąć decy­zję, czy reali­za­cja wyma­ga­nia przez dostaw­cę sta­no­wi ryzy­ko (i jakie). Sami pro­jek­tu­je­my reali­za­cję (two­rzy­my model) zawsze, gdy to ryzy­ko jest za duże by je akcep­to­wać. Podobnie trak­tu­je­my testy. Projektujemy je, gdy koszt nie­speł­nie­nia dane­go wyma­ga­nia prze­kra­cza dopusz­czal­ny poziom. Testem może być tak­że model (np. pro­ce­su biznesowego).

Takie podej­ście powo­du­je, że zanim jesz­cze dotknie­my goto­we­go pro­duk­tu (tu nie­ste­ty już po jego wybo­rze) może­my po pierw­sze: prze­te­sto­wać samą spe­cy­fi­ka­cję a po dru­gie prze­ka­zać poten­cjal­ne­mu dostaw­cy (na eta­pie zapy­ta­nia) peł­ną infor­ma­cję o tym, cze­go ocze­ku­je­my od pro­duk­tu i jak to sprawdzimy.

Powyższe podej­ście w posta­ci «full wypas” może być pra­co­chłon­ne, dla­te­go moż­li­we są warian­ty pośred­nie, czy­li tyl­ko dla wyma­gań ozna­czo­nych jako ryzy­kow­ne budu­je­my testy lub mode­le, jed­nak mamy narzę­dzie do pano­wa­nia nad tym ryzy­kiem. Po dru­gie zysku­je­my narzę­dzie do wery­fi­ka­cji, odbiór opro­gra­mo­wa­nia nie będzie spraw­dza­niem pokaź­nej i ryzy­kow­nej zara­zem listy dzie­sią­tek cech, będzie jaz­dą prób­ną na sucho”, a więc rela­tyw­nie tanią i pew­ną meto­dą testów: dostaw­ca dekla­ru­je (ofer­ta na nasze zapy­ta­nie) zgod­ność z naszy­mi wyma­ga­nia­mi, a te są wery­fi­ko­wal­ne. Należy roz­wa­żać zawsze koja­rze­nie mode­li z testami.

Kiedy jesz­cze pisze­my reali­za­cję”? Gdy chce­my pozo­stać jej auto­ra­mi i chro­nić nasz know-how.

Ten straszny diagram klas

(aktu­ali­zo­wa­ny 2020) Gdybym miał oce­nić sta­ty­stycz­nie dia­gram klas opi­sy­wa­ny w książ­kach o UML , pro­jek­tach jakie widu­ję nie tyl­ko w pra­cach stu­den­tów, to powie­dział bym, że jest jakiś pro­blem z nimi. Dlaczego? Pokaże to, co moim zda­niem jest chy­ba nie tak. Szczególnie jak ktoś uwa­ża, że dia­gram klas do model danych co wprost pro­wa­dzi do antyw­zor­ca obiek­to­we­go o nazwie ane­micz­ny model dzie­dzi­ny ?*?Ten arty­kuł to kon­ty­nu­acja poprzed­nie­go arty­ku­łu o mode­lach dzie­dzi­ny sys­te­mu.

Co można i należy pokazać w wynikach analizy – taksonomia

Przede wszyst­kim ana­li­za to nie pro­jekt, powin­na poka­zać obiek­tyw­ny stan fak­tycz­ny. Druga rzecz, o tym już nie­któ­rzy zapo­mi­na­ją: wyni­kiem ana­li­zy jest doku­men­ta­cja zro­zu­mie­nia, tak więc model ana­li­tycz­ny nie może być mode­lem poka­zu­ją­cym stan po uprosz­cze­niach. To powi­nien być model rze­czy­wi­sto­ści z nanie­sio­ny­mi, zasto­so­wa­ny­mi lokal­nie, ogra­ni­cze­nia­mi i uprosz­cze­nia­mi. Innymi sło­wy: dla fabry­ki spodni budu­je­my kom­plet­ny model czło­wie­ka (mane­kin) z komen­ta­rzem, że tu w uży­ciu jest część od pasa w dół a nie wma­wia­my niko­mu, że w tej fabry­ce czło­wiek skła­da sie wyłącz­nie z bio­der i nóg. W prze­ciw­nym wypad­ku, przy­szła roz­bu­do­wa sys­te­mu będzie co naj­mniej problematyczna.

Produkt ana­li­zy prze­ka­zu­je infor­ma­cję o tym co zasta­no, opi­su­je poję­cia i regu­ły jakie nimi rzą­dzą. Tak na praw­dę, opi­sać fir­mę (orga­ni­za­cję) to zna­czy stwo­rzyć listę pojęć jaki­mi się w niej ope­ru­je (jaki­mi moż­na ją opi­sać) i regu­ły jakie ogra­ni­cza­ją swo­bo­dę uży­cia (funk­cjo­no­wa­nia) tych pojęć. Model poję­cio­wy (ich spe­cy­fi­ka­cja) to seman­ty­ka sys­te­mu, ogra­ni­cze­nia swo­bo­dy ich wza­jem­ne­go koja­rze­nia to syn­tak­ty­ka, i na koniec dzie­dzi­no­we ogra­ni­cze­nie swo­bo­dy ich uży­cia to prag­ma­ty­ka. Wkrada się tu tak­że przy­dat­ne poję­cie jakim jest entro­pia czy­li mia­ra nie­upo­rząd­ko­wa­nia. Tak więc mamy sys­tem pojęć, jego entro­pia (sto­pień nie­upo­rząd­ko­wa­nia) jest ogra­ni­czo­na syn­tak­ty­ką i prag­ma­ty­ką spe­cy­ficz­ną dla dzie­dzi­ny i miej­sca (orga­ni­za­cji). Co to ozna­cza dla ana­li­zy przedwdrożniowej?

Jednym z celów tej ana­li­zy jest odkry­cie i zapi­sa­nie wie­dzy o pod­mio­cie infor­ma­ty­zo­wa­nym”. Jak ją zapi­sać? Ano wła­śnie tak: zbu­do­wać listę pojęć i wska­zać opi­sa­ne ogra­ni­cze­nia. Doskonałym narzę­dziem do tego jest dia­gram klas (odra­dzam dia­gram ERD, moż­na go póź­niej zbu­do­wać w opar­ciu o model poję­cio­wy, jeże­li zaj­dzie taka potrze­ba, ale nie nale­ży tych dwóch mode­li sto­so­wać zamien­nie). Diagram klas opi­su­ją­cy taki sys­tem poję­cio­wy to tak zwa­na prze­strzeń poję­cio­wa (name­spa­ce) . Jak to wygląda:

Diagram klas, taksonomia

Od razu uwa­ga: powyż­szy dia­gram jest nad­mia­ro­wy, w real­nym pro­jek­cie bym tego tak nie nary­so­wał, ale po kolei.???

Podstawowe poję­cia (seman­ty­ka) ana­li­zo­wa­ne­go sys­te­mu to kla­sy ozna­czo­ne nie­bie­skim kolo­rem. Bardzo czę­sto zda­rza się, że pew­ne poję­cia moż­na lub nale­ży pokla­sy­fi­ko­wać, by prze­ka­zać infor­ma­cję o ist­nie­niu tej kla­sy­fi­ka­cji. Diagram ten moż­na wiec uzu­peł­nić na dwa spo­so­by: sto­su­jąc tak zwa­ne super­kla­sy (uogól­nie­nie, zebra­nie kil­ku wspól­nych cech) oraz tak zwa­ne ste­reo­ty­py, czy­li zna­cząc dodat­ko­wo kla­sy. Klasa uogól­nia­na nazy­wa­na jest spe­cja­li­za­cją. Na powyż­szym dia­gra­mie Zamówienie (spe­cja­li­za­cja) jest spe­cy­ficz­nym rodza­jem Dokumentu (uogól­nie­nie) a każ­dy doku­ment to coś będą­ce­go jakąś tre­ścią np. na papie­rze. Zamówienie jed­nak jest tak­że «obiek­tem biz­ne­so­wym», utrwa­lo­nym i zro­zu­mia­łym poję­ciem (bytem) w fir­mie, do cze­goś kon­kret­ne­go służy.

Jest pew­na seman­tycz­na róż­ni­ca pomię­dzy super-kla­są a ste­reo­ty­pem, gdyż uwa­żam, że tych pojęć nie moż­na sto­so­wać zamien­nie. Super-kla­sa poka­zu­je, że pew­ne byty są uogól­nia­ne (mają one jakieś wspól­ne cechy zebra­ne w tym uogól­nie­niu) i uogól­nie­nie to – jako poję­cie – jest sto­so­wa­ne w roz­mo­wie”. Stereotyp wska­zu­je na pew­ne ist­nie­ją­ce i istot­ne (chce­my to zako­mu­ni­ko­wać w doku­men­ta­cji) roz­róż­nie­nie pomię­dzy poję­cia­mi jed­nak nie jest ono sto­so­wa­ne w roz­mo­wie”. Można więc uznać, że poję­cie Dokument funk­cjo­nu­je w roz­mo­wie” na rów­ni z poję­ciem Zamówienie choć jest to poję­cie (Dokument) abs­trak­cyj­ne. Nie ist­nie­je coś takie­go jak ogól­ny doku­ment” ale poję­cie to jest powszech­nie sto­so­wa­ne w fir­mach, abs­trak­cje takie ozna­cza­my pisząc nazwę takiej kla­sy kur­sy­wą. Można tak­że powie­dzieć, że Zamówienie jest «obiek­tem biz­ne­so­wym» (coś istot­ne­go, uży­wa­ne­go) jed­nak raczej nikt nie uży­wa tego poję­cia na co dzień. Ten ste­reo­typ infor­mu­je czy­tel­ni­ka ana­li­zy, że to coś istot­ne­go (jakimś kontekście).

Wpłata jest zda­rze­niem, jed­nak zda­rze­nie to coś, co na co dzień nie jest trak­to­wa­ne jako rów­no­praw­ne sło­wo” w biz­ne­sie. Dlatego w tym przy­pad­ku w mode­lu użył­bym tyl­ko ste­reo­ty­pu «zda­rze­nie», by wska­zać, że jest to coś inne­go niż «obiekt biz­ne­so­wy» ale już nie użył bym, abs­trak­cyj­nej super­kla­sy Zdarzenie. Jeżeli jed­nak w toku pro­jek­to­wa­nia (etap po ana­li­zie) uzna­my, że chce­my prze­twa­rzać dane o tych zda­rze­niach zapro­jek­tu­je­my dla sys­te­mu kla­sę Zdarzenie.

Obiektem biz­ne­so­wym jest jed­nak Dowód Wpłaty (tak na praw­dę repre­zen­tu­je on to zda­rze­nie ale nie jest to toż­sa­me poję­cie: stwier­dze­nie wpła­ty nie jest dowo­dem wpła­ty). Te niu­an­se są bar­dziej oczy­wi­ste (mam nadzie­ję :)) na przy­kła­dzie klas Klient, Osoba, Pracownik, Sprzedawca. Widać tu tak­że ewi­dent­nie, że Klient jest wyłącz­nie Osobą.

Diagram ten zawie­ra tak­że pew­ne regu­ły biz­ne­so­we (ogra­ni­cze­nia entro­pii, czy­li swo­bo­dy). Są to liczeb­no­ści nanie­sio­ne na sko­ja­rze­nia (aso­cja­cje), linie łączą­ce kla­sy. Zaznaczono np. że Sprzedawca może mieć pod opie­ką klien­tów, tak­że żad­ne­go, jed­nak klient musi mieć i tyl­ko jed­ne­go opie­ku­na. Brak linii łączą­cej dwie kla­sy świad­czy zaś o tym, że nie ogra­ni­cza­ją się one nawza­jem w żaden spo­sób np. Wpłaty w żaden spo­sób nie wpły­wa­ją na Sprzedawcę i odwrot­nie. Istnieje jedy­nie pośred­ni zwią­zek mówią­cy, że moż­na sko­ja­rzyć Wpłatę ze Sprzedawcą, ele­men­tem koja­rzą­cym jest Faktura i jest ona tak­że kon­tek­stem tego sko­ja­rze­nia: Faktura jest pro­duk­tem pro­ce­su Sprzedaży, za któ­ry odpo­wia­da Sprzedawca. To jest powód, dla któ­re­go model pro­ce­sów powi­nien tak­że powstać jako jeden z pro­duk­tów takiej ana­li­zy bo to on zawie­ra tę wła­śnie informację.

Model dziedziny to projekt

A teraz model dzie­dzi­ny, przy­to­czę dia­gram uży­ty w poprzed­nim artykule:

Diagram klas, model dziedziny systemu

Jak widać jest pomię­dzy nimi istot­na róż­ni­ca. Jej źró­dłem jest to, że tak­so­no­mia to model poję­cio­wy zaś model dzie­dzi­ny (w rozu­mie­niu Model z wzor­ca MVC) to opis prze­twa­rza­nia. Przede wszyst­kim model dzie­dzi­ny nie zawie­ra pojęć abs­trak­cyj­nych. Dlaczego? No bo ich nie zapi­su­je­my i nie prze­twa­rza­my :)! Po dru­gie pew­ne poję­cia znik­nę­ły z mode­lu (Klient, jest akto­rem) bo Klient nie jest prze­twa­rza­ny, ale dane klien­ta będą atry­bu­ta­mi (nie zazna­czo­no) Zamówienia: jest on tu, Klient, zama­wia­ją­cym. Czytaj wię­cej o two­rze­niu i testo­wa­niu mode­lu dzie­dzi­ny.

Tak więc war­to zwró­cić uwa­gę na to, że dia­gram klas dia­gra­mo­wi nie rów­ny, to samo narzę­dzie może posłu­żyć do dwóch róż­nych celów w tej samej doku­men­ta­cji. Widać tak­że (mam nadzie­ję), że pró­ba poka­za­nia na jed­nym dia­gra­mie zarów­no sys­te­mu pojęć jak i spo­so­bu ich prze­twa­rza­nia, jako infor­ma­cji w sys­te­mach infor­ma­tycz­nych, jest raczej błęd­nym podej­ściem. Wydaje mi się, że podej­mo­wa­nie takich prób świad­czy o nie­zro­zu­mie­niu róż­ni­cy pomię­dzy sys­te­mem poję­cio­wym a mode­lem prze­twa­rza­nia infor­ma­cji. W szcze­gól­no­ści gdy doty­czy to sys­te­mów obiektowych.

Programistom pole­cam tak­że te stro­ny.


  1. ?*?
    https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​A​n​e​m​i​c​D​o​m​a​i​n​M​o​d​e​l​.​h​tml
  2. ???
    w 2015 roku zmie­ni­ła się spe­cy­fi­ka­cja UML, usu­nię­to poję­cie dzie­dzi­cze­nia i agre­ga­cji, suge­ru­ję uzu­peł­nić wie­dzę wpi­sa­mi, któ­re powsta­ły po 2015 roku. 

Źródła

Zelinski, J. (2020) Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns’, in Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities. IGI Global, pp. 78 – 89. Available at: https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699 (Accessed: 18 December 2019).
Fowler, M. (1997) Analysis pat­terns: reu­sa­ble object models. Menlo Park, Calif: Addison Wesley (The Addison-Wesley series in object-orien­ted softwa­re engineering).
Usman, M. et al. (2017) Taxonomies in softwa­re engi­ne­ering: A Systematic map­ping stu­dy and a revi­sed taxo­no­my deve­lop­ment method’, Information and Software Technology, 85, pp. 43 – 59. Available at: https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​1​7​.​0​1​.​006.
Stevens, P. (2007) UML Inżynieria opro­gra­mo­wa­nia. Translated by I. Jakóbik. Gliwice: Helion.
Booch, G., Rumbaugh, J. and Jacobson, I. (2002) UML prze­wod­nik użyt­kow­ni­ka. dru­gie wyda­nie. Warszawa: WNT (inży­nie­ria oprogramowania).

Domain Model – serce aplikacji

Całkiem nie­daw­no pisa­łem o two­rze­niu dia­gra­mów klas a kon­kret­nie mode­lu dzie­dzi­ny w odpo­wie­dzi na post pew­ne­go blo­ge­ra. Wymiana poglą­dów skoń­czy­ła się z e stro­ny adwer­sa­rza na zwró­ce­niu uwa­gi, iż dia­gram klas może poka­zy­wać wie­ce niż mój (bo może) ja zaś zwró­ci­łem uwa­gę na fakt, że dia­gram klas to jakiś model a model powi­nien mode­lo­wa jed­ne coś. Pokazanie na jed­nym dia­gra­mie klas dużo chy­ba mija się z celem bo moż­na zabrnąć w rejon gdzie spraw­dza się rekla­ma Banki od wszyst­kie­go są do nicze­go.

Tak więc for­su­ję tezę, że dia­gram klas to albo np. tak­so­no­mia albo np. model dzie­dzi­ny. W tym dru­gim przy­pad­ku jest to wsad do mode­lu opro­gra­mo­wa­nia, ten wsad to Model z wzor­ca MVC, a Model ten naj­le­piej stwo­rzyć sto­su­jąc zasa­dy [[DDD]]. Jednak w tym wypad­ku Model nie powi­nien być anemiczny:

Jednym z naj­częst­szych powo­dów powsta­wa­nia ane­micz­nych mode­li dome­no­wych jest spo­sób pro­jek­to­wa­nia apli­ka­cji w opar­ciu o wcze­śniej stwo­rzo­ny sche­mat bazy danych. To pro­wa­dzi to do tego, że model dome­no­wy powsta­je w sku­tek mapo­wa­nia tabel do klas posia­da­ją­cych odzwier­cie­dlo­ne kolum­ny w posta­ci wła­ści­wo­ści. Jedynym wyzwa­niem dla nie­któ­rych osób może być mode­lo­wa­nie rela­cji, któ­re w przy­pad­ku bazy danych są klu­cza­mi obcy­mi, zaś w przy­pad­ku obiek­to­we­go mode­lu powin­ny być rela­cja­mi do innych obiek­tów. Nie bra­ku­je oczy­wi­ście przy­kła­dów, gdzie rela­cje w mode­lu dome­no­wym two­rzo­ne są rów­nież w opar­ciu o klu­cze obce, co cał­ko­wi­cie zaprze­cza obiek­to­we­mu pro­gra­mo­wa­niu (źr. za pomo­cą Domain Model ? !FrAgile Thinking.)

Polecam cały arty­kuł (no ja pomi­ja­łem część zwią­za­ną z kodem bo nie pro­gra­mu­ję ;). Polecam przy oka­zji arty­kuł: http://​msdn​.micro​soft​.com/​e​n​-​u​s​/​m​a​g​a​z​i​n​e​/​d​d​4​1​9​6​5​4​.​a​spx

Diagram klas ? czyli ?reinżynieria? analizy biznesowej c.d. Przypadki użycia i granice systemu

Pora na przy­pad­ki uży­cia i gra­ni­ce sys­te­mu. W poprzed­niej czę­ści (Diagram klas ? czy­li ?rein­ży­nie­ria? ana­li­zy biz­ne­so­wej) wska­za­łem na poten­cjal­ne ryzy­ka opi­su user sto­ry i narzę­dzie niwe­lu­ją­ce tę wadę czy­li model pro­ce­su jaki opi­sał Zamawiający (hipo­te­tycz­ny autor opi­su User sto­ry). Tworzenie mode­lu ma dwa zada­nia: wery­fi­ka­cja spój­no­ści i kom­plet­no­ści opi­su Zamawiającego oraz stwo­rze­nie pod­sta­wy do okre­śle­nia zakre­su pro­jek­tu i wyspe­cy­fi­ko­wa­nia wyma­gań funk­cjo­nal­nych czy­li tak zwa­nych przy­pad­ków uży­cia. Czy tak się robi zawsze? Ja z zasa­dy (moja meto­dy­ka opra­co­wa­na na bazie doświad­czeń i lite­ra­tu­ry) trak­tu­ję KAŻDY opis, nawet w posta­ci struk­tu­ral­nej (tabe­le, punk­ty itp.), dostar­czo­ny przez Zamawiającego jako takie wła­śnie ryzy­kow­ne user sto­ry.

Czy to brak zaufa­nia dla Zamawiającego? Przecież to dla nie­go sys­tem, Zamawiający powi­nien umieć okre­ślić cze­go potrze­bu­je. Hm… każ­dy z nas potra­fi powie­dzieć do cze­go i jaki chce samo­chód, czy to zna­czy że potra­fi wyspe­cy­fi­ko­wać kon­struk­cję tego samo­cho­du? (mój mecha­nik jest bar­dziej dosad­ny, zawsze mówi: nie nic gor­sze­go od face­ta, któ­re­mu wyda­je się, że zna się na samo­cho­dach). Aby kupić goto­we opro­gra­mo­wa­nie o stan­dar­do­wej, powszech­nie sto­so­wa­nej funk­cjo­nal­no­ści, w zasa­dzie żaden ana­li­tyk nie jest nam potrzeb­ny. Jeżeli jed­nak chce­my coś, co choć trosz­kę ma paso­wać do nasze­go biz­ne­su i nie jest try­wial­ne nale­ży do tego podejść z więk­sza rezer­wą do wsze­la­kich oczy­wi­sto­ści, bo nie mówi­my już o prze­cięt­nym samo­cho­dzie ale o samo­cho­dzie, któ­rym wystar­tu­je­my w zawo­dach. Te zawo­dy to Wolny Rynek, star­cie z Konkurencją. Może nie zawsze jest to Formuła 1, ale też pra­wie nigdy nie jest to też jaz­da spa­ce­ro­wa na święta.

Wróćmy do nasze­go mode­lu pro­ce­sów. Ten, powsta­ły na bazie opi­su Zamawiającego pozwo­lił zna­leźć luki i nie­spój­no­ści, jest jed­nak zbyt szcze­gó­ło­wy. To rzad­ki u mnie przy­pa­dek ana­li­zy bot­tom-up (od szcze­gó­łu do ogó­łu) jed­nak pierw­sza sztyw­na zasa­da ana­li­ty­ka mówi: nie ist­nie­ją sztyw­ne zasa­dy ana­li­zy i pro­jek­to­wa­nia. Po drob­nych popraw­kach, uogól­nie­niu, model wyglą­da tak:

W zakre­sie pro­jek­tu mamy wszyst­kie czyn­no­ści, któ­re wraz z ich pro­duk­ta­mi sta­no­wią pro­ce­sy biz­ne­so­we, zosta­ły ona ozna­czo­ne ste­reo­ty­pem «usłu­ga apli­ka­cji» (ste­reo­ty­py nie są czę­ścią BPMN, moż­na je sto­so­wać do wska­za­nia powią­zań pomię­dzy obiek­ta­mi na mode­lach BPMN i UML gdzie będą im odpo­wia­da­ły przy­pad­ki użycia).

Po stro­nie Klienta (użyt­kow­ni­ka, dalej zwa­ne­go tak­że akto­rem) zasto­so­wa­no uprosz­cze­nie: jest mode­lo­wa­ny jak tak zwa­na czar­na skrzynka.

Będziemy bazo­wa­li na defi­ni­cji pro­ce­su biz­ne­so­we­go: pro­ces biz­ne­so­wy to czyn­ność lub logicz­nie powią­za­ny łań­cuch czyn­no­ści prze­kształ­ca­ją­cy pro­dukt na swo­im wej­ściu w pro­dukt (jego stan) na wyj­ściu. Różnica pomię­dzy tymi pro­duk­ta­mi sta­no­wi war­tość wno­szo­ną biz­ne­so­wą przez pro­ces.

Po stro­nie Sklepu mamy więc teraz pro­ce­sy (czyn­no­ści): Rejestracja Zamówienia, Rejestracja wpła­ty, Pakowanie i wysył­ka oraz Utworzenie rapor­tu o sta­nie zamówienia.

Kolejna rzecz to gra­ni­ce sys­te­mu. Dwa zało­że­nia, któ­re wyda­ją się bar­dzo roz­sąd­ne: Firma posia­da sys­tem ERP oraz płat­no­ści elek­tro­nicz­ne będą przed­mio­tem out­so­ur­cin­gu. Tak więc wyma­ga­nia na sys­tem to:

  1. przyj­mo­wa­nie zamówień,
  2. przyj­mo­wa­nie płat­no­ści dro­ga elektroniczną,
  3. inte­gra­cja z ERP: sys­tem ten odpo­wia­da za księ­go­wa­nie fak­tur i zarzą­dza­nie magazynem,
  4. uży­cie zewnętrz­ne­go ope­ra­to­ra płat­no­ści elektronicznych.

Powyższe wyda­je się roz­sąd­ne i bywa czę­sto spo­ty­ka­ne (sta­ram się by ten przy­kład aż tak nie odbie­gał od rze­czy­wi­sto­ści ;)). Wymagania powin­ny być zwię­złe ale tez nie powin­ny wykra­czać poza opis co powin­no być moż­li­we z nowym sys­te­mem. Tak więc dia­gram przy­pad­ków jaki stwo­rzy­łem uży­cia wyglą­da tak:

Kilka słów na temat tego dia­gra­mu. Mamy przy­pa­dek uży­cia dla każ­dej aktyw­no­ści. Każdy przy­pa­dek uży­cia powi­nien zostać udo­ku­men­to­wa­ny co naj­mniej trze­ma elementami:

  1. stan począt­ko­wy (warun­ki początkowe)
  2. sce­na­riusz
  3. ocze­ki­wa­ny stan końcowy

Kontekst sta­no­wi model pro­ce­sów wiec nie musi­my tu pisać czym są poprze­dza­ne i jakich mają następ­ców poszcze­gól­ne przy­pad­ki uży­cia. Wystarczy w mode­lach zacho­wać tak zwa­ne tra­ce­abi­li­ty (ja sto­su­ję pro­stą zasa­dę: nazwa przy­pad­ku uży­cia jest taka sama jak czyn­no­ści na mode­lu pro­ce­sów, z któ­rej został wypro­wa­dzo­ny, nazwy te są uni­kal­ne). Nie musi­my tak­że two­rzyć dia­gra­mów sce­na­riu­szy nad­rzęd­nych łań­cu­chów przy­pad­ków uży­cia bo zastę­pu­je je wła­śnie model BPMN. Na koniec uwa­ga: przy­pa­dek uży­cia powi­nien być samo­wy­star­czal­ny, inny­mi sło­wy musi mieć sens jako sam jeden (sam z sie­bie słu­ży do wyko­na­nia jakiejś logicz­nej czyn­no­ści dają­cej przy­dat­ny produkt).

Scenariusz naj­pro­ściej i naj­sku­tecz­niej jest opi­sy­wać w posta­ci dia­lo­gu Aktor <-> System. Ja sto­su­ję np. pro­sta tabe­lę z kolum­na­mi Aktor i System:

AKTOR                            SYSTEM
Inicjuje pracę                   Wyświetla listę produktów
Zaznacza wybrane produkty i OK   Wyświetla treść zamówienia
Potwierdza zamówienie            Wyświetla dane o płatności
Wybiera system płatności i OK    Kończy i ewentualnie przekazuje sterowanie

Tworzenie dia­gra­mów przy­pad­ków uży­cia w zasa­dzie war­to trak­to­wać tyl­ko jako spe­cy­fi­ka­cję kon­cep­cji zacho­wu­jąc zro­zu­mia­łość dla laika. Bąbelki powin­ny być tyl­ko spe­cy­fi­ka­cją funk­cjo­nal­ną i niczym ponad to. Ten dia­gram i tak nie zastą­pi dia­gra­mu klas, sekwen­cji czy tym bar­dziej opi­su pro­ce­su (tu był BPMN). Jak nie trud­no chy­ba już zauwa­żyć, doku­men­ta­cja zmie­rza w kie­run­ku kil­ku pro­stych mode­li (dia­gra­mów) zamiast jed­ne­go spa­ge­tii-mode­lu. Często spo­ty­kam się z doku­men­ta­mi, w któ­rych autor ana­li­zy wyma­gań wszyst­ko udo­ku­men­to­wał (sta­rał się) na dia­gra­mie przy­pad­ków uży­cia. To bywa straszne.

Potrzeby informacyjne firmy ? Zarządzanie wiedzą

Wprowadzenie

Problematyka infor­ma­cji w fir­mach, jej kolek­cjo­no­wa­nia i prze­twa­rza­nia jest czę­stym tema­tem arty­ku­łów w pra­sie spe­cja­li­stycz­nej jak i opi­sem zakre­sów pro­jek­tów IT. Termin ten jest jed­nak nie raz nad­uży­wa­ny. W pra­sie moż­na pozwo­lić sobie na pew­ną dowol­ność jego inter­pre­ta­cji jed­nak w opi­sie zakre­su pro­jek­tu ana­li­tycz­ne­go pozy­cja o nazwie ?Zdefiniowanie potrzeb infor­ma­cyj­nych fir­my? może rodzić poważ­ne kło­po­ty z odbio­rem tej czę­ści pro­jek­tu gdyż tu na dowol­ność inter­pre­ta­cji nie powin­no być miejsca.

Potrzeby informacyjne firmy

Czym są? Aby okre­ślić potrze­by infor­ma­cyj­ne fir­my musi­my wska­zać (opi­sać) to jaką wie­dzę chce­my posia­dać. To jest naj­trud­niej­sze. Potem, budu­je­my listę fak­tów, któ­rych reje­stra­cja jest wyma­ga­na do zgro­ma­dze­nia potrzeb­nej wie­dzy. Kolejnym kro­kiem jest okre­śle­nie jakie dane są wyma­ga­ne do opi­su tych fak­tów. Następnie budu­je­my model poję­cio­wy i struk­tu­rę danych opi­su­ją­cych te fak­ty. Na koniec imple­men­tu­je­my ten model danych two­rząc Bazę Danych.

Poniżej opi­sa­łem to w jaki spo­sób powsta­ła aku­rat taka kolej­ność i to, że Wiedza nie ist­nie­je, ist­nie­ją dane. Z mode­lem sta­je się to nie­co prostsze.

Definicje

Informacja – 1. ?wia­do­mość o czymś lub zako­mu­ni­ko­wa­nie cze­goś?, 2. ?dział infor­ma­cyj­ny urzę­du, insty­tu­cji?, 3. ?dane prze­twa­rza­ne przez kom­pu­ter? (źr. Słownik PWN)

Informacja – Informacja (łac. infor­ma­tio – wyobra­że­nie, poję­cie) to poję­cie o wie­lu defi­ni­cjach w róż­nych dzie­dzi­nach. Zasadniczo mamy dwa pod­sta­wo­we punk­ty widze­nia na infor­ma­cję. Pierwszy, któ­ry moż­na nazwać obiek­tyw­nym i wywo­dzi się z fizy­ki i mate­ma­ty­ki, gdzie infor­ma­cja ozna­cza pew­ną wła­sność fizycz­ną lub struk­tu­ral­ną obiek­tów, i dru­gi, subiek­tyw­ny (kogni­ty­wi­stycz­ny), gdzie infor­ma­cją jest to, co umysł jest w sta­nie prze­two­rzyć i wyko­rzy­stać do wła­snych celów. (źr. Wikipedia).

Dane – 1. ?fak­tylicz­by, na któ­rych moż­na się oprzeć w wywo­dach?, 2. ?infor­ma­cje prze­twa­rza­ne przez kom­pu­ter? (źr. Słownik PWN)

Dane (ang. data; z łac. datum – to, co jest dane) ? w infor­ma­ty­ce zbio­ry liczb i tek­stów o róż­nych for­mach. Są one uży­wa­ne przez kom­pu­te­ry do obli­czeń oraz są pre­zen­to­wa­ne, czy też prze­twa­rza­ne cyfro­wo. Takie tema­tycz­ne zbio­ry infor­ma­cji są nazwa­ne baza­mi danych. Bazy Danych są pod­sta­wo­wą czę­ścią sys­te­mów zarzą­dza­nia infor­ma­cją, sys­te­mów zarzą­dza­nia pro­jek­ta­mi czy kata­lo­gów pro­duk­tów. Układ danych przy­no­szą­cy kon­kret­ną infor­ma­cję to komu­ni­kat. (źr. Wikipedia).

Wiedza – 1. ?ogół wia­do­mo­ści zdo­by­tych dzię­ki bada­niom, ucze­niu się itp.; też: zasób infor­ma­cji z jakiejś dzie­dzi­ny?, 2. ?zna­jo­mość cze­goś? (źr. Słownik PWN)

Wiedza – ter­min uży­wa­ny powszech­nie, dotych­czas nie posia­da jesz­cze ogól­nie uzna­nej defi­ni­cji. Za kla­sycz­ną uzna­je się defi­ni­cję Platona z dia­lo­gu Teajtet, gdzie Sokrates w roz­mo­wie z Teajtetem docho­dzi do sfor­mu­ło­wa­nia defi­ni­cji, że wie­dza to praw­dzi­we, uza­sad­nio­ne prze­ko­na­nie. Nowa Encyklopedia Powszechna defi­niu­je wie­dzę jako ?ogół wia­ry­god­nych infor­ma­cji o rze­czy­wi­sto­ści wraz z umie­jęt­no­ścią ich wyko­rzy­sty­wa­nia?. (źr. Wikipedia)

Na bazie tych defi­ni­cji moż­na stwo­rzyć nastę­pu­ją­cy model pojęciowy:

? Fakty są komu­ni­ko­wa­ne przez wia­do­mo­ści, wia­do­mość komu­ni­ku­je fakt

? Fakty nio­są infor­ma­cje, infor­ma­cja to poj­mo­wa­nie faktów

? Informacja sta­no­wi widzę, wie­dza to zbiór informacji

Informacja a wiedza

Jak widać rela­cje te nie są skom­pli­ko­wa­ne jed­nak ich obraz poka­zu­je, że samo stwier­dze­nie ?baza wie­dzy? czy ?sys­tem infor­ma­cyj­ny? nabie­ra nie­co innej per­spek­ty­wy. Proszę zwró­cić uwa­gę na to, że nie ma tu bez­po­śred­nie­go powią­za­nia Wiadomości z Wiedzą. Można jed­nak powie­dzieć, że wia­do­mo­ści, jako opis fak­tów, nio­są infor­ma­cje, któ­re budu­ją naszą wie­dzę.

Czym są dane?

Otóż powyż­sze czte­ry poję­cia są tak na praw­dę nie­ma­te­rial­ne. Funkcjonują w naszych umy­słach. Dopiero ich utrwa­le­nia w posta­ci zapi­su na trwa­łym nośni­ku (ot choć­by pió­rem na papie­rze) czy­ni z fak­tów dane.

Mamy więc kolej­ny ele­ment tego mode­lu: Dane repre­zen­tu­ją Fakty, Fakty są doku­men­to­wa­ne przez Dane.

Jaki z tego wnio­sek? Pierwszy jaki się nasu­wa to to, że poję­cie Bazy Wiedzy jest trosz­kę ?nacią­ga­ne?. Dlaczego? Bo Wiedza to spo­sób inter­pre­ta­cji otrzy­my­wa­nych Wiadomości przez czło­wie­ka a pro­ces ten jest subiek­tyw­ny i zale­ży od kon­tek­stu prze­ka­za­nych wia­do­mo­ści. Kontekst zaś budu­ją wia­do­mo­ści poprze­dza­ją­ce. Podam przykład.

Wiadomość: ?w wyni­ku zde­rze­nia samo­cho­dów zgi­nę­ła jed­na oso­ba?. Na jej pod­sta­wie zbu­du­je­my sobie obraz koli­zji na dro­dze i ludz­kiej tra­ge­dii. Wiadomość ta jed­nak poprze­dzo­na (np. audy­cją radio­wą poda­ną godzi­nę wcze­śniej) prze­ka­zem o tre­ści ?Na dro­dze eks­pre­so­wej nr 48, w wyni­ku oblo­dze­nia, miał miej­sce wiel­ki karam­bol, zde­rzy­ło się 37 samo­cho­dów? wywo­ła nie­mal­że ulgę, że w takiej wiel­kiej kata­stro­fie zgi­nę­ła tyl­ko jed­na osoba.

Skoro więc nasza wie­dza bazu­je na wia­do­mo­ściach a ich inter­pre­ta­cja (poj­mo­wa­nie) bazu­je na kon­tek­ście to czym jest ta Wiedza? Kluczem tu są dane, to jak są maga­zy­no­wa­ne. Inaczej mówią to jak są repre­zen­to­wa­ne po ich utrwa­le­niu (rysu­nek powyżej).

Powoli nasu­wa się już chy­ba świa­do­mość tego, że dobra baza wie­dzy (czym by nie była) musi prze­cho­wy­wać dane opi­su­ją­ce i fak­ty i ich kon­tekst. Po dru­gie spo­sób repre­zen­ta­cji danych (ich zapi­su, utrwa­la­niu) powi­nien być jak naj­mniej podat­ny na ich subiek­tyw­ną inter­pre­ta­cję. Jak to osiągnąć?

Model pojęciowy jako model rzeczywistości

Dobrnęliśmy do poję­cia repre­zen­ta­cji danych. Najprostszą repre­zen­ta­cją danych jest nie­struk­tu­ral­ny tekst, popu­lar­nie zwa­ny pro­zą . Proszę zwró­cić uwa­gę na to, że nawet ten tekst to dane. Jaki z nim pro­blem? Ano trud­no jest w tej posta­ci wska­zać wia­do­mość, fakt, infor­ma­cję czy w koń­cu odpo­wie­dzieć na pyta­nie gdzie jest tu ta Wiedza. Wyobraźmy sobie dodat­ko­wo, że ten tekst (ten arty­kuł) pozba­wio­no ilu­stra­cji. Stałby się prak­tycz­nie tak nie­jed­no­znacz­ny, że każ­dy jego czy­tel­nik miał by pra­wo do jego wła­snej inter­pre­ta­cji (na szczę­ście są tu te dia­gra­my, dostęp­ne w wer­sji PDF, adres URL peł­nej wer­sji arty­ku­łu na koń­cu tekstu).

Powstaje potrze­ba takie­go zapi­su danych by były one zapi­sem fak­tów i nio­sły jed­nak ich kon­tekst, na tyle na ile to moż­li­we. Jaki to zapis?

Struktura informacji

Aby dane były moż­li­wie jed­no­znacz­ne i nio­sły kon­tekst muszą być zapi­sa­ne w spo­sób struk­tu­ral­ny i muszą mieć zde­fi­nio­wa­ną ich inter­pre­ta­cję czy­li tak zwa­ne meta­da­ne. Co to oznacza?

Za słow­ni­kiem języ­ka pol­skie­go: struk­tu­ra – 1. ?układ i wza­jem­ne rela­cje ele­men­tów sta­no­wią­cych całość?, 2. ?całość zbu­do­wa­na w pewien spo­sób z poszcze­gól­nych elementów?

Dodatkowo za WIKI: Metadane ? czy­li ?dane o danych?, [?]w przy­pad­ku bazy danych, meta­da­ny­mi są defi­ni­cje tabel, wido­ków, klu­czy itp. nato­miast dany­mi ? zawar­tość tych tabel, wido­ków (czy­li rekor­dy). W sys­te­mach zarzą­dza­nia doku­men­ta­mi meta­da­ne okre­śla się mia­nem metry­ki dokumentu.

Tak wiec mamy już wstęp­ną odpo­wiedź. Ale może przykład:

?Po jutrze, godzi­nę po Wiadomościach odbę­dzie spo­tka­nie człon­ków klu­bu twór­ców nie­jed­no­znacz­nych tek­stów w miej­scu tym samym co ostat­nio. Będziemy roz­ma­wia­li mię­dzy inny­mi o tym jak jesz­cze wydaj­niej zanu­dzać czy­tel­ni­ka, roz­wa­żać aspek­ty wpły­wu nud­nych tek­stów na sto­pień sen­no­ści adre­sa­ta prze­ka­zu oraz oce­ni­my wpływ naszych prac na tak zwa­ne zamu­la­nie sie­ci Internet.?.

Taki prze­kaz pozba­wio­ny kon­tek­stu jakim jest mię­dzy inny­mi dokład­ny czas nada­nia tej wia­do­mo­ści prak­tycz­nie nie nada­je się do jakiej­kol­wiek inter­pre­ta­cji (co nie zmie­nia fak­tu, że w takiej posta­ci czę­sto poda­wa­ne są zapo­wie­dzi spo­tkań w zapro­sze­niach prze­ka­zy­wa­nych pocz­tą elektroniczną)

Zapis struk­tu­ral­ny wyglą­dał by tak:

[Rodzaj zda­rze­nia]: Spotkanie

[Uczestnicy]: człon­ko­wie Klubu Twórców Niejednoznacznych Tekstów

[Termin]: 2008-10-06, godzi­na 20:00

[Miejsce]: klub Grafoman przy uli­cy Nudnej 24

[Treść]: Będziemy roz­ma­wia­li mię­dzy inny­mi o tym jak jesz­cze wydaj­niej zanu­dzać czy­tel­ni­ka, roz­wa­żać aspek­ty wpły­wu nud­nych tek­stów na sto­pień sen­no­ści adre­sa­ta prze­ka­zu oraz oce­ni­my wpływ naszych prac na tak zwa­ne zamu­la­nie sie­ci Internet.

Powyżej mamy struk­tu­ral­ny tekst (skła­da się z oddziel­nych powią­za­nych czę­ści), i meta­da­ne któ­ry­mi są nazwy (opi­sy) po lewej stro­nie dwu­krop­ków w kwa­dra­to­wych nawia­sach. Gdyby był to doku­ment (treść) w wer­sji ory­gi­nal­nej to pierw­sze czte­ry ele­men­ty tej struk­tu­ry mogły by sta­no­wić tak zwa­ną metry­kę całe­go doku­men­tu. Metryka doku­men­tu to nic inne­go na struk­tu­ral­ny opis zawar­to­ści (naj­czę­ściej skró­co­ny) nie­struk­tu­ral­ne­go tek­stu. Tak więc mamy opis tego co nazy­wa­my repre­zen­ta­cją danych.

Zaczynają się schody ? model dziedziny

Na począ­tek model danych. Model danych (bazy danych) to zbiór zasad (spe­cy­fi­ka­cji), opi­su­ją­cych struk­tu­rę danych w bazie danych. [?] Definiuje się tę struk­tu­rę danych poprzez spe­cy­fi­ka­cję repre­zen­ta­cji dozwo­lo­nych w mode­lu obiek­tów (encji) oraz ich związ­ków. (źr. WIKI)

Model danych to opis struk­tur, któ­re posłu­żą do kolek­cjo­no­wa­nia danych. Jest więc to nic inne­go jak struk­tu­ra obra­zu­ją­ca poję­cia i powią­za­nia mię­dzy nimi. Opisem takich struk­tur są mię­dzy inny­mi dia­gra­my takie jak te w tym arty­ku­le (co nie zmie­nia fak­tu, że są ludzie opi­su­ją­cy struk­tu­ry danych prozą).

[…] Jedyne co nam teraz pozo­sta­ło to imple­men­ta­cja mode­lu danych czy­li stwo­rze­nie bazy danych:

Obecnie coraz czę­ściej moż­na się spo­tkać z mode­la­mi obiektowymi.

Czy baza danych to wiedza?

[…]

Model jaw­nie poka­zu­je, że bez­po­śred­ni zwią­zek z Bazą Danych mają Dane. Dalej już są wyłącz­nie nie­ma­te­rial­ne poję­cia czym więc jest Zarządzanie Wiedzą (mil­czą­co zakła­dam, że zarzą­dzać moż­na czymś mate­rial­nym)? Jest to ?prze­cho­wy­wa­nie danych jed­no­znacz­nie zro­zu­mia­łych, opi­su­ją­cych okre­ślo­ne i ogra­ni­czo­ne licz­bą fak­ty inter­pre­to­wa­ne jako poj­mo­wal­na przez adre­sa­ta informacja?.

Przemyślenia zwią­za­ne z tą ostat­nią defi­ni­cją pozo­sta­wiam Państwu. Ciąg dal­szy może nastąpi?

Pobierz kom­plet­ne opracowanie: