Objektový přístup

1.3. Objektový přístup
Zmíněný základní rozpor funkčního a datového přístupu řeší přístup objektový. Tento přístup vyjadřuje principiální jednotu dat a procesů (časovou i obsahovou). Objekty vznikly bez souvislosti s metodikou návrhu IS a sloužili a slouží jako prostředek k usnadnění programování.
Základním modelem tohoto přístupu je objektový model. Skládá se z objektů a jejich vazeb. Základní vlastností objektů je, že obsahují jak data, tak i operace, které se těmito daty pracují (data=atributy, operace=metody). Objekty mají své charakteristické vlastnosti :
dědičnost, polymorfismus, zapouzdření,generalizace, specializace, abstrakce, synergie atd.
První skutečný standard objektového přístupu vznikl v roce 1997 v rámci působení společnosti OMG pod názvem UML (Unified Modelling Language). Vznikl sloučením mnoha metod objektové analýzy a návrhu, které vznikaly od počátku 90.let (Booch, OMT, Room, atd.) Tento standard si klade za cíl stát se nezávislým objektově orientovaným modelovacím jazykem. Jeho snahou je univerzálnost, interpretace modelů, postupy jejich tvorby a ostatní metodické záležitosti jsou vědomě odsunuty mimo oblast UML. Jeho součástí je sémantický metamodel, grafická notace (8 typů diagramů), pravidla pro správnost vytváření modelů a doménová rozšíření.

1.4. Prototypování
Klasický postup projektu je založen na sekvenčním pořadí jeho jednotl. fází. K návratům na předcházející fáze dochází pouze v případě objevení podstatných chyb, které nelze v rámci dané fáze odstranit.Čím později je chyba objevena, tím rostou náklady na její odstranění.
Cílem prototypového přístupu je minimalizovat nejistotu a rizika při řešení projektu využitím prototypů.
Výhody : pomáhá upřesnit požadavky uživatele, usnadňuje spolupráci, usnadňuje řešení problémů s návrhem a implementací SW systému, pomáhá vyhnout se chybám.
Nevýhody: přínos prototypu nemusí být úměrný vynaloženým prostředkům a času, je potřeba provést odhad nákladů a přínosů; prototyp se snadno přizpůsobuje uživatelským požadavkům, uživatel může nabýt dojmu, že se tak přizpůsobí i finální systém; problémem může být přesvědčit toho, kdo projekt financuje o nutnosti prototypování atd.
Obrázek viz. [VOŘ, str.147]

1.5. Inkrementální přístup [VOŘ]
Inkrementální (přírůstkový) vývoj aplikace si klade za cíl co nejrychlejší dosažení přínosů projektu. Klasické metodiky postupují při řešení projektu fáze po fázi, tzn. že přechod k další fázi řešení je podmíněn úspěšným dokončením celého řešení v předchozí fázi. Inkrementální vývoj aplikace naopak rozdělí řešenou aplikaci na menší celky, přičemž každá část aplikace prochází fázemi projektu samostatně. Každá verze inkrementálně vytvářené aplikace musí být provozovatelná ( k jejímu provozu nesmí být potřebné později vyvíjené části). Proto se úvodní studie rozšiřuje o návrh jádra aplikace a o návrh jednotlivých inkrementů.
Inkrementální vývoj aplikace lze výhodně kombinovat s prototypovým přístupem tak, že úspěšně otestovaný prototyp se stane základem pro vytvoření příslušného inkrementu aplikace.
Obrázek viz. [VOŘ, str.147]