(nástroje UML, modely různých aspektů systémů v UML, vysvětlení a aplikace empirických zákonů)
Objektově orientovaná analýza je přístup k softwarovému inženýrství, který modeluje systém jako skupinu vzájemně interagujících objektů.
Přínosy objektově orientované analýzy.
Tvrdí se o ní, že je „přirozenější“ proti strukturované analýze
Abstrakce vymezuje podstatné znaky objektu, které jej odlišují od ostatních druhů objektů, a tak poskytuje ostře definované konceptuální hranice relativně podle perspektivy pozorovatele .1)
Princip použitý při vývoji celé programové struktury. Spočívá v tom, že každá komponenta programu by měla zapouzdřit a ukrýt jediné návrhové rozhodnutí. Rozhraní každého modulu je definováno tak, aby odhalilo co nejméně o vnitřním dění v modulu.2)
Mechanismus, který vyjadřuje podobnost mezi třídami, zjednodušuje definici třídy pomocí dříve definované třídy. Vyjadřuje generalizaci a specializaci tím, že v hierarchii tříd explicitně určuje společné atributy a služby.3)
Hlavní aktivity:
Nejedná se o sekvenční kroky. Rozpracované aktivity lze podle potřeby střídat v různém pořadí.
UML (Unified modeling language) je standardní jazyk pro zobrazení, specifikaci, konstrukci a dokumentaci artefaktů systémů s převážně softwarovou charakteristikou. Může být použit při všech procesech životního cyklu vývoje a pro různé technologie implementace.
UML kombinuje to nejlepší z
UML umožňuje:
Výsledkem jejich práce byl návrh UML (verze 0.9) a metodika RUP (Rational Unified Process). Standardizační organizace OMG v roce 1997 přijala jako standard UML verze 1.1 ve které byly začleněny prvky z dalších metodik (označení UML 1.0 se používá pro návrh, který poslala firma Rational Rose standardizační komisi).
Nejpoužívanější UML diagramy:
Diagram případů užití (Use Case Diagram) předkládá vnější pohled na systém.
Diagramy případů užití jsou tvořeny, aby znázornily vztahy mezi účastníky a případy užití.
Při tvorbě případů užití můžou být nalezeny další vztahy.
Diagram posloupnosti (Sequence diagram) ukazuje interakci mezi objekty uspořádanou do časové posloupnosti.
Diagram tříd (Class diagram) ukazuje existenci tříd a jejich vztahů v logickém pohledu na systém.
UML modelovací prvky používané v diagramech tříd:
Třída je kolekce objektů se shodnou strukturou, shodným chováním, shodnými vztahy a shodnou sémantikou.
Třída se znázorňuje obdélníkem, který obsahuje tři části :
Třídy a jejich operace mohou být nalezeny po přezkoumání diagramů interakcí (posloupnosti, spolupráce).
Atributy tříd, kterými je reprezentována struktura třídy, mohou být nalezeny přezkoumáním definice třídy, požadavků na problémy a použitím znalostí z předmětné oblasti.
Vztahy poskytující cestu pro komunikaci mezi objekty bývají odhaleny po přezkoumání diagramů interakcí – pokud dva objekty spolu hovoří, musí existovat komunikační cesta.
Vztahy:
Znázorňuje se jako čára propojující vztažné třídy.
Znázorňuje se jako čára propojující vztažené třídy, značka diamant je umístěna u třídy, která představuje celek. Agregace se značí prázdným diamantem, její silnější forma – kompozice – při které celek nemá bez částí smysl, se značí vyplněným diamantem. (Dle všeho je tedy notace ve slidech uvedena dle starší normy.)
Je ukázána jako čárkovaná čára se šipkou ukazující od klienta k poskytovateli.
Dědičnost se znázorňuje šipkou směrem od podtřídy k nadtřídě. Společné atributy a vztahy jsou zobrazeny na nejvyšší úrovni hierarchie.
Stavově přechodový diagram se tvoří pro objekty, které mají významné dynamické chování, ukazuje:
Diagram nasazení ukazuje konfiguraci procesních prvků použitých během běhu a softwarové procesy, které jsou na ně umístěny.
V těchto diagramech se velmi často používají stereotypy, a to tak, že mají přiřazen vlastní vizuální symbol – tedy např. tiskárna nevypadá jako krychle, ale opravdu nám připomíná tiskárnu, nebo server opravdu může vypadat jako schematické znázornění serveru. Pak jsou tyto diagramy přístupné i pro čtenáře, kteří naprosto neznají UML.
Diagram komponent znázorňuje uspořádání a závislosti mezi softwarovými komponentami. Komponentou mohou být:
UML je možné rozšiřovat dalšími prvky dle uvážení uživatele pomocí stereotypů. Stereotyp je vlastně nějaké rozšíření jazyka UML, může být prakticky libovolné, jde jen o to, aby bylo pro čtenáře pochopitelné.
Příklady stereotypů:
Systém používaný v reálném prostředí se neustále mění, dokud není levnější systém restrukturalizovat nebo nahradit zcela novou verzí.
Při evolučních změnách je program stále méně strukturovaný a vzrůstá jeho vnitřní složitost. Odstranění složitosti vyžaduje dodatečné úsilí.
Rychlost globálních změn atributů systému se může jevit v omezeném časovém intervalu jako náhodná. V dlouhodobém pohledu se však jedná o seberegulující proces, který lze statisticky sledovat a předvídat.
Celkový pokrok při vývoji projektů je statisticky invariantní. Jinak řečeno, rychlost vývoje programu je přibližně konstantní a nekoreluje s vynaloženými prostředky
Systém určuje přípustnou velikost přírůstku v nových verzích. Pokud je limita překročena, objeví se závažné problémy týkající se kvality a použitelnosti systému.
Náklady na začlenění nového pracovníka do týmu jsou zpravidla větší než jeho přínos.
Každý kdo někdy prošel vývojem jakéhokoli produktu narazil občas, nebo spíš skoro vždy na to že to není úplně totéž jako se nám snaží vtlouct do hlavy ve škole. Asi mi dáte za pravdu že to s projektem vypadá spíš nějak takhle…
Winsik - ICQ: 215787520 mail: winsik.cz(zavinac)gmail.com
Otázku jsem připravil podle sebe a jsem si vědom toho, že někomu může něco chybět, nebo že se někomu nebude líbit struktura nebo grafické zpracování. Proto pokud chcete můžete samozřejmě sami otázku upravit, doplnit co podle vás chybí, kontaktovat mne, a třeba připomínku vyjádřit v diskuzi, budu jen rád.