Diagram Przypadków Użycia

Wstęp

Jest to dia­gram, któ­ry na rów­ni z Diagramem Klas, budzi bar­dzo czę­sto ogrom­ne pro­ble­my inter­pre­ta­cyj­ne (patrz: Diagram klas…). Bardzo wie­lu auto­rów przy­pi­su­je temu dia­gra­mo­wi role, któ­rych on nie peł­ni, a nie raz pre­zen­to­wa­ne w sie­ci i lite­ra­tu­rze przy­kła­dy są nie­po­praw­ne. Znakomita więk­szość auto­rów tych dia­gra­mów uży­wa ich jako zbio­ru moż­li­wych klik­nięć” co jest cał­ko­wi­tym nie­zro­zu­mie­niem celu uży­cia i idei tego dia­gra­mu. Nawet jeże­li ktoś potrze­bu­je takiej mapy kli­ka­nia, to są do tego lep­szych narzę­dzia i meto­dy (przy­kład: Mapa ekra­nów apli­ka­cji – pod­sta­wa dobre­go UX/UI design). Tworzenie nie­zgod­nych z nota­cją dia­gra­mów przy­pad­ków uży­cia po pro­stu psu­je struk­tu­rę pro­jek­tu w narzę­dziach CASE, czy­niąc ją prak­tycz­nie bez­u­ży­tecz­ną w pro­jek­to­wa­nia archi­tek­tu­ry systemu. 

Najpierw opi­szę krót­ko dia­gram przy­pad­ków uży­cia posłu­gu­jąc sie cyta­ta­mi z ory­gi­nal­nej spe­cy­fi­ka­cji. Później opi­szę typo­we błędy. 

Czym jest Diagram Przypadków Użycia

Kluczowe są tu wyja­śnie­nia wstę­pu do roz­dzia­łu UseCases Specyfikacji UML :

18 UseCases
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.
[…]
18.1.3 Semantics
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 structure.

Powyższe wytłusz­cze­nia zebra­łem poni­żej, uwa­gi ozna­czo­ne „[…]” są moje:

  1. Przypadki uży­cia są spo­so­bem na uchwy­ce­nie [wska­za­nie] wyma­gań sta­wia­nych sys­te­mom, tzn. tego, co sys­te­my mają robić [powo­dy, dla któ­rych one powsta­ną, co będą reali­zo­wa­ły na rzecz i na żąda­nie Aktora].
  2. Każdy Przypadek Użycia repre­zen­tu­je okre­ślo­ny cel (powód), dla któ­re­go System jest projektowany. 
  3. Przypadek Użycia jest rodza­jem kla­sy­fi­ka­to­ra beha­wio­ral­ne­go, któ­ry repre­zen­tu­je dekla­ra­cję zbio­ru ofe­ro­wa­nych zacho­wań. [to zna­czy, że gru­pu­je okre­ślo­ny kon­tek­sto­wo powią­za­ny zbiór zacho­wań, są to alter­na­tyw­ne sce­na­riu­sze tego same­go przy­pad­ku użycia].
  4. Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] sys­te­mu bez odwo­ły­wa­nia się do jego wewnętrz­nej struktury. (!)

Są to pryn­cy­pia budo­wy tych diagramów.

Związki między Przypadkami Użycia

Extend

Specyfikacja UML:

An Extend is a rela­tion­ship from an exten­ding UseCase (the exten­sion) to an exten­ded UseCase (the extendedCase) that spe­ci­fies how and when the beha­vior defi­ned in the exten­ding UseCase can be inser­ted into the beha­vior defi­ned in the exten­ded UseCase. The exten­sion takes pla­ce at one or more spe­ci­fic exten­sion points defi­ned in the exten­ded UseCase. Extend is inten­ded to be used when the­re is some addi­tio­nal beha­vior that sho­uld be added, possi­bly con­di­tio­nal­ly, to the beha­vior defi­ned in one or more UseCases.

Związku «extend» moż­na użyć do poka­za­nia, że pew­ne ele­men­ty zacho­wa­nia Systemu reali­zo­wa­ne są warun­ko­wo. Te dodat­ko­we zacho­wa­nia są jed­nak z zasa­dy czę­ścią bazo­we­go Przypadku Użycia.

Autorzy spe­cy­fi­ka­cji UML jasno piszą, że: Szczegółowy spo­sób okre­śla­nia poło­że­nia punk­tu roz­sze­rzeń jest celo­wo nie­okre­ślo­ny. Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp. […] Zazwyczaj, przy­pa­dek uży­cia z ExtensionPoints skła­da się z zesta­wu drob­no­ziar­ni­stych opi­sów frag­men­tów zacho­wa­nia (sce­na­riu­sze), któ­re są naj­czę­ściej wyko­ny­wa­ne w pew­nej sekwen­cji. Taka seg­men­to­wa struk­tu­ra tek­stu opi­su dane­go przy­pad­ku uży­cia pozwa­la na roz­sze­rze­nie pier­wot­ne­go opi­su zacho­wa­nia przez dołą­cza­nie dodat­ko­wych opi­sów, frag­men­tów zacho­wa­nia, w odpo­wied­nich punk­tach wsta­wia­ne pomię­dzy pier­wot­ne frag­men­ty (punk­ty roz­sze­rzeń). Tak więc, roz­sze­rze­nie UseCase skła­da się zwy­kle z jed­ne­go lub wię­cej opi­sów frag­men­tów zacho­wa­nia, któ­re mają być wsta­wio­ne w odpo­wied­nie miej­sca roz­sze­rza­ne­go przy­pad­ku uży­cia. Rozszerzenia są więc spe­cy­fi­ka­cją wszyst­kich róż­nych punk­tów roz­sze­rzeń w danym przy­pad­ku uży­cia, w któ­rych moż­na umie­ścić dodat­ko­we zachowania.”

Innymi sło­wy, for­mal­nie moż­na na Diagramie Przypadków Użycia poka­zać, to że sce­na­riusz przy­pad­ku uży­cia jest podzie­lo­ny na frag­men­ty, któ­re są wyko­ny­wa­ne warun­ko­wo. Jest to jed­nak mode­lo­wa­nie sce­na­riu­sza zawie­ra­ją­ce­go instruk­cje if … then”. Tu przy­po­mnę więc klu­czo­wą zasa­dę, zapi­sa­ną w spe­cy­fi­ka­cji UML: Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Dlatego wie­lu auto­rów zwra­ca uwa­gę na pew­ne, takie jak ta, nie­kon­se­kwen­cje w specyfikacji. 

Include

Specyfikacja UML:

The Include rela­tion­ship is inten­ded to be used when the­re are com­mon parts of the beha­vior of two or more UseCases. This com­mon part is then extrac­ted to a sepa­ra­te UseCase, to be inc­lu­ded by all the base UseCases having this part in com­mon. As the pri­ma­ry use of the Include rela­tion­ship is for reu­se of com­mon parts, what is left in a base UseCase is usu­al­ly not com­ple­te in itself but depen­dent on the inc­lu­ded parts to be meaning­ful. This is reflec­ted in the direc­tion of the rela­tion­ship, indi­ca­ting that the base UseCase depends on the addi­tion but not vice versa.

Innymi sło­wy: jeże­li dwa Przypadki Użycia mają pew­ne wspól­ne frag­men­ty zacho­wa­nia, moż­na taki frag­ment wyjąć przed nawias”, ten frag­ment jest na dia­gra­mie repre­zen­to­wa­ny tak­że jako Przypadek Użycia, jed­nak jest to nie­sa­mo­dziel­ny frag­ment, sta­no­wią­cy część wspól­ną co naj­mniej dwóch PU bazo­wych i on sam z sie­bie nie repre­zen­tu­je samo­dziel­ne­go zacho­wa­nia. Ten wspól­ny, wyłą­czo­ny frag­ment, łączy­my z PU bazo­wy­mi związ­kiem «inc­lu­de».

Tak więc związ­ki «inc­lu­de» i «extend» owszem nadal są w spe­cy­fi­ka­cji UML, jed­nak Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp.” i ktoś może chcieć taki tek­sto­wy for­mat zobra­zo­wać na Diagramie. 

Konsekwencje

Diagram Przypadków uży­cia ma rodo­wód w meto­dy­ce struk­tu­ral­nej (sto­so­wa­nie instruk­cji go to” i sub­ro­uti­ne” w pro­gra­mo­wa­niu struk­tu­ral­nym). Związki «extend» i «inc­lu­de» mają wła­śnie taki rodo­wód i nadal są w nota­cji UML, gdyż Diagram Przypadków Użycia jest nadal popu­lar­nym narzę­dziem w meto­dach struk­tu­ral­nych. Jest też nie­kon­se­kwen­cją spe­cy­fi­ka­cji UML, co widać w jej tre­ści, gdzie na począt­ku roz­dzia­łu auto­rzy spe­cy­fi­ka­cji UML zwra­ca­ją jed­nak uwa­gę, że Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Więc sto­so­wa­nie powyż­szych związ­ków jest relik­tem metod struk­tu­ral­nych, i nie nale­ży ich sto­so­wać w pro­jek­tach zorien­to­wa­nych obiek­to­wo, tym bar­dziej, że jest to łama­nie pod­sta­wo­wej zasa­dy para­dyg­ma­tu obiek­to­we­go jaką jest hermetyzacja. 

Autorzy spe­cy­fi­ka­cji nota­cji UML, takim oto przy­kła­dem pod­su­mo­wu­ją roz­dział 18. Przypadki Użycia:

Jak widać celem pro­jek­to­wa­nia ban­ko­ma­tu są: Wypłata, Wpłata, Przelew, a tak­że: Rejestrowanie ban­ko­ma­tu (w sie­ci) i Udostępnianie listy trans­ak­cji. Detale tych dzia­łań i kolej­ność ich reali­za­cji nie są przed­mio­tem tego mode­lu, nie ma tu związ­ków «inc­lu­de» ani «extend», mimo, że np. trzy klu­czo­we ope­ra­cje wyma­ga­ją uży­cia kar­ty płat­ni­czej i kodu PIN (owszem, wspól­na część, ale są to jed­nak deta­le sce­na­riu­szy a nie osob­ne PU).

Traktując więc PU zgod­nie z jego pod­sta­wo­wą, przy­to­czo­ną powy­żej defi­ni­cją, jako: okre­ślo­ny cel (powód), dla któ­re­go System jest pro­jek­to­wa­ny”, uzna­je­my, że celem apli­ka­cji biz­ne­so­wej jest np. Rejestrowanie Zamówień czy Fakturowanie, a nie to, że Drukujemy doku­ment”, szu­ka­my fak­tu­ry” czy wpro­wa­dza­my NIP kon­tra­hen­ta”. Pokazanie dru­ko­wa­nia jako wyłą­czo­nej czę­ści wspól­nej, lub roz­sze­rze­nia, PU Faktura i Zamówienie (sto­su­jąc zwią­zek «inc­lu­de» lub «extend»), czy też wydzie­la­nie na dia­gra­mie PU Wybór klien­ta z listy kon­tra­hen­tów”, to pro­jek­to­wa­nie archi­tek­tu­ry i dro­ga do klę­ski tego dia­gra­mu. To, że kom­po­nent reali­zu­ją­cy dru­ko­wa­nie będzie osob­nym ele­men­tem archi­tek­tu­ry tego sys­te­mu zapew­ne jest praw­dą, ale Diagram PU, jak już wie­my, to nie jest model archi­tek­tu­ry sys­te­mu. Nie jest to tak­że spe­cy­fi­ka­cja pro­ce­su biznesowego.

Obiektowo-zorientowane modelowanie systemu

W arty­ku­le Use Case 2.0 opi­sy­wa­łem kon­cep­cję obiek­to­we­go podej­ścia w pro­jek­to­wa­niu zorien­to­wa­nym na Przypadki Użycia, opra­co­wa­ną przez jed­ne­go z współ­twór­ców UML: Ivara Jacobsona . W arty­ku­le Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych opi­sa­łem pro­jek­to­wa­nie opro­gra­mo­wa­nia opar­te na obiek­to­wym para­dyg­ma­cie i wzor­cach pro­jek­to­wych takich jak mikro­ser­wi­sy. Cytowałem mię­dzy inny­mi ten diagram:

Po pra­wej stro­nie powyż­sze­go widzi­my archi­tek­tu­rę zorien­to­wa­ną na mikro­ser­wi­sy. Jest to typo­we i zna­ne od lat kom­po­nen­to­we podej­ście z her­me­ty­za­cją kom­po­nen­tów, reali­zu­ją­cych usłu­gi apli­ka­cji . Bloki [MS] (micro­se­rvi­ces) to nic inne­go jak kom­po­nen­ty reali­zu­ją­ce Przypadki Użycia tego sys­te­mu. Każdy PU ma wła­sną imple­men­ta­cję (i bazę danych, dane [DB] tak­że nie są współ­dzie­lo­ne mię­dzy przy­pad­ka­mi uży­cia). Komponent [UI] to zagre­go­wa­ne na jed­nym ekra­nie wywo­ła­nia usług, czy­li głów­ne menu sys­te­mu. Tak więc Diagram Przypadków Użycia, to model tego głów­ne­go menu sys­te­mu, a nie model imple­men­ta­cji usług (nie archi­tek­tu­ra kodu i nie pro­ces biznesowy).

Podsumowanie

Na poniż­szym dia­gra­mie po lewej stro­nie, poka­za­no for­mal­nie popraw­ny dia­gram przy­pad­ków uży­cia. Z per­spek­ty­wy pro­jek­to­wa­nia zorien­to­wa­ne­go na kom­po­nen­ty, oraz zacho­wa­nia zasa­dy mówią­cej, że ten dia­gram nie słu­ży do mode­lo­wa­nia wewnętrz­nej archi­tek­tu­ry sys­te­mu, popraw­na pro­jek­to­wo jest wer­sja poka­za­na po pra­wej stronie:

Warto też wie­dzieć, że w kon­se­kwen­cji powyż­sze­go, łącze­nie Aktora z wydzie­lo­ny­mi, nie­sa­mo­dziel­ny­mi, opi­sa­mi zacho­wań repre­zen­to­wa­ny­mi przez przy­pad­ki uży­cia 4 i 5, jest pozba­wio­ne logi­ki (podob­nie jak tyl­ko jeden PU połą­czo­ny związ­kiem «inc­lu­de»).

Więc jak i gdzie poka­zać owe sce­na­riu­sze PU? Osobno na dia­gra­mach aktyw­no­ści (role kom­po­nen­tów) lub na dia­gra­mach sekwen­cji (wywo­ły­wa­ne ope­ra­cje inter­fej­sów). (Patrz arty­kuł: Diagram aktyw­no­ści – kie­dy).

Powyższa for­ma (dia­gram po pra­wej stro­nie) ma tak­że prak­tycz­ną zale­tę: Zamawiający zro­zu­mie ten dia­gram. Diagram o po lewej, jest już prak­tycz­ną utra­tą komu­ni­ka­cji z Zamawiającym, bo mało któ­ry z nich stu­diu­je spe­cy­fi­ka­cję UML. Specyfikacja po lewej pro­wa­dzi tak­że do ogrom­ne­go zawy­ża­nia osza­co­wa­nia wycen, gdyż mia­ry opar­te na tak zwa­nych punk­tach funk­cyj­nych, trak­tu­ją każ­dy PU jako samo­dziel­ną, kom­plet­ną jed­ną jed­nost­kę kosztową. 

A co może­my zna­leźć w sie­ci? Poniżej kil­ka przy­kła­dów wraz ze źró­dła­mi, ich oce­nę pozo­sta­wię czytelnikom. 

przykład 1

Major elements of business use case UML diagram.

(w nota­cji UML nie ma i nigdy nie było poję­cia biz­ne­so­wy przy­pa­dek uży­cia”, to poję­cie jest relik­tem meto­dy RUP, Rational Unified Process, z cza­sów gdy nie było nota­cji BPMN i BMM).

przykład 2

Major elements of UML use case diagram.

przykład 3

przykład 4

(źr.: Podstawy mode­lo­wa­nia w języ­ku UML, dr hab. Bożena Woźna-Szcześniak, prof. UJD, Uniwersytet Humanistyczno-Przyrodniczy im. Jana Długosza w Częstochowie, http://​www​.wozna​.org/​s​t​u​d​e​n​t​s​/​2​018 – 2019/uml/UML03.pdf)

Dla porów­na­nia do pobra­nia: Biblioteka

przykład 5

przykład 6

(źr.: Projektowanie Systemów Komputerowych, Laboratoria/Projekty, Krzysztof Regulski, AGH, WIMiIP, DIAGRAM PRZYPADKÓW UŻYCIA – USE CASE MODEL, https://home.agh.edu.pl/~regulski/psk/cw/01_UseCase.pdf)

___

Na koniec pole­cam też arty­kuł: Ile przy­pad­ków uży­cia?

Źródła

D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
architektura kontrukcja

Projektowanie i dokumentowanie architektury oprogramowania – trzy książki

Architektura

Projekty infor­ma­tycz­ne się roz­ra­sta­ją, cała bran­ża ewo­lu­uje. Ostatnie 20 lat doświad­czeń poka­za­ło, że owszem sztu­ką jest stwo­rzyć i wdro­żyć opro­gra­mo­wa­nie, ale jesz­cze więk­szą sztu­ką jest je kon­ser­wo­wać, zmie­niać i roz­wi­jać. Wiele firm bory­ka się z powta­rza­ny­mi dłu­go­trwa­ły­mi i kosz­tow­ny­mi ana­li­za­mi przed­wdro­że­nio­wy­mi” poprze­dza­ją­cy­mi każ­dy kolej­ny pro­jekt wdra­ża­nia zmian. To sku­tek bra­ku aktu­al­nej doku­men­ta­cji posia­da­ne­go sys­te­mu. To jak pla­no­wa­nie nowej budo­wy w mie­ście nie mając aktu­al­nych pla­nów urba­ni­stycz­nych tego mia­sta: każ­dy nowy pro­jekt to ponow­ne doku­men­to­wa­nie sta­nu obec­ne­go, tyl­ko dla­te­go, że ktoś nie udo­ku­men­to­wał zmian wpro­wa­dzo­nych ostat­nim razem (być może poprzed­nio udo­ku­men­to­wał jakiś stan zasta­ny, jed­nak nie aktu­ali­zo­wał tej doku­men­ta­cji). Podobno deve­lo­per pamię­ta co mają jego klien­ci, jed­nak zmia­na deve­lo­pe­ra sta­je się wte­dy trud­na, a nie raz nie­moż­li­wa z powo­du złej umo­wy (pra­wo autor­skie) i bra­ku doku­men­ta­cji (wie­dza w gło­wach pro­gra­mi­stów, wdro­że­niow­ców, bywa, że nigdzie), to efekt zna­ny jako ven­dor lock-in.

Rozwiązaniem jest doku­men­ta­cja sys­te­mu. Co jest głów­nym wyzwa­niem w two­rze­niu doku­men­ta­cji sys­te­mu? Ustalenie kom­pro­mi­su mię­dzy szcze­gó­ło­wo­ścią doku­men­ta­cji a cza­sem i kosz­tem jej opra­co­wa­nia a potem aktu­ali­za­cji. Tym kom­pro­mi­sem jest archi­tek­tu­ra: struk­tu­ra opi­su­ją­ca co i do cze­go słu­ży: ele­men­ty sys­te­mu i ich wza­jem­ne powią­za­nia, ale bez anga­żo­wa­nia się w doku­men­to­wa­nie deta­li tych ele­men­tów (her­me­ty­za­cja). To dla­te­go bar­dzo przy­dat­ne jest kom­po­nen­to­we podej­ście do pro­jek­to­wa­nia i obiek­to­wy para­dyg­mat two­rze­nia opro­gra­mo­wa­nia.

Dzisiaj kil­ka słów o trzech książ­kach, każ­da z nich była na tym blo­gu krót­ko recen­zo­wa­na, razem sta­no­wią moim zda­niem pod­sta­wo­wy zestaw pro­jek­tan­ta. Pod poję­ciem pro­jek­to­wa­nia rozu­mie­my two­rze­nie pro­jek­tu sys­te­mu czy­li doku­men­to­wa­nie tego jakim ma być, lub jakim jest i co w nim zmienimy.

Dokumentowanie architektury

Ta książ­ka to rodzaj pod­su­mo­wa­nia. We wstę­pie czytamy:

Architektura opro­gra­mo­wa­nia – kon­cep­cyj­ny klej, któ­ry spa­ja każ­dą fazę pro­jek­tu, dla jego wie­lu inte­re­sa­riu­szy – jest powszech­nie uzna­wa­na za kry­tycz­ny ele­ment współ­cze­sne­go roz­wo­ju opro­gra­mo­wa­nia. Praktycy coraz czę­ściej prze­ko­nu­ją się, że poświę­ca­nie szcze­gól­nej uwa­gi archi­tek­tu­rze sys­te­mu opro­gra­mo­wa­nia przy­no­si wymier­ne korzy­ści. Bez archi­tek­tu­ry, któ­ra jest odpo­wied­nia dla roz­wią­zy­wa­ne­go pro­ble­mu, pro­jekt będzie się poty­kał, a naj­praw­do­po­dob­niej zakoń­czy się nie­po­wo­dze­niem. Ale nawet przy dosko­na­łej archi­tek­tu­rze, jeśli nie jest ona dobrze rozu­mia­na i prze­ka­zy­wa­na, pro­jekt ma małe szan­se powodzenia. 

Książka Documenting Software Architectures, dostar­cza naj­bar­dziej kom­plet­nych i aktu­al­nych wska­zó­wek, nie­za­leż­nie od języ­ka czy nota­cji, jak ująć archi­tek­tu­rę w powszech­nie zro­zu­mia­łej for­mie. Bazując na swo­im boga­tym doświad­cze­niu, auto­rzy naj­pierw poma­ga­ją zde­cy­do­wać, jakie infor­ma­cje nale­ży udo­ku­men­to­wać, a następ­nie, za pomo­cą wska­zó­wek i przy­kła­dów (w róż­nych nota­cjach, w tym UML), poka­zu­ją, jak wyra­zić archi­tek­tu­rę, aby inni mogli na jej pod­sta­wie z powo­dze­niem budo­wać, uży­wać i utrzy­my­wać sys­tem. Książka zawie­ra zasa­dy two­rze­nia solid­nej doku­men­ta­cji, cele i stra­te­gie doku­men­ta­cji, wido­ki i sty­le archi­tek­to­nicz­ne, doku­men­ta­cję inter­fej­sów opro­gra­mo­wa­nia i zacho­wa­nia opro­gra­mo­wa­nia oraz sza­blo­ny do zbie­ra­nia i orga­ni­zo­wa­nia infor­ma­cji w celu stwo­rze­nia spój­ne­go pakietu. 

Zdaniem auto­rów klu­czem są poję­cia: ele­ment sys­te­mu, jego cechy i związ­ki mię­dzy tymi ele­men­ta­mi. Zwracają uwa­gę na to, że zwią­zek mię­dzy ele­men­ta­mi to ich wza­jem­ne wywo­ły­wa­nie się (współ­pra­ca to nie rela­cje a uży­cie). Mając model poja­wia się dru­ga waż­na rzecz: adre­sa­ci infor­ma­cji czy­li per­spek­ty­wy opi­su sys­te­mu. Dlatego kolej­na istot­na rzecz to treść i for­ma pre­zen­to­wa­nia kontekstu. 

Kolejna książ­ka to Architektura Oprogramowania w Praktyce . Ze wstęu: Wielokrotnie nagra­dza­na i cie­szą­ca się dużym zain­te­re­so­wa­niem Architektura opro­gra­mo­wa­nia w prak­ty­ce, wyda­nie trze­cie, zosta­ła zna­czą­co zmie­nio­ne, aby odzwier­cie­dlić naj­now­sze osią­gnię­cia w tej dzie­dzi­nie. W książ­ce po raz kolej­ny przed­sta­wio­no kon­cep­cje i naj­lep­sze prak­ty­ki archi­tek­tu­ry opro­gra­mo­wa­nia – struk­tu­rę sys­te­mu opro­gra­mo­wa­nia oraz spo­sób, w jaki jego ele­men­ty mają ze sobą współdziałać. 

W tym wyda­niu auto­rzy sku­pi­li się na kon­cep­cji roz­wo­ju archi­tek­tu­ry. Każdy cykl roz­wo­ju poka­zu­je, w jaki spo­sób archi­tek­tu­ra wpły­wa na okre­ślo­ny kon­tekst, w któ­rym odgry­wa klu­czo­wą rolę, oraz jak jest kształ­to­wa­na przez ten kon­tekst. Konteksty te obej­mu­ją śro­do­wi­sko tech­nicz­ne, cykl życia pro­jek­tu, pro­fil biz­ne­so­wy orga­ni­za­cji oraz prak­ty­ki zawo­do­we archi­tek­ta. Autorzy znacz­nie roz­sze­rzy­li tak­że omó­wie­nie atry­bu­tów jako­ści, któ­re pozo­sta­ją cen­tral­nym ele­men­tem ich filo­zo­fii archi­tek­tu­ry – każ­de­mu z atry­bu­tów poświę­ci­li cały roz­dział – oraz roz­sze­rzy­li omó­wie­nie wzor­ców architektonicznych.” 

Autorzy cie­ka­wie pre­zen­tu­ją to jak i po co powsta­je doku­men­ta­cja: pro­ce­so­wo. Streszczają (pre­zen­tu­ją) treść książ­ki w posta­ci kil­ku pro­stych mode­li procesów:

Ta for­ma bar­dzo mi się spodo­ba­ła: poka­zu­je bodź­ce, model (arti­fact) logi­ki i efekt uzy­ska­ny. Generalnie auto­rzy w swo­jej książ­ce pre­zen­tu­ją prak­tycz­ne aspek­ty doku­men­to­wa­nia opro­gra­mo­wa­nia i sto­so­wa­nia tej doku­men­ta­cji. Pamiętajmy tak­że, że doku­men­ta­cja opro­gra­mo­wa­nia to przede wszyst­kim jego modele. 

Na koniec zosta­wi­łem książ­kę naj­star­szą: Large-Scale Software Architecture .

Jak piszą auto­rzy, celem pro­jek­to­wa­nia (doku­men­to­wa­nia) archi­tek­tu­ry dużych apli­ka­cji jest uchwy­ce­nie i opi­sa­nie prak­tycz­nych metod jego zobra­zo­wa­nia (udo­ku­men­to­wa­nia), mają­cych na celu zwięk­szyć efek­tyw­ność komu­ni­ka­cji zespo­łów pro­gra­mi­stów i ich zro­zu­mie­nia kon­tek­stu systemu.

W tej książ­ce auto­rzy poka­zu­ją, jak wyko­rzy­stać archi­tek­tu­rę opro­gra­mo­wa­nia już jako narzę­dzie na eta­pie zarzą­dza­nia roz­wo­jem apli­ka­cji, nie tyl­ko jako powy­ko­naw­czą doku­men­ta­cję po pod­ję­ciu wszyst­kich decy­zji pro­jek­to­wych. Prezentują w swo­jej książce:

  • Zwięzły opis wyko­rzy­sta­nia języ­ka UML w archi­tek­tu­rze dużych aplikacji, 
  • Architekturę opro­gra­mo­wa­nia i zasa­dy jej projektowania,
  • Zwracają uwa­gę na jej nie­za­leż­ność od tech­no­lo­gii i dostawców.
Struktura projektu UML

Tę książ­kę moż­na pod­su­mo­wać tak: każ­da archi­tek­tu­rę nale­ży doku­men­to­wać od ogó­łu do szcze­gó­łu, każ­dy model powi­nien być pro­sty i zwię­zły ale mode­li tych może być wie­le, każ­dy sys­tem to jego klu­czo­wa rola, jego wewnętrz­na struk­tu­ra i zacho­wa­nia jego skła­do­wych ele­men­tów oraz jego poję­cio­wy dzie­dzi­no­wy ogól­ny opis. 

Podsumowanie

Powyższe opi­sy to klu­czo­we cechy każ­dej z tych trzech pozy­cji. Moją inten­cją było pole­ce­nie tych trzech pozy­cji jako zesta­wu pre­zen­tu­ją­ce­go dość kom­plet­ną wie­dzę na temat sta­nu wie­dzy na temat pro­jek­to­wa­nia opro­gra­mo­wa­nia sku­pia­ją­ce­go się na jego archi­tek­tu­rze. Jako efekt uzy­sku­je­my doku­men­ta­cję rela­tyw­nie szczu­płą obję­to­ścio­wo, więc będzie czy­ta­na. Stosowanie stan­dar­du nota­cyj­ne­go, jakim jest UML, uzy­sku­je­my sze­ro­ki zasięg odbior­ców i uni­wer­sal­ność. Zwracają na to uwa­gę auto­rzy wszyst­kich tych trzech pozycji. 

Ostatnia pozy­cja to kla­sy­ka kom­po­nen­to­we­go podej­ścia do pro­jek­to­wa­nia. Pierwsze dwie powsta­ły kil­ka lat po fascy­na­cji auto­rów zwin­nym podej­ściem (agi­le). Podobnie jak Scott Ambler , odkry­li że zbyt­nie przy­kła­da­nie wagi do dzia­ła­ją­ce­go opro­gra­mo­wa­nia” na nie­ko­rzyść jego doku­men­ta­cji, powo­du­je szko­dy na kolej­nych eta­pach cyklu życia pro­duk­tu jakim jest aplikacja. 

Żadne opro­gra­mo­wa­nie nie powsta­je tyl­ko na jeden dzień, będzie komuś słu­ży­ło mie­sią­ca­mi, lata­mi, a świat nie stoi w miej­scu. sta­wia­nie tezy, że celem two­rze­nia opro­gra­mo­wa­nia jego powsta­nie jest szko­dli­we. Kluczem jest cykl życia opro­gra­mo­wa­nia, a jego doku­men­ta­cja to jedy­na for­ma komu­ni­ko­wa­nia się zmie­nia­ją­cych się osób, lata­mi zaan­ga­żo­wa­nych w utrzy­ma­nie i roz­wój aplikacji. 

Te trzy książ­ki to moim zda­niem mały zbiór rze­tel­nej wie­dzy, któ­ry powi­nien pomóc każ­de­mu począt­ku­ją­ce­mu i zagu­bio­ne­mu junio­ro­wi ana­li­zy biz­ne­so­wej” w nauce two­rze­nia wyso­kiej jako­ści doku­men­ta­cji. To tak­że wie­dza przy­dat­na dla doświad­czo­nych ana­li­ty­ków i pro­jek­tan­tów: zawsze war­to wie­dzieć jak robią to inni, mają­cy ogrom­ny doro­bek. Dokumentacja sys­te­mu to jedy­ne trwa­łe źró­dło wie­dzy o nim, jed­nak zła i nie­ak­tu­al­na doku­men­ta­cja jest gor­sza od jej braku… 

Źródła

Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Merson, P., Nord, R., & Stafford, J. (2015). Documenting Software Architecture (Second, Vol. 1 – 1). Pearson Education, Inc.
Bass, L., Clements, P., & Kazman, R. (2013). Software archi­tec­tu­re in prac­ti­ce (3rd ed). Addison-Wesley.
Ambler, S. W. (2002). Agile mode­ling. John Wiley & Sons.
Ambler, S. W. (2004). The object pri­mer. Agile Model-Driven Development with UML 2.0 (Third Edition). Cambridge University Press.
Garland, J., & Anthony, R. (2003). Large-sca­le softwa­re archi­tec­tu­re: a prac­ti­cal guide using UML. J. Wiley.

Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy

Artykuł ma dwie czę­ści. Pierwsza część jest adre­so­wa­na do kadr zarząd­czych, cały arty­kuł (obie czę­ści) do osób zaj­mu­ją­cych się pro­jek­to­wa­niem roz­wią­zań. (22.04.2022 dopi­sa­łem Dodatek).

Wstęp

Mamy ogól­no­świa­to­wą sieć Internet, apli­ka­cje lokal­ne i w chmu­rze, apli­ka­cje naszych kon­tra­hen­tów i apli­ka­cje cen­tral­nych urzę­dów. Wszystkie one współ­pra­cu­ją i wymie­nia­ją dane, czy­li są zin­te­gro­wa­ne. Dlatego inte­gra­cja sta­ła się jed­nym z obli­ga­to­ryj­nych wyma­gań każ­de­go sys­te­mu informatycznego. 

Pogodzenie się z tym, że świat już nigdy nie będzie tak pro­sty jak 40 lat temu jest nie­unik­nio­ne. Podobnie jak pogo­dze­nie się z tym, że cza­sy jed­nej cen­tral­nej apli­ka­cji też ode­szły do lamu­sa. Praktyka zaś poka­zu­je, że idea zbu­do­wa­nia wszyst­kich funk­cjo­nal­no­ści jako zin­te­gro­wa­nej apli­ka­cji na jed­nej współ­dzie­lo­nej bazie danych jest utopią. 

Czytaj dalej… Integracja sys­te­mów ERP jako źró­dło prze­wa­gi ryn­ko­wej. Projektowanie REST API i sce­na­riu­szy”

Cyfrowa Transformacja a dziedzictwo IT

Wstęp

Transformacja cyfro­wa, jest przez dostaw­ców tech­no­lo­gii infor­ma­tycz­nych, naj­czę­ściej defi­nio­wa­na jako inte­gra­cja tech­no­lo­gii cyfro­wej z dzia­łal­no­ścią fir­my. Poniżej wybra­ne defi­ni­cje, któ­re naj­czę­ściej znaj­du­je­my w sieci:

Transformacja cyfro­wa defi­niu­je się jako inte­gra­cję tech­no­lo­gii cyfro­wej ze wszyst­ki­mi obsza­ra­mi funk­cjo­no­wa­nia fir­my. Dzięki niej moż­li­we jest wyko­rzy­sta­nie gro­ma­dzo­nych danych do two­rze­nia inno­wa­cyj­nych usług i posze­rze­nia dotych­cza­so­wej oferty.

Cyfrowa trans­for­ma­cja to nic inne­go jak inte­gra­cja tech­no­lo­gii cyfro­wej we wszyst­kich obsza­rach dzia­łal­no­ści fir­my oraz zmia­na spo­so­bu, w jaki dzia­łasz i zapew­niasz klien­tom war­tość. To tak­że zmia­na kul­tu­ro­wa, któ­ra wyma­ga od orga­ni­za­cji cią­głe­go rzu­ca­nia sobie wyzwań, eks­pe­ry­men­to­wa­nia, ale rów­nież godze­nia się z poraż­ką. Transformacja cyfro­wa jest pro­ce­sem nie­unik­nio­nym, nie­za­leż­nie od roz­mia­ru przedsiębiorstwa.

Transformacja cyfro­wa odno­si się do pro­ce­sów i stra­te­gii wyko­rzy­sta­nia tech­no­lo­gii cyfro­wej do rady­kal­nej zmia­ny spo­so­bów, w jakie przed­się­bior­stwa pro­wa­dzą dzia­łal­ność i obsłu­gu­ją klien­tów. Termin ten stał się w epo­ce cyfry­za­cji wszech­obec­ny. Spowodowane jest to tym, że każ­da orga­ni­za­cja ? nie­za­leż­nie od jej roz­mia­ru i bran­ży ? coraz bar­dziej opie­ra się na danych i tech­no­lo­gii, aby zwięk­szać wydaj­ność swo­jej dzia­łal­no­ści i zapew­niać war­tość swo­im klientom.

Ogólne idee wie­dzy jako fun­da­men­tu nowej gospo­dar­ki i infor­ma­cji jako naj­waż­niej­sze­go zaso­bu wypeł­nia­ją się tre­ścią i rodzą nowe poję­cia: smart devi­ces i weare­ables, Big Data, mobil­ność, chmu­ra obli­cze­nio­wa, plat­for­my spo­łecz­no­ścio­we, bio- i nano­tech­no­lo­gie, Internet of Things, ener­gia odna­wial­na czy sha­re economy?

Dominuje inte­gra­cja tech­no­lo­gii cyfro­wej z dzia­łal­no­ścią fir­my”. Osobiście jestem zwo­len­ni­kiem tezy, że nie tyle fir­my co gene­ral­nie czło­wie­ka. Czym jest tu sama inte­gra­cja tech­no­lo­gii z dzia­łal­no­ścią czło­wie­ka? Maszyny nie myślą, jed­nak prze­twa­rza­ją dane. Człowiek nada­je zna­cze­nie danym, potra­fi je tak­że prze­kształ­cać. Cyfrowa trans­for­ma­cja to pro­ces prze­no­sze­nia prze­twa­rza­nia danych z czło­wie­ka na maszy­ny: to już nie my ludzie wyszu­ku­je­my doku­men­ty w archi­wach, robi to elek­tro­nicz­ne archi­wum, nie my ludzie obsłu­gu­je­my klien­tów za ladą, coraz czę­ściej robi to Internetowy Sklep. Cyfrowa trans­for­ma­cja to wła­śnie pro­ces prze­no­sze­nia czę­ści pra­cy z czło­wie­ka na maszyny. 

Aby trans­for­ma­cja cyfro­wa była w ogó­le moż­li­wa, musi­my prze­nieść te dane (tre­ści, infor­ma­cje) z papie­ru do kom­pu­te­ra”, w spo­sób nie­nisz­czą­cy obec­nych moż­li­wo­ści i pozwa­la­ją­cy na two­rze­nie nowych. 

Trzeba też zni­we­lo­wać posia­da­ny dług tech­no­lo­gicz­ny. Dług tech­no­lo­gicz­ny to posia­da­ne dzie­dzic­two, to zapóź­nie­nie, to pozo­sta­wa­nie w tyle za trwa­ją­cym postę­pem tech­no­lo­gicz­nym. Dług taki ma bar­dzo wie­le firm. Co z nim zro­bić i jak z nie­go wyjść?

Czytaj dalej… Cyfrowa Transformacja a dzie­dzic­two IT”

Odpowiedzialność administratora systemu

Wstęp

pra­wie 10 lat temu pisałem:

Często spo­ty­kam się z róż­ny­mi meto­da­mi uwzględ­nia­nia pra­wa w ??doku­men­ta­cji wyma­gań?. Jakim wyma­ga­niem jest ??zgod­ność z obo­wią­zu­ją­cym pra­wem?? I trud­niej­sze pyta­nie: czy zmia­na pra­wa to zmia­na wyma­gań? Inny aspekt pro­ble­mu to ana­li­za i defi­ni­cja (opis) tej zgod­no­ści z pra­wem. Spotkać moż­na się z meto­dą pole­ga­ją­cą na trak­to­wa­niu każ­de­go (mają­ce­go wpływ na sys­tem) para­gra­fu np. usta­wy jako wyma­ga­nia. Problem zgod­no­ści opro­gra­mo­wa­nia z pra­wem ma dwa aspek­ty. Zgodność opro­gra­mo­wa­nia z pra­wem pole­ga na tym, że ??opro­gra­mo­wa­nie nie może ogra­ni­czać sto­so­wa­nia pra­wa to jest nie może wymu­szać swo­imi ogra­ni­cze­nia­mi dzia­łań nie­zgod­nych z pra­wem?. Ja oso­bi­ście reko­men­du­ję roz­cią­gnię­cie tej defi­ni­cji na ??ani nie powin­no pozwa­lać na łama­nie pra­wa?. Tu jed­nak wie­lu uwa­ża, że ??zama­wiam narzę­dzie i uży­wam jak chcę, na swo­ja odpo­wie­dzial­ność?. Coś w tym jest, war­to jed­nak zosta­wić ??włącz­nik?. (źr.: Prawo a wyma­ga­nia … )

Dzisiaj czy­tam:

To admi­ni­stra­tor odpo­wia­da za zabez­pie­cze­nia sys­te­mów ? a więc tak­że za to, że pra­cow­nik zdo­łał sko­pio­wać dane oso­bo­we na zewnętrz­ny nośnik. […] W oce­nie WSA w toku postę­po­wa­nia PUODO pra­wi­dło­wo usta­lił, iż w SGGW dopusz­czo­no się licz­nych uchy­bień, w szcze­gól­no­ści nie prze­pro­wa­dzo­no wła­ści­wej ana­li­zy ryzy­ka i oce­ny zagro­żeń już na eta­pie pro­jek­to­wa­nia sys­te­mów (pri­va­cy by design) oraz nie wdro­żo­no odpo­wied­nich środ­ków zapew­nia­ją­cych bez­pie­czeń­stwo danych, w tym przed moż­li­wo­ścią wyeks­por­to­wa­nia danych z sys­te­mu na zewnątrz.(źr.: Odpowiedzialność admi­ni­stra­to­ra za naru­sze­nie zasa­dy pri­va­cy by design)

Rzecz w tym, że admi­ni­stra­tor, w rozu­mie­niu pra­wa, to tak­że pod­miot zle­ca­ją­cy powsta­nie opro­gra­mo­wa­nia, któ­re go wspie­ra w reali­za­cji jego obo­wiąz­ków, a jed­nym z nich jest egze­kwo­wa­nie usta­lo­nych zasad.

Czytaj dalej… Odpowiedzialność admi­ni­stra­to­ra sys­te­mu”

Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Jarosław Żeliński Date. (2021). Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go – aspek­ty eko­no­micz­ne: Recenzja. https://​doi​.org/​1​0​.​1​3​1​4​0​/​R​G​.​2​.​2​.​2​2​2​9​2​.​0​1​927

Wstęp

Publikacja Jędrzeja Wieczorkowskiego (dalej: recen­zo­wa­ne opra­co­wa­nie) o poniż­szym tytu­le uka­za­ła się w 2015 roku:

Jędrzej Wieczorkowski
Instytut Informatyki i Gospodarki Cyfrowej
Szkoła Główna Handlowa w Warszawie
Metody kasto­mi­za­cji opro­gra­mo­wa­nia stan­dar­do­we­go: aspek­ty eko­no­micz­ne.

Autor recen­zo­wa­ne­go tek­stu odno­si sie do skut­ków eko­no­micz­nych, pomi­ja jed­nak cał­ko­wi­cie skut­ki praw­ne kasto­mi­za­cji kodu opro­gra­mo­wa­nia, któ­re mają wpływ na kosz­ty i ochro­nę war­to­ści inte­lek­tu­al­nych. Autor pisze we wstępie:

Celem niniej­sze­go opra­co­wa­nia jest ana­li­za moż­li­wych metod kasto­mi­za­cji sys­te­mów infor­ma­tycz­nych zarzą­dza­nia prze­pro­wa­dzo­na z eko­no­micz­ne­go punk­tu widze­nia, w tym w szcze­gól­no­ści opła­cal­no­ści sto­so­wa­nia opro­gra­mo­wa­nia stan­dar­do­we­go i wyko­rzy­sta­nia poszcze­gól­nych metod jego adap­ta­cji. […] Kastomizację sys­te­mu infor­ma­tycz­ne­go ogól­nie nale­ży rozu­mieć jako jego adap­ta­cję do potrzeb kon­kret­ne­go pod­mio­tu. M. Flasiński okre­ślił kasto­mi­za­cję, jako ?kon­fi­gu­ra­cję sys­te­mu, osa­dze­nie w sys­te­mie za pomo­cą prac pro­gra­mi­stycz­nych dodat­ko­wych funk­cjo­nal­no­ści oraz mody­fi­ka­cję ist­nie­ją­cych funk­cjo­nal­no­ści systemu?

Dostarczanie opro­gra­mo­wa­nia i jego wdra­ża­nie, wią­że się jego ewen­tu­al­nym dosto­so­wa­niem do potrzeb użyt­kow­ni­ka. Autor powyż­sze­go opra­co­wa­nia, sto­su­jąc nie­pre­cy­zyj­ne defi­ni­cje pojęć, wpro­wa­dza czy­tel­ni­ka w błąd, opi­su­jąc przy­czy­ny i kon­se­kwen­cje zwią­za­ne z sze­ro­ko poję­tym dosto­so­wa­niem opro­gra­mo­wa­nia do potrzeb użyt­kow­ni­ka. Niestety z tego doku­men­tu korzy­sta wie­lu praw­ni­ków, nazy­wa­jąc go nie raz nawet wykład­nią”.

Czytaj dalej… Kastomizacja opro­gra­mo­wa­nia stan­dar­do­we­go, aspek­ty eko­no­micz­ne: Recenzja i reko­men­da­cje”