Tag: Architektura

Diagram: Jeden model dwa konteksty Diagram przedstawia obiekty biznesowe - dokumenty () pochodzące z dwóch różnych kontaktów. Na schemacie mamy trzy klasyfikatory reprezentujące dokumenty i ich struktury. W celu usunięcia kolizji pojęć opisanej przez Fowlera (FOWLER 2014) obiekty funkcjonujące w dwóch różnych kontaktach zostały rozdzielone na dwie kontekstowe przestrzenie pojęciowe: Sprzedaż oraz Serwis. W kontekście Sprzedaż pojęcia Klient i Produkt zostały użyte do nazwania obiektów biznesowych będących przedmiotami mającymi tożsamość. W kontekście Serwis pojęcia te (klient i produkt) ca jedynie cechami (atrybutami) obiektu biznesowego Uszkodzenie, słowa te (pojęcia) stanowią jedynie nazwy atrybutów a konkretne nazwy klienta i produktu stanowią wartość tych atrybutów i jako obiekty nie mają tu tożsamości (value UML i value object w DDD). Tak więc problem kolizji nazewnictwa została rozwiązany, warto tu zwrócić, że zbudowanie jednej spójnej relacyjnej bazy danych dla wszystkich pojęć obu tych dziedzin jest niemożliwe bez dodatkowych zabiegów z nazewnictwem.

Modelowanie architektury HLD i LLD usług aplikacji – modelowanie podsystemów

1 komentarz

Wstęp

Tym razem krót­ki arty­kuł na temat pew­nej cie­ka­wej kon­struk­cji. Została ona opi­sa­na przez Rebekę Wirfs-Brock w 1999 roku . Pomysł nie zdo­był sobie wte­dy raczej zbyt dużej popu­lar­no­ści, jed­nak obec­nie, w dobie wzor­ców opar­tych o mikro­ser­wi­sy i mikro apli­ka­cje, ma szan­sę wró­cić do łask. Ja sto­su­ję go już od dłuż­sze­go cza­su (patrz: pro­jek­to­wa­nie zorien­to­wa­ne na inter­fej­sy). Skróty HLD i LLD to odpo­wied­nio: High-Level Design (pro­jekt wyso­kie­go pozio­mu) i Low-Level Design (pro­jekt niskie­go pozio­mu). Są to pozio­my abs­trak­cji w mode­lu PIM. Jest to tak­że opis sty­lu pro­jek­to­wa­nia archi­tek­tu­ry sys­te­mu zorien­to­wa­ne­go na inter­fej­sy (archi­tek­tu­ra zorien­to­wa­na na interfejsy).

Czytaj dalej… ​„Modelowanie archi­tek­tu­ry HLD i LLD usług apli­ka­cji – mode­lo­wa­nie pod­sys­te­mów” →

Marsz ku klęsce – Poradnik dla projektanta systemów

Dodaj komentarz

Lektura na Nowy Rok… Co praw­da wyda­na w 2007 roku, ale wła­śnie sobie o niej przypomniałem.. 

Ta książ­ka Yourdona leży u mnie na pół­ce nie­mal­że od dnia jej wyda­nia, gdy ją przy­pad­kiem upo­lo­wa­łem, zaraz po jej uka­za­niu się w księ­gar­niach. Napisanie o niej odkła­dam od lat, bo prak­tycz­nie nie ma tam obraz­ków UML, opi­sów wzor­ców itp.. Od jej prze­czy­ta­nia mówię sobie: jutro o niej napi­szę… i to trwa­ło do tego momentu.

To książ­ka w cało­ści napi­sa­na pro­zą, bez obraz­ków, w któ­rej autor dzie­li sie swo­imi prze­my­śle­nia­mi na temat archi­tek­tu­ry sys­te­mów, ich pro­jek­to­wa­nia i tym co z tego wynika. 

Bardzo cie­ka­wie pisze o tym, czym jest zło­żo­ność opro­gra­mo­wa­nia, o tym, że zło­żo­ność sys­te­mu to sto­pień kom­pli­ka­cji mode­lu dzie­dzi­no­we­go a nie ​„całe­go sys­te­mu”. Typowy sys­tem (tu apli­ka­cja dla biz­ne­su) skła­da się w ponad 90% z biblio­tek, z któ­rych nie­wąt­pli­wie trze­ba umieć zbu­do­wać śro­do­wi­sko apli­ka­cji, jed­nak to nie one decy­du­ją o tym do cze­go słu­ży ten sys­tem i czy w ogó­le komu­kol­wiek do cze­goś słu­ży… Z biblio­tek, na któ­re nie mamy wpły­wu, ale musi­my (chce­my) ich użyć. 

Jaki to jest skom­pli­ko­wa­ny sys­tem? Ile ma klas/komponentów by uznać go za zło­żo­ny? Gdzie jest gra­ni­ca zło­żo­no­ści małej i dużej? Czym jest archi­tek­tu­ra i po co ona nam? O tym tu przeczytacie.

Polecam tę książ­kę każ­de­mu, kto ma ambi­cję pro­jek­to­wać archi­tek­tu­rę sys­te­mów biz­ne­so­wych. Uczy poko­ry. Zwracam tu uwa­gę, że oso­ba mówią­ca o sobie ​„ana­li­tyk biz­ne­so­wy”, któ­re­go pro­duk­tem pra­cy mają być ​„wyma­ga­nia na opro­gra­mo­wa­nie”, to nie zbie­racz nota­tek a pro­jek­tant . Albo niech zmie­ni zawód.. 

Yourdon, E., & Bloch, J. (2007). Marsz ku klę­sce: porad­nik dla pro­jek­tan­ta sys­te­mów. Wydawnictwa Naukowo-Techniczne. https://​lubi​my​czy​tac​.pl/​k​s​i​a​z​k​a​/​1​5​9​1​8​0​/​m​a​r​s​z​-​k​u​-​k​l​e​sce
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049

Dokument a kumulacja faktów: OOAD i model dziedziny systemu

Dodaj komentarz

Tym razem o czymś co potra­fi zabić 😉 czy­li czym jest doku­ment oraz fakt i obiekt. Czym się róż­ni zakup kil­ku pro­duk­tów, w tym samym skle­pie, w np. godzin­nych odstę­pach cza­su, od zaku­pu wszyst­kich razem? Poza for­mą udo­ku­men­to­wa­nia, niczym: w skle­pie to samo i tyle samo zeszło ze sta­nu maga­zy­nu, a my wyda­li­śmy w obu przy­pad­kach tyle samo pie­nię­dzy (o pro­mo­cjach póź­niej)! W pierw­szym przy­pad­ku mamy kil­ka fak­tów zaku­pu, w dru­gim, jeden, ale zawsze tyle samo obiek­tów (pro­dukt). Faktura (para­gon) to doku­ment opi­sją­cy fakt, przed­miot sprze­da­ży jest obiek­tem. Tu obiek­tem jest opi­sy­wa­ny przed­miot zaku­pu. Ten arty­kuł to przy­kład archi­tek­tu­ry usłu­gi apli­ka­cji, któ­ra jest nie­czu­ła na takie różnice. 

Wprowadzenie

Żeby upo­rząd­ko­wać treść, w sto­sun­ku to archi­tek­tu­ry apli­ka­cji tu nie będę uży­wał pojęć ​„kla­sa i obiekt” a kom­po­nent i doku­ment. Pojęcia obiekt i fakt tu będą doty­czy­ły świa­ta real­ne­go, to odpo­wied­nio: opi­sy­wa­ny przed­miot i zda­rze­nie z nim powią­za­ne. Innymi sło­wy: doku­ment może opi­sy­wać obiekt lub zda­rze­nie z nim powią­za­ne. Np. pro­dukt oraz fakt jego sprze­da­nia (dwa byty: sepa­ro­wa­nie kon­tek­stu doku­men­tów). Konkretne opro­gra­mo­wa­nie jako sys­tem, to kom­po­nen­ty (w UML obiek­ty okre­ślo­nej kla­sy) oraz dane zor­ga­ni­zo­wa­ne np. jako doku­men­ty (doku­ment: nazwa­na, okre­ślo­na struk­tu­ra danych). Aplikacje prze­twa­rza­ją dane opi­su­ją­ce real­ny świat, co ład­nie poka­zał i opi­sał Smith :

computer model real world
Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512

Projektowanie opro­gra­mo­wa­nia to two­rze­nie jego mode­lu, potem pozo­sta­je już tyl­ko jego imple­men­ta­cja. Obecnie pra­ce pro­jek­to­we i przy­go­to­wa­nie do imple­men­ta­cji tak­że są zali­cza­ne do ​„pro­gra­mo­wa­nia” .

Projekt systemu sprzedaży

Każda ana­li­za powin­na być opar­ta na onto­lo­gii z dzie­dzi­ny pro­ble­mu. Dzięki cze­mu nazwy doku­men­tów, atry­bu­tów i ich war­to­ści będą spój­ne, jed­no­znacz­ne i nie­sprzecz­ne. Poniżej pro­sty model poję­cio­wy dla dzie­dzi­ny opi­sy­wa­ne­go tu problemu:

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

(UWAGA! Powyższy model nie jest żad­nym ​„mode­lem dzie­dzi­ny” ani ​„mode­lem danych”. To model pojęciowy). 

Modele poję­cio­we słu­żą do zarzą­dza­nia sys­te­mem pojęć (onto­lo­gia) dla dane­go mode­lu opro­gra­mo­wa­nia. Testowanie tego mode­lu pole­ga na spraw­dze­niu czy każ­da para połą­czo­nych seman­tycz­nie pojęć two­rzy popraw­ne i praw­dzi­we(!) zda­nie w języ­ku natu­ral­nym (tu musi­my brać popraw­kę na flek­sję języ­ka pol­skie­go), np. «sprze­da­ją­cy wysta­wia fak­tu­rę» (fakt) lub «fak­tu­ra jest doku­men­tem» (typ).

Oprogramowanie słu­ży do prze­twa­rza­nia danych, dla­te­go war­to opi­sać jak się to odby­wa. Bardzo wygod­ną meto­dą pro­jek­to­wa­nia struk­tur danych doku­men­ty (w tym opi­sie dia­gram struk­tur zło­żo­nych nota­cji UML). Po pierw­sze są one zro­zu­mia­łe dla przy­szłe­go użyt­kow­ni­ka, po dru­gie meto­da ta pozwa­la uwol­nić się od wad mode­li rela­cyj­nych: usu­nię­cie redun­dan­cji nazw co pro­wa­dzi do utra­ty ich kon­tek­stu. Dokumenty czę­sto mają róż­ny kon­tekst, zna­cze­nie pojęć zale­ży od kon­tek­stu. Relacyjny model danych, pozba­wio­ny redun­dan­cji, jest strat­ny: utrwa­lo­ne dane nie sta­no­wią żad­nej infor­ma­cji a doku­men­tem jest dopie­ro wynik zapy­ta­nia SQL do tabel. 

W przy­pad­ku opi­sy­wa­ne­go tu pro­jek­tu wyglą­da to tak:

Struktury danych zor­ga­ni­zo­wa­nych w doku­men­ty (nota­cja UML)

Mamy tu dwa doku­men­ty: Oferta i Faktura. Pojęcie Produkt ma swo­ją defi­ni­cję real­na (defi­ni­cja atry­bu­to­wa: poprzez cechy): jest to ​„cos co ma nazwę, cenę i ilość”. Atrybuty Produktu na doku­men­tach przyj­mu­ją war­to­ści opi­sa­ne tym typem. Po dru­gie doku­ment nie­sie kon­tekst więc nada­je nazwie zna­cze­nie: np. data to data fak­tu­ry i data ofer­ty. To nie są te same daty, a pro­dukt ofe­ro­wa­ny (jako atry­but ofer­ty) nie musi być tym samym pro­duk­tem sprze­da­nym (jako atry­but Faktury).

Projekt powyż­szy poka­zu­je tak­że waż­ną rzecz: sepa­ro­wa­nie danych o obiek­tach (pro­duk­ty) i fak­tach (fak­tu­ra). Nie nale­ży na jed­nym doku­men­cie łączyć (mie­szać) kon­tek­stów (uwspól­nia­nie danych w mode­lu rela­cyj­nym). (Więcej na temat sepa­ra­cji kon­tek­stów obiek­tu i fak­tu w publi­ka­cji ​„Chapter 3 Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases”).

Poniżej, na dia­gra­mie sekwen­cji, widać, że dla kom­po­nen­tu zarzą­dza­ją­ce­go sta­na­mi maga­zy­no­wy­mi nie ma żad­ne­go zna­cze­nia ile jest (było) fak­tur, ope­ra­cje zmia­ny ilo­ści to poje­dyn­cze ope­ra­cje. Tak zapro­jek­to­wa­na apli­ka­cja jest odpor­na na to ile pro­duk­tów jest na ofer­cie i fak­tu­rze, mogą to być róż­ne ilo­ści. Oba te doku­men­ty: ofer­ta i fak­tu­ra, to cał­ko­wi­cie odręb­ne kon­struk­cje, to doku­men­ty rzą­dzą­ce się każ­dy inną logi­ką i mają­ce każ­dy inny cykl życia (tu np. Oferta nie jest utrwa­la­na). Często sto­so­wa­ne kon­struk­cje, takie jak ​„dzie­dzi­cze­nie fak­tu­ry i ofer­ty po doku­men­cie” są tu naj­gor­szym pomysłem. 

Architektura. Nasza apli­ka­cja to kil­ka współ­pra­cu­ją­cych komponentów:

Obiektowy (kom­po­nen­to­wy) model dziedziny. 

Klasy ozna­czo­ne ste­reo­ty­pem «Document» to cią­gi zna­ków (np. XML) sta­no­wią­ce war­to­ści atry­bu­tów i para­me­try wywo­łań ope­ra­cji. (w UML: ?Document? A human-reada­ble file. Subclass of ?File?. )

Model archi­tek­tu­ry to sta­tycz­ny model, a ten może być nie­zro­zu­mia­ły, dla­te­go zawsze wzbo­ga­ca­my pro­jekt tech­nicz­ny archi­tek­tu­ry mode­lem dyna­mi­ki sys­te­mu: dia­gra­mem sekwen­cji. Diagram taki powi­nien powstać dla każ­dej usłu­gi apli­ka­cji (przy­pad­ku użycia):

Scenariusz reali­za­cji sprze­da­ży (dia­gram sekwen­cji UML)

Powyższy dia­gram poka­zu­je współ­pra­cę kom­po­nen­tów, opi­sa­ne wcze­śniej doku­men­ty są war­to­ścia­mi atry­bu­tów i para­me­tra­mi wywo­ły­wa­nych ope­ra­cji i ich odpo­wie­dzi. Powyższa archi­tek­tu­ra z powo­dze­niem wyko­na tak­że usłu­gi wglą­du do histo­rycz­nych fak­tur czy aktu­ali­za­cję cennika. 

Poprawna obiek­to­wa archi­tek­tu­ra i kom­plet­ny pro­jekt tech­nicz­ny apli­ka­cji (model PIM) opi­su­je pre­cy­zyj­nie jak wyko­nać imple­men­ta­cje i nie zawie­ra pro­jek­tu żad­nej bazy danych, ani tym bar­dziej zapy­tań SQL. Implementacja utrwa­la­nia nie może mieć wpły­wu na logi­kę biz­ne­so­wą sys­te­mu ani nawet zawie­rać jej! 

Samo opra­co­wa­nie rela­cyj­ne­go mode­lu danych oraz zapy­tań SQL, by gene­ro­wać powyż­sze doku­men­ty z warian­ta­mi doty­czą­cy­mi róż­nych ilo­ści ofe­ro­wa­nych i zama­wia­nych, zaj­mie kil­ka­krot­nie wię­cej cza­su niż opra­co­wa­nie powyż­sze­go, goto­we­go do imple­men­ta­cji, pro­jek­tu. Opracowanie mode­lu rela­cyj­ne­go bazy danych, wyma­ga­ło by dodat­ko­wo wie­dzy o wszyst­kich pozo­sta­łych doku­men­tach w tym sys­te­mie, a tego z regu­ły nigdy nie wie­my na początku!

Powyższy model to w peł­ni współ­pra­cu­ją­ce obiek­ty mają­ce ope­ra­cje, a pod­sta­wo­wym związ­kiem mode­lu obiek­to­we­go jest zwią­zek uży­cia (wywo­ła­nia ope­ra­cji), czy­li nie jest to tak zwa­ny ane­micz­ny model dzie­dzi­ny.

Tu tak­że war­to zwró­cić uwa­gę na kolej­ny czę­sty błąd i antyw­zo­rzec w pro­jek­tach dekla­ro­wa­nych jako obiek­to­we: sto­so­wa­nie dzie­dzi­cze­nia. Jest to mie­sza­nie mode­li poję­cio­wych i archi­tek­tu­ry (dzie­dzi­cze­nie, jako współ­dzie­le­nie, łamie pod­sta­wo­wą zasa­dę para­dyg­ma­tu obiek­to­we­go jaką jest her­me­ty­za­cja). Dlatego model poję­cio­wy i model archi­tek­tu­ry to z zasa­dy dwa odręb­ne mode­le z powo­dów jak wyżej opisane.

Modelowanie archi­tek­tu­ry systemu 

Podsumowanie

Powyższy opis to krót­ki ale prak­tycz­nie kom­plet­ny Opis Techniczny Oprogramowania. Wymaga nie­wiel­kich uzu­peł­nień (ewen­tu­al­ne sche­ma­ty opi­su­ją­ce meto­dy ope­ra­cji). Wykonanie imple­men­ta­cji na jego pod­sta­wie nie powin­no spra­wić pro­ble­mu oso­bie radzą­cej sobie z czy­ta­niem nota­cji UML. Projekt jest na tyle pre­cy­zyj­ny, że sta­no­wi utwór w rozu­mie­niu pra­wa autor­skie­go (pro­gra­mi­sta nie ma tu żad­nej swo­bo­dy decy­zji w pisa­niu kodu dla tej czę­ści). Projekt taki to tak­że opis okre­ślo­ne­go mecha­ni­zmu dzia­ła­nia, zawie­ra więc opis know-how i jako jego udo­ku­men­to­wa­na for­ma chro­ni to know-how (usta­wa o prze­ciw­dzia­ła­niu nie­uczci­wej konkurencji). 

Dlatego każ­dy pro­gram kom­pu­te­ro­wy napi­sa­ny na pod­sta­wie takiej doku­men­ta­cji, z zasa­dy jest utwo­rem zależ­nym. Developer ma pra­wa autor­skie oso­bi­ste do kodu jaki napi­sze, ale nie ma pra­wa do dys­po­no­wa­nia tym kodem: ma je posia­dacz praw mająt­ko­wych do pro­jek­tu, któ­ry jest tu utwo­rem pier­wot­nym. Jedyny wybór jaki ma tu deve­lo­per to wybór tech­no­lo­gii jakiej użyje.

https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​e​m​e​r​g​i​n​g​-​c​h​a​l​l​e​n​g​e​s​-​s​o​l​u​t​i​o​n​s​-​b​e​s​t​-​p​r​a​c​t​i​c​e​s​/​2​7​1​7​3​3​#​t​a​b​l​e​-​o​f​-​c​o​n​t​e​nts

Powyższy pro­jekt wyko­na­no z uży­ciem Visual Paradigm.

Źródła

OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Weilkiens, T. (2007). Systems engi­ne­ering with SysML/UML: mode­ling, ana­ly­sis, design (1. Aufl). Morgan Kaufmann OMG Press/Elsevier.
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049
Smith, B. C. (1985). The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18 – 26. https://​doi​.org/​1​0​.​1​1​4​5​/​3​7​9​4​8​6​.​3​7​9​512

Model i dokumentowanie wdrożenia

Dodaj komentarz

Ten arty­kuł to pró­ba przy­bli­że­nia czy­tel­ni­ko­wi poję­cia meta­mo­del i model. To tak­że mała prób­ka tego co jest pro­duk­tem nad­zo­ru autorskiego.

Nieco ponad pięć lat temu w arty­ku­le Diagram obiek­tów czy­li bot­tom-up pisa­łem o poję­ciu instan­cji obiek­tu i dia­gra­mie obiek­tów. Wtedy sku­pi­łem się na jed­nym tyl­ko wąt­ku, jakim jest ana­li­za zmie­rza­ją­ca do opra­co­wa­nia … no wła­śnie, cze­go? Z regu­ły auto­rzy doku­men­tów zawie­ra­ją­cych ​„dia­gra­my klas” mówią, że two­rzą mode­le. Czy zawsze są to modele?

Wprowadzenie

Jednym z bar­dzo nie­do­ce­nia­nych typów dia­gra­mów UML są dia­gram obiek­tów i dia­gram wdro­że­nia (któ­ry jest rodza­jem dia­gra­mu obiek­tów). Oba te dia­gra­my słu­żą do mode­lo­wa­nia okre­ślo­nych sytu­acji. Nie raz pisa­łem, że pro­jekt (doku­men­ta­cja pro­jek­to­wa) tez ma cykl życia. To nie jest tak, że powsta­je doku­ment Wymagania, zawie­ra­ją­cy jakieś mode­le, a następ­nie ktoś za nie­go pła­ci i ten doku­ment lądu­je za szy­bą tyl­ko do odczytu.

Patrząc na cykl życia pro­jek­tu, doku­men­ta­cja sta­no­wią­ca począt­ko­wo Wymagania, żyje i roz­wi­ja się razem z nim. Ona tak­że ma swój cykl życia. Na koniec doku­men­ta­cja ta jest opi­sem tego co powsta­ło. Jest to model kon­kret­ne­go ukoń­czo­ne­go wdrożenia.

Meta Object Facility

(oso­by nie inte­re­su­ją­ce się teo­rią mogą pomi­nąć ten rozdział) 

MOF (Meta Object Facility) to spe­cy­fi­ka­cja okre­śla­ją­ca bazo­we poję­cia dla nota­cji zarzą­dza­nych przez Object Management Group . Specyfikacja ta okre­śla trzy pod­sta­wo­we pozio­my abs­trak­cji oraz poziom pod­sta­wo­wy jakim jest świat (przed­mio­ty) mode­lo­wa­ny. Realny świat to poziom M0. Zobrazowanie real­ne­go świa­ta za pomo­cą nazw przed­mio­tów i ich wybra­nych klu­czo­wych cech (bo nie wszyst­kich) to abs­trak­cja tego świa­ta. Jeżeli jakieś gru­py przed­mio­tów mają te same klu­czo­we cechy, ale róż­nią sie jedy­nie war­to­ścia­mi tych cech, np. wie­le przed­mio­tów róż­ni się wyłącz­nie kolo­rem i dłu­go­ścią ale opi­su­je­my je z pomo­cą kolo­ru i dłu­go­ści, to mówi­my, że mamy kla­sę przed­mio­tów o atry­bu­tach kolor i dłu­gość, i nada­je­my jej (temu zbio­ro­wi) nazwę, nazwa ta czę­sto jaw­nie wystę­pu­je w języ­ku natu­ral­nym, np. ​„kolo­ro­we słom­ki” mają atry­bu­ty: kolor i dłu­gość. Zakładamy, że przed­mio­ty reagu­ją na bodź­ce czy­li mają zacho­wa­nia: słom­ka pod wpły­wem siły prze­miesz­cza się lub wygi­na (to operacja). 

Powyższy dia­gram obra­zu­je ww. pozio­my abs­trak­cji MOF. Złóżmy, że wśród drob­nych przed­mio­tów real­nych (poziom M0) są tak­że nasze słom­ki. Dwie z tych sło­mek obra­zu­je­my jak pro­sto­ką­ty mają­ce nazwy: Egzemplarz 1 i Egzemplarz 2 (mają uni­kal­ne nazwy bo musi­my je roz­róż­niać). To – poziom M1 – jest abs­trak­cja nasze­go świa­ta: jego model. Skoro słom­ki mają te same cechy: nazwa, kolor i dłu­goś, to two­rzy­my nazwę (tu Class) dla zbio­ru wszyst­kich takich sło­mek. Nazwa tego zbio­ru repre­zen­tu­je wszyst­kie takie słom­ki (zbiór sło­mek). Na pozio­mie M2 uży­wa­my już tyl­ko nazwy zbio­ru. Poziom M2 to meta­mo­del. Aby upo­rząd­ko­wać nasze mode­le i meta­mo­de­le, stan­da­ry­zu­je­my tę meto­dę opi­su, uma­wia­jąc sie, że ele­men­ty naszych mode­li to poję­cia (nazwy) i związ­ki mię­dzy nimi (zwa­ne tak­że aso­cja­cje). Pojęcia mają zawsze defi­ni­cje i repre­zen­tu­ją nazwy, czy­li zbio­ry ele­men­tów zgod­nych z daną defi­ni­cją (ele­men­ty dia­gra­mów), a defi­ni­cja ta to kla­sy­fi­ka­tor. Ta umo­wa to poziom M3, nazy­wa­ny meta-meta­mo­del (zbiór zbio­rów). Mówimy, że w UML wszyst­ko jest klasą.

Najnowsza spe­cy­fi­ka­cja MOF wska­zu­je, że co praw­da pod­sta­wo­we pozio­my abs­trak­cji to te czte­ry wymie­nio­ne, jed­nak nie ma żad­ne­go zaka­zu orga­ni­zo­wa­nia zbio­rów w zbio­ry. Robimy to na pozio­mie M2 a słu­żą do tego tak zwa­ne ste­reo­ty­py: są to kla­sy klas. Np. gdy­by było praw­dą, że słom­ki mają prze­kro­je kwa­dra­to­we i okrą­głe to albo doda­je­my im nową cechę: prze­krój o war­to­ści koło lub kwa­drat, albo two­rzy­my pod­zbio­ry «kwa­dra­to­we» i «okrą­głe». Możemy tak­że dopre­cy­zo­wać, że cechą sło­mek «kwa­dra­to­we» zawsze jest tak­że zapach a sło­mek «okrą­głe» ich cię­żar. Taka dodat­ko­wa defi­ni­cja typów klas i ich spe­cy­fi­ki to profil. 

Projektowanie i realizacja projektu

Cykl życia pro­jek­tu zaczy­na się od budo­wy archi­tek­tu­ry sys­te­mu, budu­je­my struk­tu­rę zło­żo­na z blo­ków o okre­ślo­nym zasto­so­wa­niu: mówi­my ​„sys­tem kla­sy CRM”, ​„sys­tem kla­sy ERP” czy ​„sys­tem kla­sy WorkFlow”. Nie wie­my jakie kon­kret­ne apli­ka­cje wdro­ży­my, ale wie­my (powin­ni­śmy to zde­fi­nio­wać) jakie wyma­ga­nia sta­wia­my przed każ­dą z tych klas aplikacji.

Idea podej­ścia zgod­ne­go z MOF to ana­li­za i jej efekt: nazwa­ne blo­ki funk­cjo­nal­ne sys­te­mu (dia­gram komponentów):

Ich defi­ni­cje to wyma­ga­nia na te kom­po­nen­ty. Każdy z powyż­szych kom­po­nen­tów moż­na opi­sać przy­pad­ka­mi uży­cia. Całość może zostać zre­ali­zo­wa­na jako odręb­ne apli­ka­cje, każ­dy impo­nent jest zde­fi­nio­wa­ny poprzez wyma­ga­nia wobec nie­go. Nazwy kom­po­nen­tów są zwy­cza­jo­we, tak na praw­de są one defi­nio­wa­ne poprzez przy­pad­ki uży­cia i wewnętrz­ną archi­tek­tu­rę infor­ma­cji: są to dzie­dzi­no­we komponenty. 

Wybierając i wdra­ża­jąc kolej­ne apli­ka­cje zna­my ich nazwy i to jak współ­pra­cu­ją (dia­gram wdrożenia):

Instancje (nazwy apli­ka­cji praw­dzi­we ale przy­pad­ko­we, nie jest to reko­men­da­cja żad­ne­go z tych programów)

Powyższy dia­gram mozna uzu­peł­nić o infor­ma­cje o doce­lo­wym śro­do­wi­sku ich pracy:

Instancje wraz ze śro­do­wi­ska­mi w jakich zosta­ły uruchomione

Należy tak­że wska­zać jakiej kla­sy są to apli­ka­cje (któ­re wyma­ga­nia reali­zu­ją), dla­te­go każ­dą kon­kret­ną apli­ka­cje przy­po­rząd­ko­wu­je­my do okre­ślo­nej wcze­śniej kla­sy komponentów:

Instancje wraz przy­po­rząd­ko­wa­ny­mi kla­sy­fi­ka­to­ra­mi (np. Salesforce to egzem­plarz apli­ka­cji kla­sy System CRM)

Detali opi­su­ją­cych wdro­że­nie krok po kro­ku może być wię­cej (np. inter­fej­sy i ich spe­cy­fi­ka­cje). W każ­dym razie w dniu zakoń­cze­nia wdro­że­nia dostaw­ca zosta­wi po sobie deta­licz­ną doku­men­ta­cję wyko­na­nej imple­men­ta­cji, dla admi­ni­stra­to­ra całe­go sys­te­mu, będzie to kil­ka­set, a bywa że kil­ka tysię­cy, stron. Analityk-pro­jek­tant, po eta­pie nad­zo­ru autor­skie­go, zosta­wi po sobie doku­men­ta­cję zawie­ra­ją­ca abs­trak­cję: model sys­te­mu na potrze­by podej­mo­wa­nia decy­zji tak­tycz­nych i stra­te­gicz­nych, raczej kil­ka­dzie­siąt stron (patrz tak­że: Analiza, mode­lo­wa­nie i uspraw­nia­nie orga­ni­za­cji).

Następne wdro­że­nie nowe­go ele­men­tu sys­te­mu lub wpro­wa­dze­nie w nim zmian, nie będzie już wyma­ga­ło żad­nej owej ana­li­zy, a jed­nie pro­jek­tu poka­zu­ją­ce­go nowy kom­po­nent lub miej­sce gdzie będą wdra­ża­ne zmiany. 

Diagram kom­po­nen­tów to poziom M2. Diagram wdro­że­nia to poziom M1 wg. MOF. W ramach UML korzy­sta­my tu z dia­gra­mu kom­po­nen­tów i dia­gra­mu wdro­że­nia, są stan­dar­do­we pro­fi­le dla UML (MOF tak­że war­stwa M2: dodat­ko­we ste­reo­ty­py). Gdybyśmy chcie­li two­rzyć dedy­ko­wa­ne kom­po­nen­ty, zapew­ne deve­lo­per wyko­rzy­sta wzor­ce fra­me­wor­ki (goto­we zesta­wy biblio­tek) i wzor­ce pro­jek­to­we. To tak­że defi­niu­je się jako pro­fi­le w war­stwie M2 .

Źródła

OMG​.org. (2016, October). MetaObject Facility (MOF). https://​www​.omg​.org/​s​p​e​c​/​MOF
D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
Suleiman, B. (2007). Specification of Business Value with and in Software Patterns. … on Software Patterns …. https://​www​.aca​de​mia​.edu/​9​8​7​5​2​3​/​S​p​e​c​i​f​i​c​a​t​i​o​n​_​o​f​_​B​u​s​i​n​e​s​s​_​V​a​l​u​e​_​w​i​t​h​_​a​n​d​_​i​n​_​S​o​f​t​w​a​r​e​_​P​a​t​t​e​rns
Larman, C. (2005). Applying UML and pat­terns: an intro­duc­tion to object-orien­ted ana­ly­sis and design and ite­ra­ti­ve deve­lop­ment (3rd ed). Prentice Hall PTR, c2005.
Wei, B., Sun, J., & Wang, Y. (2018). A Knowledge Engineering Approach to UML Modeling (S). SEKE, 60 – 63.
Evans, E. (2014). Domain-dri­ven design: tac­kling com­ple­xi­ty in the heart of softwa­re. Addison-Wesley.

Generalizacja/Specjalizacja Przypadków Użycia

4 komentarze

W arty­ku­le Ile przy­pad­ków uży­cia opi­sa­łem przy­pad­ki uży­cia jako narzę­dzie defi­nio­wa­nia zakre­su pro­jek­tu, czy­li spo­sób doku­men­to­wa­nia wyma­gań. Takie jego zasto­so­wa­nie jest zde­fi­nio­wa­ne w spe­cy­fi­ka­cji UML .

Tym razem chcę ostrzec przed bez­kry­tycz­nym ​„ucze­niem się” ze stron inter­ne­to­wych, nawet tych uzna­wa­nych powszech­nie za ​„dobre i popu­lar­ne”. Sam nie­któ­re z nich pole­cam, ale coraz czę­ściej, nie całe ser­wi­sy jako takie, a tyl­ko okre­ślo­ne arty­ku­ły. Modernanalyst​.com też do nich nale­ży. Dziś będzie to arty­kuł, któ­re­go nie pole­cam, a opi­szę go, bo autor powie­la w nim dość powszech­ne błę­dy nota­cyj­ne, błę­dy któ­re sta­ły się ​„kano­nem” dla wie­lu auto­rów sto­su­ją­cych UML. 

Poniżej dia­gram przy­pad­ków uży­cia ze związ­ka­mi «inc­lu­de» i «extend».

W UML zależ­no­ści «inc­lu­de» i «extend» są relik­tem ana­li­zy struk­tu­ral­nej (dia­gra­my przy­pad­ków uży­cia wymy­ślo­no w latach 80-tych). Związek «inc­lu­de» słu­ży do wyłą­cza­nia czę­ści wspól­nej zacho­wań (sce­na­riu­szy) przy­pad­ków uży­cia, w kon­se­kwen­cji: (1) muszą być co naj­mniej dwa bazo­we przy­pad­ki uży­cia by moż­na było mówić o czę­ści wspól­nej, (2) część wspól­na jest jedy­nie frag­men­tem, więc sama (samo­dziel­nie) jako taka do nicze­go nie słu­ży, więc nie wol­no z nią łączyć żad­ne­go akto­ra . Powyższy rysu­nek łamie obie te zasa­dy. Zależność «extend», to zawar­te w przy­pad­ku uży­cia, warun­ko­we roz­sze­rze­nie okre­ślo­ne­go zacho­wa­nia i obli­ga­to­ryj­ne jest poda­nie warun­ku (zda­rze­nia) uru­cha­mia­ją­ce­go to dodat­ko­we zacho­wa­nie . Tu tak­że tę zasa­dę złamano. 

A gdy pro­jekt jest ​„obiek­to­wy”? Specyfikacja UML jasno mówi: Use Case defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal struc­tu­re . Tak więc tych związ­ków po pro­stu nie uży­wa­my w pro­jek­tach, o któ­rych mówi­my, że są obiek­to­we, bo łamią pod­sta­wo­wą zasa­dę para­dyg­ma­tu obiek­to­we­go jaką jest hermetyzacja. 

Kolejne nad­uży­cie to sto­so­wa­nie gene­ra­li­za­cji na dia­gra­mie przy­pad­ków uży­cia: nie jest prze­wi­dzia­na dla tego dia­gra­mu (a dzie­dzi­cze­nie zosta­ło słusz­nie z UML usu­nię­te w 2015 roku wraz z opu­bli­ko­wa­niem wer­sji 2.5 UML). Zachowania sys­te­mu to okre­ślo­ne odręb­ne (her­me­ty­za­cja) ele­men­ty, tu tak­że obo­wią­zu­je zasa­da nie sto­so­wa­nia dia­gra­mu UML do opi­su archi­tek­tu­ry systemu/kodu. Po dru­gie, nawet gdy­by autor miał na myśli sta­re ​„dzie­dzi­cze­nie”, to co do zasa­dy nie łączy­my akto­rów z ele­men­ta­mi abs­trak­cyj­ny­mi mode­lu („woła­nie przod­ka” to daw­no temu opi­sa­ny antyw­zo­rzec obiektowy). 

Poniżej dia­gram pro­fi­lu UML defi­niu­ją­cy poję­cie przy­pa­dek uży­cia (spraw­ne korzy­sta­nie z nota­cji UML wyma­ga umie­jęt­no­ści czy­ta­nia tego dia­gra­mu). I cóż my tu mamy? Należy to inter­pre­to­wać tak: związ­ki «extend» i «inc­lu­de» to inte­gral­ne czę­ści ich przy­pad­ków uży­cia, są to związ­ki skie­ro­wa­ne, przy­pa­dek roz­sze­rza­ny MUSI mieć punkt roz­sze­rze­nia (roz­sze­rza­ją­cy). Nie ma tu w ogó­le moż­li­wo­ści uży­cia gene­ra­li­za­cji mię­dzy ele­men­ta­mi na tym diagramie. 

Data publi­ka­cji tego arty­ku­łu: 5 sty­czeń 2020, czy­li jego autor pisał to pięć lat po publi­ka­cji UML v.2.5! Zaś, miej­sce publi­ka­cji tego tek­stu to zacny ser­wis Modern Analyst:

What can Modern Analyst do for YOU?
Let Modern Analyst help you gain an edge over your competition!Whether you are a tra­ining pro­vi­der, an expe­rien­ced prac­ti­tio­ner, a tool ven­dor, or a recru­iter focu­sing on busi­ness sys­tems ana­ly­sis, make Modern Analyst work for YOU. (źr.: What can Modern Analyst do for YOU?)

Autor sam o sobie:

Author: Mr. Monteleone holds a B.S. in phy­sics and an M.S. in com­pu­ting scien­ce from Texas A&M University. He is cer­ti­fied as a Project Management Professional (PMP?) by the Project Management Institute (PMI?), a Certified Business Analysis Professional (CBAP?) by the International Institute of Business Analysis (IIBA?), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance. He holds an Advanced Master’s Certificate in Project Management and a Business Analyst Certification (CBA?) from George Washington University School of Business. Mark is also a mem­ber of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF).

Nie rzad­ko sły­szę, że ​„ale ten dia­gram ma poka­zać jak sys­tem dzia­ła”. Niestety ten dia­gram nie słu­ży do ​„poka­za­nia” (doku­men­to­wa­nia) tego, jak dzia­ła apli­ka­cja. Do tego słu­żą inne dia­gra­my (ozna­czo­ne na poniż­szym sche­ma­cie blo­ko­wym, dia­gra­my aktyw­no­ści słu­żą obec­nie do mode­lo­wa­nia kodu wiec nie są uży­wa­ne na eta­pie ana­li­zy i pro­jek­to­wa­nia, lub tyl­ko do doku­men­ta­cji algo­ryt­mów) . Jest to – dia­gram przy­pad­ków uży­cia – od 2015 roku, dia­gram pomoc­ni­czy, słu­żą­cy wyłącz­nie do okre­śle­nia zakre­su pro­jek­tu, czy­li wyma­gań. Autorzy spe­cy­fi­ka­cji piszą: ​„Use Case are a means to cap­tu­re the requ­ire­ments of sys­tems, i.e. what sys­tems are sup­po­sed to do” (Przypadek uży­cia jest spo­so­bem na uchwy­ce­nie wyma­gań na sys­te­my, tj. tego CO sys­te­my mają zro­bić [dla akto­ra, a nie JAK]). 

Często sły­szę zarzu­ty, że ​„dia­gra­my UML i doku­men­ty je zawie­ra­ją­ce, nie poma­ga­ją deve­lo­pe­rom, dla­te­go nie uży­wa­my UML”. No cóż, ale dia­gra­my, jak ten tu opi­sa­ny, i nie raz jak te na stro­nach Wikipedii czy Stackoverflow, pre­zen­tu­ją podob­ny poziom, i fak­tycz­nie nie są przy­dat­ne… A sto­so­wa­nie dia­gra­mów przy­pad­ków uży­cia do opi­su ​„pro­ce­sów” (łań­cu­chy «extend» i «inc­lu­de») to wręcz epi­de­mia.. ;). Przypominam tak­że, że logo­wa­nie to nie przy­pa­dek uży­cia (use case) apli­ka­cji, a funk­cjo­nal­ność śro­do­wi­ska apli­ka­cji (są też inne meto­dy uwie­rzy­tel­nia­nia użytkownika). 

Dlatego pole­cam źró­dła rze­tel­nej wie­dzy o nota­cjach, a są to ory­gi­nal­ne spe­cy­fi­ka­cje, któ­rych umie­jęt­ność czy­ta­nia jest pod­sta­wo­wą umie­jęt­no­ścią dobre­go ana­li­ty­ka i pro­jek­tan­ta. Tu nie cho­dzi o ​„głu­pie bycie orto­dok­sem”, cho­dzi o JEDNOZNACZNOŚĆ doku­men­ta­cji, czy­li i autor doku­men­tu i jego adre­sat, powin­ni uży­wać tego same­go ​„kodu”, czy­li sto­so­wać się do spe­cy­fi­ka­cji uży­wa­nej nota­cji. Bez tego mamy wyłącz­nie nie­po­ro­zu­mie­nia i dodat­ko­we kosz­ty w projektach. 

W ran­kin­gach przy­czyn pora­żek pro­jek­tów, nie­jed­no­znacz­ność doku­men­ta­cji zawsze jest w pierw­szej trójce. 

Źródła

OMG​.org (2017) Unified Modeling Language (UML), UML. Available at: https://​www​.omg​.org/​s​p​e​c​/​U​ML/ (Accessed: 5 December 2019).
Zelinski, J. (2020) ​‘Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns’, in Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities. IGI Global, pp. 78 – 89. Available at: https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699 (Accessed: 18 December 2019).

Chmura wykończy wdrożenia ?on-premises?. Ich śmierć ma być powolna…

4 komentarze

Niedawno prze­czy­ta­łem, że:

„Chmura obli­cze­nio­wa sztur­mem zdo­by­wa rynek IT. Liczba wdro­żeń opro­gra­mo­wa­nia w mode­lu SaaS rośnie w tem­pie 20,1 proc. rdr ? poda­ją ana­li­ty­cy z fir­my Gartner. Na naszych oczach odby­wa się rewo­lu­cja, któ­rej naj­więk­szą ofia­rą jest opro­gra­mo­wa­nie insta­lo­wa­ne na wła­snej, fir­mo­wej infra­struk­tu­rze. Agonię wdro­żeń ?on-pre­mi­ses? wie­ści Eric Kimberling, part­ner zarzą­dza­ją­cy w fir­mie dorad­czej Panorama Consulting. Jego zda­niem chmu­ra obli­cze­nio­wa posia­da tak wie­le zalet, że porzu­ce­nie przez przed­się­bior­stwa roz­wią­zań sta­cjo­nar­nych jest jedy­nie kwe­stią czasu.”

https://​fin​tek​.pl/​c​h​m​u​r​a​-​w​y​k​o​n​c​z​y​-​w​d​r​o​z​e​n​i​a​-​o​n​-​p​r​e​m​i​s​e​s​-​s​m?/

Źródło: Chmura wykoń­czy wdro­że­nia ?on-pre­mi­ses?. Ich śmierć ma być powol­na, ale defi­ni­tyw­na ? Fintek​.pl

Po pierw­sze: to, że dzi­siaj rośnie 20,1% rdr nie zna­czy (ehh, ta wia­ra w tren­dy..), że tak będzie zawsze. Po dru­gie, nie tyl­ko z uwa­gi na pra­wa autor­skie i ochro­nę know-how, zawsze będzie kla­sa sys­te­mów, któ­re w chmu­rze nigdy nie wylą­du­ją. Ten arty­kuł w moich oczach, to kla­sy­ka PR-owców two­rzą­ca sztucz­ną rze­czy­wi­stość w mediach i tak zwa­ne ​„samo­speł­nia­ją­ce się prze­po­wied­nie”, bazu­ją­ce w 100% na kon­for­mi­zmie czy­tel­ni­ków takich prognoz.

Swego cza­su, 2016 rok, mia­łem refe­rat na kon­fe­ren­cji doty­czą­cej archi­tek­tu­ry w chmu­rze. Kilka tez, któ­re pomo­gą oce­nić wróż­by upad­ku wdro­żeń ​„u siebie”.

Każdy pro­jekt wdro­że­nio­we ma dwa klu­czo­we, oczy­wi­ste, para­me­try: czas wdro­że­nia i łącz­ny koszt (pozy­ska­nie i posia­da­nie – utrzy­ma­nie). Jednak w dobie zmien­no­ści ryn­ku jaką mamy obec­nie, war­to brać pod uwa­gę tak­że ryzy­ko tego, że zmie­ni­my decy­zję bo zmie­ni­ły się warun­ki. Dlatego poja­wia się para­metr jakim jest czas wyj­ścia z inwe­sty­cji, co sta­je się coraz waż­niej­szym para­me­trem, z uwa­gi na ryzy­ko takich wdro­żeń i ryzy­ko wyni­ka­ją­ce ze zmien­no­ści rynku.

Co wiemy o wdrożeniach?

Pomijając, deta­licz­ne kwo­ty, wła­sna insta­la­cja jest naj­tań­sza w utrzy­ma­niu jed­nak trze­ba ponieść rela­tyw­nie duże kosz­ty pozy­ska­nia i wdro­że­nia. Na prze­ciw­nym koń­cu jest typo­wa insta­la­cja w tak zwa­nej chmu­rze, któ­ra nie wyma­ga prak­tycz­nie żad­ne­go okre­su ​„roz­ru­chu”. Po środ­ku jest out­so­ur­cing, któ­ry ma niż­sze kosz­ty ini­cja­cji w porów­na­niu z insta­la­cją na wła­ność, ale wyż­sze kosz­ty utrzy­ma­nia (mar­ża na zaso­by ludzkie).

Na tym tle mamy typo­we, dla obec­ne­go ryn­ku, wyma­ga­nia biznesowe:

Nazwałem je ​„impli­ku­ją­ce zasto­so­wa­nie chmu­ry”, bo jak widać są to dość typo­we wyma­ga­nia w dobie szyb­kiej zmien­no­ści oto­cze­nia ryn­ko­we­go. Jednak jest pewien haczyk: wszyst­ko w chmu­rze to naj­kosz­tow­niej­sza w utrzy­ma­niu wer­sja. Dlatego fir­my, po usta­le­niu tego co jest tak­ty­ką a co stra­te­gią, powin­ny roz­wa­żyć decy­zję: odpo­wied­nio co powin­no dać się szyb­ko zmie­nić, a co będzie jed­nak sta­łym zaso­bem. Zasoby uzna­ne za sta­łe bez­piecz­nie (jako inwe­sty­cje) moż­na pozy­skać na wła­sność co w dłuż­szej per­spek­ty­wie daje odczu­wal­ne oszczęd­no­ści. Tam gdzie ryzy­ko zmia­ny jest zbyt duże, pono­si­my wyż­sze kosz­ty chmu­ry ale rekom­pen­su­je­my sobie to tym, że kosz­ty wyj­ścia z takiej inwe­sty­cji są bli­skie zera.

Na zakoń­cze­nie kil­ka słów o archi­tek­tu­rze. Warto pamię­tać, że – pomi­ja­jąc pro­por­cje – każ­da fir­ma ma opro­gra­mo­wa­nie u sie­bie i może mieć w chmu­rze, w efek­cie ich inte­gra­cja zawsze wyma­ga, by podej­mo­wa­nie decy­zji o korzy­sta­niu z chmu­ry, było w peł­ni świa­do­me. Każda decy­zja archi­tek­to­nicz­na na swo­je konsekwencje.

Dlatego, moim zda­niem, nie gro­zi nam jed­nak nigdy cał­ko­wi­ta rezy­gna­cja z opro­gra­mo­wa­nia na własność.