architektura oprogramowania – Jarosław Żeliński IT-Consulting

Diagram aktywności UML – kiedy

Post author:Jarosław Żeliński
Post published:23 lipca 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:10 komentarzy
Post last modified:24 października 2024

Wstęp

Od czasu do czasu jestem pytany o to, kiedy używać diagramu aktywności UML. Od 2015 roku specyfikacja UML wskazuje, że diagramy te są narzędziem modelowania metod czyli logiki kodu (dla Platform Independent Model): aktywności (activities) to nazwy metod, zadania/kroki (actions) to elementy kodu (przykłady w dalszej części).

Gdy powstawał UML, diagramy aktywności były używane także do modelowanie procesów biznesowych. W roku 2004 opublikowano specyfikację notacji BPMN, która w zasadzie do roku 2015 “przejęła” po UML funkcję narzędzia modelowania procesów biznesowych. W 2015 roku formalnie opublikowano specyfikację UML 2.5, gdzie generalnie zrezygnowano z używania UML do modeli CIM. Obecnie Mamy ustabilizowaną sytuację w literaturze przedmiotu: BPMN wykorzystujemy w modelach CIM (modele biznesowe), UML w modelach PIM i PSM jako modele oprogramowania (a modele systemów: SysML, profil UML).

Na przełomie lat 80/90-tych rozpoczęto prace nad standaryzację notacji modelowania obiektowego, w 1994 opublikowano UML 0.9, w 2001 roku pojawiają się pierwsze publikacje o pracach nad notacją BPMN, jednocześnie pojawia się Agile Manifesto, od 2004 roku ma miejsce spadek zainteresowania dokumentowaniem projektów programistycznych, w 2004 rok publikowano specyfkację BPMN 1.0, od tego roku ma miejsce wzrost zainteresowania modelowaniem procesów biznesowych, powoli stabilizuje się obszar zastosowania notacji UML. W 2015 roku opublikowano UML 2.5, stosowanie analizy (CIM) i i projektowania (PIM), jako etapu poprzedzającego implementacje, stało się standardem (źr. wykresu: Google Ngram).

Tak więc obecnie:

Nie używamy diagramów aktywności do modelowania procesów biznesowych. Do tego służy notacja BPMN!

Diagram aktywności może być modelem kodu na wysokim lub niskim poziomie abstrakcji, operujemy wtedy odpowiednio aktywnościami (activity) lub działaniami (actions). Te ostatnie to w zasadzie reprezentacja poleceń programu.

Nie ma czegoś takiego jak “proces systemowy”, oprogramowanie realizuje “procedury”.

Projektując oprogramowanie zgodnie ze SPEM , powstaje Platform Independent Model. W praktyce już na tym etapie programujemy, bo tworzymy logikę i obraz przyszłego kodu. Taka forma dokumentowania pozwala także lepiej chronic wartości intelektualne zamawiającego.

(więcej…)

Czytaj dalej

Aplikacje webowe i mikroserwisy czyli architektura systemów webowych

Post author:Jarosław Żeliński
Post published:13 lipca 2020
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:17 kwietnia 2024

Architektura referencyjna przeglądarki internetowej i aplikacji webowych.

Czytaj dalej

Koncepcja rozszerzenia wzorca projektowego BCE

Post author:Jarosław Żeliński
Post published:17 maja 2019
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:27 października 2021

Streszczenie: W pracy przedstawiono metodę projektowania architektury oprogramowania od ogółu do szczegółu z pomocą metamodeli definiowanych jako profili UML. Pokazano zaletę jaką jest możliwość szybkiego rozpoczęcia prac projektowych i testowania efektów mimo braku detalicznej wiedzy o danych. Metoda zakłada, że dane są zorganizowane z nazwane dokumenty o określonej strukturze. W trakcie prac analitycznych i projektowych wystarczającą wiedzą jest to jakie dokumenty są (będą) przetwarzane, zrozumienie ich celu i opis zawartości. Detaliczne szablony dokumentów (pola i ich zawartość) mogą pozostawać nieznane prawie do końca analizy i projektowania, wymagane są dopiero na…

Czytaj dalej

Synteza pojęć i wzorców MOF, MDA, PIM, MVC i BCE. Zintegrowany model struktury procesu projektowania aplikacji.

Post author:Jarosław Żeliński
Post published:30 kwietnia 2019
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:5 komentarzy
Post last modified:8 lipca 2021

Streszczenie: Wiele publikacji, w tym podręczniki akademickie, zawiera niespójności w opisach zastosowań metod i wzorców architektonicznych, kryjących się pod skrótami MOF, MDA, PIM, MVC, BCE. Skuteczna analiza oraz następujące po niej projektowanie oprogramowania, szczególnie gdy są to projekty realizowane w dużych zespołach, wymaga standaryzacji procesu wytwórczego i stosowanych wzorców i frameworków. W pracy tej podjęto próbę uporządkowania systemu pojęć opisujących ten proces , stosowanych do opisu wzorców architektonicznych. Przeprowadzono analizę kluczowych pojęć MOF i MDA, wzorców MVC i BCE, stworzono spójny opis łączący je w jeden system. 1. Wprowadzenie Celem badań było zweryfikowanie obecnego stanu metod projektowania i opracowanie spójnego systemu pojęć i wzorców…

Czytaj dalej

Know-how a Zasada Kerckhoffs’a i bezpieczeństwo

Post author:Jarosław Żeliński
Post published:9 stycznia 2018
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:12 lipca 2024

Wprowadzenie Tematem numer jeden, niemalże w każdym moim projekcie, jest model biznesowy i tajemnica przedsiębiorstwa. Z perspektywy lat muszę powiedzieć, że to fobia wielu (jak nie większości) przedsiębiorców i nie tylko przedsiębiorców. Nie dlatego, że chcą coś chronić, ale dlatego co i jak chronią. Nie raz już pisałem, że firmy nie raz, najpierw podpisują z dostawcami rozwiązań i konsultantami umowy o poufności, a potem wyzbywają praw do swojego know-how na ich rzecz: W branży inżynierii oprogramowania dość powszechna jest sytuacja, gdy programista jest także projektantem, innymi słowy programista ma pełnię…

Czytaj dalej

Wymiarowanie oprogramowania

Post author:Jarosław Żeliński
Post published:23 listopada 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:3 komentarze
Post last modified:24 stycznia 2024

Wprowadzenie Bardzo często spotykam się z metodami wymiarowania oprogramowania, czyli mówiąc ludzkim językiem: oceny pracochłonności jego wytworzenia. Typowym argumentem za stosowaniem tych metod jest potrzeba planowania. Nie raz spotykam się z porównaniami do pomiaru powierzchni np. w budownictwie (cytat celowo ze strony stosownego stowarzyszenia): Wymiarowanie oprogramowania, ma podobne znaczenie, co wymiarowanie w innych dziedzinach inżynierii. Określa wielkość, pozwala na porównywanie różnych przedsięwzięć, szacowanie kosztów wytwarzania i lepsze planowanie. Punkty funkcyjne ? najbardziej popularna i promowana przez specjalistów jednostka wielkości oprogramowania, to przykładowo odpowiednik metrów kwadratowych w budownictwie. Wyobraźmy sobie tę…

Czytaj dalej