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

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

Wstęp

Tym razem krót­ki arty­kuł na temat pew­nej cie­ka­wej kon­struk­cji. Została ona opi­sa­na przez Rebekę Wirfs-Brock w 1999 roku . Pomysł nie zdo­był sobie wte­dy raczej zbyt dużej popu­lar­no­ści, jed­nak obec­nie, w dobie wzor­ców opar­tych o mikro­ser­wi­sy i mikro apli­ka­cje, ma szan­sę wró­cić do łask. Ja sto­su­ję go już od dłuż­sze­go cza­su (patrz: pro­jek­to­wa­nie zorien­to­wa­ne na inter­fej­sy). Skróty HLD i LLD to odpo­wied­nio: High-Level Design (pro­jekt wyso­kie­go pozio­mu) i Low-Level Design (pro­jekt niskie­go pozio­mu). Są to pozio­my abs­trak­cji w mode­lu PIM. Jest to tak­że opis sty­lu pro­jek­to­wa­nia archi­tek­tu­ry sys­te­mu zorien­to­wa­ne­go na inter­fej­sy (archi­tek­tu­ra zorien­to­wa­na na interfejsy).

(wię­cej…)

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

Dlaczego nie używam poczty elektronicznej do komunikacji w projektach

Wstęp Od lat spotykam się w literaturze z zakresu zarządzania, z krytyką poczty elektronicznej jako narzędziem zarządzania czymkolwiek (patrz: Sabotaż...2013). Poczta elektroniczna (podobnie jak pakiety biurowe w ogóle) jest typowym przykładem maksymy: ułatwienie nie zawsze jest ulepszeniem. W kliencie poczty elektronicznej zarówno treść jak i sposób adresowania (co i do kogo, kopia, itp.) nie podlega żadnej standaryzacji ani restrykcji (poczta elektroniczna często służy do wyprowadzania danych z firmy). Jak dodać do tego fakt, że załączniki są niewidoczne w narzędziach do lokalnego wyszukiwania, że mamy na serwerach filtry antyspamowe których reguły…

Czytaj dalejDlaczego nie używam poczty elektronicznej do komunikacji w projektach

Opis wymagań z użyciem Gherkin – czyli duuużo korniszonów…

Wstęp

Zostałem nie­daw­no zapy­ta­ny czy pomo­gę bo mamy już ponad 150 przy­pad­ków uży­cia w doku­men­ta­cji…”. Myślę sobie, to nie­moż­li­we, nie ma tak wiel­kich sys­te­mów (wyce­na oka­za­ła się w efek­cie pię­cio­krot­nie zawy­żo­na tyl­ko dla­te­go, że uży­to meto­dy zorien­to­wa­nej na user story”). 

(wię­cej…)

Czytaj dalejOpis wymagań z użyciem Gherkin – czyli duuużo korniszonów…

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

I jak to wszyst­kim poka­zać żeby było czytelne?

Wstęp

Niedawno napi­sał do mnie czy­tel­nik pod jed­nym z artykułów:

Załóż­my, że reali­zu­je­my pro­ces biz­ne­so­wy: zarzą­dza­nie kur­sa­mi walut. W ramach pro­ce­su pra­cow­nik musi przy­go­to­wać plik csv zawie­ra­ją­cy wyłącz­nie listę słow­ni­ko­wą par walut (np. usdpln, eurpln, eurusd). Nazwa pli­ku to np bie­żą­cą data. Następnie systemX łączy się z API zewnętrz­nej plat­for­my i pobie­ra tabe­le kur­sów tych par walut (aktu­al­ne i histo­rycz­ne mie­siąc wstecz) i wysta­wia plik xls zawie­ra­ją­cy dane: nazwa pary walut, data kur­su, war­tość kur­sy) Plik ten sys­tem X wysy­ła do szy­by ESB. Szyna prze­sy­ła ten plik do systemuY. SystemY wyko­rzy­stu­je te dane do wyzna­cze­nia wewnętrz­nych kur­sów walut wg. usta­lo­ne­go mode­lu mate­ma­tycz­ne­go. Wynik obli­czeń odkła­da­ny jest w bazie danych tego sys­te­mu. Na koń­cu pro­ce­su jest pra­cow­nik, któ­ry wyko­rzy­stu­je te infor­ma­cje za pośred­nic­twem SystemuZ. Wybiera parę walut, okre­śla datę i sys­tem zwra­ca mu wewnętrz­ny kurs wyzna­czo­ny przez SystemY. Technicznie odby­wa się poprzez odpy­ta­nie sys­te­mu Y poprzez jego API. Czyli mamy SystemX, SystemY, SystemZ, pra­cow­ni­ka, szy­nę, plik csv, plix xls, 2XAPI no i prze­pływ danych (naj­pierw pli­ków, potem poszcze­gól­nych atry­bu­tów) . I jak to wszyst­kim poka­zać żeby było czy­tel­ne? (źr.: : Model poję­cio­wy, model danych, model dzie­dzi­ny sys­te­mu)

Prawdę mówiąc, mniej wię­cej w takiej for­mie dosta­je mate­ria­ły od moich klien­tów.. ;). Co może­my zro­bić? Pomyślałem, że dobry repre­zen­ta­tyw­ny przy­kład. Popatrzmy…

(wię­cej…)

Czytaj dalejI jak to wszyst­kim poka­zać żeby było czytelne?

Emocjonujące bramki czyli dogmaty vs. logika

W toku szko­leń, a tak­że audy­tów, powsta­ją nie raz spo­ry o inter­pre­ta­cje zna­cze­nia sym­bo­li nota­cji: ich seman­ty­ki i syn­tak­ty­ki (co ozna­cza­ją i jak je moż­na łączyć z inny­mi). Dzisiaj o dość czę­stym spo­rze czy­li bram­ki OR (inc­lu­si­ve) i XOR (exc­lu­si­ve) w nota­cji BPMN oraz o tym, że z 380 stron spe­cy­fi­ka­cji BPMN, w mode­lach ana­li­tycz­nych sto­su­je­my tyl­ko nie­ca­łe 40 stron roz­dzia­łu 7., pozo­sta­łe roz­dzia­ły słu­żą wyłącz­nie lep­sze­mu zro­zu­mie­niu teo­rii i mode­lom wyko­ny­wal­nym. Czyli dla­cze­go w ana­li­zach sto­su­je­my kil­ka, a nie kil­ka­dzie­siąt sym­bo­li nota­cji BPMN. 

(wię­cej…)

Czytaj dalejEmocjonujące bramki czyli dogmaty vs. logika

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

SPEM czyli Software & Systems Process Engineering

Tym razem arty­kuł adre­so­wa­ny do zaawan­so­wa­nych analityków. 

Ta spe­cy­fi­ka­cja (SPEM) jest dato­wa­na na 2008 rok. Stanowi sobą tło dla MDA oraz uza­sad­nia wzor­ce pro­jek­to­wa­ne opar­te na przy­pad­kach uży­cia (mikro­ser­wi­sy, Use Case 2.0, inne podob­ne). Podstawowa róż­ni­ca mię­dzy spe­cy­fi­ka­cją SPEM a spe­cy­fi­ka­cją UML pole­ga na tym, że UML to pro­fi­le MOF sta­no­wią­ce opi­sy nota­cji i sys­te­mów poję­cio­wych. SPEM to meta­mo­del pro­ce­su wytwór­cze­go opro­gra­mo­wa­nia czy­li gene­ral­ne zasa­dy budo­wa­nia pro­ce­sów wytwa­rza­nia i dostar­cza­nia oprogramowania. 

(wię­cej…)

Czytaj dalejSPEM czyli Software & Systems Process Engineering

Koniec treści

Nie ma więcej stron do załadowania