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):

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ń):

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):

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..