Sprzęt, środowisko, aplikacja, mechanizm

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 dalejSprzęt, środowisko, aplikacja, mechanizm

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

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 dalejWprowadzenie do modelowania w języku UML czyli dramat Polskiej Nauki

Diagramy klas UML wg. p-programowanie.pl

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 dalejDiagramy klas UML wg. p-programowanie.pl
Read more about the article Projektowanie czyli architektura kodu aplikacji c.d.
architektura systemu workflow

Projektowanie czyli architektura kodu aplikacji c.d.

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 dalejProjektowanie czyli architektura kodu aplikacji c.d.

Webhook – zwrotne wywołania API

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 dalejWebhook – zwrotne wywołania API

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

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 dalejDepozyt kodu źródłowego czyli co naprawdę należy chronić? Archiwum!

Mechanizm działania vs model systemu vs diagram

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 dalejMechanizm działania vs model systemu vs diagram

Ile scenariuszy ma Use Case i dlaczego nie jeden?

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 dalejIle scenariuszy ma Use Case i dlaczego nie jeden?

Wzorzec MVC – dyskusja c.d.

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 dalejWzorzec MVC – dyskusja c.d.

Model UML i stereotypy jako ikony

Wprowadzenie Modele UML są często postrzegane jako niezrozumiałe diagramy. Do napisania tego artykułu skłonił mnie pewien wpis na LinkedIn, w którym pokazano ciekawy schemat blokowy: źr.: Marcel van Oost, LinkedIn, https://www.linkedin.com/posts/marcelvanoost_fintech-payments-paytech-activity-7085945466286153728-GEgt Nie tylko moim zdaniem jest to bardzo obrazowe pokazanie tego jak działają te systemy płatności, szczególnie, że bardzo dobrze jest dobrany poziom abstrakcji: autorowi udało sią pokazać istotę mechanizmu realizacji tych płatności bez zbędnych detali. Pierwsze moje wrażenie, gdy zobaczyłem ten diagram to: to jest diagram komunikacji UML a obrazowe ikony na tym diagramie to stereotypy. Stereotyp czyli typ…

Czytaj dalejModel UML i stereotypy jako ikony

Architektura informacji, system informacyjny a system informatyczny w organizacji

"Jeśli myślisz, że dobra architektura jest droga, spróbuj złej" Wstęp W roku 2008 pisałem (Forbs): W wie­lu fir­mach decy­zja o wdro­że­niu sys­te­mu infor­ma­tycz­ne­go bar­dzo czę­sto nie jest poprze­dzo­na żad­ny­mi przy­go­to­wa­nia­mi w rodza­ju oce­ny struk­tu­ry orga­ni­za­cji, jej zdol­no­ści do zmian czy też upo­rząd­ko­wa­niem obie­gu infor­ma­cji. Częstym grze­chem jest pró­ba ?wtło­cze­nia? w sys­tem infor­ma­tycz­ny ?sta­re­go? porząd­ku. Drugi grzech to brak opi­sa­ne­go sys­te­mu infor­ma­cyj­ne­go. W efek­cie nastę­pu­je zde­rze­nie rygo­rów papie­ro­we­go obie­gu infor­ma­cji z obie­giem danych w sys­te­mie infor­ma­tycz­nym. Rezygnacja z wie­lu czyn­no­ści (np. sta­wia­nie pie­czą­tek i pod­pi­sów) lub zamia­ny ich na inne sta­je się klu­czo­wym, bro­nio­nym jak nie­pod­le­gło­ści przez wie­lu kie­row­ni­ków…

Czytaj dalejArchitektura informacji, system informacyjny a system informatyczny w organizacji

Diagramy w notacji UML

Wprowadzenie "The Unified Modeling Language User Guide" autorstwa Grady'ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona (Addison-Wesley, 1998) mówi nam, że "możesz wykonać 80% modelowania za pomocą 20% UML" gdzieś po stronie 400. Zaoszczędziliby branży wiele milionów (miliardów?) dolarów i przerażających przypadków paraliżu analitycznego [?], gdyby powiedzieli to we Wstępie, ale tego nie zrobili. Aby spotęgować przestępstwo, nigdy nie mówią nam, które 20% UML jest użyteczną częścią". Diagramy UML i sposób ich użycia, od samego początku istnienia tej notacji, budzą emocje i fale sprzecznych komentarzy. Powodem jest wysoki poziom abstrakcji etapu…

Czytaj dalejDiagramy w notacji UML

Koniec treści

Nie ma więcej stron do załadowania