unified modeling language (uml) Áttekintésusers.iit.uni-miskolc.hu/ficsor/swtechseg/uml.pdf ·...

FicsorLajos

Unified Modeling Language UML / 1

UnifiedUnified ModelingModeling LanguageLanguage (UML)(UML)ÁÁttekintttekintééss

Ficsor Lajos

Miskolci Egyetem

Általános Informatikai TanszékUtolsó módosítás: 08. 10. 16.

FicsorLajos


SzSzüükskséégessgesséégegeAz objektum orientált fejlesztési módszerek a rendszer különbözı nézıpontú modelljeit készítik el

A modellek dokumentálására megfelelı technikára van szükség

A technikának szabványosnak kell lennie, mert ez– segíti a fejlesztık közötti kommunikációt (közös

nyelv),

– lehetıvé teszi a technikát támogató eszközök ("tool"-ok) készítését

FicsorLajos


Az UML tAz UML töörtrtéénete 1.nete 1.Az 1990-es évek közepe - vezetı módszertanok:

Booch'93 (Booch): erıs a tervezés fázisában, népszerő az engineering-intenzív alkalmazásoknál.

OMT2 (Rumbaugh) : erıs az analízis fázis során, népszerő az adat-intenzív alkalmazásoknál.

OOSE (Jacobson) : kiváló támogatást ad a "business engineering"-hez, és igazan csak ez támogatja a követelmény analízist.

FicsorLajos


Az UML tAz UML töörtrtéénete 2.nete 2.1991-ben Grady Booch és Jim Rumbaugh(Rational Software Corporation)1995 október: UML 0.81995-ben Ivar Jacobson is csatlakozott1996. október: UML 0.911997. január 17.: UML 1.0 (OMG-nek!)1997. szeptember: UML 1.1 (szabvány!)az utolsó teljes szabványos verzió az UML 1.5(elfogadva 2003. március) Részben elfogadva: UML 2.0 (2006. március.)

FicsorLajos


Az UML tAz UML töörtrtéénete 3.nete 3.

Más módszerek Booch'91 OMT-1 OOSE

Booch'93 OMT2

UML 0.8

UML 0.9További fejlesztõ

partnerek

UML 1.0

1995

1996 jun, okt.

1997. jan. 17.

Sokféleség

Egységesítés

Szabványosítás

Iparszerû alkalmazás

FicsorLajos


Az UML definAz UML definíícicióójajaAz OMG Unified Modeling LanguageSpecification, vers. 1.5 dokumentum 1.1 pontjának (Overview) elsı két mondata:The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems.

FicsorLajos


Az UML fı célkitőzései 1.

Kifejezı vizuális modellezı nyelv biztosítása– fejlesztés támogatása– kommunikáció támogatása

Lehetıség az alap koncepció bıvítésére és specializálására– Alkalmazkodni tudjon a különbözı fejlesztések

szükségleteihez• Szokásos fejlesztés: elegendı legyen hozzá az alap eszköztár• Új elképzelésekkel az alapok módosítása nélkül legyen

kiegészíthetı (kiterjesztési mechanizmus)• Egy adott alkalmazásterület speciális igényei szerint testre

szabható legyen

FicsorLajos



Programozási nyelvtıl és módszertantól független legyen

Biztosítson formális alapot a modellezı nyelv megértéséhez– Precíz definíciók szükségesek az eszköz készítık

számára– Érthetı (nem túl formális) definíciók szükségesek a

felhasználók számára– Megoldás: metamodell osztály diagrammok

segítségével

FicsorLajos



Támogatja az objektum orientált eszközök fejlesztését– Számos felhasználó által ismert és használt,

szabványos eszköz

Az eddigi gyakorlati tapasztalatok ("bestpractices") integrálása

A magas szintő fejlesztési koncepciók támogatása: komponensek, keretrendszerek, minták (patterns) stb.

FicsorLajos


HivatkozHivatkozáások 1.sok 1.A legteljesebb:www.omg.com/uml

Vég Csaba: Alkalmazásfejlesztés a Unified

Modeling Language szabványos jelöléseivel

Logos 2000, Debrecen, 2000

Raffai Mária: Egységesített mogoldások a

fejlesztésben; UML modellezı nyelv, RUP

módszertan

Novodat, 2001.

FicsorLajos


HivatkozHivatkozáások 2.sok 2.Sike Sándor, Varga László: Szoftvertechnológia

és UML

ELTE Eötvös Kiadó, Budapest, 2002.

FicsorLajos


A modell leíró nyelv elemei 1.

A továbbiakban szereplı elemek az 1.5 verziószerinti állapotnak megfelelıek.

use case diagramm

osztály diagramm

viselkedés diagrammok :– állapot diagramm (state diagram)

– aktivitás diagramm (activity diagram)

– sorrend diagramm (sequence diagram)

– együttmőködési diagramm (collaboration diagram)

FicsorLajos


A modell leíró nyelv elemei 2.

implementációs diagrammok:– komponens diagramm (component diagram)

– telepítési diagramm (deployment diagram)

kiterjesztési mechanizmusok– kiegészítı jelölések, amelyek több diagramtípus által

is használhatók

Az UML tehát nem módszertan!

FicsorLajos


KiterjesztKiterjesztéési mechanizmusoksi mechanizmusokAz UML kiegészítı jelölései. Feladatai:– a szabványos jelölésrendszer "testre szabása"– a szabványos elemekkel nem leírható modell

tulajdonságok rögzítése

Fajtái:– sztereotípia (stereotype): új modell elemek jelölésére– megszorítás (constraint): az UML más jelöléseivel

meg nem adható tulajdonságok– kulcsszavas értékek (tagged values): modell elemek

speciális jellemzıinek megadására– megjegyzések

FicsorLajos


MegjegyzMegjegyzééseksek

Megjegyzés szövege

Megjegyzés teljes szövege:megjegyzes.doc

Egy osztály

Elemhez kapcsolt megjegy zés

Formája:

Kapcsolható egy elemhez:

FicsorLajos


SztereotSztereotíípiapiaFormája:

« megnevezés »

A minısített név elıtt vagy fölött kell megadni.

Ikon is rendelhetı hozzá.

Az egyes ábratípusoknál speciális sztereotípiák jelennek meg.

FicsorLajos


MegszorMegszorííttáásoksokFormája:

{ megszorítás leírása }

A leírás lehet szöveges vagy formális.

A formális leírásra egy ajánlat: OCL (ObjectConstraint Language, IBM)

Megadható:

minısített elem után vagy alatt

kapcsolt megjegyzésben

FicsorLajos


Kulcsszavas Kulcsszavas éértrtéékekkekFormálisan ez is megszorítás

Adott névhez értéket rendel

Érték önállóan is szerepelhet

A fejlesztéssel kapcsolatos információkat is így rögzíthetjük

Példák:

{ persistent }

{author="Ficsor", version=0.9.9, date=00.01.01}

FicsorLajos


UseUse casecase diagram 1.diagram 1.Jacobson "hozománya"

Use Case (használati eset):– interakció a felhasználó és az alkalmazás között

– a felhasználó által látható funkciót ír le

– konkrét felhasználói cél elérését rögzíti

A rendszer határait jelölhetjük ki.

Lényeges szerepe van a követelmény analízis során

FicsorLajos


UseUse casecase diagram 2: diagram 2: AktorAktor

Jele:

A felhasználó egy szerepe a rendszerben.

Több felhasználó - egy aktor

Egy felhasználó - több aktor

Aktor lehet külsı rendszer is

Vásárló(f rom Act ors)

FicsorLajos


UseUse casecase diagram 3: diagram 3: UseUse casecaseEgy jól meghatározott funkció, amelynek végrehajtása a rendszer és egy külsı entitás közötti üzenetváltást kíván.Jele:

A rendszer, egy alrendszer vagy egy osztály objektumai által végrehajtott funkció-együttes.Pontos leírása is szükséges (szöveges vagy egyéb diagram)

Áruvásárlás

FicsorLajos


UseUse casecase diagram 4: Pdiagram 4: PééldaldaFizetés a kasszánál:

A vevı a kasszához megy a kiválasztott árukkal, a pénztáros leolvassa a vonalkódokat, a rendszer elkészíti a blokkot, a vevı fizet, a pénztáros elveszi az összeget.

Aktorok: vevı, pénztáros

A rendszer válaszai: egységár a vonalkódokra

Use-case-ek: vásárlás, blokkolás, fizetés

FicsorLajos


UseUse casecase diagram 5: Pdiagram 5: Péélda (lda (áábra)bra)

Vásárló(f rom Actors)

Blokkolás

Áruvásárlás

Pénztáros

Fizetés

FicsorLajos


UseUse casecase diagram 6: kapcsolatokdiagram 6: kapcsolatokAktor és use case között: asszociáció (jelölhetı a

számossága is)Use case-ek között:

<<include>>: A1 use case magában foglalja A2-ıt (részletezés, vagy ismétlıdés kezelése)<<extend>>: A1 use case mőködését A2kiegészíti (többlet funkciók vagy speciális esetek)

Aktorok vagy use case-ek között: általánosítás(generalization)

FicsorLajos


UseUse casecase diagram 7: kapcsolatok (diagram 7: kapcsolatok (áábra)bra)

Pénztáros(f rom U se Cas e View)

Boltvezeto

Hitel adás

Göngyöleg kezelés

Áruvásárlás(f rom Use Case View)

<<include>>

Árulista megnézése

<<exte nd>>

Általánosítás

Blokkolás

FicsorLajos


OsztOsztáálydiagramlydiagramOsztályok és összefüggéseik ábrázolásáraA rendszer statikus strukturális modelljeHárom szint:

koncepcionálisspecifikációsimplementációs - általában túl sok részlet, de– dokumentáció– kódgenerálás

Rajzolható objektum diagram is, az osztályok példányainak felhasználásával

FicsorLajos


OsztOsztáálydiagram: osztlydiagram: osztáály szimbly szimbóólumaluma

Windowk

Windowsvisibili ty : Bool eansize : A rea

display()hide()

Windowi

size : Area = (100,100)visibil ity : Boolean = invisiblexptr : XWindow*

display()hide()attachXwindow()create()

<<abstract>>

Koncepcionális

Specifikációs

Im plementációs

Név

Attribútumok

Operációk

FicsorLajos


OsztOsztáálydiagram: objektum szimblydiagram: objektum szimbóólumalumaEgy konkrét objektum

Objektum neve : Osztály neve KissPista : HallgatóPl.:

Egy osztály tetszıleges objektuma

: Osztály neve

Megadhatók konkrét attribútum értékek is

Megjegyzés: az aláhúzás része a jelölésnek!

KissPista : Hallgató

Név = Kiss PistaNeptunKód = ZZZZZZ

FicsorLajos


OsztOsztáálydiagram: attriblydiagram: attribúútumoktumokFormája:

láthatóság név : típus = alapérték

A láthatóság jelölése:

szabványos:

+ public

# protected

- private

Windowprivate attr.protected attr.public attr.

Rational Rose szerint

FicsorLajos


OsztOsztáálydiagram: attriblydiagram: attribúútumoktumokkoncepcionális szint:

az osztálynak van ilyen adata (pl. a vásárlónak van neve)

specifikációs szint:

az osztálynak van adott típusú adata, amelyen meghatározott operációk hajthatók végre (pl. a vásárló neve beállítható, lekérdezhetı)

implementációs szint:

az osztály adott típusú mezıje és az azokat kezelımódszerei

FicsorLajos


OsztOsztáálydiagram: operlydiagram: operáácicióókk

Formája:láthatóság név(param) : típus{comment}

típus a visszatérési érték típusaparam a paraméterlista (vesszıvel elv.)– azonosító : típus = alapérték

Közöttük lehetnek az alábbi sztereotípusok:– <<constructor>>– <<query>>– <<update>>– <<getting method>> vagy <<setting method>>

FicsorLajos


OsztOsztáálydiagram: operlydiagram: operáácicióókkkoncepcionális szint:

a viselkedés lényegi elemei


az osztály publikus módszerei


az osztály módszerei

FicsorLajos


OsztOsztáálydiagram: lydiagram: kapcsolatokkapcsolatokKapcsolat az egyes osztályok között

Asszociáció (általános kapcsolat)Nevesített kapcsolatok:– általánosítás– tartalmazás (aggregáció és kompozíció)– beágyazott (osztály hatáskörben definiált) osztály -

elsısorban az implementációs szintő diagrammokon

FicsorLajos


OsztOsztáálydiagram: asszocilydiagram: asszociáácicióóJele vonal, tulajdonságai:

kapcsolat neve,szerepkör (mindkét irányban),irányítása (egy-vagy kétirányú vagy nincs),a szerepkörök számossága– n..m vagy n-m vagy n,m, ...,k– n,m stb lehet 0 vagy * (végtelen)– * magában a 0..* -ot jelenti.

A szerep kötött sorrendje is elıírható.Az asszociáció minısítıje is elıírható.Az asszociációhoz a tulajdonságait leíró osztály is rendelhetı.

FicsorLajos


OsztOsztáálydiagram: asszocilydiagram: asszociáácicióókoncepcionális szint:

viszony a fogalmak között


felelısségek


az elérhetıség megvalósítása (pl. pointer, kulcs)

FicsorLajos


OsztOsztáálydiagram: asszocilydiagram: asszociáácicióóPélda:

Cég Személy1..*0..1

+alkalmazott1..*

+alkalmazóAlkalmazás0..1

Szerep nevek

Kapcsolat neve

Számosság Számosság

FicsorLajos


OsztOsztáálydiagram: asszocilydiagram: asszociáácicióó (szerep)(szerep)A szerep lehet sorrendiségi, azaz jelölhetjük, hogy az objektumok kötött sorrendben vesznek részt az asszociációban

Jelölése az {ordered} megszorítással

Példa:

sokszög pont3..*

{ordered}

+alkotjaSzerepnévmultiplicitás

Kötött sorrendben!

FicsorLajos


OsztOsztáálydiagram: asszocilydiagram: asszociáácicióó (szerep)(szerep)Két osztály közötti asszociációhoz tartozhat több szerep is

Ilyenkor minden szerephez egy vonal

Példa:

Tárgy Hallgató

+regisztrált

+gyakvezér

felvesz

demonstrátor

FicsorLajos


OsztOsztáálydiagram: asszocilydiagram: asszociáácicióó (min(minııssííttıı))A minısítı konkrét értékei az asszociáció többes oldalán az objektumok egy példányát vagy egy részhalmazát jelölik ki.

Jele:

Osztály1 minısítı Osztály2

FicsorLajos


OsztOsztáálydiagram: asszocilydiagram: asszociáácicióó (min(minııssííttıı))Példa:

Tárgy tárgykód Hallgatófelvesz

Ennek megfelelı objektum diagram:

SoftwareTechnológia : TárgyGEIAL2144N KissPista: Hallgató

felvesz

FicsorLajos


OsztOsztáálydiagram: asszocilydiagram: asszociáácicióó (tulajdons(tulajdonsáág)g)Olyan tulajdonságokat, amelyek inkább az asszociációhoz, mint valamelyik osztályhoz rendelhetık, összefoglalhatunk egy harmadik osztályba, amelyet a kapcsolathoz rendelünk.

Jelölés:

Osztály1 Osztály2

Tulajdonság

FicsorLajos


OsztOsztáálydiagram: asszocilydiagram: asszociáácicióó (tulajdons(tulajdonsáág)g)Példa:

Cég Személy

Alkalmazás

KezdeteFizetés

beosztás

FicsorLajos


OsztOsztáálydiagram: asszocilydiagram: asszociáácicióó (t(tööbbes)bbes)Több osztály között fennálló asszociáció jelölése:

Osztály1

Osztály3

Osztály2 Osztály1

Osztály3

Osztály2

Osztály4

FicsorLajos


OsztOsztáálydiagram: lydiagram: ÁÁltalltaláánosnosííttáássSpeciális (közvetett) viszony két osztály között

koncepcionális szint:

típus - altípus viszony


az alosztály interface-e rendelkezik az ısosztály interfac-ének minden elemével


öröklıdés (származtatás)

FicsorLajos


OsztOsztáálydiagram: lydiagram: ÁÁltalltaláánosnosííttááss

Alakzat

Kör Téglalap Hatszög

FicsorLajos


OsztOsztáálydiagram: lydiagram: aggregaggregáácicióó éés kompozs kompozíícicióó

Kétféle egész - rész viszony:

aggregáció: a rész az egészhez tartozik, de önállóan is létezı entitás

kompozíció: a rész önmagában nem létezhet, csak valaminek a részeként.

FicsorLajos


OsztOsztáálydiagram: lydiagram: aggregaggregáácicióó éés kompozs kompozíícicióó((áábra)bra)

Motor Kerék

Autó

1 4..51 4..5

Konyha Szoba

Ház

0..1 1..*0..1 1..*

Aggregáció Kompozíció

FicsorLajos


OsztOsztáálydiagram: lydiagram: parametrizparametrizááltlt osztosztáályly

Címlista

Elemek:Tombelemelemszám:Integer

DinTomb

<<bind (Cím, 100)>>

Parametrizált osztály

Paraméterek

Konkretizált osztály

Konkretizálás paraméterei

FicsorLajos


OsztOsztáálydiagram: lydiagram: interfaceinterfaceAz <<interface>> sztereotípiával, vagy egy körrel jelöljük

Csak a metódusoknak van hely

Interface-ek közötti lehetséges asszociáció: általánosítás

Interface és osztály közötti lehetséges asszociáció: implementálás, realizálás. Jele a példán.

FicsorLajos


Szekvencia diagram 1.Szekvencia diagram 1.Objektumok közötti üzenetváltások az idıben

Elemei:

példaobjektumok, életvonallal, aktivitási szakasszal (vezérlési fókusszal)

üzenetek (név, argumentum, feltétel, ismétlıdés)

megjegyzések az ábrától balra

FicsorLajos


Szekvencia diagram 2: pSzekvencia diagram 2: pééldalda

Forrás: UML specification

FicsorLajos


Szekvencia diagram Szekvencia diagram 33: : üüzenetzenet fajtfajtáákk

Objektum1 Objektum2

Egyszerû üzenet

Szinkron üzenet

Aszinkron üzenet

Uzenet time-outttal

FicsorLajos


Szekvencia diagram 4: pSzekvencia diagram 4: pééldalda

Alternatívmőködés

Élettartam vége

Beágyazott vezérlés fókusz

Élettartam kezdete


FicsorLajos


ÁÁllapot diagram 1.llapot diagram 1.Egy adott objektum

lehetséges állapotaiátmenetek az egyes állapotok között (állapotváltozások)– ehhez kapcsolható események– az objektum értékeihez kapcsolható feltételek [feltétel]

formában– az ismétlıdés jelzése (*)

kezdı és végállapotegy állapot részletezhetı (strukturált áll. diagram)állapotok között lehet általánosítás kapcsolat

FicsorLajos


ÁÁllapot diagram 2.llapot diagram 2.

Állapot

entry/ Belépési tevékenységexit/ Kilépési tevékenység

do/ Normál tevékenységon esemény/ ^Eseményhez kapcsolódó tev.

Állapot jelölése

FicsorLajos


ÁÁllapot diagram 3. (pllapot diagram 3. (péélda)lda)


FicsorLajos


EgyEgyüüttmttmőőkkööddéési diagram 1.si diagram 1.Szintén objektumok közötti üzenetváltások az idıben

Elemei:

példaobjektumok– aktív: vastag keret vagy {active} megszorítás – üzenetet

küldhet másik objektumnak– passzív – üzenet hatására aktivizálódik– multiobjektum: objektumok egy csoportja

Az együttmőködı objektumok vonallal összekötve– Ellenırzendı: a megfelelı osztályok között az

osztálydiagramon asszociációnak kell lennie!

FicsorLajos


EgyEgyüüttmttmőőkkööddéési diagram 2.si diagram 2.üzenetek– objektumok közötti nyilak, sorszámozva és névvel

ellátva– a nyíl iránya jelzi az üzenetküldés irányát– A sorszám sorrendiséget jelez

Üzenetnek lehet argumentuma és eredménye– Jele kis körbıl kiinduló nyíl, az adatáramlás irányát

mutatja– A nyílon az argumentum vagy eredmény megnevezése

Az ábrán szerepelhet aktor is, ekkor tıle indul az elsı üzenet.

FicsorLajos


EgyEgyüüttmttmőőkkööddéési diagram 3. psi diagram 3. pééldalda

Vásárló(f rom Actors)

Ügyfél

: ATM

: központi gép: banki gép

tranzakció

összeg

készpénz

tranzakció

összeg

engedély

tranzakció

összeg

rendben

Készpénzfelvétel ATM-bıl

FicsorLajos


EgyEgyüüttmttmőőkkööddéési diagram 4. psi diagram 4. pééldalda

: hallgató: oktató

Zh eredmény hirdetés

eredménylap

Multi objektummal

FicsorLajos


AktivitAktivitáás diagrams diagramIdıben lezajló változások ábrázolása a végrehajtandó tevékenységek és azok sorrendjének megadásával Alapjai:– munkafolyamat (work-flow) diagram– folyamatábra (flow chart)

Alapelemei:– tevékenységek (ívelt oldalú téglalap)– átmenet (nyíl)– szinkronizációs vonal (vastag vízszintes vonaldarab)– döntési pont (rombusz)

FicsorLajos


AktivitAktivitáás diagram s diagram -- ppééldalda ((nemnem teljesteljes!)!)Tágy

meghirdetése

Határidõig várakozás

Tárgy lem ondás a

Tárgy véglegesítése

Kiírások megnézése

Tárgyra jelentkezés

Jeletkezés elfogadása

Módosítás felajánlása

Tárgy megtartása

Tárgy lezárása

FicsorLajos


SSáávvoos s aktivitaktivitááss diagramdiagramA diagramm függılegesen sávokra osztható

Egy sáv egy felelısségi kört (felhasználó, szervezeti egység stb.) jelöl

A tevékenységek a sávokhoz rendelhetık, ezzel az adott tevékenységhez tartozó felelıs is ábrázolható

FicsorLajos


SSáávvoos s aktivitaktivitááss

diagram diagram --ppééldalda

FicsorLajos


Komponens diagramKomponens diagramKomponensek: fizikai alkotóelemek. Tipikusan:– forrás-állományok

– könyvtárak

– futtatható állományok

– dokumentumok

– adatfile-ok

– software komponensek

Definiált sztereotípiák:– «executable»

– «library»

– «tables»

– «file»

– «document»

FicsorLajos


Komponens diagram Komponens diagram -- ppééldalda

Tárgyra jelentkezés

Tárgy kezelés s zerver

Adatbázis szerver

Online szerver

Web Browser

FicsorLajos


TelepTelepííttéési diagramsi diagramTartalma:

A rendszer hardware elemei (csomópontok) és a közöttük levı fizikai viszonyok

A hardware és software elemek összerendelése

FicsorLajos


TelepTelepííttéési diagram si diagram -- ppééldaldaTanszéki szerver

Admin. szerver

Hallgatói PC

TCP-IP

TCP-IP (védett)

Tárgy kezelés szerver

Adatbázis szerver

Online szerver

Web Browser

FicsorLajos


ModellModellezezééss ttáámogatmogatáásasaAz UML támogatja teljes modellek felépítését

Eszközei:

Csomag (package)

Alrendszer (subsystem)

Modell

FicsorLajos


CsomagCsomagTetszıleges modell elemek csomagba rendezhetık

A csomagok egymásba ágyazhatók

Egy csomag beágyazott csomagot és egyéb modell elemeket egyszerre is tartalmazhat.

A csomagok közötti kapcsolatokat szaggatott nyilak jelzik, a kapcsolat jellegét sztereotípiával adhatjuk meg. Két elıre definiált sztereotípia:– <<import>>

– <<access>>

FicsorLajos


CsomagCsomag: p: péélldada


FicsorLajos


AlrendszerAlrendszerOlyan csomag, amely egy viselkedési egység.

Az alrendszer interface-eket biztosít a többi alrendszernek

Tartalmaz(hat)– Operációkat

– Specifikációs elemeket

– Realizációs elemeket

FicsorLajos


Alrendszer: jelAlrendszer: jelöölléés s éés kapcsolatoks kapcsolatok

Jelölés:

Operációk leírása

Interface-ek

Kapcsolatok:


FicsorLajos


ModellModellA rendszer egy nézete (view)

Jelölés:


unified modeling language (uml) Áttekintésusers.iit.uni-miskolc.hu/ficsor/swtechseg/uml.pdf ·...

Documents