S01-6 Szoftverfejlesztési modellek

Hasonló dokumentumok
Programfejlesztési Modellek

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

S01-7 Komponens alapú szoftverfejlesztés 1

01. gyakorlat - Projektalapítás

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

S01-8 Komponens alapú szoftverfejlesztés 2

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

Szoftver újrafelhasználás

Kölcsönhatás diagramok

Autóipari beágyazott rendszerek. Komponens és rendszer integráció

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

Név: Neptun kód: Pontszám:

V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus

Szoftvertechnológia ellenőrző kérdések 2005

Információs rendszerek Információsrendszer-fejlesztés

Bevezetés a programozásba

Szoftvertechnológia 12. előadás. Szoftverfejlesztési módszerek és modellek. Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert

HASZNÁLATI ESET DIAGRAM (USE CASE DIAGRAM)

Tartalom. Szoftverfejlesztési. Szoftver = Termék. módszertan. la Rational XDE CASE eszköz. Az előállításához technológiára van szükség

Objektumelvű programozás

Már megismert fogalmak áttekintése

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Verifikáció és validáció Általános bevezető

Objektumorientált paradigma és a programfejlesztés

S0-02 Típusmodellek (Programozás elmélet)

UML (Unified Modelling Language)

Objektum orientált software fejlesztés (Bevezetés)

OOP. Alapelvek Elek Tibor

Eseménykezelés. Szoftvertervezés és -fejlesztés II. előadás. Szénási Sándor.

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár

Objektumorientált paradigma és programfejlesztés Bevezető

Interfészek. PPT 2007/2008 tavasz.

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár

Információtartalom vázlata

TOGAF elemei a gyakorlatban

Bánsághi Anna 2014 Bánsághi Anna 1 of 31

Komponens alapú programozás Bevezetés

4. A szoftvergyártás folyamata

Metamodellezés. Simon Balázs BME IIT, 2011.

1. SW fejl. modellek. V-modell: Vízesés módosítása, az egyes fázisokat előbb ellenőrzik visszacsatolás nagysága és hatása csökken.

Programozási alapismeretek 4.

és az instanceof operátor

Java programozási nyelv

Java VIII. Az interfacei. és az instanceof operátor. Az interfészről általában. Interfészek JAVA-ban. Krizsán Zoltán

Modellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK

UML Feladatok. UML Feladatok

Magas szintű adatmodellek Egyed/kapcsolat modell I.

Szoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II.

Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata

Bevezetés a Programozásba II 5. előadás. Objektumorientált programozás és tervezés

Előzmények

Osztálytervezés és implementációs ajánlások

Osztálytervezés és implementációs ajánlások

Modell alapú tesztelés mobil környezetben

Folyamatok. 6. előadás

Iman 3.0 szoftverdokumentáció

SOA modell: Ez az interfész definiálja az elérhető adatokat, és megadja, hogy hogyan lehet azokhoz hozzáférni.

Szakterületi modell A fogalmak megjelenítése. 9. fejezet Applying UML and Patterns Craig Larman

Programozás III KIINDULÁS. Különböző sportoló típusok vannak: futó, magasugró, focista, akik teljesítményét más-más módon határozzuk meg.

Az iskolai rendszerű képzésben az összefüggő szakmai gyakorlat időtartama. 10. évfolyam Adatbázis- és szoftverfejlesztés gyakorlat 50 óra

1. Mi a fejállományok szerepe C és C++ nyelvben és hogyan használjuk őket? 2. Milyen alapvető változókat használhatunk a C és C++ nyelvben?

Függőség injekció Konstantinusz Kft 2010

Programozás III. - NGB_IN001_3

Szoftverprototípus készítése. Szoftverprototípus készítése. Szoftverprototípus készítése

Minőségmenedzsment és Informatika Test-Driven Development

Összefoglalás. Készítette: Siklósi Zsolt info2007

Utolsó módosítás:

A SZOFTVERTECHNOLÓGIA ALAPJAI

Objektum orientáltság alapjai A Java nyelv Fordítás - futtatás

Verziókövető rendszerek használata a szoftverfejlesztésben

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor

C++ programozási nyelv

Használati alapú és modell alapú tesztelés kombinálása szolgáltatásorientált architektúrák teszteléséhez az ipari gyakorlatban

Szoftverfejlesztő képzés tematika oktatott modulok

Bánsághi Anna 1 of 67

Kommunikáció. Távoli eljáráshívás. RPC kommunikáció menete DCE RPC (1) RPC - paraméterátadás. 3. előadás Protokollok. 2. rész

A dokumentáció felépítése

Programozási technológia 2.

Programozási nyelvek II. JAVA

Projectvezetők képességei

Bevezetés. Szendrei Rudolf Informatikai Kar Eötvös Loránd Tudományegyetem. Programozási technológia I. Szendrei Rudolf. Bevezetés. Szoftvertechnológia

Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom

Objektumorientált felbontás

Tudásalapú információ-kereső rendszerek elemzése és kifejlesztése

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

OO rendszerek jellemzői

30 MB INFORMATIKAI PROJEKTELLENŐR

Tervezés és elemzés elmélete jegyzet 1

A Java EE 5 plattform

A szoftverfejlesztés eszközei

Programozás II. 3. gyakorlat Objektum Orientáltság C++-ban

C# Szálkezelés. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) C# Szálkezelés / 21

COMET webalkalmazás fejlesztés. Tóth Ádám Jasmin Media Group

NC program ellenorzo szimulátor fejlesztése objektumorientált módszerrel

Dr. Mileff Péter

Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E

LabView Academy. 4. óra párhuzamos programozás

Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

Széchenyi István Egyetem. Programozás III. Varjasi Norbert

Átírás:

S01-6 Szoftverfejlesztési modellek Tartalom 1. Szoftverfejlesztési modellek (vízesés, spirális, evolúciós, RUP, XP, xuml) 2. Architekturális minták és hatásuk a rendszer minőségi jellemzőire 3. Tervezési minták (GoF, valamint 3 további létrehozási minta) 4. Konkurens minták 5. Antiminták, újratervezési minták 1. Szoftverfejlesztési modellek (vízesés, spirális, evolúciós, RUP, XP, xuml) A szoftverfejlesztés hagyományos fázisai: 1. Követelmények felmérése 2. Specifikáció 3. Vázlatos/finom tervek készítése 4. Implementáció 5. Integráció 6. Verifikáció/validáció (megfelel-e a specifikációnak/ezt kérte-e a user) 7. Rendszerkövetés/karbantartás Ezeket használják fel, vagy módosítják a következő szoftverfejlesztési modellek. 1.1 Vízesés modell Az egyes fázisok lineárisan követik egymást. Előre megtervezi a projekt időtartamát, ráfordításait. Elvárja minden fázis megfelelő dokumentálását, amely tartalmazza annak eredményeit. Jól strukturált dokumentált folyamatot biztosít. Nehézkes a megszervezése, tervezése és fájdalmas az új feature-ök bevezetése. Nem teszi lehetővé a követelmények megváltoztatását, nem készül fel az esetleges nehézségekre. Csak akkor szabad egy fázisról a következőre ugrani, ha az előző biztosan véget ért (reviewed & verified). Rövid élettartamú, előre jól specifikálható projekteknél lehet jó. 1

Figure 1: Vízesés modell 2

1.2 Boehm féle spirális modell A spirál minden hurka a gyártási folyamat egy fázisát jelképezi. Nincsenek fix hurkok, (pl.: specifikáció, vagy tervezés), azok az igényeknek megfelelően alakulnak ki. Minden ilyen fázisnak 4 szakasza van: (az ábrán lásd bal fentről kezdve) 1. A célok és korlátok meghatározása 2. Különböző megoldások elemzése, stratégiák kialakítása. Prototípus készítés 3. Az előző pont feladatának megoldása 4. A következő lépés megtervezése (nyilván az utolsónál ilyen nincs) A módszer jól dokumentálható, áttekinthető, a fázisok rugalmasak. Ellenben elég drága a sok kidolgozás és próbálgatás. A 3. pont kivételével nehezen párhuzamosítható. a fejlesztés ciklusokban történik, amelyben az elkészített prototípusok, valamint a továbbfejlesztésével kapcsolatos kockázatok kiértékelésre kerülnek előnyei: jobban alkalmazkodik a változó követelményekhez a prototípusok lehetővé teszik a nehézségek előrelátását hátrányai: költségesebb a prototípus elkészítése és a kockázatkiértékelés végett továbbá a prototípusok megzavarhatják a felhasználót 1.3 Evolúciós modell Akkor jó, ha nincs pontos specifikáció Először a prototípust készítjük el, majd a megrendelővel folyamatosan egyeztetve jutunk el a végleges megoldásig Hátránya, hogy gyenge a dokumentáció, áttekinthetetlen egy idő után és nehezen módosítható. 1.4 RUP (Rational Unified Process) Az UML alkotóitól egy iteratív, inkrementális módszer. 4 fázisa van, mindegyik állhat több iterációból, ezeken belül munkafolyamatokból: modellezés, követelményelemzés, tervezés, implementáció, tesztelés, telepítés, konfigurálás, változáskezelés, projektvezetés, stb Fázisai: 1. Előkészítés: Architektúra, költségbecslés. (Use case és activity diagramokkal) 2. Kidolgozás: Minimális kódolással az 1.) véglegesítése, innen már csak építeni kell. 3. Megvalósítás: Ez a fejlesztési fázis, egészen a tesztelésig 3

Figure 2: Spirális modell 4

4. Átadás: Kb készen van, még tesztelendő, újrakiadható állapot javításokkal Figure 3: RUP 1.5 Extreme Programming (XP) Lightweight fejlesztés, kis csapatokkal, határozatlan, változékony körülményekre. Alapelvei, hogy mindig a legegyszerűbb megoldást válasszuk, azokat csináljuk meg először, van idő próbálkozni. Ha egy megoldás rossz, el kell dobni! Kis csapatokban, folyamatosan tanulva, pair-programming alkalmazásával a lehető legmagasabb minőséget biztosítva kell dolgozni Fázisai: 1. Feltárás: Az architektúra kitalálása (pár hét) 2. Tervezés: Az első kiadás határidejének megállapítása (pár nap) 3. Iterációk: 1-4 hetes, 2-6 hónapos kiadások, itt történik a fejlesztés nagy része. 4. Fejlesztés, karbantartás, befejezés: Konfiguráció, bővítés, módosítás és átadás 5

Figure 4: XP Figure 5: XP 6

1.6 Végrehajtható UML (xuml) Ebben az esetben csak egy platformfüggetlen modell van, csak a feladatra koncentrálunk. Ebből pedig kódgenerálással előáll a platformfüggő termék. Ezt az UML megszorításával (és kiterjesztésével) valamint az Action Specification Language-dzsel érjük el. Menete: Meghatározzuk a alrendszereket (use case és szekvencia diagramokkal) Létrehozzuk a modellt (osztálydiagramok és állapotdiagramok) Ellenőrizzük őket Modellfordítást végzünk (kódgenerálás) A komponensekből összeállítjuk a terméket 2. Architekturális minták és hatásuk a rendszer minőségi jellemzőire A rendszer kívülről látható részeit mutatja meg, a belső implementációt NEM. Az elemek által nyújtott szolgáltatások, kommunikáció, hibakezelés, erőforrás használat tartozik ide. A kezdeti döntések kihatnak a következő tulajdonságokra: Rendelkezésre állás Megbízhatóság Teljesítmény Biztonság Tesztelhetőség Használhatóság Csövek és szűrők: Adatfolyam feldolgozása a komponensek (szűrők) között. A komponensek bemenettel és kimenettel rendelkeznek és valamilyen transzformációt hajtanak végre az adatokon. Az adatokat pedig a csövek szállítják. Van passzív és aktív szűrő. Az aktív szűrő tud igényelni és küldeni is. Két aktív szűrő között a kommunikációt az egyik szűrő vagy a cső szinkronizálja. Ha a szűrők lineárisak, akkor csővezetékről beszélünk. Objektumelvű rendszer: A komponensek objektumok, közöttük eljáráshívással történik a kommunikáció. A belső reprezentációjuk rejtett. A kommunikációhoz kapcsolat kell, és ha az egyik publikus része változik, akkor valószínűleg a használóját is módosítani kell. Eseményalapú rendszer: A komponensek nem tudják, hogy más milyen eseményeket bocsát ki, mire iratkozik fel és milyen sorrendben szolgálódik ki. Sőt, nem tudni, hogy ki-mit csinál és meddig. 7

Réteg szerkezetű rendszer: Minden réteg az alatta lévő szolgáltatásait használja, vele kommunikál. A módosítások max 1-2 réteget érintenek, tesztelés esetén lehet szimulálni a rétegeket. Gyűjtemény: Komponens adattár, komponensek veszik körbe és tárolja őket. Ha végre is hajt műveleteket, akkor táblának, ha nem, akkor adatbázisnak nevezzük. Így a komponensek függetlenek is lehetnek egymástól, jól módosítható. Virtuális gép, értelmező: A bemenő adatokat értelmezi, feldolgozza, majd a feldolgozó interfészen ki is adja az eredményt. Modell-Nézet-Vezérlő: A rétegek elkülönülnek. A modell az adatokért és a rajtuk végzett műveletekért felel. A nézet a megjelenítésért, míg a vezérlő a felhasználói utasítások kezeléséért felel. A rendszer sajnos könnyen bonyolulttá válhat. Továbbiak: szerver-kliens, modell-nézet, gyakran használt módszerek : állapotgép-rendszer, felügyelő (supervisor), monád ( számítás-építő ) 3. Tervezési minták (GoF, valamint 3 további létrehozási minta) A Gang of Four (GoF) a Design Patterns: Elements of Reusable Object- Oriented Software könyv négy szerzője Az objektumelvű rendszer tervezésekor építünk ezekre az újrafelhasználható stratégiákra. 23 tervezési mintát írtak le amelyek 3 osztályba sorolhatóak: létrehozási, szerkezeti és viselkedési Létrehozási Egyke (Singleton): Az osztályból csak 1 példány létezhet globálisan. A változóban tárolás nem jó ötlet. Helyette tegyük a konstruktort protecteddé és egy publikus metóduson keresztül lehessen ezt meghívni, ahol a konstruálás biztonságos. Ha nem létezik még az objektum, akkor hozza létre, ha létezik, akkor azt adja vissza. Építő (Builder): Összetett objektumok konstruálásának szétválasztása. A konstrukciós folyamat eltérő reprezentációt hozhat létre. (konstrukció leválasztása a repr.-ről) Gyártó művelet (Factory Method): Az objektum létrehozási felületét úgy határozzuk meg, hogy alosztályok döntsék el, mely osztályba tartozzon az objektum. Absztrakt gyártó (Abstract Factory): Felület összetartozó objektumok családjának létrehozására (az interfész adja a család jelleget, mert egymás mellé kerülnek a létrehozóműveletek, a konkrét esetben pedig alákerül az implementáció). Gyártóműveletek gyártójaként is felfogható. 8

Prototípus (Prototype): Új objektum létrehozása egy ilyen prototípus másolásával (clone metódus hívása). Cachelésre használható például. Szerkezeti Összetétel (Compositer): Fa struktúra, egyedileg és egészben is kezelhetőek a résztvevő elemek, mind ugyanazzal a felülettel rendelkezik. Híd (Bridge): Szétválasztja az absztrakciót az implementációtól, így azok egymástól függetlenül fejleszthetőek. Futási időben lesz összekötve az absztrakt az implementációval. Díszítő (Wrapper): Származtatás nélkül egészíti ki az objektum műveleteit. Ehhez az objektumot be kell ágyazni egy másikba. Arculat (Facade): Bonyolult alrendszerek közös felülete. Könnyűsúlyú (Flyweight): Megosztás nagy számú objektum között, mert a sok objektum sok memóriát foglalhat. Ilyenkor érdemes a közös részeket egy másik osztályba kiszervezni. Helyettes (Proxy): Hozzáférhetőség szabályozása. Amíg nem akarjuk használni az objektumot, addig ne inicializálódjon. Viselkedési Figyelő (Observer): Ha egy objektum állapotot vált, akkor a rá feliratkozottakat értesíti. A tárgy ismeri a figyelőket, fel/le tudnak iratkozni, a figyelő pedig le tudja kérdezni a figyelt tárgy állapotát. Iterátor (Cursor): Egy aggregátum végigjárása a szerkezet ismerete nélkül. Ezen kívül a listát akár több módon (visszafelé, kettőt lépve, párhuzamosan) is be lehet járni. Állapot (State): Állapottól függően más viselkedés (kicsit mintha osztályt váltana futás közben). Van egy context ami tartalmazza a state-et. A state egy State interfészt megvalósító osztály egy példánya. A context-ből hívhatjuk a state valamely metódusát aminek paramétere a context maga, ami pedig beállíthat a context-nek egy új állapotot (state új implementációját). Ha változott a state, akkor legközelebb már State interfész egy másik implementációja fog lefutni. Közvetítő (Mediator): Olyan objektum megadása, ami megmondja más objektumok, hogy működnek együtt. Nem szerencsés ha mindenki ismer mindenkit, vagy hosszú az öröklődési lánc. (az obj-ok csak a mediátort ismerik, egymást nem) Feljegyzés (Memento): Feljegyezzük egy objektum állapotát, hogy később visszanézhessük (pl UNDO művelethez). Csak az objektum láthatja. Kezelési lánc (Chain of responsibility): A kezelőket láncba fűzzük, majd valaki lekezeli az igényt. A default kezelő kerül a lánc legelejére. Stratégia (Strategy): Algoritmusok halmazának létrehozása, beágyazása, cserélhetősége. Van egy közös felületük, az ősosztály. 9

Látogató (Visitor): Egy szerkezeten végigjárunk és végrehajtunk egy műveletet. A műveletet a szerkezet különböző pontjain máshogy kell használni. Akkor jó, ha sok különböző új művelet van, de az osztályszerkezet stabil. Értelmező (Interpreter): Ha egy probléma sokszor fordul elő, érdemes egy nyelv mondataként leírni és egy értelmezőt írni hozzá. 3 További minta- Lusta példányosítás: Olyan, mint a proxy, csak itt addig nem hozhatja létre az új objektumot, amíg nem kap rá engedélyt. Lusta gyártó: Gyártó művelet + lusta példányosítás. Objektumkészlet: Ha valakiből sok kell, akkor nem érdemes folyton létrehozni, hanem néhány darabot tárolunk és azokat adogatjuk. 4. Konkurens minták Eseményalapú aszinkron hívás: Ha egy esemény sokáig tart, egy új szálban indítjuk el Ütemező: szálak sorbaállítása (pl szekvenciális kód kell egy adott helyen, nem futhatnak akárhogy a szálak) Aktív objektum: Minden művelet futtatás külön objektum. Párhuzamosítható, szinkronizálható. Blokkolás: Csak akkor engedünk egy szálnak végrehajtani egy műveletet, ha az objektum egy bizonyos állapotban van. (más esetben szimplán eldobjuk a műveletet) Író-olvasó zárás: Több olvasó lehet, de egyszerre csak egy író. (írás közben nincs más I/O!) Threadpool: Olyan, mint az objektumkészlet. Termelő-fogyasztó: Aszinkron, párhuzamos folyamatok. Feladatok generálása/végrehajtása. A termelő egy közbeiktatott raktárba helyezi az objektumokat, ahonnan a fogyasztó kiveheti. 5. Antiminták, újratervezési minták Antiminták Mindenható objektum: Túl sokat tud, egy idő után borzasztóan nehéz lesz a módosítás. Kör-ellipszis probléma: Mi az általánosabb? Mindig attól függ, milyen műveletek vannak. Felesleges rétegződés: Ha túl sok réteg van a rendszerben, érdemes összevonni néhányat. Jojó probléma: Túl hosszú az öröklődési lánc. Poltergeist objektum: Az osztály összes objektumának élete túl rövid (pl: paraméter átadás, üzenetküldés, stb) 10

Újratervezési minták Létrehozó metódus: Olyan, mint a singletonnál. Inkább legyenek olyan műveltek, amik visszaadnak egy objektumot. Műveletek kihelyezése: Egy bonyolult művelet egy részét kihelyezzük, ezzel több kisebb műveletre bontva, amelyek egyenként már könnyebben értelmezhetőek. NullObject: A nullreferencia sokszor gondot okozhat. Ilyenkor érdemes egy NullObject típust bevezetni. További források Előző éves kidolgozás 11