Információrendszerfejlesztés II. 2006. március 6. 1 Információk, elérhetőségek Kovács Katalin A 606-os szoba Tel.: 06-96-613-618 E-mail: kovacsk@sze.hu Konzultációs időpont: Hétfő: 15 17 óra 2006. március 6. 2
IR-fejlesztés II. Irodalom: Ian Sommerville: Software Engineering 7 Roger S Pressman: Software Engineering: A Practitioner's Approach Sziray J., Kovács K.: Az UML nyelv alapjai 2006. március 6. 3 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. 2006. március 6. 4
Engineering Mérnöki munka rendszerek létrehozására (~ fejlesztés) Építő mérnök Gépész mérnök Villamos mérnök Szoftver mérnök Modellezés általános eszköz leendő rendszer leírása, specifikációja, terve 2006. március 6. 5 System Engineering és Software Engineering 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. 2006. március 6. 6
Rendszerfejlesztés Rendszerfejlesztés alapkérdései Általános értelemben vett rendszer fejlesztés Rendszerfejlesztés lehet: Business Process Engineering ha vállalat (működésének) (át)szervezésével foglalkozunk Product Engineering ha egy termék előállítása a cél pl.: mobil telefon, repülőgép vezérlő rsz. Szoftverfejlesztési folyamat 2006. március 6. 7 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) 2006. március 6. 8
Vízesés modell 2006. március 6. 9 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. Rendszerfejlesztés System Eng. 2006. március 6. 10
Módszerek, modellek Rendszerek tervezése, fejlesztése Rendszerfejlesztési módszerek Szoftverrendszerek fejlesztése Szoftverfejlesztési módszerek (módszertanok) 2006. március 6. 11 BMW elv Rendszerfejlesztés területén segít a rendszerek tervezésében. BMW: Beschreibungsmittel Methode Werkzeug. 2006. március 6. 12
BMW elv Központi gondolat: Bármelyik módszertan három komponens: Leíróeszköz Módszer Támogatóeszköz megfelelő kombinációja. Az elv alkalmazásával a rendszerek tervezéséhez megfelelően lehet kiválasztani: A módszert, Leíró és Támogatóeszközt. 2006. március 6. 13 BMW elv Módszer: Szabályrendszerre épülő, tárgya és célja szerint tervszerű, ismeretek és gyakorlati eredmények megszerzésére irányuló eljárás. Leíróeszköz: A viselkedés leírására, formalizálására szolgáló eszköz. Támogatóeszköz: Valamely leíróeszköz számítógépes alkalmazását segítő szoftver. 2006. március 6. 14
Módszertan Modellező nyelv Eljárások Módszertan 2006. március 6. 15 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. 2006. március 6. 16
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ége lehet. 2006. március 6. 17 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. 2006. március 6. 18
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. 2006. március 6. 19 IR-fejlesztés II. Rendszerfejlesztési folyamat Szoftverfejlesztési folyamat Szoftverfejlesztés strukturált szemléletben 2006. március 6. 20
Fázisok 2006. március 6. 21 SE fázisok Ü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 feladatok Támogató munkafolyamatok 2006. március 6. 22
SE fázisok mérnöki feladatok 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. 2006. március 6. 23 SE fázisok mérnöki feladatok 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. 2006. március 6. 24
Támogató feladatok a fejlesztés során Azok 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. 2006. március 6. 25 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. 2006. március 6. 26
Ciklusok Egy fejlesztési ciklusnak nevezzük azt az időtartamot, amíg egyszer végigmegyünk mindegyik fázison és előáll a szoftver egy generációja, verziója. A szoftvert az új igényeknek megfelelően folyamatosan fejleszteni, javítani kell. Ilyenkor újabb és újabb fejlesztési ciklusok következnek, amelyek szintén végigmennek a fejlesztési fázisokon és a szoftver újabb és újabb generációját állítják elő. Ezeket a fejlesztési ciklusokat evolúciós ciklusoknak nevezzük. Az evolúciós ciklusoknál általában eltérően alakul a fázisok aránya. 2006. március 6. 27 Fejlesztési fázisok 2006. március 6. 28
Ü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égeit Biztosítani, hogy az ügyfelek, végfelhasználók és fejlesztők egységes képet kapjanak az adott szervezetről A szervezetet támogató rendszerrel szemben felmerülő követelmények felderítése 2006. március 6. 29 Ü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. 2006. március 6. 30
Üzleti modellezés 2006. március 6. 31 Ü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. 2006. március 6. 32
Ü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. 2006. március 6. 33 Üzleti modellezés Az üzleti folyamatok azonosítása (Identify Business Processes) 2006. március 6. 34
Üzleti modellezés - tevékenységek 2006. március 6. 35 Üzleti modellezés - termékek 2006. március 6. 36
od A diplomamunka kezelésének folyamata A ké t esemén y kö zött meg határozatlan hosszúságú idõ telik el Diplomaterv beé rkezése a Tan szé kre Dip lo mamunka beérkezé se a Tanszé kre Diplomamunka - diplomaterv: - ko nzu le nsi la p: - kido lg ozo tt téma : Diplomaterv - szerzõ ada ta i: - kon zulen s ada ta i: - té ma b emutatása: - elfog adá s ke lte: Diplomaterv elbírálása Részleteszõ diagram Diploma te rv felvé te le enge délye zés vag y elu ta sítás [elfogad ás esetén ] Diploma te rv e k nyilv á nta rtás a Diplomamunka beérkeztetése, elbírálása Részletezõ diagram Bírálat - b íráló vélemé nye : - o sztályzat: bíráló és bírálat b ejegyzése Diploma -terv dokumentum B írálat dokumentum Elbírá lt terv visszakü ld ése Elbírált diplomamu nka visszaküldése D.O-ra A szakterület folyamatai (üzleti folyamat diagram) (Diplomáztatás esettanulmány) A két esemény között meghatározatlan hosszúságú idõ telik el Diplomaterv ek nyilv ántartása Diplomamunka - diplomaterv: - konzulensi lap: - kidolgozott téma: bíráló és bírálat bejegyzése Diplomamunka beérkezése a Tanszékre Diplomamunka beérkeztetése, elbírálása Részletezõ diagram visszaküldése D.O-ra Bírálat - bíráló véleménye: - osztályzat: Bírálat dokumentum 2006. március 6. 37 Szakterületi modell (Diplomáztatás esettanulmány) cd Szakterületi osztálydiagram Fejlesztõeszköz - megnevezés: DiplomaTerv - szerzõ neve: - fejlesztõeszköz: - konzulens: - tanszék: - cím: - témavázlat: +közremûködik Konzulens - név: +használja - név: Szerzõ +elkészíti +elkészíti +közremûködik Diplomamunka - diplomaterv: - konzulensi vélemyény: - kidolgozás: +jóváhagyja +kijelöli +bírálatra kiadja +kijelöli Tanszéki felelõs +képviseli Bírálat - bíráló neve: - osztályzat: - szöveg: +elbírálja +elkészíti Bíráló - név: Tanszék - megnevezés: 2006. március 6. 38
Követelmény (elemzés) 2006. március 6. 39 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 2006. március 6. 40
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 2006. március 6. 41 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. 2006. március 6. 42
Követelményelemzés A tervezett szoftverrendszernek kívülről, a felhasználó szempontjából történő leírását adja meg. 2006. március 6. 43 Követelményelemzés 2006. március 6. 44
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. 2006. március 6. 45 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. 2006. március 6. 46
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. 2006. március 6. 47 Követelmények 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. 2006. március 6. 48
Követelmények 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. 2006. március 6. 49 Követelmények feltárását, összegyűjtését segítő technikák tipikus módszerek: megbeszélés, interjú FAST (Facilitated Application Specification Techniques) QFD (Quality Function Deployment) Use Case technika, amelynek segítségével különböző scenáriókat készíthetünk az előzőekben felsorolt technikákkal feltárt/meghatározott követelmények alapján, a scenáriókkal leírható ahogy a rendszer viselkedni fog adott szituációkban. 2006. március 6. 50
Követelmények feltárását, összegyűjtését segítő technikák 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? 2006. március 6. 51 Követelménykezelés és az analízis a fejlesztésben Rendszerfejlesztés Szoftver követelmények, elemzés Szoftver tervezés 2006. március 6. 52
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 2006. március 6. 53 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. 2006. március 6. 54
Felhasználói követelmények 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. 2006. március 6. 55 Felhasználói követelmények 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). 2006. március 6. 56
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. 2006. március 6. 57 Felhasználói követelmények 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. 2006. március 6. 58
Funkcionális és nem funkcionális 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. 2006. március 6. 59 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. 2006. március 6. 60
Funkcionális követelmények 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. 2006. március 6. 61 Funkcionális követelmények 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. 2006. március 6. 62
Szervezet, vállalati belső környezet Fejlesztendő szoftverrendszer Felhasználók, akik fejlesztendő alkalmazást működtetik SW alkalmazások Külső rendszerek Külső szereplők, akik fejlesztendő alkalmazás szolgáltatásait igénybe veszik 2006. március 6. 63 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. 2006. március 6. 64
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. 2006. március 6. 65 Tesztelés követelmények alapján 2006. március 6. 66
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. 2006. március 6. 67 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). 2006. március 6. 68
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. 2006. március 6. 69 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. 2006. március 6. 70
Szoftvertesztelés alapsémája Referencia (követelmény specifikáció, prototípus, rendszermodell stb.) referencia kimenet bemeneti sorozat viselkedés, állapot megfigyelése Értékelés (viselkedés, kimenetek összehasonlítása) eredmény Tesztelt szoftver software under test, SUT SUT kimenet 2006. március 6. 71 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 UMLben 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 casenek. 2006. március 6. 72
Követelmények megvalósításának ábrázolása EA-ban ud Követelmé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 EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version ÁrajánlatbólRendelés EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version ÁrajánlatKészítés ÁrajánlatKészítés ÁrajánlatMódosítás EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version ÁrajánlatKészít_Weben EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version 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ánlatLekérdez_Weben ÁrajánlatMódosít_Weben EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version 2006. március 6. 73 Követelményelemzés 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. 2006. március 6. 74
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. 2006. március 6. 75 Ú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. 2006. március 6. 76
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. 2006. március 6. 77 Ú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 2006. március 6. 78
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. 2006. március 6. 79 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). 2006. március 6. 80
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. 2006. március 6. 81 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. 2006. március 6. 82
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. 2006. március 6. 83 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 2006. március 6. 84
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. 2006. március 6. 85 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. 2006. március 6. 86
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. 2006. március 6. 87 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. 2006. március 6. 88
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 2006. március 6. 89 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. 2006. március 6. 90
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. 2006. március 6. 91 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. 2006. március 6. 92
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. 2006. március 6. 93 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. 2006. március 6. 94
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. 2006. március 6. 95 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. 2006. március 6. 96
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? 2006. március 6. 97 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 caseeknek (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. 2006. március 6. 98
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. 2006. március 6. 99 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; 2006. március 6. 100
A use case-ekre vonatkozó jellemzők, sajátosságok a use case-eket minden esetben az aktorok kezdeményezik; 2006. március 6. 101 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. 2006. március 6. 102
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. 2006. március 6. 103 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ó 2006. március 6. 104
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. 2006. március 6. 105 Use case leírás Normál működés: a use case szokásos működését 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 use case-ek normál és alternatív működését külön forgatókönyvekben rögzítjük. 2006. március 6. 106
Forgatókönyv Más szóval szcenárió. A use case egy konkrét végrehajtása, lefutása, a use case egy instanciája (példánya). A use case működésének lépésenkénti, un. step-by-step végrehajtását írja le a felhasználó szemüvegén keresztül. Egy use case-hez az alternatív működések miatt több forgatókönyv készülhet, de egy biztosan. 2006. március 6. 107 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. 2006. március 6. 108
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. 2006. március 6. 109 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. 2006. március 6. 110
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? 2006. március 6. 111 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. 2006. március 6. 112
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. 2006. március 6. 113 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. 2006. március 6. 114
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. 2006. március 6. 115 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. 2006. március 6. 116
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. Aktivitási diagram 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! ] 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 megerősítést kér az Ügyféltől az Árajánlat elfogadására. [ Árajánlat Elutasítva! ] 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. 2006. március 6. 117 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. 2006. március 6. 118
Kapcsolatok A kapcsolatot a diagramban az aktorokat és a use case-eket összekötő vonal szimbolizálja. A vonal lehet irányított. 2006. március 6. 119 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 2006. március 6. 120
Aktorok és use case-ek között értelmezett kapcsolatok típusa 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. 2006. március 6. 121 Kezdemenyező szereplő use case 2006. március 6. 122
Példa Regisztrál ÁrajánlatKészít_Weben ÁrajánlatLekérdez_Weben Ügyfél (from use case view) (from aktorok) ÁrajánlatMódosít_Weben ÁrajánlatNyomtat_Weben (from use case view) (from use case view) 2006. március 6. 123 Aktorok és use case-ek között értelmezett kapcsolatok típusa 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. 2006. március 6. 124
Résztvevő szereplő1 Kezdemenyező szereplő use case Résztvevő szereplő2 2006. március 6. 125 Speciális kapcsolatok Két aktor közötti kapcsolatot. Definiálhatunk use case-ek közötti speciális viszonyokat is. 2006. március 6. 126
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ő. 2006. március 6. 127 Speciális kapcsolat két aktor között 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 2006. március 6. 128
Speciális kapcsolat két aktor között Ős szereplő use case/funkció Leszármazott szereplő1 Leszármazott szereplő2 2006. március 6. 129 Speciális kapcsolat két aktor között Kereskedő Kereskedelmi Menedzser 2006. március 6. 130
Speciális kapcsolatok use case-ek között Három speciális viszony: tartalmazás, kiterjesztés és öröklődés viszonyokat. 2006. március 6. 131 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. 2006. március 6. 132
Tartalmazás include viszony 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. 2006. március 6. 133 Tartalmazás include viszony 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. 2006. március 6. 134
Tartalmazás include viszony alap/normál use case1 <<include>> szereplő/aktor alap/normál use case2 <<include>> tartalmazott (included) use case 2006. március 6. 135 Tartalmazás include viszony ÁrajánlatKészít_Weben <<include>> <<include>> Ügyfél (from aktorok) ÁrajánlatMódosít_Weben (from use case view) <<include>> ÜgyfélAzonosítás_ felhasználói név&jelszó (from use case view) ÁrajánlatLekérdez_Weben (from use case view) 2006. március 6. 136
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. 2006. március 6. 137 Kiterjesztés extend viszony 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. 2006. március 6. 138
Kiterjesztés extend viszony <<extend>> szereplő/aktor alap/normál use case kiterjesztett (extended) use case 2006. március 6. 139 Kiterjesztés extend viszony <<extend>> Kereskedő (from aktorok) MegrendelésKészít (from Kereskedő use case-ei) Kedvezményzárolás 2006. március 6. 140
Ö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. 2006. március 6. 141 Öröklődés generalizáció 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. 2006. március 6. 142
Öröklődés generalizáció szereplő/aktor use case leszármazott use case 2006. március 6. 143 Öröklődés generalizáció Kereskedő ÜgyfélTörzsadatFelvitel (from aktorok) <<generalization>> ÜgyfélTörzsadatKarbantartás 2006. március 6. 144
Use case modell Aktorok. Use case-ek. Use case-ek struktúrálása. Kapcsolatok. Ábrázolás: Use case diagram. 2006. március 6. 145 Use case 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. 2006. március 6. 146
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. 2006. március 6. 147 ÜgyfélTörzsadatFelvitel <<generalization>> (from ÜgyféltörzsKezelés) ÁrajánlatKészítés (from ÁrajánlatKezelés) ÁrajánlatMódosítás (from ÁrajánlatKezelés) ÜgyfélTörzsadatKarbantartás (from ÜgyféltörzsKezelés) Kereskedő (from aktorok) ÁrajánlatbólRendelés (from ÁrajánlatKezelés) <<extend>> MegrendelésKészítés (from Kereskedő use case-ei) Kedvezmény zárolása (from use case view) Kereskedelmi Menedzser (from aktorok) KedvezményTörlése (from use case view) KedvezményJóváhagyása (from use case view) 2006. március 6. 148
Ügyfél által kezdeményezett use caseeket összefoglaló use case diagram Regisztrál ÁrajánlatotKészít _Weben <<include>> Ügyfél ÁrajánlatotLekérdez _Weben <<include>> ÜgyfeletAzonosít_ felhasználóinév&jelszó ÁrajánlatotNyomtat _Weben 2006. március 6. 149 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. 2006. március 6. 150
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. 2006. március 6. 151 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. 2006. március 6. 152
2006. március 6. 153 Követelmény AZ Forrás Prioritás Tulajdonos Funkcionális követelmény Nem funkcionális követelmény Haszon: Megjegyzések/ javasolt megoldási módok Kapcsolódó iratok Kapcsolódó követelmények egyedi azonosító a követelmény forrása, lehet személy, dokumentum stb. a követelmény prioritása, a felhasználó szerint, pl. magas/alacsony, vagy kötelező/ javasolt/ választható felhasználó vagy felhasználói szervezet, aki a követelménnyel kapcsolatos egyezkedésért felelős az igényelt lehetőség vagy szolgáltatás leírása leírás, lehetőség szerint cél értékkel, elfogadható tartománnyal (minimum, maximum), minősítő megjegyzéssel a követelmény kielégítéséből származó várható hasznok leírása lehetséges megoldások leírása, általános megjegyzések hivatkozás kapcsolódó dokumentumokra, mint például felhasználói dokumentumok, projektalapító okirat, adatfolyam-ábra stb. ha 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 a követelmény megoldási módjának feljegyzése, például egy konkrét funkcióleírásra Megoldás való hivatkozással. Ha egy követelményt nem fogunk kielégíteni, akkor itt kell felírni az okait 2006. március 6. 154
Use case-ek szerepe a követelménykezelés és az elemzés és tervezési egyes fázisokban 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 é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. 2006. március 6. 155