Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

Miło mi poin­for­mo­wać, że moja publi­ka­cja nauko­wa (tu była zapo­wiedź) na temat syn­te­zy wzor­ców archi­tek­to­nicz­nych i wzor­ców pro­jek­to­wych, sys­te­mów obiek­to­wo-zorien­to­wa­nych zatytułowana:

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

po dłu­gim pro­ce­sie selek­cji i recen­zo­wa­nia, zosta­ła zakwa­li­fi­ko­wa­na do publi­ka­cji i wła­śnie się uka­za­ła jako jeden z roz­dzia­łów książki:

Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities.

Jeszcze milej mi poin­for­mo­wać, że – jako współ­au­tor – mogę Wam zaofe­ro­wać kod pro­mo­cyj­ny dają­cy 40% zniż­ki na zakup: IGI40.

Poniżej infor­ma­cje o książ­ce i o wydawcy. 

O książce

Ch. 3: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities:
Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns (050719 – 041004) (J.Żeliński)

DescriptionIn today?s moder­ni­zed envi­ron­ment, a gro­wing num­ber of softwa­re com­pa­nies are chan­ging the­ir tra­di­tio­nal engi­ne­ering appro­aches in respon­se to the rapid deve­lop­ment of com­pu­ting tech­no­lo­gies. As the­se busi­nesses adopt modern softwa­re engi­ne­ering prac­ti­ces, they face vario­us chal­len­ges inc­lu­ding the inte­gra­tion of cur­rent metho­do­lo­gies and con­tem­po­ra­ry design models and the refac­to­ring of exi­sting sys­tems using advan­ced approaches.Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities is a pivo­tal refe­ren­ce sour­ce that pro­vi­des vital rese­arch on the deve­lop­ment of modern softwa­re prac­ti­ces that impact main­te­nan­ce, design, and deve­lo­per pro­duc­ti­vi­ty. While high­li­gh­ting topics such as augmen­ted reali­ty, distri­bu­ted com­pu­ting, and big data pro­ces­sing, this publi­ca­tion explo­res the cur­rent infra­struc­tu­re of softwa­re sys­tems as well as futu­re advan­ce­ments. This book is ide­al­ly desi­gned for softwa­re engi­ne­ers, IT spe­cia­li­sts, data scien­ti­sts, busi­ness pro­fes­sio­nals, deve­lo­pers, rese­ar­chers, stu­dents, and aca­de­mi­cians seeking cur­rent rese­arch on con­tem­po­ra­ry softwa­re engi­ne­ering methods. Source: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities: 9781799821427: Computer Science & IT Books | IGI Global

O wydawcy

IGI Global is a leading inter­na­tio­nal aca­de­mic publi­sher com­mit­ted to faci­li­ta­ting the disco­ve­ry of pio­ne­ering rese­arch that enhan­ces and expands the body of know­led­ge ava­ila­ble to the rese­arch com­mu­ni­ty. Working in clo­se col­la­bo­ra­tion with expert rese­ar­chers and pro­fes­sio­nals from leading insti­tu­tions, inc­lu­ding Massachusetts Institute of Technology (MIT), Harvard University, Stanford University, University of Cambridge, University of Oxford, Tsinghua University, and Australian National University, IGI Global dis­se­mi­na­tes quali­ty con­tent across 350+ topics in 11 core sub­ject are­as. Source: About IGI Global | IGI Global

Synteza pojęć i wzorców MOF, MDA, PIM, MVC i BCE. Zintegrowany model struktury procesu projektowania aplikacji.

Streszczenie: Wiele publi­ka­cji, w tym pod­ręcz­ni­ki aka­de­mic­kie, zawie­ra nie­spój­no­ści w opi­sach zasto­so­wań metod i wzor­ców archi­tek­to­nicz­nych, kry­ją­cych się pod skró­ta­mi MOF, MDA, PIM, MVC, BCE. Skuteczna ana­li­za oraz nastę­pu­ją­ce po niej pro­jek­to­wa­nie opro­gra­mo­wa­nia, szcze­gól­nie gdy są to pro­jek­ty reali­zo­wa­ne w dużych zespo­łach, wyma­ga stan­da­ry­za­cji pro­ce­su wytwór­cze­go i sto­so­wa­nych wzor­ców i fra­me­wor­ków. W pra­cy tej pod­ję­to pró­bę upo­rząd­ko­wa­nia sys­te­mu pojęć opi­su­ją­cych ten pro­ces , sto­so­wa­nych do opi­su wzor­ców archi­tek­to­nicz­nych. Przeprowadzono ana­li­zę klu­czo­wych pojęć MOF i MDA, wzor­ców MVC i BCE, stwo­rzo­no spój­ny opis łączą­cy je w jeden system.

1. Wprowadzenie

Celem badań było zwe­ry­fi­ko­wa­nie obec­ne­go sta­nu metod pro­jek­to­wa­nia i opra­co­wa­nie spój­ne­go sys­te­mu pojęć i wzor­ców pro­jek­to­wych w obsza­rze pro­jek­to­wa­nia logi­ki opro­gra­mo­wa­nia, jako jej abs­trak­cyj­ne­go mode­lu. Wiele publi­ka­cji na temat ana­liz i pro­jek­to­wa­nia, w obsza­rze inży­nie­rii opro­gra­mo­wa­nia, przy­wo­łu­je nazwy wzor­ców pro­jek­to­wych MVC i BCE oraz model PIM (patrz OMG MDA, OMG MOF 2016). Z uwa­gi na, nie raz, nie małe roz­bież­no­ści w inter­pre­ta­cji tych metod i wzor­ców, autor pod­jął pró­bę upo­rząd­ko­wa­nia ich wza­jem­nych zależności.

2. Metody

Wykorzystano sys­te­my nota­cyj­ne Object Management Group (OMG​.org). Specyfikacja MOF opi­su­je trzy pozio­my abs­trak­cji: M1, M2, M3 oraz poziom M0 czy­li real­ne rze­czy (patrz struk­tu­ra pozio­mów abs­trak­cji, OMG MOF 2016). M0 to real­ny sys­tem, poziom M1 to abs­trak­cja obiek­tów tego sys­te­mu (jego model) . Poziom M2 to związ­ki pomię­dzy kla­sa­mi tych obiek­tów (nazwy ich zbio­rów) czy­li meta­mo­del sys­te­mu. Poziom M3 to meta-meta­mo­del poziom opi­su­ją­cy meto­dę mode­lo­wa­nia z uży­ciem nazwa­nych ele­men­tów o okre­ślo­nej seman­ty­ce i syntaktyce.

Proces ana­li­zy i pro­jek­to­wa­nia został opar­ty na spe­cy­fi­ka­cji MDA (OMG MDA). Proces ten ma trzy fazy rozu­mia­ne jako two­rze­nie kolej­nych mode­li: CIM, PIM, PSM oraz fazę two­rze­nie kodu. Model CIM jest doku­men­to­wa­ny z uży­ciem nota­cji BPMN (OMG BPMN 2013) i SBVR (OMG SBVR 2017). Są to odpo­wied­nio: mode­le pro­ce­sów biz­ne­so­wych oraz mode­le poję­cio­we i regu­ły biz­ne­so­we. Modele PIM i PSM doku­men­to­wa­ne są z uży­ciem nota­cji UML (OMG UML 2017). Pomiędzy mode­lem CIM a PIM ma miej­sce usta­le­nie listy usług apli­ka­cyj­nych (reak­cje sys­te­mu), któ­rych mecha­nizm reali­za­cji opi­su­je model PIM. Standardowym wzor­cem uży­wa­nym do mode­lo­wa­nia archi­tek­tu­ry apli­ka­cji jest wzo­rzec MVC. Komponent Model tego wzor­ca jest mode­lo­wa­ny z uży­ciem wzor­cza archi­tek­to­nicz­ne­go BCE.

[…]

Spis tre­ści
1. Wprowadzenie 1
2. Metody 2
2.1. Semiotyka a UML 2
2.2. Specyfikacja MOF Poziomy abs­trak­cji 3
2.3. Specyfikacja MDA i model PIM 4
2.4. Wzorzec archi­tek­to­nicz­ny MVC 5
2.5. Wzorzec archi­tek­to­nicz­ny BCE 5
3. Rezultaty 6
3.1. Założenie uprosz­cza­ją­ce 6
3.2. Zintegrowany model struk­tu­ry pro­ce­su pro­jek­to­wa­nia apli­ka­cji 7
4. Dyskusja 8
5. Dalsze pra­ce 8
6. Bibliografia 9
7. Kluczowe poję­cia meto­dycz­ne 11

Cała publi­ka­cja …

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns
Jaroslaw Zelinski (Independent Researcher, Poland)

Source Title: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities
Copyright: ? 2020 |Pages: 12
DOI: 10.4018/978 – 1‑7998 – 2142‑7.ch003

MDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Ten arty­kuł moż­na czy­tać na dwa spo­so­by: ana­li­ty­cy czy­ta­ją od dechy do dechy po kolei ;). Menedżerowie i tak zwa­ny biz­nes czy­ta­ją od razu koniec, to jest część Na zakoń­cze­nie, gdy uzna­ją, że nie wie­rzą w te wnio­ski (wyrok) to zaczy­na­ją od począt­ku czy­li czy­ta­ją uzasadnienie :).

Niedawno napi­sa­łem:

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. (Źródło: Analiza a mode­lo­wa­nie czy­li ile abs­trak­cji a ile rze­czy­wi­sto­ści | | Jarosław Żeliński IT-Consulting)

Kontynuując temat z innej per­spek­ty­wy powie­my sobie teraz o eta­pach ana­li­zy i pro­jek­to­wa­nia w inży­nie­rii, nie tyl­ko opro­gra­mo­wa­nia, w opar­ciu o MDA ([[Model Driven Architecture]], www​.omg​.org/​mda, pole­cam tak­że poję­cie [[model dri­ven engi­ne­ering]]). Dobra infor­ma­cja dla czy­tel­ni­ków: na koń­cu się wszyst­ko wyja­śni, moż­na pomi­nąć część o MDA 🙂

MDA

Pięć lat temu, jeden z arty­ku­łów o mode­lo­wa­niu i pro­jek­to­wa­niu, koń­czy­łem tymi słowami:

Podsumowując moż­na by powie­dzieć, że eta­py two­rze­nia opro­gra­mo­wa­nia to:

  1. Analiza biz­ne­so­wa, któ­rej pro­duk­tem są: model orga­ni­za­cji (model biz­ne­so­wy) oraz opis tego co ma powstać (opis, wyma­ga­nia na opro­gra­mo­wa­nie). Całość (sfor­ma­li­zo­wa­ne mode­le) pozwa­la na prze­te­sto­wa­nie czy tak okre­ślo­ne wyma­ga­nia speł­nia­ją potrze­by biznesu.
  2. Wytworzenie opro­gra­mo­wa­nia pole­ga­ją­ce na: opra­co­wa­niu szcze­gó­łów archi­tek­tu­ry, roz­wią­za­niu pro­ble­mów tech­nicz­nych (wyma­ga­nia nie­funk­cjo­nal­ne), kodo­wa­niu oraz dostar­cze­niu i wdrożeniu.

Źródło: Hej, Biznesie, to ma być dla biz­ne­su czy­li dla Ciebie! | | Jarosław Żeliński IT-Consulting

Powoływałem się w tym tek­ście wła­śnie na MDA. Czymże to jest? Na stro­nach OMG znaj­dzie­my: Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0) Contact: Dr. Jon M. SiegelThis final draft of the revi­sed MDA Guide edi­ted in Boston on 18 June 2014 reflects all AB edits requ­ested at the Reston and Boston AB meetings. (Źródło: OMG Document – ormsc/14 – 06-01 (MDA Guide revi­sion 2.0)

Skorzystam z kil­ku cyta­tów i napi­sze co nie­co o MDA. Poniżej klu­czo­we tezy, nie mia­łem tu ambi­cji lite­ral­ne­go tłu­ma­cze­nia tego doku­men­tu, cho­dzi­ło mi o pryncypia.

This guide descri­bes the Model Driven Architecture (MDA) appro­ach as defi­ned by the Object Management Group (OMG). MDA pro­vi­des an appro­ach for deri­ving value from models and archi­tec­tu­re in sup­port of the full life cyc­le of phy­si­cal, orga­ni­za­tio­nal and I.T. sys­tems (A ?System?, in this con­text, is any arran­ge­ment of parts and the­ir inter­re­la­tion­ships, wor­king toge­ther as a who­le.). The MDA appro­ach repre­sents and sup­ports eve­ry­thing from requ­ire­ments to busi­ness mode­ling to tech­no­lo­gy imple­men­ta­tions. By using MDA models, we are able to bet­ter deal with the com­ple­xi­ty of lar­ge sys­tems and the inte­rac­tion and col­la­bo­ra­tion betwe­en orga­ni­za­tions, people, har­dwa­re, software.

Stosowanie mode­li pozwa­la znacz­nie lepiej radzić sobie ze zło­żo­no­ścią wiel­kich sys­te­mów jaki­mi są orga­ni­za­cje oraz funk­cjo­nu­ją­ce w nich związ­ki mię­dzy ludź­mi, opro­gra­mo­wa­niem i infra­struk­tu­rą. Fakt, że bada­ne orga­ni­za­cje współ­pra­cu­ją z inny­mi, dodat­ko­wo kom­pli­ku­je tę całość.

Models as com­mu­ni­ca­tions vehicles

A fun­da­men­tal value pro­po­si­tion for models and mode­ling is to faci­li­ta­te a team or com­mu­ni­ty coming to a com­mon under­stan­ding and/or consensus.

Jedną z głów­nych ról mode­li, poza ich ana­li­zą, jest komu­ni­ka­cja: komu­ni­ku­je­my innym człon­kom zespo­łu (tak­że klien­tom) to co zro­zu­mie­li­śmy i to cze­go ocze­ku­je­my. Tak więc mode­le są zarów­no opi­sem rze­czy­wi­sto­ści powsta­łym w toku jej zro­zu­mie­nia, są tak­że opi­sem tego co ma powstać, jeże­li chce­my tę rze­czy­wi­stość stworzyć.

[?]Abstraction deals with the con­cepts of under­stan­ding a sys­tem in a more gene­ral way; said in more ope­ra­tio­nal terms, with abs­trac­tion one eli­mi­na­tes cer­ta­in ele­ments from the defi­ned sco­pe; this may result in intro­du­cing a higher level view­po­int at the expen­se of remo­ving deta­il. A model is con­si­de­red more abs­tract if it encom­pas­ses a bro­ader set of sys­tems and less abs­tract if it is more spe­ci­fic to a sin­gle sys­tem or restric­ted set of systems. [?]

Podstawową rze­czą w ana­li­zie jest redu­ko­wa­nie szcze­gó­łów i uogól­nia­nie. Człowiek nie jest w sta­nie ana­li­zo­wać cze­goś co skła­da się z setek detali.

Model Analytics

Once models are cap­tu­red as seman­tic data vario­us ana­ly­tics can be exe­cu­ted across tho­se models inc­lu­ding model vali­da­tion, sta­ti­stics and metrics. Analytics assi­sts in deci­sion making, moni­to­ring and quali­ty asses­sment. OMG MDA Guide rev. 2.0 June 2014 page 2

Modele poję­cio­we i ana­li­tycz­ne słu­żą do zro­zu­mie­nia bada­nej rze­czy­wi­sto­ści. Modele two­rzo­ne (pro­jek­to­wa­nie) słu­żą do testo­wa­nia pomy­słów i podej­mo­wa­nia decy­zji, dalej zaś sta­no­wią opis cech wyma­ga­ne­go roz­wią­za­nia. Modele wyko­ny­wal­ne to inne mode­le ale bazu­ją na mode­lach ana­li­tycz­nych. Poniżej, na bazie MOF ([[Meta Object Facility]]), poka­za­no trzy pozio­my abs­trak­cji (poziom zero­wy to rzeczywistość).

poziomy-abstrakcji

Abstrakcja to uprosz­czo­ny” (pozba­wio­ny zbęd­nych szcze­gó­łów) model okre­ślo­nej rze­czy­wi­sto­ści. Metamodel to mecha­nizm two­rze­nia tej rze­czy­wi­sto­ści w tym tak­że model poję­cio­wy (wię­cej w dal­szej części).

Model (M1) więc jest albo wyni­kiem (pro­duk­tem) ana­li­zy bada­nej rze­czy­wi­sto­ści, albo wyni­kiem (pro­duk­tem) pro­ce­su jej pro­jek­to­wa­nia (pro­jek­to­wa­nia rozwiązania). 

Model Simulation and Execution

Models as data can dri­ve simu­la­tion engi­nes that can assist in both ana­ly­tics and exe­cu­tion of the desi­gns cap­tu­red in models. Simulation assi­sts in the human under­stan­ding of how a mode­led sys­tem will func­tion as well as a way to vali­da­te that models are cor­rect. Models can, in some cases be direc­tly exe­cu­ted ? serving as the ?sour­ce code? for high­le­vel appli­ca­tions that imple­ment pro­ces­ses, data repo­si­to­ries and servi­ce end­po­ints. Model exe­cu­tion pro­vi­des a direct and imme­dia­te path to reali­zing a design with a mini­mum of tech­ni­cal deta­ils being expo­sed. DBMS Schema and pro­cess models are well-known cate­go­ries of (par­tial­ly) exe­cu­ta­ble models.[?]

Modele symu­la­cyj­ne słu­żą do testo­wa­nia hipo­tez i podej­mo­wa­ni decy­zji. Modele wyko­ny­wal­ne, w tym two­rzo­ne auto­ma­tycz­nie na bazie mode­li abs­trak­cyj­nych, to narzę­dzia do two­rze­nia wyko­ny­wal­ne­go kodu. Nie tyl­ko w moim mnie­ma­niu, jest to albo dale­ka przy­szłość (mam na myśli komer­cyj­ne zasto­so­wa­nia) albo wyłącz­nie aka­de­mic­kie bada­nia. Wiem, że są uda­ne pró­by gene­ro­wa­nia dzia­ła­ją­ce­go kodu z mode­li, jed­nak wyma­ga­nia na ilość deta­li, jakie trze­ba zade­kla­ro­wać w tych mode­lach, zbli­ża ich zło­żo­ność do zło­żo­no­ści kodu jaki powsta­je. Nie będzie­my się tu zaj­mo­wa­li mode­la­mi wykonywalnymi.

Cztery produkty

Te dwa opi­sa­ne na począt­ku eta­py do ana­li­za sys­te­mo­wa orga­ni­za­cji (potocz­nie ana­li­za biz­ne­so­wa”) oraz imple­men­ta­cja roz­wią­za­nia. Produkty to …

MDA to archi­tek­tu­ra mają­ca trzy pozio­my mode­lo­wa­nia, nazy­wa­ne od góry” CIM (Computation Independent Model), PIM (Platform Independent Model) i PSM (Platform Specific Model).

Architectural Layers It is use­ful to iden­ti­fy par­ti­cu­lar ?lay­ers? of an archi­tec­tu­re with respect to its level of abs­trac­tion. While the­re can be any num­ber of archi­tec­tu­ral lay­ers, a bro­ad cate­go­ri­za­tion of this con­cept is:

  • Business or doma­in models ? models of the actu­al people, pla­ces, things, and laws of a doma­in. The ?instan­ces? of the­se models are ?real things?, not repre­sen­ta­tions of tho­se things in an infor­ma­tion sys­tem. In MDA doma­in models have histo­ri­cal­ly been cal­led a ?CIM? for ?Computation Independent Model?.
  • Logical sys­tem models ? models of the way the com­po­nents of a sys­tem inte­ract with each other, with people and with orga­ni­za­tions to assist an orga­ni­za­tion or com­mu­ni­ty in achie­ving its goals. [model PIM]
  • Implementation models ? the way in which a par­ti­cu­lar sys­tem or sub­sys­tem is imple­men­ted such that it car­ries out its func­tions. Implementation models are typi­cal­ly tied to a par­ti­cu­lar imple­men­ta­tion tech­no­lo­gy or plat­form. [model PSM].

Model CIM opi­su­je ludzi i ich związ­ki, miej­sca, pra­wa rzą­dzą­ce tym wszyst­kim. Ten model opi­su­je real­ną, bada­ną rze­czy­wi­stość cał­ko­wi­cie abs­tra­hu­jąc od wyko­rzy­sty­wa­nych ewen­tu­al­nie posia­da­nych narzę­dzi infor­ma­tycz­nych (w przy­pad­ku start-up’u lub roz­wo­ju orga­ni­za­cji jest to przy­szła jej postać). Nie jest to model jakie­go­kol­wiek opro­gra­mo­wa­nia ani tego jak ono dzia­ła. Produktem tego eta­pu są: mode­le pro­ce­sów biz­ne­so­wych, spe­cy­fi­ka­cja reguł biz­ne­so­wych, biz­ne­so­wy słow­nik pojęć i mode­le pojęciowe.

Model PIM opi­su­je kom­po­nen­ty apli­ka­cji, ich wza­jem­ne inte­rak­cje, logi­kę dzia­ła­nia tych kom­po­nen­tów (ta część logi­ki opi­sa­nej w mode­lu CIM, któ­ra ma być reali­zo­wa­na w apli­ka­cji). Produktem tego eta­pu są mode­le: przy­pad­ków uży­cia (w tym postać nośni­ków danych, moc­ku­p’y ekra­nów), kom­po­nen­tów, wewnętrz­ne struk­tu­ry kom­po­nen­tów (mode­le dzie­dzi­ny z per­spek­ty­wy wzor­ca MVC), inte­rak­cji, inne jeśli konieczne.

Model PSM to model będą­cy pro­jek­tem wyko­naw­czym. Jest to roz­sze­rze­nie mode­lu PIM, uszcze­gó­ło­wie­nie go wraz z dodat­ko­wy­mi ele­men­ta­mi tech­nicz­ny­mi (reali­zu­ją­cy­mi śro­do­wi­sko, bez­pie­czeń­stwo, wyma­ga­ną wydaj­ność itp.). Kod apli­ka­cji to mate­ria­li­za­cja (imple­men­ta­cja) mode­lu PSM. 

Powyższe, to czte­ry pro­duk­ty powsta­ją­ce w tym pro­ce­sie. Dlaczego pisze o dwóch eta­pach? Poniżej wyjaśnienie.

model-driven-architecture-structure

Diagram obra­zu­je produkty/fazy defi­nio­wa­ne jako MDA. Każdy pro­dukt ana­li­zy to okre­ślo­ny zestaw mode­li. Na dia­gra­mie wska­za­no jakich nota­cji uży­wa się w każ­dym z nich (tu bazu­jąc na nota­cjach rodem z OMG). Tu przy­po­mi­nam to co już nie raz pisa­łem: celem jest zro­zu­mie­nie (i two­rze­nia potrzeb­nych w danym przy­pad­ku mode­li) oraz prze­ka­za­ne tej wie­dzy, a nie two­rze­nie jakichś mode­li i doku­men­tów”. Każdy model, jego powsta­nie, ma okre­ślo­ny cel.

Jeszcze sto­sun­ko­wo nie­daw­no w moich pro­jek­tach zwią­za­nych z opro­gra­mo­wa­niem, wyróż­nia­łem trzy eta­py: ana­li­za orga­ni­za­cji, spe­cy­fi­ka­cja wyma­gań oraz opra­co­wa­nie logi­ki dla dedy­ko­wa­nych kom­po­nen­tów opro­gra­mo­wa­nia. W koń­cu, po kil­ku pro­jek­tach, prze­ko­na­łem się, że ten podział nie dzia­ła”. Dlaczego?

Skoro na eta­pie CIM opra­co­wa­li­śmy mię­dzy inny­mi model logi­ki biz­ne­so­wej dla danej orga­ni­za­cji (w tym regu­ły biz­ne­so­we, słow­nik pojęć) to już ją, te logi­kę, mamy. Okazało się, że ten trze­ci etap” w zasa­dzie jest sztucz­ny, gdyż rze­tel­ne opra­co­wa­nie CIM to tak­że ta” logi­ka. Tu war­to przy­to­czyć diagram:

Swego cza­su pisa­łem tak­że o testo­wa­niu modeli:

W toku dal­szej pra­cy podej­mo­wa­na jest decy­zja o zakre­sie pro­jek­tu. Wskazując to, jakie dzia­ła­nia” ma wspie­rać lub prze­jąć na sie­bie apli­ka­cja (to są wła­śnie przy­pad­ki uży­cia), wska­zu­je­my jaka logi­ka ma być przez tę apli­ka­cję reali­zo­wa­na i kie­dy. Wskazanie zakre­su pro­jek­tu jest więc pierw­szym eta­pem defi­nio­wa­nia logi­ki apli­ka­cji. Jeżeli do tego dodać wie­dzę dzie­dzi­no­wą, np. to któ­re ele­men­ty mogą być współ­dzie­lo­ne a któ­re nie, któ­re powin­ni być cał­ko­wi­cie nie­za­leż­ne itp., powsta­nie tak zwa­ny model dzie­dzi­ny sys­te­mu (logi­ka biz­ne­so­wa i jej struk­tu­ra czy­li archi­tek­tu­ra apli­ka­cji, a kon­kret­nie czę­ści reali­zu­ją­cej logi­kę biznesową).

Na zakończenie

Jak podejść do pla­nów zaku­pu tak­że goto­we­go opro­gra­mo­wa­nia? Czy war­to je pro­jek­to­wać? Oczywiście, że war­to z pro­ste­go powo­du: nie ma zna­cze­nia to, czy przy­szłe opro­gra­mo­wa­nie będzie goto­we czy trze­ba je będzie dopie­ro stwo­rzyć. Ono ma reali­zo­wać taką logi­kę jakiej ocze­ku­je­my. Owszem, jest moż­li­wa decy­zja: sko­ro na ryn­ku nie ma poszu­ki­wa­ne­go pro­duk­tu a stwo­rze­nie dedy­ko­wa­ne­go jest zbyt kosz­tow­ne, to albo rezy­gnu­je­my z zaku­pu albo z okre­ślo­nej logi­ki wewnątrz orga­ni­za­cji. Jednak do pod­ję­cia takiej decy­zji musi­my tę logi­kę znać i mieć udo­ku­men­to­wa­ną (no bo jakoś musi­my ją poka­zać ofe­ren­tom). Ale dostaw­cy opro­gra­mo­wa­nia zawsze ofe­ru­ją ana­li­zę wyma­gań”… To praw­da … A ilu z nich powie, że nie mają Wam nic do zaofe­ro­wa­nia? Ale dedy­ko­wa­ne opro­gra­mo­wa­nie może zapro­jek­to­wać tyl­ko jego wyko­naw­ca”. To dla­cze­go fir­my budow­la­ne nie są dopusz­cza­ne do prac pro­jek­to­wych i architektonicznych?

Dlatego na dia­gra­mie powy­żej, jako moment wybo­ru dostaw­cy opro­gra­mo­wa­nia, wska­za­no ten w któ­rym mamy udo­ku­men­to­wa­ny model logi­ki czy­li PIM. To czy logi­ka taka jest dostęp­na w jakimś pro­duk­cie na ryn­ku czy nie, nie zmie­nia fak­tu, że i tak musi zostać ona opi­sa­na, bez cze­go taki wybór jest nie­moż­li­wy. Czym więc są (czym powin­ny być) wyma­ga­nia na opro­gra­mo­wa­nie? Niestety powin­ny być zwię­złym pro­jek­tem a nie dłu­gą listą cech.

Jeden ana­li­tyk pro­jek­tant mają­cy dobre wspar­cie narzę­dzio­we, jest w sta­nie wyko­nać ana­li­zę i pro­jekt dla dowol­nie dużej fir­my, wystar­czy, że potra­fi two­rzyć abs­trak­cje i zarzą­dzać zło­żo­no­ścią doku­men­ta­cji. Czy kil­ku ana­li­ty­ków zro­bi to nie gorzej i szyb­ciej? Nie znam takie­go przy­pad­ku.… bo im wię­cej osób pro­wa­dzi taką ana­li­zę tym wię­cej pra­cy wyma­ga koor­dy­na­cja i pra­ca nad spój­no­ścią całości.

Na zakoń­cze­nie cytat z pew­nej dyskusji:

I star­ted a com­pa­ny cal­led Nascent Blue that spe­cia­li­zes in MDD for appli­ca­tion deve­lop­ment. We have actu­al­ly had the oppor­tu­ni­ty to com­pa­re MDD to tra­di­tio­nal deve­lop­ment side-by-side on lar­ge pro­jects. Our client set up ?the expe­ri­ment? to col­lect the PM data for ana­ly­sis. It was a lar­ge pro­ject with 5 teams. The results:

1. Our team was less than half the size of the other teams.
2. Our team pro­du­ced more than twi­ce the code of the other teams.
3. Our team achie­ved a 75% reduc­tion in cost.
4. Our team achie­ved a 66% reduc­tion in defect rate.
5. Our team was twi­ce as fast (with half the size).
We have sin­ce got­ten more effi­cient and more advan­ced, so I don?t know what the num­bers are now.
(źr. Model dri­ven pro­duc­ti­vi­ty | LinkedIn).

MDA

ang. Model Driven Architecture (archi­tek­tu­ra zorien­to­wa­na na mode­le), archi­tek­tu­ra opar­ta na otwar­tych stan­dar­dach OMG (Object Management Group), pozwa­la na odse­pa­ro­wa­nie w ana­li­zie i pro­jek­to­wa­niu logi­ki biz­ne­so­wej, logi­ki apli­ka­cji i jej imple­men­ta­cji (źr. www​.omg​.org/​mda).

MDA defi­niu­je trzy typy mode­li: CIM, PIM, PSM (patrz pozo­sta­łe defi­ni­cje w słow­ni­ku). Model CIM (biz­ne­so­wy) to nie­za­leż­ny od tech­no­lo­gii model opi­su­ją­cy cele biz­ne­so­we (BMM), pro­ce­sy biz­ne­so­we (BPMN) oraz logi­kę tych pro­ce­sów i wspól­ny słow­nik (SBVR). Model ten powi­nien tak­że zawie­rać struk­tu­ry danych (doku­men­tów, tu UML). Model PIM (UML) to model opi­su­ją­cy wewnętrz­ną archi­tek­tu­rę i logi­kę pla­no­wa­nej do wdro­że­nia apli­ka­cji (opro­gra­mo­wa­nia). Zakres tego wdro­że­nia okre­śla sie z uży­ciem dia­gra­mu przy­pad­ków uży­cia (nie on ele­men­tem ani CIM ani PIM, to łącz­nik). Model PSM to pro­jekt wyko­na­nia opro­gra­mo­wa­nia w okre­ślo­nym śro­do­wi­sku deve­lo­per­skim. Tu prak­tycz­nie powsta­je jedy­nie model wdro­że­nia (UML) i doku­men­ta­cja kodu w for­mie wybra­nej przez wyko­naw­cę. Poniżej dia­gram obra­zu­ją­cy związ­ki mie­dzy tymi modelami. 

Struktura mode­li w MDA. Po lewej stro­nie typo­wy pro­ces MDA, po pra­wej pró­ba uży­cia mode­li wyko­ny­wal­nych BPMN (BPEL4WS) w miej­sce PIM, ścież­ka ta jed­nak nie przy­ję­ła się. 

Czytaj tak­że: MDA – Cztery pro­duk­ty czy­li dwa eta­py: wyma­ga­nia i produkt

Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. W Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (s. 78 – 89). IGI Global. 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

UML MDA czyli od biznesu do projektu logiki systemu

(arty­kuł uzu­peł­nio­ny w 2019 r.) 

Kolejna god­na pole­ce­nia książ­ka na ryn­ku. Nie mia­łem cza­su by wcze­śniej ją opi­sać ale w koń­cu uda­ło się. Ale od począt­ku, wró­ci­my do niej.

To co naj­czę­ściej wzbu­dza brak zaufa­nia to teza, że moż­na prze­pro­wa­dzić ana­li­zę i pro­jek­to­wa­nie opro­gra­mo­wa­nia na papie­rze”. Programiści w więk­szo­ści uwa­ża­ją, że to nie moż­li­we (rok temu na stro­nach tego blo­ga burz­li­wa dys­ku­sja z jed­nym z nich…). W więk­szo­ści przy­pad­ków pod­czas spo­tkań (kon­fe­ren­cje, pro­jek­ty itp.) z zespo­ła­mi pro­gra­mi­stów sły­szę: czy­ta­my wyma­ga­nia, kodu­je­my od razu i two­rzy­my kolej­ne wer­sje apli­ka­cji; ina­czej się nie da”. W przy­pad­ku szko­leń, ostat­nie­go dnia warsz­ta­tów naj­czę­ściej sły­szę: ooo, w cią­gu jed­ne­go dnia [teraz] powstał kom­plet­ny pro­jekt dzie­dzi­ny sys­te­mu [cho­dzi­ło o kom­po­nent], prze­te­sto­wa­ny i oczysz­czo­ny z wąt­pli­wo­ści, bra­ku logi­ki i nie­spój­no­ści, do tego łatwy w dal­szym roz­bu­do­wy­wa­niu; to co zro­bi­li­śmy teraz na dia­gra­mach UML w cią­gu dnia, jako zespół tra­dy­cyj­ną meto­dą robi­li­by­śmy co naj­mniej tydzień, bio­rąc pod uwa­gę kodo­wa­nie każ­de­go pomy­słu by go dać użyt­kow­ni­ko­wi do testów”. W zasa­dzie taki pro­ces ana­li­zy i pro­jek­to­wa­nia jest zna­ny od lat jako Model Driven Architecture (MDA):

W czym pro­blem? Nauczyć się pra­co­wać na mode­lach (abs­trak­cje sys­te­mu) a nie od razu na kodzie (a raczej poprze­dzić kodo­wa­nie ana­li­zą i pro­jek­to­wa­niem), nauczyć się wzor­ców pro­jek­to­wych i przede wszyst­kim obiek­to­we­go myśle­nia (para­dyg­ma­tu) czy­li ana­li­zy i pro­jek­to­wa­nia. Wykonanie – imple­men­ta­cja na koń­cu a nie na począt­ku (podob­nie jak baza danych: w meto­dach obiek­to­wych pro­jek­tu­je­my utrwa­la­nie na koń­cu!). Po dru­gie, nie­ste­ty, nie raz sły­sza­łem o dostaw­ców: nie mamy inte­re­su w tym by pro­jekt trwał krót­ko”, to jed­nak tyl­ko argu­ment za tym by nie zle­cać im pro­jek­to­wa­nia a tyl­ko realizację.

MDA to trzy klu­czo­we eta­py: CIM, PIM i PSM (szcze­gó­ło­wo opi­sa­łem w arty­ku­le o ana­li­zie). Interesuje mnie tu etap CIM (Computation Independent Model) i PIM (Platform Independent Model). Pierwszy to ana­li­za biz­ne­so­wa, nie ma ona nic wspól­ne­go z opro­gra­mo­wa­niem, jej celem jest zro­zu­mie­nie i udo­ku­men­to­wa­nie tego co robią przy­szli użyt­kow­ni­cy sys­te­mu oraz wska­za­nie zakre­su pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia. Drugi to PIM czy­li opra­co­wa­nie mode­lu logi­ki sys­te­mu bez wzglę­du na to w jakiej tech­no­lo­gii powsta­nie, tu mil­czą­cym zało­że­niem jest, że będzie to tech­no­lo­gia obiek­to­wa jed­nak język pro­gra­mo­wa­nia może być dowolny.

Dużą zale­tą tego podej­ścia jest to, że opra­co­wa­nie mode­lu PIM jako Opisu Przedmiotu Zamówienia (OPZ) jest zgod­ne z PZP (Prawo Zamówień Publicznych) bo nie deter­mi­nu­je imple­men­ta­cji ale dokład­nie opi­su­je ocze­ki­wa­nia. Uważam, że jest to naj­lep­szy spo­sób two­rze­nia OPZ, bo nie pozo­sta­wia dowol­no­ści w kwe­stii funk­cjo­nal­no­ści roz­wią­za­nia. Jaki mamy tu pro­blem? Należy oddzie­lić pro­jek­to­wa­nie od reali­za­cji czy­li mamy dwa eta­py pro­jek­tu zamiast jed­ne­go, dwóch wyko­naw­ców (ana­li­za i pro­jek­to­wa­nie oraz reali­za­cja). Wady? Nie, korzy­ści bo wyko­naw­ca i tak musi jakiś pro­jekt opra­co­wać, po dru­gie wyce­na na bazie pro­jek­tu jest dale­ko mniej ryzy­kow­na niż wyce­na na bazie kon­cep­cji”, zresz­tą skut­ki wszy­scy obser­wu­je­my na ryn­ku. Ale wra­ca­my do tematu :).

Proces od analizy do projektu

Dwa pierw­sze (CIM i PIM) to pierw­sze eta­py pro­ce­su powsta­wa­nia opro­gra­mo­wa­nia: Analiza Biznesowa i jej pro­dukt oraz pro­jek­to­wa­nie roz­wią­za­nia i jego pro­dukt. Między nimi ma miej­sce okre­śle­nie zakre­su, któ­re­go pro­duk­tem jest model przy­pad­ków uży­cia (od 2015 roku w UML 2.5.x ten dia­gram jest mode­lem uzupełniającym) 

Analiza biznesowa

Zgodnie z zale­ce­nia­mi opra­co­wu­je­my model CIM czy­li two­rzy­my model tego jak dzia­ła biz­nes”. Produktem tego eta­pu są mode­le pro­ce­sów biz­ne­so­wych (raczej [[BPMN]] niż [[UML]]). Muszą się one jed­nak cecho­wać usta­lo­nym pozio­mem abs­trak­cji (nie powin­ny być zbyt szcze­gó­ło­we) i muszą uwzględ­niać roz­dział kom­pe­ten­cji pra­cow­ni­ków (ich nie kom­pu­te­ry­zu­je­my) od ich spe­cy­ficz­nych dla danej orga­ni­za­cji i pro­ce­su (te będą wspie­ra­ne przez nowe opro­gra­mo­wa­nie). Dobrą prak­ty­ką jest poprze­dza­nie tego eta­pu (uzu­peł­nie­nie go) o ana­li­zę i model archi­tek­tu­ry kor­po­ra­cyj­nej. To jest ostat­ni gwiz­dek na wpro­wa­dza­nie ewen­tu­al­nych ulep­szeń zarzą­dza­nia (rein­ży­nie­ria pro­ce­sów) w orga­ni­za­cji. Kolejny etap to

Opracowanie modelu przypadków użycia

Przypadki uży­cia, usłu­gi sys­te­mu dla użyt­kow­ni­ków, to celo­we inte­rak­cje użyt­kow­ni­ka z sys­te­mem. Ich cechą powin­na być kom­plet­ność, bo przy­pa­dek uży­cia to reali­za­cja kon­kret­ne­go celu biz­ne­so­we­go przez użyt­kow­ni­ka. Poprawnie opra­co­wa­ny taki model pozwa­la mapo­wać czyn­no­ści z mode­lu pro­ce­sów wprost na przy­pad­ki uży­cia (ale nie koniecz­nie jeden do jed­ne­go, przy­pad­ków uży­cia może być mniej, bo ta sama usłu­ga sys­te­mu może posłu­żyć do reali­za­cji kil­ku celów biz­ne­so­wych, np. utwo­rze­nia danych jak i ich pod­glą­du czy korek­ty, przy­kła­dem mogą być tak zwa­ne [[CRUD]]«y) (klik­nij tu by zoba­czyć to na przy­kła­dzie narzę­dzia jakie­go uży­wam).

Każda czyn­ność kan­dy­du­ją­ca na przy­pa­dek uży­cia powin­na być opi­sa­na sce­na­riu­szem jej reali­za­cji opi­su­ją­cym jak pla­nu­je­my tę usłu­gę zre­ali­zo­wać. Jest to tak zwa­ny dia­log użyt­kow­nik-sys­tem. Model przy­pad­ków uży­cia to tak­że defi­ni­cja zakre­su pro­jek­tu pro­gra­mi­stycz­ne­go (robi­my to i tyl­ko to).

Opracowanie modelu dziedziny

Specyfikacja usług sys­te­mu (przy­pad­ki uży­cia) to tak zwa­ne wyma­ga­nia funk­cjo­nal­ne. Jest to sta­now­czo za mało by cokol­wiek (w szcze­gól­no­ści opro­gra­mo­wa­nie) mogło powstać. Problem w tym, że samo stwier­dze­nie sys­tem ma wcią­gać śmie­ci” nijak się nie ma do kon­struk­cji urzą­dze­nia jakim jest odku­rzacz. Wymaganie poza­funk­cjo­nal­ne, że ma ich wcią­gać co naj­mniej 90%” tak­że nic nie mówi o tym co na praw­dę ma zostać wytwo­rzo­ne. Brakuje PROJEKTU.

Takim pro­jek­tem jest model dzie­dzi­ny, jed­nak nie jest to dia­gram klas na któ­rym poka­że­my, że np. ist­nie­je zwią­zek logicz­ny brud­ne­go dywa­nu z odku­rza­czem! bo to jest tyl­ko model poję­cio­wy (słow­nik pojęć). Model dzie­dzi­ny sys­te­mu to model dzie­dzi­no­wej logi­ki jaką nale­ży odwzo­ro­wać w opro­gra­mo­wa­niu. Owszem, jest to tak­że Diagram klas UML, ale zupeł­nie inny niż tak zwa­ny model kon­cep­tu­al­ny, któ­ry po pro­stu jest tyl­ko słow­ni­kiem (i czę­sto jest mylo­ny z mode­lem danych!).

Model dzie­dzi­ny sys­te­mu to sed­no ana­li­zy obiek­to­wej. To model całej logi­ki biz­ne­so­wej apli­ka­cji: kla­sy, ich ope­ra­cje i atry­bu­ty. Nie powi­nien to być na pew­no tak zwa­ny [[ane­micz­ny model dzie­dzi­ny]] a nie­ste­ty takie wła­śnie są one w więk­szo­ści pro­jek­tów jakie widuję.

Na tym eta­pie, mode­lo­wa­nie dzie­dzi­ny sys­te­mu, powsta­ją suche” kla­sy, bez metod i atry­bu­tów (tak, bez atry­bu­tów!). W pro­jek­tach zło­żo­nych sys­te­mów, powsta­nie mode­lu dzie­dzi­no­we­go powin­no być poprze­dzo­ne powsta­niem mode­lu kom­po­nen­tów (tak­że sto­sow­ny dia­gram UML), któ­ry jest pośred­nią war­stwą abs­trak­cji w takich pro­jek­tach. W takim przy­pad­ku począt­ko­wo ope­ru­je­my prak­tycz­nie tyl­ko na kla­sach abs­trak­cyj­nych i ich inter­fej­sach (są to inter­fej­sy tych komponentów).

Projektowanie realizacji czyli testowanie modelu dziedziny

Mając model dzie­dzi­ny, czy­li listę spe­cja­li­zo­wa­nych wyko­naw­ców” kon­kret­nych prac, może­my przy­stą­pić do testów sce­na­riu­szy przy­pad­ków uży­cia. Takim testem jest pró­ba zre­ali­zo­wa­nia sce­na­riu­sza przy­pad­ku uży­cia z pomo­cą obiek­tów mode­lu dzie­dzi­ny. Na tym eta­pie powsta­je dia­gram sekwen­cji (lub ste­ro­wa­nia inte­rak­cją, prze­pły­wu inte­rak­cji) dla każ­de­go przy­pad­ku uży­cia. Dobrą prak­ty­ką jest sto­so­wa­nie tu dia­gra­mów prze­pły­wu inte­rak­cji. Służą one do mode­lo­wa­nie nie­try­wial­nych przy­pad­ków uży­cia, prze­pły­wu sce­na­riu­szy alter­na­tyw­nych, ekra­nów itp.

W trak­cie two­rze­nia dia­gra­mu sekwen­cji pro­jek­to­wa­ne są ope­ra­cje klas (meto­dy to ich reali­za­cje). Diagram sekwen­cji opi­su­je dia­log pomię­dzy obiek­ta­mi pro­wa­dzą­cy do zre­ali­zo­wa­nia zada­nia, jakim jest cel przy­pad­ku uży­cia (jego stan koń­co­wy). Dialog taki to nic inne­go jak wywo­ła­nia ope­ra­cji obiek­tów przez inne obiek­ty (lub wła­snych). Po opra­co­wa­niu dia­gra­mu sekwen­cji obiek­ty, któ­re bra­ły w niej udział wzbo­ga­cą” się w pro­jek­cie o swo­je ope­ra­cje. Na tym eta­pie może się oka­zać, że pew­ne obiek­ty zmie­nia­ją swo­je sta­ny. Dla ich klas pro­jek­tu­je­my dia­gra­my maszy­ny sta­no­wej. Jeżeli oka­że się, że jakiś obiekt wyko­nu­je nie­try­wial­ne zada­nia (obli­cze­nio­we, zło­żo­ny pro­ces itp.), jego ope­ra­cję, któ­ra za to odpo­wia­da, doku­men­tu­je­my z pomo­cą np. dia­gra­mu czyn­no­ści – taki algo­rytm to Metoda danej Operacji. Za każ­dym razem spraw­dza­my zgod­ność z ocze­ki­wa­nia­mi użyt­kow­ni­ka i uzu­peł­nia­my kla­sy o nie­zbęd­ne atry­bu­ty, w szcze­gól­no­ści, jeże­li repre­zen­tu­ją one doku­men­ty czy formularze.

Projekt wykonany

Po wyko­na­niu powyż­sze­go, otrzy­ma­my kom­plet­ny model apli­ka­cji w nota­cji UML. Będzie to wła­śnie model PIM. Wszelkie nie­ja­sno­ści powin­ny zostać wyja­śnio­ne. Pozostaje reali­za­cja, model PSM, czy­li opa­ko­wa­nie pro­jek­tu tech­ni­ka­lia­mi” (w tym reali­za­cja wyma­gań poza­funk­cjo­na­lych) czy­li tym co dają nam np. fra­me­wor­ki MVC i podob­ne. Oczywiście nie jest to try­wial­ny pro­blem”, ale w takim pro­jek­cie deve­lo­per roz­wią­zu­je pro­ble­my jako­ści sys­te­mu a nie logi­ki biz­ne­so­wej sys­te­mu (podob­nie jak inży­nier budow­la­ny, któ­ry ma posta­wić moc­ny i bez­piecz­ny dom, bo jego funk­cjo­nal­ność to pro­blem miesz­kań­ca i zada­nie pro­jek­tan­ta architekta).

Poniżej pro­duk­ty takiej ana­li­zy i pro­jek­to­wa­nia w posta­ci dia­gra­mów (mode­li), pierw­szy to BPMN, pozo­sta­łe UML:

Aby zoba­czyć jak to zro­bić pakie­tem Agilian obej­rzyj Tutorial pakie­tu Visual-Paradigm Agilian

A teraz lektura Craig’a Larman’a

Larman w swo­jej książ­ce opi­su­je nie­mal­że iden­tycz­ne podej­ście (tabe­la poni­żej). Kluczową róż­ni­cą jest jed­nak źró­dło infor­ma­cji pier­wot­nej. U Larman’a jest to model przy­pad­ków uży­cia i ich sce­na­riu­sze. W porów­na­niu z mode­lem biz­ne­so­wym, pod­le­ga­ją­cym testo­wa­niu czy wali­da­cji, całe ryzy­ko pro­jek­tu spo­czy­wa na jako­ści mode­lu przy­pad­ków uży­cia. Jeżeli powsta­ły one jako efekt np. burzy mózgów, ankie­to­wa­nia pra­cow­ni­ków zama­wia­ją­ce­go czy tak zwa­nych sesji JAD ([[Joint Application Development]]), jest bar­dzo praw­do­po­dob­ne, że całe ryzy­ko złej jako­ści takie­go mode­lu (a jest ono bar­dzo duże jak poka­zu­je prak­ty­ka) zosta­nie prze­nie­sio­ne na projekt.

To jest wła­śnie pro­blem nazy­wa­ny użyt­kow­nik nie wie cze­go chce”. Po to się robi ana­li­zy biz­ne­so­we by w koń­cu wie­dział. Nie zmie­nia to fak­tu, że książ­kę Larman’a gorą­co pole­cam każ­de­mu pro­jek­tan­to­wi i pro­gra­mi­ście z ambi­cja­mi na meto­dy obiek­to­we i wzor­ce projektowe.

Larman’s UML Process

Use Cases
  • Define user inte­rac­tion with the system.
  • Underline nouns to iden­ti­fy con­cepts in the pro­blem domain.
Conceptual Model
  • Use the under­li­ned nouns from the use cases to cre­ate the con­cepts in the con­cep­tu­al model.
  • Some of the nouns, if they iden­ti­fy sim­ple data types, are used to cre­ate attri­bu­tes of the­se concepts.
  • Create asso­cia­tions betwe­en the concepts.
System Sequence Diagram
  • Create sys­tem sequ­en­ce dia­grams for each use case scenario.
  • Each sequ­en­ce event in the dia­gram cor­re­sponds to a user inte­rac­tion with the sys­tem spe­ci­fied by the expan­ded use case.
System Contracts
  • Specify post-con­di­tions for each sys­tem event in the sys­tem sequ­en­ce diagrams.
  • Use the con­cep­tu­al model to iden­ti­fy objects cre­ated, asso­cia­tions for­med, and attri­bu­tes modified.
Collaboration Diagram
  • Create a col­la­bo­ra­tion (or sequ­en­ce) dia­gram for each sys­tem event in the sys­tem sequ­en­ce diagrams.
  • Assign respon­si­bi­li­ties to clas­ses in the con­cep­tu­al model to ful­fill the post-con­di­tions in the contracts.
  • Use asso­cia­tions from the con­cep­tu­al model in con­junc­tion with pat­terns (Expert, Creator) to assign responsibilities.
Class Diagram
  • Add methods and addi­tio­nal attri­bu­tes which were disco­ve­red in the col­la­bo­ra­tion dia­grams to the clas­ses in the con­cep­tu­al model.
Code
  • Create clas­ses with the­ir names, attri­bu­tes and method signa­tu­res taken from the class diagram.
  • For each method on a class, use the col­la­bo­ra­tion dia­grams to find the sequ­en­ce of mes­sa­ges gene­ra­ted when the method is cal­led and cre­ate at least one line of code for each message.

(Based on Craig Larman’s Applying UML and Patterns -> Larman’s UML Process).

kon­wen­cje bar­dzo bli­ska powyż­szej (Larmana) opi­sa­no na stro­nach MSDN, tu wyciąg:

You can cre­ate seve­ral dif­fe­rent views of the users» requ­ire­ments. Each view pro­vi­des a par­ti­cu­lar type of infor­ma­tion. When you cre­ate the­se views, it is best to move fre­qu­en­tly from one to ano­ther. You can start from any view.

Diagram or document What it descri­bes in a requ­ire­ments model Section
Use case diagram Who uses the sys­tem and what they do with it. Describing how your sys­tem is used
Conceptual class diagram Glossary of types that are used to descri­be the requ­ire­ments; the types visi­ble at the sys­te­m’s interface. Defining terms used to descri­be requirements
Activity dia­gram Flow of work and infor­ma­tion betwe­en acti­vi­ties per­for­med by users and sys­tem or its parts. Showing work flow betwe­en users and your system
Sequence dia­gram Sequence of inte­rac­tions betwe­en users and sys­tem or its parts. An alter­na­ti­ve view to the acti­vi­ty diagram. Showing inte­rac­tions betwe­en users and your system
Additional docu­ments or work items Performance, secu­ri­ty, usa­bi­li­ty and relia­bi­li­ty criteria. Describing quali­ty of servi­ce requirements
Additional docu­ments or work items Constraints and rules not spe­ci­fic to a par­ti­cu­lar use case Showing busi­ness rules

Notice that most of the dia­gram types can be used for other pur­po­ses. For an ove­rview of dia­gram types, see Developing Models for Software Design. For basic infor­ma­tion abo­ut dra­wing dia­grams, seeHow to: Edit UML Models and Diagrams.

Na zakończenie

Powyżej opi­sa­ny pro­ces w cało­ści moż­na prze­ćwi­czyć wraz z pozna­niem wyma­ga­nych dia­gra­mów UML na warsz­ta­tach, któ­re pro­wa­dzę.

Serdecznie zapra­szam.

Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]

Wymagania biznesowe – jak zbierać i dokumentować

Wprowadzenie

Ronald Ross, współ­au­tor stan­dar­du mode­lo­wa­nia reguł biz­ne­so­wych i biz­ne­so­we­go słow­ni­ka pojęć napi­sał nie­daw­no na swo­im pro­fi­lu LinkedIn:

People love sto­ries. Are user sto­ries help­ful in engi­ne­ering busi­ness solu­tions? Absolutely. Are you done with requ­ire­ments and solu­tion engi­ne­ering when you’ve wor­ked thro­ugh a set of user sto­ries? No. Not even clo­se!” [„Ludzie kocha­ją histo­rie. Czy histo­rie użyt­kow­ni­ków są pomoc­ne w two­rze­niu roz­wią­zań biz­ne­so­wych? Zdecydowanie tak. Czy skoń­czy­łeś z wyma­ga­nia­mi i inży­nie­rią roz­wią­za­nia, gdy już opra­co­wa­łeś zestaw histo­ry­jek użyt­kow­ni­ka? Nie. Nawet nie zbli­ży­łeś się do nich!”.]

(https://​www​.lin​ke​din​.com/​p​o​s​t​s​/​r​o​s​s​r​o​n​a​l​d​_​p​e​o​p​l​e​-​l​o​v​e​-​s​t​o​r​i​e​s​-​a​r​e​-​u​s​e​r​-​s​t​o​r​i​e​s​-​h​e​l​p​f​u​l​-​a​c​t​i​v​i​t​y​-​6​9​3​5​6​2​7​0​0​8​2​6​5​6​3​3​7​9​3​-​B​p​zb/)

Świat od dekad bory­ka się z jako­ścią i sku­tecz­no­ścią spe­cy­fi­ko­wa­nia wyma­gań na opro­gra­mo­wa­nie. OMG​.org opu­bli­ko­wa­ło stan­dard o nazwie MDA (ang. Model Driven Architecture ), któ­ry tak opi­su­je pro­ces two­rze­nia oprogramowania:

CIM -> PIM -> PSM

Są to odpo­wied­nio mode­le: Model Biznesowy (CIM: Computation Independent Model), Model Mechanizmu dzia­ła­nia (PIM: Platform-Independent Model, jest to model dzie­dzi­ny sys­te­mu wg. MVC) oraz Model Implementacji (PSM: Platform-Specific Model). Swego cza­su sze­rzej opi­sa­łem zależ­no­ści mię­dzy tymi mode­la­mi (czy­taj wię­cej o MDA).

CIM to model dzia­ła­nia orga­ni­za­cji: pro­ce­sy biz­ne­so­we i ich pro­duk­ty. Z uwa­gi na to, że obec­nie już nie rodzą się pro­jek­ty jed­no­ra­zo­wej infor­ma­ty­za­cji cało­ści orga­ni­za­cji, poja­wia się potrze­ba okre­śle­nia zakre­su pro­jek­tu, bo nie jest już nim cała orga­ni­za­cja. Model PIM to udo­ku­men­to­wa­ny mecha­nizm dzia­ła­nia sys­te­mu (opro­gra­mo­wa­nia), logi­ka jego dzia­ła­nia. Nie ma tu mowy o tym w jakiej tech­no­lo­gii powsta­nie, bo z zasa­dy mamy ich wie­le do wybo­ru, a wybór tech­no­lo­gii zale­ży od wie­lu poza-funk­cjo­nal­nych ogra­ni­czeń i wyma­gań. Technologia jest (powin­na być) kon­se­kwen­cją wybo­ru wyko­naw­cy i ten dopie­ro opra­cu­je model PSM, któ­ry w prak­ty­ce jest tak zwa­ną Koncepcją Wdrożenia, moż­na ją tak­że udo­ku­men­to­wać w nota­cji UML, ale na tym eta­pie powszech­na prak­ty­ką jest jedy­nie zapro­jek­to­wa­nie śro­do­wi­ska, zesta­wie­nie go i pra­ca od razu w kodzie.

Kluczowym pro­ble­mem jest przej­ście z CIM na PIM, czy­li jak udo­ku­men­to­wać zakres pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia i prze­kształ­cić go na wyma­ga­nia wobec tego oprogramowania?

CIM -> [zakres pro­jek­tu] -> PIM -> PSM

W meto­dach zwa­nych zwin­ny­mi, mode­le CIM i PIM są pomi­ja­ne. Typowym zaś narzę­dziem zbie­ra­nia wyma­gań” są tak zwa­ne histo­ryj­ki użyt­kow­ni­ka (user sto­ry). Problem w tym, że są one klu­czo­wym ryzy­kiem pro­jek­tów gdyż z regu­ły są nie­spój­ne i nie­kom­plet­ne jako wyma­ga­nia. Specyfikacja wyma­gań powin­na być: spój­na, kom­plet­na i nie­sprzecz­na. Opisanie zakre­su pro­jek­tu histo­ryj­ka­mi użyt­kow­ni­ka, nie mając mode­lu pro­ce­sów biz­ne­so­wych cało­ści (model CIM), jest pozba­wie­niem się narzę­dzia do wery­fi­ka­cji kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści takiej spe­cy­fi­ka­cji. Wszystkie wady (nie­kom­plet­ność, nie­spój­ność, sprzecz­no­ści) odkry­wa­ne są i usu­wa­ne (uzu­peł­nia­ne) dopie­ro na eta­pie wdra­ża­nia. Jest to pro­ces odkry­wa­nia wyma­gań w toku wdrożenia”. 

Historyjki użyt­kow­ni­ka jako lista potrzeb biz­ne­so­wych? Owszem! Historyjki użyt­kow­ni­ka jako wyma­ga­nia dla deve­lo­pe­ra? NIE! To tyl­ko mate­riał dla pro­jek­tan­ta, ponie­waż bar­dzo czę­sto jed­na i ta sama funk­cja sys­te­mu reali­zu­je wie­le róż­nych histo­rii użyt­kow­ni­ka. Implementacja per user sto­ry” pro­wa­dzi do bar­dzo kosz­tow­nych i nie­efek­tyw­nych roz­wią­zań (Opisywałem to na blo­gu: wpis pro­jekt Biblioteka, dwie histo­ryj­ki użyt­kow­ni­ka: chciał­bym wypo­ży­czyć książ­kę oraz chciał­bym zwró­cić książ­kę są reali­zo­wa­ne jed­ną usłu­gą apli­ka­cji: Karta Wypożyczenia, któ­ra zawie­ra rów­nież pole Data zwro­tu. Nadal spo­ty­kam pro­gra­mi­stów prze­ko­nu­ją­cych, że powin­ny to być dwa osob­ne ekra­ny – dwa przy­pad­ki uży­cia, czy­taj dwa razy wię­cej pra­cy kode­ra i dwa razy więk­szy koszt).

Czy można sformalizować proces zbierania historyjek użytkownika?

User Story to jed­no z naj­bar­dziej pro­ble­ma­tycz­nych narzę­dzi w meto­dach zwin­nych. Najczęściej zale­ca­na struk­tu­ra tych histo­ry­jek”, wraz z przykładami:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Na przy­kład:

Jako Administrator chcę otrzy­my­wać wia­do­mość e‑mail, gdy zosta­nie prze­sła­ny for­mu­larz kon­tak­to­wy, abym mógł na nie­go odpowiedzieć”

albo

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”;

Tak spi­sy­wa­ne wyma­ga­nia sta­no­wią ogrom­ny pro­blem z powo­du nie­rów­nej gra­da­cji, spro­wa­dza­nie ich do pozio­mu tak zwa­nych ato­mo­wych user sto­ry (dru­gi z powyż­szych przy­kła­dów) pro­wa­dzi do bar­dzo dużych liczb tych histo­ry­jek. Próba ich wery­fi­ka­cji (wali­da­cja user sto­ry) sta­je się co naj­mniej trud­nym zada­niem. Jakakolwiek wyce­na opro­gra­mo­wa­nia na bazie takich histo­ry­jek to wró­że­nie z fusów (więc deve­lo­pe­rzy moc­no zawy­ża­ją wyce­ny z uwa­gi na ryzy­ko utra­ty ren­tow­no­ści). Autorzy inne­go opra­co­wa­nia zauważają:

Rzeczywiście, przy oko­ło 800 US [User Story], hie­rar­chia była raczej trud­na do okre­śle­nia, a obraz sys­te­mu pod­czas pla­no­wa­nia był bar­dzo duży. Skalowalność jest więc zde­cy­do­wa­nie pro­ble­mem w pro­jek­tach zwin­nych, w któ­rych US są sła­by­mi arte­fak­ta­mi inży­nie­rii wyma­gań. Zdecydował się on [autor] na wpro­wa­dze­nie wzor­ca US: Jako [Użytkownik], chcę [Zadanie], aby [Cel]”, aby zde­fi­nio­wać hie­rar­chię w posta­ci Celu, Zadania i Użytkownika, ale bez powią­za­nia semantycznego.

Znam pro­jekt, w któ­rym licz­ba przy­pad­ków uży­cia, w pew­nym śred­niej tyl­ko wiel­ko­ści pro­jek­cie, szyb­ko się­gnę­ła czte­ry­stu. Wycena na ich pod­sta­wie poka­za­ła, że pla­no­wa­ny koszt wie­lo­krot­nie prze­kra­cza pla­no­wa­ny budżet. Ten pro­jekt zarzu­co­no, jed­nak wie­le tak wyce­nio­nych pro­jek­tów jest reali­zo­wa­nych, co daje obraz ska­li strat jakie przy­no­szą (zawy­żo­ny koszt to stra­ta). Powyżsi auto­rzy piszą na zakończenie:

Przyszłe pra­ce obej­mu­ją iden­ty­fi­ka­cję luk repre­zen­ta­cyj­nych, któ­re napo­ty­ka­ją prak­ty­cy w mode­lo­wa­niu US, oraz prze­gląd spo­so­bów, w jakie nasze ramy i [meto­da] GORE w ogó­le mogły­by roz­wią­zać te pro­ble­my. Równolegle oce­nia­na będzie rów­nież zdol­ność prak­ty­ków do sto­so­wa­nia pro­po­no­wa­nych ram zamiast zwy­kłych sza­blo­nów. Obecnie trwa­ją pra­ce nad narzę­dziem CASE (Computer Aided Software Engineering), któ­re zosta­nie wyko­rzy­sta­ne do wspar­cia eksperymentów.

Nie zna­la­złem wyni­ków dal­szych prac, więc podzie­lę się wyni­ka­mi swoich.

Gradacja User Story

Podstawowym pro­ble­mem z user sto­ry jest, moim zda­niem, brak stan­dar­du pozwa­la­ją­ce­go na zde­fi­nio­wa­nie ato­mo­wej histo­ryj­ki użyt­kow­ni­ka” czy­li pozio­mu, poni­żej któ­re­go nie dzie­li­my ich na mniej­sze. Jako audy­tor wie­lu doku­men­ta­cji (czę­sto w roli bie­głe­go) zauwa­ży­łem, że histo­ryj­ki użyt­kow­ni­ka są dopro­wa­dza­ne do pozio­mu poje­dyn­czych kro­ków sce­na­riu­szy przy­pad­ków uży­cia. Często też histo­ryj­ki użyt­kow­ni­ka utoż­sa­mia­ne są z przy­pad­ka­mi uży­cia (UML) i tak mode­lo­wa­ne, co jest poważ­nym błę­dem. Np. powyższe: 

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”

Mogło by to być czę­ścią sce­na­riu­sza usłu­gi (przy­pa­dek uży­cia UML), któ­rej celem jest Pokazanie Określonego Miejsca:

  1. AKTOR ini­cju­je usłu­gę Cel podróży
  2. SYSTEM wyświe­tla for­mu­larz Adres
  3. AKTOR wpro­wa­dza dane i naci­ska OK
  4. SYSTEM wyświe­tla mapę z nanie­sio­ną lokalizacją
  5. AKTOR kli­ka okre­ślo­ny punkt na mapie 
  6. SYSTEM powięk­sza obraz poka­zu­jąc deta­le lokalizacji

Powyższa histo­ryj­ka to jedy­nie punkt 5. tego sce­na­riu­sza. Nie trud­no dojść do wnio­sku, że samo klik­nię­cie na mapie to pozba­wio­na kon­tek­stu i celu, wyrwa­na pro­sta czyn­ność, i jej samo­dziel­ne ist­nie­nie w spe­cy­fi­ka­cji jako osob­ny byt, pozba­wio­ne jest sen­su. Z per­spek­ty­wy opro­gra­mo­wa­nia powsta­ją­ce­go w okre­ślo­nym celu, uzna­nie tej histo­ryj­ki za samo­dziel­ne wyma­ga­nie nie ma uza­sad­nie­nia. Uznanie jed­nak, że apli­ka­cja słu­ży mię­dzy inny­mi do zapo­zna­wa­nia się okre­ślo­ny­mi miej­sca­mi w prze­strze­ni, a usłu­gą tej apli­ka­cji jest Pokazanie Określonego Miejsca jak naj­bar­dziej ma sens. Idąc za suge­stią by histo­ryj­ka użyt­kow­ni­ka mia­ła strukturę: 

Jako [Użytkownik], chcę [Zadanie], aby [Cel]”

zmu­sza do zasta­no­wie­nia się czy kli­ka­nie na mapie jest celem, czy może jed­nak tym celem jest Pokazanie Określonego Miejsca, a kli­ka­nie jest ele­men­tem sce­na­riu­sza (pro­ce­du­ry) reali­za­cji tego celu (pamię­ta­my, że przy­pad­ki uży­cia mają sce­na­riu­sze, a te zło­żo­ne są z sekwen­cji kolej­nych kroków!).

Formalizacja User Story

Pojęcia Użytkownik, Zadanie, Cel, jako spój­ny zestaw pojęć odpo­wia­da­ją defi­ni­cji ato­mo­we­go (ele­men­tar­ne­go) pro­ce­su w nota­cji BPMN (doda­tek C, Słownik , ): Aktywność jest sko­ja­rzo­na z jej wyko­naw­cą (pula, tor), two­rzy pro­dukt (data object). Biorąc pod uwa­gę fakt, że pro­dukt ma tu okre­ślo­ne­go adre­sa­ta i musi on sta­no­wić sobą war­tość dla tego adre­sa­ta, mamy punkt wyzna­cza­ją­cy gra­ni­cę dzie­le­nia na czę­ści” tych histo­ry­jek. Nie będzie to moż­li­wość wsta­wie­nia z listy nume­ru NIP nabyw­cy” a utwo­rze­nie fak­tu­ry” (bo war­tość ma dopie­ro popraw­nie wysta­wio­na fak­tu­ra, a nie klik­nię­cie np. w pole NIP by wybrać kontrahenta). 

Jak sfor­ma­li­zo­wać histo­ryj­kę użyt­kow­ni­ka? Podstawą for­ma­li­za­cji (i celem) jest opra­co­wa­nie meto­dy kon­tro­li popraw­no­ści (wali­da­cja). Popatrzmy jesz­cze raz na szablon:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Typ użyt­kow­ni­ka to rola, celem jest pro­dukt pra­cy, a powo­dem? Powodem jest zawsze to, że okre­ślo­na oso­ba ocze­ku­je na efekt tej pra­cy (bez tego pra­ca ta była­by po pro­stu zbęd­na). Można więc wyobra­zić sobie taki zapis:

Jako sprze­daw­ca, chcę wysta­wić fak­tu­rę, klientowi. 

Mamy tu:

  1. rola: sprze­daw­ca
  2. cel: fak­tu­ra
  3. powód: ocze­ku­je tego klient. 

W tym miej­scu widać peł­ną zgod­ność tej defi­ni­cji z kon­struk­cją: aktyw­ność, jej pro­dukt, jego odbior­ca. Innymi sło­wy ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych wyko­na­ny w nota­cji BPMN, to nic inne­go jak połą­czo­ne w logicz­ne cią­gi histo­ryj­ki użytkownika. 

Wyobraźmy sobie taką listę histo­ry­jek użyt­kow­ni­ka, wyko­na­ną wg. powyż­sze­go opisu:

Specyfikacja histo­ry­jek użytkownika

Niektóre narzę­dzia CASE, pozwa­la­ją­ce na ich pro­fi­lo­wa­nie, pozwa­la­ją przed­sta­wić to tak­że na mode­lu wyma­gań (co póź­niej umoż­li­wia śla­do­wa­nie, czy­li kon­tro­lę kom­plet­no­ści, spój­no­ści i niesprzeczności):

Diagram wyma­gań (nota­cja SysML)

Powyższe mogło­by być kon­se­kwen­cją takie­go mode­lu procesów:

Diagram pro­ce­su reali­za­cji zamó­wie­nia (nota­cja BPMN).

Jak widać, model pro­ce­su daje peł­ny kon­tekst dla aktyw­no­ści. Fakt, że pro­ces to logicz­ny prze­pływ pra­cy, powo­du­je, że two­rze­nie mode­li BPMN gwa­ran­tu­je spój­ność, kom­plet­ność i nie­sprzecz­ność listy aktyw­no­ści, ich pro­duk­tów i ról. 

Podsumowanie

Stosowanie typo­wych histo­ry­jek użyt­kow­ni­ka ma dwie klu­czo­we wady: 1. nie ma jed­nej meto­dy zarzą­dza­nia ich gra­da­cją i struk­tu­rą, wie­lu auto­rów przy­wo­łu­je wła­sne, nie­co się róż­nią­ce meto­dy stan­da­ry­za­cji, 2. ich dro­bia­zgo­wość oraz brak meto­dy kon­tro­li spój­no­ści, pro­wa­dzą do szyb­ko rosną­cej ich licz­by, w kon­se­kwen­cji cha­osu, szcze­gól­nie w śred­nich i więk­szych projektach.

Powyżej widać, że mode­lo­wa­nie pro­ce­sów biz­ne­so­wych na pod­sta­wie zebra­nych przy­kła­do­wych doku­men­tów (pro­duk­ty pra­cy ludzi: doku­men­ty) i opra­co­wa­nie na ich pod­sta­wie dia­gra­mu przy­pad­ków uży­cia, daje znacz­nie lep­sze wyni­ki niż zbie­ra­ne na warsz­ta­tach histo­ryj­ki użyt­kow­ni­ka. Same wyma­ga­nia wyra­żo­ne jako histo­ryj­ki użyt­kow­ni­ka, nie dają żad­nej szan­sy (brak meto­dy) na kon­tro­lę ich spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści. Wymagania, jako kon­se­kwen­cja popraw­nie wyko­na­nych mode­li pro­ce­sów biz­ne­so­wych, z zasa­dy są spój­ne, kom­plet­ne i niesprzeczne.

W przy­to­czo­nym tu przy­kła­dzie widać, że dwie aktyw­no­ści (reje­stra­cja zamó­wie­nia i kon­tro­la jego sta­tu­su) reali­zo­wa­ne są jako dostęp do zapi­sa­ne­go w sys­te­mie Zamówienia. Daje to jasną prze­słan­kę do tego, że dwie histo­ryj­ki użyt­kow­ni­ka (dwie aktyw­no­ści na mode­lu pro­ce­sów) to dwa róż­ne kon­tek­sty uży­cia tej samej usłu­gi apli­ka­cji: Zamówienia (czy­li dostęp do ich two­rze­nia, aktu­ali­za­cji i pod­glą­du, to typo­wy przy­pa­dek uży­cia typu CRUD). Prawa dostę­pu do tego doku­men­tu mode­lu­je się zaś regu­ła­mi biz­ne­so­wy­mi (nie poka­za­no ich na dia­gra­mach), np. Klient ma wgląd tyl­ko w Zamówienia, któ­re sam złożył”. 

Można uznać, że małe pro­jek­ty, o małym ryzy­ku cha­osu wywo­ła­ne­go bra­kiem mode­li pro­ce­sów, moż­na reali­zo­wac na skró­ty” czy­li histo­ryj­ki użyt­kow­ni­ka i od razu model PSM (imple­men­ta­cja) z pomi­nię­ciem CIM i PIM, jed­nak jest to poważ­ne ryzy­ko już przy śred­nich pro­jek­tach. Dlatego pro­ces MDA:

{CIM -> [zakres pro­jek­tu] -> PIM} -> PSM

wyda­je się być znacz­nie efek­tyw­niej­szy co poka­zu­je prak­ty­ka (w nawia­sach klam­ro­wych {} zakres pra­cy analityka-projektanta).

Zakres pro­jek­tu to albo całe pro­ce­sy biz­ne­so­we albo świa­do­mie wybra­ne ich okre­ślo­ne aktyw­no­ści. Nie jest to tak­że żaden wodo­spad” (water­fall), bo ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych powsta­nie szyb­ciej i taniej niż lista setek histo­ry­jek z pomo­cą wie­lo­dnio­wych warsz­ta­tów anga­żu­ją­cych całe zespo­ły ludzi. Wygenerowane z mode­lu pro­ce­sów biz­ne­so­wych przy­pad­ki uży­cia, są z zasa­dy spój­ne i kom­plet­ne, więc ich ite­ra­cyj­ne (kolej­ne) spe­cy­fi­ko­wa­nie (każ­dy pro­jek­tu­je­my jako samo­dziel­ny mikro­ser­wis) pozwa­la bez ryzy­ka odda­wać je kolej­no do imple­men­ta­cji, i jed­no­cze­śnie doku­men­to­wać (uszcze­gó­ła­wiać) kolejne. 

To spraw­dzo­na w prak­ty­ce meto­da wspie­ra­na przez wie­le narzę­dzi CASE (wszyst­kie dia­gra­my i ich prze­kształ­ce­nia poka­za­ne w tym arty­ku­le powsta­ły z uży­ciem Visual-Paradigm). Diagram przy­pad­ków uży­cia UML jest tu auto­ma­tycz­nie gene­ro­wa­ny z mode­li BPMN, wg poniż­szych zasad:

BPMNtoUseCase (źr. http://​www​.visu​al​-para​digm​.com/​t​u​t​o​r​i​a​l​s​/​f​r​o​m​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​t​o​-​u​s​e​-​c​a​s​e​s​.​jsp)

Po tej ope­ra­cji wystar­czy spraw­dzić kon­tek­sty doku­men­tow i skon­so­li­do­wać w jeden ewen­tu­al­ne nad­mia­ro­we przy­pad­ki uży­cia. I na koniec:

Jeśli nie masz mode­li poję­cio­wych, bra­ku­je Ci waż­ne­go ele­men­tu ukła­dan­ki w pro­jek­to­wa­niu roz­wią­zań, któ­ry jest nie­zwy­kle pomoc­ny w dostrze­ga­niu i prze­ka­zy­wa­niu ogól­ne­go obra­zu tych historyjek.”

Ronald Ross (Business Rules)

Źródła

Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., & Brinkkemper, S. (2016). Improving agi­le requ­ire­ments: the Quality User Story fra­me­work and tool. Requirements Engineering, 21(3), 383 – 403. https://doi.org/10.1007/s00766-016‑0250‑x
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
OMG​.org. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). 334. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/
Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
Ross, R. G., & Fisher, L. (2020). Business Rules: Management and Execution.
Wautelet, Y., Heng, S., Kolp, M., & Mirbel, I. (2014). Unifying and Extending User Story Models. In M. Jarke, J. Mylopoulos, C. Quix, C. Rolland, Y. Manolopoulos, H. Mouratidis, & J. Horkoff (Eds.), Advanced Information Systems Engineering (Vol. 8484, pp. 211 – 225). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 07881-6_15
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 (pp. 78 – 89). IGI Global. 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

Pełna Specyfikacja

Poniżej przy­kła­do­wy doku­ment wyge­ne­ro­wa­ny bez­po­śred­nio z Visual Paradigm, zawie­ra tak­że śladowanie. 

1. Procesy Business Process Diagram

Procesy Business Process Diagram

2. User Story

Historyjki użyt­kow­ni­ka jako wyma­ga­nia biznesowe.

ID

Nazwa

Rola

Produkt

Adresat

Opis

REQ001

Sprzedaż

Sprzedawca

Faktura

Klient

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

REQ002

Wydanie towa­ru

Magazynier

Dokument WZ

Klient

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

REQ003

Rejestracja Zamówień

Pracownik BOK

Zamówienie zaku­pu

Sprzedawca

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

REQ004

Śledzenie Zamówień

Klient

Zamówienie zaku­pu

Klient

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

3. Diagram Przypadków Użycia

Diagram Przypadków Użycia

4. Specyfikacja

 

Nazwa

ID

 

Główni akto­rzy 

Pula zadań

!!

Sprzedaż

UC02

Sprzedawca

Magazyny

UC03

Magazynier

Zamówienia

UC01

Klient, Pracownik BOK

4.1. Sprzedaż

ID: UC02

Usługa pozwa­la wysta­wiać faktury.

4.1.1. Główni aktorzy 

Sprzedawca

4.1.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Sprzedaż będzie doku­men­to­wa­na fak­tu­ra­mi w reje­strze sprzedaży

4.1.3. Wymagania 

4.1.3.1. Sprzedaż

ID: REQ001

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

4.1.4. Relacje

Relacja

Z

Do

unnamed

Sprzedawca

Sprzedaż

4.1.5. Diagramy Podległe 

4.1.5.1. Faktura

Faktura

4.1.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Sprzedaż

4.2. Magazyny

ID: UC03

Usługa doku­men­tu­je wyda­wa­nie towa­ru na pod­sta­wie opła­co­nych faktur.

4.2.1. Główni aktorzy 

Magazynier

4.2.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Operacje maga­zy­no­we doku­men­to­wa­ne są stan­dar­do­wy­mi doku­men­ta­mi księgowymi

4.2.3. Wymagania 

4.2.3.1. Wydanie towaru

ID: REQ002

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

4.2.4. Relacje

Relacja

Z

Do

unnamed

Magazynier

Magazyny

4.2.5. Diagramy Podległe 

4.2.5.1. Dokument WZ

Dokument WZ

4.2.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Wydanie z magazynu

4.3. Zamówienia

ID: UC01

Rejestr zamó­wień pozwa­la reje­stro­wać zamó­wie­nia, śle­dzić ich status.

4.3.1. Główni aktorzy 

Klient,  Pracownik BOK

4.3.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Zamówienia od klien­tów są reje­stro­wa­ne jako Zamówienia zaku­pu w Rejestrze zamówień

4.3.3. Wymagania 

4.3.3.1. Rejestracja Zamówień

ID: REQ003

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

4.3.3.2. Śledzenie Zamówień

ID: REQ004

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

4.3.4. Relacje

Relacja

Z

Do

unnamed

Pracownik BOK

Zamówienia

unnamed

Klient

Zamówienia

4.3.5. Diagramy Podległe 

4.3.5.1. Zamówienia Zakupu

Zamówienia Zakupu

4.3.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Rejestracja zamó­wie­nia