UML – Jarosław Żeliński IT-Consulting

Jak udokumentować istniejący monolit

Post author:Jarosław Żeliński
Post published:27 kwietnia 2025
Post category:Analizy biznesowa i projektowanie oprogramowania Przykładowe projekty
Post last modified:27 kwietnia 2025

Wprowadzenie Oprogramowanie na obecnym rynku, w ogromnej ilości, nadal stanowią produkty powstałe ponad dwie dekady temu. Znakomita większość powstawała ewolucyjnie. Lata 90-te to bardzo często monolity budowane w oparciu o EJB, JavaEE i nieco później Microsoft .NET. Są to wzorce powstała na bazie relacyjnego modelu danych i skryptów transakcyjnych. "W anemicznym projekcie domeny logika biznesowa jest zwykle implementowana w oddzielnych klasach, które przekształcają stan obiektów domeny. Fowler nazywa takie zewnętrzne klasy skryptami transakcyjnymi. Ten wzorzec jest powszechnym podejściem w aplikacjach Java, wspieranym przez technologie takie jak wczesne wersje Entity Beans…

Czytaj dalej

Modelowanie struktury organizacyjnej – po 12 latach

Post author:Jarosław Żeliński
Post published:13 lutego 2025
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:15 marca 2025

Wprowadzenie W roku 2013 pisałem: Pisząc recenzję książki Modelowanie biznesowe napisałem, że kompletny model organizacji to: słownik pojęć (Glossary), model struktury organizacyjnej, reguły biznesowe (specyfikacja) oraz model procesów biznesowych korzystający z trzech poprzednich. Całość stanowi dopiero kompletny model organizacji. W Listopadzie ubiegłego roku także pisałem o modelowaniu struktury organizacyjnej. Osobiście uważam, że modelowanie struktury organizacyjnej w UML nie jest dobrym pomysłem. Są do tego prostsze narzędzia, nie przypadkiem te lepsze narzędzia CASE mają do tego dedykowany diagram. Niestety nie ma tu dedykowanej notacji, dlatego bardzo ważne jest by słownik pojęć w modelu zawierał…

Czytaj dalej

Architektura C4

Post author:Jarosław Żeliński
Post published:12 lutego 2025
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:8 kwietnia 2025

Wprowadzenie

Wpis na LinkedIn:

GUI czy DSL, klikanie czy tekst? Co wybierzesz do modelowania?
Structurizr ma swój DSL, za pomocą którego opisywana jest architektura a następnie generowane są odpowiednie widoki C4. Text to Model.
Z drugiej strony możemy zamodelować strukturę bazy danych w LucidChart albo Miro klikając w GUI. Click to Model.
Jeśli mógłbyś wybrać, to którą z tych opcji preferowałbyś do modelowania i dlaczego?
Jako devsi jesteśmy przyzwyczajeni do kodowania, stąd DLS structurizra jest dla nas czymś naturalnym. Jedynym problemem jest to, że trzeba się go nauczyć. Tego problemu nie ma w przypadku GUI. Ale znowu GUI cierpi z UX gdy dodawane są kontrolki manipulujące elementami (dodaj, usuń, zmień nazwę).
Ja osobiście wolę DSL nawet jeśli potrzebuje czasu by się go nauczyć, ze względu na prostotę podglądu wygenerowanego na podstawie tekstu.
(link do źródła)

Deweloperzy często deklarują: “my wszystko dokumentujemy w modelach C4 a nie w UML, którego deweloper nie używa!” Problem? Modele C4 nie są dokumentacją działania aplikacji, są jedynie opisem jej instalacji. Sam autor (Simon Brown) w swoich publikacjach zaleca dodatkowo UML i ER by udokumentować realizowaną logikę.

(więcej…)

Czytaj dalej

Sprzęt, środowisko, aplikacja, mechanizm

Post author:Jarosław Żeliński
Post published:20 listopada 2024
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:26 listopada 2024

Wprowadzenie Bardzo często można w książkach i na blogach spotkać opisy wzorców architektonicznych, wzorców projektowych, dobrych praktyk. Jednak bardzo rzadko autorzy piszą o tym kiedy je stosować. Sam fakt, że jakiś wzorzec "rozwiązuje jakiś problem", co jest celem tworzenia i stosowania danego wzorca, nie mówi nic o tym jak często i kiedy dany problem się pojawia. Komputer może być częścią firmy, samochodu, lodówki, telewizora, może być platformą dla oprogramowania użytkowego albo dla gier komputerowych, ale te - użyte - staja sie częścią tego komputera (gramy na komputerze a nie na…

Czytaj dalej

Wprowadzenie do modelowania w języku UML czyli dramat Polskiej Nauki

Post author:Jarosław Żeliński
Post published:19 listopada 2024
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:11 stycznia 2025

Wprowadzenie Stale śledzę to co świat nazywa "publikacje naukowe". Niestety notuje powolny upadek nauki, w już w branży informatyki postęp tego upadku jest chyba najszybszy. Regularnie czytam, że w Internecie jest łatwy dostęp do dobrej darmowej wiedzy i publikacji naukowych. Popatrzmy co znalazłem: Szynalski, K., & Różański, D. (2022). Wprowadzenie do modelowania w języku UML. Biuletyn Naukowy Wrocławskiej Wyższej Szkoły Informatyki Stosowanej. Informatyka, 9(1), 31–37. https://bibliotekanauki.pl/articles/2146699.pdf To nie tylko "Darmowa wiedza w Internecie" to "publikacje naukowe", a Panowie autorzy pewnie się (mam nadzieję, że nie) doktoryzują (pozakładali sobie numery ORCID).…

Czytaj dalej

Diagramy klas UML wg. p-programowanie.pl

Post author:Jarosław Żeliński
Post published:29 października 2024
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:9 grudnia 2024

Wprowadzenie Od czasu do czasu dostaję emaile rozpoczynające się od słów: "A tu programista i pisze inaczej". Tym razem dostałem od czytelnika link do tekstu Diagramy klas UML https://web.archive.org/web/20240428033730/https://www.p-programowanie.pl/uml/diagramy-klas-uml). Artykuł ten w zasadzie w całości jest lawiną nieprawdy o UML. Odniosę się do części dotyczącej notacji UML i powiązanych z nią fałszywych treści. Wszystkie cytaty pochodzą z ww. artykułu (inne oznaczono, źródłami). Recenzja Artykuł jest datowany na 30 września 2022. Aktualna wersja notacji UML 2.5.1 pochodzi z Grudnia 2017 roku, kluczowe zmiany: rezygnacja z podziału na Superstructure i Infrastructure, usunięcie…

Czytaj dalej

architektura systemu workflow

Projektowanie czyli architektura kodu aplikacji c.d.

Post author:Jarosław Żeliński
Post published:29 września 2024
Post category:Analizy biznesowa i projektowanie oprogramowania Referaty z konferencji
Post last modified:15 marca 2025

Wprowadzenie

W 2017 roku napisałem referat na pewną konferencję naukową studentów. Artykuł dotyczył architektury kodu. Jedną z ilustracji była ta:

Artykuł kończyłem słowami:

Nie chodzi więc o to by podzielić oprogramowanie na “składowe, które łączą w sobie możliwość przechowywania danych oraz wykonywania operacji”. Chodzi o to by mechanizm, o dowiedzionej poprawności, zaimplementować w określonej wybranej technologii.Chodzi też o to by nie udawać, że programowanie jako “podzielone na obiekty” partie kodu, nadal korzystające z jednej wspólnej bazy danych, różni się czymkolwiek od “strukturalnego kodu”. Chodzi o to by kod programu faktycznie implementował określony (zbadany i opisany) mechanizm. (źr.: Architektura kodu aplikacji jako pierwszy etap tworzenia oprogramowania – Jarosław Żeliński IT-Consulting)

W 2021 roku opisałem Architektoniczne wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu. Artykuł jest ukierunkowany na ich definicje i modelowanie. Tu kilka słów na temat tego “skąd się biorą i po co”.

(więcej…)

Czytaj dalej

Webhook – zwrotne wywołania API

Post author:Jarosław Żeliński
Post published:26 lipca 2024
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:28 lipca 2024

Wprowadzenie Swego czasu opisywałem wzorce projektowe i API (Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy). Kluczowym wzorcem jest wzorzec SAGA, czyli sterowanie sekwencją wymiany danych z jednego miejsca. Wzorzec ten to typowy system klient-serwer (usługobiorca-usługodawca) i sprawdza się doskonale, gdy sterowanie z jednego miejsca rozwiązuje wszystkie problemy integracji. Pewnym problem jest tu jednak to, że serwer musi zostać odpytany by klient poznał jego stan, a nie zawsze jest to wystarczające. Opis problemu Wyobraźmy sobie, że mamy system WMS (ang. Warehouse Managements System, zarządzanie magazynami) oraz…

Czytaj dalej

Depozyt kodu źródłowego czyli co naprawdę należy chronić? Archiwum!

Post author:Jarosław Żeliński
Post published:13 kwietnia 2024
Post category:Prawo autorskie i know-how
Post last modified:15 stycznia 2025

Wprowadzenie W 2021 roku, w artykule Transformacja Cyfrowa a dziedzictwo IT pisałem: Aby transformacja cyfrowa była w ogóle możliwa, musimy przenieść te dane (treści, informacje) z papieru „do komputera”, w sposób nieniszczący obecnych możliwości i pozwalający na tworzenie nowych. Trzeba też zniwelować posiadany dług technologiczny. Dług technologiczny to posiadane dziedzictwo, to zapóźnienie, to pozostawanie w tyle za trwającym postępem technologicznym. Dług taki ma bardzo wiele firm https://it-consulting.pl/2021/11/21/cyfrowa-transformacja-a-dziedzictwo-it/ W tym tekście poruszam pokrewny temat jakim jest zabezpieczenie się bo kluczowe pytanie brzmi: co zabezpieczyć mają "wszystko w wersji elektronicznej"? Bardzo często…

Czytaj dalej

Mechanizm działania vs model systemu vs diagram

Post author:Jarosław Żeliński
Post published:12 marca 2024
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:30 października 2024

Wprowadzenie Najczęściej w toku analiz posługujemy się pojęciem model, rzadziej mechanizm. Rzecz w tym, że pojęcie mechanizm pojawia się gdy chcemy coś wyjaśnić, np. "mechanizm generowania upustu na fakturze". Ale tu uwaga! Model (schematy blokowe, wzory itp.) to dokumentacja, opis chroniony prawem autorskim. Mechanizm to to, co zrozumieliśmy czytając te dokumentację (model), bo mechanizm to chronione know-how. Treść wniosku do Urzędu Patentowego to model (opis), ale to co patentujemy to wymyślony/opracowany mechanizm. Mechanizm a model Mechanizm i model w nauce to bliskie sobie pojęcia, np. tak opisywane: Modelowanie polega na…

Czytaj dalej

Ile scenariuszy ma Use Case i dlaczego nie jeden?

Post author:Jarosław Żeliński
Post published:12 lutego 2024
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:12 lutego 2024

Wprowadzenie Bardzo często na szkoleniach, a także na zajęciach laboratoryjnych z przedmiotu Inżynieria oprogramowania, jestem pytany o przypadki użycia i ich scenariusze. Szczególnie często pada pytanie czy przypadek użycie reprezentuje tylko jeden scenariusz. Przypadki użycia w UML to "dzieło" Ivara Jacobsona . Pierwotnie było to narzędzie do opisu zewnętrznych cech (zachowań) systemu, rozumianych jako jego oczekiwane zachowania, czyli wymagania wobec systemu. Był to tak zwany "opis czarnej skrzynki". Problemem było to, że "czarna skrzynka" mówi CO ale nie mówi JAK. Jacobson opisywał przypadki użycia z pomocą warunków (stanów początkowego i…

Czytaj dalej

Wzorzec MVC – dyskusja c.d.

Post author:Jarosław Żeliński
Post published:25 stycznia 2024
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:20 stycznia 2025

Wprowadzenie Wzorzec ten budzi wiele kontrowersji co do tego czym są te trzy komponenty. Popatrzmy do anglojęzycznej WIKI: Model - Centralny komponent wzorca. Jest to dynamiczna struktura danych aplikacji, niezależna od interfejsu użytkownika. Bezpośrednio zarządza danymi, logiką i regułami aplikacji. W Smalltalk-80, model jest całkowicie pozostawiony programiście. W WebObjects, Rails i Django, model zazwyczaj reprezentuje tabelę w bazie danych aplikacji. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Jest to dominująca definicja w literaturze, zaś spory o to czym jest Model w architekturze MVC jak widać mają jedno główne źródło: jakiego frameworka używa osoba wchodząca w takie…

Czytaj dalej

Koniec treści

Nie ma więcej stron do załadowania

Starsze wpisy