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/

Business Knowledge Blueprints

Ronald G. Ross 

Ronald G. Ross jest auto­rem lub współ­au­to­rem wie­lu opra­co­wań na temat mode­li poję­cio­wych i zarzą­dza­nia wie­dzą . Jest tak­że współ­za­ło­ży­cie­lem Business Rule Solution LLC, oraz współ­twór­cą spe­cy­fi­ka­cji i nota­cji SBVR .

Książka

Najnowsze z powyż­szych opra­co­wań to rodzaj pod­su­mo­wa­nia pew­nej czę­ści dorob­ku autora.

Modele poję­cio­we są czę­sto mylo­ne z pro­jek­to­wa­niem rela­cyj­ne­go mode­lu danych, a bywa gorzej, gdy są utoż­sa­mia­ne z mode­lem dzie­dzi­ny sys­te­mu” w pro­jek­tach doty­czą­cych two­rze­nia apli­ka­cji okre­śla­nych jako„obiektowe”.

Książka trak­tu­je o mode­lach poję­cio­wych, i autor defi­niu­je je jako: 

model poję­cio­wy: upo­rząd­ko­wa­ny zbiór pojęć i związ­ków mię­dzy nimi

Podstawowym związ­kiem mię­dzy poję­cia­mi (nazwa­mi) jest fakt (pre­dy­kat: zwią­zek zda­nio­twór­czy) łączą­cy poję­cia w popraw­ne i praw­dzi­we zdania. 

Przykład: poję­cia «pies» oraz «listo­nosz» to nazwy słow­ni­ko­we. Połączone fak­tem (pre­dy­ka­tem) two­rzą zda­nie, np.: „ «Pies» szcze­ka na «listo­no­sza» ” (z uwzględ­nie­niem pol­skiej flek­sji, «szcze­ka (na)» to fakt – pre­dy­kat). Jest to zda­nie popraw­ne a tak­że zda­nie praw­dzi­we: jest praw­dą, że pies szcze­ka na listo­no­sza” (to rela­cja), albo: jest moż­li­we, że pies szcze­ka na listo­no­sza” (jest praw­dą to, że to może się to wyda­rzyć). Ważna rzecz: poję­cia to nie sło­wa, to to co opi­su­ją defi­ni­cje tych pojęć (patrz: trój­kąt semio­tycz­nysemio­ty­ka).

Budowanie takich zdań to kon­tro­la (testo­wa­nie) popraw­no­ści mode­lu poję­cio­we­go, test spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści mode­lu poję­cio­we­go. Poprawny model poję­cio­wy (name­spa­ce) to pod­sta­wo­wy waru­nek np. póź­niej­szej spój­no­ści całe­go sys­te­mu zarzą­dza­nia infor­ma­cją (tak­że dany­mi), doku­men­ta­mi (gro­ma­dzą dane), meta­da­ny­mi (opi­su­ją dane). 

Podtytuł książ­ki to: About Vocabulary & Concept Models (O słow­nic­twie i mode­lach poję­cio­wych). Warto wie­dzieć, że zna­ko­mi­ta więk­szość nie­uda­nych pro­jek­tów i wdro­żeń opro­gra­mo­wa­nia to sku­tek błę­dów w mode­lach poję­cio­wych (nazew­nic­two).

Nazewnictwo to nie tyl­ko nazwy doku­men­tów, tabel i pól (ety­kiet danych), to tak­że same dane czy­li nazwy sta­no­wią­ce war­to­ści pól for­mu­la­rzy: nazwy miast, nazwi­ska, nazwy przed­mio­tów, pro­duk­tów, itp. Dawno temu już skoń­czy­ły się cza­sy, gdy kom­pu­te­ry tyl­ko liczy­ły” (to wte­dy powsta­ła idea rela­cyj­ne­go mode­lu danych). Obecnie kom­pu­te­ry prze­twa­rza­ją dane nie będą­ce licz­ba­mi, dane niestrukturalne. 

Zarządzanie wie­dzą to nie są obliczenia.

Autor pisze: akt two­rze­nia danych (zapi­sy­wa­nie infor­ma­cji) to akt komu­ni­ka­cji: to prze­kaz (wia­do­mość) dla przy­szłych czy­tel­ni­ków, odbior­ców tych danych. Dlatego komu­ni­kat (treść), musi (powi­nen) być zro­zu­mia­ły i jed­no­znacz­ny. Jedynym spo­so­bem zagwa­ran­to­wa­nia tego jest popraw­ność uży­te­go zaso­bu pojęć (słow­nic­twa). To wła­śnie jest miej­sce na ana­li­zy i pro­jek­to­wa­nie: naj­pierw mode­li poję­cio­wych a potem mode­li i struk­tur danych. 

Pewną wadą moim zda­niem jest wpro­wa­dze­nie przez auto­ra nowej sym­bo­li­ki dla gene­ra­li­za­cji (budo­wa­nie tak­so­no­mii) w posta­ci pogru­bio­nej linii”. Jednak każ­dy kto zna UML i pozna SBVR, moim zda­niem, bez pro­ble­mu sobie z tym pora­dzi (Visual Paradigm tak wła­śnie zro­bił: gene­ra­li­za­cje na mode­lach fak­tów obra­zo­wa­ne są jako strzał­ki z zamknię­tym gro­tem, zna­ne z UML, podej­ście to opi­su­je Dodatek C do spe­cy­fi­ka­cji SBVR). 

Modele pojęciowe

Modele poję­cio­we są bar­dzo czę­sto mylo­ne z mode­lem pro­ce­sów. Jest to kon­se­kwen­cja sto­so­wa­nia związ­ków skie­ro­wa­nych (aso­cja­cje skie­ro­wa­ne w UML, mode­le poję­cio­we są wyra­ża­ne jako kon­tek­sto­we dia­gra­my klas). Zdanie pies szcze­ka na listo­no­sza” to nie pro­cess (biz­ne­so­wy), to zda­nie spraw­dza­ją­ce popraw­ność uży­tych nazw (pies, listo­nosz) i rozu­mie­nia tych pojęć (komu­ni­kat) oraz praw­dzi­wość zda­nia jako takie­go. Przykład: 

Diagram fak­tów nota­cji SBVR, przy­kład wery­fi­ka­cji pojęć pies i listo­nosz oraz zda­nia pies szcze­ka na listo­no­sza”. (dia­gra­my opra­co­wa­ne z uży­ciem Visual Paradigm).

Powyższy dia­gram zawie­ra dwa poję­cia słow­ni­ko­we: pies, listo­nosz (for­mal­nie powin­ny być tak­że w słow­ni­ku i mieć swo­je jed­no­znacz­ne defi­ni­cje). Górna część dia­gra­mu to gra­ficz­na for­ma, omó­wio­ne­go wyżej, zda­nia pies szcze­ka na listo­no­sza”. Typowe zda­nia to co naj­mniej dwie nazwy połą­czo­ne pre­dy­ka­tem (fak­tem: szcze­ka­nie to fakt). Dolna część dia­gra­mu to zda­nie zbu­do­wa­ne z jed­nej nazwy i pre­dy­ka­tu: Pies szcze­ka”. To tak­że jest popraw­ne zda­nie. Metoda i sys­tem nota­cyj­ny, two­rze­nia mode­li poję­cio­wych (opar­ta na logi­ce pre­dy­ka­tów) zosta­ła opi­sa­na i opu­bli­ko­wa­na jako stan­dard SBVR (patrz tak­że OWL: Web Ontology Language) .

Autor w książ­ce dokład­nie opi­su­je róż­ni­cę mię­dzy mode­lem poję­cio­wym a mode­lem danych: model poję­cio­wy i model danych do róż­ne modele!

Model danych i model poję­cio­wy to nie to samo!

Autor poka­zu­je tak­że zasto­so­wa­nie dia­gra­mów fak­tów do mode­lo­wa­nia ontologii.

Na zakończenie

Słownik jest bar­dzo waż­ny bo sta­no­wi fun­da­ment logi­ki biz­ne­so­wej wyra­żo­nej w posta­ci reguł biz­ne­so­wych (busi­ness rules, patrz arty­kuł z 2015 roku: Reguły biz­ne­so­we, decy­zje i poję­cia). Autor dokład­nie opi­su­je meto­dy two­rze­nia słow­ni­ków i dia­gra­mów fak­tów, w dodat­kach jest omó­wio­ny przy­kład kom­plet­ne­go mode­lu wraz ze słow­ni­kiem. Tu, jako uzu­peł­nie­nie, pole­cam książ­kę prof. Hołówki o logi­ce i two­rze­niu defi­ni­cji pojęć .

Gorąco zachę­cam do lek­tu­ry tej książ­ki, moim zda­niem jest to typo­wa pozy­cja must have” dla każ­de­go ana­li­ty­ka i pro­jek­tan­ta sys­te­mów infor­ma­cyj­nych. Więcej na ten temat napi­sa­łem w 2016 roku w arty­ku­le: Model poję­cio­wy, model danych, model dzie­dzi­ny sys­te­mu.

Literatura

OMG​.org. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). 334. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/
Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
OMG​.org. (2014, September). Ontology Definition Metamodel (ODM).
Al-Fedaghi, S. (2020). Conceptual Modeling of Time for Computational Ontologies. 14.
Hołówka, T. (2012). Kultura logicz­na w przy­kła­dach (Wydawnictwo Naukowe PWN, Ed.). Wydawnictwo Naukowe PWN.
Ross, R. G. (2013). Business rule con­cepts: get­ting to the point of know­led­ge (4th Ed). Business Rule Solutions.
Ross, R. G., & Lam, G. S. W. (2011). Building busi­ness solu­tions: busi­ness ana­ly­sis with busi­ness rules. Business Rule Solutions.
Diagram: Jeden model dwa konteksty Diagram przedstawia obiekty biznesowe - dokumenty () pochodzące z dwóch różnych kontaktów. Na schemacie mamy trzy klasyfikatory reprezentujące dokumenty i ich struktury. W celu usunięcia kolizji pojęć opisanej przez Fowlera (FOWLER 2014) obiekty funkcjonujące w dwóch różnych kontaktach zostały rozdzielone na dwie kontekstowe przestrzenie pojęciowe: Sprzedaż oraz Serwis. W kontekście Sprzedaż pojęcia Klient i Produkt zostały użyte do nazwania obiektów biznesowych będących przedmiotami mającymi tożsamość. W kontekście Serwis pojęcia te (klient i produkt) ca jedynie cechami (atrybutami) obiektu biznesowego Uszkodzenie, słowa te (pojęcia) stanowią jedynie nazwy atrybutów a konkretne nazwy klienta i produktu stanowią wartość tych atrybutów i jako obiekty nie mają tu tożsamości (value UML i value object w DDD). Tak więc problem kolizji nazewnictwa została rozwiązany, warto tu zwrócić, że zbudowanie jednej spójnej relacyjnej bazy danych dla wszystkich pojęć obu tych dziedzin jest niemożliwe bez dodatkowych zabiegów z nazewnictwem.

Modelowanie architektury HLD i LLD usług aplikacji – modelowanie podsystemów

Wstęp

Tym razem krót­ki arty­kuł na temat pew­nej cie­ka­wej kon­struk­cji. Została ona opi­sa­na przez Rebekę Wirfs-Brock w 1999 roku . Pomysł nie zdo­był sobie wte­dy raczej zbyt dużej popu­lar­no­ści, jed­nak obec­nie, w dobie wzor­ców opar­tych o mikro­ser­wi­sy i mikro apli­ka­cje, ma szan­sę wró­cić do łask. Ja sto­su­ję go już od pew­ne­go cza­su. Skróty HLD i LLD to odpo­wied­nio: High-Level Design (pro­jekt wyso­kie­go pozio­mu) i Low-Level Design (pro­jekt niskie­go pozio­mu). Są to pozio­my abs­trak­cji w mode­lu PIM. 

Czytaj dalej… Modelowanie archi­tek­tu­ry HLD i LLD usług apli­ka­cji – mode­lo­wa­nie pod­sys­te­mów”

Dlaczego nie używam poczty elektronicznej do komunikacji w projektach

Wstęp

Od lat spo­ty­kam się w lite­ra­tu­rze z zakre­su zarzą­dza­nia, z kry­ty­ką pocz­ty elek­tro­nicz­nej jako narzę­dziem zarzą­dza­nia czym­kol­wiek (patrz: Sabotaż…2013). Poczta elek­tro­nicz­na (podob­nie jak pakie­ty biu­ro­we w ogó­le) jest typo­wym przy­kła­dem mak­sy­my: uła­twie­nie nie zawsze jest ulep­sze­niem. W klien­cie pocz­ty elek­tro­nicz­nej zarów­no treść jak i spo­sób adre­so­wa­nia (co i do kogo, kopia, itp.) nie pod­le­ga żad­nej stan­da­ry­za­cji ani restryk­cji (pocz­ta elek­tro­nicz­na czę­sto słu­ży do wypro­wa­dza­nia danych z fir­my). Jak dodać do tego fakt, że załącz­ni­ki są nie­wi­docz­ne w narzę­dziach do lokal­ne­go wyszu­ki­wa­nia, że mamy na ser­we­rach fil­try anty­spa­mo­we któ­rych regu­ły nie pod­da­ją się kon­tro­li użyt­kow­ni­ków, że nie panu­je­my nad tym co inni mają w swo­ich skrzyn­kach pocz­to­wych, to mamy obraz abso­lut­ne­go bra­ku pano­wa­nia nad infor­ma­cją w orga­ni­za­cji i chaosu. 

Swego cza­su dr Paweł Litwiński, praw­nik, napi­sał kry­tycz­ny arty­kuł o zasto­so­wa­niu pocz­ty elek­tro­nicz­nej przez adwo­ka­tów. Jego tekst był sze­ro­ko cyto­wa­ny przez wie­lu auto­rów, tu jeden z takich arty­ku­łów. Wybrałem kil­ka waż­nych kwestii:

Praktyka poka­zu­je, że wie­lu adwo­ka­tów i rad­ców praw­nych korzy­sta z dar­mo­wych skrzy­nek, tak­że tych wprost zastrze­ga­ją­cych sobie pra­wo do ska­no­wa­nia korespondencji. […]

Konflikt pomię­dzy obo­wiąz­kiem ochro­ny infor­ma­cji a warun­ka­mi narzu­co­ny­mi w regu­la­mi­nach dar­mo­wych usług to jed­no. Czym innym są kwe­stie bezpieczeństwa.[…]

? Na logi­kę, lepiej żeby o mate­ria­łach obję­tych tajem­ni­cą adwo­kac­ką nie dowie­dział się żaden dostaw­ca, ale z dru­giej stro­ny, rzad­ko któ­rej kan­ce­la­rii praw­nej uda się samo­dziel­nie skon­fi­gu­ro­wać ser­wer pocz­to­wy tak, aby był rów­nie bez­piecz­ny i nie­awa­ryj­ny, jak infra­struk­tu­ra np. Gmaila. Oczywiście, moż­na zle­cić to zewnętrz­nej pol­skiej fir­mie, ale wte­dy mamy ten sam pro­blem z zaufa­niem, co w przy­pad­ku korzy­sta­nia z ser­we­rów np. Google ? zwra­ca uwa­gę Piotr Konieczny, eks­pert ds. cyber­bez­pie­czeń­stwa z ser­wi­su Niebezpiecznik​.pl. ? Abstrahując więc od aspek­tów praw­nych, roz­pa­tru­jąc pro­blem wyłącz­nie na płasz­czyź­nie bez­pie­czeń­stwa, tj. ochro­ny skrzyn­ki przed ata­ka­mi, moim zda­niem praw­ni­kom nie­dy­spo­nu­ją­cym budże­tem na bez­pie­czeń­stwo takim, jaki posia­da­ją pro­fe­sjo­nal­ni dostaw­cy usług pocz­to­wych, lepiej i pro­ściej było­by wyko­rzy­stać infra­struk­tu­rę np. Google?a ? doda­je. Jego zda­niem praw­ni­cy powin­ni przede wszyst­kim roz­wa­żyć moż­li­wość szy­fro­wa­nia kore­spon­den­cji. Wtedy zarów­no dar­mo­wy, jak i płat­ny dostaw­ca usług nie będzie w sta­nie jej podej­rzeć. Szyfrowanie jest bez wąt­pie­nia naj­bez­piecz­niej­szym spo­so­bem, ale wią­że się z koniecz­no­ścią dostar­cze­nia klu­cza czy hasła odbior­cy, a ten nie zawsze godzi się na takie nie­do­god­no­ści. Co wię­cej, klien­ci kan­ce­la­rii sami czę­sto korzy­sta­ją z dar­mo­wych skrzy­nek. ? I nie rozu­mie­ją, dla­cze­go pouf­ne infor­ma­cje nie powin­ny być na nie prze­sy­ła­ne. Moim obo­wiąz­kiem jest wów­czas poin­for­mo­wać takie­go klien­ta o zagro­że­niach z tym zwią­za­nych. Oczywiście jeśli mimo tego będzie chciał uży­wać takiej skrzyn­ki do kore­spon­den­cji ze mną, to nie mogę mu tego zabro­nić ? zwra­ca uwa­gę dr Paweł Litwiński. ? Z dru­giej stro­ny są rów­nież klien­ci, któ­rzy wręcz wyma­ga­ją, by w kore­spon­den­cji z nimi uży­wać jedy­nie skrzy­nek zało­żo­nych na ich ser­we­rach. Tak restryk­cyj­ną mają poli­ty­kę bez­pie­czeń­stwa. Chcąc dla nich pra­co­wać, adwo­kat czy rad­ca musi przy­stać na te warun­ki ? doda­je ekspert.

(patrz: Darmowe e‑maile nie dla praw­ni­ków. Dostawca pocz­ty ska­nu­je jej zawar­tość – Forsal​.pl)

W 2013 roku pisałem:

W więk­szo­ści przy­pad­ków treść umiesz­cza­na jest w tre­ści ema­il??a lub w załącz­ni­ku (załą­czo­ne doku­men­ty). Jeżeli treść ema­ila nie jest szy­fro­wa­na (a gene­ral­nie nie jest, o ile sami o to nie zadba­my, co jed­nak, jak poka­zu­je cyto­wa­ny Niebezpiecznik, nie jest try­wial­ne) nasza kore­spon­den­cja, prze­cho­dząc przez publicz­ne łącza sie­ci Internet, jest jaw­na i łatwa do pod­słu­chi­wa­nia. Jak uczy­nić naszą kore­spon­den­cję (bar­dziej) niejawną?

(Patrz: Bezpieczny jak ema­il czy­li wca­le – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Przypomnę klu­czo­we tezy powyż­sze­go arty­ku­łu. Generalnie waż­nych doku­men­tów nie nale­ży prze­sy­łać jako załącz­ni­ki z dwóch powo­dów: nie wie­my co sie z nimi dzie­je po dro­dze, nie wie­my czy zosta­ły dostar­czo­ne, i kie­dy, gdyż bar­dzo wie­lu użyt­kow­ni­ków ema­il ma wyłą­czo­ne auto­ma­tycz­ne ode­sła­nie potwier­dze­nia w swo­jej poczcie, co skut­ku­je tym, że po pro­stu jest to nie­wia­ry­god­na for­ma potwier­dza­nia. Poniżej sche­mat poka­zu­ją­cy dro­gę pocz­ty email: 

Droga pocz­ty elektronicznej.

Środkowa część (Internet) to tak­że poten­cjal­ne kolej­ne pośred­ni­czą­ce ser­we­ry, nie wie­my co sie na nich dzie­je. Tak więc dwie klu­czo­we wady ema­il to poten­cjal­ne ska­no­wa­nie tre­ści po dro­dze oraz brak kon­tro­li nad dorę­cze­niem. Czy moż­na ina­czej? Owszem: do prze­ka­zy­wa­nia doku­men­tów moż­na użyć repo­zy­to­rium (ser­we­ra pli­ków) z kon­tro­lo­wa­nym dostę­pem. Poniżej sche­mat blo­ko­wy archi­tek­tu­ry nie­ma­ją­cej ww. wad prze­sy­ła­nia doku­men­tów mailem:

Dokumenty prze­ka­zy­wa­ne za pośred­nic­twem repozytorium

Dokumenty w dro­dze” nie opusz­cza­ją repo­zy­to­rium: z nasze­go kom­pu­te­ra ładu­je­my je na ser­wer wska­zu­jąc ewen­tu­al­nie okre­ślo­ne­go adre­sa­ta (lub robi to mecha­nizm obsłu­gu­ją­cy wymia­nę tre­ści pomię­dzy uczest­ni­ka­mi), okre­ślo­na oso­ba dosta­je mailem infor­ma­cje, że jest dla niej doku­ment, żeby go pobrać musi się zalo­go­wać do repo­zy­to­rium. W efek­cie treść (plik) nie jest nigdzie nara­żo­na na ska­no­wa­nie, podej­rze­nie go itp. Tu ema­il słu­ży wyłącz­nie do moni­to­wa­nia fak­tu, że jest doku­ment do nas adre­so­wa­ny i że moż­na do pobrać, co zosta­nie odnotowane.

Mając nawet pro­ste, dostęp­ne przez inter­net, repo­zy­to­rium, moż­na umie­ścić tam dowol­ny plik i mailem poin­for­mo­wać adre­sa­ta (wcze­śniej zakła­da­my mu tam kon­to), że powi­nien pobrać plik. Serwer reje­stru­je zarów­no moment zała­do­wa­nia pli­ku jak i jego pobra­nia, co jest gwa­ran­to­wa­nym zna­kiem cza­su nada­nia i dorę­cze­nia. Minus takie­go roz­wią­za­nia to ręcz­na obsłu­ga całe­go pro­ce­su, plus to pano­wa­nie nad wszyst­kim i bezpieczeństwo.

Sprawdzonym, od daw­na, na ryn­ku pomy­słem jest sys­tem work­flow z udo­stęp­nia­nym repo­zy­to­rium, auto­ma­ty­zu­ją­cy cały ten proces: 

Architektura sys­te­mu wymia­ny danych z Repozytorium.

Uogólniając moż­na go przed­sta­wić jako ser­wer usług:

System work­flow ste­ro­wa­ny regułami

System dorę­czeń to tak napraw­dę funk­cjo­nal­ność apli­ka­cji typu work­flow zorien­to­wa­ne­go na zada­nia (task mana­ger), mają­cej moż­li­wość udo­stęp­nie­nia jej kon­tra­hen­tom. Funkcjonalność taką ma wie­le sys­te­mów CRM, sys­te­mów help­desk, wie­le repo­zy­to­riów pozwa­la na skon­fi­gu­ro­wa­nie sub­skryp­cji zda­rzeń powią­za­nych z doku­men­ta­mi. Zbudowanie takie­go sys­te­mu opar­te­go na regu­łach, zamiast na macier­zach praw dostę­pu do doku­men­tów, zna­ko­mi­cie uprasz­cza całość i dodat­ko­wo pod­no­si bez­pie­czeń­stwo (bar­dzo uła­twia wdra­ża­nie RODO) . Ciekawą funk­cjo­nal­no­ścią jest moż­li­wość blo­ko­wa­nia moż­li­wo­ści pobra­nia doku­men­tu na lokal­ny dysk, dozwo­lo­ne jest jedy­nie prze­glą­da­nie tre­ści w prze­wi­ja­nym oknie (ofe­ru­ją to nie­któ­re tego typu systemy).

Systemy tego typu są tak­że wdra­ża­ne jako zamien­nik pocz­ty elek­tro­nicz­nej wewnątrz orga­ni­za­cji. Tam gdzie pod­sta­wo­wym wewnętrz­nym sys­te­mem komu­ni­ka­cji jest pocz­ta elek­tro­nicz­na pro­ble­mem są giną­ce doku­men­ty oraz brak dostę­pu do doku­men­tów (skrzy­nek) osób nie­do­stęp­nych, będą­cych poza fir­mą (chro­ba, dele­ga­cja itp.). Generalnie pocz­ta jako skład doku­men­tów” ma tę pod­sta­wo­wą wadę, że doku­men­ty są roz­pro­szo­ne i zarza­dza­nie nimi w jed­no­li­ty spo­sób jest nie­moż­li­we. Stosowanie współ­dzie­lo­nych dys­ków nie roz­wią­zu­je cał­ko­wi­cie pro­ble­mu, bo po pierw­sze nie da się budo­wać reguł dostę­pu, po dru­gie wymia­na doku­men­tów z oso­ba­mi spo­za fir­my jest bar­dzo trud­na (np. wyma­ga uru­cho­me­nia VPN co jest trud­ne, wyma­ga inge­ren­cji w cudzy kom­pu­ter, i coraz czę­ściej nie jest to moż­li­we w wie­lu firmach).

Tak więc pocz­ta elek­tro­nicz­na, jako swo­bod­na komu­ni­ka­cja mię­dzy ludź­mi owszem, jest przy­dat­na. Jednak jako narzę­dzie do zarzą­dza­nia komu­ni­ka­cją, prze­pły­wem tre­ści, doku­men­tów ich wydań i dorę­czeń, jest bar­dzo zawod­na. A war­to wie­dzieć, że praw­na ochro­na know-how w UE, czy­li w Polsce tak­że, to przede wszyst­kim obo­wią­zek ochro­ny tre­ści przez pod­miot chro­nią­cy (udo­stęp­nia­ją­cy) takie dane. Dlatego dość kurio­zal­nie wyglą­da każ­da fir­ma, któ­ra wysy­ła­jąc mailem umo­wę o pouf­no­ści (NDA) wysy­ła potem tak­że mailem te pouf­ne” dokumenty…

Na zakończenie

Rozwiązań, reali­zu­ją­cych opi­sa­ne wyżej funk­cje, nie bra­ku­je. Główną blo­ka­dą ich wdra­ża­nia jest przy­zwy­cza­je­nie do swo­bo­dy. Jednak pocz­ta elek­tro­nicz­na jest kla­sycz­nym przy­kła­dem tego, że uła­twie­nie nie zawsze jest ulep­sze­niem. O wdra­ża­niu sys­te­mów work­flow, panu­ją­cych nad komu­ni­ka­cją i jej pouf­no­ścią, mówi się podob­nie jak o sys­te­mach kopii zapa­so­wych: fir­my dzie­lą się na te, któ­re wdro­ży­ły sku­tecz­ny work­flow i na te któ­re wdrożą.

Kilka przy­kła­dów (nie ofe­ru­ję tych sys­te­mów, to nie są reko­men­da­cje a przykłady):

  • Biuro księ­go­we, któ­re mnie obsłu­gu­je, ode­szło od pro­ste­go sys­te­mu FK i komu­ni­ka­cji mailo­wej (prze­ka­zy­wa­nie doku­men­tów kosz­to­wych, wysy­ła­nie klien­tom dekla­ra­cji podat­ko­wych, rapor­tów itp.), obec­nie korzy­sta z podat​ki​po​dat​ki​.pl.
  • Zaczynałem jak wie­lu od pocz­ty elek­tro­nicz­nej, po kil­ku przy­go­dach z doku­men­ta­mi w pro­jek­tach (kto, co, kie­dy i komu) szyb­ko wdro­ży­łem dar­mo­wy, potem sup­por­to­wa­ny osTicket (na począ­tek bar­dzo dobry i łatwy we wdrożeniu). 
  • Z uwa­gi na spe­cy­fi­kę mojej pra­cy (pra­ca pole­ga­ją­ca na zbie­ra­niu danych i two­rze­niu rapor­tów z ana­liz, ich recen­zo­wa­nie przez klien­tów) uży­wam obec­nie do komu­ni­ka­cji bar­dziej zaawan­so­wa­ne­go opro­gra­mo­wa­nia PostMania.
  • U wie­lu klien­tów spo­ty­kam, popu­lar­ny w ser­wi­sach i fir­mach IT, Mantis.
  • Do zarzą­dza­nia pro­ce­sem nego­cjo­wa­nia i pod­pi­sy­wa­nia umów, wie­le firm i ich praw­ni­ków uży­wa opro­gra­mo­wa­nia Pergamin.
  • No i powszech­ny, z uwa­gi na pra­wo, ePUAP.

Polecam roz­wa­że­nie rezy­gna­cji z pocz­ty elek­tro­nicz­nej do prze­ka­zy­wa­nia doku­men­tów pro­jek­to­wych, nie tyl­ko z uwa­gi na ich bez­pie­czeń­stwo ale głów­nie z uwa­gi na zarzą­dza­nie nimi i kon­tro­le w całym cyklu życia dokumentu. 

Źródła

Paschke, A., & Kozlenkov, A. (2008). A Rule-based Middleware for Business Process Execution. 13.

Opis wymagań z użyciem Gherkin – czyli duuużo korniszonów…

Wstęp

Zostałem nie­daw­no zapy­ta­ny czy pomo­gę bo mamy już ponad 150 przy­pad­ków uży­cia w doku­men­ta­cji…”. Myślę sobie, to nie­moż­li­we, nie ma tak wiel­kich sys­te­mów (wyce­na oka­za­ła się w efek­cie pię­cio­krot­nie zawy­żo­na tyl­ko dla­te­go, że uży­to meto­dy zorien­to­wa­nej na user story”). 

Czytaj dalej… Opis wyma­gań z uży­ciem Gherkin – czy­li duuużo kor­ni­szo­nów…”
Wzorce projektowe Książki

Wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Analiza biz­ne­so­wa i projektowanie

Wstęp

W arty­ku­le o apli­ka­cjach webo­wych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wza­jem­na nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług apli­ka­cyj­nych. (źr.: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych).

Przy innej oka­zji pisa­łem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzor­ce projektowe ) 

Szkolenia dla ana­li­ty­ków poprze­dzam ankie­ta­mi przed szko­le­nio­wy­mi, jak do tej pory żad­na nie zawie­ra­ła pytań o wzor­ce pro­jek­to­we: ani tego że są uży­wa­ne ani tego, że są celem szko­le­nia, nie­mal­że każ­dy dekla­ru­je albo, że uży­wa UML lub, że chce zacząć uży­wać UML, nawet gdy są to pro­gra­mi­ści. Zauważyłem, że wzor­ce pro­jek­to­we w świa­do­mo­ści ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia (OOAD) nie ist­nie­ją”. Wśród pro­gra­mi­stów, jeże­li jest spo­ty­ka­na, to wie­dza o wzor­cach przy­dat­nych w two­rze­niu biblio­tek i narzę­dzi, czę­sto też powie­la­ne są wyuczo­ne sta­re i złe prak­ty­ki pro­gra­mi­stycz­ne rodem z lat 60-tych (np. prak­ty­ki SmallTalk, patrz dalej). 

Z dru­giej stro­ny od wie­lu lat zna­ne są tech­ni­ki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), któ­re w róż­nych for­mach, ale jed­nak wska­zu­ją, że naj­sku­tecz­niej­sza for­ma wyra­ża­nia wyma­gań wobec roz­wią­za­nia to pro­jekt archi­tek­tu­ry i logi­ki dzie­dzi­no­wej (model) dzia­ła­nia apli­ka­cji . O pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cję pisze sie od dość daw­na, meto­dy obiek­to­we i dobre prak­ty­ki zna­ne są od lat .

Autorzy BABoK prak­tycz­nie od począt­ku ist­nie­nia tego wydaw­nic­twa, zwra­ca­ją uwa­gę na tak zwa­ną bia­łą skrzyn­kę”, czy­li wyma­ga­nia wyra­żo­ne w posta­ci wewnętrz­nej struk­tu­ry pro­duk­tu, wska­zu­jąc, że to znacz­nie sku­tecz­niej­sza meto­da defi­nio­wa­nia wyma­gań wobec roz­wią­za­nia, niż tak zwa­na czar­na skrzyn­ka”, czy­li tra­dy­cyj­ne, i jed­nak mniej sku­tecz­ne, wyma­ga­nia wyra­żo­ne tyl­ko jako cechy funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Pamiętajmy, że adre­sa­tem wyma­gań jest zawsze dostaw­ca produktu!

Czytaj dalej… Wzorce pro­jek­to­we w ana­li­zie i pro­jek­to­wa­niu mode­lu dzie­dzi­ny sys­te­mu”