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”.

(wię­cej…)

Czytaj dalejDozwolony użytek programów komputerowych czyli o interfejsach

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.

(wię­cej…)

Czytaj dalejDiagram aktywności UML – kiedy

SPEM czyli Software & Systems Process Engineering

Tym razem arty­kuł adre­so­wa­ny do zaawan­so­wa­nych analityków. 

Ta spe­cy­fi­ka­cja (SPEM) jest dato­wa­na na 2008 rok. Stanowi sobą tło dla MDA oraz uza­sad­nia wzor­ce pro­jek­to­wa­ne opar­te na przy­pad­kach uży­cia (mikro­ser­wi­sy, Use Case 2.0, inne podob­ne). Podstawowa róż­ni­ca mię­dzy spe­cy­fi­ka­cją SPEM a spe­cy­fi­ka­cją UML pole­ga na tym, że UML to pro­fi­le MOF sta­no­wią­ce opi­sy nota­cji i sys­te­mów poję­cio­wych. SPEM to meta­mo­del pro­ce­su wytwór­cze­go opro­gra­mo­wa­nia czy­li gene­ral­ne zasa­dy budo­wa­nia pro­ce­sów wytwa­rza­nia i dostar­cza­nia oprogramowania. 

(wię­cej…)

Czytaj dalejSPEM czyli Software & Systems Process Engineering

Modele as-is i to-be, czy warto je robić?

Z zamiarem napisania tego tekstu noszę się już od kilku lat i za każdym razem mówiłem sobie: "ok, jeszcze tylko skończę ten jeden projekt i zobaczymy czy faktycznie ma to sens". I tak od kilku lat. W końcu jednak udało się. Wprowadzenie Popularność podejścia do modeli procesów biznesowych, polegającego na "pokazaniu różnicy", trwa od czasów popularyzacji re-inżynierii procesów biznesowych (lata 90-te) . Umowy na usługi, zawierające w zakresie opracowanie modelu 'as-is' i 'to-be' nadal są podpisywane. Zakładam, że decyzje o zakresie projektu to indywidualne potrzeby zamawiających. Ja opiszę swoje doświadczenia…

Czytaj dalejModele as-is i to-be, czy warto je robić?

Be IT 2021 – po konferencji

W Sobotę 22 maja 2021, na konferencji Be IT 2021 organizowanej przez Koło Naukowe Zarządzanie IT Politechniki Gdańskiej, poprowadziłem warsztat: Analiza i projektowanie struktury informacji. Z uwagi na tematykę: rzeczy dla uczestników nowe, takie jak chmurowe repozytoria i dokumentowe bazy danych NoSQL, poprowadziłem go jako konwersatorium omawiając przykłady repozytoriów NoSQL oferowane w chmurze publicznej oraz omawiając wcześniej przygotowany prosty przykład aplikacji dla Biblioteki, zbudowany z użyciem omówionych wzorców dla baz dokumentowych i notacji UML. Jak co roku otrzymałem ankietę i jak zawsze postanowiłem się z niej wytłumaczyć, a także przyjąć…

Czytaj dalejBe IT 2021 – po konferencji

Analiza nie musi być przedwdrożeniowa

Wprowadzenie

W ramach jed­ne­go z moich nie­daw­nych pro­jek­tów badaw­czych celem ana­li­zy nie było opra­co­wa­nie wyma­gań na opro­gra­mo­wa­nie (tego typu pro­jek­ty to naj­wy­żej ok. 70% mojej aktyw­no­ści) a roz­wią­za­nie pew­nych pro­ble­mów infor­ma­cyj­nych. Z uwa­gi na ochro­nę know-how klien­ta, opis ten został moc­no okro­jo­ny do isto­ty pro­ble­mu oraz meto­dy jego roz­wią­za­nia, nie ma tu z oczy­wi­stych powo­dów opi­su roz­wią­za­nia (ale waż­ne jest to, że roz­wią­za­nie zna­le­zio­no). Wartość jed­nak ma to, że czy­tel­nik może się tu odna­leźć i sam prze­ko­nać, co jest źró­dłem pew­nych pro­ble­mów, czy i jak moż­na je rozwiązać. 

W poniż­szym tek­ście poję­cie sys­tem odno­si sie do sys­te­mu doku­men­tów i for­mu­la­rzy czy­li do infor­ma­cji i zarzą­dza­nia nią. 

(wię­cej…)

Czytaj dalejAnaliza nie musi być przedwdrożeniowa

Krótka historia pewnego wymagania

Wprowadzenie Zarówno w projektach jak i w dyskusjach np. na konferencjach czy na LinkedIn, pojawia się stale pewne nieporozumienie: "projektowanie to waterfall". Myśli tak każdy, kto wyobraża sobie, że projekt czegoś to jakaś masa wszystkich możliwych detali. Jednocześnie nie ja jeden widuję "Dokumenty analizy biznesowej" albo "Dokumenty wymagań" zawierające setki pozycji o treści "system powinien...", nie raz wykonane przez krytyków "water fall", którzy reprezentując developera deklarującego metody "agile", "zabezpieczają się" przez odpowiedzialnością za zakres projektu. Pierwsza ważna uwaga: projekt systemu to nie jest ani zestaw dziesiątków "user story" ani detaliczna…

Czytaj dalejKrótka historia pewnego wymagania

Kod open source, prawa do niego i jego wartość

Na stronach portalu LindekIn ukazał sie bardzo dobry artykuł autorstwa Marcina Maruty z kancelarii Maruta Wachta sp.j., na temat oprogramowania open source: Barierą technologiczną jest brak dostępu do kodu źródłowego, niezbędnego dla wprowadzania zmian i rozwoju oprogramowania. Barierą prawną jest natomiast bardzo szeroki zakres ochrony programów komputerowych, który sprawia że jakakolwiek forma korzystania z programu, w tym jego modyfikowanie, wymagają uzyskania zgody uprawnionego. Ruch Open Source, wyrósł ze sprzeciwu wobec takiego stanu rzeczy, stawia sobie za cel tworzenie i popularyzowanie programów ?otwartych?, ?wolnych?, a więc dostępnych wraz z kodem źródłowym…

Czytaj dalejKod open source, prawa do niego i jego wartość
(źr. Martin Fowler, Analysis Patterns, 1997)
(źr. Martin Fowler, Analysis Patterns, 1997)

Koncepcja wzorca projektowego dla systemów w chmurze

Wprowadzenie W 2019 opisałem swoistą próbę rewitalizacji wzorca BCE (Boundary, Control, Entity). Po wielu latach używania tego wzorca i dwóch latach prób jego rewitalizacji uznałem jednak, że Zarzucam pra­ce nad wzor­cem BCE. Podstawowy powód to boga­ta lite­ra­tu­ra i utrwa­lo­ne zna­cze­nia pojęć opi­su­ją­cych ten wzo­rzec. Co do zasa­dy rede­fi­nio­wa­nie utrwa­lo­nych pojęć nie wno­si nicze­go do nauki. Moja publi­ka­cja zawie­ra­ją­ca tak­że opis tego wzor­ca bazo­wa­ła na pier­wot­nych zna­cze­niach pojęć Boundary, Control, Entity. Sprawiły one jed­nak nie­co pro­ble­mu w kolej­nej publi­ka­cji na temat dokumentów . Dlatego w mode­lu poję­cio­wym opi­su­ją­cym role kom­po­nen­tów przy­ją­łem nastę­pu­ją­ce bazo­we stwierdzenie:…

Czytaj dalejKoncepcja wzorca projektowego dla systemów w chmurze

Bazy NoSQL jako implementacje wzorców struktur informacji

Dane niestrukturalne stanowią ponad 80% składowanych danych, to oznacza, że model relacyjny pozwala opisać i przetwarzać tylko ułamek posiadanej informacji (UNSTRUCTURED DATA AND THE 80 PERCENT RULE) [toc] Wstęp W podsumowaniu niedawnego artykułu o NoSQL w chmurze, napisałem: Problem pro­jek­to­wa­nia struk­tur doku­men­tów, tak­że w bazach doku­men­to­wych, to osob­ne i trud­ne zagad­nie­nie. Opisałem go w naj­now­szym arty­ku­le, któ­ry uka­że się za nie­dłu­go w wydaw­nic­twie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation. (Repozytorium w chmurze - NoSQL - Jarosław Żeliński IT-Consulting - Systemy Informacyjne) Artykuł sie właśnie ukazał. We wstępie napisałem:…

Czytaj dalejBazy NoSQL jako implementacje wzorców struktur informacji

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: Business & Management Book Chapter | IGI Global

Jaroslaw Zelinski (Independent Researcher, UK)Source Title: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation Copyright: ? 2021 | Pages: 24 DOI: 10.4018/978-1-7998-8587-0.ch003 OnDemand PDF Download: Available $37.50 Current Special Offers Abstract This study presents a method for the storage of data organized in digital documents, which is proven in practice. The discussed method does not bear any disadvantages of the relational model used for data organization, such as the loss of data context and complications evoked by the lack of data redundancy. The method presented here can be used for data organization into documents…

Czytaj dalejDigital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases: Business & Management Book Chapter | IGI Global

Struktury formularzy jako forma wyrażania wymagań

Wprowadzenie

Ten arty­kuł to uzu­peł­nie­nie opi­su: Dokument jako wyma­ga­nie.

Często jestem i ja pyta­ny o to Jak wyja­śnić zło­żo­ne roz­wią­za­nie tech­nicz­ne inte­re­sa­riu­szom nie­tech­nicz­nym?” Jak wie­lu mi podob­nych odpo­wia­dam: roz­ma­wiaj doku­men­ta­mi. Sponsor pro­jek­tu, przy­szli użyt­kow­ni­cy, postrze­ga­ją swo­ją pra­cę poprzez doku­men­ty: ich treść i układ. Zauważyli to tak­że inni:

A Mock-up is a sli­gh­tly glo­ri­fied pic­tu­re, so you will be answe­ring with at least 1001 words ! 

Bardzo czę­sto widu­ję wyma­ga­nia spi­sy­wa­ne jako tak zwa­na lista funk­cji lub funk­cjo­nal­no­ści. Pojęcia te mają takie defi­ni­cje w języ­ku polskim: 

funk­cja ?zada­nie, któ­re speł­nia lub ma speł­nić jakaś oso­ba lub rzecz?, ?moż­li­wość wyko­na­nia okre­ślo­nej ope­ra­cji przez urzą­dze­nie lub pro­gram komputerowy?

Funkcjonalność jest defi­nio­wa­na jako funk­cja cze­goś w jakimś systemie. 

(wię­cej…)

Czytaj dalejStruktury formularzy jako forma wyrażania wymagań

Koniec treści

Nie ma więcej stron do załadowania