Mało który deweloper używa UMLa zgodnie ze specyfikacją…

Od cza­su do cza­su wpa­da­ją mi do skrzyn­ki ema­il niu­slet­te­ry”, któ­re gdzieś tam cza­sem zama­wiam, głów­nie z powo­dów poznaw­czych. Oto jeden z nich…

Nie jest tajem­ni­cą, że na ryn­ku mamy róż­ne meto­dy pra­cy i wszyst­kie mają swo­ich zwo­len­ni­ków i prze­ciw­ni­ków czy może raczej kry­ty­ków. Tym razem przed­mio­tem bada­nia” był spo­sób opi­sa­nia pro­ble­mu i wnio­ski jakie autor wyciągnął.

Czytaj dalej… Mało któ­ry dewe­lo­per uży­wa UMLa zgod­nie ze spe­cy­fi­ka­cją…”

Model czy abstrakcja

[zak­tu­ali­zo­wa­ny lip 16, 2020 @ 13:28]

Niedawno pisa­łem na temat mode­lu sys­te­mu” i mode­lu dzie­dzi­ny sys­te­mu”. Oba te poję­cia są sobie bli­skie, pierw­sze jest bar­dzo ogól­ne, doty­czy sys­te­mu zawę­żo­ne­go do jego dzie­dzi­no­wej spe­cy­fi­ki. Model dzie­dzi­ny sys­te­mu to tak­że, w inży­nie­rii opro­gra­mo­wa­nia, nazwa kon­kret­ne­go kom­po­nen­tu, nazy­wa­ne­go Model, w archi­tek­tu­rze opar­tej na wzo­ru MVC. Swego cza­su pisa­łem, że (Czym jest a czym nie jest model dzie­dzi­ny…):

Pojęcie sys­tem ozna­cza albo deta­licz­ną struk­tu­rę okre­ślo­nej rze­czy­wi­sto­ści albo abs­trak­cję ją repre­zen­tu­ją­cą (model systemu).

Jest to stan­dar­do­we tłu­ma­cze­nie tego poję­cia w lite­ra­tu­rze z zakre­su teo­rii sys­te­mów a tak­że wła­śnie inży­nie­rii opro­gra­mo­wa­nia .

Mam wła­śnie za sobą kil­ka spo­tkań na tar­gach IT Future Expo. Dotyczyły mię­dzy inny­mi roli pro­duct owne­ra”, ana­li­ty­ka biz­ne­so­we­go i wymia­ny infor­ma­cji pomię­dzy deve­lo­pe­ra­mi i resz­tą świa­ta”. Okazuje się, że naj­więk­szym pro­ble­mem w pro­jek­cie jest: (a) zro­zu­mieć cze­go chce zama­wia­ją­cy biz­nes, (b) prze­two­rzyć to tak by deve­lo­per wie­dział co ma zaim­ple­men­to­wać. I tu nie­ste­ty jest pro­blem: deve­lo­per owszem jest bar­dzo dobry w imple­men­ta­cji… i w niczym wię­cej. Co cie­ka­we, pro­gra­mi­ści, z któ­ry­mi czę­sto mam do czy­nie­nia, nie potra­fią (nie chcą?) myśleć abs­trak­cyj­nie, ocze­ku­ją typo­wej kawy na ławę” (pierw­szy dzień pro­jek­tu a tu nagle ktoś pyta o typ pola nazwi­sko”). Gorzej, wie­lu z nich myśli wyłącz­nie o odda­niu kodu na jutro rano”. Paradoksalnie, nie mała rota­cja na sta­no­wi­skach pro­gra­mi­stów oraz regu­lar­ne prze­no­sze­nie wszel­kich kosz­tów i ryzyk na kupu­ją­ce­go (któ­ry tego nie wie, bo nie rozu­mie tej tech­no­lo­gii), powo­du­je, że prze­my­śla­na archi­tek­tu­ra cało­ści to coś cze­go nie nikt robi, deve­lo­per po pro­stu koduje…

Nie wal­czy­my z fak­ta­mi, musi­my się z nimi zmie­rzyć. Jak? Dać deve­lo­pe­ro­wi i egze­kwo­wać archi­tek­tu­rę i logi­kę sys­te­mu jako wyma­ga­nie, a nie zebra­ne wyma­ga­nia”. Niestety, oso­ba zwa­na ana­li­ty­kiem, nie powin­na postrze­gać swo­jej pra­cy jako kolek­cjo­ne­ra” („zbie­ra­nie wyma­gań” zawsze koja­rzy mi się ze zbie­ra­niem grzy­bów). Tak zwa­ny ana­li­tyk musi abs­tra­ho­wać od wszel­kich deta­li, bez tego pro­jekt zosta­nie już na samym począt­ku zabi­ty” ich ilo­ścią. To się nazy­wa utra­ta pano­wa­nia nad zło­żo­no­ścią pro­jek­tu” a w kon­se­kwen­cji utra­ta pano­wa­nia nad zakre­sem pro­jek­tu”. W arty­ku­le o zega­rze [1] opi­sa­łem jak to zro­bić, tu opi­szę źró­dła tego podejścia.

Analiza systemowa dziedziny problemu

Praca ana­li­ty­ka powin­na mieć cha­rak­ter nauko­wy”: na bazie fak­tów opi­su­je się logi­kę dzia­ła­nia ana­li­zo­wa­nej orga­ni­za­cji . Przede wszyst­kim trze­ba mieć świa­do­mość, że bada­nym sys­te­mem jest np. orga­ni­za­cja a nie tyl­ko sys­tem infor­ma­tycz­ny”. Organizacja (fir­ma, urząd, itp.) to sys­tem skła­da­ją­cy się z ludzi i narzę­dzi jakich uży­wa­ją a całość jest ste­ro­wa­na regu­ła­mi (pra­wo, regu­la­cje wewnętrz­ne nie­spi­sa­ne zasa­dy itp.). Część z tych narzę­dzi to opro­gra­mo­wa­nie. Jeżeli jest to opro­gra­mo­wa­nie pla­no­wa­ne do zaku­pu i wdro­że­nia, to zna­czy, że ktoś musi zro­zu­mieć stan obec­ny, zro­zu­mieć cele i zapro­jek­to­wać stan przy­szły, zakła­da­ją­cy ist­nie­nie nowe­go opro­gra­mo­wa­nia. Nie ma tu zna­cze­nia czy będzie to opro­gra­mo­wa­nie wspo­ma­ga­ją­ce pro­duk­cje czy praw­ni­ka i jego pracę. 

A gdzie wyma­ga­nia? Wymaganiem jest pro­jekt logi­ki (archi­tek­tu­ra) nowe­go opro­gra­mo­wa­nia. Czy to robo­ta ana­li­ty­ka? Tak, bo deve­lo­per jest od wyko­na­nia implementacji.

Zegar. Abstrakcja systemu

Przede wszyst­kim war­to upo­rząd­ko­wać uży­te tu poję­cia, któ­re są czę­sto mylo­ne lub źle interpretation:

  • abs­tra­hu­je­my od czegoś 
  • ide­ali­zu­je­my coś

Modelowanie pole­ga na abs­tra­ho­wa­niu od okre­ślo­nych szcze­gó­łów i stwo­rze­niu ide­ali­za­cji tak, by sku­pić się na isto­cie danej rze­czy. Dobry model opi­su­je wyłącz­nie mechanizm. 

Powinno paść pyta­nie: Co sys­tem robi? (będzie robił jak go wdrożymy).

Jeżeli był­by to zegar, to sys­tem wska­zu­je aktu­al­ny czas”. To jest biz­ne­so­wy cel, uzna­no, że potrzeb­na jest sta­ła zna­jo­mość aktu­al­nej godzi­ny, a nie my chce­my mieć zegar”.

Teraz decy­zja: Jak sys­tem to robi? Może to być zegar ścien­ny, ana­lo­go­wy, cyfro­wy, może to być sta­le włą­czo­ne radio. Decyzja brzmi: zegar ścien­ny ana­lo­go­wy (poni­żej pro­to­typ w posta­ci mock-up’u). 

I dopie­ro teraz wiem o co pytać dostawców!

Tu draż­li­wy moment. Jeżeli opi­sze­my to tyl­ko pro­sty­mi histo­ryj­ka­mi użyt­kow­ni­ka to może się skoń­czyć tak, że deve­lo­per po pro­stu stwo­rzy kil­ka­dzie­siąt obra­zów tar­czy zega­ra i będzie je wyświe­tlał np. na wiszą­cym ekra­nie. To nic inne­go jak lite­ral­nie zre­ali­zo­wa­ne zebra­ne wyma­ga­nia” (pro­szę się nie śmiać, tak to nie raz wyglą­da: hard­ko­do­wa­nie” wymagań).

Dlatego war­to jed­nak opra­co­wać abs­trak­cyj­ną archi­tek­tu­rę roz­wią­za­nia czy­li model opi­su­ją­cy mecha­nizm dzia­ła­nia tego co chce­my otrzymać:

To nam zagwa­ran­tu­je, że deve­lo­per nie pój­dzie na łatwi­znę, że nasz zegar będzie się dał w przy­szło­ści roz­wi­jać i mody­fi­ko­wać .

Teraz dopie­ro deve­lo­per, mając (i słusz­nie) nie­co zwią­za­ne ręce, opra­cu­je kon­cep­cję reali­za­cji (Jak sys­tem został zre­ali­zo­wa­ny?), my ją zatwier­dzi­my i dosta­nie­my np. to:

…albo opro­gra­mo­wa­nie zawie­ra­ją­ce trzy kom­po­nen­ty i wyświe­tlacz. Jak nam kie­dyś przyj­dzie do gło­wy doda­nie datow­ni­ka albo zamia­na tar­czy ana­lo­go­wej na cyfro­wą, to będzie to roz­wój opro­gra­mo­wa­nia a nie kosz­tow­ne pisa­nie od zera (gdy­by nam dano pro­jek­tor z fil­mem z nakrę­co­nym zega­rem ana­lo­go­wym). To jak ten sys­tem został zre­ali­zo­wa­ny zale­ży od deve­lo­pe­ra, jed­nak jego logi­ka i archi­tek­tu­ra powin­ny być opra­co­wa­ne wcze­śniej po stro­nie zama­wia­ją­ce­go i narzu­co­ne deve­lo­pe­ro­wi (inży­nie­rom).

Inny przy­kład. Popatrzmy na szklan­kę jako opi­sa­ne histo­ryj­ka­mi użyt­kow­ni­ka wymagania:

  • moż­li­wość picia kawy,
  • moż­li­wość prze­cho­wa­nia cukru,
  • moż­li­wość zła­pa­nia muchy na stole,
  • moż­li­wość pod­la­nia wodą kwiatów,
  • .…

Alternatywą dla tego opi­su będzie:

- Szklanka jako pro­jekt: szkla­ny cylin­drycz­ny pojem­nik o śred­ni­cy 8 cm i pojem­no­ści 250 ml”.

Zastanówcie się, któ­ry z powyż­szych opi­sów będzie więk­szym ryzy­kiem, jeże­li wyśle­my go do huty szkła jako zamó­wie­nie na 1000 szt. szkla­nek dla pra­cow­ni­ków… .

P.S.

Czy te moż­li­wo­ści” to przy­pad­ki uży­cia szklan­ki? Nie. Przypadek uży­cia szklan­ki, to co ona fak­tycz­nie robi (usłu­ga sys­te­mu), to przechowanie/magazynowanie sub­stan­cji cie­kłej lub syp­kiej z pew­ny­mi ogra­ni­cze­nia­mi taki­mi jak np. mak­sy­mal­na tem­pe­ra­tu­ra. Te moż­li­wo­ści to co naj­wy­żej histo­ryj­ki użyt­kow­ni­ka… któ­re są może dobrym mate­ria­łem do ana­li­zy ale nie są dobrym wyma­ga­niem. Większość pro­gra­mi­stów, jak dosta­nie tak opi­sa­ne moż­li­wo­ści” jako wyma­ga­nia, to je po pro­tu wprost zako­du­je i odda sys­tem zgod­ny z wyma­ga­nia­mi”… sami oceń­cie jego przy­dat­ność teraz i w przyszłości…

Źródła

Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Börger, E. (2018). Why Programming Must Be Supported by Modeling and How. In T. Margaria & B. Steffen (Eds.), Leveraging Applications of Formal Methods, Verification and Validation. Modeling (Vol. 11244, pp. 89 – 110). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑030 – 03418-4_6
Bertalanffy, L. van. (2003). General sys­tem the­ory: foun­da­tions, deve­lop­ment, appli­ca­tions (Rev. ed., 14. paper­back print). Braziller.
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.

Nieco zaawansowane techniki analizy i modelowania

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. 

Produkt analizy jako twierdzenie naukowe

Znakomita więk­szość pro­gra­mów zawie­ra ponad 10 krot­nie wię­cej kodu niż mogła by mieć, bo pro­gra­mi­ści czę­sto imple­men­tu­ją warian­ty zacho­wań a nie ich mecha­ni­zmy (co powo­du­je, że sys­te­my te są tyleż razy droż­sze niż mogły by być).

Prawie za każ­dym razem, gdy mówię (ale nie robię tego jed­nak zbyt czę­sto 😉 ), że sto­su­ję meto­dy nauko­we w ana­li­zie, spo­ty­kam się z zarzu­tem, że prze­sa­dzam. Zapewne nie ma sen­su epa­to­wa­nie w pro­jek­tach biz­ne­so­wych aka­de­mic­kim słow­nic­twem, nie ma zna­cze­nia dobór słow­nic­twa w nazwa­niu meto­dy pra­cy, bo zna­cze­nie ma skuteczność.

Twierdzenie naukowe

Poniżej defi­ni­cja tego czym jest twier­dze­nie naukowe:

Twierdzenie nauko­we ? zda­nie oznaj­mia­ją­ce speł­nia­ją­ce nastę­pu­ją­ce warun­ki :

  1. moż­na wobec nie­go sfor­mu­ło­wać kry­te­ria pozwa­la­ją­ce na eks­pe­ry­men­tal­ne, obser­wa­cyj­ne lub logicz­ne ich oba­le­nie (fal­sy­fi­ko­wal­ne według zasad Karla R. Poppera),
  2. ist­nie­ją regu­ły jego odczy­ta­nia, któ­re ogra­ni­cza­ją do skoń­czo­no­ści licz­bę ich inter­pre­ta­cji (kry­te­rium pre­cy­zji Józefa Bocheńskiego),
  3. odno­si się do empi­rycz­nie doświad­czal­nej lub logicz­nie defi­nio­wa­nej rze­czy­wi­sto­ści (tzw. widły Hume?a),
  4. jest ele­men­tem zbio­ru twier­dzeń para­dyg­ma­tu wyja­śnia­ją­ce­go rze­czy­wi­stość i pozwa­la­ją­ce­go na prze­wi­dy­wa­nie jej przy­szłych sta­nów (kon­cep­cja nauki nor­mal­nej T. S. Kuhna),
  5. twier­dze­nie będą­ce naj­prost­szym z moż­li­wych opi­sów świa­ta (tzw. Brzytwa Ockhama).

Graficznie sam pro­ces odkry­cia nauko­we­go moż­na poka­zać tak :

Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley. 

Celowo cytu­ję tu lite­ra­tu­rę z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, by poka­zać, że nie jestem odosob­nio­ny w tym podej­ściu. Dla porząd­ku poda­je tak­że defi­ni­cje poję­cia model:

model: sys­tem zało­żeń, pojęć i zależ­no­ści mię­dzy nimi pozwa­la­ją­cy opi­sać (mode­lo­wać) w przy­bli­żo­ny spo­sób jakiś aspekt rzeczywistości

Więcej o mode­lach w nauce: .

Inżynieria oprogramowania

Jeżeli uzna­my, że wynik zarów­no ana­li­zy jak i pro­jek­to­wa­nia, to tak­że mode­le (przyj­mu­je­my meto­dę pra­cy opar­tą na two­rze­niu mode­li: MDD/MDA czy­li model dri­ven deve­lop­ment”, MDA czy­li model dri­ven archi­tec­tu­re”, itp.), to w związ­ku z tym 

model, jako wynik ana­li­zy, moż­na potrak­to­wać jako twier­dze­nie nauko­we opi­su­ją­ce bada­ną (ana­li­zo­wa­ną) orga­ni­za­cję, jest on zara­zem wyma­ga­niem wobec opro­gra­mo­wa­nia (ma zostać zaimplementowany).

Wyjaśnienie: odnio­sę się do powyż­szej defi­ni­cji twier­dze­nia nauko­we­go (zgod­nie z powyż­szym pod poję­ciem model rozu­mie­my kom­plet doku­men­ta­cji zawie­ra­ją­cej mode­le, powsta­łej jako pro­dukt analizy):

  1. kry­te­rium fal­sy­fi­ka­cji: dopie­ro wska­za­nie w bada­nej orga­ni­za­cji fak­tu, któ­re­go nie opi­su­je opra­co­wa­ny model, pozwa­la uznać model (wynik ana­li­zy) za zły,
  2. ist­nie­ją regu­ły jego (mode­lu) odczy­ta­nia, czy­li do stwo­rze­nia mode­lu uży­to sfor­ma­li­zo­wa­nych nota­cji i sys­te­mów poję­cio­wych (np. BPMN, UML, BMM, SBVR itp),
  3. model powstał na bazie, i odno­si się wyłącz­nie do, zebra­nych w toku ana­li­zy fak­tów (w szcze­gól­no­ści doku­men­tów, któ­re powsta­ją w toku pra­cy ana­li­zo­wa­nej orga­ni­za­cji – doku­men­ty opi­su­ją fak­ty np. fak­tu­ra to opis fak­tu doko­na­nia sprzedaży),
  4. model pozwa­la na prze­wi­dy­wa­nie tego co zaj­dzie w odpo­wie­dzi na okre­ślo­ne bodź­ce (para­dyg­mat pro­ce­so­wy opi­su­ją­cy zacho­wa­nia i para­dyg­mat obiek­to­wy opi­su­ją­cy struk­tu­ry), mając model pro­ce­sów biz­ne­so­wych moż­na prze­wi­dzieć pro­dukt pro­ce­su, mając model apli­ka­cji moż­na prze­wi­dzieć pro­dukt każ­de­go przy­pad­ku użycia,
  5. opra­co­wa­ny model jest naj­prost­szy (mini­mal­ny) z moż­li­wych, czy­li nie da się już z nie­go usu­nąć nic bez spo­wo­do­wa­nia jego znisz­cze­nia (uczy­nie­nia nieprawdziwym).

Tu, dla dopeł­nie­nia, war­to dodać powszech­nie uzna­wa­ną w świe­cie nauki defi­ni­cję praw­dy (A.Tarski): twier­dze­nie praw­dzi­we to twier­dze­nie kore­spon­du­ją­ce z faktami.

Tak więc mamy to co chce­my czy­li kry­te­rium odbio­ru doku­men­ta­cji ana­li­tycz­nej i pro­jek­to­wej: nie jest to licz­ba stron a to, że mówi prawdę”. 

Z dru­giej stro­ny, nie­ste­ty nie ist­nie­je moż­li­wość wyka­za­nia popraw­no­ści doku­men­ta­cji powsta­łej w wyni­ku ankiet, wywia­dów czy burzy mózgów spi­sa­nej języ­kiem natu­ral­nym … .

cięż­ką arty­le­rię”, jak ta tu opi­sa­na, wyta­cza­my głów­nie dla pro­jek­tów ryzy­kow­nych i kosz­tow­nych… 😉 oraz wszę­dzie tam gdzie waż­na jest ochro­na know-how.

Dodatek

(dwa dni po publikacji)

Właśnie pode­sła­no mi link do cie­ka­we­go tekstu:

One of the most impor­tant ele­ments of eve­ry Business Analyst?s tool­kit is pro­cess mode­ling, which is also signi­fi­cant acti­vi­ty for Business Process Management pro­fes­sio­nals. For BPM mar­ket B? (Źródło: BPMN for Business Analysts ? why, when and how)

Przejrzałem treśc i wszyst­kie wypo­wie­dzi one krę­cą się” wokół doku­men­to­wa­nia, pre­zen­ta­cji w celu zatwier­dze­nia lub zgła­sza­nia uwag oraz nie­któ­rzy wska­zu­ją na moż­li­wość ryso­wa­nia zamiast kodo­wa­nia w celu wyko­na­nia”, albo prze­oczy­łem albo nikt nie zwró­cił uwa­gi na bar­dzo – mim zda­niem waż­ny ele­ment – two­rze­nie mode­lu orga­ni­za­cji czy­li two­rze­nie hipo­te­zy tak dzia­ła­cie” jako orga­ni­za­cja.

Problem w tym, że chy­ba więk­szość użyt­kow­ni­ków” tej (BPMN) – i nie tyl­ko – nota­cji, sto­su­je induk­cyj­ne meto­dy uwia­ry­gad­nia­nia tych mode­li, rozu­mia­nych raczej jako sche­ma­ty blo­ko­we. Podejście bazu­ją­ce na dowo­dzie z ilo­ści” (induk­cja): model pro­ce­sów jest dobry bo bar­dzo dużo osób (osób akcep­tu­ją­cych, recen­zen­tów) tak uzna­ło, jest chy­ba najgorsze.

To błąd logicz­ny: nie da się wyka­zać popraw­no­ści meto­dą induk­cyj­ną. Model owszem powi­nien być jako dia­gram zro­zu­mia­ły dla czy­tel­ni­ka, to nie ule­ga wąt­pli­wo­ści, jed­nak jego testy powin­ny pole­gać na wska­zy­wa­niu (szu­ka­niu) ewen­tu­al­nych fak­tów typu a tu mówi nie­praw­dę”. Innymi sło­wy model pro­ce­su nie jest dobry” (odzwier­cie­dla praw­dzi­wy mecha­nizm dzia­ła­nia orga­ni­za­cji) dla­te­go, że wszy­scy go zaak­cep­to­wa­li, jest dobry dla­te­go, że nikt nie zna­lazł (nie wska­zał) jego wady (nie pod­wa­żo­no go).

Projektów zakoń­czo­nych klę­ską, w któ­rych wszy­scy zaak­cep­to­wa­li doku­men­ta­cję” zna­my chy­ba wszy­scy masę.…

Tak więc ana­li­tyk, któ­ry pod­cho­dzi sys­te­mo­wo do ana­li­zy powi­nien two­rzyć hipo­te­zy tak to dzia­ła” i nie dowo­dzić ich popraw­no­ści, a cze­kać na wska­za­nie wad. Notacje (BPMN, UML, BMM, …) oraz mode­le two­rzo­ne z ich pomo­cą, są dosko­na­łym narzę­dziem do doku­men­to­wa­nia tych teorii.

Na zakoń­cze­nie pole­cam to 🙂

Źródła

Kitchenham, B., Pearl Brereton, O., Budgen, D., Turner, M., Bailey, J., & Linkman, S. (2009). Systematic lite­ra­tu­re reviews in softwa­re engi­ne­ering – A sys­te­ma­tic lite­ra­tu­re review. Information and Software Technology, 51(1), 7 – 15. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​n​f​s​o​f​.​2​0​0​8​.​0​9​.​009
Budgen, D. (2003). Software design (2nd ed). Addison-Wesley.
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.

Sens i znaczenie – Pisma semantyczne Fregego

Najpierw przy­po­mnę moją tezę z arty­ku­łu napi­sa­ne­go w 2011 roku:

Zaryzykuje tezę: ?Im więk­sza nie­jed­no­znacz­ność doku­men­tu wyma­gań tym więk­sze ryzy­ko, że pro­jekt będzie miał kłopoty?.Powyższe nie sta­no­wi żad­ne­go odkry­cia co nie zmie­nia fak­tu, że jakość więk­szo­ści doku­men­tów wyma­gań (owe 70%) jest sła­ba, na co wska­zu­ją sami ankie­to­wa­ni. (Źródło: Analityk biz­ne­so­wy czy­li wyple­nić dwu­znacz­ność z doku­men­tów ana­li­tycz­nych! | Jarosław Żeliński IT-Consulting)

Mam nadzie­ję, że to – ta krót­ka recen­zja – będzie sku­tecz­nym począt­kiem zachę­ca­nia do czy­ta­nia tego co powszech­nie nazy­wa się filozofią.

Ta pozy­cja to zbiór pism, wykła­dów Fregego, ja jed­nak pole­cam tę książ­kę głów­nie z powo­du dwóch z nich.

Pierwszy to Sens i zna­cze­nie”. Nie raz pisa­łem, a raczej ubo­le­wa­łem nad jako­ścią doku­men­tów będą­cych tak zwa­ny­mi ana­li­za­mi, jakie wpa­da­ją mi w ręce. Są to opa­słe i zara­zem pozba­wio­ne tre­ści doku­men­ty pisa­ne potocz­nym języ­kiem. Ich przy­dat­ność” nie raz raczej nale­ża­ło by nazwać szko­dli­wo­ścią”.

Nie da się stre­ścić, książ­ki któ­ra sama w sobie jest zwię­złym wywo­dem, lecz na pocie­sze­nie i zachę­tę nad­mie­nię, że książ­ka zawie­ra bar­dzo mało sym­bo­licz­nych wywo­dów. Frege pisze o logi­ce języ­kiem mówio­nym”, więc rów­nań sym­bo­licz­nych, zna­nych z lek­cji logi­ki, jest tam bar­dzo mało, a w tym roz­dzia­le ich nie ma…

Drugi obo­wiąz­ko­wy roz­dział to Co to jest funk­cja. Tu dowie­my się czym jest wyni­ka­nie. Oba te ese­je trak­tu­ją o, klu­czo­wych dla ana­li­zy, kwe­stiach defi­ni­cji pojęć, zro­zu­mia­ło­ści zdań i logi­ki ich kon­struk­cji, czy­li wszyst­kim tym co gwa­ran­tu­je jed­no­znacz­ność tre­ści, sądu. Sądem w logi­ce nazy­wa­my wynik wywo­du a w ana­li­zie i opi­sie wyma­gań, jest to pod­sta­wa zro­zu­mia­ło­ści i jed­no­znacz­no­ści tre­ści tego co opi­su­je­my: rekomendacji.

Analityk to nie ste­no­ty­pi­sta na spo­tka­niach i warsz­ta­tach. Zaryzykuję tezę, że każ­dy kto chce być ana­li­ty­kiem biz­ne­so­wym, musi posiąść umie­jęt­ność pozna­nia tego co pod­le­ga ana­li­zie, zapro­jek­to­wa­nia roz­wią­za­nia pro­ble­mu oraz wyar­ty­ku­ło­wa­nia rapor­tu, któ­ry musi być logicz­nie spój­nym i jed­no­znacz­nym tekstem. 

Pisma seman­tycz­ne, Gottlob Frege
Tłumaczenie: Bogusław Wolniewicz
Wydanie: drugie
Wydawnictwo Naukowe PWN, 2014
Wybór naj­waż­niej­szych prac nie­miec­kie­go filo­zo­fa Gottloba Fregego, któ­re poło­ży­ły fun­da­men­ty pod współ­cze­sną logi­kę i filo­zo­fię mate­ma­ty­ki. Autor przed­sta­wił sfor­ma­li­zo­wa­ny sys­tem aksjomatyczny.
diagram klas, ikony, stereotypy, dział handlowy

Jak identyfikować klasy?

Tytułowy pro­blem ma chy­ba każ­dy począt­ku­ją­cy . Jak słusz­nie zauwa­żył autor poniż­sze­go tekstu:

Eksperci od obiek­to­we­go podej­ścia do pro­ce­su two­rze­nia opro­gra­mo­wa­nia dzie­lą się na dwa obo­zy, w zależ­no­ści od pro­po­no­wa­ne­go przez nich spo­so­bu iden­ty­fi­ka­cji klas:

W opar­ciu o odpo­wie­dzial­no­ści klas (RDD – Responsibility Driven Design) – naj­pierw roz­po­zna­wa­ne są wszyst­kie odpo­wie­dzial­no­ści sys­te­mu (na pod­sta­wie potrzeb przy­szłych użyt­kow­ni­ków), a następ­nie, bazu­jąc na tych odpo­wie­dzial­no­ściach, wyróż­nia­ne są kla­sy, któ­rym przy­pi­su­je się odpo­wie­dzial­no­ści sys­te­mu. W ten spo­sób defi­niu­je się odpo­wie­dzial­no­ści klas, któ­re odpo­wia­da­ją zbio­ro­wi zacho­wań ich obiek­tów. Przykładem tego podej­ścia jest wyko­rzy­sty­wa­na w nie­któ­rych meto­dy­kach meto­da CRC.

W opar­ciu o dane (DDD – Data Driven Design) – podej­ście to pole­ga na iden­ty­fi­ko­wa­niu wszyst­kich danych w sys­te­mie i podzia­le ich na kla­sy, bez spe­cjal­ne­go roz­wa­ża­nia ich odpo­wie­dzial­no­ści. Przykładem tej tech­ni­ki jest iden­ty­fi­ka­cja rze­czow­ni­ków i fraz rze­czow­ni­ko­wych w tek­ście wyma­gań użytkownika. )

Niestety dalej jest gorzej bo autor tek­stu poświę­cił się prak­tycz­nie w cało­ści meto­dzie opar­tej na danych. Napisał Wyróżnianie klas poprzez iden­ty­fi­ka­cję rze­czow­ni­ków i fraz rze­czow­ni­ko­wych w tek­ście spe­cy­fi­ku­ją­cym wyma­ga­nia użyt­kow­ni­ka jest jed­ną z pod­sta­wo­wych i powszech­nie sto­so­wa­nych tech­nik.”. Zgodzę z bólem z tym, że jest to meto­da naj­czę­ściej sto­so­wa­na, jed­nak nie jest to pod­sta­wo­wa meto­da. Bazowanie, w ana­li­zie obiek­to­wej, na danych pro­wa­dzi pro­stą dro­gą do powsta­nia kon­struk­cji w posta­ci antyw­zor­ca o nazwie [[ane­micz­ny model dzie­dzi­ny]]. Ta meto­da ma rodo­wód z rela­cyj­ne­go mode­lu danych, gdzie dane iden­ty­fi­ko­wa­ne były wła­śnie jako rze­czow­ni­ki, z tego powo­du, że dane to z natu­ry rzeczowniki.

Nieco dalej autor pisze: Identyfikacja aso­cja­cji. Sposób postę­po­wa­nia przy iden­ty­fi­ka­cji aso­cja­cji jest podob­ny do spo­so­bu iden­ty­fi­ka­cji klas, z tą róż­ni­cą, że w tek­ście wyma­gań zamiast rze­czow­ni­ków (ogól­nie: fraz rze­czow­ni­ko­wych) wyszu­ki­wa­ne są cza­sow­ni­ki (ogól­nie: fra­zy cza­sow­ni­ko­we). Zgodnie z tą zasa­dą z powyż­sze­go przy­kła­du z biblio­te­ką moż­na wyde­du­ko­wać aso­cja­cje: wypo­ży­czy­ła (od fra­zy wypo­ży­czać”) oraz jest egzem­pla­rzem (od fra­zy może być kil­ka egzem­pla­rzy tej samej książ­ki”).”. W kon­se­kwen­cji poja­wia się idea (i potrze­ba) sto­so­wa­nia klas pośred­ni­czą­cych czy­li kon­struk­cji rodem z z mode­lu rela­cyj­ne­go, sto­so­wa­nych w celu roz­wią­zy­wa­nia związ­ków wie­le do wie­lu” (nie­do­pusz­czal­nych w mode­lu rela­cyj­nym a dopusz­czal­nych w mode­lu obiek­to­wym). Niestety to podej­ście to kon­se­kwen­cja trak­to­wa­nia dia­gra­mu klas jako mode­lu danych, co jest kom­plet­nym nie­po­ro­zu­mie­niem, jeśli uznać, że para­dyg­mat obiek­to­wy to uzna­nie, że sys­tem to zbiór obiek­tów współ­pra­cu­ją­cych w okre­ślo­nym celu” .

Autor koń­czy roz­dział tego pod­ręcz­ni­ka” dla stu­den­tów (PJWSTK) przy­kła­dem o nazwie Diagram klas dla biblioteki”. 

(źr.

Jednak dia­gram klas to nota­cja, a model (wyko­na­ny z uży­ciem tej nota­cji) może być albo mode­lem poję­cio­wym albo mode­lem struk­tu­ry sys­te­mu o okre­ślo­nym pozio­mie abs­trak­cji. Przykłady tam poda­ne to w zasa­dzie antyw­zor­ce (patrz tak­że M.Fowler: Anemic Domain Model): model z dzie­dzi­cze­niem nie­spe­cjal­nie nada­je się na model dzie­dzi­ny z uwa­gi na to, że dzie­dzi­cze­nie łamie zasa­dy uni­ka­nia ści­słych zależ­no­ści” (uży­cie dzie­dzi­cze­nia bar­dzo sil­nie uza­leż­nia wszyst­kie kla­sy pochod­ne od uogól­nia­ją­cych na szczy­cie hie­rar­chii). Zaś kom­po­zy­cje nie są sto­so­wa­ne w mode­lach poję­cio­wych, bo mode­le poję­cio­we to słow­ni­ki pojęć w for­mie gra­ficz­nej. Pojęcia mogą być z sobą powią­za­ne (aso­cja­cje) ale nie ma tu licz­no­ści czy zawie­ra­nia się w sobie (czy książ­ka skła­da się z egzem­pla­rzy książek”???).

Osobiście radzę ana­li­ty­kom i pro­jek­tan­tom sku­pić się na pro­jek­to­wa­niu obiek­tów, któ­re współ­pra­cu­ją: mają odpo­wie­dzial­no­ści i komu­ni­ku­ją się wywo­łu­jąc swo­je ope­ra­cje. Dane to pro­blem na sam koniec ana­li­zy a nie jest to coś, od cze­go nale­ży ja zaczy­nać. Karty CRC są dosko­na­łym narzę­dziem dla począt­ku­ją­cych, ana­li­za rze­czow­ni­ków chy­ba najgorszym.

Na koniec pole­cam jed­nak książ­ki, któ­re na stro­nach blo­ga cytu­ję (jeże­li już ktoś uwa­ża, że moje tek­sty są mało wiarygodne ;)).

Źródła

Wirfs-Brock, R., & McKean, A. (2009). Object design: roles, respon­si­bi­li­ties, and col­la­bo­ra­tions. Addison-Wesley.
Fowler, M. (1997). Analysis pat­terns: reu­sa­ble object models. Addison Wesley.