OntoUML a UFO-A pro softwarové inženýrství

OntoUML a UFO-A pro softwarové inženýrství No Author Given No Institute Given

Abstrakt OntoUML je rozšířením známé notace UML o prvky ontologickyorientovaného konceptuálního modelování. Díky zjemnění kategorizace různých typů entit a zpřesnění jejich definice nabízí diagramy v OntoUML mnohem vyšší výrazovost v oblasti konceptuálního modelování. Tento příspěvek shrnuje hlavní principy a koncepty OntoUML ve vztahu k využití OntoUML při vývoji informačních systémů. V příspěvku jsou ilustrovány výhody vyššív výrazovosti OntoUML na příkladu a jsou též diskutovány další aspekty využití OntoUML v softwarovém inženýrství, jako transformace na implementační model a přísliby dalšího rozvoje. Zmíněny jsou též současné překážky širšího rozšíření OntoUML mezi odbornou veřejností. Keywords: ontologické modelování, OntoUML, softwarové inženýrství, vývoj informačních systémů

1

Úvod

Proces vývoje složitějšího informačního či znalostního systému (business information system, BIS) sestává z řady na sebe navazujících činností [1]. Pokud budeme předpokládat, že požadavky již byly formulovány a je nastavena potřebná infrastruktura projektu, potom k realizaci softwarového díla (tj. neuvažujeme navazující fáze testování, nasazení, správy a podpory) vedou následující tři klíčové fáze: 1. Analýza, 2. Návrh, 3. Implementace.

Implementační model

Konceptuální model

Požadavky

Analýza

Návrh

Kód

Implementace

Obrázek 1. Zjednodušený model softwarového vývojového procesu ukazující klíčové artefakty předávané mezi fázemi

Obr. 1 ukazuje, že mezi fázemi jsou předávány artefakty jako vstupy a výstupy. Kvalita vstupních artefaktů významně ovlivňuje úspěšnost fáze – z nekvalitních analytických podkladů nelze vytvořit kvalitní návrh a z nekvalitního návrhu nelze vytvořit kvalitní implementaci1 . Kvalita je ovlivňována především těmito dvěma faktory: – Kvalitou notace použité pro modelování – viz [4]. – Zachování informace při přechodu mezi fázemi – viz [7]. V tomto příspěvku se budeme zabývat především kvalitou výstupů Analýzy, konkrétně strukturálním modelem. Dále budeme diskutovat Návrh, konkrétně transformaci konceptuálního strukturálního modelu na implementační strukturální model.

2

Cíl a metodika

Cílem příspěvku je nastínit možnosti a výhody využití notace OntoUML pro konceptuální modelování business informačních systémů. V příspěvku se budeme věnovat výhradně strukturálním modelům. Dalším cílem je nastínit problematiku transformace OntoUML do implementačních modelů, konkrétně do čistého objektově-orientovaného modelu. Cílem příspěvku je též krátce představit notaci OntoUML, která zatím není mezi širokou odbornou veřejností příliš známa, a též současné překážky širšího rozšíření. V příspěvku krátce představíme vznik a strukturu OntoUML, představíme základní pilíře, principy a kategorie typů. Vyšší výrazovost OntoUML budeme demonstrovat na konkrétním příkladu porovnání kusu modelu v UML a OntoUML.

3

Vznik OntoUML

OntoUML vzniklo jakožto snaha o praktické spojení ontologické analýzy a konceptuálního modelování. Jeho cílem je nabídnout analytikovi sadu různých typů entit přesně definovaných vlastností, pomocí kterých lze velmi exaktně modelovat realitu. OntoUML vychází z poznatků Cognitive Science o charakteru a specifikách našeho vnímání a současně pevně stojí na aparátu modální logiky a matematických základech logiky, množin a relací. Syntakticky je postaveno nad notací třídních diagramů UML [2], kterou doplňuje o nové koncepty formou stereotypů, formálně je tedy v souladu s metamodelem UML [6], což přináší možnosti využívat stávající CASE nástroje, nástroje pro prezentaci, transformaci a výměnu dat, apod. Oproti jiným snahám o rozšíření UML o konceptuální prvky je však vybudováno zcela od základů a představuje samostatný úplný systém nezávislý na původních elementech UML. Některé využívá (např. třídy), 1

Kvalitu zde chápeme v souladu s ISO 9000, tj. jako „míru splnění požadavků zákazníkaÿ.

řady konceptuálně problematických elementů se však zříká (např. agregace a kompozice) a nahrazuje je vlastními, ontologicky čistými verzemi. OntoUML bylo poprvé uceleně publikováno v disertační práci Dr. Giancarla Guizzardiho, kterou obhájil s nejvyššími poctami v r. 2005 na univerzitě v Twente, a která vyšla formou monografie [4]. Od té doby patří Dr. Guizzardi mezi nejaktivnější vědce a autory zabývající se konceptuálním modelováním a je hostem či členem programových výborů nejvýznamnějších konferencí v této oblasti2 . Dr. Guizzardi působí na Federální univerzitě Ducha Svatého v Brazilské Vittorii, kde vede výzkumnou skupinu NEMO. Pomocí OntoUML jsou vybudovány tzv. základní ontologie (Foundational Ontologies) pro různé oblasti, tzv. UFO (Unified Foundational Ontology): UFO-A: Strukturální aspekty reality – Objekty, jejich typy, podčásti, role, které hrají, . . . UFO-B: Dynamické aspekty – Události, jejich části a vazby mezi nimi, participace objektů v událostech, časové chování, . . . UFO-C: Sociální aspekty – Vybudováno nad UFO-A a UFO-B, zabývá se agenty, stavy, cíly, akcemi, normami, sociálními úmluvami a vztahy, apod. UFO-A je považováno za hotové a je též prověřeno v řadě projektů v praxi, neočekává se tedy další významný vývoj a rozšiřování. Oproti tomu UFO-B a UFO-C jsou nyní předmětem intenzivního vývoje. OntoUML a UFO však nejsou pouze vědecky zajímavé, nýbrž byly již úspěšně použity v rozsáhlých projektech, např. Off-Shore Software Development, konceptuální analýza pro velkou petrolejářskou firmu, v projektech v oblasti telekomunikací a Media Content Management.

4

Základní principy OntoUML

Dále se tedy budeme zabývat výhradně UFO-A. Termínem OntoUML budeme tedy označovat notaci plus UFO-A, tedy strukturální aspekty, jež umožňují vytvářet statické modely struktur. 4.1

Kategorie typů entit

Jak již bylo uvedeno, OntoUML důsledně rozlišuje různé kategorie entit v naší realitě. Ukázka části typové hierarchie je na obr. 2. Jednotlivé kategorie typů jsou vymezeny podle přesných kritérií: Identita – zda-li typ poskytuje či vůbec má ontologickou identitu. Typy, které identitu neposkytují, ale mají, ji dědí od svých nadtypů. 2

Stránky Dr. Guizzardiho [3] obsahují seznam všech publikací a řada z nich je k dispozici i ke stažení.

!"#$"%&$"'%#()*'%+(,-./&$(012/#

{Person}

{Brazilian, Man, Woman}

{Teenager,! {Student,! {Physical Object} {Student, {Teenager, LivingPerson} Husband} Husband} LivingPerson}

{Customer}

{Insurable Item}

Obrázek 2. Ukázka hierarchie typů entit v OntoUML UFO-A

Rigidita – charakterizuje neměnnost či proměnlivost typu. Pro definice OntoUML využívá modální logiku, která zavádí operátory „nutnostÿ a „možnostÿ v rámci času a prostoru – modální logika hovoří obecně v pojmu svět. Hovoříme o rigiditě, anti-rigiditě a non-rigiditě, která je negací rigidity. Na základě toho potom rozlišujeme rigidní, anti-rigidní a semi-rigidní typy (pro některé instance rigidní, pro jiné non-rigidní). Relační závislost – umožňuje specifikovat, že typ může existovat pouze za současné existence vazby na jiný typ.

!"##$%$&'()*'$+,%"$-(,#(./0$1'(234$Tabulka na obr. 3 shrnuje vlastnosti různých kategorií typů entit z obr. 2. Category of Type

Supply Identity

Identity

Rigidity

Dependence

SORTAL

-

+

« kind »

+

+

+

-

« subkind » « role »

-

+

+

-

-

+

-

+

-

-

« phase »

-

+

NON-SORTAL

-

-

« category »

-

-

+

-

« roleMixin »

-

-

-

+

« mixin »

-

-

~

-

Obrázek 3. Ukázka hierarchie typů entit v OntoUML UFO-A

Přesné rozlišování kategorií typů má v softwarovém inženýrství značný praktický význam. Obr. 4 obsahuje porovnání části UML class modelu osob na uni-

Obrázek 4. Příklad stejného modelu v UML a OntoUML

verzitě a odpovídající OntoUML verzi s přesným vymezením kategorií typů entit. V čistém UML modelu chybí řada informací, které potom mohou vést k chybnému návrhu: – Studenta a zaměstnance namodelujeme v OntoUML jakožto anti-rigidní typ <>, čímž říkáme, že osoba se zaměstnancem může stát a může jím přestat být bez ztráty své identity. To samé platí pro studenta. Navíc rolí může mít Osoba vícero najednou. Zjednodušený model v UML vede na rigidní implementaci a student nemůže být současně zaměstnancem a naopak (jsou to dvě oddělené entity)3 . – Role dědí v OntoUML identitu od typu Kind, tudíž Osoba se může stávat i přestávat být studentem či zaměstnancem bez ztráty identity. V UML modelu mají Student i Zaměstnanec vlastní identitu, student, který dostuduje a stane se zaměstnancem, tak ztratí všechnu svoji historii. – Podobně Fáze <> je anti-rigidní, tj. zaměstnanec může přecházet mezi stavy pojištěného zaměstnance a nepojištěného zaměstnance. Oproti rolím, kterých může mít člověk vícero, fázi může mít v daný okamžik pouze jednu. Rigidní model v UML opět neumožňuje přecházet mezi pojištěným a nepojištěným stavem. V UML bychom tuto situaci mohli částečně obejít nepovinnou vazbou Zaměstnanec-Pojištění, nebyli bychom pak ale schopni modelovat polymorfně Zaměstnance na základě pojištění – v OntoUML např. můžeme udělat vazbu od Pojištěný zaměstnanec ke služebnímu 3

Existují samozřejmě implementační řešení, která tento i další problémy řeší, zde se však bavíme o vyjádření těchto vlastností na strukturální konceptuální úrovni dle pravidla, že konceptuální model by měl být maximálně úplný.

autu, čímž vyloučíme, aby vůz řídil nepojištěný zaměstnanec. Toto omezení nejsme ve strukturálním UML modelu schopni vyjádřit4 . – Role je v OntoUML relačně závislý typ, tudíž musí existovat entita, ke které má role vazbu s minimální multiplicitou 1. To analytika vede k zamyšlení, co je skutkovou podstatou vzniku role (angl. „truthmakerÿ) a nezapomene tuto navázanou entitu do modelu uvést. V UML modelu žádné takové vodítko nemáme. 4.2

Vztahy celek-část

OntoUML se dále podrobně zabývá problematikou vztahů celek-část, která je v UML v podobě kompozice a agregace definována značně nejasně a neúplně. OntoUML zavádí různé typy povinnosti vztahů celek-část, a to jak pro celek, tak pro část. Zanedbání těchto nuancí v konceptuálním modelu opět vede k absenci důležitých informací při návrhu a implementaci. Typy povinnosti z hlediska celku Různé typy povinnosti z hlediska celku přináší obr. 5.

Obrázek 5. Typy povinnosti z hlediska celku

Nepovinná část (Optional Part) – část není pro celek povinná, celek může existovat bez ní. Povinná část (Mandatory Part) – část je pro celek povinná, může se však měnit instance části. Příkladem může být vztah Člověk-Srdce: člověk musí mít srdce, srdce však lze transplantovat, tj. vyměnit jeho instanci za jinou. Podobným příkladem může být motor v automobilu. Esenciální část (Essential Part) – část je pro celek povinná, navíc je esenciální: část nelze vyměnit za jinou instanci. Došlo by ke zničení celku či ztrátě jeho identity. Příkladem může být mozek člověka, nebo karosérie automobilu 4

Řešením v UML je podobná omezení vyjádřit v jazyku OCL, což je ale opět řešení „mimo diagramÿ.

– karoserie obsahuje jednoznačný identifikátor vozidla VIN a nelze ji tedy vyměnit bez ztráty identity vozidla. Typy povinnosti z hlediska části Různé typy povinnosti z hlediska části přináší obr. 6.

Obrázek 6. Typy povinnosti z hlediska části

Nepovinný celek (Optional Whole) – část může existovat i sama, bez celku. Povinný celek (Mandatory Whole) – část musí být částí celku (sama existovat nemůže), může však být přeřazena k jiné instanci celku. Příkladem může být opět srdce, které není schopno samo fungovat, lze jej však transplantovat. Neoddělitelná část (Inseparable Part) – část musí být po celou svou životnost částí právě jedné instance celku. Příkladem může být opět mozek, který nelze transplantovat. U anti-rigidních typů pak vyvstává otázka, jestli podčást anti-rigidního celku jej musí doprovázet v té samé instanci ve všech světech. Pokud ano, jedná se o neměnitelnou část (Immutable Part). Opačným směrem pak hovoříme o neměnitelném celku (Immutable Whole). Dále OntoUML rozlišuje, jestli je část sdílitelná (shareable), tj. jestli může být částí vícero celků:

V

&

– Plný symbol či stereotyp {isShareable = false} . . . nesdílitelná část. – Prázdný symbol či stereotyp {isShareable = true} . . . sdílitelná část. Klíčový je fakt, že všechny tři dimenze: typy povinnosti z hlediska celku, typy povinnosti z hlediska části a sdílení jsou na sobě nezávislé a možné jsou tedy všechny kombinace. 4.3

Typy vztahů celek-část

OntoUML rozlišuje několik typů vztahů celek-část, které se liší svými vlastnostmi, především tranzitivitou:

Kvantita (Quantity) – Celek je složen z částí, které jsou stejného typu jako on sám. – Části jsou nekonečně dělitelné. – Relace SubQuantityOf: alkohol-víno, cukr-káva, písek v kyblíku, . . . Kolektiv (Collective) – – – –

Celek je složen z částí, které nejsou stejného typu jako on sám. Kolektiv není nekonečně dělitelný. Všechny prvky hrají v kolektivu stejnou roli. Rozlišujeme relaci podkolektiv a člen: • relace MemberOf: strom-les, student-paralelka, pták-hejno, . . . • relace SubCollectionOf: severní cíp lesa-les, studenti s vyznamenánímstudenti, vadné součástky-součástky, . . .

Funkční celek (Functional Entity) – Skládá se z částí, které mají různé úlohy. – Relace ComponentOf: srdce-oběhový systém, ředitel-firma, motor-automobil, ...

4.4

Ostatní části UFO-A

UFO-A se dále podobně důkladně zabývá asociacemi, aspekty (objekty existenčně závislé na jiných), kvalitami (měřitelné atributy) a jejich doménami a též speciálními situacemi jako redefinicí a různými vztahy „specializaceÿ.

5

Diskuse a závěr

OntoUML a UFO jakožto nástroje ontologicky orientovaného konceptuálního modelování mají široké uplatnění ve všech oblastech, kde je třeba přenášet velmi přesný mentální model, tedy při: – výměně informací, – definici pojmů a vztahů (právní předpisy), – integraci informací (informační a znalostní inženýrství, business intelligence, e-government), – integraci služeb a komponent (heterogenní prostředí). Softwarové inženýrství je disciplína, kde výměna informací je klíčová pro úspěch projektu, tedy dodání systému odpovídajícího požadavkům zákazníka (viz též obr. 1). OntoUML a UFO poskytuje výrazně vyšší výrazovost a přesnost strukturálních modelů oproti tradičním UML diagramům. Z hlediska cíle softwarově-inženýrských modelů, tedy implementace do programového kódu, lze poté konstatovat některá specifika pro používání OntoUML.

5.1

Důležité koncepty

Z naší zkušenosti softwarový inženýr většinou vystačí s podmnožinou možností OntoUML. Jako vysoce přínosné hodnotíme tyto koncepty: – Rozlišování kategorií a podkategorií typů objektů Sortals a Non-Sortals (Kind, Subkind, Role, Phase, Category, RoleMixin, Mixin). – Rozlišování typů povinností vztahů celek-část. – Rozlišování různých typů vztahů celek-část. – Rozlišování materiálních a formálních relací. – Rozlišování typů kategorií aspektů (Kvality a Módy). U uvedených konceptů softwarový inženýr vystačí typicky se základními definicemi a vlastnostmi – např. u problematiky vztahů celek-část Dr. Guizzardi zachází poměrně hluboko do teorií mereologie, které nepovažujeme za nutné pro praxi softwarového inženýrství. 5.2

Transformace na implementační model

Zatímco v případě čistě konceptuálních analýz je konceptuální model výstupem práce, v softwarovém inženýrství je teprve jedním z prvních vstupů do procesu (viz obr. 1). Implementace systému na základě konceptuálního modelu OntoUML a doplňkových informací a pravidel, které nebylo možno v modelu zachytit (plus samozřejmě příslušné modely chování, stavů, apod.), je možná, nicméně sémantická mezera mezi konceptuálním modelem OntoUML a programovým kódem je značná a hrozí tak ztráta informace při transformaci. Implementace navíc vyžaduje určité doplňkové informace, které v konceptuálním modelu obsaženy nejsou – typicky směry navigace mezi entitami, které jsou důležité pro optimalizaci systému z hlediska dotazů, aktualizací struktur apod. Z tohoto důvodu se nám osvědčuje vytvořit implementační model a ten poté (již s podstatně menší sémantickou mezerou) transformovat na kód. Zabýváme se nyní na našem pracovišti čistě objektově-orientovaným modelem, který zahrnuje třídy, atributy, metody, dědění a skládání. Transformací konceptuální model samozřejmě ontologicky zdegeneruje, při implementaci je tedy třeba konzultovat i původní konceptuální strukturální model (a samozřejmě ostatní modely). Další možnosti představuje transformace na relační model: tím se již do určité míry zabývala i skupina NEMO, výsledky však bohužel nejsou veřejně dostupné, jelikož se jednalo o komerční projekt. Zde je situace složitější než v čistém objektovém modelu, relační model dat je třeba vhodně doplnit a ošetřit aplikační logikou (např. PL-SQL). 5.3

Překážky masivnější adopce OntoUML

Je nutné konstatovat, že zde v současnosti existují nemalé bariéry masivnějšího rozšíření OntoUML. Mezi ně patří zejména:

– – – – –

Nedostatek literatury a informačních zdrojů. Mizivé množství široce dostupných příkladů a případových studií. Absence kurzů a tréninkových programů. Obtížně dostupná podpora a komunita. Absence CASE nástrojů.

Nedostatek literatury a informačních zdrojů. Prakticky jedinou ucelenou široce dostupnou publikací o OntoUML je v současnosti disertační práce Dr. Guizzardiho [4]. Jedná se o špičkovou vědeckou práci, avšak pro širokou veřejnost poměrně hutné čtení. Práce navíc neobsahuje kompletní současné OntoUML, další části je třeba nastudovat z příspěvků z konferencí. Vše samozřejmě v angličtině. Prakticky nulový počet široce dostupných příkladů a případových studií. Jak bylo zmíněno, v OntoUML byla již realizována řada úspěšných projektů, ty však vzhledem ke svému komerčnímu charakteru a citlivosti obchodních údajů nejsou zveřejněny. Několik případových studií bylo zveřejněno v příspěvcích (viz [3]), nejedná se však o množství a rozsah potřebný k širší edukaci. Absence kurzů a tréninkových programů . OntoUML je samozřejmě vyučováno na mateřské univerzitě Dr. Guizzardiho a též na několika univerzitách v Holandsku. Neexistují však komerční kurzy pro širší veřejnost. Obtížně dostupná podpora a malá komunita. Dr. Guizzardi a tým NEMO jsou velmi ochotní a rádi se o své know-how se zájemci dělí, ovšem pro masovější rozšíření je třeba rozvíjení široké komunity profesionálů v OntoUML, kde by praktikant našel zdroje, rady a tipy a odpovědi na každodenní otázky. Absence CASE nástrojů. V současnosti je k dispozici CASE nástroj na platformě Eclipse, jenž vznikl jako diplomová práce diplomanta Dr. Guizzardiho. Nástroj podporuje všechny koncepty UFO-A a dokonce je schopen hlídat porušení omezení a pravidel OntoUML při modelování a radit uživateli. Nástroj však bohužel není dále rozvíjen a k praktickému nasazení v softwarovém inženýrství chybí řada funkcí. OntoUML je možné díky již zmíněné kompatibilitě s notací UML využívat i ve stávajících UML nástrojích, ovšem bez podpory sémantiky OntoUML. 5.4

Další možnosti a výhledy

Tým NEMO nyní intenzivně pracuje na software, jež umožní simulovat chování entit ve strukturálním diagramu. Takovýto nástroj by softwarovému inženýrovi mohl umožnit verifikovat vytvořený model a validovat jej se zákazníkem de-facto formou předvedení prototypu chování jeho struktur.

Dopracování pravidel transformace na různé implementační modely a jejich realizace v nějakém CASE nástroji by poskytla mocný způsob rapid developmentu, zvýšení flexibility úprav a zajištění konzistence model-implementace. Tuto transformaci však nebude nejspíš možné zcela automatizovat, nýbrž pouze poloautomatizovat a poskytnout komfortní nástroje. S pokračujícími pracemi na UFO-B bude též zajímavé začít se zabývat možnostmi modelování diagramů dynamického chování informačních systémů v OntoUML. Ačkoliv existuje řada metodik a notací pro procesní modelování, situace je zde obdobná jako u strukturálních modelů: z ontologického hlediska jsou více či méně nevyhovující (viz např. analýza BPMN z hlediska ontologické čistoty, [5]).

Reference 1. Beck, K.: Process Patterns: Building Large-Scale Systems Using Object Technology. Cambridge University Press (1998) 2. Fowler, M.: UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley Professional, 3rd edition edn. (2003) 3. Guizzardi, G.: Homepage, http://nemo.inf.ufes.br/gguizzardi 4. Guizzardi, G.: Ontological Foundations for Structural Conceptual Models. Telematica Instituut Fundamental Research Series (2005) 5. Guizzardi, G., Wagner, G.: Can bpmn be used for making simulation models? Lecture Notes in Business Information Processing 88 LNBIP, 100–115 (2011) 6. OMG: Metaobject facility, http://www.omg.org/mof 7. Pícka, M., Pergl, R.: Gradual modeling of information system: Model of method expressed as transitions between concepts. vol. ISAS, pp. 538–541 (2006) Na stránkách Dr. Guizzardiho [3] je uvedeno velké množství (stále nových) publikací s tématy OntoUML a konceptuálního modelování (řada z nich je i ke stažení).