uml-alapú fejlesztés

UML-alapú fejlesztés

Software Engineering – szoftverfejlesztési folyamat

• Software Engineering értelmezése– Az a folyamat, mely eredményekénk

létrehozunk egy adott feladatot megvalósító szoftver rendszert.

– Tevékenységek, technológia, módszerek, eszközök…

– Számítógép alapú rendszert hozunk létre.

Szoftverfejlesztési folyamat• Rendszerfejlesztési folyamat

(„rendszer”…)– System Engineering– Általános értelemben vett rendszer fejlesztés.

• Szoftverfejlesztési folyamat (szoftver…)– Software Engineering– Szoftver alkalmazásokat, eszközöket ad a SE

által definiált feladatok megoldására.– A szoftver rendszer (alkalmazás)

létrehozására koncentrál.

Rendszerfejlesztés

• Rendszerfejlesztés alapkérdései– Általános értelemben vett rendszer

fejlesztés– Rendszerfejlesztés lehet:

• Business Process Engineeringha vállalat (működésének) (át)szervezésével foglalkozunk

• Product Engineeringha egy termék előállítása a célpl.: mobil telefon, repülőgép vezérlő rsz.

• Szoftverfejlesztési folyamat

Szoftverfejlesztési folyamat• Szoftverfejlesztés értelmezése

– Az a folyamat, amelynek eredményekénk létrehozunk egy adott feladatot megvalósító szoftverrendszert, számítógép alapú rendszert hozunk létre.

• Szoftverfejlesztés lépései– Fázisok

• Szoftverfejlesztési modellek, módszertanok:– struktúrált (vízesés modell, Boehm-féle

spirálmodell, V modell stb.)– objektumorientált (OMT, OOA/OOD, Bocch2, RUP)

Vízesés modell

A fejlesztés életciklusa• System engineering – Rendszerfejlesztés

– Business process eng. – Üzleti modellezés• üzleti folyamatok tervezése, szervezése• az üzleti környezet modellezése

– Product eng. – Termék modellezés• termékek tervezés• termék modellezése, annak használata

• Requirements – Követelménykezelés• Analysis – Elemzés• Design – Tervezés• Implementation – Implementáció• Testing – Tesztelés, Telepítés• Karbantartás, Rendszerkövetés, Továbbfejl.

Software eng.

Rend

szer

fejle

szté

s –

Syst

em E

ng.

Módszertan

Módszertan

Modellező nyelv

Eljárások

Eljárások

• Tanácsok: milyen lépések szükségesek a rendszer elkészítése során és azokat milyen sorrendben kell végrehajtani.

• Az egyes lépéseket milyen szerepkört betöltő embereknek kell elvégezni.

• Milyen termékek születnek az egyes lépések során és hol kerülnek felhasználásra.

Szerepkörök és tevékenységek

• A szerepkör (worker) egyfajta viselkedést ír le. A szerepkört betöltő személy vagy személyek felelősek meghatározott termékek (artifact) előállításáért.

• Minden munkatárs meghatározott tevékenység-sort végez a termékek előállítása érdekében.

• Minden valóságos személy többféle munkatársi szerepkört is betölthet a projekt folyamán, többféle felelősségelehet.

Szerepkörök és tevékenységek a RUP-ban

Munkafolyamat részletek

Megadja, hogy az adott feladat során

milyen lépéseket kell végrehajtani,

ki a felelős az adott feladat végrehajtásáért

és milyen termékeket kell a lépések során előállítani.

Termékek (Artifact)• A projekt során előállított, használt dolgok. Például:

– Dokumentum– Modell (pl.: használati eset modell)– Modell-elem (pl.: használati eset)– Riportok: modellekből, modell-elemekből előállított

dokumentumok.• A termékek tevékenységek során állnak elő, és

útmutatók (guideline), sablonok (template) segítik a készítésüket:– Pl.: hogyan találjuk meg és dokumentáljuk a használati

eseteket?– Nem termékhez kapcsolódó útmutatók: például hogyan

szervezzünk workshopot.

Modellező nyelv• Jelölésrendszer (általában grafikus), amellyel

leírjuk a rendszert, rendszertervet a fejlesztés során.

• A kommunikáció alapja: – megrendelő és fejlesztő csoport között,– fejlesztő csoport tagjai között.

• Fontos, hogy a modellező nyelv alkalmas legyen mind a valóság, mind rendszer belső szerkezetének ábrázolására:– üzleti modelltől, telepítési modellig.

Rational Unified Process• Szoftverfejlesztési módszertan, közvetlen elődje az

Objectory (Jacobson).• Booch, Rumbaugh és Jacobson munkájának

eredménye.• Világszerte elterjedt fejlesztési módszertan.• Nagyon sok előző módszertanból merít és mindazt

egyesíti („nem spanyol viasz”).• NAGY fejlesztési módszertan testre kell szabni.• A módszertan, ill. a hozzá fejlesztett eszközök a

teljes fejlesztési ciklust támogatják:– üzleti modellezés, követelmények elemzése, elemzés,

tervezés, tesztelés, stb.

A RUP szerkezeteta

rtalo

m (m

it ke

ll vé

greh

ajta

ni?)

idő (mikor, milyen sorrendben?)

RUP módszertan• A Rational Unified Process egy UML-t, mint modellező

nyelvet használó szoftver fejlesztési módszertan:– UML modellező nyelv jelölésrendszerét használja.– Eljárásaiban megadja, hogy milyen lépéseket kell végrehajtani,

milyen sorrendben.– A feladatok elvégzéséért ki a felelős.– Milyen termékeket kell előállítani a feladat végrehajtása során.

– Eszközökkel támogatja a fejlesztés egyes szakaszait.– Tool-mentorok segítik az eszközök használatát.– Sablonokat, útmutatókat ad az egyes feladatokhoz.

+

Az UML modellező nyelv

• Unified Modelling Language - Egységes Modellező Nyelv

• Objektumorientált elemzés, tervezés és üzleti modellezés eszköze:– Az üzleti modellezés esetén a valóság folyamatait írja le.– Analízis (elemzés) során a megoldandó feladat leírása.– Tervezés során a megoldást (implementálandó

rendszert) írja le.• Szabványos (Object Management Group - OMG)

– 1997. november óta• Alapvetően grafikus nyelv.• Modellező nyelv, nem módszertan.

UML diagramok

1. Use Case (használati eset) diagram2. Tevékenységi/Aktivitási (Activity) diagram3. Eseménykövetési/Szekvencia (Sequence)

diagram4. Együttműködési/Kollaborációs (Collaboration)

diagram5. Osztály (Class) diagram6. Objektum (Object) diagram7. Állapot-átmeneti (Statechart) diagram8. Komponens (Component) diagram9. Telepítési (Deployment) diagram

A RUP szerkezeteta

rtalo

m (m

it ke

ll vé

greh

ajta

ni?)


Munkafolyamatok

A RUP munkafolyamatai

• Üzleti modellezés• Követelmény-elemzés• Elemzés-tervezés• Implementáció• Tesztelés• Telepítés• Konfiguráció és változás-kezelés• Projektvezetés• Környezet kialakítása

Mérnöki munkafolyamatok

Támogató munkafo-lyamatok


A fejlesztési munka konkrét feladatai:• Üzleti modellezés (Business Modeling)

– Cél megérteni annak a szervezetnek a felépítését, folyamatait, amely támogatására az alkalmazást fejlesztjük.

• Követelmény-elemzés (Requirements)– Cél meghatározni azokat a feladatokat, amelyeket a

rendszernek meg kell oldani (scope) és a megrendelőkkel együttműködve egy egységes képet kell kialakítani a fejlesztendő rendszerről.

• Elemzés-tervezés (Analysis & design)– Cél a követelményelemzés során meghatározott elvárásoknak

megfelelő, robosztus rendszer tervezése.


• Implementáció (Implementation)– Cél a terv alapján a rendszert alkotó komponensek

implementálása, egységtesztjeinek elvégzése és integrálása.

• Tesztelés (Test)– Cél annak ellenőrzése, hogy az implementált

rendszer megfelel-e az elvárásoknak, és hogy valamennyi követelmény implementálva lett-e.

• Telepítés (Deployment)– Cél a kész alkalmazást elérhetővé tenni a felhasználó

számára.

Támogató munkafolyamatokAzok a feladatok, amelyek a fejlesztés során

folyamatosan segítik a fejlesztők munkáját: • Konfiguráció és változás-kezelés

– Cél a fejlesztés során előálló termékek verzióinak kezelése.• Projektvezetés

– Cél irányelvek megadása és a projekt ellenőrzésével és irányításával kapcsolatos feladatok elvégzése.

• Környezet kialakítása– Cél a szoftverfejlesztési környezet (módszertan, eszközök)

kialakításával kapcsolatos feladatok ellátása.

RUP szerkezete

Munkafolyamatok

A munkafolyamatot egy „folyamatábra (activity)

segítségével mutatja be.

Ez segít a feladat típusa, és a fejlesztés aktuális fázisa szerint

meghatározni a további feladatokat.

RUP szerkezete

Munkafolyamat részletek

Megadja, hogy az adott feladat során

milyen lépéseket kell végrehajtani,

ki a felelős az adott feladat végrehajtásáért

és milyen termékeket kell a lépések során előállítani.

Szerepkörök és tevékenységek

• A szerepkör (worker) egyfajta viselkedést ír le. A szerepkört betöltő személy vagy személyek felelősek meghatározott termékek (artifact) előállításáért.

• Minden munkatárs meghatározott tevékenység-sort végez a termékek előállítása érdekében.

• Minden valóságos személy többféle munkatársi szerepkört is betölthet a projekt folyamán, többféle felelősségelehet.

Termékek (Artifact)• A projekt során előállított, használt dolgok. Például:

– Dokumentum– Modell (pl.: használati eset modell)– Modell-elem (pl.: használati eset)– Riportok: modellekből, modell-elemekből előállított

dokumentumok.• A termékek tevékenységek során állnak elő, és

útmutatók (guideline), sablonok (template) segítik a készítésüket:– Pl.: hogyan találjuk meg és dokumentáljuk a használati

eseteket?– Nem termékhez kapcsolódó útmutatók: például hogyan

szervezzünk workshopot.

Fázisok és iterációk

Fázisok

• A Rational Unified Process a szoftverfejlesztés életciklusát négy egymást követő fázisra bontja: – Előkészítés (Inception, Kiindulás, Elindulás).– Kidolgozás (Elaboration).– Megvalósítás (Construction).– Átadás (Transition).

Előkészítés fázis

• A rendszer határainak meghúzása• Az üzleti lehetőségek tervezése és előkészítése• Egy lehetséges architektúra meghatározása• A projekt során alkalmazott fejlesztési környezet

előkészítése

• Mérföldkő: A követelmények rögzítése

Kidolgozás fázis• Az architektúra meghatározása és alkalmazhatóságának

igazolása• A Projekt Vízió finomítása• A megvalósítás fázis részletes iterációs tervének

elkészítése• A fejlesztési folyamatok finomítása és a fejlesztési

környezet kialakítása a megvalósítási feladatok támogatására

• Az architektúra finomítása és újrafelhasználható komponensek kiválasztása

• Mérföldkő: Szoftver architektúra rögzítése

Megvalósítás fázis

• Erőforrás kezelés, ellenőrzés és optimalizálás• Teljes komponens fejlesztés és tesztelés az

elfogadási kritériumok alapján• A termék verziójának értékelése az átvételi

kritériumok alapján

• Mérföldkő: Kibocsátás béta tesztelésre

Átadás fázis• A telepítési terv végrehajtása• A végfelhasználókat támogató anyagok elkészítése• Az átadott szoftver tesztelése a felhasználó telephelyén• A termék verziójának elkészítése• A felhasználók visszajelzéseinek összegyűjtése• A visszajelzések alapján a rendszer végső beállításainak

elvégzése• A rendszert elérhetővé tenni a felhasználók számára

• Mérföldkő: Termék kibocsátása

A RUP szerkezete• Egy-egy fázis elkészítése minden

munkafolyamatot érint, amelyek a különböző fázisokban különböző intenzitásúak, és erőforrás-igényűek.

• Más megközelítésben:– A fázisok iterációkra bonthatók.– Minden egyes iteráció egy mini fejlesztés: kezdődik

üzleti modellezéssel, követelményelemzés, elemzés, tervezés, implementáció, tesztelés, befejeződik telepítéssel.

Fázisok

• Minden fázis végén jól-definiált mérföldkövek vannak: kritikus döntéseket kell hozni:– Értékelni az eddigi eredményeket,– Dönteni a folytatásról.

Iterációk• A RUP szerint a fejlesztés egyes fázisai tovább bonthatóak

iterációkra. • Az iteráció egy olyan fejlesztési ciklus, amely során minden

alapvető munkafolyamatot egyszer elvégzünk.

Vízesés

Iteratív -

“sok kis vízesés”

Iterációk

Az iterációk során egyre több termék

áll elő, és a termékek

érettsége egyre nő.

Fázisok és iterációk

Az aktuális feladat dönti el, hogy hány iterációra van szükség a feladat elvégzéséhez.

Az iterációk tervezése kritikus feladat a projekt tervezése során.

V. A fejlesztés menete a RUP ajánlásával

A RUP szerkezeteta

rtalo

m (m

it ke

ll vé

greh

ajta

ni?)


V.1. Üzleti modellezés – Business Modeling

Üzleti modellezés

Megérteni annak a szervezetnek a felépítését, viselkedését, amely

számára a rendszert ki akarjuk fejleszteni

Feltárni a szervezet aktuális problémáit és meghatározni a

javítás lehetőségeitBiztosítani, hogy az ügyfelek, végfelhasználók és fejlesztők egységes képet kapjanak az

adott szervezetrőlA szervezetet támogató

rendszerrel szemben felmerülő követelmények felderítése

Üzleti modellezés

• Azt a környezetet írja le, amelyikben a rendszer működik, vagy amelyikben a rendszer működni fog.

• A rendszernek az üzleti környezetben, a szakterületi környezeten belüli helyét határozza meg.

• Más néven szakterületi (domén) modellezés.• Értelmezhető mind a jelenlegi, mind a tervezett

rendszer üzleti környezetére.

Üzleti modellezés

Üzleti modellezés

• Az üzleti folyamatok állapotának felderítése (Assess Business Status)– A fejlesztett rendszer által támogatott

szervezet (cél szervezet) állapotának felderítése.

Üzleti modellezés

• Az aktuális üzleti folyamatok leírása (Describe Current Business)– Feltárni a cél szervezet folyamatait és

szerkezetét.– Nem cél a szervezet részletes leírása. – Addig a szintig kell az elemzéseket elvégezni,

amíg képesek leszünk kategorizálni a szervezet folyamatait és kiválasztani azokat a részeit, amelyekre a projekt hátralevő részét alapozni fogjuk.

– Üzleti szereplők, használati esetek, entitások és workerek azonosítása.

Üzleti modellezés

• Az üzleti folyamatok azonosítása (Identify Business Processes)

Üzleti modellezés - tevékenységek

Üzleti modellezés - termékek

Üzleti folyamatok leírása UML segítségével

• Csomag elem, csomag diagramok:– Összetett tevékenységek, folyamatok

strukturálása.– Logikai rendszerezés.– Átlátható struktúra kialakítása.

• Business use case, business use case diagram:– Üzleti folyamatok leírása.

Üzleti folyamatok leírása UML segítségével

• Business aktorok:– A megbízó szervezettel a működése során

kapcsolatba kerülő személyek.• Business workerek:

– A megbízó szervezet alkalmazottjai.• Aktivitási diagram:

– Az üzleti folyamatok működésének részletezése, lépéseinek leírása.

A szakterület folyamatai (üzleti folyamat diagram)

od A diplomamunka kezelésének folyamata

Diplomaterv beérkezése a Tanszékre

Diplomaterv

- szerző adatai: - konzulens adatai: - téma bemutatása: - elfogadás kelte:

Diplomamunka beérkezése a Tanszékre

Diplomamunka beérkeztetése, elbírálása

Diplomamunka

- diplomaterv: - konzulensi lap: - kidolgozott téma:

Bírálat

- bíráló véleménye: - osztályzat:

Diplomaterv ek nyilv ántartásaA két esemény között

meghatározatlan hosszúságú idő telik el

Elbírált terv visszaküldése

Elbírált diplomamunka

visszaküldése D.O-ra

Bírálat dokumentum

Diploma-terv dokumentum

Részletesző diagram

Részletező diagram

engedélyezésvagyelutasítás

bíráló és bírálatbejegyzése

Diplomatervfelvétele[elfogadás esetén]

(Diplomáztatás esettanulmány) od A diplomamunka kezelésének folyamata


Diplomaterv elbírálása

Diplomaterv

- szerző adatai: - konzulens adatai : - téma bemutatása: - elfogadás kelte:

Diplomamunka beérkezése a T anszékre


Diplomamunka


Bírálat


Diplomaterv ek nyilv ántartása

A két esemény között meghatározatlan hosszúságú idő tel ik el







Részletező d iagram




Szakterületi modell(Diplomáztatás esettanulmány)

cd Szakterületi osztálydiagram

Tanszéki felelős

DiplomaTerv

- szerző neve: - fejlesztőeszköz: - konzulens: - tanszék: - cím: - témavázlat:

Diplomamunka

- diplomaterv: - konzulensi vélemyény: - kidolgozás:

Bírálat

- bíráló neve: - osztályzat: - szöveg:

Fej lesztőeszköz

- megnevezés:

Tanszék

- megnevezés:

Szerző

- név:

Konzulens

- név:

Bíráló

- név:

+elkészíti

+elbírálja

+közreműködik

+közreműködik

+bírálatra kiadja

+jóváhagyja

+képviseli

+elkészíti+használja

+kijelöli

+elkészíti

+kijelöli

Követelmény (elemzés)

Követelményanalízis/kezelés

– a szoftverfejlesztési folyamat első lépcsőfoka– már konkrét specifikáció, amely alapját képezi

valamennyi szoftverfejlesztési tevékenységeknek, a teljes szoftverfejlesztési folyamatnak

– végrehajtásához a következő tevékenységek javasoltak:

• problémafeltárás• problémaértékelés és megoldás keresés/alternatív

megoldások felállítása• modellezés• specifikáció• áttekintés, felülvizsgálat, ismertetés

Követelményanalízis/kezelés

– a probléma információs, funkcionális és a viselkedési doménére!!! koncentrál – követelmények összegyűjtése

– követelmények elemzése – konzisztencia, prioritások, köv. típusok

– követelmények specifikálása– követelmények validálása– produktuma: szoftver követelményspecifikáció

dokumentum

Követelményelemzés

A megrendelővel (felhasználóval) egyetértésre

jutni, hogy pontosan mit kell a szoftverrendszernek tudnia.

A fejlesztőknek pontos képet adni a rendszerről.

Meghúzni a rendszer határait.Biztosítani az iterációk

tervezéséhez szükséges technikai információkat.

A rendszerhez a felhasználói igényeknek megfelelő felhasználói interfész

meghatározása.


• A tervezett szoftverrendszernek kívülről, a felhasználó szempontjából történő leírását adja meg.

Követelmény

• Követelmény: olyan feltétel, képesség, szolgáltatás, melynek teljesítését (vagy az annak való megfelelést) elvárjuk a tervezett alkalmazástól.

Követelménymenedzsment

• A követelmény menedzsment:– folyamatos tevékenység, amely

végigkíséri a fejlesztés teljes folyamatát. – Célja a követelmények feltárása,

rendszerezése, dokumentálása.– További fontos feladata a

követelmények változásának nyomon követése és ezek érvényesítése a fejlesztési folyamatra.

Követelmények változásainak nyomon követése

• A fejlesztés során a megrendelőnek, a felhasználónak újabb elképzelései, igényei merülhetnek fel.

• A korábban specifikált követelmények tehát a fejlesztés folyamán változhatnak, módosulhatnak.

• A rendszert fel kell készíteni a követelmények változásának követésére. – A változáskövetés során első lépésben elemezni kell a

fejlesztés folyamán jelentkező új igényeket, majd – meg kell vizsgálni az új igények milyen hatással lesznek a

már felállított követelményrendszerre. – A vizsgálat eredményének kiértékelése után lehet csak

dönteni a változások megvalósíthatóságáról.

Követelmények szerepe

• A követelmények jellegének meghatározása abban nyújt segítséget, hogy eldönthessük: – milyen funkcionalitást, – milyen felületet biztosítson a program a

felhasználó felé,– milyen belső funkciókat kell teljesítenie ahhoz,

hogy a felhasználó igényeit kielégítse, – és működése közben milyen előírásokat,

szabályokat kell alkalmaznia, betartania.

Tipikus módszerek: megbeszélés, interjúGaus&Weinberg által javasolt 3 kérdéscsoport módszer:

– szövegkörnyezet független kérdések• Ki fogja majd használni az alkalmazást? Ki lesz az

alkalmazás felhasználója?• Milyen gazdasági előnyökkel jár egy sikeres

alkalmazás?• Kinek az érdekeit szolgálja a fejlesztés?

– a fejlesztés specifikus kérdések• Le tudná írni azt a környezetet, amelyben a megoldást

alkalmazzák?• Létezik bármilyen dolog vagy megszorítás, amely

hatással lehet az alkalmazás megvalósítására?– meta-kérdések: amelyek a megbeszélés eredményességére

fókuszálnak - • A témához kapcsolódó kérdésekkel találkozott?• Nem volt sok a feltett kérdések száma?

Követelmények feltárását, összegyűjtését segítő technikák

Követelmények csoportosítása

• A követelmények hierarchikus rendszert alkotnak, a rendszer elemei pedig összefüggésben állnak egymással. Az összefüggések lehetnek közvetlen ok-okozati, származási, illetve egyéb logikai kapcsolatok.

• A követelményrendszer felépítéséhez célszerű a követelményeket típusokba sorolni.

A követelmények csoportosítása

• Felhasználói követelmények• Funkcionális és nem funkcionális

követelmények• Szakterületi követelmények

Felhasználói követelmények

• A felhasználónak a szoftverrendszerrel szembeni igényei, elvárásai felhasználói célok un. felhasználói követelmények formájában fogalmazódnak meg.


• Magas szintű, gyakran absztrakt követelmények – a rendszerrel szembeni legfőbb megrendelői elvárások.

• Ábrázolásukhoz általában diagramokkal kiegészített természetes nyelvű leírásokat használunk.

• A cél annak definiálása, hogy milyen szolgáltatásokat várunk el a rendszertől, és annak milyen feltételek, megszorítások mellett kell működnie.


• Meg tudják adni, le tudják írni a szervezetnek azt a területét/területeit (alrendszer), azt a szervezeti környezetet, amelyikben majd a fejlesztendő szoftveralkalmazás működni fog.

• Megadják a rendszertől elvárt szolgáltatásokat, és azokat a feltételeket (megszorításokat), amelyeket a rendszer fejlesztése és majdani működése során be kell tartani.

• Vannak elképzeléseik az alkalmazás használatára, az alkalmazás bemenetére, kimenetekre (pl. listák, bizonylatok formája).

Felhasználói követelmények• A felhasználói követelmények:

– un. magas szintű célok– kategorizálni kell, közöttük prioritási sorrendet

kialakítani, majd a felállított fontossági sorrend alapján az igényeknek megfelelően, szükséges mélységben részletesen ki kell fejteni.

• A követelmények kategorizálásnak és minősítésének számos hatékony módszerei:– A szakirodalom a Software Engineering Institute

(SEI) és az ISO által kidolgozott módszereket javasolja alkalmazni.

– Az egységesített módszertan a követelmények csoportosítását a FURPS+ modell alapján végzi.


• A felhasználói követelmények alapot képeznek:– a szoftverrendszertől elvárt konkrét

szolgáltatások (szoftverfunkciók, amiket a szoftver csinál) meghatározására.

Követelmények

• Az alkalmazástól elvárt szolgáltatások, szoftverfunkciók a követelménymodellben:– funkcionális (a rendszer működésére

vonatkoznak) és – nem funkcionális követelmények (a működést

befolyásoló egyéb követelmények) formájában fogalmazódnak meg.

Funkcionális követelmények

• A rendszer által nyújtandó szolgáltatások ismertetése (hogyan kell reagálnia a rendszernek bizonyos eseményekre, hogyan kell viselkednie egyes szituációkban).

• A funkcionális követelmények a rendszertől várt funkciókat és/vagy szolgáltatásokat írják le.

• Már a szoftverrendszer működésére, a tényleges funkcionalitásra vonatkozó leírások.


• Funkcionális követelmények:– azokat a követelményeket értjük,

amelyek a szoftverrendszert kívülről nézve, a felhasználó szemszögéből írják le.


• A funkcionális követelmények:– leírják, hogy a rendszert ért hatásokra,

eseményekre a szoftveralkalmazásnak hogyan kell reagálni,

– a megfogalmazott feltételek, megadott megszorítások függvényében a rendszernek milyen alternatív végrehajtást kell biztosítani,

– a bekövetkezett események hatására milyen más funkciókat kell aktivizálni.

Fejlesztendő szoftverrendszer

Szervezet, vállalati belső környezet

SW alkalmazásokFelhasználók, akik fejlesztendő alkalmazást

működtetik

Külső szereplők, akik

fejlesztendő alkalmazás szolgáltatásait igénybe veszik

Külső rendszerek

Nem funkcionális követelmények

• A rendszer funkcióival és szolgáltatásaival kapcsolatos megszorítások.

• Például – időbeli korlátozások, szabványok, hardver és

szoftverkörnyezeti előírások, teljesítménykövetelmények, stb.

Szakterületi követelmények

• A rendszer szakterületén alkalmazott előírások, megszorítások (számítási előírások, jogszabályok, stb.).

• A szakterületi követelmények természetesen lehetnek funkcionális és nem funkcionális követelmények.

Tesztelés követelmények alapján

Szoftverrendszerek tesztelése

• A szoftver fejlesztés célja:– a specifikációban leírt követelményeket

kielégítő szoftver készítése. – Fejlesztés során különböző ellenőrző,

elemző lépéseket kell végrehajtanunk a cél elérése érdekében. A vizsgálat során két egymástól eltérő célunk lehet:

• Vizsgálhatjuk azt, hogy a megfelelő terméket készítjük-e. Ebben az esetben validációt végzünk.

• Vizsgálhatjuk azt, hogy a terméket jól készítjük-e. Ebben az esetben verifikációt végzünk.

V & V: verifikáció és validáció

• A verifikáció:– azt vizsgáljuk, hogy a fejlesztés során

egymás után végrehajtott fejlesztési lépések során előállított szoftver (ill. annak terve) megfelel-e a specifikációban rögzített elvárásoknak, tulajdonságoknak.

– A verifikáció során a vizsgálat alapja mindig valamilyen fejlesztés során előállított információ (termék).

V & V: verifikáció és validáció

• A validáció:– általánosabb folyamat, – Azt vizsgáljuk, hogy az elkészített termék

megfelel-e a megrendelő elvárásainak. – A validáció tehát magában foglalja a

specifikáció ellenőrzését is.

Szoftvertesztelés alapsémája

• A tesztelés lényege összehasonlítás: – A tesztelt szoftver (software under test, SUT)

kimeneteit, működését, viselkedését összehasonlítjuk valamilyen referenciával.

– Az összehasonlítás alapjául szolgáló referencia leírása sok forrásból származhat, attól függően, hogy a szoftverfejlesztés mely stádiumában hajtjuk végre a tesztelést.

• Származhat az információ a specifikációból nyert adatokból,

• prototípus szoftver leírásából/megfigyeléséből, vagy

• a fejlesztés során előállított, rendszer viselkedését leíró modellből.

bemeneti sorozat

Tesztelt szoftver software under test,

SUT

Értékelés (viselkedés, kimenetek

összehasonlítása)

Referencia (követelmény specifikáció, prototípus, rendszermodell

stb.)

SUT kimenet

viselkedés, állapot megfigyelése

referencia kimenet

eredmény

Szoftvertesztelés alapsémája

Funkcionális követelmények leírása

• A felhasználói célokat a követelményelemzés munkafolyamat során a funkcionális követelményekben definiált funkciókkal teljesítjük.

• A funkcionális követelményeket az UML-ben use case-ekkel írjuk le, ábrázoljuk.

• Minden felhasználói célhoz tartozni kell a funkcionális követelmények egy bizonyos halmazának, de legalább egy use case-nek.

Követelmények megvalósításának ábrázolása EA-ban

ud Köv etelményekMegv alósítása

EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version






























ÁrajánlatKészít_Weben

ÁrajánlatKészítés ÁrajánlatMódosítás

ÁrajánlatbólRendelés

ÁrajánlatKészítés

ÁrajánlatMódosít_WebenÁrajánlatLekérdez_Weben


A megrendelővel (felhasználóval) egyetértésre jutni, hogy pontosan mit kell a

rendszernek tudnia.A fejlesztőknek pontos képet

adni a rendszerről.Meghúzni a rendszer határait.

Biztosítani az iterációk tervezéséhez szükséges technikai információkat.

A rendszerhez a felhasználói igényeknek megfelelő felhasználói interfész

meghatározása.

KövetelményelemzésÁltalános célok, feladatok:• A megrendelővel (felhasználóval) egyetértésre jutni,

hogy pontosan mit kell a rendszernek tudnia.• A fejlesztőknek pontos képet adni a rendszerről.• Meghúzni a rendszer határait.• Biztosítani az iterációk tervezéséhez szükséges

technikai információt.• A rendszerhez a felhasználói igényeknek megfelelő

felhasználói interfész meghatározása.

Új rendszer fejlesztése

• A probléma elemzése:– Nincs egy meglévő rendszer, amely meghatározná a

megoldandó feladatot és az alapvető követelményeket.

• A probléma elemzését elsősorban az előkészítés fázisban, és a kidolgozás fázis korai szakaszában hajtjuk végre.

• Kapcsolódó tevékenységek:– Fogalomtár készítése – Use case modell: szereplők és use case-ek megkeresése – Követelmény kezelési terv kidolgozása – Projekt Vízió kidolgozása.

Fogalomtár készítése• Közös fogalmak megkeresése.

– a probléma domain területének közös fogalmai– az itt definiált fogalmakat konzisztens módon használhatjuk a

rendszer bármilyen szöveges dokumentációjában– elkerülhetőek a projekt tagjai közötti félreértések

• A fogalomtár kialakítása során a következő típusú fogalmakat kell figyelembe venni:

• Üzleti fogalmak, amelyekkel az adott szervezet a mindennapi munkája során találkozik

• Valós világbeli fogalmak, amelyeket a rendszernek figyelembe kell venni, például: számla, utas, vevő…

• Események, amelyeket a rendszernek kezelnie kell, például megbeszélések, hiba előfordulások.

Új rendszer fejlesztése - Lépések

– Felvázolni a rendszer funkcionális működését– Meghatározni, melyek azok a funkciók, amelyeket a

rendszernek meg kell valósítani, és melyek azok, amelyek a rendszer határain kívül vannak

– Meghatározni, hogy KI vagy MI fog kapcsolatba kerülni a rendszerrel

– A készülő modellt csomagokra bontani a megtalált aktorok és használati esetek figyelembe vételével

– Elkészíteni a használati eset modellt– A használati eset modell áttekintő leírásának

elkészítése

Elvégzendő feladatok

• Felhasználói követelményeket teljesítő:– funkcionális és– nem funkcionális követelmények

meghatározása.• Funkcionális követelmények leírása UML

segítségével:– Use case-ek.

Elvégzendő feladatok

• Use case-ek struktúrálása.• Use case-ek és az aktorok kapcsolatának

meghatározása:– use case diagram.

• Use case modell(ek).

Use case modell

• A követelményspecifikáció végére előálló use case modell:– a rendszer tervezett funkcionális működését, – a rendszer viselkedését írja le – a rendszert kívülről, a felhasználó

szemszögéből nézve.

Use case modell elemei

• use case-ek (szoftverfunkciók), amelyeket a fejlesztendő szoftverrendszernek meg kell valósítani,

• aktorok, akik/amik a rendszer határán kívül vannak, a rendszerrel kapcsolatba kerülnek, hogy a rendszerrel feladatokat (szoftverfunkciók) hajtsanak végre,

• a kapcsolat az aktorok és use case-ek közötti viszonyrendszert definiálja.

Az aktorok és a use case-ek megkeresése

• gyakorlat:– gyakran elég nehéz a use case-ek listájának

felállítása– a gyakorlat szerint elsőként könnyebb az aktorok

listájának elkészítése, majd ezután a use case-k megkeresése

– vegyük sorra a szereplőket, és nézzük meg – a felhasználó szemszögéből – mit várnak el a rendszertől!

• Mi az elsődleges funkció, amit a szereplő elvár a rendszertől?

• A szereplő fog adatot bevinni a rendszerbe, módosítani vagy törölni?

• stb.

Aktorok és use case-ek megkeresése - Aktorok azonosítása

• Cél:– Meghatározni, hogy KI vagy MI fog

kapcsolatba kerülni a rendszerrel

Use case modell elemei - Aktorok

Aktorok

• Az aktor: – egy szerep, amit az érdekelt játszik/végrehajt a

rendszerrel folytatott interakcióban. – A rendszer szereplője, valaki vagy valami a

rendszer határán kívül, aki/ami kapcsolatba kerül a rendszerrel.

– Az aktorok nem kizárólag személyek, lehetnek elemek, dolgok, gépek-berendezések, üzleti egységek, vagy a rendszerrel kapcsolatot létesítő valamely külső rendszerek, rendszerkomponensek.

Aktorok - szerepkör

• A szereplő elnevezés helyett gyakran a szerepkör kifejezés.

• Szerepkör:– A rendszer felhasználói meghatározott

feladatkört (szerepet, jogosultságot) betöltve léphetnek csak kapcsolatba a rendszerrel, csak konkrét szerepkör birtokában használhatják a szoftverrendszert és azok szolgáltatásait.

Aktorok sajátosságai

• Egy felhasználó többfajta szerepet is játszhat/végezhet, többféle szerepkörben lehet; egy szerepkört több felhasználó is betölthet;– Ha van a rendszerben két azonos aktor,

akkor az csak egy aktor.

Aktorok sajátosságai• Az aktoroknak a rendszerrel kapcsolatban

igényeik vannak, feladatok végrehajtását kezdeményezik, vagy a rendszer által nyújtott funkciók, szolgáltatások megvalósításában vesznek részt.– A feladatok végrehajtását kezdeményező

szereplőket kezdeményező szereplőnek, a funkció (use case) megvalósításában részt vevőket résztvevő szereplőnek hívjuk.

– Egy use case-t mindig csak egy aktor kezdeményezhet, egy use case megvalósításában viszont több aktor is részt vehet.

Aktorok sajátosságai

• Az aktorok egymással együttműködve megvalósítják a rendszer céljait;

• Az aktor nem objektum, hanem csak egy osztályszerű elem, amit az UML classifier minősítéssel azonosít;

• Az aktor grafikus szimbóluma egy pálcikaemberke.

szereplő/aktor

Aktorok azonosítása• A felhasználóval folytatott beszélgetések, a

felhasználói célokat összefoglaló dokumentumok alapján körvonalazódik, hogy mik, vagy kik az érdekeltek a rendszer határán kívül, amik/akik közvetlenül kapcsolatba kerülnek, kommunikálnak a szoftverrendszerrel.

• A követelményspecifikációban meghatározott érdekeltek köre (pl. a Kft. ügyfélszolgálati munkatársai, mint a szoftverrendszer használói) nem feltétlenül, sőt sok esetben abszolút nem egyezik meg az üzleti modellezés során felállított érdekeltek (pl. a Kft. vezetése, aki tendert írt ki a szoftverrendszer fejlesztésére) listájával.

Az aktorok megtalálásának módja

• A felhasználói célokat összefoglaló dokumentumokból kikeressük a főneveket. A kereséskor a releváns szereplők meghatározása érdekében célszerű arra koncentrálni, hogy:– Ki/mi használja a rendszert?– Kik működtetik a rendszert, kik felelnek a rendszer

karbantartási és adminisztrációs feladatainak végrehajtásáért?

– Kinek a hatáskörébe tartozik a biztonságkezelés, rendszervédelem?

– Létezik a rendszerben folyamatfigyelés, monitoring folyamat (monitoring process), amelyik hiba esetén újraindítja a rendszert?

– Kommunikál-e az új rendszer más rendszerekkel?– stb.

A rendszer szereplőinek specifikálásra vonatkozó előírások

• A rendszerrel közvetlenül kapcsolatba kerülő, a rendszert használó érdekelteket (személyek, dolgok, más rendszerek, rendszerkomponensek) a feladatkörre, szerepkörre utaló névvel kell ellátni, azonosítani.

• Az aktorok neve egy tetszőleges jelekből álló karaktersor.

• Az aktor neve azonosítja a use case-t kezdeményező, vagy a use case megvalósításában részt vevő szereplőt.

A rendszer szereplőinek specifikálásra vonatkozó előírások

• Az UML modellező nyelv szabályai szerint az aktorokat grafikusan egy pálcikaember jelöli.

• Az aktor nevét a szimbólum alá írjuk.• A specifikációban röviden meg kell adni

mit vár el az aktor a tervezett szoftverrendszertől, mi a felelőssége.

Use case-ek azonosítása

• A rendszer aktorainak, és azok elvárásainak ismeretében már viszonylag könnyű meghatározni a use case-eket.

Use case modell elemei – Use Case-ek

Use case

• Az UML-ben use case-ekkel írható le a fejlesztendő szoftverrendszertől a valós szituációkban a felhasználó által elvárt, megkövetelt viselkedések, a rendszer által nyújtott szolgáltatások.

Use case fogalma• Feladatok, funkciók kisebb vagy nagyobb egységeinek

specifikálására szolgáló grafikus ábrázolási technika – a use case-ek valójában a rendszer funkcionalitását, viselkedését fejezik ki a rendszert kívülről szemlélve.

• A rendszer egy aspektusának pillanatképe. A rendszerrel kapcsolatos összes use case feltárása a fejlesztendő rendszer külső képét adja.

• A rendszer kívülről látható funkciói, un. kapcsolódási pontok a szoftverrendszert használók és a szoftverrendszer között.

A use case• A felhasználó és a számítógépes rendszer

közötti interakciót definiálja. • Tipikusan a szoftver és a felhasználó (aktor)

között lezajló kommunikáció, üzenetváltás lépéseit írja le a felhasználó szemszögéből.

• Egy use case pontosan azt határozza meg, hogy a felhasználó (aktor) MIT akar a szoftverrel végrehajtani, milyen célt kíván megvalósítani, ugyanakkor nem tér ki a megvalósítás, a HOGYAN részleteire?

Use case-ek a követelményspecifikációban

• A követelményspecifikáció munkaszakaszban definiált use case-eket a szakirodalom fekete doboz use case-eknek (black-box use case) nevezi.

• A fekete doboz jelző:– azt hangsúlyozza, hogy a fejlesztésnek ebben a

szakaszában nem térünk ki a rendszer, a rendszerkomponensek belső működésére.

– A cél csak a rendszer viselkedésének specifikálása a rendszert külső szemmel nézve, fontos a külső környezetnek a feltárása, a rendszerhatár meghúzása.

Példa

Black-box módszer a rendszer (külső) viselkedésének leírására

Belső működés specifikálása

ÁrajánlatKészít_Weben use case:Végrehajtásakor az Ügyfél

megadja az Árajánlat összeállításához szükséges adatokat, majd a rendszer elkészíti az árajánlatot.

ÁrajánlatKészít_Weben use case:A rendszer ellenőrzi a megadott

adatokat, ha az adatok helyesek a rendszer az adatbázisba, az árajánlat táblába beszúr egy új sort, rekordot.

A use case-ekre vonatkozó jellemzők, sajátosságok

• A fejlesztendő rendszer szempontjából megkülönböztetünk:– architektúrálisan fontos, – egyéb és – rendszeridegen use case-eket;

• egy use case lehet „kicsi vagy nagy”;• egy use case diszkrét célt teljesít, valósít

meg a felhasználó számára;

A use case-ekre vonatkozó jellemzők, sajátosságok

• a use case-eket minden esetben az aktorok kezdeményezik;

Use case-ek megtalálásának módszerei

• az adott területre jellemző felhasználóval való folytatott közös beszélgetések, interjúk,

• kérdőívek használata csoportos felmérés esetén, • brainstorming (ötletbörze) módszer alkalmazása.

Használata elsősorban új fejlesztések esetén hasznos, vagy nehezen megfogható, leírható problémák megoldásakor.

• vitakurzusok a korábbi beszélgetések során definiált dolgok (feladatok, funkciók) megvitatására, tisztázására,

• egyszerű, un. favágó módszer: a célokat megfogalmazó dokumentumokból kigyűjtjük az igéket,

• stb.

A use case-ek specifikálásra vonatkozó szabályok

• a követelményspecifikáció során feltárt diszkrét dolgokat, feladatokat – a use case-eket a funkciójellegre utaló névvel kell ellátni, azonosítani,

• a use case-t azonosító név egy tetszőleges jelekből álló karaktersor,

• a use case neve kettős szerepet tölt be:• azonosítja a diszkrét feladatot, amit a

rendszernek teljesíteni kell, • az megnevezés az adott use case-t meg is

különbözteti a többi use case-től.

A use case-ek specifikálásra vonatkozó szabályok

• a use case-eket (diszkrét feladat, funkció) az UML modellező nyelv szabályai szerint grafikusan egy ellipszis szimbólum jelöli,

• a use case (funkció) nevét az ellipszis alá írva adjuk meg ,

• minden use case-hez tartozni kell egy use case leírásnak

use case/funkció

Munkafolyamat

A rendszer hatáskörének kezelése

A rendszer hatáskörének kezelése

• Kapcsolódó tevékenységek:– Használati esetek kategorizálása

• Ennek a tevékenységnek a feladata kiválasztani azokat a használati eseteket, amelyeket az adott iterációban meg fogunk valósítani.

• Ezeket kell majd elemezni és tervezni és ezeket fogjuk először implementálni.

– Követelmények közötti összefüggések kezelése

– Projekt Vízió kidolgozása

Használati esetek kategorizálása

• Azoknak a használati eseteknek és forgatókönyveknek a kiválasztása, – amelyek elemzését az aktuális iterációban el

akarjuk végezni– amelyek szignifikáns, központi funkcionalitást

valósítanak meg– amelyek architektúrális szempontból

jelentősek • A kategorizálás a rendszerépítész

(architect) feladata.

Használati esetek kategorizálása

• Azoknak a használati eseteknek vagy forgatókönyveknek a kiválasztása, amelyeket az adott iterációban elemezni és tervezni kell. – A döntési szempont lehet:– A forgatókönyv fontossága: kritikus, fontos, kiegészítő– A megszüntethető kockázat: teljesítmény,

felhasználhatóság, megfelelőség– Az architektúrára gyakorolt hatása– Egyéb technikai igények, például demo készítése.

• A Szoftver Architektúra Dokumentum használati eset nézetének elkészítése– architektúrális szempontból kritikus használati esetek

A rendszer definíciójának finomítása


• Kapcsolódó tevékenységek:– Használati eset részletezése

• A használati esetekhez korábban elkészített flow of event leírás alapján a működés további részletezése.

• A részletes működés ábrázolása Activity diagram segítségével. – A szoftver követelmények részletezése

• Azoknak a dokumentumoknak az összegyűjtése és rendszerezése, amelyek a rendszerrel szembeni követelményeket tartalmazzák.

• Itt a korábban dokumentált követelményeket kell egységes formában megjeleníteni.


– A felhasználói felület modellezése• A kiválasztott használati esetek végrehajtásához szükséges

felhasználói felület megtervezése.

• A felhasználói felület osztályainak (határosztályok) azonosítása és tervezése.

– Felhasználói felület prototípusának elkészítése• Amennyiben a projekt során úgy döntöttünk, hogy készítünk

prototípust

Használati eset részletezése• A használati eset folyamatának részletes leírása a step-

by-step leírásból kiindulva:– Hogyan kezdődik a használati eset? (Például: A használati eset

akkor kezdődik, amikor a felhasználó kiválasztja a Jelentés menüpontot.)

– Hogyan ér véget a használati eset? (Például: A használati eset véget ér, ha a felhasználó jóváhagyja a megadott adatokat. )

– Milyen kölcsönhatások történnek az aktor és a használati eset között? (Például: A felhasználó megnyomja az OK gombot, a használati eset megjeleníti a kiválasztható időszakokat…)

– Milyen adatok cserélődnek a használati eset és az aktor között? (Például: A felhasználó megadja a nevét és jelszavát…)

– Milyen ismétlődő viselkedést hajt végre a használati eset? Ez algoritmikus viselkedésre utal, de ha lehet, akkor nem ciklusokkal kifejezve. (Például: a használati eset mindaddig kéri az időszakot, amíg az aktuális dátumnál kisebbet nem kap…)

Használati eset részletezéseFolyamatok struktúrálása:• Egy használati eset is sokféleképpen hajtódhat végre:

– Mit választ a felhasználó (bemenetek)?– A belső objektumok állapota milyen?

• Az összes opcionális, alternatív esetet le kell írni. • Célszerűen külön szekcióba. Különösen, ha

– nagyon nagy az opcionális szakasz,– a kivételes, hibás eseteket kezeli a

folyamat - így tisztább marad az alapfolyamat,

– az alfolyamat több helyről is elindulhat.

Használati eset részletezése - Activity diagramok

• A folyamatok szerkezetét aktivitás (activity) diagramok segítségével szemléltethetjük.

• Aktivitás-diagram– Több különböző technikát is ötvöz

• Folyamat ábra• Petri háló• Állapot diagram

– Hasznos munkafolyamatok, illetve párhuzamos folyamatok modellezésére is.

– Felfogható egy olyan speciális állapot diagramnak, amelynél az állapot átmenetek nem zéró idő alatt zajlanak le és egyszerre több tevékenységet is lehet végezni az átmenet alatt.

Use case leírás

• A felhasználó szemszögéből rögzítjük a felhasználó és a rendszer között zajló üzenetváltás (párbeszéd) lépéseit:– Normál működés,– Alternatív működés.

Use case leírás• Normál működés:

– a use case-ben definiált szokásos működést a use case normál lefutásának, más szóval alapfolyamatnak hívjuk.

• Alternatív esetek:– A működésnek lehetnek különleges, alternatív

esetei (pl. hibás működés), ezek az alfolyamatok. • A fejlesztés során minden use case esetén fel

kell tárni az összes alternatív lefutási menetet. • A tervezett rendszernek a use case-ekben

definiált normál és alternatív működését külön forgatókönyvekben rögzítjük.

Forgatókönyv

• Más szóval szcenárió.• A use case-ben definiált működés egy konkrét

végrehajtása, lefutása, a use case egy instanciája (példánya).

• A rendszer use case-ben definiált működésének lépésenkénti, un. step-by-step végrehajtását írja le a felhasználó szemszögéből.

• Egy use case-hez az alternatív működések miatt több forgatókönyv készülhet, de egy biztosan.

Forgatókönyv• A forgatókönyv készítésekor a rendszer és a

felhasználó között zajló üzenetváltásokat a felhasználó szerepében célszerű megfogalmazni, hiszen a felhasználó fogja az alkalmazást használni.

• Az üzenetváltások leírásakor a MIT-re koncentráljunk, azt írjuk le, hogy a use case működéskor MI történik, milyen tevékenységek zajlanak, és ne térjünk ki a HOGYAN részleteire, a megvalósítás módjára.

• A forgatókönyvben elsőként a use case normál működést írjuk le, de el kell készíteni az alternatív esetekhez tartozó forgatókönyveket is.

Forgatókönyv készítése

• A forgatókönyv készítésére nincsenek szigorú formai előírások, megkötések.

• A forgatókönyvben a use case működését, vagyis az egymás után zajló tevékenységeket szöveges formában, mondatszerűen fogalmazzuk meg.

A forgatókönyv tartalma

• Egy lehetséges alternatíva:– a feladat rövid értelmezése,– alternatív útvonalak meghatározása,– a végrehajtásban résztvevő szereplők

meghatározása,– közös feladatok kiválasztása.

Forgatókönyv készítése

• Érdemes megvizsgálni:– Hogyan kezdődik a use case?– Hogyan ér véget a use case?– Milyen kölcsönhatások történnek az aktor és

a use case között?– Milyen adatok cserélődnek a use case és az

aktor között?– Milyen ismétlődő viselkedést hajt végre a use

case?

Példa• Az ÁrajánlatKészít_Weben use case-hez

készített részletes leírásban négy forgatókönyvet kell részletezni:– A use case normál lefutása szokásos működés

esetén: a use case sikeresen véget ér, ha az Ügyfél elfogadja az Árajánlatra vonatkozó feltételeket.

Példa• A szokásostól eltérő működéskor a lehetséges

lefutások, alternatív útvonalak: – az Ügyfél a felhasználói név és a jelszó megadásakor

a MÉGSEM gombra kattint.– az Ügyfél a felhasználói név és a jelszó megadásakor

az OK gombot választja, azonban a rendszer a megadott adatok ellenőrzésekor hibát talál. A megadott adatok vagy azért hibásak, mert az ügyfél azokat rosszul adta meg, vagy azért, mert nem regisztrált felhasználó. Ilyen esetben a use case véget ér.

– Az Ügyfél a rendszer által küldött Árajánlat elfogadása üzenet megerősítésekor a MÉGSEM gombot választja.

Forgatókönyv normál működés esetén

• Az Ügyfél a Kft. honlapján aktiválja az "Az Árajánlat készítés" funkciót.

• A bejelentkezéskor a rendszer megjeleníti a Login dialógusablakot, ahol kéri az Ügyfél felhasználói nevét, és jelszavát.

• Az Ügyfél megadja a felhasználói nevét, és jelszavát.

• A rendszer ellenőrzi (validálja) a megadott adatokat. Hibás adatok esetén újra kéri az adatokat.

Forgatókönyv normál működés esetén

• A rendszer megjeleníti az „Árajánlat készítés” lapot.• Az Ügyfél megadja a kért adatokat.• A rendszer validálja a megadott adatok helyességét,

ellenőrzi az adatok konzisztenciáját. Ha az Ügyfélnek nem sikerült érvényesen kitölteni a lapot, a rendszer mindaddig visszatér a laphoz, amíg azt az Ügyfél helyesen ki nem tölti.

• A rendszer megerősítést kér az Ügyféltől az Árajánlat elfogadására.

• A rendszer elmenti az Árajánlat adatait, és nyugtázó üzenetet küld a képernyőn keresztül az Ügyfélnek az Árajánlat készítésének sikerességéről.

Aktivitási diagram

Az Ügyfél a Kft. honlapján aktiválja az "Az Árajánlat készítés" funkciót.

A rendszer megjeleníti a Login dialógusablakot, ahol kéri az Ügyfél felhasználói nevét, és jelszavát.

Az Ügyfél megadja a felhasználói nevét, és jelszavát.

A rendszer ellenőrzi, validálja a megadott adatokat.

A rendszer megjeleníti az "Árajánlat készítés" lapot.

Az Ügyfél megadja a kért adatokat.

A rendszer validálja a megadott adatok helyességét, ellenőrzi az adatok konzisztenciáját.

A rendszer elmenti az Árajánlat adatait.

A rendszer nyugtázó üzenetet küld az Ügyfélnek a képernyőn az Árajánlat készítésének sikerességéről.

A rendszer megerősítést kér az Ügyféltől az Árajánlat elfogadására.

[ Árajánlat Elutasítva! ]

[ Hibás adatok! ]

Aktivitási diagram

Aktivitási diagram• Activity diagram / Tevékenység diagram.• Tevékenységfolyamatnak tekintjük: az egymás

után végrehajtandó feladatokat, amelyeknél egy kiindulási pontot – initial state, avagy kezdő állapotot, és egy vagy több lezárási pontot, más néven vég állapotot – final state értelmezünk.

• Felhasználás:– egy UC (használati eset) formalizálása, megértése– workflow modellezés (több UC közötti kapcsolat)– metódusok összekapcsolása (többszálú alkalmazás).

Aktivitási diagram• A forgatókönyvben meghatározott lépéseket az

UML-ben tevékenységeknek, aktivitásoknak nevezzük.

• A forgatókönyvben meghatározott tevékenységek menetének grafikus szemléltetésére az UML diagramok közül az aktivitási (tevékenységi) diagramot használjuk.

• Egy use case-hez annyi aktivitási diagram készül, ahány alternatív lefutása (forgatókönyvek száma) van.

Tevékenységek, akciók, átmenetek

• tevékenységek, akciók: a rendszer működtetése során végrehajtandó feladatok, műveletek

• akciók: – a funkció-hierarchia legalsó szintjén elhelyezkedő elemi

műveletek un. atomi műveletek– további lépésekre nem bonthatók– pl. számítási műveletek, objektum manipulására

vonatkozó kérések stb.• tevékenységek:

– összetettebbek, további lépésekre bonthatók– megszakítható tevékenységek a végrehajtás

folyamatában: az akciók elvégzéséhez meghatározott időre van szükség

Tevékenységek, akciók, átmenetek

• UML igazán nem tesz köztük különbséget, mégis lehet következtetni, hogy elemi műveletről vagy tevékenységről van szó– de a tevékenységekhez pl. hozzájuk

kapcsolhatók belépési pontok, kilépési akciók• átmenetek

– a végrehajtás folyamatában műveletek követik egymást, az egyik művelet végrehajtása után egy másik művelet végrehajtása következik - átmenet

Aktivitási diagram

• Aktivitás, tevékenység (activity)– Valamilyen tevékenység, amit meg kell

csinálni.– Valamely osztály művelete lesz belőle.

• Szekvencia: a tevékenységet egy másik tevékenység követ – Alapértelmezett a szekvenciális végrehajtás.

Aktivitási diagram

• A tevékenységek kezdetét a start szimbólum jelöli

• A működés félbeszakad: ha a vezérlés eléri az aktivitás diagram egy stop szimbólumát

• A működés befejeződik: ha minden aktivitás befejeződött és nincs hátra más végrehajtandó tevékenység

start Rendelés érkezik

Fizetés ellenőrzése

Raktárkészlet ellenőrzés

Rendelés törlése

Áru eladva

UtánrendelésKiszállítás

*[ minden egyes árura a rendelésben ]

[ nem OK ]

[minden elem kész, fizetés OK]

[ OK ]

[ utánrendelés szükséges ]

[ van raktáron ]

Start, kezdőpont átmenet

műveletek (tevékenységek,

akciók)

Aktivitási diagram

• Elemkészlete:– aktivitás– sorrendezés/párhuzamosság– szinkronizáció– őrfeltételek– döntések

szinkronizáció (fork/join)

Aktivitás1 Aktivitás2[ őrfeltétel ]

döntés

kezdőpont végpont

Példa: Aktivitási diagram• Rendelésfelvétel használati eset forgatókönyve:

– Amikor egy rendelés beérkezik, minden egyese elemére megnézzük, hogy van-e raktáron.

• Ha van raktáron, akkor összerendeljük őket• Ha egy utánrendelési (minimum) szint alá csökken a

raktárban az árukészlet, akkor utánrendelést adunk be– Mialatt az árukészlettel foglalkozunk, megnézzük,

hogy a fizetés rendben van-e: • rendelés OK, fizetés OK: szállítás• fizetés OK, rendelés nem OK: várakoztatás• fizetés nem OK: a rendelés törlése

start Rendelés érkezik

Fizetés ellenőrzése

Raktárkészlet ellenőrzés

Rendelés törlése

Áru eladva

UtánrendelésKiszállítás

*[ minden egyes árura a rendelésben ]

[ nem OK ]

[minden elem kész, fizetés OK]

[ OK ]

[ utánrendelés szükséges ]

[ van raktáron ]

Aktivitási diagram• a műveletek végrehajtási sorrendje általában

szekvenciát, egymásutáni sorrendet mutat, de van amikor dönteni kell a folytatás irányáról – különböző ágak jönnek létre, különböző folyamat alternatívák jönnek létre

• az elágazási feltételek (branch) valamilyen logikai kifejezés formájában fogalmazhatók meg:– verbálisan a Boole algebra szabályrendszerével egyszerűen

írhatók le: then, else

• az elágazási pontokban a rendszer kiértékeli, és az eredménytől függő ágon folytatja a végrehajtást

Aktivitási diagram - szinkronizáció

• feladatok, amelyek egyidejűleg, egymással párhuzamosan hajthatók végre

• bizonyos műveletek végrehajtásának a megkezdése előtt más feladatokat kell befejezni

• szemléltetés: szinkronizációs vonalszinkronizáció (fork/join)

Aktivitási diagram - szinkronizáció

• kétféleképpen értelmezhető:– elágazás – fork:

• a folyamat olyan pontja, amelyből a végrehajtás egy, vagy több ágban párhuzamosan végzett tevékenységek végrehajtásával folytatódik

• az elágazási pontban egy bemenő, és kettő vagy több kimenő akció van

– csatlakozás – join:• a csatlakozási pontban a folyamat különböző ágakban, addig

egymással párhuzamosan végrehajtott tevékenységei befejeződnek, és egy újabb tevékenység megkezdésére kerül sor.

• a csatlakozási pontban kettő vagy több bemenő tevékenység befejezését kell szinkronizálni, a folyamat egy kimenő akcióval folytatódik

Use case modell elemei - Kapcsolat

Kapcsolatok

• Kapcsolat alatt klasszikus értelemben:– az aktorok és a use case-ek közötti

kapcsolatokat értjük.• Az UML-ben a rendszer szereplői és a use

case-ek között definiált kapcsolatok modellezésére a use case diagram szolgál.

Kapcsolatok

• A kapcsolatot a diagramban az aktorokat és a use case-eket összekötő vonal szimbolizálja.

• A vonal lehet irányított.

Aktorok és use case-ek között értelmezett kapcsolatok típusa

• Kezdeményezés• Közreműködés, részvétel a

végrehajtásban


• Egy use case-t mindig egy aktor kezdeményezhet, aktivizálhat.

• A rendszer szereplői és a use case-ek közötti kapcsolatot egy irányított vonal, nyíl jelöli.

• A nyíl a szereplőtől a use case felé mutat.• Az aktor és a számítógépes rendszer között

alapértelmezésben kommunikációs jellegű kapcsolat van.– A kommunikatív jelleget a kapcsolatot szimbolizáló

nyíl felett a <<communicate>> sztereotípiával jelölhetjük.

Kezdemenyező szereplő use case

Példa


ÁrajánlatLekérdez_Weben

(from use case view)

ÁrajánlatMódosít_Weben


Regisztrál

Ügyfél

(from aktorok)

ÁrajánlatNyomtat_Weben



• Egy feladat (use case) végrehajtásában több aktor is közreműködhet.

• A use case megvalósításában részt vevő szereplőket és a use case-t egyszerű vonal (irányítás nélküli) köti össze.

Kezdemenyező szereplő

Résztvevő szereplő1

use case

Résztvevő szereplő2

Speciális kapcsolatok

• Két aktor közötti kapcsolatot.• Definiálhatunk use case-ek közötti

speciális viszonyokat is.

Speciális kapcsolat két aktor között

• Öröklődési viszony:– egy use case végrehajtásakor több szereplő

is ugyanazt a szerepet tölti be, ugyanabban a szerepkörben van.

• Az öröklődési viszonyban két aktortípus:– leszármazott, – ős szereplő.


• A leszármazott minden use case-zel kapcsolatban van, amivel az ős szereplő kezdeményez kapcsolatot. Az ős szereplőnél definiált minden use case végrehajtását kezdeményezheti, de annál akár többet is


Leszármazott szereplő1

Leszármazott szereplő2

Ős szereplő use case/funkció


Kereskedő Kereskedelmi Menedzser

Speciális kapcsolatok use case-ek között

• Három speciális viszony:– tartalmazás, – kiterjesztés és – öröklődés viszonyokat.

Tartalmazás – include viszony

• A szereplő által kezdeményezett (alap vagy normál) use case-ek végrehajtásában vannak olyan részek, lépések, amelyek mindegyik use case végrehajtásakor bekövetkeznek és azonos módon játszódnak le.

• Érdemes az azonos viselkedéseket egy külön use case-be kiemelni.


• A kiemelt viselkedés:– tartalmazott vagy rész use case. – A tartalmazott elnevezés utal arra, hogy a

tartalmazott use case az alap use case-nek szerves része.

• A tartalmazott use case végrehajtása feltétel nélküli, vagyis az alap use case végrehajtáskor mindig bekövetkezik, lejátszódik.


• Az UML-ben az alap use case-t és a tartalmazott use case-t szaggatott nyíl köti össze.

• A szaggatott nyíl az alap use case-től a tartalmazott felé mutat.

• A kapcsolat tartalmazás jellegét a szaggatott nyílon elhelyezett, francia zárójelek közé írt <<include>> sztereotípiával jelöljük.


tartalmazott (included) use case

alap/normál use case1

szereplő/aktor

alap/normál use case2

<<include>>

<<include>>



ÁrajánlatLekérdez_Weben


ÁrajánlatMódosít_Weben


Ügyfél

(from aktorok)

ÜgyfélAzonosítás_ felhasználói név&Jelszó


<<include>>

<<include>>

<<include>>

Kiterjesztés – extend viszony

• A modellben lehetnek use case-ek, amelyek végrehajtási menetében– bizonyos feltételek bekövetkezésekor a vezérlés egy

másik use case-nek adódik át. • Ilyenkor a normál use case-nek egy bővített

változata játszódik le. • Mivel a normál use case viselkedésében a

feltétel csak bizonyos esetekben következik be, ezért a normál use case-t bővítő viselkedést érdemes külön use case-ben leírni.


• A feltételt (extention point) a követelmények specifikálásakor kell megadni.

• A szaggatott nyíl a kiterjesztett use case-ből az alap use case felé mutat.


szereplő/aktor alap/normál use case kiterjesztett (extended) use case

<<extend>>


MegrendelésKészít

(from Kereskedő use case-ei)

Kereskedő

(from aktorok)

Kedvezményzárolás

<<extend>>

Öröklődés – generalizáció

• Az öröklődési viszony:– a leszármazott use case örökli a normál

use case viselkedését, kapcsolatait. – A leszármazott az eredeti/normál use

case viselkedéséhez hozzáadhat újabb viselkedéseket, sőt az eredeti use case viselkedését felülbírálhatja, felülírhatja.


• Az öröklődés jele:– az UML-ben egy telt fejű nyíl. – A nyíl a leszármazott use case-től az

általánosított normál (ős) use case felé mutat.


leszármazott use caseszereplő/aktor use case


ÜgyfélTörzsadatKarbantartás

Kereskedő

(from aktorok)

ÜgyfélTörzsadatFelvitel

<<generalization>>

Use case modell

• Aktorok.• Use case-ek.• Use case-ek struktúrálása.• Kapcsolatok.

• Ábrázolás:– Use case diagram.

Use case diagram

Use case diagram

• Használati eset diagram.• A követelményspecifikációban feltárt

– use case-eket, – Aktorokat (szereplőket) és – a közöttük értelmezett kapcsolatokat

ábrázolja.• Segít:

– a rendszer viselkedésének megértésében– grafikus modellezésében.

Use case diagram

• Alkalmas:– A tervezett rendszerrel szemben támasztott

összes követelmény (use case-ek halmaza) meghatározására, leírására.

• Eszköz:– A felhasználóval való kommunikációra.

KedvezményJóváhagyása


Kereskedelmi Menedzser(from aktorok)

KedvezményTörlése


MegrendelésKészítés

(from Kereskedő use case-ei)

ÜgyfélTörzsadatKarbantartás

(from ÜgyféltörzsKezelés)

ÁrajánlatMódosítás

(from ÁrajánlatKezelés)

ÁrajánlatbólRendelés


ÁrajánlatKészítés


Kedvezmény zárolása


<<extend>>

Kereskedő

(from aktorok)

ÜgyfélTörzsadatFelvitel

(from ÜgyféltörzsKezelés)<<generalization>>

Ügyfél által kezdeményezett use case-eket összefoglaló use case diagram

ÁrajánlatotLekérdez _Weben

Regisztrál

ÁrajánlatotNyomtat _Weben

Ügyfél

ÁrajánlatotKészít _Weben

ÜgyfeletAzonosít_ felhasználóinév&Jelszó

<<include>>

<<include>>

Use case modell dokumentálása

• Aktorok azonosítása. • Minden aktor esetén meg kell határozni mit vár

el a rendszertől. • Use case-ek feltárása, use case lista

összeállítása.• Minden use case-hez részletes leírás készítése:

– Alternatív forgatókönyvek készítése a use case működésének leírására.

– Aktivitási/tevékenységi diagram készítése.

Use case modell dokumentálása

• Kapcsolatok meghatározása:– Kapcsolatok aktor és use case között.– Speciális kapcsolatok azonosítása.

• A rendszer funkcionalitásának, viselkedésének grafikus modellezése use case diagramok készítésével.

• A fejlesztés során menetközben módosult funkciók dokumentálása, módosítások átvezetése a követelménydokumentumba.

Követelményjegyzék bejegyzés formalap

• Funkcionális és nem funkcionális követelmények dokumentálásának eszköze.

• Követelmények pontosabb, precízebb meghatározása.

• Nem UML szabvány.• Folyamatosan bővül a fejlesztés során.

Követelmény AZ egyedi azonosító

Forrás a követelmény forrása, lehet személy, dokumentum stb.

Prioritás a követelmény prioritása, a felhasználó szerint, pl. magas/alacsony, vagy kötelező/ javasolt/ választható

Tulajdonos felhasználó vagy felhasználói szervezet, aki a követelménnyel kapcsolatos egyezkedésért felelős

Funkcionális követelmény az igényelt lehetőség vagy szolgáltatás leírása

Nem funkcionális követelmény

leírás, lehetőség szerint cél értékkel, elfogadható tartománnyal (minimum, maximum), minősítő megjegyzéssel

Haszon: a követelmény kielégítéséből származó várható hasznok leírása

Megjegyzések/ javasolt megoldási módok lehetséges megoldások leírása, általános megjegyzések

Kapcsolódó iratok hivatkozás kapcsolódó dokumentumokra, mint például felhasználói dokumentumok, projektalapító okirat, adatfolyam-ábra stb.

Kapcsolódó követelményekha különböző követelmények hatnak egymásra, vagy kizárják egymást, akkor a

hivatkozást fel kell jegyezni mindkét oldalon, hogy esetleges változtatás esetén fel lehessen mérni a hatást a mások oldalon

Megoldása követelmény megoldási módjának feljegyzése, például egy konkrét

funkcióleírásra való hivatkozással. Ha egy követelményt nem fogunk kielégíteni, akkor itt kell felírni az okait

Use case

• Követelményspecifikáció:– fejlesztendő szoftverrendszertől a felhasználó

által elvárt, megkövetelt viselkedés(ek)t, a rendszer által nyújtott szolgáltatásokat írják le.

• Elemzés/tervezés:– A rendszer belső működésének leírása.– Hogyan lesznek a rendszertől elvárt funkciók,

use case-ek megvalósítva, majd implementálva.

Követelmények áttekintése

• Formális ellenőrzés: megegyezik-e az általunk kialakított modell a felhasználó elvárásaival

• Az összes termék ellenőrzése több menetben– koncepció, – felhasználói igények, – használati eset modell,– szereplők, – használati esetek, – nem-funkcionális követelmények, – fogalomszótár, – követelmény-tulajdonságok

Követelményelemzés - tevékenységek

Követelményelemzés - termékek

Használati eset modell

Tanszéki felelős

Napi feladatok elv égzése

Karbantartási feladatok elv égzése

Kimutatások készítése

(Diplomáztatás esettanulmány)ud Napi feladatok elv égzése

Új diplomaterv

nyitása

A kész diplomamunka beérkeztetése

Bírálat beérkeztetése

Diplomamunka kiadása bírálatra

Tanszéki felelős

Diplomaterv kiv álasztása

E-mail küldése «include»

«include»

«include»

«extend»

Használati eset modell

Használati eset diagram

V.2. Elemzés - tervezés

Elemzés - tervezés

Az előzőekben összegyűjtött követelményeket kielégítő rendszer

tervezése

Robosztus architektúra kialakítása

A rendszerterv illesztése az implementációs környezethez és a

hatékonysági elvárásokhoz


Általános célok, feladatok:• Az előzőekben összegyűjtött

követelményeket kielégítő rendszer tervezése.

• Robosztus architektúra kialakítása.• A rendszerterv illesztése az

implementációs környezethez és a hatékonysági elvárásokhoz.

Elemzés-tervezés• A kidolgozás fázis kezdeti szakaszában az a cél,

hogy a rendszerhez egy kezdeti architektúrát határozzunk meg („architektúra jelölt”).– Ez lesz az elemzési munka kiindulási pontja.

• Ha az architektúra már létezik:– vagy azért, mert egy korábbi iterációban vagy korábbi

projektben már kidolgoztuk, – vagy pedig azért, mert az alkalmazási keretrendszer

eleve meghatározza azt• akkor a cél a meglévő architektúra finomítása.

Elemzés/Tervezés - feladatok• A kiválasztott használati eseteket elemezni kell.• Meg kell határozni azokat az elemzési osztályokat,

amelyek megvalósíthatják a használati esetekben definiált funkciót.

• A használati eset viselkedését szét kell osztani az elemzési osztályok között:– elemzési osztályok felelősségeinek meghatározása.

• Meg kell határozni az elemzési osztályokat megvalósító tervezési osztályokat és alrendszereket.

• Meg kell tervezni a rendszer által használt (perzisztens és nem perzisztens) perzisztens adatokat tároló adatbázist.

Elemzés - tervezés• Az architektúra finomítása (Refine the

Architecture)– Az elemzési elemeknek megfelelő tervezési elemek

azonosítása– Az elemzési mechanizmusoknak megfelelő tervezési

mechanizmusok azonosítása– Az architektúra teljességének és konzisztenciájának

biztosítása– Az aktuális iterációban azonosított, új tervezési

elemek integrálása a már korábban létező tervezési elemekhez

– A meglévő komponensek és tervezési elemek újrafelhasználásának maximalizálása a tervezés lehető legkorábbi szakaszában

Elemzés - tervezés• A viselkedés elemzése (Analyze Behavior)

– A használati esetekben leírt viselkedés alapján meg kell határozni azokat az elemeket, amelyek a tervezés alapjául szolgálnak

• Komponensek tervezése (Design Components)– A tervezési elemek definíciójának finomítása azon

részletek kidolgozásával, amelyek az adott tervezési elem elvárt viselkedésének implementálásához szükségesek

– A használati esetek megvalósításainak finomítása és módosítása az újonnan megtalált tervezési elemek alapján

– A tervezési elemek alapján a komponensek implementálása

– Az implementált komponensek unit szintű tesztelése


• Adatbázis tervezése (Design the Database)– Tervezés során a perzisztens osztályok

meghatározása– A perzisztens osztályok tárolására megfelelő

adatbázis szerkezet meghatározása– A teljesítmény elvárásoknak megfelelő

mechanizmusok és stratégiák kidolgozása az adatok tárolására és visszakeresésére

Tervezés fázisai

• Architektúra kialakítása:– Architektúra tervezés

• strukturális felépítése a rendszernek minták, specifikáció, részek…

– Adat tervezés• adat könyvtár, ER adat struktúrák

• Részletes tervezés:– Interfész tervezés

• belső és külső kommunikáció– Komponens tervezés

• architektúra terv elemei implementálható program elemek, procedúrák, függvények stb.

Egy lehetséges architektúra meghatározása

Elemzés - tervezés• Egy lehetséges architektúra meghatározása (Define

a Candidate Architecture)– A rendszer architektúrájának kezdeti vázának elkészítése– Architektúrális szempontból lényeges elemek

meghatározása– Elemzési mechanizmusok meghatározása – Az alrendszerek magas szintű definiálása (rétegek és

partíciók)– Használati esetek megvalósításának létrehozása– Az elemzési osztályok meghatározása architektúrális

szempontból lényeges használati esetek elemzése alapján– Az elemzési osztályok kapcsolatai alapján módosítani a

használati esetek megvalósításait

Egy lehetséges architektúra meghatározása

• Kapcsolódó tevékenységek:• Architektúrális elemzés

– a rendszer számára egy kezdeti architektúra meghatározása a cél.

• Használati esetek elemzése– az architektúrális szempontból meghatározó

használati esetek elemzése

Architektúrális elemzés

• Pontosan definiálni kell a leendő rendszer felépítését.

Architektúra központú

• A rendszer architektúrája– (egy adott pillanatban) a rendszer alapvető

komponenseinek szerveződése, melyek egymással meghatározott felületeken keresztül kommunikálnak, és hierarchikus szervezésű, egyre finomabb, egymással szintén megfelelő, alacsonyabb szintű felületeken keresztül kommunikáló komponensekből épülnek fel.

Architektúrális elemzés• Modellezési konvenciók kidolgozása

– Nagyon fontos, hogy a modell miként adja vissza az elemzés eredményét

• Újrafelhasználható elemek azonosítása és az újrafelhasználás lehetőségeinek megvizsgálása

• Az alrendszerek magas szintű definíciója (rétegek és partíciók)– Általában két réteg: üzleti és alkalmazás réteg– Az alacsonyabb szintű felbontás az architektúrális

tervezés feladata– UML eszköz a modell felbontására: csomag

Architektúrális elemzés

• Egymástól egyértelműen elhatárolt rétegek:– üzleti logika réteg,– alkalmazási réteg,– adatbázis réteg stb.), – és a rétegekbe tartozó objektumokat.

Architektúrális elemzés - Csomag

• A rendszer építőelemeinek (osztályoknak, használati eseteknek, stb.) a magasabb szintű egységekbe való csoportosítása.

• Megadható:– Sztereotípia és jellemző (pl.: <<system>>)– Láthatóság

• Tesztelés egysége is lehet

Adattipusok

global

<<rendszer>>Alkalmazas

Reteg

<<modell>>UzletiReteg<<modell>>

Architektúrális elemzés - Függőség

• Két elem között függőség van, ha az egyik definíciójának megváltozása a másik (a függő) elem megváltozását is eredményezheti.

• Csomagok esetén: ha a függő csomag valamely eleme függ a másik csomag egy elemétől.

• A függőségeket célszerű minimálisra csökkenteni

AlkalmazasReteg

<<modell>>UzletiReteg<<modell>>

Architektúrális elemzés• Használati esetek megvalósításának létrehozása

– A használati esetek további elemzésének, tervezésének előkészítése.

– A használati eset modellben szereplő valamennyi használati esethez hozzunk létre egy használati eset megvalósítást (<<use case realization>>) a tervezési modellben (név ugyanaz.)

Use case realizáció

• Use case realization• Use case-ek megvalósítása.• Alap:

– Követelményspecifikációban elkészített use case modell.

• Use case-ek:– az elemzési, – tervezési modellben tovább elemzzük,

részletezzük.


• A use case egy lefutása a rendszeren belül.

• Az eseménykövetési (szekvencia) diagrammal modellezünk. A diagram: – a működéshez szükséges objektumokat– az objektumok közötti üzenetváltásokat, – azok időbeli sorrendjében. – Sequence Diagram.

Üzenetek

• A use case funkciója:– az üzeneteken keresztül teljesül.

• Az üzenetek:– eljárás vagy– függvény jellegűek, ez utóbbiak visszatérési

értékét is megadhatjuk. – Az üzenetek paraméterezhetők.


use case realization

use case use case realization

<<trace>>

Példa I.

ÁrajánlatKészít_Weben ÁrajánlatKészít_Weben realization

<<trace>>

Példa II.

• Konferencia felvétele Use Case realisation

Konferencia felvétele


(from Vezető-szervező use case-i)

Konferencia felvitele

Use Case realisation

A f elhasználó kiv álasztja a "Konf erencia f elv étele" f unkciót.

Rendszer ellenőrzi a f elhasználó jogosultságát.

Felhasználó megadja az új konf erencia adatait.

A rendszer elmenti az új konf erencia adatait.

Felhasználó bef ejezi az adatf elv ételt.

Rendszer ellenőrzi az adatokat és megerősítést kér a létrehozásra.

Szükséges adatok:- Cím, téma- Konf erencia röv id azonosítója - Főszerv ező nev eKiegészítő adatok:- Időpont,- Hely ,- Előadások, előadók-...

Használati esetek elemzése - Cél

• Azonosítani azokat az osztályokat, amelyek az adott használati eset végrehajtásában részt vesznek.

• A használati eset megvalósítások segítségével szétosztani a használati eset viselkedését az azonosított elemzési osztályok között.

• Meghatározni az osztályok felelősségeit, attribútumait és asszociációit.

Használati esetek elemzése - lépések

• A használati eset leírásának kiegészítése• Minden egyes használati eset megvalósításhoz:

– Keressük meg az elemzési osztályokat a használati eset által definiált viselkedés alapján

– Osszuk szét a viselkedést az osztályok között• Minden egyes elemzési osztályhoz:

– Írjuk le a felelősségeit– Az attribútumait és kapcsolatait– Adjuk meg az egyéb jellemzőit

• Egységesítsük az elemzési osztályokat

Használati eset leírásának kiegészítése - Példa

• A belső részleteket is tisztázni kell. Példa:– „Az ATM ellenőrzi a behelyezett kártya érvényességét”.– „Az ATM elküldi a központi rendszerbe a számlaszá-

mot, és a PIN kódot. A központi rendszer pozitív vá-laszt ad, ha a számlaszám és a kód egyezik, és az ügyfél jogosult tranzakciókat végezni, különben hibajelzést küld vissza.”

– Eredmény:• Ellenőrzéshez szükséges adatok (számlaszám, PIN) • Ki a felelős az ellenőrzésért (a központi rendszer, aki az ATM

szempontjából szereplő)• Két osztály-jelölt:

– az ügyfél, akinek van számlaszáma, és PIN kódja– egy interfész osztály, aki az ATM és a központi rendszer közötti

kommunikációért felelős

Egy megközelítés az elemzés elvégzésére

• Keressünk elemzési osztályokat és alkossunk elemzési modellt belőlük a feladat és a használati esetek leírása alapján!

(alulról felfelé)

• Valamilyen módon (interakciós diagramok) bizonyítsuk, hogy ez a modell szükséges és elégséges feltétele a feladat elvégzésének!

(felülről lefelé elemzés)

• A megrajzolt interakciós diagramok segítségével derítsük

fel az elemzési osztályok felelősségeit, biztosítva ezzel, hogy csak azt oldjuk meg, ami valóban a feladatunk.

Elemzési osztályok

• Az elemzési osztályok a rendszer fogalmi modelljét alkotják. „Dolgok, amivel a rendszernek foglalkozni kell.”

• Az UML-ben osztályok reprezentálják, amelyek sztereotípiája:– <<boundary>> - külső kapcsolat– <<entity>> - entitás, belső információ hordozó – <<control>> - vezérlő

Elemzési osztályok megkeresése

• Azonosítjuk,– Az üzleti modell vagy a használati esetek leírásaiban

aláhúzzuk a főneveket– Elemzési mintákat keresünk és azokat alkalmazzuk a

konkrét példára– Ez csak az <<entity>> és a <<control>> típusú

osztályokra működik és csak egy megoldási lehetőség

• elnevezzük– Ha nem lehet neki jó nevet adni, akkor talán nem is

létezik• és néhány mondattal leírjuk az elemzési

osztályokat.

<<boundary>> osztályok

• A rendszer és környezete közötti kommunikációért felelősek, gyakorlatilag valamilyen protokollt valósítanak meg.

• Típusok:– Felhasználói felület osztályai - rendszer és ember– Kommunikációs osztályok - rendszer és rendszer– Eszközök reprezentánsai - rendszer és külső eszköz

(pl.: szenzor)

DialogLoginDialogLogin<<boundary>>

Speciális protokoll - felhasználói felület

• Minden használati eset - szereplő párhoz van legalább egy.

• Képernyő vázlatot érdemes csinálni hozzáNem részletes tervezés, csak a fő funkciók látszódjanak (ami kell a folyamatok lefutásához).

• Az elemzés során a <<boundary>> osztály feladatára kell koncentrálni és nem a hogyanra.

<<entity>> osztályok• Információ-tárolás és kezelés• Alapfogalmak, amivel a rendszer foglalkozik• Az objektumok általában passzívak (nem

kezdeményeznek) és perzisztensek (a példányaik tárolásra kerülnek)

• Nézzük a fogalomszótárt az entitások keresésekor• Példa:

Customer

Customer<<entity>>

<<control>> osztályok

• A rendszer viselkedését koordinálják.• Egyes használati esetekhez felesleges - ha

nagyon egyszerű manipulációról van szó, akkor a boundary és az entity osztályok ezt önállóan elvégezhetik.

• Általában azonban egy vagy több vezérlő osztály tartozik egy használati esethez– tranzakció-kezelés– erőforrás-kiosztás– Hibakezelés.

<<control>> osztályok• A vezérlő osztályok hatékonyan választják el az

interfészeket és az entitásokat jobb változás-tűrés, újrafelhasználhatóság

• Vannak olyan feladat, amely nem lehet egyetlen entitás példány feladat sem, ezért ott a vezérlő osztályok létrehozása szükséges (példányok darabszámának meghatározása)

• Példa:

TransactionHand

ler

Architektúra az alkalmazás jellege alapján

• Az objektumok csoportosítása az MVC koordináta rendszer alapján– Model-View-Control– Smalltalk vezette be– Sztereotípus– Minden jól tervezett objektum valamelyik

koordináta fele húz.

MVC koordináta rendszer

• Koordináták:– Határ,– Entitás,– Control objektumok.

• Ez a gondolatmenet általánosítható alkalmazásokra, egy-egy alkalmazás olyan mint egy nagy objektum.

MVC koordináta rendszer• Határ:

– Felület dominenciájú alkalmazások:• Jellegzetes desktop alkalmazások, szövegszerkesztők, vizuális

felhasználói környezetek stb.

• Entitás:– Klasszikus információrendszerek– Fő feladatuk az adatkezelés

• Control– Algoritmus dominenciájú alkalmazások– Tudományos, műszaki számításokat végző alkalmazások– Az architektúrát az algoritmusok befolyásolják– Ritka a gyakorlatban.

Egy megközelítés az elemzés elvégzésére

• Keressünk elemzési osztályokat és alkossunk elemzési modellt belőlük a feladat és a használati esetek leírása alapján!

(alulról felfelé)

• Valamilyen módon (interakciós diagramok) bizonyítsuk, hogy ez a modell szükséges és elégséges feltétele a feladat elvégzésének!

(felülről lefelé elemzés)

• A megrajzolt interakciós diagramok segítségével derítsük

fel az elemzési osztályok felelősségeit, biztosítva ezzel, hogy csak azt oldjuk meg, ami valóban a feladatunk.

Viselkedés szétosztása az osztályok között - Interakciós diagramok

• Az objektumok együttműködésének a formáját írják le egy adott funkció megvalósítása érdekében.

• Hasonló információk különböző megjelenítési formái:– szekvencia diagram (sequence diagram): az

üzenetek explicit sorrendjét fejezi ki– együttműködési diagram (collaboration diagram): az

objektumok közötti kapcsolatok leírása• Az üzeneteket műveletek implementálják,

dolgozzák fel.

Szekvencia diagram

Szekvencia diagram

• Sequence diagram / Eseménykövetési diagram.• Az adott folyamat egy konkrét végrehajtását írja

le az objektumok közötti kommunikáción keresztül.

• Azt a célt szolgálják, hogy megértsük az objektumok együttműködésének módját, a rendszer működését.

• Minden használati esethez tartoznia kell legalább egy forgatókönyvnek, hiszen minden folyamatnak legalább egy módon le kell zajlani.

Szekvencia diagram

• Az objektumokat (nem osztályokat) függőleges vonalak reprezentálják.

• A vonal akkor kezdődik, amikor az objektum létrejön és akkor fejeződik be, amikor az objektum megszűnik.

• Az események, üzenetek vízszintes címkézett nyilak az objektumok között.

• Az idő fentről lefelé halad.

Hívókagyló felemelése

HívottTelefonvonal

1 tárcsázása

8 tárcsázása9 tárcsázása

tárcsahang

csöngetési hang

csöngetési hang végekagyló felemelése

tárcsahang vége

csöngetés vége

csöngetés

Idő

Példa - hívjuk fel a tudakozót

Szekvencia diagram

• Alapvetően egy lefutás érzékletes ábrázolására lehet használni. Nem az algoritmusok ábrázolására szolgál, hiszen nincs benne igazi elágazás. (Erre a célra az aktivitás diagram használható).

• Jól ábrázolhatóak a tesztelés esetei a segítségével.

• Meg lehet érteni egy komponens vagy egy kész rendszer adott működését (log állomány szekvencia diagram).

Szekvencia diagram

• Időpont megjelölés: – Jelezni lehet azt az időpontot, amikor egy üzenet

elindul vagy megérkezik– Az időpontot jelölő szimbólumokat időzítési

feltételekben lehet használni– (A szabvány szerint az üzenetnek lehet rövid nevet

adni és ezt lehet meghivatkozni az időzítésre vonatkozó megszorításokban, például msg.sendTime(), msg.receiveTime() stb... )

Szekvencia diagram - Időzítés

Hívó

a : kagyló felemelése

Telefonvonal

c : 1 tárcsázása

b : tárcsahang

{b.sendTime()- a.receiveTime() < 1 sec}{c.sendTime() - b.receiveTime() < 10 sec}

Időzítési feltétel

Együttműködési diagram


• Collaboration diagram / Kollaborációs diagram.• Az üzenetek áramlásának egy másfajta ábrázolása, bár

a kifejező képessége nem különbözik a szekvencia diagramtól, az UML egyre inkább hangsúlyozza a szerepét

• Objektumokat és kapcsolatokat tartalmaz. Ezek:– vagy a művelet előtt is léteztek– vagy a művelet során keletkeznek esetleg szűnnek meg

• Ha sok objektum kevés üzenettel kommunikál, akkor áttekinthetőbb lehet, mint a szekvencia diagram

Együttműködési diagram elemei I.

• Az együttműködésben objektumok vesznek részt.

• Objektum speciális előfordulási formái a diagramon:– Multiple instance

• Egy-több kapcsolat több oldalán álló objektumokat jelképezi– Active object

• Az objektum saját szállal rendelkezik és önállóan képes a működésre

• Az objektumba írható szöveg: „objektum neve” / „minősítő szerepkör” : „minősítő”[‘.’ „minősítő”]*

Együttműködési diagram elemei II.

• Üzenetek:– címkézett vonal, a szöveghez rendelt nyíl jelzi az

üzenet irányát– több üzenet is tartozhat ugyanahhoz a kapcsolathoz.

• A nyilak alakja fontos jelentéssel bír (UML 1.3):– Eljárás hívás, beágyazott hívás– Egyszerű szekvencia, általában aszinkron – Aszinkron végrehajtás– Eljárás visszatérése


Hívó Telefonvonal

Hívott

5: 9 tárcsázása1: kagyló felemelése3: 1 tárcsázása6: 8 tárcsázása

9: kagyló felemelése

2: tárcsahang4: tárcsahang vége7: csöngetési hang10: csöngetési hang vége

8: csöngetés

11: csöngetés vége


Egyéb elemek az üzenet-címkén• Sorszám (sequence number) - az üzenetek

egymásutániságát hivatott jelezni Az egymásba ágyazott eljáráshívásokat a ponttal elválasztott sorszámok jelölik– [2.1.4] a [2.1] üzenet által hívott eljárás része, a

[2.1.3] üzenet után következik– a párhuzamos szálakat betűvel jelöljük. [1.2a] és

[1.2b] konkurensen hajtódik végre


Egyéb elemek az üzenet-címkén• Sorszám

– az iterációt *-gal jelöljük (*[feltétel]). Jelentése: ugyanolyan formájú üzenet többször megy el

– feltétel is megfogalmazható ( [feltétel])• Az üzeneteknek lehet paraméterlistája• A visszatérési érték a speciális üzenet neve


• Az egymástól vesszővel elválasztott sorszámok listája ([sorszám, sorszám]) azt jelzi, hogy párhuzamos végrehajtás esetén az üzenet mely üzenetek után következhet. (Szálak szinkronizálása)

Hívó Telefonvonal

Hívott

5*[i:=9..8]: tárcsáz(i)1: kagyló felemelése3: 1 tárcsázása

7: kagyló felemelése

2: tárcsahang4: tárcsahang vége6a: csöngetési hang8a: csöngetési hang vége

6b: csöngetés

8b: csöngetés vége


Viselkedés elosztása az osztályok között

• Vegyük a használati eset leírását és formalizáljuk valamelyik interakciós diagrammal (szekvencia vagy együttműködési)

• Minden használati esethez legalább egy diagram, de pontosabb, ha folyamatonként egy diagram

• Használjuk a korábban megtalált elemzési osztályokat

Példa - IQTAR Tanfolyami jelentkezés

: Jelentkezõ

: DlgLogin : Ugyfel : FrmJelentkezes

: Tanfolyam UML : Tanfolyam UML19990301 : Tanfolyami

Regisztracio : JelentkezesVezerles

Beír "név", "jelszó"

Megnyomja "OK"

Kiválaszt "UML"

Kiválaszt "1999.03.01"

Jóváhagy

Megjelenít"Regisztráció"

Keres ügyfelet

ügyfél-keresés

Megjelenít

TanfolyamLista

IdõpontLista

Létrehoz

Tanfolyam-lista megjelenítése

Idõpont lista megjelenítése

Van szabad hely?

Mintapélda - KonfMan

KonfMan • Használati esetek

megvalósításának létrehozása– A használati esetek további

elemzésének, tervezésének előkészítése.

– A használati eset modellben szereplő valamennyi használati esethez hozzunk létre egy használati eset megvalósítást (<<use case realization>>) a tervezési modellben (név ugyanaz.)



(from Vezető-szervező use case-i)

Béla : Vezető-szerv ező

: Fablak : AlkalmazsVezrl : FelhasználóKezelő

: Konf erenciaFelv itel

: Konf erenciaKezelő

: Konf erencia

1: "Konf erencia f elv étele" opció v álasztása

2: "Béla" f elhasználó jogosultság lekérdezése

3: "Béla"-hoz tartozó jogosultságok lekérdezése( )

4: Béla jogosultságai

5: jogosultság összev etése

6: létrehozás

7: adatok megadása

8: bev itel bef ejezése

9: adatok ellenőrzése

10: rendben!

11: Létrehozhatom?

12: Igen!

13: Hozz létre egy új konf erenciát a megadott adatokkal

15: OK

16: Minden OK, a konf erenciát léterehoztam!

14: létrehozás

Kötelező:- Konf erencia címe- Főszerv ező- Konf erencia témája

Opcionális:- Hely e- Ideje- ...

Béla : Vezető-szervező

: KonferenciaFelvitel

: AlkalmazsVezrl

: FelhasználóKezelő

: KonferenciaKezelő

: Konferencia

5: jogosultság összevetése

: Fablak

1: "Konferencia felvétele" opció választása

7: adatok megadása8: bevitel befejezése

12: Igen!

11: Létrehozhatom?16: Minden OK, a konferenciát léterehoztam!


13: Hozz létre egy új konferenciát a megadott adatok...10: rendben!

15: OK

2: "Béla" felhasználó jogosultság lekérdezése



6: létrehozás

14: létrehozás

FelhasználóKezelő

"Béla"-hoz tartozó jogosultságok lekérdezése()

(from Alkalmazás Réteg)

Fablak

aktuálisFelhasználóAzonosítója(from Üzleti Réteg)

AlkalmazsVezrl

(from Üzleti Réteg)1

1

Konferencia

CímFőszervezőRövid_név


KonferenciaKezelő


0..*

1

0..*

KonferenciaFelvitel

FőszervezőCím

Rövid_név

(from Üzleti Réteg)

1

1

0..1

1

0..1

1 1

1

1

1

1

Béla : Vezető-szervező

: KonferenciaFelvitel

: AlkalmazsVezrl

: FelhasználóKezelő

: KonferenciaKezelő

: Konferencia

5: jogosultság összevetése

: Fablak

1: "Konferencia felvétele" opció választása

7: adatok megadása8: bevitel befejezése

12: Igen!

11: Létrehozhatom?16: Minden OK, a konferenciát léterehoztam!


13: Hozz létre egy új konferenciát a megadott adatok...10: rendben!

15: OK

2: "Béla" felhasználó jogosultság lekérdezése



6: létrehozás

14: létrehozás

FelhasználóKezelő

"Béla"-hoz tartozó jogosultságok lekérdezése()


Fablak

aktuálisFelhasználóAzonosítója(from Üzleti Réteg)

AlkalmazsVezrl

(from Üzleti Réteg)1

1

Konferencia

CímFőszervezőRövid_név


KonferenciaKezelő


0..*

1

0..*

KonferenciaFelvitel

FőszervezőCím

Rövid_név

(from Üzleti Réteg)

1

1

0..1

1

0..1

1 1

1

1

1

1

Mintapélda – SWE Product

Use Case realizáció

ÁrajánlatKészít_Weben ÁrajánlatKészít_Weben realization

<<trace>>

Aktivitási diagram

Az Ügyfél a Kft. honlapján aktiválja az "Árajánlat készítés" funkciót.

A rendszer megjeleníti a Login dialógusablakot, ahol kéri az Ügyfél felhasználói nevét, és jelszavát.

Az Ügyfél megadja a felhasználói nevét, és jelszavát.

A rendszer ellenőrzi, validálja a megadott adatokat.

A rendszer megjeleníti az "Árajánlat készítés" felületet.

Az Ügyfél megadja a kért adatokat.

A rendszer validálja a megadott adatok helyességét, ellenőrzi az adatok konzisztenciáját.

A rendszer elmenti az Árajánlat adatait.

A rendszer nyugtázó üzenetet küld az Ügyfélnek a képernyőn az Árajánlat készítésének sikerességéről.

A rendszer megerősítést kér az Ügyféltől az Árajánlat elfogadására.

[ Árajánlat rendben! ]

[ Árajánlat Elutasítva! ]

[ Hibás adatok! ][ Adatok rendben! ]

[ Adatok rendben! ][ Hibás adatok! ]

Szekvencia diagram az elemzési szakaszban

: ÜgyfélFőablak AlkalmazásVezérlő LoginDialog Ablak ÜgyfélTörzsadat

Árajánlat Készítés Ablak

ÁrajánlatKezelő

Árajánlat

"Az Árajánlat készítés" funkció választása

JogosultsagLekerdezes( )

megjelenít( )

"Felhasználói név" és "Jelszó" beírása

OK gomb megnyomása

ügyfelKereses( )

megjelenit( )

Adatok megadása

OK gomb megnyomása

adatokEllenorzese( )

Elfogadja az Árajánlatot?

Elfogad gomb megnyomása

Létrehozás

create( )

Az Ön által készített Árajánlat létrehozva!

Szekvencia diagram a tervezési szakaszban

Szekvencia diagram

• Elemzési modellben:– a use case egy részletes lefutását írja le.

• Nagyvonalakban definiált szoftverarchitektúra.

• Alapja:– A tervezési szakaszban: a végleges

szoftverarchitektúra.

Használati esetek elemzése / Elemzési osztályok felelősségei

• Felelősség (responsibility): szolgáltatás, ami az objektumtól kérhető.– Az elemzés során a műveletek ábrázolják az

elemzési osztályok felelősségeit– Jellemzően:

• Valamilyen tevékenység, amit az objektum végez• Valamilyen tudás, amit az objektum kezel, és felajánl

más objektumoknak– Amennyiben az elemzési osztály egy komplex

részrendszert takar (szimulációs rendszer - szimulációs motor), az felelősség a részrendszer szempontjából a használati esetek szerepét tölti be

Műveletek• Tevékenység, amelyet az osztály végre tud hajtani. • Művelet megvalósítása a metódus (módszer).• Egy osztály minden konkrét objektuma azonos

műveletekkel rendelkezik. • Minden művelet implicit argumentumként "ismeri" az

objektumát, el tudja érni annak attribútumait és műveleteit.

• UML szintaktika:– láthatóság név(paraméterek):típus {jellemzők}– paraméterek :- {in,out,inout} név:típus=alapértelmezett

Műveletek csoportosítása• Lekérdezés (query): mindössze értékeket kér le

– nem változtatja a megfigyelhető állapotot (observable state)

– tetszőleges sorrendben végrehajthatók• Módosító (modifier)

– Végrehajtása után van olyan művelet, amelynek a végrehajtása nem ugyan azzal az eredménnyel jár, mint előtte. Ez tehát a megfigyelhető állapotot módosítja. Ezek végrehajtási sorrendje nem közömbös és ha tranzakció kezelésre kerül a sor, akkor ezekre kell figyelni.

Láthatóság

• Láthatóság– + (public) nyilvános– - (private) saját– # (protected) védett– Az implementation és a protected is nyelvfüggő

módon értelmezett• Jellemzőként is megadható, pl.: {public}. • Nyelvfüggő módon értelmezik, azonban a

nyilvános felelősségek a teljes alkalmazásból elérhetők, ha az osztály is elérhető

Elemzési osztályok felelősségei

• Szolgáltatások felfedezése:– Az interakciós diagramok üzeneteiből. Vizsgáljuk meg az

üzeneteket, és döntsük el, hogy a címzettnek van-e már olyan szolgáltatása, ami ehhez az üzenethez kell.

– Nem-funkcionális követelményeket figyelembe kell venni! (Bővítsük a leírást a nem-funkcionális követelményben előírtaknak megfelelően, vagy definiáljunk új szolgáltatást, ami segíti a kielégítését.)

• Dokumentálás:– Rövid név– Rövid leírás: mit csinál az objektum a szolgáltatás végrehajtása

érdekében, és mit ad vissza


: Jelentkezõ


: Tanfolyam UML : Tanfolyam UML19990301 : TanfolyamiIdopont

Regisztracio : Regisztracio

: JelentkezesVezerles


Megnyomja "OK"

Kiválaszt "UML"


Jóváhagy

megjelenít( )"Regisztráció"

ugyfelKereses("név", "jelszó")

megjelenít( )

tanfolyamLista( )

idopontLista( )

letrehoz( )

kiirTanfolyamLista( )

kiirIdopontLista( )

Van ilyen ügyfél

vanSzabadhely( )

Példa - IQTAR

• tanfolyamLista– Visszaadja az összes tanfolyam listáját

• idopontLista– Visszaadja az adott tanfolyamhoz tartozó

időpontok listáját

Tanfolyam

tanfolyamLista()idopontLista()

<<entity>>


: Jelentkezõ

: DlgLogin : Ugyfel

: FrmJelentkezes

: Tanfolyam

UML : Tanfolyam

UML19990301 : TanfolyamiIdopont


1: "Regisztráció"

2: megjelenít( )

3: Beír "név", "jelszó"4: Megnyomja "OK"

5: ugyfelKereses("név", "jelszó")

6: megjelenít( ) 7: tanfolyamLista( )8: kiirTanfolyamLista( )

9: Kiválaszt "UML"

10: idopontLista( )

11: kiirIdopontLista( )

12: Kiválaszt "1999.03.01"

13: vanSzabadhely( )

14: Jóváhagy


15: letrehoz( )

Használati esetek elemzése / Attribútumok és asszociációk leírása

Attribútum

• Attribútumok: információkat tárolnak– Az értékük az, ami fontos, azaz objektum egy

tulajdonságát tartalmazzák valamilyen szempontból– Az objektum kizárólagos tulajdonában vannak (azaz

nem hivatkozik rájuk más objektum)– Get/set műveletek és egyszerű transzformációk

végezhetők rajtuk, nincs valódi viselkedésük

Attribútum

• Attribútum-érték az attribútum egy konkrét előfordulása, egy adott pillanatban felvett állapot, az objektumpéldányban tárolt elemi adat.

• Specifikációja:[láthatóság] név [: típus] [= kezdeti érték]

[{jelleg}]

Attribútum

• Az attribútum neve mindig főnév és az attribútum által hordozott információtartalomra utal– Rövid leírás: csak abban az esetben

hagyható el, ha az attribútum neve minden kétséget kizár

• Az attribútum típusa: egyszerű adattípus az elemzés során(összeg cím)

Attribútumok• Az UML szintaktikája:

láthatóság név: típus = kezdetiÉrték {jellemzők}– az attribútum-név elnevezi a szempontot, – az attribútum típusa megadja a lehetséges értékeket.– a kezdeti érték az objektum készítésekor beállítandó értéket jelenti.– az attribútum-érték megadja, hogy az objektum milyen az adott

szempontból

Tanfolyam- tematika: string- megnevezes: string- idotartam: integer

<<entity>> a Tanfolyam osztály objektumainak van tematikája,• az objektum meg tudja mondani a tematikáját, illetve az

beállítható,• implementáció: az objektumnak van egy tematika

mezője.

Példa

Ugyfel- nev : string- lakcim : cim- felhasznaloiNev : string- jelszo : kodoltString

+ ugyfelKereses()

<<entity>>TanfolyamiIdopont

- kezdet : date- veg : date- hely : string

+ vanSzabadhely()

<<entity>>Tanfolyam

- megnevezes : string- idotartam : integer- tematika : string

+ tanfolyamLista()+ idopontLista()

<<entity>>

Láthatóság

• Az objektum különböző tulajdonságai, metódusai mennyire fedhetők fel a külvilág számára. Az UML az osztályjellemzőkhöz (attribútum, művelet) három láthatósági szintet javasol:– a + public– a – private– a # protected

Láthatóság• +: a jellemző interfészen keresztül

tetszőlegesen minden osztály által elérhető, nincs szükség metódusra az eléréséhez,

• - : csak az osztály látja, csak saját objektumon belül látszik.

• # : a jellemző csak saját objektumból és az utódokból látszik, csak az adott osztályon érhető el, a gyermek (leszármazott) és a barát (friend) osztályok látják – Egy osztálynak barátja (friend) egy olyan

metódus vagy akár teljes osztály, amely hozzáférhet az adott osztály minden – ill. deklarációtól függően néhány – mezőjéhez és metódusához.

Attribútum

• A típus egyszerű adattípusokat jelent. • A kezdeti érték az objektum készítésekor

beállítandó értéket jelenti.

Attribútum

• Az attribútumok meghatározásakor figyelmesen kell eljárni, mert egyes adatok az elemzés/tervezés későbbi szakaszaiban maguk is objektumoknak minősülhetnek (pl. lakcím vagy dátum).

• Az ilyen attribútumok számára a modellben külön osztályt kell definiálni.

Attribútum

• Az attribútumok tekinthetők kicsi, egyszerű és korlátozott funkcionalitású osztályokként.

• Az objektumot egyedi módon azonosító objektum-azonosítót (OID) nem szabad attribútumként felvenni, mivel az a megvalósításhoz kapcsolódik.

• Az osztály és az attribútum nem áll messze egymástól

• Az osztály szintű attribútumot aláhúzással jelöli az UML (A Rose-ban $ jel jelöli)

Műveletek

• Az osztály által nyújtott szolgáltatás.• Feladat, tevékenység, amit az osztály

végre tud hajtani.• Az osztályok által nyújtott szolgáltatásokat

elsősorban eseménykövetési diagramok üzenetei alapján azonosítjuk.

Példa - Tanfolyami jelentkezés

: Jelentkezõ


: Tanfolyam UML : Tanfolyam UML19990301 : TanfolyamiIdopont




Megnyomja "OK"

Kiválaszt "UML"


Jóváhagy

megjelenít( )"Regisztráció"

ugyfelKereses("név", "jelszó")

megjelenít( )

tanfolyamLista( )

idopontLista( )

letrehoz( )

kiirTanfolyamLista( )

kiirIdopontLista( )

Van ilyen ügyfél

vanSzabadhely( )

Példa - IQTAR

• tanfolyamLista– Visszaadja az összes tanfolyam listáját

• idopontLista– Visszaadja az adott tanfolyamhoz tartozó

időpontok listáját

Tanfolyam

tanfolyamLista()idopontLista()

<<entity>>

Példa

Ugyfel- nev : string- lakcim : cim- felhasznaloiNev : string- jelszo : kodoltString

+ ugyfelKereses()

<<entity>>TanfolyamiIdopont

- kezdet : date- veg : date- hely : string

+ vanSzabadhely()

<<entity>>Tanfolyam

- megnevezes : string- idotartam : integer- tematika : string

+ tanfolyamLista()+ idopontLista()

<<entity>>

Műveletek

• A művelet megvalósítása a metódus. • Egy osztály minden konkrét objektuma

azonos műveletekkel rendelkezik. • A metódusok segítségével végzünk

műveleteket a tulajdonságokon, ill. módosíthatjuk azokat.

Műveletek

• Minden művelet implicit argumentumként "ismeri" az objektumát, el tudja érni annak attribútumait és műveleteit.

• UML szintaktika:– láthatóság név(paraméterek):típus {jellemzők}– paraméterek :- {in,out,inout}

név:típus=alapértelmezett

Műveletek csoportosítása• Lekérdezés (query): mindössze értékeket kér le

– nem változtatja a megfigyelhető állapotot (observable state)

– tetszőleges sorrendben végrehajthatók• Módosító (modifier)

– Végrehajtása után van olyan művelet, amelynek a végrehajtása nem ugyan azzal az eredménnyel jár, mint előtte. Ez tehát a megfigyelhető állapotot módosítja.

– Ezek végrehajtási sorrendje nem közömbös és ha tranzakció kezelésre kerül a sor, akkor ezekre kell figyelni.

Láthatóság

• Láthatóság– + (public) nyilvános– - (private) saját– # (protected) védett– Az implementation és a protected is nyelvfüggő

módon értelmezett• Jellemzőként is megadható, pl.: {public}. • Nyelvfüggő módon értelmezik, azonban a

nyilvános felelősségek a teljes alkalmazásból elérhetők, ha az osztály is elérhető

Osztályok közötti asszociációk

Osztályok közötti asszociációk

• Az osztályok szolgáltatásaikat rendszerint csak más osztályokkal együttműködve tudják biztosítani - kapcsolatnak kell lenni közöttük

• Formák:– Egy objektum lehet globális, és akkor a rendszer bármely

osztálya küldhet üzenetet neki– Egy objektumot paraméterként át lehet adni és így egy

objektum tud üzenetet küldeni a paraméterként kapott objektumnak

– Egy objektumnak állandó kapcsolata lehet, egy másikkal, amelyiknek üzenetet küld - asszociáció

• Nem az elemzés során kell dönteni, hogy valóban asszociáció lesz-e, de itt azt használjuk!

Asszociáció

• Az osztályok objektumai közötti kapcsolat leírása, absztrakciója.

• Az asszociációt, mint viszonyt megtestesítő fogalmat az osztályok közötti viszonyokra értjük.

• A kapcsolat fogalmat az objektumok közötti viszonyra értelmezzük

Asszociációk leírása

• Térjünk vissza a Használati esetek elemzése / Elemzési osztályok felelősségei lépésben definiált interakciós diagramokhoz (együttműködési diagram)

• Ha két objektum között kapcsolat van, az azt jelzi, hogy az osztályaik között asszociációnak kell lennie.

• Az együttműködési diagram még kifejezőbb, hiszen ott az objektum kapcsolat egyből megmutatja az asszociációkat.

Asszociációk (association)

• Általában bináris (a magasabb fokú asszociációk általában felbonthatók binárisokra, bár ekkor részben elveszíti a mondanivalóját)

• Az asszociáció nagyon sok szabály és megkötés kifejezésére alkalmas, de mindenre nem OCL

Asszociációk (association)

• Két osztály vagy osztályok közötti kapcsolatot a két osztályt összekötő vonal reprezentálja.

• Az asszociációhoz név rendelhető: a nevet az osztályokat összekötő vonal fölé, középre helyezve írjuk.

Szerep - roles• Megadhatjuk az osztályoknak az asszociációban

játszott szerepét.• Minden kapcsolathoz két szerep rendelhető,

melyek az asszociáció két végén levő osztályoknak az adott asszociációban betöltött szerepére vonatkoznak.

• A szerepek definiálásával párhuzamosan általában megadjuk a kapcsolat (asszociáció) irányát.

• A szerepeknek az osztályokhoz rendelése az attribútumokhoz hasonló funkciót töltenek be

Multiplicitás

• Hány objektum vehet részt az asszociációban.• Multiplicitás

– az egyik osztály egy objektumához a másik osztályból hány objektum tartozik, vagyis kifejezi, hogy az osztályok objektumai milyen számosságban kapcsolódnak egymáshoz.

• Kardinalitás, a számosság fogalma. – Megadja az adott osztályban specifikálható

előfordulások minimális, illetve maximális számát.

Multiplicitás jelölése UML-ben• 1: az adott osztály egy objektumához a másik osztályból

pontosan egy objektum kapcsolódik• 0..1: 0 vagy 1 objektum kapcsolódik, opcionális

kapcsolat• 0..*: opcionális többes kapcsolat• 1..*: 1 vagy többes kapcsolódás, kötelező többes

kapcsolat• 22.. 44: egy objektumhoz [22,44] zárt intervallumnak

megfelelő számú objektum kapcsolódhat• 9: ebben az esetben pontosan 9 objektum kapcsolódik a

megjelölt osztály egy objektumához• 2 és 13 értékeken kívül bármilyen számosság

lehetséges: a számosság akár szövegesen is megadható.

Navigálhatóság iránya

• Az asszociáció bejárhatóságának iránya.• A kapcsolatok mentén kommunikáció zajlik,

amely lehet egy vagy kétirányú. A kommunikáció irányának jelölésére az osztályokat összekötő vonalra nyilat helyezünk.

• Megadja, hogy az asszociációval összekötött osztályok közül melyik kezdeményezi a kommunikációt, melyik osztály objektumainak kell ismernie a másik osztály objektumait.

Megszorítás

• Constraint: – korlátozás, ami az egyes modellelemek között

definiált asszociációs viszony finomítására szolgál. Klasszikus példa a megszorításra, amikor azt akarjuk hangsúlyozni, hogy az asszociációban az egyik objektummal kapcsolatban levő objektumok rendezve legyenek elérhetőek, láthatóak. A megszorítások a modellben kapcsos zárójelek {} között szerepelnek.

Megszorítás

• Megszorítások megfogalmazására az UML specifikáció részét képező OCL (Object Constraint Language) nyelv ad lehetőséget.

• Az OCL segítségével további szemantikai értelmezéssel lehet finomítani a modellt.

OrdinaryCustomerdateOfLastPurchase

KeyAccountCustomerpercentOfDiscountcontactName

Customername : Stringaddress : String

Order/ totaldateReceived

close()

StoragestoragePlacestoredQuantity

OrderLinequantity : Integer/ subtotal

11..* 1

+line items

1..*ProductCatalog

ProductsumValuenamepriceproductId

create()

0..*

1

0..*

1

productId1

1

1productId

1

contains

Store 0..*1..* 0..*1..* stores

{ordered}

A kapcsolatok implementálása

A konceptuális modell

• Csak a lényegi elemekre, az elemek közötti kapcsolatok leírására koncentrál.

• A diagramban ábrázolhatjuk a kapcsolat fokát, megadhatjuk az asszociáció nevét és különféle asszociációs viszonyokat ábrázolhatunk



Customername : Stringaddress : String


create()

{ordered}

Order/ totaldateReceived

close()

1

0..*

1

0..*

OrderLinequantity : Integer/ subtotal

0..*

1

0..*

1

1..* 11..* 1+line items

A specifikációs szintű modell

• Csak felelősségeket definiál, de nem kód szinten: egy Order-nek lesz olyan felelőssége, hogy megmondja melyik Customer-hez tartozik.

• A modell azt fejezi ki, hogy egy Order-nek az a felelőssége, hogy megmondja pontosan melyik egyedi azonosítójú Customer tartozik hozzá.

class Order{

public Customer customer(); public Enumeration orderLines(); //Az

Order osztálytól lekérdezhetők hozzátartozó orderLine-ok.

}

Implementációs modell

• Már a felelősségek pontos megvalósítását is definiáljuk.

• Az implementációs osztály-diagramban azt írjuk le, hogy minden Order típusú objektum tartalmaz egy pointert, amelyik pontosan egy adott Customer objektumra mutat.

Az Order osztály definíciója

class Order // Az Order osztály definíciója{public:

Order();virtual ~Order();long lPrice;long lNumber;Customer* m_pTheCustomerOfTheOrder;Customer* getTheCustomerOfTheOrder();

};

A getTheCustomerOfTheOrder() függvény megvalósítása

Customer* Order::getTheCustomerOfTheOrder()

{return m_pTheCustomerOfTheOrder;

};

Példa - asszociációkra

Cég SzemélyAlkalmazás

munkaadó munkavállaló

Asszociáció neve

Szerepkör Szerepkör

Példa - asszociációkra

Cég SzemélyAlkalmazás

munkaadó munkavállaló* *

Csúcspont Poligon

10..n0..n 1

{ordered}

Az öröklődés

• A modellelemek (use case-ek, osztályok) között értelmezett sajátos viszony.

• A modellelem sajátjaként kezeli a nála általánosabb szinten definiált modellelem jellemzőit (a modellelemek jellemzőihez beállított láthatóság alapján).

• Az utód osztály (leszármazott) sajátjaként kezeli a nála általánosabb/magasabb szinten levő osztály (ős osztály) attribútumait és műveleteit.

Öröklődési viszony UML-ben

• Az öröklődés jele egy üres háromszögben végződő nyíl, a háromszög csúcsa az ős osztálynál található.

ŐsOsztály

LeszármazottOsztály2LeszármazottOsztály1

Öröklődési viszonyok

• Öröklődési viszony:– Általánosítás (generalizáció – generalization)– Specializáció (pontosítás – specialization)

Általánosítás• A különböző objektumok sokszor tartalmaznak

közös jellemzőket (adatok, műveletek). • Az általánosítás az a folyamat, amikor ezeket a

közös jellemzőket kiemeljük egy ős osztályba (alulról-felfelé).

• Eredményként létrejön:– egy általános/közös sajátosságokat tartalmazó ős

vagy szülő osztály, amelyhez tartozik – egy vagy több speciális tulajdonságokkal rendelkező

al vagy gyerek osztály.• Használatának célja a kód újrafelhasználási

fokának emelése a rendszerben.

Általánosítás

• Az ős osztály általában absztrakt osztály.– Osztály, aminek nincsenek példányai.

• Az ős osztály szerepe:– csak a közös sajátosságok egy helyen történő

tárolása, segítségével jelentősen egyszerűsödik a modellünk felépítése.

Általánosítás - példa

KeyAccountCustomerpercentOfDiscountaddressnamecontactName

OrdinaryCustomernameaddressdateOfLastPurchase

Általánosítás - példa



Customernameaddress

Absztrakt

Specializáció

• Meglevő osztályokból származtatott osztályokat képezünk finomítással (fentről-lefelé).

• A finomítás célja – az osztályok specifikációjának pontosítása, az

objektumok egyedi jellegének megerősítése az egyedi jellegre utaló jellemzők definiálásával.

Specializáció

• A származtatott osztályok keresése során feltételezzük, hogy az osztályok általánosak (gyűjtőfogalmat jelenítenek meg).

• A specializáció során azt vizsgáljuk, hogy újabb attribútumok és műveletek hozzáadásával milyen, a feladat szempontjából értelmes osztályok határozhatók meg.

• Az attribútumokat és az asszociációkat mindig a legáltalánosabb osztályhoz rendeljük. – A ős osztály nem feltétlenül absztrakt.

Specializáció - Példa

PaymentpaymentDatetotal

CashPaymentcashVoucher

WireTransferindexNumberOfMoneyCirculation

Öröklődési hierarchia

• Öröklődési lánc.• A hierarchiában azokat az osztályokat, amik

nem örökölnek másoktól sajátosságokat – vagyis nincsenek szüleik – gyökér osztály. – a {root} megszorítással jelöljük

• Az öröklődési lánc legalsó szintjén – vagyis nem örökítenek tovább jellemzőket – levél (leaf) osztályok.– {leaf} megszorítás az osztály neve alá vagy

megjegyzésbe kerül.

Öröklődési hierarchia

GyökérOsztály

LeszármazottKöztesOsztály

LevélOsztály

{root} megszorítás

{leaf} megszorítás

Az öröklési viszony

• egyszeres: egy osztálynak csak egy őse lehet.

• többszörös: a kapcsolatban egy osztálynak több szülője is lehet.

• többszintű: egy osztálynak legalább egy őse és több leszármazottja van. Ez az osztály az öröklődési lánc köztes szintjén helyezkedik el.

Speciális fogalmak, asszociációs viszonyok

• Aggregáció – kompozíció• Minősített asszociáció

Aggregáció

• Egy objektum több másik objektumból épül fel, vagyis egy objektum egy vagy több másik objektumot tartalmaz.

• Az UML lehetőséget ad összetett objektumok definiálására és kezelésére, aminek eredményeként az osztályok között ún. rész-egész viszony jön létre.

• A rész-egész viszony formái:– Aggregáció– kompozíció

Aggregáció

• Más UML szimbólum az aggregáció és a kompozíció jelölésére.

• Az aggregációt egy rombusz, a kompozíciót egy sötétített rombusz szimbolizálja,

• a rombuszok a tartalmazó osztály felöli oldalon helyezkednek el.

Aggregáció

• Aggregation: a rész-egész viszony gyengébb formája.

• A tároló objektum (az egész osztály) és az azt felépítő részobjektumok (részelemek) elkülönülnek.

• A részoldal nem értelmes az egész nélkül. – Abban az esetben, amikor az osztály a másik

oldal nélkül is értelmes, akkor a két modellelem között egyszerű asszociációs viszony van.

Aggregáció

Customernameaddress

Addresscountycitydistrictstreetfloordoor

Kompozíció• Composition: a rész-egész viszony

erősebb változata. • A tároló objektum a részobjektumokat is

fizikailag tartalmazza – együtt keletkeznek és szűnnek meg, vagyis

az egész megszűntével a rész is megszűnik. – Az egész oldal számossága csak 1 lehet.

Kompozíció

Minősített asszociáció

• Két osztály között asszociációs viszony áll fenn és az egyik osztály egy tulajdonságot, attribútumot (minősítő - qualifier) használ fel kulcs gyanánt az asszociáció másik oldalán levő objektumok elérésére, azonosítására.

• Azt az osztályt, amelyik a másik osztály objektumait akarja a minősítő attribútum felhasználásával elérni, célosztály,

• a kapcsolatban részt vevő másik osztályelemet forrásosztály.


• A rendszer működése során a meghatározott minősítő attribútumok (kulcsértékek) alapján kérdezhetők le az egyes elemek.

• Implementációs szinten a minősített asszociáció rendszerint a célosztály objektumaiból képzett indexelhető tömb, vagy valamilyen más, kulcs szerinti keresésre alkalmas összetett adatstruktúra (pl. hashtábla) megjelenését eredményezi a forrásosztályban.



ProductCatalog11..* 11..* contains


• A Product osztály productID attribútuma kulcsjellemzőként, ún. minősítőként szolgál a ProductCatalog számára.

Product ProductCatalogproductId11 11 contains

productId

Asszociációs osztály

• Két osztály közötti kapcsolat jellemzésére, ill. annak létrejöttéhez önálló tulajdonságok, esetleg metódusok tartoznak.

• Alkalmazása:– két osztály elemei között több-több jellegű

leképezést akarunk megvalósítani, de az egymáshoz rendelt párokhoz, ill. az asszociációval jelzett kapcsolat létrejöttéhez még további információkat is hozzá akarunk rendelni, amelyek igazából egyik osztályhoz sem tartoznak kizárólagos módon.


• Az UML-ben az asszociációs osztályt és a kapcsolatot szaggatott vonal köti össze.

• Főként az elemzési fázisban.• A tervezési és az implementációs

modellben ezek az osztályok normál osztályokká szerveződnek


Store

StoragestoragePlacestoredQuantity

Product 1..*0..* 1..*0..* stores

Származtatott elemek

• Elemek, amelyek más, már a modellben definiált elemekből származnak, azokból számítódnak.

• A származtatásra leggyakrabban az attribútumoknál és az asszociációknál lehet szükség.

• A számított tulajdonságokat a tulajdonság neve előtt megjelenő per (/) jellel jelöljük.

• A számításhoz használt kifejezést kényszerként (megszorítás) kapcsos zárójelek {} között megadva írhatjuk le.

Származtatott elemek

Sztereotípia

• A modellelemek tipizálása, minősítésre szolgál.

• Sztereotípia megadása:– karaktersorának francia zárójelek közé

tételével vagy – szimbólummal, vagy – a kettő egyidejű alkalmazásával.

Elemzési osztályok sztereotípiái

• Az elemzési modellben az osztályok minősítésére:– a <<boundary>>, – a <<control>> és – az <<entity>> sztereotípiákat használhatjuk.

• A sztereotípusok meghatározását az interakciós diagramok készítésekor, elemzésekor lehet megtenni.

Elemzési osztályok sztereotípiái

• Megkönnyíti:– a diagramok összeállítását, – értelmezését, – elősegíti a szoftverrendszer

rétegeinek:• felület/prezentációs réteg,• alkalmazáslogika, • adattárolási logika szétválasztását.

Absztrakt osztályok

• Speciális osztályok, amelyeknek nem hozhatunk létre példányait.

• Az osztály nevét döntött betűkkel kell írni.

• Az absztrakt osztályból mindig származtatunk további osztályokat, amelyek öröklik az absztrakt osztály attribútumait, műveleteit és asszociációit.

Függőség

• Két elem egymásra hatását fejezi ki. • Az egyik elem definíciójának

(specifikációjának) változása a másik elem megváltozását okozhatja, eredményezi.

Függőség

• A kapcsolatban az előbbi a független, az utóbbi a függő elem.

• A függési kapcsolatot irányított, szaggatott vonallal modellezzük.

• A nyíl iránya egyben meghatározza a függőség irányát. – A nyíl a függő elemtől indul, és a felé az

elem felé mutat, amitől az elem függ

Függőség

• Gyakran adatcsere jellegű kapcsolatok leírására használjuk.

• Ilyen kapcsolat lehet például a felhasználói felület egy ablaka, mely adatokat kér be a felhasználótól (átmenetileg létező objektum) és az adatokat egy szakterületi, perzisztens módon eltároló objektum között. Az ablak esetében ahhoz, hogy teljesíteni tudja funkcióját, szüksége van a tároló objektumra.

Osztály-attribútum, osztály-művelet

• Az osztályok attribútumait és műveleteit különleges szereppel és jelleggel ruházhatjuk fel, ún. scope specifikációt rendelhetünk hozzájuk:– A classifier típusú attribútumok– A classifier típusú műveletek.


• A classifier típusú attribútumok (class-scope attibute)– az osztály minden objektumában,

vagyis instanciájában ugyanazt az értéket veszik fel.

• A classifier típusú műveletek – minden objektumra, vagyis instanciára

azonos módon lejátszódó műveletek. • Aláhúzással jelöljük.



create()

Osztálynak önmagával való asszociációja (self-association)

Személy

házasság+feleség

+férj

0..10..1

hierarchia

+főnök

+beosztott0..1

*

Szerepkör

Fonök<<Interface>>

Beosztott<<Interface>>

0..n0..10..1 0..n

Személy

Megvalósít


Cég Személy** **

+munkavállaló+munkaadó

Alkalmazásfizetés : double Részleg

1* 1*Asszociációs osztály

Asszociáció attribútumai

Asszociáció vagy

attribútum?

Osztálydiagram a leíráshoz

• Class diagram.• Az osztály diagram a legismertebb

objektumorientált (OO) technika:– A rendszer objektumait leíró osztályokat és– a közöttük levő kapcsolatokat modellezi.

Osztály diagram

Osztálydiagram a leíráshoz

• Class diagram.• Az osztály diagram a legismertebb

objektumorientált (OO) technika:– A rendszer objektumait leíró osztályokat és– a közöttük levő kapcsolatokat modellezi.

Osztály

• A közös tulajdonságokkal (attribútumok), • viselkedéssel (metódusok) és • kapcsolatokkal rendelkező objektumok

csoportjának, halmazának leírására szolgálnak

Osztály

• Az objektum:– az osztály konkrét megjelenési formája,

egyedi példánya (instancia). – Az osztályok attribútumok és metódusok

(függvények, eljárások) gyűjteménye.

Osztály

• Az osztályt az UML-ben egy három részre osztott téglalap modellez:– az osztály megnevezését a felső részben

adjuk meg, – a középső részben találhatók az attribútumok

(tulajdonságok),– az alsó rész a műveleteket tartalmazza.

OsztálynévattribútumNév

műveletNév()

Osztálydiagramok a fejlesztési modellben

• A fejlesztés különböző munkaszakaszaiban készülnek.

• Ez nem újabb és újabb modellek, a fejlesztés teljes ideje alatt egy alapmodellt vizsgálunk.

• Ezt az egy modellt fokozatosan bővítjük a megfelelő részekkel a fejlesztés menetében előrehaladva.

• A modell aktuális állapotát, érettségét az egyes szakaszokban készített osztálydiagramokkal ábrázoljuk.


• Üzleti modellezés– Szakterületi osztálydiagram elemei:

• Üzleti aktorok• Üzleti entitások

– üzleti objektum modell

• Elemzési szakasz:– Elemzési osztályok leírása

• Tervezési modell:– Az elemzési modell részletezése– Implementáció alapja


• Módszertanok:– Az osztálydiagramot három alapvető

perspektíva szerint értelmezik. – Ez nem része az UML definíciójának.– Hasznos, hogy

• mindig csak az aktuális probléma megoldására engedi a fejlesztésben résztvevő szakembereket koncentrálni

Osztálydiagramok a fejlesztési modellben - perspektíva

• Konceptuális perspektíva• Specifikációs perspektíva• Implementációs perspektíva


• Konceptuális perspektíva:– a kapcsolat foka, – az asszociáció neve, – a különféle asszociációs viszonyok:

• öröklődés, aggregáció, kompozíció


• Specifikációs perspektíva– Átmenet a konceptuális és az

implementációs megközelítés között.– A use case-ek fizikai megvalósításának

módját írja le, a megvalósítás vázát adja. – A modellelemekhez felelősségeket

határoz meg, de ezt nem kód szinten teszi.

– Az alkalmazás struktúrájára, felépítésére összpontosít.


• Implementációs perspektíva– Valódi osztályok konkrét programnyelvi

környezetben.

CRC kártya

• Class – Responsibility – Collaboration • Osztály – Felelősség – Együttműködés • CRC kártya használatának elve:

– Ward Cunningham és Kent Beck.

CRC kártya

• Osztályok meghatározása nem diagramok alapján, hanem táblázatos lapok segítségével.

• A leírásban nem metódusokat és attribútumok, hanem az osztályokhoz rendelhető felelősségek vannak.

Felelősség

• Annak a magas szintű leírása, hogy mi a fő célja az illető osztálynak.

• Cél:– Minél egyértelműbben meghatározni egy

osztály működésének a célját, egy rövid, tömör leírás formájában.

CRC kártya

Order

A tételek raktáron való meglétének ellenőrzése Order Line

Az ár meghatározása

A kifizetés érvényességének ellenőrzése

Áruk elküldése a megrendelő címére

Order Line

Customer

<Osztály neve>

<Együttműködés><Felelősség>

CRC kártya

• Ixtlan Software

Elemzési osztályok egységesítése

• Az elemzési osztály neve:– fejezze ki azt a szerepet, amit az adott osztály a rendszerben

játszik– legyen egyedi, szinonimák sem megengedettek

• Vonjuk össze:– a hasonló viselkedésű, azonos szerepű osztályokat– azokat az entitásokat (<<entity>> osztályokat), amelyeknek

azonosak az attribútumaik, még ha a viselkedésük különböző is (a viselkedést is fésüljük össze)

• Az osztályok módosításakor módosítsuk a kapcsolódó használati esetek leírását és a folyamatokat (együttműködési diagram)

Tervezési elemek azonosítása

• Elemzési osztályok: olyan fogalmi dolgok, amelyek valamilyen viselkedéssel rendelkeznek. A tervezés során tervezési osztályokká és alrendszerekké válnak – tervezési döntések– implementációs környezet

• Alrendszer: speciális csomag, amelynek jól-definiált interfészei vannak, egyébként zárt– Csomag: különösebb szemantika nélküli fogalom az UML-ben a

modell-elemek csoportosítására – Alrendszer: a csomag-fogalom egy speciális használata,

amelynek osztályszerű tulajdonságai, viselkedése van

Tervezési elemek azonosítása

• Tervezési osztályok: az egyszerű elemzési osztályokból egy-egy tervezési osztály keletkezik– Tipikusan az <<entity>> osztályok ilyenek

• Tervezési alrendszerek: az összetett elemzési osztályokból keletkezik. Az elemzési osztály által definiált viselkedés túl komplex ahhoz, hogy egyetlen osztály szolgáltatásaival megvalósítható legyen. – Implementáció: komponensek– Példa:

• hitel- vagy kockázatértékelő mechanizmusok (pénzügy)• szabályalapú kiértékelési mechanizmusok (kereskedelem)• biztonsági szolgáltatások (minden rendszer)

Tervezési minták• Az OO szemlélet lehetővé teszi a problémák és a

megoldások absztrakt és általános ábrázolását• Az újrafelhasználás:

– Kód szintű, ha a megírt programot használjuk fel újra. Ez nem túl hatékony, mert gyakran a megírt komponenshez keresünk rendszert. (Gomb kontra kabát effektus)

– A tervezés újra használata, a típus problémák adott környezetben működő megoldásának újbóli felhasználása. Tervezési minták

– Elemzés eredményeinek újra felhasználása esetén a típus követelményekre egy típus rendszert határoz meg, amely minden kérdésre kitér az adott problémakörben. Elemzési minták

Létező tervezési elemek egyesítése

• Az újrafelhasználás lehetőségeinek feltérképezése

• Meglévő komponensek és adatbázisok visszafejtése (reverse-engineer)

• A Tervezési Modell átstruktúrálása

A futás idejű architektúra leírása

• A konkurenciára vonatkozó követelmények elemzése,

• a processzek azonosítása, • a processzek közötti kommunikációs

mechanizmusok azonosítása, • a processzek közötti szinkronizálást végző

erőforrások allokálása, • a processzek életciklusának azonosítása • a modell elemeinek szétosztása a processzek

között.

Funkciók elosztása

• Annak meghatározása, hogy az egyes funkciók hogyan oszlanak meg a csomópontok között

• A hálózati konfiguráció specifikálása• A processzek elosztása a csomópontokba

Az architektúra szemlézése• Olyan eddig fel nem tárt kockázatok felderítése, amelyek hatással

lehetnek az ütemezésre vagy a költségvetésre.• Az architektúrális tervezés során elkövetett hibák felfedezése

– ezek azok a hibák, amelyek a legnagyobb költséggel javíthatóak• Felderíteni a követelmények és a tervezett architektúra közötti

ellentmondásokat. – Ilyenek lehetnek például a hiányzó, vagy nem reális követelmények

vagy a túlzott bonyolultságú architektúra.• Az architektúra néhány jellemző tulajdonságának becslése:

– teljesítmény, megbízhatóság, módosíthatóság, robosztusság, biztonság…

A tervezés szemlézése

• Annak igazolása, hogy a tervezett modell megfelel a rendszer követelményeinek és jó alapként szolgál az implementációhoz

• Annak ellenőrzése, hogy a tervezési modell megfelel-e a tervezési útmutató alapelveinek

Komponensek tervezése

Komponensek tervezése - Cél

• A tervezési elemek definíciójának finomítása azon részletek kidolgozásával, amelyek az adott tervezési elem elvárt viselkedésének implementálásához szükségesek

• A használati esetek megvalósításainak finomítása és módosítása az újonnan megtalált tervezési elemek alapján

• A fokozatosan kialakuló tervezési modell szemlézése• A tervezési elemek alapján a komponensek

implementálása• Az implementált komponensek tesztelése annak

ellenőrzésére, hogy megfelelnek-e a unit szintű követelményeknek

Komponensek tervezése• Kapcsolódó tevékenységek:• Használati esetek tervezése

– a használati esetek leírásának kiegészítése az implementáláshoz szükséges információkkal.

• Osztályok tervezése– a tervezési osztályok tulajdonságainak meghatározása

• Részrendszerek tervezése– a tervezési részrendszerek kialakítása és részletes

dokumentálása• A tervezés szemlézése

– az eddig elkészített tervezési modell elemeinek ellenőrzése

Használati esetek tervezése

• Az interakciók alapján a használati eset megvalósítások finomítása

• A tervezési osztályok műveleivel kapcsolatos követelmények finomítása

• A részrendszerek és azok interfészeinek műveleihez kapcsolódó követelmények finomítása

Részrendszerek tervezése• Az alrendszer szolgáltatásait az interfészei biztosítják a

külvilágnak– Egy interfész-osztály metódusával: ennek végrehajtásában

közreműködhetnek más osztályok– Az interfészt megvalósító alrendszer interfészével

• Az alrendszeren belüli elemek együttműködését szekvencia illetve aktivitás diagrammal dokumentáljuk

• Az alrendszer belső szerkezetét ábrázoljuk egy vagy több osztálydiagrammal (az osztályok tervezése a következő lépés)

Részrendszerek tervezése

• Dokumentáljuk az alrendszerek közti függéseket:– Amikor az

alrendszerünk egy eleme egy másik alrendszerben lévő elemet használ, akkor függ attól a másiktól

FizetésiÜtemezés

Számlázás

Osztályok tervezése - lépések

• Tervezési osztályok kialakítása típusonként, perzisztens osztályok azonosítása

• Részletes tervezés– Az osztályok láthatóságának meghatározása– Műveletek, metódusok – Állapotok– Attribútumok– Függések– Asszociációk– Öröklődés– Az osztályhoz kapcsolódó nem-funkcionális követelmények

kezelése

Osztályok tervezése

• A lépések nem szekvenciálisan következnek, az osztályok specifikációja fokozatosan finomodik

• A megfelelő tervezési minták alkalmazása• A tervezés végén az összes osztálynak

közvetlenül implementálhatónak kell lennie, tehát a tervezés során használt modell szorosan összefügg az implementációs környezettel

Osztályok tervezése / <<Boundary>> osztályok

• Az elemzés során egy osztályt definiáltunk minden ablak számára - nagyon magas szint

• A GUI fejlesztőeszközökben rendszerint létre tudjuk hozni a felhasználói felület osztályait - csak azt kell megtervezni, ami automatikusan nem jön létre

• A más rendszerekkel kapcsolatot tartó <<Boundary>> osztályokat általában alrendszerekként tervezzük, mivel általában összetett viselkedést takarnak. Ha egyszerű adattovábbítás a feladat, akkor lehet tervezési osztály is belőle

Boundary felhasználói felület

• Az elemzés eredménye egy osztály, amely leírja, hogy mit kell tudnia az adott felhasználói interakcióban a rendszernek.

Tanfolyami jelentkezés

+ Jelentkező adatainak megadása(név, cím, telefonszám, cégnév)+ tanfolyam lista megjelenítése(cím, rövid tematika, teljes tematika)+ tanfolyam kiválasztása()+ időpontok listájának megjelenítése(kezdete, vége, oktatók)+ időpont kiválasztása()+ regisztráció a kiválasztott időpontra()

<<boundary>>

Felhasználói felület megvalósítva

Felhasználói felület modellje

A tervezés során a modellezési konvenciónak a megvalósító környezet fogalmai szerint kell megjeleníteni a szerkezetet. Ezt az architektúrális tervezés szakaszában kell kialakítani!

tblTanfolyam<<column>> név : String<<column>> tematika : Long String

<<event>> doubleClick()

<<tablewindow>>

tlbTanfolyamIdopont<<column>> tanfolyam kezdete : Date<<column>> tanfolyam vége : Date<<column>> oktatók : String

<<event>> doubleClick()

<<tablewindow>> frmJelentkezo<<datafield>> név : String<<datafield>> cím : Long String<<datafield>> telefonszám : String<<datafield>> cégnév : String

<<button>> regisztráció()

Osztályok tervezése / <<Entity>> osztályok

• Általában passzívak és perzisztensek• Perzisztens: képes az állapotát tárolni valamilyen

háttértáron• Lehetnek perzisztens és tranziens példányai a

perzisztensnek jelölt osztályoknak is• Az adatbázis tervezés során kell őket figyelembe venni• Perzisztens osztályok nemcsak <<Entity>> osztályokból

keletkeznek, hanem például folyamat- vagy tranzakció-vezérlő osztályokból is (nem-funkcionális követelmények)

Osztályok tervezése / <<Control>> osztályok

• A használati esetek végrehajtásáért felelősek, azt a logikát tartalmazzák, ami nem a <<Boundary>> és nem az <<Entity>> osztályokhoz tartozik alkalmazási logika vagy üzleti logika

• A tervezésük során figyelembeveendő szempontok:– Komplexitás: az egyszerű vezérlés megoldható boundary vagy entity

osztályokkal is– Változás valószínűsége: ha kicsi, akkor a control osztályok bevezetése

nem indokolt– Elosztás és hatékonyság: ha elosztott a rendszerünk, akkor rendszerint

kellenek control osztályok– Tranzakció-kezelés: ha a keretrendszerünk nem tartalmazza, akkor

szükség van control osztályra

Osztályok tervezése / Láthatóság meghatározása

• Minden egyes osztályhoz határozzuk meg a láthatóságát:– Public: az osztályt tartalmazó csomagon

kívülről is elérhető– Private (esetleg „implementation”): csak az

osztályt tartalmazó csomag osztályai hivatkozhatnak rá

Osztályok tervezése / Műveletek definiálása

• Vegyük sorra az elemzési osztályok szolgáltatásait, és mindegyikhez definiáljunk egy műveletet– A szolgáltatás leírása alapján készítsük el a művelet

első leírását– Nézzük meg azon használati eset megvalósításokat,

amelyekben az osztály részt vesz, így pontosíthatjuk a művelet definícióját, paramétereit, visszatérési értékét, leírását

– A használati esetben megfogalmazott nem-funkcionális követelményeket is vegyük figyelembe

Osztályok tervezése / Műveletek tervezése

• A használati eset megvalósítások alapján definiálhatókon kívül műveletekre is szükség lehet:– Létre lehet-e hozni, lehet-e inicializálni az osztály példányát?

(Beleértve a más objektumokkal való kapcsolatot is.)– Szükséges e annak ellenőrzése, hogy két objektum azonos e

(azaz attribútumaik és kapcsolataik megegyeznek-e, elosztott rendszerben nehéz ügy)?

– Le kell-e másolni egy objektumot?– Szükség van-e egyéb műveletekre a mechanizmusok

megvalósításához? (Például szemét-gyűjtési mecha-nizmus megköveteli, hogy egy objektum törölni tudja az összes egyéb objektumra vonatkozó referenciáit)


• Minden művelethez meg kell adni:– A művelet neve: rövid, de kifejező név (mit fog a művelet

eredményezni)• Az implementációs nyelv szintaxisa szerint

– Visszatérési érték típusa– Rövid leírás: néhány mondat a művelet hívójának

szemszögéből (nem algoritmus)– Paraméterek:

• Minden paraméterhez:– Név– Típus– Rövid leírás: a paraméter jelentése, cím vagy érték szerinti, kötelező

vagy opcionális, default értéke, érvényes értékek• Kevesebb paraméter könnyebben használható fel újra,

könnyebben érthető ( OO előny! )


• Láthatóság:– Public (+): minden más modell-elem hivatkozhat rá– Implementation ( ): csak az osztályon belül használható– Protected (#): az osztály, leszármazottai és barátai (friend)

hivatkozhatnak rá– Private (-): csak az osztályon és az osztály barátain (friend) használható

• Osztály-műveletek– Szükség van néha arra, hogy egy műveletet az osztály összes

példányán végrehajtsunk osztályművelet– Például: hozzunk létre új példányt, adjuk vissza az összes példányt, stb– Jelölés: a művelet aláhúzásával történik, jelenleg a Rose-ban a

<<class>> sztereotípust használjuk


• A művelet algoritmusa (method): hogyan hajtódik végre a művelet (nemcsak mit csinál)– Hogyan kell a műveletet implementálni?– Milyen attribútumok kellenek és hogyan használja

azokat a művelet?– Milyen kapcsolatok kellenek?– Együttműködési diagramok használhatóak a folyamat

dokumentálására!– Esetleg aktivitás diagram alkalmazható az algoritmus

leírásra.

Osztályok tervezése / Állapotok

• Az osztályok egy részénél a művelet végrehajtása attól függ, hogy az objektum milyen állapotban van

• Állapotátmenet diagram (State Transition Diagram) vagy állapot diagram (State Diagram) használható a viselkedés ábrázolására– Ha egy művelet végrehajtása után létezik olyan

művelet, amely más eredménnyel fut le mint előtte, akkor az adott osztály rendelkezik állapottal, különben honnan tudná, hogy másként kell reagálnia.

– Összefüggés az együttműködési diagramokkal!

Állapot-átmeneti diagram

Az állapot-átmeneti diagram• State/State transition diagram• tágabb értelemben:

– a rendszer dinamikus nézetét jellemző technika– az állapot diagramokkal leírható egy rendszer

viselkedése • szűkebb megközelítésben:

– egyetlen osztályhoz kapcsolódó fogalom, amely bemutatja az osztály konkrét objektumának élettartama (a rendszerben levő) alatt mutatott viselkedését, vagyis

• azokat a lehetséges állapotokat, amelyekbe az objektum kerül, jut, és

• ahogy az objektum állapota változik (állapotátmenet) az őt érő események hatására


• Az objektumok dinamikus viselkedésének leírására szolgáló eszköz.

• Egy-egy objektum elemezésére szolgál:– az objektum az események hatására hogyan

változtatja meg a belső állapotát, – az események hatására milyen üzeneteket küld

a többi objektum számára.


• A fejlesztés során csak az intenzíven dinamikus (változó) viselkedésű objektumok állapot-átmeneteit érdemes modellezni.

• A gyakorlatban a legtöbb osztályhoz nem készül állapot-átmeneti diagram, mert azok a rendszerben csak kisegítő ún. utility osztályok.

Állapot-átmeneti diagram• Ábrázolásukra különböző megoldások vannak.• Az egyes megoldások némileg szemantikájukban

különböznek egymástól.• Az UML szerinti állapot diagram: David Harel által

kidolgozott megoldás, javasolt állapot diagram:– elsőként az OO módszertanok közül az OMT

alkalmazta– 1994 - Booch is beépítette módszertanába - second

edition

Az objektumok állapota

• az objektumok a valós dolgokat leíró elemek• a valós dolgokhoz hasonlóan az objektumoknak

is van létük, mindegyik valamikor, valaminek a hatására létrejön, egy ideig létezik, majd megszűnik

• életük során más más állapotokat vesznek fel, különböző módon viselkednek

• a felvett állapotokat csak véges ideig tartják, ez alatt az idő alatt az objektum az adott állapotban van

Az állapot• egy konkrét objektum adott időpontban vett

attribútum-értékei és kapcsolatai együttesen• az állapot két esemény közötti időtartamot

határoz meg• az a nem nulla hosszú időszak, amíg az

objektum valamely esemény bekövetkezését várja

• jelölés:stateName

Állapotok leírása• Eseménykövetési diagramok is segítenek. • Az állapotok feltérképezéséhez ki kell gyűjteni:

– az adott osztály objektumait reprezentáló függőleges vonalakat (életvonal – lifeline),

– a kapott és küldött üzeneteket jelölő nyilakkal együtt.

• A kapott üzenetek forrása és a küldött üzenetek célja az állapotmodell szempontjából lényegtelen.

• Egyetlen eseménykövetési diagramrészletből kell kiindulni.

• Végig kell nézni az objektumhoz érkező, és az objektumot elhagyó üzeneteket.

• Az állapotok két esemény között írják le az objektumot. – Ha két egymást követő állapot között az objektum

kívülről kap üzenetet, akkor ezt az eseményt kell megadni az állapot-átmenet eseményeként.

– Amennyiben a két állapot között az objektum küld üzenetet, az üzenet elküldését az átmenet során elvégzendő akcióként kell megadni.

– Ha eseménykövetési diagram ciklusokat tartalmaz, a bejárt állapotokat csak egyszer kell létrehozni, és az állapot-átmeneteket úgy kell kialakítani, hogy a ciklus végén az objektum újra a ciklus elején lévő állapotba kerüljön.

Állapotok leírása

Az order különböző állapotait bemutató állapotdiagram

checkingdo: check item

waiting

dispatchingdo: initiate delivery

delivered

/ get first item

[ not all items checked ] / get next item

item received[ some items not in stock ]

[ all items checked&&all items available ]

item received[ all items available ]

delivered[ all items checked&&some items not in stock ]

start

self-transition transition

activity

state


• kiindulási/kezdő pont (start point): a diagram egy kiindulási ponttal indul (az objektum automatikusan a kezdő állapotba lép), és

• megmutatja a kiindulási/kezdő átmenetet: „/ get first item” a checking állapotba


/ get first item

Átmenet• az átmenetet egy esemény váltja ki, vagyis az átmenet az

objektum válasza egy külső eseményre,• az átmenet során az objektum egy másik állapotba

kerülhet• általában eljáráshívással jár együtt, vagyis valamilyen

tevékenység végrehajtásával• az átmenet szintaxisa – három része van:

– esemény– feltétel– akció– szintaxisa: esemény [feltétel] / akció - Event [guard] / action– megadásuk opcionális

Állapot-átmenet típusai• Külső állapot-átmenet:

– Az objektum állapotai között értelmezzük, az állapotokat összekötő nyíllal jelöljük.

– Az aktuális állapotból másik állapotba vezet. – Eljáráshívás vagy történik, vagy nem.

• Belső állapot-átmenet: – Az objektum egy adott állapotában értelmezzük.– Eljáráshívással jár együtt anélkül, hogy az objektum

állapota megváltozna. A belső átmenetet az állapot alsó rekeszében adjuk meg.

A rendelési rendszer példában• az átmenet szintaxisa:

esemény [feltétel] / akció - Event [guard] / action

• a példában az átmenet megadása:– csak egy akció van: „/ get first item” , ez az átmenet

esetén végrehajtandó akció– elsőként ezt az akciót kell végrehajtani a checking

állapotba való belépéshez


/ get first item

Esemény• esemény vagy üzenet: egy objektumnak egy másik

objektumra történő hatása: az objektum az állapotából adott esemény hatására más állapotba kerülhet

• az átmenetet kiváltó események• az esemény egyetlen időpillanathoz kapcsolódik - (az

állapot két esemény közötti időtartamot határoz meg)• ha egy átmenethez nincs esemény megadva - az esemény

nélküli állapotváltás esetén: az objektum az állapothoz rendelt tevékenységet végrehajtva automatikusan a következő állapotba kerül

A példa folytatása• a checking állapotból három átmenet látható • mindhárom átmenethez feltétel, őrszem

kapcsolható



[ all items checked&&some items not in stock ]


guard

transition

Feltétel• az átmenet feltétele• más néven: őrszem – guard• a feltétel maga is az objektum állapotára utal, de ezt nem

jelöljük külön névvel• a feltétel megadása: szögletes zárójelek [feltétel] között az

esemény neve után• az objektum egy adott állapotából vagy egy esemény

hatására vagy automatikus átmenettel csak akkor vált át az átmenet által meghatározott állapotba, ha teljesíti az őrszemként megadott feltételt, vagyis

• ha az átmenet feltételhez van kötve, az állapotváltás csak az esemény bekövetkezése ÉS a feltétel igaz értékének bekövetkezése esetén történik meg

• a feltétel hamis értéke esetén az állapot nem változik

Feltétel – példa folytatása• egy adott állapotból csak egy átmenet vehető ki,

következhet• a példában a checking állapotból három átmenet

látható – ha nincs minden tétel ellenőrizve, megkapva/elérve a

következő tételt visszatérünk a checking állapotba, hogy azt ellenőrizzük

– ha minden tételt ellenőriztünk és azok mindegyike raktáron is az objektum a dispatching (a rendelés feladása) állapotba kerül

– ha minden tételt ellenőriztünk, de nem mindegyik van raktáron az objektum a waiting állapotba kerül



waiting






• a példában csak egy akció van: „/ get first item” , elsőként ezt az akciót kell végrehajtani a checking állapotba való belépéshez

• a checking állapotban az objektum „check item” tevékenységet végez

• az állapottal kapcsolatban levő tevékenység szintaxisa:– do/activity – „do/check item”


Tevékenységek/activities

• az állapotokhoz megadhatók végrehajtandó tevékenységek - az objektumok meghatározott ideig vannak egy adott állapotban, eközben különböző tevékenységeket végezhetnek

• a tevékenységek végrehajtása időt vesz igénybe, tehát a tevékenységekhez időtartam tartozik

• a tevékenyek végrehajtása alatt az állapot nem változik

Tevékenységek, akciók

• „akció” – az átmenettel kapcsolatban – az objektum által végzett elemi műveletek

• „tevékenység/activity” – az állapottal kapcsolatban – elemi műveletekből álló tevékenységek

• mindkettő eljárás, művelet, amelyek az objektum metódusaként implementálhatók, a példában tipikusan néhány metódussal lesznek implementálva az order-on

• tevékenységek, akciók: a rendszer működtetése során végrehajtandó feladatok, műveletek

• tevékenységek olyan műveletek:– összetettebbek, további lépésekre bonthatók– események által megszakítható tevékenységek a végrehajtás

folyamatában– az elemi műveletekből (akciók) álló tevékenységek elvégzéséhez

meghatározott időre van szükség – ezért az állapotokhoz kapcsolhatók

• akciók olyan pillanatnyi műveletek: – a funkció-hierarchia legalsó szintjén elhelyezkedő elemi műveletek

un. atomi műveletek - további lépésekre nem bonthatók– nem szakíthatók meg, nem rendelünk hozzájuk időtartamot – ezért az

átmenethez kapcsolhatók– pl. számítási műveletek, objektum manipulálására vonatkozó kérések

stb.


Akciók

• az állapotokkal kapcsolatban többféle akció különböztethető meg, az állapothoz rendelhető:– bemeneti akció – entry action: – kimeneti akció – exit action– belső akció – internal action

Bemeneti akció – entry action

• entry/ jelölés után adható meg• az állapotba történő átváltás (és így a

tevékenység) előtt hajtódik végre• azt az esetet rövidíti, amikor az állapotba

vezető minden átmenet esetén azonos tevékenységet akarunk végrehajtani

Kimeneti akció – exit action

• exit/ jelölés után adható meg• az állapotból történő kilépés után hajtódik

végre• azt az esetet rövidíti, amikor az állapotból

kivezető minden átmenet esetén azonos tevékenységet akarunk végrehajtani

Belső akció – internal action

• esemény/művelet jelöléssel adható meg – az esemény nevét követő perjel után adjuk meg a végrehajtandó akció nevét

• egy adott esemény egy akciót vált ki anélkül, hogy az állapot megváltozna

• olyan átmenetek rövidítése, amikor az állapotból kiinduló, az eseménnyel címkézett él ugyanabba az állapotba tér vissza, de ekkor nem hajtódik végre sem kimeneti, sem bemeneti akció, mivel az objektum ugyanabban az állapotban maradt


• UML igazán nem tesz köztük különbséget, mégis lehet következtetni, hogy elemi műveletről vagy tevékenységről van szó– de a tevékenységekhez pl. hozzájuk

kapcsolhatók belépési pontok, kilépési akciók– az állapothoz tartozó tevékenységet

félbeszakíthatja egy külső esemény, azonban a kimeneti tevékenység ekkor is végrehajtódik – akció nem szakítható félbe, mert nem rendelkezik időtartammal


waiting


delivered

/ get first item





delivered[ all items checked&&some items not in stock ]


start

self-transition transition

activity

state

Példa folytatása• waiting állapothoz nincsenek megadva végrehajtandó

tevékenységek• az adott order objektum a waiting állapotban tartózkodik

egy esemény bekövetkezésére várva• a waiting állapotból két kimenő tranzakció mindegyikéhez

a item received esemény tartozik, ami azt jelenti, hogy az order addig vár, amíg nem észleli az eseményt, vagyis az esemény bekövetkezésére vár

• az order kiértékeli az átmeneten levő feltételeket, majd végrehajtja a megfelelő tranzakciót – vagy visszamegy a waiting állapotba– vagy az order a feltételek kiértékelésének eredményeként a

dispatching állapotba kerül

A waiting állapot

waiting




A dispatching – foglalás állapot

• az állapotban meg van adva egy végrehajtandó tevékenység:– do/initiate delivery – szállítás elindítása

• létezik továbbá egy feltétel nélküli átmenet – a delivered eseménnyel triggerelve

• ez azt jelzi, hogy az átmenet mindig bekövetkezik, amikor ez az esemény bekövetkezik

• azonban, az átmenet nem következik be, ha a tevékenység befejeződött

• ha egyszer initiate delivery tevékenység kész, befejezett, az adott order egészen addig marad a dispatching állapotban, amíg a delivered esemény be nem következik


delivered

delivered

A cancelled átmenet

• a rendszernek lehetőséget kell adni arra, hogy a rendelési folyamat bármely pontjában töröljük a megadott rendelést, mielőtt az szállításra kerülne

• megoldás: mindegyik állapotból:– checking, waiting, dispatching biztosítunk

egymástól elkülönített átmeneteket


waiting


delivered

/ get first item



delivered

cancelled




cancelled

cancelledcancelled

Szuperállapot• az állapotok finomíthatók alállapotokkal – a

logikailag összetartozó állapotokat érdemes egy nagyobb egységbe összefogni és ebben az egységben kezelni

• a példában hasznosabb lehet létrehozni a három állapotnak egy szuperállapotát, majd ebből megrajzolni egyetlen cancelled átmenetet

• egyfajta öröklődési hierarchia, az alállapotok öröklik a szuperállapot átmeneteit (a példában a cancelled átmenetet), ha azt nem definiálják át

• egy szuperállapotban levő objektum lehet a szubállapotok bármelyikében



delivered

/ get first item


delivered

cancelled

waiting

active


Szubállapotok

• a szubállapotok egy meghatározott szuperállapoton belül:– szekvenciálisan követik egymást:

• diszjunkt állapotok• a szuperállapotot egy adott időpontban az

alállapotok közül mindig csak egy határozza meg, vagy

– párhuzamos kapcsolatban lehetnek egymással – konkurens szub-állapotok



delivered

/ get first item


delivered

cancelled

waiting

active


Konkurens állapot diagram

• műveletsorok, amelyek párhuzamosan végezhetők egymással

• a párhuzamos állapotfolyamok mindegyikének külön állapota van - az egy szuperállapotba zárt, konkurens állapotgépeknek saját induló és végállapotaik vannak

• a szuperállapot akkor következik be, amikor a benne levő összes párhuzamos folyam befejeződik, vagyis eléri a végállapotot – ha valamelyik előbb fejeződik be, az vár

• hasznos: ha egy objektumnak vannak egymástól független viselkedéscsoportjai


• törekedjünk minél kevesebb konkurens szubállapot kialakítására

• ha túl bonyolult egy objektumhoz tartozó konkurens állapot diagram, érdemes az objektumot további objektumokra szétszedni, szétválasztani

• példában az order állapotai:– egyrészt a rendelési tételek elérhetőségén alapulnak, – másrészt léteznek olyan állapotok is, amelyek viszont

a fizetés engedélyezésén alapulnak

Példa

• az authorzing állapotban végrehajtásra kerül a check payment tevékenység

• a tevékenység egy signal-lal fejeződik be, hogy a payment az helyes

• ha a payment OK, a feltétel igaz értékkel fejeződik be, akkor az adott order objektum addig vár az authorized állapotban, amíg a delivered esemény be nem következik

• ha a feltétel nem igaz az order bekerül a rejected állapotba

Payment authorizing - fizetésengedélyezés

authorizingdo: check payment

authorized

delivered

rejected[ payment not OK ]

[ payment OK ]


• hasznos: ha egy objektumnak vannak egymástól független viselkedéscsoportjai

• példában az order állapotai:– egyrészt a rendelési tételek elérhetőségén alapulnak, – másrészt léteznek olyan állapotok is, amelyek viszont a fizetés

engedélyezésén alapulnak– ha az authorizing állapot check payment tevékenysége sikeresen

befejeződött, az adott order a checking és az authorized állapotba kerül

– ha a cancel esemény bármikor bekövetkezik, az order csak a cancelled állapotban lesz

– a párhuzamos folyamatok mindegyikének befejeződése után a műveletsor kilép a szuperállapotból és a végrehajtás ismét egy ágban fog folytatódni

checking dispatching

waiting

authorizing authorized

cancelled

delivered

rejected

Az állapot diagram alkalmazása

• egyetlen objektum viselkedését akarjuk leírni több use case-en keresztül

• a gyakorlatban legtöbb osztálynak nincs állapot diagramja, mert például egyszerű kisegítő un. utility osztályok

• csak a markánsan dinamikus osztályokhoz készítünk állapot diagramokat – gyakorlatban a UI és control osztályokhoz érdemes

Állapottérképek elemei

• Állapot

• (Állapotátmenet)

• Emlékező állapot (history)

• Feltétel

• Kezdőállapot

• Végállapot

• Állapotcsonk

StateName

H

s1 s2

H*

s1

s1

Emlékező állapot

• olyan állapot, amelyik emlékszik arra, hogy melyik alállapotból terminált, és képes arra, hogy az állapotba való újabb belépéskor ugyanabba az állapotba kerüljön

HH

megszakitas

újrakezdés

Állapot-átmenet diagram

• Az objektumok dinamikus viselkedésének leírására szolgál

• Az objektumok külső hatások eredményeként változtatják állapotukat, és hatnak környezetükre

• Egy állapot-diagramot mindig egy osztályhoz készítünk, vagy egy magasabb szintű diagram pontosításaként

• A legtöbb osztálynak a gyakorlatban nincs állapot-diagramja, mert például egyszerű kisegítő utility osztályok

Várakozó

Aktív

Idõ lejárt

Csöngetésdo: csöngetõ hang

Tárcsázás

Idő lejártdo: Szaggatott hang

Érvénytelendo: sípoló hang Kapcsolás

Csöngetésdo: csöngetõ hang

Foglaltdo: foglalt hang

Beszélgetés

[ 15 mp lejárt ]

tárcsáz( n )[ nem teljes a szám

tárcsáz( n )[ érvénytelen a szám ]

tárcsáz( n )[ érvényes a szám ] / kapcsol

[ foglalt a vonal ]

[ szabad a vonal ]

hívott felveszi / beszélgetés engedélyezése

[ 15 mp lejárt ]

tárcsáz( n )

hívó leteszi a kagylót / bontja a vonalat

felveszi a hallgatót / tárcsahang Tárcsahangdo: búgó hang

Állapot-átmenet diagram - Példa

Összetett állapot (composite state)

• A modellt távoli, nagyvonalú nézőpontból készítjük el először. Egy ilyen diagram több alacsonyabb szintű állapotot kezel egységként.

• Az alállapotok közötti átmenetek a magasabb absztrakciós szinten nem látszanak, azokkal nem foglalkozunk.

• Az összetett állapotnak mindig van egy kezdő alállapota (starting substate), és lehet végállapota (terminal state)

Példa

Tárcsázó

Startentry: búgó hang kezdeteexit: búgó hang vége

Tárcsázás folyamatbanentry: number.append(n)

Startentry: búgó hang kezdeteexit: búgó hang vége

Tárcsázás folyamatbanentry: number.append(n)

tárcsáz( n )

[ number.isValid() ]tárcsáz( n )

Várakozó Tárcsázó Kapcsoló[ number.isValid() ]hallgató felvétele

Kezdőállapot Végállapot

Osztályok tervezése / Állapotok

• A markánsan dinamikus viselkedésű osztályokhoz készítünk állapot-diagramot

• Minden esemény az állapot-diagramon megfeleltethető egy műveletnek– A művelet algoritmusának leírását ki kell egészíteni

az állapot-specifikus információkkal - az egyes állapotokban hogyan kell a műveletnek viselkednie

• Az állapotokat gyakran attribútumok reprezentálják– Az állapot-diagram jó segítség az attribútumok

definiálásához

Példa - Tanfolyami időpont

Törölve

Inicializálás alatt Nyitottdo: Jelentkezõ regisztrálása

entry: jelentkezõk számának növelése

Jelentkezés / jelentkezõk száma=0

Jelentkezés

Megtelt

[ jelentkezõk száma=15 ]

törlés

törléstörlés

Példa

Újraélesztés

Törölve

Inicializálás alatt Nyitottdo: Jelentkezõ regisztrálásaexit: jelentkezõk számának növelése

Megtelt

H

Inicializálás alatt Nyitottdo: Jelentkezõ regisztrálása

entry: jelentkezõk számának növelése

Jelentkezés / jelentkezõk száma=1

Jelentkezés

Megtelt

[ jelentkezõk száma=15 ]

H

Törlés

Osztályok tervezése / Attribútumok

• Minden attribútumhoz meg kell adni:– nevét - az implementációs nyelv szabályai szerint– típusát - az implementációs nyelv alaptípusai közül – alapértelmezett vagy kezdeti értékét - ezzel az értékkel

inicializálódik az attribútum az objektum létrehozásakor– láthatóságát:

• public• implementation• protected• private

– a perzisztens osztályoknál azt is, hogy az attribútum perzisztens (default) vagy tranziens

• Ellenőrizzük, hogy minden attribútumra tényleg szükség van e

Osztályok tervezése / Függőségek definiálása

• Minden egyes esetben, amikor két objektum kommunikál, a küldő és a címzett között függőségi kapcsolatot kell használni, ha:– Paraméterként jut el a címzetthez a referencia. Az

együttműködési diagramon jelöljük meg, hogy a kapcsolat láthatósága a paraméter

– A címzett globális objektum. Az együttműködési diagramon jelöljük meg, hogy globális a kapcsolat

– A címzettet a művelet hozza létre és szünteti meg. Az együttműködési diagramon jelöljük meg, hogy lokális a kapcsolat)

Osztályok tervezése / Asszociációk, aggregációk

• Szorosabb kapcsolat, mint a függőség (Az együtt-működési diagramon a láthatóság mező (field))

• Ellenőrizni kell az asszociáció irányítottságát. Alapértelmezésben mindkét osztály objektumai látják a másikat. Ahol erre nincs szükség ott egyirányúvá kell tenni az asszociációt

• Határozzuk meg, hogy az asszociáció valamelyik oldalán rendezettek-e az elemek ({ordered})

• Ha egy osztállyal csak az adott osztálynak van kapcsolata, akkor érdemes megfontolni a beágyazását

Aggregáció vagy kompozició

• Rész-egész viszony: aggregáció vagy kompozíció

• Megosztott aggregáció

Cím- város- utca- házszám- irányítószám

Személy

11

SzemélyCím

- város- utca- házszám- irányítószám

1..*1..*

Cég11

Aggregáció vagy kompozíció• Kompozíció: szoros kapcsolat a rész és az egész között,

– a rész és az egész élettartama szorosan összetartozik– az egész megszűntével a rész is megszűnik– az egész nem teljes a részek nélkül– ha egyszer egy kapcsolat létrejött, nem változtatható meg– az egész oldal számossága csak 1 lehet

• Kompozícióval modellezhetjük az összetett attribútumokat is

SzámlaTételSzámla

Aggregáció vagy asszociáció

• Aggregáció csak akkor, – ha tényleg rész-egész kapcsolatról van szó– ha a rész nem értelmes az egész nélkül

• Asszociáció, ha az osztály a másik oldal nélkül is értelmes, független, önálló létezése van

• Kétségek esetén asszociációt használjunk!

Real-Time komponensek tervezése

Adatbázis tervezése

Adatbázis tervezése - Cél

• Tervezés során a perzisztens osztályok meghatározása

• A perzisztens osztályok tárolására megfelelő adatbázis szerkezet meghatározása

• A teljesítmény elvárásoknak megfelelő mechanizmusok és stratégiák kidolgozása az adatok tárolására és visszakeresésére

Adatbázis tervezése• Kapcsolódó tevékenységek:• Osztályok tervezése

– finomítani kell a tervezési osztályokat a perzisztens adatok kezelésére vonatkozó követelmények, jellemzők megadásával és modellbe integrálásával

• Adatbázis tervezése– a tervezési modell perzisztens adatainak tárolását és

visszakeresését reprezentáló adatmodell létrehozása• A tervezés szemlézése

– az elkészített adatmodell megfelelőségének vizsgálata

Adatbázis tervezése

• A perzisztens tervezési osztályok leképezése adatmodellre

• Konzisztens és hatékony tárolási struktúra kialakítása

• Adatelérés optimalizálása• Jelenlegi fejlesztéseknél elsődleges fontosságú,

mert az adatbázis hordozza magán az üzleti logika jelentős részét

• Későbbiekben fontos lenne az adatbázis tervezést minél inkább szeparálni

Struktúramodellezés

• Komponensdiagram (component diagram): Megadja a szoftver fizikai felépítését, vagyis azt, hogy a tervezési elemek szoftver elemekre való leképezését.

Komponens diagram

konfmanDesktop

MFC 6.0

DB

konfmanPages

<<HTML>>

Struktúramodellezés

• Telepítési diagram (deployment diagram): Megadja, hogy milyen szoftver elemeket milyen hardverre telepítünk.

Telepítési diagram

WEB_SERVER DB_SERVER

KONFMAN_LOCAL_MACHINE



KONFMAN_REMOTE_CLIENT



Elemzés - tervezés - tevékenységek

Elemzés - tervezés - termékek

Elemzés - tervezés - tevékenységek

Elemzés - tervezés - termékek

Az üzleti folyamat modell kapcsolata a többi modellel

• Kapcsolat a használati eset modellel• Kapcsolat az elemzési osztálymodellel




Diplomaterv

- szerző adatai : - konzulens adatai: - téma bemutatása: - elfogadás kel te:



Diplomamunka


Bírálat


Diplomatervek nyilvántartásaA két esemény között

meghatározatlan hosszúságú idő tel i k el











od Diplomaterv elbírálása - részletezés

Diplomaterv értékelése

Diplomaterv


Diplomaterv beérkezése a

Tanszékre

Új diplomaterv nyitása Diplomaterv visszaküldése

Diplomatervek nyilvántartása

elfogadás

od Folyamatok és kapcsolódó használati esetek

Új diplomaterv nyitása

cd Elemzési osztálymodell

Diplomaterv

- cím: String- készBeérkezés: Date- tanszék: LongInt- szerző1: String- szerző2: String- fejlesztőeszköz: LongInt- tervBeérkezés: Date




Diplomaterv




Diplomamunka


Bírálat


Diplomaterv ek nyilv ántartásaA két esemény között

meghatározatlan hosszúságú idő telik el











Diplomaterv elbírálása - részletezés

od Diplomaterv elbírálása - részletezés

Diplomaterv értékelése

Diplomaterv


Diplomaterv beérkezése a

Tanszékre

Új diplomaterv nyitása Diplomaterv visszaküldése

Diplomaterv ek nyilv ántartása

elfogadás

Elemzési osztálymodell


Diplomaterv


Elemzési osztálymodell(Diplomáztatás esettanulmány, diagram-részlet)


Diplomaterv


+ Tárol() : void+ Töröl() : void+ Adatvizsgálat() : Boolean

Diplomaterv Ablak

- entitás: Entitás

Bírálat

- kiadás: Date- kész: Date- bíráló: Integer- jegy: Integer- bírálatFile: String

+ Tárol() : void+ Töröl() : void+ Adatvizsgálat() : Boolean

BírálatAblak

- entitás: Entitás

bírálatFile

Diplomaterv ablak

Bírálat ablak

V.3. Implementáció

Implementáció

A kód szerkezetének meghatározása az

implementációs részrendszerek, rétegek szempontjából

Az osztályok, objektumok implementálása

A implementált komponensek unit tesztjeinek elvégzése

A különálló fejlesztők vagy fejlesztő csoportok

eredményeinek integrálása egy végrehajtható rendszerbe

Implementáció• Az implementációs modell strukturálása (Structure the

Implementation Model)– Az implementációs modell szerkezetét úgy kialakítani, hogy a

komponensek fejlesztését és a build építés folyamatát a lehető legkisebb konfliktusokkal lehessen végrehajtani.

– Egy jól szervezett modell megelőzi a konfiguráció kezelési problémákat és megkönnyíti az egyes részek integrációját.

• Az integráció tervezése (Plan the Integracion)– Annak megtervezése, hogy az aktuális iterációban mely

részrendszerek kerülnek implementálásra és milyen sorrendben lesznek az implementált részrendszerek integrálva.

Implementáció• Komponensek implementálása (Implement

Components)– Az osztályok implementálása a tervezési modellben

meghatározott módon. A forráskódot elkészítése, a meglévő komponenseket alkalmazása, a fordítás, szerkesztés és unit tesztelés elvégzése.

– A felderített kód hibák kijavítása és újabb unit tesztek elvégzése a változtatások ellenőrzésére.

– A forráskód minőségének ellenőrzése a kód szemlézése során.• A részrendszerek integrálása (Integrate each

Subsystem)– Az új vagy módosított komponensek integrálása.

Implementáció

• A rendszer integrálása (Integrate the System) – Az integrációs terv alapján a rendszer

integrálása. Ennek során az átadott implementációs részrendszereket hozzáadják a rendszer integrációs munkaterülethez és felépítik a build-et. Minden build ezek után integrációs teszten és rendszerteszten megy keresztül.

Implementáció - tevékenységek

Implementáció - termékek

V.4. Tesztelés

Tesztelés

Az objektumok közötti kölcsönhatások ellenőrzése

Ellenőrizni a rendszer valamennyi komponensének integrációját

Ellenőrizni, hogy valamennyi követelmény megfelelően implementálva lett-e

A szoftver telepítését megelőzően megkeresni és kijavítani a hibákat

Tesztelés• Tesztelési stratégia kidolgozása (Plan Test)

– A tesztelési stratégia meghatározása, amely később implementálásra és végrehajtásra kerül.

– A tesztelési stratégia tartalmazza a teszteléssel kapcsolatos követelményeket, tesztelési típusokat, dokumentálási előírásokat és erőforrásokat.

• A teszttervek elkészítése (Design Test)– A tesztelési eljárások és tesz esetek leírása

• A tesztelés implementálása (Implement Test)– A teszttervekben leírt tesztelési eljárások

implementálása (rögzítése, generálása vagy programozása), a teszt scriptek elkészítése.

Tesztelés• Integrációs teszt végrehajtása (Execute tests in

Integration Test Stage)– Annak biztosítása, hogy a rendszer komponenseinek

együttműködése megfeleljen az elvárásoknak, valamint a rendszer új funkciói a megfelelő módon működjenek.

– Az újonnan beépített szolgáltatásokat nemcsak funkcionálisan tesztelik, hanem azt is megvizsgálják, hogy a rendszer előző verziójának szolgáltatásai nem romlottak-e el (regressziós teszt).

– Egy iteráción belül több integrációs teszt végrehajtása, míg a teljes rendszer (amit az adott iterációban célul tűztek ki) össze nem áll.

– Az iteráció végén a teljes rendszer tesztelése. Itt elsősorban a rendszer és az aktorok közötti kommunikációt vizsgálják.

Tesztelés

• Rendszerteszt végrehajtása (Execute Tests in System Test Stage)– A rendszerteszt célja annak biztosítása, hogy a teljes

rendszer az elvárásoknak megfelelően működik.• A tesztelés értékelése (Evaluate Test)

– A tesztelés eredményeinek értékelése, a felhasználói igények változásainak azonosítása és naplózása, a tesztelés mérőszámainak meghatározása. Ezek a tesztelt alkalmazás minőségén túl a tesztelés folyamatát is minősítik.

Tesztelés - tevékenységek

Tesztelés - termékek

V.5. Telepítés

Telepítés

Azoknak a tevékenységeknek a leírása, amelyek ahhoz

szükségesek, hogy a szoftver termék elérhető legyen a végfelhasználók számára

A munkafolyamat a szoftver telepítésének többféle módját fedi le

Telepítés• Telepítés tervezése (Plan Deployment)

– A telepítési terv elkészítése, amely meghatározza, hogy mikor és milyen módon lesz elérhető a szoftver termék a végfelhasználók számára.

– Az ügyfelekkel való együttműködés kialakítása, hiszen a telepítési terv elkészítéséhez szükségesek az ügyfelek előkészületei is. Gyakran a szoftver fejlesztésétől független tényezők hátráltatják egy szoftver termék bevezetését, például a hardver infrastruktúra hiánya, vagy a nem megfelelően képzett felhasználók.

– A rendszer supportjára, a felhasználók képzésére vonatkozó tevékenységek beépítése a telepítési tervbe.

Telepítés• A rendszer használatához szükséges eszközök,

dokumentációk elkészítése (Develop Support Material)– Minden olyan információ biztosítása, amely szükséges a

végfelhasználóknak a rendszer telepítéséhez, használatához és karbantartásához. Ide sorolhatjuk a különböző oktatási anyagokat is.

• Átvételi teszt végrehajtása (Manage Acceptance Test)– Annak biztosítása, hogy a fejlesztett szoftver megfelel az átvételi

követelményeknek. Ezt a tesztelést a fejlesztés helyén, a fejlesztési környezetben is végre kell hajtani, valamint a telepített terméket tesztelni kell az ügyfél telephelyén is, a cél környezetben.

Telepítés• Telepítési csomag kidolgozása (Produce Deployment

Unit)– A telepítési csomag elkészítése, amely a szoftver mellett azokat

a termékeket tartalmazza, amelyek az installáláshoz és a használathoz szükségesek. A telepítési csomag több célból is létrejöhet. Létrehozhatjuk béta tesztelés, vagy végső telepítés céljából.

• A termék csomagolása (Package Product)– A dobozos termék telepítéséhez szükségesek tevékenységek

meghatározása. A munkafolyamat során el kell készíteni a telepítési csomagot, az installáló scriptet, a felhasználói kézikönyvet, majd mindezekből elő kell állítani a kész terméket.

Telepítés

• A termék interneten keresztül történő letöltésének lehetővé tétele (Provide Access to Download Site)– A termék megrendelésének és letöltésének lehetővé

tétele az interneten keresztül.• A termék béta tesztelése (Beta Test Product)

– Egy béta program előkészítése, amely lehetővé teszi, hogy a fejlesztés alatt álló termékkel kapcsolatban hozzájussunk a potenciális felhasználók visszajelzéseihez. A béta program létrehozása lehet felhasználói igény is.

Telepítés - tevékenységek

Telepítés - termékek

Telepítési modell

dd Telepítési Modell

Kliens gép

Szerv er gép

«executable»Program

Adatbázis szerver

Adatbázis

«protokoll»

A modellek kapcsolatai

od A modellek és a fej lesztés folyamata

Elemzés

Terv ezés

«modell»Üzleti folyamat

modell

«modell»Használati eset

modell

«modell»

Domain modell«modell»

Analízis modell

Felhasználói felületek

«modell»Logikai modell

«modell»

Komponens modell

«modell»Telepítési modell

Opcionális

Az implementáció alapja

Implementációs modell 1

Implementációs modell 2

Implementációs modell n

UML diagramok – rövid összefoglaló

Diagramok UML 1.x-ben- 9 diagram -

Dinamikus nézet

– eseménykövetési diagram– együttműködési diagram– állapot diagram– tevékenység/aktivitás diagram

Statikus nézet

– use case diagram–objektum diagram– osztály diagram– komponens diagram– működési/telepítési diagram

UML diagramok– használati eset diagramok : (követelmények)

• bemutatja a valós rendszer szereplőit, a szereplők kapcsolatát

• a szereplők által végzett tevékenységeket,• a rendszert statikus aspektusból közelítve a fenti

összefüggésben ábrázolja.

– osztály/objektum diagramok (statikus architektúra):

• leírja az objektumok típusát a rendszerben, és az ezek között fennálló különböző változatú, fajta statikus kapcsolatokat, viszonyrendszert

UML dinamikus viselkedés-leírás

–interakciós diagramok• eseménykövetési diagramok• együttműködési diagramok

–tevékenység/aktivitás diagramok–állapot diagramok kódgenerálás

Az UML dinamikája• interakciós diagramok:

– tipikus alkalmazás: egy use case viselkedésének leírása, ahol a diagramok segítségével az adott use case-ben megnyilvánuló objektumok és azok együttműködésének (objektumok közötti üzenetváltás) vizsgálata

• aktivitás diagramok:– egy UC (használati eset) formalizálása, megértése– az általános működés követése több use case-en

keresztül - workflow modellezés (több UC közötti kapcsolat)– a párhuzamos működés tervezése - metódusok

összekapcsolása (többszálú alkalmazás)

A dinamikus viselkedés elemei

• Esemény (event)• Művelet (operation) - osztályok által nyújtott

szolgáltatás (metódus)

• Üzenet (message)– Esemény vagy művelet

A dinamikus viselkedés elemei

• Állapot (state):– egy objektum állapota – meghatározza:

- attribútumok értékei (pl. x<3)- feltételek teljesülnek (pl. művelet végrehajtható)

• Állapotátmenet:– állapot változása– bejövő üzenet hatására (triggerelt)

vagy önállóan (null trigger) • Akció: az objektum által végzett műveletek

UML konceptuális modellje

Az UML konceptuális modellje

• Elemek.• Elemek egymáshoz való viszonya.• Szabályrendszer a nyelv használatára.• Négy komponensből áll:

– architektúra,– építőelemek,– szabályrendszer,– általános nyelvi mechanizmus.

Konceptuális modell - Architektúra

• Modellnézetek képezik:– A modellnézetek szoros kapcsolatban vannak

egymással.– A rendszer különböző aspektusainak

absztrakcióit tükrözik.• Az UML öt nézetet javasol.

Konceptuális modell - architektúra

• Az UML öt nézetet javasol:– use case nézet,– logikai nézet,– komponens nézet,– folyamat nézet,– telepítési/működési nézet.

telepítési nézet

folyamat nézet

komponens nézet

Az UML öt nézete

use case nézet

logikai nézet

Architektúra – Use Case nézet

• A use case nézet:– a rendszer funkcionalitását írja le,– definiálja a szerepköröket és funkciókat.

Architektúra – Logikai nézet

• A logikai nézet:– tervezési nézet (design view),– tervezők, programfejlesztők számára fontos,– a rendszer belső struktúráját írja le,– a rendszer statikus elemeit és struktúráját,

valamint– az objektumok együttműködésének a formáját

írja le.

Architektúra – Folyamat nézet

• A folyamat nézet:– a rendszert folyamataira és a végrehajtó

elemekre tagoljuk,– párhuzamosan végezhető műveletek

feltárása,– a programfejlesztők és rendszerintegrátorok

számára fontos feladatok.

Architektúra – Komponens nézet

• A komponens nézet:– a rendszer megvalósítása,– programkomponensek és állományok

specifikációja és függőségi viszonyai kerülnek meghatározásra,

– leírás komponens diagramokkal,– főleg a programfejlesztők

feladatvégrehajtása.

Architektúra – Telepítési nézet

• A telepítési nézet:– a rendszer fizikai működésének

megvalósítása, a fizikai architektúra, – hardver topológia: számítógépegységek

(node - csomópontok) és elemek leírása,– programfejlesztők, rendszerintegrátorok,

tesztelők feladatai.

Építőelemek

• Az építőelemek az egyes modellnézeteket reprezentáló diagramokba rendezhetők.

• Csoportjai:– elemek,– relációk, kapcsolatok,– diagramok.

Elemek

• Az elemek három további csoportba sorolhatók:– strukturális elemek,– viselkedési elemek, – csoportosítási elemek.

Strukturális elemek

• use case-ek,• osztályok,• aktív osztályok,• interfészek,• komponensek,• együttműködés,• csomópontok.

Viselkedési elemek

• interakciók,• állapot-gépek.

Csoportosítási elemek

• csomagok,• modellek,• alrendszerek,• keretrendszer.

Relációk, kapcsolatok

• függőség,• asszociációk,• generalizáció.

Diagramok

• use case diagram,• osztály diagram,• objektum diagram,• szekvencia diagram,• együttműködési diagram,• állapot átmenet diagram• komponens diagram,• telepítési diagram.

Nyelvi szabályrendszer

• A szabályok olyan szemantikai előírások, amelyek azt határozzák meg, hogy hogyan kell a nyelvi elemeket használni, értelmezni a rendszer különböző nézeteiben és a nézetek során létrehozott modellekben.

Nyelvi szabályrendszer

• A modell-elemek tervezésénél figyelembe veendő sajátosságok:– azonosításra szolgáló Név (megkülönböztető

képességgel kell, hogy rendelkezzenek),– értelmezés (az adott névvel azonosított

rendszerelemeket egyértelműsíti),– láthatóság,– integritás (az elemek egymáshoz való

kapcsolódásának a módját és következetes alkalmazását kifejezi az integritás foka),

– végrehajtási szabályok – megvalósítás feltételei.

Általános nyelvi mechanizmus

• Megjegyzések kezelésére,• a modell elemek sajátosságainak

pontosítására vonatkozik.• Lehetőség van a nyelvi elemek

bővítésére, ezáltal mód van az UML nyelvet speciális alkalmazásokhoz, feladatokhoz, felhasználókhoz, módszerekhez illeszteni.

Általános nyelvi mechanizmus

• Az UML nyelv mechanizmusok:– specifikációk: az adott építőelem szintaktikai

és szemantikai szabványos leírása,– szimbólumrendszer és kiegészítő információk,– megosztottság,– kiterjesztési mechanizmus:

• sztereotípiák,• megszorítások,• hozzárendelt érték (pl. az elem verziószáma, vagy

a létrehozó személye).

A RUP modelljei

• üzleti és domén modell,• use case modell,• elemzési modell,• tervezési modell,• implementációs modell,• fizikai megvalósítási modell,• tesztmodell.

uml-alapú fejlesztés

Documents