Základní principy stavby objektového modelu. Vytváření objektového modelu existujícího obchodního procesu
Budova objektový modelúlohy využívající modelovací jazyk UML.
PRÁCE SE DĚLÁ ve StarUML
Dodací lhůta:
2 - 3 lekce
Pro ochranu díla je nutné poskytnout projekt vytvořený v balíku Rational Rose, včetně tří typů diagramů: případy použití, třídy (rozhraní, data) a sekvence pro každou funkci.
PŘÍKLAD ÚLOHY:
V databázi musí být uloženy následující informace:
- informace o studentech
Ó CELÉ JMÉNO.,
Ó adresa,
Ó údaje o pasu,
Ó číslo účtu,
Ó skupina);
- informace o specialitách
Ó název speciality,
Ó šifra;
- informace o skupině
Ó specialita,
Ó rok přijetí
Ó číslo skupiny.
Zajistěte vydání dokumentu „Seznam skupin“ obsahujícího pole:
· CELÉ JMÉNO.,
· číslo účtu.
Zakázka
Objektový model je zabudován v balíčku Rational Rose. K tomu vytvoříme prázdný projekt. Začněte svou práci s diagramem případu použití. Je postaven v hlavní oblasti části Use Case View, jak je znázorněno na obrázku 9.
Před zahájením tvorby diagramu je nutné definovat role uživatelů systému (aktérů) a jejich funkce (případy užití). V našem případě se systémem pracují dva aktéři - jedná se o „Zaměstnanec vzdělávacího oddělení“ a „Zaměstnanec děkanátu“. Mezi funkce zaměstnance vzdělávacího oddělení patří vedení seznamu odborností (pod údržba seznamu budeme rozumět přidávání záznamů, jejich úpravám a mazání). Mezi funkce pracovníka děkanátu patří vedení seznamu studentů a vedení seznamu skupin.
Zkonstruované schéma je znázorněno na Obr. 10.
Dále v části Logický pohled vytvořte dva diagramy tříd. K tomu můžete vytvořit dva balíčky. První diagram by měl obsahovat třídy rozhraní navrhované aplikace (viz obrázek 11). Na tomto obrázku jsou u tříd Seznam skupin a Seznam studentů vynechány operace Přidat, Upravit a Odstranit, aby nedošlo k přeplnění obrázku. Výstupním dokumentem je seznam skupin (nižší třída) (předchází mu třída "Výběr skupiny", protože je nutné získat seznam studentů určité skupiny). Druhým diagramem jsou databázové entity (viz obrázek 12).
Vytvořený diagram tříd zobrazuje všechny formy budoucí aplikace a jejich vztah.
Měli byste položit klíčová pole a vytvořit odkaz (z kontextové nabídky šipky - Násobnost).
Dalším krokem při vytváření objektového modelu je vytvoření sekvenčních diagramů. Sekvenční diagramy jsou vytvořeny pro každý případ užití v diagramu případu užití. Chcete-li do případu užití přidat sekvenční diagram, musíte jej vybrat ve stromu a zavolat na něj kontextová nabídka(NewàSequence Diagram), jak je znázorněno na obr. 13.
Příklad sekvenčního diagramu pro případ užití "Vedení seznamu specialit" je znázorněn na Obr. 14.
Je třeba poznamenat, že při konstrukci tohoto typu diagramu pro výstupní dokument „Seznam skupin“ v našem případě musíte nejprve vybrat skupinu ve formuláři „Vybrat skupinu“ (ta by naopak měla získat data z „ Skupina") a poté zobrazte formu výstupního dokumentu, do kterého již data pocházejí z entity "Student".
S objektově orientovaným přístupem je analýza systémových požadavků redukována na vývoj modelů tohoto systému. Model systému (nebo nějakého jiného objektu nebo jevu) je formální popis systému, ve kterém jsou identifikovány hlavní objekty tvořící systém a vztahy mezi těmito objekty. Stavba modelů je rozšířeným způsobem učení složité objekty a jevy. Z modelu je vynecháno mnoho detailů, což ztěžuje pochopení. Modelování je rozšířené jak ve vědě, tak v technice.
Modely pomáhají:
Zkontrolujte výkon vyvíjeného systému v raných fázích jeho vývoje;
Komunikace se zákazníkem systému, vyjasnění jeho požadavků na systém;
Proveďte (v případě potřeby) změny v návrhu systému (jak na začátku jeho návrhu, tak v dalších fázích jeho životního cyklu).
V současné době existuje několik technologií pro objektově orientovaný vývoj aplikovaných softwarových systémů, které jsou založeny na konstrukci a interpretaci modelů těchto systémů na počítači. V tomto projektu je aplikována jedna z nich - OMT (Object Modeling Techniques). Kromě toho byl vytvořen diagram objektového modelu v jazyce UML.
Objektový model popisuje strukturu objektů, které tvoří systém, jejich atributy, operace, vztahy s jinými objekty. Objektový model by měl odrážet ty koncepty a objekty reálného světa, které jsou důležité pro vyvíjený systém. Objektový model odráží především pragmatičnost vyvíjeného systému, která je vyjádřena v používání terminologie aplikační oblasti spojené s používáním vyvíjeného systému.
Definování tříd objektového modelu
Analýza vnějších požadavků na navrhovaný systém umožňuje určit objekty a třídy objektů související s aplikovaným problémem, který musí tento systém řešit. Všechny třídy musí být chápány v uvažované oblasti použití; třídy související s počítačovou implementací, jako je seznam, zásobník atd. by se v této fázi nemělo zadávat.
Začněme zvýrazněním možných tříd z písemného prohlášení aplikovaný úkol. Při určování možných tříd se snažte identifikovat co nejvíce tříd tak, že napíšete název každé třídy, která vás napadne. Zejména každé podstatné jméno vyskytující se v předběžném vyjádření problému může odpovídat třídě. Proto při rozlišování možných tříd je každé takové podstatné jméno obvykle spojeno s možnou třídou.
Výsledkem je následující seznam možných názvů tříd:
Další proxy;
Dokument;
Vzdálený webový server;
Konfigurace;
Informace o dokumentu;
Informace o vzdáleném webovém serveru;
Záhlaví požadavku;
Hlavička odpovědi.
Objektový model
Objektově orientovaná technologie je založena na tzv objektový model. Hlavní principy jeho konstrukce jsou: abstrakce, zapouzdření, modularita, hierarchie, typování, paralelismus a persistence. Každý z těchto principů není sám o sobě nový, ale objektový model je poprvé, kdy byly použity společně.
Objektově orientovaná analýza a návrh se zásadně liší od tradičních konstrukčních přístupů: zde musíte myslet na proces rozkladu jinak a architekturu výsledného softwarový produkt do značné míry přesahuje koncepty tradiční pro strukturované programování. Rozdíly jsou způsobeny tím, že konstrukční návrh je založen na strukturálním programování, zatímco objektově orientovaný návrh je založen na metodice objektově orientovaného programování.
Techniky strukturálního návrhu pomáhají zjednodušit proces vývoje složitých systémů pomocí algoritmů jako hotových stavebních bloků. Podobně jsou techniky objektově orientovaného návrhu navrženy tak, aby pomohly vývojářům aplikovat výkonné vyjadřovací prostředky objektové a objektově orientované programování, využívající třídy a objekty jako bloky.
. (objektově orientovaná analýza, OOA) je zaměřena na vytváření modelů reality založených na objektově orientovaném vidění světa.
Objektově orientovaná analýzaje metodologie, ve které jsou systémové požadavky vnímány z hlediska tříd a objektů identifikovaných v předmětová oblast.
. ( objektově orientovaný design, OOD )
Programování zahrnuje především správné a efektivní využívání mechanismů konkrétních programovacích jazyků. Design se naopak zaměřuje na správné a efektivní strukturování složitých systémů. Definujme objektově orientovaný design takto:
Objektově orientovaný designje návrhová metodologie, která kombinuje proces dekompozice objektů a techniky reprezentace logické a fyzické, stejně jako statické a dynamické modely navržený systém.
V tato definice obsahuje dvě důležité části: objektově orientovaný design
1) je založen na objektově orientovaném rozkladu;
2) používá různé techniky pro reprezentaci modelů, které odrážejí logickou (třídy a objekty) a fyzickou (moduly a procesy) strukturu systému, stejně jako jeho statické a dynamické aspekty.
Je to objektově orientovaná dekompozice, která odlišuje objektově orientovaný design od strukturálního, v prvním případě se logická struktura systému odráží abstrakcemi ve formě tříd a objektů, ve druhém - pomocí algoritmů.
. (objektově orientované programování, OOP)
Objektově orientované programováníje metodologie programování založená na reprezentaci programu jako sady objektů, z nichž každý je instancí určité třídy a třídy tvoří hierarchii dědičnosti.
Tuto definici lze rozdělit do tří částí:
1) OOP používá jako základní prvky předměty, ne algoritmy;
2) každý objekt je instance jakékoli konkrétní třída;
3) jsou organizovány třídy hierarchicky.
Program bude objektově orientovaný pouze tehdy, jsou-li splněny všechny tři tyto požadavky. Zejména programování, které není založeno na hierarchických vztazích, není OOP, ale je voláno založené na programování abstraktní typy data.
Existuje pět hlavních typů programovacích stylů, které jsou uvedeny níže, spolu s jejich příslušnými typy abstrakcí:
Je nemožné uznat jakýkoli styl programování jako nejlepší ve všech oblastech. praktická aplikace. Například pro návrh znalostních bází je vhodnější styl orientovaný na pravidla a pro výpočetní úlohy pak procedurálně orientovaný. Na základě nashromážděných zkušeností je objektově orientovaný styl nejpřijatelnější pro nejširší spektrum aplikací; ve skutečnosti toto paradigma často slouží jako architektonický základ, na kterém jsou založena jiná paradigmata.
Každý styl programování má svůj vlastní koncepční základ. Každý styl vyžaduje své vlastní myšlení a způsob vnímání řešeného problému. Pro objektově orientovaný styl je koncepční základna objektový model. Má čtyři hlavní prvky:
- abstrakce;
- zapouzdření;
- modularita;
- hierarchie.
Tyto prvky jsou hlavní v tom smyslu, že bez žádného z nich by model nebyl objektově orientovaný. Kromě hlavních prvků existují další tři další prvky:
- psaní na stroji;
- rovnoběžnost;
- vytrvalost.
Nazývat je nepovinné znamená, že jsou užitečné v objektovém modelu, ale nejsou povinné.
Abstrakce vyzdvihuje podstatné vlastnosti nějakého objektu, které jej odlišují od všech ostatních druhů objektů, a tím jasně vymezuje jeho pojmové hranice z pohledu pozorovatele.
Abstrakce je založena na pojmech klient a server.
Klient je jakýkoli objekt, který využívá zdroje jiného objektu (tzv server).
Chování objektu budeme charakterizovat službami, které poskytuje jiným objektům, a operacemi, které s jinými objekty provádí. Tento přístup se zaměřuje na vnější projevy objektu a vede k myšlence smluvní model programování, kdy je vnější projev objektu posuzován z hlediska jeho smlouvy s jinými objekty, v souladu s tím jeho vnitřní organizace(často v interakci s jinými objekty). Smlouva stanoví všechny závazky, které má objekt serveru vůči objektu klienta. Jinými slovy, tato smlouva definuje odpovědnost objekt, tedy chování, za které je odpovědný.
Každá operace poskytovaná touto smlouvou je jednoznačně definována svými formálními parametry a typem návratnosti. Kompletní sada operací, které může klient provádět na jiném objektu, spolu s správný příkaz ve kterém jsou tyto operace volány, se nazývá protokol. Protokol odráží vše možné způsoby, kterým může objekt působit nebo být ovlivněn. Zcela tak určuje vnější chování abstrakce ze statického i dynamického hlediska.
Zapouzdření - jedná se o proces vzájemného oddělování prvků objektu, které určují jeho strukturu a chování. Zapouzdření slouží k oddělení smluvních závazků abstrakce od jejich implementace.
Abstrakce a zapouzdření se vzájemně doplňují: abstrakce se zaměřuje na pozorovatelné chování objektu, zatímco zapouzdření se zabývá vnitřnostmi. Nejčastěji se zapouzdření provádí skrytím informací, tedy maskováním všech vnitřní části které neovlivňují vnější chování. Obvykle je skryta jak vnitřní struktura objektu, tak implementace jeho metod. V praxi to znamená, že třída má dvě části: rozhraní a implementaci. Rozhraní odráží vnější chování objektu, popisuje abstrakci chování všech objektů tato třída. Vnitřní implementace popisuje znázornění této abstrakce a mechanismy pro dosažení požadovaného chování objektu. Princip oddělení rozhraní a implementace odpovídá podstatě věci: vše, co souvisí s interakcí, je shromážděno v části rozhraní tento objekt s jakýmikoli jinými předměty; implementace skrývá před ostatními objekty všechny detaily, které nesouvisejí s procesem interakce mezi objekty.
Modularita je vlastnost systému, který byl rozložen na vnitřně koherentní, ale volně propojené moduly.
V procesu rozdělování systému na moduly mohou být užitečná dvě pravidla. Za prvé, protože moduly slouží jako elementární a nedělitelné jednotky programu, které lze znovu použít v celém systému, musí to při přidělování tříd a objektů modulům brát v úvahu. Za druhé, mnoho kompilátorů vytváří samostatný segment kódu pro každý modul. Proto může existovat omezení velikosti modulu. Dynamika volání podprogramů a uspořádání popisů v rámci modulů může výrazně ovlivnit umístění odkazu a správu stránek. virtuální paměť. Pokud jsou procedury špatně rozděleny do modulů, častější jsou vzájemná volání mezi segmenty, což vede ke ztrátě efektivity vyrovnávací paměti a častým změnám stránek.
Je poměrně obtížné spojit takové protichůdné požadavky, ale hlavní věcí je pochopit, že izolace tříd a objektů v projektu a organizace modulární struktury jsou nezávislý akce. Proces izolace tříd a objektů je součástí procesu logického návrhu systému a rozdělení do modulů je fází fyzického návrhu. Samozřejmě někdy není možné dokončit logický návrh systému bez dokončení fyzického návrhu a naopak. Tyto dva procesy se provádějí iterativně.
Hierarchie - to je řazení abstrakcí, jejich uspořádání podle úrovní.
Hlavní typy hierarchických struktur ve vztahu k komplexní systémy jsou struktura třídy (hierarchie "je-a") a struktura objektu ("část" hierarchie).
Důležitý prvek objektově orientované systémy a hlavním druhem hierarchie „je-a“ je výše zmíněný koncept dědičnosti. Dědičnost znamená takový vztah mezi třídami (vztah rodič/dítě), kdy si jedna třída vypůjčí strukturální nebo funkční část jedné nebo více jiných tříd (resp. singl A vícenásobné dědictví). Jinými slovy, dědičnost vytváří hierarchii abstrakcí, ve které podtřídy dědí strukturu od jedné nebo více nadtříd. Podtřída často vytváří nebo přepisuje komponenty nadřazené třídy.
Pokud hierarchie "je" definuje vztah zobecnění/specializace, pak vztah "část" zavádí agregační hierarchii. V hierarchii „části“ je třída na vyšší úrovni abstrakce než kterákoli z těch, které se používají při její implementaci.
Psaní na stroji je způsob, jak chránit nebo alespoň kontrolovat používání objektů jedné třídy místo jiných.
Rovnoběžnost je vlastnost, která odlišuje aktivní objekty od pasivních.
Vytrvalost - schopnost objektu existovat v čase, přežít proces, který jej dal vzniknout, a (nebo) v prostoru, pohybovat se ze svého původního adresního prostoru.
Teď máme všechno potřebné koncepty popsat proces budování objektového modelu. Tento proces zahrnuje následující kroky:
definice objektů a tříd;
příprava datového slovníku;
definice závislostí mezi objekty;
definice atributů objektů a vazeb;
organizace a zjednodušení tříd při použití dědičnosti;
další výzkum a vylepšení modelu.
2.2.1. Definice tříd. Analýza vnějších požadavků na navržený PS umožňuje určit objekty a třídy objektů související s aplikovaným problémem, který by měl tento systém řešit. Všechny třídy musí být chápány v uvažované oblasti použití; třídy související s počítačovou implementací, jako je seznam, zásobník atd. by se v této fázi nemělo zadávat.
Musíte začít zvýrazněním možných tříd z písemného prohlášení aplikovaného problému ( podmínky zadání a další dokumentace poskytnutá zákazníkem). Je třeba mít na paměti, že se jedná o velmi složitou a odpovědnou fázi vývoje, protože na tom do značné míry závisí další osud projektu.
Při určování možných tříd se snažte identifikovat co nejvíce tříd tak, že napíšete název každé třídy, která vás napadne. Zejména každé podstatné jméno vyskytující se v předběžném vyjádření problému může odpovídat třídě. Proto při rozlišování možných tříd je každé takové podstatné jméno obvykle spojeno s možnou třídou.
· nadbytečné třídy: pokud dvě nebo více tříd vyjadřují stejné informace, měla by být zachována pouze jedna z nich;
· irelevantní(nesouvisí přímo s problémem) třídy: pro každý možný název třídy se vyhodnocuje, do jaké míry je potřeba budoucí systém(toto je často velmi obtížné vyhodnotit); irelevantní třídy jsou vyloučeny;
· nejasně definovaný(z hlediska problému) třídy(viz odstavec 2.3.1);
· atributy: některá podstatná jména více odpovídají ne třídám, ale atributům; taková podstatná jména zpravidla popisují vlastnosti předmětů (například jméno, věk, váha, adresa atd.);
· operace: některá podstatná jména již neodpovídají třídám, ale názvům operací (například phone_call pravděpodobně nebude znamenat žádnou třídu);
· role: některá podstatná jména definují názvy rolí v objektovém modelu (například vlastník, řidič, šéf, zaměstnanec; všechna tato jména jsou spojena s rolemi v různých závislostech objektů osoby třídy);
· implementační konstrukce: názvy související spíše s programováním a počítačovým hardwarem by neměly být tuto fázi porovnávat třídy, protože neodrážejí vlastnosti navrženého PS; příklady takových jmen: podprogram, proces, algoritmus, přerušení atd.
Po odstranění názvů všech nepotřebných (nadbytečných) možných tříd bude získán předběžný seznam tříd, které tvoří navrhovaný systém.
2.2.2. Příprava datového slovníku. Jednotlivá slova mají příliš mnoho výkladů. Proto je nutné se na samém začátku návrhu připravit datový slovník, obsahující jasné a jednoznačné definice všech objektů (tříd), atributů, operací, rolí a dalších entit uvažovaných v projektu. Bez takového slovníku nemá diskutovat o projektu s ostatními vývojáři a zákazníky systému smysl, protože každý si může diskutované pojmy vyložit po svém. Příklad slovníku viz 2.3.2.
2.2.3. Definice závislostí. Na další krok vytváření objektového modelu definuje závislosti mezi třídami. Nejprve jsou z tříd vyloučeny atributy, které jsou explicitními odkazy na jiné třídy; takové atributy jsou nahrazeny závislostmi. Smyslem tohoto nahrazení je, že závislosti jsou abstrakcí na stejné úrovni jako třídy, a proto přímo neovlivňují budoucí implementaci (odkaz na třídu je pouze jedním ze způsobů implementace závislostí).
Stejným způsobem, jakým byly názvy možných tříd získány od podstatných jmen, se kterými se setkali v předběžném vyjádření aplikovaného problému, lze názvy možných závislostí získat z slovesa nebo slovesové fráze naleznete v uvedeném dokumentu. Tak se obvykle popisuje fyzická pozice (follows_is_a_part, is_contained_in), řízená akce (sets_in_motion), komunikace (talks_with), sounáležitost (has_is_a_part) atd. Příklad výběru explicitních a implicitních slovních spojení z předběžného vyjádření konkrétního aplikovaného problému je uveden v odstavci 2.3.3.
Poté byste měli odstranit zbytečné nebo nesprávné závislosti pomocí následujících kritérií:
· závislosti mezi vyloučenými třídami musí být odstraněny nebo přeformulovány z hlediska zbývajících tříd (viz 2.3.3);
· nepodstatné závislosti a závislosti související s implementací by měly být vyloučeny (viz 2.3.3);
· akce: závislost by měla popisovat strukturální vlastnosti aplikační oblasti, a ne méně významné události (viz článek 2.3.3);
· tréninkové závislosti: většina závislostí mezi třemi resp velký počet třídy lze rozložit do několika binárních závislostí, v případě potřeby pomocí kvalifikátorů (viz 2.3.3); v některých (vzácných) případech nelze takový rozklad provést; například tréninkovou závislost „Profesor vyučuje kurz v místnosti 628“ nelze bez ztráty informace rozložit na binární;
· deriváty závislosti: je nutné vyloučit závislosti, které lze vyjádřit jinými závislostmi, protože jsou nadbytečné (viz část 2.3.3); při vyloučení redundantních (odvozených) závislostí je třeba být obzvláště opatrný, protože ne všechny závislosti mezi třídami, které se navzájem duplikují, jsou redundantní; v některých případech jiné závislosti umožňují pouze stanovení existence jedné další odvozené závislosti, ale neumožňují stanovení násobnosti této závislosti; Například v případě znázorněném na Obr. 2.36, firma má mnoho zaměstnanců a vlastní mnoho počítačů; každý zaměstnanec je vybaven osobní užití několik počítačů, navíc existují veřejné počítače; kardinalitu závislosti poskytovanou_pro_použití nelze odvodit ze závislostí, které obsluhují a vlastní; ačkoli odvozené závislosti nepřidávají nové informace, jsou často užitečné; v těchto případech mohou být na schématu označeny lomítkem.
Rýže. 2.36. Neredundantní závislosti
Po odstranění nadbytečných závislostí musíme upřesnit sémantiku zbývajících závislostí následovně:
· špatně pojmenované závislosti: měly by být přejmenovány, aby byl jasný jejich význam (viz 2.3.3);
· názvy rolí: v případě potřeby musíte přidat názvy rolí; název role popisuje roli, kterou hraje odpovídající třída v této závislosti z pohledu jiné třídy účastnící se této závislosti; pokud je název role jasný z názvu třídy, lze jej vynechat (viz část 2.3.3);
· kvalifikace: přidáním kvalifikátorů tam, kde je to nutné, zavádíme kontextové prvky, což nám umožňuje dosáhnout jedinečné identifikace objektů; kvalifikátory také umožňují zjednodušit některé závislosti snížením jejich multiplicity;
· násobnost: nutno doplnit označení násobnosti závislostí; zároveň je třeba pamatovat na to, že v procesu další analýzy požadavků na systém se může změnit mnohonásobnost závislostí;
· nezapočítané závislosti musí být identifikován a přidán do modelu.
2.2.4. Zpřesnění atributů. V další fázi je specifikován systém atributů: atributy třídy jsou opraveny, v případě potřeby jsou zavedeny nové atributy. Atributy vyjadřují vlastnosti objektů dané třídy, případně určují jejich aktuální stav.
Atributy obvykle odpovídají podstatným jménům; například auto_color (vlastnost objektu), kurzor_pozice (stav objektu). Atributy mají zpravidla malý vliv na strukturu objektového modelu.
Neměli byste se snažit definovat co nejvíce atributů: velký počet atributy komplikují model, znesnadňují pochopení problému. Je nutné zadat pouze ty atributy, které jsou relevantní pro navržený aplikační systém, vynechat náhodné, nedůležité a odvozené atributy.
Spolu s atributy objektů je nutné zavést i atributy závislostí mezi třídami (vazby mezi objekty).
Při zadávání atributů se řídí následujícími kritérii:
· Nahrazení atributů objekty. Pokud je přítomnost nějaké entity důležitější než její hodnota, pak je to objekt, pokud je důležitější hodnota, pak je to atribut: například šéf je objekt (nezáleží na tom, kdo je šéf , hlavní je, aby jím někdo byl), plat je atribut (jeho význam je velmi významný); město - vždy objekt, i když v některých případech se může zdát, že se jedná o atribut (například město jako součást adresy společnosti); v případech, kdy chcete, aby bylo město atributem, měli byste definovat závislost (řekněme umístěnou) mezi třídou firmy a města.
· Kvalifikace. Pokud hodnota atributu závisí na specifickém kontextu, měl by být kvalifikátorem (viz 2.3.4).
· Jména. Jména obvykle lépe odpovídají kvalifikátorům než atributy objektů; ve všech případech, kdy název umožňuje výběr z objektů nějaké množiny, by měl být kvalifikátorem (viz 2.3.4).
· Identifikátory. Identifikátory objektů jsou spojeny s jejich implementací. V raných fázích návrhu by neměly být považovány za atributy.
· Atributy vztahu. Pokud nějaká vlastnost necharakterizuje objekt sám o sobě, ale jeho spojení s jiným objektem (objekty), pak se jedná o atribut spojení, nikoli o atribut objektu.
· Vnitřní hodnoty. Atributy, které definují pouze vnitřní stav objektu, nepostřehnutelný vně objektu, by měly být vyloučeny z úvahy.
· Nepodstatné detaily. Atributy, které neovlivňují většinu operací, doporučujeme vynechat.
2.2.5. Organizace systému tříd pomocí dědičnosti. Dále se musíte pokusit najít supertřídy pro představené třídy. To je užitečné, protože to objasňuje strukturu modelu a usnadňuje pozdější implementaci. Příklad je uveden v části 2.3.5.
2.2.6. Další výzkum a vylepšování modelu. Pouze ve velmi vzácných případech se konstruovaný objektový model okamžitě ukáže jako správný. Model je třeba prozkoumat a odladit. Některé chyby lze nalézt při zkoumání modelu bez počítače, jiné - při jeho interpretaci spolu s dynamickými a funkčními modely na počítači (tyto modely jsou sestaveny po již sestavení objektového modelu).
Zde se podíváme na techniky pro nepočítačové vyhledávání a opravu chyb v objektovém modelu. Jsou založeny na vnějších znacích, pomocí kterých můžete najít chyby v modelu; tyto znaky lze kombinovat do následujících skupin.
Známky chybějícího objektu (třídy):
asymetrie spojení a zobecnění (dědičnosti); pro opravu chyby je třeba přidat chybějící třídy;
nesoulad atributů a operací třídy; pro opravu chyby je nutné třídu rozdělit na několik dalších tříd, aby si atributy a operace nových tříd vzájemně odpovídaly;
Byla zjištěna operace, která nemá uspokojivou cílovou třídu; Chcete-li chybu opravit, musíte přidat chybějící cílovou třídu;
Bylo nalezeno několik závislostí se stejným názvem a účelem; pro opravu chyby je třeba zobecnit a přidat vynechanou nadtřídu.
Známky zbytečné (nadstandardní) třídy:
nedostatek atributů, operací a závislostí pro určitou třídu; Chcete-li chybu opravit, musíte zvážit, zda by taková třída neměla být vyloučena.
Známky chybějících závislostí:
· neexistují žádné způsoby přístupu k operacím; Chcete-li chybu opravit, musíte přidat nové závislosti, které umožňují obsluhovat odpovídající požadavky.
Známky zbytečných (nadbytečných) závislostí:
nadbytečné informace v závislostech; pro opravu chyby je nutné vyloučit závislosti, které nepřidávají nové informace, nebo je označit jako odvozené závislosti;
není dostatek operací, které překračují závislost; k nápravě chyby je třeba zvážit, zda by taková závislost neměla být odstraněna.
Známky nesprávně umístěných závislostí:
Názvy rolí jsou pro jejich třídy příliš široké nebo příliš úzké. Chcete-li chybu opravit, musíte posunout závislost nahoru nebo dolů v hierarchii třídy.
Známky nesprávně umístěných atributů:
· není potřeba přistupovat k objektu pomocí hodnot jednoho z jeho atributů; Chcete-li chybu opravit, musíte zvážit, zda potřebujete zavést kvalifikovanou závislost.
Příklady praktického použití popsaných vlastností viz bod 2.3.6.
Příklad objektového modelu
Uvažujme proces budování objektového modelu pro systém bankovních služeb v procesu analýzy požadavků a předběžného návrhu tohoto systému. Abychom sestavili objektový model uvažovaného systému, musíme dokončit všechny kroky uvedené v části 2.2.
2.3.1. Definice objektů a tříd. V odstavci 1.3 je problém formulován a je znázorněno schéma sítě bankovních služeb (obr. 1.3). Analýzou tohoto vyjádření problému lze vyčlenit možné třídy jejich porovnáním s podstatným jménem uvedeným v jeho předběžné formulaci; výsledkem je následující seznam možných názvů tříd (in abecední pořadí):
Prozkoumáme tento seznam a vyloučíme z něj názvy tříd v souladu s doporučeními odstavce 2.2.1:
· nadbytečné třídy: je jasné, že klient a uživatel mají na mysli stejný koncept; pro bankovní systém je přirozenější opustit třídu klientů;
· irelevantní třídy: taková třída je cenová třída (nesouvisí přímo s prací bankovní síť);
· nejasně definované třídy: tyto třídy jsou record_keeping_service a security check (tyto služby jsou součástí transakce), system (v našem případě není jasné, co to je), banking_network (celá PS bude obsluhovat bankovní síť);
· atributy: zaúčtování dat, údaje o účtu, peníze (myšleno skutečné peníze, které klientovi dává pokladní nebo bankomat, nebo přijaté pokladníkem), účtenka (předaná klientovi spolu s penězi) je přirozenější mít jako atributy;
· implementační konstrukce vyjadřovat názvy jako software a přístup; i oni by měli být vyloučeni ze seznamu možných jmen tříd.
Po odstranění všech zbytečných názvů možných tříd získáme následující seznam tříd, které tvoří navržený bankovní systém (tyto třídy jsou znázorněny na obr. 2.5):
2.3.2. Příprava datového slovníku. Zde je část datového slovníku obsahující definice tříd použitých v projektu.
Bankomat (ATM) - terminál, který umožňuje klientovi provést vlastní elektroinstalaci pomocí jeho karty pro identifikaci. ATM (ATM) interaguje se zákazníkem, aby získal nezbytné informace pro zaúčtování odešle informace o zaúčtování do centrálního počítače k ověření a dalšímu použití při zaúčtování a vydá klientovi peníze a účtenku. Předpokládá se, že ATM (ATM) nemusí fungovat nezávisle na síti.
Banka je finanční instituce, která spravuje účty svých zákazníků a vydává karty, které opravňují přístup k účtům prostřednictvím sítě bankomatů (ATM).
Kartu - plastová karta, kterou banka předá svému klientovi, který autorizuje přístup k účtům prostřednictvím sítě bankomatů (ATM). Každá karta obsahuje kód banky a číslo karty zakódované v souladu s národními standardy pro bankovní karty. Bank_code jednoznačně identifikuje banku v rámci konsorcia. Číslo_karty definuje účty, ke kterým má karta přístup. Karta nemusí nutně poskytovat přístup ke všem zákaznickým účtům. Každou kartu může vlastnit pouze jeden zákazník, ale může existovat více kopií, proto je třeba zvážit použití stejné karty z více bankomatů (ATM) současně.
Pokladník je zaměstnanec banky, který má právo provádět transakce z hotovostních terminálů a také přijímat a vydávat peníze a šeky zákazníkům. Transakce, peníze a šeky, se kterými každý pokladník pracuje, musí být evidovány a správně zaúčtovány.
Cash_terminal - terminál, ze kterého pokladník provádí transakce pro zákazníky. Když pokladník přijme a vydá peníze a šeky, pokladní terminál vytiskne účtenky. Teller_terminal komunikuje s bank_computer za účelem ověření a dokončení zaúčtování.
Klient je majitelem jednoho nebo více bankovních účtů. Klientem může být jedna nebo více osob nebo organizací. Stejná osoba, která má účet u jiné banky, je považována za jiného klienta.
Bank_computer - počítač ve vlastnictví banky, který spolupracuje se sítí bankomatů (ATM) a vlastními POS terminály banky. Banka může mít vlastní interní počítačová síť zpracovávat faktury, ale zde se díváme pouze na bank_computer, který komunikuje se sítí bankomatů.
Konsorcium je sdružení bank, které zajišťuje provoz sítě bankomatů (ATM). Síť posílá bankovní transakce do konsorcia.
Zaúčtování – jediný integrovaný požadavek na provedení určité sekvence operací na účtech jednoho klienta. Bylo navrženo, že bankomaty (ATM) pouze vydávají peníze, ale neměly by být vyloučeny z tisku šeků nebo přijímání peněz a šeků. Rovněž by bylo žádoucí zajistit flexibilitu systému, který v budoucnu poskytne možnost současného zpracování účtů různých klientů, i když to zatím není vyžadováno. Různé operace musí být správně vyváženy.
Účet – jeden bankovní účet, na který se provádí účtování. Účty mohou být různé typy; Zákazník může mít více účtů.
Central_computer – počítač vlastněný konsorciem, který distribuuje transakce a jejich výsledky mezi bankomaty (ATM) a počítače bank. Centrální počítač kontroluje kódy bank, ale neprovádí žádné účtování.
2.3.3. Definice závislostí. Podle doporučení v části 2.2.3 rozlišujeme explicitní a implicitní slovní obraty z předběžného vyjádření problému a považovat je za názvy možných závislostí. Z prohlášení o problému bankovní sítě (viz část 1.3) lze vyčíst následující pojmy:
Konstrukce sloves (explicitní a implicitní):
bankovní síť zahrnuje pokladny a bankomaty
Konsorcium distribuuje Výsledky účtování bankomatů
banka vlastní bankovní počítač
bankovní počítač podporujeúčty
banka vlastní pokladní terminály
Hotovostní terminál interaguje s počítačem banky
Pokladní představuje zaúčtování na účet
bankomaty interagovat s centrálním počítačem při zapojování
Centrální počítač interaguje s počítačem banky
bankomat přijímá Kartu
bankomat komunikuje s uživatelem
bankomat problémy hotovost
bankomat tiskne příjmy
Systém vládne kolektivní přístup
banka poskytuje software
Konsorcium skládá se z banky
Konsorcium vlastní centrální počítač
Systém poskytuje protokolování
Systém poskytuje bezpečnost
klienti mít karty
Kartu poskytuje přístup na účet
V bance sloužit Pokladny
Potom vyloučíme zbytečné nebo nesprávné závislosti pomocí kritérií formulovaných v odstavci 2.2.3:
· závislosti mezi vyloučenými třídami: vyloučeny jsou následující závislosti: Bankovní síť zahrnuje pokladny a bankomaty (bez třídy bankovní_síť), bankomat tiskneúčtenky (bez třídy účtenek), bankomat problémy hotovost (kromě peněžní třídy), Systém poskytuje protokolování účtování (třída záznam_udržování_služeb zastaralá), Systém poskytuje zabezpečení správy účtu (vyjma třídy bezpečnostní_služby), banky poskytnout software (třída software_software kromě);
· irelevantní závislosti a závislosti související s implementací: závislost "Systém vládne„sdílení“ je vyloučeno jako související s implementací;
· akce jsou popsány závislostmi jako „ATM přijímá karta“ a „bankomat komunikuje s uživatelem"; tyto závislosti vylučujeme;
· tréninkové závislosti: závislost "pokladní" představuje zaúčtování přes účet“ se rozloží na dvě binární závislosti „Pokladna představuje elektroinstalace“ a „Zapojení odkazuje naúčet". Závislost „ATM"s interagovat s centrálním počítačem během zaúčtování“ se rozloží na „bankomaty“. interagovat s centrálním počítačem“ a „Zapojení začít s BANKOMAT";
· deriváty závislosti: závislost "Konsorcium distribuuje ATM "s" je důsledkem závislostí "Consortium vlastní centrální počítač“ a „bankomaty“. interagovat s centrálním počítačem.
Odstraněním nadbytečných závislostí získáme následující seznam závislostí:
banka vlastní bankovní počítač
bankovní počítač podporujeúčty
banka vlastní pokladní terminály
Hotovostní terminál interaguje s počítačem banky
Pokladní představuje elektrické vedení
Elektrické vedení odkazuje naúčet
bankomaty interagovat s centrálním počítačem
Elektrické vedení začíná s bankomatem
Centrální počítač interaguje s počítačem banky
Konsorcium skládá se z banky
Konsorcium vlastní centrální počítač
klienti mít karty
Kartu poskytuje přístup na účet
V bance sloužit Pokladny
Upřesníme sémantiku zbývajících závislostí následovně:
· přejmenovat nesprávně pojmenované závislosti, aby byl jejich význam jasnější; takže závislost na počítači_banka podporuje je výhodnější nahradit účty se závislostní bankou udržujeúčty.
· názvy rolí nelze použít, protože jsou jasné z názvů tříd zapojených do závislosti, jako je například závislost ATM "s interagovat s centrálním počítačem;
· nezapočítané závislosti: Elektrické vedení začíná z cash_terminálu, Klienti mítúčty, zaúčtování registrovaný karta by měla být přidána k modelu.
Po vyjasnění závislostí můžete skládat originální verze objektový diagram. Pro uvažovaný problém bude mít podobu znázorněnou na obr. 2.37.
Rýže. 2.37. První verze objektového diagramu pro bankovní síť
2.3.4. Zpřesnění atributů. Aplikováním kritérií formulovaných v odstavci 2.2.4 získáme:
Karta obsahuje kód banky a kód_karty; lze je považovat za atributy objektů třídy karet, ale je pohodlnější je použít jako kvalifikátory, protože kód banky poskytuje výběr banky, čímž se snižuje mnohonásobnost závislosti konsorcia a banky; Pro podobné použití card_code, musíte přidat závislost banky vydání karta, jejímž kvalifikátorem bude kód_karty.
Po provedení výše uvedených změn bude mít diagram podobu znázorněnou na obr. 2.38.
2.3.5. Organizace systému tříd pomocí dědičnosti. V tomto příkladu je přirozené definovat nadtřídy pro objekty, které definují různé terminály: cash_terminal a ATM (ATM), a pro objekty, které definují transakce: cashier_transaction a remote_transaction (z ATM).
Provedením příslušných změn získáme objektový diagram znázorněný na Obr. 2.39.
Rýže. 2.38. Diagram objektů pro bankovní síť po upřesnění atributů a přidání kvalifikátorů
Rýže. 2.39. Diagram objektů pro bankovnictví s dědičností
2.3.6. Další vylepšení modelu. Karta působí ve dvou entitách: jako evidenční jednotka v bance (vkladní knížka), která klientovi zajišťuje přístup k jeho účtům, a jako datová struktura, se kterou bankomat pracuje. Proto je vhodné rozdělit třídu karet do dvou tříd: card_registration a card; první z těchto tříd poskytuje klientovi přístup k jeho bankovním účtům a druhá definuje datovou strukturu, se kterou bankomat pracuje.
Je vhodné reprezentovat třídu zaúčtování jako agregaci tříd změn, protože zaúčtování je dohodnutá posloupnost provádění změn na účtech a jiných bankovních dokladech; Při práci s bankovními dokumenty jsou zvažovány tři typy změn: výběr, umístění a žádost.
Je přirozené kombinovat třídu bank s třídou bank_computer a třídu konsorcia s třídou central_computer.
Rýže. 2,40. Konečný pohled na objektový diagram pro bankovní síť
Po provedení výše uvedených změn bude mít schéma objektu podobu znázorněnou na obr. 2,40. Tím je stavba modelu objektu ve fázi předběžného návrhu dokončena. Další upřesnění objektového modelu budou provedeny v dalších fázích životního cyklu systému.
Výběr subsystémů
2.4.1. Pojem subsystému. PS je tedy sada vzájemně závislých objektů. Každý objekt je charakterizován sadou atributů, jejichž hodnoty určují stav objektu, a sadou operací, které lze na tento objekt aplikovat. Při vývoji PS je vhodné vzít v úvahu, že všechny atributy objektů jsou soukromé (tj. nejsou dostupné mimo objekt, a abyste mohli zjistit hodnotu atributu jiného objektu v nějakém objektu nebo ji změnit, musíte použijte některou z otevřených operací tohoto objektu, pokud je samozřejmě taková operace definována). Objektové operace mohou být veřejné nebo soukromé.
Každý objekt má tedy přesně definované rozhraní, tj. sada veřejných operací, které lze na tento objekt použít. Všechny objekty stejné třídy mají stejné rozhraní. Rozhraní třídy (a následně každého objektu této třídy) je specifikováno seznamem podpisů jejích veřejných (veřejných) operací (a metod, které je implementují); podpisy uzavřených operací nejsou zahrnuty v rozhraní objektů odpovídající třídy.
Objektový model systému definuje sadu vzájemně závislých objektů, které tvoří systém, a proto definuje sadu rozhraní dostupných v rámci systému. Všechny možnosti zpracování dat v rámci systému (tj. v každém objektu, který je součástí systému) jsou definovány touto sadou rozhraní, která definuje vnitřní prostředí(nebo středa) systémy.
Spolu s vnitřním prostředím systému lze definovat i jeho vnější prostředí. Je určena funkcemi (operacemi) implementovanými jako součást systému software(tj. operační systém, programovací systém, různé editory, DBMS atd.), jakož i v dalších aplikačních systémech a knihovnách používaných ve spojení se systémem. K objektům a operacím, které tvoří vnější prostředí systému, lze také přistupovat zevnitř systému. Aby to bylo na paměti, bylo by možné do objektového modelu přidat další objekt, jehož rozhraní by reprezentovalo vlastnosti vnějšího prostředí používaného v systému (takové rozhraní obvykle představuje pouze podmnožinu schopností vnějšího prostředí). To by ale nebylo úplně přesné, protože vnější prostředí není implementováno jedním, ale několika objekty. Na druhou stranu uvnitř systému není důvod uvažovat o struktuře jeho vnějšího prostředí. Východiskem z tohoto rozporu je zavedení další entity v úvahu - subsystému.
Subsystém je soubor objektů a subsystémů, které poskytují určitou funkcionalitu a vzájemně se ovlivňují v souladu se svými rozhraními. Rozhraní subsystému představuje podmnožina kombinující rozhraní všech objektů a subsystémů, které tvoří tento subsystém. Subsystém může zahrnovat jeden nebo více vzájemně závislých objektů a/nebo subsystémů.
Množina rozhraní objektů (a subsystémů), které dohromady tvoří určitý subsystém, je vnitřní prostředí tento subsystém. Každý subsystém by měl zahrnovat subsystém reprezentující prostředí vnější prostředí tento subsystém. Subsystém prostředí pro systém bankovních služeb, uvažovaný jako průřezový příklad, je znázorněn na Obr. 2.41. Rozhraní subsystému prostředí určuje, v jakém softwarovém prostředí bude navržený systém pracovat a jaké vlastnosti tohoto prostředí budou využívány při jeho provozu (to je důležité při potřebě úpravy nebo výměny jednotlivých komponent prostředí).
Všimněte si, že subsystém prostředí představuje pouze rozhraní systému bankovních služeb s jeho vnějším prostředím. Vnější prostředí systému bankovních služeb se skládá z více subsystémů a knihoven a lze pro něj vyvinout i objektový model, který může obsahovat i vyvíjený systém (v tomto objektovém modelu se bude jednat o jeden ze subsystémů).
Objektový model systému bankovních služeb a jeho systémové (externí) prostředí lze znázornit také ve formě objektového diagramu (tento objektový diagram však nebude zahrnovat objekty, ale pouze subsystémy; každý subsystém je v diagramu znázorněn jako obdélník s dvojitými vertikálními stranami). Závislosti mezi subsystémy znázorněné v tomto objektovém diagramu (obr. 2.42) odrážejí interakci navrženého bankovního systému a odpovídajících subsystémů během provozu systému. Jsou tak určeny požadavky navrženého systému na jeho systémové prostředí.
Rýže. 2.41. Objektový diagram bankovní sítě, který specifikuje rozhraní s prostředím systému
Rýže. 2.42. Objektové schéma bankovní sítě a jejího systémového prostředí
Zavedení konceptu subsystému a schopnosti zahrnout do objektového modelu subsystémy spolu s objekty (třídami) určuje hierarchickou strukturu objektového modelu a umožňuje použití metodiky OMT při návrhu poměrně složitých softwarových systémů obsahujících velké množství různých objektů a tříd.
2.4.2. rozhraní a prostředí. Budou volány objekty a subsystémy, které tvoří subsystém vyšší úrovně komponenty poslední. Jak již bylo uvedeno, pro každou komponentu, která je součástí objektového modelu subsystému, jeho rozhraní, tj. sada otevřených (veřejných) operací, které lze aplikovat na tuto komponentu (objekt nebo subsystém).
Rozhraní objektu definována rozhraním odpovídající třídy a specifikována seznamem signatur jejích veřejných operací (metod). Rozhraní subsystému je definován prostřednictvím rozhraní jeho základních objektů a subsystémů takto: operace může být zahrnuta do rozhraní subsystému, pokud tento subsystém obsahuje objekt (subsystém), jehož rozhraní obsahuje tuto operaci. Rozhraní jsou popsána v jazyce popisu rozhraní IDL (Interface Definition Language).
Všechny možnosti zpracování dat v rámci subsystému (tj. v každé komponentě zahrnuté v jeho složení) jsou určeny sadou rozhraní jeho komponent, která určuje vnitřní prostředí subsystému.
Pokud se u některého subsystému ukáže, že žádná z jeho komponent neobsahuje operaci, kterou je žádoucí zahrnout do jeho rozhraní, lze do jeho složení přidat objekt, který takovou operaci implementuje. Takový objekt se nazývá objekt rozhraní. Objekty rozhraní vám umožňují sladit vnější rozhraní podsystému s jeho vnější prostředí, tj. s rozhraními dalších objektů a subsystémů, které spolu s uvažovaným subsystémem tvoří subsystém vyšší úrovně.
Vysvětleme si pojmy představené na příkladu systému bankovních služeb. Je možné vyčlenit bankovní subsystém v jeho složení (ve skutečnosti bude mít systém několik instancí bankovního subsystému - jednu pro každou banku zahrnutou v konsorciu). V tomto případě bude mít objektový model systému podobu znázorněnou na obr. 2.43.
Rýže. 2.43. Objektové schéma bankovní sítě po výběru bankovního subsystému
Zároveň vnější rozhraní subsystémů, banky a prostředí tvoří spolu s rozhraními objektů ATM a konsorcia vnitřní prostředí systému bankovních služeb. Jeho vnější prostředí je znázorněno na Obr. 2,42; skládá se z externí rozhraní různé softwarové systémy používané v bankovním systému (na obrázku je znázorněna pouze část těchto systémů) a vlastní externí rozhraní.
Koncepčním základem objektově orientovaného přístupu je objektový model. Hlavní principy jeho konstrukce jsou:
abstrakce;
Zapouzdření
modularita;
Hierarchie.
Abstrakce je výběr nejdůležitějších, podstatných charakteristik objektu, které jej odlišují od všech ostatních typů objektů, a tím jasně definují jeho pojmové hranice z hlediska dalšího zvažování a analýzy a ignorují méně důležité nebo nepodstatné detaily. .
Abstrakce vám umožňuje řídit složitost systému zaměřením na podstatné vlastnosti objektu. Abstrakce se zaměřuje na vnější vlastnosti objektu a umožňuje oddělit nejvýznamnější rysy jeho chování od detailů jejich implementace. Výběr správné sady abstrakcí pro danou doménu je velkou výzvou v objektově orientovaném designu. Abstrakce je závislá na doméně a úhlu pohledu – co je důležité v jednom kontextu, nemusí být důležité v jiném. Předměty a třídy jsou hlavní abstrakce předmětové oblasti.
Zapouzdření je fyzická lokalizace vlastností a chování v rámci jediné abstrakce (považované za „černou skříňku“), která skrývá jejich implementaci za veřejné rozhraní.
Zapouzdření je proces vzájemného oddělení jednotlivé prvky objekt, který určuje jeho strukturu a chování. Zapouzdření slouží k izolaci rozhraní objektu, které odráží jeho vnější chování, od vnitřní implementace objektu. Objektový přístup předpokládá, že jeho vlastní zdroje, se kterými lze manipulovat pouze operacemi samotného objektu, jsou skryty před vnějším prostředím. Abstrakce a zapouzdření se doplňují: abstrakce zaměřuje pozornost na vnější rysy objektu, zatímco zapouzdření (nebo jiné omezení přístupu) neumožňuje uživatelským objektům rozlišovat mezi vnitřní strukturou objektu.
Zapouzdření je podobné konceptu skrývání informací. Jedná se o schopnost skrýt četné detaily objektu před vnějším světem. Vnější svět objektu je vše, co je mimo něj, včetně zbytku systému. Skrytí informací poskytuje stejnou výhodu jako zapouzdření – flexibilitu.
Modularita je vlastnost systému spojená s možností jeho rozkladu na řadu vnitřně silně propojených, avšak slabě propojených subsystémů (modulů).
Modularita snižuje složitost systému tím, že umožňuje nezávislý vývoj jednotlivých modulů. Zapouzdření a modularita vytvářejí bariéry mezi abstrakcemi.
Hierarchie je seřazený nebo uspořádaný systém abstrakcí, jejich uspořádání podle úrovní.
Hlavními typy hierarchických struktur ve vztahu ke komplexním systémům jsou struktura tříd (hierarchie podle nomenklatury) a struktura objektů (hierarchie podle složení). Příklady hierarchií tříd jsou jednoduchá a vícenásobná dědičnost (jedna třída používá strukturální nebo funkční část jedné nebo více jiných tříd) a hierarchie objektů - agregace.
Třídy mohou být organizovány v hierarchické struktuře, která vzhled připomíná klasifikační schéma v pojmové logice. Hierarchie pojmů je konstruována následovně. Jako nejobecnější pojem nebo kategorie se bere pojem, který má největší objem, a tedy i nejmenší obsah. Tohle je nejvíc vysoká úroveň abstrakce pro danou hierarchii. Pak tohle obecný koncept se konkretizuje, to znamená, že se jeho objem zmenšuje a jeho obsah se zvětšuje. Objeví se méně obecný koncept, který se v hierarchickém diagramu bude nacházet o úroveň níže než původní. Tento proces konkretizace pojmů může pokračovat, dokud není získán koncept na nejnižší úrovni, jehož další konkretizace je v tomto kontextu buď nemožná, nebo nevhodná.