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

4. 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: "4. ELŐADÁS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 1."— Előadás másolata:

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

2 Objektum diagram 2

3 Sokszög Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 3

4 Kölcsönhatási diagramok Sorrend diagram – kevés résztvevő sok üzenettel Kommunikációs diagram – sok résztvevő kevés üzenettel Időzítés diagram – kevés résztvevő, komplex időbeli egymásra hatás 4

5 Sorrend diagram Üzenetváltásokat ábrázol, amelyek több, kölcsönhatásban lévő partner között zajlanak le A partnerek lehetnek osztályok, aktorok, komponensek, csatlakozók és csomópontok. Akkor érdemes használni, ha kevés résztvevő (partner) van, de azok sok üzenetet küldenek. Az életvonalon látható üres téglalapot aktivációs résznek nevezzük, ilyenkor csinálhat valamit az adott szereplő. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 20145

6 Sorrend diagram 6

7 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/353/Enterprise-Architect-for-Business-Analysts.aspx 7

8 Sorrend diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 http://www2.pms.ifi.lmu.de/publikationen/diplomarbeiten/Sacha.Berger/illustrations/UML/SequenceDiagram-initiatingPhoneCall.pdf.png 8

9 Sorrend diagram

10 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Kommunikációs diagram ha sok résztvevő van és azok viszonylag kevés üzenetet küldenek egymásnak. 10

11 Kommunikációs diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 http://afruj.wordpress.com/2008/07/28/the-unified-modeling-language-uml-part-8/ 11

12 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Időzítés diagram kevés résztvevő, komplex időbeli egymásra hatás 12

13 Kölcsönhatás áttekintő diagram A kölcsönhatás áttekintő diagram kicsit kilóg a sorból, mivel ő az előző három fajta módon megrajzolt (de ugyanarra a rendszerre vonatkozó) diagramok között fennálló összefüggéseket a tevékenységdiagramok vizuális eszközeivel fejezi ki. Ő valóban egy áttekintést nyújt. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 13

14 Kölcsönhatás áttekintő diagram Olyan, mintha egy tevékenységdiagramot rajzolnánk (kezdőpont, végpontok, elágazás, stb.), de a tevékenységek helyett ref-ek állnak (referenciák). A referenciák általában egy sorrenddiagramra vonatkoznak, amit már részletesen megrajzoltunk. A példában mindkét ref mögött létezik egy-egy ugyanilyen nevű sorrenddiagram, ami megmutatja a bejelentkezés és a felhasználó megrendeléseinek a részleteit. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 14

15 Kölcsönhatás áttekintő diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 15

16 Üzenettípusok Az első háromfajta kölcsönhatási diagramban egyaránt a következő háromfajta üzenettípust használjuk. Kérés: Szinkron üzenet. Kérés alkalmával a küldő szünetelteti aktivitását (vár) és a fogadó aktiválása következik be. (pl. telefonálás) Válasz: Szinkron üzenet. A kérést küldő a válaszüzenet hatására újra aktiválódik. Szignál: Aszinkron üzenet, vagyis a küldő nem szünetelteti az aktivitását az üzenet elküldése után, hanem tovább dolgozik. (pl. levélküldés) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 16

17 Kérés, válasz és szignál Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 17

18 Komplex interakció Az első háromfajta kölcsönhatási diagramban szerepelhetnek. Folyamatok egész halmazát reprezentálhatják, amelyeket az interakciós operátorok kötnek össze. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 18

19 Interakciós operátorok strict operátor – szigorú sorrend ref operátor – névvel hivatkozik más interakciókra opt operátor – opcionális alt operátor – alternatívák (választási lehetőség) brk operátor - megszakítás seq operátor – sorrend, de nem szigorú sorrend, mint a strict-nél loop operátor – ciklus, ismétlés par operátor – párhuzamosság … (vannak még továbbiak) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 19

20 Interakciós operátorok Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 20

21 IMPLEMENTÁLÁS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 21

22 Implementálás A technológiai részletek kidolgozása, a tényleges kód előállítása Komponens tervezés, adatszerkezet tervezés Felhasználói interakció megtervezése, felülettervek Integrálás (modulok összekapcsolása). Dokumentáció: objektum d., csomag d., komponens d. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201422

23 Csomag diagram Az UML-elemek csoportosítására, közös névtérben való elhelyezésére alkalmas Tartalmazhat további csomagot Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201423

24 Csomag láthatóság és útvonal megadás Public (default) – más névtérből is látható, private Teljes minősített név egymásba ágyazásnál: gyökércsomag_neve::csomag_neve::elemnév Relatív útvonal >-al Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201424

25 Csomag beolvasztás Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201425

26 Csomagok közötti kapcsolatok > a csomag összes elemét vagy egy elemet láthatóvá tesz a másik csomag számára > privát import, ez az elem nem importálható tovább újabb csomagokba > összeolvasztás, a csomagimportálás egy fajtája, a beolvasztott része lesz a beolvasztónak Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201426

27 Összetevő (komponens) diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201427

28 Komponens Komponens: a rendszer fizikailag létező és kicserélhető része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel. Az osztály és a komponens fogalma nagyon hasonló az UML-ben Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201428

29 Interfész Van nyújtott (szolgáltatott) interfész (kör a jele) Van elvárt (required) interfész (félkör a jele) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201429

30 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Összetevő diagram 30

31 Interfészek összefogása csatlakozóba (portba) Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 31

32 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Kialakítási diagram 32

33 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Kihelyezési/telepítési diagram 33

34 ADATBÁZISOK MODELLEZÉSE Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Ismétlés és kiegészítés a tervezés témakörhöz 34

35 ER modell Forrás: http://www.inf.unideb.hu/~fazek asg/oktata s/Adatbazi sok/adatb elm_nyh_ pdf.PDF Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201435

36 Relációs modell Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201436

37 Leképezési szabályok Egyedtípus → reláció Összetett attribútumok → komponensekre bontás → reláció Kulcsattr. → elsődleges kulcs N:M kapcsolat → kapcsolat reláció Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201437

38 Kiinduló relációk Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201438

39 Normálformák 1. A táblázat minden cellájában csak egy attribútum érték szerepel (1NF) 2. Minden nem kulcs (másodlagos) attribútum funkcionálisan teljesen függ minden kulcstól (2NF) 3. Nincs olyan másodlagos attribútum, ami tranzitívan függne valamilyen kulcstól Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201439

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

41 Entity Framework modell kialakítása Id Egyedtípus → entitás Összetett attribútumok → komponensekre bontás → entitás Kulcsattr. → elsődleges kulcs (Entity key) N:M kapcsolat → kapcsolat Automatikusan keletkező navigációs tulajdonságok Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201441

42 IMPLEMENTÁLÁS - FOLYTATÁS Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 42

43 Prototípus A szoftverrendszer kezdeti verziója, amelyet arra használnak, hogy bemutassák a koncepciókat kipróbálják a tervezési opciókat jobban megismerjék a problémát és annak lehetséges megoldásait Támogatott tevékenységek a követelménytervezési folyamatban követelmények feltárása követelmények validálása Felhasználható Felhasználók képzésére Rendszer tesztelésére Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201443

44 A prototípus készítés előnyei A funkciók bemutatásakor azonosítani lehet a szoftverfejlesztők és a felhasználók közötti félreértéseket A szoftverfejlesztésen dolgozók hiányos és/vagy ellentmondásos követelményekre akadhatnak Hamar a rendelkezésünkre áll egy működő rendszer, így demonstrálhatjuk a vezetőségnek az alkalmazás megvalósíthatóságát és hasznosságát A prototípus felhasználható a valódi rendszer specifikációjának megírásakor A rendszer jobban használható lesz A rendszer jobban illeszkedik a felhasználói igényekhez Jobb a tervezés minősége Jobb a rendszer karbantarthatósága Kevesebb erőfeszítés szükséges a fejlesztéshez Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201444

45 Prototípus típusai Evolúciós prototípus - készítésének célja egy működő rendszer átadása a végfelhasználóknak Eldobható prototípus - készítésének célja a rendszerkövetelmények validálása vagy származtatása. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201445

46 Gyors prototípus készítési technikák Magas szintű nyelvek (3GL, 4GL) Komponensek és alkalmazások összeépítése Alkalmazási szinten Komponens szinten Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201446

47 Programozási nyelvek 1. generációs: gépi szintű nyelv/utasítások, kapcsolókkal vitték be Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Kép forrása http://en.wikipedia.org/wik i/File:360-91-panel.jpg 47

48 Programozási nyelvek 2. generációs (2GL): assembly nyelvek – van logikai struktúra, lassú fejlesztés 3. generációs (3GL): magasszintű nyelvek, strukturált programozás támogatása, kényelmi funkciók, nem kell a programozó kidolgozzon minden egyes részletet pl. C, C++, C#, Java, BASIC and Delphi gyorsabb fejlesztés, de sok hibalehetőség Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201448

49 Programozási nyelvek 4. generációs(4GL): kereskedelmi/üzleti célú szoftverek fejlesztéséhez, magasabb absztrakciós szint még gyorsabb fejlesztés kevesebb hibával, cél a fejlesztési költségek csökkentése PowerBuilder, jelentés generáló rendszerek, form generáló rendszerek, adatfeldolgozó rendszerek: SAS, SPSS Pl: http://en.wikipedia.org/wiki/Fourth- generation_programming_language#Some_fourt h-generation_languageshttp://en.wikipedia.org/wiki/Fourth- generation_programming_language#Some_fourt h-generation_languages Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201449

50 Programozási nyelvek 5 GL: mesterséges intelligencia nyelvek, feladatmegoldás a korlátok/kényszerek megadásával, logikai nyelvek - ? Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201450

51 Az objektum-orientált tervezés néhány kérdése Mik az objektumok? Alapelvek: egységbezárás, öröklődés, többrétűség, adatrejtés Vezérlés – szolgáltatáskérés Szinkron kommunikáció Aszinkron kommunikáció Ütemezés – szabályozott megosztott hozzáférés erőforráshoz Nem preemptív – pl. szemaforok Preemptív Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201451

52 Az objektum-orientált tervezés néhány kérdése Objektum belső állapota Objektumok élettartama Perzisztens objektumok: élettartamuk hosszabb mint a program futási ideje Tranziens objektumok Nagyszámú perzisztens objektum  adatbáziskezelő rendszer alkalmazása RDB ha sok objektum, de kevés osztály OODB Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201452

53 OBJEKTUM ORIENTÁLT SZOFTVERFEJLESZTÉSI MÓDSZERTANOK Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 53

54 Objektum orientált szoftverfejlesztési módszertanok OMT Booch RUP Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201454

55 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Object Modeling Technique (OMT) Rumbaugh, Blaha, Premerlani, Eddy és Lorensen 1991 Egyszerű objektum orientált szoftverfejlesztési módszertan Jelölésrendszerének számos elemét átvették az UML-ben Alapgondolat: az OO gondolkodás közelebb áll az emberi problémamegoldáshoz, mint a korábbi próbálkozások A követelmény elemzés és tervezési fázis támogatására dolgozták ki Szekvenciális. Először a követelmény elemzés, majd a tervezés Mindegyik fázisban a kis lépések ciklikusan ismétlődnek Nem hangsúlyozza ki a tényleges implementációt, a tesztelést és a többi alaptevékenységet (fázist) 55

56 A modellezés célja (Rumbaugh ) A fizikai egységek tesztelése még beépítés előtt (szimuláció), Kommunikáció a megrendelővel Megjelenítés (vizualizáció) Bonyolultság csökkentése Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201456

57 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 OMT Három modell kidolgozását javasolja Objektum modell: a rendszer építőelemei  OM diagramok: objektumok és osztályok közötti statikus kapcsolatok Dinamikus modell: építőelemek közötti kölcsönhatás (események, állapotok átmenetek)  állapot diagram és esemény folyam diagram Funkcionális modell: a rendszer eljárásai adatfolyam/áramlás szempontból  adatfolyam diagramok 57

58 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Objektum diagram 58

59 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 OMT fázisai Elemzés - f eladatmeghatározás (célok és alapkoncepciók felsorolása is) Rendszertervezés fázis A rendszer felépítése (architektúra) Alrendszerek meghatározása Alrendszerek folyamatokhoz rendelése figyelembe véve a párhuzamos végrehajtást és együttműködést Perzistens adattárolás (adatbázis) Megosztott – globális információ kezelése, Határesetek vizsgálata, prioritások meghatározása Objektum tervezés fázis Implementációs terv elkészítése Osztályok és algoritmusok definiálása Adattárolás optimalizálás Öröklődés, asszociáció, aggregáció, alapértelmezett értékek vizsgálata Szoftver implementálás 59

60 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Booch módszertan Grady Booch A grafikus jelölésrendszer egy része bekerült az UML-be Az követelmény elemzési és a tervezési fázist fedi le Négy modellt dolgoz ki a feladatról Logikai modell (az osztályok és objektumok) Fizikai modell Statikus modell Dinamikus modell A modellek dokumentálására használt diagramok Osztály, objektum, modul, Állapot, kölcsönhatás, folyamat 60

61 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Booch osztálydiagram Forrás: http://en.wikipedia.org/wiki/File:Booch-diagram.png Forrás: Grady Booch: Object- Oriented Analysis and Design. With Applications, 2nd edition, Addison- Wesley Longman, ISBN 0-8053- 5340-2, 1994 61

62 Osztálydiagram példa Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Forrás: Grady Booch: Object- Oriented Analysis and Design. With Applications, 2nd edition, Addison- Wesley Longman, ISBN 0-8053- 5340-2, 1994 Hidrokultúrás kertészeti rendszer 62

63 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Booch objektum diagram Forrás: http://users.csc.calpoly.edu/~dbutler/tutorials/winter96/rose/node7.html 63

64 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Dr. Johanyák Zs. Csaba - Szoftvertechn. - 2009 Booch modul diagram Forrás: http://users.csc.calpoly.edu/~dbutler/tutorials/winter96/rose/node8.html#picmodule_diagram 64

65 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill Booch állapot átmenet diagram 65

66 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Booch - Fázisok Követetelmény-elemzés (analízis) – ciklikusan ismétli a három részfeladatot Követelmények a megrendelő szempontjából (a rendszer feladatainak és struktúrájának magasszintű leírása) Domain elemzés (osztályok attribútumok, öröklődés, metódusok + állapot diagramok az objektumokhoz) Validálás Tervezés (design) – ciklikusan ismétli a részfeladatokat Logikai tervezés Fizikai tervezés (Végrehajtási szálak, folyamatok, teljesítmény, adattípusok, adattstruktúrák) Prototípus létrehozása és tesztelése 66

67 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Egységesített eljárás – Rational Unified Process A három legelterjedtebb szoftverfejlesztési módszer egységesítésével jött létre 1997-ben (OMT + Booch + OOSE) Rational Unified Process (RUP) IBM Világszerte elterjedt fejlesztési módszertan Nagyon sok előző módszertanból merít Keret módszertan -> testre kell szabni 67

68 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Használati eset vezérelt (use case driven) A rendszer fejlesztésének elején meghatározott használati esetek végigkísérik a teljes fejlesztést Architektúra központú (architecture centric) A teljes fejlesztést meghatározza a rendszer architektúrája Iteratív és inkrementális (növekvő) Az egyes iterációk során a rendszer újabb verzióit fejlesztjük, készítjük el. Az egyes iterációk munkafolyamatokból állnak Főbb jellemzői 68

69 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Architektúra központú fejlesztés Architektúra: strukturálisan fontos elemek és ezek kapcsolata A rendszer nagy léptékű tagolását írja elő Nehezen megváltoztatható, a rendszer egész élettartama alatt változatlan A helyes architektúra meghatározása kulcsfontosságú: ha itt hibázunk, akkor ennek a kijavítása nagyon sokba kerül A klasszikus példa : ház Alaprajz Homlokzati rajz Elektromos kábelezés és berendezések Épületgépészet, vízvezetékek, fűtés 69

70 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Az architektúra célja Lehetővé teszi a bonyolultság kezelését Átláthatóvá tesz a fejlesztést Könnyebben felismerhetőek az újrafelhasználható elemek Átlátható projekt menedzsment Kockázatok csökkentése Lehetővé válik a párhuzamos fejlesztés 70

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

72 RUP – mérföldkövek - iterációk Minden fázis vége a fejlesztés egy-egy jól meghatározott mérföldkövét (milestone) jelenti, azaz olyan pontot, ahol egy célt kell elérnünk, illetve ahol kritikus döntéseket kell meghozni. A fázisok további kisebb egységekre, iterációkra (iteration) bonthatók. Minden iteráció egy teljes, illetve részben önálló fejlesztési ciklust jelent, mivel az iteráció végén egy működő és végrehajtható alkalmazásnak kell felállnia, az iteráció végén a rendszer újabb, bővített funkcionalitású verziója készül el. Minden egyes iteráció egy-egy mini fejlesztés. Az Egységesített Eljárás iterációi tervezettek és szigorúan ellenőrzöttek. Az iterációk számát és időtartamát, az egyes iterációk feladatát és az általuk előállított termékeket, az iterációs munkafolyamatok résztvevőit előre tervezik. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201472

73 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 RUP – átlós jelleg Ábra: http://www.quattrosoft.hu/szolgaltatasok/szoftverfejlesztes 73

74 Átlós jelleg Az előkészítés fázisában a legnagyobb hangsúly a követelmények rögzítésére helyeződik, a többi tevékenység pedig jóval kisebb mértékben kap szerepet, tesztelés pedig gyakorlatilag nincs is. A későbbi iterációkban, illetve fázisokban ez a hangsúly fokozatosan áthelyeződik a technikaibb jellegű tevékenységekre. Az átadás fázisában már elsősorban tesztelés zajlik, így elemzés, tervezés és implementáció a tesztekre vonatkozóan és azok eredményeitől függően válik szükségessé, míg a követelmények összegyűjtése már nem kap szerepet. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201474

75 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 A fejlesztés fázisai Előkészítés a rendszer eredeti ötletét olyan részletes elképzeléssé dolgozzuk át, mely alapján a fejlesztés tervezhető lesz, a költségei pedig megbecsülhetők; megfogalmazzuk, hogy a felhasználók milyen módon fogják használni a rendszert, itt azonosítjuk a kulcsfontosságú használati eseteket, azaz a rendszer alapvető szolgáltatásait. milyen alapvető belső szerkezetet, architektúrát alakítunk ki. Kidolgozás a „használati eseteket” részleteiben is kidolgozzuk; alaparchitektúra kialakítása (Executable Architecture Baseline); az alaparchitektúra segítségével a teljes fejlesztés folyamata ütemezhető, és a költségei is tisztázhatók. Megvalósítás a rendszer iteratív és inkrementális növelése. a teljes rendszert kifejlesztjük (tervezés, kódolás). Átadás bétaváltozatok, tesztelés, módosítás dokumentációk, egyéb kapcsolódó termékek 75

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

77 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 A fázisok erőforrás- és időigénye egy átlagos fejlesztés esetében 5% 20% 65% 10% 10% 30% 50% 10% Fázisok: Előkészítés Kidolgozás Megvalósítás Átadás 77

78 Idő- és erőforrásigény A különböző jellegű fejlesztéseknél az egyes fázisok idő illetve erőforrás igénye lényegesen különbözhet. Például egy létező termék újabb verziójánál az előkészítő fázis majdnem nullára zsugorodhat, s a kidolgozási fázis is rövid lehet. Ugyanakkor egy ismeretlen szakterülten, ismeretlen eszközökkel végzett fejlesztés esetében az előkészítés igen hosszú ideig tarthat. Általános jellegzetesség, hogy az építési fázis a leghosszabb és a legnagyobb erőforrás igényű. Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201478

79 Idő- és erőforrásigény Viszonylag általános jellegzetesség, hogy az előkészítő fázisnak jellemzően nagyobb az idő, mint az erőforrás igénye. Az elkészítő fázisban viszonylag kevés ember s viszonylag csekély intenzitással foglalkozik a projekttel. A megvalósítási fázisnak jellemzően nagyobb az erőforrás és arányosan kisebb az időigénye, mivel ez a fázis viszonylag jól párhuzamosítható, a már jól definiált feladatokon párhuzamosan sok fejlesztő dolgozhat Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201479

80 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Egy iteráció munkafolyamatai (RUP) Üzleti modellezés (Business Modeling): a készítendő rendszer üzleti (szakterületi) környezetének vizsgálata Követelmények (Requirements): a rendszer működésével kapcsolatos kezdeti elképzelések összegyűjtése (a felhasználó szemszögéből) Elemzés (Analysis): követelményeket a fejlesztők szempontjának megfelelően rendezzük át, így azok együttessen a rendszer egy belső képét határozzák meg, mely a további fejlesztés kiindulópontja lesz. Rendszerezzük és részletezzük az összegyűjtött használati eseteket, valamint azok alapján meghatározzuk a rendszer alapstruktúráját. Tervezés (Design): az elemzés során kialakított szerkezeti váz teljessé tétele. A tervezésnek a rendszert olyan szinten kell vázolnia, melyből az közvetlenül, egyetlen kérdés és probléma felvetése nélkül implementálható. Implementáció (Implementation): forráskódok, bináris és futtatható állományok, szövegek, képek, stb. előállítása. Az állományok előállítása egyben azok függetlenül végrehajtható, önálló tesztjeit is jelenti. Teszt (Test): Megtervezzük és implementáljuk a teszteket, azok eredményeit szisztematikusan feldolgozzuk, majd hibák vagy hiányosságok esetén újabb tervezési vagy implementációs tevékenységeket hajtunk végre. 80

81 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Egységesített Eljárás architektúrája Megvalósítás 81

82 Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014 Az egyes termékcsoportok eltérő növekedése Megvalósítás 82

83 RUP irodalom http://www.sze.hu/~heckenas/okt/RUP.pdf http://www.iit.uni- miskolc.hu/iitweb/export/sites/default/users/fic sorl/Targyak/Infterv/Segedletek/swprochand. pdf http://www.iit.uni- miskolc.hu/iitweb/export/sites/default/users/fic sorl/Targyak/Infterv/Segedletek/swprochand. pdf http://courses.cs.tamu.edu/lively/cpsc606/rup. ppt Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 201483


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

Hasonló előadás


Google Hirdetések