W toku szkoleń, a także audytów, powstają nie raz spory o interpretacje znaczenia symboli notacji: ich semantyki i syntaktyki (co oznaczają i jak je można łączyć z innymi). Dzisiaj o dość częstym sporze czyli bramki OR (inclusive) i XOR (exclusive) w notacji BPMN oraz o tym, że z 380 stron specyfikacji BPMN, w modelach analitycznych stosujemy tylko niecałe 40 stron rozdziału 7., pozostałe rozdziały służą wyłącznie lepszemu zrozumieniu teorii i modelom wykonywalnym. Czyli dlaczego w analizach stosujemy kilka, a nie kilkadziesiąt symboli notacji BPMN.
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.
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.
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.
Miło mi poinformować, że moja publikacja naukowa (tu była zapowiedź) na temat syntezy wzorców architektonicznych i wzorców projektowych, systemów obiektowo-zorientowanych zatytułowana:
po długim procesie selekcji i recenzowania, została zakwalifikowana do publikacji i właśnie się ukazała jako jeden z rozdziałów książki:
Jeszcze milej mi poinformować, że – jako współautor – mogę Wam zaoferować kod promocyjny dający 40% zniżki na zakup: IGI40.
Poniżej informacje o książce i o wydawcy.
O książce
Ch. 3: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities: Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns (050719 – 041004) (J.Żeliński)
DescriptionIn today?s modernized environment, a growing number of software companies are changing their traditional engineering approaches in response to the rapid development of computing technologies. As these businesses adopt modern software engineering practices, they face various challenges including the integration of current methodologies and contemporary design models and the refactoring of existing systems using advanced approaches.Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities is a pivotal reference source that provides vital research on the development of modern software practices that impact maintenance, design, and developer productivity. While highlighting topics such as augmented reality, distributed computing, and big data processing, this publication explores the current infrastructure of software systems as well as future advancements. This book is ideally designed for software engineers, IT specialists, data scientists, business professionals, developers, researchers, students, and academicians seeking current research on contemporary software engineering methods. Source: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities: 9781799821427: Computer Science & IT Books | IGI Global
O wydawcy
IGI Global is a leading international academic publisher committed to facilitating the discovery of pioneering research that enhances and expands the body of knowledge available to the research community. Working in close collaboration with expert researchers and professionals from leading institutions, including Massachusetts Institute of Technology (MIT), Harvard University, Stanford University, University of Cambridge, University of Oxford, Tsinghua University, and Australian National University, IGI Global disseminates quality content across 350+ topics in 11 core subject areas. Source: About IGI Global | IGI Global
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.
Streszczenie: Wiele publikacji, w tym podręczniki akademickie, zawiera niespójności w opisach zastosowań metod i wzorców architektonicznych, kryjących się pod skrótami MOF, MDA, PIM, MVC, BCE. Skuteczna analiza oraz następujące po niej projektowanie oprogramowania, szczególnie gdy są to projekty realizowane w dużych zespołach, wymaga standaryzacji procesu wytwórczego i stosowanych wzorców i frameworków. W pracy tej podjęto próbę uporządkowania systemu pojęć opisujących ten proces , stosowanych do opisu wzorców architektonicznych. Przeprowadzono analizę kluczowych pojęć MOF i MDA, wzorców MVC i BCE, stworzono spójny opis łączący je w jeden system.
1. Wprowadzenie
Celem badań było zweryfikowanie obecnego stanu metod projektowania i opracowanie spójnego systemu pojęć i wzorców projektowych w obszarze projektowania logiki oprogramowania, jako jej abstrakcyjnego modelu. Wiele publikacji na temat analiz i projektowania, w obszarze inżynierii oprogramowania, przywołuje nazwy wzorców projektowych MVC i BCE oraz model PIM (patrz OMG MDA, OMG MOF 2016). Z uwagi na, nie raz, nie małe rozbieżności w interpretacji tych metod i wzorców, autor podjął próbę uporządkowania ich wzajemnych zależności.
2. Metody
Wykorzystano systemy notacyjne Object Management Group (OMG.org). Specyfikacja MOF opisuje trzy poziomy abstrakcji: M1, M2, M3 oraz poziom M0 czyli realne rzeczy (patrz struktura poziomów abstrakcji, OMG MOF 2016). M0 to realny system, poziom M1 to abstrakcja obiektów tego systemu (jego model) . Poziom M2 to związki pomiędzy klasami tych obiektów (nazwy ich zbiorów) czyli metamodel systemu. Poziom M3 to meta-metamodel poziom opisujący metodę modelowania z użyciem nazwanych elementów o określonej semantyce i syntaktyce.
Proces analizy i projektowania został oparty na specyfikacji MDA (OMG MDA). Proces ten ma trzy fazy rozumiane jako tworzenie kolejnych modeli: CIM, PIM, PSM oraz fazę tworzenie kodu. Model CIM jest dokumentowany z użyciem notacji BPMN (OMG BPMN 2013) i SBVR (OMG SBVR 2017). Są to odpowiednio: modele procesów biznesowych oraz modele pojęciowe i reguły biznesowe. Modele PIM i PSM dokumentowane są z użyciem notacji UML (OMG UML 2017). Pomiędzy modelem CIM a PIM ma miejsce ustalenie listy usług aplikacyjnych (reakcje systemu), których mechanizm realizacji opisuje model PIM. Standardowym wzorcem używanym do modelowania architektury aplikacji jest wzorzec MVC. Komponent Model tego wzorca jest modelowany z użyciem wzorcza architektonicznego BCE.
[…]
Spis treści 1. Wprowadzenie 1 2. Metody 2 2.1. Semiotyka a UML 2 2.2. Specyfikacja MOF Poziomy abstrakcji 3 2.3. Specyfikacja MDA i model PIM 4 2.4. Wzorzec architektoniczny MVC 5 2.5. Wzorzec architektoniczny BCE 5 3. Rezultaty 6 3.1. Założenie uproszczające 6 3.2. Zintegrowany model struktury procesu projektowania aplikacji 7 4. Dyskusja 8 5. Dalsze prace 8 6. Bibliografia 9 7. Kluczowe pojęcia metodyczne 11
Cała publikacja …
Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns Jaroslaw Zelinski (Independent Researcher, Poland)
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.
Mając przed oczami kolejny projekt badawczy, kolejny raz gapię się na strony OMG i mała refleksja: porządki dobiegają końca. W artykule o UML v.2.5. wspominałem, że zrezygnowano w końcu z pojęcia „agregacji” (zwanej czasami „słabą kompozycją”), odchodzi się od całkowicie zbędnych związków „extend” i „include” w przypadkach użycia (konstrukcje te nadal pozostają w specyfikacji z uwagi na kompatybilność wstecz narzędzi CASE i dokumentów jakie w nich są nadal tworzone lub archiwizowane). Paradoksalnie specyfikacja UML jest upraszczana (stale tkwi w niej echo pierwotnego zlepku kilku notacji z lat 99-tych). Oczyma wyobraźni widzę jak ktoś, w toku prac nad UML, stale wymachuje „brzytwą Ockhama”…
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.
Regularnie obserwuję pewną trudność jaką sprawia wielu ludziom, z jednej strony stosowanie systemów notacyjnych a z drugiej samo modelowanie. Wspólną częścią obu tych obszarów jest abstrahowanie od szczegółów. Praktycznie każdy mój klient i bardzo często, analitycy i projektanci developerów realizujących projekty które nadzoruję, zadają mi pytania: a gdzie zobaczę to, że zamówienie może być dla innego produktu i innego segmentu.…. itp. Innymi słowy: na dowolnym etapie pracy padają pytania o bardzo detaliczne szczegóły konkretnych operacji. Co prawda, jak to mawiają „diabeł tkwi w szczegółach”, z czym wypada się zgodzić, ale to dokładnie ten właśnie diabeł niszczy projekty prowadząc nie raz do „utraty panowania nad szczegółowością projektu”. Dokładnie dwa lata temu opisywałem modelowanie problem detali w artykule Gdzie są te cholerne szczegóły, a kwestie zasad (reguł) działania aplikacji w niedawnym artykule Mechanizm działania. Dzisiaj będzie o modelach i abstrakcjach.
Modele a abstrakcje
Modelowanie ma dwa aspekty: projektowanie jako tworzenie modelu przyszłej (projektowanej) rzeczywistości oraz analiza jako tworzenie modelu badanej, istniejącej rzeczywistości. Model jako taki nie jest abstrakcją czegoś, jest uproszczonym obrazem lub opisem z określonej perspektywy, ale zachowującym określone cechy rzeczywistości. Model z definicji jest zawsze uproszczeniem, innymi słowy, jest pozbawiony określonych szczegółów, tych które w danym zastosowaniu modelu (kontekst) są nieistotne. Pojęcia model i abstrakcja są często mylone, bywa że stosowane zamiennie, co jest bardzo dużym błędem.
Podstawowym narzędziem analizy jest proces redukowania szczegółów, w przeciwnym wypadku pracochłonność opracowania modelu i późniejsza jego analiza, może wręcz uniemożliwić rzetelne ich przeprowadzenie, może być to nawet niewykonalne z uwagi na ich nadmierną złożoność. Słownik j. polskiego PWN podaje następujące definicje:
abstrakcja: pojęcie ogólne, niemające odpowiednika w żadnym konkretnym przedmiocie;
model: konstrukcja, schemat lub opis ukazujący działanie, budowę, cechy, zależności jakiegoś zjawiska lub obiektu;
Pomiędzy pojęciami abstrakcja i model jest pewna kluczowa różnica: abstrakcja to pojęcie zaś model to opis mechanizmu, jego konstrukcja, działanie, budowa. Prosty przykład: nazwane prostokąty na typowym diagramie struktury organizacyjnej to abstrakcje komórek organizacyjnych i osób w nich zatrudnionych, prostokąty te wraz z liniami je łączącymi stanowią, jako całość, model podległości zasobów w organizacji. Nieco ponad pół roku temu opisałem to w artykule Diagram obiektów czyli bottom-up:
Generalnie rzecz w tym, by pokazać to co wiemy czyli konkretne nazwane egzemplarze ?tych rzeczy?, o których ktoś mówi lub które obserwujemy. To egzemplarze i ich specyfikacja (nazwy, cechy itp.). Innymi słowy diagram obiektów służy do pokazania konkretnego, obserwowalnego stanu rzeczy. Jeżeli więc z jakiegoś powodu nie możemy operować uogólnieniami (klasy) bo nie posiadamy odpowiedniej wiedzy lub jest ona zbyt uboga, analizę można prowadzić ?od dołu? czyli mając szczegóły uogólniać je. Poważną zaletą tej metody jest łatwość weryfikacji modelu przez ?klienta?. Większość ludzi nie radzi sobie z abstrakcjami (np. metamodele): modele budowane z użyciem diagramów klas to uogólnienia: opisują klasy a nie konkretną rzeczywistość. Diagramy obiektów (instancje klas) to nic innego jak modele ?konkretnych sytuacji? z życia. (Źródło: Diagram Obiektów | Jarosław Żeliński IT-Consulting)
Poziomy abstrakcji w UML
Notacja UML pozwala na modelowanie na obu wyżej wymienionych poziomach. W ramach [[MOF]]/[[UML]] wyróżniamy łącznie cztery poziomy uogólnienia oznaczone od M0 do M3. M0 to świat rzeczywistych bytów. M1 to model w którym konkretne rzeczywiste byty zastępuje się ich abstrakcjami (np. nazwane prostokąty), których jest tyle ile rzeczywistych obiektów. Poziom M2 to metamodel, czyli wszystkie nazwane elementy klasyfikujemy i zastępujemy klasyfikatorami. Obiekty mające pewne ustalone wspólne cechy (całą ich grupę) zastępujemy jednym klasyfikatorem. Np. na poziomie M1 model drużyny piłkarskiej będzie zawierał 11 nazwanych obiektów (tu prostokąt to abstrakcja zawodnika). Na poziomie M2 model tej drużyny to była by już tylko klasa Zawodnik, zapewne jednym z jej atrybutów byłoby imię i nazwisko oraz numer zawodnika a drugim jego rola (bramkarz lub zawodnik w polu, to decyduje o jego zachowaniu). Na najwyższym poziomie M3 mamy tylko zdefiniowane pojęcie klasyfikatora.
Notacja UML pozwala na modelowanie (tworzenie modeli i metamodeli) na poziomach M1 i M2 (poziom M3 to definicja klasyfikatora w UML, polecam tu książkę Model-Driven Software Engineering…). Poniżej diagram obrazujący te cztery poziomy oraz taksonomie diagramów w UML 2.5 gdzie diagramy zostały skojarzone z odpowiadającymi im poziomami abstrakcji.
Poziomy modelowania (opracowanie własne Jarosław Żeliński na podstawie OMG UML 2.5 oraz OMG Meta-Object Facility (MOF))
Warto o tym pamiętać, głównie z tego powodu, że diagram klas notacji UML jest powszechnie nadużywany, wiele modeli, szczególnie dokumentujących stan faktyczny konkretnej aplikacji i wdrożenia, powinno być diagramami obiektów i wdrożenia a nie diagramami klas czy komponentów, bo te ostanie to jedynie metamodele. Warto też wiedzieć, że kod programu to metamodel tego co zostanie wytworzone w pamięci komputera (bo to jest model rzeczywostości), po uruchomieniu tego programu. W kodzie np. gry będzie klasa zawodnik, ale po uruchomieniu gry komputerowej, w pamięci będzie 11 wygenerowanych z tych klas obiektów, reprezentujących zawodników drużyny.
Na powyższym diagramie, po jego lewej stronie, pokazałem także, że projektowanie czegoś jest rozpoczynaniem pracy od tworzenia określonej abstrakcji pomysłu (z reguły obiekty a nie klasy). Analiza stanu rzeczywistego to tworzenie tej abstrakcji na bazie obserwacji analizowanej rzeczywistości.
Projekty w obszarze inżynierii oprogramowania, tworzone w duchu paradygmatu obiektowego to:
analiza rzeczywistości i zbudowanie jej obiektowej abstrakcji (diagram obiektów),
określenie, który obszar rzeczywistości zostanie zastąpiony oprogramowaniem (np. papierowe kartoteki w bibliotece),
zbudowanie metamodelu wybranego obszaru : to model dziedziny (diagram klas)
Pierwszy punkt to element analizy systemowej: tworzenie obiektowego modelu tego co jest analizowane. Podejście obiektowe do analizy i projektowania więc:
…pozwala wyjść od konkretnego rzeczywistego ?stanu świata? i opracować na jego podstawie model pojęciowy i metamodel. To bardzo pomocna technika. Warto pamiętać, że to co nie raz nazywane jest ?modelem dziedziny? jednak nim nie jest. (Źródło: Diagram Obiektów | Jarosław Żeliński IT-Consulting)
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.