Plansza do gry w szachy czyli analiza i projektowanie

Na ten wpis pew­nie wie­lu z Was cze­ka, tak przy­naj­mniej suge­ru­ją listy do mnie i gło­sy na forach, a tak­że poten­cjal­ni klien­ci. Ci, któ­rych nie­ste­ty cza­sem kry­ty­ku­ję, tak­że pew­nie cze­ka­ją. Pokażę na pro­stym przy­kła­dzie, pro­ces od ana­li­zy przez wyma­ga­nia aż do pro­jek­tu dedy­ko­wa­ne­go opro­gra­mo­wa­nia. Całość będzie zgod­na z faza­mi CIM/PIM (www​.omg​.org/​mda). Projekt dzie­dzi­ny, któ­ry powsta­nie będzie speł­niał zasa­dy SOLID pro­jek­to­wa­nia obiek­to­we­go, pro­jek­to­wa­nia przez kom­po­zy­cje (zamiast dzie­dzi­cze­nia) (pole­cam arty­kuł Łukasza Barana) i DDD. Opis doty­czy każ­de­go pro­jek­tu zwią­za­ne­go z opro­gra­mo­wa­niem, tak­że goto­wym np. ERP, CRM, EOD itp.

Korzystałem z opi­su zasad gry w sza­chy zamiesz­czo­ne­go na WIKI:

Zasady gry w sza­chy ? pra­wi­dła regu­lu­ją­ce spo­sób roz­gry­wa­nia par­tii sza­chów. Choć pocho­dze­nie gry nie zosta­ło dokład­nie wyja­śnio­ne, to współ­cze­sne zasa­dy ukształ­to­wa­ły się w śre­dnio­wie­czu. Ewoluowały one do począt­ków XIX wie­ku, kie­dy to osią­gnę­ły wła­ści­wie swą bie­żą­cą postać. W zależ­no­ści od miej­sca zasa­dy gry róż­ni­ły się od sie­bie, współ­cze­śnie za prze­pi­sy gry odpo­wia­da Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się róż­nić w przy­pad­ku róż­nych warian­tów gry, np. dla sza­chów szyb­kich, bły­ska­wicz­nych czy kore­spon­den­cyj­nych. (Zasady gry w sza­chy ? Wikipedia, wol­na ency­klo­pe­dia).

To na co chcę zwró­cić tu uwa­gę w szcze­gól­no­ści, to metafora:

pro­jek­tu­jąc (mode­lu­jąc) opro­gra­mo­wa­nie dla czło­wie­ka, mode­lu­je­my narzę­dzie dla tego czło­wie­ka a nie jego samego.

Swego cza­su pisa­łem, w arty­ku­le o nazy­wa­niu klas, że opro­gra­mo­wa­nie z regu­ły zastę­pu­je dotych­cza­so­we narzę­dzie czło­wie­ka a nie czło­wie­ka jako takie­go. Druga waż­na rzecz: aktor jest rów­no­praw­nym ele­men­tem sys­te­mu (tu sys­te­mem jest orga­ni­za­cja z jej ludź­mi i uży­wa­ny­mi przez nich narzę­dzia­mi). No to zaczynamy.

Czytaj dalej… Plansza do gry w sza­chy czy­li ana­li­za i pro­jek­to­wa­nie”

Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Opisywałem ostat­nio wzo­rzec DDD jako narzę­dzie doku­men­to­wa­nia ana­li­zy i two­rze­nia mode­li ana­li­tycz­nych. Faktycznie, czy­tel­ni­cy mają wie­le racji twier­dząc, że czę­sto jest on zbyt bli­ski imple­men­ta­cji (zbyt szcze­gó­ło­wy a więc trud­ny dla nie­pro­gra­mi­stów). Niejednokrotnie lep­szym pomy­słem” jest opis logi­ki sys­te­mu na nie­co wyż­szym pozio­mie abs­trak­cji, pozo­sta­wia­jąc tym samym wię­cej swo­bo­dy developerowi.

Od cza­su do cza­su uży­wam wzor­ca BCE (Boundary, Control Entity) do mode­lo­wa­nia logi­ki biz­ne­so­wej. Jego rodo­wód się­ga chy­ba jesz­cze cza­sów począt­ków [[meto­dy­ki RUP]]. Pierwotnie był trak­to­wa­ny jako wzo­rzec ana­li­tycz­ny do mode­lo­wa­nia archi­tek­tu­ry kom­pa­ty­bil­nej z MVC, w swej ory­gi­nal­nej posta­ci nawią­zu­je do EJB/DAO ([[Enterprise JavaBeans/Data Access Object]]). Przykładowe stan­dar­do­we uży­cia (źr. wiki):

Wzorzec BCE koja­rzo­ny jest głów­nie z archi­tek­tu­rą EJB ([[Enterprise Java Beans]]). Od tam­tej pory EJB jed­nak nie­co ode­szło w nie­pa­mięć”, nie mamy już J2EE a JEE. Wzorzec MVC docze­kał się sen­sow­nej moim muta­cji do wer­sji [[MVVMC]], [[Model-View-ViewModel Contoler]], [[MVP]] (i kil­ku innych odmian). Diagram w tej kon­wen­cji jest tak­że nazy­wa­ny „[[robust­ness dia­gram]]” i koja­rzo­ny jest z meto­dy­ką ICONIX, jed­nak oso­bi­ście pole­cam sto­so­wa­nie zasad UML i uży­wa­nie dia­gra­mu klas zgod­nie z jego zasa­da­mi” czy­li uży­wa­nie związ­ków uży­cia (linia prze­ry­wa­na z gro­tem a nie cią­gła) i uzna­nie, że robust­ness dia­gram to po pro­stu dia­gram klas.

Podstawowa pier­wot­na wer­sja inter­pre­ta­cji wzor­ca BCE opi­sa­na jest zwięź­le tutaj:

This pat­tern is simi­lar to the Model View Controller pat­tern (descri­bed here [BUS96] and here [WIKP-MVC] among other pla­ces), but the Entity Control Boundary pat­tern is not sole­ly appro­pria­te for dealing with user inter­fa­ces and it gives the con­trol­ler a sli­gh­tly dif­fe­rent role to play. (za Entity-Control-Boundary Pattern).

Stosuję go jed­nak w nie­co zmie­nio­nej” formie.

Boundary, Control, Entity

Jak widać na powyż­szym, BCE nawią­zu­je bez­po­śred­nio do wzor­ca MVC, kla­sy boun­da­ry są w tej wer­sji już ele­men­ta­mi kom­po­nen­tu View. Starając się oddzie­lić (her­me­ty­zo­wać) logi­kę biz­ne­so­wą od czę­ści nie­biz­ne­so­wej” kodu, będą­cej w więk­szo­ści przy­pad­ków ele­men­ta­mi śro­do­wi­ska ([[fra­me­work]]) aplikacji.

Nieco inne podej­ście, to któ­re sto­su­ję obec­nie, opi­su­ję poni­żej. Zachowując pod­sta­wo­we zna­cze­nia tych trzech klas (BCE), nawią­za­łem do wzor­ca MVVM. Powstaje więc kon­struk­cja, w któ­rej Model ma struk­tu­rę M‑VM, pozo­sta­łe ele­men­ty View i Controler mają kon­kret­ne zadania:

  • M‑VM to struk­tu­ra czę­ści dzie­dzi­no­wej (Model-ViewModel),
  • View – tra­dy­cyj­nie odpo­wia­da za prezentację,
  • Controler – tra­dy­cyj­nie odpo­wia­da za zarzą­dza­nie cało­ścią, w tym poza-funk­cjo­nal­ne wyma­ga­nia (np. kodo­wa­nie trans­fe­ru danych nie jest ele­men­tem dzie­dzi­ny sys­te­mu, itp.)

Pewna cie­ka­wost­ką jest w tym wzor­cu wła­śnie ele­ment VM (ViewModel). Jego idea pole­ga na umiesz­cze­niu w obsza­rze dzie­dzi­ny dodat­ko­wej wie­dzy (logi­ki), ste­ru­ją­cej tym jakie (cho­dzi o ich bogac­two”) infor­ma­cje są poda­wa­ne na urzą­dze­nia pre­zen­tu­ją­ce o róż­nych moż­li­wo­ściach np. mały lub duży ekran, roz­dziel­czość czy wręcz komu­ni­ka­cja z pomo­cą SMS.

Powyższy dia­gram poka­zu­je sche­mat budo­wa­nia mode­lu na bazie tego wzor­ca. Jak widać ele­ment dzie­dzi­ny Model zacho­wu­je się zawsze tak samo, repre­zen­tu­je wie­dzę i logi­kę dzie­dzi­no­wą (np. kom­plet infor­ma­cji o oso­bie), Dziedzina (Model) jest dodat­ko­wo wypo­sa­żo­na w wie­dzę o moż­li­wo­ściach pre­zen­to­wa­nia peł­nej lub okro­jo­nej wer­sji wie­dzy publi­ko­wa­nej przez obiekt dzie­dzi­no­wy (kla­sy ViewModel). Dzięki temu View nie zawie­ra żad­nej logi­ki np. fil­tro­wa­nia peł­nej infor­ma­cji, dosta­je tyl­ko pro­sty przy­go­to­wa­ny zestaw danych do pre­zen­ta­cji poza samą pre­zen­ta­cją (dla uprosz­cze­nia pomię­to kom­po­nent Controller).

Jest to o tyle wygod­ne i waż­ne, że sto­so­wa­nie wzor­ca BCE wyłącz­nie do mode­lo­wa­nia logi­ki biz­ne­so­wej wyma­ga zacho­wa­nia her­me­ty­za­cji kom­po­nen­tu Model. Spotkać się moż­na z dia­gra­ma­mi, w któ­rych boun­da­ry będzie ele­men­tem kom­po­nen­tu Model (jako ViewModel). Jego rola to stwo­rze­nie dedy­ko­wa­ne­go inter­fej­su np. pomię­dzy kom­po­nen­tem View (lub Controller) a Model. Dzięki temu moż­li­we jest np. stwo­rze­nie odręb­ne­go inter­fej­su dla View na duży ekran i odręb­ne­go dla View na np. małych ekra­nach smart­fo­nów. Takie podej­ście wyglą­da tak:

Znaczenie (seman­ty­ka) stereotypów:

Boundary to kla­sa ozna­czo­na ste­reo­ty­pem «boun­da­ry», na dia­gra­mach repre­zen­to­wa­na może być iko­ną jak po lewej. Odpowiedzialność klas boun­da­ry to sepa­ra­cja mode­lu dzie­dzi­ny od innych kom­po­nen­tów (to czę­sto adap­ter, fasa­da, inter­fejs). Dzięki temu ewen­tu­al­ne zmia­ny Modelu nie prze­nio­są się na kom­po­nen­ty View i Controller oraz może­my zbu­do­wać np. róż­ne dedy­ko­wa­ne i bez­piecz­ne dzie­dzi­no­we adap­te­ry dostę­po­we do Modelu (np. w sys­te­mie nawi­ga­cyj­nym boun­da­ry dostar­czy Modelowi koor­dy­na­ty geo­gra­ficz­ne, View pozwo­li wpro­wa­dzić je z kla­wia­tu­ry a Controller z odbior­ni­ka – inter­fejs – GPS, Model sta­je nie­czu­ły na źró­dło tych koordynatów).

Control. Klasy ozna­czo­ne ste­reo­ty­pem «con­trol» lub iko­ną jak po lewej. Są to kla­sy odpo­wie­dzial­ne za wewnętrz­ne usłu­gi spe­cy­ficz­ne dla dzie­dzi­ny, umie­jęt­no­ści”. Nie są to kla­sy utrwa­la­ne. Ta kla­sa będzie obli­cza­ła np. czas prze­jaz­du na bazie wyty­czo­nej w sys­te­mie nawi­ga­cji strasy.

Entity. Najbardziej kon­tro­wer­syj­na kla­sa, w pier­wot­nej wer­sji inter­pre­ta­cji wzor­ca BCE (EJB) ozna­cza­ła tyl­ko dane utrwa­la­ne, nawią­zu­jąc do EJB sta­no­wi­ła mate­riał” na tak zwa­ny [[antyw­zo­rzec obiek­to­wy o nazwie ane­micz­ny model dzie­dzi­ny]]. Klas ozna­czo­nych ste­reo­ty­pem «enti­ty» uży­wa­my do mode­lo­wa­nia wie­dzy, czy­li zgro­ma­dzo­nych danych, nie są to jed­nak ane­micz­ne kla­sy bez ope­ra­cji. Będą to np. punk­ty na mapie cyfrowej.

Trzy powyż­sze typy klas są tu ele­men­ta­mi kom­po­nen­tu Model. Syntaktyka odwo­łań ele­men­tów wzor­ca BCE:

Obrazowo wyglą­da to tak:

Przejście na poziom DDD, dro­gę w kie­run­ku imple­men­ta­cji tego mode­lu przy powyż­szych zało­że­niach, moż­na reali­zo­wać np. tak:

Interpretacja ta pozwa­la zacho­wać głów­ny cel czy­li roz­ło­że­nie logi­ki Modelu na pro­stą” mapę trzech ele­men­tów: kon­tak­tu z oto­cze­niem (boun­da­ry), reali­za­cji logi­ki i reguł (con­trol) oraz zacho­wy­wa­nia bier­nych” obiek­tów biz­ne­so­wych (enti­ty). Mała adap­ta­cja kon­wen­cji do wzor­ca MVVM-V‑C pozwa­la uzy­skać kom­fort cał­ko­wi­tej sepa­ra­cji tak mode­lo­wa­ne­go Modelu od jego otoczenia.

Tak więc jest to moim zda­niem dro­ga do mode­lo­wa­nia wyma­gań meto­dą tak to ma dzia­łać” a nie tyl­ko tak to ma wyglą­dać”, bo to dru­gie jest przy­czy­ną wie­lu problemów…

Wielu deve­lo­pe­rów zacie­kle bro­ni się przed tezą, że wyma­ga­nia to tak­że żąda­na reali­za­cja logi­ki biz­ne­so­wej”, ocze­ku­ją wyłącz­nie zesta­wu: wyma­ga­nia funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Jest to moim zda­niem źró­dło dwóch ryzyk:

  • jeże­li zamó­wie­nie jest opi­sem czar­nej skrzyn­ki tak na praw­dę nie wie­my do dosta­nie­my jako jej realizację,
  • jeże­li auto­rem reali­za­cji jest dostaw­ca pozo­sta­je mu nie­zby­wal­ne autor­skie pra­wo oso­bi­ste do pro­jek­tu tej reali­za­cji (mająt­ko­we­go nie musi wydać).

Dlatego war­to, jako wyma­ga­nie prze­ka­zać pro­jekt tak zwa­nej bia­łej skrzyn­ki”, bo zabez­pie­cza to nas przed powyż­szy­mi ryzykami. 

Literatura

Polecam cie­ka­wy arty­kuł na podob­ny temat:

As we have seen, the fun­da­men­tal idea of MVC is a sepa­ra­tion of the doma­in logic and the GUI objects into the Model and the View. These two are lin­ked indi­rec­tly by using the Publish-Subscribe mecha­nism known as the Observer pat­tern. Another ele­ment of this design is a Controller that imple­ments a par­ti­cu­lar stra­te­gy for the View. (Model View Controller, Model View Presenter, and Model View ViewModel Design Patterns – CodeProject).

Oraz (apro­po MVVM iMVC):

Warto pisać apli­ka­cje w taki spo­sób, żeby moż­na było je w cało­ści obsłu­gi­wać za pomo­cą testów jed­nost­ko­wych. Jak nale­ży to rozu­mieć? Budując apli­ka­cję w taki spo­sób, że cała jej funk­cjo­nal­ność dostęp­na jest bez inter­fej­su użyt­kow­ni­ka, możesz każ­dy jej aspekt opi­sać za pomo­cą testów jed­nost­ko­wych. To pozwa­la na wstęp­ne testo­wa­nie zgod­no­ści apli­ka­cji z wyma­ga­nia­mi wstęp­ne, bo cały czas nale­ży pamię­tać, że testy jed­nost­ko­we to narzę­dzie, wspie­ra­ją­ce pro­gra­mi­stów, a nie teste­rów i jako takie nie może zastą­pić testów apli­ka­cji. (Wykorzystanie TDD wraz ze wzor­cem MVVM).

Kiedy i po co robimy te modele?

Tu nawią­żę do MDA (tu co nie­co o Model Driven Architecture). W łań­cu­chu mode­li MDA mamy trzy mode­le: CIM->PIM->PSM. Analiza biz­ne­so­wa na pierw­szym eta­pie to two­rze­nie mode­lu orga­ni­za­cji pomi­ja­ją­ce­go ist­nie­nie jakie­go­kol­wiek opro­gra­mo­wa­na (CIM – [[Computation Independent Model]]), celem jest peł­ne zro­zu­mie­nie i opi­sa­nie funk­cjo­no­wa­nia organizacji.

Kolejny etap to opra­co­wa­nie mode­lu dzie­dzi­ny pro­jek­to­wa­ne­go (wyma­ga­ne­go) opro­gra­mo­wa­nia. To model PIM ([[Platform Independent Model]]). Jego celem jest udo­ku­men­to­wa­nie logi­ki opro­gra­mo­wa­nia, wyma­ga­nia poza funk­cjo­nal­ne są reali­zo­wa­ne nie­za­leż­nie od tej logi­ki. Tak więc model PIM do coś co nazy­wa­ne bywa: wyma­ga­nia dzie­dzi­no­we”. Wymagania funk­cjo­nal­ne nie opi­su­ją w ogó­le logi­ki biz­ne­so­wej, same przy­pad­ki uży­cia nie są wystar­cza­ją­ce do napi­sa­nia opro­gra­mo­wa­nia, potrzeb­na jest wie­dza o logi­ce biz­ne­so­wej. Funkcjonalność sys­tem sprze­da­ży auto­ma­tycz­nie uwzględ­nia upu­sty dla klien­tów” nic nie mówi. Ale gdzie defi­ni­cja logi­ki udzie­la­nia tych upu­stów? Gdzie jest wie­dza o upu­stach a gdzie o towa­rach? Przy klien­cie czy przy towa­rze? Nie wia­do­mo, trze­ba to jakoś zro­zu­mieć i udo­ku­men­to­wać, w spo­sób pozwa­la­ją­cy na imple­men­ta­cją czy­li jed­no­znacz­nie. I po to się two­rzy mode­le PIM.

Tu jed­nak nale­ży się mała uwa­ga (bo nigdy nie mów nigdy): bywa, że ogra­ni­cze­nie o tre­ści mak­sy­mal­ny czas ocze­ki­wa­nia na ofer­tę nie może prze­kro­czyć pro­gu cier­pli­wo­ści 80% klien­tów”. Pozostaje zba­da­nie pro­gu cier­pli­wo­ści”, ten para­metr nie jest ele­men­tem regu­ły biz­ne­so­wej gdyż jest wła­śnie para­me­trem” a nie zasa­dą” (regu­ły biz­ne­so­we to zasa­dy postę­po­wa­nia a nie regu­ły podej­mo­wa­nia decy­zji czy mier­ni­ki). Ta regu­ła może stać się ele­men­tem dzie­dzi­ny pro­jek­to­wa­ne­go sys­te­mu jeże­li np. jej speł­nie­nie jest ele­men­tem budo­wy prze­wa­gi ryn­ko­wej. Co to zna­czy? Że nie nale­ży opty­ma­li­zo­wać obec­ne­go mode­lu dzie­dzi­ny (np. pod­no­sze­nie wydaj­no­ści poprzez uprosz­cze­nie struk­tu­ry opi­su pro­duk­tów) a dodać do dzie­dzi­ny struk­tu­rę pozwa­la­ją­cą na wyko­ny­wa­nie pew­nych wybra­nych czyn­no­ści pro­ściej i szyb­ciej. To jed­nak temat o wzor­cu pro­jek­to­wym CQRS ale to temat na inny arty­kuł.

(inne źró­dła:

basic rules apply: Actors can only talk to boun­da­ry objects.Figure 3. Robustness Analysis RulesBoth boun­da­ry objects and enti­ty objects are nouns, and con­trol­lers are verbs. Nouns can’t talk to other nouns, but verbs can talk to either nouns or verbs. Boundary objects can only talk to con­trol­lers and actors. Entity objects can only talk to con­trol­lers. Controllers can talk to boun­da­ry objects and enti­ty objects, and to other con­trol­lers, but not to actors

źr. Memorandum).

Sprzedam Ci prawa do kodu czyli wielka ściema

Wczoraj mia­ła miej­sce kon­fe­ren­cja Forum pra­wa nowych tech­no­lo­gii zor­ga­ni­zo­wa­na przez Centrum Promocji Informatyki. Jednak to nie mój refe­rat z tego semi­na­rium, a pew­na kon­klu­zja po burz­li­wej dys­ku­sji, będzie dziś tema­tem przewodnim.

To o czym był mój refe­rat, to ochro­na know-how zama­wia­ją­ce­go (opis spo­so­bu pra­cy orga­ni­za­cji) i ochro­na tego co zamó­wił i za co zapła­cił (opro­gra­mo­wa­nie jak utwór). Ale tu będzie o kodzie i pra­wach do nie­go… (kto nie był na kon­fe­ren­cji niech żałuje ;))

Przytoczmy na począ­tek defi­ni­cję tego co chro­ni pra­wo autor­skie” czy­li czym jest przed­miot pra­wa autorskiego”:

Przedmiotem pra­wa autor­skie­go jest 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 (utwór) (źr. Ustawa z dnia 4 Lutego 1994 roku o pra­wie autor­skim i pra­wach pokrewnych).

2/3 kon­fe­ren­cji praw­ni­cy wyka­zy­wa­li, że jedy­ne co moż­na sku­tecz­nie chro­nić pra­wem (albo wyce­niać) to stan udo­ku­men­to­wa­ny. Czyli, jeże­li chce­my chro­nić wie­dzę o swo­jej wewnętrz­nej orga­ni­za­cji, tak zwa­ny know-how, oraz pomysł na to co powin­no umieć” zama­wia­ne opro­gra­mo­wa­nie by nam poma­ga­ło, nale­ży posłu­żyć się pra­wem autor­skim, tajem­ni­cą przed­się­bior­stwa i mieć to w posta­ci udo­ku­men­to­wa­nej. Zapis, któ­ry od lat poma­ga mi i moim klien­tom chro­nić pro­jek­ty i know-how brzmi tak (moż­na go użyć w swo­ich dokumentach :)):

Treść doku­men­tu jest chro­nio­na na mocy USTAWY z dnia 16 kwiet­nia 1993 r. o zwal­cza­niu nie­uczci­wej kon­ku­ren­cji oraz na mocy USTAWY z dnia 4 lute­go 1994 r. o pra­wie autor­skim i pra­wach pokrew­nych. Posiadanie egzem­pla­rza tego opra­co­wa­nia nie sta­no­wi naby­cia jakich­kol­wiek praw do jego treści.

(szcze­gó­ły ustaw i para­gra­fów były pre­zen­to­wa­ne na semi­na­rium, w razie potrze­by pole­cam wizy­tę w dobrej kan­ce­la­rii prawnej).

Ale po kolei czyli…

Jak to – ochrona know-how i kodu który ktoś nam napisał – można robić

Opiszę to języ­kiem dla osób nie zna­ją­cych inży­nie­rii oprogramowania.

Pierwszą rze­czą jaką war­to chro­nić jest wypra­co­wa­na wewnętrz­na orga­ni­za­cja pra­cy, spo­sób pra­cy fir­my czy­li pro­ce­du­ry, regu­ły biz­ne­so­we, kom­pe­ten­cje pra­cow­ni­ków (i wie­le innych). Kompletny taki opis, raport z audy­tu orga­ni­za­cji, zawie­ra mode­le pro­ce­sów biz­ne­so­wych sko­ja­rzo­ne z pro­ce­du­ra­mi, zakre­sa­mi obo­wiąz­ków, regu­ła­mi biz­ne­so­wy­mi itp. Tak powsta­je udo­ku­men­to­wa­ne nasze know-how”.

Kolejna rzecz to opra­co­wa­nie opi­su a cza­sem pro­jek­tu, opro­gra­mo­wa­nia, któ­re chce­my nabyć lub zamó­wić, a kon­kret­nie tego co i jak ono powin­no umieć”. Opis taki nie powi­nien poprze­sta­wać tyl­ko na tym co-ma-sys­tem-robić (wyma­ga­nia w posta­ci przy­pad­ków uży­cia). Firmy róż­nią się tym jak-to-jest-robio­ne u nich, więc nie wystar­czy napi­sać, że sys­tem ma wspie­rać przy­ję­cia na maga­zyn i sto­so­wać usta­lo­ne meto­dy zarzą­dza­nia kosz­ta­mi pro­duk­tów”. Powierzenie dostaw­cy zada­nia udo­ku­men­to­wa­nia (ana­li­za przed-wdro­że­nio­wa) np. meto­dy zarzą­dza­nia pro­duk­ta­mi” na 99% zaowo­cu­je opi­sem tego co dostaw­ca może zaofe­ro­wać, a nie tego jak-pra­cu­je-zama­wia­ją­cy i co jest mu potrzeb­ne. Po dru­gie auto­rem pomy­słu” będzie dostaw­ca (wyko­naw­ca) więc do nie­go będą nale­ża­ły pra­wa do wła­sno­ści inte­lek­tu­al­nej zawar­tej w opro­gra­mo­wa­niu – a tego wła­śnie nie chcemy.

Co i jak udokumentować? Czy to się da?

Owszem, poni­żej meto­da opi­sa­na jako stan­dard (opis dostęp­ny za dar­mo bez żad­nych opłat) na stro­nach http://​www​.omg​.org/​mda:

Co może­my. Etap pierw­szy to udo­ku­men­to­wa­nie know-how fir­my czy­li model orga­ni­za­cji i spo­so­bu jej dzia­ła­nia (opi­sy­wa­ny na stro­nach tego blo­ga wie­lo­krot­nie). Jak już wspo­mnia­łem, ele­men­tem know-how są udo­ku­men­to­wa­ne mode­le pro­ce­sów biz­ne­so­wych, regu­ły biz­ne­so­we i struk­tu­ra orga­ni­za­cji. Ten opis, jako doku­ment, jest chro­nio­ny pra­wem autor­skim jako dzie­ło, treść zaś jest chro­nio­na pra­wem o prze­ciw­dzia­ła­niu nie­uczci­wej kon­ku­ren­cji jako know-how fir­my. Warunek: taki opis MUSI ist­nieć a pra­wa mająt­ko­we do nie­go powi­nien posia­dać opi­sa­ny w nim pod­miot. Autor, jeże­li nie był pra­cow­ni­kiem fir­my pod­czas two­rze­nia, powi­nien mieć dodat­ko­wo umo­wę o pouf­no­ści i po zakoń­cze­niu pra­cy prze­ka­zać pisem­nie pra­wa mająt­ko­we do dzie­ła swo­je­mu klien­to­wi.

Tak więc, jeże­li ktoś z zewnątrz robi taką ana­li­zę (np. pra­cow­nik dostaw­cy opro­gra­mo­wa­nia czy nie­za­leż­ny kon­sul­tant) i nie chce prze­ka­zać praw mająt­ko­wych do opra­co­wa­nia, orga­ni­za­cji ana­li­zo­wa­nej, to nale­ży się zacząć bać. Na powyż­szym dia­gra­mie ten etap nazy­wa Computing Independent Mode (model dzia­ła­nia orga­ni­za­cji na pozio­mie nie­za­leż­nym od uży­wa­nych sys­te­mów IT).

Chcemy mieć oprogramowanie wspomagające nasz biznes

Na bazie powyż­szej doku­men­ta­cji powsta­je opis, któ­re obsza­ry dzia­ła­nia fir­my chce­my wspie­rać opro­gra­mo­wa­niem i jak. To okre­śle­nie zakre­su pro­jek­tu. Następnie, w mode­lach pro­ce­sów wska­zu­je­my czyn­no­ści, któ­re mają być wspie­ra­ne nowym opro­gra­mo­wa­niem. To ocze­ki­wa­ne funk­cjo­nal­no­ści (usłu­gi apli­ka­cyj­ne) nowe­go opro­gra­mo­wa­nia (w nota­cji UML nazy­wa­ne przy­pad­ka­mi uży­cia). Dodajemy do nich ele­men­ty jako­ścio­we czy­li wyma­ga­nia poza-funk­cjo­nal­ne (ogra­ni­cze­nia np. nie­za­wod­ność, bez­pie­czeń­stwo itp.). To jed­nak za mało, to tyl­ko opis tego co-sys­tem-ma-robić (idea).

Jednoznaczne są dopie­ro opi­sy logi­ki biz­ne­so­wej, czy­li jak-sys­tem-ma-to-robić (w koń­cu sys­tem poza zapi­sy­wa­niem, prze­twa­rza nasze dane), opis tego, cze­go ocze­ku­je­my od tego opro­gra­mo­wa­nia (co ono powin­no umieć). To kolej­ny opis, udo­ku­men­to­wa­ne coś, co chce­my chro­nić. Zakładam, że spe­cy­fi­ka fir­my, wypra­co­wa­na logi­ka biz­ne­so­wa, to dobro war­te ochro­ny. Taki opis to war­stwa dru­ga od góry na powyż­szym dia­gra­mie (model opro­gra­mo­wa­nia PIM, Platform Independent Model). Do tego doku­men­tu tak­że nale­ży mieć pra­wa mająt­ko­we. Ten model to już szcze­gó­ło­wy pro­jekt, jedy­ne cze­go może nie zawie­rać to spe­cy­fi­ka uży­te­go języ­ka pro­gra­mo­wa­nia czy wyko­rzy­sta­ne ele­men­ty cudze­go opro­gra­mo­wa­nia (tak zwa­ne biblio­te­ki, fra­me­wor­ki, śro­do­wi­sko sys­te­mo­we pra­cy itp…). Także inne, nie będą­ce spe­cy­fi­ką fir­my (tym co chce­my chro­nić) stan­dar­do­we ele­men­ty takie jak logo­wa­nie do sys­te­mu czy np. spo­sób drukowania.

A teraz niech nam to dostarczą

No to szu­ka­my dostaw­cy (wyko­naw­cy) opro­gra­mo­wa­nia: robi­my listę poten­cjal­nych dostaw­ców, ktoś wygry­wa prze­targ, pod­pi­su­je­my umo­wę o pouf­no­ści, wyko­naw­ca dosta­je do wyko­rzy­sta­nia udo­ku­men­to­wa­ny know-how, pra­wo autor­skie chro­ni taki opis z zasa­dy. Wyłaniamy dostaw­cę, pro­jekt dobie­ga koń­ca. Dostawca nie ma moż­li­wo­ści praw­nej zaofe­ro­wa­nia tego opro­gra­mo­wa­nia (tego co obej­mu­je nasza spe­cy­fi­kę) niko­mu inne­mu. Wszystko co zro­bił na bazie naszej doku­men­ta­cji jest dzie­łem zależ­nym, bez naszej zgo­dy wyko­naw­ca nie ma pra­wa tym kodem dys­po­no­wać. Jesteśmy uratowaniu :)!

A może chcecie prawa do kodu źródłowego?

A jasne, może­my chcieć. No to zapłać­cie za to pra­wo”. A prze­pra­szam za co teraz? Kod, któ­ry powstał to utwór zależ­ny, jest więc chro­nio­ny i już mamy na nie­go wyłącz­ność, nie musi­my eks­tra za to pła­cić. Ale nie chce­my tego sami pisać (kodo­wać) jesz­cze raz. No dobrze, patrzy­my na fak­tu­ry, a tam jest kil­ka­set godzin pro­gra­mi­stów. Czyli co? Już zapła­ci­li­śmy za ich pra­cę, za ten kod! Wystarczy!

Kiedy pojawia się problem?

W więk­szo­ści przy­pad­ków z jaki­mi się nie­ste­ty spo­ty­kam to pro­jek­ty, w któ­rych nie powsta­ła opi­sa­na tu doku­men­ta­cja. Jaki mamy efekt? No jest kod, wszel­kie pra­wa do nie­go i jego logi­ki ma wyko­naw­ca (jest auto­rem cało­ści). Specyfikacja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych pod­le­ga wyłącz­nie ochro­nie jako dzie­ło lite­rac­kie, jed­nak nie­ste­ty to-co-pro­gram-ma-robić to tyl­ko idea, a ta nie pod­le­ga ochro­nie (stwier­dze­nie fak­tu, że wysta­wia­my fak­tu­ry, jako treść, nie sta­no­wi żad­ne­go zdat­ne­go do ochro­ny tajem­ni­cą fir­my know-how). Tak więc wszel­kie pra­wa do kodu ma w takim wypad­ku pro­gra­mi­sta bo sam od zera to napi­sał (kod).

Pada pro­po­zy­cja: za dodat­ko­we pie­nią­dze sprze­da­my pra­wa mająt­ko­we do kodu, będzie­cie się Państwo czu­li bez­piecz­nie. I teraz pyta­nie: jaką war­tość ma nie­udo­ku­men­to­wa­ny kod opro­gra­mo­wa­nia? Tysiące linii kodu pro­gra­mu, nie raz kil­ka milio­nów, pisa­ny bez pro­jek­tu w wie­lu ite­ra­cjach. Mamy któ­rąś tam jego wer­sję, w koń­cu powsta­wał w bólach, wie­lo­krot­nie mody­fi­ko­wa­ny, bez pro­jek­tu. Nakład pra­cy wie­lo­krot­nie prze­wyż­sza­ją­cy jego powtór­ne prze­pi­sa­nie. Kto i jakim kosz­tem będzie ten kod ana­li­zo­wał by go zro­zu­mieć i roz­wi­jać? Ten kod, bez jego auto­ra, jest z regu­ły BEZWARTOŚCIOWY a My, bez tej opła­ty, nie mamy żad­nych praw do tego za co zapła­ci­li­śmy (poza licen­cją czy­li pra­wem do korzy­sta­nia). Pat.

Tak więc niejednokrotnie oferta na sprzedaż praw do kodu to zwykła ściema”!

złodziej

A jak to wyglą­da w przy­pad­ku zaku­pu goto­we­go ERP i jego kasto­mi­za­cji”? Jest to cudzy pro­dukt, zapew­ne może­my dostać pra­wa do kodu na wła­sny uży­tek” w co jed­nak wąt­pię, raczej dosta­nie­my licen­cje na uży­wa­nie. A nasze know-how? Jeżeli nasze dedy­ko­wa­ne wyma­ga­nia zosta­ły zre­ali­zo­wa­ne” w posta­ci kasto­mi­za­cji kodu tego pro­duk­tu, to i tak nadal jest on wła­sno­ścią dostaw­cy (pro­du­cen­ta) i nic nam do nie­go. Niektóre fir­my idą dalej, pod­ty­ka­ją” swo­im klien­tom aneks do umo­wy, z zapi­sem, że kod powsta­ły pod­czas wdro­że­nia (w tym kasto­mi­za­cja), zawie­ra­ją­cy pomy­sły na nowe funk­cjo­nal­no­ści w cało­ści prze­cho­dzi na wła­sność dostaw­cy opro­gra­mo­wa­nia ERP. Jeżeli zgo­dzi­cie się na to, nie zdziw­cie się gdy dowie­cie się np. z gaze­ty, że jakaś fir­ma kupi­ła od Waszego part­ne­ra” moduł z logi­ką biz­ne­so­wą wasze­go pomysłu”…

U nie­któ­rych praw­ni­ków moż­na się spo­tkać z tezą:

Zgodnie usta­wą o pra­wie autor­skim i pra­wach pokrew­nych pro­gra­my kom­pu­te­ro­we pod­le­ga­ją ochro­nie jak utwo­ry lite­rac­kie, o ile prze­pi­sy roz­dzia­łu VII usta­wy nie sta­no­wią ina­czej. Taki zapis sta­tu­uje więc ogól­ną zasa­dę włą­cze­nia pro­gra­mów kom­pu­te­ro­wych pod reżim ochro­ny praw­no­au­tor­skiej, zrów­nu­jąc je w tym aspek­cie z utwo­ra­mi literackimi.

Ochrona przy­zna­na pro­gra­mo­wi kom­pu­te­ro­we­mu obej­mu­je wszyst­kie for­my jego wyra­że­nia. Natomiast idee i zasa­dy będą­ce pod­sta­wą jakie­go­kol­wiek ele­men­tu pro­gra­mu kom­pu­te­ro­we­go, w tym pod­sta­wą łączy, nie pod­le­ga­ją ochro­nie (w pra­wie autor­skim idee ? wsze­la­kie ? nie są chro­nio­ne). O ile ele­men­ty tek­sto­we pro­gra­mu (w zna­cze­niu kon­kret­ne­go przed­sta­wie­nia cią­gu instruk­cji) pod­le­ga­ją ochro­nie, o tyle w przy­pad­ku ele­men­tów poza­tek­sto­wych (algo­rytm – struk­tu­ra pro­gra­mu języ­ka pro­gra­mo­wa­nia) trze­ba się raczej liczyć z ich wyłą­cze­niem spod ochro­ny pra­wa autor­skie­go. (Kod źró­dło­wy – aspek­ty praw­ne).

To podej­ście jest nie­kom­plet­ne, gdyż pomi­ja aspekt (ewen­tu­al­ny etap) pro­jek­to­wa­nia jako eta­pu two­rze­nia opro­gra­mo­wa­nia. Zresztą nie tyl­ko opro­gra­mo­wa­nia ale tak­że spe­cy­fi­ki orga­ni­za­cji, któ­ra może zostać zawar­ta” w opro­gra­mo­wa­niu w posta­ci spe­cy­ficz­nej, uni­kal­nej logi­ki działania. 

Skoro Ochrona przy­zna­na pro­gra­mo­wi kom­pu­te­ro­we­mu obej­mu­je wszyst­kie for­my jego wyra­że­nia” to zna­czy, że każ­dy jed­no­znacz­ny jego pro­jekt tak­że. Ustawa nie sta­no­wi, że jedy­nie for­ma tek­sto­wa pro­gra­mu pod­le­ga ochro­nie, ochro­nie pod­le­ga każ­da for­ma wyra­że­nia dzie­ła. Prawo autor­skie chro­ni w jed­na­ko­wym stop­niu tekst, zdję­cia czy pra­ce gra­ficz­ne, sche­mat blo­ko­wy (szcze­gó­ło­wy algo­rytm) tak­że pod­le­ga ochro­nie, bo speł­nia kry­te­rium uni­kal­no­ści. Skoro mamy tech­no­lo­gię (meto­dy), pozwa­la­ją­cą napi­sać kod pro­gra­mu na bazie jego sche­ma­tu blo­ko­we­go (a nawet cza­sem auto­ma­tycz­nie wyge­ne­ro­wać) to taki dokład­ny sche­mat blo­ko­wy tak­że pod­le­ga ochro­nie z tytu­łu pra­wa autor­skie­go jako dzie­ło. To już nie jest idea a program.

Jeżeli dodat­ko­wo ten algo­rytm opi­su­je spe­cy­fi­kę pra­cy danej fir­my to pod­le­ga tak­że ochro­nie jako tajem­ni­ca przed­się­bior­stwa. Jest więc nie­ja­ko podwój­nie chro­nio­ny. Oczywiście, co pod­kre­ślam po raz kolej­ny, sche­mat blo­ko­wy o jakim mowa musi być jed­no­znacz­ny, nie może to być tyl­ko zapis pomy­słu”. Z per­spek­ty­wy dia­gra­mów BPMN i UML (gra­ficz­ne języ­ki) mamy więc:

  1. BPMN: model pro­ce­su na wyso­kim pozio­mie abs­trak­cji (np. dwa blocz­ki: pro­ces sprze­da­ży połą­czo­ny z pro­ce­sem obsłu­gi rekla­ma­cji) to idea,
  2. BPMN: dokład­ny sce­na­riusz (pro­ce­du­ra) obsłu­gi sprze­da­ży spe­cy­ficz­ny dla kon­kret­nej fir­my, obra­zu­ją­cy spe­cy­fi­kę kom­pe­ten­cji jej pra­cow­ni­ków i funk­cjo­no­wa­nia, to pod­le­ga­ją­cy ochro­nie opis know-how fir­my, dia­gram to opi­su­ją­cy wraz z opi­sem i komen­ta­rza­mi to utwór chro­nio­ny pra­wem autor­skim. Stanowi zapis know-how. 
  3. UML: dia­gram przy­pad­ków uży­cia: to idea pomy­słu (podob­nie jak tek­sto­wa spe­cy­fi­ka­cja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych), to wyłącz­nie dzie­ło lite­rac­kie, pro­gram jaki powsta­nie na tej pod­sta­wie nie jest wią­za­ny z taką spe­cy­fi­ka­cją jako utwór zależ­ny, jest dzie­łem programisty.
  4. UML: dia­gram klas – model poję­cio­wy, to jedy­nie idea,
  5. UML: dia­gram klas jako pro­jekt logi­ki i struk­tu­ry pro­gra­mu (zawie­ra atry­bu­ty i ope­ra­cje, tam gdzie to koniecz­ne, tak­że algo­ryt­my metod) oraz uzu­peł­nia­ją­ce go dia­gra­my maszy­ny sta­no­wej i sekwen­cji (obra­zu­ją szcze­gó­ło­wo jak opro­gra­mo­wa­nie ma dzia­łać) to już zapis ana­lo­gicz­ny do kodu pro­gra­mu, jest chro­nio­ny jako dzie­ło lite­rac­kie, ale kod jaki powsta­nie na tej posta­wie jest prak­tycz­nie w 100% jego odzwier­cie­dle­niem (wier­ne odzwier­cie­dle­nie sche­ma­tu blo­ko­we­go). Podlega ochro­nie jako dzie­ło lite­rac­kie oraz tak­że jako know-how. Program jaki powsta­nie na pod­sta­wie tak opra­co­wa­ne­go opi­su ma sta­tus tłu­ma­cze­nia (utwór zależny). 

Więc kod napi­sa­ny pod dyk­tan­to” pro­jek­tan­ta nie jest nie­za­leż­nym dzie­łem pro­gra­mi­sty, nie ma on (pro­gra­mi­sta) pra­wa do swo­bod­ne­go dys­po­no­wa­nia takim kodem, podob­nie jak tłu­macz tek­stu nie naby­wa auto­ma­tycz­nie ani praw do dys­po­no­wa­nia tłu­ma­cze­niem, któ­re opra­co­wał, ani, w szcze­gól­no­ści, do tek­stu źró­dło­we­go, któ­ry przetłumaczył.

Zaprezentowana opi­nia praw­na, moim zda­niem pomi­ja więc waż­ny fakt, że poza języ­ka­mi pro­gra­mo­wa­nia tek­sto­wy­mi”: taki­mi jak Java, Pascal czy .NET ist­nie­ją tak­że języ­ki gra­ficz­ne takie jak np. UML. Opinia powyż­sze (przy­to­czo­ny cytat) jest praw­dzi­wa pod warun­kiem, że mowa o powyż­szych dia­gra­mach na pozio­mie ogól­nym, idei. Jednak pro­jek­ty ozna­czo­ne kolo­rem czer­wo­nym to przy­pad­ki pod­le­ga­ją­ce już peł­nej ochronie.