7.

tétel Ön egy olyan munkacsoport tagja, mely egy internetes videotéka-alkalmazás

modellezését kapta feladatául. A modellezéshez az UML-t használják.
Mutassa be a konkrét példán keresztül az UML felépítését, elemeit!

Információtartalom vázlata

Szabványos modellező nyelv (UML)

- Az UML célja, rendeltetése
- Az UML elemei
- Architektúra
- Építőelemek
- Elemek
- Relációk
- Diagramok
- Szabályrendszer
- Mechanizmusok

UML
(Unified Modeling Language)

Története:

Objektumközpontú modellezést már a ’80-as években is használtak, elsősorban az

objektumorienált programok tervezésére, és egyéb célokra is. A ’90-es években több,
egymástól független modellező nyelvet is kifejlesztettek, majd 1997-ben lett az UML
benyújtva az Object Management Group nevű független szabványszervezethez, mely azóta is
fejleszti.

Az UML definíciója
Az OMG definíciója az UML-ről:
Az egységesített modellező nyelv (UML) egy grafikus nyelv egy szoftver-intenzív rendszer
termékeinek megjelenítésére, specifikálására, felépítésére és dokumentálására. Az UML
szabványos lehetőségeket kínál a rendszer felvázolásához, beleértve a fogalmi dolgokat, mint
üzleti modellezés és rendszerfunkciók, valamint a konkrét dolgokat, mint programnyelvi
utasítások, adatbázis sémák és újrafelhasználható szoftverkomponensek."

Az UML általános célú modellező nyelv, így nem csak szoftverekről készíthető vele modell.
Nagyon széleskörűen használható:

 Rendszerek, szervezetek
 Szereplők
 Üzleti tevékenységek, folyamatok
 Logikai összetevők
 Szoftverek, programok
 Adatbázisok modellezésére is.
Az UML elemei

Elemek
- strukturális: osztály, interfész, együttműködés, use case, aktív osztály, komponens,
csomópont (működés)
- viselkedési: egymásrahatás, állapot
- csoport elem: package-ek
- megjegyzés elem: jegyzet

Architektúra
Egy rendszer alapvető szerkezeti felépítése, amely a komponenseiben, ezek egymáshoz ill. a
környezethez való kapcsolódásaiban, valamint azon elvekben fejeződik ki, amelyek a
rendszer tervezését, működését és továbbfejlesztését meghatározzák.

Szoftver architektúra kialakítása:

- A szoftver architektúra kialakításánál első feladatunk, hogy eldöntsük milyen
programot kívánunk írni, és hogy mire szeretnénk használni. Ez az úgynevezett üzleti
modellezés.
- Ha ezzel kész vagyunk, következhet a követelmény elemzés. Ennek célja, hogy
pontosan eldöntsük mit várunk a programunktól. Ebben a részben első lépésben
összegyűjtik a követelményeket. Ha ez megtörtént, következhet a begyűjtött
követelmények elemzése (konzisztencia, prioritások .. stb.). Az elemzés utáni lépés a
specifikáció, vagyis a konzisztens és érthető követelmény definiálása, valamint a
rendszer modelljének kidolgozása. A követelményeken belüli utolsó lépés a
követelmények validálása lesz, vagy magyarul követelmények érvényesítése.
- A követelmény elemzése után következik a program tervezése. Elsődleges cél, hogy
tervezési modell (direkt módon megvalósítható rendszerelemek leírása) készüljön.
Tervezés fázisai:
- Divergálás, vagyis alternatívák keresése(struktúrált tervezés, objektum orientált
tervezés);
- Konvergálás, azaz az alternatívák közül kiválasztásra kerül a legmegfelelőbb;
- Kreatív folyamat, vagyis döntés születik.
- Ha kész a tervezés, következhet az implementáció vagy más néven a konkrét
megvalósítás. Ebben a fázisban írja meg a programozó a kívánt programot.
- Ezek után a megírt program belép a tesztelési részbe, ahol alapos vizsgálatnak vetik
alá, hogy a program minden része hibátlanul működjön.
- A tesztelés befejeztével véget ért a program elkészítése, átlép a telepítési fázisba, ahol
már tulajdonképpen csak használni kell a programot.

Építőelemek
- nézetek:use case, logikai, implementációs, párhuzamossági és működési
- építőelemek: elemek, kapcsolatok, diagramok
- nyelvi szabályrendszer: név, kiterjesztés, láthatóság,
- integritás végrehajtás
- nyelvi mechanizmus: specifikációk, megjegyzések,
- osztott elemek, kiterjesztés

Elemek és relációk
A rendszer egyes nézeteinek statikus és dinamikus sajátosságait különböző diagramokkal
fejezhetjük ki, amelyek a rendszer elemei közötti relációkat írják le, több különböző
szemszögből nézve.
Az UML négy relációtípust különböztet meg:
1. függőség (dependency)
Két elem között akkor áll fenn, ha az egyik (a független) elem változása hatással van a
másik (a függő) elemre. Kölcsönös a függőség akkor, ha mindegyik elem hatással van a
másikra.
Grafikus ábrázolásában a szaggatott nyíl a független elem felé mutat.
2. asszociáció (association)
Az objektumok kapcsolatát, ezek struktúráját határozza meg. Speciális esete a rész-egész
viszony, amely kétféle lehet: aggregáció vagy kompozíció. Aggregáció esetén a rész az
egészhez tartozik, de önmagában is létező entitás, míg kompozíció esetén a rész
önmagában nem létezhet, csak az egész elemeként.
A szemléltető nyílon jelöljük az asszociáció irányát, multiplicitását. Rész-egész viszony
esetén az egésznél lévő vonalvég egy csúcsára állított, aggregációnál „lyukas”,
kompozíciónál tömött rombusz.
3. általánosítás és specializáció (generalization/ specification)
Az objektumok speciális viszonya, gyermek-szülő kapcsolat, amelyben a fölérendelt elem
az általános, az alárendelt a specializált.
ábrázolása egy „lyukas” nyíl, amely a szülő felé mutat.
4. megvalósítás (realization)
Annak kifejezése, hogy egy osztály biztosít egy másikat arról, hogy elvégez számára egy
bizonyos feladatot.
Grafikus szimbóluma egy szaggatott, „lyukas” fejű nyíl.

Diagramok

Az UML alapelemei a diagramok, melyek szabvány UML jelölést használnak. Az UML 2.0
verziójában már 13 különböző diagram található. Ezekről ad áttekintést az 1. sz. melléklet.

Strukturális diagramok
Ez a típus a rendszer egészéről, felépítéséről ad felvilágosítást.
- Osztálydiagram (Class Diagram): Megadja a rendszer osztályait, és az azok közötti
társítási és öröklési kapcsolatokat. Az adatbázisdiagram (database diagram) egy speciális
osztálydiagram, amely megadja a rendszer perzisztens adatainak szerkezetét.
- Objektumdiagram (Object Diagram): Megadja a rendszer objektumait, és az azok
közötti kapcsolatokat. Az osztálydiagram egy „pillanatfelvétele”.
- Komponensdiagram (Component Diagram): Megadja a szoftver fizikai felépítést,
vagyis a tervezési elemek szoftver elemekre való leképezését
- Telepítési diagram (Deployment Diagram): Megadja, hogy milyen szoftver elemeket
milyen hardverre telepítünk.
- Összetett szerkezet diagram (Composite Structure Diagram): az osztály belső
szerkezetét mutatja meg.
- Csomag diagram (Package Diagram): a rendszer elemeinek logikai csoportokra való
osztását és azok összefüggéseit ábrázolja

Viselkedés diagramok
A rendszer történéseit, és azok paramétereit modellezi.
 - Használatieset-diagram (Use Case Diagram). Megadja, hogy a felhasználó mire
tudja használni a rendszert. Aktorokat, használati eseteket és azok kapcsolatait ábrázoló
diagram. Funkcionális követelményeket ábrázoló diagram.
- Állapotdiagram (State Diagram): Egy adott osztály vagy alrendszer
állapotváltozásait írja le.
- Aktivitásdiagram (Activity Diagram): Leír egy folyamatot (tevékenységek
egymásutánját). Az üzleti folyamat diagram egy speciális aktivitásdiagram, mely leírja a
rendszert körülvevő folyamatokat, illetve azt a környezetet, amelybe a rendszert el kell
helyezni.

Interakciós diagramok
A rendszerelemek közti kommunikációt modellezik.
- Szekvenciadiagram (Sequence Diagram): Aktorokat, objektumokat és az azok
közötti kapcsolatokat, kölcsönhatásokat (üzeneteket) ábrázoló diagram. A
szekvenciadiagram olyan interakció diagram, mely az idő múlására helyezi a hangsúlyt.
- Együttműködési diagram (Collaboration (UML 1.x)/Communication Diagram
(UML 2.0)): Megadja a rendszer objektumait, az azok közötti kapcsolatokat és üzeneteket.
Az együttműködési diagram a szekvenciadiagram egy más formája – olyan interakció
diagram, mely az objektumok közötti kapcsolatra helyezi a hangsúlyt.
- Interaction Overview Diagram (UML 2.0) A variant of an activity diagram
which overviews the control flow within a system or business process. Each
node/activity within the diagram can represent another interaction diagram.
- UML Timing Diagram (UML 2.0) Depicts the change in state or condition of a
classifier instance or role over time.

Hátrányai
Bár az UML széles körben elterjedt, mégis számos kritikát fogalmaztak meg vele szemben.
Túl sok diagramot használ, melyek részben redundánsak, ezért bonyolulttá, nehezen
áttekinthetővé vált. AZ UML szemantikája nem definiált szigorúan, részben OCL-ben,
részben angolul van, ami szintén megnehezíti az értelmezését. Ez a nyelv még nem kiforrott,
ez abból is látszik, hogy az 1-es és a 2-es verzió közt is vannak eltérések, és mivel még
mindig fejlesztik, valószínűsíthető, hogy továbbra is változni fog. A legnagyobb hátránya
viszont az, hogy amennyi idő alatt lemodellezünk vele egy programot, azalatt kényelmesen
meg is írhatjuk azt.

A nyelv konceptuális modellje

Szabályrendszer
- nézetek:use case, logikai, implementációs, párhuzamossági és működési
- építőelemek: elemek, kapcsolatok, diagramok
- nyelvi szabályrendszer: név, kiterjesztés, láthatóság, integritás végrehajtás
- nyelvi mechanizmus: specifikációk, megjegyzések, osztott elemek, kiterjesztés
Modell-elemek tervezése
Tervezési szempontok
- név
- kiterjesztés
- láthatóság
- integritás
- végrehajtás

Modelltípusok:
- rejtettek
- nem rejtettek
- inkonzisztensek
Mechanizmusok

Az UML nyelvi mechanizmusa

- specifikációs mechanizmus
- megjegyzések
- megosztások
- kiterjesztés
- sztereotípiák
- kiegészítések
- megszorítások

A kiterjesztési mechanizmust a négyrétegű metamodellhez illesztették.

- Az UML-specifikáció magját a szintaktikai és a szemantikai specifikációk képezik,
pontosan definiálva
- a modellnézetek kapcsolatát (UML CORBA facility, XMI DTD),
- a nyelvi kiterjesztéseket (UML Standard Profiles), valamint
- a feltételeket (OCL: Object Constraint Language).