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
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

Diagram Przypadków Użycia UML

Wstęp Jest to diagram, który na równi z Diagramem Klas, budzi bardzo często ogromne problemy interpretacyjne (patrz: Diagram klas...). Bardzo wielu autorów przypisuje temu diagramowi role, których on nie pełni, a nie raz prezentowane w sieci i literaturze przykłady są niepoprawne. Znakomita większość autorów tych diagramów używa ich jako "zbioru możliwych kliknięć" co jest całkowitym niezrozumieniem celu użycia i idei tego diagramu. Nawet jeżeli ktoś potrzebuje takiej mapy klikania, to są do tego lepszych narzędzia i metody (przykład: Mapa ekranów aplikacji – podstawa dobrego UX/UI design). Tworzenie niezgodnych z notacją…

Czytaj dalejDiagram Przypadków Użycia UML

Wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

Analiza biz­ne­so­wa i projektowanie

Wstęp

W arty­ku­le o apli­ka­cjach webo­wych, ponad rok temu, pisałem:

Generalnie klu­czo­wą cechą micro-ser­wi­­sów, czy­nią­cą z nich tak zwa­ną zwin­ną archi­tek­tu­rę, jest cał­ko­wi­ta wza­jem­na nie­za­leż­ność imple­men­ta­cji poszcze­gól­nych usług apli­ka­cyj­nych. (źr.: Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych).

Przy innej oka­zji pisa­łem o wzorcach:

Wzorce pro­jek­to­we to bar­dzo waż­na część ??zawo­du? ana­li­ty­ka i archi­tek­ta opro­gra­mo­wa­nia. […] Generalnie wzor­ce są to ska­ta­lo­go­wa­ne stan­dar­dy i dobre prak­ty­ki . (Obiektowe wzor­ce projektowe ) 

Szkolenia dla ana­li­ty­ków poprze­dzam ankie­ta­mi przed szko­le­nio­wy­mi, jak do tej pory żad­na nie zawie­ra­ła pytań o wzor­ce pro­jek­to­we: ani tego że są uży­wa­ne ani tego, że są celem szko­le­nia, nie­mal­że każ­dy dekla­ru­je albo, że uży­wa UML lub, że chce zacząć uży­wać UML, nawet gdy są to pro­gra­mi­ści. Zauważyłem, że wzor­ce pro­jek­to­we w świa­do­mo­ści ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia (OOAD) nie ist­nie­ją”. Wśród pro­gra­mi­stów, jeże­li jest spo­ty­ka­na, to wie­dza o wzor­cach przy­dat­nych w two­rze­niu biblio­tek i narzę­dzi, czę­sto też powie­la­ne są wyuczo­ne sta­re i złe prak­ty­ki pro­gra­mi­stycz­ne rodem z lat 60-tych (np. prak­ty­ki SmallTalk, patrz dalej). 

Z dru­giej stro­ny od wie­lu lat zna­ne są tech­ni­ki MDA (Model Driven Architecture) czy MBSE (Model Based System Engineering), któ­re w róż­nych for­mach, ale jed­nak wska­zu­ją, że naj­sku­tecz­niej­sza for­ma wyra­ża­nia wyma­gań wobec roz­wią­za­nia to pro­jekt archi­tek­tu­ry i logi­ki dzie­dzi­no­wej (model) dzia­ła­nia apli­ka­cji . O pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cję pisze sie od dość daw­na, meto­dy obiek­to­we i dobre prak­ty­ki zna­ne są od lat .

Autorzy BABoK prak­tycz­nie od począt­ku ist­nie­nia tego wydaw­nic­twa, zwra­ca­ją uwa­gę na tak zwa­ną bia­łą skrzyn­kę”, czy­li wyma­ga­nia wyra­żo­ne w posta­ci wewnętrz­nej struk­tu­ry pro­duk­tu, wska­zu­jąc, że to znacz­nie sku­tecz­niej­sza meto­da defi­nio­wa­nia wyma­gań wobec roz­wią­za­nia, niż tak zwa­na czar­na skrzyn­ka”, czy­li tra­dy­cyj­ne, i jed­nak mniej sku­tecz­ne, wyma­ga­nia wyra­żo­ne tyl­ko jako cechy funk­cjo­nal­ne i poza-funk­cjo­nal­ne. Pamiętajmy, że adre­sa­tem wyma­gań jest zawsze dostaw­ca produktu!

(wię­cej…)

Czytaj dalejWzorce projektowe w analizie i projektowaniu modelu dziedziny systemu

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

Studium wykonalności c.d. czyli analiza systemowa rozwiązania

Wprowadzenie ?Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle ?problemami złośliwymi? . ?Problem złośliwy? to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.? W roku 2014 w artykule Studium wykonalności produktu - czym naprawdę jest napisałem na zakończenie: W literaturze można spotkać różne ?definicje? studium wykonalności, jednak ta którą opisałem, zdaje się być najbliższa definicji, którą przytoczyłem na początku: bazującej na znaczeniu słownikowym. Praktyka pokazuje, że intencje sponsorów…

Czytaj dalejStudium wykonalności c.d. czyli analiza systemowa rozwiązania

Procesy biznesowe a procedury

Wstęp Powodem napisania tego artykułu była publikacja: "Wdrożenie zintegrowanych elektronicznych usług, informacyjnych na przykładzie poradników przedsiębiorcy, udostępnianych poprzez Punkt Kontaktowy w Polsce" (Elektroniczna gospodarka nr 4/2015, plik pdf). Autorzy Mgr Szymon Mamrot, doktorant na Wydziale Informatyki i Gospodarki Elektronicznej Uniwersytetu Ekonomicznego w Poznaniu, główny specjalista w Centrum Elektronicznej Gospodarki Instytutu Logistyki i Magazynowania (e-mail: szymon.mamrot@ilim.poznan.pl). Mgr Magdalena Stachowicz, absolwentka studiów doktoranckich na Wydziale Politologii Uniwersytetu Marii Curie-Skłodowskiej w Lublinie, starszy specjalista w Centrum Elektronicznej Gospodarki Instytutu Logistyki i Magazynowania (e-mail: magdalena.stachowicz@ilim.poznan.pl). Artykuł był recenzowany. Autorzy cytują między innymi mój artykuł, a konkretnie definicję…

Czytaj dalejProcesy biznesowe a procedury

Fundament analizy: metodyka

Nieco ponad rok temu opisywałem sytuację, w której pewien doświadczony analityk narzekał, że pracownicy jego klientów nie potrafią mu powiedzieć czego chcą i jak ma działać ich przyszły system. Odpowiedź moja jest w takich sytuacjach zawsze taka sama: ...analiza nie polega na słuchaniu! (wyobrażacie sobie leczenie, w którym diagnozy stawiają pacjenci?). Nie raz tu pisałem i kolejny raz powtórzę:Analiza oparta na zeznaniach i życzeniach jej [firmy zamawiającego] pracowników jest bardzo narażona na fiasko, gdyż subiektywna wiedza pracowników oraz ich spekulacje, mogą nie mieć wiele wspólnego z rzeczywistością lub pożądanym stanem…

Czytaj dalejFundament analizy: metodyka

Architektura kodu aplikacji jako pierwszy etap tworzenia oprogramowania

Tym razem troszkę cięższy kaliber, czyli dywagacje o tym co powszechnie jest określane jako metody obiektowe i o tym skąd "konflikty i nieporozumienia" między programistami i analitykami projektantami.?*? Wprowadzenie Literatura przedmiotu zawiera wiele różnych sposobów grupowania metod programowania w ?paradygmaty?. Autorzy z reguły skupiają się na tym, czym są programy rozumiane jako zorganizowana lista poleceń dla maszyny. Mogą to być sekwencje prostych poleceń, mogą to być wykonywane wg. określonego scenariusza funkcje.  Typowym przykładem takiego grupowania jest np. wykład (tu jego spis treści) dostępny w sieci Internet: Wstęp1.1 Przykład pierwszy: programowanie…

Czytaj dalejArchitektura kodu aplikacji jako pierwszy etap tworzenia oprogramowania

Model dziedziny jako mechanizm

Powszechnym błędem jest więc "zamawianie" oprogramowania metodą specyfikowania wymagań, jako wielu przypadkowo, lub nawet systematycznie, opisanych reakcji na bodźce, bez zrozumienia mechanizmu ich powstawania. Implementacja tak opisanych wymagań bardzo często jest realizowana jako bardzo rozbudowany system pokazujący co sekundę kolejny obraz tarczy zegara zamiast implementacji prostego mechanizmu zmieniającego położenie wskazówek na nieruchomej tarczy zegara. Większość znanego mi oprogramowania jest bardziej złożona niż mogła by być...

Czytaj dalejModel dziedziny jako mechanizm

MDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Ten artykuł można czytać na dwa sposoby: analitycy czytają od dechy do dechy po kolei ;). Menedżerowie i tak zwany biznes czytają od razu koniec, to jest część Na zakończenie, gdy uznają, że nie wierzą w te wnioski (wyrok) to zaczynają od początku czyli czytają uzasadnienie :). Niedawno napisałem: Pomiędzy pojęciami abstrakcja i model jest pewna kluczowa różnica: abstrakcja to pojęcie zaś model to opis mechanizmu, jego konstrukcja, działanie, budowa. Prosty przykład: nazwane prostokąty na typowym diagramie struktury organizacyjnej to abstrakcje komórek organizacyjnych i osób w nich zatrudnionych, prostokąty te…

Czytaj dalejMDA – Cztery produkty czyli dwa etapy: wymagania i produkt

Dynamika systemów zarządzania

Są książki nieśmiertelne. Polowanie na tę trwało ponad rok. Zastanawia mnie to, że nie ma dodruków takich książek, bo pewne osiągnięcia nauki się nie starzeją. Piękna pozycja opisująca metody analizowania i modelowania przedsiębiorstw. Książka wydana w 1975 roku przez Państwowe Wydawnictwo Naukowe. Abstrahując od antycznych :) notacji użytych do stworzenia bardzo jednak dobrze opisanych schematów blokowych, nie straciła nic na aktualności. Książka opisuje to, jak metodami systemowymi prowadzić analizy przedsiębiorstw i ich modelowanie. Pierwsza kluczowa teza, która wiele powinna wyjaśnić: To między innymi przesłanka do tego, by w toku analizy…

Czytaj dalejDynamika systemów zarządzania

Koniec treści

Nie ma więcej stron do załadowania