Szoftver technológia - 2005 ProgMat - 1. Szoftver életciklus modellek 1.1 Klasszikus waterfall vízesés modell Jellemzői: Technikai problémának tekintia fejlesztést. Nem foglalkozik a kommunikációs csatornákkal. Visszacsatolás túl későn lehetséges. Gyakorlatilag csak a teljes rendszer elkészülte után van rá mód. Diagram: 1.2 Gyors prototípus rapid prototyping modell Jellemzői: Elősegíti a fejlesztő és a felhasználó kommunikációját ellentétben a waterfall modellhez képest. Föleg kis csoportok számára javasolt a tapasztalatok szerint. Diagram: 1.3 Evolúciós inkrementálsi modell Jellemzői: Az eredeti célhoz egyre közelebb álló rendszerek sorozata. Minden egyes rendszer átmegy legalább a tervezés, az implementálás és a tesztelés fázisán.
Diagram: 1.4 Újrafelhasználási modell Jellemzői: Alulról felfelé építkező modell. Gyors módszer, ha van elég építőanyag. Azaz elegendő újra hasznosítható elemünk. Hatékonyság a szükséges helyeken utólag javítható. Újrahasználható elemek: Implementáció algoritmusok függvény könyvtárak osztály és objektum könyvtárak szoftver komponensek korábban fejlesztett, hasonló rendszerek Tervezés tervezési minták bevált architekturális megoldások Analízis, specifikáció leginkább az előző fejlesztések tapasztalatai Diagram:
1.5 Very High Level Languages Nem-procedurális nyelvek, alkalmazás-generátorok. Jellemzői: A fejlesztő eszköz számára le kell írni, hogy mit csináljon. A többi az eszköz dolga. Általában jól körülhatárolt területekre javasolt, mint például Oracle, FOCUS, Magic-AB alkalmazások. Esetleg hatékonysági problémák léphetnek föl. Diagram: 1.6 Spirál-modell Boehm 1988-s modellje. Újdonság a korábbi modellekhez képest a kockázat kezelés. Jellemzői: A fejlesztés iterációs lépések sorozata. Az egyes iterációkban kitűzött célok folyamatosan fejlődnek. Valamennyi fázis ciklikusan változik. Ezt ábrázolva kapjuk meg a spirálhoz hasonlatos alakzatot. Minden rész megoldását, részmegoldást ki kell értékelni. Elemezni kell az adott megoldás kockázatát. Ha a kockázat kisebb, mint a várható haszon akkor következhet a következő ciklus. Diagram:
2. Alapfogalmak (módszer, technika, eszköz) Módszer (methodology): Tudás, azaz a tapasztalat és az ajánlott technikák ( tudás + ajánlott technikák) Jó módszer jellemzői Hatékonyság Racionalítás, azaz tudományos alapok, melyeket a gyakorlat igazol. Konzisztens az egyes fázisokban. Teljes, azaz minden fázisra ajánl megoldást. Ismételhető, azaz személytől független, jól definiált, és megtanulható. Automatizálható és automatizált. Technikák célja: Az egyes részfolyamatok segítése. Információk rögzitése az egyértelműség elsősegítése véget. Kapcsolatok rögzitése. Ellentmondások kiszűrése. Leggyakrabban grafikus felület. Eszközök: Programok, amelyek támogatnak módszer(eke)t techniká(ka)t dokumentáció készítést Jellemzője az integráltság színtje és a támogatott fázisok száma. 3. Dekompozíció Alap probléma a szoftver komplexitása. A megoldás reménye, hogy a részek ösz komplexitása kisebb, mint az egész komplexitása. A dekompozíció lényege a teljes szoftver módszeres részekre bontása. Egy módszer meghatározza a dekompozíció elveit. Funkcionális szemlélet: Program = adatszerkezetek + algoritmusok Dekompozíció alapja adat avgy processz. Módja felülről lefelé (top-down) vagy alulról fölfelé (bottom-up). Modulok között kommunikációszükséges ebből következik a belső interface szükségessége. Dualítás elve Modul Processz alapú (Algoritmus) Adat alapú (Adatszerkezet) Adatszerkezet Algoritmus Interface Több lépés szükséges ebből következnek az absztrakciós színtek! Objektum Orientált szemlélet: Program = együttműködő objektumok halmaza Struktúra az osztályok/objektumok közötti kapcsolatok, működás üzenetváltás, és a modulok egysége az osztály. 4. Analízis fázis célja, feladata, szemlélete. Célja: A projekttel szemben támasztott követelméynek meghatározása. Felhasználó igényei. Elérendő célok és haszon. Emberi, gépi erőforrások.
Időszükséglet. Költségek. Szervezeti követelmények. Feladata: A rendszerre vonatkozó összes információt összegyűjteni és megérteni. Ehhez szükséges elemezni a meglévő, jelenleg müködő és a tervezett, leendő rendszert. Szemlélete: A legfontosabb szempontok a teljesség, az egyértelműség és a dokumentáltság. A cél tehát a harácsolás! 5. Analízis fázis módszerei (használható) Használható módszerek: A felhasználói munkafolyamat megfigyelése. Gyakorlat az adott területen. Interjúk, melyekben folyamatosan rákérdezünka dolgokra. Kérdőívek. Az alkalmazás elméletének és gyakorlatának kutatása. Analógia más rendszerekkel. Meglévő dokumentáció tanulmányozása. Eljárási szabályok Bizonylatok Jelentések, összesítések Szervezeti felépítés Munkaköri leírások Hatáskörök szabályozása Vonatkozó külső előírások Törvények, előírások Szerződések, megállapodások, vállalt kötelezettségek CASE eszközök Dokumentációs technikák Teljesség és konzisztencia vizsgálat A további fázisokban felhasználható forma Adatszótár Prototípus készítése Jobb kommunikáció a felhasználóval (Gyors prototípus modell) A felhasználó időben felismerheti az igényei teljesíthetetlenségét vagy pontatlanságát. A fejlesztő jobban megértheti a felhasználó munkamódszereit. Jó munkamódszer jellemzői: Rámenősség Kérdezzünk rá mindenre, mert így a magától érthetödö dolgokra, mehanizmusokra is fényderülhet. Ne hagyatkozzunk a megérzéseinkre vagy feltételezéseinkre. Pártatlanság Ne befolyásoljanak részérdekek. Az összes résztvevő számára legjobb megoldást keressük. Előítélet mentesség tételezzük fel, hogy minden lehetséges. Ne fogadjuk el feltétel nélkül pl. Ezt mindig is így csináltuk...
Ezt én mindig így oldottam meg eddig... A hagyomány lehet, hogy már csak értelmetlen megszokás. Figyeljünk a részletekre Minden tény összefügg(het) más tényekkel. Minden definíció legyen precíz. Gondoljunk a kivételes esetekre is. Egy adat/információ a rendszerben csak akkor felesleges, ha mindenkinek az! Kreativitás Tekintsünk friss szemmel a rendszerre. 6. Követelményekosztályozása jellemzésük (3db) Három absztrakciós szint: Felhasználói követelmények Rendszerkövetelmények Szoftver tervervezés specifikációja. Ennek az elkészítésének a feladata a specifikációs fázis feladata. Szokásos felosztás: Funkcionális követelmények Nem funkciónális követelmények Szakterületi követelmények Funkciónális követelmények: A rendszertől várt funkciók és szolgáltatások leírása. Különböző részletezettséggel adhatók meg. A felhasználó vagy a fejlesztő szemszögéből is megfogalmazhatók. Elvben teljesek és ellentmondás mentesnek kell lennie. A késöbbi munkafolyamatok során felfedezett hiányosságok javítandók, így a fejlesztés során egyre pontosabb leírást állítunk elő. Nem funkcionális követelmények: Nem közvetlenül a rendszer szolgáltatásaira vonatkozó követelmények. Általános rendszertulajdonságok, például Megbízhatósági, biztonsági szint. Válaszidő, kapacitás igények. Minőségi jellemzők. Környezettel való kapcsolat, például Más rendszerekkel való kapcsolattartás. Hardver és szoftver adottságok, abból adódó korlátozások. Szervezeti szabályok, törvényi előírások. A fejlesztési folyamatra vonatkozó előírások. Használandó módszertan. Előírt minőségbiztosi modell. Előírt/Elvárt fejlesztőeszközök. Problémák: Nem mindig könnyű eldönteni, hogy egy követelmény funkcionális vagy nem funkcionális. Egy nem funkcionális követelmény új funkcionális követelmény megjelenését jelentheti. Szakterületi követelmények: Nem közvetlenül felhasználói igényekből, hanem az alkalmazás által kiszolgált szakma követelményeiből adódik. Adhat új funkcionális vagynem funkcionális követelményt. Jelenthet korlátozást már mefogalmazott követelményhez.
Előírhatja egy adott rendszer funkció végrehajtásának módját. Problémák A fejlesztők számára nehezen érthetőek. Gyakran hiányosak, mert bizonyos szabályok a szakmai szakértők számára nyílvánvalóak. Felhasználói követelmények: A rendszer külső viselkedése a felhasználó fogalmaival. Eszközei: Természetes nyelv. Közismert ábrázolási módok, táblázatok. Use-case modell (UML) Problémák Egyértelműség hiánya. Követelmények keveredése. Követelmények összeolvadása. Célszerű elkülöníteni a technikai jellegű renszerkövetelmény leírástól. Tippek... Használjunk egységes formátumot. Használjunk kiemeléseket. Ha szükséges mindennapi szavak jelentésében is egyezzünk meg. Szótár 7. Dokumentáció használói, kik, mire használják Használói Mire használják Megrendelő Menedzserek Rendszertervező Tesztelők, minőségellenőrök Karbantartók Követelmények meghatározása, ellenörzése, változások megadása. Árajánlat készítése, a fejlesztési folyamat tervezése és ellenörzése. Annak megértése, hogy milyen rendszert kell fejleszteni. A rendszer működésének és minőségének ellenörzéséhez. A rendszer működésének és a rendszer részei közötti összefüggések megértéséhez. 8. Analízis és specifikációs fázis összehasonlítása (fogyasztó, nyelv,...) Analízis Specifikáció Fogyasztó: Felhasználó Szoftver fejlesztő Nyelv: Természetes nyelv Formális nyelv Pontosság: Nem precíz Precíz Terminológia: Az alkalmazás szakkifejezései Szoftver terminológia Szemlélet: Nem technológiai Technológiai
9. Strukturált specifikációs technikák (2 db, ábra, darabonként rövid leírás) Három komponens: Ezért léteznek Processz-specifikációs és Adat-specifikációs technikák. Processz-specifikáció: Adatfolyam diagram Állapotátmenet diagram állapotok, átmenetek, feltételek Döntési tábla, döntési fa. Mátrixok a függőségek időbeliségek ábrázolására. Adat-specifikáció: ER diagram. (EER is?) Jackson ábra 10. Specifikációs ajánlások (IEEE, RUP) IEEE: Követelmény analízis során készített dokumentum kiegészítése az alábbiakkal Rensdzerkövetelmény specifikáció Funkcionális és nem funkcionális követelmények pontos leírása. Más rendszerekkel való együttműködéshez szükséges interface-ek. Felhasználói interface leírása. Rendszermodellek A rendszer komponensei és azok kapcsolatai. Rendszer és környezetének kapcsolatai. Adatfolyam modellek. Szemantikus adatmodellek. RUP: SRS Körülbelül, mint az IEEE ajánlása. A rendszer funkciónalításait összefoglaló Use-case modell megalkotása. A Use-case modellben nem jól dokumentálható követelmények leírása. SAD Rendszermodellek leírására. A tervezési fázis során kibővül. Test Plan Tesztelési terv. 11. A tervezés szintjei, azok jellemzői (3 db) Külső (interface) tervezés.
Architekturális tervezés. Részletes tervezés. Külső tervezés: A szoftver külvilággal való kapcsolatának megtervezése. Csak technikai kérdés a más szoftverekkel és hardverekkel való kapcsoalt. A felhasználói felület tervezése kulcskérdés, mert ez jeleníti meg a program funkcionalítását a felhasználó felé. Nem csak technikai szempontok vannak. Prototípus készítése hasznos lehet. Időben elhúzódó is lehet. Diagramok: Kapcsolatok. Időben elhúzódó is lehet! Architekturális tervezés: A rendszer struktúrájának megtervezése. Több lépéses folyamat. A lépések száma mérettől függ. Egy alacsonyabb szint a felette lévő dekompozíciójával vagy az absztrakciós szint csökkentésével jön létre. Bármely szinten álló struktúra, modulok és a közöttük lévő interface-ek rendszere. Diagram: Strukturális tervezés: A tervezés végét jelzi, ha a modulok belső komplexitása és az interface-ek komplexitása hasonló. Objektum-Orientált megközelítésnél modul az objektum.
12. Objektum Orientált technológiák Programnyelvek (OOP) Szoftver trevezés (OOD) Szoftver specifikáció (OOA) Szoftver követelmény analízis (OORA) OOA: A rendszer megkívánt viselkedésének leírása. Felfedezzük a problématér (domain) lényeges osztályait illetve objektumait és kapcsolataikat a követelmény analízis felhasználásával. Osztály vagy objektum lehet esemény (helyfoglalás) OOD: szerep (utas) szervezeti egység (légitársaság) (al)rendszer (repülőgép) processz (járat) hely (célállomás) eljárás, függvény Feladata megtalálni és kiválasztani a megoldási tér osztályait és objektumait, azok viszonyait és együttműködésük módját. A megoldási tér osztályai Problématér osztályainak a leképzései. A megoldás céljából a tervező által létrehozott osztályok. Diagram: 13. UML fogalma, célkitűzései Fogalma: Az UML egy nyelv arra, hogy specializáljuk, vizualízáljuk, megkonstruáljuk és dokumentáljuk a szoftvert üzleti és egyéb nem szoftveres renszerek számára. Az UML a legjobb technikák gyűjteménye. Célkitűzései:
Kifejező vizuális modellező nyelv biztosítása. Fejlesztés támogatása. Kommunikáció támogatása. Lehetőség az alap koncepció bővítésére és specializálására. Alkalmazkodni tudjon a különböző fejlesztések szükségleteihez. Programozási nyelvtől és módszertantól független legyen. Biztosítson formális alapot a modellező nyelv megértéséhez. Támogatja az objektum orientált eszközök fejlesztését. Eddigi gyakorlati tapasztalatok integrálása. Magas szintű fejlesztési koncepciók támogatása. 14. Sorolja fel csoportosítva az UML diagramjait! Use-case diagram Osztály diagram Viselkedés diagrammok állapot diagram aktivitás diagram sorrend diagram együttműködési diagram Implementációs diagram komponens diagram telepítési diagram Kiterjesztési mehanizmusok Az UML tehát nem módszertan! 15. UML kiterjesztési mehanizmusai Feladata: Szabványos jelölésrendszer testre szabása Szabványos elemekkel nem leírható modell tulajdonságok rögzítése. Fajtái: Sztereotípia : új modell elemek jelölésére :: << sztereotípia >> Megszorítás : az UML más jelöléseivel meg nem adható tulajdonságok :: {megszorítás leírása} Kulcsszavas értékek : modell elemek speciális jellemzőinek megadására. :: {kulcsszavas érték} Megjegyzések :: {megjegyzés} 16. USE CASE diagram feladata, elemei, elemeinek jelölése A rendszer határait jelölhetjük ki vele. Lényeges szerepe van a követelmény analízis során. Ez a modell jellemzi a rendszer működését a felhasználó (Actor) és a felé irányuló szolgáltatások illetve funkciók (Use Case) között. Actor/Aktor: A felhasználó egy szerepe a rensdzerben. Több felhasználó egy aktor Egy felhasználó több aktor Aktor lehet külső rensdzer is.
Use case: Egy jól meghatározott funkció, amelynek végrehajtása a rendszer és egy külső entitás közötti üzenetváltást kíván. A rensdzer, egy alrendszer vagy egy osztály objektumai által végrehajtott funkció együttes. Pontos leírása is szükséges. Kapcsolatok: Aktor és use case között asszociáció, melynek akár a számossága is jelölhető. <<include>>:a1 magában foglalja A2-t. (részletezés, vagy ismétlődés kezelése) <<extend>>: A1 működését A2 kiegészíti. (többlet funkciók vagy speciális esetek) Általánosítás Elemei: Példák: A rendszert egy téglalappal kerítjük körbe, a felhasználó ezen kívül helyezkedik el. Általánosítás, extend és include.
20. Szekvencia diagram feladata, elemei, elemeinek jelölése Objektumok közötti üzenetváltások az időben. (függölegesen lefele telik az idő) Elemei: Példák: Életvonal, élettartam kezdete, üzenetek. Beágyazott üzenet, alternatív működés, visszatérés, elágazás.
21. Állapot diagram feladata, elemei, elemeinek jelölése Egy adott objektum lehetséges állapotai, átmenetek egyes állapotok között. Állapotváltozások és az ehhez kapcsolható események, az objektum értékeihez kapcsolható feltételek [feltétel] formában, valamint az ismétlődés jelzése x. Kezdő és végállapot. Egy állapot részletezhető (strukturált áll. Diagram). Állapotok közt lehet álltalánosítás kapcsolat. Elemei: Példa: Állapot jelölése, lehetséges állapotok felsorolása. Kezdő pont (vég pont ugyan az, mint az aktivitási diagramnál), állapot, sima/parametrizált átmenet. 22. Együttműködési diagram feladata, elemei, elmeinek jelölése Hasonlóan az állapot diagramhoz, szintén objektumok közötti üzenetváltások az időben. Elemei. A példa objektumok. Aktív, vastag keret vagy {akcive } megszorítás üzenetet küldhet másik objektumnak. Passzív, üzenet hatására aktivizálódik. Multiobjektum, objektumok egy csoportja. Az együttműkdödő objektumok. Vonallal összekötve.
A megfelelő osztályok között az osztálydiagramon asszociációnak kell lennie! Üzenetek. Objektumok közötti nyilak, sorszámozva és névvel ellátva. A nyíl iránya jelzi az üzenetküldés irányát. A sorszám pedig sorrendiséget jelez. Az üzenetnek lehet. Argumentuma és eredménye. Jele a kiskörből kiinduló nyíl. Az adatáramlás irányát jelzi. A nyílon az argumentum vagy az eredmény neve. Az ábrán szerepelhet aktor is, ekkor tőle indul az első üzenet. Példák, jelölések: Példa, multi objektum, argumentumos üzenet, aktor. 23. Aktivitási diagram feladata, elemei, elemeinek jelölése Időben lezajló változások ábrázolása a végrehajtandó tevékenységek és azok sorrendjének megadásával. Alapjai A munkafolyamat diagram. A folyamatábra. Alapelemei Tevékenységek (ívelt oldalú téglalap) Átmenet (nyíl) Szinkronizációs vonal (vastag vízszíntes vonal darab) Döntési pont (rombusz) A diagram függőlegesen sávokra oszthatók. Egy sáv egy felelőssségi kört határoz meg/jelöl.
Elemei: Példa: Kezdet, vég, szinkrozinációs vonal, döntési pont. 24. Komponens, telepítési diagram feladata, elemei, elemeinek jelölése Komponensek fizikai alkotóelemek, melyek tipikusan forrás-állományok könyvtárak futtatható állományok dokumentumok adatállományok szoftver komponensek Definiált sztereotípiák << executable >>
<< library >> << tables >> << files >> << document >> Telepítési diagram tartalma a rendszer hardver elemei és a közöttük lévő fizikai viszonyok. Valamint a hardver és a szoftver elemek összerendelése. Példák/Elemek: Komponensek és a kapcsolatok. Telepítési diagram (kockák a hardverek), komponensek, kapcsolatok es módjai. 26. OMT szemlélete, modelljei (ábra) OMT szemlélete Alkalmazás 3 része Objektum modell - mivel A rendszer általános struktúrája. Funkcionális dekompozíció helyett struktúrális. Jelölésrendszere osztály és/vagy komponens diagram.
Funkcionális modell - mi A rendszeren belüli számítások, feldolgozások. Nem tartalmaz időt. Megadhatjuk az objektum modell műveleteit, a dinamikus modell akcióit és az objektum modell korlátozó feltételeit. Eszközei a DFD, aktivitási és együttműködési diagram. Dinamikus modell - mikor A rendszer építőelemeinek viselkedése, időbeli változása. Minden objektumra hogyan változtatja állapotát és hat a környezetére. Eszközei az állapot, sorrend és az eseményfolyam diagram. Ábra: Krumpli modell, az alkalmazás összetevői. 27. OMT fejlesztés fázisa Analízis A rendszer lényeges elemeinek leírása, a feladat szöveges leírásának ellemzésével. Rendszertervezés Alrenszerekre bontás A megvalósítás stratégiai döntései. Erőforrások elosztása. Optimalizálandó tulajdonságok. Alrendszerek közötti kommunikáció. A végrehajtás/vezérlés módja. Objektum tervezés A három modell összhangba hozása. (Dinamikus, Funkciónális és a Objektum modell) Adatszerkezetek és algoritmusok. Implementáció A modell lefordítása egy programozási nyelvre. 28. OMT analízis fázis objektum modell Osztályok azonosítása. Megfelelő osztályok kiválasztása. Törlendők
Redundáns osztályok Felesleges osztályok Pontatlan osztályok Attribútomok Műveletek Szerepkörök Implementációs elemek Osztályok leírása. Asszociációk azonosítása. Többszörös asszociációk átalakítása. Asszociációk szemantikájának ellenörzése. Attributumok azonosítása. Megfelelő attributumok kiválasztása. Általánosítás. Elérési útak ellenörzése. Modulok meghatározása. Finomitás, ha a rendszer összetetsége indokolja. 29. OMT analízis fázis dinamikus modell Forgatókönyvek készítése. A működést kisérő események. Felhasználói felület. Vezérlési Információcsere Szekvencia diagram rajzolása. Állapot diagram rajzolása. Eseményfolyam digram készítése. 30. OMT analízis fázis funkciónális modell Be/Ki meneti értékek azonosítása. Adatfolyam diagram megrajzolása. A transzformációk specifikálása. Objektumok közötti korlátozások. Optimalizálandó értékek meghatározása. 31. OMT rensdzertervezés A megvalósítás magas szitű döntései. Alrendszerekre bontás. Információ áramlás az alrendszerek között. Lényegi konkurencia meghatározása. Alrenszerek processzorokhoz és taskokhoz rendelése. Erőforrás igény. Kapcsolódás eszköze. Adattárolás eszközének kiválasztása. Globális erőforrások elosztásának szabályozása. (memória, processzor, hálózat, stb.) Vezérlés elvének kiválasztása. A rensdzer háttérfeltételeinke meghatározása. Felhasználói felület /külső interface tervezése.