Model UML i stereotypy jako ikony

Wstęp 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

Diagramy w notacji UML

Wprowadzenie 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 analizy i modelowania jako dyscypliny, oraz dość powszechne niezrozumienie istoty ten notacji. Na to nakłada się ogromna różnica między tym co nazywamy analizą i projektowaniem obiektowym (OOAD) a obiektowo-zorientowanymi językami programowania (OOP). Notacja UML jest przez wielu ludzi błędnie traktowana jako kolejny zestaw symboli do tworzenia ilustracji. Większość znanych mi deweloperów uważa, że te diagramy im w niczym nie pomagają i generalnie mają racje, gdyż…

Czytaj dalejDiagramy w notacji UML

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

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

Notacja EPC

Wprowadzenie Notacja EPC (Event-driven Process Chain) została opracowana w 1992 roku w ramach projektu badawczo-rozwojowego z udziałem SAP AG na University of Saarland w Niemczech, a jej twórcą jest dr August-Wilhelm Scheer. Stanowi ona kluczowy element koncepcji modelowania SAP R/3 w zakresie inżynierii biznesowej i dostosowania tego systemu do potrzeb klienta, została włączona także do systemu NetWeaver firmy SAP. Ostatni duży projekt z jej użyciem realizowałem w 2008 roku dla polskiego oddziału niemieckiego banku WestLB Bank Polska SA. Później już jedynie okazjonalne wsparcie merytoryczne i audyty, nadal się zdarzają. EPC…

Czytaj dalejNotacja EPC
Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]
Booch, G. (1994). Object-oriented Analysis and Design with Applications. 2nd Edition, the Benjamin/Cummings Publishing Company, Inc.

Wymagania biznesowe – jak zbierać i dokumentować

Wprowadzenie Ronald Ross, współautor standardu modelowania reguł biznesowych i biznesowego słownika pojęć napisał niedawno na swoim profilu LinkedIn: "People love stories. Are user stories helpful in engineering business solutions? Absolutely. Are you done with requirements and solution engineering when you?ve worked through a set of user stories? No. Not even close!" ["Ludzie kochają historie. Czy historie użytkowników są pomocne w tworzeniu rozwiązań biznesowych? Zdecydowanie tak. Czy skończyłeś z wymaganiami i inżynierią rozwiązania, gdy już opracowałeś zestaw historyjek użytkownika? Nie. Nawet nie zbliżyłeś się do nich!".](https://www.linkedin.com/posts/rossronald_people-love-stories-are-user-stories-helpful-activity-6935627008265633793-Bpzb/) Świat od dekad boryka się…

Czytaj dalejWymagania biznesowe – jak zbierać i dokumentować

Diagram Przypadków Użycia UML

Wprowadzenie 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

Odpowiedzialność administratora systemu

Wstęp

pra­wie 10 lat temu pisałem:

Często spo­ty­kam się z róż­ny­mi meto­da­mi uwzględ­nia­nia pra­wa w ??doku­men­ta­cji wyma­gań?. Jakim wyma­ga­niem jest ??zgod­ność z obo­wią­zu­ją­cym pra­wem?? I trud­niej­sze pyta­nie: czy zmia­na pra­wa to zmia­na wyma­gań? Inny aspekt pro­ble­mu to ana­li­za i defi­ni­cja (opis) tej zgod­no­ści z pra­wem. Spotkać moż­na się z meto­dą pole­ga­ją­cą na trak­to­wa­niu każ­de­go (mają­ce­go wpływ na sys­tem) para­gra­fu np. usta­wy jako wyma­ga­nia. Problem zgod­no­ści opro­gra­mo­wa­nia z pra­wem ma dwa aspek­ty. Zgodność opro­gra­mo­wa­nia z pra­wem pole­ga na tym, że ??opro­gra­mo­wa­nie nie może ogra­ni­czać sto­so­wa­nia pra­wa to jest nie może wymu­szać swo­imi ogra­ni­cze­nia­mi dzia­łań nie­zgod­nych z pra­wem?. Ja oso­bi­ście reko­men­du­ję roz­cią­gnię­cie tej defi­ni­cji na ??ani nie powin­no pozwa­lać na łama­nie pra­wa?. Tu jed­nak wie­lu uwa­ża, że ??zama­wiam narzę­dzie i uży­wam jak chcę, na swo­ja odpo­wie­dzial­ność?. Coś w tym jest, war­to jed­nak zosta­wić ??włącz­nik?. (źr.: Prawo a wyma­ga­nia … )

Dzisiaj czy­tam:

To admi­ni­stra­tor odpo­wia­da za zabez­pie­cze­nia sys­te­mów ? a więc tak­że za to, że pra­cow­nik zdo­łał sko­pio­wać dane oso­bo­we na zewnętrz­ny nośnik. […] W oce­nie WSA w toku postę­po­wa­nia PUODO pra­wi­dło­wo usta­lił, iż w SGGW dopusz­czo­no się licz­nych uchy­bień, w szcze­gól­no­ści nie prze­pro­wa­dzo­no wła­ści­wej ana­li­zy ryzy­ka i oce­ny zagro­żeń już na eta­pie pro­jek­to­wa­nia sys­te­mów (pri­va­cy by design) oraz nie wdro­żo­no odpo­wied­nich środ­ków zapew­nia­ją­cych bez­pie­czeń­stwo danych, w tym przed moż­li­wo­ścią wyeks­por­to­wa­nia danych z sys­te­mu na zewnątrz.(źr.: Odpowiedzialność admi­ni­stra­to­ra za naru­sze­nie zasa­dy pri­va­cy by design)

Rzecz w tym, że admi­ni­stra­tor, w rozu­mie­niu pra­wa, to tak­że pod­miot zle­ca­ją­cy powsta­nie opro­gra­mo­wa­nia, któ­re go wspie­ra w reali­za­cji jego obo­wiąz­ków, a jed­nym z tych obo­wiąz­ków jest egze­kwo­wa­nie usta­lo­nych zasad.

(wię­cej…)

Czytaj dalejOdpowiedzialność administratora systemu

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

Koniec treści

Nie ma więcej stron do załadowania