Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
Cyfrowa Transformacja Organizacji: analizy systemowe przedsiębiorstw, projektowanie rozwiązań i przygotowanie do wdrożeń systemów standardowych i dedykowanych.
Ten artykuł to próba przybliżenia czytelnikowi pojęcia metamodel i model. To także mała próbka tego co jest produktem nadzoru autorskiego.
Nieco ponad pięć lat temu w artykule Diagram obiektów czyli bottom-up pisałem o pojęciu instancji obiektu i diagramie obiektów. Wtedy skupiłem się na jednym tylko wątku, jakim jest analiza zmierzająca do opracowania … no właśnie, czego? Z reguły autorzy dokumentów zawierających „diagramy klas” mówią, że tworzą modele. Czy zawsze są to modele?
Wprowadzenie
Jednym z bardzo niedocenianych typów diagramów UML są diagram obiektów i diagram wdrożenia (który jest rodzajem diagramu obiektów). Oba te diagramy służą do modelowania określonych sytuacji. Nie raz pisałem, że projekt (dokumentacja projektowa) tez ma cykl życia. To nie jest tak, że powstaje dokument Wymagania, zawierający jakieś modele, a następnie ktoś za niego płaci i ten dokument ląduje za szybą tylko do odczytu.
Patrząc na cykl życia projektu, dokumentacja stanowiąca początkowo Wymagania, żyje i rozwija się razem z nim. Ona także ma swój cykl życia. Na koniec dokumentacja ta jest opisem tego co powstało. Jest to model konkretnego ukończonego wdrożenia.
Meta Object Facility
(osoby nie interesujące się teorią mogą pominąć ten rozdział)
MOF (Meta Object Facility) to specyfikacja określająca bazowe pojęcia dla notacji zarządzanych przez Object Management Group . Specyfikacja ta określa trzy podstawowe poziomy abstrakcji oraz poziom podstawowy jakim jest świat (przedmioty) modelowany. Realny świat to poziom M0. Zobrazowanie realnego świata za pomocą nazw przedmiotów i ich wybranych kluczowych cech (bo nie wszystkich) to abstrakcja tego świata. Jeżeli jakieś grupy przedmiotów mają te same kluczowe cechy, ale różnią sie jedynie wartościami tych cech, np. wiele przedmiotów różni się wyłącznie kolorem i długością ale opisujemy je z pomocą koloru i długości, to mówimy, że mamy klasę przedmiotów o atrybutach kolor i długość, i nadajemy jej (temu zbiorowi) nazwę, nazwa ta często jawnie występuje w języku naturalnym, np. „kolorowe słomki” mają atrybuty: kolor i długość. Zakładamy, że przedmioty reagują na bodźce czyli mają zachowania: słomka pod wpływem siły przemieszcza się lub wygina (to operacja).
Powyższy diagram obrazuje ww. poziomy abstrakcji MOF. Złóżmy, że wśród drobnych przedmiotów realnych (poziom M0) są także nasze słomki. Dwie z tych słomek obrazujemy jak prostokąty mające nazwy: Egzemplarz 1 i Egzemplarz 2 (mają unikalne nazwy bo musimy je rozróżniać). To – poziom M1 – jest abstrakcja naszego świata: jego model. Skoro słomki mają te same cechy: nazwa, kolor i długoś, to tworzymy nazwę (tu Class) dla zbioru wszystkich takich słomek. Nazwa tego zbioru reprezentuje wszystkie takie słomki (zbiór słomek). Na poziomie M2 używamy już tylko nazwy zbioru. Poziom M2 to metamodel. Aby uporządkować nasze modele i metamodele, standaryzujemy tę metodę opisu, umawiając sie, że elementy naszych modeli to pojęcia (nazwy) i związki między nimi (zwane także asocjacje). Pojęcia mają zawsze definicje i reprezentują nazwy, czyli zbiory elementów zgodnych z daną definicją (elementy diagramów), a definicja ta to klasyfikator. Ta umowa to poziom M3, nazywany meta-metamodel (zbiór zbiorów). Mówimy, że w UML wszystko jest klasą.
Najnowsza specyfikacja MOF wskazuje, że co prawda podstawowe poziomy abstrakcji to te cztery wymienione, jednak nie ma żadnego zakazu organizowania zbiorów w zbiory. Robimy to na poziomie M2 a służą do tego tak zwane stereotypy: są to klasy klas. Np. gdyby było prawdą, że słomki mają przekroje kwadratowe i okrągłe to albo dodajemy im nową cechę: przekrój o wartości koło lub kwadrat, albo tworzymy podzbiory «kwadratowe» i «okrągłe». Możemy także doprecyzować, że cechą słomek «kwadratowe» zawsze jest także zapach a słomek «okrągłe» ich ciężar. Taka dodatkowa definicja typów klas i ich specyfiki to profil.
Projektowanie i realizacja projektu
Cykl życia projektu zaczyna się od budowy architektury systemu, budujemy strukturę złożona z bloków o określonym zastosowaniu: mówimy „system klasy CRM”, „system klasy ERP” czy „system klasy WorkFlow”. Nie wiemy jakie konkretne aplikacje wdrożymy, ale wiemy (powinniśmy to zdefiniować) jakie wymagania stawiamy przed każdą z tych klas aplikacji.
Idea podejścia zgodnego z MOF to analiza i jej efekt: nazwane bloki funkcjonalne systemu (diagram komponentów):
Ich definicje to wymagania na te komponenty. Każdy z powyższych komponentów można opisać przypadkami użycia. Całość może zostać zrealizowana jako odrębne aplikacje, każdy imponent jest zdefiniowany poprzez wymagania wobec niego. Nazwy komponentów są zwyczajowe, tak na prawde są one definiowane poprzez przypadki użycia i wewnętrzną architekturę informacji: są to dziedzinowe komponenty.
Wybierając i wdrażając kolejne aplikacje znamy ich nazwy i to jak współpracują (diagram wdrożenia):
Instancje (nazwy aplikacji prawdziwe ale przypadkowe, nie jest to rekomendacja żadnego z tych programów)
Powyższy diagram mozna uzupełnić o informacje o docelowym środowisku ich pracy:
Instancje wraz ze środowiskami w jakich zostały uruchomione
Należy także wskazać jakiej klasy są to aplikacje (które wymagania realizują), dlatego każdą konkretną aplikacje przyporządkowujemy do określonej wcześniej klasy komponentów:
Instancje wraz przyporządkowanymi klasyfikatorami (np. Salesforce to egzemplarz aplikacji klasy System CRM)
Detali opisujących wdrożenie krok po kroku może być więcej (np. interfejsy i ich specyfikacje). W każdym razie w dniu zakończenia wdrożenia dostawca zostawi po sobie detaliczną dokumentację wykonanej implementacji, dla administratora całego systemu, będzie to kilkaset, a bywa że kilka tysięcy, stron. Analityk-projektant, po etapie nadzoru autorskiego, zostawi po sobie dokumentację zawierająca abstrakcję: model systemu na potrzeby podejmowania decyzji taktycznych i strategicznych, raczej kilkadziesiąt stron (patrz także: Analiza, modelowanie i usprawnianie organizacji).
Następne wdrożenie nowego elementu systemu lub wprowadzenie w nim zmian, nie będzie już wymagało żadnej owej analizy, a jednie projektu pokazującego nowy komponent lub miejsce gdzie będą wdrażane zmiany.
Diagram komponentów to poziom M2. Diagram wdrożenia to poziom M1 wg. MOF. W ramach UML korzystamy tu z diagramu komponentów i diagramu wdrożenia, są standardowe profile dla UML (MOF także warstwa M2: dodatkowe stereotypy). Gdybyśmy chcieli tworzyć dedykowane komponenty, zapewne developer wykorzysta wzorce frameworki (gotowe zestawy bibliotek) i wzorce projektowe. To także definiuje się jako profile w warstwie M2 .
Larman, C. (2005). Applying UML and patterns: an introduction to object-oriented analysis and design and iterative development (3rd ed). Prentice Hall PTR, c2005.
Wei, B., Sun, J., & Wang, Y. (2018). A Knowledge Engineering Approach to UML Modeling (S). SEKE, 60 – 63.
Evans, E. (2014). Domain-driven design: tackling complexity in the heart of software. Addison-Wesley.
Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).
Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione. Ewentualne użycie treści wymaga indywidualnej zgody autora.
Nie wykryto skryptu Javascript. Javascript wymagany do działania tej strony. Proszę włączyć go w ustawieniach przeglądarki i odświeżyć tę stronę.
Zarządzaj zgodami plików cookie
Aby zapewnić jak najlepsze wrażenia, korzystamy z technologii, takich jak pliki cookie, do przechowywania i/lub uzyskiwania dostępu do informacji o urządzeniu. Zgoda na te technologie pozwoli nam przetwarzać dane, takie jak zachowanie podczas przeglądania lub unikalne identyfikatory na tej stronie. Brak wyrażenia zgody lub wycofanie zgody może niekorzystnie wpłynąć na niektóre cechy i funkcje.
Funkcjonalne
Zawsze aktywne
Przechowywanie lub dostęp do danych technicznych jest ściśle konieczny do uzasadnionego celu umożliwienia korzystania z konkretnej usługi wyraźnie żądanej przez subskrybenta lub użytkownika, lub wyłącznie w celu przeprowadzenia transmisji komunikatu przez sieć łączności elektronicznej.
Preferencje
Przechowywanie lub dostęp techniczny jest niezbędny do uzasadnionego celu przechowywania preferencji, o które nie prosi subskrybent lub użytkownik.
Statystyka
Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do celów statystycznych.Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do anonimowych celów statystycznych. Bez wezwania do sądu, dobrowolnego podporządkowania się dostawcy usług internetowych lub dodatkowych zapisów od strony trzeciej, informacje przechowywane lub pobierane wyłącznie w tym celu zwykle nie mogą być wykorzystywane do identyfikacji użytkownika.
Marketing
Przechowywanie lub dostęp techniczny jest wymagany do tworzenia profili użytkowników w celu wysyłania reklam lub śledzenia użytkownika na stronie internetowej lub na kilku stronach internetowych w podobnych celach marketingowych.