Obiektowy model systemu

Wprowadzenie

Na temat tak zwa­nych metod obiek­to­wych czę­sto moż­na spo­tkać tek­sty takie jak ten z wikipedii: 

Programowanie obiek­to­we (ang. object-orien­ted pro­gram­ming, OOP) ? para­dyg­mat pro­gra­mo­wa­nia, w któ­rym pro­gra­my defi­niu­je się za pomo­cą obiek­tów ? ele­men­tów łączą­cych stan (czy­li dane, nazy­wa­ne naj­czę­ściej pola­mi) i zacho­wa­nie (czy­li pro­ce­du­ry, tu: meto­dy). Obiektowy pro­gram kom­pu­te­ro­wy wyra­żo­ny jest jako zbiór takich obiek­tów, komu­ni­ku­ją­cych się pomię­dzy sobą w celu wyko­ny­wa­nia zadań. Podejście to róż­ni się od tra­dy­cyj­ne­go pro­gra­mo­wa­nia pro­ce­du­ral­ne­go, gdzie dane i pro­ce­du­ry nie są ze sobą bez­po­śred­nio zwią­za­ne. Programowanie obiek­to­we ma uła­twić pisa­nie, kon­ser­wa­cję i wie­lo­krot­ne uży­cie pro­gra­mów lub ich fragmentów

Portal mFiles podaje:

Programowanie obiek­to­we lub ina­czej pro­gra­mo­wa­nie zorien­to­wa­ne obiek­to­wo (ang. object-orien­ted pro­gra­ming, OOP) to para­dyg­mat pro­gra­mo­wa­nia przy pomo­cy obiek­tów posia­da­ją­cych swo­je wła­ści­wo­ści jak pola (dane, infor­ma­cje o obiek­cie) oraz meto­dy (zacho­wa­nie, dzia­ła­nia jakie wyko­nu­je obiekt). Programowanie obiek­to­we pole­ga na defi­nio­wa­niu obiek­tów oraz wywo­ły­wa­niu ich metod, tak aby współ­dzia­ła­ły wza­jem­nie ze sobą. (źr.: Programowanie obiek­to­we ? Encyklopedia Zarządzania)

Albo takie jak ten ze stro­ny JavaStart:

Programowanie obiek­to­we jest para­dyg­ma­tem pro­gra­mo­wa­nia, któ­ry opie­ra się o two­rze­nie apli­ka­cji w taki spo­sób, aby jak naj­le­piej odzwier­cie­dlać ota­cza­ją­cą nas rze­czy­wi­stość i aby model danych odda­wał spo­sób postrze­ga­nia świa­ta przez czło­wie­ka (czy­li, że na przy­kład że jabł­ko jest owo­cem, a nie kolo­ro­wą kulą). […] Poznasz tu zagad­nie­nia mię­dzy inny­mi takie jak kla­sa, obiekt, inter­fejs, czy kla­sa abs­trak­cyj­na i dzie­dzi­cze­nie. (Java – Programowanie Obiektowe | JavaStart)

Bardzo wie­lu auto­rów powie­la schemat: 

Założenia pro­gra­mo­wa­nia obiek­to­we­go
?Abstrakcja
?Hermetyzacja danych (enkap­su­la­cja)
?Dziedziczenie
?Polimorfizm

Programowanie obiek­to­we zakła­da łącze­nie danych i funk­cji w jed­nym obiekcie.

(wie­le mate­ria­łów w sie­ci, na ten temat, podob­nie jak i ten, nie zawie­ra danych auto­rów ani daty publikacji)

Przykłady z dość powszech­nie wyko­rzy­sty­wa­nych mate­ria­łów dydaktycznych:

Abstrakcyjną ideą pro­gra­mo­wa­nia obiek­to­we­go jest powią­za­nie sta­nu (danych, któ­re okre­śla­ne są zwy­kle pola­mi) i zacho­wa­nia (algo­ryt­my zwią­za­ne ze sta­nem i całym obiek­tem, okre­śla­ne sło­wem meto­dy). Program korzy­sta­ją­cy z obiek­to­wo­ści wyra­żo­ny jest jako zbiór takich obiek­tów, komu­ni­ku­ją­cych się pomię­dzy sobą w celu wyko­ny­wa­nia zadań. W pewien spo­sób jest to naj­bar­dziej intu­icyj­ne podej­ście do roz­wią­zy­wa­nia pro­ble­mów, bo w taki spo­sób ? trak­tu­jąc zagad­nie­nia jako obiek­ty wraz ze sta­nem i meto­da­mi; do roz­wią­zy­wa­nia pro­ble­mów pod­cho­dzi ludz­ki mózg. Typy obiek­tów nazy­wa­my kla­sa­mi. (źr. TI/Wstęp do pro­gra­mo­wa­nia obiek­to­we­go ? Brain-wiki)

(ten tekst tak­że nie zawie­ra danych auto­ra ani źródeł)

Programowanie zorien­to­wa­ne obiek­to­wo pole­ga na intu­icyj­nym, natu­ral­nym pisa­niu pro­gra­mów, poprzez mode­lo­wa­nie obiek­tów świa­ta rze­czy­wi­ste­go, ich atry­bu­tów i zacho­wań odpo­wied­ni­ka­mi opro­gra­mo­wa­nia. Programowanie zorien­to­wa­ne obiek­to­wo mode­lu­je tak­że komu­ni­ka­cję pomię­dzy obiek­ta­mi przez wia­do­mo­ści.
Obiekty mają atry­bu­ty (dane) i wyka­zu­ją zacho­wa­nie (funk­cje, meto­dy). Obiekty są ele­men­ta­mi opro­gra­mo­wa­nia do ponow­ne­go uży­cia, two­rzo­ne są z ?planów?zwanych kla­sa­mi. Różne obiek­ty mogą mieć wie­le takich samych atry­bu­tów i podob­ne zacho­wa­nia. (źr. dydak​ty​ka​.polsl​.pl ? kwmimkm )

W pro­gra­mo­wa­niu obiek­to­wym pro­gra­my defi­niu­je się za pomo­cą obiek­tów okre­śla­ją­cych dane rze­czy­wi­ste i funk­cji na nich ope­ru­ją­cych. Obiektowy pro­gram kom­pu­te­ro­wy wyra­żo­ny jest jako zbiór takich obiek­tów, komu­ni­ku­ją­cych się mię­dzy sobą w celu wyko­ny­wa­nia okre­ślo­nych zadań. 

Dziedziczenie porząd­ku­je i wspo­ma­ga poli­mor­fizm i inkap­su­la­cję
dzię­ki umoż­li­wie­niu defi­nio­wa­nia i two­rze­nia spe­cja­li­zo­wa­nych obiek­tów na pod­sta­wie bar­dziej ogól­nych. Dla obiek­tów spe­cja­li­zo­wa­nych nie trze­ba rede­fi­nio­wać całej funk­cjo­nal­no­ści, lecz tyl­ko tę, któ­rej nie ma obiekt ogólniejszy.

W typo­wym przy­pad­ku powsta­ją gru­py obiek­tów zwa­ne kla­sa­mi
oraz gru­py klas zwa­ne drze­wa­mi. Odzwierciedlają one wspól­ne cechy
obiek­tów. Każdy obiekt może (choć nie musi) mieć przod­ka, od któ­re­go się wywo­dzi. Np. każ­dy czło­wiek ma swo­je­go przod­ka w posta­ci rodzi­ca.
W zależ­no­ści od przy­ję­tej meto­do­lo­gii obiekt może mieć jed­ne­go lub wie­lu przod­ków. O ile może ist­nieć ogra­ni­cze­nie w posta­ci jed­ne­go przod­ka, o tyle takie­go ogra­ni­cze­nia nie ma co do licz­by potom­ków, któ­rych dany obiekt jest przod­kiem. Fakt posia­da­nia przod­ka wią­że się ści­śle z dziedziczeniem.

Dziecko jako obiekt może dzie­dzi­czyć po swo­ich przod­kach
takie atry­bu­ty, jak kolor oczu, wzrost itp. Obiekt może oprócz dzie­dzi­cze­nia atry­bu­tów odzie­dzi­czyć meto­dy, czy­li ? ana­lo­gicz­nie ? w naszym przy­kła­dzie dziec­ko może po swo­ich przod­kach odzie­dzi­czyć takie ?meto­dy? (zacho­wa­nia), jak skłon­ność do pale­nia papie­ro­sów, talent w wybra­nych dzie­dzi­nach życia, wcze­sne wsta­wa­nie itp. ?(Gryglewicz-Kacerka & Duraj, 2013)?

Ta prób­ka jest moim zda­niem repre­zen­ta­tyw­na, jeśli cho­dzi o treść publi­ka­cji na ten temat. Autorzy tych tre­ści, naj­czę­ściej pro­gra­mi­ści, sku­pia­ją się na funk­cjach, danych, i tak na praw­dę trak­tu­ją poję­cie obiek­to­we­go para­dyg­ma­tu” jak kolej­ne wcie­le­nie struk­tu­ral­ne­go kodu, tyle, że wg, innych zasad (obiekt łączą­cy dane i funk­cje, dzie­dzi­cze­nie itp.), co jest ogrom­nym uprosz­cze­niem. Sam fakt zasto­so­wa­nia wymie­nia­nych wyżej kon­struk­cji języ­ków zorien­to­wa­nych obiek­to­wo nie czy­ni pro­gra­mu obiek­to­wym, to kolej­ne wcie­le­nie pro­gra­mo­wa­nia struk­tu­ral­ne­go, gdzie blo­ki i pod­pro­gra­my zyska­ły nazwę obiek­tów a re-uży­cie kodu nazwę dzie­dzi­cze­nia. Paradygmat obiek­to­wy to przede wszyst­kim architektura. 

Jednak para­dyg­mat to tyl­ko umo­wa, pozo­sta­je sto­so­wa­nie wzor­ców i dobrych prak­tyk w toku projektowania. 

Prawie nikt nie pisze o ana­li­zie i pro­jek­to­wa­niu zorien­to­wa­nym obiek­to­wo, a cała idea pole­ga tu na zaczy­na­niu od ana­li­zy i pro­jek­to­wa­nia, potem dopie­ro się pro­gra­mu­je. Nie przy­pad­kiem naj­po­pu­lar­niej­szym skró­tem w lite­ra­tu­rze przed­mio­tu jest OOAD (ang. Object-Oriented Analysis and Design, Obiektowo Zorientowane Analiza i Projektowanie). 

Istotą obiek­to­we­go para­dyg­ma­tu w inży­nie­rii opro­gra­mo­wa­nia jest to, że wynik ana­li­zy jest zara­zem projektem!

Paradygmat obiektowy

Pół roku temu w arty­ku­le Paradygmat obiek­to­wy i Przypadki Użycia pisa­łem o para­dyg­ma­cie obiektowym:

Paradygmat obiek­to­wy, w swej isto­cie, nawią­zu­je do teo­rii sys­te­mów: sys­tem (ana­li­zo­wa­ny lub pro­jek­to­wa­ny) skła­da się z współ­pra­cu­ją­cych obiek­tów. Cechą obiek­tów jest ich her­me­ty­za­cja, któ­ra ozna­cza, że obiekt nie udo­stęp­nia (i nie współ­dzie­li) swo­jej wewnętrz­nej struk­tu­ry (imple­ment­cji), ma z oto­cze­niem wyłącz­nie okre­ślo­ne inte­rak­cje: wyko­ny­wa­ne ope­ra­cje. Inny­mi sło­wy obiekt reagu­je w okre­ślo­ny spo­sób na okre­ślo­ne bodź­ce, igno­ru­jąc wszel­kie pozo­sta­łe, a zbiór tych bodź­ców (ope­ra­cji) nazy­wa­my inter­fej­sem obiek­tu. Jedy­nym spo­so­bem pozy­ska­nie infor­ma­cji o obiek­cie jest ?zapy­ta­nie go o to?. 

Generalnie więc:

Paradygmat obiek­to­wy to przy­ję­cie zasa­dy: sys­tem skła­da się ze współ­pra­cu­ją­cych i nie­za­leż­nych obiek­tów, obiek­ty cechu­je okre­ślo­na odpo­wie­dzial­ność, współ­pra­ca obiek­tów pole­ga na wza­jem­nym wywo­ły­wa­niu (call) ope­ra­cji w celu uzy­ska­nia okre­ślo­ne­go efek­tu. Obiekty udo­stęp­nia­ją ope­ra­cje, jest to inter­fejs publicz­ny obiek­tu nazy­wa­ny tak­że jego kon­trak­tem (odpo­wie­dzial­ność). Obiekty ukry­wa­ją przed oto­cze­niem swo­ją wewnętrz­ną budo­wę (her­me­ty­za­cja) a kon­trakt gwa­ran­tu­je, że ta sama ope­ra­cja zawsze da ten sam efekt, nie­za­leż­nie od uży­te­go w danej chwi­li do jej reali­za­cji algo­ryt­mu (meto­dy), co nazy­wa­my poli­mor­fi­zmem. (patrz tak­że ).

Związek dzie­dzi­cze­nia jest sto­so­wa­ny w obiek­to­wych języ­kach pro­gra­mo­wa­nia ale nie jest on ele­men­tem (cechą) para­dyg­ma­tu obiek­to­we­go jako takie­go (został nawet usu­nię­ty z nota­cji UML w 2015 roku patrz UML 2.5). Związek dzie­dzi­cze­nia to spo­sób re-uży­cia kodu w języ­kach zorien­to­wa­nych obiek­to­wo i sta­no­wi sobą łama­nie pod­sta­wo­wej cechy obiek­tów jaką jest nie­za­leż­ność i her­me­ty­za­cja (nie­współ­dzie­le­nie i nie ujaw­nia­nie niczego).

Jeden z naj­czę­ściej publi­ko­wa­nych przy­kła­dów dia­gra­mu klas UML (źr. mate­ria­ły dydaktyczne)

Powyższa kon­struk­cja jest bar­dzo łatwa do imple­men­ta­cji w języ­kach zorien­to­wa­nych obiek­to­wo, jest bar­dzo czę­sto poda­wa­na jako przy­kład, jed­nak łamie pod­sta­wo­we cechy para­dyg­ma­tu obiek­to­we­go: nie­za­leż­ność obiek­tów i her­me­ty­za­cję. Kod repre­zen­to­wa­ny kla­są Figura_Geometryczna jest wspól­ną czę­ścią kon­struk­cji Okrąg i Kwadrat, w efek­cie wszyst­kie trzy kla­sy są z sobą ści­śle powią­za­ne (zależ­ne od sie­bie) co prze­czy zasa­dzie pro­jek­to­wa­nia obiek­to­we­go zwa­nej loose coupling (luź­ne powiązanie).

Kluczową cechą obiek­to­wej archi­tek­tu­ry sys­te­mu jest współ­pra­ca her­me­tycz­nych i luź­no powią­za­nych obiek­tów, więc pod­sta­wo­wym związ­kiem pomię­dzy obiek­ta­mi jest zależ­ność (zwią­zek uży­cia) a nie aso­cja­cja czy kom­po­zy­cja, bo te to związ­ki struk­tu­ral­ne. Wszystkie obiek­ty MUSZĄ mieć ope­ra­cje, bez któ­rych nie ma mowy o jakiej­kol­wiek komu­ni­ka­cji czy­li tak­że współ­pra­cy. Od lat zna­ny jest antyw­zo­rzec obiek­to­wy o nazwie ane­micz­ny model dzie­dzi­ny”. Jest to struk­tu­ra trwa­le (aso­cja­cje) powią­za­nych klas (obiek­tów) pozba­wio­nych ope­ra­cji ?(Fowler, 2003)?. Taki model, jak ten poni­żej, nie jest mode­lem obiektowym: 

(źr.https://en.wikipedia.org/wiki/Domain_model)

Kluczowe wady powyż­sze­go dia­gra­mu to: brak ope­ra­cji i w kon­se­kwen­cji brak związ­ków uży­cia, trwa­łe powią­za­nia oraz dzie­dzi­cze­nie (jego wady opi­sa­no wcze­śniej): te obiek­ty nie komu­ni­ku­ją się w żaden spo­sób. Diagram zorien­to­wa­ny jest na dane. 

Mitem wyrzą­dza­ją­cym chy­ba naj­wię­cej szkód jest teza o mode­lo­wa­niu danych z uży­ciem UML („UML łączy naj­lep­sze cechy: mode­lo­wa­nia danych ERD, mode­lo­wa­nia czyn­no­ści DFD., […]”, mate­ria­ły dydak­tycz­ne: Modelowanie z wyko­rzy­sta­niem UML, Politechnika Poznańska) oraz teza, że pod­sta­wo­wa idea obiek­tu to łącze­nie danych i funk­cji je prze­twa­rza­ją­cych”. Tu war­to wie­dzieć, że jed­nym z pod­sta­wo­wych wzor­ców pro­jek­to­wych i dobrych prak­tyk archi­tek­tu­ry jest sepa­ro­wa­nie two­rze­nia ele­men­tów infor­ma­cji, skła­do­wa­nia infor­ma­cji, i prze­twa­rza­nia infor­ma­cji (odręb­ne kom­po­nen­ty: fabry­ka, repo­zy­to­rium, usłu­ga) ?(Evans, 2015)?. Atrybuty obiek­tu to nie są pola bazy danych a stan obiek­tu to nie aktu­al­na war­tość jego wszyst­kich atrybutów. 

Nie mniej wadli­we są czę­sto publi­ko­wa­ne dia­gra­my przy­pad­ków uży­cia skła­da­ją­ce się z dużej ich licz­by, wie­lu związ­ków inc­lu­de i extend a nie raz i owe­go dzie­dzi­cze­nia, ale ten temat już opi­sa­łem w arty­ku­le Paradygmat obiek­to­wy i Przypadki Użycia .

UML: klasa, klasyfikator, obiekt

Modele obiek­to­we doku­men­tu­je się z uży­ciem nota­cji UML (Unified Modeling Notation?*?). Notacja ta nie powsta­ła do doku­men­to­wa­nia kodu (jak piszą nie­któ­rzy auto­rzy) a do doku­men­to­wa­nia wyni­ków ana­li­zy i pro­jek­to­wa­nia (OOAD, Object Oriented Analysis and Design, Analiza i Projektowanie Zorientowane Obiektowo). Zostało to opi­sa­ne w OMG (Object Management Group???) jako pro­ces MDA (Model Driven Architecture???). Kolejność powsta­wa­nia opro­gra­mo­wa­nia to: ana­li­za i model biz­ne­so­wy, decy­zja o zakre­sie pro­jek­tu czy­li wyma­ga­nia, model logi­ki sys­te­mu (Platform Independent Model) czy­li opis roz­wią­za­nia i dopie­ro pro­jekt imple­men­ta­cji (Platform Specific Model). Wszystkie te mode­le (jeże­li doty­czą tego same­go sys­te­mu) muszą korzy­stać z tej samej prze­strze­ni poję­cio­wej (jed­no­li­ty słow­nik pojęć). Pokazano to poniżej:

Model pro­jek­tu obiek­to­we­go, strzał­ki do związ­ki zależ­no­ści i wska­zu­ją na źró­dło­we informacje. 

Niektórzy auto­rzy jed­nak piszą:

Proces pro­jek­to­wa­nia sys­te­mu infor­ma­tycz­ne­go obej­mu­je nastę­pu­ją­ce głów­ne eta­py:
? pro­gra­mo­wa­nie (two­rze­nie kodu pro­gra­mu w wybra­nym języ­ku pro­gra­mo­wa­nia),
? opra­co­wy­wa­nie doku­men­ta­cji (opi­sy­wa­nie wszyst­kich ele­men­tów skła­do­wych sys­te­mu, zależ­no­ści zacho­dzą­cych mię­dzy nimi, a tak­że opra­co­wy­wa­nie szcze­gó­ło­wej instruk­cji użyt­kow­ni­ka),
? wdra­ża­nie sys­te­mu do pra­cy (jest to pro­ces odpo­wie­dzial­ny, zło­żo­ny i dłu­go­trwa­ły obej­mu­ją­cy: insta­la­cję sys­te­mu w miej­scu prze­zna­cze­nia, uru­cha­mia­nie, testo­wa­nie oraz szko­le­nie per­so­ne­lu obsłu­gu­ją­ce­go system).

Projektowanie sys­te­mu infor­ma­tycz­ne­go wyma­ga okre­śle­nia:
? mode­lu danych (Data Model),
? inter­fej­su użyt­kow­ni­ka (User Interface, Front-End).
Model danych okre­śla zbiór ogól­nych zasad posłu­gi­wa­nia się danymi.

?(Gryglewicz-Kacerka & Duraj, 2013)?

Autorzy tu cał­ko­wi­cie pomi­nę­li etap ana­li­zy i pro­jek­to­wa­nia co prze­czy tytu­ło­wi tej publi­ka­cji: Projektowanie obiek­to­we sys­te­mów infor­ma­tycz­nych. Padają tu tak­że sło­wa o mode­lu danych, od któ­rych para­dyg­mat obiek­to­wy cał­ko­wi­cie abstrahuje. 

Notacja UML ope­ru­je trze­ma klu­czo­wy­mi poję­cia­mi: kla­sa (nazwa), kla­sy­fi­ka­tor (zna­cze­nie, defi­ni­cja obiek­tów), obiek­ty (desy­gna­ty, mają­ce toż­sa­mość egzem­pla­rze). Pojęcia te są opar­te na tak zwa­nym trój­ką­cie semiotycznym:

trój­kąt semio­tycz­ny (źr. Logika ogól­na, Grzegorz Malinowski, PWN 2010).

Trójkąt semio­tycz­ny to kon­tek­sto­we powią­za­nie pojęć: znak (sło­wo), defi­ni­cja, przed­miot. Określony znak (nazwa) wska­zu­je (deno­tu­je) przed­miot (uży­wa­my nazwy/znaku do wskazania/nazwania przed­mio­tu). Wszystkie przed­mio­ty zgod­ne z okre­ślo­nym opi­sem (desy­gna­ty danej nazwy) moż­na nazwać (ozna­czyć) tym sło­wem (nazwa). Np. każ­de stwo­rze­nie, któ­re szcze­ka” (znaczenie/opis) moż­na nazwać sło­wem pies” i są to te wszyst­kie psy” (kon­kret­ne zna­ne nam psy czy­li desy­gna­ty sło­wa pies). W nota­cji UML kla­sa” to poję­cie: nazwa”, kla­sy­fi­ka­tor do defi­ni­cja, a obiek­ty to desy­gna­ty (instan­cje kla­sy­fi­ka­to­ra, tu UWAGA: z uwa­gi na nie­jed­no­znacz­ność pew­nych zapi­sów w UML, instan­cje – obiek­ty – ma kla­sy­fi­ka­tor a nie kla­sa, kla­sa to tyl­ko nazwa zbioru).

W mode­lach poję­cio­wych uży­wa­ne są związ­ki seman­tycz­ne (aso­cja­cja) i defi­ni­cyj­ne (gene­ra­li­za­cja). Związek gene­ra­li­za­cji jest klu­czo­wym narzę­dziem two­rze­nia defi­ni­cji spra­woz­daw­czych (patrz przy­pis na stro­nie Słownik pojęć). W nota­cji UML sto­so­wa­ny jest tak­że zwią­zek kom­po­zy­cji (zwią­zek struk­tu­ral­ny całość – część), słu­ży do doku­men­to­wa­nia tak zwa­nych kla­sy­fi­ka­to­rów zło­żo­nych zwa­nych tak­że agregatami.

Tak więc pro­jekt obiek­to­wy to udo­ku­men­to­wa­ny zestaw współ­pra­cu­ją­cych w okre­ślo­nym celu obiek­tów (kom­po­nen­tów). Wymaganym i klu­czo­wym ele­men­tem pro­jek­tu jest słow­nik pojęć, czy­li zna­cze­nia i struk­tu­ra nazw uży­tych w tym pro­jek­cie (nazwy klas, atry­bu­tów i ich war­to­ści, ope­ra­cji, para­me­trów itp.). Jest to tak zwa­na prze­strzeń poję­cio­wa sys­te­mu (słow­nik, name­spa­ce) przed­sta­wia­na jako model poję­cio­wy (tak­so­no­mie). Jeżeli dany atry­but przyj­mu­je skoń­czo­ną licz­bę war­to­ści jako skut­ków okre­ślo­nych fak­tów, doku­men­tu­je­my to dia­gra­mem maszy­ny sta­no­wej. Kolejnym ele­men­tem pro­jek­tu obiek­to­we­go są sce­na­riu­sze (mode­le) opi­su­ją­ce współ­pra­cę (dyna­mi­kę) ele­men­tów sys­te­mu (obiek­tów), któ­rej efek­tem są ocze­ki­wa­ne rezul­ta­ty (przy­pad­ki uży­cia oraz ich sce­na­riu­sze, jako dia­gra­my sekwen­cji UML). 

Model obiektowy systemu

Należało by raczej powie­dzieć, zorien­to­wa­ny obiek­to­wo lub zgod­ny z obiek­to­wym para­dyg­ma­tem. Oznacza to, że struk­tu­ra sys­te­mu (jego model) skła­da się z samo­dziel­nych obiek­tów, któ­re razem jako sys­tem, reali­zu­ją okre­ślo­ne zada­nia. System jako taki może być tak­że obiek­tem, mogą­cym współ­pra­co­wać z innym sys­te­mem. Innymi sło­wy każ­dy obiekt sam z sie­bie jest pro­stym (ato­mo­wym, ele­men­tar­nym) systemem. 

Omówię tu przy­kład pro­jek­tu pro­stej apli­ka­cji. Projekt zosta­nie udo­ku­men­to­wa­ny z uży­ciem nota­cji UML. Pominę etap two­rze­nia mode­li CIM (pro­ce­sy biznesowe). 

Zakres pro­jek­tu to usłu­ga reje­stra­cji wizyt u wete­ry­na­rza oraz usłu­ga pre­zen­to­wa­nia wete­ry­na­rzom ich pod­sta­wo­wych danych a tak­że ter­mi­nów wizyt im przy­po­rząd­ko­wa­nych. Zakres udo­ku­men­to­wa­no z uży­ciem dia­gra­mu przy­pad­ków uży­cia nota­cji UML.

Z apli­ka­cji będą korzy­sta­li wete­ry­na­rze. Aplikacja świad­czy dwie usłu­gi: zarzą­dza­nie wizy­ta­mi oraz pro­fi­le wete­ry­na­rzy. Można zapi­sać infor­ma­cje o pla­no­wa­nych wizy­tach, kar­ta wizy­ty będzie zawie­ra­ła tak­że pod­sta­wo­we dane przy­po­rząd­ko­wa­ne­go wete­ry­na­rza, pobra­ne z pro­fi­lu tego wete­ry­na­rza. Każdy wete­ry­narz będzie pro­wa­dził swój pro­fil: poda­jąc klu­czo­we infor­ma­cje o sobie np. imię, nazwi­sko, spe­cja­li­za­cja, kon­takt do sie­bie. Będzie tak­że widział swój kalen­darz wizyt. Pełny pro­jekt zawie­rał­by deta­licz­ne sza­blo­ny tych for­mu­la­rzy. W ramach wyma­gań spi­sa­no regu­ły biz­ne­so­we czy­li logi­kę biz­ne­so­wą systemu:

  • Wizyty nie mogą być uma­wia­ne w dni wol­ne od pracy
  • Weterynarz może mieć tyl­ko jed­ną zapla­no­wa­na wizy­tę w danym terminie
  • Profil okre­ślo­ne­go wete­ry­na­rza może edy­to­wać wyłącz­nie on sam

(regu­ły biz­ne­so­we i słow­nik pojęć, patrz spe­cy­fi­ka­cja SBVR: Semantics Of Business Vocabulary and Rules?§?). Reguł biz­ne­so­wych nie doku­men­tu­je­my w UML bo nie do tego służy.

Do kon­tro­li pola Data wizy­ty, zapla­no­wa­no spraw­dza­nie danych o dniach wol­nych od pra­cy w zewnętrz­nym sys­te­mie, udo­stęp­nia­ją­cym dane o dniach wol­nych od pra­cy (na dia­gra­mie aktor po pra­wej stro­nie, taka sytu­acja to nie przy­pa­dek uży­cia! a zwią­zek zależ­no­ści od aktora).

Kluczowa część pro­jek­tu to ana­li­za poję­cio­wa i opra­co­wa­nie mode­lu poję­cio­we­go czy­li słow­ni­ka pojęć, ich tak­so­no­mii i definicji.

Model poję­cio­wy (dia­gram klas UML lub dia­gram fak­tów SBVR)

Słownik pojęć sta­no­wi pod­sta­wo­we źró­dło nazw wszyst­kich ele­men­tów mode­lu dzie­dzi­ny sys­te­mu. Jak widać słow­nik to tyl­ko kla­sy (same nazwy) połą­czo­ne aso­cja­cja­mi (związ­ki seman­tycz­ne) i związ­ka­mi gene­ra­li­za­cji (łączą poję­cia ogól­niej­sze i ich typy). Pojęcia ogól­ne są czę­sto kan­dy­da­ta­mi na nazwy kla­sy­fi­ka­to­rów (kom­po­nen­tów sys­te­mu) i ich atry­bu­tów, typy pojęć (liście tak­so­no­mii) są kan­dy­da­ta­mi na nazwy war­to­ści atry­bu­tów (ich słow­ni­ki). To nie jest ani model danych ani model archi­tek­tu­ry tego systemu!

Zaprojektowano kom­po­nent Model (model dzie­dzi­no­wy) sys­te­mu (patrz opis wzor­ca MVC: Model, View, Controller), jego archi­tek­tu­ra jest zgod­na z opi­sa­nym obiek­to­wym para­dyg­ma­tem i ma cechy dobrej archi­tek­tu­ry (zasa­dy SOLID). Dla uprosz­cze­nia pomi­ną­łem na dia­gra­mie imple­men­ta­cję reje­stru weterynarzy). 

Architektura kom­po­nen­tu Model Dziedziny sys­te­mu (dia­gram klas UML). 

Przedstawiony przy­kład nie ma poważ­nej wady archi­tek­to­nicz­nej (wręcz pla­gi), pole­ga­ją­cej na wycią­ga­niu” zawar­to­ści atry­bu­tów obiek­tu serią pole­ceń Get/Set dla każ­de­go atry­bu­tu. Powoduje to bar­dzo sil­nie uza­leż­nie­nie obiek­tu pobie­ra­ją­ce­go dane od obiek­tu będą­ce­go ich źró­dłem (wadę tę opi­sał dokład­nie Fowler we wzor­cu DTO. Operacje zapisz i przy­wo­łaj powo­du­ją zapi­sa­nie i przy­wo­ła­nie całej kar­ty wizy­ty (wszyst­kich jej danych).

Jak widać mamy peł­ną her­me­ty­za­cję kom­po­nen­tów i luź­ne powią­za­nia mię­dzy nimi (tyl­ko związ­ki uży­cia). Oddzielono logi­kę biz­ne­so­wą od repo­zy­to­rium. Nie ma tu żad­ne­go dzie­dzi­cze­nia (nie ma go w UML od 2015 roku). Każdy kom­po­nent (kla­sy­fi­ka­tor) ma ope­ra­cje. Pola gatu­nek i wiel­kość mają zde­fi­nio­wa­ne słow­ni­ki (enu­me­ra­tor). Nazwy te są zde­fi­nio­wa­ne w odręb­nym mode­lu poję­cio­wym (bo do tego on mię­dzy inny­mi słu­ży). Model powyż­szy jest jed­nak nadal dość tra­dy­cyj­ny” (prze­sta­rza­ły) bo atry­bu­ty repre­zen­tu­ją poszcze­gól­ne pola for­mu­la­rzy (od cze­go się odchodzi!). 

Wadą tego prze­sta­rza­łe­go” pomy­słu jest to, że każ­da mody­fi­ka­cja for­mu­la­rzy będzie wyma­ga­ła refak­to­rin­gu tego sys­te­mu (atry­bu­ty kla­sy­fi­ka­to­rów i meto­dy). Dlatego poka­za­łem alter­na­tyw­ne nowo­cze­śniej­sze podej­ście (różo­we tło), w któ­rym kla­sy­fi­ka­tor Wizyty2 ma iden­tycz­ny inter­fejs, nadal odpo­wia­da za prze­cho­wy­wa­nie infor­ma­cji o wizy­tach, ale tu są one – cała kar­ta wizy­ty – prze­cho­wy­wa­ne jako treść jed­ne­go atry­bu­tu: tu w posta­ci tek­stu XML. Dzięki temu zmia­na struk­tu­ry for­mu­la­rza nie będzie wyma­ga­ła refak­to­ry­za­cji, a jedy­nie wymia­ny sza­blo­nów XML i XSD. Polimorfizm i her­me­ty­za­cja pozwo­li na wymia­nę imple­men­ta­cji z Wizyty na Wizyty2 bez kon­se­kwen­cji dla resz­ty sys­te­mu (kla­sa Wizyty2 ma iden­tycz­ny interfejs). 

Aktualne war­to­ści atry­bu­tów nie są sta­nem obiek­tu” (kolej­ny mit). Obiekt Wizyty to repo­zy­to­rium kart wizyt, sta­nem (sta­tu­sem) danej wizy­ty jest jed­na infor­ma­cja (war­tość jed­ne­go atry­bu­tu). Wizyta jako taka ma sta­tu­sy, zmie­nia­ją się one automatycznie.

Zmiany war­to­ści atry­bu­tu status_wizyty (maszy­na sta­nów UML)

Aby udo­ku­men­to­wać przy­pa­dek uży­cia (jego sce­na­riusz) oraz jed­no­cze­śnie prze­te­sto­wać tę archi­tek­tu­rę (udo­ku­men­to­wać dyna­mi­kę sys­te­mu) two­rzy­my dia­gram sekwencji.

Scenariusz reali­za­cji usłu­gi Wizyta (dia­gram sekwen­cji UML). 

Myślę, że nie wyma­ga on komen­ta­rza. Warto wie­dzieć, że uży­wa­nie do tego celu dia­gra­mów aktyw­no­ści jest mało efek­tyw­ne, a w UML 2.5 dia­gra­my aktyw­no­ści są zare­zer­wo­wa­ne już wyłącz­nie do mode­lo­wa­nia kodu programu. 

Cały pro­jekt ma nastę­pu­ją­cą strukturę:

Pełna doku­men­ta­cja zawierałaby: 

  • model poję­cio­wy (jeden lub kil­ka dia­gra­mów klas),
  • jeden dia­gram przy­pad­ków użycia,
  • jeden lub wię­cej (alter­na­tyw­ne) sce­na­riu­szy dla każ­de­go przy­pad­ku uży­cia (dia­gra­my sekwencji),
  • jeden model dzie­dzi­ny sys­te­mu czy­li model archi­tek­tu­ry kom­po­nen­tu Model dla wzor­ca MVC (dia­gram klas, duży sys­tem to dia­gram kom­po­nen­tów, każ­dy z osob­nym mode­lem swo­jej wewnętrz­nej architektury),
    • dla każ­de­go obiek­tu w mode­lu dzie­dzi­ny, mają­ce­go sta­tu­sy, model maszy­ny sta­no­wej opi­su­ją­cy war­to­ści atry­bu­tu repre­zen­tu­ją­ce­go stan obiek­tu (może ich być wię­cej niż jeden).
    • struk­tu­ry tak zwa­nych obiek­tów trans­fe­ro­wych czy­li struk­tu­ry danych wymie­nia­ne pomię­dzy obiek­ta­mi (agre­ga­ty, naj­czę­ściej XML).

Do tego bogat­szy opis kon­tek­stu, makie­ty for­mu­la­rzy, peł­ną spe­cy­fi­ka­cję reguł biznesowych. 

Model taki nada­je się (pomi­ja­jąc potrze­bę zapro­jek­to­wa­nia gra­fi­ki i śro­do­wi­ska wyko­naw­cze­go) do imple­men­ta­cji wprost, sta­no­wi więc bar­dzo pre­cy­zyj­ne wymaganie. 

Korzyści

Najczęściej jako korzy­ści ze sto­so­wa­nia metod obiek­to­wych wska­zy­wa­ne jest re-uży­cie kodu, łatwe korzy­sta­nie z biblio­tek, podział pra­cy na zespo­ły. A tak na praw­dę klu­czo­wą korzy­ścią są skut­ki her­me­ty­za­cji i poli­mor­fi­zmu: sys­tem podzie­lo­ny na cał­ko­wi­cie nie­za­leż­ne (her­me­ty­za­cja) kom­po­nen­ty i cał­ko­wi­ta nie­za­leż­ność od ich wewnętrz­nej budo­wy (poli­mor­fizm) powo­du­je, że roz­wój i wpro­wa­dza­nie zmian dla sys­te­mu jest szyb­kie, łatwe i nie­mal­że pozba­wio­ne ryzy­ka. To jak rower, jeże­li nie jest spa­wa­ny a zło­żo­ny ze stan­dar­do­wych ele­men­tów łączo­nych na unor­mo­wa­ne zaci­ski i śrub­ki (stan­da­ry­za­cja inter­fej­sów), mody­fi­ku­je­my go w dowol­nym momen­cie, małym nakła­dem pra­cy, w mia­rę zmian naszych potrzeb i nawy­ków. W 2013 pisałem:

Zasa­da ?nigdy nie mów nigdy? ozna­cza, że żaden pro­gram nie jest skoń­czo­ny. Inny­mi sło­wy powin­no być moż­li­we roz­sze­rza­nie jego funk­cjo­nal­no­ści bez prze­bu­do­wy. (czy­taj wię­cej: Plansza do gry w sza­chy czy­li ana­li­za i pro­jek­to­wa­nie | | Jarosław Żeliński IT-Consulting )

Opisałem tam obiek­to­wy model gry w sza­chy speł­nia­ją­cy powyż­szą zasadę. 

Na zakończenie

Mam nadzie­ję, że ten arty­kuł wyja­śni wie­le wąt­pli­wo­ści. Wiele róż­nych przy­kła­do­wych dia­gra­mów moż­na zna­leźć w lite­ra­tu­rze i w sie­ci inter­net. Wiele z nich, mimo że są zgod­ne z nota­cją UML, to nie mode­le obiek­to­we a struk­tu­ral­ne. Niestety wie­le zawie­ra tak­że błę­dy nota­cyj­ne. Dodam tak­że, co bar­dzo waż­ne: spe­cy­fi­ka­cja UML to nie jest pod­ręcz­nik ana­li­zy i mode­lo­wa­nia a tyl­ko spe­cy­fi­ka­cja nota­cji. Zawiera popraw­ne kon­struk­cje UML ale nie koniecz­nie są to zawsze dobre wzor­ce architektury. 

Warto wie­dzieć, że to co nazy­wa­my para­dyg­ma­tem obiek­to­wym to aksjo­mat a nie dogmat. Dlatego nota­cja UML nie narzu­ca nicze­go poza zasa­da­mi jej sto­so­wa­nia, jed­nak jeże­li już pisze­my, że nasz pro­jekt jest obiek­to­wy, to musi­my (wypa­da­ło by) uznać aksjo­mat: sys­tem to współ­pra­cu­ją­ce samo­dziel­ne obiek­ty (a więc uznać kon­se­kwent­nie her­me­ty­za­cję i poli­mor­fizm). Dobre prak­ty­ki archi­tek­tu­ry to już kon­se­kwen­cje doty­czą­ce cyklu życia sys­te­mu, w szcze­gól­no­ści kosz­tu jego utrzy­ma­nia i rozwoju. 

Ciekawostką jest tak­że to, że o opi­sa­nych tu zale­tach archi­tek­tu­ry obiek­to­wej pisa­no już w 1994 roku (i póź­niej też nie raz). Wiedza, któ­rą tu pre­zen­tu­ję ma 25 lat:

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))
(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

Na zakoń­cze­nie powiedz­my sobie wprost: nie ma cze­goś takie­go jak obiek­to­wy model danych”!. 

Dane to infor­ma­cje (zna­ki), któ­re mogą zostać zor­ga­ni­zo­wa­ne w okre­ślo­ne nazwa­ne struk­tu­ry, one same z sie­bie nic nie robią. Obiekt to coś co ma okre­ślo­ne zacho­wa­nie”, więc okre­śle­nie obiek­to­wy model danych” jest pozba­wio­ne sen­su… Jednym z naj­bar­dziej zna­nych antyw­zor­ców obiek­to­wych jest tak zwa­ny «ane­micz­nym model dzie­dzi­ny». Jest to model któ­ry skła­da się z klas mają­cych atry­bu­ty, ale nie­za­wie­ra­ją­cych żad­nych metod, co powo­du­je, że nie jest obiektowy.

Jak zawsze zachę­cam do zada­wa­nia pytań…


  1. ?*?
    https://​www​.uml​.org
  2. ???
    https://​www​.omg​.org
  3. ???
    https://​www​.omg​.org/​m​da/
  4. ?§?
    https://​www​.omg​.org/​s​p​e​c​/​S​B​V​R​/​A​b​o​u​t​-​S​B​VR/

Źródła

  1. Evans, E. (2015). Domain-Driven Design. Zapanuj nad zło­żo­nym sys­te­mem infor­ma­tycz­nym. Gliwice: HELION.
  2. Fowler, M. (2003). AnemicDomainModel. Retrieved 2019, from martinFowler​.com websi­te: 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
  3. Gryglewicz-Kacerka, W., & Duraj, A. (2013). Projektowanie obiek­to­we sys­te­mów infor­ma­tycz­nych. Włocławek: Państwowa Wyższa Szkoła Zawodowa we Włocławku.
Shishkov, B. (2020) Designing enter­pri­se infor­ma­tion sys­tems mer­ging enter­pri­se mode­ling and softwa­re spe­ci­fi­ca­tion.

Architektura kodu aplikacji jako pierwszy etap tworzenia oprogramowania

Tym razem trosz­kę cięż­szy kali­ber, czy­li dywa­ga­cje o tym co powszech­nie jest okre­śla­ne jako meto­dy obiek­to­we i o tym skąd kon­flik­ty i nie­po­ro­zu­mie­nia” mię­dzy pro­gra­mi­sta­mi i ana­li­ty­ka­mi pro­jek­tan­ta­mi.?*?

Wprowadzenie

Literatura przed­mio­tu zawie­ra wie­le róż­nych spo­so­bów gru­po­wa­nia metod pro­gra­mo­wa­nia w ?para­dyg­ma­ty?. Autorzy z regu­ły sku­pia­ją się na tym, czym są pro­gra­my rozu­mia­ne jako zor­ga­ni­zo­wa­na lista pole­ceń dla maszy­ny. Mogą to być sekwen­cje pro­stych pole­ceń, mogą to być wyko­ny­wa­ne wg. okre­ślo­ne­go sce­na­riu­sza funk­cje. Typowym przy­kła­dem takie­go gru­po­wa­nia jest np. wykład (tu jego spis tre­ści) dostęp­ny w sie­ci Internet:

Wstęp
1.1 Przykład pierw­szy: pro­gra­mo­wa­nie impe­ra­tyw­ne
1.2 Przykład dru­gi: pro­gra­mo­wa­nie obiek­to­we
1.3 Przykład trze­ci: pro­gra­mo­wa­nie funk­cyj­ne
1.4 Przykład czwar­ty: pro­gra­mo­wa­nie w logi­ce (pro­gra­mo­wa­nie logicz­ne) ?1?

Wykład ten, z uwa­gi na to, że pocho­dzi ze stron mimów.edu .pl (Uniwersytet Warszawski, Wydział Informatyki) w moich oczach, po lek­tu­rze kil­ku­na­stu podob­nych, jest repre­zen­ta­tyw­nym dla wie­lu śro­do­wisk aka­de­mic­kich podejściem.

Programowanie strukturalne

Jest to para­dyg­mat pro­gra­mo­wa­nia opie­ra­ją­cy się na podzia­le kodu źró­dło­we­go pro­gra­mu na pro­ce­du­ry i hie­rar­chicz­nie uło­żo­ne blo­ki z wyko­rzy­sta­niem struk­tur kon­tro­l­nych w posta­ci instruk­cji wybo­ru i pętli. Rozwijał się w opo­zy­cji do pro­gra­mo­wa­nia wyko­rzy­stu­ją­ce­go pro­ste instruk­cje warun­ko­we i sko­ki. Programowanie struk­tu­ral­ne zwięk­sza czy­tel­ność kodu i uła­twia ana­li­zę pro­gra­mów, co sta­no­wi zna­czą­cą popra­wę w sto­sun­ku do trud­ne­go w utrzy­ma­niu ?spa­ghet­ti code? czę­sto wyni­ka­ją­ce­go z uży­cia instruk­cji go to”. Nadal jest to jed­nak dłu­ga lista sil­nie powią­za­nych procedur.

Metody struk­tu­ral­ne ana­li­zy i pro­jek­to­wa­nia bazu­ją na uzna­niu, że opro­gra­mo­wa­nie to stos funk­cji ope­ru­ją­cych na bazach (skła­dach) danych. Innymi sło­wy pod­sta­wo­we zało­że­nie to ist­nie­nie odręb­nych bytów jaki­mi są baza danych oraz funk­cje, któ­re na tych danych wyko­nu­ją ope­ra­cje. W meto­dach struk­tu­ral­nych two­rzy dwa się rodza­je mode­li: model pro­ce­su prze­twa­rza­nia i model struk­tu­ry danych. Pierwszy wyko­rzy­stu­je nota­cję DFD (Data Flow Diagram, np. nota­cja Gane?a- Sarsona) a dru­gi nota­cja ERD (Entity Relationship Diagram, np. nota­cja Martina) do mode­lo­wa­nia struk­tur rela­cyj­nych baz danych.

Rysunek 1 Diagram DFD w nota­cji Gene’a – Sarsona

Struktura apli­ka­cji w posta­ci tak zwa­nej ?czar­nej skrzyn­ki? zosta­ła poka­za­na na Rysunku 1. W meto­dach struk­tu­ral­nych, na pozio­mie opi­su archi­tek­tu­ry, apli­ka­cja ?dzie­lo­na jest? na pod­funk­cje (patrz Rysunek 2.).

Rysunek 2 Dekompozycja funkcji

Starsze pod­ręcz­ni­ki infor­ma­ty­ki i pro­gra­mo­wa­nia powo­łu­ją się na ?zasa­dę?: algo­ryt­my + struk­tu­ry danych = opro­gra­mo­wa­nie (apli­ka­cje). Kod zawie­ra­ją­cy funk­cje jest z regu­ły dzie­lo­ny jest na czę­ści zwa­ne ?pod­pro­gram?, jed­nak nie­za­leż­nie od tego jak jest zor­ga­ni­zo­wa­ny, jest to zwar­ty i nie­po­dziel­ny sys­tem funk­cji i algo­ryt­mów, któ­ry zapi­su­je i odczy­tu­je dane ze współ­dzie­lo­ne­go ?maga­zy­nu danych?. Najczęściej tym maga­zy­nem jest rela­cyj­nie zor­ga­ni­zo­wa­na baza danych?2?, czy­li sys­tem powią­za­nych tablic, w któ­rym usu­wa się redun­dan­cje i two­rzy trwa­łe związ­ki logicz­ne mię­dzy tak zor­ga­ni­zo­wa­ny­mi danymi.

Modelowania struk­tur rela­cyj­nych baz danych (nota­cja ERD, Entity Relationship Diagram, tu nota­cja Martina)

Architektura taka nie spra­wia więk­szych pro­ble­mów do momen­tu gdy apli­ka­cja nie zaczy­na się roz­ra­stać i nie poja­wia się potrze­ba wpro­wa­dza­nia kolej­nych nowych lub zmie­nio­nych ele­men­tów mecha­ni­zmu jej dzia­ła­nia. Wtedy każ­da inge­ren­cja w tak zor­ga­ni­zo­wa­ną archi­tek­tu­rę doty­czy pra­wie zawsze całej apli­ka­cji. Stabilne kie­dyś oto­cze­nie (śro­do­wi­sko użyt­ko­wa­nia tych apli­ka­cji) pozwa­la­ło na pro­jek­to­wa­nie opro­gra­mo­wa­nia, od któ­re­go nikt nie ocze­ki­wał, że pozwo­li na łatwe i szyb­kie wpro­wa­dza­nie zmian. Po dru­gie, two­rze­niem opro­gra­mo­wa­nia zaj­mo­wa­ły się małe zespo­ły pro­gra­mi­stów, zaś logi­ka prze­twa­rza­nia pole­ga­ła raczej na reali­zo­wa­niu małej licz­by typów ope­ra­cji na wiel­kich ilo­ściach danych, to były głow­nie pro­jek­ty inży­nier­skie a nie badaw­cze. Zamawiający (tak zwa­ny dzi­siaj ?biz­nes?) musiał jedy­nie spi­sać dane i ope­ra­cje oraz wzo­ry (for­mu­ły) z jakich uży­ciem były one przeliczane.

Zmiana paradygmatu

Rosnąca zło­żo­ność opro­gra­mo­wa­nia wymu­si­ła szu­ka­nie nowych roz­wią­zań. Początkowo dzie­lo­no kod apli­ka­cji na sepa­ro­wa­ne czę­ści – modu­ły, jed­nak nadal sta­no­wi­ły one jed­ną całość z powo­du pra­cy z dany­mi w posta­ci jed­nej zwar­tej struk­tu­ry, jaką jest współ­dzie­lo­na rela­cyj­na baza danych. Fakt ten czę­sto jest postrze­ga­ny jako zale­ta: wska­zu­je się na brak redun­dan­cji, łatwy spo­sób uzy­ska­nia spój­no­ści danych, współ­dzie­le­nie jako łatwą inte­gra­cję. Problem w tym, że duże apli­ka­cje ope­ru­ją w wie­lu kon­tek­stach, co powo­du­je, że współ­dzie­lo­na baza danych o usta­lo­nej struk­tu­rze, musi sta­no­wić kom­pro­mis. Np. dane sta­no­wią­ce zapis kolej­nych zaku­pów amor­ty­zo­wa­nych środ­ków trwa­łych mają inną struk­tu­rę i logi­kę wza­jem­nych powią­zań, niż te same dane w kon­tek­ście zło­żo­nych kon­struk­cji mecha­nicz­nych jaki­mi są te środ­ki trwa­łe. Innym przy­kła­dem obra­zu­ją­cym kwe­stie kon­tek­sto­wo­ści jest przy­kład na blo­gu Martina Fowlera.?3?

Rysunek 3 Granice kon­tek­stu i zmia­na per­spek­ty­wy pojęć ?3?.

Jak widać na Rysunku 3., mamy tu dwa kon­tek­sty i redun­dan­cje (poję­cia Customer i Produkt powie­lo­ne po obu stro­nach: w obu dzie­dzi­nach). Powyższe powin­no być pod­sta­wą do podzia­łu pro­jek­tu na dwa odręb­ne kom­po­nen­ty z wła­sny­mi (nie współ­dzie­lo­ny­mi) dany­mi. Jak widać każ­dy kom­po­nent ope­ru­je poję­cia­mi Customer i Produkt, jed­nak inny jest ich kon­tekst. Inne cechy dzie­dzi­no­we tych pojęć nie są (nie powin­ny być) współ­dzie­lo­ną infor­ma­cją w jed­nej bazie danych, oba kom­po­nen­ty będą mia­ły swo­je odręb­ne mode­le danych, zapew­ne o róż­nią­cej struk­tu­rze. Powód pierw­szy to inne związ­ki poję­cio­we i być może nawet inne defi­ni­cje pojęć. Produkt w kon­tek­ście sprze­da­ży ma nazwę, cenę, dostęp­ność itp. Produkt w kon­tek­ście uszko­dzeń ma numer seryj­ny, wer­sję, użyt­kow­ni­ka itp. Inne będą regu­ły biz­ne­so­we w każ­dym kom­po­nen­cie. Drugi powód to łatwa dostęp­ność na ryn­ku spe­cja­li­zo­wa­nych pro­duk­tów typu CRM i TicketXXX, szu­ka­nie (two­rze­nie) jed­ne­go ?pakie­tu zin­te­gro­wa­ne­go? będzie bar­dzo trud­ne, bo kon­tek­stów sprze­da­ży a potem obsłu­gi uszko­dzeń czy rekla­ma­cji, jako pary, będą tysią­ce warian­tów. Wytworzenie (zakup) osob­no, i inte­gra­cja dwóch odpo­wied­nio dobra­nych kom­po­nen­tów (apli­ka­cji), będą znacz­nie łatwiejsze.

Powoli zaczę­ły swe­go cza­su powsta­wać apli­ka­cje dzie­dzi­no­we, jed­nak nadal wewnętrz­nie mia­ły one opi­sa­ne wyżej wady współ­dzie­le­nia danych w jed­nej bazie. Do tego ich inte­gra­cja pole­ga­ła na wza­jem­nym się­ga­niu do danych co sta­no­wi­ło bar­dzo duży pro­blem z powo­du róż­nych struk­tur tych danych, zaś wymia­na jed­nej z nich na inną wyma­ga­ła opra­co­wa­nia od nowa całej kon­cep­cji inte­gra­cji współ­dzie­lo­nych danych co poka­za­no na Rysunku 4.

Rysunek 4 Integracja apli­ka­cji strukturalnych

Obiektowy paradygmat

Co cie­ka­we powsta­nie metod obiek­to­wych nie było szu­ka­niem spo­so­bu usu­nię­cia wad sys­te­mów struk­tu­ral­nych. Pierwsze obiek­to­we narzę­dzia powsta­ły już w latach sześć­dzie­sią­tych XX w. narzę­dzia i pro­gra­my struk­tu­ral­ne tak­że powsta­ją do tej pory.

Do obec­nej popu­lar­no­ści metod obiek­to­wych dopro­wa­dzi­ły dwie ścież­ki: pro­blem rosną­cej zło­żo­no­ści kodu apli­ka­cji oraz potrze­ba utrzy­ma­nia zro­zu­mie­niu ?tego czym jest ta apli­ka­cja? po stro­nie zamawiającego.

Proces, powszech­nie zwa­ny ?zbie­ra­niem wyma­gań?, sta­je się coraz bar­dziej skom­pli­ko­wa­ny i ryzy­kow­ny, w mia­rę jak rośnie zło­żo­ność tych systemów.

Wymagania na opro­gra­mo­wa­nie nali­cza­ją­ce wyna­gro­dze­nia tysiąc­om pra­cow­ni­ków to ?jeden wzór? na nali­cze­nie wyna­gro­dze­nia oraz pew­na licz­ba cech jako­ścio­wych takich jak wydaj­ność czy dostęp­ność. Jednak opi­sa­nie tą meto­dą jed­nej” apli­ka­cji, ope­ru­ją­cej dzie­siąt­ka­mi doku­men­tów o róż­nych struk­tu­rach i ogrom­nej ilo­ści zależ­no­ści mię­dzy nimi, z pomo­cą ?listy cech? zaczy­na przy­bie­rać postać setek, a nie raz tysię­cy, linii i danych w tabe­lach. Przy takiej ilo­ści wyma­gań” prak­tycz­nie żaden spo­sób ich orga­ni­za­cji nie wpro­wa­dza war­to­ści doda­nej, zaś ich licz­ba prak­tycz­nie nie pozwa­la na kon­tro­lę kom­plet­no­ści i niesprzeczności.

Popatrzmy na komen­tarz auto­ra wykła­du?1? do obiek­to­we­go programowania:

W pro­gra­mo­wa­niu obiek­to­wym pro­gram to zbiór poro­zu­mie­wa­ją­cych się ze sobą obiek­tów, czy­li jed­no­stek zawie­ra­ją­cych pew­ne dane i umie­ją­cych wyko­ny­wać na nich pew­ne ope­ra­cje
- Ważną cechą jest tu powią­za­nie danych (czy­li sta­nu) z ope­ra­cja­mi na nich (czy­li pole­ce­nia­mi) w całość, sta­no­wią­cą odręb­ną jed­nost­kę ? obiekt.
- Cechą nie mniej waż­ną jest mecha­nizm dzie­dzi­cze­nia, czy­li moż­li­wość defi­nio­wa­nia nowych, bar­dziej zło­żo­nych obiek­tów, na bazie obiek­tów już ist­nie­ją­cych.
Zwolennicy pro­gra­mo­wa­nia obiek­to­we­go uwa­ża­ją, że ten para­dyg­mat dobrze odzwier­cie­dla spo­sób, w jaki ludzie myślą o świe­cie
- Nawet jeśli pogląd ten uzna­my za prze­jaw pew­nej egzal­ta­cji, to nie­wąt­pli­wie pro­gra­mo­wa­nie obiek­to­we zdo­by­ło ogrom­ną popu­lar­ność i wypa­da je uznać za para­dyg­mat obec­nie dominujący.

W cyto­wa­nym tek­ście widać ste­reo­ty­po­we podej­ście autora:

meto­dy obiek­to­we two­rze­nia opro­gra­mo­wa­nia, opie­ra­ją się na wyróż­nia­niu w two­rzo­nym opro­gra­mo­wa­niu dwóch rodza­jów skła­do­wych: pasyw­nych odzwier­cie­dla­ją­cych fakt prze­cho­wy­wa­nia w sys­te­mie pew­nych danych oraz skła­do­wych aktyw­nych odzwier­cie­dla­ją­cych fakt wyko­ny­wa­nia w sys­te­mie pew­nych ope­ra­cji. Metody obiek­to­we wyróż­nia­ją w sys­te­mie skła­do­we, któ­re łączą w sobie moż­li­wość prze­cho­wy­wa­nia danych oraz wyko­ny­wa­nia ope­ra­cji? (źr. wikipedia).

Schematycznie moż­na to przed­sta­wić tak:

Podejście, któ­re nazwę pro­gra­mi­stycz­nym, to uzna­nie, że trze­ba podzie­lić dużą apli­ka­cję na mniej­sze odręb­ne kom­po­nen­ty, z któ­rych każ­dy ma ?swo­je funk­cje i dane?. Tu tak­że pod­kre­śla­na jest kwe­stia re-uży­cia kodu w posta­ci tak zwa­ne­go dzie­dzi­cze­nia jako ?mecha­ni­zmu defi­nio­wa­nia nowych, bar­dziej zło­żo­nych obiek­tów, na bazie obiek­tów już ist­nie­ją­cych? .

Zupełnie inną dro­gą jest podej­ście opar­te na uzna­niu, że świat rze­czy­wi­sty to okre­ślo­ny mecha­nizm, któ­ry da się odwzo­ro­wać jako pew­na abs­trak­cja za pomo­cą kodu (jego struk­tu­ry). Tu struk­tu­ra kodu jest kon­se­kwen­cją struk­tu­ry tego obsza­ru świa­ta rze­czy­wi­ste­go?, któ­re­go doty­czy two­rzo­ne opro­gra­mo­wa­nie (o czym już na swo­im blo­gu nie raz pisałem).

Skutek jest ?taki sam?: pro­gram stwo­rzo­ny zgod­nie z obiek­to­wym para­dyg­ma­tem będzie się owszem skła­dał z klas obiek­tów, któ­re komu­ni­ku­ją się wza­jem­nie. Jednak podej­ście zorien­to­wa­ne na dzie­le­nie dużej apli­ka­cji na pod­pro­gra­my trak­tu­je obiek­ty jako ?jakieś? kom­po­nen­ty zawie­ra­ją­ce w sobie kod funk­cji i dane na jakich one ope­ru­ją. Podejście zorien­to­wa­ne na mode­lo­wa­nie ?świa­ta rze­czy­wi­ste­go? zaowo­cu­je obiek­ta­mi sta­no­wią­cy­mi abs­trak­cje (mode­le) ele­men­tów świa­ta rze­czy­wi­ste­go. Struktura takie­go kodu w obu przy­pad­kach będzie obiek­to­wa” ale jej sens nie raz jest skraj­nie inny np. obiekt fak­tu­ra będzie zawie­rał dane o sprze­da­ży ale nie będzie miał ope­ra­cji ?nowa fak­tu­ra?, bo fak­tu­ry nie two­rzą nowych fak­tur? (ani nie nio­są infor­ma­cji o tym jak powsta­wa­ły). Faktury będą two­rzo­ne przez inny obiekt np. Twórca fak­tur (albo jak w nie­któ­rych wzor­cach: fabry­ka fak­tur).?4?

Od lat sześć­dzie­sią­tych pro­wa­dzo­ne są pra­ce nad meto­da­mi obiek­to­wy­mi w inży­nie­rii opro­gra­mo­wa­nia, powsta­je języ­ka SIMULA w 1967 roku. W 1968 roku opu­bli­ko­wa­no pierw­sze ofi­cjal­ne wyda­nie Ogólnej Teorii Systemów Ludwiga von Bertalanffy’ego (publi­ka­cje na jej temat poja­wia­ły się od już 1964 roku). Teoria sys­te­mów mówi, że ?sys­tem to współ­pra­cu­ją­ce obiek­ty?, język SIMULA powstał do two­rze­nia (pro­gra­mów) symu­la­cji obiek­tów świa­ta rzeczywistego.

Oba wska­za­ne podej­ścia są zna­ne od lat, jed­nak podej­ście ?inży­nier­skie? (dzie­le­nie duże­go kodu na małe kawał­ki) domi­nu­je, nie tyl­ko jak widać w sys­te­mie kształcenia.

Ogólna teo­ria sys­te­mów trak­tu­je wszyst­ko jak ?sys­tem? (współ­pra­cu­ją­ce obiek­ty). Z zewnątrz sys­tem to obiekt reagu­ją­cy na bodź­ce. Reakcja ta może być opi­sa­na mecha­ni­zmem jej powsta­wa­nia, to wewnętrz­na struk­tu­ra sys­te­mu. Jeżeli uznać, że opro­gra­mo­wa­nie (i kom­pu­ter) zastę­pu­je okre­ślo­ną rze­czy­wi­stość (np. mecha­nicz­ny zegar zastą­pio­ny pro­gra­mem wyko­ny­wa­nym w kom­pu­te­rze) to moż­na przy­jąć, że kom­pu­ter to maszy­na abs­trak­cyj­na, jej imple­men­ta­cja reali­zu­je kon­kret­ne sys­te­my i (lub) ich kom­po­nen­ty?5?.

Nie cho­dzi więc o to by podzie­lić opro­gra­mo­wa­nie na ?skła­do­we, któ­re łączą w sobie moż­li­wość prze­cho­wy­wa­nia danych oraz wyko­ny­wa­nia ope­ra­cji?. Chodzi o to by mecha­nizm, o dowie­dzio­nej popraw­no­ści, zaim­ple­men­to­wać w okre­ślo­nej wybra­nej technologii. 

Chodzi też o to by nie uda­wać, że pro­gra­mo­wa­nie jako ?podzie­lo­ne na obiek­ty? par­tie kodu, nadal korzy­sta­ją­ce z jed­nej wspól­nej bazy danych, róż­ni się czym­kol­wiek od ?struk­tu­ral­ne­go kodu?. Chodzi o to by kod pro­gra­mu fak­tycz­nie imple­men­to­wał okre­ślo­ny (zba­da­ny i opi­sa­ny) mechanizm.

Tak więc ?obiek­to­wy para­dyg­mat? to nie ?nowe pro­gra­mo­wa­nie”, to archi­tek­tu­ra kodu: ?obiek­to­wa? archi­tek­tu­ra???.

Proces pro­jek­to­wa­nia opro­gra­mo­wa­nia, idąc tro­pem ana­li­zy sys­te­mo­wej i opi­sa­nia mecha­ni­zmu dzia­ła­nia tego cze­goś”, zaczy­na się już na eta­pie ana­li­zy. Programista imple­men­tu­je model a nie wymy­śla pro­gram”. Oczywiście pod warun­kiem, że mamy tu na myśli ana­li­zę obiek­to­wą i pro­jek­to­wa­nie sys­te­mu a nie jakiś podział kodu na klasy”.

Na zakoń­cze­nie jeden z moich ulu­bio­nych cyta­tów na temat ana­li­zy i pro­jek­to­wa­nia obiektowego:

(źr. Martin Fowler, Analysis Patterns, 1997)
(źr. Martin Fowler, Analysis Patterns, 1997)?6?

  1. ?*?
    Artykuł został opu­bli­ko­wa­ny w mate­ria­łach pokon­fe­ren­cyj­nych: https://www.academia.edu/37284192/Materiały_pokonferencyjne_III_Ogólnopolskiej_Konferencji_Interdyscyplinarnej_Współczesne_zastosowania_informatyki_Architektura_kodu_aplikacji_jako_pierwszy_etap_tworzenia_oprogramowania
  2. ???
    Wielu auto­rów przy­wo­łu­je tu poję­cie kom­po­nen­tów a nie obiek­tów. Komponentem jest tu każ­dy samo­dziel­ny, komu­ni­ku­ją­cy się z oto­cze­niem, obiekt nie­za­leż­nie od wiel­ko­ści i stop­nia złożoności. 

Źródła:

  1. 1.
    Paradygmaty programowania/Wykład 1: Co to jest para­dyg­mat pro­gra­mo­wa­nia? – Studia Informatyczne. MIMUW. http://wazniak.mimuw.edu.pl/index.php?title=Paradygmaty_programowania/Wykład_1:_Co_to_jest_paradygmat_programowania%3F. Accessed July 16, 2017.
  2. 2.
  3. 3.
    Fowler M. bli­ki: BoundedContext. mar​tin​fow​ler​.com. https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​B​o​u​n​d​e​d​C​o​n​t​e​x​t​.​h​tml. Published January 15, 2014. Accessed July 16, 2017.
  4. 4.
    Żeliński J. Analiza biz­ne­so­wa. Praktyczne mode­lo­wa­nie orga­ni­za­cji. one​press​.pl. http://​one​press​.pl/​v​i​e​w​/​2​2​3​9​k​/​s​f​o​m​o​d​.​htm. Accessed July 16, 2017.
  5. 5.
  6. 6.
    Martin Fowler, Analysis Patterns, 1997.

Analiza procesowa a obiektowa czyli niedopasowanie oporu

Swego cza­su w arty­ku­le o Wścipskim Analityku uza­sad­nia­łem potrze­bę pano­wa­nia nad wyma­ga­nia­mi od momen­tu poja­wie­nia się potrze­by biz­ne­so­wej aż do jej imple­men­ta­cji. Nie zna­czy to abso­lut­nie, że ana­li­tyk ma pro­gra­mo­wać, zna­czy to jed­nak, że ana­li­tyk powi­nien doku­men­to­wać to cze­go żąda w wyma­ga­niach a potem nad­zo­ro­wać realizację.

Developerzy uzur­pu­ją sobie pra­wa do wszyst­kie­go co wią­że się z imple­men­ta­cją. Z jed­nej stro­ny czę­sto żąda­ją szcze­gó­ło­wych danych np. o danych z dru­giej stro­ny sami chcą opi­sać ich logi­kę biz­ne­so­wą (tak, bo dane biz­ne­so­we to logi­ka biz­ne­so­wa a nie tech­no­lo­gia). Do tego bar­dzo wie­lu deve­lo­pe­rów sto­su­je meto­dy pra­cy rodem z przed kil­ku­na­stu lat… We wspo­mnia­nym wyżej arty­ku­le napi­sa­łem mię­dzy inny­mi o tak zwa­nym para­dyg­ma­cie obiek­to­wym i wie­dzy o nim u deve­lo­pe­rów, szu­kam hasła ana­li­za pro­ce­so­wa” i para­dyg­mat obiektowy”:

Tradycyjnie idzie­my do WIKI:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Analiza pro­ce­so­wa? w Wikipedii. (24 Maj 2011)

No cóż, szu­ka­my dalej:

Process ana­ly­sis pre­sents a chro­no­lo­gi­cal sequ­en­ce of steps that expla­in how some­thing is done, how some­thing hap­pens, or how readers can do some­thing. (źr. http://​www​.tcc​.edu/​s​t​u​d​e​n​t​s​/​r​e​s​o​u​r​c​e​s​/​w​r​i​t​c​e​n​t​/​h​a​n​d​o​u​t​s​/​w​r​i​t​i​n​g​/​p​r​o​c​e​s​s​.​htm).

Coś mamy: ana­li­za pro­ce­so­wa pre­zen­tu­je w posta­ci chro­no­lo­gicz­nej sekwen­cji kro­ków, to jak coś powsta­je, co się wyda­rza lub jak moż­na coś zro­bić. Piękna defi­ni­cja. Ta pre­zen­ta­cja to, w kon­tek­ście biz­ne­so­wym, model (mapa) pro­ce­sów biznesowych.

Mamy wiec upo­rząd­ko­wa­ną wie­dzę o fir­mie (orga­ni­za­cji) zama­wia­ją­ce­go opro­gra­mo­wa­nie. Tu tak­że powsta­je opis tego po co i gdzie tego opro­gra­mo­wa­nia chce­my uży­wać: model procesowy.

Tak zwane niedopasowanie oporu

Tak jest nazy­wa­na w lite­ra­tu­rze róż­ni­ca pomię­dzy para­dyg­ma­tem pro­ce­so­wym a obiek­to­wym. Paradygmat pro­ce­so­wy ope­ru­je taki­mi poję­cia­mi jak: pro­ces, wej­ście pro­ce­su, wyj­ście pro­ce­su, zda­rze­nie, wyko­naw­ca pro­ce­su (zaso­by), czyn­ność (lub ich sekwen­cja). Paradygmat obiek­to­wy to wspo­mnia­ne współ­pra­cu­ją­ce obiek­ty. W czym pro­blem? W przej­ściu z mode­lu pro­ce­so­we­go na obiek­to­wy. Czy to łatwe? Nie. Jak to zro­bić? Hm… usiąść i popra­co­wać nad tym.

Należy prze­pro­wa­dzić ana­li­zę obiek­to­wą i wyko­nać model obiek­to­wy. Czego? Kodu? Nie! Logiki dzia­ła­nia i orga­ni­za­cji zamawiającego!

Tak wła­śnie jest: ana­li­za obiek­to­wa i mode­lo­wa­nie obiek­to­we to nie pro­gra­mo­wa­nie. Programowanie (wraz z pro­jek­to­wa­niem ele­men­tów czy­sto tech­nicz­nych) to imple­men­ta­cja modelu.

Jak moż­na radzić sobie z tym nie­do­pa­so­wa­niem”. Pomagają w tym zasa­dy SOLID (w szcze­gól­no­ści zasa­da otwar­to­ści na roz­sze­rze­nia i zamknię­cia na mody­fi­ka­cje oraz pro­jek­to­wa­nie zorien­to­wa­ne na zobo­wią­za­nia klas) oraz wzor­ce DDD w ana­li­zie i projektowaniu.

To co tu opi­szę nie jest pro­stym algo­ryt­mem mode­lo­wa­nia”, z pra­cy myślo­wej niko­go tu nie zwol­nię. Moim celem jest uzu­peł­nie­nie arty­ku­łu o sza­chow­ni­cy i arty­ku­łu o zbyt Niskim pozio­mie ana­li­zy o wska­za­nie, że model dzie­dzi­ny jest bar­dziej ele­men­tem ana­li­zy i mode­lo­wa­nia biz­ne­so­we­go niż pro­jek­to­wa­nia i imple­men­ta­cji. Model ten to jed­no z klu­czo­wych wyma­gań: sys­tem ma reali­zo­wać logi­kę opi­sa­ną w mode­lu dziedziny.

Jeżeli uzna­my, że moż­na (taki) model dzie­dzi­ny imple­men­to­wać to jego opra­co­wa­nie to tak­że pro­jek­to­wa­nie. Nadal uwa­żam, że nie jest to robo­ta dla pro­gra­mi­sty, bo na jakiej pod­sta­wie on miał by taki model opracować?

Jak wyglą­da więc pra­ca ana­li­ty­ka biz­ne­so­we­go zgod­nie z mode­lem kom­pe­ten­cyj­nym IIBA (IIBA com­pe­ten­cy model). Kluczowym ele­men­tem pra­cy Analityka Biznesowego (w kon­wen­cji IIBA) jest pro­wa­dze­nie (ana­li­za) wyma­gań od momen­tu okre­śle­nia potrze­by biz­ne­so­wej aż do imple­men­ta­cji uzy­ska­nia wła­ści­we­go roz­wią­za­nia. Jednak uzy­ska­nie to nie to samo co wła­sno­ręcz­ne wyko­na­nie. Znowu ana­lo­gia do budow­nic­twa: archi­tekt na bazie biz­ne­so­wych celów swo­je­go klien­ta opra­co­wu­je nie tyl­ko wizu­ali­za­cję budyn­ku ale tak­że jego kon­struk­cję, do takie­go pozio­mu by deve­lo­per miał jed­no­znacz­nie posta­wio­ne wyma­ga­nia, nie blo­ku­je to jed­nak deve­lo­pe­ro­wi reali­za­cji” wszel­kich poza-funk­cjo­nal­nych wymagań.

Więc po kolei, opracowujemy.

Model procesu biznesowego

Model procesuMamy tu pro­ces skła­da­ją­cy się z dwóch ele­men­tar­nych pro­ce­sów biz­ne­so­wych (czyn­no­ści). Każda czyn­no­ści, zgod­nie z defi­ni­cją pro­ce­su biz­ne­so­we­go, ma dane wej­ścio­we i dane wyj­ścio­we. Dokument 2 i Dokument 3 powsta­ją w tych pro­ce­sach. Mamy tak­że Procedury two­rze­nia doku­men­tów, czy­li jakąś logi­kę ich two­rze­nia. Pojawia się tak­że regu­ła biz­ne­so­wa. Jest to to ele­ment z poza nota­cji BPMN (nota­cja ta zawie­ra jed­nak moż­li­wość ozna­cza­nia czyn­no­ści wyma­ga­ją­cych uży­cia takiej regu­ły). Na dia­gra­mie poka­za­no, regu­łę biz­ne­so­wą oraz jej powią­za­nie z kon­kret­ną czynnością.

Czas zacząć ana­li­zo­wać czy­li pro­jek­to­wać nasz System. Założenie: wyma­ga­ne jest by System (opro­gra­mo­wa­nie) wspie­ra­ło oba pro­ce­sy: 1 i 2 (przy­po­mnę, że pro­ces biz­ne­so­wy to jed­na czyn­ność lub ich sekwen­cja, więc jed­ną czyn­ność mają­cą wej­ście i wyj­ście tak­że z defi­ni­cji, utoż­sa­mia­ny z pro­ce­sem biznesowym).

Usługi systemu

Usługi sys­te­mu to korzeń ana­li­zy obiek­to­wej. Stanowią szkie­let całe­go obiek­to­we­go pro­jek­tu. two­rzy­my bar­dzo waż­ny dia­gram: dia­gram przy­pad­ków użycia.

Usługi systemu

Często sły­szę, że ten dia­gram nic nie wno­si do pro­jek­tu. To nie praw­da. Wnosi klu­czo­wą infor­ma­cję: wyzna­cza gra­ni­ce Systemu i wska­zu­je ewen­tu­al­ne powią­za­nia z inny­mi sys­te­ma­mi. Ale też nie praw­dą jest, że słu­ży do poka­za­nia cze­go­kol­wiek ponad to, np. kolej­no­ści korzy­sta­nia z usług czy struk­tu­ry wewnętrz­nej. To ostat­nie robi­my w posta­ci mode­lu dziedziny.

Na powyż­szym dia­gra­mie udokumentowano:

  1. System ofe­ru­je użyt­kow­ni­ko­wi dwie usłu­gi (to wyma­ga­nie by Czynność 1 i Czynność 2 pro­ce­su były wspie­ra­ne przez System). 
  2. System będzie korzy­stał z danych inne­go opro­gra­mo­wa­nia (Zewnętrznego źró­dła danych), wyma­ga­na jest więc integracja.
  3. Usługa 2 jest reali­zo­wa­na w cało­ści przez inny, zewnętrz­ny sys­tem, wyma­ga­ne jest od sys­te­mu więc by obsłu­gi­wał prze­kie­ro­wa­nie na inny sys­tem (np. reali­za­cja płat­no­ści na stro­nie Banku).

Zakres pro­jek­tu to wyłącz­nie to co w środ­ku”, albo lepiej: wszyst­ko to co jest poza pro­sto­ką­tem System jest poza zakre­sem pro­jek­tu. Nie dostar­cza­my ani Zewnętrznego źró­dła danych ani Systemu Zewnętrznego usłu­go­daw­cy ale musi­my na liście wyma­gań zapi­sać, że inte­gra­cja z nimi jest wyma­ga­na i jaka ona ma być.

Logika działania Systemu – model dziedziny

Zabawa zaczy­na się tu: zamie­nia­my sce­na­riu­sze” na narzę­dzia i materiały”:

Model dziedziny

Celowo zacho­wa­łem nazwy tak by moż­li­we było śla­do­wa­nie” co z cze­go powsta­ło. Kilka komen­ta­rzy, czy­li dobre prak­ty­ki, wzor­ce i styl projektowania.

Każda usłu­ga ma swo­ją dedy­ko­wa­ną kla­sę, zmia­ny reali­za­cji jed­nej nie prze­nio­są się na inne. Usługi są więc od sie­bie nie­za­leż­ne. Oddzielono two­rze­nie doku­men­tów od ich prze­cho­wy­wa­nia, dzię­ki cze­mu łatwo w przy­szło­ści zmie­nić meto­dy ich two­rze­nia bez potrze­by inge­ren­cji w repo­zy­to­rium. Wszelkie regu­ły biz­ne­so­we (w tym vali­da­cji) są zamknię­te” w tak zwa­nych zło­żo­nych typach danych (valueObject, sytu­acja ide­al­na to cał­ko­wi­ty brak typów pro­stych (typy pro­ste, pri­mi­ti­ves) w pro­jek­cie, wyłącz­nie typy zło­żo­ne). W zasa­dzie zastą­pie­nie wszyst­kich typów pro­stych na zło­żo­ne w obsza­rze mode­lu dzie­dzi­ny, otwie­ra w przy­szło­ści dro­gę do ich roz­bu­do­wy bez potrze­by wpro­wa­dza­nia innych zmian w pro­gra­mie. Realnie pomię­dzy Aktorem a usłu­gą ist­nie­ją kla­sy wido­ku (GUI, View w MVC), tu nie umiesz­czo­ne, bo kla­sy te nie reali­zu­ją (nie powin­ny) żad­nej logi­ki biznesowej.

Powyższy model:

  1. Spełnia zasa­dy SOLID (w szcze­gól­no­ści System jest łatwy w roz­sze­rza­niu i nie wyma­ga w tym celu zmian)
  2. Jest zgod­ny z DDD czy­li struk­tu­ra mode­lu odwzo­ro­wu­je struk­tu­rę i poję­cia biznesowe.

Co zysku­je­my? Niskie kosz­ty dal­sze­go roz­wo­ju, łatwość wyce­ny pro­jek­tu przez deve­lo­pe­ra (zna archi­tek­tu­rę). Powstanie takie­go pro­jek­tu daje mi gwa­ran­cję, że panu­je nad nim. Owszem mogę zało­żyć, że deve­lo­per tak­że taki model opra­cu­je, jed­nak życie poka­zu­je, że pra­wie na pew­no nie…

Powyższe z oczy­wi­stych powo­dów (mało miej­sca i uogól­nie­nie) nie zawie­ra szcze­gó­łów, ale te nale­ży zawsze w pro­jek­cie odkła­dać na sam koniec. Dzięki temu może­my sku­pić się na rze­czach na praw­dę waż­nych (waż­ne jest by zro­zu­mieć cel two­rze­nia doku­men­tu a nie spi­sać jego zawar­tość, ta ostat­nia wyni­ka z tego do cze­go służy).

Ostatni wpis na blo­gu, o Niskim pozio­mie ana­li­zy zawie­ra akapit:

Istnieje nie­ste­ty tak­że bar­dzo duże ryzy­ko, któ­re­go źró­dłem jest sto­so­wa­nie sta­rych, struk­tu­ral­nych metod wytwa­rza­nia opro­gra­mo­wa­nia czy­li roz­biór” (i pro­jekt) sys­te­mu na bazę danych i pro­ce­du­ry. Ta prak­ty­ka (meto­da) nie­ste­ty daje jako efekt opro­gra­mo­wa­nie bar­dzo kosz­tow­ne w pro­jek­to­wa­niu i roz­wo­ju. Od metod struk­tu­ral­nych znacz­nie lep­sze są meto­dy obiek­to­we, nie­ste­ty samo dekla­ro­wa­nie korzy­sta­nia z .NET czy Java albo nota­cji UML nie czy­ni sto­so­wa­nych metod obiektowymi.

Właśnie dla­te­go ana­li­za i wyma­ga­nia powin­ny zawie­rać model dzie­dzi­ny wraz z zale­ce­nia­mi co do imple­men­ta­cji. Nie jest to doku­ment (ten model) dla spon­so­ra pro­jek­tu (w rozu­mie­niu do czy­ta­nia). Jego rola (war­tość jaką wno­si do pro­jek­tu) to mini­ma­li­za­cja ryzy­ka, że deve­lo­per wyko­na coś cze­go nie chcemy.

A gdzie baza danych? Nie tu! Implementacja prze­cho­wy­wa­nia danych to pra­ca deve­lo­pe­ra, nie wol­no mu jedy­nie znor­ma­li­zo­wać powyż­sze­go mode­lu. Zaprojektowanie rela­cyj­ne­go mode­lu i uży­cie mapo­wa­nia obiek­to­wo-rela­cyj­ne­go znisz­czy wszyst­kie zale­ty tego pro­jek­tu a dodat­ko­wo strasz­nie skom­pli­ku­je całość.

(prze­druk uka­zał się w ERP-View)

Semantic Core czyli bat na szczegóły

Bardzo czę­sto zasta­na­wiam się, nad przy­czy­na­mi pora­żek pro­jek­tów, przy­czy­na­mi tego, że jed­ne są lep­sze inne gor­sze, a gor­szy to taki, któ­ry wymy­ka się spod kon­tro­li a osta­tecz­ny efekt (pro­dukt), uzy­ska­ny po znacz­nie dłuż­szym cza­sie niż pla­no­wa­no, jest zasko­cze­niem dla wszyst­kich. Na to nakła­da się pro­blem prze­ka­zy­wa­nia wie­dzy pomię­dzy kolej­ny­mi eta­pa­mi pro­jek­tu, gdzie naj­więk­szym ryzy­kiem jest zro­zu­mie­nie pro­ble­mu i prze­ka­zy­wa­nie wie­dzy przez same­go zama­wia­ją­ce­go. Gdzie problem?

Ten arty­kuł pole­cam biz­ne­so­wi” któ­ry szu­ka przy­czyn swo­ich pro­ble­mów, i tym (nie tyl­ko ana­li­ty­kom), któ­rzy mają ambi­cje robić coś w kie­run­ku popra­wy tego sta­nu rze­czy, zamiast uzna­wać obec­ne sta­ty­sty­ki za pew­nik bo takie są fakty”.

Wpadłem jakiś czas temu na stro­nę SemanticCore​.ORG, oto krót­ki cytat z pierw­szej strony :

The seman­tic core repre­sents a vision of com­plex sys­tems that are defi­ned and pro­vi­sio­ned based on high-level models. This vision is being pur­su­ed by mul­ti­ple gro­ups in mul­ti­ple orga­ni­za­tions based on a varie­ty of para­digms such as UML, Ontologies, Business Rules, MOF, EDOC, Data Modeling, OWL, SQL, Etc.. It is the intent of the seman­tic core to inte­gra­te the­se diver­se para­digms into fami­ly of lan­gu­ages that leve­ra­ges the­ir com­mo­na­li­ty whi­le taking advan­ta­ge of the­ir uni­que capa­bi­li­ties. We will defi­ne nor­ma­li­zed Meta-Models cap­tu­ring uni­que seman­tics, inde­pen­dent of the nota­tion. […] It is our intent to cre­ate a com­bi­ned sub­mis­sion appro­pria­te for mul­ti­ple OMG ini­tia­ti­ves inc­lu­ding Ontologies, Business Rules, Business Process Modeling and a UML infra­struc­tu­re libra­ry.[…] the seman­tic core will defi­ne models for a fami­ly of onto­lo­gi­cal­ly gro­un­ded models defi­ning all aspects of sys­tems, inc­lu­ding the­ir requ­ire­ments, envi­ron­ment, spe­ci­fi­ca­tion and imple­men­ta­tion. This will ena­ble a trans­i­tion from tra­di­tio­nal and manu­al sys­tems buil­ding tech­ni­qu­es to an auto­ma­ted and human-focu­sed para­digm. (źr. Semantic Core).

Powyżej (moje wytłusz­cze­nia) głów­ne cele tej orga­ni­za­cji (pole­cam zapo­zna­nie się z całą stroną)

  • nasza wizja to zło­żo­ne sys­te­my opi­sy­wa­ne i przed­sta­wia­ne w posta­ci mode­li na wyso­kim pozio­mie abstrakcji,
  • w tym celu defi­niu­je­my znor­ma­li­zo­wa­ny meta­mo­del opi­sa­ny sys­te­mem zna­czeń (seman­ty­ka) nie­za­leż­nym od notacji,
  • two­rzy­my to w zgo­dzie z ini­cja­ty­wa­mi OMG (www​.omg​.org),
  • seman­tic core” okre­śla stan­dar­do­wy zestaw klu­czo­wych pojęć i ich zna­czeń, opi­su­ją­cych wszyst­kie aspek­ty sys­te­mów, w tym ich wyma­ga­nia, oto­cze­nie, spe­cy­fi­ka­cji i implementacje.

Wygląda jak baj­ka ale nie jest tak źle, a coś takie­go jest bar­dzo przy­dat­ne. Nie ma sen­su budo­wa­nie jed­nej mega-nota­cji do wszyst­kie­go, widać to po pra­cach OMG (i po tym, że UML jed­nak nie zastą­pił innych nota­cji, i nikt roz­sąd­ny chy­ba już tego nie pla­nu­je). Jednak uzna­jąc fakt, że uży­wa­my (dobra prak­ty­ka) nota­cji wła­ści­wych dla roz­wią­zy­wa­ne­go pro­ble­mu (zary­zy­ku­ję tezę: wła­ści­wa to moż­li­wie naj­prost­sza i wystar­cza­ją­ca) war­to jed­nak zadbać o ich kom­pa­ty­bil­ność”. Część wspól­na to nie nowa nota­cja, a utrzy­ma­nie spój­no­ści zna­czeń współ­dzie­lo­nych pojęć ist­nie­ją­cych już notacji.

SemanticCore
(źr. SemanticCore​.org)

O złożoności

Na co war­to zwró­cić uwa­gę? Otóż w pro­ce­sie każ­dej więk­szej ana­li­zy poja­wia się zło­żo­ność, nad któ­rą nale­ży zapa­no­wać. Bez tego opa­no­wa­nia poja­wia się coś co zabi­ja pro­jek­ty ana­li­tycz­ne: utra­ta pano­wa­nia nad zło­żo­no­ścią pro­ble­mu, poja­wia­ją się mega-dia­gra­my i mega for­mu­la­rze danych.

Kilka tygo­dni temu, w jed­nym z moich pro­jek­tów, mia­łem oka­zję wejść w mały spór na temat tego, kie­dy udo­ku­men­to­wać szcze­gó­ło­wo spo­sób kla­sy­fi­ka­cji (ozna­cza­nia) pozy­cji budże­to­wych w sys­te­mie zarzą­dza­nia pro­ce­sem two­rze­nia budże­tu i jego reali­za­cji. Zamawiający od razu wcho­dził (wręcz żądał) w szcze­gó­ły, czy­li naście rodza­jów każ­de­go z ogrom­nej licz­by typów wydat­ków. Jeszcze bym dobrze nie ruszył z miej­sca a już został bym zgnie­cio­ny licz­bą tych szcze­gó­łów. Do tego dorzu­ca­no mi peł­ną szcze­gó­ło­wość struk­tu­ry orga­ni­za­cyj­nej (tak­że prze­kła­da się na budżet jako miej­sca wyda­wa­nia środ­ków). Dodam, że struk­tu­ra orga­ni­za­cyj­na zmie­ni­ła się w cią­gu roku trzy razy.

Co z tym zro­bić? Wyrzucić” te szcze­gó­ły na sam koniec! One są na począt­ku zupeł­nie nie­istot­ne (nie licząc zapo­zna­nia się nimi jako obec­nie funk­cjo­nu­ją­cym sys­te­mem), każ­dy zaś kto twier­dzi, że jed­nak są istot­ne już teraz, po pro­stu jesz­cze nie zro­zu­miał ana­li­zo­wa­ne­go problemu.

Problemem są pryn­cy­pia czy­li co i po co” a nie jak”. Owo jak” to dopie­ro pro­jek­to­wa­nie. Tak więc np. budżet, pro­ces jego two­rze­nia a potem reali­za­cji, to jakiś sys­tem pozy­cji budże­to­wych” i zda­rzeń zwią­za­nych z jego reali­za­cją. Jakaś logi­ka tej cało­ści (dalej jako regu­ły biz­ne­so­we i decy­zyj­ne). To jak zosta­nie ozna­czo­na (jakim sym­bo­lem itp.) to efekt tego co chce­my osią­gnąć. Każdy kto chwy­ci się od razu za te szcze­gó­ły (jakieś one są, mamy je już więc dla­cze­go się za nie nie zabrać), zaczy­na od koń­ca i w zasa­dzie zarzu­cił ana­li­zę i odciął sobie (klien­to­wi) moż­li­wość zbu­do­wa­nia opty­mal­ne­go (nowe­go) roz­wią­za­nia (zapew­ne inne­go niż obec­ne) na rzecz obecnego.

Należy na począt­ku pra­co­wać na abs­trak­cji, uogól­nie­niu pozwa­la­ją­cym sku­pić się na kil­ku­na­stu pryn­cy­piach zamiast na tysią­cach szcze­gó­łów. To pierw­sze jest rela­tyw­nie łatwe, to dru­gie w zasa­dzie niemożliwe.

abstraction systemcore_org
(źr. SemanticCore​.org)

Modele

Jak wspo­mnia­no powy­żej, typów mode­li (nota­cji) mamy wię­cej niż jeden. Każdy model (rodzaj mode­lu) ma swój dedy­ko­wa­ny sys­tem pojęć, po ubra­niu go w iko­ny mamy nota­cję (język obraz­ko­wy), czy­li język opi­sa­ny seman­ty­ką (zna­cze­nia pojęć) i syn­tak­ty­ką (ich wza­jem­ne, dopusz­czal­ne rela­cje). Zestaw pojęć powi­nien być dobra­ny sto­so­wa­nie do roz­wią­zy­wa­ne­go pro­ble­mu (wybór wła­ści­wej do eta­pu pra­cy notacji).

Jak wska­za­no wyżej, mamy czte­ry klu­czo­we sys­te­my pojęciowe:

  1. UML czy­li obiek­to­wy para­dyg­mat opi­su i projektowania,
  2. Ontologia (biz­ne­so­wa, sys­te­mo­wa), któ­rą obec­nie repre­zen­tu­ją Model Motywacji Biznesowej (w mię­dzy cza­sie tak­że doro­bił się ikon), SBVR i sys­te­my poję­cio­we opi­sy­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej, struk­tu­ry organizacji,
  3. Procesy biz­ne­so­we,
  4. Reguły biz­ne­so­we.

Wspólny śro­dek ma już swo­je zarze­wie”. W 2010 roku wyda­no ostat­nią spe­cy­fi­ka­cję Modelu Motywacji Biznesowej (ang. BMM). Można przy­jąć, że ten sys­tem poję­cio­wy (teraz tak­że nota­cja) to ele­ment biz­ne­so­wej onto­lo­gii. Pojawił się w niej doda­tek F zaty­tu­ło­wa­ny Powiązane spe­cy­fi­ka­cje mode­lo­wa­nia w OMG. I co my tu mamy?

Ano mamy stwier­dze­nie, że ta kom­pa­ty­bil­ność jest potrzeb­na. Napisano, że BMM współ­dzie­li pew­ne poję­cia z taki­mi sys­te­ma­mi poję­cio­wy­mi jak:

  1. BPMN (w BMM poja­wia się poję­cie pro­ces biznesowy)
  2. SBVR (BMM tak­że ope­ru­je poję­ciem Reguła Biznesowa)
  3. OSM (Organization Structure Metamodel, BMM uży­wa poję­cia komór­ka organizacyjna”).

Co cie­ka­we poję­cia te mają w OMG wspól­ne defi­ni­cje (te same poję­cia lub poję­cia dają­ce się mapo­wać 1:1). Utrzyma jest zgod­ność roli w pro­ce­sie biz­ne­so­wym i roli jako ele­men­tu struk­tu­ry orga­ni­za­cyj­nej w tych sys­te­mach (OSM, BPMN, BMM).

W spe­cy­fi­ka­cji BMM v.1.1 znaj­dzie­my taki oto diagram:

BMMOvierwiev

Notacje, któ­re wpa­dły” w ręce OMG maja wła­śnie tę bar­dzo pożą­da­ną i przy­jem­ną cechę: są kom­pa­ty­bil­ne. Wspominałem swe­go cza­su o nota­cji ArchiMate (obec­nie nale­ży do The Open Group podob­nie jak i TOGAF). Niestety nie ma tu tej kom­pa­ty­bil­no­ści, mimo że TOGAF nie jest samo­wy­star­czal­nym mode­lem (wyma­ga sto­so­wa­nia innych nota­cji poza ArchiMate), w efek­cie nie widzę moż­li­wo­ści pro­ste­go” zasto­so­wa­nia ram TOGAF”a jako bazo­wej archi­tek­tu­ry kor­po­ra­cyj­nej, bo kolej­ne eta­py uszcze­gó­ła­wia­nia mode­li (a od tego nie ma uciecz­ki w pro­jek­tach) albo będą mia­ły kło­po­ty z jed­no­znacz­no­ścią albo będą wyma­ga­ły jakie­goś dedy­ko­wa­ne­go sys­te­mu tłu­ma­cze­nia pojęć TOGAF na UML, BPMN (BMM nie, bo TOGAF od ostat­niej wer­sji dublu­je – nie wiem czy w 100% i po co – poję­cia mode­lu moty­wa­cji biznesowej.

Nie wymie­ni­łem tu nota­cji UML bo ta słu­ży do obiek­to­we­go mode­lo­wa­nia (para­dyg­mat obiek­to­wy) sys­te­mów. Nie widzę sen­su wpy­cha­nia” jej w dzie­dzi­nę onto­lo­gii zarzą­dza­nia. Paradygmat obiek­to­wy to inne spoj­rze­nie, sys­te­mo­we, opi­su­ją­ce współ­dzia­ła­ją­ce obiek­ty”, jed­nak to wtór­ny model, bo te obiek­ty sys­te­mo­we repre­zen­tu­ją” komór­ki orga­ni­za­cyj­ne, stra­te­gie, regu­ły biz­ne­so­we, doku­men­ty itp. Modele obiek­to­we są dosko­na­łe jako wstęp do pro­jek­to­wa­nia opro­gra­mo­wa­nia imple­men­to­wa­ne­go z pomo­cą obiek­to­wo zorien­to­wa­nych narzę­dzi. Są kom­plet­nie nie­przy­dat­ne jako biz­ne­so­wy sys­tem poję­cio­wy. Owszem, nie raz tu wspo­mi­na­ny DDD (spo­sób mode­lo­wa­nia dzie­dzi­ny sys­te­mu) to pew­ne takie połą­cze­nie, ale to raczej most niż ekwi­wa­lent. Patrząc na ten pro­blem z per­spek­ty­wy MDA (OMG, Model Driven Architecture) model CIM (Computing Independent Model) to powyż­sze mode­le (BMM, BPMN), UML ma zasto­so­wa­nie dla czę­ści PIM (wstęp­ny model imple­men­ta­cji w posta­ci opro­gra­mo­wa­nia) i tu jest dopie­ro miej­sce na DDD.

Tak więc bat na szcze­gó­ły jest: to pro­sta zasa­da od ogó­łu do szcze­gó­łu”, na każ­dym eta­pie mamy sto­sow­ną nota­cję (pro­sty sys­tem pojęć). Należy uogól­niać i mode­lo­wać, i potem stop­nio­wo uszcze­gó­ła­wiać mode­le aż do momen­tu doj­ścia do imple­men­ta­cji dane­go systemu.

TheMetaModelArchitecture

Powyżej obraz z nanie­sio­ny­mi eta­pa­mi [[MDA]] (wię­cej o Model Driven Architecture oraz Meta Object Facility – powyż­szy rysu­nek – na stro­nach OMG). Core Semantic to szczyt (M3) powyż­sze­go. Wymienione wyżej nota­cje to war­stwa M2 (UML dodat­ko­wo obej­mu­je tak­że M1).

Konkluzja jest taka: bazy danych zawie­ra­ją­ce szcze­gó­ło­wość sys­te­mu, pro­jek­tu­je­my na koń­cu. Szczegóły ele­men­tów budże­tu (przy­ta­cza­ny przy­kład) opra­co­wu­je­my dopie­ro jako pomysł na imple­men­ta­cję, mamy to jed­nak dwa pozio­my implementacji:

  1. roz­wią­za­nie pro­ble­mu efek­tyw­ne­go zarzą­dza­nia budże­tem w nowej for­mie np. sys­tem zna­ko­wa­nia pozy­cji budżetowych,
  2. imple­men­ta­cja tego sys­te­mu jako opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go ten pro­ces w organizacji.

To wszyst­ko powin­no być jed­nak poprze­dzo­ne ana­li­zą. Analiza obec­nej sytu­acji nie pole­ga jed­nak na jej 100% odwzo­ro­wa­niu w doku­men­tach ana­li­tycz­nych, a jedy­nie na pozna­niu w celu zro­zu­mie­nia celu biz­ne­so­we­go, opra­co­wa­nie jego mode­lu, i potem dopie­ro roz­wią­zy­wa­nie pro­ble­mu: jak to osiągnąć.

Na koniec pew­na uwa­ga :). Ktoś może powie­dzieć: biz­nes tego (nota­cje, mode­le itp.) nie rozu­mie. I ma racje, bo to narzę­dzia a nie pro­duk­ty ana­liz. Produktem ana­li­zy dla biz­ne­su są zawsze reko­men­da­cje (wyma­ga­nia na opro­gra­mo­wa­nie to tak­że rodzaj reko­men­da­cji brzmią­cej: zale­cam by takie warun­ki speł­nia­ło to opro­gra­mo­wa­nie). Zamawianie przez biz­nes mode­li jako takich, to jakieś kosz­mar­ne nie­po­ro­zu­mie­nie. To tak jak by np. praw­nik, jako pro­dukt zle­ce­nia opi­nia praw­na” oddał wybra­ny stos kodek­sów z komen­ta­rza­mi. Nie, dobry praw­nik odda­je jed­na stro­nę reko­men­da­cji: opi­nie praw­ną. To, że sko­rzy­stał z tych kodek­sów to jego narzę­dzie pra­cy, moż­li­we, że załą­czy je do tej tej opi­nii (ale raczej jako mate­riał dla inne­go praw­ni­ka lub audytora).

Analiza a programowanie czyli gramy w chińczyka na szachownicy

Permanentne dys­ku­sje z wie­lo­ma pro­gra­mi­sta­mi utrwa­la­ją we mnie pewien ste­reo­typ: inży­nier to dobry wyko­naw­ca ale żaden ana­li­tyk. Czy to coś złe­go? Absolutnie nie, dobry inży­nier jest na wagę zło­ta ale dobry inży­nier powi­nien mieć jed­ną klu­czo­wą cechę: nie dys­ku­tu­je z pro­jek­tan­tem (jeże­li tyl­ko pro­jek­tant potra­fi uza­sad­nić cze­go chce). Ale po kolei.

Popatrzmy do Wikipedii bo w znacz­nej mie­rze jest two­rzo­na przez pro­gra­mi­stów i entu­zja­stów infor­ma­ty­ki, choć chy­ba nale­ży raczej powie­dzieć: pro­gra­mo­wa­nia (dodam, że w pra­wie każ­dej fir­mie obser­wu­ję dwa syn­dro­my: każ­dy kto nie jest infor­ma­ty­kiem zna się na mar­ke­tin­gu, pozo­sta­li zna­ją się i na pro­gra­mo­wa­niu i na marketingu).

Programowanie obiek­to­we (ang. object-orien­ted pro­gram­ming) ? para­dyg­mat pro­gra­mo­wa­nia, w któ­rym pro­gra­my defi­niu­je się za pomo­cą obiek­tów ? ele­men­tów łączą­cych stan (czy­li dane, nazy­wa­ne naj­czę­ściej pola­mi) i zacho­wa­nie (czy­li pro­ce­du­ry, tu: meto­dy). Obiektowy pro­gram kom­pu­te­ro­wy wyra­żo­ny jest jako zbiór takich obiek­tów, komu­ni­ku­ją­cych się pomię­dzy sobą w celu wyko­ny­wa­nia zadań. Podejście to róż­ni się od tra­dy­cyj­ne­go pro­gra­mo­wa­nia pro­ce­du­ral­ne­go, gdzie dane i pro­ce­du­ry nie są ze sobą bez­po­śred­nio zwią­za­ne. Programowanie obiek­to­we ma uła­twić pisa­nie, kon­ser­wa­cję i wie­lo­krot­ne uży­cie pro­gra­mów lub ich fragmentów.

Największym atu­tem pro­gra­mo­wa­nia, pro­jek­to­wa­nia oraz ana­li­zy obiek­to­wej jest zgod­ność takie­go podej­ścia z rze­czy­wi­sto­ścią – mózg ludz­ki jest w natu­ral­ny spo­sób naj­le­piej przy­sto­so­wa­ny do takie­go podej­ścia przy prze­twa­rza­niu infor­ma­cji. Już Platon postu­lo­wał dwo­istość: byt” – idea (wzo­rzec) bytu”, np. książ­ka jako idea ogól­na – w ter­mi­no­lo­gii pla­toń­skiej: dosko­na­ła (choć nie­do­okre­ślo­na), i książ­ka kon­kret­na np. zbiór baśni leżą­cy na pią­tej pół­ce. Podobnie, choć póź­niej Arystoteles ana­li­zu­jąc rze­czy­wi­stość wpro­wa­dził poję­cia for­my i mate­rii. (źr. WIKI)

Mamy tu więc dwa wąt­ki: tech­nicz­ny czy­li imple­men­ta­cja [[para­dyg­ma­tu]] obiek­to­we­go w języ­kach pro­gra­mo­wa­nia oraz huma­ni­stycz­ny czy­li opis (model) rze­czy­wi­sto­ści: byty i ich postrze­ga­nie przez czło­wie­ka (w zasa­dzie filo­zo­fia, a kon­kret­nie [[feno­me­no­lo­gia]]: wśród waż­nych pojęć feno­me­no­lo­gii znaj­du­je się [[ana­li­za eide­tycz­na]], czy­li dąże­nie do uchwy­ce­nia isto­ty tego, co dane, ide­acja, docie­ra­nie do isto­ty zja­wisk, widze­nie istot­no­ścio­we. W naocz­no­ści istot­no­ścio­wej dana jest czy­sta isto­ta zja­wi­ska. Uchwycenie tej isto­ty nie musi być prze­pro­wa­dzo­ne na wie­lu przy­kła­dach, wystar­czy nawet jeden lub tyl­ko naocz­ność wyobra­że­nio­wa (przy­kład wyobra­żo­ny)).

Modelowanie rze­czy­wi­stych bytów nie ma nic wspól­ne­go z pro­gra­mo­wa­niem czy infor­ma­ty­ką (przy­po­mi­nam tak­że, że [[teo­ria infor­ma­cji]] i [[infor­ma­ty­ka]] to nie toż­sa­me dzie­dzi­ny wie­dzy) . Raczej potrzeb­na jest do tego [[teo­ria pozna­nia czy­li epi­ste­mo­lo­gia]], [[onto­lo­gia]] czy seman­ty­ka a tak­że [[teo­ria komu­ni­ka­cji społecznej]].

Model dzie­dzi­ny więc, to nic inne­go jak zespół pojęć, związ­ków mię­dzy tymi poję­cia­mi, tego jak czło­wiek postrze­ga te byty rze­czy­wi­ste na bazie nazw, któ­rych uży­wa do ich ozna­cza­nia. Powszechnie pod­no­szo­ny brak wie­dzy klien­ta o tym co chce”, to tak na praw­dę brak kom­pe­ten­cji pro­gra­mi­stów do odczy­ta­nia tego co swo­imi poję­cia­mi prze­ka­zu­je im klient. 

Nie piszę o tym dla­te­go, co mi się cza­sa­mi zarzu­ca, by zamu­lić ana­li­zę teo­rią i udo­wad­niać coś pro­gra­mi­stom. Piszę o tym dla­te­go, że ana­li­za jako drą­że­nie tego co chcą ludzie powie­dzieć i co mówią, taka wła­śnie jest: nieinformatyczna.

Naturalnym więc bie­giem wyda­rzeń w two­rze­niu opro­gra­mo­wa­nia powin­no być więc mode­lo­wa­nie świa­ta opi­sy­wa­ne­go” a potem odtwo­rze­nie” go w kodzie opro­gra­mo­wa­nia. Wcześniej nale­ży okre­ślić co i po co ma zna­leźć odzwier­cie­dle­nie w pro­gra­mie. Być może ktoś dostrze­że tu ele­men­ty DDD ([[Domain Driven Design]], ang. pro­jek­to­wa­nie ste­ro­wa­ne mode­lem dzie­dzi­ny) i słusz­nie bo tak wła­snie jest.

Komponent opro­gra­mo­wa­nia odpo­wie­dzial­ny za reali­za­cję wyma­gań funk­cjo­nal­nych, omó­wio­ny dalej Model, to nic inne­go jak pro­gra­mo­wa symu­la­cja” kawał­ka rze­czy­wi­ste­go świa­ta. Nie moż­na jej abso­lut­nie uprasz­czać, w prze­ciw­nym wypad­ku psu­je­my pro­gram” odda­la­jąc go od rze­czy­wi­sto­ści. Paradoksalnie przy­kła­dem takie­go psu­cia jest nor­ma­li­za­cja rela­cyj­nej bazy danych (redun­dan­cje są typo­wym ele­men­tem rze­czy­wi­sto­ści, usu­wa­nie ich to nisz­cze­nie związ­ku pomię­dzy pro­gra­mem a świa­tem jaki pro­gram modeluje).

Jak zwró­co­no uwa­gę w przy­to­czo­nej defi­ni­cji: Największym atu­tem pro­gra­mo­wa­nia, pro­jek­to­wa­nia oraz ana­li­zy obiek­to­wej jest zgod­ność takie­go podej­ścia z rze­czy­wi­sto­ścią”. Tak więc nale­ży posiąść” tę zgod­ność i rze­czy­wi­stość i nie psuć jej.

Kto powi­nien mode­lo­wać nasz świat”? Dla pro­gra­mi­sty, jak sami to nie raz pod­kre­śla­ją, obiekt to struk­tu­ra łączą­ca w kodzie dane prze­twa­rza­ne z meto­da­mi ich prze­twa­rza­nia. Ale wokół nas są obiek­ty rze­czy­wi­ste: świat i jego zawi­ło­ści. To suge­ru­je raczej, że ana­li­za obiek­to­wa i two­rze­nie mode­lu rze­czy­wi­sto­ści” nie ma nic wspól­ne­go z pro­gra­mo­wa­niem. To raczej jest tak, że pro­gra­mi­sta powi­nien odtwo­rzyć” w kodzie otrzy­ma­ny od ana­li­ty­ka i pro­jek­tan­ta, model. Po to powsta­ły obiek­to­we narzę­dzia by wła­śnie uła­twić pro­gra­mi­stom imple­men­ta­cje obiek­to­wych mode­li a ana­li­ty­kom ich two­rze­nie, dać im wspól­ny (powszech­ny, [[Ubiquitous Language]]) język.

A tu pro­szę: inży­nier ze swo­im obiek­to­wym języ­kiem pro­gra­mo­wa­nia, struk­tu­ra­mi kodu i danych” zabie­ra się do tego, do cze­go nie ma żad­ne­go przy­go­to­wa­nia: mode­lo­wa­nie fir­my (świa­ta) i tego jak jest zarzą­dza­na. Rozumiem obu­rze­nie: to my jeste­śmy pro­gra­mi­sta­mi i my wie­my jak pro­gra­mo­wać. Owszem, JAK ale nie CO. Nie wystar­czy że popy­ta­cie use­ra jak pra­cu­je, trze­ba zro­zu­mieć: co i po co robi a potem stwo­rzyć tego model. Dobry model musi odzwier­cie­dlać rzeczywistość”.

Z obiek­to­wo­ści pro­gra­mi­ści rozu­mie­ją tyl­ko tyle, że to coś co łączy dane i funk­cje”. Ja nicze­go wię­cej nie ocze­ku­ję od pro­gra­mi­stów. Ilu pro­gra­mi­stów czy­ta­ło ze zro­zu­mie­niem Druckera, Portera, Kottlera?

Wielu z nich jest (będzie jak to prze­czy­ta ;)) jak obra­żo­ne dzie­ci bawią­ce się sza­cha­mi: roz­po­zna­ją koni­ka, wie­że czy kró­la, tra­fia­ją figu­ra­mi w pola sza­chow­ni­cy i nie dadzą sobie powie­dzieć, że Goniec to tyl­ko po sko­sie. Szachy to nie jakieś drew­nia­ne pio­ny i 64 pola do ich usta­wia­nia”. Można zagrać tymi pio­na­mi na tej plan­szy w war­ca­by a nawet w zbi­ja­ka, ale to nadal są sza­chy i ta gra ma nie­co inne zasa­dy mimo, że to fak­tycz­nie tyl­ko plan­sza i drew­nia­ne pio­ny i fak­tycz­nie da się z powo­dze­niem zagrać tym sprzę­tem” w war­ca­by, a nawet w chiń­czy­ka (w koń­cu to tyl­ko drew­nia­ne figurki).

Tak więc obiek­to­we pro­gra­mo­wa­nie to narzę­dzie, moż­na nim wie­le zro­bić na wie­le spo­so­bów, ale jeże­li powie­my sobie, że pro­jek­tu­je­my jakąś rze­czy­wi­stość biz­ne­so­wą meto­da­mi obiek­to­wy­mi, to z całym sza­cun­kiem: ocze­ku­ję od pro­gra­mi­sty, że uzna fakt, że figur­ki i plan­sza to jed­nak sza­chy. Od sto­la­rza nie ocze­ku­ję, że będzie mistrzem sza­cho­wym, ocze­ku­ję, że pod dyk­tan­do sza­chi­sty (wyma­ga­nia) wyko­na naj­lep­szą plan­szę i pio­ny i nie będzie się wda­wał w dys­ku­sje na temat tego, dla­cze­go koń na sza­chow­ni­cy wyci­na takie śmiesz­ne hołub­ce i for­so­wał tezy by uznać, że ma cho­dzić pro­sto” i będzie pro­ściej. Szachista tak chce i już, ma pra­wo bo to on zama­wia, to on tu jest sza­chi­stą a sto­larz stolarzem.

Proces powstawania oprogramowania

Tu powo­łam się (po raz kolej­ny) na wzo­rzec pro­jek­to­wy MVC. Obrazuje on podział opro­gra­mo­wa­nia na trzy klu­czo­we podsystemy:

Stosowanie tego wzor­ca ma pewien głę­bo­ki sens: podział odpo­wie­dzial­no­ści zgod­nie z regu­łą obiek­to­wą mówią­cą, że obiekt (tak­że kom­po­nent i jego inter­fejs) ma wszyst­kie i tyl­ko te kom­pe­ten­cje, któ­re są wyma­ga­ne do wywią­za­nia się z kon­trak­tu ([[pro­jek­to­wa­nie zorien­to­wa­ne na kon­trakt]]). Tym kon­trak­tem jest to za co odpo­wia­da obiekt i tyl­ko to”. Powyższy dia­gram (nie jest to [[dia­gram klas]], to sche­mat blo­ko­wy obra­zu­ją­cy wza­jem­ne oddzia­ły­wa­nie na sie­bie kom­po­nen­tów: blo­czek ozna­cza kom­po­nent, strzał­ka poka­zu­je kie­ru­nek oddzia­ły­wa­nia) obra­zu­je zobo­wią­za­nia tych trzech komponentów.

Nie wgłę­bia­jąc się w szcze­gó­ły tego wzor­ca (opi­sy dostęp­ne w sie­ci) istot­ne jest odręb­ne ist­nie­nie kom­po­nen­tów. Model zawie­ra w sobie (mode­lu­je w pro­jek­cie i imple­men­tu­je w kodzie) świat rze­czy­wi­sty wyra­żo­ny w obiek­to­wym para­dyg­ma­cie” (kon­trakt brzmi: wiem wszyt­ko o tym czym jest i jak dzia­ła świat w oto­cze­niu użyt­kow­ni­ka), zarów­no dane jak i logi­kę ich zacho­wań. View ma kon­trakt inny: bio­rę na sie­bie całą inte­rak­cję pro­gra­mu z użyt­kow­ni­kiem. Controller zaś mówi: bio­rę na sie­bie zapa­mię­ty­wa­nie, całą komu­ni­ka­cję, jej spraw­ność i nie­za­wod­ność, w tym tak­że pomię­dzy View i Modelem.

Mamy pro­sty podział odpo­wie­dzial­no­ści: Grafik odpo­wia­da za pro­jekt View, Analityk Biznesowy za Model (przy­po­mnę: co i jak jest prze­twa­rza­ne) a pro­gra­mi­sta za tech­no­lo­gię i ubra­nie tego wszyst­kie­go w dzia­ła­ją­cy kod czy­li za imple­men­ta­cję. Jeżeli uzna­my, że ana­li­tyk opra­cu­je Model meto­da­mi obiek­to­wy­mi to mamy wła­śnie atut pro­gra­mo­wa­nia, pro­jek­to­wa­nia oraz ana­li­zy obiek­to­wej czy­li zgod­ność takie­go podej­ścia z rzeczywistością.

No i teraz sko­ro tak, to samo się nasuwa:

  1. wyko­naj ana­li­zę i opra­cuj obiek­to­wy model rze­czy­wi­sto­ści, upew­nij się, że jest praw­dzi­wy (zgod­ny z tą rzeczywistością),
  2. opra­cuj pro­jekt tego co zoba­czy użyt­kow­nik pro­gra­mu: ekrany,
  3. zapisz ogra­ni­cze­nia sto­so­wa­nia przy­szłe­go programu,
  4. daj to pro­gra­mi­stom by stwo­rzy­li zgod­ny z tymi wyma­ga­nia­mi, dzia­ła­ją­cy program.

Czy inna kolej­ność jest moż­li­wa? Czy widać, że bez pro­jek­tów Modelu i ekra­nów nie ma się co brać za kodo­wa­nie? Co kodo­wać? Jak na tym tle wyglą­da­ją meto­dy pole­ga­ją­ce, na tym, że od razu po roz­mo­wie z nie­ro­zu­mie­ją­cym obiek­to­we­go para­dyg­ma­tu użyt­kow­ni­kiem, przy­stę­pu­je się do kodo­wa­nia? Jak będzie prze­bie­ga­ło two­rze­nie kodu, jeśli wie­my na razie tyl­ko to, że ma powstać fak­tu­ra zaś o tym, że doty­czy zamó­wień z inne­go sys­te­mu i wła­sne­go maga­zy­nu dowie­my się jutro mając już coś napi­sa­ne”? Bo ja mam wra­że­nie, że to po pro­tu sta­re funk­cyj­ne podej­ście tyle, że z uży­ciem klas obiek­tów, metod i atry­bu­tów” bo nie raz, patrząc na pra­ce nie­któ­rych pro­gra­mi­stów, nie prze­cho­dzi mi przez gar­dło para­dyg­mat obiektowy”.

Czym to gro­zi? Długim cza­sem kodo­wa­nia, kolej­ny­mi pro­to­ty­pa­mi i dzie­siąt­ka­mi mody­fi­ka­cji kodu, bra­kiem zro­zu­mie­nia, uprosz­cze­nia­mi wyma­gań czy­li jed­nym sło­wem: duży­mi pie­niędz­mi za kiep­ski pro­gram (skąd to znamy??).

Dlatego pro­szę pro­gra­mi­stów: rób­cie to co rozu­mie­cie i nie wma­wiaj­cie niko­mu, że wie­cie lepiej jak zarzą­dzać fir­mą Waszych klien­tów. Róbcie to co każ­dy dobry sto­larz: popro­ście klien­ta o rysu­nek tego co ma powstać i zrób­cie. Nie zapo­mi­naj­cie, że dobry sto­larz to nie to samo do dobry pro­jek­tant, jak klient nie potra­fi ryso­wać (a naj­czę­ściej nie, bo nie to jest jego kom­pe­ten­cją), dobry sto­larz zawsze ode­śle do pro­jek­tan­ta po rysu­nek. Między inny­mi dla­te­go, by póź­niej nie być posą­dzo­nym o stron­ni­czość czy­li ryso­wa­nie tyl­ko tego co jest łatwe w wyko­na­niu. Rzecz w tym, że nie ma być łatwe dla sto­la­rza a dobre dla klienta.

Pod tym wszyst­kim pod­pi­su­ję się ja, Jarek Rysownik

P.S.

Ten arty­kuł powi­nien mieć chy­ba tytuł: Manifest analityka-projektanta ;).

Ach ten wstrętny, wścibski analityk

Znowu o tym, tak: o ana­li­zie, pro­jek­to­wa­niu i … ryzy­ku. Czy ana­li­za jest koniecz­na? Nie! To cze­mu słu­ży? By praw­do­po­do­bień­stwo tego, że uda się stwo­rzyć i wdro­żyć wła­ści­we opro­gra­mo­wa­nie było jak naj­więk­sze. Ale o co cho­dzi? Ano nie zawsze jest tak, że to praw­do­po­do­bień­stwo jest wystar­cza­ją­co duże! Ale po kolei.

Wprowadzenie

Obecnie na ryn­ku coraz bar­dziej domi­nu­ją tak zwa­ne obiek­to­we meto­dy ana­li­zy, pro­jek­to­wa­nia i pro­gra­mo­wa­nia. W czym pro­blem? Jedyną nama­cal­ną rze­czą jest kod i od pro­gra­mo­wa­nia (kodo­wa­nia) nie ma uciecz­ki: kod musi powstać by powsta­ło opro­gra­mo­wa­nie. Pozostaje ana­li­za i pro­jek­to­wa­nie – to moż­na pomi­nąć, moż­na od razu kodo­wać nicze­go nie ana­li­zu­jąc ani nie projektując.

Myślenie zama­wia­ją­ce­go: Te dwa eta­py, ana­li­za i pro­jek­to­wa­nie, to dodat­ko­wy koszt: może da się go uniknąć.

Myślenie pro­gra­mi­sty: Istniejący pro­jekt to wią­za­nie mi rąk, mojej kre­atyw­no­ści i roz­wo­ju: może uda się od razu zacząć kodować.

Nie raz pro­gra­mi­sta, w sumie tak­że wyko­naw­ca, doda­je sobie powyż­sze myśle­nie klien­ta: unik­nę kosz­tu ana­li­zy i projektowania.

Obaj mają ten sam cel! Pominąć ana­li­zę i projektowanie! 

A teraz po kolei i od koń­ca. Posłużymy się defi­ni­cja­mi a potem je jakoś razem pokle­imy. Mimo, że pod­cho­dzę z dużą rezer­wą do WIKI, posłu­żę się tymi stro­na­mi, gdyż są w więk­szo­ści reda­go­wa­ne przez ludzi zwią­za­nych z infor­ma­ty­ką, nie raz wła­śnie przez pro­gra­mi­stów programistów.

Programowanie obiektowe

Na począ­tek definicja:

Programowanie obiek­to­we (ang. object-orien­ted pro­gram­ming) ? para­dyg­mat pro­gra­mo­wa­nia, w któ­rym pro­gra­my defi­niu­je się za pomo­cą obiek­tów ? ele­men­tów łączą­cych stan (czy­li dane, nazy­wa­ne naj­czę­ściej pola­mi) i zacho­wa­nie (czy­li pro­ce­du­ry, tu: meto­dy). Obiektowy pro­gram kom­pu­te­ro­wy wyra­żo­ny jest jako zbiór takich obiek­tów, komu­ni­ku­ją­cych się pomię­dzy sobą w celu wyko­ny­wa­nia zadań.

Podejście to róż­ni się od tra­dy­cyj­ne­go pro­gra­mo­wa­nia pro­ce­du­ral­ne­go, gdzie dane i pro­ce­du­ry nie są ze sobą bez­po­śred­nio zwią­za­ne. Programowanie obiek­to­we ma uła­twić pisa­nie, kon­ser­wa­cję i wie­lo­krot­ne uży­cie pro­gra­mów lub ich frag­men­tów. (źr. WIKI)

Jak widać, mamy nowe narzę­dzie dla pro­gra­mi­stów, kolej­na edy­cja struk­tu­ra­li­za­cji kodu. cza­sem spo­ty­kam się u pro­gra­mi­stów z defi­ni­cją: pro­gra­mo­wa­nie obiek­to­we to ukła­da­nie kodu w pod­pro­gra­my łączą­ce dane i ope­ra­cje na nich. Tak więc tyl­ko tech­no­lo­gia. Drugi aka­pit tyl­ko to pod­kre­śla: tu tyl­ko technologia.

Powstaje opro­gra­mo­wa­nie.

Projektowanie obiektowe

I tu problem:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Projektowanie obiek­to­we? w Wikipedii. (dziś jest 24 Maj 2011, zno­wu spraw­dzam i nadal nie ma a jest 07 luty 2019).

Nie ma takiej defi­ni­cji w pol­skim WIKI. Czyżby nasi” nie projektowali?

Object-orien­ted design is the pro­cess of plan­ning a sys­tem of inte­rac­ting objects for the pur­po­se of solving a softwa­re pro­blem. It is one appro­ach to softwa­re design. (źr, http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​O​b​j​e​c​t​-​o​r​i​e​n​t​e​d​_​d​e​s​ign)

Uff, jed­nak pro­jek­tu­ją. Tak więc pro­jek­to­wa­nie obiek­to­we to zorien­to­wa­ny obiek­to­wo (para­dyg­mat obiek­to­wy) pro­ces roz­wią­zy­wa­nia pro­ble­mu poprzez pro­jek­to­wa­nie opro­gra­mo­wa­nia jako sys­te­mu komu­ni­ku­ją­cych się obiek­tów. Tak wiec moż­na przed roz­po­czę­ciem kodo­wa­nia, zapla­no­wać to co sta­nie zako­do­wa­ne. Gdzie indziej tak robią.

Powstaje pro­jekt opro­gra­mo­wa­nia (prze­my­śla­ny!).

[nie­ste­ty, wbrew temu co piszą pro­gra­mi­ści, para­dyg­mat obiek­to­wy to nie łącze­nie danych i funk­cji w obiek­ty, a budo­wa­nie sys­te­mu jako zesta­wu współ­pra­cu­ją­cych obiek­tów reagu­ją­cych w okre­ślo­ny spo­sób na okre­ślo­ne bodź­ce, obiek­ty są defi­nio­wa­ne wła­ści­wo­ścia­mi jaki­mi są ich atry­bu­ty i ope­ra­cje, cechu­ją się cał­ko­wi­tą her­me­ty­za­cją, czy­ni nie ujaw­nia­ją swo­ich wła­ści­wo­ści na zewnątrz.]

Analiza obiektowa

Kolejne podej­ście do Wikipedii:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Analiza obiek­to­wa? w Wikipedii. (dziś jest 24 Maj 2011, spraw­dzam 07 luty 2019, nadal nie ma)

Mam pecha, nasi nie ana­li­zu­ją. Znowu spo­glą­da­my na stro­ny anglo­sa­skich WIKI:

Object-orien­ted ana­ly­sis (OOA) looks at the pro­blem doma­in, with the aim of pro­du­cing a con­cep­tu­al model of the infor­ma­tion that exi­sts in the area being ana­ly­zed. Analysis models do not con­si­der any imple­men­ta­tion con­stra­ints that might exist, such as con­cur­ren­cy, distri­bu­tion, per­si­sten­ce, or how the sys­tem is to be built. Implementation con­stra­ints are dealt during object-orien­ted design (OOD). Analysis is done befo­re the Design. (źr. http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​O​b​j​e​c​t​-​o​r​i​e​n​t​e​d​_​a​n​a​l​y​s​i​s​_​a​n​d​_​d​e​s​ign)

W dużym skró­cie: ana­li­za obiek­to­wa (ana­li­za zorien­to­wa­na obiek­to­wo) to opra­co­wa­nie mode­lu poję­cio­we­go infor­ma­cji, opi­su­ją­ce­go bada­ną dome­nę (czy­li ana­li­zo­wa­ny obszar dzie­dzi­no­wy, np. kon­kret­na orga­ni­za­cja, fir­ma nasze­go klien­ta). Kolejny etap to pro­jek­to­wa­nie obiek­to­we. Model ana­li­tycz­ny nie powi­nien zawie­rać ogra­ni­czeń tech­no­lo­gicz­nych (imple­men­ta­cyj­nych), te ogra­ni­cze­nia powin­ny być bra­ne pod uwa­gę dopie­ro na eta­pie pro­jek­to­wa­nia (to pra­ca pro­gra­mi­stów). I na koniec tra­ge­dia: ana­li­za powin­na być wyko­na­na przed roz­po­czę­ciem projektowania!

Powstaje obiek­to­wy model ele­men­tów orga­ni­za­cji zama­wia­ją­ce­go (pole­cam arty­kuł o Domain Driven Design).

Druga strona barykady: Analiza procesowa

Tradycyjnie idzie­my do WIKI:

Przepraszamy, ale nie ma jesz­cze arty­ku­łu ?Analiza pro­ce­so­wa? w Wikipedii. (24 Maj 2011)

No cóż, szu­ka­my dalej:

Process ana­ly­sis pre­sents a chro­no­lo­gi­cal sequ­en­ce of steps that expla­in how some­thing is done, how some­thing hap­pens, or how readers can do some­thing. (źr. http://​www​.tcc​.edu/​s​t​u​d​e​n​t​s​/​r​e​s​o​u​r​c​e​s​/​w​r​i​t​c​e​n​t​/​h​a​n​d​o​u​t​s​/​w​r​i​t​i​n​g​/​p​r​o​c​e​s​s​.​htm).

Coś mamy: ana­li­za pro­ce­so­wa pre­zen­tu­je w posta­ci chro­no­lo­gicz­nej sekwen­cji kro­ków, to jak coś powsta­je, co się wyda­rza lub jak moż­na coś zro­bić. Piękna defi­ni­cja. Ta pre­zen­ta­cja to, w kon­tek­ście biz­ne­so­wym, model (mapa) pro­ce­sów biznesowych.

Mamy wiec upo­rząd­ko­wa­ną wie­dzę o fir­mie (orga­ni­za­cji) zama­wia­ją­ce­go opro­gra­mo­wa­nie. Tu tak­że powsta­je opis tego po co i gdzie tego opro­gra­mo­wa­nia chce­my uży­wać: model procesowy.

Tak zwane niedopasowanie oporu

Tak jest nazy­wa­na w lite­ra­tu­rze róż­ni­ca pomię­dzy para­dyg­ma­tem pro­ce­so­wym a obiek­to­wym. Paradygmat pro­ce­so­wy ope­ru­je taki­mi poję­cia­mi jak: pro­ces, wej­ście pro­ce­su, wyj­ście pro­ce­su, zda­rze­nie, wyko­naw­ca pro­ce­su (zaso­by), czyn­ność (lub ich sekwen­cja). Paradygmat obiek­to­wy to wspo­mnia­ne obiek­ty czy­li struk­tu­ry łączą­ce dane i meto­dy ich prze­twa­rza­nia. W czym pro­blem? W przej­ściu z mode­lu pro­ce­so­we­go na obiek­to­wy. Czy to łatwe? Nie. Jak to zro­bić? Hm… usiąść i popra­co­wać nad tym.

Należy prze­pro­wa­dzić ana­li­zę obiek­to­wą i wyko­nać model obiek­to­wy. Czego? Kodu? Nie! Organizacji zamawiającego!

W latach 60-tych (tak!) powsta­ły meto­dy obiek­to­we ana­li­zy i pro­jek­to­wa­nia jako pomysł na mode­lo­wa­nie świa­ta” tak jak jest postrze­ga­ny: w posta­ci obiek­tów mają­cych jakąś wie­dzę i jakieś umie­jęt­no­ści. To ana­li­za obiek­to­wa (sama w sobie nie ma ona nic wspól­ne­go z programowaniem!).

Skoro wie­le pro­ble­mów pro­gra­mi­stycz­nych doty­czy świa­ta rze­czy­wi­ste­go, powstał pomysł stwo­rze­nia języ­ka (ów) pro­gra­mo­wa­nia pasu­ją­ce­go” do pro­duk­tu ana­li­zy obiek­to­wej: mode­lu obiek­to­we­go: powstał obiek­to­wy język pro­gra­mo­wa­nia Small Talk.

Dzisiaj mamy sytu­ację, w któ­rej pro­gra­mi­ści uży­wa­ją obiek­to­wych narzę­dzi pro­gra­mi­stycz­nych i nie­ste­ty postrze­ga­ją je tyl­ko jako nowe meto­dy łącze­nia funk­cji i danych.

A teraz to wszystko narysuję

Zebrałem wszyst­ko powyż­szej i mamy:

Paradygmat obiektowy i procesowy, proces analizy
Paradygmat obiek­to­wy i pro­ce­so­wy, pro­ces analizy

U góry fir­ma (orga­ni­za­cja klien­ta), by zro­zu­mieć ją, pro­wa­dzi­my ana­li­zę pro­ce­so­wą. To ana­li­za ukie­run­ko­wa­na na zarzą­dza­nie czy­li kto, co i po robi. Jak odkry­je­my, że coś war­to uspraw­nić, robi­my to.

Wiedząc, że meto­dy obiek­to­we są sku­tecz­niej­sze w pro­jek­tach biz­ne­so­wych inży­nie­rii opro­gra­mo­wa­nia (no coś nale­ży uznać), opra­co­wu­je­my (prze­cho­dzi­my na) model obiek­to­wy tej organizacji.

Innymi sło­wy, model pro­ce­sów słu­ży nam do zro­zu­mie­nia tego jak dzia­ła orga­ni­za­cja, bo war­tość doda­na powsta­je jako pro­dukt pro­ce­su (biz­ne­so­we­go). Opracowanie narzę­dzia, jakim jest opro­gra­mo­wa­nie, wyma­ga opra­co­wa­nia okre­ślo­nej kon­struk­cji sys­te­mu, a ten jako taki jest obiektowy.

Jeżeli model pro­ce­so­wy orga­ni­za­cji poka­zu­je jak się ona zacho­wu­je, to model obiek­to­wy poka­zu­je czym ona jest.

W pro­ce­sie ana­li­zy obiek­to­wej powsta­je model obiek­to­wy bada­nej orga­ni­za­cji. Tu ma miej­sce trans­for­ma­cja para­dyg­ma­tu pro­ce­so­we­go na obiek­to­wy. To naj­trud­niej­sza część całe­go pro­jek­tu, tu powsta­je naj­więk­sze ryzy­ko, zła ana­li­za obiek­to­wa skut­ku­je jesz­cze gor­szym opro­gra­mo­wa­niem. Z regu­ły model obiek­to­wy jest two­rzo­ny nie dla całej orga­ni­za­cji a dla jej czę­ści (opro­gra­mo­wa­nie to jedy­nie narzę­dzie wspie­ra­ją­ce ludzi a nie cała firma).

Mając obiek­to­wy model wybra­ne­go obsza­ru orga­ni­za­cji i cel pro­jek­tu (koniecz­nie) two­rzy­my pro­jekt przy­szłe­go opro­gra­mo­wa­nia. Tu mała uwa­ga: opro­gra­mo­wa­nie to dwa aspek­ty: jego funk­cjo­nal­ność oraz tech­nicz­ne para­me­try takie jak bez­pie­czeń­stwo, wydaj­ność i dostęp­ność. Funkcjonalność wyni­ka wprost z pro­duk­tu ana­li­zy obiek­to­wej, para­me­try tech­nicz­ne to poza biz­ne­so­we ele­men­ty, któ­rych pro­jek­tan­ta­mi są inży­nie­ro­wie i programiści.

Mając pro­jekt, sia­da­my w koń­cu i kodu­je­my. Powstało opro­gra­mo­wa­nie, któ­re wspie­ra w usta­lo­nym obsza­rze orga­ni­za­cję zama­wia­ją­ce­go: opro­gra­mo­wa­nie to narzę­dzie. Na każ­dym eta­pie powyż­sze­go pro­ce­su powin­no się doko­nać oce­ny jako­ści pro­duk­tu. Należy spraw­dzić (upew­nić się), że mode­le są praw­dzi­we, i że ich imple­men­ta­cja dopro­wa­dzi do powsta­nia ocze­ki­wa­ne­go opro­gra­mo­wa­nia. Jak? Testując je. Jak? Opisałem to już 🙂 w poprzed­nich artykułach.

Diagram powyż­szy wyróż­nia dwa obsza­ry: żół­ty, któ­ry wska­zu­je na kom­pe­ten­cje Analityka Biznesowego oraz fio­le­to­wy, wska­zu­ją­cy na obszar kom­pe­ten­cyj­ny Dewelopera (wyko­naw­cy, dostaw­cy oprogramowania). 

Opracowanie mode­lu biz­ne­so­we­go (pro­ce­so­wy i obiek­to­wy) wyma­ga bar­dzo dużej wie­dzy z zakre­su zarzą­dza­nia i mar­ke­tin­gu. Wykonanie imple­men­ta­cji wyma­ga oczy­wi­ście dużej wie­dzy i doświad­cze­nia w zakre­sie inży­nie­rii opro­gra­mo­wa­nia. Są to nie­ste­ty dwa zupeł­nie odręb­ne obsza­ry wie­dzy i połą­cze­nie ich w jed­nej oso­bie jest nie­zwy­kle rzad­kie. Ale nawet jeśli znaj­dzie­my taka oso­bę, eta­py te powin­ny zostać roz­dzie­lo­ne z inne­go powo­du: wyko­naw­ca w biz­ne­sie nie powi­nien sam sobie sta­wiać wyma­gań! Rodzi to ogrom­ne ryzy­ko nad­użyć. (wię­cej o podzia­le na role w pro­jek­cie)

Komunikacja: powszech­nie uzna­ną meto­dą komu­ni­ka­cji w takich pro­jek­tach jest wła­śnie two­rze­nie mode­li, sfor­ma­li­zo­wa­nych dia­gra­mów obra­zu­ją­cych pro­duk­ty poszcze­gól­nych eta­pów ana­liz i pro­jek­to­wa­nia. O nota­cjach (stan­dar­dach two­rze­nia dia­gra­mów) w innych postach (są to głow­nie BPMN i UML). Warto tu tyl­ko przy­to­czyć sta­re porze­ka­dło: rysu­nek wart tysią­ca słów. Kod jest zaś na samym koń­cu osta­tecz­nym produktem.

Agile

Najpierw przy­to­czę tak zwa­ny Manifest Agile:

Manifest Zwinnego Tworzenia Oprogramowania

Wytwarzając opro­gra­mo­wa­nie i poma­ga­jąc innym w tym zakre­sie, odkry­wa­my lep­sze spo­so­by wyko­ny­wa­nia tej pra­cy. W wyni­ku tych doświad­czeń przedkładamy:

Ludzie i inte­rak­cje ponad pro­ce­sy i narzędzia.

Działające opro­gra­mo­wa­nie ponad obszer­ną dokumentację.

Współpraca z klien­tem ponad for­mal­ne ustalenia.

Reagowanie na zmia­ny ponad podą­ża­nie za planem.

Doceniamy to, co wymie­nio­no po pra­wej stronie,

jed­nak bar­dziej ceni­my to, co po lewej.

Cóż, zastą­pie­nie pro­ce­su ana­li­zy i pro­jek­to­wa­nia wer­bal­ną komu­ni­ka­cją to dro­ga na skró­ty: czer­wo­na strzał­ka. Czy to zła dro­ga? Droga na skró­ty to wspo­mnia­ne na począt­ku ryzy­ko, ogrom­ne bo sta­ty­sty­ki wska­zu­ją sta­le, że ok. 70 – 80% pro­jek­tów pro­gra­mi­stycz­nych ma poważ­ne kło­po­ty. Statystyki te są takie same od lat. Dlaczego? Skoro od razu kodu­je­my to pomi­nę­li­śmy pośred­nie spraw­dze­nia i weryfikacje.

Od lat zna­ny jest powyż­szy pro­ces i mimo to zawsze jest te 80% klien­tów i ich dostaw­ców, któ­rzy doga­du­ją się, że ana­li­za i pro­jek­to­wa­nia żad­ne­mu z nich nie słu­ży… tak jak to napi­sa­no na początku.

Po co to napi­sa­łem? By każ­dy z Państwa sam, świa­do­mie, oce­niał ryzy­ko swo­ich pro­jek­tów. Rezygnacja z ana­li­zy i pro­jek­to­wa­nia to pod­ję­cie pew­ne­go ryzy­ka. Niestety rezy­gna­cja z ana­li­zy i pro­jek­to­wa­nia ze stro­ny dewe­lo­pe­ra to cza­sem dodat­ko­wo sku­tek przy­zna­nia, że ana­li­za i pro­jek­to­wa­nie leży poza kom­pe­ten­cja­mi pro­gra­mi­stów (Ci obiek­to­wo kodu­ją) wiec wybie­ra­na jest dro­ga na skróty.

A Agile? Mam dziw­ne wra­że­nie, że to z jed­nej stro­ny łapa­nie brzy­twy przez toną­ce­go, ratu­nek, głos pro­gra­mi­stów pozba­wio­nych ana­li­ty­ka i pro­jek­tan­ta, a z dru­giej meto­dy­ka pozby­cia się roli nie pasu­ją­cej od para­dyg­ma­tu” pro­gra­mi­sty, któ­ry bada i roz­wi­ja się poprzez sta­łe ćwi­cze­nie się w swo­im fachu”, szko­da, że nie raz na cudzej skórze.

Pominięcie jed­nak ana­li­zy i pro­jek­to­wa­nia pro­wa­dzi do pro­gra­mów gdzie para­dyg­mat obiek­to­wy, koń­czy się na tym, że owe struk­tu­ry łączą­ce dane i ope­ra­cje na nich” powsta­ją jako sztucz­ne byty, nie mają­ce nic wspól­ne­go z rze­czy­wi­sto­ścią, a co naj­wy­żej z wygo­dą kodu­ją­ce­go pro­gra­mi­sty. Tak wła­śnie powsta­ją bar­dzo czę­sto bar­dzo złe pro­gra­my: nie­roz­wo­jo­we, nie­ży­cio­we, nie­na­tu­ral­ne w pracy.

I nie cho­dzi o to by koniecz­nie zatrud­niać ana­li­ty­ka, cho­dzi o to by rze­tel­nie wyko­nać ana­li­zę i pro­jekt zanim roz­pocz­nie­my kodowanie.