Szoftvertechnológia Gyurkó György

Az előadások a következő témára: "Szoftvertechnológia Gyurkó György"— Előadás másolata:

1 Szoftvertechnológia Gyurkó György
Megjegyzés: A lap új anyag. A lap olyan ismétlés a gazdasági informatika alapjai tárgyból, amely az objektumorientált elemzés és tervezés kurzus keretében is számon lesz kérve.

2 Technológiai célok és megoldások

3 A szoftvertechnológia általános célja
Kezelhetővé tenni a bonyolult (összetett) problémákat. Javítani a szoftver fejlesztési és megtérülési minőségi jellemzőit.

4 Komplex probléma kezelhetővé tétele
Bármilyen bonyolult is a probléma egésze, annak megoldása olyan út(hálózat) bejárásával produkál- ható, amelynek végül minden csomópontjában csak egyszerű problémákat kell megoldani. A feladat egésze csoportmunkában is elvégezhető, azaz felosztható a csoport tagjai által nagymérték- ben függetlenül megoldható részfeladatokra.

5 Szoftvertechnológiával befolyásolható szoftverminőségek (Fejlesztési és megtérülési minőségek)
elemezhetőség, változtathatóság, tesztelhetőség, stabilitás, hordozhatóság, újrafelhasználhatóság.

6 Technológiai megoldások
Modularizáció „Osztd meg és uralkodj!” A független problémák megoldásának elkülönítése.

7 Modularizáció - „Osztd meg és uralkodj!”
A probléma (a termék) olyan építőelemekre (modulokra) bontása, amelyek a környezetük számára fekete dobozok (absztrakció: részletek elrejtése); a környezet csak a stabil felületüket (interfész) ismerheti. a rendeltetése egymagában megérthető, meghatározható; önállóan (elkülönülten) tervezhető, kivitelezhető, tesztelhető; a modulokból a célul kitűzött rendszer felépíthető, a rendszer működése a modulok megfelelő együttműködé-sével produkálható. Többszintű, azaz hierarchikus modularizáció (felbontás).

8 Kitérő: Itt mit jelent az absztrakció?
Az absztrakció itt két jelentést hordoz: összetettséget és elrejtést. A modulok olyan – a szakterület jelenségeihez, a rendszertől elvárt szolgáltatásokhoz közelebb álló – összetett műveletek, amelyekből a rendszert könnyebb összerakni, mint a programnyelv elemi művele-teiből. Ugyanakkor egy-egy modult, egy-egy szűkebb szoftverépítő-elemet sokkal egyszerűbb kifejleszteni, mint a rendszer egészét. A modul az elrejtés eszköze, amennyiben a külvilágnak (más modulok-nak, a rendszer egészének) elegendő annyit tudni róla, hogy mit csinál (milyen adatokat vár, illetve milyen adatot szolgáltat), és csak a modul-ra tartozik, hogy hogyan csinálja. (Tömörebben: a modul a környezete számára fekete doboz.) Ennek az az előnye, hogy a modul belseje (a megoldás módja) anélkül módosítható, hogy az kihatással lenne a más modulokkal való együttműködésére. (Karbantarthatóság.)

9 A hierarchikus modularizáció következményei (a feladat „megszelídítése”)
A rendszer egészének szintje: Kevés elem (néhány nagyobb modul) és kevés kapcsolatot (az említett modulok közötti kapcsolatokat). A modulok fekete dobozok: érdektelen, hogy belül hogyan működnek, csak az a lényeg, hogy a rendeltetésük szerint elfogadható megszólításra (inputra), a rendeltetésük szerinti választ (outputot) adjanak. A modul belseje a többi modul számára észrevétlenül cserélhető, ha a környezet felé mutatott felülete nem változik. Összetett modul szintje: mint a rendszer szintje. Elemi modul szintje: Minden részletével együtt könnyen átlátható. Nincs akadálya a csoportmunkának, a felsorolt tulajdonságú modulok kivitelezése szétosztható egy csoport különböző tagjai között.

10 A független problémák megoldásának elkülönítése
A szoftver komponenseit (építőelemeit) úgy kell kijelölni, hogy adott probléma megoldásáért felelős (egyszerű vagy összetett) szoftverépítőelem mindig egyértelműen azonosítható legyen. Ha két probléma egymástól függetlenül is felmerülhet, vagy az egyik probléma megoldására vonatkozó köve- telmények a másik probléma megoldására vonatkozó követelményektől függetlenül megváltozhatnak, akkor ezen két probléma megoldása nem lehet egyetlen bonthatatlan építőelem feladata.

11 Újrafelhasználhatóság?
Az ismertetett technológiai megoldások hogyan javítják fejlesztési és megtérülési minőségeket? Elemezhetőség? Változtathatóság ? Tesztelhetőség? Stabilitás? Hordozhatóság? Újrafelhasználhatóság?

12 Megközelítési módok és módszertanok

13 A (szoftver)fejlesztési megközelítési mód egy sajátos absztrakciós szemlélet, amelyből sajátos
fogalomrendszer, eszköztár, elemzési (felbontási) és konstrukciós elvek következnek. A (szoftver)fejlesztési módszertan a fejlesztési folyamat minden architekturális összetevőjét lefedő, a kidolgozók által figyelembe vett célkitűzések és feltételek mellett legjobb gyakorlatnak szánt terméksémák, folyamatsémák és szervezeti sémák, valamint a felsoroltakhoz kapcsolódó értékelési (mérési) kritériumok együttese.

14 Megközelítési módok Moduláris Strukturált Objektumorientált

15 Módszertanok Alaptípusok: Folyamatvezérelt Eseményvezérelt
Adatvezérelt Felhasználóvezérelt Az előbbieket kombináló kevert típusok: Hagyományos Objektumorientált

16 A szoftverfejlesztés folyamata

17 Az IR fejlesztésének főbb tevékenységei
Ezek minden életciklusmodellben megjelennek: Elemzés Tervezés Megvalósítás, tesztelés, integráció Bevezetés

18 Elemzés Cél a követelmények meghatározása
A létező rendszer folyamatainak megfigyelése, elemzése Dokumentumok tanulmányozása Kérdőíves felmérés Interjúk a szakterület specialistáival, a felhasználókkal Termékek: Elemzési modellek Követelményleírások Rendszerszervezési változatok

19 Rendszerszervezési változat
A követelmények olyan részhalmaza, amely a projekt korlátai mellett teljesíthető és konzisztens (ellentmondásmentes és hivatkozásteljes) Megjegyzés: Kivételesen a fejlesztés (tervezés, megvalósítás) alatt megengedhetők ellentmondó követelmények is, de legkésőbb a szoftver telepítésekor el kell dönteni, hogy közülük melyik érvényes. Tehát ilyenkor a szoftvert fel kell készíteni a telepítési időre halasztott – és már a felhasználó által hozott - döntések fogadására.

20 Tervezés A szoftvertervezés termékei:
szakterületi (termék)modell: a szakterület fogalmainak, objektumainak, viszonyainak közvetlenül megfeleltethető absztrakciókat tartalmazó modell; architektúramodell: a tervezés és a megvalósítás struktúráját és követendő mintáit és az architekturális komponensek interfészeinek specifikációit tartalmazó modell; termékterv: nagyvonalú rendszer-, illetve szoftverterv, funkcionás modulok között interfészek specifikációk, valamint részletes szoftverterv; tesztspecifikációk: egységtesztekre, integrációs tesztekre, validáló tesztelésre; megoldásmodell: az architektúramodellt maradéktalanul érvényesítő részletes szoftverterv.

21 Tervezés / 2 A szoftvertermék elemezhetőségét, változtathatóságát, tesztelhetőségét, stabilitását, hordozhatóságát, valamint a komponenseinek újrafelhasználhatóságát szolgáló alapvető tervezési (konstrukciós) elv: Egymástól függetlenül előforduló problémákat nem szabad egyazon megbonthatatlan építőelemben megoldani!!! A problémák függetlenségének felismerését segítő osztályozási szempontok: szintek és vetületek - a strukturált megközelítés szerint; szintek, rétegek és minőségek – a korszerűbb módszertanokban.

22 Felhasználói felület / Környezet, események
A szoftvertervezés szintjei és vetületei a strukturált megközelítés szerint Vetületek Szintek Adat Feldolgozás Felhasználói felület / Környezet, események Fogalmi szint A szakterületi igények, szabályok figyelembevétele A kiszolgált szakterület adatai és ezeknek a szakterület szabályaiból következő kapcsolatai. Mit?: Milyen szolgáltatásokat kell nyújtani a rendszernek? Ennek érdekében milyen funkciói lesznek? (A funkciókat mint fekete dobozokat leíró specifikációk.) Szűkebben: az ember-gép kapcsolatra vonatkozó elképzelések. Tágabban: a környezet azon eseményei, amelyekre a rendszer reagál. Logikai szint Hatékonysági, biztonsági szempontok és szervezeti korlátok figyelembevétele Informatikai hatékonysági, biztonsági szempontok miatt szükséges további adatok, adatkapcsolatok. A szervezeti korlátokat is figyelembe vevő struktúra. Hogyan?: A megoldás – az egyes funkciók működésének – részletes megtervezése. Szűkebben: a felhasználói felület, párbeszédek részletes megtervezése – minden előtérfunkcióhoz. Tágabban: részletes eseménymodellek – a rendszer és a környezete interakcióinak megtervezése. Fizikai szint A technikai környezet sajátosságainak, korlátainak figyelembevétele Konkrét adatbázis-kezelő rendszer képességeit kihasználó és korlátait figyelembe vevő tervezés. Operációs rendszer, programnyelv, fejlesztő környezet, üzemeltető környezet sajátosságait figyelembe vevő tervezés. A párbeszédeszközök, konkrét kommunikációs kapcsolatok sajátosságait figyelembe vevő tervezés.

23 Egy finomabb rendszerezés: A SunTone módszertan architektúra-sémája
Az alkalmazás minden építőeleme egy meghatározott szintbe, illetve rétegbe sorolható, és egy meghatározott minőségért felel.

24 Az elemzés és tervezés technikái, eszközei
Grafikus modellezési technikák: tömörség, egyértelműség CASE (Computer Aided Software Engineering) eszköztár: a grafikus modellezési technikák integrált támogatása

25 CASE eszköztár használatának előnyei
Redundanciamentes terv Bizonyos tervezési-szintaktikai hibák automatikus kizárása A modellek konzisztenciájának ellenőrzése Iparági szabványnak számító technológia használata Csoportmunka támogatása A követelmények változásának és teljesülésének követhetősége Változáskezelés Az adatbáziskód (SQL) generálása (100%) és a programkód generálása (részben) Reengineering Dokumentációgenerálás

26 A fejlesztés további tevékenységei
Kivitelezés (kódolás és egységtesztek) Integráció és integrációs teszt Minőségi teszt Szoftver telepítése, bevezetése a használatba a szervezeti folyamatok újraszervezése – a szoftver szakmai felhasználási környezetének kialakítása; a szoftver testreszabása; az üzemeltetési, technikai környezet kialakítása, a rendszer üzemeltetési környezetbe telepítése; adatmigráció, azaz a korábbi rendszer adatainak konvertálása és betöltése az új rendszer adatbázisába; a felhasználók kiképzése; próbaüzemi teszt, azaz üzemi környezetben tényleges volumenek és csúcsterhelés melletti teszt; átállás az új rendszerre

27 Fejlesztési életciklusmodellek

28 Vízesés modell

29 Vízesés modell / 2 Előnyei: - Világos struktúra. - A projekt egyszerűen ütemezhető, irányítható. Hátrányai: - Csak a szakaszok végén van visszacsatolás. - Feltételezi, hogy a követelmények pontosan ismertek és nem változnak. - Hosszú a fejlesztési idő.

30 V modell

31 V-modell / 2 Előnyei / hátrányai: Többnyire azonosak az egyszerű vízesés modellével. - Az egyszerű vízesés modellnél világosabb képet ad arról, hogy adott tevékenység és annak terméke mely korábbi tevékenység termékének kell megfeleljen.

32 Iteratív fejlesztés / 1 Iteráció: Azonos tevékenység vagy tevékenységsor ismételt végrehajtása. Iteratív fejlesztés: Minden iteráció újabb minőséget ad az előző végrehajtás termékéhez. - Az iterációkat határozott célkitűzés, átfogó projektterv előzi meg. Nem önálló modell, hanem egy olyan, a célt fokozatosan közelítő megoldás, amelyet klasszikus életciklusmodellekkel kombinálva új életciklusmodellt kapunk. Iteratív fejlesztésen alapuló nevezetes modellek: az inkrementális modell a spirálmodell

33 Iteratív fejlesztés / 2 Az iteratív fejlesztés motivációi:
kezelni, hogy kezdetben nem lehet ismert minden követelmény; számolni az ismert követelmények megváltozásával; különlegesen nagy kockázatú projekteket is kezelhetővé tenni (lásd spirálmodell); minél korábban szülessen egy működő, átadott verzió (lásd inkrementális modell); az előző iterációk során szerzett tapasztalatok felhasználásával a módszerek, a termékminőség folyamatos javítása (inkrementális modell); megbízhatóbb termék (inkrementális modell: előbbi következménye; spirálmodell: kifejezetten a minőségi kockázatok csökkentését célzó prototípusok).

34 Inkrementális modell - átlapolással

35

36 Inkrementális modell előnyei, hátrányai
Kezelni tudja a követelmények változásait. Korán megszületik egy működő, átadott verzió (ez a projekt megítélése, a megrendelő elégedettsége szempontjából nagyon fontos); Az előző verziók fejlesztése és használata során szerzett tapasztalatok felhasználásával a módszerek folyamatosan javulnak, a követelmények finomodnak, a kockázatok csökkennek. A későbbi verziók egyre megbízhatóbbak (több tapasztalat, több sokszorosan kipróbált komponens a termékben). A teljes rendszer helyett csupán egy inkrementumot fejlesztő projekt akkor is elindítható, ha a szervezet szűkösebb emberi és pénzügyi erőforrásokkal rendelkezik. Elegendő erőforrások birtokában viszont az inkrementumok fejlesztésének átlapolásával a teljes rendszer fejlesztésének időtartama is csökkenthető. Hátrányai: Szűkös erőforrások esetén a teljes rendszer lassan készül el. A soklépéses folyamat és a párhuzamos tevékenységek irányítása nehéz feladat. A már működő részeket és a későbbi lépések eredményeit újra és újra integrálni kell.

37 További életciklusmodellek
Az iteratív fejlesztés valamilyen változatai (pl. Boehm-féle spirálmodell) A kombinált iteratív-inkrementális modell változatai (pl. a Rational Unified Process – RUP-modell) A felhasználó és a fejlesztő közötti jobb megértést, a követelmények pontosabb meghatározását, valamint a fejlesztés gyorsítását szolgáló modellek (pl. egyszerű prototípusmodell és annak evolúciós fejlesztés nevű változata) A követelmények megváltozásával szemben különösen toleráns modellek (pl. agilis módszertanok - extrém programozás) A ráfordítások – megvásárolható kész komponensek beépítésével való – csökkentő modellek (komponens alapú fejlesztés) Az esetleges minőségi hiányosságok katasztrofális következményeinek kockázatát módszeresen csökkentő modell (pl. Boehm-féle spirálmodell)