AP14 Objektově-orientovaná analýza a návrh

(nástroje UML, modely různých aspektů systémů v UML, vysvětlení a aplikace empirických zákonů)

Objektově orientovaná analýza

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.

  • Zvládnutí náročnějších problémových oblastí.
  • Zlepšení interakce mezi analytikem a expertem v dané oblasti.
  • Zvýšení vnitřní konzistence analytických výsledků.
  • Explicitní vyjádření společného
  • Vytvoření modifikovatelných specifikací.
  • Opětné použití analytických výsledků
  • Konzistentní nosná reprezentace pro analýzu a návrh.

Tvrdí se o ní, že je „přirozenější“ proti strukturované analýze

  • Během vývoje systému mají funkce a procesy tendenci se měnit, zatímco objekty mají tendenci zůstávat beze změn.
  • …vlivem toho může model podle strukturované analýzy časem přestat platit, zatímco objektově orientovaný model nezestárne
  • …proto se tvrdí, že objektově-orientované systémy jsou lépe udržovatelné.

Principy zvládnutí složitosti

  • Abstrakce

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)

  • Zapouzdření

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)

  • Dědičnost

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)

  • Sdružování
  • Komunikace pomocí zpráv
  • Postupné metody organizace
  • Měřítko
  • Kategorie chování

Coad & Yourdon: 5vrstvý model

4)

  • vrstva subjektů
  • vrstva Tříd & Objektů
  • vrstva struktury
  • vrstva atributů
  • vrstva služeb

Hlavní aktivity:

  1. Nalezení Tříd & Objektů
  2. Identifikace struktur
  3. Identifikace subjektů
  4. Definice atributů
  5. Definice služeb

Nejedná se o sekvenční kroky. Rozpracované aktivity lze podle potřeby střídat v různém pořadí.

UML

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

  • konceptů datového modelování.
  • modelování výrobních procesů
  • modelování objektů
  • modelování komponent

UML umožňuje:

  • zobrazovat hranice systému a jeho hlavních užití pomocí případů užití a účastníků.
  • ilustrovat realizaci případů užití pomocí diagramů interakcí.
  • reprezentovat statickou strukturu systému pomocí diagramu tříd.
  • modelovat chování objektů, pomocí stavově přechodových diagramů
  • odhalit fyzickou implementační strukturu, pomocí diagramů zapojení komponent.
  • rozšířit funkcionalitu pomocí stereotypů.

Vývoj UML začal v roce 1994, kdy Grady Booch a Jim Rumbaugh začali ve firmě Rational Software (nyní součást firmy IBM) spojovat své metodiky – Booch a OMT (Object Modeling Technique). Na konci roku 1995 do firmy Rational Software vstoupil Ivar Jacobson se svojí metodologii OOSE (Object-Oriented Software Engineering).

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í

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.

  • vztah «uses» (užívá) ukazuje chování, které je společné dvěma a více případům užití, části nemůžou bez používané třídy fungovat .
  • vztah «extends» (rozšiřuje) ukazuje volitelné chování.

Realizace případů užití se popisuje pomocí interakčních diagramů.

  • diagramy posloupností.
  • diagramy spolupráce.

Diagram posloupností

Diagram posloupnosti (Sequence diagram) ukazuje interakci mezi objekty uspořádanou do časové posloupnosti.

Diagram spolupráce

Diagram spolupráce (Collaboration diagram) ukazuje interakce objektů a jejich propojení mezi sebou.

Diagram tříd

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řídy, jejich struktura a chování
  • asociace, agregace, závislosti a vztahy dědění.
  • příznaky (ukazatele) násobnosti a navigace.
  • jména rolí

Třída

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 :

  • jméno
  • atributy
  • metody

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 mezi třídami

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:

  • Asociace – obousměrné propojení mezi třídami.

Znázorňuje se jako čára propojující vztažné třídy.

  • Agregace – je silnější forma vztahu, jedná se o vztah mezi celkem a jeho částmi.

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

  • Závislost – je slabší forma vztahu mezi klientem a poskytovatelem, kde klient nemá žádnou sémantickou znalost o poskytovateli.

Je ukázána jako čárkovaná čára se šipkou ukazující od klienta k poskytovateli.

  • Dědičnost – je vztah mezi nadtřídou a jejími podtřídami. Existují dvě cesty jak ji nalézt – zobecnění a specializace.

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.

  • Násobnost – definuje, kolik objektů se účastní vztahů. Násobnost je počet instancí jedné třídy vztažené k jedné instanci druhé třídy. Pro každou asociaci a agregaci musí být nalezeny dvě násobnosti, pro každý konec vztahu.

Stavově přechodový diagram

Stavově přechodový diagram se tvoří pro objekty, které mají významné dynamické chování, ukazuje:

  • životní historii dané třídy,
  • události, které způsobují přechod z jednoho stavu do druhého
  • akce, které jsou výsledkem změny stavu

Diagram nasazení

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

Diagram komponent znázorňuje uspořádání a závislosti mezi softwarovými komponentami. Komponentou mohou být:

  • komponenty zdrojového kódu (source code components)
  • binární komponenty (binary code components)
  • spustitelné komponenty (executable components)

Rozšiřování UML

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

  • stereotyp tříd: hranice, entity, utility, výjimky
  • stereotyp dědičnosti: «uses» a «extends»
  • stereotyp komponent: subsystém
  • stereotyp nasazení: obrázky procesních prvků

Empirické zákony

Lehmanovy zákony

  • Zákon trvalé proměny

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

  • Zákon rostoucí složitosti

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

  • Zákon vývoje programu

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.

  • Zákon invariantní spotřeby práce

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

  • Zákon omezené velikosti přírůstku

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.

Brooksův zákon

Přidání řešitelské kapacity u opožděného projektu může zvětšit jeho zpoždění

Náklady na začlenění nového pracovníka do týmu jsou zpravidla větší než jeho přínos.

Předměty

Použitá literatura

Kam dál

  • UML a objektový návrh je probíráno více v předmětu - FI:PA103 Objektové metody návrhu informačních systémů
  • UML : co je UML Web o návrhu systému.
  • Visual paradigm Dle mého nejlepší a nejdostupnější nástroj pro UML modelování.

Jedna k dobru

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…

Vypracuje

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.

1) skripta, kapitola OOA, strana 7
2) skripta, kapitola OOA, strana 8
3) skripta, kapitola OOA, strana 14
4) skripta, kapitola OOA, strana 22

Diskuze

, 2008/05/31 00:30

nějak mám pocit že jsem dal malé obrázky, stačí to tak nebo je natípat znovu?

, 2008/05/31 07:41

Obrázky jsou úplně v pohodě (vidím je i bez brýlí :))

, 2008/06/05 11:29

ahoj, mel bych jenom pripominku k «uses» - tam bych dopsal, ze casti nemuzou bez pouzivane tridy fungovat (narozdil od «extend»). dal u agregace je znacka prazdny diamant (plny je az u kompozice, coz je existencne silnejsi agregace http://en.wikipedia.org/wiki/Class_diagram#Aggregation). jinak pekny :).

, 2008/06/13 14:30

Pozor. Neplťte si dyně s baňama :) «use», «access», «import», «instances» a popřípadě «trace» stereotypy používáme v diagramu tříd («access» a «trace» konkrétně u balíků). V diagramu případu užití jsem se setkal jen s «import» a «extend». Samozřejmě, «use» nebo «uses» můžete použít i v případu užití, ale musíte si ho řádně zadefinovat.

, 2008/06/16 15:00

U těch use case diagramů (diagramů případů užití) se v UML 2.0 používají stereotypy «include» a «extend»..

, 2008/06/13 14:42

Jo, a kde jsi přišel na toto? „Realizace případů užití se popisuje pomocí interakčních diagramů.“ Realizace PU se popisuje může popsat dvojím (respekt. trojím) způsobem. 1. Pomocí toku událostí 2. tzv. scénáři 3. diagramem aktivit.
Interakční diagramy nám spíše popisuje dynamické chování statického diagramu tříd.

, 2008/06/15 22:04

Jako jasne, v UML se da vsechno delat ruznymi zpusoby, o tom to je.

Ta veta je ze skript malicko prepsana :

„Interakční diagramy popisují, jak jsou případy
užití realizovány jako interakce mezi skupinami
objektů.“

skripta kapitola UML, strana 14.

«extends» a «uses» jsou uz dnes standartizovane stereotypy pro use case. uses opravdu nemuze bez daneho pripadu uziti byt. opet ze skript, ja jsem vychazel primo ze skript, v bakalarskem se uml nikde jinde nebere.

Pokud se neco da napsat jinak nebo lepe, davam ti samozrejme volnou ruku :)

Z meho pohledu… co si nebudu jisty proste nereknu, 15+7 min je dost kratka doba i na nakresleni prikladu diagramu, nijak do podrobna osobne zachazet nebudu.

, 2008/06/16 21:42

Jj, mas to ok… je tady vse zakladni… ale tak pro jistotu rikam mouchy co vidim. Prestne tak, interakcni diagramy resi interakci mezi objekty. To je ta podstata.
K tomu «uses». Já začal pracovat až s UML 2.0, takže pokud v 1.1 bylo «uses» pak sorry. To jsem nevedel. Ale to jsou stejne jen detaily… :)

You could leave a comment if you were logged in.
home/prog/ap14.txt · Poslední úprava: 2014/10/27 09:07 (upraveno mimo DokuWiki)
Nahoru
CC Attribution-Noncommercial-Share Alike 3.0 Unported
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0