Odpowiedzialność administratora systemu

Wstęp

pra­wie 10 lat temu pisałem:

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

Dzisiaj czy­tam:

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

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

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

Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

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

Wstęp

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

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

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

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

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

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

Dozwolony użytek programów komputerowych czyli o interfejsach

Wstęp

Dzisiejszy wpis to efekt lek­tu­ry arty­ku­łu Pani Mec. Marty Pasztaleniec na stro­nie IP Procesowo. Kluczowe dla dzi­siej­sze­go wpi­su jego frag­men­ty to:

Programy kom­pu­te­ro­we w świe­tle kra­jo­we­go pra­wa autor­skie­go korzy­sta­ją ze szcze­gól­nej ochro­ny. Z uwa­gi na ich spe­cy­fi­kę wyłą­czo­no sto­so­wa­nie nie­któ­rych regu­la­cji z ogól­nej czę­ści pra­wa autor­skie­go, w szcze­gól­no­ści prze­pi­sów doty­czą­cych dozwo­lo­ne­go użyt­ku, któ­ry umoż­li­wia w ści­śle okre­ślo­nych oko­licz­no­ściach korzy­sta­nie z utwo­rów bez zgo­dy twór­cy, a nawet wbrew takiej zgo­dzie. Co do zasa­dy zatem jakie­kol­wiek zwie­lo­krot­nie­nie pro­gra­mu kom­pu­te­ro­we­go wyma­ga zgo­dy twór­cy. […]
Spór ma swą gene­zę w 2005 r. kie­dy to Google nabył star­tup Android Inc i roz­po­czął sta­ra­nia by wejść na rynek smart­fo­nów, two­rząc plat­for­mę do budo­wy sys­te­mów dla urzą­dzeń mobil­nych. Platforma w swym zało­że­niu mia­ła być nie­od­płat­na po to by popu­la­ry­zo­wać śro­do­wi­sko Google. Jako że język pro­gra­mi­stycz­ny Java był wów­czas jed­nym z naj­bar­dziej popu­lar­nych i powszech­nych wśród pro­gra­mi­stów, Google pod­jął roz­mo­wy z Sun Microsystems ? twór­cą Java ? na temat licen­cjo­no­wa­nia całej plat­for­my Java. Ostatecznie zde­cy­do­wał się jed­nak na budo­wę wła­snej plat­for­my. Aby jed­nak zapew­nić jej powszech­ność i łatwość sto­so­wa­nia wśród pro­gra­mi­stów zasto­so­wa­no w nim nazwy funk­cji i for­ma­tów danych cha­rak­te­ry­stycz­ne dla języ­ka Javy. Google de fac­to opra­co­wał wła­sne odpo­wied­ni­ki funk­cji Javy i nadał im nazwy takie same jak w Javie. Oracle, po prze­ję­ciu spół­ki Sun Microsystems, pozwał w 2010 r. Google o naru­sze­nie przy­słu­gu­ją­cych Oracle praw autor­skich i paten­tów. Zarzucono Google sko­pio­wa­nie bli­sko 11 500 linii dekla­ra­cji API pro­gra­mu Java (co sta­no­wi­ło 0,4 % dekla­ra­cji). […]
Sąd uznał, że dzia­ła­nie Google było ?zgod­ne z kre­atyw­nym ?postę­pem?, któ­ry jest pod­sta­wo­wym kon­sty­tu­cyj­nym celem same­go pra­wa autor­skie­go?. Według sądu dozwo­lo­ny uży­tek peł­ni więc istot­ną rolę w roz­wo­ju opro­gra­mo­wa­nia, a pra­wo autor­skie nie powin­no hamo­wać tego roz­wo­ju. (żr.: Dozwolony uży­tek pro­gra­mów kom­pu­te­ro­wych ? jak Google poko­nał Oracle w USA).

Powyższy tekst wska­zu­je na dwa cie­ka­we aspek­ty opro­gra­mo­wa­nia, o któ­rych dzi­siaj napi­szę. Pierwszy to tak zwa­ny dozwo­lo­ny uży­tek, bar­dzo czę­sto przy­wo­ły­wa­ny w spo­rach o bez­płat­ne uży­cie opro­gra­mo­wa­nia i zakres tego uży­cia. Najczęściej doty­czy gier kom­pu­te­ro­wych ale nie tyl­ko. Drugi to cha­rak­ter opro­gra­mo­wa­nia, jakim jest kod źró­dło­wy będą­cy tek­stem, oraz efekt osta­tecz­ny, jakim jest kom­pu­ter reali­zu­ją­cy okre­ślo­ny mecha­nizm”, gdzie kom­pu­ter defi­niu­je­my jako pro­ce­sor, pamięć i pro­gram” . Warto tu zwró­cić uwa­gę na pewien dro­biazg”: autor­ka (jak wie­lu innych praw­ni­ków) trak­tu­je treść pro­gra­mu jako tekst” i nie raz sto­su­je ana­lo­gię do typo­wych utwo­rów pisa­nych takich jak pro­za czy poezja, co jest poważ­nym błę­dem. Fragmenty tek­stów (esej, pra­ca dok­tor­ska, powieść, itp.) bar­dzo czę­sto mają war­tość, cze­go o nie moż­na powie­dzieć o opro­gra­mo­wa­niu (nie dzia­ła w kawał­kach). Owszem, moż­na potrak­to­wać frag­men­ty kodu lite­ra­tu­ro­wo”, jako przy­kła­dy jego struk­try i skład­ni (np. lite­ra­tu­ra na temat wzor­ców pro­jek­to­wych w inży­nie­rii opro­gra­mo­wa­nia), jed­nak nie moż­na mówić o frag­men­cie kodu, że to opro­gra­mo­wa­nie”, gdyż to z zasa­dy musi dzia­łać”, a jest to moż­li­we tyl­ko wte­dy gdy do kom­pu­te­ra zała­du­je­my kom­plet­ny pro­gram a nie cyto­wa­ny fragment”.

Czytaj dalej… Dozwolony uży­tek pro­gra­mów kom­pu­te­ro­wych czy­li o inter­fej­sach”

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”

Dokument a kumulacja faktów: OOAD i model dziedziny systemu

Tym razem o czymś co potra­fi zabić 😉 czy­li czym jest doku­ment oraz fakt i obiekt. Czym się róż­ni zakup kil­ku pro­duk­tów, w tym samym skle­pie, w np. godzin­nych odstę­pach cza­su, od zaku­pu wszyst­kich razem? Poza for­mą udo­ku­men­to­wa­nia, niczym: w skle­pie to samo i tyle samo zeszło ze sta­nu maga­zy­nu, a my wyda­li­śmy w obu przy­pad­kach tyle samo pie­nię­dzy (o pro­mo­cjach póź­niej)! W pierw­szym przy­pad­ku mamy kil­ka fak­tów zaku­pu, w dru­gim, jeden, ale zawsze tyle samo obiek­tów (pro­dukt). Faktura (para­gon) to doku­ment opi­sją­cy fakt, przed­miot sprze­da­ży jest obiek­tem. Tu obiek­tem jest opi­sy­wa­ny przed­miot zaku­pu. Ten arty­kuł to przy­kład archi­tek­tu­ry usłu­gi apli­ka­cji, któ­ra jest nie­czu­ła na takie różnice. 

Wprowadzenie

Żeby upo­rząd­ko­wać treść, w sto­sun­ku to archi­tek­tu­ry apli­ka­cji tu nie będę uży­wał pojęć kla­sa i obiekt” a kom­po­nent i doku­ment. Pojęcia obiekt i fakt tu będą doty­czy­ły świa­ta real­ne­go, to odpo­wied­nio: opi­sy­wa­ny przed­miot i zda­rze­nie z nim powią­za­ne. Innymi sło­wy: doku­ment może opi­sy­wać obiekt lub zda­rze­nie z nim powią­za­ne. Np. pro­dukt oraz fakt jego sprze­da­nia (dwa byty: sepa­ro­wa­nie kon­tek­stu doku­men­tów). Konkretne opro­gra­mo­wa­nie jako sys­tem, to kom­po­nen­ty (w UML obiek­ty okre­ślo­nej kla­sy) oraz dane zor­ga­ni­zo­wa­ne np. jako doku­men­ty (doku­ment: nazwa­na, okre­ślo­na struk­tu­ra danych). Aplikacje prze­twa­rza­ją dane opi­su­ją­ce real­ny świat, co ład­nie poka­zał i opi­sał Smith :

computer model real world
Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512

Projektowanie opro­gra­mo­wa­nia to two­rze­nie jego mode­lu, potem pozo­sta­je już tyl­ko jego imple­men­ta­cja. Obecnie pra­ce pro­jek­to­we i przy­go­to­wa­nie do imple­men­ta­cji tak­że są zali­cza­ne do pro­gra­mo­wa­nia” .

Projekt systemu sprzedaży

Każda ana­li­za powin­na być opar­ta na onto­lo­gii z dzie­dzi­ny pro­ble­mu. Dzięki cze­mu nazwy doku­men­tów, atry­bu­tów i ich war­to­ści będą spój­ne, jed­no­znacz­ne i nie­sprzecz­ne. Poniżej pro­sty model poję­cio­wy dla dzie­dzi­ny opi­sy­wa­ne­go tu problemu:

Model poję­cio­wy (dia­gram fak­tów SBVR lub model poję­cio­wy, dia­gram klas UML)

(UWAGA! Powyższy model nie jest żad­nym mode­lem dzie­dzi­ny” ani mode­lem danych”. To model pojęciowy). 

Modele poję­cio­we słu­żą do zarzą­dza­nia sys­te­mem pojęć (onto­lo­gia) dla dane­go mode­lu opro­gra­mo­wa­nia. Testowanie tego mode­lu pole­ga na spraw­dze­niu czy każ­da para połą­czo­nych seman­tycz­nie pojęć two­rzy popraw­ne i praw­dzi­we(!) zda­nie w języ­ku natu­ral­nym (tu musi­my brać popraw­kę na flek­sję języ­ka pol­skie­go), np. «sprze­da­ją­cy wysta­wia fak­tu­rę» (fakt) lub «fak­tu­ra jest doku­men­tem» (typ).

Oprogramowanie słu­ży do prze­twa­rza­nia danych, dla­te­go war­to opi­sać jak się to odby­wa. Bardzo wygod­ną meto­dą pro­jek­to­wa­nia struk­tur danych doku­men­ty (w tym opi­sie dia­gram struk­tur zło­żo­nych nota­cji UML). Po pierw­sze są one zro­zu­mia­łe dla przy­szłe­go użyt­kow­ni­ka, po dru­gie meto­da ta pozwa­la uwol­nić się od wad mode­li rela­cyj­nych: usu­nię­cie redun­dan­cji nazw co pro­wa­dzi do utra­ty ich kon­tek­stu. Dokumenty czę­sto mają róż­ny kon­tekst, zna­cze­nie pojęć zale­ży od kon­tek­stu. Relacyjny model danych, pozba­wio­ny redun­dan­cji, jest strat­ny: utrwa­lo­ne dane nie sta­no­wią żad­nej infor­ma­cji a doku­men­tem jest dopie­ro wynik zapy­ta­nia SQL do tabel. 

W przy­pad­ku opi­sy­wa­ne­go tu pro­jek­tu wyglą­da to tak:

Struktury danych zor­ga­ni­zo­wa­nych w doku­men­ty (nota­cja UML)

Mamy tu dwa doku­men­ty: Oferta i Faktura. Pojęcie Produkt ma swo­ją defi­ni­cję real­na (defi­ni­cja atry­bu­to­wa: poprzez cechy): jest to cos co ma nazwę, cenę i ilość”. Atrybuty Produktu na doku­men­tach przyj­mu­ją war­to­ści opi­sa­ne tym typem. Po dru­gie doku­ment nie­sie kon­tekst więc nada­je nazwie zna­cze­nie: np. data to data fak­tu­ry i data ofer­ty. To nie są te same daty, a pro­dukt ofe­ro­wa­ny (jako atry­but ofer­ty) nie musi być tym samym pro­duk­tem sprze­da­nym (jako atry­but Faktury).

Projekt powyż­szy poka­zu­je tak­że waż­ną rzecz: sepa­ro­wa­nie danych o obiek­tach (pro­duk­ty) i fak­tach (fak­tu­ra). Nie nale­ży na jed­nym doku­men­cie łączyć (mie­szać) kon­tek­stów (uwspól­nia­nie danych w mode­lu rela­cyj­nym). (Więcej na temat sepa­ra­cji kon­tek­stów obiek­tu i fak­tu w publi­ka­cji Chapter 3 Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases”).

Poniżej, na dia­gra­mie sekwen­cji, widać, że dla kom­po­nen­tu zarzą­dza­ją­ce­go sta­na­mi maga­zy­no­wy­mi nie ma żad­ne­go zna­cze­nia ile jest (było) fak­tur, ope­ra­cje zmia­ny ilo­ści to poje­dyn­cze ope­ra­cje. Tak zapro­jek­to­wa­na apli­ka­cja jest odpor­na na to ile pro­duk­tów jest na ofer­cie i fak­tu­rze, mogą to być róż­ne ilo­ści. Oba te doku­men­ty: ofer­ta i fak­tu­ra, to cał­ko­wi­cie odręb­ne kon­struk­cje, to doku­men­ty rzą­dzą­ce się każ­dy inną logi­ką i mają­ce każ­dy inny cykl życia (tu np. Oferta nie jest utrwa­la­na). Często sto­so­wa­ne kon­struk­cje, takie jak dzie­dzi­cze­nie fak­tu­ry i ofer­ty po doku­men­cie” są tu naj­gor­szym pomysłem. 

Architektura. Nasza apli­ka­cja to kil­ka współ­pra­cu­ją­cych komponentów:

Obiektowy (kom­po­nen­to­wy) model dziedziny. 

Klasy ozna­czo­ne ste­reo­ty­pem «Document» to cią­gi zna­ków (np. XML) sta­no­wią­ce war­to­ści atry­bu­tów i para­me­try wywo­łań ope­ra­cji. (w UML: ?Document? A human-reada­ble file. Subclass of ?File?. )

Model archi­tek­tu­ry to sta­tycz­ny model, a ten może być nie­zro­zu­mia­ły, dla­te­go zawsze wzbo­ga­ca­my pro­jekt tech­nicz­ny archi­tek­tu­ry mode­lem dyna­mi­ki sys­te­mu: dia­gra­mem sekwen­cji. Diagram taki powi­nien powstać dla każ­dej usłu­gi apli­ka­cji (przy­pad­ku użycia):

Scenariusz reali­za­cji sprze­da­ży (dia­gram sekwen­cji UML)

Powyższy dia­gram poka­zu­je współ­pra­cę kom­po­nen­tów, opi­sa­ne wcze­śniej doku­men­ty są war­to­ścia­mi atry­bu­tów i para­me­tra­mi wywo­ły­wa­nych ope­ra­cji i ich odpo­wie­dzi. Powyższa archi­tek­tu­ra z powo­dze­niem wyko­na tak­że usłu­gi wglą­du do histo­rycz­nych fak­tur czy aktu­ali­za­cję cennika. 

Poprawna obiek­to­wa archi­tek­tu­ra i kom­plet­ny pro­jekt tech­nicz­ny apli­ka­cji (model PIM) opi­su­je pre­cy­zyj­nie jak wyko­nać imple­men­ta­cje i nie zawie­ra pro­jek­tu żad­nej bazy danych, ani tym bar­dziej zapy­tań SQL. Implementacja utrwa­la­nia nie może mieć wpły­wu na logi­kę biz­ne­so­wą sys­te­mu ani nawet zawie­rać jej! 

Samo opra­co­wa­nie rela­cyj­ne­go mode­lu danych oraz zapy­tań SQL, by gene­ro­wać powyż­sze doku­men­ty z warian­ta­mi doty­czą­cy­mi róż­nych ilo­ści ofe­ro­wa­nych i zama­wia­nych, zaj­mie kil­ka­krot­nie wię­cej cza­su niż opra­co­wa­nie powyż­sze­go, goto­we­go do imple­men­ta­cji, pro­jek­tu. Opracowanie mode­lu rela­cyj­ne­go bazy danych, wyma­ga­ło by dodat­ko­wo wie­dzy o wszyst­kich pozo­sta­łych doku­men­tach w tym sys­te­mie, a tego z regu­ły nigdy nie wie­my na początku!

Powyższy model to w peł­ni współ­pra­cu­ją­ce obiek­ty mają­ce ope­ra­cje, a pod­sta­wo­wym związ­kiem mode­lu obiek­to­we­go jest zwią­zek uży­cia (wywo­ła­nia ope­ra­cji), czy­li nie jest to tak zwa­ny ane­micz­ny model dzie­dzi­ny.

Tu tak­że war­to zwró­cić uwa­gę na kolej­ny czę­sty błąd i antyw­zo­rzec w pro­jek­tach dekla­ro­wa­nych jako obiek­to­we: sto­so­wa­nie dzie­dzi­cze­nia. Jest to mie­sza­nie mode­li poję­cio­wych i archi­tek­tu­ry (dzie­dzi­cze­nie, jako współ­dzie­le­nie, łamie pod­sta­wo­wą zasa­dę para­dyg­ma­tu obiek­to­we­go jaką jest her­me­ty­za­cja). Dlatego model poję­cio­wy i model archi­tek­tu­ry to z zasa­dy dwa odręb­ne mode­le z powo­dów jak wyżej opisane.

Modelowanie archi­tek­tu­ry systemu 

Podsumowanie

Powyższy opis to krót­ki ale prak­tycz­nie kom­plet­ny Opis Techniczny Oprogramowania. Wymaga nie­wiel­kich uzu­peł­nień (ewen­tu­al­ne sche­ma­ty opi­su­ją­ce meto­dy ope­ra­cji). Wykonanie imple­men­ta­cji na jego pod­sta­wie nie powin­no spra­wić pro­ble­mu oso­bie radzą­cej sobie z czy­ta­niem nota­cji UML. Projekt jest na tyle pre­cy­zyj­ny, że sta­no­wi utwór w rozu­mie­niu pra­wa autor­skie­go (pro­gra­mi­sta nie ma tu żad­nej swo­bo­dy decy­zji w pisa­niu kodu dla tej czę­ści). Projekt taki to tak­że opis okre­ślo­ne­go mecha­ni­zmu dzia­ła­nia, zawie­ra więc opis know-how i jako jego udo­ku­men­to­wa­na for­ma chro­ni to know-how (usta­wa o prze­ciw­dzia­ła­niu nie­uczci­wej konkurencji). 

Dlatego każ­dy pro­gram kom­pu­te­ro­wy napi­sa­ny na pod­sta­wie takiej doku­men­ta­cji, z zasa­dy jest utwo­rem zależ­nym. Developer ma pra­wa autor­skie oso­bi­ste do kodu jaki napi­sze, ale nie ma pra­wa do dys­po­no­wa­nia tym kodem: ma je posia­dacz praw mająt­ko­wych do pro­jek­tu, któ­ry jest tu utwo­rem pier­wot­nym. Jedyny wybór jaki ma tu deve­lo­per to wybór tech­no­lo­gii jakiej użyje.

https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​e​m​e​r​g​i​n​g​-​c​h​a​l​l​e​n​g​e​s​-​s​o​l​u​t​i​o​n​s​-​b​e​s​t​-​p​r​a​c​t​i​c​e​s​/​2​7​1​7​3​3​#​t​a​b​l​e​-​o​f​-​c​o​n​t​e​nts

Powyższy pro­jekt wyko­na­no z uży­ciem Visual Paradigm.

Źródła

OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Weilkiens, T. (2007). Systems engi­ne­ering with SysML/UML: mode­ling, ana­ly­sis, design (1. Aufl). Morgan Kaufmann OMG Press/Elsevier.
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049
Smith, B. C. (1985). The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18 – 26. https://​doi​.org/​1​0​.​1​1​4​5​/​3​7​9​4​8​6​.​3​7​9​512

Prawo autorskie w projektach IT

Ten arty­kuł to pew­ne­go rodza­ju kon­ty­nu­acja poprzed­nie­go: Vendor lock-in. Starałem się tu wyja­śnić czym jest pro­jekt i wska­zać, że pew­ne wywo­dy praw­ni­ków wyda­ją się nie mieć żad­ne­go uzasadnienia. 

Prawo autorskie

Pomysł, aby ochro­nę roz­wią­zań bran­ży IT oprzeć na pra­wie autor­skim nie był spe­cjal­nie szczę­śli­wy. Prawo autor­skie stwo­rzo­no z myślą o twór­cach oraz odbior­cach. (źr.: Prawa autor­skie w pro­jek­tach IT. Głównie o róż­ni­cach mię­dzy prze­nie­sie­niem praw a licen­cja­mi)

Zaskakuje mnie taka teza, bo pra­wo autor­skie, jak sama nazwa wska­zu­je, stwo­rzo­no z myślą o auto­rach. To, że ta kon­kret­na usta­wa zawie­ra wie­le odnie­sień np. do muzy­ki nie zmie­nia fak­tu, że regu­lu­je wszel­kie prze­ja­wy twór­czej dzia­łal­no­ści o indy­wi­du­al­nym cha­rak­te­rze”. Ta usta­wa dosko­na­le sobie radzi z każ­dą inży­nie­rią, i uwa­żam, że inży­nie­ria opro­gra­mo­wa­nia nie jest tu żad­nym wyjąt­kiem. Być może Pan Maruta dzia­ła tu jako lob­by­sta edżaj­lo­wych pro­gra­mi­stów”, cze­mu chy­ba daje wyraz, np. tu:

Wdrożenia sys­te­mów infor­ma­tycz­nych to zde­cy­do­wa­nie jed­ne z naj­bar­dziej skom­pli­ko­wa­nych przed­się­wzięć w bran­ży IT. Ta oczy­wi­sta oczy­wi­stość znaj­du­je swo­je potwier­dze­nie cho­ciaż­by w kosz­tach zwią­za­nych z reali­za­cją wdro­żeń oraz ska­lą ryzy­ka wyni­ka­ją­cą z ewen­tu­al­ne­go nie­po­wo­dze­nia pro­jek­tów wdro­że­nio­wych. (źr.: Jak pisać umo­wy dla pro­jek­tów IT reali­zo­wa­nych w mode­lu Agile? Cz. I.)

Słowa oczy­wi­sta oczy­wi­stość” to czę­sty wybieg reto­rycz­ny praw­ni­ków, mówią­cy roz­mów­cy nawet nie pró­buj pod­wa­żać tego co powie­dzia­łem”. Otóż nie­ste­ty wiel­ko­ści budże­tów nie są jakieś spe­cjal­nie wiel­kie na tle innych inży­nie­rii (Pan Maruta stra­szy kil­ko­ma ewe­ne­men­ta­mi, rzecz w tym, że podał przy­kła­dy głów­nie złe­go zarzą­dza­nia zakre­sem pro­jek­tów), a ska­la ryzy­ka pro­jek­tów IT jest dale­ko mniej­sza, bo nie­po­wo­dze­nia pro­jek­tów IT nie powo­du­ją np. ofiar w ludziach jak w przy­pad­ku kata­strof budow­la­nych czy komu­ni­ka­cyj­nych. A więc nie jest to żad­na oczy­wi­sta oczywistość”. 

Teza Pana Maruty i jego wywo­dy o IT natych­miast przy­po­mnia­ły mi inny arty­kuł (pole­cam):

TWÓJ PRAWNIK ROZUMIE KONTRAKT LEPIEJ NIŻ TWOI LUDZIE Z BIZNESU? COŚ TU JEST NIE TAK (źr.: https://www.linkedin.com/pulse/tw%C3%B3j-prawnik-rozumie-kontrakt-lepiej-ni%C5%BC-twoi-ludzie-warchol-lewicka/ )

Teza auto­ra (Marcin Maruta): Pomysł, aby ochro­nę roz­wią­zań bran­ży IT oprzeć na pra­wie autor­skim nie był spe­cjal­nie szczę­śli­wy”, jest co naj­mniej nie­zro­zu­mia­ła, a sam autor jej nie uza­sad­nia. Autor wska­zu­je na rosną­cą kom­pli­ka­cje tego pra­wa, ale nie­ja­ko sam wska­zu­je źró­dło: lob­bing pra­co­daw­ców w celu zła­go­dze­nia ochro­ny twór­ców (auto­rów czy­li ich pra­cow­ni­ków: pro­gra­mi­stów, pro­jek­tan­tów, archi­tek­tów opro­gra­mo­wa­nia). Ten wątek pozo­sta­wię bez komentarza. 

USTAWA z dnia 4 lute­go 1994 r. o pra­wie autor­skim i pra­wach pokrew­nych , mówi mie­dzy innymi: 

Art. 1. 1. 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).

To zna­czy, że istot­ny jest indy­wi­du­al­ny cha­rak­ter czy­li uni­kal­ność powsta­łej tre­ści, nie jest istot­ny spo­sób jej wyra­że­nia (tekst, rysun­ki, głos), istot­ny jest fakt jej utrwa­le­nia (usta­le­nie). Artykuł ten jest bar­dzo istot­ny, bo zapis ten cał­ko­wi­cie abs­tra­hu­je od bran­ży, zasto­so­wa­nia i przy­dat­no­ści utwo­ru. Coś jest utwo­rem bo jest uni­kal­ne i powsta­ło w wyni­ku twór­czej (a więc celo­wej) dzia­łal­no­ści czło­wie­ka (czło­wie­ka bo Prawo doty­czy ludzi). Ustawa mówi wprost: 

2. W szcze­gól­no­ści przed­mio­tem pra­wa autor­skie­go są utwo­ry:
1) wyra­żo­ne sło­wem, sym­bo­la­mi mate­ma­tycz­ny­mi, zna­ka­mi gra­ficz­ny­mi
(lite­rac­kie, publi­cy­stycz­ne, nauko­we, kar­to­gra­ficz­ne oraz pro­gra­my
kom­pu­te­ro­we);[…]

3. Utwór jest przed­mio­tem pra­wa autor­skie­go od chwi­li usta­le­nia, cho­ciaż­by miał postać nieukończoną

Jak widać for­ma (treść lite­rac­ka, sche­ma­ty, wzo­ry mate­ma­tycz­na, pro­gram kom­pu­te­ro­wy itp.) nie ma żad­ne­go zna­cze­nia, liczy się wyłącz­nie fakt zma­te­ria­li­zo­wa­nia się utwo­ru w jakiej­kol­wiek postaci. 

Art. 2. 1. Opracowanie cudze­go utwo­ru, w szcze­gól­no­ści tłu­ma­cze­nie,
prze­rób­ka, adap­ta­cja, jest przed­mio­tem pra­wa autor­skie­go bez uszczerb­ku dla pra­wa do utwo­ru pier­wot­ne­go.
2. Rozporządzanie i korzy­sta­nie z opra­co­wa­nia zale­ży od zezwo­le­nia twór­cy utwo­ru pier­wot­ne­go (pra­wo zależ­ne), chy­ba że autor­skie pra­wa mająt­ko­we do utwo­ru pier­wot­ne­go wyga­sły. W przy­pad­ku baz danych speł­nia­ją­cych cechy utwo­ru zezwo­le­nie twór­cy jest koniecz­ne tak­że na spo­rzą­dze­nie opracowania

Tu waż­na uwa­ga: moż­na bez pro­ble­mu opra­co­wy­wać cudze utwo­ry do szu­fla­dy”, jed­nak jakie­kol­wiek roz­po­rzą­dza­nie takim opra­co­wa­niem (nawet publi­ka­cja), wyma­ga już zgo­dy auto­ra utwo­ru pier­wot­ne­go. To bar­dzo istot­ne, bo w inży­nie­rii reali­za­cje są opra­co­wa­niem ich pro­jek­tu. Tak jak budow­la jest reali­za­cją jej pro­jek­tu wyko­na­ne­go na desce kre­ślar­skiej, tak opro­gra­mo­wa­nie może być reali­za­cją (opra­co­wa­niem) pro­jek­tu logi­ki dzia­ła­nia i archi­tek­tu­ry opro­gra­mo­wa­nia wyra­żo­nych sło­wem, sym­bo­la­mi mate­ma­tycz­ny­mi, zna­ka­mi gra­ficz­ny­mi” (parz tak­że ).

Innymi sło­wy jeże­li pro­gram powstał bez takie­go pro­jek­tu, jest on fak­tycz­nie samo­dziel­nym utwo­rem pro­gra­mi­sty (co zresz­tą bar­dzo czę­sto ma miej­sce). Jeżeli jed­nak pro­gram (opro­gra­mo­wa­nie, apli­ka­cja) powstał jako opra­co­wa­nie pro­jek­tu wyra­żo­ne­go w for­mie j.w. (sche­ma­ty blo­ko­we, wzo­ry, tabli­ce, algo­ryt­my itp. ) jest wyłącz­nie imple­men­ta­cją (efekt sta­ran­ne­go dzia­ła­nia), lub utwo­rem zależ­nym, jeże­li autor oddał pew­ną okre­ślo­ną swo­bo­dę pro­ga­mi­ście. To, że to jest to rzad­ka sytu­acja (ist­nie­nie pro­jek­tu), nie zmie­nia fak­tu, że jest pro­gram nie jest tu utwo­rem a wyko­na­niem utwo­ru .

Rzesze pro­gra­mi­stów (i ich praw­ni­ków) zwal­cza­ją tą tezę bo ude­rza ona w ich monopol. 

Uważam, że orzecz­nic­two jest jed­nak po stro­nie pro­jek­tan­tów i archi­tek­tów sys­te­mów, w tym opro­gra­mo­wa­nia. Więcej o tym zagad­nie­niu napi­sa­łem w arty­ku­le Ochrona know-how. Tu sku­pię się na pro­jek­cie opro­gra­mo­wa­nia jako samo­dziel­nym i peł­no­praw­nym utwo­rze będą­cym spe­cy­fi­ka­cją opro­gra­mo­wa­nia jakie ma powstać (pro­jekt jako wymaganie).

Projektowanie

Zacznijmy od pro­ste­go przy­kła­du i słyn­ne­go zara­zem wyna­laz­ku i paten­tu (w USA). Poniższy rysu­nek to model (spe­cy­fi­ka­cja) mecha­ni­zmu dzia­ła­nia regu­la­to­ra. Nie jest to nawet rysu­nek tech­nicz­ny wyko­naw­czy. Jest to utwór w rozu­mie­niu usta­wy, bo: sta­no­wi prze­jaw dzia­łal­no­ści twór­czej o indy­wi­du­al­nym cha­rak­te­rze, usta­lo­ny zna­ka­mi gra­ficz­ny­mi. Nie mniej jed­nak sta­no­wi bar­dzo pre­cy­zyj­ny opis mecha­ni­zmu dzia­ła­nia odśrod­ko­we­go regu­la­to­ra obrotów. 

PODSTAWY CYBERNETYKI REGULACJA PROCESÓW FIZJOLOGICZNYCH - ppt video online  pobierz

Poniższe zdję­cie to jed­na z wie­lu moż­li­wych imple­men­ta­cji (opra­co­wa­nia) powyż­sze­go mecha­ni­zmu. I co cie­ka­we, udo­wod­nie­nie, że jest to imple­men­ta­cja (utwór zależ­ny) mecha­ni­zmu opi­sa­ne­go powy­żej, nie zaj­mie żad­ne­mu sądo­wi zbyt wie­le czasu. 

Historia automatyki - Wikiwand

Tak więc jed­no jest tu pew­ne: kon­kret­na kon­struk­cja na zdję­ciu powy­żej jest opra­co­wa­niem utwo­ru jakim jest sche­mat opi­su­ją­cy mecha­nizm dzia­ła­nia odśrod­ko­we­go regu­la­to­ra obro­tów Watta. I nie­za­leż­nie od tego ile wła­snej inwen­cji wło­żył w to inży­nier kon­struk­tor tego kon­kret­ne­go regu­la­to­ra, jest to – kon­struk­cja na zdję­ciu – utwór zależ­ny. Poniżej inna kon­struk­cja (imple­men­ta­cja) tego same­go mecha­ni­zmu, to tak­że jest utwór zależny. 

Regulator odśrodkowy obrotów silnika rozbryzgiwacz oleju Briggs 691968 -  skladczesci.pl

Pewną cie­ka­wost­ką jest sta­no­wi­sko pol­skie­go usta­wo­daw­cy, mówią­ce że: 

Art. 28 pkt. 5 usta­wy o wła­sno­ści prze­my­sło­wej sta­no­wi, iż za wyna­la­zek nie może być uzna­wa­ny ?pro­gram do maszyn cyfro­wych?. Wynika z tego jasno, iż pro­gram kom­pu­te­ro­wy nie może być zatem zgło­szo­ny do wła­ści­we­go urzę­du paten­to­we­go celem jego reje­stra­cji i uzy­ska­nia sto­sow­ne­go paten­tu. Autorzy pro­gra­mu kom­pu­te­ro­we­go mogą pró­bo­wać jedy­nie opa­ten­to­wać wyna­la­zek, któ­ry wspo­ma­ga­ny jest pro­gra­mem kom­pu­te­ro­wym, nie­zbęd­nym do jego pra­wi­dło­we­go funk­cjo­no­wa­nia. (źr.: Ochrona praw­na pro­gra­mów kom­pu­te­ro­wych)

Absolutnie nie jestem zwo­len­ni­kiem paten­to­wa­nia opro­gra­mo­wa­nia, a nawet gene­ral­nie jestem prze­ciw­ni­kiem paten­tów, czy­li trwa­łych mono­po­li na wyna­laz­ki ludz­kie. Skąd teza mówią­ca, że za wyna­la­zek nie może być uzna­wa­ny ?pro­gram do maszyn cyfro­wych?”?. Wydaje się ona nielogiczna.

Popatrzmy na to. Poniżej zdję­cie mecha­ni­zmu mecha­nicz­ne­go pro­gra­ma­to­ra pral­ki: zawie­ra sil­nik i tak zwa­ne krzyw­ki ste­ru­ją­ce sty­ka­mi sterownika. 

Mechaniczny pro­gra­ma­tor pralki

Identyczne funk­cje, jako mecha­nizm ste­ru­ją­cy, reali­zu­je poniż­szy nowo­cze­sny ste­row­nik będą­cy tak na praw­dę kom­pu­te­rem (mikro­kon­tro­ler)

Programator pralki Aquamatic AQUA 100 +blokada+ silnik Sosnowiec -  Sprzedajemy.pl
Mikrokontroler peł­nią­cy funk­cję pro­gra­ma­to­ra pral­ki automatycznej. 

W pew­nych obsza­rach mecha­nizm wyko­na­ny (opra­co­wa­ny, wyna­le­zio­ny) jako kon­struk­cja mecha­nicz­na (moż­li­wa do opa­ten­to­wa­nia) może być zre­ali­zo­wa­ny w 100% z uży­ciem kom­pu­te­ra: mecha­nicz­ny aryt­mo­metr został zastą­pio­ny elek­tro­nicz­nym kal­ku­la­to­rem (to jest kom­pu­ter), mecha­nicz­ny zegar tak­że pro­gra­mem kom­pu­te­ra (czy­taj tak­że Model czy abs­trak­cja). Ładnie to opi­su­je autor publi­ka­cji nauko­wej zaty­tu­ło­wa­nej Komputer jako uni­wer­sal­ny mecha­nizm . Innymi słowy: 

sko­ro kom­pu­ter to pro­ce­sor, pamięć i pro­gram, i sko­ro 100% reali­zo­wa­nych funk­cji kom­pu­te­ra reali­zu­je pro­gram, to zna­czy sam pro­gram, bez wzglę­du na for­mę jego wyra­zu, z zasa­dy jest tu kom­plet­nym opi­sem mecha­ni­zmu dzia­ła­nia, pod­le­ga­ją­cym poten­cjal­nie ochro­nie praw­no-autor­skiej i/lub know-how.

Dokładnie z tego same­go powo­du gar­nek nie jest inte­gral­ną czę­ścią chro­nio­ne­go prze­pi­su potra­wy kuli­nar­nej (a są one chro­nio­ne pra­wem np. jako pro­duk­ty spo­żyw­cze regio­nal­ne, np. takie jak oscypek). 

Od dekad mamy do czy­nie­nia z postę­pem tech­no­lo­gii gdzie jeden z obsza­rów inży­nie­rii: sze­ro­ko poję­te sys­te­my ste­ro­wa­nia, jest sys­te­ma­tycz­nie pochła­nia­ny przez kom­pu­te­ry. Mechaniczne kon­struk­cje takie jak sys­te­my zli­cza­ją­ce, cza­so­mie­rze, kal­ku­la­to­ry, ste­ro­wa­nie opar­te o cię­gna, sys­te­my auto­ma­ty­ki, sys­te­my zobra­zo­wa­nia (np. wska­zów­ko­we: moni­tor zamiast mecha­nicz­ne­go wskaź­ni­ka) itp. są zastę­po­wa­ne przez kom­pu­ter (rozu­mia­ny jako pro­ce­sor, pamięć i pro­gram). Kolejne kon­struk­cje, do nie­daw­na wyłącz­nie mecha­nicz­ne, są zastę­po­wa­ne kom­pu­te­rem (patrz tak­że nie­daw­ny arty­kuł: Inteligentna pral­ka czy­li czym jest mecha­tro­ni­ka). Proces ten postę­pu­je, powsta­ła nota­cja (roz­sze­rze­nie UML) pozwa­la­ją­ca na mode­lo­wa­nie (spe­cy­fi­ko­wa­nie) takich mie­sza­nych kon­struk­cji: SysML:

Wszystkie powyż­sze kon­struk­cje są chro­nio­ne pra­wem autor­skim, jako ich pro­jek­ty wyko­na­ne w posta­ci udo­ku­men­to­wa­nych (usta­lo­nych) opi­sów (spe­cy­fi­ka­cji) wyko­na­nych z uży­ciem sche­ma­tów blo­ko­wych, zapi­sów związ­ków logicz­nych i wzo­rów mate­ma­tycz­nych. Tak więc teza, jako­by opro­gra­mo­wa­nie wyma­ga­ło jakie­goś inne­go spe­cjal­ne­go podej­ścia, jest moim zda­niem nie do obro­ny: jeże­li kom­pu­ter (czy­li tak­że pro­gram) może być rów­no­praw­nym funk­cjo­nal­nie zamien­ni­kiem kon­struk­cji mecha­nicz­nej (co wyka­za­no powy­żej), to zna­czy że moż­na wobec nie­go i kon­struk­cji mecha­nicz­nych, sto­so­wać te same zapi­sy w prawie. 

Podsumowanie

Czy moż­li­we jest więc opra­co­wa­nie spe­cy­fi­ka­cji dla wyko­na­nia opro­gra­mo­wa­nia, ana­lo­gicz­nej jak dla urzą­dze­nia mecha­nicz­ne­go? Oczywiście! Powyższa pozy­cja lite­ra­tu­ry to jed­na z wie­lu tego typu. Na tym blo­gu jest wie­le przy­kła­dów takich spe­cy­fi­ka­cji. Stawianie tezy, że jedy­ną moż­li­wą for­mą usta­le­nia opro­gra­mo­wa­nia jest kod źró­dło­wy, nie ma żad­ne­go uza­sad­nie­nia w fak­tach: mamy na świe­cie ogrom­ną ilość doku­men­ta­cji sta­no­wią­cej pre­cy­zyj­ną spe­cy­fi­ka­cje opro­gra­mo­wa­nia jakie ma powstać. Oczywiście nie ma obo­wiąz­ku two­rze­nia takich doku­men­tów (meto­dy nazy­wa­ne agi­le) ale po pierw­sze jest to moż­li­we, po dru­gie jest to jed­nak nadal naj­sku­tecz­niej­sza meto­da zama­wia­nia opro­gra­mo­wa­nia. Panu Marucie, świet­ne­mu praw­ni­ko­wi, pole­cam jed­nak kon­fron­to­wa­nie poglą­dów pro­gra­mi­stów któ­rych repre­zen­tu­je, z dostęp­ną lite­ra­tu­rą i nauko­wą i popu­lar­ną z zakre­su inży­nie­rii opro­gra­mo­wa­nia oraz orzecz­nic­two w tym zakre­sie, np. poniższe: 

Dokumentacja i inne mate­ria­ły doty­czą­ce pro­jek­to­wa­nia pro­gra­mu kom­pu­te­ro­we­go nale­ży trak­to­wać jako pro­gram kom­pu­te­ro­wy (imple­men­ta­cja dyrek­ty­wy Parlamentu Europejskiego i Rady 2009/24/WE dnia 23 kwiet­nia 2009 (wer­sja ujed­no­li­co­na dyrek­ty­wy Rady Wspólnoty Europejskich nr 91/250 z dnia 14 maja 1991): ?dla celów niniej­szej dyrek­ty­wy poję­cie ?pro­gram kom­pu­te­ro­wy? obej­mu­je rów­nież przy­go­to­waw­cze pra­ce pro­jek­to­we i mate­riał projektowy?.

Co potwier­dza­ją tak­że auto­rzy naj­now­szych publi­ka­cji nauko­wych, np. 

Programming is not sole­ly abo­ut con­struc­ting software?programming is abo­ut desi­gning softwa­re”. .

Podsumowując: moż­li­we jest opra­co­wa­nie doku­men­ta­cji opro­gra­mo­wa­nia opi­su­ją­cej (wyma­ga­ny) mecha­nizm jego dzia­ła­nia i archi­tek­tu­rę. Oprogramowanie powsta­łe na bazie takiej doku­men­ta­cji to imple­men­ta­cja pro­jek­tu i sta­no­wi ono utwór zależ­ny w sto­sun­ku do utwo­ru jakim jest pier­wot­na spe­cy­fi­ka­cja. Prawo autor­skie jest tu wręcz dosko­na­łym mecha­ni­zmem kon­tro­l­nym nad wyko­naw­cą opro­gra­mo­wa­nia: mając pra­wa mająt­ko­we do pro­jek­tu tech­nicz­ne­go, z zasa­dy dys­po­nu­je­my w peł­ni opro­gra­mo­wa­niem wyko­na­nym na nasze zamó­wie­nie i na pod­sta­wie takiej doku­men­ta­cji. Jeżeli dostaw­ca stwo­rzy zamó­wio­ne opro­gra­mo­wa­nie ina­czej bo po swo­je­mu, to zna­czy tyl­ko tyle, nie zre­ali­zo­wał zawar­tej umo­wy i nie nale­ży mu płacić. 

Tak zwa­ne pro­jek­ty «agi­le» to cał­ko­wi­ty brak kon­tro­li nad wyko­naw­cą i nad wła­snym know-how. Trudno się więc dzi­wić, że jest to meto­da for­so­wa­na przez dostaw­ców opro­gra­mo­wa­nia i ich prawników. 

(pole­cam tak­że ana­lo­gicz­ny pra­wo­moc­ny wyrok doty­czą­cy muzy­ków gra­ją­cych z nut pod dyk­tan­do dyry­gen­ta)

Źródła

Wolak, G. J. (2019). Umowa o dzie­ło jako zobo­wią­za­nie rezul­ta­tu. https://​doi​.org/​1​0​.​3​4​6​9​7​/​2​451 – 0807-SP-2019 – 1‑006
Murawski, R. (Ed.). (2015). Filozofia mate­ma­ty­ki i infor­ma­ty­ki. Copernicus Center Press.
Friedenthal, S., Moore, A., & Steiner, R. (2009). OMG Systems Modeling Language (OMG SysMLTM) Tutorial September, 2009. 132.
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049