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 + algoritmusokDekompozí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 elveModul Interface

Processz alapú (Algoritmus) Adatszerkezet

Adat alapú (Adatszerkezet) Algoritmus

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 halmazaStruktú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ákHasználói Mire használják

Megrendelő Követelmények meghatározása, ellenörzése, változások megadása.

Menedzserek Árajánlat készítése, a fejlesztési folyamat tervezése és ellenörzése.

Rendszertervező Annak megértése, hogy milyen rendszert kell fejleszteni.

Tesztelők, minőségellenőrök A rendszer működésének és minőségének ellenörzéséhez.

Karbantartók 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 nyelvPontosság: Nem precíz Precíz

Terminológia: Az alkalmazás szakkifejezései Szoftver terminológiaSzemlé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)– 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

OOD:– 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éseiFogalma: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 mehanizmusaiFeladata:– 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:

Állapot jelölése, lehetséges állapotok felsorolása.

Példa:

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.