Stručná metodika efektivního modelování

Koncový uživatel –> Definice pohledu/Viewpoint –> Pohled/Diagram –> Model –> Elementy, Vazby

• Vždy vím, pro koho (koncový uživatel) se model vytváří. Podle jeho přání je model tvořen.
• Není vhodné modelovat všechno. Modeluje se jen ta část reality, kterou požaduje koncový uživatel.
• Model není výstup pro koncového uživatele, tím je diagram, který graficky ztvárňuje část modelu. To, jaký diagram pro koncového uživatele použít definuje on sám svými požadavky.
• Volit vhodné názvy elementů, používat již vytvořené elementy. Vhodně pojmenovávat element dle jejich povahy.
  • nevymýšlet si názvy elementů – koncový uživatel pak neví, o co jde
  • ctít legislativní pojmy
  • Nepoužívat zástupné/sdružující elementy "služby ZR PP" atd.
• Diagram musí být čitelný a pochopitelný i pro neznalého čtenáře konkrétní reality-
• Diagramy se vytvářejí v agregačních úrovní L0, L1 a L2.
  • Cílem L0 je přehledně popsat (identifikovat) základní podstatu modelového reality a jeho blízkého okolí.
  • Cílem L1 je přehledně popsat (identifikovat) detailnější podstatu modelované reality a jeho blízkého okolí.
    • POZOR! Správně by každá identifikovaná část diagramu z L0 měla být vytvořena v separátním L1 diagramu - detailnější pohled na identifikovanou oblast. Tvrzení totiž, že L1 je detailnější popis L0 vede k vytvoření tzv. "plachty" velkému diagramu, který se nevleze na A4.
• Vazby by se neměly křížit.
• Pro byznysovou architekturu využívat metainformační systém Registru práv a povinností a všechny údaje, které jsou veřejně dostupné. ZDROJ: https:%%//%%rpp-ais.egon.gov.cz/gen/agendy-detail/ případně https:%%//%%rpp-ais.egon.gov.cz/AISP/verejne/ovm-spuu/katalog-ovm
  • Agenda - byznys funkce
  • CR - jednotlivé procesy, které lze sdružit případně obecně obsáhnout v byznys funkci
  • Zákon - Kontrakt
  • Odběratelé - byznys aktéři, kteří využívají agendu (služby agendy).
  • Rozhraní - byznys interface, kterým se služby konzumují.
• Čtenář by měl číst modely od agregační úrovně od L0 (Přehled) přes L1 (Obsah) do L2 (Deatil), aby prvně pochopil smysl modelovaného systému a následně viděl detail.
• Používat grouping pro logické vyznačení klíčových částí (subvrstev) modelovaného systému.
• Pracovat s velikostí elementů. Velké elementy značí důležitý element, menší značí detailní, případně méně významný element. Pokud jsou elementy vnořovány do sebe, značí to hierarchii, nikoliv významnost.

• Všechny diagramy v různých architektonických doménách musí vycházet z metamodelu.
• Rozložení elementů na diagramu musí odpovídat metamodelu.
• Všechny elementy mohou vnořovat element stejného typu elementu
• Externí elementy by měly být vizualizovány bílou barvou. Externím elementem se myslí takový, který je potřeba zachytit v modelu, ale není ve scope koncového uživatele.

Diagram musí být vizuálně přehledný, to znamená:

• Diagram se čte zleva doprava a odshora dolů.
• Elementy stejného typu řadit pokud možno v jedné linii.
• Elementy stejné důležitosti musí mít stejnou velikost.
• Diagram by měl působit kompaktně a neměl by využívat prolínání vrstev.
• Mezi vrstvami se vyměňují služby, které jsou poskytovány pomocí rozhraní
• Vazby nesmí působit rušivým dojmem a je nutné ke každému diagramu přistupovat individuálně a vazby správně vést. Techniky pro zlepšení vzhledu vazeb:
  • Změnit barvu vazby na šedou (méně výrazná barva, než černá vazba).
  • Zalamovat vazby tak, aby obtékaly elementy z jedné strany.
  • Vazby neprotínají elementy, ale obtékají (obíhají) elementy.
  • Stejné typy vazeb mohou být ze zdroje vedeny přes/na sobě, aby se ušetřilo místo a rozvětveny budou vazby až u cílových elementů.
  • Vazby vytvořit do modelu a následně je skrýt a seskupením pod nějaký element zvýraznit logickou vazbu (pozor vazba musí existovat v modelu).

• Behaviorální elementy kulaté rohy elementů musí být nazývány průběhovým časem (musí být patrná činnost/chování). Příklad "Poskytování katalogu služeb", "Editování údajů". "Prodej zboží".
• Pasivní elementy - mohou být nazývány podstatným jménem "Dokument", "Faktura"
• Aktivní elementy - mohou být pojmenovány podstatným jménem "Jan Novák", Oddělení fakturace, Zákon 111/2009 Sb.

Co jsou aktivní/pasivní a behaviorální elementy je možno zjistit ve specifikaci ArchiMate https:%%//%%pubs.opengroup.org/architecture/archimate3-doc/chap04.html#_Toc10045299

• Diagram L0 má prezentovat systém jako celek a ukázat jak je zasazen do svého okolí.
• Diagram L0 musí obsahovat hlavní službu(y), jejich realizátorem je systém a konzumenti.
• Diagram by neměl obsahovat vnořené elementy (zanořené elementy kompozicí, agregací, přiřazením, realizací).
• Diagram by měl minimálně obsahovat klíčově aktéry a jejich role s vazbou na byznys službu a všechny agendy a hlavní zákon (contract).
• Hlavní legislativní předpis (zákon) podle kterého zkoumaný systém funguje.
• Součástí diagramu by měli být i okolní aktéři s vyjádřením, jak se systémem interagují.

  Výše uvedený diagram lze interpretovat:

1. Byznys Aktor je vždy v horní části diagramu. V této oblasti by měly být všechny byznys aktéři popsání.
2. Ve 2. oblasti (případně v 1 vedle sebe) se vyskytují role a byznys rozhraní s vazbami dle metamodelu.
3. Oblast obsahuje behaviorální elementy a zde je potřeba pracovat vytvořit diagram tak, aby se nejednalo o "spletenec" vazeb, ale aby byl diagram čitelný a současně se na něm vyskytovaly klíčové elementy SLUŽBA, PROCES a FUNKCE ostatní elementy z této oblasti nejsou významné, ale autor je může použít.
4. Tato oblast by měla obsahovat agendu případně produkt, který vytváří služba. Tyto elementy z metamodelu by měly být ve stejné linii jako oblast 3.
5. Poslední oblast obsahuje pasivní prvky a vždy je v dolní části diagramu.

  Výjimky jsou povoleny, pokud aplikování výjimky přispěje k čitelnosti diagramu.

Oranžově zvýrazněné elementy jsou doporučené nepoužívat a spíše modelovanou skutečnost vyjádřit neoranžovým elementem, pokud je to možné.

• Diagram by neměl obsahovat vnořené elementy (zanořené elementy kompozicí, agregací, přiřazením, realizací).
• Diagram by měl minimálně obsahovat klíčově aplikační komponenty jejich služby.
• Součástí diagramu by měly být i okolní (externí) aplikační systémy/služby.

  Výše uvedený diagram lze interpretovat:

1. Aplikační služba by měla být vždy v 1. oblasti, tedy vždy úplně nahoře diagramu.
2. Ve druhé oblasti elementů by měly být aplikační rozhraní
3. Stěžejní část diagramu obsahuje aplikační komponenty a k ní přiřazené aplikační funkce. Tyto aplikační funkce musí být vnořeny do aplikační komponenty, aby bylo zřejmé, které funkce patří do které aplikační komponenty. Diagram aplikační funkci vnořenou nemá pro znázornění vazby.
4. Poslední oblastí jsou pasivní elementy, tedy datové objekty.

  Výjimky jsou povoleny, pokud aplikování výjimky přispěje k čitelnosti diagramu.

Oranžově zvýrazněné elementy jsou doporučené nepoužívat a spíše modelovanou skutečnost vyjádřit neoranžovým elementem, pokud je to možné.

• Diagram by neměl obsahovat vnořené elementy (zanořené elementy kompozicí, agregací, přiřazením, realizací).
• Diagram by měl minimálně obsahovat klíčově Uzly jejich služby.
• Součástí diagramu by měly být i okolní (externí) technologické služby.
• L0 ukazuje náhled na technologickou vrstvu architektury zkoumaného systému a jeho interakce s okolím.

Výše uvedený diagram lze interpretovat:

1. Technologická služba by měla být vždy v 1. oblasti, tedy vždy úplně nahoře diagramu.
2. Ve druhé oblasti by měla být technologická rozhraní
3. Stěžejní část diagramu obsahuje uzly a k ní přiřazené technologické funkce, zařízení a systémový software. Tyto elementy by měly být vnořeny do uzlu, aby bylo zřejmé, které funkce, zařízení a systémový software patří do kterého uzlu. Diagram technologickou funkci, zařízení a systémový software vnořené nemá pro znázornění vazeb..
4. Poslední oblastí jsou pasivní elementy, tedy artefakty, které vždy jsou ve spodní části diagramu.

  Výjimky jsou povoleny,pokud aplikování výjimky přispěje k čitelnosti diagramu.

Oranžově zvýrazněné elementy jsou doporučené nepoužívat a spíše modelovanou skutečnost vyjádřit neoranžovým elementem, pokud je to možné.

• Diagram by neměl obsahovat vnořené elementy (zanořené elementy kompozicí, agregací, přiřazením, realizací).
• Diagram by měl minimálně obsahovat klíčově Uzly jejich služby, síť a lokaci.
• Součástí diagramu by měly být i okolní (externí) technologické služby.
• L0 ukazuje náhled na infrastrukturní vrstvu architektury zkoumaného systému a jeho interakce s okolím.

Výše uvedený diagram lze interpretovat:

1. Technologická služba by měla být vždy v 1. oblasti, tedy vždy úplně nahoře diagramu.
2. Ve druhé oblasti elementů by měla být technologická rozhraní
3. Stěžejní část diagramu obsahuje uzly a k ní přiřazené technologické funkce, zařízení. Tyto elementy by měly být vnořeny do uzlu, aby bylo zřejmé, které funkce, zařízení patří do kterého uzlu. Diagram technologickou funkci a zařízení vnořené nemá pro znázornění vazeb.
4. Oblast se týká infrastruktury, sítí a spojení.
5. Poslední oblastí jsou elementy vyznačující prostředí, lokalitu a umístění. Tyto elementy jsou vždy ve spodní části diagramu.

  Výjimky jsou povoleny, pokud aplikování výjimky přispěje k čitelnosti diagramu.

Oranžově zvýrazněné elementy jsou doporučené nepoužívat a spíše modelovanou skutečnost vyjádřit neoranžovým elementem, pokud je to možné.

Pokud na diagramu chci naznačit, že Systém A má integraci (vazbu) na jiný systém externí a současně na jiný systém v rámci organizace, vzhled diagramu by měl vypadat dle návrhu:

Výše uvedený diagram lze interpretovat:

1. Externí systém včetně služeb. Ne vždy je nutné modelovat externí systém včetně služeb, nebo včetně aplikačních komponent.
   1. Preference je využít VAR1, tedy bude existovat externí služba, kterou Systém A využívá. Tuto službu realizuje Externí systém Z, který na diagramu nemusí být naznačen.
      1. To znamená, že bude existovat pouze bílá externí aplikační služba.
   2. Méně preferované, ale je VAR2, který je opakem VAR1, tedy externí systém a jeho integrace je vázána přes aplikační komponentu nikoliv službu.
2. Ve druhé oblasti je samotný zkoumaný systém (Systém A), případně ZR RPP, či jiný příklad.
3. Třetí oblast zobrazuje okolní systémy v rámci zkoumané organizace/systému, tedy Systémy B a C, např. Editoři RPP, atd…