Objektově orientovaná analýza a design

Objektově orientovaná analýza a design (object-oriented analysis and design – OOAD, resp. OOA&D) je jedním z přístupů používaným při tvorbě softwaru. V užším slova smyslu se jedná o popis systému jako skupiny samostatných objektů, které na sebe různě působí. V širším slova smyslu se jedná o komplexní přístup k tvorbě programů, který zahrnuje doporučené postupy (best practices) prakticky pro každý aspekt tvorby aplikací, které nakonec mají splňovat zákazníkovy požadavky (u kterých se předpokládají neustálé změny) a zároveň mají být snadno udržovatelné a rozšiřitelné.

Objektově orientovaný systém

Objektově orientovaný systém se skládá z objektů. Chování systému vyplývá ze spolupráce těchto objektů. Ta zahrnuje zasílání zpráv mezi objekty. Zasílání zpráv se od volání funkcí liší. Když totiž cílový objekt obdrží zprávu, sám se rozhodne, jakou funkci použít pro zpracování příchozí zprávy. Stejná zpráva také může být zpracována pokaždé jinak v závislosti na momentálním stavu cílového objektu. Ono zasílání zpráv může být implementováno různě. To záleží na architektuře modelovaného systému (resp. modelované reality) a umístění objektů, se kterými má komunikace probíhat.

Objektově orientovaná analýza

Objektově orientovaná analýza (OOA) zkoumá daný problém a klade si za cíl vytvořit konceptuální model informací, které patří do dané oblasti zkoumání. Analytické modely vůbec neberou v potaz jakákoliv omezení, se kterými se potýkáme při implementaci, ani konkrétní podobu budoucího systému.

Výsledkem OOA je popis funkčních požadavků na systém ve formě konceptuálního modelu. Ten se obvykle skládá z diagramů případů užití (use case diagrams), diagramů tříd (class diagrams) a několika interakčních diagramů (interaction diagrams). Také může zahrnovat náhledy uživatelských rozhraní. Cílem OOA je vytvořit model, který popíše software tak, jak pracuje, aby došlo k uspokojení všech zákazníkových požadavků.

Objektově orientovaný design

Objektově orientovaný design (OOD) přetváří konceptuální model vytvořený během objektově orientované analýzy v systém implementačních tříd a rozhraní. Přitom se berou v úvahu omezení způsobená zvolenou architekturou či nefunkčními požadavky jako např. počet najednou obsluhovaných uživatelů, doba odezvy, použitý hardware a operační systém, ale také vývojové prostředí a programovací jazyk.

Cílem OOD je definovat, jak má být systém vytvořen.

Vstupní zdroje pro objektově orientovaný design

Výstup objektově orientované analýzy se stává vstupem pro OOD. Ve skutečnosti výstupy OOA nemusí být úplně kompletní, aby mohly sloužit jako vstup pro OOD. Tyto procesy mohou probíhat současně a v praxi tomu tak často bývá – výsledky jednoho procesu totiž mohou ovlivňovat a usměrňovat ten druhý. Analýza i design mohou probíhat inkrementálním postupem a veškeré materiály (dokumentace, diagramy,…) mohou být vytvářeny postupně.

Základní koncepty objektově orientovaného designu

Existuje 5 základních konceptů OOD, které obvykle bývají zabudovány přímo do objektového programovacího jazyka. Tyto koncepty se běžně nazývají takto:

• Objekty/Třídy: Zahrnují datové struktury a metody pro přístup k těmto datům a práci s nimi. Každý objekt má svou jedinečnou funkci. Je definován svými vlastnostmi, tím, co je zač, a tím, co umí.
• Zapouzdření: Schopnost zabránit okolním entitám v přímém přístupu k některým částem objektu, ať už se jedná o data nebo metody.
• Dědičnost: Schopnost rozšířit funkcionalitu nadřízeného objektu. Toto může znamenat přidání nové funkcionality, jinou implementaci metod nadřízeného objektu (tzv. overriding), či dokonce dodání implementace (konkrétního obsahu) metodám, které nadřízený objekt definoval a využívá je, ale sám je není schopen implementovat.
• Rozhraní: Definice hlaviček metod, které říkají, jaké vstupy metoda potřebuje, a jaké má výstupy (co vrací). Rozhraním se také rozumí popis, CO daná metoda dělá, ale skrytí implementace, která říká, JAK to dělá. Jde také o možnost definice hlaviček metod bez definování jejich obsahu.
• Polymorfismus: Schopnost objektu měnit své chování v závislosti na stavu, ve kterém se nachází. V praxi se jedná o schopnost objektu vydávat se nejen sám za sebe, ale také za kterýkoliv z vlastních podobjektů.

Postupy objektově orientovaného designu

• Definice objektů, vytvoření diagramu tříd z konceptuálního modelu (obvykle jde pouze o namapování entity z konceptuálního diagramu na třídu diagramu tříd).
• Určení atributů
• Použití návrhových vzorů (pokud nějaký lze použít): Návrhový vzor je popis řešení nějakého obecného problému. Hlavní výhodou návrhového vzoru je, že může být použit v mnoha aplikacích. Objektově orientované návrhové vzory typicky ukazují vztahy a interakce mezi objekty, aniž by určovaly implementaci konkrétních tříd.
• Definice aplikačního rámce (pokud je to možné): Aplikačním rámcem (application framework) se většinou rozumí skupina knihoven či tříd, pomocí nichž se implementuje standardní struktura použitelná ve více aplikacích, které v nějaké své části potřebují využít stejnou funkcionalitu. Aplikační rámce šetří mnoho času, neboť programátor nemusí znovu vytvářet kód popisující nějakou standardní funkcionalitu použitelnou v aplikaci, na které právě pracuje.
• Nalezení persistentních objektů a/nebo dat (pokud existují): Persistentní data jsou taková data, která je třeba zachovat i po skončení běhu programu. V případě použití relační databáze je nutné specifikovat namapování objektů do této databáze (k čemuž se používá objektově-relační mapování).

Výstupy objektově orientovaného designu

• Sekvenční diagramy: Sekvenční diagram ukazuje postupnou výměnu zpráv mezi objekty (příp. procesy) – tzn. zaslání zprávy, její zpracování a následný návrat k původnímu procesu. Objekty jsou vymezeny v souběžných svislých liniích a vodorovně pod sebou je zobrazeno zasílání zpráv mezi těmito objekty tak, jak jde za sebou. Sekvenční diagram vlastně nabízí dynamický pohled na systém (klade důraz na chování systému).
• Diagram tříd: Diagram tříd popisuje strukturu systému. Obsahuje jednotlivé třídy, jejich atributy, některé metody a vazby mezi třídami. Na rozdíl od sekvenčního diagramu tedy nabízí statický pohled na systém (zobrazuje strukturu systému). Objekty a zasílané zprávy, které byly vytvořeny v jednotlivých sekvenčních diagramech, mohou sloužit jako vstup pro automatické vygenerování globálního diagramu tříd systému.

Některé principy a strategie

• Vložení do závislého objektu (dependency injection): Pokud objekt potřebuje vlastnit instanci jiného objektu, pak je lepší, když ho do závislého objektu vložíme zvenčí. Např. pokud náš objekt potřebuje databázové spojení, tak mu ho předáme jako parametr konstruktoru, místo toho, abychom ho vytvářeli interně.
• Vyhnutí se cyklům (acyclic dependencies principle): Graf závislostí, který zahrnuje jednotlivé balíčky či komponenty, by neměl obsahovat žádné cykly. Tzn. např. 3 třídy (balíčky…) by neměly záviset na sobě navzájem, ale pouze např. první na druhé a druhá na třetí.
• Princip znovupoužití částí (composite reuse principle): Tento princip říká, že by se mělo upřednostňovat skládání objektů pomocí polymorfismu před dědičností.

Související články

• Objektově orientované programování
• Softwarové inženýrství

Externí odkazy

• Obrázky, zvuky či videa k tématu Objektově orientovaná analýza a design na Wikimedia Commons

Literatura

• McLaughlin, B. D., Pollice, G., West, D.: Head First Object-Oriented Analysis and Design, Sebastopol, O'Reilly Media, 2006. (anglicky)