Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

2. ELŐADÁS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 1.

Hasonló előadás


Az előadások a következő témára: "2. ELŐADÁS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 1."— Előadás másolata:

1 2. ELŐADÁS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 1

2 Az 1. előadás tartalmából Projekt A vezető feladatai A projekttervezési és vezetési folyamat Hierarchikus tevékenység/feladat lebontás Mérföldkövek és részeredmények Tevékenység – Időtartam – Függőségek - Erőforrások Ütemezés Kockázatkezelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 20142 Ismétlés

3 A projekttervezési és vezetési folyamat 1. Projektcél? A projekt megszorításai Szervezeti keretek, felelősök A projekt paramétereinek kezdeti összegzése A projekt részeredményeinek és mérföldköveinek definiálása A dokumentálás módjának és szabályainak lefektetése Kockázatelemzés Kiinduló ütemterv elkészítése Projekt indító értekezlet Ismétlés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 20143

4 A projekttervezési és vezetési folyamat 2. Amíg a projekt nincs kész, vagy nem vonták vissza, addig elindítani az ütemtervnek megfelelő tevékenységeket átvizsgálni a projekt előrehaladását felülvizsgálni a projekt paramétereinek becslését frissíteni a projekt ütemtervét ha probléma merül fel elindítani a műszaki felülvizsgálatokat és a lehetséges átdolgozásokat újratárgyalni a projekt megszorításait és részeredményeit ciklus vége Projekt lezárása Ismétlés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 20144

5 SWOT elemzés Belső tényezők Strengthserősségek Weaknessesgyengeségek Külső tényezők Opportunitieslehetőségek Threatsveszélyek Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 20145

6 SWOT elemzés (vállalati példa)

7 Erősségek Meghatározó a vállalat piaci szerepe? Jó a vásárlók véleménye? Fejlett technológiát használ a vállalat? Egyedülálló versenyelőnnyel rendelkezik? Jók a piaci erőforrásai? Gazdaságos üzemméretet használ? Jó a vállalat menedzsmentje? Kimagasló szakértelműek az alkalmazottak? Sikeres a vállalati stratégia? Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 20147

8 Gyengeségek Elavult a technológia? Romlik a piaci pozíció? Nincs egyértelműen meghatározott stratégia? Hiányzik a megfelelő szakértelem? Elhasználódtak a létesítmények? Rossz a vállalat imázsa? Nem sikeres a kutatás-fejlesztési részleg? Rosszul funkcionál a menedzsment? A pénzügyi háttér nem rendezett? Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 20148

9 Lehetőségek Gyorsabb piaci növekedés? Kiegészítő termékek fejlesztése? Új piacokra való belépés? Új technológia alkalmazása? A termékcsoport továbbfejlesztése? További célcsoportok feltérképezése? Egy nyersanyagforrás megszerzése? Beszállítás helyett saját előállítás? Új szervezeti felépítés kidolgozása? Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 20149

10 Veszélyek Új versenytársak megjelenése a piacon. A piaci növekedés lassulása. Változó fogyasztói igények. Szigorodó szabályozás. Helyettesítő termékek megjelenése. Hátrányos demográfiai változások. Kedvezőtlen gazdasági ciklusok hatása. A beszállítók javuló alkupozíciója. Fogyasztói érdekvédelem fokozódó nyomása. Forrás: Dr. Rutkovszky Edéné: Projektmenedzsment Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201410

11 Kockázat tervezése és menedzselése Stratégiák Elkerülési stratégiák Minimalizációs stratégiák Vészhelyzeti tervek Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201411

12 Kockázat tervezése KockázatStratégia Szervezeti pénzügyi problémák Elkészíteni egy részletes dokumentumot a felső vezetés részére, amely bemutatja, hogy a projekt mennyire fontos kapcsolatban áll az üzleti célokkal Toborzási problémák Riasztani a megrendelőt, hogy potenciális nehézségek és lehetséges késések várhatók, kutatni a megvásárolható komponensek után. Munkaerő megbetegedése Újraszervezni a csapatot úgy, hogy a munkák jobban átfedjék egymást, így az emberek jobban megértik mások munkáit is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 12 Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése

13 A kockázat figyelése Változott-e az azonosított kockázatok bekövetkezési valószínűsége hatása Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201413

14 Információgyűjtés Kitöltött űrlapok jelentések, jegyzőkönyvek, programok kimenetei, értekezleteken elhangzott információk Óraelszámolások Állapotjelentések Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201414

15 Elemzés - alapfogalmak ACWP ACWP – Actual Cost Of Work Performed – az elvégzett munka tényleges költsége BCWP BCWP – Budget Cost Of Work Performed – az elvégzett munkára ennyi költséget terveztünk BCWS BCWS – Budget Cost Of Work Scheduled – a tervezett (ütemezett) munkára ennyi költséget terveztünk Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201415

16 Elemzés – származtatott fogalmak CV CV – Cost Variance – költségeltérés CV=BCWP-ACWP SV SV – Schedule Variance – ütemezéstől való eltérés SV=BCWP-BCWS CPI CPI – Cost Performance Index – költséghatékonysági mutató CPI=BCWP/ACWP SPI SPI – Schedule Performance Index – ütemterv teljesülési mutató SPI=BCWP/BCWS CR CR – Critical Ratio – kritikus arány CR=SPI*CPI Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201416

17 Diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201417 Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben

18 Felügyelet Beavatkozási határokat meghatározni Pl. 0,9…1,1 - OK 0,8…0,9 vagy 1,1…1,2 - tendenciafigyelés 0,8 alatt vagy 1,2 felett - cselekvés Az SPI és CPI értékét folyamatosan figyelni Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201418

19 Minta BCWSBCWPACWPCVSVCPISPIÉrtelmezés 100 0011Időben és költségen 100125 02511,25Időelőny és költségen 125100 0-2510,8Késés és költségen 100 125-2500,81Időben és túlköltekezés 100125150-25250,831,25Időelőny és túlköltés 125100125-25 0,8 Késés és túlköltés 125 1002501,251Időben és megtakarítás 10012510025 1,25 Időelőny és megtakarítás 15012510025-251,250,83Késés és megtakarítás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 19 Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben

20 Projekt lezárása A projekt akkor fejeződik be, ha teljesül a projektcél (elfogadták a projekt eredményét) Projektzáró dokumentum Projektadatok (…, tervezett és tényleges befejezési idő, bevétel, tervezett és tényleges költségek, emberóra ráfordítás) Lezárást követő teendők Vevői elégedettség Projekt általános értékelése Projektzáró értekezlet – értékelik a projekt lefutását Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201420

21 A projekt utóélete Szoftverrendszerrel kapcsolatos költségek 1/3-a fejlesztés és 2/3-a működtetés Projektzárást követő tevékenységek Üzemeltetés Garanciális javítások Későbbi karbantartás Támogatás (tanácsadás) Követés (változó jogi, hardver és szoftver környezet) Továbbfejlesztés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201421

22 Bejelentések fogadása Service Level Agreement (SLA) rögzíti Bejelentések súlyosság és prioritás szerinti kategorizálása Vállalt reakcióidők Informatikai infrastrukturális szolgáltatások módszertana (ITILv3) - Information Technology Infrastructure Library (ISO/IEC 20000) Informatikai rendszerek üzemeltetésére és fejlesztésére szolgáló módszertan, illetve szabvány- és ajánlás-gyűjtemény Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201422

23 Bejelentéskezelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201423

24 SZOFTVER ÉLETCIKLUS MODELLEK Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 24

25 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Mi a szoftver? A számítógépes programok, a hozzájuk kapcsolódó dokumentációk és konfigurációs adatok összessége Két fő csoport Általános termékek és Rendelésre készített 25

26 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Igény a rendszerezett munkára Kezdetben kis programok Hardverfejlődés → bonyolultabb feladatok Folyamatábra, metanyelvű algoritmus leírás, stb. Szoftvertechnológia 26

27 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Boehm - 1976 A szoftvertechnológia tudományos ismeretek gyakorlati alkalmazása számítógépes programok előállításához, a fejlesztéshez, a használathoz és karbantartáshoz szükséges dokumentációk tervezésében és előállításában. 27

28 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 IEEE - 1983 A szoftvertechnológia olyan technológiai és vezetési alapelvek összessége, amelyek lehetővé teszik a programok termékszerű gyártását és karbantartását a költség- és határidő korlátok betartásával. 28

29 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Alap tevékenységek Követelményelemzés (Mit is kellene csinálni? Mikorra, és mennyiért? – megvalósíthatóság vizsgálata) Tervezés (architekturális tervezés, absztrakt specifikáció, interfész tervezés) Implementálás (komponens tervezés, adatszerkezet tervezés és algoritmus tervezés) Kipróbálás, validálás, bevezetés (szoftverátvizsgálás és tesztelés) Működtetés, karbantartás, továbbfejlesztés, leállítás 29

30 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Szoftverfolyamat modellek Vízesés Boehm féle spirál Inkrementális (evolúciós) Újrafelhasználás orientált (komponens alapú) V RUP (Rational Unified Process) ISO/IEC 12207 (1995, 2008) 30

31 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Vízesés modell Ábra forrása: Ficsor Lajos: http://www.iit.uni-miskolc.hu/iitweb/opencms/users/ficsorl/Targyak/Sweng/Segedletek / 31

32 Vízesés modell A következő fázis addig nem indulhat el, amíg az előző be nem fejeződött. Ez a modell akkor működik jól, ha a követelmények teljesen ismertek. Előny: Jól menedzselhető és ellenőrizhető. Minden fázisban jól definiált feladatok. Minden fázis jól dokumentálható. Előre jól definiálható követelmények esetén jól alkalmazható. Hátrány: Nagyon sok probléma csak az utolsó fázisban derül ki, így a javítás nagyon költséges. Korán kell jelentős döntéseket hozni, ez hibás döntésekhez vezethet. Nehéz a rendszert a fejlesztés közben változó követelményekhez igazítani. Sok dokumentációs munkát igényel. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201432

33 Spirál modell Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 megvalósíthatóság a rendszer követelményeinek meghatározása rendszertervezés, stb. 33

34 Spirál Modell Elemzés Tervezés Megvalósítás Igények és Célok Prototípus 1 Prototípus 2 Prototípus 3

35 Spirál modell Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Ábra forrása: http://sloanreview.mit.edu/the-magazine/articles/2008/spring/49315-3/the-spiral-model-of-software-development/ megvalósíthatóság a rendszer követelményeinek meghatározása rendszertervezés, stb. 35

36 Spirál modell Előny: a kockázati tényezőkkel explicite számol. A spirális modellben nincsenek rögzített fázisok, és felölelhet más folyamatmodelleket is (vízesés, evolúciós, stb.). Hátrányai: a modell alkalmazása bonyolult, munkaigényes feladat; a párhuzamos foglalkoztatás csak a 3. szektorban lehetséges. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201436

37 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 V modell Forrás: http://softwareandme.wordpress.com/2009/10/20/software-development-life-cycle/sdlc_v_model 37

38 V modell Egy módosított vízesés modell. Megkülönbözteti a fejlesztésen belül a konstrukciós és a tesztelési fázisokat. Definiálja a tesztelés szintjeit. Szemlélteti, hogy a tesztelési munka végigköveti a teljes fejlesztési folyamatot. Összefüggést tételez fel az egyes konstrukciós fázisok és az egyes tesztelési szintek között. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201438

39 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Inkrementális (evolúciós) Ábra forrása: Ficsor Lajos: http://www.iit.uni-miskolc.hu/iitweb/opencms/users/ficsorl/Targyak/Sweng/Segedletek / 39

40 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201440

41 Evolúciós modell Ki kell fejleszteni egy kezdeti implementációt (prototípust), azt a felhasználókkal véleményeztetni, majd sok-sok verzión át addig finomítani, amíg megfelelő nem lesz. Iterációs modellnek is nevezik. Objektum orientált fejlesztésben gyakran használják. Ez a modell a felhasználó kívánságait jobban kielégítő programot eredményez. A kis (<100.000 programsor) és közepes (<=500.000 programsor) rendszerek fejlesztéséhez ideális. Hátrányai: a folyamat nem látható; a rendszerek gyakran szegényesen strukturáltak; a gyors fejlesztés rendszerint a dokumentáltság rovására megy. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201441

42 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Újrafelhasználás orientált fejlesztés (komponens alapú) Komponenselemzés Követelménymódosítás Rendszertervezés újrafelhasználással Fejlesztés és integráció 42

43 Komponens alapú modell Előnye: lecsökkenti a kifejlesztendő részek számát, így csökkenti a költségeket és a kockázatot. Ez általában a kész rendszer gyorsabb leszállításához vezet. Hátrányai: a követelményeknél hozott kompromisszumok elkerülhetetlenek, és ez olyan rendszerhez vezethet, ami nem felel meg a felhasználó valódi kívánságának. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201443

44 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Fázisok: Előkészítés Kidolgozás Megvalósítás Átadás Munka- folyamatok folyamatokKövetelményekTervezésImplementációTeszt RUP Ábra: http://www.quattrosoft.hu/szolgaltatasok/szoftverfejlesztes Munkafolyamatok 44

45 RUP - dimenziók Az ábra vízszintes dimenziója az időbeliséget, a függőleges dimenziója a különböző munkafolyamatokat (tevékenységeket) szimbolizálja. Az ábra harmadik dimenziója – amit a sávok magassága jelent –, az egyes tevékenységek intenzitását, erőforrás igényét szimbolizálja. Egy-egy fázis elkészítése során több munkafolyamatot érint, ugyanakkor az egyes munkafolyamatok a különböző fázisokban különböző intenzitásúak, erőforrás igényűek. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201445

46 ISO 12207 Forrás: Tarczali Tünde: UML diagramok a gyakorlatban [link]link Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201446

47 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 CASE eszközök Computer-Aided Software Engineering Követelményspecifikáció: grafikus rendszermodellek, üzleti és domain Elemzés/tervezés során: adatszótár kezelése, mely a tervben található egyedekről és kapcsolataikról tartalmaz információt; felhasználói interfész generálását egy grafikus interfész- leírásból, melyet a felhasználóval együtt készíthetünk el.; a terv ellentmondás mentesség vizsgálata Implementáció során: automatikus kódgenerálás (Computer Aided Programming - CAP);verziókezelés Szoftvervalidáció során: automatikus teszt-eset generálás, teszt-kiértékelés, -dokumentálás Szoftverevolúció során: forráskód visszafejtés (reverse engineering); régebbi verziójú programnyelvek automatikus újrafordítása újabb verzióba. 47

48 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 CASE eszközök Automatikus dokumentumgenerálás; Projektmenedzsment támogatás (ütemezés, határidők figyelése, erőforrás-tervezés, költség- és kapacitásszámítás, stb. ) 48

49 UML Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 49

50 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 UML Unified Modeling Language Egységes modellező nyelv 2.4.1 (2.1.2 ISO/IEC 19505 ) http://www.uml.org Object Management Group Eric J. Naiburg, Robert A. Maksimchuk: UML földi halandóknak. Kiskapu Kiadó, Budapest, 2006. 50

51 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 UML Dokumentálható A szoftverrel szemben támasztott követelmények A szoftver felépítése A szoftver működése Grafikus elemek Nem programozási nyelv Nem módszertan „Csak” segédeszköz 51

52 Mire jó az UML? 1. szemléltetésre a fejlesztői csoporton belül, illetve a fejlesztők, tesztelők, menedzserek és a megrendelők közötti kommunikációra specifikálásra megvalósításra dokumentálásra Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201452

53 Mire jó az UML? 2. Evolúciós programfejlesztés „szoftver mag ültetés és hajtatás” Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201453

54 Sikeres szoftverfejlesztési folyamat Jelölésrendszer (notation) – ez lehet az UML Folyamat (process) – pl. RUP (Rational Unified Process) Eszköz (tool) – pl. Enterprise Architect, Rational Rose, Visual Studio 2010 osztálydiagram készítő része, stb. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201454

55 UML szabvány részei 1. Infrastructure (4 rétegű metamodell, a nyelv alapvető szerkezetei, a „mag”) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201455

56 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 56

57 A metamodell architektúra M3 Meta- metamodell EBNF (Extended Backus-Naur Form) MOF M2metamodell A C# nyelv nyelvtana UML M1modell Egy C# program Számkitaláló M0rendszer Egy konkrét C# program végrehajtása A program futásának egy állapota Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201457

58 Az UML szabvány részei 2. Superstructure (a felhasználó milyen diagramokat, azon belül milyen elemeket és kapcsolatokat használhat; mi főleg ezt tanuljuk) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201458

59 Az UML szabvány részei 3. UML Diagram Interchange (UMLDI) – lehetővé teszi a különböző UML szerkesztő szoftverek közötti dokumentumcserét UML Human-Usable Textual Notation – egyes UML diagramokból ember által is olvasható szöveget generál MOF 2 XMI Mapping – MOF = Meta Object Facility XMI = XML Metadata Interchange – XML adatok és objektumok cseréje, manipulálása Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201459

60 Modell - diagram A kettő nem ugyanaz! „A modellek (tehát) több diagramból állnak, a diagramok pedig az elemek és azok más elemekkel való kölcsönhatásának ábrázolásai.” (Forrás: UML földi halandóknak könyv) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201460

61 Diagram Szerkezeti diagram Viselkedési diagram Osztály diagram (class) Objektumd. (object) Csomagdiagram (package) Összetevő d. (component) Összetett szerkezet d. (composite structure) Kialakítás d. (deployment) Tevékenység d. (activity) Használati eset d.(use-case) Állapotautomata d.(state machine) Kölcsönhatási diagram Sorrenddiagram (sequence) Kommunikációs d. (communication) Kölcsönhatás áttekintő d. (interaction overview) Időzítés d. (timing) Kontextus diagram Szakarchitektúra diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 61

62 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Diagram típusok Szerkezeti diagramok: Osztálydiagram (class) Objektumdiagram (object) Csomagdiagram (package) Összetevő diagram (component) Kontextus d., Szakarchitektúra d. Összetett szerkezet diagram (composite stucture) Kihelyezési/telepítési/kihelyezési diagram (deployment) Viselkedési diagramok: Tevékenység diagram (activity) Használati eset vagy feladat diagram (use-case) Állapotautomata vagy állapotgép diagram (state machine) Kölcsönhatási diagramok: Sorrend diagram (sequence) Kommunikációs diagram (communication) Időzítés diagram (timing) Kölcsönhatás áttekintő diagram (interaction overview) 62

63 Szerkezeti és viselkedési A szerkezeti diagramok (statikus) nem törődnek az időbeli változással, ők a modellezett rendszer állapotát egy adott időpillanatban mutatják be. Viselkedési diagramok (dinamikus) folyamatában, változásában mutatják ugyanazt a modellezett rendszert. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201463

64 Szerkezeti diagramok 1 Osztálydiagram: az UML modellezésben leggyakrabban használt diagramfajta. A rendszerben található állandó elemeket, azok szerkezetét és egymás közötti logikai kapcsolatát jeleníti meg. Objektumdiagram: a rendszer egy adott időpontban érvényes pillanatképét határozza meg. Az osztálydiagramból származtatjuk. Csomagdiagram: a csomagok olyan modellelemek, amelyek más modellelemek csoportosítására szolgálnak, és ezeket valamint a köztük lévő kapcsolatokat ábrázolja ez a fajta diagram. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201464

65 Szerkezeti diagramok 2 Összetevő diagram: az összetevő vagy komponens a rendszer fizikailag létező és lecserélhető része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel. Főleg implementációs kérdések eldöntését segíti. A megvalósításnak és a rendszeren belüli elemek együttműködésének megfelelően mutatja be a rendszert. Összetett szerkezeti diagram: A modellelemek belső szerkezetét mutatja. Kialakítás/kihelyezés/telepítési diagram: A fizikai (kész) rendszer futásidejű felépítését mutatja. Tartalmazza a hardver és a szoftverelemeket is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201465

66 Viselkedési diagramok Tevékenységdiagram: A rendszeren belüli tevékenységek folyamatát jeleníti meg. Általában üzleti folyamatok leírására használjuk. Használati eset/feladat diagram: A rendszer viselkedését írja le, úgy, ahogy az egy külső szemlélő szemszögéből látszik. Állapotautomata diagram: Az objektumok állapotát és az állapotok közötti átmeneteket mutatja, valamint azt, hogy az átmenetek milyen esemény hatására következnek be. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201466

67 Kölcsönhatási diagramok Kommunikációs diagram: Az objektumok hogyan működnek együtt a feladat megoldása során, hogyan hatnak egymásra. Sorrenddiagram: Az objektumok közötti üzenetváltás időbeli sorrendjét mutatja. Időzítés diagram: A kölcsönhatásban álló elemek részletes időinformációit és állapotváltozásait vagy állapotinformációit írja le. Kölcsönhatás áttekintő diagram: Magas szintű diagram, amely a kölcsönhatás-sorozatok közötti vezérlési folyamatról ad áttekintést. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201467


Letölteni ppt "2. ELŐADÁS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 1."

Hasonló előadás


Google Hirdetések