Objektově orientované metasystémy


JUDr Jiří Duben, DIAS Praha
Národní obrany 45, 160 00 Praha 6
Tel. (02) 2431 3231 E-mail: jiri.duben@brailcom.cz

Abstract:
          The standard object orientation is to the software development, which solves only partial problems of the real world. The concept, structure and properties of the metasystem modelling exclusively real world objects and designated primarily to the reengineering of functions of systems, but enabling the smart transition to the conceptual and SW objects is presented. A progression and prerequisites in building an object oriented metasystem is recommended. There are some explaining graphic schemes and examples in the supplements.

1. Pojem metasystému
          Termín »metasystém«, původem z řečtiny, má v překladu význam "o systému", rozumí se informace o určitém systému. Chápání skutečnosti jako systému, tj. soustavy prvků ve vzájemných vazbách, je sice obecně ve vědě staršího data, ale pro tento způsob chápání skutečnosti se v historickém vývoji vžil termín »systémový přístup« především ve spojení se systémy zpracování dat a informací, nazývaných »informační systémy«. V této souvislosti pak vznikl termín »metainformační systém«., který se nyní obecně používá pro katalog (tj. seznam a charakteristiky) prvků datové základny (jednotlivých údajů) informačního systému.
          Pro účely reinženýringu1, jehož významnou součástí je racionalizace pracovních postupů a modernizace technologických prostředků, je však nezbytné vrátit se k původnímu významu a termínu »metasystém«. Nestačí totiž poznat jenom používané údaje, ale je nutné objektivně poznat i jejich účel, situaci při jejich vzniku, důvody a způsob využívání. Kromě toho metasystém musí umožnit názorné a srozumitelné návrhy změn ještě před jejich uskutečněním, musí být modelem jak současného tak budoucího optimalizovaného stavu systému.
          Metasystém nemůže tedy obsahovat jen popis datových prvků informačních systémů, nemůže být jen "metainformačním systémem" ve výše uvedeném smyslu. Metasystém musí být především zobrazením procesů v systému probíhajících jako předpoklad racionalizace a modernizace; v tomto rámci bude ovšem obsahovat také popis datového obsahu komunikačních vazeb (dotazů a odpovědí).
          Jako takový samozřejmě umožní pracovat se záznamy ("metainformacemi") o procesech v systému a v nich používaných údajích. Avšak používat v této souvislosti termín "metainformační systém« by bylo konfuzní (zmatečné, zavádějící) právě s ohledem na historický vývoj, popsaný v předchozím odstavci.
          Místo termínu »MetaSystém« budeme v dalším textu používat zkratku »MS«

2. Co je objektová orientace MS
          Termín »Objektová orientace« (či »objektový přístup«) vznikl původně jako nástroj konstrukce softwarových systémů (dále jen F). Hlavní výhodou byla přehlednost, snadnější údržba a vícenásobné využívání programů.
          Spolu s poznáním, že SW je v podstatě nástrojem pro obsluhu potřeb reálného světa, byl koncem 80. let přenesen objektový přístup (orientace) i do popisu reálného světa, aby byla překlenuta tzv. sémantická mezera, tj. obtížné a nepřesné dorozumívání mezi návrháři a programátory software na jedné straně a uživateli počítačových informačních systémů na straně druhé.
          Konstruktéři SW znají především své nástroje, zatímco uživatelé vidí své úkoly - agendy. Sémantickou mezeru názorně ukazuje Schéma č. 1 na str.6
          Mluvíme-li tedy o objektově orientovaných MS pro účely reinženýringu 1, máme na zřeteli pouze objekty reálného světa (RWO). Konceptuální (CSO) a softwarové (SWO) objekty se používají pouze v objektových modelech dílčích problémů systému (podrobněji níže).

3. Metasystém - nástroj dorozumívání
          Zatímco objektový přístup je prostředkem překonání sémantické mezery v zájmu lepšího a snadnějšího dorozumění mezi tvůrci SW systémů (návrháři a programátory) a provozovateli SW,
          při reinženýringu jakéhokoli funkčního systému je MS objektů reálného světa nástrojem dorozumívání vedoucích i provozních pracovníků a systémových analytiků. Důvody jsou zřejmé:
          Systémová analýza a design (dále jen SA/SD) racionalizovaného (optimalizovaného) systému jako celku totiž probíhá na vyšší funkční úrovni zúčastněných lidí a také trvá déle a obsahuje větší objemy dokumentace, než konstrukce SW, který řeší jednotlivé problémy, nikoli systém jako celek. Proto je k překonání těchto skutečností nezbytný účinný a propracovaný nástroj, jímž je MS.
          Je samozřejmé, že také MS musí být objektově orientován. Schéma č. 2 na str. 6 ukazuje složité vazby, jimiž vzniká model systému jako celku a případně podklady pro software; současně ukazuje, jak je nutné, aby byla zachována jednotná technika vyjadřování - objektový přístup - všech lidí zúčastněných na reinženýringu celého provozního systému od racionalizačních úprav procesů až po modernizaci technologie procesů pomocí ICT2 včetně SW.
          Při konstrukci SW pro optimalizovaný funkční systém se používá MS jako model, z něhož se vyčlení dílčí technologické problémy a z nich se odvíjí další vytváření konceptuálních a nakonec softwarových objektů. Tento postup je natolik složitý a členitý, že přesahuje rámec tohoto příspěvku.

4. Charakteristiky funkčních systémů.
          Objektově orientovaný MS (dále jen OOMS) vychází následujícího z pojetí funkčních systémů, ať již jde o systémy ekonomické (business) nebo sociotechnické 3, zejména o veřejnou správu (dále VS).
          Funkční systém je vždy řízen pomocí informací, jak ukazuje Schéma č. 2 na str. 7 a Schéma č. 3 na str. 7; jeho součástí tedy vždy je také informační systém
          Informační systém je zrcadlem reálného systému - viz schémata ;
          je to zrcadlo, které má paměť a může tedy přijímat i vydávat informace o něm. Informační systém však zřídka bývá jednolitý celek, zpravidla je rozptýlen do dílčích subsystémů, obsahujících specializované údaje o různých objektech a jevech v reálném systému.
          Informace v informačním systému zobrazují stav reálného systému, a to buď faktický ("skutečný" tak, jak se v nich obráží) , a/nebo v budoucnosti žádoucí (u ekonomických systémů mluvíme o plánech, v systémech veřejné správy o právní úpravě správních procesů a chování VS vůči klientům).
          Hlavní rozdíl v řízení obou výše uvedených typů systémů, který ukazuje Schéma č. 3 na str.7, je v tom, že zatímco v business systémech jsou objektem řízení přímo entity reálného světa, systém VS řídí vztahy mezi entitami reálného světa. Existuje sedm tříd entit, jejichž vztahy upravuje právní řád a řídí veřejná správa, jak ukazuje Schéma č. 4 na str.7
          Z dosud uvedeného vyplývá, že pomocí OOMS je možno vyjádřit jakýkoli funkční systém, že však je vždy nutné uvážit typ reálného systému a způsob, jakým řídí procesy v reálném světě. Metodiku a notaci je vždy nutno poněkud přizpůsobit nejen zmíněným skutečnostem, ale i kapacitám a technickému vybavení analytických týmů a úrovni pracovníků analyzovaného systému.

5. Prvky a struktura OOMS
5.1 Obsahové prvky
 OOMS obsahuje následující prvky:
a) objekty v širším smyslu , tj. identifikovatelné a relativně uzavřené celky reálného světa.
          Ze zkušeností v modelování systémů reálného světa víme, že některé z nich jsou aktivní, vyznačující se tím, že reagují na podněty (události) a provádějí činnosti (aktivity = sled úkonů v čase, nebo akty = jednorázové účelové úkony), kdežto pasivní objekty jsou pouze předmětem činností aktivních objektů.
          Objekty reálného světa v řízeném systému, bývá zvykem pro výrazné odlišení označovat termínem »entity« ( příklad viz Schéma č. 4 na str. 7. Mohou být aktivní (působit události), ale většinou se pouze zobrazují v objektech OOMS.
          Aktivní objekty OOMS budeme dále rozlišovat (ikonami v diagramech) na:           Pasivní objekty OOMS (objekty v užším smyslu) jsou ostatní objekty; obvykle jsou to hmotné předměty, jako písemnosti, dokumenty a jiné typy informací, předávané mezi aktivními objekty.
b) vazby vytvářejí z objektů systém; můžeme rozlišit vazby: c) specifikace objektu nebo role, případně vazby: d) role - představuje specifický pohled na objekt, v němž může být spojen s různými atributy, případně datovými obsahy, a může procházet různými stavy. Odhalení téhož objektu za různými rolemi 4 může znamenat významný přínos ve zjednodušení správních agend.
e) události; změna stavu objektu nastává v důsledku nějaké vnější nebo vnitřní události (důsledek nějaké činnosti aktivního objektu v systému). Události a změny stavu objektů vytvářejí dynamiku chování systému.
Podrobnější výklad pojmů objektového modelování přesahuje rámec tohoto příspěvku

5.2 Formální struktura
          Modelovaným systémem bude podnik či nadpodnikový útvar nebo úřad (VPI 5), jako definovaný rámec systému, aby byla zajištěna konsistence a budoucí kompatibilita dalších modelových jednotek.
          Model (metasystém) systému jako celku je soustavou modelových jednotek a společného slovníku používaných termínů z problémové oblasti ( zkratka TERMS). Systém jako celek může být dále dekomponován na subsystémy, zahrnující několik modelových jednotek.
          Modelovou jednotkou je »agenda «, představující komplexní proces (soustava procesů, zajišťujících jednu z funkcí systému (v ekonomickém systému např. fakturace, evidence skladů, ve veřejné správě např. zajištění určité potřeby občanů, apod.).
          Struktura modelové jednotky - agendy má tuto skladbu:           Příklad tabulkového scénáře a diagramu 6 z oblasti veřejné správy je uveden v příloze.

5.3 Technická struktura
          Technickou strukturou se rozumí uspořádání počítačových souborů - databází jednotlivých modelovaných systémů, které obsahují záznamy o prvcích MS. Na tomto místě stačí konstatovat, že každý model systému tvoří archivní strom, v němž každá agenda je uložena ve verzi analýzy a aktuálního designu. Podrobnosti přesahují rámec příspěvku.

6. Vlastnosti OOMS
Na základě zkušeností, čerpaných z literatury i vlastních poznatků, musí OOMS mít následující vlastnosti:
  1. Musí umožňovat postupné rozšiřování a prohlubování v krocích tvorby, trvalou archivaci, aktualizaci podle potřeby, neboť je nástrojem racionalizace a modernizace, zkrátka reinženýringu VS.
  2. Musí vést k poznání "křižujících se procesů" v tom smyslu, že.lidé provádějí procesy, ale pracují ve funkcích. Tyhle dvě věci se pletou. Lidé ve skutečnosti hrají role v procesech, které však procházejí hranicemi různých organizačních útvarů. Toto poznání a zkušenost tvoří větší díl reinženýringu.
  3. Musí ukazovat, co lidé dělají, co rozhodují a na čem kooperují, nikoli jen data s nimiž pracují!
              Zde opět přežívá neblahý vliv minulosti IT - soustředění na data.
              Jsme v procesním businessu, ne v datovém businessu.
  4. Model musí mít nástroje k "sumarizování" či "shrnování" ("collapsing"), tj. zakrytí detailů znázorněním širšího procesu, ale nesmí modelovat to, co ve skutečnosti není. Reálné procesy jsou komplexní a zamotané, v reálném světě je nepořádek, chaos, daný historií. Velikou chybou dosavadního přístupu IT odborníků bylo, že po léta používali hierarchií, jakoby to byla jediná existující struktura skutečného světa. Jenže pomocí hierarchických struktur nelze popisovat organické věci, jako jsou provozní (business) procesy, existující také ve VS.
  5. Záznam modelu (notace) musí být vyjádřen v pojmech a terminologii, které lidé běžně používají.
              Jak jinak by vám mohli potvrdit, že "sedí"?
  6. Záznam modelu (notace)se musí vyjadřovat jednoznačně.
              Bude-li dvoj- nebo víceznačný, jak se pozná, co vlastně říká ?
  7. Záznam modelu (notace) musí dávat lidem jasný smysl.
              Objektový procesní model je o lidech a pro lidi. Když vyžaduje rozsáhlou interpretaci zkušenými analytiky, aby jej pochopili obyčejní lidé z provozu, je věc ztracena. Nemůžete-li model vysvětlit během 10 minut, pak není dobrý.
  8. Metoda a notace musí umožnit dva druhy modelů, které bychom mohli označit jako:           Je rozdíl mezi tím, co lidé dělají aktuálně, a tím co dělají efektivně. Např. když účtárna vystavuje fakturu, efektivně (abstraktně) dobývá peníze za dodané zboží nebo služby. Aktuálně provádí vkládání textu a čísel, tiskne fakturu, zajišťuje její odeslání atd.
  9. Metoda a notace musí umožnit zachycení vzorků (patterns) chování v procesech.
              Život je zcela nestrukturovaný, ale existují určité "pracovní jednice" (work items), plány, delegace odpovědnosti, periodické aktivity a kontrakty (vyžadování a poskytování služeb). jako vzorky chování. Některé procesy jsou založeny na cyklickém opakování, mnoho procesů je založeno na párování požadavků a odpovědí (reakcí) na ně.
              Všechny tyto vzorky jsou v základech procesů a když je rozpoznáme, ulehčí nám to práci na modelu. Zda bude vylepšený proces bude pracovat správně nebo ne, často závisí na tom, zda použijeme správný vzorek na daný proces.
              Odhalování a používání těchto vzorků je věc studia i praktické zkušenosti
              Existuje metoda modelování a technika notace 7 , která tyto požadavky splňuje.
              Ovšem nemůže zaručit, že všechny modelující týmy využijí všech jejích vlastností k vytvoření stejně dokonalého MS.

7. Předpoklady vytvoření MS
          lze shrnout přibližně do následujících bodů:
a) tvorba MS musí být podložena rozhodnutím nejvyššího vedení dané organizace / instituce
b) tvorba MS musí probíhat jako samostatný projekt podle zásad řízení projektů
c) příslušní vedoucí činitelé.musí být pověřeni pravomocemi a musí být stanovena odpovědnost
          Jako příklad uvádíme tabulku řídících činitelů z návrhu projektu OOMS veřejné správy:


d) musí být zajištěna údržba MS v aktuálním stavu, neboť smyslem MS je následná racionalizace (reinženýring) a modernizace postupně všech základních činnosti systému (např. zavedení čipové karty pro automatizaci sběru základních údajů, výkonnější SW apod.).
e) pro úspěch OOMS je bezpodmínečně nutné složení realizačních týmů:           potvrzují to nejen naše, ale i zahraniční zkušenosti firem, zabývajících se systémovou analýzou a designem systémů.
          Jako příklad uvádíme obdobnou tabulku realizačních funkcí pro tvorbu a údržbu MS:


f) realizační týmy musí být vybaveny příslušnými nástroji, zejména počítači (v síti ?) s příslušným software - vhodný CASE je nezbytný - podrobnosti přesahují rámec příspěvku.
g) je třeba postupovat v etapách:           Takový postup vede ke shromažďování zkušeností a zdokonalování dovedností ve vytváření a údržbě OOMS.

Schémata


Schéma č. 1 - Vyplnění sémantické mezery


Schéma č. 2 - Modelování reálného business systému a tvorba SW


Schéma č. 3 - Analogie i rozdíly v řízení ekonomických a sociotechnických systémů


Schéma č. 4 - Třídy entit reálného světa a jejich vztahy (předměty řízení VS)

          Na schématu jsou podtrženy názvy entit, pro které již v současnosti existují tzv. registry (katalogy).

Literatura: