OOAD – Object Oriented Design

Po fázi analýzy se konceptuální model dále rozvíjí do podoby objektově orientovaného modelu pomocí objektově orientovaného návrhu (OOD). Při OOD se technologicky nezávislé koncepty v analytickém modelu mapují na implementační třídy, identifikují se omezení a navrhují se rozhraní, čímž vzniká model pro doménu řešení. Stručně řečeno, je vytvořen podrobný popis specifikující, jak má být systém postaven na konkrétních technologiích

Fáze pro objektově orientovaný návrh lze identifikovat jako –

• Definice kontextu systému
• Navržení architektury systému
• Identifikace objektů v systému
• Konstrukce návrhových modelů
• Specifikace objektových rozhraní

Návrh systému

Objektový návrhorientovaný návrh systému zahrnuje definování kontextu systému, po kterém následuje návrh architektury systému.

• Kontext – Kontext systému má statickou a dynamickou část. Statický kontext systému se navrhuje pomocí jednoduchého blokového schématu celého systému, který je rozveden do hierarchie subsystémů. Model subsystému je reprezentován balíčky UML. Dynamický kontext popisuje, jak systém interaguje se svým okolím. Modeluje se pomocí diagramů případů užití.

• Architektura systému – Architektura systému se navrhuje na základě kontextu systému v souladu se zásadami architektonického návrhu a také znalostí domény. Obvykle je systém rozdělen do vrstev a každá vrstva je dekomponována tak, aby tvořila subsystémy.

Objektově orientovaná dekompozice

Dekompozice znamená rozdělení velkého složitého systému na hierarchii menších komponent s menší složitostí na principech rozděl a panuj. Každá hlavní součást systému se nazývá subsystém. Objektově orientovaná dekompozice identifikuje jednotlivé autonomní objekty v systému a komunikaci mezi těmito objekty.

Výhody dekompozice jsou –

• Jednotlivé komponenty jsou méně složité, a tak srozumitelnější a lépe ovladatelné.

• Umožňuje rozdělení pracovních sil, které mají specializované dovednosti.

• umožňuje nahradit nebo upravit subsystémy, aniž by to ovlivnilo ostatní subsystémy.

Identifikace souběžnosti

Souběžnost umožňuje, aby více objektů přijímalo události současně a aby se současně provádělo více činností. Souběžnost je identifikována a reprezentována v dynamickém modelu.

Pro umožnění souběžnosti je každému souběžnému prvku přiřazeno samostatné vlákno řízení. Pokud je souběžnost na úrovni objektu, pak jsou dvěma souběžným objektům přiřazena dvě různá vlákna řízení. Pokud jsou dvě operace jednoho objektu souběžné povahy, pak je tento objekt rozdělen mezi různá vlákna.

Konkurence je spojena s problémy integrity dat, deadlocku a hladovění. Proto je třeba vytvořit jasnou strategii, kdykoli je vyžadována souběžnost. Kromě toho je třeba souběžnost identifikovat již v samotné fázi návrhu a nelze ji ponechat až na fázi implementace.

Identifikace vzorů

Při návrhu aplikací se pro některé kategorie problémů přijímají obecně přijímaná řešení. Jedná se o vzory návrhu. Vzor lze definovat jako zdokumentovanou sadu stavebních bloků, které lze použít v určitých typech problémů vývoje aplikací.

Některé běžně používané vzory návrhu jsou –

• Vzor fasády
• Vzor oddělení pohledu na model
• Vzor pozorovatele

.

• Vzor kontroléru pohledu na model
• Vzor odběru publikace
• Vzor proxy

Kontrolér událostí

Při návrhu systému, je třeba identifikovat události, které mohou nastat v objektech systému, a vhodně je řešit.

Událost je specifikace významné události, která má své místo v čase a prostoru.

Existují čtyři typy událostí, které lze modelovat, a to –

• Signální událost – pojmenovaný objekt vyhozený jedním objektem a zachycený jiným objektem.

• Událost volání – synchronní událost představující odeslání operace.

• Časová událost – Událost představující plynutí času.

• Událost změny – Událost představující změnu stavu.

Obsluha okrajových podmínek

Fáze návrhu systému musí řešit inicializaci a ukončení systému jako celku i jednotlivých subsystémů. Jednotlivé aspekty, které jsou dokumentovány, jsou následující –

• Nastartování systému, tj. přechod systému z neinicializovaného stavu do ustáleného stavu.

• Ukončení systému, tj, uzavření všech běžících vláken, vyčištění zdrojů a odesílání zpráv.

• Počáteční konfigurace systému a rekonfigurace systému v případě potřeby.

• Předvídání selhání nebo nežádoucího ukončení systému.

Hraniční podmínky se modelují pomocí hraničních případů použití.

Návrh objektů

Po vytvoření hierarchie subsystémů se identifikují objekty v systému a navrhnou se jejich detaily. Zde projektant podrobně popíše strategii zvolenou při návrhu systému. Důraz se přesouvá od konceptů aplikační domény ke konceptům počítačů. Objekty identifikované během analýzy jsou vytyčeny pro implementaci s cílem minimalizovat dobu provádění, spotřebu paměti a celkové náklady.

Návrh objektu zahrnuje následující fáze –

• Identifikace objektu
• Prezentace objektu, tj, konstrukce návrhových modelů
• Klasifikace operací
• Návrh algoritmů
• Návrh vztahů
• Zavedení řízení vnějších interakcí
• Sbalení tříd a asociací do modulů

Identifikace objektu

Prvním krokem návrhu objektu je identifikace objektu. Objekty identifikované ve fázích objektově orientované analýzy se seskupí do tříd a upřesní tak, aby byly vhodné pro skutečnou implementaci.

Funkce této fáze jsou –

• Identifikace a upřesnění tříd v každém subsystému nebo balíčku

• Definice vazeb a asociací mezi třídami

• Navržení hierarchických asociací mezi třídami, tj, zobecnění/specializace a dědičnosti

• Navržení agregací

Objektová reprezentace

Po určení tříd je třeba je reprezentovat pomocí technik objektového modelování. Tato fáze v podstatě zahrnuje konstrukci diagramů UML.

Existují dva typy návrhových modelů, které je třeba vytvořit –

• Statické modely – Popis statické struktury systému pomocí diagramů tříd a objektových diagramů.

• Dynamické modely – K popisu dynamické struktury systému a zobrazení interakce mezi třídami pomocí interakčních diagramů a diagramů stavových diagramů.

Klasifikace operací

V tomto kroku se definují operace, které se mají provádět s objekty, kombinací tří modelů vytvořených ve fázi OOA, a to objektového modelu, dynamického modelu a funkčního modelu. Operace určuje, co má být provedeno, nikoliv jak to má být provedeno.

V souvislosti s operacemi se provádějí následující úkoly –

• Vypracovává se diagram přechodových stavů každého objektu v systému.

• Pro události přijímané objekty se definují operace.

• Jsou identifikovány případy, kdy jedna událost spouští další události ve stejných nebo různých objektech.

• Jsou identifikovány dílčí operace v rámci akcí.

• Hlavní akce jsou rozvedeny do diagramů toku dat.

Návrh algoritmů

Operace v objektech jsou definovány pomocí algoritmů. Algoritmus je krokový postup, který řeší problém stanovený v operaci. Algoritmy se zaměřují na to, jak se má postupovat.

Dané operaci může odpovídat více než jeden algoritmus. Po určení alternativních algoritmů se vybere optimální algoritmus pro danou problémovou oblast. Metriky pro výběr optimálního algoritmu jsou –

• Výpočetní složitost – složitost určuje efektivitu algoritmu z hlediska výpočetního času a paměťových nároků.

• Pružnost – pružnost určuje, zda lze zvolený algoritmus vhodně implementovat, aniž by došlo ke ztrátě vhodnosti v různých prostředích.

• Srozumitelnost – Určuje, zda je zvolený algoritmus snadno pochopitelný a implementovatelný.

Návrh vztahů

Strategii implementace vztahů je třeba vytyčit během fáze návrhu objektu. Hlavní vztahy, které se řeší, zahrnují asociace, agregace a dědičnosti.

Projektant by měl v souvislosti s asociacemi provést následující kroky –

• Identifikovat, zda je asociace jednosměrná nebo obousměrná.

• Analyzovat cestu asociací a v případě potřeby je aktualizovat.

• Implementovat asociace jako samostatný objekt v případě vztahů mnoho k mnoha; nebo jako odkaz na jiný objekt v případě vztahů jeden k jednomu nebo jeden k mnoha.

Vzhledem k dědičnosti by měl návrhář provést následující kroky –

• Upravit třídy a jejich asociace.

• Identifikovat abstraktní třídy.

• Učinit opatření, aby chování bylo v případě potřeby sdílené.

Implementace řízení

Projektant objektu může do strategie modelu stavového diagramu začlenit upřesnění. Při návrhu systému se provádí základní strategie realizace dynamického modelu. Při návrhu objektu se tato strategie vhodně zkrášlí pro vhodnou implementaci.

Přístupy k implementaci dynamického modelu jsou –

• Prezentace stavu jako místa v programu – Jedná se o tradiční procedurálně řízený přístup, kdy místo řízení definuje stav programu. Konečný stavový stroj může být implementován jako program. Přechod tvoří vstupní příkaz, hlavní cesta řízení tvoří posloupnost instrukcí, větve tvoří podmínky a zpětné cesty tvoří smyčky nebo iterace.

• State Machine Engine – Tento přístup přímo reprezentuje stavový stroj prostřednictvím třídy state machine engine. Tato třída provádí stavový stroj prostřednictvím sady přechodů a akcí poskytnutých aplikací.

• Řízení jako souběžné úlohy – V tomto přístupu je objekt implementován jako úloha v programovacím jazyce nebo operačním systému. Událost je zde implementována jako volání mezi úlohami. Zachovává inherentní souběžnost skutečných objektů.

Balíčkování tříd

V každém velkém projektu je důležité pečlivé rozdělení implementace do modulů nebo balíčků. Při návrhu objektů se třídy a objekty seskupují do balíčků, aby na projektu mohlo spolupracovat více skupin.

Různé aspekty balení jsou –

• Skrytí vnitřních informací před pohledem zvenčí – Umožňuje nahlížet na třídu jako na „černou skříňku“ a dovoluje měnit implementaci třídy, aniž by bylo nutné, aby klienti třídy měnili kód.

• Soudržnost prvků – Prvek, například třída, operace nebo modul, je soudržný, pokud je uspořádán na konzistentním plánu a všechny jeho části spolu vnitřně souvisejí tak, že slouží společnému cíli.

• Konstrukce fyzických modulů – Při konstrukci fyzických modulů pomáhají následující pokyny –

  • Třídy v modulu by měly reprezentovat podobné věci nebo komponenty ve stejném složeném objektu.

  • Těsně propojené třídy by měly být ve stejném modulu.

  • Nepropojené nebo slabě propojené třídy by měly být umístěny v samostatných modulech.

  • Moduly by měly mít dobrou soudržnost, tj,

  • Modul by měl mít nízkou provázanost s ostatními moduly, tj. interakce nebo vzájemná závislost mezi moduly by měla být minimální.

Optimalizace návrhu

Analytický model zachycuje logické informace o systému, zatímco návrhový model přidává podrobnosti pro podporu efektivního přístupu k informacím. Před implementací návrhu by měl být návrh optimalizován tak, aby byla implementace efektivnější. Cílem optimalizace je minimalizovat náklady z hlediska času, prostoru a dalších ukazatelů.

Optimalizace návrhu by však neměla být nadbytečná, protože důležitým zájmem je také snadná implementace, udržovatelnost a rozšiřitelnost. Často se setkáváme s tím, že dokonale optimalizovaný návrh je efektivnější, ale méně čitelný a znovu použitelný. Návrhář tedy musí najít rovnováhu mezi těmito dvěma aspekty.

Různé věci, které lze provést pro optimalizaci návrhu, jsou –

• Přidání nadbytečných asociací
• Vynechání nepoužitelných asociací
• Optimalizace algoritmů
• Uložení odvozených atributů, aby se zabránilo opětovnému výpočtu složitých výrazů

Přidání nadbytečných asociací

Při optimalizaci návrhu, se kontroluje, zda odvození nových asociací může snížit náklady na přístup. Ačkoli tyto nadbytečné asociace nemusí přidat žádnou informaci, mohou zvýšit efektivitu celého modelu.

Přidání nepoužitelných asociací

Přítomnost příliš mnoha asociací může způsobit, že systém bude nečitelný, a tím se sníží jeho celková efektivita. Proto jsou při optimalizaci všechny nepoužitelné asociace odstraněny.

Optimalizace algoritmů

V objektově orientovaných systémech se optimalizace datové struktury a algoritmů provádí ve spolupráci. Po vytvoření návrhu třídy je třeba optimalizovat operace a algoritmy.

Optimalizace algoritmů se dosahuje –

• Změnou pořadí výpočetních úloh
• Změnou pořadí provádění smyček oproti pořadí stanovenému ve funkčním modelu

.

• Odstranění mrtvých cest v rámci algoritmu

Ukládání a ukládání odvozených atributů

Odvozené atributy jsou takové atributy, jejichž hodnoty jsou vypočteny jako funkce jiných atributů (základních atributů). Opětovný výpočet hodnot odvozených atributů při každé jejich potřebě je časově náročný postup. Aby se tomu předešlo, lze hodnoty vypočítat a uložit v jejich vypočtené podobě.

To však může způsobit anomálie při aktualizaci, tj. změnu hodnot základních atributů bez odpovídající změny hodnot odvozených atributů. Aby se tomu předešlo, provádí se následující kroky –

• Při každé aktualizaci hodnoty základního atributu se znovu vypočítá i odvozený atribut.

• Všechny odvozené atributy se znovu vypočítávají a aktualizují pravidelně ve skupině, nikoli po každé aktualizaci.

Dokumentace návrhu

Dokumentace je nezbytnou součástí každého procesu vývoje softwaru, která zaznamenává postup tvorby softwaru. Rozhodnutí o návrhu je třeba dokumentovat u každého netriviálního softwarového systému pro předání návrhu ostatním.

Oblasti použití

Ačkoli se jedná o sekundární produkt, je dobrá dokumentace nepostradatelná, zejména v následujících oblastech –

• Při návrhu softwaru, který vyvíjí řada vývojářů
• Při iterativních strategiích vývoje softwaru
• Při vývoji dalších verzí softwarového projektu
• Pro vyhodnocení softwaru
• Pro zjištění podmínek a oblastí testování
• Pro údržbu softwaru.

Obsah

Přínosná dokumentace by měla v zásadě obsahovat následující obsah –

• Architektura systému na vysoké úrovni – Diagramy procesů a modulů

• Klíčové abstrakce a mechanismy – Diagramy tříd a objektové diagramy.

• Scénáře, které znázorňují chování hlavních aspektů – Diagramy chování

Funkce

Vlastnosti dobré dokumentace jsou –

• Souhrnné a zároveň jednoznačné, konzistentní a úplná

• Navazující na specifikace požadavků na systém

• Dobře strukturovaná

• Diagramatická místo popisné

.