Diagram aktywności UML – kiedy

Wstęp

Od cza­su do cza­su jestem pyta­ny o to, kie­dy uży­wać dia­gra­mu aktyw­no­ści UML. Od 2015 roku spe­cy­fi­ka­cja UML wska­zu­je, że dia­gra­my te są narzę­dziem mode­lo­wa­nia metod czy­li logi­ki kodu (dla Platform Independent Model): aktyw­no­ści (acti­vi­ties) to nazwy metod, zadania/kroki (actions) to ele­men­ty kodu (przy­kła­dy w dal­szej części). 

Gdy powsta­wał UML, dia­gra­my aktyw­no­ści były uży­wa­ne tak­że do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych. W roku 2004 opu­bli­ko­wa­no spe­cy­fi­ka­cję nota­cji BPMN, któ­ra w zasa­dzie do roku 2015 prze­ję­ła” po UML funk­cję narzę­dzia mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. W 2015 roku for­mal­nie opu­bli­ko­wa­no spe­cy­fi­ka­cję UML 2.5, gdzie gene­ral­nie zre­zy­gno­wa­no z uży­wa­nia UML do mode­li CIM. Obecnie Mamy usta­bi­li­zo­wa­ną sytu­ację w lite­ra­tu­rze przed­mio­tu: BPMN wyko­rzy­stu­je­my w mode­lach CIM (mode­le biz­ne­so­we), UML w mode­lach PIM i PSM jako mode­le opro­gra­mo­wa­nia (a mode­le sys­te­mów: SysML, pro­fil UML). 

Na prze­ło­mie lat 80/90-tych roz­po­czę­to pra­ce nad stan­da­ry­za­cję nota­cji mode­lo­wa­nia obiek­to­we­go, w 1994 opu­bli­ko­wa­no UML 0.9, w 2001 roku poja­wia­ją się pierw­sze publi­ka­cje o pra­cach nad nota­cją BPMN, jed­no­cze­śnie poja­wia się Agile Manifesto, od 2004 roku ma miej­sce spa­dek zain­te­re­so­wa­nia doku­men­to­wa­niem pro­jek­tów pro­gra­mi­stycz­nych, w 2004 rok publi­ko­wa­no spe­cyf­ka­cję BPMN 1.0, od tego roku ma miej­sce wzrost zain­te­re­so­wa­nia mode­lo­wa­niem pro­ce­sów biz­ne­so­wych, powo­li sta­bi­li­zu­je się obszar zasto­so­wa­nia nota­cji UML. W 2015 roku opu­bli­ko­wa­no UML 2.5, sto­so­wa­nie ana­li­zy (CIM) i i pro­jek­to­wa­nia (PIM), jako eta­pu poprze­dza­ją­ce­go imple­men­ta­cje, sta­ło się stan­dar­dem (źr. wykre­su: Google Ngram).

Tak więc obecnie: 

Nie uży­wa­my dia­gra­mów aktyw­no­ści do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Do tego słu­ży nota­cja BPMN!

Diagram aktyw­no­ści może być mode­lem kodu na wyso­kim lub niskim pozio­mie abs­trak­cji, ope­ru­je­my wte­dy odpo­wied­nio aktyw­no­ścia­mi (acti­vi­ty) lub dzia­ła­nia­mi (actions). Te ostat­nie to w zasa­dzie repre­zen­ta­cja pole­ceń programu. 

Nie ma cze­goś takie­go jak pro­ces sys­te­mo­wy”, opro­gra­mo­wa­nie reali­zu­je pro­ce­du­ry”.

Projektując opro­gra­mo­wa­nie zgod­nie ze SPEM , powsta­je Platform Independent Model. W prak­ty­ce już na tym eta­pie pro­gra­mu­je­my, bo two­rzy­my logi­kę i obraz przy­szłe­go kodu. Taka for­ma doku­men­to­wa­nia pozwa­la tak­że lepiej chro­nic war­to­ści inte­lek­tu­al­ne zamawiającego.

(wię­cej…)

Czytaj dalejDiagram aktywności UML – kiedy

Koncepcja rozszerzenia wzorca projektowego BCE

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 dalejKoncepcja rozszerzenia wzorca projektowego BCE

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

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 dalejSynteza pojęć i wzorców MOF, MDA, PIM, MVC i BCE. Zintegrowany model struktury procesu projektowania aplikacji.

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

[toc] 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…

Czytaj dalejKnow-how a Zasada Kerckhoffs’a i bezpieczeństwo

Wymiarowanie oprogramowania

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ę branżę,…

Czytaj dalejWymiarowanie oprogramowania

Koniec treści

Nie ma więcej stron do załadowania