Wprowadzenie

Ukazała się książka Prawo w IT. Praktycznie i po ludzku [zotpressInText item=”{5085975:SDYYERHD}”]. Jako, że profesjonalnie zajmuję się tak zwanym IT, a z prawem dotyczącym IT mam ogromne doświadczenia jako biegły (ale prawnikiem nie jestem), ta książka od razu po wydaniu wylądowała się na moim biurku. Jak tylko zacząłem czytać zapadła decyzja: napisze recenzję. Czytam bardzo dużo, ale recenzuję (tu na blogu) książki bardzo dobre lub bardzo szkodliwe.

Autor książki, Szymon Ciach (profil LinkedIn: “Attorney-at-law | Counsel @Osborne Clarke Poland | IT & Data”.), profil na Cybergov.pl:

Patron medialny książki ITwiz.

Szymon Ciach
Counsel, Kancelaria Osborne Clarke Poland
Prawnik specjalizujący się w obszarze technologii oraz regulacji rynku finansowego. Posiada szerokie doświadczenie w przygotowywaniu i negocjowaniu umów IT (m.in. umowy wdrożeniowe, utrzymania i rozwoju systemów informatycznych, outsourcingu IT), zarówno na rzecz zamawiających, jak i dostawców. Jest ekspertem w zakresie wdrażania usług chmury obliczeniowej oraz outsourcingu IT w sektorze finansowym. Współtworzył standard wdrażania chmury obliczeniowej w bankowości “PolishCloud 2.0”, w roli Koordynatora Grupy Prawnej przy Związku Banków Polskich. Doradza również w budowie nowych modeli biznesowych na styku finansów i technologii (FinTech), w szczególności w zakresie wykorzystania technologii rozproszonego rejestru (DLT, blockchain). Absolwent WPiA Uniwersytetu Jagiellońskiego, członek Okręgowej Izby Radców Prawnych w Warszawie. Rekomendowany prawnik w sektorze TMT w Polsce (Legal 500 EMEA 2023). (https://cybergov.pl/prelegenci/szymon-ciach/)

Kluczowe pojęcia

W rozważaniach o znaczeniach pojęć od wielu lat kluczem jest tak zwany trójkąt semiotyczny, nazywany także trójkątem Ullmanna [zotpressInText item=”{5085975:RSU5DBMZ},{5085975:ZAV7CQ6P}”]. Poniżej wersja tego trójkąta opisana w publikacji Towards a model for grounding semantic composition [zotpressInText item=”{5085975:ESXILXF4}”].

Mamy tu pojęcia Concept (ang. pojęcie, myśl, abstrakcja), Symbol (ang. symbol, znak, reprezentacja, litera oraz słowo z nich zbudowane), Thing (ang. określony przedmiot, sprawa, zdarzenie, coś a także coś do zrobienia) [zotpressInText item=”{5085975:D7RVPITQ}”].

Odnosząc się do pojęć z dziedziny information science (pojęcia informatyka czy technologie informatyczne odnoszą się nieprecyzyjnie do tego co literatura naukowa nazywa w j. ang. information science oraz information technology).

Owszem, Słownik Języka Polskiego (SJP) podaje:

informatyka: «nauka o tworzeniu i wykorzystywaniu systemów komputerowych»

informacja 1. «to, co powiedziano lub napisano o kimś lub o czymś, także zakomunikowanie czegoś», 2. «dział informacyjny urzędu, instytucji», 3. «dane przetwarzane przez komputer»

dane 1. «fakty, liczby, na których można się oprzeć w wywodach» 2. «informacje przetwarzane przez komputer»

Tak więc mamy jednak rozróżnienie, które wielu autorów dostrzega [zotpressInText item=”{5085975:S7UN3N7Y}”].

Trójkąt semiotyczny, w odniesieniu do omawianych terminów, można więc przedstawić tak:

Model pojęciowy omawianej dziedziny:

Model pojęciowy (ontologia) to model pozwalający zbudować i przetestować system pojęciowy. Cechą poprawnego modelu jest wzajemne wykluczanie się definicji pojęć oraz istnienie typów czyli specjalizacji. Definicja pojęcia to klasyfikator a rzeczy, które spełniają tę definicje to zbiór (taki jak w matematyce) [zotpressInText item=”{5085975:7FREZB72}”]. Poprawny dziedzinowy model pojęciowy (przestrzeń nazw) na diagramie Venna [zotpressInText item=”{5085975:A4TSJUQC},{5085975:XTN432ZI}”] byłby modelem, w którym zbiory obiektów (things) są styczne i żadna granica zbioru nie przecina innej. Inną wersją testu poprawności jest prawo wyłączonego środka: “jeżeli coś jest czymś, to nie jest niczym innym” [zotpressInText item=”{5085975:6LD24N2L}”]. Specjalizacja (typ) to podzbiór:

Definicje pojęć z powyższego modelu:

Na tym tle pojęcie technologie informatyczne mają sens, pojęcie technologie informacyjne w zestawieniu z tym, że informacja to jest to co zrozumiał człowiek, dotyczy wyłącznie procesów myślowych, czyli np. procesów wnioskowania czy “liczenia w pamięci”. Potocznie możemy sobie pozwalać na utożsamianie pojęć dane i informacje, ale w opracowaniach eksperckich, czy wręcz naukowych, już nie [zotpressInText item=”{5085975:S7UN3N7Y}”].

Autor pisze, że (str. 22)

“dane reprezentują fakty i same w sobie nie mają znaczenia. Natomiast informacje to dane, które przez interpretacje odbiorcy nabierają znaczenia…”.

Niestety takie podstawienie sprawy jest nielogiczne i pozbawione sensu. Ullmann i Eco [zotpressInText item=”{5085975:RSU5DBMZ},{5085975:ZAV7CQ6P}”] jasno wykazują (trójkąt semiotyczny): dane to utrwalone znakami zapisy, a informacja to jest to co człowiek zrozumiał poznając je. Tak więc fakty (opis tego co zaszło) to informacja dla człowieka i dane jako utrwalone znaki i symbole. Zwracam uwagę, że encyklopedia w języku chińskim to na pewno dane, jednak niosą one informacje wyłącznie dla ludzi znających język chiński.

Jeżeli, jak pisze autor (str. 23), w kontekście prawnym pojęcia dane i informacje są używane jako synonimy to jest kardynalny błąd tych, którzy to czynią. Co ciekawe w następnym akapicie sam autor pisze, że konieczne jest “odróżnienie informacji od danych”.

Autor wplata znienacka pojęcie przepływu danych, ale nie wyjaśnia co ma to pojęcie wspólnego z danymi, ich ochroną i przetwarzaniem. Fakt zbierania danych osobowych nie jest przepływem danych, a co najwyżej ich utrwalaniem: ktoś informacje o sobie zapisuje (utrwala) w określonym formularzu na papierze lub ekranie komputera. Dostęp (człowieka) do danych to także nie jest przepływ danych. O przepływie danych możemy mówić wyłącznie wtedy, gdy są kopiowane z jednego nośnika na innych nośnik. I nie należy tego mylić ani utożsamiać z przepływem informacji (patrz encyklopedia w języku chińskim).

Stos technologiczny

Ten aspekt systemu informatycznego opisałem w artykule Sprzęt, środowisko, aplikacja, mechanizm. Tu zwrócę jedynie uwagę na kluczowe elementy. Autor prezentuje taką tabelę:

Autor definiuje “stos technologiczny” jako

sposób na opisanie opisanie zestawu technologii i narzędzi informatycznych mających jakiś wspólny mianownik

Autor nie podaje źródła tej kuriozalnej definicji. Najczęściej spotykaną definicją jest (trudno wskazać autora, Google pokazuje dziesiątki stron na to hasło):

stos technologiczny to zestaw elementów budujących stronę internetową lub aplikację. Są to język programowania, frameworki, systemy baz danych, biblioteki front-end i back-end oraz aplikacje połączone za pośrednictwem interfejsów API.

Po pierwsze stos technologiczny to nie aplikacja, ale ona oraz jej środowisko. Generalnie ten stos to sprzęt, sterowniki i szeroko pojęte oprogramowanie:

Jednak na użytek ochrony wartości intelektualnych w postaci oprogramowania (“Software”) dzielimy je (oprogramowanie) na odrębne aplikacje (SJP, aplikacja: komputerowy program użytkowy). Dlatego to co nazywamy stosem technologicznym przyjmuje bardziej skomplikowaną postać, bo pokazany tu Software to “frameworki, systemy baz danych, biblioteki front-end i back-end oraz aplikacje połączone za pośrednictwem interfejsów API”, i nie zapominajmy o systemie operacyjnym. O potrzebie separacji kodu aplikacji pisałem też w artykule Kastomizacja…

Duża nieprawda to dane jako osobna warstwa i to że są na szczycie tego stosu, bo jest odwrotnie: dane są na nośnikach a te, to hardware. Po drugie system operacyjny, oraz każda aplikacja, zarządza swoimi danymi niezależnie, więc nie są to “jedne dane”.

Autor stawia tezę, że dane to “podstawowy zasób świata IT” a zapomniał, że to za co płacimy najwięcej to aplikacje (np. system ERP) a nie dane. Po drugie często same dane na nośnikach są niemalże bezwartościowe bez logiki (procedury i algorytmy) ich przetwarzania.

Jak widać, dane są zawsze “na dnie” i NIGDY na szczycie “stosu”. Autor na str. 29 pisze, że pojęcie aplikacja stosuje się zamiennie z pojęciem system informatyczny co jest nieprawdą (patrz wyżej, model pojęciowy i stos technologiczny).

Na stronie 44 autor pisze o “środowisku informatycznym”. Najwyraźniej zapomniał czym jest stos technologiczny: TO jest właśnie to środowisko.

Nie miałem tu ambicji i nie było moim celem punktowanie wszystkich błędów, generalnie moim zdaniem cały rozdział Wprowadzenie to pasmo nieprawdy lub złych uproszczeń. Tytuł tego rozdziału to “Świat IT okiem prawnika”, jeżeli to prawda (tak prawnik rozumie IT) to jest to dowód na to, by prawnicy pozostali przy prawie, a inne informacje pozyskiwali, tak jak Sąd: od biegłych.

Umowy IT

Autor wprowadza pojęcie “Umowy IT” i z jednej strony sam stwierdza, że to umowy których przedmiotem są “technologie informacyjne”, zapominając że sam wskazywał na różnice między systemami informacyjnymi a informatycznymi. Pamiętajmy, że “technologią informacyjną” jest także system znaków drogowych na drogach…

Nie przypadkiem na całym świecie mamy prawo karne i cywilne. Sprzęt komputerowy i oprogramowanie to jedne z wielu możliwych przedmiotów umowy cywilno-prawnej. Pamiętajmy, że prawo autorskie i tajemnica przedsiębiorstwa dotyczy szeroko-pojetej treści. To czy jest nią kod źródłowy czy treść trylogii Władca Pierścieni nie ma żadnego znaczenia. Przedmiot zamówienia to (powinna być) treść załącznika do umowy i nie jest to praca dla prawnika (za wyjątkiem umowy z prawnikiem na usługę prawniczą).

Autor pisze, że programy komputerowe podlegają ochronie jak utwory literackie. Owszem, jeżeli ten kod rozumiemy jako tekst (znaki). Niestety mamy także pojęcie “informacja”, np. o mechanizmie naliczania upustów w programie lojalnościowym, i tu ochronie (tajemnica przedsiębiorstwa) podlega mechanizm naliczania upustu, bez względu na formę jego wyrażenia (o ile jest zrozumiała dla czytelnika), a mogą to być schematy blokowe i wzory matematyczne (patrz artykuł Prawo autorskie i wartości niematerialne – analiza systemowa oraz Ochrona wartości intelektualnych i know-how w organizacji – Poradnik). Ten mechanizm można zaimplementować w dowolnym języku oprogramowania, więc będą to “różne teksty o tym samym”. Co to znaczy? To znaczy, że TREŚĆ zeznania świadka morderstwa, jest tą samą treścią bez względu na to czy została utrwalona (dane) w języku francuskim czy języku Aborygenów.

Autor wprowadza pojęcie “Umowy wdrożeniowej”. Nie mam pojęcia po co, skoro to czy dana praca jest wdrożeniem czegokolwiek czy nie jest, jest skutkiem przedmiotu pracy a nie jej nazwy.

Autor pisze o modelu kaskadowym ale opisał ten model jak za czasów komputerów mainframe z lat 70tych ubiegłego wieku: każdy etap dotyczy całego systemu, co w dobie systemów zintegrowanych i komponentowych po prostu nie jest prawdą (patrz artykuł Integracja systemów ERP jako źródło przewagi rynkowej).

W rozdziale Umowy na inne usługi IT autor napisał (str. 195), że “Umowa na usługi programistyczne to najprostsza prawna forma współpracy w zakresie wytwarzania lub rozwoju oprogramowania”. Jak to przeczytałem, to pomyślałem od razu o prawach autorskich, o których autor pisał wcześniej, o różnych formach wyrażenia oprogramowania, o tym, że mamy licencje i przekazanie praw majątkowych, o tym, że stos technologiczny to aplikacja i biblioteki. Usługi programistyczne, a szczególnie ich produkt, to – patrząc na mediacje i spory w sądach – jedna z najtrudniejszych dziedzin w IT i w prawie. Kastomizacja systemu ERP czy dedykowane oprogramowanie napisane z użyciem określonego języka programowania i jego bibliotek, to labirynt. Gdy czytam jak prawnik pisze, że to “najprostsza umowa” to krew mi zamarza.

Podsumowanie

Opisałem wybrane, “ciekawsze” w moim subiektywnym odczuciu, elementy tej książki. Jednak cała ta książka, poza treściami stricte dotyczącymi prawa (a takich jest tam bardzo mało) spowodowała, że czytając tę książkę czułem się jak bym czytał książkę dobrego aktora piszącego swoje wyobrażenia o stolarstwie, bo “scena to deski”.

Opisanie wszystkich wad tej książki zajęło by wiele czasu i stron tekstu, bo niemalże każdy jej rozdział zawiera treści wymagające skomentowania lub wręcz wadliwe. Dlatego z uwagi na charakter i objętość bloga (staram się czas potrzebny na przeczytanie jednego postu nie przekraczał 20 minut) ograniczyłem się kilku wybranych wad, które w moich czynią tę książkę nieprzydatną dla osoby poznającej branżę, a osoba mająca stosowną wiedzę zareaguje podobnie jak ja: odłoży i nie wróci do niej.

Jako osoba, która widziała niejedno nieszczęście wdrożeniowe, nie tylko jako biegły w sądzie, zawsze będę powtarzał: prawnik, który projektuje systemy IT nigdy, nie będzie odpowiadał za ich nieudane wdrożenia, bo nawet gdy na etapie negocjacji umowy ma coś do powiedzenia, to Sąd nigdy nie powoła prawnika jako biegłego w sporze o przedmiot wdrożenia IT. Szanowni Państwo, pamiętajcie o tym, bo to co ja widzę w umowach i w dokumentach sądowych to na prawdę dramat.

A moja rekomendacja? Cóż, odradzam tę książkę prawnikom, korzystając z niej zrobią krzywdę swoim klientom. Prawnikom polecam raczej  Logika dla prawników [zotpressInText item=”{5085975:KVQS3HXD}”]. Branża IT? To tym bardziej nie jest książka dla Was.

Polecam także artykuł Wzorcowe klauzule w umowach IT oraz Przed Tobą wdrożenie systemu IT czyli Polemika z poradami prawników.

Prawnicy, bądźcie prawnikami i uczcie się od sędziów: do zagadnień z poza prawa powołujcie w swoich projektach biegłych (ekspertów).

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

Bardzo często można w książkach i na blogach spotkać opisy wzorców architektonicznych, wzorców projektowych, dobrych praktyk. Jednak bardzo rzadko autorzy piszą o tym kiedy je stosować. Sam fakt, że jakiś wzorzec “rozwiązuje jakiś problem”, co jest celem tworzenia i stosowania danego wzorca, nie mówi nic o tym jak często i kiedy dany problem się pojawia.

Komputer może być częścią firmy, samochodu, lodówki, telewizora, może być platformą dla oprogramowania użytkowego albo dla gier komputerowych, ale te – użyte – staja sie częścią tego komputera (gramy na komputerze a nie na grze). Oprogramowanie użytkowe czy gry komputerowe (to też oprogramowanie) mają pewne cechy. Kluczową cechą jest zmienność mechanizmu działania lub całkowity brak takiej zmienności. W efekcie inne problemy rozwiązuje projektant gry czy systemu operacyjnego (tu w zasadzie nic sie zmienia), a inne projektant aplikacji której zadaniem jest np. zgodne z prawem fakturowanie wyprodukowanych wyrobów czy zrealizowanych usług (tu zmiany mogą zachodzić nawet kilka razu w roku).

Tak więc owszem, software to “słoń w pokoju” inżynierii [zotpressInText item=”{5085975:Y3KLU3JX}”].

Komputer

Komputer to generalnie procesor, pamięć i program. Jako materialna całość stanowi sobą jednak dość skomplikowane urządzenie zawierające także porty i urządzenia wejścia i wyjścia, a także elektromechaniczną część czyli zasilanie, obudowę, klawiaturę, ekran, mysz, wentylację itp. Nie zmienia to faktu, że jest to urządzanie realizujące określony mechanizm, jego zachowanie się “jest programowane”, czyli zachowanie się tego urządzenia jest efektem wykonywania przez procesor komputera kodu programu przechowywanego w pamięci, ten zaś jest niczym innym jak procedurą (zestawem procedur). Dlatego mówimy, że komputer to uniwersalny mechanizm [zotpressInText item=”{5085975:ZCXJ2S7U}”].

Urządzeniami wejścia i wyjścia mogą być nawet bardzo skomplikowane konstrukcje elektromechaniczne a całość może być nie tylko maszyną do pisania ale także robotem przemysłowym czy autonomicznym samochodem. Większe systemy (mechanizmy) dzieli się często na mniejsze części: komponenty, a te – każdy – może być samodzielnym urządzeniem zawierającym komputer. Notebook, który prawdopodobnie czytelnik tego tekstu ma teraz przed sobą, to złożone urządzenie. Wiele jego komponentów: dysk twardy, karta graficzna, klawiatura, ma swój procesor.

Wiele urządzeń, pierwotnie w 100% elektromechanicznych, ewoluuje do hybrydy: urządzenie elektromechaniczne + komputer, nazywamy to urządzeniem “mechatronicznym”. Prostym i typowym przykładem są zegary i programatory mechaniczne (np. pralki, obrabiarki). Bardziej wyrafinowane są urządzenia przetwarzające sygnały (zamiana analogowych urządzeń na cyfrowe), np. telefonia i telewizja. Proces ten postępuje (np. zegar obecnie może być w 100% komputerem). System ERP to też takie urządzenie.

Poniżej wykres pokazujący rosnący udział kosztów oprogramowania w urządzeniach, odpowiada to temu, że coraz więcej funkcji w tych urządzeniach realizuje (przejmuje) komputer [zotpressInText item=”{5085975:I7N5YSN4}”]. Trend ten nie jest nowy [zotpressInText item=”{5085975:2JAV96GM}”]. Więcej [zotpressInText item=”{5085975:NLT4Z5MI}”].

Jeżeli, kiedyś zegar odmierzał czas z pomocą wahadła i kół zębatych, a teraz role te pełnią procedury wykonywane przez procesor, to znaczy że komputer ma tę samą funkcjonalność co klasyczny zegar, ale nadal mechanizm pomiaru czasu to sekundy, minuty i godziny (patrz Zegar). Wielu autorów nazywa to wirtualizacją tego mechanizmu [zotpressInText item=”{5085975:5MQBZYDU}”].

Schematycznie urządzenie mechatroniczne mozna pokazać tak:

Są tu trzy kluczowe warstwy:

• hardware – sprzęt elektromechaniczny,
• firmware – sterowniki (ang. drivery) czyli interfejsy oferowane pomiędzy częścią elektromechaniczną a programową,
• software – funkcje systemowe i aplikacyjne, czyli właściwy kod, tu dobrą praktyką (wzorcem architektonicznym) jest wydzielenie (oddzielenie kodu, implementacji) kodu logiki dziedzinowej, reszta to tak zwane środowisko systemowe: system operacyjny i jego otoczenie.

Znakomita większość tej układanki to standardowe produkty, które praktycznie nie są modyfikowane od momentu ich wytworzenia. Są to: sprzęt oraz sterowniki dostarczane wraz z nim, systemy operacyjne i środowiska programistyczne (system operacyjny, biblioteki programistyczne, kompilatory). Pozostaje clue czyli wirtualizowany mechanizm co pokazano poniżej:

Jeżeli więc wirtualizujemy jakiś mechanizm jako program komputera, to kodowanie (pisanie kodu w jakimś języku programowania) de facto jest konfigurowaniem zachowania tego komputera. Pozostaje jedynie wcześniej opisać lub zaprojektować wirtualizowany mechanizm (opracować dokument zawierający modele np. w notacji UML).

Model systemu i ochrona wartości intelektualnych

Z perspektywy dziedziny zwanej informatyką lub technologią informatyczną, najczęściej mamy do czynienia z oprogramowaniem określanym jako aplikacje biznesowe. Jest to oprogramowanie wspomagające zarządzanie takie jak CRM, ERP, workflow itp. ale także sklepy internetowe czy kasy samoobsługowe. Aplikacje te często pochodzą z różnych źródeł i wtedy są integrowane (patrz Integracja ERP).

Struktura systemu informatycznego w średniej wielkości organizacji może schematycznie wyglądać jak pokazano poniżej:

Warto tu zwrócić uwagę na kwestię tego czym tu są, i czyje są, chronione wartości intelektualne (ang. IP, Intellectual Properties). Na powyższym diagramie w zasadzie każdy element może być licencjonowany od innej firmy. Coraz częściej jednak zdarza się, że organizacja, w pewnym obszarze, cechuje się pewną własną, unikalną logiką działania. Rzadko jest to więcej niż 10% całości mechanizmów działania danej organizacji gdyż większość wymuszają prawo i standardy branżowe. Jednak organizacje, szczególnie te które wyróżniają sie na rynku, cechują się pewna specyfiką, unikalnym elementem sposobu swojego działania. Wtedy powstaje potrzeba stworzenia dedykowanego oprogramowania (Custom Application). Wymaganiem wobec oprogramowania, czyli de facto komputera, jest ten specyficzny mechanizm działania, który musi zostać opisany aby możliwa była jego ochrona jako ww. wartości intelektualne i jego odtworzeniem z pomocą komputera (wirtualizacja). Np. archiwum treści w postaci e-booków to nic innego jak zwirtualizowane archiwum papierowe wraz z zasadami dostępu do zasobów, rejestracją udostępniania itp.

Od wielu lat toczą się spory na temat tego czy i jak chronić to powyżej opisano. Aktualne prawodawstwo powoli ale systematycznie zmierza jednak do tego, by chronić opis mechanizmu a nie kod, który go implementuje:

Prawa autorskie, chociaż nie doprowadziły do tak wielu jawnie absurdalnych zgłoszeń, zostały mocno rozciągnięte przez sądy. Pojęcie, pierwotnie mające na celu ochronę prac literackich, zostało tak rozszerzone, iż zawiera takie pisarskie „prace” jak programy komputerowe czy nawet kod maszynowy i kod wynikowy, którym bliżej do elementów maszyn, takich jak krzywka, niż do prac literackich. [zotpressInText item=”{5085975:QAHTAUZ4},{5085975:Y4W6IFZI}”]

Na tym tle ciekawe jest:

2.6. Wystarczające ujawnienie
Opis wynalazku powinien przedstawiać (ujawniać) wynalazek na tyle jasno i wyczerpująco, aby znawca mógł ten wynalazek urzeczywistnić, a ekspert mógł dokonać rzeczowej analizy porównawczej z dotychczasowym stanem techniki. Za „znawcę z danej dziedziny” uważa się przeciętnego praktyka dysponującego przeciętną, ogólnie dostępną wiedzą z danej dziedziny w odpowiednim czasie, który dysponuje typowymi środkami i możliwościami prowadzenia prac i doświadczeń. Przyjmuje się, że specjalista taki ma dostęp do stanu techniki; tzn. informacji zawartych w podręcznikach, monografiach, książkach. Zna także informacje zawarte w opisach patentowych i publikacjach naukowych, jeżeli wynalazek dotyczy rozwiązań, które są na tyle nowe, że nie są zawarte w książkach. Ponadto, potrafi korzystać ze stanu techniki w działalności zawodowej do rozwiązywania problemów technicznych. Przedstawiony wynalazek powinien więc nadawać się do odtworzenia bez dodatkowej twórczości wynalazczej. Pod pojęciem tym należy rozumieć dodatkową działalność umysłową, eksperymentalną związaną z niepełną informacją techniczną zawartą w opisie wynalazku, a także konieczność dodatkowych uzupełniających badań naukowych, niezbędnych do realizacji rozwiązania według wynalazku w pełnym zakresie żądanej ochrony. Odtworzenie wynalazku powinno być możliwe na podstawie przeciętnej wiedzy specjalisty w danej dziedzinie, bez nadmiernego wysiłku. [zotpressInText item=”{5085975:Y86V5TMQ}”].

Z perspektywy tematu tego tekstu w miejsce słowa “wynalazek” wystarczy wstawić słowo “produkt” (lub komputer). Dlatego niektórzy autorzy operują pojęciem “testu urzędu patentowego: “czy to COŚ można zgłosić jako patent”, i niestety żaden kod źródłowy nie spełnia twego warunku. Tu autor wynalazku (produktu) to projektant, zaś znawca zdolny do jego urzeczywistnienia, to deweloper.

Bezpieczeństwo

Kilka słów o bezpieczeństwie. W obszarze tak zwanego cyberbezpieczeństwa mówi się o podatnościach:

Podatności to luki w systemach informatycznych, które mogą być wykorzystane przez atakujących do uzyskania nieautoryzowanego dostępu do danych lub systemów. Mogą one wynikać z błędów w oprogramowaniu, niewłaściwej konfiguracji systemów, słabych haseł czy też zaniedbania w aktualizowaniu oprogramowania. Podatności stanowią poważne zagrożenie dla bezpieczeństwa, ponieważ mogą być wykorzystane do przeprowadzenia różnorodnych ataków, takich jak kradzież danych, przejęcie kontroli nad systemami, czy też zakłócenie działania usług.

W praktyce podatności mogą przyjmować różne formy. Przykłady obejmują exploity wykorzystujące luki w oprogramowaniu, ataki typu SQL Injection, które wykorzystują słabe zabezpieczenia baz danych, czy też błędy w konfiguracji serwerów, które pozwalają na nieautoryzowany dostęp. Każda z tych podatności może prowadzić do poważnych konsekwencji, w tym utraty danych, naruszenia prywatności, a nawet strat finansowych. (https://nflo.pl/baza-wiedzy/czym-jest-zarzadzanie-podatnosciami-it-vulnerability-management-i-dlaczego-jest-kluczowe-dla-cyberbezpieczenstwa/)

Definicje, taka jak powyższa, skupiają się na “systemie informatycznym” jednak należy odróżnić wadliwość zaimplementowanego mechanizmu od wadliwości jego implementacji (błędy w kodzie) oraz celowego działania dewelopera (exploity). Innymi słowy podatnościami mogą być:

• niskiej jakości projekt (złe procedury w mechanizmie działania aplikacji),
• niskiej jakości implementacja (błędy koderów),
• celowe działania projektanta i/lub dewelopera.

Powyższe może dotyczyć każdej ww. warstwy. Czy certyfikaty chronią? Paradoksalnie bardzo słabo: wiele znanych z prasy włamań, a w dużych instytucjach wszystkie, to włamania do organizacji i ich systemów, które miały certyfikaty.

Bardzo niebezpieczne (stwarzają ogromne ryzyko) są monolityczne aplikacje (jeden błąd i cały system jest otwarty). Najskuteczniejszą metodą ochrony jest dzielenie systemu na komponenty bo mogą one kontrolować się wzajemnie, a podatność zamknie się jednym komponencie, czyli w razie ataku nie “padnie” cały system a jeden jego komponent. Te komponenty nie powinny pochodzić z jednej fabryki. Podział systemu na dziedzinowe aplikacje i ich integracja powoduje, że żaden dostawca nie ma “władzy” nad całością.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

Stale śledzę to co świat nazywa “publikacje naukowe”. Niestety notuje powolny upadek nauki, w już w branży informatyki postęp tego upadku jest chyba najszybszy.

Regularnie czytam, że w Internecie jest łatwy dostęp do dobrej darmowej wiedzy i publikacji naukowych.

Popatrzmy co znalazłem:

Szynalski, K., & Różański, D. (2022). Wprowadzenie do modelowania w języku UML. Biuletyn Naukowy Wrocławskiej Wyższej Szkoły Informatyki Stosowanej. Informatyka, 9(1), 31–37. https://bibliotekanauki.pl/articles/2146699.pdf [zotpressInText item="{5085975:XYBM5BGI}"]

To nie tylko “Darmowa wiedza w Internecie” to “publikacje naukowe”, a Panowie autorzy pewnie się (mam nadzieję, że nie) doktoryzują (pozakładali sobie numery ORCID). To, że na wielu blogach ludzie piszą brednie wiem od dawna, ale to że ktoś je recenzuje i publikuje do druku i na stronie: https://bibliotekanauki.pl/ to jest to dramat. Aha, obaj autorzy to deweloperzy: Konrad Szynalski, Dawid Różański (linki do ich profili na LinkedIn, dane kontaktowe w publikacji).

The Library of Science is a service run by the Open Science Platform (PON) team operating as part of the Interdisciplinary Centre for Mathematical and Computational Modelling of the University of Warsaw. (https://bibliotekanauki.pl/ )

Czytamy na stronie:

Serwis internetowy Biblioteki Nauki powstał w ramach projektu Platforma Polskich Publikacji Naukowych współfinansowanego ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach II osi priorytetowej Programu Operacyjnego Polska Cyfrowa na lata 2014 – 2020, Działanie 2.3. (Łączna wartość projektu: 5 164 777,78 zł; dofinansowanie z Funduszy Europejskich: 4 370 951,43 zł).

Krótka recenzja

1. “UML Umożliwia standaryzację sposobu opracowywania przekrojów systemu obejmujących różnorakie obiekty takie jak funkcje systemowe czy schematy baz danych.”,

UML, nie służy do modelowania danych, nawet słowa o tym nie ma w specyfikacji, to brednia. [zotpressInText item=”{5085975:DCYU6XZJ}”]

2. “Rys.1. Diagram zależności”,

nie ma czegoś takiego w UML, zaś związek include z jednym UC jest niezgodny z UML, łączenie w parę UC “Kupowanie” include “Przeglądanie produktów” to UML-owa brednia. [zotpressInText item=”{5085975:DCYU6XZJ}”]

3. “Rys.2. Diagram asocjacji”

takiego cuda też nie ma w UML, zaś silnik jest częścią samochodu (kompozycja), agregacja (pusty rombik) zniknęła z UML w 2015 roku (razem z dziedziczeniem) [zotpressInText item=”{5085975:DCYU6XZJ}”]

4. “Rys. 3. Zastosowanie diagramu agregacji częściowej”

takiego cuda w ULM też nie ma [zotpressInText item=”{5085975:DCYU6XZJ}”]

5. “Rys. 4. Zastosowanie diagramu agregacji całkowitej”

nie ma czegoś takiego, jest związek kompozycji [zotpressInText item=”{5085975:DCYU6XZJ}”]

6. “Rys. 5. Zastosowanie diagramu dziedziczenia”

tu brednia do kwadratu: nie ma dziedziczenia w UML, a diagram mówi, ze “narodowość i obywatelstwo dziedziczy po człowieku” (co oni palą?) [zotpressInText item=”{5085975:DCYU6XZJ}”]

7. “Rys. 9. Zastosowanie diagramu klas”

pokazano typowy anemiczny model dziedziny: to antywzorzec pochodzący z EJB/JavaEE

The fundamental horror of this anti-pattern is that it’s so contrary to the basic idea of object-oriented designing; which is to combine data and process together. […] In an anemic domain design, business logic is typically implemented in separate classes which transform the state of the domain objects. Fowler calls such external classes transaction scripts. This pattern is a common approach in Java applications, possibly encouraged by technologies such as early versions of EJB’s Entity Beans,[1] as well as in .NET applications following the Three-Layered Services Application architecture where such objects fall into the category of “Business Entities” (although Business Entities can also contain behavior). (https://en.wikipedia.org/wiki/Anemic_domain_model)

Tyle fragmentów z tej publikacji. To jedynie wybrane “kwiatki”, cała ta publikacja reprezentuje taki poziom.

I dziwić się, że ludzie nie lubią UML, po takiej “nauce” też bym znienawidził. Mój apel: ludzie, nie uczcie innych tego o czym nie macie bladego pojęcia! To jest publikacja z 2022roku !!!!!!!!! Aktualna specyfikacja UML jest z 2017, Ci ludzie nawet do niej nie zajrzeli! Bibliografia: sam szmelc, i NIE MA w niej ORYGINALNEJ SPECYFIKACJI UML.

Czy tak zwana Polska Nauka na prawdę upadła już tak nisko, że publikuje takie rzeczy na “swoich stronach”?

Recenzowana publikacja

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]