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

Makiety interfejsu użytkownika jako wstępny projekt

Post author:Jarosław Żeliński
Post published:4 sierpnia 2025
Post category:Analizy biznesowa i projektowanie oprogramowania Załącznik video
Post comments:0 Komentarzy
Post last modified:4 sierpnia 2025

Wprowadzenie W marcu 2021 w artykule Struktury formularzy jako forma wyrażania wymagań skupiłem się na detalach treści formularzy ekranowych, jako elementach specyfikowania przypadków użycia. Artykuł ten sprowokował pytania o związki między formularzami, ich przepływy oraz niekończące się pytania o cel stosowania związków extend i include używane często niepoprawnie w celu pokazania "przepływu ekranów". Dlatego napisałem post będący rodzajem kontynuacji tego tekstu. W toku analizy biznesowej, a potem projektowania oprogramowania, powstają różne produkty: modele procesów biznesowych, modele architektury systemów, scenariusze integracji, definicje interfejsów, i inne. Większość ich jest niezrozumiała dla przeciętnego…

Czytaj dalej

Aplikacja i jej środowisko

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

Wprowadzenie Bardzo wiele emocji budzą kwestie styku aplikacji i jej środowiska: mój wpis na LinkedIn "Czy logowanie jest przypadkiem użycia" wzbudził burzliwą dyskusję i wiele kontrowersji. Ten artykuł to opis modelu aplikacji i jej środowiska. Kluczowe pojęcia Pojęcie aplikacja jest definiowane (SJP) jako "komputerowy program użytkowy". Biorąc pod uwagę fakt, że słownikowo "użytkownik" to osoba (użytkownik - osoba lub instytucja użytkująca coś, SJP), aplikacja to "program użytkowy dla człowieka". W specyfikacji notacji UML czytamy: Przypadki Użycia są środkiem do uchwycenia wymagań systemów, tj. tego, co systemy mają robić. Kluczowymi pojęciamiw…

Czytaj dalej

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:9 lipca 2025

Wprowadzenie Oprogramowanie na obecnym rynku, w ogromnej ilości, nadal stanowią produkty powstałe ponad dwie dekady temu (legacy systems). 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…

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:2 maja 2025

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:29 czerwca 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 i dokumentację.

Post author:Jarosław Żeliński
Post published:13 kwietnia 2024
Post category:Prawo autorskie i know-how
Post last modified:4 maja 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

Koniec treści

Nie ma więcej stron do załadowania

Starsze wpisy