(źr.: https://codersociety.com/blog/articles/contract-testing-pact)
Wprowadzenie Coraz częściej słyszę buzzword "Event-Driven Architecture". Co to jest? To założenie, że obiekty reagują i zmieniają swój stan pod wpływem zdarzeń (zmiana stanu innych obiektów) w ich otoczeniu (https://en.wikipedia.org/wiki/Event-driven_architecture). Opis w postaci prezentacji link poniżej: https://youtu.be/gOuAqRaDdHA?si=lwK0jW8ekeV_ukHa Tak więc logika "systemu" to "maszynach stanów" tych obiektów. Brzmi fajnie, nie? Dlaczego więc tak wiele projektów oprogramowania kończy się niepowodzeniem? Są to próby tworzenia aplikacji w formie dużych zespolonych maszyn stanowych, które zmieniają stan dużej bazy danych. Niestety, model ten jest najbardziej nienaturalny, ponieważ my, jako ludzie (jako firmy, jako agencje rządowe),…
Tytułowe pytanie zadałem AI (Google i Copilot) licząc na samokrytykę i autoocenę. I proszę... AI "wie" że jest tylko betoniarką! Odpowiedź jakiej udzielił Google: Mówiąc o tym, że AI „nie potrafi modelować”, zazwyczaj mamy na myśli jeden z trzech obszarów: tworzenie precyzyjnej geometrii 3D, rozumowanie przyczynowo-skutkowe lub modelowanie świata (zrozumienie fizyki i logiki rzeczywistości). Oto główne powody, dla których AI wciąż ma z tym problemy: 1. Brak zrozumienia praw fizyki Modele AI, takie jak te generujące obrazy czy tekst, opierają się na statystycznym przewidywaniu kolejnych elementów (pikseli lub słów), a…
Wprowadzenie Często jestem pytany: "Panie Jarku, czy Pan używa AI?". Tak, np. do szybkiego przeglądu publicznie dostępnych popularnych treści. Np. zadałem tytułowe Copilotowi. Tak odpowiedział: "PlantUML i Mermaid różnią się od klasycznych narzędzi CASE w celu, filozofii pracy, zakresie funkcji i miejscu w procesie inżynierskim. Najkrócej: PlantUML/Mermaid to języki do rysowania diagramów, a CASE to środowiska do projektowania systemów. PlantUML i Mermaid nie konkurują z CASE — one konkurują z Visio, Draw.io, PowerPointem. CASE to zupełnie inna liga: model-first, a nie diagram-first." (poniższy tekst wygenerowany przez Copilot w odpowiedzi na…
ERP, CRM, Inventory, problem.
https://dataedo.com/cartoon
Wprowadzenie To pytanie zadaje sobie każdy kto planuje tę inwestycję. Czy to łatwy wybór? Nie. Na początek ważny fakt: wdrożenia monolitów: Co jest powodem? Kluczowym jest architektura: relacyjne bazy danych tych systemów mają kilka tysięcy powiązanych tabel, zapytania SQL do tych tabel to setki linii kodu na każde zapytanie, a zapytań tych są setki, kod tych aplikacji jest jeszcze bardziej złożony (mowa o milionach linii kodu). Razem wygląda tak jak poniżej: Struktura monolitycznego ERP Efekt? Kastomizacja tak złożonego kodu to praktycznie pewna porażka, a niestety oferują to w zasadzie wszystkie…
Ponieważ projekty informatyczne są traktowane jako projekty technologiczne i najczęściej zlecane dostawcom technologii. To największy błąd, jaki można popełnić. W tym miejscu chciałbym zwrócić uwagę, że wymagania dzielą się na funkcjonalne i niefunkcjonalne. Wymagania niefunkcjonalne nigdy nie stanowiły problemu, ale wymagania funkcjonalne zawsze są problemem. Dlaczego więc zarządzanie projektami powierza się dostawcom technologii? Architektura korporacyjna – stary model SOA Poniższy schemat (Street, K. (2006). Budowanie architektury zorientowanej na usługi z wykorzystaniem BPM i MDA. 2(1), 8.) ilustruje kluczowe warstwy (poziomy) opisu organizacyjnego: procesy biznesowe usługi biznesowe (wymagane przez biznes) komponenty…
Zależnie od szacunków (czyli od tego jak zdefiniowano sukces) 60 - 80% projektów IT to nieudane projekty. Pod pojęciem projektu IT rozumiemy tu systemy dla firm: szeroko pojęte systemy biznesowe. Na świecie każdego dnia inicjowanych są setki tysięcy projektów IT dla firm, śladowe ilości nowych gier i w zasadzie żaden nowy system operacyjny (co najwyżej jego drobne rozszerzenia i aktualizacje). Dlatego nie ma sensu by w projektach biznesowych stosować wzorce i metody sprawdzone w tworzeniu gier czy środowisk technologicznych. Dlatego zlecanie projektów biznesowych od razu deweloperom ma bardzo nikłe szanse…
Wprowadzenie W roku 2024 pisałem: Jak widać czasami łatwo pomylić pojęcia model i mechanizm, można jednak powiedzieć, że model to schemat obrazujący coś, zaś mechanizm to wyjaśnienie zjawiska (tego jak coś powstaje jak działa). Mechanizm można zobrazować w postaci modelu. Jeżeli dążymy by model był idealizacją, to wtedy właśnie:"Modelowanie polega na abstrahowaniu od szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm." (Craver & Tabery, 2019) Patrz: Mechanizm działania vs model systemu vs diagram – Jarosław Żeliński IT-Consulting A co z komputerami…
Wprowadzenie W kwietniu 2024 roku opisywałem API Artykuł powyższy polecam osobom zainteresowanym stroną techniczną projektowania integracji i API. Dzisiaj odpowiem na problemy jakie zgłaszają prawnicy, czyli co jest przedmiotem umowy gdy przedmiotem tym jest mityczne API. (https://it-consulting.pl/2024/04/05/api-to-cos-innego-nie/) Wtedy problemem była próba traktowania oryginalnego API systemu ERP jak dedykowanej aplikacji, czy odrębnego kodu (licencja na API). Problemem jest często także poprawne nazewnictwo tego "o czym mowa", są to nieporozumienia (lub celowe działanie) wywoływane ukrywaniem architektury przez dostawcę oprogramowania. W między czasie trafiła się dzisiaj ciekawa, krótka dyskusja o API na "Anonimowy…
Wprowadzenie Aplikacje Jira i Confluence firmy Atlassian są bardzo popularne nie tylko w działach IT. Obie wspierają między innymi prace analityczne i projektowe na poziomie zadań (Jira) i treści (Confluence). Producent pakietu CASE Visual Paradigm, od wersji 17.3 wspiera integrację swojego pakietu z tymi aplikacjami, w efekcie w tych środowiskach możliwa stała się pełna integracja zespołu projektowego wykonawczego z analitykami i projektantami. Płynna integracja z Atlassian Confluence Zastosowanie: Agile Development: Udostępnianie zaktualizowanych przepływów pracy i diagramów UML w dokumentacji sprintu. Zarządzanie produktem: Osadzanie modeli procesów na stronach specyfikacji produktu. Architektura…
Wprowadzenie Czym jest dziedziczenie? Dziedziczenie umożliwia tworzenie nowych klas, które ponownie wykorzystują, rozszerzają i modyfikują zachowanie zdefiniowane w innych klasach. Klasa, której elementy są dziedziczone, nazywana jest klasą bazową, a klasa, która dziedziczy te elementy, nazywana jest klasą pochodną. Klasa pochodna może mieć tylko jedną bezpośrednią klasę bazową. Konstrukcja ta wywodzi sie z generalizacji: jej założeniem było usuwanie z kodu domniemanych redundancji na wzór pojęciowego związku generalizacji. Kluczowy problem polega na tym, że takie podejście czyni z każdej aplikacji monolit o bardzo złożonej strukturze kodu źródłowego. Problem w tym, że…
(źr.: https://www.redhat.com/en/topics/microservices/what-are-microservices)
Wprowadzenie Często spotykaną definicją mikro-serwisów jest W inżynierii oprogramowania architektura mikro-serwisów to wzorzec architektoniczny, który organizuje aplikację w zbiór luźno powiązanych, drobnoziarnistych usług, które komunikują się za pośrednictwem lekkich protokołów. Wzorzec ten charakteryzuje się możliwością niezależnego opracowywania i wdrażania usług, poprawiając modułowość, skalowalność i zdolność adaptacji. Wprowadza on jednak dodatkową złożoność, szczególnie w zarządzaniu systemami rozproszonymi i komunikacją między usługami, czyniąc początkową implementację trudniejszą w porównaniu do architektury monolitycznej. (https://en.wikipedia.org/wiki/Microservices) To samo źródło dalej: Nie istnieje jedna, powszechnie uzgodniona definicja mikro-serwisów. Ogólnie jednak charakteryzują się one skupieniem na modułowości, a…
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…
