Objektově orientovaná analýza a 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ě.

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ů.

• 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í).

• 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.

• 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í.