SWI041: UML a jeho použit projektování. Unified Modeling Language - jak se to zapisuje

SWI041: UML a jeho použití p i projektování Unified Modeling Language - jak se to zapisuje

Nejprve trochu kontroly Stav projekt

Metodiky SI Metodika = soubor prezenta ních technik (výrazových prost edk ) a metodických postup , které podporují systematický vývoj a údržbu programového díla, v etn plánování a ízení prací na programovém projektu. ím se mohou metodiky lišit ? prezenta ními technikami (notací) metodickými postupy (procesy) nástroji SWI041 - UML a jeho použití p i projektování

3

Pro UML? UML je unifikovaný vyjad ovací prost edek pro dokumentaci obsahové ásti informatických projekt (dokumentace projektu obsahuje ješt projektovou dokumentaci, která popisuje projekt jako takový). UML umož uje vyjád ení dokumentace analýzy, návrhu i implementace. UML byl vyvinut na základ zkušeností s mnoha r znými metodikami. UML umož uje i vyjád ení strukturovaného p ístupu, ale byl ur en zejména pro objektov -orientovaný p ístup. SWI041 - UML a jeho použití p i projektování

4

Nejprve OO odhalili programáto i Simula'67 (1962-67, poprvé zde byly uplatn ny OO koncepty jako t ída, objekt, d d ní a dynamicky vázané metody) Smalltalk (1972-80, prvý jazyk založený zcela na konceptu komunikujících objekt , novinkou je též virtuální stroj jako interpret "byte code“) C++ (1983, 1998 - ISO, OO rozší ení C, novinkou je zpracování výjimek) Eiffel (1986, novinkou jsou kontroly invariant , generické parametry, "garbage collection")

SWI041 - UML a jeho použití p i projektování

5

Pak se do toho vložili metodici 1.generace OO metodik: Rumbaugh - OMT (diagramy t íd) Coad/Yourdon - OOAD Martin - OOIE Booch - OOAD (diagramy komponent) Wirfs/Brock - RDD (model odpov dností) Jacobson - OOSE (model jednání - use cases)

Každá metodika p inesla n co nového, byla v n em lepší, ale zase n co postrádala snaha o kombinaci výhod SWI041 - UML a jeho použití p i projektování

6

A z stali u toho 2.generace OO metodik (kombinace výhod metodik 1.generace): Coleman - Fusion (kompletní cyklus) Rumbaugh/Booch - UM (Unified Method 0.8)

Z staly rozdíly v prezenta ních technikách, každá metodika používá svou notaci snaha o unifikaci 3.generace (unifikace prezenta ních technik): Rumbaugh/Booch - UM (Unified Method 0.8) 1996 - Rumbaugh/Booch/Jacobson - UML Unified Modeling Language 1.0) 1997 - OMG standard UML 1.1


7

Historie UML 1994 – zahájení vývoje UML (Rumbaugh, Booch) 1995 – notace pro Unified Method 0.8, p ipojuje se Jacobson a model jednání, Rational Unified Process 1996 – UML 1.0 (zabudování p ipomínek, kooperace) 1997 – UML 1.1 (precizn jší sémantika, p ijat jako standard OMG) 1999 – UML 1.3 (up esn ná verze 1.1) 2001 – UML 1.4 (komponenty) 2003 – UML 1.5 (diagramy aktivit, sémantika akcí) 2005 – UML 2.0 (nové diagramy, zm ny) - p vodn plánované ukon ení kv ten 2002, ale (p íliš mnoho hlav,obtížné) 2006 – UML 2.1 (další snaha o up esn ní sémantiky) SWI041 - UML a jeho použití p i projektování

8

Hlavní problém tvorby software nápad

? Jak to ud lat rychle, efektivn , bezchybn , …


class … … end;

9

Jak postupovat? Za ít hned kódovat? Nejd íve modelovat, pak kódovat? Zdá se, že vývoj software p ešel od kódem ízeného stylu ke specifikací ízenému stylu. Nejnov jší trend konsorcia OMG (Object Management Group) je modelem ízený vývoj (MDD – Model Driven Development), nebo také modelem ízená architektura (MDA).


10

Vývoj software jako posloupnost transformací Model 1

Transformace

Model 2


11

Model Driven Development Pracuje se co nejvíce s modelem


12

Modelem ízený vývoj v UML


13

6 dobrých zásad tvorby SW Vyvíjej iterativn a p ír stkov ádn rozpoznej a zpracuj požadavky Modeluj visuáln ( => UML) Používej komponentové technologie Kontinuáln ov uj kvalitu, testuj Snaž se být p ipraven na zm ny


14

Co to je UML? UML (Unified Modeling Language) je: „Standard konsorcia OMG (Object Management Group) pro záznam, vizualizaci a dokumentaci artefakt systém s p evážn softwarovou charakteristikou“.


15

Co není UML? UML není žádná metodika – slouží pouze pro vyjád ení artefakt ur itého typu, které metodiky požadují. Jsou metodiky, které UML intensivn využívají (nap . UP, RUP), jiné nikoliv. UML není všespasitelné (U znamená unifikovaný, nikoli univerzální).


16

T i úrovn využívání UML Jako notaci pro zachycení artefakt , na kterých se je pot eba domluvit. Lze jej využít jak p i p ímo (nakreslíme obrázek, abychom si up esnili imlementaci), tak zp tn (obrázek nám poslouží k pochopení existujícího kódu). Jako dokumenta ní prost edek, ve kterém dokumentujeme systém, i jeho ásti. Jako programovací jazyk, ze kterého se skute ná implementace (p esn ji asi jen její kostra) generuje. SWI041 - UML a jeho použití p i projektování

17

Jazykové jednotky UML Jazyk UML je rozd len do jednotek (language units), které p edstavují sdružené modelovací prvky pro ur itou oblast – nap . jednotka pro popis stavových automat umož uje vyjád ení chování ízeného diskrétními událostmi. Uživatelé nemusí vždy znát celý jazyk UML, ale posta í jim znalost n kterých jednotek.


18

Složky UML Elementární prvky (infrastruktura) Diagramy UML (superstruktura) OCL (Object Constraint Language – jazyk pro popis omezení) Vým nný formát (bu jen model – XMI, IDL, nebo v etn diagram konvertovaných do SVG)


19

Lexikální elementy UML ty i základní druhy element : et zec - posloupnost znak , znaková sada není omezena, v n kterých p ípadech doporu eno ASCII ikona - grafický symbol zastupující element, neobsahující žádné složky 2D-symbol - grafický symbol zastupující element, který má obsah, p ípadn rozd lený na oblasti spojnice - path - posloupnost úse ek, které navazují, mohou mít zvýrazn ny koncové body a mohou incidovat s hranicí 2D-symbol - slouží k vyzna ení propojení SWI041 - UML a jeho použití p i projektování

20

Identifikace element UML elementy pot ebujeme ozna ovat - pot ebujeme jména objekt , t íd, atribut , metod, … jméno - identifikátor (v etn ‘_’ nebo ‘-’) josefNovak, josef_novak, josef-novak kvalifikované jméno - jméno se vztahuje k n jakému kontextu (scope), explicitn : Ucetnictvi::Objednavka náv ští - et zec p idružený ke grafickému symbolu klí ové slovo <> (guillemets) SWI041 - UML a jeho použití p i projektování

21

Nejprve n které ikony

Ikona pro objekt

Podtržení vyzna uje jméno jedine ného objektu

Jedine ný objekt identifikovaný svým jménem


23

Ikona pro t ídu

T ída zahrnuje objekty stejného typu – se stejnými atributy a operacemi SWI041 - UML a jeho použití p i projektování

24

2D-symbol pro t ídu

T ída s atributy a operacemi


25

Ikona pro balík (package)

Logická skupina element


26

Spojnice

Vyjad uje vztah (v tomto p ípad symetrický vztah mezi t ídami) SWI041 - UML a jeho použití p i projektování

27

Spojnice

Vyjad uje závislost (v tomto p ípad , že n co implementuje n co jiného) SWI041 - UML a jeho použití p i projektování

28

Ikona pro p ípad užití (use case)

Záznam o p ípadu použití – vn systému m že nastat událost, na kterou musí systém reagovat SWI041 - UML a jeho použití p i projektování

29

Ikona pro aktéra

Uživatelská role nebo spolupracující systém


30

Nová ikona – rámec (frame) Package P

Dá se použít pro celý diagram, nebo pro n jaký jeho prvek (nap . zde pro balík P), nebo nap . jako interak ní rámec ve scéná i. Náv ští popisuje typ rámce (zde Package), identifikátor rámce (zde P) a p ípadné parametry (zde nic). SWI041 - UML a jeho použití p i projektování

31

P íklad použití rámce pro diagram sd demo

Zde je rámcem ozna en celý diagram typu „sd“ = „sequence diagram“ = scéná , který se jmenuje „demo“. SWI041 - UML a jeho použití p i projektování

32

P íklad použití rámce ve scéná i

Rámec je zde typu „loop“ (smy ka) a nemá jméno. Vyjad uje, že se ur itá ást scéná e opakuje pro každý seminá . SWI041 - UML a jeho použití p i projektování

33

Nová ikona pro „interface“

Nová ikona pro rozhranní (interface), vyjad ující p esn ji, kdo je poskytovatel (ball) a kdo konzument (socket).


34

Artefakt Artefakt je specifikace fyzického kousku informace, která je použita nebo produkována p i vývoji softwaru nebo p i jeho nasazení a použití. P íkladem artefaktu m že být modelový soubor, zdrojový soubor, skript, vykonatelný program, tabulka v databázi, libovolná sou ást dodávky, textový dokument, i zpráva. Instance artefaktu:


35

Použití artefaktu v diagramech Komponenta „Objednávka“ je „manifestována“ artefaktem „Objednávka.jar“


36

Poznámky Poznámka obsahuje libovolný text Zobrazuje se jako obdélník s „p ehnutým rohem“ M že být p idružena k elementu M že obsahovat stereotyp (nap . <> - pak se jedná o specifikaci omezení)


37

Výrazy v UML Výrazy v UML jsou et zce sestavené podle jistých pravidel (syntaxe výraz není striktní, je doporu eno používat OCL) Výraz p edstavuje formuli, kterou musí být možno v daném jazyce vyhodnotit (má sémantiku) Definice UML zahrnuje definici OCL (Object Constraint Language), který je použit pro definici sémantiky UML (metamodel UML) SWI041 - UML a jeho použití p i projektování

38

Navigace v OCL objekt.selektor ozna uje položku daného objektu (atribut, jméno role) objekt.selektor [ kvalifikátor ] ozna uje objekt vybraný podle kvalifikátoru (zobecn né pole) sada -> select ( logická podmínka ) ozna uje objekty vybrané z dané sady podle logické podmínky: Firma.zamestnanci -> select(funkce="ucetni")


39

Struktura UML 2.0 Specifikace standardu UML 2.0 je rozd lena do 4 ástí: definice infrastruktury – notace UML (syntax), definuje základní elementy, jádro UML spole né pro UML a související standardy, nap . MOF i CWM definice superstruktury - sémantika definovaná pomocí metamodelu, popis prvk metamodelu, konstrukty používané uživateli UML – elementy diagram a diagramy definice vým nné struktury (diagram interchange) – pro export a import model a diagram , formát pro vým nu dokument (diagram ) mezi r znými nástroji, specifikace p evodu do vým nných formát (CORBA IDL, XML DTD) Object Constraint Language (OCL) – jazyk pro formáln p esný popis r zných omezení platných v modelu


40

Aktuální verze UML 2.0 Superstructure Specification 2.0: Revised Final Adopted Specification (formal/05-07-04) August 2005 Infrastructure Specification 2.0: Revised Final Adopted Specification (formal/05-07-05) March 2006 Diagram Interchange Specification 2.0: Convenience Document (ptc/05-06-04) June 2005 OCL 2.0: Available Specification (formal/06-05-01) May 2006 http://www.uml.org


41

Infrastruktura UML (2.0)


42

Profily v UML P íklad: SysML je rozší ení UML, které využívá jen n které diagramy UML a p idává nové diagramy, které v UML nejsou.


43

UML 2

ást UML 2, která není využívána v SysML

SysML ást SysML, která není v UML

Spole ná ást SWI041 - UML a jeho použití p i projektování

44

Superstruktura UML (2.0)


45

Diagramy verze 1.5 a 2.0


46

Heirarchie diagram


47

Sm r pohledu na systém dle UML Diagramy popisující strukturu – diagramy t íd, objekt , komponent a nasazení Diagramy popisující chování – model jednání, scéná e, diagramy aktivit, kolaborace objekt , stavové diagramy Diagramy pro správu model – balíky (packages), subsystémy a modely


48

Rozši itelnost UML UML se snaží být univerzální notací pro všestranné použití od obchodního modelování po detailní návrh systém pro práci v reálném ase Notace, která by vy erpávajícím zp sobem pokryla tak široké spektrum pot eb by ale byla velmi komplikovaná a složitá UML proto definuje pouze základní ást (UML core) a umož uje rozší ení notace dle konkrétních pot eb


49

Nástroje rozši itelnosti UML Rozší ení UML lze dosáhnout použitím jiného jazyka pro výrazy (než OCL) Standardní sémantiku UML je možno doplnit standardními omezeními, která umož ují r znou interpretaci element : p íznaky (tags) – umož ují p idat k prvku diagramu další informace stereotypy (stereotypes) – umož ují klasifikovat elementy omezení (constraints) – umož ují specifikovat omezení pro elementy


50

P íznaky (tags) Umož ují p idat k prvku diagramu další informace ve form dvojice: { název atributu = hodnota } Název atributu m že být libovolný P íznaky se zapisují do složených závorek, p ipojují se k názvu prvku diagramu a typicky je lze použít nap íklad ke specifikaci verze, autora, i implementa ních poznámek: { autor="Josef Novák", verze=1.2 }


51

Stereotypy (stereotypes) Umož ují klasifikovat elementy diagram (a tím vyjád it další sémantiku) Zapisují se jako klí ová slova (mohou se p ípadn zobrazit jako ikony, což se p íliš nedoporu uje porušuje to princip jednotnosti) P íklady: <> <<entity>>

(ozna ení komponenty) (ozna ení t ídy reprezentující data)

Existují standardní stereotypy, nap .: <>, <<extend>>


52

Omezení Umož ují specifikovat požadavky na sémantiku prvk - lze pomocí nich formulovat r zná omezení v modelu Zapisují se jako výraz uzav ený do složených závorek P íklad: { po et_zaznamu < 10000 } Omezení se m že týkat více prvk - pak je spojeno s t mito prvky árkovanou árou


53

Poznámky Poznámka obsahuje libovolný text Zobrazuje se jako obdélník s „p ehnutým rohem“ M že být p idružena k elementu M že obsahovat stereotyp (nap . <> - pak se jedná o specifikaci omezení)


54

Diagramy objekt Objekt je pojem, abstrakce, nebo v c s dob e definovanými hranicemi a významem Každý objekt má t i charakteristiky: identitu, stav a chování. Stav objektu je jedna z možných situací, ve kterých se objekt m že nacházet. Stav objektu se m že m nit a je definován sadou vlastností - atribut a vztahy. Chování ur uje, jak objekt reaguje na žádosti jiných objekt a vyjad uje vše, co m že objekt d lat. Chování je implementováno sadou operací (metod). Identita znamená, že každý objekt je jedine ný.


55

Notace objekt libovolný objekt t ídy Student

unikátní objekt t ídy Student

unikátní objekt vztah „býti instancí“ SWI041 - UML a jeho použití p i projektování

t ída 56

Vztahy mezi objekty instance vztahu je vždy 1..1

instance vztahu

vztah SWI041 - UML a jeho použití p i projektování

vztah má kardinalitu 57

Diagramy t íd Pro definici atribut se používá notace:

viditelnost jméno [ násobnost ] : typ = po áte ní hodnota { omezení, vlastnost } Pro definici operací (metod) se používá notace:

viditelnost jméno(druh jméno: typ, …) : typ { omezení, vlastnost } Viditelnost: + ... public # ... protected - ... private Násobnost: [ a..b ] ( [ 0..1 ] m že být NULL) Druh: in, out, inout (implicitn in) SWI041 - UML a jeho použití p i projektování

58

Notace t íd Student

Student jmeno : string pocetKreditu : integer = 0 datumNarozeni : date getJmeno()

viditelnost ikonou SWI041 - UML a jeho použití p i projektování

statická metoda 59

Stereotypy a t ídy Stereotypem lze zavést nový druh prvku modelování. Zde m žeme tvo it nové druhy (skupiny) t íd. Nej ast jšími skupinami (stereotypy) t íd jsou: entitní t ídy (stereotyp je <<entity>>), t ídy rozhraní (stereotyp je <>) a t ídy ídicí (stereotyp je <>).


60

T ídy se stereotypy


61


62


63

Balíky (packages) Logická skupina element


64

Vztahy mezi t ídami vztah (asociace) - vyzna ení možného vztahu mezi objekty role – ozna ení konce vztahu, které íká, jakou roli objekt ve vztahu hraje Pro vyjád ení kardinality a volitelnosti se používá notace: N..M, kde N a M m že být íslo nebo * (samotná * znamená 0..*) jméno vztahu


role

65

P idružené t ídy (atributy vztah ) Vztah nemá atributy, ale m že být popsán p idruženou t ídou

p idružená t ída


66

Agregace a generalizace agregace (aggregation) – druh vztahu, kdy jedna t ída je sou ástí jiné t ídy - vztah typu celek/ ást kompozice (composition) – siln jší druh agregace - u kompozice je ást p ímo závislá na svém celku, zaniká se smazáním celku a nem že být sou ástí více než jednoho celku generalizace (generalization) – druh vztahu, kdy jedna t ída je zobecn ním vlastností jiné t ídy (jiných t íd) vztah typu nadtyp/podtyp, generalizace/specializace


67

P íklad agregace a generalizace generalizace

agregace SWI041 - UML a jeho použití p i projektování

68

Další možnosti Kvalifikované vztahy Navigované vztahy Odvozené atributy a vztahy (p edzna í se ‘/’) Parametrizované t ídy (generiky) Generické instance „Interface“ - t ída bez atribut


69

Model jednání (Use Case Model) Viz: Úvodní studie


70

Scéná e událostí (Sequence diagrams) (zachycení sledu událostí) Prvky: objekty - znázorn né obvykle jako sloupce interakce mezi objekty (stimuly) orientované šipky mezi objekty události - události, které vyvolaly interakci reakce - odezvy na události (výstupy) asová osa - pro vyzna ení sledu událostí


71

Scéná pro “p ejímku”


72

Scéná pro “dodávku”


73

Diagramy spolupráce (kolaborace) Podobn jako scéná e inností dokumentují spolupráci objekt p i ešení úlohy Kladou d raz na komunika ní aspekt ( as je vyjád en íslováním) Dokumentují objekty a zprávy, které si posílají p i ešení problému Jsou vhodné pro popis spolupráce objekt p i návrhu komunikace


74

P íklad diagramu spolupráce

asování SWI041 - UML a jeho použití p i projektování

75

Stavové diagramy Slouží k popisu dynamiky systému Stavový diagram definuje možné stavy, možné p echody mezi stavy, události, které p echody iniciují, podmínky p echod a akce, které s p echody souvisí Stavový diagram lze použít pro popis dynamiky objektu (pokud má rozpoznatelné stavy), pro popis metody (pokud známe algoritmus), i pro popis protokolu (v etn protokolu o styku uživatele se systémem)


76

Notace stavových diagram po áte ní stav

událost, která vyvolala p echod

stav akce p echod

koncový stav SWI041 - UML a jeho použití p i projektování

77

Dopl ky ke stavovým diagram m P echod m že být ohodnocen:

událost(parametry)[podmínka]/akce^zpráva Každý stav m že obsahovat popis akcí pro události vstup, výstup a opakované provád ní: entry/akce exit/akce do/akce Stavové diagramy mohou být hierarchické Mohou obsahovat synchroniza ní zna ky


78

Diagramy aktivit Varianta stavových diagram , kde stav p edstavuje aktivitu, p echody jsou vyvolány dokon ením akce (jsou synchronní) Používají se pro dokumentaci t íd, metod, nebo p ípad použití (jako „workflow“) Nahrazují do ur ité míry v UML neexistující diagramy datových tok Proti stavovým diagram m mohou obsahovat symboly „rozhodnutí (branch)“, „slou ení (merge)“, „rozv tvení (fork)“ a „spojení (join)“ Mohou obsahovat okruhy zodpov dnosti (organiza ní jednotky, plavecké dráhy (swimlanes)


79

P íklad diagramu aktivity rozhodnutí aktivita

synchronizace SWI041 - UML a jeho použití p i projektování

80

Inspekce (audit)


81

Diagram aktivity pro „p ivolání výtahu“


82

Diagram aktivity pro „dodávku“


83

Diagramy komponent Vyjad ují (fyzickou) strukturu komponent systému Popisují typy komponent - instance komponent jsou vyjád eny v diagramu nasazení Komponenty mohou být vno eny do jiných komponent P i vyjad ování vztahu mezi komponentami lze používat „interface“


84

P íklad diagramu komponent

vztah

interface

komponenta SWI041 - UML a jeho použití p i projektování

85

Diagramy nasazení Popisují fyzické rozmíst ní element systému na uzly výpo etního systému Uzly a elementy jsou zna eny obdobn jako objekty a t ídy (m že být uveden pouze typ, nebo konkrétní instance a typ - podtržena) Popisují nutné vazby mezi uzly (p ípadn též použitý protokol - „interface“) Obsahují pouze komponenty pot ebné pro b h aplikace komponenty pot ebné pro p eklad a sestavení jsou v diagramu komponent


86

P íklad diagramu nasazení uzel

instance komponenty SWI041 - UML a jeho použití p i projektování

komunikace

interface 87

P íklad diagramu nasazení


88

P íklad diagramu nasazení


89

OCL - Object Constraint Language pochází z metodiky Syntropy je ist funkcionální (bez vedlejších efekt ) není to programovací jazyk - je ur en pro vyjád ení invariant - je to specifika ní jazyk je siln typovaný (každý výraz OCL má definován typ) má p eddefinovanou sadu typ


90

Kdy použít OCL? pro vyjád ení integritních omezení v datovém modelu (diagramu t íd) pro vyjád ení typových omezení p i definici stereotyp pro popis vstupních a výstupních podmínek operací, nebo pro popis operací (metod) ve tvaru: operace(x1, …, xn) = výraz kde výraz m že obsahovat x1, …, xn jako naviga ní jazyk


91

Jak vypadá zápis v OCL? context <jméno> [inv|pre|post]: klí ové slovo context slouží pro definici kontextu pro výraz v OCL, nap . zápis:

context Student inv : ozna uje, že uvedený výraz se vztahuje k instanci kontextu (t ídy) Student (na kterou se lze odkazovat klí ovým slovem self

klí ová slova inv,pre,post zastupují stereotypy <>, <<precondition>>, <<postcondition>>


92

P íklad zápisu v OCL context Student inv: self.kredity > 10 tento zápis vyjad uje, že pro každou instance t ídy Student, musí mít atribut kredity hodnotu v tší než 10 context s:Student inv: s.kredity > 10 ozna uje totéž context s:Student inv platnýStudent : s.kredity > 10 zavádí pro toto integritní omezení jméno P íklad popisu metody: context Student::pridejKredity(kolik: Integer) : Integer pre : kolik > 1 -- nemá smysl p idávat mén post : result = self.kredity@pre + kolik SWI041 - UML a jeho použití p i projektování

93

Typy v OCL p edefinované primitivní typy (s obvyklými operacemi): Integer, Boolean, Real, String konstruktory: Collection, Set, Bag, Sequence s operátory: collect, select, reject, forAll, exists, iterate, include, count, union, intersect, isEmpty, notEmpty, isUnique, ...


94

Lokální objekty (let) context Student inv : let Po et : Integer = self.kredity in if postupuje then Po et > 10 else Po et <= 10 endif kde postupuje je atribut (odvozený) t ídy Student


95

Odkazy v OCL context Student inv: self.predmety -> isEmpty má hodnotu true, pokud student nemá zapsán žádný p edm t, jinak false context Student inv : self.predmety -> pocetKreditu > 3 má hodnotu true, pokud student nemá zapsán žádný p edm t, jehož kredity jsou menší, jinak false context Osoba inv : self.zena -> nonEmpty implies self.zena.pohlavi = #zena vyjad uje fakt, že ženou osoby m že být pouze žena SWI041 - UML a jeho použití p i projektování

96

P íklad - neformáln


97

P íklad – formáln v OCL


98

P íklad podmínek v OCL

context Mortgage inv: security.owner = borrower context Person::getMortgage(sum : Money, security : House) pre: self.mortgages.monthlyPayment->sum() <= self.salary * 0.30 SWI041 - UML a jeho použití p i projektování

99

P íklad: (meta)model elementu


100

P íklad využití OCL


101

P íklad: podmínky v OCL

/ownedElement: Element[*] - elementy, které vlastní daný element (je to odvozené sjednocení) SWI041 - UML a jeho použití p i projektování

102


/owner: Element [0..1] – element, který vlastní tento element – je to odvozené sjednocení (union) SWI041 - UML a jeho použití p i projektování

103


Operace allOwnedElements() vrací všechny elementy, které p ímo i nep ímo vlastní daný element. Element::allOwnedElements(): Set(Element); allOwnedElements = ownedElement -> union(ownedElement -> collect(e|e.allOwnedElements() SWI041 - UML a jeho použití p i projektování

104


Element nem že p ímo, nebo nep ímo vlastnit sám sebe: not self.allOwnedElements() -> includes(self)


105

Základní principy UML - 1 (ze 2) Modularita - tento princip požaduje velkou soudržnost a malou souvztažnost p i organizaci modelovacích konstrukt do balík a komponent metamodelu. Vrstvení (Layering) - vrstvy v definici metamodelu UML odpovídají základní 4-vrstvé architektu e UML, struktura balík je vytvá ena tak, aby nižší vrstvy využívaly konstrukty z vyšších vrstev. D lení (Partitioning) - uvnit jednotlivých vrstev je dbáno na odd lování samostatných koncept . V p ípad základu jádra (InfrastructureLibrary), je snaha d sledn odlišit sou asné a budoucí prvky standardu. P i tom je nutno dbát na zachování soudržnosti a pokud možno malé souvztažnosti. SWI041 - UML a jeho použití p i projektování

106

Základní principy UML - 2 (ze 2) Rozši itelnost (Extensibility) - UML m že být rozši ováno dv ma zp soby:

Nový dialekt UML m že být definován pomocí profil (InfrastructureLibrary::Profiles) tak, aby se obecné definice p izp sobily konkrétní platform (nap . J2EE/EJB, .NET/COM+) a konkrétní domén aplikace (nap . finance, telekomunikace, letectví apod.) Nový jazyk t ídy UML m že být budován nad spole ným základem, tj. s využitím ástí infrastruktury (InfrastructureLibrary), které se doplní o pot ebné metat ídy a metavztahy. Prvým zp sobem vznikne dialekt UML, druhým nový prvek t ídy UML jazyk .

Znovupoužití (Reuse) - základní knihovny prvk jsou vytvá eny tak, aby byly znovupoužitelné nejen pro definici UML, ale i pro architektonicky podobné metamodely jako je Meta Object Facility (MOF) nebo Common Warehouse Model (CWM). SWI041 - UML a jeho použití p i projektování

107

Úrovn shody UML UML je modulární jazyk se širokým záb rem. Pro vyjád ení úrovn vym nitelnosti dokument mezi r znými nástroji definuje UML tzv. úrovn shody (compliance levels). Na úrovni infrastruktury jsou jen 2 úrovn : Úrove 0 (Level 0 - L0). Zahrnuje jedinou základní jazykovou jednotku, která se týká vyjád ení struktury pomocí t íd. Jinými slovy, na této základní úrovni si nástroje mohou informace vym ovat pouze ve form popisu t íd. Konstrukce metamodelu (Metamodel Constructs LM). Tato úrove p idává další jazykovou jednotku pro budování meta-modelu nad CMOF (Complete Meta Object Facility) SWI041 - UML a jeho použití p i projektování

108

Úrovn shody pro superstrukturu Úrove 0 (Level 0 - L0). Zahrnuje jedinou základní jazykovou jednotku, která se týká vyjád ení struktury pomocí t íd. Jinými slovy, na této základní úrovni si nástroje mohou informace vym ovat pouze ve form popisu t íd (viz infrastruktura). Úrove 1 (Level 1 - L1). Tato úrove p idává k požadavk m na úrovni 0 další jazykové jednotky pro p ípady užití, interakce, struktury, akce a aktivity. Úrove 2 (Level 2 – L2). Tato úrove p idává k požadavk m na úrovni 1 další jazykové jednotky pro nasazení, stavové diagramy a profily. Úrove 3 (Level 3 – L3). Tato úrove p idává k požadavk m na úrovni 2 další jazykové jednotky pro modelování informa ních tok , šablon a balík . SWI041 - UML a jeho použití p i projektování

109

Záv r Jazyk UML se ve verzi 2.0 snaží posloužit pro pot eby specifikací ízeného vývoje, kdy pracujeme s modely a implementaci generujeme. Samotné diagramy jazyka UML pro modelování nesta í. Neumož ují popsat všechny skute nosti a podmínky platné v modelovaném sv t . UML proto obsahuje speciální formální jazyk OCL pro p esné formální vyjád ení r zných omezení a podmínek. Teprve model dopln ný o výrazy zapsané v OCL poskytuje dostatek informací pro nástroje podporující specifikací ízený vývoj (MDD – Model Driven Development). SWI041 - UML a jeho použití p i projektování

110

The End

SWI041: UML a jeho použit projektování. Unified Modeling Language - jak se to zapisuje

Recommend Documents