Információrendszerfejlesztés. Információk, elérhetőségek

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: [email protected] Konzultációs időpont:

2006. március 6.

Hétfő: 15 – 17 óra

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

2006. március 6.

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.

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…)

2006. március 6.

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.

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

Szoftverfejlesztés lépései

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. Fázisok

Szoftverfejlesztési modellek, módszertanok:

2006. március 6.

struktúrált (vízesés modell, Boehm-féle spirálmodell, V modell stb.) objektumorientált (OMT, OOA/OOD, Bocch2, RUP) 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 Software Implementation – Implementáció eng. Testing – Tesztelés, Telepítés Karbantartás, Rendszerkövetés, Továbbfejl.

2006. március 6.

10

Rendszerfejlesztés – System Eng.

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:

2006. március 6.

Beschreibungsmittel Methode Werkzeug.

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:

Leíróeszköz:

Szabályrendszerre épülő, tárgya és célja szerint tervszerű, ismeretek és gyakorlati eredmények megszerzésére irányuló eljárás. A viselkedés leírására, formalizálására szolgáló eszköz.

Támogatóeszköz:

2006. március 6.

Valamely leíróeszköz számítógépes alkalmazását segítő szoftver. 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:

2006. március 6.

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.

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 Mérnöki feladatok Implementáció Tesztelés Telepítés Konfiguráció és változás-kezelés Támogató Projektvezetés munkafoKörnyezet kialakítása lyamatok

2006. március 6.

22

SE fázisok – mérnöki feladatok A fejlesztési munka konkrét feladatai: Üzleti modellezés (Business Modeling)

Követelmény-elemzés (Requirements)

Cél megérteni annak a szervezetnek a felépítését, folyamatait, amely támogatására az alkalmazást fejlesztjük. 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)

Tesztelés (Test)

Cél a terv alapján a rendszert alkotó komponensek implementálása, egységtesztjeinek elvégzése és integrálása. 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)

2006. március 6.

Cél a kész alkalmazást elérhetővé tenni a felhasználó számára.

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

Projektvezetés

Cél a fejlesztés során előálló termékek verzióinak kezelése. 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:

2006. március 6.

Értékelni az eddigi eredményeket, Dönteni a folytatásról.

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

2006. március 6.

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 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)

2006. március 6.

A fejlesztett rendszer által támogatott szervezet (cél szervezet) állapotának felderítése.

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

A szakterület folyamatai (üzleti folyamat diagram) (Diplomáztatás esettanulmány) od A diploma munka k eze lé sének folyamata Diplomaterv -

Dipl om a -terv do kum e ntum

szerzõ ada ta i: kon zul en s ada ta i: té ma b em utatása: el fog adá s ke lte:

enge dél ye zés vag y elu ta sítás Di pl om aterv beé rkezése a Tan szé kre

Diplomaterv ek nyilv ántartása

A két esemény között meghatározatlan hosszúságú idõ telik el

El bírá lt terv vi sszakü ld ése

Diplomaterv e lbírálása Részl eteszõ di ag ra m Di pl om a te rv fel vé te le [el fogad ás esetén ]

Diploma te rv e k nyilv á nta rtás a

A ké t esem én y kö zött m eg határozatl an ho sszúság ú idõ tel i k el Diplomamunka -

Diplomamunka -

diplomaterv: konzulensi lap: kidolgozott téma:

Diplomamunka beérkezése a T anszékre

di pl om aterv: ko nzu le nsi la p: ki do lg ozo tt tém a :

Dip lo m am unka beérkezé se a Tanszé kre

b írál ó és b írál at b ej egyzése

Diplomamunka beé rke ztetése , elbírá lá sa Ré szle te zõ di agram

Bírálat -

bíráló és bírálat bejegyzése

Diplomamunka beérkeztetése, elbírálása Részletezõ diagram

visszaküldése D.O-ra

Bírálat dokumentum

Bírálat -

El bírál t di pl om am u nka visszaküld ése D.O-ra

B írál at d okum entum

b írál ó vél em é nye : o sztál yzat:

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

2006. március 6.

37

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

cd Szakterületi osztálydiagram DiplomaTerv -

Fej lesztõeszköz -

megnevezés:

szerzõ neve: fejlesztõeszköz: konzulens: tanszék: cím: témavázlat: +közremûködik Konzulens -

+használja Szerzõ -

név:

+elkészíti

név: +jóváhagyja

+közremûködik

+elkészíti

+kijelöli

Diplomamunka -

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

+bírálatra kiadja Tanszéki felelõs

+kijelöli

+képviseli

+elbírálja Bírálat -

2006. március 6.

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

+elkészíti

Bíráló -

Tanszék -

megnevezés:

név:

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.

2006. március 6.

A rendszerhez a felhasználói igényeknek megfelelő felhasználói interfész meghatározása. 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:

2006. március 6.

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. 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? 51

2006. március 6.

Követelménykezelés és az analízis a fejlesztésben

Rendszerfejlesztés

2006. március 6.

Szoftver követelmények, elemzés

Szoftver tervezés

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


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


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


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


A felhasználói követelmények alapot képeznek:

2006. március 6.

a szoftverrendszertől elvárt konkrét szolgáltatások (szoftverfunkciók, amiket a szoftver csinál) meghatározására.

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:

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


A funkcionális követelmények:

2006. március 6.

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. 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

2006. március 6.

időbeli korlátozások, szabványok, hardver és szoftverkörnyezeti előírások, teljesítménykövetelmények, stb.

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ó:

2006. március 6.

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). 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.

2006. március 6.

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.

70

Szoftvertesztelés alapsémája

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

bemeneti sorozat

viselkedés, állapot megfigyelése

Tesztelt szoftver software under test, SUT

referencia kimenet

Értékelés (viselkedés, kimenetek összehasonlítása)

eredmény

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ö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 Á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 á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

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 Áraj ánlatMódosít_Weben

EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version Áraj ánlatLekérdez_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.

2006. március 6.

A rendszerhez a felhasználói igényeknek megfelelő felhasználói interfész meghatározása. 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:

2006. március 6.

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. 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

2006. március 6.

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

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:

2006. március 6.

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

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:

2006. március 6.

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. 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


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.

2006. március 6.

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. 88


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:

2006. március 6.

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. 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ő:

2006. március 6.

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. 98

Példa Black-box módszer a rendszer (külső) viselkedésének leírására Á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.

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

Á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

2006. március 6.

use case/funkció

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:

Alternatív esetek:

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. 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:

2006. március 6.

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.

112

Példa

A szokásostól eltérő működéskor a lehetséges lefutások, alternatív útvonalak:

2006. március 6.

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. 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


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 <> sztereotípiával jelölhetjük.

2006. március 6.

121

Kezdemenyező szereplő

2006. március 6.

use case

122

Példa Regisztrál ÁrajánlatKészít_Weben

ÁrajánlatLekérdez_Weben (from use case view)

Ügyfél (from aktorok)

ÁrajánlatMódosít_Weben ÁrajánlatNyomtat_Weben

(from use case view)


2006. március 6.

123


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:

2006. március 6.

leszármazott, ős szereplő.

127


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


use case/funkció

Ős szereplő

Leszármazott szereplő1

Leszármazott szereplő2

2006. március 6.

129


Kereskedő

2006. március 6.

Kereskedelmi Menedzser

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


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


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 <> sztereotípiával jelöljük.

2006. március 6.

134


<> alap/normál use case1

tartalmazott (included) use case

<>

szereplő/aktor

alap/normál use case2

2006. március 6.

135


<>

ÁrajánlatKészít_Weben

<>

Ügyfél (from aktorok)

ÁrajánlatMódosít_Weben

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



<>

Á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


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


<<extend>>

szereplő/aktor

alap/normál use case

kiterjesztett (extended) use case

2006. március 6.

139


<<extend>>

Kereskedő (from aktorok)

2006. március 6.

MegrendelésKészít

Kedvezményzárolás

(from Kereskedő use case-ei)

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


Az öröklődés jele:

2006. március 6.

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.

142


szereplő/aktor

use case

leszármazott use case

2006. március 6.

143


Kereskedő

ÜgyfélTörzsadatFelvitel

(from aktorok)

<>

Ü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:

2006. március 6.

a rendszer viselkedésének megértésében grafikus modellezésében. 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 <> (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

Kedvezmény zárolása

(from Kereskedő use case-ei)


Kereskedelmi Menedzser (from aktorok)

2006. március 6.

KedvezményTörlése

KedvezményJóváhagyása



148

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

Regisztrál <> ÁrajánlatotKészít _Weben <> ÜgyfeletAzonosít_ felhasználóinév&Jelszó

Ügyfél ÁrajánlatotLekérdez _Weben

Á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:

2006. március 6.

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. 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

egyedi azonosító Követelmény AZ 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ények

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

Megoldás

a 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

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:

2006. március 6.

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. 155

Információrendszerfejlesztés. Információk, elérhetőségek

Recommend Documents