Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- znalostni_baze:strucna_metodika_modelovani [2022/01/11 14:19] – Tomáš Šedivec
+++ znalostni_baze:strucna_metodika_modelovani [2023/01/20 16:00] (aktuální) – Tomáš Šedivec
@@ Řádek 1: / Řádek 1: @@
 ======Stručná metodika efektivního modelování======
-<wrap info>Koncový uživatel --> Definice pohledu/Viewpoint --> Pohled/Diagram --> Model --> Elementy, Vazby</wrap>
-Model je souhrn elementů a vazeb, nejčastěji reprezentovaný formou databáze. Pohledy a diagramy jsou grafická znázornění (obrázky) elementů a vazeb z modelu. Pohledy a diagramy jsou tvořeny na základě definic pohledů či také viewpointů. Definice pohledů odpovídají dobrým praxím prezentace různým skupinám koncových uživatelů.
-===== Pravidla modelování =====
-  * Model je ideálně jeden a popisuje potřebný výsek reality. Je možné tvořit i více modelů pro stejnou realitu, ale pak je nutné ctít stejná pravidla a interoperabilitu mezi modely.
-  * Vždy vím, pro koho (koncový uživatel) se model vytváří. Model je tvořen na základě potřeb konkrétních koncových uživatelů.
-  * 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 popsat (identifikovat) **přehledovou** podstatu modelového reality a jejího blízkého okolí.
-    * Cílem L1 je popsat (identifikovat) **základní** podstatu modelované reality a jejího blízkého okolí.
-    * Cílem L2 je popsat (identifikovat) **detailní** podstatu modelované reality a jejího blízkého okolí.
-  * Správně by každá identifikovaná část diagramu z L0 měla být vytvořena v separátním L1, L2 diagramu - detailnější pohled na identifikovanou oblast.
-  * 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/|https:%%//%%rpp-ais.egon.gov.cz/gen/agendy-detail/]] případně [[https://rpp-ais.egon.gov.cz/AISP/verejne/ovm-spuu/katalog-ovm|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 (Detail), 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.
-{{ :znalostni-baze:strucna_metodika.jpg?600 |}}
-===== Vzhled diagramu =====
-  * 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).
-==== Pojmenování diagramů ====
-  * **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|https:%%//%%pubs.opengroup.org/architecture/archimate3-doc/chap04.html#_Toc10045299]]
- ==== Byznys architektura ====
-=== Rozložení BA L0 vychází z metamodelu ===
-  * 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í.
-=== Rozložení BA L1 vychází z metamodelu ===
-{{ :znalostni-baze:strucna_metodika_1.png?600 |}}
-Výše uvedený diagram lze interpretovat:
-  -  **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í.
-  -  Ve 2. oblasti (případně v 1 vedle sebe) se vyskytují **role** a **byznys rozhraní** s vazbami dle metamodelu.
-  -   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.
-  -  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.
-  -  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é.
-==== Aplikační architektura ====
-=== Rozložení AA L0 vychází z metamodelu ===
-  * 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.
-=== Rozložení AA L1 vychází z metamodelu ===
-{{ :znalostni-baze:strucna_metodika_2.png?600 |}}
-Výše uvedený diagram lze interpretovat:
-  - **Aplikační služba** by měla být vždy v 1. oblasti, tedy vždy úplně nahoře diagramu.
-  -   Ve druhé oblasti elementů by měly být **aplikační rozhraní**
-  -   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.
-  -  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é.
-==== Technologická architektura ====
-=== Rozložení TA L0 vychází z metamodelu ===
-  * 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.
-=== Rozložení TA L1 vychází z metamodelu ===
-{{ :znalostni-baze:strucna_metodika_3.png?600 |}}
-Výše uvedený diagram lze interpretovat:
-  -   **Technologická služba** by měla být vždy v 1. oblasti, tedy vždy úplně nahoře diagramu.
-  -   Ve druhé oblasti by měla být **technologická rozhraní**
-  -   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..
-  -   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é.
-==== Komunikační architektura ====
-=== Rozložení IA L0 vychází z metamodelu ===
-  * 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 komunikační vrstvu architektury zkoumaného systému a jeho interakce s okolím.
-=== Rozložení TA L1 vychází z metamodelu ===
-{{ :znalostni-baze:strucna_metodika_4.png?600 |}}
-Výše uvedený diagram lze interpretovat:
-  -   **Technologická služba** by měla být vždy v 1. oblasti, tedy vždy úplně nahoře diagramu.
-  -   Ve druhé oblasti elementů by měla být **technologická rozhraní**
-  -   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.
-  -   Oblast se týká infrastruktury, sítí a spojení.
-  -   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é.
-==== Integrační schémata ====
-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:
-{{ :znalostni-baze:strucna_metodika_5.png?600 |}}
-Výše uvedený diagram lze interpretovat:
-  -   **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.
-    -    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.
-      -    To znamená, že bude existovat pouze bílá externí aplikační služba.
-    -     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.
-  -   Ve druhé oblasti je samotný zkoumaný systém (Systém A), případně ZR RPP, či jiný příklad.
-  -   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…