Niedawno napisał do mnie czytelnik pod jednym z artykułów:
Załóżmy, że realizujemy proces biznesowy: zarządzanie kursami walut. W ramach procesu pracownik musi przygotować plik csv zawierający wyłącznie listę słownikową par walut (np. usdpln, eurpln, eurusd). Nazwa pliku to np bieżącą data. Następnie systemX łączy się z API zewnętrznej platformy i pobiera tabele kursów tych par walut (aktualne i historyczne miesiąc wstecz) i wystawia plik xls zawierający dane: nazwa pary walut, data kursu, wartość kursy) Plik ten system X wysyła do szyby ESB. Szyna przesyła ten plik do systemuY. SystemY wykorzystuje te dane do wyznaczenia wewnętrznych kursów walut wg. ustalonego modelu matematycznego. Wynik obliczeń odkładany jest w bazie danych tego systemu. Na końcu procesu jest pracownik, który wykorzystuje te informacje za pośrednictwem SystemuZ. Wybiera parę walut, określa datę i system zwraca mu wewnętrzny kurs wyznaczony przez SystemY. Technicznie odbywa się poprzez odpytanie systemu Y poprzez jego API. Czyli mamy SystemX, SystemY, SystemZ, pracownika, szynę, plik csv, plix xls, 2XAPI no i przepływ danych (najpierw plików, potem poszczególnych atrybutów) . I jak to wszystkim pokazać żeby było czytelne? (źr.: : Model pojęciowy, model danych, model dziedziny systemu)
Prawdę mówiąc, mniej więcej w takiej formie dostaje materiały od moich klientów.. ;). Co możemy zrobić? Pomyślałem, że dobry reprezentatywny przykład. Popatrzmy…
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Niedawno blady strach padł na użytkowników oprogramowanie SAP AG za sprawą pewnego procesu i wyroku:
Po niedawnym orzeczeniu brytyjskiego Sądu Najwyższego, który potwierdził prawo firmy SAP do naliczania opłat za pośrednie korzystanie z systemów SAP przy użyciu takich aplikacji innych firm jak Salesforce, WorkDay i QlikView, korzystanie pośrednie jest obecnie wymieniane przez klientów firmy SAP jako główna obawa w obszarze zarządzania licencjami SAP i kontrolowania ich kosztów. […] W ostatnich tygodniach ryzyko związane z korzystaniem pośrednim ? dotychczas głównie teoretyczne ? stało się rzeczywistością, która może zmusić wiele przedsiębiorstw do poniesienia milionowych niezabudżetowanych kosztów dodatkowych licencji SAP. (Źródło: Korzystanie pośrednie główną obawą klientów SAP – ERP-view.pl)
Cóż to jest to „korzystanie pośrednie” i w czym problem?
In this instance, the third party systems are accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a ?user? must be set up to gain access to the SAP system. On the surface then it can appear like only one user (or a small number of users) is performing actions on the SAP system. In reality though, the ?user? will be performing far more tasks than is possible for a single person to undertake. (Źródło: SAP Audits ? Is it impossible to gauge financial exposure? – IT Asset Knowledgebase)
Generalnie chodzi o to, że integrowane ze sobą aplikacje wymieniają dane i „zlecają sobie” usługi, i tu warto wiedzieć co (dane, logika aplikacyjna) jest chronione prawami autorskimi i co stanowi know how. Problem tkwi w poprawnym zdefiniowaniu przedmiotu (obiektu) przetwarzania, przedmiotu prawa autorskiego i tego co stanowi know-how.
USTAWA z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych mówi:
Art. 1. 1. Przedmiotem prawa autorskiego jest każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia (utwór).
Art. 2. 1. Opracowanie cudzego utworu, w szczególności tłumaczenie, przeróbka, adaptacja, jest przedmiotem prawa autorskiego bez uszczerbku dla prawa do utworu pierwotnego. 2. Rozporządzanie i korzystanie z opracowania zależy od zezwolenia twórcy utworu pierwotnego (prawo zależne), chyba że autorskie prawa majątkowe do utworu pierwotnego wygasły. W przypadku baz danych spełniających cechy utworu zezwolenie twórcy jest konieczne także na sporządzenie opracowania. 2. (1) Ochroną objęty może być wyłącznie sposób wyrażenia; nie są objęte ochroną odkrycia, idee, procedury, metody i zasady działania oraz koncepcje matematyczne.
USTAWA z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji, mówi, że:
Art. 11. 4. Przez tajemnicę przedsiębiorstwa rozumie się nieujawnione do wiadomości publicznej informacje techniczne, technologiczne, organizacyjne przedsiębiorstwa lub inne informacje posiadające wartość gospodarczą, co do których przedsiębiorca podjął niezbędne działania w celu zachowania ich poufności.
Tak więc mamy kluczowe pojęcie: utwór oraz know-how. Utworem jest unikalna treść zaś know-how to nieujawnione i chronione (!) informacje (treści) techniczne, organizacyjne lub gospodarcze.
Czym jest owo „pośrednie korzystanie z systemu SAP”? Drugi tekst wyjaśnia: „accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a ?user? must be set up to gain access to the SAP system”. Czyli „pobieranie i zapisywanie danych”, użytkownik by mógł „tego dokonać” musi mieć dostęp Systemu SAP.
Jednak sam fakt istnienia dostępu i korzystania z niego, nie oznacza korzystania z cudzych wartości intelektualnych!
Najpierw model takiego przypadku:
Użytkownik bezpośredni Systemu to „standardowy”, licencjonowany użytkownik. Aplikacja pośrednicząca także korzysta z licencjonowanego dostępu (API). Jak, i z czego (i czy), korzysta Użytkownik pośredni Systemu?
Żeby wskazać to, z czego korzysta zewnętrzny użytkownik (aktor) Systemu, należy „zajrzeć” do wnętrza systemu. Architektura Systemu i integracji ma taką postać:
Na tym diagramie mamy trzy kluczowe elementy (tu artefakty) reprezentujące wartości intelektualne chronione prawem: Logika biznesowa, Zebrane dane i Strukturę danych. Logika biznesowa to sposób (metody) przetwarzania informacji (danych) zawarte w programie komputerowym, stanowią (mogą stanowić) know-how firmy, sam program komputerowy (jego treść) to ustalony utwór. Prawo autorskie chroni bazy danych (zebrane i uporządkowane dane) zaś struktura danych (projekt, model danych) to także utwór chroniony.
Zintegrowana z Systemem aplikacja korzysta z API Systemu. API standardowo pozwala np: na pobranie obiektu, wstawienie obiektu oraz wykonanie operacji z użyciem logiki biznesowej.
Zasadnicze pytanie brzmi: co w Systemie stanowi produkt „działalności twórczej o indywidualnym charakterze”? Na pewno jest to oprogramowanie jako takie oraz struktura (model) danych oraz baza danych, czyli zebrane dane (z uwagi na ich unikalną strukturę, model, w bazie danych). Jednak program realizuje określoną logikę biznesową (operacje na danych) i przetwarza określone obiekty biznesowe, czyli określone zestawy danych takie jak faktura czy dokument magazynowy WZ. Ogólnie operacje z użyciem Systemu (aplikacji) mają np. taką postać:
Jest to przykład możliwego dialogu użytkownika (aktor) z aplikacją (System). Dialog taki, niezależnie od stopnia komplikacji, będzie się składał z operacji będących logiką biznesową (czyli specyfiką dziedziny) lub techniczną (specyfiką technologii implementacji). Przedmiotem przetwarzania będą określone obiekty biznesowe (nazwane zestawy danych), komunikat na ekranie także może być takim obiektem (jeżeli tym komunikatem jest treść dokumentu a nie tylko tekst mówiący, że coś zostało wykonane np. bez błędu).
Tu jednak mamy do czynienia z oprogramowaniem wspierającym między innymi operacje opisane w ustawach (księgowe). Niewątpliwie prawo chroni strukturę danych, dane zebrane w bazie danych oraz know-how, to które jest nieznane „innym”. Jednak prawo nie chroni idei, nie chroni też tego co „jest powszechnie znane”. Warto także wiedzieć, że wdrożenie w toku którego miała miejsce tak zwana kastomizacja, „wnosi” know-how przyszłego użytkownika do kodu, i za korzystanie z tej logiki dostawca oprogramowania nie ma prawa brać wynagrodzenia. Pod warunkiem jednak, że kod realizujący to wniesione know-how jest jawnie wydzielony!
Nie ma jednoznacznej odpowiedzi na pytanie czy w danym przypadku ma miejsce korzystanie pośrednie z oprogramowania, niewątpliwie sam fakt integracji nie stanowi korzystania pośredniego. Nie jest tez prawdą, ze sam fakt integracji automatycznie implikuje korzystanie pośrednie wymagające opłaty licencyjnej. Kluczem do stwierdzenia tego jest wiedza o architekturze systemu, o architekturze całości integracji i o tym jakie operacje i gdzie są wykonywane. Na szczęście to dostawca Systemu musi uzasadnić swoje roszczenia dotyczące własności intelektualnej, jednak korzystający z tego Systemu – jeżeli nie potrafi podać kontrargumentów – nie jest w stanie się obronić. Niestety największym problemem jest wdrożenie polegające na kastomizacji, gdyż dochodzi do „wplecenia” nowej logiki biznesowej do już istniejącej w dostarczanym oprogramowaniu.
Skutek jest taki, że dostawca oprogramowania ma podstawy prawne do ochrony kodu jaki dostarczył, jednak kupujący nie ma żadnych podstaw (dokumenty, projekt itp.) by chronić swoje know-how i by nie płacić za swoje własne know-how „włożone” w toku wdrożenia, do wdrażanego oprogramowania.
Dlatego warto restrykcyjnie prowadzić proces analizy i projektowania, to jest umiejętnie udokumentować projekt tak, by granica pomiędzy wartościami intelektualnymi dostawcy i nabywcy oprogramowania była jasno określona. I nie jest to rola prawnika a architekta całości systemu, który musi także znać i rozumieć prawne aspekty tej architektury.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Bardzo często spotykam się z projektami inicjowanymi przez średnie kadry kierownicze dużych firm i urzędów, często mają one pewną wspólną cechę: „nie możemy nic zmieniać w strategii organizacji ale chcemy usprawnić pracę w naszym wydziale”. To z reguły bardzo cenna inicjatywa ale także dobra droga do porażki projektu. W urzędach często na granicy łamania prawa… a nie raz z jego łamaniem.
Projekty w administracji publicznej mają dodatkową specyfikę: zasady ustala prawodawca a nie menedżer organizacji. Bardzo dobrze opisał to zjawisko prof. Bolesław Szafrański wskazując przyczynę wielu porażek wdrożeń w administracji. Opisał trzy-etapowy referencyjny (i zalecany) proces wdrażania nowych rozwiązań, a na jego tle, w swoim opracowaniu, wskazał dostrzeżone zaniedbania administracji:
(źr. na podst.: Bolesław Szafrański, Wydział Cybernetyki, Wojskowa Akademia Techniczna, „Architektura korporacyjna ? problemy nie tylko pojęciowe”)
Cytuję to opracowanie, bo model ten jest bardzo podobny do ogólnej trójwarstwowej koncepcji organizacji. Prof Szafrański zwraca uwagę na to (z czym się zgadzam), że kolejność podejmowania decyzji i działań, powinna być następująca: opracowanie nowej lub zmienionej strategii (Dokument strategiczny), opracowanie taktyki działania (Model operacyjny działania) oraz opracowanie planu wdrożenia IT (Fundament działalności, w kontekście Architektury Korporacyjnej). Oczywiście nic nie stoi na przeszkodzie, by inicjatywa wyszła „od dołu”.
W swoim opracowaniu prof. Szafrański wskazuje, że wdrożenie nowej strategii wymaga sprawdzenia i ewentualnego opracowania nowych mechanizmów, procedur, prawa, pozwalającego nie tylko wdrożyć nową strategię ale także skutecznie ją „wymusić”.
Jeżeli powyższy model uogólnić do postaci obrazującej związek pomiędzy: strategią rynkową organizacji, wewnętrzną taktyką realizacji misji oraz tym jak zostały one zaimplementowane, to powstanie taki oto diagram (po prawej znane od lat opracowanie Business Process Trends):
Jeżeli pomiąć formę prawną, każda organizacja ma strategię i każda jakoś ją realizuje (implementuje: ma pracowników a Ci umiejętności i zakresy obowiązków). Mało która organizacja ma tak zwany „model operacyjny”, czyli to co łączy strategię i ludzi z ich obowiązkami i uzyskiwanymi efektami pracy. Czym jest taki model? To model procesów biznesowych: środkowa „warstwa” powyższego diagramu po prawej.
Rozwijające się ewolucyjnie organizacje zawsze dokumentują detale prac (informacje w procedurach zarządzania jakością i tak zwanych dokumentach kadrowych), często dokumentują to, jaką rolą pełni organizacja w swoim otoczeniu (misja, wizja, strategie itp.) i bardzo rzadko dokumentują wewnętrzny łańcuch wartości czyli procesy biznesowe oraz, no najważniejsze, logika tego jak „to wszystko działa” w środku (i czy działa z sensem). Wadą większości tego typu projektów, jakie obserwuję, jest skupianie się na detalach i pomijanie pryncypiów. W efekcie projekt pochłania wiele pracy i nadal nie mamy zrozumienia całości (w lit. ang. „big picture”), osiągane efekty są losowe.
Pokażę na dość prostym przykładzie o czym mowa (polecam ww. opracowanie prof. Szafrańskiego, opisał w nim błędy popełnione w przypadku informatyzacji Państwa).
Poniższy diagram to uproszczony model organizacji z zainstalowanym systemem EOD (Elektroniczny Obieg Dokumentów) oraz zachowanym, nadal wykorzystywanym „po staremu” oprogramowaniem poczty elektronicznej.
Linie ciągłe to droga jaką pokonują dokumenty z użyciem EOD. Linie przerywane to poczta elektroniczna. Jeżeli zostanie w jakiejś organizacji zainstalowany EOD (celowo nie używam słowa „wdrożony”) i nie zostanie z niej usunięty email jako narzędzie alternatywnej wewnętrznej komunikacji, to użytkownik będzie sam decydował, o tym którym kanałem przekaże daną treść. W efekcie EOD, który miał „mieć wszystko” nie ma wszystkiego, dane w EOD są niewiarygodne i niekompletne. Jeżeli jest to urząd, to metryka sprawy w zasadzie nie ma sensu, celem jej tworzenia była możliwość odtworzenia pełnego przebiegu sprawy, a tu urzędnik sam decyduje, które informacje i dokumenty przekazuje kanałem formalnym (EOD), a które „na boku”. Czy wszystko musi być w EOD? Tak. Jeżeli nie jest, EOD jest tylko uznaniowym archiwum dokumentów.
Aby skutecznie wdrożyć EOD należy najpierw opracować nowy model operacyjny działania organizacji, model uwzględniający nowe narzędzie pracy, model który w sposób systemowy wyeliminuje niepożądane elementy „złego starego systemu”. Dla przykładu powyżej należy wyeliminować kanały komunikacyjne oznaczone linią przerywaną. Domyślam się, że wielu czytelników myśli teraz „no jak to tak bez maila?!”. Po wdrożeniu EOD, wewnętrzny mail jest już nie potrzebny (a nawet jest szkodliwy), a na zewnątrz nadal jest narzędziem komunikacji firma-firma (tak np. działa mój system komunikacji z klientami). Bardzo często spotykam urzędy i firmy, w których obieg email i obieg „formalny” to uznaniowość pracowników. Te wdrożenia nie spełniają podstawowej roli systemów EOD: śledzenie spraw, statystyki zajętości pracowników, wychwytywanie wąskich gardeł, łatwe zastępowanie się pracowników, możliwość skontrolowania i przejęcia sprawy w dowolnym momencie, pełna historia wymiany informacji.
Takie wdrożenia to właśnie bardzo często inicjatywy na średnich szczeblach, gdzie mogą powstać decyzje o wydaniu środków na takie wdrożenie, ale nie ma żadnych szans na decyzje o opracowaniu i wdrożeniu zmian operacyjnych w skali organizacji (np. aktualizacja instrukcji kancelaryjnej w urzędzie, bez czego wdrożeni EOD nie ma tu żadnego sensu).
Celowo podałem ten przykład, bo typowym powodem niepowodzeń wdrożeń systemów EOD czy CRM (te systemy mają najgorszą statystykę niepowodzeń, a są bardzo podobne do siebie), jest brak opracowanego i wdrożonego skutecznego nowego operacyjnego modelu działania organizacji „po wdrożeniu”. Takim modelem są modele procesów biznesowych, ale nie w postaci monstrualnych ilości detalicznych diagramów (te są tu do niczego nie przydatne). Nie znam przypadku, by takie „obrazki” się do czegokolwiek przydały. Chodzi o modele sformalizowane, o ściśle ustalonym poziomie gradacji procesów. Ile diagramów „powinno być”? Tylko i aż tyle, ile trzeba do rozwiązania problemu… co opisałem między innymi tu.
Powyższe ma także inny istotny aspekt: planowanie i wdrażanie zmian. Typowy rozwój organizacji przebiega w sposób ewolucyjny, dość powolny. Nie wymaga żadnych dodatkowych zabiegów poza przemyślanym wprowadzaniem nowych, pojedynczych zarządzeń czy drobnych zmian organizacyjnych. Jednak próby wdrożenia znacznych zmian w krótkim czasie, z reguły skutkują nieoczekiwanymi efektami, nie zawsze pożądanymi. „Moda” na re-inżynierię procesów biznesowych w latach 90-tych przeminęła tak szybko jak się pojawiła. Dzisiejszy silnie konkurencyjny rynek nie daje czasu na powolne, ewolucyjne zmiany. Bezpieczne zaś wprowadzanie takich zmian nie jest możliwe bez przygotowania. Opisane powyżej plany operacyjne i ich testy, to nic innego jak właśnie przygotowanie się do takich zmian. Mając dobrze opracowane modele procesów i architektury IT (jako całość Architektura Biznesowa/Korporacyjna), możemy przewidzieć i przetestować, większość skutków planowanych zmian, i powoli ale coraz więcej firm to robi…
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Kolejna odsłona w rozwoju oprogramowania CASE firmy Visual Paradigm. Agile, pierwszych katach churra optymizmu, zaczyna troszkę się krystalizować co zauważył już [[Scott Ambler]] 12 lat temu:
Visual-Paradigm to także zestaw narzędzi Agile pozwalających z jednej strony zwinnie zarządzać projektowaniem i projektem (to nie jest to samo) z drugiej nie zaniedbywać analizy i modelowania tam gdzie to jednak pomaga.
Nowe elementy v.13.2.:
Kanban Board to nowe narzędzie pozwalające zarządzać zakresem projektu i jego realizacją. Kanban to opracowana w latach pięćdziesiątych w Japonii metoda sterowania produkcją. Słowo kanban w wolnym tłumaczeniu można w poniższym przypadku oddać jako ?spis widoczny?. Tu praktycznie oznacza to co znamy pod nazwą „backlog” tyle, że wersji „widocznej” jako tablicę postępu prac: bilboard dostępny dla członków zespołu.
User Story Estimation to nowy parametr obiektów „user story”. Generalnie tu (w tym narzędziu) user story to nie „proza użytkownika” a sformalizowana wersja znana jako szablon „ja jako .… chciałbym osiągnąć.… mając do dyspozycji …”, historyjki te są parametryzowane miedzy innymi (teraz) estymacja czasu ich implementacji co bardzo ułatwia zarzadzanie projektem.
Kroki wymagające potwierdzenia, nowa cecha specyfikacji przypadków użycia, bardzo ważna rzecz w specyfikowaniu przypadków użycia to wskazanie tych kroków scenariuszy, które wymagają potwierdzenia przez system.
Szybki podgląd (także zestawienie) historyjek użytkownika, w toku projektu kluczowe jest śledzenie projektu, który nie raz ma setki detali w zakresie, od teraz dysponujemy odpowiednimi zestawieniami i podsumowaniami, to jedyny sposób na sprawne zarzadzanie zakresem projektu.
Makiety ekranów to kolejny bardzo ważny element komunikacji z zamawiającym i definiowaniem zakresu projektu, rozbudowana została paleta elementów i ich cech.
CMMN (Case Management Model and Notation) to notacja opublikowana formalnie w 2014 roku. Notacja BPMN ma za cel modelowanie procesów biznesowych czyli powtarzalnych zachowań organizacji, CMMN to narzędzie do modelowania konkretnych (zidentyfikowanych) aktywności, nie przewidzianych w modelach procesów, także do modelowania proponowanych (zaakceptowanych) rozwiązań, w przypadku gdy dana aktywność stwarza problem.
Zarządzanie plikami w repozytorium TeamWork (serwer) z poziomu przeglądarki diagramów.
Tymczasowe diagramy analizy wpływu. Do tej pory były zawsze zapamiętywane co w dużych projektach skutkowało dużą ich liczbą i przeciążaniem projektu, teraz mogą one być tworzone „w locie” bez konieczności ich zachowywania.
Narzędzie potężnieje z każdą kolejną wersją. Obecnie oferowane jest w dwóch wersjach:
Visual-Paradigm (VP) jako narzędzie adresowane do wspierania procesów inżynierii oprogramowania.
ArchiMetric to rozszerzenie pakietu VP, to narzędzie wspierające prowadzenie analiz systemowych organizacji, szeroko pojętego modelowania architektury biznesowej (korporacyjnej).
W 2005 roku wybrałem to narzędzie całkowicie przypadkowo, kierowałem się czasem od momentu zamówienia do uzyskania licencji, bo działo się w toku bardzo ważnego projektu, w którym nie mogłem sobie pozwolić ani na przerwę ani na znaki wodne „evaluation version” w dokumentach w czasie oczekiwania na licencje. Po tych latach korzystania z VP i porównywania pracy z innymi narzędziami spotykanymi w projektach, nadal mam przekonanie, że nieświadomie dokonałem wtedy chyba najlepszego możliwego wyboru.
Więcej o nowinkach w aplikacji:
Visual Paradigm 13.2 introduces a number of new features, which includes:
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Narzędzie, którego używam od 2005 roku (rezygnując wtedy z MS Visio bo toporny i wyrzucając demo EA SPARX bo toporny i niezgodny z UML), staje się coraz lepsze. To co powoduje, że nadal nie planuję zmieniać narzędzia to mega ergonomia pracy, 100% zgodności ze specyfikacjami OMG, a przede wszystkim serwer pracy grupowej VPository, co razem daje mega platformę analityczno-komunikacyjną dla analityka i klienta.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Często spotykam się z czymś takim jak „Diagramy klas (UML) to modelowanie wymagań z perspektywy danych (model danych)”. Jest to niestety dość często spotykana „herezja”, także w zalecanej przez wielu literaturze, o czym swego czasu wspominałem:
Regularnie widuje pytania takie jak to: I have an assignment for developing a hotel reservation system! One of tasks is to develop UML class diagram! However, in the task description it is written ?Class diagram should represent your database?. I am a bit confused about the rules, notations and etc? because I can?t find any official UML class diagrams specifically for databases! Could you help me please? (UML class diagram for database). I regularnie piszę: używanie diagramu klas jako reprezentacji [relacyjnej] bazy danych to świadectwo kompletnego niezrozumienia analizy i projektowania zorientowanego obiektowo (żeby nie powiedzieć ignorancji). Jest to także świadectwo braku znajomości literatury, bo faktycznie, jak zauważa autor powyższych słów, nie ma oficjalnych materiałów (organizacja standaryzująca) mówiących o modelowaniu danych diagramami klas w notacji UML. Do modelowania danych używamy notacji ERD (ang. Entity Relationship, diagram związków encji). Niestety takie wzmianki ? jak stosować diagram klas UML do modelowania danych ? można znaleźć w książkach uznawanych za wartościowe (okładka jednej z nich po prawej), można usłyszeć na wielu szkoleniach dotyczących notacji UML, a nawet usłyszeć o tym można ? modelowanie danych w UML ? z ust niejednego wykładowcy na uczelniach wyższych technicznych (co jest smutne, mam na półce podręcznik akademicki z opisem stosowania kluczy głównych i obcych na diagramach klas UML w modelowaniu danych). Źródło: Business Analysis ? diagram klas UML i bazy danych | Jarosław Żeliński IT-Consulting
Przypomnę po raz kolejny czym jest obiektowy paradygmat analizy i projektowania:
Paradygmat obiektowy analizy i projektowania to uznanie, że analizowany lub projektowany system to współpracujące w określonym celu obiekty.
Definicja ta jest zbieżna z definicją pojęcia system: złożony obiekt wyróżniony w badanej rzeczywistości, stanowiący całość tworzoną przez zbiór obiektów elementarnych (elementów) i powiązań (związków i relacji) między nimi (Sienkiewicz, 1994).
Innymi słowy system, w rozumieniu ogólnej teorii systemów (UML i metody obiektowe wspierają właśnie tę teorię), system to zbiór współpracujących obiektów. Nie ma tu żadnej mowy o danych. Dlaczego? Bo współpracują ze sobą obiekty a nie dane. Owszem, dysponujemy nimi, ale … Każdy zespół współpracujących ludzi niewątpliwie wykorzystuje, a nie raz przetwarza, określone informacje. Jednak ta współpraca polega na współpracy, informacje są wymieniane na określonych nośnikach, to obiekty biznesowe. Np. celem negocjacji jest współpraca negocjatorów i podpisana umowa (jej treść to szczegóły przydane w sporze oraz cel zawarcia umowy), celem sprzedaży jest przychód (a nie faktura), celem dostawy jest towar w określanym miejscu i czasie (list przewozowy wskazuje miejsce i czas, dokument WZ to tylko specyfikacja konkretnego przedmiotu tej dostawy) itd.
Popatrzmy na jeden z wielu szkieletów tak zwanej architektury biznesowej (architektura biznesowa, architektura korporacyjna):
Ma ona, każda organizacja, przede wszystkim cele. By mogła je realizować ma: fasadę (tak się objawia na zewnątrz), wewnętrzne procesy biznesowe, metody komunikacja (z otoczeniem), oraz „entities” (nie mylić z modelem relacyjnym danych) czyli obiekty biznesowe, to co jest „mięsem” całości, bo to one ze przedmiotem współpracy i niosą informacje. Każda organizacja to system złożony ze współpracujących elementów: tych niosących informacje i tych mających wiedzę o mechanizmach (logice) tej współpracy.
Kolejna ważna rzecz to zauważenie, że oprogramowanie to narzędzie pracy. Część (rzadko kiedy wszystkie) obiektów biznesowych (są nimi dokumenty i ich treść) będzie miała swoje wersję elektroniczną, co jednak nie zmienia faktu, że to jedyna zmiana!
Tak więc kilka słów o wymaganiach na narzędzie pracy. Oprogramowanie to narzędzie pracy, wyrafinowane ale jednak tylko narzędzie, które jest deterministyczne, czyli 100% zachowań tego oprogramowania jest przewidywalna i została z góry określona. Te zachowania to nic innego jak nasze wymagania wobec tego narzędzia pracy. Skoro jest to narzędzie, to wymagania są opisem tego narzędzia. I tu zaczyna się „zabawa”, bo jednak nie działa „klasyczne” i anachroniczne już moim zdaniem, zestawienie wymagania funkcjonalne i poza-funkcjonalne (to podział z lat 80-tych). Tu przypomnę, że młotek może mieć kilkanaście cech, które można nazwać funkcjonalnymi i poza-funkcjonalnymi, co nie zmienia faktu, że generalnie służy wyłącznie do uderzania w coś (świadczy jedną usługę), jest to przypadek użycia: uderzyć w coś. Stan początkowy: wiemy w co uderzyć i po co (z jaką siłą), stan końcowy to efekt pożądany (np. wbity gwóźdź). Panuje moda na nazywanie przypadkami użycia kontekstu z perspektywy aktora, było by więc: uderz w gwoźdź, uderz w ścianę, uderz w osobę, uderz w szybę, uderz w stół słabo, uderz w płytę chodnikową mocno, i tak mozna w nieskończoność jak tylko np. nie przerwiemy tak zwanych „warsztatów zbierania wymagań”. To, takie podejście, nie ma większego sensu, bo zamula developera nadmiarem informacji i nic nie mówi o konstrukcji młotka.
Bardziej wyrafinowana usługą będzie zarządzanie danymi kontaktowymi. Mamy więc szafkę, szuflady, a w nich kartoteki z danymi kontaktowymi. Jest to narzędzie pracy, całość – szafka i jej zawartość – to „martwa natura”, której użytkownik (aktor) używa w sobie tylko znanym kontekście. Może nim być zapamiętywanie adresów dostawców, odbiorców, potencjalnych klientów, itp. Z uwagi na to, że ma być postęp, opisujemy tę szafkę razem z archiwistą (oprogramowanie zastąpi część jego pracy), który zarządza dostępem do niej. Czy karta katalogowa wie do czego jest używana? Nie. Czy cel użycia cokolwiek zmienia w konstrukcji tego mebla i jego zawartości? Nie. Więc co? Tu obiektem biznesowym będzie nośnik danych kontaktowych, jednak to my decydujemy co i po co zapisujemy a nie szafka, archiwista też nie wnika w treść. Owszem, wygodnie będzie opracować jednakowy szablon na te dane, nadal nie zmienia to faktu, że będziemy zaznaczali np. w polu „typ adresu” jakimś słowem czy dany adres to dostawca, odbiorca, czy może zainteresowany potencjalny klient.
Co tu jest wymaganiem? Zamawiając elektroniczną wersje kartotek, powiemy co nieco o łatwości dostępu, o wyszukiwaniu, o kontroli dostępu, i gdzieś na końcu przytoczymy wzór karty katalogowej. Dodamy reguły biznesowe (zastąpimy archiwistę), np. dane jednej osoby powinny być tylko na jednej karcie (brak dubletów) a świadectwem unikalności będzie zgodność imienia, nazwiska i kodu pocztowego (są też inne pomysły). Inną regułą może być zakaz niszczenia kart, żądanie niekontaktowania się może być realizowane dodatkowym zapisem „nie dzwonić”, nasze oprogramowanie przejmie na siebie procedury realizowane przez archiwistę.
Czy mamy tu jakąś „perspektywę danych systemu”? Gdybyś my mieli docelowo stworzyć oprogramowanie w modelu „dane + funkcje = program” to tak, ale my mówimy o obiektowych metodach analizy i projektowania, mówimy o tym deklarując użycia notacji UML (jest obiektowa). Każda większa aplikacja to wiele takich osobnych szafek na dokumenty, wiele reguł biznesowych powiązanych z dokumentami, całymi szafkami, oraz mechanizmy operowania tymi dokumentami w konkretnych celach. Czy ma tu jakikolwiek sens „wyciąganie” tego, że adres korespondencyjny podmiotu powtarza się w różnych kontekstach na większości tych dokumentach? Czy ma sens wyciąganie „na wierzch” tego, że połowa dokumentów zawiera coś takiego jak „produkt”. Nie ma to żadnego sensu, bo po pierwsze te szafki i kartoteki, każda żyje własnym życiem i nie zmienimy tego, w każdej chwili może nam dojść nowa szafka z nowymi papierami, a stara zniknąć gdy stanie się niepotrzebna. Może nam się przytrafić rezygnacja z szafki na rzecz korzystania z usługi biura numerów na telefon. Takich sytuacji nie tylko nie jesteśmy w stanie przewidzieć, możemy nie mieć możliwości przeciwdziałania temu (np. zmiany w prawie).
Obiektowe podejście uwalania nas od zajmowania się osobno „wspólnymi danymi”, powiem wręcz, podejście takie – usuwanie redundancji i współdzielenie – jest wręcz szkodliwe, „Perspektywa danych” to strukturalne a nie obiektowe podejście, nie ma w nim nic złego ale nie mieszajmy tego. Pisałem o tym:
Metody strukturalne to rozkładanie problemu biznesowego na oddzielone od siebie dane i procedury ich przetwarzania. Informacje o obiektach rzeczywistych są tracone w tych metodach. Model relacyjny danych to model, w którym utracono wiele informacji, np. nie da się z modelu relacyjnego odtworzyć np. faktury nie wiedząc jak ona wygląda. Do wydruku faktury potrzebne jest zapytanie, które wyciągnie z bazy danych właściwe dane i procedura która właściwie je sformatuje. Metody obiektowe polegają na wiernym modelowaniu (odwzorowaniu) świata rzeczywistego (domeny systemu), w efekcie nie tracimy żadnej wiedzy modelując (zapisując) ?świat? w postaci modelu dziedziny. Źródło: Czym jest a czym nie jest tak zwany model dziedziny systemu | Jarosław Żeliński IT-Consulting
Czy mamy więc jakieś perspektywy w modelach obiektowych? W zasadzie tylko dwie:
- przypadki użycia (diagram przypadków użycia) i skojarzone z każdym z nich scenariusze, jako opisy tego jak system ma się zachować w odpowiedzi na próbę jego użycia,
- struktura wewnętrzna tego systemu (model dziedziny systemu – diagram klas) , odwzorowująca „współpracujące obiekty”, jest to opis mechanizmu działania tego systemu (bloki funkcjonalne, obiekty i komponenty).
Czy ma sens tworzenie zamówienia na szafki do kartotek wysyłając tylko zdjęcie strony czołowej wraz z dziesiątkami stron opowieści o tym jak do tej pory ich używano? Jest to bardzo ryzykowne podejście. Duże bezpieczniej jest zaprojektować konstrukcję takiej szafki, wskazując gdzie jakie zamki i blokady chcemy mieć i dać taki projekt do wykonania. Owszem nie ma sensu odbieranie chleba inżynierom, pisanie z jakich materiałów to ma być zrobione i jakimi technikami wykonane i zabezpieczone. Ale wewnętrzne, „czysto biznesowe” szczegóły takie jak podział na szuflady, wzory kartotek, wymóg możliwości ich modyfikacji, kontrola dostęp do szuflad, owszem: to warto opisać samemu (lub zatrudnić projektanta).
Wiele książek zawiera opis tak zwanego widoku 4+1 Kruchtena. Co tam mamy? To jeden z wielu dostępnych w sieci opisów:
perspektywa logiki biznesu ? istnieje w każdym systemie informatycznym i ukazuje różne elementy systemu informatycznego w kontekście logiki biznesu, takie jak klasy, pakiety itp.;
perspektywa procesów ? opisuje wszystko co jest związane z współbieżnością pracy SI, najczęściej opisuje komunikację i synchronizację różnych komponentów systemu i z reguły dotyczy systemów rozproszonych i/lub współbieżnych;
perspektywa implementacji ? opisuje sposób implementacji elementów składowych systemu, z reguły jest to statyczny opis składowych elementów systemu w jego fizycznym środowisku (deweloperskim, a docelowo produkcyjnym);
perspektywa wdrożenia ? opisuje sposób fizycznego kopiowania i wdrażania różnych elementów SI, sposób ich komunikowania się w kontekście ich fizycznego rozlokowania na docelowej platformie informatycznej;
perspektywa przypadków użycia ? opisuje najbardziej znaczące wymagania SI dla użytkowników końcowych, czyli te przypadki użycia lub ich części, które wywierają największy wpływ na architekturę i są najbardziej krytyczne do zobrazowania mechanizmów działania systemu.
(źr. IIC Magazine2012/04/19/)
Wystarczy porównać to z moim opisem powyżej, by zauważyć, że powyższe to zbędne komplikowanie całości i niepotrzebne wplatanie kontekstu biznesowego (młotek nie wie w jakim celu jest używany).
Implementacja to praca dla developera a mieszanie w to późniejszego wdrożenia już zupełnie pomieszanie celów specyfikowania wymagań.
Przypadki użycia to zewnętrzne (widziane przez jego użytkownika) cechy systemu. Używanie słowa „proces” do tego co w UML nazywa się „sekwencja” powoduje tylko nieporozumienia, tu każdy przypadek użycia jest realizowany z użyciem wewnętrznych komponentów, jest to logika biznesowa (mechanizm działania) czyli i model dziedziny. Nie przypadkiem kluczową cecha obiektowego podejścia jest hermetyzacja czyli ukrywanie wnętrza komponentów (do samego końca). Najpierw analizujemy i dokumentujemy do czego służy faktura, a na końcu (mają kompletny projekt) upewniamy się (testujemy), że każdy komponent dysponuje wiedzą potrzebną mu do realizacji przypadku użycia. Na samym końcu jest mowa o danych, i nie jako odrębnej perspektywie, a jako wewnętrznych cechach (atrybutach) komponentów. Tu dopiero definiujemy ewentualne zawartości dokumentów reprezentowanych w modelu dziedziny przez odrębne komponenty. I absolutnie nie uwspólniamy (nie normalizujemy, nie pozbywamy się redundancji) na co zwróciłem uwagę na początku.
Nie powinniśmy zapominać, że model Kruchtena to połowa lat 90-tych, szczyt rozkwitu metod strukturalnych i raczkujące metody i narzędzia obiektowe. To stare systemy i ich relacyjne bazy danych wymusiły stosowanie [[mapowania ORM]] i takich narzędzi jak [[Hibernate]]. Dzisiaj mamy rok 2015, od tamtej pory minęło 20 lat. Nie musimy się cofać do początków inżynierii oprogramowania w wersji obiektowej. Coś takiego jak perspektywa danych to anachronizm. Podejście to w 100% zostały już dawno zastąpione przez MDA. Ale o tym już tu pisałem 😉
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.