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

2 Objektum diagram 2

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

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

6 Sorrend diagram 6

7 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

8 Sorrend diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

9 Sorrend diagram

10 Dr. Johanyák Zs. Csaba - Szoftvertechnológia 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

12 Dr. Johanyák Zs. Csaba - Szoftvertechnológia 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35 ER modell Forrás: asg/oktata s/Adatbazi sok/adatb elm_nyh_ pdf.PDF Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

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

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

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

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

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

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

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

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

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 Kép forrása i/File: 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

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

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

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

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

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

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

55 Dr. Johanyák Zs. Csaba - Szoftvertechnológia 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

57 Dr. Johanyák Zs. Csaba - Szoftvertechnológia 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 Objektum diagram 58

59 Dr. Johanyák Zs. Csaba - Szoftvertechnológia 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 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 Booch osztálydiagram Forrás: Forrás: Grady Booch: Object- Oriented Analysis and Design. With Applications, 2nd edition, Addison- Wesley Longman, ISBN ,

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

63 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Booch objektum diagram Forrás: 63

64 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechn Booch modul diagram Forrás: 64

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

66 Dr. Johanyák Zs. Csaba - Szoftvertechnológia 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 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 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 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 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 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: 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

73 Dr. Johanyák Zs. Csaba - Szoftvertechnológia RUP – átlós jelleg Ábra: 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

75 Dr. Johanyák Zs. Csaba - Szoftvertechnológia 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

77 Dr. Johanyák Zs. Csaba - Szoftvertechnológia 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

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

80 Dr. Johanyák Zs. Csaba - Szoftvertechnológia 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 Egységesített Eljárás architektúrája Megvalósítás 81

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

83 RUP irodalom miskolc.hu/iitweb/export/sites/default/users/fic sorl/Targyak/Infterv/Segedletek/swprochand. pdf miskolc.hu/iitweb/export/sites/default/users/fic sorl/Targyak/Infterv/Segedletek/swprochand. pdf ppt Dr. Johanyák Zs. Csaba - Szoftvertechnológia


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