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

Szoftvertechnológia 2011/2012 – 2. félév levelező tagozat.

Hasonló előadás


Az előadások a következő témára: "Szoftvertechnológia 2011/2012 – 2. félév levelező tagozat."— Előadás másolata:

1 Szoftvertechnológia 2011/2012 – 2. félév levelező tagozat

2 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Előadó Dr. Johanyák Zsolt Csaba Tel.:

3 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Követelményrendszer Március től zárthelyi dolgozat írása Kérdések a honlapon február 14-től Pótlási lehetőség: május Házi feladatként UML diagramokat kell készíteni Enterprise Architect segítségével Ingyenesen letölthető a 30 napos próbaverzió a címről.http://www.sparxsystems.com/

4 Követelményrendszer MIN1O2L - MIN6C6IL - MIN6C8IL: 8 óra konzultáció (előadás) MIN4H0I - MIN2C1TDL: 16 óra konzultáció (gyakorlat jellegű konzultációk: március 31., ápr. 28., május 12.) ZH: 50 pont Házi feladat: 50 pont Megajánlott vizsgajegy: 51 ponttól Dr. Johanyák Zs. Csaba - Szoftvertechnológia

5 Kötelező és ajánlott irodalom Kötelező A konzultációkhoz készült bemutató - minden konzultációt követően frissített változatot töltök fel Szabolcsi Judit: Szoftvertechnológia (a honlapomról letölthető) Ajánlott Mileff Péter: Szoftverfejlesztés segédlet (link a honlapomon) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

6 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

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

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

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

10 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Alap tevékenységek Elvárások elemzése és specifikáció (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 (szoftverátvizsgálás és tesztelés) Szoftverevolúció: karbantartás, fejlesztés, …

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

12 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Vízesés modell Ábra forrása: Ficsor Lajos: /

13 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

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

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

16 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

17 V modell Forrás:

18 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

19 Inkrementális (evolúciós) Ábra forrása: Ficsor Lajos: /

20 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 (< programsor) és közepes (<= 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

21 Ú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ó

22 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áshoz vezet. Hátrányai: akö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

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

24 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

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

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

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

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

29 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Diagram típusok Szerkezeti diagramok: Osztálydiagram (class) Objektumdiagram (object) Csomagdiagram (package) Összetevő diagram (component) Összetett szerkezet diagram (composite stucture) Kialakítás 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)

30 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

31 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

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

33 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

34 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

35 Használati eset diagram Leggyakrabban a követelményelemzés és a specifikáció során alkalmazzák A rendszer viselkedését írja le, ahogyan az egy külső szemlélő szemszögéből látszik Összetevői Használati eset Szereplő Rendszerhatár

36 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Kapcsolatok Asszociáció Általánosítás

37 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Kapcsolatok >

38 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Használati eset diagram készítése Enterprise Architectben Könyvtári rendszer használati eset diagramja

39 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Tevékenység diagram A probléma megoldásának a lépéseit szemlélteti, a párhuzamosan zajló vezérlési folyamatokkal együtt Hasznos az üzleti vagy munkafolyamatok modellezésére, használati esetek vagy konkrét algoritmusok lefutásának leírására Az állapotautomata egy változatának is tekinthető, ahol az állapotok helyére a végrehajtandó tevékenységeket tesszük, az állapotátmenetek pedig a tevékenységek befejezésének eredményeként valósulnak meg.

40 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Párhuzamos feladatvégrehajtás Elágazás (fork) Csatlakozás (join)

41 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Dr. Johanyák Zs. Csaba - Szoftvertechn Kivétel Mi idézheti elő? Külső esemény (pl. adathordozóval megszakad a kapcsolat) Időpont (pl. inaktív ftp kapcsolat megszakítása) Esetválasztás (pl. hibás paraméterezés következtében a hívott metódus kivételt idéz elő) Célzott előidézés - továbbadás (throw)

42 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Másodfokú egyenlet megoldása

43 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Osztálydiagram

44 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Az osztályok közötti kapcsolatok Asszociáció/társítás (association) Aggregáció/rész-egész kapcsolat (aggregation) Általánosítás (generalization) Függőség (dependency) Megvalósítás (realization)

45 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Asszociáció Reflexív asszociáció – Többes asszociáció

46 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Aggregáció Kompozíció (erős tartalmazás) Gyenge tartalmazás

47 Dr. Johanyák Zs. Csaba - Szoftvertechnológia További kapcsolatok Általánosítás Függőség Megvalósítás

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

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

50 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Összetett szerkezeti diagram Strukturált osztály: az osztály belső szerkezetét is megmutatja.

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

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

53 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Állapotgép Az osztályok objektumainak, a használati eseteknek és a protokolloknak a dinamikus viselkedését mutatja, vagy a dialógusok lefutásának leírására is alkalmas Állapot Állapot: az objektum állapotát az attribútumai konkrét értékeinek n-esével jellemezzük. Állapotátmenet: két állapot közötti kapcsolat, amely kifejezi, hogy egy adott állapotban lévő objektum egy esemény vagy valamely feltétel bekövetkezésének hatására milyen másik állapotba kerül.

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

55 Water Phase Diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

56 Állapotgép - tanulmányi rendszer - tantárgyfelvétel

57 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Állapotgép - sakkjátszma

58 Állapotgép - párátlanító Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

60 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

61 Sorrend diagram

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

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

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

65 Kommunikációs diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

69 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

70 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

71 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Objetum diagram

72 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

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

74 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Booch osztálydiagram Forrás:

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

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

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

78 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

79 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, és mindazt egyesíti Keret módszertan -> testre kell szabni

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

81 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Használatieset-vezérelt fejlesztés Azt akarjuk elkészíteni, amire a felhasználónak szüksége van. Aktor: a rendszeren kívül álló személy, vagy másik gépi rendszer, aki üzeneteket küld, illetve kap a rendszertől Használati eset: a használatnak egy értelmes, kerek egysége, kívülről írja le a rendszer viselkedését, szolgáltatásait Architektúrálisan fontos használati eset: a rendszer meghatározása, azonosítása szempontjából kulcsfontosságúak, ami a rendszer célját valósítja meg A használati esetek határozzák meg, hogy mit fejlesztünk? (rendszerhatárok, funkcionalitás) milyen sorrendbe fejlesszük? (prioritás) milyen legyen a termékünk belső szerkezete (architektúra)

82 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

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

84 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

85 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

86 RUP – átlós jelleg Ábra:

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

88 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

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

90 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

91 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

92 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. Az építési fázisnak jellemzően nagyobb az erőforrás és arányosan kisebb az időigénye, mivel az építés 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

93 Egy iteráció munkafolyamatai a tevékenységbeli dimenzió A módszertan statikus, tevékenység típusok szerinti tagozódása (ábra függőleges tengelye) Ez a munkafolyamatok (újabb megfogalmazás szerint diszciplínák), termékek, munkatársak szerinti tagozódás. Üzleti modellezés (Business Modeling) Követelmények (Requirements) Elemzés és Tervezés (Analysis & Design) Implementáció (Implementation) Teszt (Test) Telepítés (Deployment)

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

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

96 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Az Egységesített Eljárás termékei A fejlesztés eredménye mindig több, mint a kód: tervek, dokumentációk, modellek. Egymásra épülnek a termékek Két különböző kategorizálás Nézetek: Lényegében ugyanannyira részletes leírások, de a rendszer különböző „oldalait” mutatják. Egyenrangúak, az alkalmazás jellege dönti el, hogy melyik nézet mennyire határozza meg az architektúrát. Modellek: A rendszer logikailag különböző absztrakciós szintjeit mutatják be. Az egyes munkafázisok, diszciplínák különböző modelleket, más néven termék csoportokat hoznak létre, illetve bővítenek. (ld. UML)

97 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Az egyes termékcsoportok eltérő növekedése

98 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

99 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

100 Szoftverek ellenőrzése és elemzése Technikák Statikus elemzés Szoftver átvizsgálás Automatikus elemzés Dinamikus tesztelés Hiányosság tesztelés Stressz tesztelés Komponens tesztelés Rendszer (integrációs) tesztelés

101 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Szoftver átvizsgálás Legalább 4 fős csapat: szerző, olvasó, tesztelő, moderátor Átvizsgálás ↔ Szerző módosít Tipikus hibák: adath., vezérlési h., I/O h., interfész h., tárkezelési h., kivételkezelési h. A program hibáinak több mint 60%-a felderíthető ily módon

102 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Automatikus elemzés Szoftver, ami a forrásszöveget vizsgálja (nem futtat) Nem használt kódrészlet, inicializálatlan változók Tipikus hibák: adath., vezérlési h., I/O h., interfész h., tárkezelési h. Pl. LINT/Splint C; VS beépített figyelmeztetések Nem ismeri fel a helytelen inicializálást

103 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Szoftverek ellenőrzése és elemzése Technikák Statikus elemzés Szoftver átvizsgálás Automatikus elemzés Dinamikus tesztelés Hiányosság tesztelés Stressz tesztelés Komponens tesztelés Rendszer (integrációs) tesztelés

104 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Hiányosság tesztelés Célok A specifikáció és a megvalósított program közötti eltérések felderítése A rendszer helytelen működésének előidézése Irányelvek Válasszunk olyan bemeneteket, amelyekkel az összes lehetséges hibaüzenetet előidézhetjük Próbáljuk meg elérni a bemeneti pufferek túlcsordulását Ugyanaz a bemenet ugyanazt a kimenetet adja mindig? Kényszerítsük ki az érvénytelen kimenetet

105 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Módszerek Fekete doboz tesztelés A rendszer/komponens belseje nem ismert A bemenetre adott válaszok tanulmányozása Fehér doboz tesztelés Ismert a szerkezet Kis egységekre alkalmazzák Minden független végrehajtási utat kipróbálnak (útvonal teszt)

106 Dr. Johanyák Zs. Csaba - Szoftvertechnológia Fehér doboz tesztelés Útvonalak felderítése Egyszerű esetekben folyamatgráf felrajzolása kézzel Bonyolult esetekben dinamikus programelemzővel (DPE) DPE: a fordítóval együttműködő szoftver, számolja, hogy az egyes utasítások hányszor kerültek végrehajtásra – mi maradt ki → futási profil

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

108 Stressz tesztelés Cél A teljesítmény és a megbízhatóság tesztelése A tervezett terhelés mellett képes legyen dolgozni a rendszer Olyan hiányosságok is kiderüljenek, amelyek nem jelennek meg normál körülmények között Eljárás Addig növeljük a terhelést, amíg a rendszer teljesítménye elfogadhatatlanná nem válik

109 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

110 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

111 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

112 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

113 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

114 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

115 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

116 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

117 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 premptív – pl. szemaforok Preemptív Dr. Johanyák Zs. Csaba - Szoftvertechnológia

118 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

119 Gyors szoftverfejlesztés – agilis módszerek Lassú fejlesztési folyamatok Gyorsan változó környezet A gyors szoftverfejlesztési folyamatokat arra tervezték, hogy segítségükkel gyorsan készíthessük használható szoftvereket Dr. Johanyák Zs. Csaba - Szoftvertechnológia

120 Általános jellemzők - alapelvek A specifikáció, a tervezés és az implementálás párhuzamosan zajlik. Nincs részletes rendszerspecifikáció. Inkrementális fejlesztés. A végfelhasználók is részt vesznek minden lépés specifikációjában és az eredmény kiértékelésében. Indítványozhatnak változtatásokat és új követelményeket (gyakran). Felhasználói felület vizuális tervezéssel Kezelési egyszerűség: az egyszerűségre kell koncentrálni, mind a fejlesztendő szoftver, mind a fejlesztési folyamat tekintetében. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

121 Előnyök A szolgáltatások hamar használhatók Mivel a felhasználót bevonják a fejlesztésbe, a rendszer sokkal jobban meg fog felelni az igényeiknek és ráadásul jobban elkötelezik magukat a szoftver mellett. Az inkrementális szoftverfejlesztés közel áll az emberek probléma-megoldási módjához: mivel ritkán dolgozunk ki teljes megoldásokat, hanem a megoldásainkat lépésenként továbbfejlesztjük, és visszalépünk, ha hibáztunk. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

122 Nehézségek Nem biztos, hogy az ügyfél tud és akar is időt tölteni a fejlesztőcsapattal Személyi adottságok hiánya Gyakori áttervezés Az egyszerűség fenntartása külön munkát igényel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

123 Hátrányok Kezelési problémák - kevés a rendszerdokumentáció Szerződésbeli problémák - nincs rendszer- specifikáció A független validáció nehezen oldható meg A folyamatos változtatás elronthatja a rendszer struktúráját Dr. Johanyák Zs. Csaba - Szoftvertechnológia

124 Alkalmazás Mikor alkalmazzák? Kis rendszerek/ kis projekt Kevés fejlesztő Alacsony kritikussági fok Gyakran változó követelmények Csak gyakorlott, szenior fejlesztők esetén Mikor nem? Nagy és elosztott rendszerek Kritikus rendszerek Hosszú élettartamú rendszerek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

125 Agilis technikák eXtrém Programozás eXtrém Programozás Scrum KristályTiszta és más Kristály módszertanok Dynamic Systems Development Method Feature Driven Development (Funkcionalitáson Alapuló Fejlesztés) Test Driven Development (Tesztelésen Alapuló Fejlesztés) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

126 eXtrém Programozás Minden követelmény forgatókönyv (felhasználói történet) Ez feladatokra bontható és egy-egy feladat önállóan implementálható A programozók változó párokban dolgoznak és minden feladatra teszteket készítenek, mielőtt még a kódot megírnák Minden tesztnek sikeresen le kell futnia, mielőtt az új kódot elhelyeznék a rendszerben A rendszer kiadásai között csak kis idő telik el (pl. 1 hét) Folyamatos tökéletesítés (a kódot át kell írni, átszervezni, hatékonyabbá tenni, amikor csak lehet) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

127 XP lépések 1. A kiadáshoz történő felhasználói történet kiválasztása 2. A történet feladatokra bontása 3. A kiadás tervezése 4. A szoftver fejlesztése/integrálása/tesztelése 5. A szoftver kiadása 6. A rendszer értékelése 7. Vissza  1. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

128 Felhasználói történet „Egy cikk letöltése és kinyomtatása Először válasszuk ki egy megjelenített listából a kívánt cikket. Aztán adjuk meg a rendszernek a fizetési módot – ez lehet előfizetéses vagy vállalati számláról történő vagy hitelkártyával. Ezután kapunk egy kitöltendő szerzői jogi űrlapot. Ha ezt elküldtük, a cikk letöltődik a számítógépünkre. Ezután választunk egy nyomtatót és kinyomtatjuk a cikk egy másolatát. Közöljük a rendszerrel a sikeres nyomtatás tényét. Ha a cikk csak nyomtatható, akkor nem őrizhetjük meg a PDF-verziót, így az automatikusan törlődik a számítógépünkről.” Dr. Johanyák Zs. Csaba - Szoftvertechnológia

129 Feladatokra bontás „3. feladat: A fizetési lehetőségek implementálása A fizetés három különböző úton történhet. A felhasználó kiválasztja, hogy milyen módon szeretne fizetni. Ha a felhasználónak van könyvtári olvasójegye, akkor beírhatja ide annak azonosítóját, amit a rendszernek ellenőriznie kell. Másik lehetőség, hogy megad egy szervezeti számlaszámot. Ha az érvényes, akkor a cikknek megfelelő költséggel megterhelik a számlát. Végül beírható a 16 számjegyből álló hitelkártyaszám és lejárati dátum. Ellenőrizni kell ennek az érvényességét, és amennyiben érvényes, akkor terhelést kell küldeni a hitelkártyaszámlára.” Dr. Johanyák Zs. Csaba - Szoftvertechnológia

130 Teszteset-leírás „4. teszt: Hitelkártya érvényességének ellenőrzése Bemenet: A hitelkártyaszámot egy karaktersorozat, míg a kártya lejárati hónapját és évét két egész szám reprezentálja. Tesztek: Ellenőrizni kell, hogy a karaktersorozat minden bájtja számjegy- e. Ellenőrizni kell, hogy a hónap egy és 12 között van-e és az év nagyobb vagy egyenlő-e az aktuális évvel. A hitelkártya számának első négy számjegye alapján ellenőrizni kell, a kibocsátó érvényességét a kártyakibocsátók táblázata alapján. A hitelkártya érvényességét ellenőrizzük úgy, hogy elküldjük a kártyaszámot és a lejárati dátuminformációt a kártya kibocsátójához. Kimenet: OK vagy hibaüzenet, ami a kártya érvénytelenségét jelzi.” Dr. Johanyák Zs. Csaba - Szoftvertechnológia

131 Programtervezési minták Design Patterns Újrahasznosítható osztályok: igazodnia kell a megoldandó problémához  eléggé általánosnak kell lennie ahhoz, hogy később könnyen módosítható legyen Típusfeladatokra bevált megoldások Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (GoF - Gang of Four) 23 minta Minta: „Egymással együttműködő objektumok és osztályok leírása, amely testreszabott formában valamilyen általános tervezési problémát old meg egy bizonyos összefüggésben.” Azonosítja a résztvevő osztályokat és objektumokat, szerepüket és kapcsolataikat Dr. Johanyák Zs. Csaba - Szoftvertechnológia

132 Egyke - singleton A minta neve és besorolása: Egyke, objektum-létrehozási minta Cél: Egy osztályból csak egy példányt engedélyezni, és ehhez globális hozzáférési pontot megadni Egyéb nevek: Singleton Feladat: Egyes osztályok esetén fontos, hogy pontosan egy példány legyen belőlük. Egy rendszerben több nyomtató is lehet, de nyomtatási sorból csak egyet lehet használni. Vagy csak egy fájlrendszer és csak egy ablakkezelő futhat. Hogyan biztosíthatjuk, hogy egy osztályból csak egyetlen példány legyen, de azt könnyen el lehessen érni? Ha globális változót hozunk létre, akkor az objektum könnyen elérhető lesz, de akkor akárhány példányt létrehozhatunk belőle. Maga az osztály a felelős a példányok nyilvántartásáért. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

133 Egyke Alkalmazhatóság: Pontosan egy példányra van szükség egy osztályból és annak elérhetőnek kell lennie az ügyfelek számára. Az osztály bővíthető kell legyen (leszármazott osztályok), és az ügyfelek legyenek képesek a saját kódjuk módosítása nélkül használni a bővített osztály példányát. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

134 Egyke Szerkezet: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

135 Egyke Résztvevők: Egyke: Meghatároz egy olyan Példány műveletet, amely lehetővé teszi, hogy az ügyfelek hozzáférjenek az osztály egyedi példányához. A Példány statikus metódus. Felelős saját egyedi példányának (objektumának) létrehozásáért. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

136 Egyke Együttműködés: Az ügyfelek az Egyke példányt kizárólag az Egyke Példány műveletén keresztül érik el. Következmények: Az Egyke minta előnyei: Szabályozott hozzáférés az egyetlen példányhoz. Nincs globális változó. A leszármazással bővíthető az Egyke osztály funkcionalitása. Nem csak pontosan egy, hanem akárhány példány ellenőrzött létrehozására is alkalmas. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

137 C# megvalósítás class Egyke { private static Egyke EgyediPéldány; public static Egyke Példány() { if (EgyediPéldány == null) EgyediPéldány = new Egyke(); return EgyediPéldány; } protected Egyke(){ … } … } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

138 Használat Egyke e=new Egyke(); Miért nem jó a fenti utasítás? A jó megoldás: Egyke e=Egyke.Példány(); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

139 Tervezési minták osztályozása Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás:http://nik.uni-obuda.hu/erdelyi/CASE/DesignPattern_Singleton.pdf


Letölteni ppt "Szoftvertechnológia 2011/2012 – 2. félév levelező tagozat."

Hasonló előadás


Google Hirdetések