Read more about the article Diagram aktywności UML c.d.
David Harel. (2001). Rzecz o istocie informatyki. Algorytmika. (Zbigniew Weiss & Piotr Carlson, Trans.; Wydanie trzecie). PWN.

Diagram aktywności UML c.d.

Technical Description of Software, as documentation of the mechanism of its operation, requires precision because it constitutes documentation of know-how (it can also be part of patent documentation). Such documentation cannot be source code of a specific (one of many on the market) programming language, as it must be a "dry" description of the mechanism of operation, and not an example of one of many possible implementations. This is also pointed out by the author of the above-mentioned book. Therefore, the documentation of the system, it is not its example implementation ("working code"), it is the essence of its operation expressed as an abstract model.

Czytaj dalejDiagram aktywności UML c.d.

Organizacja jako mechanizm czyli słoń w pokoju

The era of "sacred cows" of engineering is slowly coming to an end. Software engineering, after almost 20 years of an "agile" approach to this branch of engineering, is beginning to mature into "real engineering" with analysis, design and testing on the "drawing board" of CASE systems and MBSE approaches, which are a universal systems approach to multidisciplinary engineering (mechatronics) (Rosenberg, 2023). Organizations are also systems and their engineering: we have business process engineering, resource engineering, financial engineering. Organizations are systems and should be treated and modeled as such (Kozminski, 1979). IT systems maintenance and development costs are already more than 8% of a company's revenue, and this value is slowly but steadily growing. The discipline of their creation, implementation and management of their costs is also growing.

Czytaj dalejOrganizacja jako mechanizm czyli słoń w pokoju

ICONIX jako komponentowo zorientowany, zwinny standard projektowania oprogramowania

"A software system’s architecture is the set of principal design decisions made about the system." Wprowadzenie O podobnej porze roku, w 2015 roku pisałem: W ICONIX moż­na z powo­dze­niem sto­so­wać ​„czy­sty” UML źr.: : ICONIX and Use Case Driven Object Modeling with UML - Jarosław Żeliński IT-Consulting ICONIX to w zasadzie standard komponentowego, zorientowanego obiektowo, na przypadki użycia i interfejsy komponentów, procesu projektowania oprogramowania . Jest to od samego początku swojego istnienia, metoda klasyfikowana jako zwinna . Orientacja na Przypadki Użycia (use case driven) to obecnie kanon projektowania . Coraz popularniejszy…

Czytaj dalejICONIX jako komponentowo zorientowany, zwinny standard projektowania oprogramowania

Czym jest PIM czyli kto jest programistą

Ten arty­kuł jest adre­so­wa­ny do wszyst­kich. Biznes (praw­ni­cy tak­że) może prze­ko­nać się, że opro­gra­mo­wa­nie moż­na nary­so­wać i zro­zu­mieć. Analitycy i pro­gra­mi­ści, że to moż­li­we, a dewe­lo­pe­rzy, że nikt im nie odbie­ra pra­cy a raczej pomaga. 

Wprowadzenie

W dzi­siej­szym świe­cie inży­nie­rii naj­więk­szą war­tość mają czas i zaso­by. Czas to jak naj­szyb­sze odda­nie roz­wią­za­nia (pro­duk­tu) do użyt­ku (szyb­ka komer­cja­li­za­cja), zaso­by to koszt jakim się to odbę­dzie. Kluczem są kosz­ty: time to mar­ket”, tu kosz­tem jest opóź­nie­nie komer­cja­li­za­cji (nie­zre­ali­zo­wa­ne przy­cho­dy), kosz­tem jest tak­że samo powsta­wa­nia opro­gra­mo­wa­nia. Praktycznie od począt­ku inży­nie­rii opro­gra­mo­wa­nia zależ­ność kosz­tów od dys­cy­pli­ny i eta­pu pra­cy się nie zmie­nia, wyglą­da to jak poniżej:

Źr. Effective softwa­re deli­ve­ry. White paper. May 2009

Od same­go począt­ku prac nad opro­gra­mo­wa­niem tak napraw­dę roz­wią­zu­je­my pro­ble­my: począw­szy od pro­ble­mów z odkry­ciem co tak napraw­dę jest roz­wią­za­niem pro­ble­mu (a pro­blem trze­ba naj­pierw ziden­ty­fi­ko­wać), przez pro­ble­my zwią­za­ne z wła­ści­wym zapro­jek­to­wa­niem roz­wią­za­nia (algo­ryt­my, archi­tek­tu­ra kodu), do pro­ble­mów wybo­ru tech­no­lo­gii i imple­men­ta­cji. Patrząc od koń­ca: pomył­ki są bar­dzo kosz­tow­ne dla orga­ni­za­cji (spon­sor pro­jek­tu). Development (kodo­wa­nie i testy) to pra­ca zespo­łów ludzi, są bar­dzo kosz­tow­ne. Najtańsza jest tu pra­ca (etap) ana­li­ty­ka-pro­jek­tan­ta, to jed­nak tak­że czas (pamię­ta­my time to market”). 

Tak więc water­fall” nie wcho­dzi w grę. Praktyka jed­nak poka­zu­je, że roz­po­czę­cie od razu od kodo­wa­nia nie roz­wią­zu­je żad­ne­go pro­ble­mu bo złe pomy­sły są i będą, kory­go­wa­ne dopie­ro na eta­pie kodo­wa­nia gene­ru­ją bar­dzo duże kosz­ty. Lekarstwem jest odej­ście o mono­li­tycz­nej archi­tek­tu­ry na rzecz samo­dziel­nych kom­po­nen­tów, czy wręcz mikro­ser­wi­sów (jed­nost­ki imple­men­ta­cji to poje­dyn­cze przy­pad­ki uży­cia UML, tu rozu­mia­ne jako nie­za­leż­ne mikro-apli­ka­cje ). Dlatego opty­mal­ne wyda­je sie podej­ście: 1. ana­li­za, 2. pro­jek­to­wa­nie HLD: kom­po­nen­ty, 3. ite­ra­cyj­ne pro­jek­to­wa­nie LLD kom­po­nen­tów i ich deve­lop­ment. Osiągamy waż­ną rzecz: naj­droż­sze zaso­by: deve­lop­ment, dosta­ją do imple­men­ta­cji prze­my­śla­ne roz­wią­za­nie, nie tra­ci­my cza­su i środ­ków na kolej­ne pro­to­ty­py w kodzie. 

(wię­cej…)

Czytaj dalejCzym jest PIM czyli kto jest programistą
Read more about the article Modelowanie systemów – organizacja jako mechanizm
Friedenthal, S., Moore, A., & Steiner, R. (2015). A practical guide to SysML: The systems modeling language (Third edition). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a-practical-guide-to-sysml

Modelowanie systemów – organizacja jako mechanizm

Wprowadzenie Pojęcie 'system' stało się bardzo popularne, głównie za sprawą "systemów informatycznych", jednak jego rodowód jest starszy i pochodzi nie od technologii a od biologii . Poza IT mamy systemy bezpieczeństwa, system ubezpieczeń, system emerytalny, system prawa, i wiele innych. Słownik języka polskiego podaje taką definicję pojęcia system: «układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość» «zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość» «narządy lub inne części żywego organizmu pełniące razem określoną funkcję» «uporządkowany zbiór twierdzeń, poglądów, tworzących jakąś teorię» «określony sposób wykonywania jakiejś czynności lub…

Czytaj dalejModelowanie systemów – organizacja jako mechanizm

Diagram Przypadków Użycia UML – aktor jako persona

Wstęp W niedawno napisanym artykule na temat przypadków użycia i ich definicji zgodnej z UML, wskazywałem między innymi, że: Przypadki uży­cia są spo­so­bem na uchwy­ce­nie [wska­za­nie] wyma­gań sta­wia­nych sys­te­mom, tzn. tego, co sys­te­my mają robić [powo­dy, dla któ­rych one powsta­ną, co będą reali­zo­wa­ły] na rzecz i na żąda­nie Aktora. źr.: Diagram Przypadków Użycia UML - Jarosław Żeliński IT-Consulting Sama specyfikacja UML o aktorze, jako elemencie wokół systemu, mówi bardzo niewiele, poza rozdziałem dotyczącym przypadków użycia: Przypadki użycia są sposobem na uchwycenie wymagań systemów, czyli tego, co systemy mają robić. Kluczowymi pojęciami…

Czytaj dalejDiagram Przypadków Użycia UML – aktor jako persona

MVC a etapy projektowania aplikacji HLD i LLD – Czym jest Architektura Systemu

W perspektywie krótkoterminowej architektura oprogramowania pomaga zredukować czas i koszty rozwoju.W dłuższej perspektywie architektura oprogramowania pomaga zredukować koszty utrzymaniu. https://medium.com/@learnwithwhiteboard_digest/basics-of-software-architecture-a-guide-for-developers-8098a76881ca Wstęp W 2017 roku pisałem dość ogólnie o logice wzorca architektonicznego MVC kończąc artykuł słowami: A gdzie mitycz­na baza danych? Tam gdzie jej miej­sce: zarzą­dza dany­mi utrwa­la­ny­mi w pamię­ci. Baza danych i sys­te­my zarzą­dza­nia dany­mi w archi­tek­tu­rze obiek­to­wej nie sta­no­wią miej­sca na logi­kę biz­ne­so­wą, stan­dar­do­wym wzor­cem pro­jek­to­wym jest tu acti­ve records. Podstawową zale­tą sto­so­wa­nie tego wzor­ca jest sepa­ra­cja utrwa­lo­nych danych od apli­ka­cji. To pozwa­la sku­pić całą logi­kę i jej zmien­ność w kodzie apli­ka­cji i jego archi­tek­tu­rze. Dzięki temu…

Czytaj dalejMVC a etapy projektowania aplikacji HLD i LLD – Czym jest Architektura Systemu
Model systemu służy do określenia składników systemu.
Friedenthal, S., Moore, A., & Steiner, R. (2015). A practical guide to SysML: the systems modeling language (Third edition). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a-practical-guide-to-sysml

Przeciążanie BPMN czyli jak nie modelować produkcji

Analityczne modele BPMN to łańcuchy aktywności reprezentujących procedury oraz ich produkty czyli dokumenty (dane). Na tych modelach aktywność to abstrakcja reprezentująca (całą) pracę, której efekt (wynik) jest prezentowany jako treść (DataObject), czyli aktywność kopania rowu kończy się pisemnych stwierdzeniem, że rów wykopano, z ewentualnym opisem parametrów tego rowu (patrz specyfikacja BPMN i definicja atomowej aktywności w procesach ). A gdzie dokładny opis machania łopatą albo obsługi koparki? Nie tu (patrz Procesy a procedury). Tak więc nie używamy notacji BPMN do modelowania procesów i struktury produkcji. Skoro nie BPMN to czego…

Czytaj dalejPrzeciążanie BPMN czyli jak nie modelować produkcji

Ontologia czyli jak się to robi

Wiele problemów w projektach informatycznych, to skutki źle zbudowanej ontologii lub jej braku w projekcie. Niemal co druga firma (46 proc. badanych przez AIIM, 2022) ocenia, że przeciwdziałanie chaosowi informacyjnemu wewnątrz ich organizacji „wypada słabo” lub „wymaga poprawy”. Obecnie większość przetwarzanych w firmach treści to treści częściowo lub nawet całkowicie nieustrukturyzowane. Zarzadzanie nimi wymaga nowych metod . [toc] Czym jest ontologia Ontologia jest często nazywana reprezentacją wiedzy. Pozostaje pytanie co jest tu tą wiedzą? Czy wiedzą jest to co oznacza w określonym języki (tu polskim) słowo "samochód", czy wiedzą jest…

Czytaj dalejOntologia czyli jak się to robi

Visual Paradigm v.17

Właśnie skończył się mi instalować upgrade Visual Paradigm v.17. To narzędzie towarzyszy mi od 2005 roku, ale po kolei. W zasadzie od początku swojej kariery w branży IT modele tworzyłem wyłącznie z użyciem sformalizowanych notacji. Kluczowym powodem zawsze były: kontrolowalna poprawność i logika tych modeli oraz standaryzacja. To troszkę jak z matematyką: wiemy, że dwa i dwa to zawsze cztery a do zakomunikowania tego innym używamy standardowej formy zapisu: 2+2=4. W zasadzie z matematyką nie mamy problemu, problemem są schematy blokowe: wielu ludzi uważa, że to tylko obrazki, które można…

Czytaj dalejVisual Paradigm v.17

Interface-Oriented Design czyli architektura systemu zorientowana na interfejsy

[toc] Wprowadzenie Tym razem krótka recenzja pewnej książki z roku 2006, a raczej jej polecenie każdemu projektantowi i architektowi dzisiaj. Na końcu polecam także kolejną nowszą pozycję jako uzupełnienie. Adresatami tej recenzji są głównie analitycy i projektanci, jednak adresuję ten wpis także do developerów, zakładam że dla nich nie jest to "coś nowego", ale być może mają jakieś rady dla projektantów. Warto także podkreślić, że pomiędzy OOP a OOAD jest coraz większa różnica i podział na role: analiza i projektowanie oraz implementacja, a także postępująca separacja tych ról, stają się…

Czytaj dalejInterface-Oriented Design czyli architektura systemu zorientowana na interfejsy

Związki między elementami w modelach systemów – zawieranie, dekompozycja i zależności

[toc] Wprowadzenie Tym razem artykuł na temat typów związków między elementami w modelach systemów. Modele tego typu to hierarchiczna struktura mająca kilka różnych perspektyw, poziomów abstrakcji i poziomów dekompozycji. Do tego dochodzą fizyczne i logiczne powiązania między elementami oraz fakt, że każdy system to określone "materialne" elementy ułożone w hierarchiczną strukturę. Każdy system składa się ze skończonej liczby elementów o skończonej liczbie typów. Na to wszystko nakłada się struktura wymagań na system, oraz konieczność wykazania zgodności projektu systemu z tymi wymaganiami . Bardzo często jestem pytany o to, jak organizować…

Czytaj dalejZwiązki między elementami w modelach systemów – zawieranie, dekompozycja i zależności

Koniec treści

Nie ma więcej stron do załadowania