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

Modelowanie produkcji

Nie używamy notacji BPMN do modelowania tego co się dzieje na produkcji. Skoro nie BPMN to czego używamy? Wprowadzenie 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? Ten opis to procedura,…

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

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ę standardem…

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

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…

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
Read more about the article Business Knowledge Blueprints
Semiotic/Semantic Triangle in SBVR Terms

Business Knowledge Blueprints

Ronald G. Ross Ronald G. Ross jest autorem lub współautorem wielu opracowań na temat modeli pojęciowych i zarządzania wiedzą . Jest także współzałożycielem Business Rule Solution LLC, oraz współtwórcą specyfikacji i notacji SBVR . Książka Najnowsze z powyższych opracowań to rodzaj podsumowania pewnej części dorobku autora. Modele pojęciowe są często mylone z projektowaniem relacyjnego modelu danych, a bywa gorzej, gdy są utożsamiane z "modelem dziedziny systemu" w projektach dotyczących tworzenia aplikacji określanych jako"obiektowe". Książka traktuje o modelach pojęciowych, i autor definiuje je jako: model pojęciowy: uporządkowany zbiór pojęć i związków…

Czytaj dalejBusiness Knowledge Blueprints

Modelowanie architektury HLD i LLD usług aplikacji – modelowanie podsystemów

This time a short article about an interesting construction. It was described by Rebecca Wirfs-Brock in 1999 (Miller & Wirfs-Brock, 1999) . The idea did not gain much popularity at the time, but now, in the era of patterns based on microservices and micro applications, it has a chance to come back into favour. I've been using it for a long time (see interface-oriented design). The abbreviations HLD and LLD are High-Level Design and Low-Level Design, respectively. These are the levels of abstraction in the PIM model. It is also a description of the design style of an interface-oriented system architecture (interface-oriented architecture).

Czytaj dalejModelowanie architektury HLD i LLD usług aplikacji – modelowanie podsystemów

Koniec treści

Nie ma więcej stron do załadowania