Wzorce projektowe Książki

Wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Analiza biz­ne­so­wa i projektowanie

Wstęp

W arty­ku­le o apli­ka­cjach webo­wych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wza­jem­na nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług apli­ka­cyj­nych. (źr.: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych).

Przy innej oka­zji pisa­łem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzor­ce projektowe ) 

Szkolenia dla ana­li­ty­ków poprze­dzam ankie­ta­mi przed szko­le­nio­wy­mi, jak do tej pory żad­na nie zawie­ra­ła pytań o wzor­ce pro­jek­to­we: ani tego że są uży­wa­ne ani tego, że są celem szko­le­nia, nie­mal­że każ­dy dekla­ru­je albo, że uży­wa UML lub, że chce zacząć uży­wać UML, nawet gdy są to pro­gra­mi­ści. Zauważyłem, że wzor­ce pro­jek­to­we w świa­do­mo­ści ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia (OOAD) nie ist­nie­ją”. Wśród pro­gra­mi­stów, jeże­li jest spo­ty­ka­na, to wie­dza o wzor­cach przy­dat­nych w two­rze­niu biblio­tek i narzę­dzi, czę­sto też powie­la­ne są wyuczo­ne sta­re i złe prak­ty­ki pro­gra­mi­stycz­ne rodem z lat 60-tych (np. prak­ty­ki SmallTalk, patrz dalej). 

Z dru­giej stro­ny od wie­lu lat zna­ne są tech­ni­ki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), któ­re w róż­nych for­mach, ale jed­nak wska­zu­ją, że naj­sku­tecz­niej­sza for­ma wyra­ża­nia wyma­gań wobec roz­wią­za­nia to pro­jekt archi­tek­tu­ry i logi­ki dzie­dzi­no­wej (model) dzia­ła­nia apli­ka­cji . O pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cję pisze sie od dość daw­na, meto­dy obiek­to­we i dobre prak­ty­ki zna­ne są od lat .

Autorzy BABoK prak­tycz­nie od począt­ku ist­nie­nia tego wydaw­nic­twa, zwra­ca­ją uwa­gę na tak zwa­ną bia­łą skrzyn­kę”, czy­li wyma­ga­nia wyra­żo­ne w posta­ci wewnętrz­nej struk­tu­ry pro­duk­tu, wska­zu­jąc, że to znacz­nie sku­tecz­niej­sza meto­da defi­nio­wa­nia wyma­gań wobec roz­wią­za­nia, niż tak zwa­na czar­na skrzyn­ka”, czy­li tra­dy­cyj­ne, i jed­nak mniej sku­tecz­ne, wyma­ga­nia wyra­żo­ne tyl­ko jako cechy funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Pamiętajmy, że adre­sa­tem wyma­gań jest zawsze dostaw­ca produktu!

Czytaj dalej… Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu”

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.

Analiza a modelowanie czyli ile abstrakcji a ile rzeczywistości

Regularnie obser­wu­ję pew­ną trud­ność jaką spra­wia wie­lu ludziom, z jed­nej stro­ny sto­so­wa­nie sys­te­mów nota­cyj­nych a z dru­giej samo mode­lo­wa­nie. Wspólną czę­ścią obu tych obsza­rów jest abs­tra­ho­wa­nie od szcze­gó­łów. Praktycznie każ­dy mój klient i bar­dzo czę­sto, ana­li­ty­cy i pro­jek­tan­ci deve­lo­pe­rów reali­zu­ją­cych pro­jek­ty któ­re nad­zo­ru­ję, zada­ją mi pyta­nia: a gdzie zoba­czę to, że zamó­wie­nie może być dla inne­go pro­duk­tu i inne­go seg­men­tu.…. itp. Innymi sło­wy: na dowol­nym eta­pie pra­cy pada­ją pyta­nia o bar­dzo deta­licz­ne szcze­gó­ły kon­kret­nych ope­ra­cji. Co praw­da, jak to mawia­ją dia­beł tkwi w szcze­gó­łach”, z czym wypa­da się zgo­dzić, ale to dokład­nie ten wła­śnie dia­beł nisz­czy pro­jek­ty pro­wa­dząc nie raz do utra­ty pano­wa­nia nad szcze­gó­ło­wo­ścią pro­jek­tu”. Dokładnie dwa lata temu opi­sy­wa­łem mode­lo­wa­nie pro­blem deta­li w arty­ku­le Gdzie są te cho­ler­ne szcze­gó­ły, a kwe­stie zasad (reguł) dzia­ła­nia apli­ka­cji w nie­daw­nym arty­ku­le Mechanizm dzia­ła­nia. Dzisiaj będzie o mode­lach i abstrakcjach.

Modele a abstrakcje

Modelowanie ma dwa aspek­ty: pro­jek­to­wa­nie jako two­rze­nie mode­lu przy­szłej (pro­jek­to­wa­nej) rze­czy­wi­sto­ści oraz ana­li­za jako two­rze­nie mode­lu bada­nej, ist­nie­ją­cej rze­czy­wi­sto­ści. Model jako taki nie jest abs­trak­cją cze­goś, jest uprosz­czo­nym obra­zem lub opi­sem z okre­ślo­nej per­spek­ty­wy, ale zacho­wu­ją­cym okre­ślo­ne cechy rze­czy­wi­sto­ści. Model z defi­ni­cji jest zawsze uprosz­cze­niem, inny­mi sło­wy, jest pozba­wio­ny okre­ślo­nych szcze­gó­łów, tych któ­re w danym zasto­so­wa­niu mode­lu (kon­tekst) są nie­istot­ne. Pojęcia model i abs­trak­cja są czę­sto mylo­ne, bywa że sto­so­wa­ne zamien­nie, co jest bar­dzo dużym błędem.

Podstawowym narzę­dziem ana­li­zy jest pro­ces redu­ko­wa­nia szcze­gó­łów, w prze­ciw­nym wypad­ku pra­co­chłon­ność opra­co­wa­nia mode­lu i póź­niej­sza jego ana­li­za, może wręcz unie­moż­li­wić rze­tel­ne ich prze­pro­wa­dze­nie, może być to nawet nie­wy­ko­nal­ne z uwa­gi na ich nad­mier­ną zło­żo­ność. Słownik j. pol­skie­go PWN poda­je nastę­pu­ją­ce definicje:

abs­trak­cja: poję­cie ogól­ne, nie­ma­ją­ce odpo­wied­ni­ka w żad­nym kon­kret­nym przedmiocie;

model: kon­struk­cja, sche­mat lub opis uka­zu­ją­cy dzia­ła­nie, budo­wę, cechy, zależ­no­ści jakie­goś zja­wi­ska lub obiektu;

Pomiędzy poję­cia­mi abs­trak­cja i model jest pew­na klu­czo­wa róż­ni­ca: abs­trak­cja to poję­cie zaś model to opis mecha­ni­zmu, jego kon­struk­cja, dzia­ła­nie, budo­wa. Prosty przy­kład: nazwa­ne pro­sto­ką­ty na typo­wym dia­gra­mie struk­tu­ry orga­ni­za­cyj­nej to abs­trak­cje komó­rek orga­ni­za­cyj­nych i osób w nich zatrud­nio­nych, pro­sto­ką­ty te wraz z linia­mi je łączą­cy­mi sta­no­wią, jako całość, model pod­le­gło­ści zaso­bów w orga­ni­za­cji. Nieco ponad pół roku temu opi­sa­łem to w arty­ku­le Diagram obiek­tów czy­li bot­tom-up:

Generalnie rzecz w tym, by poka­zać to co wie­my czy­li kon­kret­ne nazwa­ne egzem­pla­rze ?tych rze­czy?, o któ­rych ktoś mówi lub któ­re obser­wu­je­my. To egzem­pla­rze i ich spe­cy­fi­ka­cja (nazwy, cechy itp.). Innymi sło­wy
dia­gram obiek­tów słu­ży do poka­za­nia kon­kret­ne­go, obser­wo­wal­ne­go sta­nu rze­czy.
Jeżeli więc z jakie­goś powo­du nie może­my ope­ro­wać uogól­nie­nia­mi (kla­sy) bo nie posia­da­my odpo­wied­niej wie­dzy lub jest ona zbyt ubo­ga, ana­li­zę moż­na pro­wa­dzić ?od dołu? czy­li mając szcze­gó­ły uogól­niać je. Poważną zale­tą tej meto­dy jest łatwość wery­fi­ka­cji mode­lu przez ?klien­ta?. Większość ludzi nie radzi sobie z abs­trak­cja­mi (np. meta­mo­de­le): mode­le budo­wa­ne z uży­ciem dia­gra­mów klas to uogól­nie­nia: opi­su­ją kla­sy a nie kon­kret­ną rze­czy­wi­stość. Diagramy obiek­tów (instan­cje klas) to nic inne­go jak mode­le ?kon­kret­nych sytu­acji? z życia. (Źródło: Diagram Obiektów | Jarosław Żeliński IT-Consulting)

Poziomy abstrakcji w UML

Notacja UML pozwa­la na mode­lo­wa­nie na obu wyżej wymie­nio­nych pozio­mach. W ramach [[MOF]]/[[UML]] wyróż­nia­my łącz­nie czte­ry pozio­my uogól­nie­nia ozna­czo­ne od M0 do M3. M0 to świat rze­czy­wi­stych bytów. M1 to model w któ­rym kon­kret­ne rze­czy­wi­ste byty zastę­pu­je się ich abs­trak­cja­mi (np. nazwa­ne pro­sto­ką­ty), któ­rych jest tyle ile rze­czy­wi­stych obiek­tów. Poziom M2 to meta­mo­del, czy­li wszyst­kie nazwa­ne ele­men­ty kla­sy­fi­ku­je­my i zastę­pu­je­my kla­sy­fi­ka­to­ra­mi. Obiekty mają­ce pew­ne usta­lo­ne wspól­ne cechy (całą ich gru­pę) zastę­pu­je­my jed­nym kla­sy­fi­ka­to­rem. Np. na pozio­mie M1 model dru­ży­ny pił­kar­skiej będzie zawie­rał 11 nazwa­nych obiek­tów (tu pro­sto­kąt to abs­trak­cja zawod­ni­ka). Na pozio­mie M2 model tej dru­ży­ny to była by już tyl­ko kla­sa Zawodnik, zapew­ne jed­nym z jej atry­bu­tów było­by imię i nazwi­sko oraz numer zawod­ni­ka a dru­gim jego rola (bram­karz lub zawod­nik w polu, to decy­du­je o jego zacho­wa­niu). Na naj­wyż­szym pozio­mie M3 mamy tyl­ko zde­fi­nio­wa­ne poję­cie klasyfikatora.

Notacja UML pozwa­la na mode­lo­wa­nie (two­rze­nie mode­li i meta­mo­de­li) na pozio­mach M1 i M2 (poziom M3 to defi­ni­cja kla­sy­fi­ka­to­ra w UML, pole­cam tu książ­kę Model-Driven Software Engineering…). Poniżej dia­gram obra­zu­ją­cy te czte­ry pozio­my oraz tak­so­no­mie dia­gra­mów w UML 2.5 gdzie dia­gra­my zosta­ły sko­ja­rzo­ne z odpo­wia­da­ją­cy­mi im pozio­ma­mi abstrakcji.

Poziomy modelowania (opracowanie własne Jarosław Żeliński na podstawie OMG UML 2.5 oraz OMG Meta-Object Facility (MOF))
Poziomy mode­lo­wa­nia (opra­co­wa­nie wła­sne Jarosław Żeliński na pod­sta­wie OMG UML 2.5 oraz OMG Meta-Object Facility (MOF))

Warto o tym pamię­tać, głów­nie z tego powo­du, że dia­gram klas nota­cji UML jest powszech­nie nad­uży­wa­ny, wie­le mode­li, szcze­gól­nie doku­men­tu­ją­cych stan fak­tycz­ny kon­kret­nej apli­ka­cji i wdro­że­nia, powin­no być dia­gra­ma­mi obiek­tów i wdro­że­nia a nie dia­gra­ma­mi klas czy kom­po­nen­tów, bo te osta­nie to jedy­nie meta­mo­de­le. Warto też wie­dzieć, że kod pro­gra­mu to meta­mo­del tego co zosta­nie wytwo­rzo­ne w pamię­ci kom­pu­te­ra (bo to jest model rze­czy­wo­sto­ści), po uru­cho­mie­niu tego pro­gra­mu. W kodzie np. gry będzie kla­sa zawod­nik, ale po uru­cho­mie­niu gry kom­pu­te­ro­wej, w pamię­ci będzie 11 wyge­ne­ro­wa­nych z tych klas obiek­tów, repre­zen­tu­ją­cych zawod­ni­ków drużyny.

Na powyż­szym dia­gra­mie, po jego lewej stro­nie, poka­za­łem tak­że, że pro­jek­to­wa­nie cze­goś jest roz­po­czy­na­niem pra­cy od two­rze­nia okre­ślo­nej abs­trak­cji pomy­słu (z regu­ły obiek­ty a nie kla­sy). Analiza sta­nu rze­czy­wi­ste­go to two­rze­nie tej abs­trak­cji na bazie obser­wa­cji ana­li­zo­wa­nej rzeczywistości.

model-dependent-realism
(źr. https://​thin​kin​mo​dels​.word​press​.com/​2​0​1​1​/​1​1​/​2​4​/​m​o​d​e​l​-​d​e​p​e​n​d​e​n​t​-​r​e​a​l​i​s​m​-​i​s​-​t​h​i​s​-​t​h​e​-​w​o​r​l​d​v​i​e​w​-​o​f​-​s​o​f​t​w​a​r​e​-​e​n​g​i​n​e​e​r​i​ng/)

Projekty w obsza­rze inży­nie­rii opro­gra­mo­wa­nia, two­rzo­ne w duchu para­dyg­ma­tu obiek­to­we­go to:

  1. ana­li­za rze­czy­wi­sto­ści i zbu­do­wa­nie jej obiek­to­wej abs­trak­cji (dia­gram obiektów),
  2. okre­śle­nie, któ­ry obszar rze­czy­wi­sto­ści zosta­nie zastą­pio­ny opro­gra­mo­wa­niem (np. papie­ro­we kar­to­te­ki w bibliotece),
  3. zbu­do­wa­nie meta­mo­de­lu wybra­ne­go obsza­ru : to model dzie­dzi­ny (dia­gram klas)

Pierwszy punkt to ele­ment ana­li­zy sys­te­mo­wej: two­rze­nie obiek­to­we­go mode­lu tego co jest ana­li­zo­wa­ne. Podejście obiek­to­we do ana­li­zy i pro­jek­to­wa­nia więc:

…pozwa­la wyjść od kon­kret­ne­go rze­czy­wi­ste­go ?sta­nu świa­ta? i opra­co­wać na jego pod­sta­wie model poję­cio­wy i meta­mo­del. To bar­dzo pomoc­na tech­ni­ka. Warto pamię­tać, że to co nie raz nazy­wa­ne jest ?mode­lem dzie­dzi­ny? jed­nak nim nie jest. (Źródło: Diagram Obiektów | Jarosław Żeliński IT-Consulting)

złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Kolejna wpadka IT: obiektowość

CW 4-1019 Bereza Blad Arystotelesa w IT
CW 4 – 1019 Bereza Blad Arystotelesa w IT

Tym razem wpadł mi w oko dosko­na­ły arty­kuł Pana Bogdana Berezy w COMPUTEROWRLD nr. 4 – 1019 z tego roku. Polecam cały arty­kuł do prze­czy­ta­nia, a po pra­wej cytat, któ­ry obu­dził we mnie potrze­bę uzupełnienia.

Cały arty­kuł doty­czy igno­ro­wa­nia nauki w inży­nie­rii opro­gra­mo­wa­nia na rzecz pro­stych pseu­do­ro­zwią­zań. Tu się z auto­rem w peł­ni zga­dzam: nauka jako szu­ka­nie zro­zu­mie­nia i roz­wią­zań pro­ble­mów poprzez ana­li­zę i uogól­nia­nie ma głę­bo­ki sens, histo­ria poka­zu­je, że tak zwa­ne meto­dy nauko­we są sku­tecz­ne (o czym nie raz tu już pisa­łem) ale też nie­lu­bia­ne bo trudne.

Autor napi­sał tak­że (cytat po pra­wej, moim zda­niem praw­dę), że nastą­pi­ło pew­ne sza­leń­stwo, któ­re w moich oczach dopro­wa­dzi­ło w bran­ży IT to total­ne­go pomie­sza­nia pojęć (ostat­ni aka­pit cyta­tu obok). Nie zgo­dzę się jed­nak z tym, że dane i funk­cje, zade­kla­ro­wa­ne wewnątrz jed­nej funk­cji prze­sta­ją ist­nieć, gdy się te funk­cję opu­ści” (pierw­szy aka­pit cyta­tu po pra­wej). Otóż w meto­dach obiek­to­wych nie ist­nie­je poję­cie funk­cji”, są ope­ra­cje i meto­dy oraz atry­bu­ty a nie dane, a znik­nąć mogą co naj­wy­żej atry­bu­ty obiek­tu (tu trak­to­wa­ne jako jakieś dane) pod warun­kiem, że go – ten obiekt – znisz­czy­my. Tu chy­ba jed­nak mamy pomie­sza­nie pojęć (dodam, że nie rozu­miem stwier­dze­nia funk­cja zawie­ra funk­cje i dane”).

W czym pro­blem? Otóż nale­ży bar­dzo rygo­ry­stycz­nie odróżnić:

  • ana­li­zę obiek­to­wą (OOA – Object Oriented Analysis)
  • pro­jek­to­wa­nie obiek­to­we (OOD – Object Oriented Design)
  • pro­gra­mo­wa­nie obiek­to­we (OOP – Object Oriented Programming)

Autor arty­ku­łu, pisząc jedy­nie o pro­gra­mo­wa­nie obiek­to­wym, w moich oczach ma rację. Co do zgod­no­ści OO z psy­chi­ką to i ja mam wąt­pli­wo­ści, i tu chy­ba fak­tycz­nie pomy­sło­daw­cy popłynęli.

Tu przy­po­mnę kolej­ne waż­ne pojęcia:

  • ogól­na teo­ria sys­te­mów to teo­ria ope­ru­ją­ca poję­ciem sys­tem, defi­nio­wa­nym jako zbiór ele­men­tów współ­pra­cu­ją­cych w okre­ślo­nym celu”, teo­ria ta w zasa­dzie sta­no­wi obec­nie pod­sta­wę tak zwa­nych metod naukowych,
  • para­dyg­mat obiek­to­wy to trak­to­wa­nie okre­ślo­nej rze­czy­wi­sto­ści jako zbio­ru współ­pra­cu­ją­cych obiek­tów reali­zu­ją­cych okre­ślo­ne funk­cje wobec swo­je­go otoczenia”.

Jak widać są to bar­dzo do sie­bie podob­ne (nie­mal­że toż­sa­me) poję­cia. Studiując lite­ra­tu­rę przed­mio­tu zary­zy­ku­ję tezę, że ta zbież­ność nie jest przy­pad­ko­wa :), pierw­sze obiek­to­we języ­ki pro­gra­mo­wa­nia powsta­ły w ośrod­kach aka­de­mic­kich na potrze­by pro­wa­dze­nia badań opar­tych o symulacje.

W świe­cie ludzi IT” poję­cie obiek­to­wo­ści” zosta­ło cał­ko­wi­cie zawłasz­czo­ne na uży­tek języ­ków pro­gra­mo­wa­nia. Jest to w moich oczach wiel­ka szko­da wyrzą­dzo­na obiek­to­we­mu podej­ściu, teo­rii a tak­że samej inży­nie­rii opro­gra­mo­wa­nia. Autor ma rację pisząc, że obiek­to­wość” jako taka (powyż­sze defi­ni­cje) nie ma nic wspól­ne­go (nie tyl­ko) z prze­no­sze­niem danych ze sto­su na ster­tę czy z dzie­dzi­cze­niem. Ale to wła­śnie efekt tego zawłasz­cze­nia (i opis imple­men­ta­cji obiek­to­wo­ści” w języ­kach programowania).

Gdzie zalety i sukces obiektowości?

Jednym z klu­czo­wych czyn­ni­ków ryzy­ka pro­jek­tów z obsza­ru inży­nie­rii opro­gra­mo­wa­nia, two­rzo­ne­go dla firm i orga­ni­za­cji, jest zła jakość spe­cy­fi­ka­cji wyma­gań. Zajmuję się o tym od lat, wszel­kie (słusz­nie skry­ty­ko­wa­ne przez Pana Berezę) pro­ste meto­dy zbie­ra­nia wyma­gań” dają w efek­cie to, co nazy­wa­ne jest nie­kom­plet­no­ścią i nie­spój­no­ścią. Przyczyną pora­żek pro­jek­tów pro­gra­mi­stycz­nych, poda­wa­ną w 100% przy­pad­ków tych pora­żek, jest nie­kom­plet­ność i nad­mia­ro­wość spe­cy­fi­ka­cji wyma­gań. Niekompletność to wyma­ga­nia odkry­wa­ne dopie­ro na eta­pie wdro­że­nia, nad­mia­ro­wość to tak zwa­ne wyma­ga­nia osie­ro­co­ne, czy­li funk­cjo­nal­no­ści zgło­szo­ne jako wyma­ga­ne na eta­pie ana­li­zy wyma­gań i nie wyko­rzy­sty­wa­ne po dostar­cze­niu opro­gra­mo­wa­nia. Pierwsze gene­ru­ją dodat­ko­we kosz­ty, dru­gie to czy­ste mar­no­traw­stwo środ­ków. Nieodkryte wyma­ga­nia dodat­ko­wo nisz­czą” pier­wot­ny harmonogram.

Jak poma­ga tu obiek­to­wość”? Pomaga jako meto­da ana­li­zy, poma­ga jako meto­da pro­jek­to­wa­nia, poprze­dza­ją­ce­go spe­cy­fi­ko­wa­nie wyma­gań. W czym rzecz?

Popularna i fał­szy­wa teza, mówią­ca, że wyma­ga­nia się zbie­ra”, pro­wa­dzi do dekla­ra­tyw­nej i nie­we­ry­fi­ko­wal­nej spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych i poza-funk­cjon­la­nych (przy­po­mi­nam wyma­ga­nia odkry­te i osie­ro­co­ne). Popularna i mitycz­na jakość wyma­gań nazy­wa­na SMART i FURPS nie daje żad­ne­go narzę­dzia do testo­wa­nia kom­plet­no­ści i nie­sprzecz­no­ści wyma­gań, więc nie da się stwier­dzić, że kon­kret­na spe­cy­fi­ka­cja wyma­gań jest SMART i FURPS, wcze­śniej niż po zakoń­cze­niu pro­jek­tu. Tak więc FURPS i SMART spo­koj­nie, moim zda­niem, moż­na zali­czyć do tego co Pan Bereza nazy­wa bzdur­ną misty­fi­ka­cją”, i co nie­ja­ko wyja­śnia pew­na filo­zo­ficz­na praw­da” mówią­ca: nie ist­nie­ją pro­ste meto­dy roz­wią­zy­wa­nia zło­żo­nych problemów.

Sprawdzoną w inży­nie­rii jako takiej, meto­dą, jest pro­ces wytwór­czy mają­cy trzy eta­py: ana­li­za potrzeb, pro­jek­to­wa­nie i testy, wyko­na­nie (wytwo­rze­nie) na bazie pro­jek­tu. Wprowadzenie zmian w każ­dym następ­nym eta­pie jest prze­cięt­nie o rząd wiel­ko­ści kosz­tow­niej­sze. Wynika z tego, że inwe­sty­cja w ana­li­zę i pro­jek­to­wa­nie poprze­dza­ją­ce budo­wę, jest jak naj­bar­dziej uza­sad­nio­na. Jednak kolek­cjo­no­wa­nie wyma­gań” to nie jest żad­na ana­li­za, to dopie­ro zbie­ra­nie danych do analizy.

A gdzie tu OOA, OOD, OOP?

Jak podejść do pro­ble­mu spe­cy­fi­ko­wa­nia wyma­gań” z dużo mniej­szym ryzy­kiem? Zamówić opro­gra­mo­wa­nie na bazie pro­jek­tu, a nie na bazie opi­su czar­nej skrzyn­ki”. Co pro­jek­to­wać? Na pew­nie nie wszyst­ko. Wg. róż­nych sza­cun­ków, tak zwa­na logi­ka biz­ne­so­wa to ok. 3 – 5% cało­ści kodu (któ­ry zawie­ra mię­dzy inny­mi roz­bu­do­wa­ne kom­po­nen­ty komu­ni­ka­cyj­ne, inte­gra­cyj­ne, wydaj­no­ścio­we, bez­pie­czeń­stwa, set­ki biblio­tek, itp.) pro­blem w tym, że te 3 – 5% kodu decy­du­je w 100% o przy­dat­no­ści aplikacji.

Analiza obiek­to­wa (OOA) to meto­da ana­li­zy i opi­su przed­mio­tu ana­li­zo­wa­ne­go (np. orga­ni­za­cji). Projektowanie obiek­to­we (OOD) to meto­da opi­su logi­ki dzia­ła­nia tego co chce­my stwo­rzyć (narzę­dzie pra­cy). Programowanie obiek­to­we to jest to co przy­wo­łał Pan Bereza, jed­nak cechą OOP jest to, że pro­jekt obiek­to­wy, pro­dukt OOD jest moż­li­wy do imple­men­ta­cji wprost” w języ­ku obiek­to­wym na eta­pie OOP. Innymi sło­wy wyma­ga­niem nie jest lista wyma­gań” a pro­jekt, ana­lo­gicz­nie jak w każ­dej innej inży­nie­rii: wyma­ga­niem wobec wyko­naw­cy jest pro­jekt tego co nale­ży wyko­nać a nie tyl­ko słow­ny opis tego cze­go ocze­ku­je zamawiający.

OOA i OOD jest łączo­ne w OOAD z tego powo­du, że obiek­to­wy opis (model) cze­goś” jest 9w meto­dach obiek­to­wych) zara­zem pro­jek­tem tego cze­goś”. Mając obiek­to­wy model opro­gra­mo­wa­nia (czę­ści opi­su­ją­cej jego biz­ne­so­wą logi­kę dzia­ła­nia, nazy­wa­nej Modelem Dziedziny) może­my spraw­dzić (prze­te­sto­wać) jak speł­nia on wyma­ga­nia funk­cjo­nal­ne zanim jesz­cze, powsta­nie znacz­nie droż­sza od pro­jek­tu, imple­men­ta­cja. Mamy szan­se, rela­tyw­nie niskim kosz­tem, zmie­nić pro­jekt zanim uru­cho­mi­my kosz­tow­ny zespół pro­gra­mi­stów. Na bazie takie­go mode­lu moż­li­we jest w ogó­le wyko­na­nie ana­li­zy wyko­nal­no­ści.

Metoda ta jest spraw­dzo­na, dzia­ła, jest sku­tecz­na. Pierwszy, gło­śno, napi­sał o tym Eric Evans w dzie­le Domain-Driven Design: Tackling Complexity in the Heart of Software (pisa­łem o tym tu: Poziomy szcze­gó­ło­wo­ści wyma­gań ? wzor­ce DDD ? czy­li czym jest ana­li­za obiek­to­wa). Problem pole­ga na tym, że biz­ne­so­wa ana­li­za obiek­to­wa (OOAD), dają­ca jako efekt model dzie­dzi­ny (czy­li sed­no biz­ne­so­wych apli­ka­cji), wyma­ga zupeł­nie innych kom­pe­ten­cji (nie licząc rozu­mie­nia samej obiek­to­wo­ści) niż kom­pe­ten­cje pro­gra­mi­stów i archi­tek­tów opro­gra­mo­wa­nia. Nie praw­dą jest, że tyl­ko deve­lo­per” ma tu kom­pe­ten­cje do pro­jek­to­wa­nia opro­gra­mo­wa­nia. W obsza­rze ana­li­zy i mode­lo­wa­nia biz­ne­su” z regu­ły nie ma żad­nych kom­pe­ten­cji. Potwierdza to tak­że obec­ny model kom­pe­ten­cji Analityka Biznesowego pre­zen­to­wa­ny przez orga­ni­za­cję IIBA.

Tak więc obiek­to­wość jako pana­ceum na pro­ble­my pro­gra­mi­stów i pro­gra­mo­wa­nia to w moich oczach jak naj­bar­dziej wpad­ka. Obiektowość jako sku­tecz­ne meto­da ana­li­zy świa­ta” i jego mode­lo­wa­nia to suk­ces, ale to tyl­ko kon­ty­nu­acja roz­wo­ju ogól­nej teo­rii sys­te­mów. Obiektowość dała tej teo­rii bar­dzo dobre narzę­dzie – obiek­to­we meto­dy mode­lo­wa­nia. Specyfikowanie wyma­gań w posta­ci czar­nej skrzyn­ki się nie spraw­dza, sta­ty­sty­ki pora­żek pro­jek­tów są nie­zmien­ne od lat. Specyfikacja wyma­gań w posta­ci pro­jek­tu jest nie­mal­że dosko­na­ła (ale tyl­ko na tyle na ile dosko­na­ły jest projekt). 

Arystoteles (jak słusz­nie zauwa­żył Pan Bereza), uwa­żał, że przed­mio­ty cięż­sze spa­da­ją szyb­ciej i miał on pra­wo posłu­żyć się heu­ry­sty­ką, w jego cza­sach fizy­ka nawet nie racz­ko­wa­ła. Nie zapo­mi­naj­my jed­nak, że Arystoteles dał pod­wa­li­ny dzi­siej­szych metod nauko­wych, tezą: praw­dzi­wa wie­dza to zna­jo­mość przyczyn.

Mamy jed­nak inny para­doks: Znamy sta­ty­sty­ki mówią­ce, że ok. 75% pro­jek­tów IT to poraż­ki, a mimo to nadal naj­czę­ściej sto­so­wa­ne są meto­dy wyko­rzy­sty­wa­ne przez więk­szość”. To się nazy­wa kon­for­mizm Project Managera, któ­ry jak widać, jest sil­niej­szy od umie­jęt­no­ści wycią­ga­nia wnio­sków: histo­ria uczy ludzi, że histo­ria nicze­go ludzi nie nauczyła…

Demo System Szachownica

Z uwa­gi na zain­te­re­so­wa­nie moim pro­jek­tem demo” stwo­rzy­łem tę stro­nę. Tu będą się poja­wia­ły infor­ma­cje o kolej­nych eta­pach two­rze­nia tego doku­men­tu. Powiadomienia o postę­pach będą wysy­ła­ne mailem do subskrybentów.

Projekt Szachy ma na celu poka­za­nie na pro­stym przy­kła­dzie, toku ana­li­zy i pro­duk­tów jakie two­rzę w roli ana­li­ty­ka i pro­jek­tan­ta. Dokument ten może zawie­rać pew­ne bra­ki (brak pew­nych szcze­gó­łów) gdyż celem tego doku­men­tu jest zade­mon­stro­wa­nie zawar­to­ści tego rodza­ju doku­men­ta­cji a nie szcze­gó­ło­we opra­co­wa­nie real­ne­go pro­jek­tu, będzie to jed­nak zazna­czo­ne w treści.

Kliknij i pobierz aktu­al­ny plik projektu

Wszelkie pyta­nia i suge­stie na temat tre­ści pro­jek­tu pro­szę zgła­szać poni­żej, będę na nie sys­te­ma­tycz­nie odpowiadał.

System Analysis And Design with UML 2.0

Tym razem książ­ka napi­sa­na jak pod­ręcz­nik. Co praw­da napi­sa­na w 2005 roku, ale opar­ta jest na UML w wer­sji 2.0 więc nie psu­je” czy­tel­ni­ka ;). Książka zawie­ra w posta­ci bar­dzo dobrze upo­rząd­ko­wa­nej, opis całe­go pro­ce­su two­rze­nia opro­gra­mo­wa­nia meto­da­mi obiek­to­wy­mi: od pla­no­wa­nia do implementacji.

Wstęp zawie­ra bar­dzo poucza­ją­ce porów­na­nie i pod­su­mo­wa­nie pro­ce­sów wytwór­czych: od kla­sycz­ne­go wodo­spa­du do pro­gra­mo­wa­nia eks­tre­mal­ne­go. Znajdziecie tak­że uwa­gi na temat metod będą­cych ich kom­bi­na­cja­mi i, w róż­nych warian­tach, chy­ba naj­czę­ściej stosowanych.

Omówiono: fazę ini­cja­cji w tym pla­no­wa­nie i zarzą­dza­nie pro­jek­tem deve­lo­per­skim. Fazę ana­li­zy w tym ana­li­zę wyma­gań, mode­lo­wa­nie funk­cjo­nal­no­ści, struk­tu­ry i zacho­wa­nia. Fazę pro­jek­to­wa­nia w tym przej­ście z ana­li­zy na pro­jek­to­wa­nie, pro­jek­to­wa­nie klas i ich metod, pro­jek­to­wa­nie war­stwy danych, pro­jek­to­wa­nie komu­ni­ka­cji użyt­kow­ni­ka z sys­te­mem (GUI), pro­jek­to­wa­nie archi­tek­tu­ry (szcze­gól­nie ma to zna­cze­nia dla dużych sys­te­mów). Na koń­cu faza imple­men­ta­cji i wdrożenia.

Książka zawie­ra wie­le boga­to ilu­stro­wa­nych przy­kła­dów. Co praw­da auto­rzy powie­la­ją jesz­cze coś, co w moim mnie­ma­niu jest błę­dem, a mia­no­wi­cie nie oddzie­la­ją (albo łączą) ana­li­zy poję­cio­wej od obiek­to­wej na eta­pie ana­li­zy i pro­jek­to­wa­nia struk­tu­ry. Niestety model dzie­dzi­ny sys­te­mu to nie model poję­cio­wy, łącze­nie ich w jeden to echa kla­sycz­nej ana­li­zy struk­tu­ral­nej (dia­gra­my ERD i mode­le relacyjnej).

System Analysis and Design with UML Version 2.0. An Object-Oriented Approach (Second Edition), Alan Dennis, Barbara Haley Wixdom, David Tergarden
System Analysis and Design with UML Version 2.0. An Object-Oriented Approach (Second Edition), Alan Dennis, Barbara Haley Wixdom, David Tergarden

Generalnie książ­kę pole­cam, mało jest tak dobrze napi­sa­nych kom­pen­diów na ten temat. Co do róż­ni­cy pomię­dzy ana­li­zą poję­cio­wą i pro­jek­to­wa­niem mode­lu dzie­dzi­ny sys­te­mu, nie raz pisa­łem (patrz art. Cholerny dia­gram klas) ale leży już w kolej­ce do prze­czy­ta­nia Business Rules Concepts Ronalda Ross’a. To czwar­ta edy­cja tej pozy­cji (mam wszyst­kie ;)) i już po pobież­nym przej­rze­niu widać ewo­lu­cje i stop­nio­we dora­sta­nie dziec­ka Ronalda Ross’a jakim jest kon­cep­cja reguł biz­ne­so­wych i mode­li poję­cio­wych jako narzę­dzia ana­li­zy i mode­lo­wa­nia. Koncepcja dosko­na­le pasu­je do metod obiek­to­wych ana­li­zy i pro­jek­to­wa­nia, ale o tym innym razem.

Książkę pole­cam przede wszyst­kim ana­li­ty­kom do nauki ale tak­że wyżar­tym” pro­gra­mi­stom, by sobie upo­rząd­ko­wa­li zdo­by­te doświad­cze­nie i moż­li­wie łagod­nie prze­cho­dzi­li od metod struk­tu­ral­nych do obiek­to­wych. Tu pew­nie nowin­ka dla nich: bazy danych pro­jek­tu­je­my na samym koń­cu, na eta­pie imple­men­ta­cji opra­co­wa­ne­go kom­plet­ne­go pro­jek­tu obiektowego.