Diagram aktywności UML – kiedy

Wstęp

Od cza­su do cza­su jestem pyta­ny o to, kie­dy uży­wać dia­gra­mu aktyw­no­ści UML. Od 2015 roku spe­cy­fi­ka­cja UML wska­zu­je, że dia­gra­my te są narzę­dziem mode­lo­wa­nia metod czy­li logi­ki kodu (dla Platform Independent Model): aktyw­no­ści (acti­vi­ties) to nazwy metod, zadania/kroki (actions) to ele­men­ty kodu (przy­kła­dy w dal­szej części). 

Gdy powsta­wał UML, dia­gra­my aktyw­no­ści były uży­wa­ne tak­że do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych. W roku 2004 opu­bli­ko­wa­no spe­cy­fi­ka­cję nota­cji BPMN, któ­ra w zasa­dzie do roku 2015 prze­ję­ła” po UML funk­cję narzę­dzia mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. W 2015 roku for­mal­nie opu­bli­ko­wa­no spe­cy­fi­ka­cję UML 2.5, gdzie gene­ral­nie zre­zy­gno­wa­no z uży­wa­nia UML do mode­li CIM. Obecnie Mamy usta­bi­li­zo­wa­ną sytu­ację w lite­ra­tu­rze przed­mio­tu: BPMN wyko­rzy­stu­je­my w mode­lach CIM (mode­le biz­ne­so­we), UML w mode­lach PIM i PSM jako mode­le opro­gra­mo­wa­nia (a mode­le sys­te­mów: SysML, pro­fil UML). 

Na prze­ło­mie lat 80/90-tych roz­po­czę­to pra­ce nad stan­da­ry­za­cję nota­cji mode­lo­wa­nia obiek­to­we­go, w 1994 opu­bli­ko­wa­no UML 0.9, w 2001 roku poja­wia­ją się pierw­sze publi­ka­cje o pra­cach nad nota­cją BPMN, jed­no­cze­śnie poja­wia się Agile Manifesto, od 2004 roku ma miej­sce spa­dek zain­te­re­so­wa­nia doku­men­to­wa­niem pro­jek­tów pro­gra­mi­stycz­nych, w 2004 rok publi­ko­wa­no spe­cyf­ka­cję BPMN 1.0, od tego roku ma miej­sce wzrost zain­te­re­so­wa­nia mode­lo­wa­niem pro­ce­sów biz­ne­so­wych, powo­li sta­bi­li­zu­je się obszar zasto­so­wa­nia nota­cji UML. W 2015 roku opu­bli­ko­wa­no UML 2.5, sto­so­wa­nie ana­li­zy (CIM) i i pro­jek­to­wa­nia (PIM), jako eta­pu poprze­dza­ją­ce­go imple­men­ta­cje, sta­ło się stan­dar­dem (źr. wykre­su: Google Ngram).

Tak więc obecnie: 

Nie uży­wa­my dia­gra­mów aktyw­no­ści do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Do tego słu­ży nota­cja BPMN!

Diagram aktyw­no­ści może być mode­lem kodu na wyso­kim lub niskim pozio­mie abs­trak­cji, ope­ru­je­my wte­dy odpo­wied­nio aktyw­no­ścia­mi (acti­vi­ty) lub dzia­ła­nia­mi (actions). Te ostat­nie to w zasa­dzie repre­zen­ta­cja pole­ceń programu. 

Nie ma cze­goś takie­go jak pro­ces sys­te­mo­wy”, opro­gra­mo­wa­nie reali­zu­je pro­ce­du­ry”.

Projektując opro­gra­mo­wa­nie zgod­nie ze SPEM , powsta­je Platform Independent Model. W prak­ty­ce już na tym eta­pie pro­gra­mu­je­my, bo two­rzy­my logi­kę i obraz przy­szłe­go kodu. Taka for­ma doku­men­to­wa­nia pozwa­la tak­że lepiej chro­nic war­to­ści inte­lek­tu­al­ne zamawiającego.

Czytaj dalej… Diagram aktyw­no­ści UML – kie­dy”

Aplikacje webowe i mikroserwisy czyli architektura systemów webowych

Wprowadzenie

W 2015 roku pisa­łem o kom­po­nen­to­wej archi­tek­tu­rze w kon­tek­ście dużych apli­ka­cji biznesowych:

Idąc w stro­nę kom­po­nen­tów i dużych zło­żo­nych sys­te­mów war­to sko­rzy­stać z podej­ścia pole­ga­ją­ce­go na two­rze­niu (kupo­wa­niu) tak zwa­nych mikro­ser­wi­sów, czy­li wąsko spe­cja­li­zo­wa­nych dzie­dzi­no­wych apli­ka­cji (wręcz poje­dyn­czych grup przy­pad­ków uży­cia). Paradoksalnie to bar­dzo uła­twia pro­jek­to­wa­nie, imple­men­ta­cję a przede wszyst­kim obni­ża kosz­ty utrzy­ma­nia całe­go sys­te­mu. Brak zło­żo­nych połą­czeń mię­dzy kom­po­nen­ta­mi (współ­dzie­lo­na baza danych, zło­żo­ne inter­fej­sy) pozwa­la na to, by cykle ich życia były tak­że nie­za­leż­ne (wpro­wa­dza­ne zmia­ny tak­że). (Granice kon­tek­stu i mikro­ser­wi­sy )

Dwa lata póź­niej w tek­ście będą­cym kontynuacją:

Takie podej­ście pozwa­la two­rzyć szyb­ciej przy mini­mal­nym ryzy­ku poja­wie­nia się potrze­by re-fak­to­­ri­n­gu cało­ści a tak­że czy­ni apli­ka­cję łatwą do two­rze­nia w zespo­le i póź­niej­szej roz­bu­do­wy ?(Gage, 2018)?. Rosnąca popu­lar­ność tej archi­tek­tu­ry, tyl­ny­mi drzwia­mi powo­li rugu­je z ryn­ku mono­li­ty ERP, któ­re (nie­któ­re) pod­le­ga­ją re-fak­to­­ri­n­go­­wi (ich pro­du­cen­ci nie chwa­lą sie tym bo to powol­ny i bar­dzo kosz­tow­ny pro­ces). Te sys­te­my, któ­re nadal są opar­te na fun­da­men­cie jed­nej bazy danych z inte­gra­cją bazu­ją­ca na współ­dzie­le­niu danych, powo­li prze­gry­wa­ją kosz­ta­mi. (Mikroserwisy c.d.?)

Dzisiaj opi­szę jak na eta­pie ana­li­zy i pro­jek­to­wa­nia opra­co­wać model PIM (Platform Independent Model) , w taki spo­sób by sta­no­wił pro­jekt tech­nicz­ny apli­ka­cji webo­wej dla developera.

Czytaj dalej… Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych”

Koncepcja rozszerzenia wzorca projektowego BCE

Streszczenie: W pra­cy przed­sta­wio­no meto­dę pro­jek­to­wa­nia archi­tek­tu­ry opro­gra­mo­wa­nia od ogó­łu do szcze­gó­łu z pomo­cą meta­mo­de­li defi­nio­wa­nych jako pro­fi­li UML. Pokazano zale­tę jaką jest moż­li­wość szyb­kie­go roz­po­czę­cia prac pro­jek­to­wych i testo­wa­nia efek­tów mimo bra­ku deta­licz­nej wie­dzy o danych. Metoda zakła­da, że dane są zor­ga­ni­zo­wa­ne z nazwa­ne doku­men­ty o okre­ślo­nej struk­tu­rze. W trak­cie prac ana­li­tycz­nych i pro­jek­to­wych wystar­cza­ją­cą wie­dzą jest to jakie doku­men­ty są (będą) prze­twa­rza­ne, zro­zu­mie­nie ich celu i opis zawar­to­ści. Detaliczne sza­blo­ny doku­men­tów (pola i ich zawar­tość) mogą pozo­sta­wać nie­zna­ne pra­wie do koń­ca ana­li­zy i pro­jek­to­wa­nia, wyma­ga­ne są dopie­ro na eta­pie implementacji.

1. Wstęp

Wśród archi­tek­to­nicz­nych wzor­ców pro­jek­to­wych domi­nu­ją wzor­ce opi­su­ją­ce ele­men­ty tech­nicz­ne opro­gra­mo­wa­nia (Larman 2004) oraz wzor­ce opi­su­ją­ce ogól­nie two­rze­nie dzie­dzi­no­wych kom­po­nen­tów, tu naj­bar­dziej zna­ny to wzo­rzec DDD (Evans 2003). Znane jest tak­że podej­ście opar­te na meto­dzie okre­śla­nej jako pro­jek­to­wa­nie zorien­to­wa­ne na odpo­wie­dzial­ność klas” (Wirfs-Brock 2003).

Wzorzec DDD to wzo­rzec uni­wer­sal­ny (dzie­dzi­na nie ma tu zna­cze­nia), opar­ty na tech­nicz­nych odpo­wie­dzial­no­ściach kom­po­nen­tów. Wirfs-Brock zaś opi­su­je podej­ście do pro­jek­to­wa­nia archi­tek­tu­ry ale nie wska­zu­je kon­kret­nych wzor­ców ani meta­mo­de­li, sku­pia sie na meto­dzie ana­li­zy i projektowania.

Artykuł ten to pro­po­zy­cja posze­rze­nia powyż­szych metod o podej­ście uwzględ­nia­ją­ce dzie­dzi­nę pro­ble­mu oraz aktu­al­ne tren­dy w pro­jek­to­wa­niu archi­tek­tu­ry dużych sys­te­mów (jed­nym z cie­kaw­szych jest auto­ma­ty­za­cja (Sobczak 2019). Celem jest doda­nie war­stwy abs­trak­cyj­nej na jak naj­wcze­śniej­szym eta­pie pro­jek­to­wa­nia, by odsu­nąć w cza­sie pra­ce ze szcze­gó­ła­mi taki­mi jak atry­bu­ty i wewnętrz­ne (pry­wat­ne) ope­ra­cje kom­po­nen­tów. Innymi sło­wy celem jest poprze­dza­nie pro­jek­to­wa­nia archi­tek­tu­ry opro­gra­mo­wa­nia stu­dia­mi zwią­za­ny­mi z dzie­dzi­ną pro­ble­mu, w celu opra­co­wa­nia pro­fi­lu dla wybra­nej tech­no­lo­gii lub pro­jek­tu oraz słow­nic­twa dla nazw ele­men­tów mode­li, opi­su­ją­ce­go jed­no­znacz­nie role nazy­wa­nych komponentów.

Jest to idea zna­na z innych dzie­dzin np. zawod­ni­cy dru­ży­ny pił­ki noż­nej mają okre­ślo­ne role, są kla­sy­fi­ko­wa­ni jako np. zawod­nik obro­ny lub ata­ku, co infor­mu­je nas dość pre­cy­zyj­nie o moż­li­wych zacho­wa­niach dane­go zawod­ni­ka a nie wyma­ga mimo to zna­jo­mo­ści deta­li jego umie­jęt­no­ści (ope­ra­cji), może­my dłu­go nie wie­dzieć kto kon­kret­nie będzie grał na tej pozycji.

Do spo­rzą­dza­nia sche­ma­tów blo­ko­wych wyko­rzy­sta­no nota­cję UML oraz SBVR (źr. omg​.org).

2. Co zbadano?

Przedmiotem badań były pro­jek­ty ana­li­tycz­ne doku­men­to­wa­ne z uży­ciem nota­cji UML kla­sy­fi­ko­wa­ne przez auto­rów tych doku­men­tów jako obiek­to­we (o obiek­to­wej architekturze).

3. Wyniki

Opracowano roz­sze­rze­nie wzor­ca BCE i opi­sa­no meto­dę jego roz­sze­rza­nia. Zbudowanie roz­sze­rzo­ne­go meta­mo­de­lu wzor­ca BCE wyma­ga spój­ne­go sys­te­mu pojęć.

3.1. Pojęcia agenta i robota

Diagram: Pojęcia agenta i robota

Opracowanie spójnego metamodelu wymagało włączenia do niego pojęć, które już są używane w inżynierii oprogramowania: agent i robot.

W słowniku języka polskiego aplikacja jest definiowana jako komputerowy program użytkowy zaś komponent jako część składowa czegoś. Kolejne pojęcia to robot jako urządzenie zastępujące człowieka przy wykonywaniu niektórych czynności oraz agent jako przedstawiciel jakiejś firmy. Pojęcia te funkcjonują już zarówno w branży zarządzania jak i w inżynierii oprogramowania, jednak nadal nie maja ścisłych definicji. Z uwagi na potrzebę ścisłego zdefiniowania tych pojęć w tej pracy, uwzględniając obecne już publikacje z tego zakresu, przyjęto tu model przedstawiony na diagramie Pojęcia agenta i robota:
komponent aplikacyjny jest typem komponentu,
aplikacja może być zbudowana z (zawiera) komponentów aplikacyjnych,
agent jest samodzielnym typem aplikacji,
aplikacja użytkowa jest oprogramowaniem dla użytkownika,
robot jest typem komponentu aplikacyjnego

Tak określone znaczenia tych pojęć są zgodne z przyjętymi w literaturze znaczeniami: agent to samodzielny program (aplikacja), robot jest automatem (postrzeganym jako "mniej inteligentny" od agenta, a więc niesamodzielnym). Takie definicje wzajemnie się wykluczają więc spełniają wymagania dla definicji w przestrzeni pojęciowej (namespace), nie kolidują także z przyjętymi w literaturze przedmiotu.

Diagram: Pojęcia agen­ta i robota

Opracowanie spój­ne­go meta­mo­de­lu wyma­ga­ło włą­cze­nia do nie­go pojęć, któ­re już są uży­wa­ne w inży­nie­rii opro­gra­mo­wa­nia: agent i robot.

W słow­ni­ku języ­ka pol­skie­go apli­ka­cja jest defi­nio­wa­na jako kom­pu­te­ro­wy pro­gram użyt­ko­wy zaś kom­po­nent jako część skła­do­wa cze­goś. Kolejne poję­cia to robot jako urzą­dze­nie zastę­pu­ją­ce czło­wie­ka przy wyko­ny­wa­niu nie­któ­rych czyn­no­ści oraz agent jako przed­sta­wi­ciel jakiejś fir­my. Pojęcia te funk­cjo­nu­ją już zarów­no w bran­ży zarzą­dza­nia jak i w inży­nie­rii opro­gra­mo­wa­nia, jed­nak nadal nie maja ści­słych defi­ni­cji. Z uwa­gi na potrze­bę ści­słe­go zde­fi­nio­wa­nia tych pojęć w tej pra­cy, uwzględ­nia­jąc obec­ne już publi­ka­cje z tego zakre­su, przy­ję­to tu model przed­sta­wio­ny na dia­gra­mie Pojęcia agen­ta i robota:

  1. kom­po­nent apli­ka­cyj­ny jest typem komponentu,
  2. apli­ka­cja może być zbu­do­wa­na z (zawie­ra) kom­po­nen­tów aplikacyjnych,
  3. agent jest samo­dziel­nym typem aplikacji,
  4. apli­ka­cja użyt­ko­wa jest opro­gra­mo­wa­niem dla użytkownika,
  5. robot jest typem kom­po­nen­tu aplikacyjnego

Tak okre­ślo­ne zna­cze­nia tych pojęć są zgod­ne z przy­ję­ty­mi w lite­ra­tu­rze zna­cze­nia­mi: agent to samo­dziel­ny pro­gram (apli­ka­cja), robot jest auto­ma­tem (postrze­ga­nym jako mniej inte­li­gent­ny” od agen­ta, a więc nie­sa­mo­dziel­nym). Takie defi­ni­cje wza­jem­nie się wyklu­cza­ją więc speł­nia­ją wyma­ga­nia dla defi­ni­cji w prze­strze­ni poję­cio­wej (name­spa­ce), nie koli­du­ją tak­że z przy­ję­ty­mi w lite­ra­tu­rze przedmiotu.

3.2. Wzorzec architektoniczny BCE

Diagram: Wzorzec architektoniczny BCE

Wzorzec BCE (Boundary, Control, Entity) w swojej pierwotnej wersji (Rosenberg 2005) zakłada, że komponenty aplikacyjne mają (realizują) jedną z trzech odpowiedzialności:
Boundary to interfejs komponentu,
Control to logika biznesowa,
Entity to utrwalanie.
Początkowo był interpretowany jako trójwarstwowe podejście do aplikacji (odpowiednio: interfejs, logika, dane) zgodnie z podejściem "aplikacja to funkcje i dane". Później rozszerzono zastosowanie wraz ze wzorcem MVC (Rosenberg 2007). Wzorzec ten jednak jest bardzo ogólny i nie pozwala na precyzyjniejsze modelowanie ról. Z tego powodu bardzo szybko projektanci przechodzili do modelowania detali takich jak operacje i atrybuty klas i do implementacji, co w dużych projektach często prowadzi do szybkiego "zalania" projektu szczegółami.

Ikony na diagramie Wzorzec architektoniczny BCE to graficzne reprezentacje stereotypów, klasy notacji UML.

Diagram: Wzorzec archi­tek­to­nicz­ny BCE

Wzorzec BCE (Boundary, Control, Entity) w swo­jej pier­wot­nej wer­sji (Rosenberg 2005) zakła­da, że kom­po­nen­ty apli­ka­cyj­ne mają (reali­zu­ją) jed­ną z trzech odpowiedzialności:

  1. Boundary to inter­fejs komponentu,
  2. Control to logi­ka biznesowa,
  3. Entity to utrwalanie.

Początkowo był inter­pre­to­wa­ny jako trój­war­stwo­we podej­ście do apli­ka­cji (odpo­wied­nio: inter­fejs, logi­ka, dane) zgod­nie z podej­ściem apli­ka­cja to funk­cje i dane”. Później roz­sze­rzo­no zasto­so­wa­nie wraz ze wzor­cem MVC (Rosenberg 2007). Wzorzec ten jed­nak jest bar­dzo ogól­ny i nie pozwa­la na pre­cy­zyj­niej­sze mode­lo­wa­nie ról. Z tego powo­du bar­dzo szyb­ko pro­jek­tan­ci prze­cho­dzi­li do mode­lo­wa­nia deta­li takich jak ope­ra­cje i atry­bu­ty klas i do imple­men­ta­cji, co w dużych pro­jek­tach czę­sto pro­wa­dzi do szyb­kie­go zala­nia” pro­jek­tu szczegółami.

Ikony na dia­gra­mie Wzorzec archi­tek­to­nicz­ny BCE to gra­ficz­ne repre­zen­ta­cje ste­reo­ty­pów, kla­sy nota­cji UML.

Zadaniem było opra­co­wa­nie meto­dy i roz­bu­do­wy wzor­ca BCE w spo­sób nie koli­du­ją­cy z jego pod­sta­wo­wą ogól­ną for­mą (dla zacho­wa­nia kom­pa­ty­bil­no­ści z histo­rycz­ny­mi przy­pad­ka­mi jego uży­cia), dają­cy moż­li­wość pro­jek­to­wa­nia zorien­to­wa­ne­go na odpo­wie­dzial­ność kom­po­nen­tów. Narzędziem jest two­rze­nie pro­fi­li UML oraz budo­wa­nie mode­li pojęciowych.

3.3. Profil UML dla rozszerzonego wzorca BCE

Diagram: Profil UML dla rozszerzonego wzorca BCE

Podstawowy zestaw stereotypów (stereotyp to dodatkowa klasyfikacja określonych elementów w notacji UML) to: boundary, control, entity. Rozszerzenie przestrzeni pojęciowej pozwala uzyskać profil zobrazowany na diagramie Profil UML dla rozszerzonego wzorca BCE.

Centralnym elementem jest pojęcie Stereotyp, jako dodatkowy klasyfikator dla nazwanych elementów Class (patrz OMG.org/MOF oraz OMG.org/UML). Dla komponentów (<<component>>) wprowadzono dwa stereotypy (dwie klasy komponentów): agentoraz aplikacja użytkownika. Celem jest wskazanie, że aplikacja może zostać zaprojektowana jako oprogramowanie dla jego użytkownika (będącego człowiekiem) lub oprogramowanie autonomiczne (reaguje na szerokopojęte otoczenie), działające samodzielnie. Oba te typy aplikacji mogę być projektowane z użyciem wzorca MVC więc komponent logiki dziedzinowej jest w oby typach aplikacji modelowany w ten sam sposób.

Trzyelementowy wzorzec BCE został poszerzony w ten sposób, że każdy z trzech jego elementów zyskał specjalizacje:
boundary: callAdapter, API oraz GUI,
control: robot oraz onDemand,
entity: description oraz businessObject.
 
Komponent boundary to interfejs pomiędzy aplikacją a jej otoczeniem. Usługi są udostępniane aktorom, zależnie od typu aktora, interfejsem GUI lub API 9interfejs oferowany). Jeżeli jest to przypadek interfejsu wymaganego, "wyjście na świat" deklarujemy jako callAdapter (nie dopuszczamy by jakiekolwiek komponent z wnętrza aplikacji wywoływał bezpośrednio usługi z poza aplikacji).

Komponent control realizuje usługi dziedzinowe na żądanie jako onDemand, albo działa samoczynnie jako "demon" robot. W literaturze pojęcie demon jest często stosowane jako nazwa automatu uruchamiającego polecenia wg. harmonogramu, dlatego celowo użyto pojęcia robot, na nazwę komponentu zachowującego pełną autonomię w tym jakie funkcje i jak realizuje. Komponent entity odpowiada za utrwalane dane. Dla rozróżnienia description odpowiada za przechowywanie wszelkich opisów konfiguracji, z reguły jest singletonem (singleton to klasa mająca jedną instancją). Te oznaczone businessObject reprezentują  wszelkie strukturyzowane dane takie jak formularze, dokumenty, multimedia itp. Warto tu nadmienić, że obiekty typu entity nie reprezentują interfejsu do bazy danych wg. wzorca active records lub active table (Larman 2004). Dokument może tu być rozumiany jako ciąg znaków XMl przechowywany jako wartość jednego atrybuty klasy.

Diagram: Profil UML dla roz­sze­rzo­ne­go wzor­ca BCE

Podstawowy zestaw ste­reo­ty­pów (ste­reo­typ to dodat­ko­wa kla­sy­fi­ka­cja okre­ślo­nych ele­men­tów w nota­cji UML) to: boun­da­ry, con­trol, enti­ty. Rozszerzenie prze­strze­ni poję­cio­wej pozwa­la uzy­skać pro­fil zobra­zo­wa­ny na dia­gra­mie Profil UML dla roz­sze­rzo­ne­go wzor­ca BCE.

Centralnym ele­men­tem jest poję­cie Stereotyp, jako dodat­ko­wy kla­sy­fi­ka­tor dla nazwa­nych ele­men­tów Class (patrz OMG​.org/​MOF oraz OMG​.org/​UML). Dla kom­po­nen­tów («com­po­nent») wpro­wa­dzo­no dwa ste­reo­ty­py (dwie kla­sy kom­po­nen­tów): agen­to­raz apli­ka­cja użyt­kow­ni­ka. Celem jest wska­za­nie, że apli­ka­cja może zostać zapro­jek­to­wa­na jako opro­gra­mo­wa­nie dla jego użyt­kow­ni­ka (będą­ce­go czło­wie­kiem) lub opro­gra­mo­wa­nie auto­no­micz­ne (reagu­je na sze­ro­ko­po­ję­te oto­cze­nie), dzia­ła­ją­ce samo­dziel­nie. Oba te typy apli­ka­cji mogę być pro­jek­to­wa­ne z uży­ciem wzor­ca MVC więc kom­po­nent logi­ki dzie­dzi­no­wej jest w oby typach apli­ka­cji mode­lo­wa­ny w ten sam sposób.

Trzyelementowy wzo­rzec BCE został posze­rzo­ny w ten spo­sób, że każ­dy z trzech jego ele­men­tów zyskał specjalizacje:

  1. boun­da­ry: callAdapter, API oraz GUI,
  2. con­trol: robot oraz onDemand,
  3. enti­ty: descrip­tion oraz businessObject.

Komponent boun­da­ry to inter­fejs pomię­dzy apli­ka­cją a jej oto­cze­niem. Usługi są udo­stęp­nia­ne akto­rom, zależ­nie od typu akto­ra, inter­fej­sem GUI lub API 9interfejs ofe­ro­wa­ny). Jeżeli jest to przy­pa­dek inter­fej­su wyma­ga­ne­go, wyj­ście na świat” dekla­ru­je­my jako callAdapter (nie dopusz­cza­my by jakie­kol­wiek kom­po­nent z wnę­trza apli­ka­cji wywo­ły­wał bez­po­śred­nio usłu­gi z poza aplikacji).

Komponent con­trol reali­zu­je usłu­gi dzie­dzi­no­we na żąda­nie jako onDemand, albo dzia­ła samo­czyn­nie jako demon” robot. W lite­ra­tu­rze poję­cie demon jest czę­sto sto­so­wa­ne jako nazwa auto­ma­tu uru­cha­mia­ją­ce­go pole­ce­nia wg. har­mo­no­gra­mu, dla­te­go celo­wo uży­to poję­cia robot, na nazwę kom­po­nen­tu zacho­wu­ją­ce­go peł­ną auto­no­mię w tym jakie funk­cje i jak reali­zu­je. Komponent enti­ty odpo­wia­da za utrwa­la­ne dane. Dla roz­róż­nie­nia descrip­tion odpo­wia­da za prze­cho­wy­wa­nie wszel­kich opi­sów kon­fi­gu­ra­cji, z regu­ły jest sin­gle­to­nem (sin­gle­ton to kla­sa mają­ca jed­ną instan­cją). Te ozna­czo­ne businessObject repre­zen­tu­ją wszel­kie struk­tu­ry­zo­wa­ne dane takie jak for­mu­la­rze, doku­men­ty, mul­ti­me­dia itp. Warto tu nad­mie­nić, że obiek­ty typu enti­ty nie repre­zen­tu­ją inter­fej­su do bazy danych wg. wzor­ca acti­ve records lub acti­ve table (Larman 2004). Dokument może tu być rozu­mia­ny jako ciąg zna­ków XMl prze­cho­wy­wa­ny jako war­tość jed­ne­go atry­bu­ty klasy.

3.4. Przykład użycia rozszerzonego wzorca BCE

Diagram: Przykład użycia rozszerzonego wzorca BCE

Na diagramie Przykład użycia rozszerzonego wzorca BCE pokazano architekturę prostej aplikacji wspomagającej sprzedaż. Jest to model jej dziedziny.

Aplikacja jest oprogramowaniem typu aplikacja użytkownika gdyż powstała by wspomagać prace użytkownika jakim jest Sprzedawca. Użytkownik Prawnik jest tu wyłącznie osobą parametryzującą (np. okresowo) zachowanie robota Obsługa windykacji. Celem aplikacji jest wystawianie faktur oraz bieżące prowadzenie tak zwanej miękkiej windykacji.

Standardową usługą tej aplikacji jest wystawianie faktur na postawie zamówień pobieranych z aplikacji System CRM.

System kontrolingu ma dostęp do faktur przez interfejs Dostęp do statusów faktur, pobiera dane o fakturach, dla których miękka windykacja była nieskuteczna.

Z uwagi na żmudną pracę związaną z miękką windykacją (załóżmy, że wcześniej robiło to call center), zautomatyzowaną ją dodając do aplikacji komponent Obsługa windykacji pracujący jako robot. Jest to komponent zawierający kompletną procedurą, która cyklicznie realizuje scenariusz: sprawdź status faktury, sprawdź czy wpłynęła dla niej płatność, zależnie od tego oznacz ją jako zapłaconą lub wyślij monit, stosownie do tego, które jest to wezwanie do zapłaty.

Na tym etapie, opracowanie architektury zorientowane na odpowiedzialność klas, nie jest potrzebne wiedza o danych, zupełnie wystarczy wiedza o rolach poszczególnych komponentów. Kolejnym krokiem było by tu ustalenie wszystkich potrzebnych statusów i ich nośników, a na końcu dopiero ustalenia wymaga struktura faktury, monitu i dowodu wpłaty.

Rozszerzony wzorzec BCE, jako metamodel i zarazem wzorzec architektoniczny, pozwala od razu zbudować szkielet tej aplikacji, stanowi wspólny język. Można przyjąć założenie, że zrozumienie pojęć jakimi nazwano role poszczególnych komponentów (stereotypy) pozwala zrozumieć zobrazowany mechanizm działania (formalnie powinny powstać także diagramy sekwencji, które pomięto by nie zwiększać objętości tego tekstu).

Diagram: Przykład uży­cia roz­sze­rzo­ne­go wzor­ca BCE

Na dia­gra­mie Przykład uży­cia roz­sze­rzo­ne­go wzor­ca BCE poka­za­no archi­tek­tu­rę pro­stej apli­ka­cji wspo­ma­ga­ją­cej sprze­daż. Jest to model jej dziedziny.

Aplikacja jest opro­gra­mo­wa­niem typu apli­ka­cja użyt­kow­ni­ka gdyż powsta­ła by wspo­ma­gać pra­ce użyt­kow­ni­ka jakim jest Sprzedawca. Użytkownik Prawnik jest tu wyłącz­nie oso­bą para­me­try­zu­ją­cą (np. okre­so­wo) zacho­wa­nie robo­ta Obsługa win­dy­ka­cji. Celem apli­ka­cji jest wysta­wia­nie fak­tur oraz bie­żą­ce pro­wa­dze­nie tak zwa­nej mięk­kiej windykacji.

Standardową usłu­gą tej apli­ka­cji jest wysta­wia­nie fak­tur na posta­wie zamó­wień pobie­ra­nych z apli­ka­cji System CRM.

System kon­tro­lin­gu ma dostęp do fak­tur przez inter­fejs Dostęp do sta­tu­sów fak­tur, pobie­ra dane o fak­tu­rach, dla któ­rych mięk­ka win­dy­ka­cja była nieskuteczna.

Z uwa­gi na żmud­ną pra­cę zwią­za­ną z mięk­ką win­dy­ka­cją (załóż­my, że wcze­śniej robi­ło to call cen­ter), zauto­ma­ty­zo­wa­ną ją doda­jąc do apli­ka­cji kom­po­nent Obsługa win­dy­ka­cji pra­cu­ją­cy jako robot. Jest to kom­po­nent zawie­ra­ją­cy kom­plet­ną pro­ce­du­rą, któ­ra cyklicz­nie reali­zu­je sce­na­riusz: sprawdź sta­tus fak­tu­ry, sprawdź czy wpły­nę­ła dla niej płat­ność, zależ­nie od tego oznacz ją jako zapła­co­ną lub wyślij monit, sto­sow­nie do tego, któ­re jest to wezwa­nie do zapłaty.

Na tym eta­pie, opra­co­wa­nie archi­tek­tu­ry zorien­to­wa­ne na odpo­wie­dzial­ność klas, nie jest potrzeb­ne wie­dza o danych, zupeł­nie wystar­czy wie­dza o rolach poszcze­gól­nych kom­po­nen­tów. Kolejnym kro­kiem było by tu usta­le­nie wszyst­kich potrzeb­nych sta­tu­sów i ich nośni­ków, a na koń­cu dopie­ro usta­le­nia wyma­ga struk­tu­ra fak­tu­ry, moni­tu i dowo­du wpłaty.

Rozszerzony wzo­rzec BCE, jako meta­mo­del i zara­zem wzo­rzec archi­tek­to­nicz­ny, pozwa­la od razu zbu­do­wać szkie­let tej apli­ka­cji, sta­no­wi wspól­ny język. Można przy­jąć zało­że­nie, że zro­zu­mie­nie pojęć jaki­mi nazwa­no role poszcze­gól­nych kom­po­nen­tów (ste­reo­ty­py) pozwa­la zro­zu­mieć zobra­zo­wa­ny mecha­nizm dzia­ła­nia (for­mal­nie powin­ny powstać tak­że dia­gra­my sekwen­cji, któ­re pomię­to by nie zwięk­szać obję­to­ści tego tekstu).

Aplikacja Faktury Usługi i wymagania

Opisana apli­ka­cja z zewnątrz jest dla użyt­kow­ni­ka rela­tyw­nie pro­stym pro­gra­mem użyt­ko­wym. Ma tyl­ko jed­ne­go użyt­kow­ni­ka (Sprzedawca), Użytkownikiem jest tak­że Prawnik, któ­ry spo­ra­dycz­nie usta­wia para­me­try pra­cy kom­po­nen­tu ozna­czo­ne­go jako robot.

Na dia­gra­mie Aplikacja Faktury Usługi i wyma­ga­nia zobra­zo­wa­no apli­ka­cję Aplikacja Faktury z uży­ciem dia­gra­mu przy­pad­ków uży­cia nota­cji UML. Należy tu zwró­cić uwa­gę, że dia­gram ten słu­ży wyłącz­nie do doku­men­to­wa­nia celu two­rze­nia apli­ka­cji. Diagram ten nie słu­ży do opi­su szcze­gó­łów jej funk­cjo­no­wa­nia. Dlatego ten dia­gram w nota­cji UML bywa nazy­wa­ny kon­trak­tem lub kon­tek­stem pro­jek­tu. A typo­wym pro­ce­sie ana­li­zy i pro­jek­to­wa­nia ten dia­gram powsta­je jako pierwszy.

4. Dyskusja

W toku prze­glą­du dostęp­nych auto­ro­wi doku­men­ta­cji pro­jek­to­wych, stwier­dzo­no, że powszech­na prak­ty­ką jest roz­po­czy­na­nie ana­liz i pro­jek­to­wa­nia od two­rze­niu mode­lu danych (dia­gra­mu ERD) lub szcze­gó­ło­wych dia­gra­mów klas bazu­ją­cych na wzor­cu acti­ve records lub acti­ve table (kla­sa i jej atry­bu­ty repre­zen­tu­ją wier­sze tabel baz danych, zaś związ­ki mię­dzy kla­sa­mi rela­cje mię­dzy tymi tabli­ca­mi). Przykładem takie­go podej­ścia jest pró­ba stwo­rze­nia wzor­ców bazu­ją­cych na deta­licz­nych danych w doku­men­tach biz­ne­so­wych (Arlow Neustadt 2004).

Autor pro­po­nu­je cał­ko­wi­cie inne podej­ście, opar­te na doświad­cze­niach z wzor­ca­mi BCE i DDD: budo­wa­nie dzie­dzi­no­wych meta­mo­de­li w posta­ci pro­fi­li abs­tra­hu­ją­cych cał­ko­wi­cie od deta­licz­nej wie­dzy o doku­men­tach (businessObject) a sku­pia­ją­cych się na mecha­ni­zmie dzia­ła­nia, tu jedy­ny­mi wyma­ga­ny­mi atry­bu­ta­mi są te, któ­re obsłu­gu­ją logi­kę biz­ne­so­wą, są to meta­da­ne i sta­tu­sy (nie poka­za­ne w tym doku­men­cie). Trwają pra­ce nad testo­wa­niem tej meto­dy. Spodziewane są małe zmia­ny defi­ni­cji poszcze­gól­nych elementów. 

5. Literatura

Arlow Neustadt 2004

Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML, Jim Arlow; Ila Neustadt, ISBN-13: 9780321112309, 2004

Dzieszko i inni 2013

ROCZNIKI GEOMATYKI 2013 m TOM XI m ZESZYT 4(61), MODELOWANIE AGENTOWE NOWOCZESNA KONCEPCJA MODELOWANIA W GIS, Piotr Dzieszko, Katarzyna Bartkowiak, Katarzyna Gie?da-Pinas, Uniwersytet im. Adama Mickiewicza w Poznaniu, Wydzia? Nauk Geograficznych i Geologicznych, Instytut Geoekologii i Geoinformacji, Zakład Geoekologii

Evans 2003

Domain Driven Design Tackling Complexity in the Heart of Software by Evans, Eric. Published by Addison Wesley,2003,

Larman 2004

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Craig Larman, Prentice Hall, October 30, 2004, ISBN-10: 0131489062

Rosenberg 2005

Rosenberg, Don, Collins-Cope, Mark, Stephens, Matt, Agile Development with ICONIX Process, Apress 2005, ISBN 978 – 1‑59059 – 464‑3

Rosenberg 2007

Use Case Driven Object Modeling with UMLTheory and Practice, Theory and Practice, Rosenberg, Don, Stephens, Matt, Apress 2007

Sobczak 2019

Sobczak Andrzej, Czym jest robot pro­gra­mo­wy (softwa­re robot) – pró­ba defi­ni­cji (https://​robo​no​mi​ka​.pl/​c​z​y​m​-​j​e​s​t​-​r​o​b​o​t​-​p​r​o​g​r​a​m​o​w​y​-​s​o​f​t​w​a​r​e​-​r​o​b​o​t​-​p​r​o​b​a​-​d​e​f​i​n​i​cji). 19 kwie­cień 2019

Wirfs-Brock 2003

Object Design: Roles, Responsibilities, and Collaborations, Rebecca J Wirfs-Brock and Alan McKean, Addison-

Wesley, 2003 (also: http://​wirfs​-brock​.com/​D​e​s​i​g​n​.​h​tml)

Żeliński 2019

Synthesis of MOF, MDA, PIM, MVC and BCE notions and pat­terns, Self publi­shing , 2019, Jarosław Żeliński

Synteza pojęć i wzorców MOF, MDA, PIM, MVC i BCE. Zintegrowany model struktury procesu projektowania aplikacji.

Streszczenie: Wiele publi­ka­cji, w tym pod­ręcz­ni­ki aka­de­mic­kie, zawie­ra nie­spój­no­ści w opi­sach zasto­so­wań metod i wzor­ców archi­tek­to­nicz­nych, kry­ją­cych się pod skró­ta­mi MOF, MDA, PIM, MVC, BCE. Skuteczna ana­li­za oraz nastę­pu­ją­ce po niej pro­jek­to­wa­nie opro­gra­mo­wa­nia, szcze­gól­nie gdy są to pro­jek­ty reali­zo­wa­ne w dużych zespo­łach, wyma­ga stan­da­ry­za­cji pro­ce­su wytwór­cze­go i sto­so­wa­nych wzor­ców i fra­me­wor­ków. W pra­cy tej pod­ję­to pró­bę upo­rząd­ko­wa­nia sys­te­mu pojęć opi­su­ją­cych ten pro­ces , sto­so­wa­nych do opi­su wzor­ców archi­tek­to­nicz­nych. Przeprowadzono ana­li­zę klu­czo­wych pojęć MOF i MDA, wzor­ców MVC i BCE, stwo­rzo­no spój­ny opis łączą­cy je w jeden system.

1. Wprowadzenie

Celem badań było zwe­ry­fi­ko­wa­nie obec­ne­go sta­nu metod pro­jek­to­wa­nia i opra­co­wa­nie spój­ne­go sys­te­mu pojęć i wzor­ców pro­jek­to­wych w obsza­rze pro­jek­to­wa­nia logi­ki opro­gra­mo­wa­nia, jako jej abs­trak­cyj­ne­go mode­lu. Wiele publi­ka­cji na temat ana­liz i pro­jek­to­wa­nia, w obsza­rze inży­nie­rii opro­gra­mo­wa­nia, przy­wo­łu­je nazwy wzor­ców pro­jek­to­wych MVC i BCE oraz model PIM (patrz OMG MDA, OMG MOF 2016). Z uwa­gi na, nie raz, nie małe roz­bież­no­ści w inter­pre­ta­cji tych metod i wzor­ców, autor pod­jął pró­bę upo­rząd­ko­wa­nia ich wza­jem­nych zależności.

2. Metody

Wykorzystano sys­te­my nota­cyj­ne Object Management Group (OMG​.org). Specyfikacja MOF opi­su­je trzy pozio­my abs­trak­cji: M1, M2, M3 oraz poziom M0 czy­li real­ne rze­czy (patrz struk­tu­ra pozio­mów abs­trak­cji, OMG MOF 2016). M0 to real­ny sys­tem, poziom M1 to abs­trak­cja obiek­tów tego sys­te­mu (jego model) . Poziom M2 to związ­ki pomię­dzy kla­sa­mi tych obiek­tów (nazwy ich zbio­rów) czy­li meta­mo­del sys­te­mu. Poziom M3 to meta-meta­mo­del poziom opi­su­ją­cy meto­dę mode­lo­wa­nia z uży­ciem nazwa­nych ele­men­tów o okre­ślo­nej seman­ty­ce i syntaktyce.

Proces ana­li­zy i pro­jek­to­wa­nia został opar­ty na spe­cy­fi­ka­cji MDA (OMG MDA). Proces ten ma trzy fazy rozu­mia­ne jako two­rze­nie kolej­nych mode­li: CIM, PIM, PSM oraz fazę two­rze­nie kodu. Model CIM jest doku­men­to­wa­ny z uży­ciem nota­cji BPMN (OMG BPMN 2013) i SBVR (OMG SBVR 2017). Są to odpo­wied­nio: mode­le pro­ce­sów biz­ne­so­wych oraz mode­le poję­cio­we i regu­ły biz­ne­so­we. Modele PIM i PSM doku­men­to­wa­ne są z uży­ciem nota­cji UML (OMG UML 2017). Pomiędzy mode­lem CIM a PIM ma miej­sce usta­le­nie listy usług apli­ka­cyj­nych (reak­cje sys­te­mu), któ­rych mecha­nizm reali­za­cji opi­su­je model PIM. Standardowym wzor­cem uży­wa­nym do mode­lo­wa­nia archi­tek­tu­ry apli­ka­cji jest wzo­rzec MVC. Komponent Model tego wzor­ca jest mode­lo­wa­ny z uży­ciem wzor­cza archi­tek­to­nicz­ne­go BCE.

[…]

Spis tre­ści
1. Wprowadzenie 1
2. Metody 2
2.1. Semiotyka a UML 2
2.2. Specyfikacja MOF Poziomy abs­trak­cji 3
2.3. Specyfikacja MDA i model PIM 4
2.4. Wzorzec archi­tek­to­nicz­ny MVC 5
2.5. Wzorzec archi­tek­to­nicz­ny BCE 5
3. Rezultaty 6
3.1. Założenie uprosz­cza­ją­ce 6
3.2. Zintegrowany model struk­tu­ry pro­ce­su pro­jek­to­wa­nia apli­ka­cji 7
4. Dyskusja 8
5. Dalsze pra­ce 8
6. Bibliografia 9
7. Kluczowe poję­cia meto­dycz­ne 11

Cała publi­ka­cja …

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns
Jaroslaw Zelinski (Independent Researcher, Poland)

Source Title: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities
Copyright: ? 2020 |Pages: 12
DOI: 10.4018/978 – 1‑7998 – 2142‑7.ch003

Know-how a Zasada Kerckhoffs’a i bezpieczeństwo

Wprowadzenie

Tematem numer jeden, nie­mal­że w każ­dym moim pro­jek­cie, jest model biz­ne­so­wy i tajem­ni­ca przed­się­bior­stwa. Z per­spek­ty­wy lat muszę powie­dzieć, że to fobia wie­lu (jak nie więk­szo­ści) przed­się­bior­ców i nie tyl­ko przed­się­bior­ców. Nie dla­te­go, że chcą coś chro­nić, ale dla­te­go co i jak chro­nią. Nie raz już pisa­łem, że fir­my nie raz, naj­pierw pod­pi­su­ją z dostaw­ca­mi roz­wią­zań i kon­sul­tan­ta­mi umo­wy o pouf­no­ści, a potem wyzby­wa­ją praw do swo­je­go know-how na ich rzecz:

W bran­ży inży­nie­rii opro­gra­mo­wa­nia dość powszech­na jest sytu­acja, gdy pro­gra­mi­sta jest tak­że pro­jek­tan­tem, inny­mi sło­wy pro­gra­mi­sta ma peł­nię praw autor­skich do kodu jaki two­rzy a jego klient żad­nych mimo, że jest inwe­sto­rem!1

Dzisiaj dru­gi pro­blem czy­li bez­pie­czeń­stwo infor­ma­cji a nie raz i całej firmy.

Na począ­tek coś z zakres teo­rii informacji:

Zasada Kerckhoffs’a to jed­na z pod­sta­wo­wych reguł współ­cze­snej kryp­to­gra­fii. Została sfor­mu­ło­wa­na pod koniec XIX wie­ku przez holen­der­skie­go kryp­to­lo­ga Augusta Kerckhoffs’a (ur. 19 stycz­nia 1835, zm. 9 sierp­nia 1903). Zasada ta mówi, że sys­tem kryp­to­gra­ficz­ny powi­nien być bez­piecz­ny nawet wte­dy, gdy są zna­ne wszyst­kie szcze­gó­ły jego dzia­ła­nia oprócz sekret­ne­go klucza. […]

  1. System powi­nien być, jeśli nie teo­re­tycz­nie, to w prak­ty­ce nie do złamania.
  2. Projekt sys­te­mu nie powi­nien wyma­gać jego taj­no­ści, a ewen­tu­al­ne jego ujaw­nie­nie nie powin­no przy­spa­rzać kło­po­tów korespondentom.
  3. Klucz powi­nien być moż­li­wy do zapa­mię­ta­nia bez noto­wa­nia i łatwy do zmienienia.
  4. Kryptogramy powin­ny być moż­li­we do prze­sła­nia dro­gą telegraficzną.
  5. Aparatura i doku­men­ty powin­ny być moż­li­we do prze­nie­sie­nia i obsłu­że­nia przez jed­ną osobę.
  6. System powi­nien być pro­sty ? nie wyma­ga­ją­cy zna­jo­mo­ści wie­lu reguł ani nie obcią­ża­ją­cy zbyt­nio umysłu.

Właśnie dru­ga z tych reguł nosi obec­nie nazwę zasa­dy Kerckhoffs’a.

[…]Ideę zasa­dy Kerckhoffs’a wyra­ża rów­nież przy­pi­sy­wa­ne Claude’owi Shannon’owi powie­dze­nie Wróg zna sys­tem” (ang. The ene­my knows the sys­tem), zna­ne pod nazwą Maksymy Shannona (ang. Shannon’s maxim).2

Zasadę tę, jako kry­te­rium, moż­na łatwo posze­rzyć, usu­wa­jąc ostat­nie sło­wo do postaci:

Projekt sys­te­mu nie powi­nien wyma­gać jego taj­no­ści, a ewen­tu­al­ne jego ujaw­nie­nie nie powin­no przy­spa­rzać kłopotów.

Na ryn­ku mamy dwa prze­ciw­staw­ne w pew­nym sen­sie (o tym dalej) poję­cia: patent oraz know-how, dodać nale­ża­ło by do tego zesta­wu poję­cie pra­wo autor­skie oso­bi­ste i mająt­ko­we.

O bezpieczeństwie biznesowym

Na począ­tek kla­sycz­nie klu­czo­we definicje:

know-how: rozu­mia­ne jest jako pakiet nie­opa­ten­to­wa­nych infor­ma­cji prak­tycz­nych, wyni­ka­ją­cych z doświad­cze­nia i badań, któ­re są:
1. nie­jaw­ne (nie są powszech­nie zna­ne lub łatwo dostęp­ne);
2. istot­ne (waż­ne i uży­tecz­ne z punk­tu widze­nia wytwa­rza­nia Szczegóły:

">pro­duk­tów obję­tych umo­wą);
3. ziden­ty­fi­ko­wa­ne (czy­li opi­sa­ne w wystar­cza­ją­co zro­zu­mia­ły spo­sób, aby moż­na było spraw­dzić, czy speł­nia­ją kry­te­ria nie­jaw­no­ści i istot­no­ści). (źr. Rozporządzenie Unii Europejskiej nr 772/2004 w spra­wie sto­so­wa­nia art. 81 ust. 3 Traktatu do kate­go­rii poro­zu­mień o trans­fe­rze technologii).

bez­pie­czeń­stwo: stan nie­za­gro­że­nia (s.j.p.)

tajem­ni­ca: sekret; też: nie­ujaw­nia­nie cze­goś (s.j.p.)

patent: doku­ment przy­zna­ją­cy jakiejś oso­bie lub fir­mie wyłącz­ne pra­wo do czer­pa­nia korzy­ści z wyna­laz­ku; też: to pra­wo (s.j.p.)

infor­ma­cja: to, co powie­dzia­no lub napi­sa­no o kimś lub o czymś, tak­że zako­mu­ni­ko­wa­nie cze­goś (s.j.p.)

utwór: każ­dy prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny w jakiej­kol­wiek posta­ci, nie­za­leż­nie od war­to­ści, prze­zna­cze­nia i spo­so­bu wyra­że­nia (Ustawa)

Dla zapew­nie­nia i spraw­dze­nia jed­no­znacz­no­ści tego tek­stu zbu­duj­my model poję­cio­wy (tak­so­no­mia i syn­tak­ty­ka pojęć, przy­po­mi­nam, że nie korzy­sta­my w takich ana­li­zach a onto­lo­gii, poniż­szy dia­gram to nie ontologia):

Warto tu zwró­cić uwa­gę na to, że poję­cie opis paten­tu poja­wia się w tak­so­no­mii indy­wi­du­ali­zmu tre­ści jak i jej dostęp­no­ści. Innymi sło­wy opis paten­tu jest zarów­no utwo­rem jak i tre­ścią nie będą­cą tajem­ni­cą.
I teraz pyta­nie: co nale­ży chro­nić i dla­cze­go? To zależy…

Patent to mono­pol, jed­nak fak­ty poka­zu­ją, że mono­po­le trze­ba same­mu egze­kwo­wać, co nie zawsze jest eko­no­micz­nie uza­sad­nio­ne, przy zało­że­niu że kosz­ty ochro­ny paten­tu nie powin­ny prze­kro­czyć korzy­ści z jego posia­da­nia. I nie mam tu na myśli tyl­ko opłat dla Urzędu paten­to­we­go, a poten­cjal­ne sta­łe kosz­ty ochro­ny z tytu­łu wyta­cza­nych pozwów cywil­nych za łama­nie praw paten­to­wych. Rynek poka­zu­je, że nie raz ochro­nę paten­to­wą moż­na zastą­pić ochro­ną z tytu­łu praw autor­skich (treść opi­su jakie­goś roz­wią­za­nia to utwór, patrz dia­gram powy­żej) np. wzo­ry prze­my­sło­we, tym bar­dziej że są rze­czy któ­rych nie moż­na opa­ten­to­wać, ale moż­na opi­sać i chro­nić wła­śnie jako utwór (np. logi­kę opro­gra­mo­wa­nia).

Know-how

Know-how to kolej­ny cie­ka­wy obszar, bo wyma­ga­ją­cy bar­dzo czę­sto ochro­ny. Patent z zasa­dy jest tre­ścią jaw­ną, poda­wa­ną do publicz­nej wia­do­mo­ści. Jeżeli ktoś uzna, że jego know-how sta­no­wi o jego prze­wa­dze a nie chce czy­nić z nie­go paten­tu, to ma dwa wyj­ścia: (1) utrzy­my­wać know-how na pozio­mie trud­nym do naśla­do­wa­nia, to się nazy­wa utrzy­my­wa­nie barie­ry wej­ścia (patrz ana­li­za pię­ciu sił Portera), albo (2) utrzy­my­wać know-how w tajem­ni­cy przed kon­ku­ren­cją. To klu­czo­wy praw­dzi­wy powód pod­pi­sy­wa­nia umów o zacho­wa­niu pouf­no­ści (dru­gi to pra­wo regu­lu­ją­ce dostęp do infor­ma­cji w spół­kach giełdowych).

I teraz jesz­cze raz cyto­wa­na na począt­ku zasada:

Projekt sys­te­mu nie powi­nien wyma­gać jego taj­no­ści, a ewen­tu­al­ne jego ujaw­nie­nie nie powin­no przy­spa­rzać kłopotów.

I to jest ide­ał (ide­ali­za­cja) do pro­wa­dze­nia ana­liz. Punktem wyj­ścia w pro­jek­cie powin­na być ana­li­za spraw­dza­ją­ca czy fak­tycz­nie ujaw­nie­nie danej infor­ma­cji przy­no­si szko­dę a jeże­li tak, to dla­cze­go. Dalej: jeże­li know-how sta­no­wi sobą okre­ślo­ny mecha­nizm i jego ujaw­nie­nie przy­no­si szko­dę, to fak­tycz­nie nale­ży go – jego opis – chro­nić. Jak? Przede wszyst­kim taki, pre­cy­zyj­ny, opis musi w ogó­le powstać. Jeżeli z jakie­goś powo­du nie może być przed­mio­tem paten­tu, to pozo­sta­je pra­wo autor­skie. A sko­ro tak, to: (1) posia­da­czem pra­wa mająt­ko­we­go do opi­su know-how powi­nien być ten, kto chro­ni swo­je know-how, (2) jeże­li opro­gra­mo­wa­nie ma reali­zo­wać mecha­nizm sta­no­wią­cy know-how, to dostaw­ca (wyko­naw­ca) tego opro­gra­mo­wa­nia nie powi­nien mieć żad­nych praw do tego know-how, o ile tyl­ko fak­tycz­nie sta­no­wi ono o prze­wa­dze na rynku.

Ideał jest taki jak zasa­da powy­żej, wnio­sek zaś jest taki, że jeże­li o prze­wa­dze ryn­ko­wej sta­no­wi tajem­ni­ca, jej bez­pie­czeń­stwo sta­je się klu­czo­we. A jak chro­nić tajem­ni­cę czy­li infor­ma­cje? W ten sam spo­sób: sys­tem opi­su­ją­cy bez­pie­czeń­stwo infor­ma­cji opi­su­je się pro­ce­du­ra­mi i pro­ce­sa­mi :), a te wła­śnie (doku­men­ty opi­su­ją­ce pro­ce­sy), zgod­nie z zasa­dą opi­sa­ną na począt­ku, nie powin­ny wyma­gać ochrony…

Warto na koniec dodać, że na grun­cie usta­wy o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji know-how naby­wa­ne przez pra­cow­ni­ków IT pod­le­ga obo­wiąz­ko­wi ochro­ny tajem­ni­cy przed­się­bior­stwa, któ­ry od dnia 4 wrze­śnia 2018 r. został okre­ślo­ny jako bezterminowy…

Na zakończenie

Bardzo czę­sto jestem pyta­ny o róż­ni­cę pomię­dzy chro­nio­nym utwo­rem a chro­nio­nym know-how. Popatrzmy na poniż­szą map­kę, zna­ną z książ­ki (i gier) Wyspa Skarbów:

Otóż map­ka ta jest chro­nio­na pra­wem autor­skim jako obraz gra­ficz­ny. Jeżeli praw­dą zaś jest, że treść map­ki zawie­ra wie­dzę o tym jak dotrzeć do skar­bu, to wie­dza ta sta­no­wi know-how pira­tów i jest trzy­ma­na w tajem­ni­cy. Tak więc map­ka ta jest utwo­rem nio­są­cym wie­dzę o know-how. :). Wystarczająco pre­cy­zyj­ny pro­jekt archi­tek­tu­ry i logi­ki dzia­ła­nia opro­gra­mo­wa­nia jest tak­że utwo­rem, nio­są­cym wie­dzę o know-how.

A teraz popa­trz­cie Państwo na swo­je umo­wy z dostaw­ca­mi opro­gra­mo­wa­nia… i miej­cie ogra­ni­czo­ne zaufa­nie do praw­ni­ków firm dostaw­ców oprogramowania 🙂