Tag: SOA

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

1 komentarz

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

Transformacja modelu procesów biznesowych na model przypadków użycia

10 komentarzy

Ukazują się róż­ne opra­co­wa­nia na temat tytu­ło­wej trans­for­ma­cji. Jednym z takich opra­co­wań jest tekst Transformacja Modeli Pana Piotra Carewicza z fir­my 300 D&C, opu­bli­ko­wa­ny w perio­dy­ku Analiza Biznesowa Lato 2015 fir­mo­wa­nym przez Warszawski oddział IIBA. Pozwolę sobie na pew­ną pole­mi­kę z przed­sta­wio­nym tam pro­ce­sem trans­for­ma­cji mode­lu pro­ce­sów biz­ne­so­wych BPMN na Przypadki Użycia nota­cji UML. Autor powo­łu­je się na OMG​.org i spe­cy­fi­ka­cje BPMN i UML. Dlatego dla porząd­ku przy­to­czę klu­czo­we definicje.

10.3 Activities
An Activity is work that is per­for­med within a Business Process. An Activity can be ato­mic or non-ato­mic
(com­po­und). The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, which
allows the inc­lu­sion of re-usa­ble Tasks and Processes in the dia­gram. However, a Process is not a spe­ci­fic gra­phi­cal
object. Instead, it is a set of gra­phi­cal objects. The fol­lo­wing sub clau­ses will focus on the gra­phi­cal objects SubProcess
and Task. Activities repre­sent points in a Process flow whe­re work is per­for­med. They are the exe­cu­ta­ble ele­ments of a BPMN Process. (źr. BPMN for­mal 13 – 12-09)

Aktywność to ele­ment w pro­ce­sie repre­zen­tu­ją­cy wyko­na­ną okre­ślo­ną pra­cę. Atomowa (ele­men­tar­na) aktyw­ność to czyn­ność w pro­ce­sie, któ­rej nie dzie­li­my już na mniej­sze ele­men­ty składowe.

18.1.3.1 Use Cases and Actors
A UseCase may apply to any num­ber of sub­jects. When a UseCase applies to a sub­ject, it spe­ci­fies a set of beha­viors
per­for­med by that sub­ject, which yields an obse­rva­ble result that is of value for Actors or other sta­ke­hol­ders of the sub­ject.
A UseCase is a kind of BehavioredClassifier that repre­sents a dec­la­ra­tion of a set of offe­red Behaviors. Each UseCase
spe­ci­fies some beha­vior that a sub­ject can per­form in col­la­bo­ra­tion with one or more Actors. UseCases defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal struc­tu­re. These Behaviors, invo­lving inte­rac­tions betwe­en the Actors and the sub­ject, may result in chan­ges to the sta­te of the sub­ject and com­mu­ni­ca­tions with its envi­ron­ment. A UseCase can inc­lu­de possi­ble varia­tions of its basic beha­vior, inc­lu­ding excep­tio­nal beha­vior and error han­dling. (źr. UML 2.5 for­mal 13 – 12-09)

Przypadek uży­cia jest więc kon­kret­nym zacho­wa­niem sys­te­mu (sub­ject) dają­cym jako efekt war­to­ścio­wy (ocze­ki­wa­ny) rezul­tat dla aktora.

Transformacja wg. OMG

Dla doko­na­nia jakiej­kol­wiek trans­for­ma­cji, nale­ży przy­jąć kon­kret­ną prag­ma­ty­kę (kon­tekst) gdyż obie nota­cje (UML i BPMN) dają pew­ną swo­bo­dę jej uży­cia (jak widać powyż­sze defi­ni­cje dają pewien mar­gi­nes swo­bo­dy uży­cia tych sym­bo­li). Z pomo­cą może przyjść nam biz­ne­so­wa defi­ni­cja pro­ce­su biz­ne­so­we­go: aktyw­ność prze­kształ­ca­ją­ca stan wej­ścia w stan wyj­ścia pro­ce­su, two­rzą­ca war­to­ścio­wy pro­dukt dla akto­ra (roli w pro­ce­sie). Taka aktyw­ność jest reali­zo­wa­na (może być) zgod­nie z jakąś pro­ce­du­rą. Przypadki uży­cia są ogra­ni­cza­ne ich sta­nem począt­ko­wym i koń­co­wym, mają akto­ra, mają jeden lub wię­cej alter­na­tyw­nych sce­na­riu­szy. Warto tu zwró­cić uwa­gę, że stan począt­ko­wy i koń­co­wy przy­pad­ku uży­cia oraz wej­ście i wyj­ście ele­men­tar­ne­go pro­ce­su biz­ne­so­we­go, to ana­lo­gicz­ne – odpo­wia­da­ją­ce sobie – poję­cia. Pojęcie ​„ato­mo­wy” (w lite­ra­tu­rze spo­ty­ka­ne sło­wo to tak­że ​„ele­men­tar­ny”) oznacza:

ele­men­tar­ny pro­ces biz­ne­so­wy: zada­nie wyko­ny­wa­ne przez jed­na oso­bę, w jed­nym miej­scu i okre­ślo­nym cza­sie, w odpo­wie­dzi na okre­ślo­ne zda­rze­nie biz­ne­so­we; zada­nie to pro­wa­dzi do uzy­ska­nia mie­rzal­nej war­to­ści biz­ne­so­wej; po jego wyko­na­niu dane są w spój­nym sta­nie; (przy­pad­ki uży­cia powin­ny reali­zo­wać ele­men­tar­ne pro­ce­sy biz­ne­so­we, cytat z: UML i wzor­ce pro­jek­to­we, Craig Larman)

Kluczowym wyma­ga­niem dla trans­for­ma­cji jest zde­fi­nio­wa­nie poję­cia, któ­re będzie łącz­ni­kiem (będzie trans­for­mo­wa­ne z ​„cze­goś” na ​„coś”, będzie wspól­nym ele­men­tem w obu mode­lach) pomię­dzy mode­lem pro­ce­sów biz­ne­so­wych a mode­lem przy­pad­ków uży­cia. Tu z pomo­cą przy­cho­dzi archi­tek­tu­ra SOA. SOA to wzo­rzec łączą­cy model pro­ce­sów biz­ne­so­wych z modem aplikacji:

SOA_OMG_model

Generalnie kon­cep­cja SOA bazu­je na uzna­niu, że ​„ato­mo­we” pro­ce­sy biz­ne­so­we są wspo­ma­ga­ne (sup­port) poje­dyn­czy­mi usłu­ga­mi apli­ka­cyj­ny­mi. Tu zno­wu powo­ła­my się na OMG​.org i spe­cy­fi­ka­cję pro­fi­lu UML jakim jest SoaML:

6.1.5 Key Concepts of Basic Services
A key con­cept is, of cour­se, servi­ce. Service is defi­ned as the deli­ve­ry of value to ano­ther par­ty, ena­bled by one or more capa­bi­li­ties. Here, the access to the servi­ce is pro­vi­ded using a pre­scri­bed con­tract and is exer­ci­sed con­si­stent with con­stra­ints and poli­cies as spe­ci­fied by the servi­ce con­tract. A servi­ce is pro­vi­ded by a par­ti­ci­pant acting as the pro­vi­der of the servi­ce-for use by others.

6.2.6 Business Motivation […] There are other ways of cap­tu­ring requ­ire­ments inc­lu­ding use cases. A Service Contract, which is also a clas­si­fier, can reali­ze UseCases. In this case, the actors in the use case may also be used to type roles in the servi­ce con­tract, or the actors may reali­ze the same Interfaces used to type the roles. (źr. OMG SoaML, for­mal-12 – 05-10)

Tak wiec mamy prze­ło­że­nie: ato­mo­wy pro­ces w BPMN, aktyw­ność któ­ra wraz z jej wej­ściem i wyj­ściem, jest przy­po­rząd­ko­wy­wa­na do poje­dyn­czej usłu­gi apli­ka­cyj­nej repre­zen­to­wa­nej w UML jako przy­pa­dek uży­cia, któ­ry ma swój stan począt­ko­wy i koń­co­wy. Zarówno ato­mo­wy pro­ces jak i przy­pa­dek uży­cia nie są już dzie­lo­ne na mniej­sze ele­men­ty, bo ​„gra­da­cję” podzia­łu ​„w dół” ogra­ni­cza to, że w toku spój­nej pra­cy jed­ne­go czło­wie­ka (aktor) ma powstać war­to­ścio­wy dla akto­ra rezul­tat (pro­dukt). Innymi sło­wy ato­mo­wym pro­ce­sem i zara­zem przy­pad­kiem uży­cia, będzie np. utwo­rze­nie fak­tu­ry sprze­da­ży, gdyż nie­kom­plet­na fak­tu­ra nie sta­no­wi żad­nej war­to­ści biz­ne­so­wej. Wszelkie dzia­ła­nia w toku two­rze­nia fak­tu­ry są ele­men­ta­mi sce­na­riu­sza jed­ne­go przy­pad­ku uży­cia, a wcze­śniej pro­ce­du­ry reali­za­cji jed­nej aktyw­no­ści two­rzą­cej tę fakturę.

Jak więc wyglą­da trans­for­ma­cja? Tu posłu­żę się frag­men­tem stro­ny pomo­cy pakie­tu Visual-Paradigm, jed­nej z nie­wie­lu apli­ka­cji CASE zacho­wu­ją­cej peł­ną zgod­ność ze spe­cy­fi­ka­cja­mi OMG:

BPMNtoUseCase (źr. http://www.visual-paradigm.com/tutorials/from-business-process-to-use-cases.jsp)
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)

(apli­ka­cja Visual-Paradigm two­rzy taką trans­for­ma­cje auto­ma­tycz­nie dla mode­lu pro­ce­su).

Kilka uwag do tekstu Pana Carewicza

Diagram przy­pad­ków uży­cia nie jest mode­lem ​„sys­te­mo­wym”, jest kon­trak­tem pomię­dzy zama­wia­ją­cym opro­gra­mo­wa­nie a jego dostaw­cą, sta­no­wi spe­cy­fi­ka­cję wyma­gań, gdzie pod poję­ciem ​„wyma­ga­nie” rozu­mie­my to, jakie usłu­gi ma to opro­gra­mo­wa­nie ofe­ro­wać (do cze­go będzie ono wyko­rzy­sty­wa­ne przez aktora):

18.1 Use Cases
18.1.1 Summary
UseCases 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. The key con­cepts spe­ci­fied in this clau­se are Actors, UseCases, and sub­jects. Each UseCase?s sub­ject repre­sents a sys­tem under con­si­de­ra­tion to which the UseCase applies. Users and any other sys­tems that may inte­ract with a sub­ject are repre­sen­ted as Actors. (UML v.2.5)

W mode­lu MDA (Model Driven Architecture) dia­gram przy­pad­ków uży­cia sta­no­wi ​„pomost” pomię­dzy mode­lem biz­ne­so­wym CIM (Computation Independet Model) a mode­lem logi­ki dzia­ła­nia i archi­tek­tu­ry PIM (Platform Independent Model). Model PIM to reali­za­cje przy­pad­ków uży­cia bazu­ją­ce na mode­lu dziedziny.

18.1.3 Semantics
18.1.3.1 Use Cases and Actors
[…] Each UseCase spe­ci­fies some beha­vior that a sub­ject can per­form in col­la­bo­ra­tion with one or more Actors. UseCases defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal struc­tu­re. (UML v.2.5)

Kluczem jest ostat­nie zda­nie: przy­pad­ki uży­cia defi­niu­ją zacho­wa­nie sys­te­mu bez odno­sze­nia się do jego wewnętrz­nej struk­tu­ry. Innymi sło­wy model przy­pad­ków uży­cia nie słu­ży do mode­lo­wa­nia archi­tek­tu­ry (wewnętrz­nej struk­tu­ry) opro­gra­mo­wa­nia. W UML 2.5 jaw­nie wydzie­lo­ny trzy obsza­ry seman­tycz­ne mode­lo­wa­nia, któ­re potwier­dza­ją powyższe:

UMLSemanticArea

Jednak dla zacho­wa­nia uni­wer­sal­no­ści i kom­pa­ty­bil­no­ści wstecz zacho­wa­no w UML 2.5 poję­cia – ste­reo­ty­py – «Extend» i «Include», któ­re ​„wyja­wia­ją” wewnętrz­ną struk­tu­rę apli­ka­cji, jed­nak UML 2.5 zastrzega:

The spe­ci­fic man­ner in which the loca­tion of an ExtensionPoint is defi­ned is inten­tio­nal­ly unspe­ci­fied. This is becau­se UseCases may be spe­ci­fied in vario­us for­mats such as natu­ral lan­gu­age, tables, tre­es, etc. […] The inc­lu­ded UseCase must be ava­ila­ble for the beha­vior of the inc­lu­ding UseCase to be com­ple­te­ly descri­bed. (UM v.2.5. R.18.1.3.)

Czyli ste­reo­ty­py związ­ku uży­cia dla przy­pad­ków uży­cia, ozna­czo­ne związ­kiem «extend» lub «inc­lu­de», zosta­ły w UML 2.5 dla zacho­wa­nia moż­li­wo­ści uży­wa­nia dia­gra­mów przy­pad­ków uży­cia i kon­ty­nu­owa­nia ich opi­su w fir­mie opi­so­wej (tekst, tabe­le, inne­go for­my słow­ne a nie gra­ficz­ne). Są to relik­to­we kon­struk­cje z cza­sów gdy na począt­ku lat 90-tych powsta­wał UML (były to trzy odręb­ne nota­cje trzech twór­ców): autor dia­gra­mu przy­pad­ków uży­cia nie znał dia­gra­mów struk­tu­ral­nych (dia­gra­my klas, kom­po­nen­tów) i musiał jakoś ​„poka­zać” ele­men­ty archi­tek­tu­ry kodu. Stosowanie tych kon­struk­cji w sytu­acji gdy mode­lem reali­za­cji przy­pad­ków uży­cia będą dia­gra­my sekwen­cji bazu­ją­ce na mode­lu dzie­dzi­ny (mode­le struk­tu­ry), nie ma żad­ne­go uza­sad­nie­nia i wpro­wa­dza zbęd­ny zamęt i nad­mier­ne, niczym nie uza­sad­nio­ne, roz­drob­nie­nie mode­lu (pomi­jam, że na tym eta­pie – umo­wa z zama­wia­ją­cym – przed­wcze­śnie narzu­ca decy­zje architektoniczne).

Autor tek­stu wpro­wa­dził tak­że kolej­ny podział przy­pad­ków uży­cia (ste­reo­ty­py) na ​„cel użyt­kow­ni­ka”, przy­pad­ki ​„wspie­ra­ją­ce”, ​„pomoc­ni­cze”, ​„pod­funk­cje”. Niestety nie zosta­ły one (te poję­cia) pre­cy­zyj­nie zde­fi­nio­wa­ne, wpro­wa­dza­ją do całej ​„meto­dy” cha­os poję­cio­wy. Z kon­tek­stu moż­na wywo­dzić, że jest to jakaś for­ma wynie­sie­nia na poziom mode­lu przy­pad­ków uży­cia, poszcze­gól­nych kro­ków ich sce­na­riu­szy (wyszu­ka­nie zgło­sze­nia, zapi­sa­nie infor­ma­cji o zmia­nie zgło­sze­nia do dzien­ni­ka) czy wręcz (o zgro­zo!) linii kodu, jed­nak cel tego jest nie­ja­sny, poza znacz­ną kom­pli­ka­cją dia­gra­mu, któ­ry jako kon­trakt z kupu­ją­cym, powi­nien być pro­sty i czy­tel­ny dla ​„biz­ne­su”. Wyciąganie na poziom ​„usług sys­te­mu” nie­mal­że poje­dyn­czych linii przy­szłe­go pro­gra­mu nie znaj­du­je w moich oczach żad­ne­go uza­sad­nie­nia (po raz kolej­ny przy­po­mi­nam, że przy­pad­ki uży­cia to wyma­ga­nia a nie model kodu), poza tym, że przy­bli­ża taki model do pro­duk­tów ana­li­zy struk­tu­ral­nej z lat 80-tych (pyta­nie po co?).

Autor powo­łu­je się tak­że na nota­cję BPMN słusz­nie wska­zu­jąc, że do trans­for­ma­cji na przy­pad­ki uży­cia two­rzy­my ​„pro­ces pry­wat­ny”, nie prze­zna­czo­ny do wyko­na­nia (non-exe­cu­ta­ble) w rozu­mie­niu ​„nie two­rzo­ny w celu bez­po­śred­nie­go uru­cho­mie­nia” np. w jakimś ​„sil­ni­ku pro­ce­so­wym”. I tu koń­czy się kon­se­kwen­cja, gdyż zale­ca sto­so­wa­nie deta­licz­nych czyn­no­ści i znacz­ni­ków spe­cy­ficz­nych dla mode­li wyko­ny­wal­nych (ozna­cze­nia w lewym gór­nym roku). Otóż do trans­for­ma­cji na przy­pad­ki uży­cia two­rzy­my model CIM (OMG MDA) a tu nie ​„brnie­my” w deta­licz­ne szcze­gó­ły, gdyż te będą reali­zo­wa­ne w apli­ka­cji. Model CIM to pro­ce­sy biz­ne­so­we ​„com­pu­ta­tion inde­pen­dent model” w nota­cji BPMN, poziom szcze­gó­ło­wo­ści mode­lu biz­ne­so­we­go CIM, do trans­for­ma­cji, koń­czy­my na wspo­mnia­nych na począt­ku ​„ato­mo­wych pro­ce­sach biz­ne­so­wych”, to któ­ra z aktyw­no­ści tych pro­ce­sów sta­nie się wyma­ga­niem (przy­pad­kiem uży­cia apli­ka­cji) zale­ży od umo­wy na zakres pro­jek­tu i od nicze­go wię­cej. Wymóg jako­by czyn­no­ści wysła­nia i ode­bra­nia komu­ni­ka­tu musia­ły być obli­ga­to­ryj­nie wydzie­la­ne wyda­je się dziw­ny. Np. czytamy:

Send Task
A Send Task is a sim­ple Task that is desi­gned to send a Message to an exter­nal Participant (rela­ti­ve to the Process). Once the Message has been sent, the Task is completed.

sko­ro więc czyn­ność wysła­nia komu­ni­ka­tu jest dedy­ko­wa­na do jed­ne­go zda­rze­nia jakim jest wysła­nie komu­ni­ka­tu, zaś na mode­lu pro­ce­sów biz­ne­so­wych ​„nie-wyko­ny­wal­nych” taki poziom szcze­gó­ło­wo­ści nie jest niczym uza­sad­nio­ny (wysła­nie potwier­dze­nia to z regu­ły ostat­ni krok pro­ce­du­ry a w sce­na­riu­szu przy­pad­ku uży­cia, ostat­ni krok tego sce­na­riu­sza) to pomysł ten wyda­je się nie mieć żad­ne­go uza­sad­nie­nia. Po dru­gie ​„wysła­nie komu­ni­ka­tu” odwzo­ro­wa­ne jako przy­pa­dek uży­cia nie ma żad­ne­go sen­su w świe­tle tego czym jest przy­pa­dek uży­cia w UML.

Nie wiem też jak, z pomo­cą jakiej trans­for­ma­cji, Pan Carewicz uzy­skał na dia­gra­mie przy­pad­ków uży­cia dzie­dzi­czą­cych po sobie aktorów.

Na zakończenie

Z przy­kro­ścią muszę napi­sać, że arty­ku­ły takie jak tekst Pana Piotra Carewicza wpro­wa­dza­ją zamęt. Nie mają, jak poka­za­łem, pod­staw seman­tycz­nych, nie mają uza­sad­nie­nia w samych nota­cjach, nie raz wręcz koli­du­ją z nimi, pro­wa­dzą do powsta­wa­nia bar­dzo roz­bu­do­wa­nych i kosz­tow­nych w opra­co­wa­niu doku­men­tów, nie wno­szą­cych swo­ją szcze­gó­ło­wo­ścią żad­nej war­to­ści doda­nej, a uży­cie takiej doku­men­ta­cji jest prak­tycz­nie nie moż­li­we, gdyż jak widać jest ona nie­spój­na a nad­miar szcze­gó­łów poda­nych na tak wcze­snym eta­pie jak pla­no­wa­nie wyma­gań, pro­wa­dzi do bar­dzo dużej ilo­ści aktu­ali­za­cji w toku reali­za­cji pro­jek­tu. Zdaje sobie spra­wę, że Pan Carewicz pró­bu­je sobie jakoś pora­dzić z uży­ciem UML do meto­dy wymia­ro­wa­nia opro­gra­mo­wa­nia COSMIC, któ­rej jest orę­dow­ni­kiem, ale moim zda­niem to jed­nak śle­pa uliczka.

Powyższe, nie mają­ce uza­sad­nie­nia w UML, kon­struk­cje, moż­na spo­tkać tak­że w mate­ria­łach publi­ko­wa­nych przez fir­mę SPARX, pro­du­cen­ta opro­gra­mo­wa­nia Enterprise Architect. Osobiście, i nie tyl­ko ja (np. Czas nie jest akto­rem), odra­dzam te mate­ria­ły i suge­ru­ję jed­nak ory­gi­nal­ne spe­cy­fi­ka­cje. Samo narzę­dzie fir­my SPARX, mimo, że bar­dzo tanie i popu­lar­ne, nie­ste­ty jest bar­dzo pra­co­chłon­ne. Tyle w kwe­stii samej trans­for­ma­cji. Ocenę meto­dy opi­sa­nej przez Pana Carewicza z fir­my 300 D&C pozo­sta­wiam czytelnikom.

Polecam tak­że t dwa filmiki 🙂

SOA

Modelowanie w projektach integracyjnych

1 komentarz

Projekty inte­gra­cyj­ne w śro­do­wi­sku zło­żo­nych (kil­ka­dzie­siąt apli­ka­cji) sys­te­mów nale­żą do bar­dzo trud­nych z uwa­gi na ich zło­żo­ność. Z pomo­cą przy­cho­dzi nam SOA jako model poję­cio­wy i ESB jako wzo­rzec archi­tek­tu­ry. Referat, wygło­szo­ny na kon­fe­ren­cji GigaCon, opi­su­je pro­ces ana­li­zy i mode­lo­wa­nia w toku spe­cy­fi­ko­wa­nia wyma­gań na ESB i interfejsy.

Poniżej struk­tu­ra archi­tek­tu­ry SOA na bazie stan­dar­dów OMG:

SOA_OMG_model

Kluczowe poję­cia:
– pro­ce­sy biz­ne­so­we, ele­men­tar­ne aktyw­no­ści, któ­ra wraz z wej­ściem i wyj­ściem sta­no­wią ele­men­tar­ny pro­ces biznesowy,
– usłu­ga biz­ne­so­wa (tak­że apli­ka­cyj­na) to przy­pa­dek uży­cia danej apli­ka­cji (apli­ka­cja świad­czy usłu­gi, każ­da usłu­ga ma stan począt­ko­wy, pro­dukt i sce­na­riusz realizacji),
– kom­po­nent, repre­zen­tu­je inte­gro­wa­ne aplikacje.

Treść pre­zen­ta­cji:

Polecam, kto nie czy­tał, ubie­gło­rocz­ny arty­kuł o integracji. 

Na koniec, dla zain­te­re­so­wa­nych SoaML (pro­fil UML do mode­lo­wa­nia integracji):
– spe­cy­fi­ka­cja na stro­nie OMG
– tuto­rial na stro­nie Visual-Paradigm

Przypadki użycia nie znają swoich realizacji…

6 komentarzy

Diagram przy­pad­ków uży­cia sta­le budzi wie­le kon­tro­wer­sji. Bywa, że nafa­sze­ro­wa­ny związ­ka­mi «inc­lu­de» i «exc­lu­de» wyglą­da jak talerz winogron.

Considering that the main ratio­na­le of use cases is to pro­vi­de a con­cep­tu­al brid­ge betwe­en busi­ness value and sys­tem capa­bi­li­ties, it’s not the role of busi­ness ana­ly­sts to weld the­ir con­cre­te, and spe­ci­fic requ­ire­ments into the con­si­stent and sta­ble func­tio­nal archi­tec­tu­re imple­men­ted by softwa­re clas­ses. (źr. Use Cases sho­uld know nothing abo­ut clas­ses | LinkedIn).

Powyższy cytat pocho­dzi z pew­nej dys­ku­sji. ​„Świat się spie­ra” na temat tego do cze­go słu­ży dia­gram przy­pad­ków uży­cia. Dyskusja na LinkedIn poka­za­ła, że ​„świat jest w tej kwe­stii podzie­lo­ny”. Skąd problem?

W 2011 roku napi­sa­łem, nie pierw­szy i pew­nie nie ostat­ni raz, że to ma być pro­sty dia­gram. Jego celem jest okre­śle­nie zakre­su pro­jek­tu w posta­ci, zro­zu­mia­łe­go dla zama­wia­ją­ce­go, dia­gra­mu poka­zu­ją­ce­go kto i do cze­go będzie uży­wał apli­ka­cji. I nic ponad to. NIe przy­pad­kiem jest czę­sto uzna­wa­ny za tak zwa­ny „[[model czar­nej skrzyn­ki]]”. Tak czę­sto spo­ty­ka­ne, mode­le nafa­sze­ro­wa­ne szcze­gó­ła­mi pro­jek­tu wywle­czo­ny­mi na wierzch z pomo­cą związ­ków «inc­lu­de» i «extend», sta­no­wią zbęd­ne (i przed­wcze­sne) ujaw­nia­nie archi­tek­tu­ry wewnętrz­nej, zaś dzie­dzi­cze­nie na tych dia­gra­mach to dla odmia­ny zbęd­ne wpla­ta­nie tu mode­li poję­cio­wych. Komplikowanie tego dia­gra­mu nisz­czy jego pod­sta­wo­wą rolę: kon­trakt zama­wia­ją­ce­go z dostaw­cą opro­gra­mo­wa­nia: zama­wia­ją­cy zawie­ra świa­do­mie ten kon­trakt gdy zro­zu­mie ten diagram.

…pro­ste jest pięk­ne: przy­pa­dek uży­cia to poje­dyn­cza, ele­men­tar­na kom­plet­na usłu­ga świad­czo­na przez System dla jego użyt­kow­ni­ka (czy­taj Przypadki uży­cia…).

Specyfikacja UML owszem zawie­ra opis, nie tyl­ko, związ­ków «inc­lu­de» i «extend» ale i dzie­dzi­cze­nia, nale­ży jed­nak pamię­tać, że spe­cy­fi­ka­cja zacho­wu­je kom­pa­ty­bil­ność wstecz (aż do lat 90-tych!) i to, że pomy­sło­daw­ca tego dia­gra­mu (obec­ny UML to zle­pek trzech nota­cji) nie znał dia­gra­mu klas, wiec musiał sobie jakość pora­dzić z poka­za­niem choć­by namiast­ki wewnętrz­nej struk­tu­ry apli­ka­cji. Dysponując jed­nak lep­szym do tego narzę­dziem, jakim jest dia­gram klas lub kom­po­nen­tów, kom­pli­ko­wa­nie dia­gra­mów przy­pad­ków uży­cia nie ma więk­sze­go sen­su. Polecam tu nie­daw­no napi­sa­ną recen­zje książ­ki UML for Java pro­gram­mers:

UMLforJavaProgrammersUseCases

Drugim powo­dem jest postę­pu­ją­ca stan­da­ry­za­cja mode­li poję­cio­wych róż­nych nota­cji rodem z OMG, mię­dzy inny­mi z powo­du rosną­ce­go zna­cze­nia (i korzy­ści z…) cało­ścio­we­go podej­ścia do mode­lo­wa­nia orga­ni­za­cji zwa­ne­go archi­tek­tu­rą kor­po­ra­cyj­na lub biz­ne­so­wą (lub po pro­tu [[podej­ściem sys­te­mo­wym do ana­li­zy orga­ni­za­cji]]). Ta stan­da­ry­za­cja to mię­dzy inny­mi ​„zrów­na­nie” poję­cia ​„aktyw­ność” w pro­ce­sie biz­ne­so­wym (BPMN) z poję­ciem Przypadek Użycia (UML), gdzie jest to ele­men­tar­na usłu­ga, wspie­ra­ją­ca aktyw­ność akto­ra, mają­ca stan począt­ko­wy i koń­co­wy (a pro­ces ma wej­ście i wyj­ście), stan koń­co­wy cechu­je okre­ślo­na war­tość dla akto­ra (UML) lub odbior­cy (BPMN), z poję­ciem usłu­ga apli­ka­cyj­na w archi­tek­tu­rze SOA (i w archi­tek­tu­rze korporacyjnej).

Obecnie przy­pad­ki uży­cia sta­no­wią pomost pomię­dzy per­spek­ty­wą biz­ne­so­wą widzą­ca przy­pad­ki uży­cia jako ​„usłu­gi apli­ka­cji” a per­spek­ty­wą apli­ka­cji, któ­ra ofe­ru­je je (przy­pad­ki uży­cia) jako usłu­gi apli­ka­cyj­ne. Poniżej ​„kla­sycz­ny”, od lat zna­ny, dia­gram obra­zu­ją­cy model SOA ([[Service Oriented Architecture]]):

SOA_OMG_model

Na tym dia­gra­mie widać (nie suge­ruj­my się kształ­tem ikon ;)) war­stwę Business Servces, któ­ra sta­no­wi ni mniej ni wię­cej tyl­ko wła­śnie przy­pad­ki uży­cia apli­ka­cji (Components) umiesz­czo­nych w war­stwie poni­żej. Na dzi­siaj pro­ce­sy biz­ne­so­we mode­lu­je­my nota­cją BPMN (twar­dzie­le nadal robią to dia­gra­mem aktyw­no­ści UML ;)), a resz­tę poni­żej nota­cją UML (mapu­jąc 1:1 ato­mo­we pro­ce­sy biz­ne­so­we na przy­pad­ki uży­cia, nie­któ­re pro­gra­my CASE robią to nawet automatycznie):

The most effec­ti­ve way to deve­lop a quali­ty softwa­re that can stre­am­li­ne and blend well with users» daily ope­ra­tions is to begin by ana­ly­zing users» daily work flows with care and pre­ci­sion and, to under­stand how par­ties work toge­ther to get jobs done. By doing so, you can find out the func­tions that the softwa­re sho­uld pro­vi­de in order to help the users. (From Business pro­cess to Use Case…)

Jeżeli nad pro­ce­sa­mi umie­ścić model moty­wa­cji biz­ne­so­wej (nota­cja BMM, nie ma tej war­stwy na powyż­szym dia­gra­mie) to otrzy­ma­my model archi­tek­tu­ry kor­po­ra­cyj­nej (po kil­ku pró­bach zasto­so­wa­nia nadal uwa­żam, że [[nota­cja ArchiMate]] nie wno­si żad­nej war­to­ści doda­nej, jest to – pomysł na nowa nota­cję – raczej zaprze­cze­niem zasa­dy ​„nie mnóż bytów ponad potrze­bę” zna­nej jako [[brzy­twa Ockhama]]).

Jest tu jesz­cze jed­na cie­ka­wa rzecz: nie ma danych na tych mode­lach. ​„Staromodne” podej­ście mówi, że opro­gra­mo­wa­nie to struk­tu­ry danych i funk­cje. I tak jest od stro­ny tech­nicz­nej ale to nie ma nic wspól­ne­go z biz­ne­sem. Biznes jest zain­te­re­so­wa­ny fak­tem sprze­da­ży, a to, że doku­men­tu­je­my do fak­tu­rą VAT to ​„szcze­gó­ły”. Dlatego na tym pozio­mie abs­trak­cji (uogól­nie­nia) nie ma sen­su robie­nie mode­li danych, ma sens robie­nie spe­cy­fi­ka­cji obiek­tów biz­ne­so­wych, na pozio­mie ich nazw. Takie podej­ście nazy­wa się zarzą­dza­niem pozio­mem szcze­gó­ło­wo­ści pro­jek­tu (od ogó­łu do szcze­gó­łu), na pozio­mie mode­lo­wa­nia takiej archi­tek­tu­ry nie ma zna­cze­nia to, ile danych jest na fak­tu­rze, zna­cze­nie ma, to że zaist­niał fakt sprze­da­ży i na czymś (nośnik danych, obiekt bez­sen­so­wy z nazwą) go udokumentowano.

Tak więc na tytu­ło­we pyta­nie obec­nie nale­ża­ło by odpo­wie­dzieć: nie, przy­pad­ki uży­cia nie zna­ją swo­ich reali­za­cji… W doku­men­ta­cji na eta­pie mode­lo­wa­nia przy­pad­ków uży­cia, two­rzy­my pro­sty dia­gram zło­żo­ny z trzech typów ele­men­tów: aktor, przy­pa­dek i sys­tem. Bez pomi­ja­nia ele­men­tu ​„sys­tem” (pro­sto­kąt będą­cy kon­te­ne­rem ma przy­pad­ki uży­cia), któ­ry sta­no­wi pod­sta­wę tego dia­gra­mu: wska­zu­je gra­ni­ce sys­te­mu. Jakiekolwiek szcze­gó­ły, w tym mode­le danych, to ostat­ni etap pra­cy jakim jest pro­jek­to­wa­nie i wyko­na­nie imple­men­ta­cji. Wszelkie bazy danych mode­lu­je­my na samym końcu.

Kolejny wnio­sek: przy­pad­ków uży­cia nie są set­ki a o rząd a nawet dwa rzę­dy mniej. Specyfikacje na set­ki przy­pad­ków uży­cia to jakieś total­ne nie­po­ro­zu­mie­nie (albo nie­zro­zu­mie­nie). Usługa apli­ka­cji świad­czo­na akto­ro­wi (kom­plet­na) to nie wsta­wie­nie adre­su na fak­tu­rze, a wysta­wie­nie (utwo­rze­nie) kom­plet­nej fak­tu­ry. Wstawianie adre­sów, pro­duk­tów itp. to ele­men­ty sce­na­riu­sza przy­pad­ku uży­cia (wywo­ła­nia na dia­gra­mie sekwen­cji albo opis współ­dzia­ła­nia akto­ra z ekra­nem aplikacji).

Nie ma też np. cze­goś takie­go jak „[[sys­te­mo­we przy­pad­ki uży­cia]]”, anie cze­go takie­go jak „[[biz­ne­so­we przy­pad­ki uży­cia]]” (to relikt z meto­dy­ki RUP z lat 90’tych przed poja­wie­niem się nota­cji BPMN). Wiem, wiem, że czę­sto się poja­wia­ją w lite­ra­tu­rze i na stro­nach zna­nych blo­gów, jed­nak nigdzie tam nie zna­la­złem defi­ni­cji tych pojęć odróż­nia­ją­cych te two­ry od ​„nor­mal­nych” przy­pad­ków uży­cia, inter­fej­sów kom­po­nen­tów czy pro­ce­sów biz­ne­so­wych. Prowadzenie nowe­go poję­cia powin­no mieć jakieś pod­sta­wy i war­tość doda­ną bez tego są tyl­ko ury­wa­niem nie­zro­zu­mie­nia mode­lo­wa­nej isto­ty rze­czy i łama­niem zasa­dy eko­no­mii myśle­nia, tej pro­stej zasa­dy ​„nie twórz bytów ponad mia­rę” (przy­po­mi­nam [[brzy­twa Ockhama]]) (nie­ste­ty fir­ma SPARX, pro­du­cent bar­dzo popu­lar­nej i taniej apli­ka­cji: Enterprise Architect, ma w zwy­cza­ju wymy­śla­nie róż­nych dziw­nych bytów tego typu, mię­dzy inny­mi ​„czas jako aktor sys­te­mu” nada­jąc mu dedy­ko­wa­ny ste­reo­typ). Bo zasta­nów­cie się, gdzie na powyż­szym dia­gra­mie SOA wsta­wić owe sys­te­mo­we czy biz­ne­so­we przy­pad­ki użycia???

Owszem, moż­na przy­jąć dowol­na kon­wen­cję two­rze­nia mode­li ale wte­dy nale­ży ją opi­sać od stro­ny poję­cio­wej. Bez tego model sta­je się zwy­kłym obraz­kiem, nie jest mode­lem. Ale pyta­nie po co, sko­ro w BPMN/UML to wszyst­ko jest, wraz z opi­sem jak ​„gład­ko” przejść z mode­lu biz­ne­so­we­go, przez model przy­pad­ków uży­cia do mode­lu archi­tek­tu­ry sys­te­mu… Owszem nota­cja UML zawie­ra wszyst­kie opi­sa­ne tu poję­cia i sym­bo­le, ale nie wol­no zapo­mi­nać, że nota­cja to wyłącz­nie język czy­li same sło­wa i gra­ma­ty­ka, sens maja dopie­ro zda­nia. Tak wiec pisząc ​„Krowa z sil­ni­kiem odrzu­to­wym, jeli­ta na czer­wo­no, jądro­wy­mi kopy­ta­mi, wypra­wio­na na buty skó­ra, znisz­czy­ła metro, wypa­dek samo­cho­do­wy, prze­la­tu­jąc nad Warszawą, licz­ba płyt chod­ni­ko­wych to 1347, a następ­nie wylą­do­wa­ła w Elektrociepłowni Żerań, zała­du­nek węgla w połu­dnie wyko­na­ny przez Kowalskiego, i poży­wi­ła się węglem popi­ja­jąc wodę z Wisły” to popraw­ne gra­ma­tycz­nie, bez­błęd­nie napi­sa­ne zda­nie w języ­ku pol­skim, ale nikt nie ma chy­ba wąt­pli­wo­ści, że kom­plet­nie pozba­wio­ne sen­su. Tak samo moż­na popraw­nie, zgod­nie z zasa­da­mi nota­cji, nary­so­wać dia­gram UML …

Sekwencje a procesy

3 komentarze

Swego cza­su napi­sa­łem tekst o nie­jed­no­znacz­no­ści tre­ści w doku­men­ta­cji jako źró­dle kło­po­tów w pro­jek­tach: Analityk biz­ne­so­wy czy­li wyple­nić dwu­znacz­ność… Warto pamię­tać, że:

Bałagan poję­cio­wy w rapor­cie z ana­li­zy, powo­du­je, że raport nie pozwa­la na jego jed­no­znacz­ną inter­pre­ta­cję, co prak­tycz­nie dys­kwa­li­fi­ku­je go jako przy­dat­ne źró­dło infor­ma­cji w projekcie.

Dzisiaj kon­ty­nu­acja tej tezy w kon­tek­ście powsta­ją­cych mode­li, ich tre­ści i szczegółowości.

Weźmy np. dość czę­sto poja­wia­ją­ce się poję­cia: ​„pro­ces sys­te­mo­wy” czy też ​„sys­tem” w mode­lu pro­ce­su biz­ne­so­we­go, sekwen­cje i dia­gra­my sekwen­cji itp. Spotykam się nie­ste­ty z masą beł­ko­tu i here­zji w doku­men­tach, na blo­gach czy nawet w książ­kach… Na listach dys­ku­syj­nych LinkedIn widać, że pro­blem nie doty­czy tyl­ko nasze­go kra­ju :). Przyczyną tych pro­ble­mów jest prak­tycz­nie zawsze igno­ro­wa­nie defi­ni­cji pojęć tak języ­ko­wych (język w jakim pisa­na jest doku­men­ta­cja) jak i nota­cyj­nych (igno­ro­wa­nie lub po pro­stu nie­zna­jo­mość lub nawet nie zro­zu­mie­nie stan­dar­du). Czy nazy­wa­nie cze­goś here­zją to moje subiek­tyw­ne uzna­nie? Myślę, że nie, to porów­na­nie (audyt?) ze stan­dar­da­mi i ogól­nie uzna­ny­mi sys­te­ma­mi poję­cio­wy­mi, jed­nym z nich język ojczy­sty auto­ra dokumentu.

Najpierw kil­ka klu­czo­wych defi­ni­cji (słow­nik języ­ka pol­skie­go PWN):

pro­ces: prze­bieg nastę­pu­ją­cych po sobie i powią­za­nych przy­czy­no­wo okre­ślo­nych zmian

pro­ce­du­ra: okre­ślo­ne regu­ły postępowania

sekwen­cja: układ jakichś ele­men­tów, w któ­rym nastę­pu­ją one w okre­ślo­nej kolejności

sce­na­riusz: zapla­no­wa­ny lub prze­wi­dy­wa­ny roz­wój wydarzeń

Proces, defi­ni­cja ​„biz­ne­so­wa” mówi o pro­duk­cie pro­ce­su biz­ne­so­we­go, jest nim wła­śnie ta wpro­wa­dzo­na ​„zmia­na”. Procedura w prak­ty­ce jest regu­łą (biz­ne­so­wą). Sekwencja w UML to nic inne­go jak usta­lo­na (dla sen­su lub powo­dze­nia ope­ra­cji) kolej­ność zda­rzeń (wywo­łań). Scenariusz to poję­cie wyko­rzy­sta­ne w opi­sie przy­pad­ków uży­cia: ​„sce­na­riusz przy­pad­ku uży­cia”. W związ­ku z tym, że przy­pad­ki uży­cia są wyma­ga­niem (opi­sem uży­cia pro­duk­tu), inte­rak­cja aktor – sys­tem, ma sta­tus ​„pla­no­wa­ny”. Uznanie w pro­jek­cie, że wyma­ga­nie jest ​„OK”, daje w kon­se­kwen­cji ​„pro­jekt”, czy­li sekwen­cję opi­su­ją­cą reali­za­cję przy­pad­ku uży­cia. Jak widać, słow­nik nie jest taki zły, nota­cje i ich sys­tem poję­cio­wy w szczególności.

Porządkujemy wie­dze dalej. Zajrzyjmy do MDA Guide Version 1.0.1:

MDA CIM model

MDA PIM model

Model CIM to model opi­su­ją­cy logi­kę dzia­ła­nia (sens ist­nie­nia) mode­lo­wa­nej orga­ni­za­cji, to model tego ​„co i po co się dzie­je” a nie ​„jak i czym”. Tu nie poka­zu­je­my narzę­dzi (jakim jest np. opro­gra­mo­wa­nie). Standardem na tym pozio­mie mode­lo­wa­nia są nota­cje BMM i BPMN. Rzecz w tym, że model pro­ce­sów biz­ne­so­wych nie powi­nien zawie­rać żad­nych pojęć typu ​„sys­tem” czy ​„opro­gra­mo­wa­nie”. Dlaczego? Bo dla zro­zu­mie­nia i udo­ku­men­to­wa­nia tego jak dzia­ła orga­ni­za­cja, potrzeb­na jest wie­dza o tym jakie infor­ma­cje i jak są prze­twa­rza­ne, a nie ​„czym”.

Często widu­ję pró­by poka­za­nia na jed­nym dia­gra­mie: pra­cy ludzi, inte­gra­cji sys­te­mów, szcze­gó­łów pro­ce­dur i wszyst­ko inne, co tyl­ko autor doku­men­tu wie. To total­ne nie­po­ro­zu­mie­nie, to pokaz nie­zro­zu­mie­nia tego czym są mode­le, a są uprosz­cze­nia­mi (abs­trak­cja­mi), okre­ślo­ny­mi per­spek­ty­wa­mi ana­li­zo­wa­ne­go zjawiska.

Model PIM to obraz logi­ki dzia­ła­nia (część biz­ne­so­wa, dome­na) narzę­dzia jakim jest apli­ka­cja. Tu poja­wia się to, jakie infor­ma­cje i jak są (mają być) prze­twa­rza­ne. Model ten jed­nak nie opi­su­je szcze­gó­łów (śro­do­wi­sko apli­ka­cji, fra­me­work, roz­wią­za­nia tech­no­lo­gicz­ne np. logo­wa­nie, kodo­wa­nie, itp.), opi­su­je wyłącz­nie biz­ne­so­wą logi­kę dzia­ła­nia apli­ka­cji. Gdzie i jak to pro­jek­to­wać, poka­zać, testować?

Przytoczę po raz kolej­ny dia­gram ze stro­ny Business Process Trends:

(źr. http://www.bptrendsassociates.com/)
(źr. http://​www​.bptrend​sas​so​cia​tes​.com/)

Mamy tu trzy pozio­my mode­lo­wa­nia orga­ni­za­cji: archi­tek­tu­ra pro­ce­sów, mode­le pro­ce­sów oraz ich imple­men­ta­cja. Architekturę pro­ce­sów z regu­ły przed­sta­wia się jako wyso­ko­po­zio­mo­we uogól­nie­nie np. z pomo­cą pro­stej nota­cji zna­nej jako ​„pago­ni­ki” :):

Diagram Mapa Procesów

Modele pro­ce­sów two­rzy­my z uży­ciem, nie raz tu już oma­wia­nej, nota­cji BPMN. Tu jest mowa o pro­ce­sach biz­ne­so­wych i ewen­tu­al­nych ich pod­pro­ce­sach ale nadal poziom szcze­gó­ło­wo­ści nie scho­dzi poni­żej pary ​„aktyw­ność i jej pro­dukt” (pro­ces biz­ne­so­wy). Implementacja to regu­ły wg. któ­rych reali­zo­wa­ne są poszcze­gól­ne aktyw­no­ści. Dana aktyw­ność jest reali­zo­wa­na albo na bazie umie­jęt­no­ści jej wyko­naw­cy (rola) i nie two­rzy­my jej dia­gra­mu a powo­łu­je­my się na opis sta­no­wi­ska, albo na bazie pro­ce­du­ry czy­li wyko­naw­ca danej pra­cy musi prze­strze­gać reguł narzu­co­nych pro­ce­du­rą. Procedurę spi­su­je­my w punk­tach z ewen­tu­al­ny­mi warian­ta­mi (a nie mode­lu­je­my obraz­ka­mi). Ale imple­men­ta­cja to albo wdro­że­nie pro­ce­du­ry albo wdro­że­nie oprogramowania. 

A gdzie te ​„systemowe procesy”?

Otóż nie ma cze­goś takie­go, nie w archi­tek­tu­rze opi­sy­wa­nej stan­dar­do­wo ani w BPMN ani w UML, nie ma (nie znam) w archi­tek­tu­rze kor­po­ra­cyj­nej. Mając wie­dzę o kom­po­nen­tach sys­te­mu (róż­nych apli­ka­cjach) mamy wie­dzę do cze­go zosta­ły one stwo­rzo­ne i jakie reali­zu­ją zada­nia (zna­my ich inter­fej­sy). Zaś ele­men­tem, któ­ry ini­cju­je w sys­te­mie jaką­kol­wiek sekwen­cję wyda­rzeń (inte­rak­cji mię­dzy apli­ka­cja­mi, kom­po­nen­ta­mi, obiek­ta­mi) jest zaini­cjo­wa­ny przy­pa­dek uży­cia sys­te­mu, a kon­kret­nie zda­rze­nie ini­cju­ją­ce wyge­ne­ro­wa­ne przez kon­kret­ne­go akto­ra. Jeżeli teraz przy­po­mni­my sobie, że akto­rem sys­te­mu może być tak­że inny sys­tem (kła­nia się dia­gram przy­pad­ków uży­cia), ini­cju­ją­cy inte­rak­cje (żąda obsłu­gi, np. przez API) to mamy peł­ny obraz sytu­acji: aktor ini­cju­je sekwen­cje wyda­rzeń jaką są kolej­no nastę­pu­ją­ce po sobie wza­jem­ne wywo­ła­nia kom­po­nen­tów lub obiek­tów. Znowu klu­czo­wym poję­ciem sta­je się tu SYSTEM (na dia­gra­mie przy­pad­ków uży­cia jest to ele­ment System czy­li oryg. ​„sub­ject” danej per­spek­ty­wy) i jego gra­ni­ce. To aku­rat bar­dzo ład­nie poka­zu­je ten turorial:

Tak więc mamy:

  1. pro­ce­sy biz­ne­so­we jako pary aktyw­ność i jej pro­dukt (za pro­dukt odpo­wia­da wyko­naw­ca pro­ce­su, są to np. mode­le w nota­cji BPMN),
  2. pro­ce­du­ry (lub wyma­ga­ne umie­jęt­no­ści), opi­su­ją­ce ato­mo­we (nie­po­dziel­ne) aktyw­no­ści (opi­sa­ne np. w posta­ci wypunk­to­wa­nych list), two­rze­nie pro­ce­dur to imple­men­ta­cja okre­ślo­nych aktyw­no­ści meto­da­mi orga­ni­za­cyj­ny­mi (np. wdro­że­nie sys­te­mu zarzą­dza­nia jako­ścią ISO),
  3. sce­na­riu­sze przy­pad­ków uży­cia opi­su­ją inte­rak­cje aktor-apli­ka­cja (opi­sa­ne jako punk­to­wa­ne listy, mode­lo­wa­ne jako inte­rak­cje aktor-sys­tem w nota­cji UML), jest to imple­men­ta­cja okre­ślo­nych aktyw­no­ści w aplikacji,
  4. sekwen­cje opi­su­ją inte­rak­cje pomię­dzy kom­po­nen­ta­mi (obiek­ta­mi, mode­lo­wa­ne dia­gra­mem sekwen­cji UML), czy­li ele­men­ta­mi archi­tek­tu­ry apli­ka­cji (sys­te­mu).

Bardzo dobrze poka­zu­je to model SOA opi­sa­ny w poprzed­nim arty­ku­le Wzorzec CRUD. Warstwa pro­ce­sów, usług aplikacyjnych/przypadków uży­cia i kom­po­nen­tów to odręb­ne war­stwy i per­spek­ty­wy. Nie mie­sza­my więc ani pozio­mów abs­trak­cji ani per­spek­tyw mode­li. W prze­ciw­nym razie, ule­ga­jąc suge­stiom w rodza­ju ​„ale ja chcę zoba­czyć to wszyst­ko na jed­nym dia­gra­mie” pcha­my pro­jekt w kie­run­ku ​„utra­ty pano­wa­nia nad zło­żo­no­ścią”… To pro­sta dro­ga do klę­ski projektu.

Wzorzec CRUD dla przypadków użycia i mikroserwisy

7 komentarzy

Regularnie spo­ty­kam się z mon­stru­al­ny­mi spe­cy­fi­ka­cja­mi: naj­pierw ​„wyma­gań” a potem ​„przy­pad­ków uży­cia”: dzie­siąt­ki, set­ki (o ich ilo­ści napi­sa­łem tu). Na ich pod­sta­wie powsta­ją wyce­ny – nie mniej kosmicz­ne. Jednak jeże­li zesta­wić to z bada­nia­mi pro­jek­tów i oce­ną, że jed­ną z klu­czo­wych przy­czyn pora­żek jest nad­mier­na zło­żo­ność i nie­jed­no­znacz­ność spe­cy­fi­ka­cji wyma­gań, a potem same­go pro­jek­tu i jego zakre­su oraz utra­ta pano­wa­nia nad tym zakre­sem, to może war­to się nad tym pochylić?

Kluczem jest defi­ni­cja wyma­ga­nia i czę­sto są nimi wła­śnie przy­pad­ki uży­cia. Pojęcie przy­pad­ku uży­cia (UML) i usłu­gi (SoaML):

Przypadek uży­cia (UML, Superstructure v.2.4.1.): A use case is the spe­ci­fi­ca­tion of a set of actions per­for­med by a sys­tem, which yields an obse­rva­ble result that is, typi­cal­ly, of value for one or more actors or other sta­ke­hol­ders of the sys­tem.

Usługa (SoaML, v.1.0.1.): Service is defi­ned as the deli­ve­ry of value to ano­ther par­ty, ena­bled by one or more capa­bi­li­ties. Here, the access to the servi­ce is pro­vi­ded using a pre­scri­bed con­tract and is exer­ci­sed con­si­stent with con­stra­ints and poli­cies as spe­ci­fied by the servi­ce contract.

Tak więc przy­pa­dek uży­cia jako efekt daje okre­ślo­ny, war­to­ścio­wy rezul­tat. Warto teraz w tym miej­scu pod­kre­ślić, że SOA (patrz spe­cy­fi­ka­cja) zakła­da, że usłu­ga jako efekt (pro­dukt) daje ​„Real World Effect defi­ned as servi­ce ope­ra­tion post con­di­tion” co jest o tyle istot­ne, że ana­lo­gicz­nie koń­czy się przy­pa­dek uży­cia (przy­po­mnę, że ​„post con­di­tion” to sta­bil­ny stan sys­te­mu po wyko­na­niu operacji).

Popatrzmy teraz na poję­cie czyn­no­ści w BPMN:

Aktywność a czyn­ność: (BPMN, v.2.0) An Activity is work that is per­for­med within a Business Process. An Activity can be ato­mic or non-ato­mic (com­po­und). The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, which allows the inc­lu­sion of re-usa­ble Tasks and Processes in the dia­gram. However, a Process is not a spe­ci­fic gra­phi­cal object. Instead, it is a set of gra­phi­cal objects. The fol­lo­wing sec­tions will focus on the gra­phi­cal objects Sub-Process and Task. […] A Task is an ato­mic Activity within a Process flow. A Task is used when the work in the Process can­not be bro­ken down to a finer level of detail.

Tu zaczy­na się prag­ma­ty­ka biz­ne­so­wa, czy­li defi­ni­cja poję­cia pro­ces biz­ne­so­wy, któ­ra zakła­da, że pro­ces biz­ne­so­wy (tak­że ele­men­tar­ny, ato­mo­wy) to czyn­ność lub łań­cuch logicz­nie powią­za­nych czyn­no­ści (aktyw­ność), two­rzy pro­dukt mają­cy war­tość dla odbior­cy tego pro­duk­tu (pro­dukt musi się nada­wać do biz­ne­so­we­go wyko­rzy­sta­nia). Ta defi­ni­cja jest nie­mal­że kopia defi­ni­cji przy­pad­ku uży­cia. Procesem biz­ne­so­wym jest KAŻDA aktyw­ność wraz z jej samo­dziel­nie przy­dat­nym biz­ne­so­wo pro­duk­tem (para aktyw­ność i jej pro­dukt, dla­te­go w BPMN nie ma jed­nej iko­ny na ​„pro­ces biz­ne­so­wy”). Jak widać, te trzy poję­cia: przy­pa­dek uży­cia apli­ka­cji, usłu­ga apli­ka­cji oraz ele­men­tar­ny pro­ces biz­ne­so­wy (pod­kre­ślam, że pro­jek­ty IT dla biz­ne­su mają biz­ne­so­wy kon­tekst co nada­je ści­ślej­sze zna­cze­nia tym trzem poję­ciom), mają nie­mal­że toż­sa­me defi­ni­cje (zresz­tą OMG dąży w tym wła­śnie kie­run­ku). Popatrzmy tu:

The majo­ri­ty of today­’s SOA design tech­ni­qu­es 1,2,3 are cen­te­red aro­und defi­ni­tion of servi­ces. They use 1se­rvi­ce-orien­ted decom­po­si­tion, based on the busi­ness pro­ces­ses, enter­pri­se business/functional model, requ­ired long term archi­tec­tu­ral goals and reu­se of the exi­sting enter­pri­se func­tio­na­li­ty. (Incorporating Enterprise Data into SOA).

Kluczem jest suge­stia (uzna­nie), że ele­men­tar­nym poję­ciem do dekom­po­zy­cji funk­cjo­nal­nej jest poję­cie ele­men­tar­nej (ato­mo­wej) usłu­gi (i nie jest nią jed­na linia pro­gra­mu!) będą­cej tak­że ele­men­tar­nym pro­ce­sem biz­ne­so­wym. Popatrzmy na dia­gram obra­zu­ją­cy archi­tek­tu­rę SOA (pocho­dzą­cy z tego same­go artykułu):

SOA implemetation

Mamy tu, mię­dzy inny­mi, trzy waż­ne war­stwy (tu dru­gą, trze­cią i czwar­tą od góry), są to odpo­wied­nio: pro­ce­sy biz­ne­so­we, usłu­gi apli­ka­cyj­ne (ta war­stwa to abs­trak­cja) oraz apli­ka­cje świad­czą­ce te usłu­gi. Mamy więc mapo­wa­nie ele­men­tar­nych ato­mo­wych pro­ce­sów (poje­dyn­czych czyn­no­ści) na ele­men­tar­ne usłu­gi apli­ka­cyj­ne. Usługi te, to nic inne­go jak przy­pad­ki uży­cia apli­ka­cji, czy­li każ­dą apli­ka­cję (jej uży­tecz­ność) moż­na opi­sać z pomo­cą jej ​„przy­pad­ków uży­cia”, a te jak już wie­my, w UML słu­żą – jak widać słusz­nie – do spe­cy­fi­ko­wa­nia wyma­gań funk­cjo­nal­nych. Tu uwa­ga, nie nale­ży tego mylić ze spo­ty­ka­ny­mi w lite­ra­tu­rze ​„biz­ne­so­wy­mi przy­pad­ka­mi uży­cia” (nie ma taki w UML).

Konwencja biz­ne­so­wych przy­pad­ków uży­cia to relikt meto­dy RUP z lat 90’tych, kie­dy to nie było np. nota­cji BPMN, i tak zwa­ny ​„biz­ne­so­wy dia­gram przy­pad­ków uży­cia” opi­sy­wał fir­mę, jej usłu­gi i klien­tów (akto­rów), a nie apli­ka­cję (do dzi­siaj jest to przy­czy­ną wie­lu nie­po­ro­zu­mień i powsta­wa­nia niskiej jako­ści nie­jed­no­znacz­nych dokumentacji). 

Tak więc, jak widać, moż­na uznać (przy­jąć), że przy­pa­dek uży­cia to usłu­ga apli­ka­cji, a ich gra­da­cję okre­śla pro­dukt jako uży­tecz­ność efek­tu. Co cie­ka­we, nie­któ­re narzę­dzia CASE wspie­ra­ją (uła­twia­ją) two­rze­nie (mapo­wa­nie) czyn­no­ści (ele­men­tar­nych pro­ce­sów biz­ne­so­wych) w pro­ce­sach (nota­cja BPMN) na przy­pad­ki uży­cia (nota­cja UML).

Taksonomia wyma­gań, w tym biz­ne­so­we i przy­pad­ki uży­cia oraz usłu­gi apli­ka­cyj­ne (Produkty w pro­ce­sie ana­li­zy wyma­gań):

Wymagania

Warto tu teraz zwró­cić uwa­gę, że wyma­ga­nia funk­cjo­nal­ne i poza-funk­cjo­nal­ne, jako­ścio­we i dzie­dzi­no­we oraz usłu­gi sys­te­mu to ele­men­ty abstrakcyjne.

Tak na praw­dę rze­czy­wi­ste są jedy­nie wyma­ga­nia biz­ne­so­we jako ocze­ki­wa­nia zama­wia­ją­ce­go wyra­żo­ne w jego języ­ku, oraz przy­pad­ki uży­cia i model dzie­dzi­ny, bo opi­su­ją rze­czy­wi­sty byt jakim jest (przy­szły) pro­dukt (apli­ka­cja).

CRUD, czym jest?

CRUD to skrót od ang. Create, Retrieve, Update, Delete (Utwórz, Przywołaj, Zaktualizuj, Usuń). Są to czte­ry pod­sta­wo­we ope­ra­cje na tak zwa­nych kar­to­te­kach, obiek­tach słu­żą­cych do zapa­mię­ty­wa­nia infor­ma­cji czy­li poje­dyn­czych ​„encji” (nie mylić z encja­mi w bazach rela­cyj­nych) lub ich agre­ga­tach. Obiektami odpo­wie­dzial­nym za ich prze­cho­wy­wa­nie są repo­zy­to­ria (Repository). Kluczowe czte­ry ope­ra­cje udo­stęp­nia­ne przez repo­zy­to­rium to wła­śnie CRUD. Pytanie brzmi: czym jest kar­to­te­ka? Jest zbio­rem kart (doku­men­tów) o jed­na­ko­wej (lub podob­nej) struk­tu­rze. Tak więc usłu­gą jest ​„zarzą­dza­nie kar­ta­mi”, czy też odręb­ny­mi usłu­ga­mi są two­rze­nie kar­ty, czy­ta­nie, uzu­peł­nie­nie, usu­nię­cie? Popatrzmy na to z per­spek­ty­wy usłu­gi dla użyt­kow­ni­ka: ma sens posia­da­nie wygod­nej szu­fla­dy z kar­ta­mi w biblio­te­ce ale czy ma sens samo­dziel­na, wyję­ta z kon­tek­stu usłu­ga ​„two­rze­nie nowych kart”? Można pole­mi­zo­wać, ale jeże­li chcieć utrzy­mać spój­ność poję­cio­wą i moż­li­wość kon­tro­li spój­no­ści i kom­plet­no­ści pro­jek­tu i jego zakre­su, lepiej uznać, że usłu­gą apli­ka­cyj­ną jest ​„zarzą­dza­nie kar­ta­mi”. Po pierw­sze taka usłu­ga jest samo­wy­star­czal­na, zaś samo two­rze­nie kar­ty bez moż­li­wo­ści jej przy­wo­ła­nia nie ma sen­su, więc te czte­ry pro­ste czyn­no­ści są nie­ja­ko nie­ro­ze­rwal­nie zwią­za­ne, sta­no­wiąc jed­ną usłu­gę. Po dru­gie two­rze­nie nowe­go zapi­su, mody­fi­ko­wa­nie czy usu­wa­nie, to kon­tekst użyt­kow­ni­ka, w zasa­dzie każ­dą z czte­rech ope­ra­cji CRUD moż­na spro­wa­dzić do scenariusza:

  1. pokaż kar­tę (pusta to two­rze­nie nowe­go zapisu)
  2. zrób z tym coś (wpisz nowe, zmień, usuń) i potwierdź (zacho­waj skutek)

Dlatego są pod­sta­wy by uznać, że ​„zarzą­dza­nie kar­ta­mi kata­lo­go­wy­mi” to jed­nak jeden przy­pa­dek uży­cia, a poszcze­gól­ne ope­ra­cje, to kon­tek­sto­we warian­ty sce­na­riu­sza wyni­ka­ją­ce z pro­ce­su czy­li chwi­lo­we­go celu użyt­kow­ni­ka (akto­ra). To podob­nie jak mło­tek (usłu­ga dostęp­na ze skrzyn­ki narzę­dzio­wej), to czło­wiek uży­wa młot­ka w kon­tek­ście wbi­ja­nie gwoź­dzia, zbi­ja­nia szy­by, roz­bi­ja­nia kamie­ni. Młotek w rękach czło­wie­ka po pro­stu słu­ży do ude­rza­nia, więc przy­pad­kiem uży­cia jest ude­rza­nie a nie czyn­ność w pro­ce­sie zbi­ja­nia budy dla psa jaką jest wbi­ja­nie gwoź­dzi w deski. Podejście takie wca­le nie jest nowe, w cie­ka­wy spo­sób opi­sał to autor tego artykułu:

If you have ever been wri­ting use cases for a data-orien­ted sys­tem (i.e. CMS), you have pro­ba­bly noti­ced that the­re is a pro­blem with the lar­ge num­ber of use cases like ​„Add an artic­le”, ​„Remove an artic­le” etc. If you have all CRUD ope­ra­tions ava­ila­ble for all objects in the sys­tem, you can finish with up to 4 x num­ber-of-objects of use cases. You can redu­ce this num­ber by intro­du­cing the CRUD pat­tern, which I would like to pre­sent you in this blog entry. (CRUD Pattern in Use Cases ? PUT Software Engineering Team).

Można takie podej­ście (wyni­ka­ją­ce nie­ja­ko wprost z defi­ni­cji przy­to­czo­nych pojęć), jak widać, nazwać wzor­cem pro­jek­to­wym :). Bardzo ład­nie prze­kła­da się to na archi­tek­tu­rę (model opar­ty o wzo­rzec BCE), ope­ru­ją­cą poję­cia­mi boun­da­ry (gra­ni­ca), con­troll ( ste­ro­wa­nie) i enti­ty (nośnik informacji):

Wzorzec BCE

Na powyż­szym dia­gra­mie mamy dwa przy­pad­ki uży­cia: gór­ny to typo­wy CRUD, dol­ny do usłu­ga, np. obli­cze­nio­wa. Przypadek pierw­szy (gór­ny) dodat­ko­wo korzy­sta z logi­ki ​„Samodzielna logi­ka” tego dru­gie­go PU (inte­gra­cja dwóch aplikacji/komponentów).

Poniżej dwa cie­ka­we arty­ku­ły, roz­wi­ja­ją­ce powyż­sze. Pierwszy to tak zwa­ne mikro ser­wi­sy, wzo­rzec trak­tu­ją­cy każ­dą usłu­gę apli­ka­cyj­ną 9a tym samym przy­pa­dek uży­cia) jako odręb­ną apli­ka­cję, dru­gi poka­zu­je jak pro­jek­to­wać inter­fej­sy w takich przypadkach.

„Microservices” – yet ano­ther new term on the crow­ded stre­ets of softwa­re archi­tec­tu­re. Although our natu­ral inc­li­na­tion is to pass such things by with a con­temp­tu­ous glan­ce, this bit of ter­mi­no­lo­gy descri­bes a sty­le of softwa­re sys­tems that we are fin­ding more and more appe­aling. We’ve seen many pro­jects use this sty­le in the last few years, and results so far have been posi­ti­ve, so much so that for many of our col­le­agu­es this is beco­ming the default sty­le for buil­ding enter­pri­se appli­ca­tions. Sadly, howe­ver, the­re­’s not much infor­ma­tion that outli­nes what the micro­se­rvi­ce sty­le is and how to do it. (Microservices).

Tell-Don’t-Ask is a prin­ci­ple that helps people remem­ber that object-orien­ta­tion is abo­ut bun­dling data with the func­tions that ope­ra­te on that data. It reminds us that rather than asking an object for data and acting on that data, we sho­uld inste­ad tell an object what to do. This enco­ura­ges to move beha­vior into an object to go with the data. (TellDontAsk).

Na zakończenie

Analizy biz­ne­so­we wyma­ga­ją ode­rwa­nia się od tech­no­kra­cji, nie ma cze­goś takie­go jak dzie­siąt­ki przy­pad­ków uży­cia dla jed­nej fak­tu­ry, nie ma sys­te­mo­wych przy­pad­ków uży­cia (nawet w spe­cy­fi­ka­cji UML ich nie znaj­dzie­cie), są kom­plet­ne (dają­ce jako efekt przy­dat­ne pro­duk­ty) usłu­gi apli­ka­cyj­ne i korzy­sta­ją­cy z tych usług akto­rzy, w tym inne apli­ka­cje lub kom­po­nen­ty. Dokumentacje zawie­ra­ją­ce set­ki przy­pad­ków uży­cia to nie­po­ro­zu­mie­nie, tech­no­kra­tycz­ni zabój­cy pro­jek­tów. Warto się zasta­no­wić zanim powie­rzy­cie ana­li­zę i pro­jekt logi­ki sys­te­mu tech­no­kra­tycz­ne­mu deve­lo­pe­ro­wi… Zapraszam do lek­tu­ry kolej­ne­go arty­ku­łu o zarzą­dza­niu szcze­gó­ło­wo­ścią ana­li­zy..