OntoUML: Shrnutí, anti-patterny

BI-KOM: Konceptuální modelování #5

doc. Ing. Robert Pergl, Ph.D. (robert.pergl@fit.cvut.cz),

Ing. Marek Bělohoubek (belohma2@fit.cvut.cz)

1 / 53
Obsah přednášky
1. Shrnutí OntoUML (UFO-A)
2. Postup modelování v OntoUML
3. Kontrola modelu - anti-patterny

2 / 53
Shrnutí základních typů: OntoUML 1.0

3 / 53
Shrnutí základních typů: OntoUML 2.0
Type

Endurant Type
{complete,
disjoint}

Sortal NonSortal
{complete,
disjoint} {complete,
disjoint}

AntiRigidSortal RigidNonSortal SemiRigid AntiRigid

RigidSortal
NonSortal NonSortal
{complete, {complete,
disjoint} disjoint}

UltimateSortal Subkind Role Phase Category Mixin {complete

disjoint}
{complete,
disjoint}

Kind Relator Mode Quality RoleMixin PhaseMixin

Pozn.: Pozn.: Endurant Type jsou (zjednodušeně) strukturální typy. UFO-B se poté zabývá typy Perdurant konceptualizující
děje (chování).
4 / 53
Shrnutí základních typů: Aspekty
Entity

Type ◄ instance of Individual

* * 1
{disjoint, ▲
complete} inheres in

Object Aspect 1..*

{disjoint, complete}

Instrinsic Aspect Relational Aspect

Quality
Quality Mode Relator
5 / 53
Neformální shrnutí OntoUML: Sortály
Rigidní
«Kind» - poskytuje instancím princip identity
«SubKind» - neposkytuje princip identity (jen dědí)
«Relator», «Quantity», «Collective» - speciální význam vzhledem ke vztahům
Anti-rigidní
«Phase» - pouze na základě vnitřních vlastností, phase partition
«Role» - vyžaduje povinný vztah, relační závislost

6 / 53
Neformální shrnutí OntoUML: Non-sortály
Abstraktní vlastnosti společné různým druhům (Sortals).
Rigidní
«Category» - typicky jako nadtyp rigidních (vždy disjunktních) druhů
Anti-rigidní
«PhaseMixin» - nadtyp fází různých druhů
«RoleMixin» - relačně závislý nadtyp rolí různých druhů
Semi-rigidní
«Mixin» - nadtyp pro rigidní i anti-rigidní podtypy různých druhů

7 / 53
Shrnutí OntoUML: Relace
Rozlišujeme vztahy formální, materiální, a celek-část.
Formální relace «formal» je odvozena z vlastností entit (např. vyšší-než)
Materiální relace «material» vyžaduje další entitu – «Relator» jako pečetidlo vztahu
(např. Členství)
Vztahy celek-část:
Řešíme povinnost i neměnnost instancí ve vztahu ( {essential} a
{inseparable} , resp. pro anti-rigidní typy {immutablePart} , {immutableWhole} )

Speciální typy vztahů dle typů agregací (např. «Quantity» a «subQuantityOf»)

8 / 53
Shrnutí OntoUML: Aspekty
Entity existenčně závislé na jiných.
Typicky degradují na atributy, ale často od nich vyžadujeme další vlastnosti.
Rozlišujeme dva typy aspektů:
«Quality» - reprezentuje měřitelnou veličinu (váha, vzdálenost, odstín barvy)
«Mode» - neměřitelné vlastnosti entit a jejich stavy (zkušenosti, symptomy nemoci,
vydání knihy)

9 / 53
Terminologické varování
Ontologické modelování (OntoUML):
Entita (Entity): abstrakce prvku reálného světa = "krabička v diagramu"
Instance (Instance): konkrétní prvek reálného světa, instance entity
Typ entity (Entity Type): typ definující ontologické vlastnosti entity = stereotyp
"krabičky v diagramu"
Objekt (Object): existenčně nezávislý typ entity (vs Aspekt)
Softwarově-inženýrský model objektového systému (UML):
Třída (Class): vzor pro instanciaci objektů, obsahuje schéma atributů a
implementaci metod
Objekt, Instance (Object, Instance): instance třídy

10 / 53
Terminologické varování
Aby zmatení bylo ještě dokonalejší, v OntoUML jakožto profilu UML mluvíme o Diagramu
tříd (Class Diagram), byť by to tedy správně měl být Diagram typů entit (Entity Type
Diagram).
Pozn.: "Software engineers die hard" -- pokud najdete ve slidech přednáškách/cvičení chybu, prosím reportujte ji a vydělejte
si bod ;-)

The Tower of Babel

11 / 53
Postup modelování: Rigidní páteř
Začínáme identifikací rigidní páteře modelu, tj. «Kind» a «SubKind»
Jelikož všechny «Kind» jsou navzájem disjunktní, výsledkem je les.
Tato rigidní páteř představuje stabilní strukturu modelu.

12 / 53
Postup modelování: Rigidní páteř
«SubKind» se budou obvykle objevovat jako partitions specializací jednoho společného
«Kind».
Tato partice bude typicky disjoint , ale zřídka complete .
Pro identifikaci jednotlivých «SubKind» je třeba hledat vlastnosti, které odlišují
«SubKind» od obecného «Kind».
Dále hledáme komplementární «SubKind» patřící do stejné partice:

Existuje nějaký další SubKind Kindu Person, který je komplementární

k Man?

13 / 53
Postup modelování: Identifikace Anti-Rigid Sortal
Může se [A], které není [B], stát [B]?

(např. může se Člověk, který není Otec, stát Otcem?)

Může [A], které je [B], přestat býti [B]?

(např. může Člověk, který je Otec, přestat být Otec?).

14 / 53
Postup modelování: Identifikace «Role»
Role jsou vždy specifikovány jako specializace «Kind» skrze relační specializaci (tj. musí
mít k sobě vztah).

Stane se [A] [B] tím, že naváže relaci s jiným typem entity? (např.
stane se Člověk Otcem tím, že naváže relace k jinému typu
entity?).
Jak se bude jmenovat tato definující relace?
Najděme kardinality a parciality této definující relace.

15 / 53
Postup modelování: Identifikace «Role»

16 / 53
Postup modelování: Identifikace «Phase»
Fáze jsou vždy specifikovány jako specializace «Kind» skrze intrinsickou podmínku
specializace.

Stane se [A] [B] kvůli změně jedné nebo vícero hodnot atributů?
(např. stane se Člověk Teenagerem kvůli změně jedné nebo vícero
hodnot atributů?).
Najděme definující atributy a jejich definující hodnoty.

17 / 53
Postup modelování: Identifikace non-sortálů
Non-sortály reprezentují společné rysy, které jsou sdíleny entitami vícero typů.
Non-sortály tedy hrají roli strukturujícího mechanismu v konceptuálních modelech
(obzvláště v rozsáhlých ontologiích).
Vytváříme tedy nový, abstraktní nadtyp nad existujícími sortály.
Musíme "pouze" vybrat správný typ non-sortálu, který bude sedět z hlediska definic a
vlastností.

18 / 53
Postup modelování: Identifikace «Category»
«Category» volíme pro reprezentaci nutných vlastností sdílených vícero «Kind».
Vždy specifikují nadtyp vícero rigidních typů a tvoří disjunktní partici.

19 / 53
Postup modelování: Identifikace «Category»
Vytvořením «Category» poté vzniká způsob, jak abstrahovat tyto sdílené vlastnosti ve
společném typu. Tento typ je společný nadtyp v disjunktní množině generalizace těchto
typů rigidních sortálů:

20 / 53
Postup modelování: Identifikace «Mixin»
«Mixin» reprezentují vlastnosti sdílené vícero sortals, které jsou nutné pro některé
instance a možné pro jiné.
Definice «Mixin» poté umožňuje abstrahovat tyto sdílené vlastnosti ve společném
nadtypu, kde podtypy budou disjunktní množiny.
Některé z typů v množině tohoto nadtypu budou tedy rigidní typy, zatímco jiné budou
non-rigidní typy (typicky «Phase»).

21 / 53
Postup modelování: Identifikace «Mixin»

22 / 53
Postup modelování: Identifikace «RoleMixin»
Dekomponujeme «Role» (která je tedy de-facto «RoleMixin») do určitého počtu
specializovaných «Role» tak, že každá z těchto pod-rolí klasifikuje výhradně entity, které
patří ke stejnému Kind (analogicky s «PhaseMixin»).
Propojíme tyto pod-role s jejich «Kind» přes relaci specializace.
«RoleMixin» poté slouží jako mechanismus abstrakce pro všechny tyto pod-Roles
reprezentující jejich sdílené relační vlastnosti:

23 / 53
Role vs RoleMixin
Pozn.: Častá chyba je použít RoleMixin v situaci, kdy nedochází k "tříštění identity" a "stačí" Role, viz např.:

«phase» «phase»
Deceased Person Living Person
{disjoint,
complete}

«kind»
Person

{disjoint complete}

«subkind» «subkind»
Man Woman

«role» «role» 1..2

Ancestor Parent

1..2 {disjoint,
complete}
1..*

/ancesterOf «role» «role» «role»

Father Mother motherOf ► Offspring
0..1 1..*
0..1 1..*
fatherOf ►

«role»
1..* Descendent
24 / 53
Postup modelování: Princip reifikace
Reifikace (reification) je postup, kdy do modelu zavádíme dosud nevyjádřené pojmy, model
"zpřesňujeme" a zvyšujeme výrazovost (expressivity).

25 / 53
Postup modelování: Princip reifikace

OK, svazek může nastat mezi dvěma Lidmi, ale nyní budeme vyžadovat svazek pouze mezi
Mužem a Ženou...

26 / 53
Postup modelování: Princip reifikace

OK, ale je to nepřesné: vdává se přeci Ženich a Nevěsta, že?

27 / 53
Postup modelování: Princip reifikace

Všimněte si, že reifikací se nám multiplicity 0..1 změnily na 1. To je typické a lze to použít i
jako vodítko reifikace -- jak vidíte někde 0.. , vždy to znamená, že model lze reifikovat.

Fajn, ale dalo by se rýpnout, že takto se mohou vzít i mrtví lidé (nechceme Zombie Land)
28 / 53
Postup modelování: Princip reifikace
«kind»
«phase» {disjoint, complete} Person
Deceased Person

«phase»
Living Person
«subkind» «subkind»
Man Woman

«phase» «phase»
Living Man Living Woman

«role» «role»
Husband Wife

1 1
Marriage
1..* 1..*

Tipovačka: jakého typu bude manželství?

29 / 53
Jak kontrolujeme modely?
Verifikace:
Syntaktická kontrola
Validace:
Sémantická kontrola
Kontrola souladu s doménou
OntoUML narozdíl od UML dovoluje automatizovat detekci jak syntaktických, tak
sémantických chyb, díky vysoké míře formalizace a expresivity jazyka.
Kontrolu souladu s doménou je vždy nutno provádět manuálně.

30 / 53
Syntaktická kontrola
"Může být entita se stereotypem X podtypem entity se stereotypem Y?"
"Může mít asociace se stereotypem A jako zdroj entitu se stereotypem X?"
"Je každá entita, která má stereotyp phase, součástí disjoint generalization setu?"
"Mají všechny entity stereotypované jako role splněnou relační závislost?"

31 / 53
Syntaktická kontrola - OpenPonk
Kontrola na základě OntoUML specifikace.
V OpenPonku reprezentována verifikacemi.
Všechny syntaktické chyby je nutno opravit!

32 / 53
Sémantická kontrola
"Může být entita X v relaci Y sama se sebou?"
"Má nadtyp phase alespoň jeden atribut, quality nebo mode?"
"Mají všechny domain formal asociace skutečně správný stereotyp?"
"Nejsou součástí jednoho generalization setu, jehož nadtypem není mixin, jak rigidní, tak
anti-rigidní podtypy?"

33 / 53
Sémantická kontrola - Anti-patterny
Sémantická kontrola modelu.
Detekce podezřelých struktur v modelu.
V OpenPonku implementováno celkem dvacet anti-patternů.
Výskyt anti-patternu většinou znamená chybu.
Plná dokumentace anti-patternů na ontouml.readthedocs.io/en/latest/anti-
patterns/index.html

34 / 53
Anti-patterny - seznam
Binary relation between overlapping types (BinOver)
Relationally dependent phase (DepPhase)
Free role specialization (FreeRole)
Heterogenous collective (HetColl)
Mixin with the same rigidity (MixRig)
Multiple relational dependency (MultDep)
Relator mediating rigid types (RelRig)
Undefined phase partition (UndefPhase)

35 / 53
Binary relation between overlapping types (BinOver)
Overlapping typy = dva typy, které mohou být instancovány stejným individualem.
"Na obou stranách relace může být stejný individual".
Existují další "...Over" anti-patterny (PartOver, RelOver, WholeOver).

36 / 53
Relationally dependent phase (DepPhase)
Phase, která je součástí jedné nebo více asociací typu mediation.
Phase = závislá na změně vnitřního stavu.
Role = závislá na existenci vnější asociace.

37 / 53
Relationally dependent phase (DepPhase) - oprava

38 / 53
Free role specialization (FreeRole)
Splnění relační závislosti role:
Role je součástí asociace stereotypované jako mediation.
Role je přímým podtypem rolemixinu, který je součástí mediation asociace.
Role je podtypem jiné role, která má splněnou relační závislost

39 / 53
Free role specialization (FreeRole) - oprava

40 / 53
Heterogenous collective (HetColl)
Opakem je Homogeneous Functional Complex (HomoFunc).
Collective = na všechny části je nahlíženo stejně.
Funkční celek = jednotlivé části mají různé role.
Collective s dvěma či více rozdílnými typy částí.

41 / 53
Heterogenous collective (HetColl) - oprava

42 / 53
Mixin with the same rigidity (MixRig)
Mixin může být nadtypem rigidních, anti-rigidních i semi-rigidních typů.
Mixin musí mít minimálně dva podtypy s různou rigiditou.
Mixin, jehož podtypy jsou pouze rigidní, nebo pouze anti-rigidní podtypy.

43 / 53
Mixin with the same rigidity (MixRig) - oprava

44 / 53
Multiple relational dependency (MultDep)
Typ, který je propojen pomocí mediation s dvěma a více různými relatory, které
nejsou nadtypem/podtypem jeden druhého.
Velmi často důsledek redundance, přílišného zjednodušení, nebo špatné granularity
modelu.

45 / 53
Multiple relational dependency (MultDep) - oprava

46 / 53
Relator mediating rigid types (RelRig)
Relator, přímo propojený mediation asociací s jedním nebo více rigidními typy.
Většinou značí chybějící roli, případně rolemixin.
Může být též znakem toho, že rigidní typ má být stereotypován jako mode.

47 / 53
Relator mediating rigid types (RelRig) - oprava

48 / 53
Undefined phase partition (UndefPhase)
Množina entit stereotypovaných jako phase, jejichž společný nadtyp nemá žádný
atribut, quality ani mode.
Phase jsou zavislé na změně vnitřního stavu souvisejícího s vlastností nadtypu.
Tyto vlastnosti, lze přiřadit přímo k jednotlivým phase.

49 / 53
Undefined phase partition (UndefPhase) - oprava

50 / 53
OpenPonk - verifikace a anti-patterny
Menu "Diagram" v toolbaru hlavního okna
"Verify model" - syntaktická kontrola, nálezy obarví elementy na červeno
"Detect anti-patterns" - sémantická kontrola, nálezy obarví elementy do žluta
"Remove highlights" - vrátí elementům defaultní barvu

51 / 53
OpenPonk - verifikace a anti-patterny

52 / 53
Konec přednášky

53 / 53