Tym razem krótki artykuł na temat pewnej ciekawej konstrukcji. Została ona opisana przez Rebekę Wirfs-Brock w 1999 roku . Pomysł nie zdobył sobie wtedy raczej zbyt dużej popularności, jednak obecnie, w dobie wzorców opartych o mikroserwisy i mikro aplikacje, ma szansę wrócić do łask. Ja stosuję go już od dłuższego czasu (patrz: projektowanie zorientowane na interfejsy). Skróty HLD i LLD to odpowiednio: High-Level Design (projekt wysokiego poziomu) i Low-Level Design (projekt niskiego poziomu). Są to poziomy abstrakcji w modelu PIM. Jest to także opis stylu projektowania architektury systemu zorientowanego na interfejsy (architektura zorientowana na interfejsy).
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.
Lektura na Nowy Rok… Co prawda wydana w 2007 roku, ale właśnie sobie o niej przypomniałem..
Ta książka Yourdona leży u mnie na półce niemalże od dnia jej wydania, gdy ją przypadkiem upolowałem, zaraz po jej ukazaniu się w księgarniach. Napisanie o niej odkładam od lat, bo praktycznie nie ma tam obrazków UML, opisów wzorców itp.. Od jej przeczytania mówię sobie: jutro o niej napiszę… i to trwało do tego momentu.
To książka w całości napisana prozą, bez obrazków, w której autor dzieli sie swoimi przemyśleniami na temat architektury systemów, ich projektowania i tym co z tego wynika.
Bardzo ciekawie pisze o tym, czym jest złożoność oprogramowania, o tym, że złożoność systemu to stopień komplikacji modelu dziedzinowego a nie „całego systemu”. Typowy system (tu aplikacja dla biznesu) składa się w ponad 90% z bibliotek, z których niewątpliwie trzeba umieć zbudować środowisko aplikacji, jednak to nie one decydują o tym do czego służy ten system i czy w ogóle komukolwiek do czegoś służy… Z bibliotek, na które nie mamy wpływu, ale musimy (chcemy) ich użyć.
Jaki to jest skomplikowany system? Ile ma klas/komponentów by uznać go za złożony? Gdzie jest granica złożoności małej i dużej? Czym jest architektura i po co ona nam? O tym tu przeczytacie.
Polecam tę książkę każdemu, kto ma ambicję projektować architekturę systemów biznesowych. Uczy pokory. Zwracam tu uwagę, że osoba mówiąca o sobie „analityk biznesowy”, którego produktem pracy mają być „wymagania na oprogramowanie”, to nie zbieracz notatek a projektant . Albo niech zmieni zawód..
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.
Tym razem o czymś co potrafi zabić 😉 czyli czym jest dokument oraz fakt i obiekt. Czym się różni zakup kilku produktów, w tym samym sklepie, w np. godzinnych odstępach czasu, od zakupu wszystkich razem? Poza formą udokumentowania, niczym: w sklepie to samo i tyle samo zeszło ze stanu magazynu, a my wydaliśmy w obu przypadkach tyle samo pieniędzy (o promocjach później)! W pierwszym przypadku mamy kilka faktów zakupu, w drugim, jeden, ale zawsze tyle samo obiektów (produkt). Faktura (paragon) to dokument opisjący fakt, przedmiot sprzedaży jest obiektem. Tu obiektem jest opisywany przedmiot zakupu. Ten artykuł to przykład architektury usługi aplikacji, która jest nieczuła na takie różnice.
Wprowadzenie
Żeby uporządkować treść, w stosunku to architektury aplikacji tu nie będę używał pojęć „klasa i obiekt” a komponent i dokument. Pojęcia obiekt i fakt tu będą dotyczyły świata realnego, to odpowiednio: opisywany przedmiot i zdarzenie z nim powiązane. Innymi słowy: dokument może opisywać obiekt lub zdarzenie z nim powiązane. Np. produkt oraz fakt jego sprzedania (dwa byty: separowanie kontekstu dokumentów). Konkretne oprogramowanie jako system, to komponenty (w UML obiekty określonej klasy) oraz dane zorganizowane np. jako dokumenty (dokument: nazwana, określona struktura danych). Aplikacje przetwarzają dane opisujące realny świat, co ładnie pokazał i opisał Smith :
Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512
Projektowanie oprogramowania to tworzenie jego modelu, potem pozostaje już tylko jego implementacja. Obecnie prace projektowe i przygotowanie do implementacji także są zaliczane do „programowania” .
Projekt systemu sprzedaży
Każda analiza powinna być oparta na ontologii z dziedziny problemu. Dzięki czemu nazwy dokumentów, atrybutów i ich wartości będą spójne, jednoznaczne i niesprzeczne. Poniżej prosty model pojęciowy dla dziedziny opisywanego tu problemu:
Model pojęciowy (diagram faktów SBVR lub model pojęciowy, diagram klas UML)
(UWAGA! Powyższy model nie jest żadnym „modelem dziedziny” ani „modelem danych”. To model pojęciowy).
Modele pojęciowe służą do zarządzania systemem pojęć (ontologia) dla danego modelu oprogramowania. Testowanie tego modelu polega na sprawdzeniu czy każda para połączonych semantycznie pojęć tworzy poprawne i prawdziwe(!) zdanie w języku naturalnym (tu musimy brać poprawkę na fleksję języka polskiego), np. «sprzedający wystawia fakturę» (fakt) lub «faktura jest dokumentem» (typ).
Oprogramowanie służy do przetwarzania danych, dlatego warto opisać jak się to odbywa. Bardzo wygodną metodą projektowania struktur danych dokumenty (w tym opisie diagram struktur złożonych notacji UML). Po pierwsze są one zrozumiałe dla przyszłego użytkownika, po drugie metoda ta pozwala uwolnić się od wad modeli relacyjnych: usunięcie redundancji nazw co prowadzi do utraty ich kontekstu. Dokumenty często mają różny kontekst, znaczenie pojęć zależy od kontekstu. Relacyjny model danych, pozbawiony redundancji, jest stratny: utrwalone dane nie stanowią żadnej informacji a dokumentem jest dopiero wynik zapytania SQL do tabel.
W przypadku opisywanego tu projektu wygląda to tak:
Struktury danych zorganizowanych w dokumenty (notacja UML)
Mamy tu dwa dokumenty: Oferta i Faktura. Pojęcie Produkt ma swoją definicję realna (definicja atrybutowa: poprzez cechy): jest to „cos co ma nazwę, cenę i ilość”. Atrybuty Produktu na dokumentach przyjmują wartości opisane tym typem. Po drugie dokument niesie kontekst więc nadaje nazwie znaczenie: np. data to data faktury i data oferty. To nie są te same daty, a produkt oferowany (jako atrybut oferty) nie musi być tym samym produktem sprzedanym (jako atrybut Faktury).
Poniżej, na diagramie sekwencji, widać, że dla komponentu zarządzającego stanami magazynowymi nie ma żadnego znaczenia ile jest (było) faktur, operacje zmiany ilości to pojedyncze operacje. Tak zaprojektowana aplikacja jest odporna na to ile produktów jest na ofercie i fakturze, mogą to być różne ilości. Oba te dokumenty: oferta i faktura, to całkowicie odrębne konstrukcje, to dokumenty rządzące się każdy inną logiką i mające każdy inny cykl życia (tu np. Oferta nie jest utrwalana). Często stosowane konstrukcje, takie jak „dziedziczenie faktury i oferty po dokumencie” są tu najgorszym pomysłem.
Architektura. Nasza aplikacja to kilka współpracujących komponentów:
Obiektowy (komponentowy) model dziedziny.
Klasy oznaczone stereotypem «Document» to ciągi znaków (np. XML) stanowiące wartości atrybutów i parametry wywołań operacji. (w UML: ?Document? A human-readable file. Subclass of ?File?. )
Model architektury to statyczny model, a ten może być niezrozumiały, dlatego zawsze wzbogacamy projekt techniczny architektury modelem dynamiki systemu: diagramem sekwencji. Diagram taki powinien powstać dla każdej usługi aplikacji (przypadku użycia):
Powyższy diagram pokazuje współpracę komponentów, opisane wcześniej dokumenty są wartościami atrybutów i parametrami wywoływanych operacji i ich odpowiedzi. Powyższa architektura z powodzeniem wykona także usługi wglądu do historycznych faktur czy aktualizację cennika.
Poprawna obiektowa architektura i kompletny projekt techniczny aplikacji (model PIM) opisuje precyzyjnie jak wykonać implementacje i nie zawiera projektu żadnej bazy danych, ani tym bardziej zapytań SQL. Implementacja utrwalania nie może mieć wpływu na logikę biznesową systemu ani nawet zawierać jej!
Samo opracowanie relacyjnego modelu danych oraz zapytań SQL, by generować powyższe dokumenty z wariantami dotyczącymi różnych ilości oferowanych i zamawianych, zajmie kilkakrotnie więcej czasu niż opracowanie powyższego, gotowego do implementacji, projektu. Opracowanie modelu relacyjnego bazy danych, wymagało by dodatkowo wiedzy o wszystkich pozostałych dokumentach w tym systemie, a tego z reguły nigdy nie wiemy na początku!
Powyższy model to w pełni współpracujące obiekty mające operacje, a podstawowym związkiem modelu obiektowego jest związek użycia (wywołania operacji), czyli nie jest to tak zwany anemiczny model dziedziny.
Tu także warto zwrócić uwagę na kolejny częsty błąd i antywzorzec w projektach deklarowanych jako obiektowe: stosowanie dziedziczenia. Jest to mieszanie modeli pojęciowych i architektury (dziedziczenie, jako współdzielenie, łamie podstawową zasadę paradygmatu obiektowego jaką jest hermetyzacja). Dlatego model pojęciowy i model architektury to z zasady dwa odrębne modele z powodów jak wyżej opisane.
Modelowanie architektury systemu
Podsumowanie
Powyższy opis to krótki ale praktycznie kompletny Opis Techniczny Oprogramowania. Wymaga niewielkich uzupełnień (ewentualne schematy opisujące metody operacji). Wykonanie implementacji na jego podstawie nie powinno sprawić problemu osobie radzącej sobie z czytaniem notacji UML. Projekt jest na tyle precyzyjny, że stanowi utwór w rozumieniu prawa autorskiego (programista nie ma tu żadnej swobody decyzji w pisaniu kodu dla tej części). Projekt taki to także opis określonego mechanizmu działania, zawiera więc opis know-how i jako jego udokumentowana forma chroni to know-how (ustawa o przeciwdziałaniu nieuczciwej konkurencji).
Dlatego każdy program komputerowy napisany na podstawie takiej dokumentacji, z zasady jest utworem zależnym. Developer ma prawa autorskie osobiste do kodu jaki napisze, ale nie ma prawa do dysponowania tym kodem: ma je posiadacz praw majątkowych do projektu, który jest tu utworem pierwotnym. Jedyny wybór jaki ma tu developer to wybór technologii jakiej użyje.
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.
W artykule Ile przypadków użycia opisałem przypadki użycia jako narzędzie definiowania zakresu projektu, czyli sposób dokumentowania wymagań. Takie jego zastosowanie jest zdefiniowane w specyfikacji UML .
Tym razem chcę ostrzec przed bezkrytycznym „uczeniem się” ze stron internetowych, nawet tych uznawanych powszechnie za „dobre i popularne”. Sam niektóre z nich polecam, ale coraz częściej, nie całe serwisy jako takie, a tylko określone artykuły. Modernanalyst.com też do nich należy. Dziś będzie to artykuł, którego nie polecam, a opiszę go, bo autor powiela w nim dość powszechne błędy notacyjne, błędy które stały się „kanonem” dla wielu autorów stosujących UML.
Poniżej diagram przypadków użycia ze związkami «include» i «extend».
W UML zależności «include» i «extend» są reliktem analizy strukturalnej (diagramy przypadków użycia wymyślono w latach 80-tych). Związek «include» służy do wyłączania części wspólnej zachowań (scenariuszy) przypadków użycia, w konsekwencji: (1) muszą być co najmniej dwa bazowe przypadki użycia by można było mówić o części wspólnej, (2) część wspólna jest jedynie fragmentem, więc sama (samodzielnie) jako taka do niczego nie służy, więc nie wolno z nią łączyć żadnego aktora . Powyższy rysunek łamie obie te zasady. Zależność «extend», to zawarte w przypadku użycia, warunkowe rozszerzenie określonego zachowania i obligatoryjne jest podanie warunku (zdarzenia) uruchamiającego to dodatkowe zachowanie . Tu także tę zasadę złamano.
A gdy projekt jest „obiektowy”? Specyfikacja UML jasno mówi: Use Case define the offered Behaviors of the subject without reference to its internal structure . Tak więc tych związków po prostu nie używamy w projektach, o których mówimy, że są obiektowe, bo łamią podstawową zasadę paradygmatu obiektowego jaką jest hermetyzacja.
Kolejne nadużycie to stosowanie generalizacji na diagramie przypadków użycia: nie jest przewidziana dla tego diagramu (a dziedziczenie zostało słusznie z UML usunięte w 2015 roku wraz z opublikowaniem wersji 2.5 UML). Zachowania systemu to określone odrębne (hermetyzacja) elementy, tu także obowiązuje zasada nie stosowania diagramu UML do opisu architektury systemu/kodu. Po drugie, nawet gdyby autor miał na myśli stare „dziedziczenie”, to co do zasady nie łączymy aktorów z elementami abstrakcyjnymi modelu („wołanie przodka” to dawno temu opisany antywzorzec obiektowy).
Poniżej diagram profilu UML definiujący pojęcie przypadek użycia (sprawne korzystanie z notacji UML wymaga umiejętności czytania tego diagramu). I cóż my tu mamy? Należy to interpretować tak: związki «extend» i «include» to integralne części ich przypadków użycia, są to związki skierowane, przypadek rozszerzany MUSI mieć punkt rozszerzenia (rozszerzający). Nie ma tu w ogóle możliwości użycia generalizacji między elementami na tym diagramie.
Data publikacji tego artykułu: 5 styczeń 2020, czyli jego autor pisał to pięć lat po publikacji UML v.2.5! Zaś, miejsce publikacji tego tekstu to zacny serwis Modern Analyst:
What can Modern Analyst do for YOU? Let Modern Analyst help you gain an edge over your competition!Whether you are a training provider, an experienced practitioner, a tool vendor, or a recruiter focusing on business systems analysis, make Modern Analyst work for YOU. (źr.: What can Modern Analyst do for YOU?)
Autor sam o sobie:
Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP?) by the Project Management Institute (PMI?), a Certified Business Analysis Professional (CBAP?) by the International Institute of Business Analysis (IIBA?), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance. He holds an Advanced Master’s Certificate in Project Management and a Business Analyst Certification (CBA?) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF).
Nie rzadko słyszę, że „ale ten diagram ma pokazać jak system działa”. Niestety ten diagram nie służy do „pokazania” (dokumentowania) tego, jak działa aplikacja. Do tego służą inne diagramy (oznaczone na poniższym schemacie blokowym, diagramy aktywności służą obecnie do modelowania kodu wiec nie są używane na etapie analizy i projektowania, lub tylko do dokumentacji algorytmów) . Jest to – diagram przypadków użycia – od 2015 roku, diagram pomocniczy, służący wyłącznie do określenia zakresu projektu, czyli wymagań. Autorzy specyfikacji piszą: „Use Case are a means to capture the requirements of systems, i.e. what systems are supposed to do” (Przypadek użycia jest sposobem na uchwycenie wymagań na systemy, tj. tego CO systemy mają zrobić [dla aktora, a nie JAK]).
Często słyszę zarzuty, że „diagramy UML i dokumenty je zawierające, nie pomagają developerom, dlatego nie używamy UML”. No cóż, ale diagramy, jak ten tu opisany, i nie raz jak te na stronach Wikipedii czy Stackoverflow, prezentują podobny poziom, i faktycznie nie są przydatne… A stosowanie diagramów przypadków użycia do opisu „procesów” (łańcuchy «extend» i «include») to wręcz epidemia.. ;). Przypominam także, że logowanie to nie przypadek użycia (use case) aplikacji, a funkcjonalność środowiska aplikacji (są też inne metody uwierzytelniania użytkownika).
Dlatego polecam źródła rzetelnej wiedzy o notacjach, a są to oryginalne specyfikacje, których umiejętność czytania jest podstawową umiejętnością dobrego analityka i projektanta. Tu nie chodzi o „głupie bycie ortodoksem”, chodzi o JEDNOZNACZNOŚĆ dokumentacji, czyli i autor dokumentu i jego adresat, powinni używać tego samego „kodu”, czyli stosować się do specyfikacji używanej notacji. Bez tego mamy wyłącznie nieporozumienia i dodatkowe koszty w projektach.
W rankingach przyczyn porażek projektów, niejednoznaczność dokumentacji zawsze jest w pierwszej trójce.
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.
„Chmura obliczeniowa szturmem zdobywa rynek IT. Liczba wdrożeń oprogramowania w modelu SaaS rośnie w tempie 20,1 proc. rdr ? podają analitycy z firmy Gartner. Na naszych oczach odbywa się rewolucja, której największą ofiarą jest oprogramowanie instalowane na własnej, firmowej infrastrukturze. Agonię wdrożeń ?on-premises? wieści Eric Kimberling, partner zarządzający w firmie doradczej Panorama Consulting. Jego zdaniem chmura obliczeniowa posiada tak wiele zalet, że porzucenie przez przedsiębiorstwa rozwiązań stacjonarnych jest jedynie kwestią czasu.”
Źródło: Chmura wykończy wdrożenia ?on-premises?. Ich śmierć ma być powolna, ale definitywna ? Fintek.pl
Po pierwsze: to, że dzisiaj rośnie 20,1% rdr nie znaczy (ehh, ta wiara w trendy..), że tak będzie zawsze. Po drugie, nie tylko z uwagi na prawa autorskie i ochronę know-how, zawsze będzie klasa systemów, które w chmurze nigdy nie wylądują. Ten artykuł w moich oczach, to klasyka PR-owców tworząca sztuczną rzeczywistość w mediach i tak zwane „samospełniające się przepowiednie”, bazujące w 100% na konformizmie czytelników takich prognoz.
Swego czasu, 2016 rok, miałem referat na konferencji dotyczącej architektury w chmurze. Kilka tez, które pomogą ocenić wróżby upadku wdrożeń „u siebie”.
Każdy projekt wdrożeniowe ma dwa kluczowe, oczywiste, parametry: czas wdrożenia i łączny koszt (pozyskanie i posiadanie – utrzymanie). Jednak w dobie zmienności rynku jaką mamy obecnie, warto brać pod uwagę także ryzyko tego, że zmienimy decyzję bo zmieniły się warunki. Dlatego pojawia się parametr jakim jest czas wyjścia z inwestycji, co staje się coraz ważniejszym parametrem, z uwagi na ryzyko takich wdrożeń i ryzyko wynikające ze zmienności rynku.
Co wiemy o wdrożeniach?
Pomijając, detaliczne kwoty, własna instalacja jest najtańsza w utrzymaniu jednak trzeba ponieść relatywnie duże koszty pozyskania i wdrożenia. Na przeciwnym końcu jest typowa instalacja w tak zwanej chmurze, która nie wymaga praktycznie żadnego okresu „rozruchu”. Po środku jest outsourcing, który ma niższe koszty inicjacji w porównaniu z instalacją na właność, ale wyższe koszty utrzymania (marża na zasoby ludzkie).
Na tym tle mamy typowe, dla obecnego rynku, wymagania biznesowe:
Nazwałem je „implikujące zastosowanie chmury”, bo jak widać są to dość typowe wymagania w dobie szybkiej zmienności otoczenia rynkowego. Jednak jest pewien haczyk: wszystko w chmurze to najkosztowniejsza w utrzymaniu wersja. Dlatego firmy, po ustaleniu tego co jest taktyką a co strategią, powinny rozważyć decyzję: odpowiednio co powinno dać się szybko zmienić, a co będzie jednak stałym zasobem. Zasoby uznane za stałe bezpiecznie (jako inwestycje) można pozyskać na własność co w dłuższej perspektywie daje odczuwalne oszczędności. Tam gdzie ryzyko zmiany jest zbyt duże, ponosimy wyższe koszty chmury ale rekompensujemy sobie to tym, że koszty wyjścia z takiej inwestycji są bliskie zera.
Na zakończenie kilka słów o architekturze. Warto pamiętać, że – pomijając proporcje – każda firma ma oprogramowanie u siebie i może mieć w chmurze, w efekcie ich integracja zawsze wymaga, by podejmowanie decyzji o korzystaniu z chmury, było w pełni świadome. Każda decyzja architektoniczna na swoje konsekwencje.
Dlatego, moim zdaniem, nie grozi nam jednak nigdy całkowita rezygnacja z oprogramowania na własność.
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.