Wstęp

Kolejne szko­le­nie i kolej­na wal­ka z mita­mi, szko­dli­wy­mi mita­mi. Przypadki uży­cia to jed­no z chy­ba naj­bar­dziej nad­uży­wa­nych pojęć w bran­ży IT. Do tego lite­ra­tu­ra przed­mio­tu jest nafa­sze­ro­wa­na przy­kła­da­mi sto­so­wa­nia tego poję­cia w bar­dzo wie­lu kon­tek­stach i zna­cze­niach, nie­ste­ty nie raz z błę­da­mi. I nie cho­dzi o to, że tak jest a o to, że jed­ną z wie­lu metod doku­men­to­wa­nia sys­te­mów jest UML, któ­ry ma bar­dzo ści­słe sfor­ma­li­zo­wa­ne defi­ni­cje pojęć, i war­to nie zapo­mi­nać, że UML jest uni­fied” czy­li ujed­no­li­co­ny (a nie uni­wer­sal­ny!). Poza UML są inne podej­ścia” do przy­pad­ków uży­cia, np. Alistair Cocbourn’a (podob­ne do ICONIX, zorien­to­wa­ne na przy­pad­ki uży­cia), a tak­że wie­le innych, nie mają­cych z UML nic wspólnego.

Przypadek Użycia w UML

Potoczne poj­mo­wa­nie przy­pad­ku uży­cia cze­goś” to każ­dy przy­pa­dek inte­rak­cji z tym czymś” i to jest dokład­nie to czym nie jest przy­pa­dek uży­cia w UML. Skupiam się w tym arty­ku­le na nota­cji UML, gdyż jest to nota­cja sfor­ma­li­zo­wa­na, zawie­ra ona to poję­cie w kon­tek­ście dia­gra­mu przy­pad­ków uży­cia”, a licz­ba mitów i nie­pra­wi­dło­wych kon­struk­cji w książ­kach i sie­ci jest ogrom­na. Autorzy wie­lu z nich szer­mu­ją poję­ciem przy­pa­dek uży­cia”, rzad­ko jed­nak poda­ją (powo­łu­ją się na) jego ory­gi­nal­ną defi­ni­cję. Tak więc, jak już wpi­su­je­my we wstę­pie two­rzo­nej doku­men­ta­cji, że zasto­so­wa­no nota­cję UML to sto­suj­my ją.

Na począ­tek seman­ty­ka dia­gra­mu przy­pad­ków uży­cia i to czym one nie są, a nie są kon­tek­stem pra­cy akto­ra (spe­cy­fi­ka­cja UML 2.5. for­mal-15 – 03-01.pdf):

Przypadek uży­cia repre­zen­tu­je zacho­wa­nie się sys­te­mu (przed­miot opi­sy­wa­ny). Opisuje zacho­wa­nie się sys­te­mu będą­ce reak­cją na żąda­nie akto­ra: wyge­ne­ro­wa­nie obser­wo­wal­ne­go efek­tu dla akto­ra. Efektu będą­ce­go celem akto­ra (aktor uży­wa sys­te­mu by ten sku­tek osią­gnąć). Opis ten nie odno­si się do wewnętrz­nej budo­wy sys­te­mu, okre­ślo­ny uzy­ska­ny (ocze­ki­wa­ny) efekt może być osią­gnię­tym róż­ny­mi warian­ta­mi zacho­wa­nia sys­te­mu (cho­dzi o alter­na­tyw­ne sce­na­riu­sze). Młotek ma jeden przy­pa­dek uży­cia, jest nim ude­rze­nie w gwoź­dzia (albo nawet ogól­nie ude­rze­nie w coś). Jest wyko­rzy­sty­wa­ny przez akto­ra w wie­lu kon­tek­stach, ale to aktor je zna i rozumie.

Bardzo czę­sty błąd wie­lu two­rzo­nych dia­gra­mów UML” to sku­tek tezy, że user sto­ry mode­lu­je­my jako use case, jed­nak przy­pa­dek uży­cia nie jest tym po co (powód) aktor użył sys­te­mu. Przypadek uży­cia jest tym co robi ten sys­tem w odpo­wie­dzi na żąda­nie akto­ra. Przede wszyst­kim Przypadki uży­cia opi­su­ją zacho­wa­nie i reak­cje sys­te­mu a nie akto­ra i jego cele. Aktor z defi­ni­cji jest poza sys­te­mem” (jego cele tak­że). User Story to co naj­wy­żej kon­tek­sty akto­ra (patrz dia­gram powy­żej). Tragedią pew­ne­go duże­go pro­jek­tu jaki przy­szło mi rato­wać” było to, że opro­gra­mo­wa­nie, któ­re mia­ło tyl­ko przyj­mo­wać dane z pomo­cą jed­ne­go z 52 for­mu­la­rzy, zosta­ło opi­sa­ne z pomo­cą 421 przy­pad­ków użycia!

Kolejna waż­na rzecz: przy­pad­ki uży­cia opi­su­ją zacho­wa­nie (reak­cję) sys­te­mu ale nie opi­su­ją (nie odwo­łu­ją się) do jego wewnętrz­nej struk­tu­ry. Nie ma w UML cze­goś takie­go jak sys­te­mo­we przy­pad­ki uży­cia”, nie jest przy­pad­kiem uży­cia to, że sys­tem ma auto­ma­tycz­nie powia­da­miać użyt­kow­ni­ka z pomo­cą SMS” i masa innych podob­nych rze­czy”. To cecha mecha­ni­zmu, któ­ry w nim zaim­ple­men­to­wa­no (wyma­ga­no go), są to ele­men­ty mecha­ni­zmu dzia­ła­nia sys­te­mu (sce­na­riu­sze czy­li dia­gra­my sekwen­cji oraz struk­tu­ra czy­li dia­gra­my klas, kom­po­nen­tów i rozlokowania).

Trzeba też pamię­tać, że aku­rat ten dia­gram UML (przy­pad­ków uży­cia), może słu­żyć meto­dom innym, opar­tym na struk­tu­ral­nych opi­sach i auto­rzy spe­cy­fi­ka­cji UML mają to na uwadze:

The beha­viors of a UseCase can be descri­bed by a set of Behaviors (thro­ugh its ownedBehavior rela­tion­ship), such as Interactions, Activities, and StateMachines, as well as by pre-con­di­tions, post-con­di­tions and natu­ral lan­gu­age text whe­re appro­pria­te. It may also be descri­bed indi­rec­tly thro­ugh a Collaboration that uses the UseCase and its Actors as the Classifiers that type its parts. Which of the­se tech­ni­qu­es to use depends on the natu­re of the UseCase beha­vior as well as on the inten­ded reader.

Dlatego, jeże­li model ma zawie­rać kon­struk­cje nie­ty­po­we dla UML nale­ży to zade­kla­ro­wać. Standardową kon­struk­cją struk­tu­ral­ną (nie obiek­to­wą) pozo­sta­wio­ną przy dia­gra­mach przy­pad­ków uży­cia w UML są wydzie­lo­ne warun­ko­we i wspól­ne ele­men­ty kodu: «extend» i «inc­lu­de». Ale nale­ży pamię­tać, że to relik­to­we narzę­dzia” bo spe­cy­fi­ka­cja jasno mówi, że Przypadki Użycia (gene­ral­ne) w UML to nazwa­ne zacho­wa­nia Systemu nie odno­szą­ce się wewnętrz­nej architektury:

18.1.3.1 Use Cases and Actors […] UseCases defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal struc­tu­re.

Trzeba pamię­tać, że wyłą­cza­nie frag­men­tów sce­na­riu­szy (związ­ki inc­lu­de i extend) to wyłącz­nie struk­tu­ra­li­za­cja sce­na­riu­szy (kodu) przy­pad­ków uży­cia i opi­sy­wa­nie wewnętrz­nej struk­tu­ry kodu” a nie two­rze­nie nowych nie­za­leż­nych przy­pad­ków uży­cia”, kon­struk­cje mają­ca sens jeże­li sto­su­je­my roz­bu­do­wa­ne meto­dy tek­sto­we (język natu­ral­ny) lub tabe­la­rycz­ne doku­men­to­wa­nia wyma­gań (wte­dy te opi­sy lub tabe­le są koja­rzo­ne z tymi wydzie­lo­ny­mi przy­pad­ka­mi uży­cia). Warto pamię­tać, że orga­ni­za­cja OMG musi trzy­mać” kom­pa­ty­bil­ność wstecz (masa doku­men­ta­cji jaka powsta­ła i nadal ist­nie­je) oraz nadal uzna­je, że ten dia­gram nada­je się” do uży­cia w meto­dy­kach nie­obiek­to­wych, zorien­to­wa­nych tak­że na opi­sy (to chy­ba naj­bar­dziej uni­wer­sal­ny i otwar­ty dia­gram). Nie zmie­nia to fak­tu, że uży­wa­jąc tego dia­gra­mu w kon­tek­ście metod obiek­to­wych nale­ży trzy­mać się” para­dyg­ma­tu obiektowego.

Bardzo waż­ne jest zro­zu­mie­nie, że przy­pad­ki uży­cia to abs­trak­cja opi­su­ją­ca to cze­go ocze­ku­je­my od narzę­dzia (opro­gra­mo­wa­nie) a nie to jak to będzie fak­tycz­nie reali­zo­wa­ne, bo to opi­su­ją sce­na­riu­sze i sto­ry­bo­ar­dy. Aktor ma swo­je cele, uży­wa narzę­dzia dla okre­ślo­ne­go efek­tu, całość pra­cy jaką ma wyko­nać aktor ma swój kon­tekst np. w pro­ce­sach biz­ne­so­wych. Z per­spek­ty­wy mode­li MDA (mode­le CIM, PIM, PSM), dia­gram przy­pad­ków uży­cia to łącz­nik pomię­dzy CIM a PIM (kon­trakt okre­śla­ją­cy wyma­ga­ne usłu­gi zama­wia­ne­go oprogramowania).

Modelowanie zakresu

Autor mode­lu przy­pad­ków uży­cia powi­nien się więc sku­pić się na kontr­ak­cie na wyko­na­nie apli­ka­cji oraz na tym, że opi­su­je na tym eta­pie wyłącz­nie usłu­gi tej apli­ka­cji a nie inten­cje akto­ra. Jak już wspo­mnia­no w samej spe­cy­fi­ka­cji UML, dia­gram przy­pad­ków uży­cia nie słu­ży do ujaw­nia­nia (pla­no­wa­nia) struk­tu­ry (archi­tek­tu­ry) apli­ka­cji, od tego w UML są inne dia­gra­my. Nie słu­ży tak­że do poka­zy­wa­nia róż­nych spo­so­bów reali­zo­wa­nia wyma­gań jako­ścio­wych (poza-funk­cjo­nal­nych). Logowanie nie jest powo­dem zaku­pu opro­gra­mo­wa­nia, logo­wa­nie to jed­na z moż­li­wych imple­men­ta­cji cechy tyl­ko auto­ry­zo­wa­ny użyt­kow­nik może korzy­stać z apli­ka­cji”, co nie prze­szka­dza więk­szo­ści ama­to­rów uży­wa­nia tych dia­gra­mów (i auto­rów ksią­żek) potrak­to­wa­nia logo­wa­nia jako przy­pad­ku uży­cia apli­ka­cji. Dobrym testem sen­su umiesz­cza­nia takich rze­czy na dia­gra­mach przy­pad­ków uży­cia jest zada­wa­nie sobie pyta­nia: czy kupił byś tę apli­ka­cję tyl­ko dla tego jed­ne­go przy­pad­ku użycia?”

Należy zro­zu­mieć, że zwią­zek pomię­dzy abs­trak­cją apli­ka­cji a jej archi­tek­tu­rą wyglą­da np. tak:

Typowe apli­ka­cje pro­jek­to­wa­ne i reali­zo­wa­ne obec­nie w duchu obiek­to­we­go para­dyg­ma­tu, mają archi­tek­tu­rę zgod­ną z wzor­cem MVC. Komponenty Obsługa GUI (View w MVC) oraz Kontroler (Control w MVC) odpo­wia­da­ją za poza-funk­cjo­nal­ne cechy. To do cze­go (a nie jak) apli­ka­cja zosta­nie fak­tycz­nie uży­ta reali­zu­je Model (dzie­dzi­ny sys­te­mu), tu jest 100% logi­ki biz­ne­so­wej rozu­mia­nej jako wywo­ły­wa­ne usłu­gi oraz logi­ka biz­ne­so­wa ich realizacji.

Tak więc przy­pad­ka­mi uży­cia opi­su­je­my abs­trak­cję jaką jest Model Dziedziny Systemu. Są one wte­dy pro­ste, zawie­ra­ją sce­na­riusz, któ­ry w skró­cie ma postać: aktor ini­cju­je usłu­gę, sys­tem pre­zen­tu­je for­mu­larz do wypeł­nie­nia, aktor wypeł­nia go i potwier­dza, sys­tem potwier­dza ode­bra­nie danych i poka­zu­je wynik swo­jej pra­cy (lub komu­ni­ka­ty o błę­dach). Tu sku­pia­my się na opi­sie tego jakie usłu­gi są wyma­ga­ne od sys­te­mu. Kolejny etap to ?kom­pli­ko­wa­nie? każ­de­go sce­na­riu­sza w posta­ci pro­jek­to­wa­nia, dla każ­de­go przy­pad­ku uży­cia, któ­ry tego wyma­ga, róż­ne­go rodza­ju wizar­dów lub wpro­wa­dza­my ogra­ni­cze­nia zwią­za­ne z upraw­nie­nia­mi użyt­kow­ni­ków. Ten etap to pra­ca pro­jek­tan­tów UX i gra­fi­ków, spe­cja­li­stów od ergo­no­mii itp. (Źródło: Panowanie nad zło­żo­no­ścią czy­li gdzie są Przypadki Użycia czy­li MVVM-MVC | | Jarosław Żeliński IT-Consulting).

Owe baje­ry GUI a tak­że bez­piecz­ne, szy­fro­wa­ne” itp., są w pozo­sta­łych dwóch kom­po­nen­tach (View i Control).

Owszem spe­cy­fi­ka­cja UML nie zawie­ra recep­ty na dobry model” bo to tyl­ko opis języ­ka a nie meto­dy pro­jek­to­wa­nia. Jednak nie­wąt­pli­wie sto­so­wa­nie tego języ­ka jest tam opi­sa­ne, a para­dyg­ma­ty narzu­ca­ją” pew­ne kon­wen­cje, zna­cze­nie pojęć i logi­kę two­rze­nia mode­li z uży­ciem UML. Tworzenie takich dia­gra­mów jak ten poni­żej nie ma żad­ne­go sensu:

(źr. http://mirlew1.webd.pl/PSI/Projektowanie%20Systemów%20Informatycznych.htm)

UML, podob­nie jak np. język pol­ski, to zna­cze­nia pojęć (słow­nik języ­ka) i syn­tak­ty­ka (zasa­dy ich łącze­nia). Podobnie jak w języ­ku pol­skim tak i w UML, moż­na pisać zda­nia bez­sen­sow­ne i zara­zem popraw­ne gra­ma­tycz­nie. Poprawność dia­gra­mu to nie tyl­ko popraw­ne uży­cie poszcze­gól­nych sym­bo­li, to przede wszyst­kim sen­sow­ność tego co wyra­ża cały dia­gram (któ­ry jest odpo­wied­ni­kiem zda­nia w języ­ku tra­dy­cyj­nym, zda­nie myśl patrzy na kota” jest popraw­nym gra­ma­tycz­nie zda­niem i pozba­wio­nym sensu).

I tak, jeże­li dia­gram przy­pad­ków uży­cia jest czę­ścią metod opar­tych na języ­ku natu­ral­nym i tabe­lach (np. meto­dy pro­po­no­wa­ne przez Alistaira Cocbourn,a) moż­na (ma sens) korzy­sta­nie ze struk­tu­ry budo­wa­nej przez zwią­zek inc­lu­de” czy exc­lu­de”. W meto­dach obiek­to­wych, w zasa­dzie wyklu­cza­ją­cych współ­dzie­le­nie cze­go­kol­wiek mię­dzy kom­po­nen­ta­mi (her­me­ty­za­cja kom­po­nen­tów to klu­czo­wa cecha obiek­tyw­no­ści), ich sto­so­wa­nie jest poważ­nym błę­dem (podob­nie jak uży­wa­nie tych związ­ków do mode­lo­wa­nie kolej­no­ści czyn­no­ści” jako pro­ce­su, to jest gor­szy błąd).

Kolejnym czę­stym błę­dem jest sto­so­wa­nie (używanie/nadużywanie) na dia­gra­mach przy­pad­ków uży­cia związ­ków generalizacji/specjalizacji i dzie­dzi­cze­nia. Są to poję­cio­wo róż­ne związ­ki ozna­cza­ne takim samym sym­bo­lem (strzał­ka z pustym grotem).

9.2.3.2 Generalization
Generalizations defi­ne generalization/specialization rela­tion­ships betwe­en Classifiers. Each Generalization rela­tes a spe­ci­fic Classifier to a more gene­ral Classifier. Given a Classifier, the trans­i­ti­ve clo­su­re of its gene­ral Classifiers is often cal­led its gene­ra­li­za­tions, and the trans­i­ti­ve clo­su­re of its spe­ci­fic Classifiers is cal­led its spe­cia­li­za­tions. The imme­dia­te gene­ra­li­za­tions are also cal­led the Classifier?s parents, and whe­re the Classifier is a Class, its superClasses (see 11.4).
NOTE. The con­cept of parent (a gene­ra­li­za­tion rela­tion­ship betwe­en Classifiers) is unre­la­ted to the con­cept of owner (a com­po­si­tion rela­tion­ship betwe­en instances).

Specyfikacja UML (v.2.5) zawie­ra bogat­szy opis (pole­cam) jed­nak istot­ne jest to, że sym­bol ten oznacza:

  • zwią­zek poję­cio­wy (słow­ni­ko­wy) pomię­dzy poję­ciem ogól­niej­szym i jego szcze­gól­nym przy­pad­kiem (np. ssak jest uogól­nie­niem psa),
  • dzie­dzi­cze­nie to zwią­zek struk­tu­ral­ny pomię­dzy struk­tu­rą ogól­ną (abs­trak­cyj­nym szkie­le­tem) a jej kon­kret­ną posta­cią np. imple­men­ta­cją (struk­tu­ra dzie­dzi­czą­ca jest budo­wa­na na bazie szkie­le­tu struk­tu­ry od któ­rej dzie­dzi­czy swo­ją budo­wę), tak się korzy­sta np. z biblio­tek w two­rze­niu implementacji.

Warto też pamię­tać, że ele­ment ogól­ny z zasa­dy nie ma swo­ich imple­men­ta­cji bo jest abs­trak­cją (jeden z typo­wych i poważ­nych błę­dów w pro­jek­tach obiek­to­wych to tak zwa­ne woła­nie przod­ka” czy­li wywo­ły­wa­nie klas abs­trak­cyj­nych, ten i inne antyw­zor­ce: http://​kurs​.asp​net​mvc​.pl/​W​z​o​r​c​e​/​A​n​t​y​w​z​o​r​c​e​_​w​_​p​r​o​g​r​a​m​o​w​a​niu).

Spotykam się tak­że z teza­mi jako­by zwią­zek reali­za­cji był szcze­gól­nym przy­pad­kiem dzie­dzi­cze­nia – to już kom­plet­ne nie­zro­zu­mie­nie zna­cze­nia tych sym­bo­li i nie­czy­ta­nie spe­cy­fi­ka­cji UML. Realizacja to spe­cy­ficz­na (abs­trak­cyj­na) for­ma związ­ku zależ­no­ści” (depen­den­cy), poka­zu­ją­ca zwią­zek (zależ­ność) pomię­dzy opi­sem a imple­men­ta­cją wyko­na­ną na jego podstawie.

7.7.3.4 Realization
Realization is a spe­cia­li­zed Abstraction depen­den­cy betwe­en two sets of NamedElements, one repre­sen­ting a spe­ci­fi­ca­tion (the sup­plier) and the other repre­sen­ting an imple­men­ta­tion of that spe­ci­fi­ca­tion (the client). Realization can be used to model ste­pwi­se refi­ne­ment, opti­mi­za­tions, trans­for­ma­tions, tem­pla­tes, model syn­the­sis, fra­me­work com­po­si­tion, etc.

Jeżeli uznać, że cia­sto na naszym sto­le jest reali­za­cją prze­pi­su na to cia­sto z książ­ki kuchar­skiej, to jest to taki wła­śnie zwią­zek: reali­za­cja to zwią­zek pomię­dzy opi­sem (spe­cy­fi­ka­cją) a przed­mio­tem, któ­ry powstał na pod­sta­wie tego opisu.

Jaki sens (zna­cze­nie) mają związ­ki uogólnienia/dziedziczenia na dia­gra­mie przy­pad­ków uży­cia i czy w ogó­le mają? Przypadek uży­cia to kon­kret­na usłu­ga sys­te­mu. Dwa przy­pad­ki uży­cia połą­czo­ne takim związ­kiem moż­na więc inter­pre­to­wać tyl­ko jako sytu­ację, w któ­rej mamy szkie­let przy­pad­ku uży­cia i kil­ka – zgod­nych z tym szkie­le­tem – kon­kret­nych przy­pad­ków uży­cia. Ten ogól­ny z zasa­dy jest abs­trak­cyj­ny i nie moż­na (nie ma sen­su) łączyć go z jakim­kol­wiek akto­rem. Można sobie wyobra­zić sen­sow­ną kon­struk­cję zawie­ra­ją­cą abs­trak­cyj­ne­go akto­ra połą­czo­ne­go z abs­trak­cyj­nym przy­pad­kiem uży­cia, jako pewien sza­blon dla akto­rów kon­kret­nych i powią­za­nych z nimi kon­kret­ny­mi przy­pad­ka­mi uży­cia, ale nale­ży pamię­tać, że będzie pro­blem bo aso­cja­cja tak­że musia­ła­by mieć postać sza­blo­nu”… (pamię­taj­my, że dzie­dzi­cze­nie to prze­ję­cie wszyst­kich cech, związ­ków także).

Spotykam czę­sto dia­gra­my nazy­wa­ne dia­gra­ma­mi akto­rów, drze­wia­ste struk­tu­ry akto­rów, ich obro­na jako cze­goś sen­sow­ne­go będzie bar­dzo trud­na… Tym bar­dziej, że ludzie (role, sta­no­wi­ska) nie dzie­dzi­czą po sobie nicze­go. Związek pomię­dzy np. sze­fem dzia­łu a jego pod­wład­nym (a takie cza­sem widu­ję, mode­lo­wa­ne jako dziedziczenie/specjalizacja) nie ma abso­lut­nie żad­ne­go sen­su: pod­wład­ny ma inne umie­jęt­no­ści i upraw­nie­nia niż prze­ło­żo­ny. Owo dzie­dzi­cze­nie nie dzia­ła w żad­ną stro­nę: pod­wład­ny nie raz może robić to cze­go nie wol­no prze­ło­żo­ne­mu (mene­dżer bar­dzo rzad­ko może w peł­ni zastą­pić pod­wład­ne­go i odwrot­nie). Uznanie, że taki dia­gram mode­lu­je (opi­su­je) upraw­nie­nia w sys­te­mie” jest z podob­ne­go powo­du nie do obro­ny: upraw­nie­nia są przy­dzie­la­ne oso­bom a nie struk­tu­rom”.

Tak więc prze­cięt­ny (nie­try­wial­ny) sys­tem ma raczej kil­ka do kil­ku­na­stu (a nie kil­ka­dzie­siąt czy kil­ka­set) przy­pad­ków uży­cia i zło­żo­ny wewnętrz­ny mecha­nizm dzia­ła­nia. Mechanizm dzia­ła­nia sys­te­mu jest dokład­nie tym cze­go nie mode­lu­je­my na dia­gra­mie przy­pad­ków uży­cia, bo ten jest z zasa­dy tak zwa­ną czar­ną skrzyn­ką”. Z tego same­go powo­du nie ma sen­su sza­co­wa­nie kosz­tów wytwo­rze­nia opro­gra­mo­wa­nia na pod­sta­wie jego przy­pad­ków uży­cia. Rysowanie dia­gra­mów przy­pad­ków uży­cia bez klu­czo­we­go jego ele­men­tu jakim jest sub­ject” (sys­tem) też nie bar­dzo ma sens…

Nie raz spo­ty­kam się z ocze­ki­wa­nia­mi, że to duży sys­tem, spo­dzie­wam się dużo use casów”… nic bar­dziej błęd­ne­go… To tak­że powód, by nie sto­so­wać metod wyce­ny opar­tych na przy­pad­kach uży­cia w meto­dach obiek­to­wych bo tu są nieskuteczne… 

Trzy lata temu pisa­łem, że doku­men­to­wa­nie przy­pad­ków uży­cia to opis logi­ki sys­te­mu a nie mno­że­nie jaja­czek”:

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.. (Źródło: Wzorzec CRUD dla przy­pad­ków uży­cia i mikro­ser­wi­sy | | Jarosław Żeliński IT-Consulting)

Po szcze­gó­ły zapra­szam na moje szko­le­nia z ana­li­zy obiek­to­wej z uży­ciem nota­cji UML”.

Na zakończenie

Gorąco pole­cam pro­gra­mi­stom, by w ogó­le zaczę­li korzy­stać z UML a ana­li­ty­kom, by wyle­czy­li się z wie­lu mitów o UML roz­po­wszech­nia­nych nie­ste­ty na wie­lu, nie zawsze tanich, szko­le­niach i w wie­lu kiep­skich ??porad­ni­kach UML? (pisa­nych nie raz nawet przez uczel­nia­nych dok­to­rów i nie tyl­ko).?. Może wte­dy prze­sta­ną two­rzyć nie­przy­dat­ne deve­lo­pe­rom dokumentacje.

Source: UML for Java pro­gram­mers – Jarosław Żeliński IT-Consulting

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.