Page 1
1
Software EngineeringSzoftver fejlesztés
Követelmény (kezelés, elemzés, specifikáció)ElemzésTervezés
(Architektúra)
Engineering (Fejlesztés)
System EngineeringBusiness process engineering
üzleti folyamatok tervezése, szervezésemodellezzük az üzleti környezetet
Product enginneringtermékek tervezésemodellezzük a terméket, annak használatát
Software Engineeringszoftver alkalmazásokat, eszközöket ad a fenti feladatok megoldására
Modellezés – általános eszközleendő rendszer specifikációja és terve
Page 2
2
Software EngineeringSzoftver fejlesztés
Technikai tartalom, lépések
Szoftver Engineering – lépések
(Üzleti modellezés)Követelmény (kezelés, elemzés)Elemzés, tervezésImplementációTesztelésTelepítés
Fejlesztési termékek:fejlesztési lépések eredményei
Page 3
3
Fejlesztés lépései
Vízesés modell szerint
Fejlesztés lépései
Iteratív fejlesztési modell szerint
Page 4
4
Termékek előállítása a fejlesztés során
Iteratív fejlesztés:Az iterációk során egyre több termék áll elő, és a termékek érettsége egyre nő.
Szoftver EngineeringSzoftver fejlesztés
Követelmények
Page 5
5
Követelmények
KövetelményekKövetelmények összegyűjtéseKövetelmények elemzése
konzisztencia, prioritások…Követelmény specifikáció
konzisztens és érthető követelmény definíció (pl. bemenet, kimenet stb.)rendszer modell
Követelmények validálásateljesség, ellentmondás-mentesség…
Követelmények –Módszerek
Követelmények összegyűjtésepl. használati esetek; nem funkcionális…
Követelmények elemzéseinformation domain
adat feldolgozásvezérlés
funkció leírás – funkcionális modellviselkedés leírás – viselkedési modellpartíciónálás (részekre bontás)prototípus készítés
Page 6
6
Szoftver EngineeringSzoftver fejlesztés
Elemzés
Elemzés
Cél: elemzési modell készítéseFejlesztett rendszer részletes és teljes leírása első technikai reprezentáció (modell)Alternatívák:
Strukturált analízisObjektum orientált analízis
Page 7
7
Strukturált elemzés
Elemzési modell célja:felhasználói követelmények rögzítése,a szoftver terv (ill. tervezés) alapjainak megteremtése,követelmények definiálása, melyek alapján verifikálható lesz az elkészített szoftver.
Strukturált analízis módszerei
Adat könyvtár (dictonary)Rendszer által kezelt adatok leírása
Entitás relációs diagram (entity relations.)Adat objektumok és az adatelemek egymáshoz való viszonyának leírása
Adat folyam diagram (dataflow)Adat transzformáció és adat mozgatás, valamint az adat manipuláló funkciók leírása
Állapot átmeneti diagram (state trans.)Vezérlés leírása
Page 8
8
Szoftver EngineeringSzoftver fejlesztés
Tervezés
Tervezés
Cél: tervezési modell készítéseTervezési modell
direkt módon megvalósítható rendszer elemek leírása
Tervezés „fázisai” (Belady)divergálás – alternatívákkonvergálás – választáskreatív folyamat!! döntések!
Alternatívák:Strukturált tervezésObjektum orientált tervezés
Page 9
9
Strukturált tervezés fázisai
Adat tervezésadat könyvtár, ER adat struktúrák
Architektúra tervezésstrukturális felépítése a rendszernek
minták, specifikáció, részek…
Interfész tervezésbelső és külső kommunikáció
Komponens tervezésarchitektúra terv elemei implementálhatóprogram elemek, procedúrák, függvények stb.
Strukturált tervezés és a minőség
Tervezés minősége alapvetően befolyásolja a végtermék minőségét
felhasználói követelmények rendszerösszes követelmény lefedéseérthetőségteljesség: adat, funkció, viselkedés
minőségi kritériumrendszerek
Page 10
10
Strukturált tervezés menete
tipikusan iteratív folyamatabsztrakt reprezentáció konkrét reprezentáció
tervezési modellteljes reprezentációja a szoftvernekkülönböző nézetek (aspektusok)
Általános tervezési elvek
Page 11
11
Általános tervezési elvek
Ne legyen „csőlátású” a tervezőalternatívák felállítása
Az analízis modell és a tervezési modell összekapcsolása
melyik tervezési döntés (modell) melyik analízis modell elem alapján jött létre
„Ne találjuk fel a kereket megint!”tervezési mintákat próbáljunk használni
Általános tervezési elvek
A megoldás „szerkezete” lehetőleg tükrözze a megoldott probléma szerkezetétEgységes terv
~egy embertől származna
Változás tűrőúj rész integrálható
Robusztushiba, túlterhelés stb. esetén lassan csökken a rendszer funkcionalitása
Page 12
12
Általános tervezési elvek
a terv absztrakciós szintje magasabb, mint a kódé, és részletes eléggé, hogy ne kelljen lényeges döntést hozni kódoláskorminőségi követelményeket figyelembe kell venni és mérni a tervezés folyamatábanellenőrizni kell a tervet a szemantikus hibák kijavítása érdekében
ellentmondások, redundancia…nem csak szintaktikusan kell ellenőrizni
Tervezési módszerek
Page 13
13
Tervezési módszerekről általában
Módszerek:segítség a döntéseknél, de…
Kérdések tervezéskor:Mi alapján lehet a szoftvert részekre osztani?Hogyan legyenek a funkciók, ill. a adatszerkezetek részletei elválasztva a szoftver koncepcionális modelljétől?Van-e általánosan használható mérőszám a tervezés minőségének mérésére?
Tervezési módszerek -Absztrakció I.
Absztrakcióabsztrakt: megoldás (modell) a probléma tér fogalmaivalkevésbé absztrakt: keverednek a probléma tér fogalmai az implementációs tér fogalmaivalközvetlenül megvalósítható megoldás leírás
tervezés során az absztrakció csökken
Page 14
14
Tervezési módszerek –Absztrakció II.
Absztrakció típusaiműködés leírás (procedural) absztrakció
függvény név – függvény utasítások
adat absztrakcióadat szerkezet név – adat szerkezet definíció
vezérlés absztrakciószemafor
Tervezési módszerek –Pontosítás, részletezés
(refinement)top-down tervezési modellelsősorban működés leírás kidolgozásáralépésenkénti finomítása, részletezése a leírásnak
Page 15
15
Tervezési módszerek –Modulokba szerverés
komponensek névvel és elhatárolható funkcionalitással, önálló megvalósítássalkezelhető legyen a rendszer „józan ésszel”
Modulok méretének meghatározása
Probléma: p1, p2Komplexitás: C(p1), C(p2)Befektetés: B(p1), B(p2)C(p1)>C(p2) B(p1)>B(p2)C(p1+p2)>C(p1)+C(p2)
B(p1+p2)>B(p1)+B(p2)minél kisebb problémákra vágom,
annál könnyebben oldom meg…de integrálni is kell optimum!!
Page 16
16
Modulok mérete – fejlesztés költsége
integrációmodul fejlesztés
együttes
modulok száma
befektetés(költség)
Szoftver architektúra
Page 17
17
Szoftver architektúra
rendszer általános felépítés, struktúrájakomponensek (nem meghatározott a méretük) hierarchiájakomponensek együttműködésének módja
koncepcionális leírás
Szoftver architektúra leírása
strukturális modellframework modell
absztraktabb, általános működés hasonló rendszerekben, tervezési minták
dinamikus modellekviselkedés (a rendszer hogyan változik külső hatásokra)
folyamat modelleküzleti, technológia
funkcionális modellekhierarchia
leírása: Arhitectural Description Language
Page 18
18
Strukturális modell
StruktúraVezérlési hierarchiaAdat elemek hierarchiája
Struktúra: vezérlési hierarchia
modulok aktiválási sorrendje, alternatívái
fa szerkezetű ábrázolásJackson diagram
meghatározható a vezérlés bonyolultságadefiniálható a modulok láthatósága, kapcsolata
Page 19
19
Architektúra meghatározása vezérlés alapján
Horizontális bontásbontás egy-egy külső funkció alapjánkönnyű tesztelni, kevés mellékhatás változtatáskor, bővíthető
Vertikálisvezérlő és munkavégző modulokváltozás általában a munkavégző modulokban karbantarthatóbb(kevesebb mellékhatás)
Adat elemek hierarchiája (struktúra)
alap adat típusokadatszerkezetek:
vektoroktöbb dimenziós tömbökláncolt listák
hierarchikus adatszerkezetek
Page 20
20
Általános elvek hierarchia tervezéséhez
Információ rejtés
modularitás gyakorlati hasznamodulok „önálló egységek”önállóan lehessen őket tervezni megvalósítanibelső működés, szerkezet rejtett a külvilág elöl
adatszerkezetekvezérlés
Page 21
21
Modulok tervezése
Funkcionális függetlenségkohézió (összetartozás)csatolás
Kohézióegyüttműködés mértéke egy vagy több feladat (funkció) megvalósításábanesetleges, logikai, állandó, procedurális…
Csatolásinterfész bonyolultsága alapjánhívási paramétereken keresztülvezérlő adatszerkezeteken keresztülglobális adatszerkezeteken keresztülkörnyezeti elemeken (eszközökön) keresztül
Szoftver architektúra tervezés
Page 22
22
Szoftver architektúra tervezés
rendszer általános működésére, felépítésére vonatkozó legfontosabb (korai) döntések követelmények megvalósításaalternatívák számbavételemegvalósítás rizikójának csökkentéseérthető méretű leírás: kommunikáció
Tipikus architektúrák, „stílusok”
Adat központú architektúraAdat tároló központ + kliensek
Adat folyam (data flow)pipe, batch …
„Call and return” architektúraprogram – alprogramremote procedure call (kliens-szerver)
Objektum orientált architektúraRétegszerkezet
Page 23
23
Strukturált architektúra tervezés
Adat modellezés
Entitás-relációs diagramadat objektum – entitás
belső reprezentáció
attribútumokentitás rendszer által kezelt tulajdonságai
kapcsolatokmodalitás
kötelező, opcionális
számosság
Page 24
24
Entitás-relációs diagram kiterjesztése
Entitások hierarchikus viszonya~ fa struktúra
entitások minősítése (~ attribútumok, kategorizálás, dimenzió)
kapcsolati modellrészek definiálása
Funkció és információ áramlás modellezése
Információ folyam leírásAdat folyam (data flow) diagramLépés viselkedés leírás felé
vezérlés intenzív működésidő kritikus műveletekkiterjesztett adat folyam diagram
Viselkedés leírásállapot átmenet diagram
Page 25
25
Strukturált tervezés fázisai (volt)
Architektúra kialakítása:Adat tervezés
adat könyvtár, ER adat struktúrákArchitektúra tervezés
strukturális felépítése a rendszernekminták, specifikáció, részek…
Részletes tervezés:Interfész tervezés
belső és külső kommunikációKomponens tervezés
architektúra terv elemei implementálhatóprogram elemek, procedúrák, függvények stb.
Komponens tervezés módszerei
procedural designdöntések a részletekig
használható modellekfolyamat vezérlési gráf (control flow graph)
vezérlési szerkezetdobozos jelölés (box notation)
vezérlési szerkezetekdöntési táblák
szabályok rögzítésefeltételek (pl. bemenetek) hatások (műveletek)
Page 26
26
Objektum orientált tervezés
Objektum orientált tervezés
Vezérlési hierarchia (struktúra) és adat hierarchia (struktúra) együttMűködő rendszer: együttműködő objektumok halmazaObjektum: adatok és műveletek (metódusok) egysége
adat ~ tulajdonságműveletek (metódusok) üzenettel aktivizálható működésobjektum felelősségei
Page 27
27
Objektum orientált tervezés
Rendszer tervezése, modellezés, gondolkodás objektum orientált módonRendszer fejlesztés támogatása:
objektum orientált modellező, tervező, fejlesztő rendszerek (CASE)
Vezérlési hierarchia és adat hierarchia együttes meghatározása
Az OO megközelítés a feladatotegyetlen egységes módon bontja fel.adatszerkezet
vezérlési szerkezet
objektumstruktúra
Page 28
28
Objektum orientált megközelítés egyik előnye
A funkcionális dekompozíció afolyamatnak csak az „időbeli”felosztását képes kifejezni.
Strukturált szemlélet
OO megközelítés
A módszerekkel az összetett folyamat„térbeli”, azaz objektumokhoz rendeltfelosztása is kifejezhető.
Objektum orientált modellezés
Use case (használati eset) diagramnem kizárólag OO
Aktivitás diagramSzekvencia diagramEgyüttműködési (Collaboration) diagramOsztály diagramÁllapot-átmenet diagram…
Page 29
29
Use case (használati eset) diagram
Jelentkező Jelentkezés tanfolyamra
Regisztrált személy jelentkezése
<<extend>>
Új jelentkező
<<extend>>
Tanfolyamok listájának megtekintése
<<include>>
Aktivitás diagram: tevékenységek
Aktivitás, tevékenység (activity)Valamilyen tevékenység, amit meg kell csinálni
Szekvencia: a tevékenységet egy másik tevékenység követ
Tanfolyam választása
Bejelentkezés
Page 30
30
Aktivitás diagram: párhuzamos tevékenységek
Jóváhagyás
Rögzítés Számlázási rendszer értesítése
Igazolás nyomtatása
Aktivitás diagram: Döntés
Egyetlen feltétel definiálása az átmenethez
Döntés: több egymásba ágyazott feltétel kifejezése
Készletek feltérképezése
[ nincs darált kávé ]
Üveg elovétele
[ van cola ]
[ nincs cola ]
[ van darált kávé ]Tanfolyam választása
Jóváhagyás Üzenet
[ van szabad hely ][ nincs szabad hely ]
Page 31
31
Aktivitás diagram példaKészletek
feltérképezése
Darált kávé rakása a filterbe
Víz öntése a tartályba
Csésze elovétele
Gép bekapcsolása
Filter berakása a gépbe
Fozés
Kávé kitöltése
Ital elfogyasztása
[ nincs darált kávé ]
Üveg elovétele
[ van cola ]
[ nincs cola ][ van darált kávé ]
Szekvencia diagram
Hívókagyló felemelése
HívottTelefonvonal
1 tárcsázása
8 tárcsázása9 tárcsázása
tárcsahang
csöngetési hang
csöngetési hang végekagyló felemelése
tárcsahang vége
csöngetés vége
csöngetés
Idő
Page 32
32
Szekvencia diagram
: Jelentkezõ
: DlgLogin : Ugyfel : FrmJelentkezes
: Tanfolyam UML : TanfolyamUML19990301 : Tanfolyami
Regisztracio: JelentkezesVezerles
Beír "név", "jelszó"
Megnyomja "OK"
Kiválaszt "UML"
Kiválaszt "1999.03.01"
Jóváhagy
Megjelenít"Regisztráció"
Keres ügyfelet
ügyfél-keresés
Megjelenít
TanfolyamLista
IdõpontLista
Létrehoz
Tanfolyam-lista megjelenítése
Idõpont lista megjelenítése
Van szabad hely?
Együttműködési diagram
Hívó Telefonvonal
Hívott
5: 9 tárcsázása1: kagyló felemelése3: 1 tárcsázása6: 8 tárcsázása
9: kagyló felemelése
2: tárcsahang4: tárcsahang vége7: csöngetési hang10: csöngetési hang vége
8: csöngetés
11: csöngetés vége
Page 33
33
Együttműködési diagram
: Jelentkezõ
: DlgLogin : Ugyfel
: FrmJelentkezes
: Tanfolyam
UML : Tanfolyam
UML19990301 : TanfolyamiIdopont
: JelentkezesVezerles
1: "Regisztráció"2: megjelenít( )
3: Beír "név", "jelszó"4: Megnyomja "OK"
5: ugyfelKereses("név", "jelszó")
6: megjelenít( ) 7: tanfolyamLista( )8: kiirTanfolyamLista( )
9: Kiválaszt "UML"
10: idopontLista( )
11: kiirIdopontLista( )
12: Kiválaszt "1999.03.01"
13: vanSzabadhely( )
14: Jóváhagy
Regisztracio : Regisztracio
15: letrehoz( )
Osztály diagram
osztályokkapcsolatoköröklés…
Page 34
34
Osztály diagram: osztályok
Ugyfel- nev : string- lakcim : cim- felhasznaloiNev : string- jelszo : kodoltString
+ ugyfelKereses()
<<entity>>TanfolyamiIdopont
- kezdet : date- veg : date- hely : string
+ vanSzabadhely()
<<entity>>Tanfolyam
- megnevezes : string- idotartam : integer- tematika : string
+ tanfolyamLista()+ idopontLista()
<<entity>>
Osztály diagram: kapcsolatok
Cég SzemélyAlkalmazás
munkaadó munkavállaló
Asszociáció neve
Szerepkör Szerepkör
Page 35
35
Példa kapcsolatokra
Cég SzemélyAlkalmazás
munkaadó munkavállaló* *
Csúcspont Poligon
10..n0..n 1
{ordered}
Osztálynak önmagával való asszociációja (self-association)
Személy
házasság+feleség
+férj
0..10..1
hierarchia
+főnök
+beosztott0..1
*
Szerepkör
Fonök<<Interface>>
Beosztott<<Interface>>
0..n0..10..1 0..n
Személy
Megvalósít
Page 36
36
Asszociációs osztály
Cég Személy** **
+munkavállaló+munkaadó
Alkalmazásfizetés : double Részleg
1* 1*Asszociációs osztály
Asszociáció attribútumai
Asszociáció vagy
attribútum?
Minősítő (qualifier)
Számlateljesítés dátumafizetési határidõ
Számlatételsorszám : intmegnevezésár*11 *
Számlateljesítés dátumafizetési határidõ
Számlatételmegnevezésár1
sorszám : int11 1sorszám : int
Page 37
37
Termék11
érvényességKezdete: Date
1
ÁreladásiÁrérvényességVége
TermékÁr
eladásiÁrérvényességKezdeteérvényességVége*1 *1
Minősítő (qualifier)
Szekvencia diagram (sequence diagram)
Az adott folyamat egy konkrét végrehajtását írja le az objektumok közötti kommunikáción keresztül
Page 38
38
Állapot-átmenet diagram
Várakozó
Aktív
Idõ lejárt
Csöngetésdo: csöngetõ hang
Tárcsázás
Idő lejártdo: Szaggatott hang
Érvénytelendo: sípoló hang Kapcsolás
Csöngetésdo: csöngetõ hang
Foglaltdo: foglalt hang
Beszélgetés
[ 15 mp lejárt ]
tárcsáz( n )[ nem teljes a szám
tárcsáz( n )[ érvénytelen a szám ]
tárcsáz( n )[ érvényes a szám ] / kapcsol
[ foglalt a vonal ]
[ szabad a vonal ]
hívott felveszi / beszélgetés engedélyezése
[ 15 mp lejárt ]tárcsáz( n )
hívó leteszi a kagylót / bontja a vonalat
felveszi a hallgatót / tárcsahang Tárcsahangdo: búgó hang
--------------------------------------------
Page 39
39
REZERVÁTUM
A RUP szerkezete
tarta
lom
idő
Page 40
40
Rational Unified Process
A Rational Unified Process a szoftverfejlesztés életciklusát négy egymást követő fázisra bontja:
Előkészítés (Inception)Kidolgozás (Elaboration)Megvalósítás (Construction)Átadás (Transition)
Minden fázis végén jól-definiált mérföldkövek vannak: kritikus döntéseket kell hozni
Értékelni az eddigi eredményeketDönteni a folytatásról
Dinamikus aspektus -fázisok és iterációk
Az aktuális feladat dönti el, hogy hány iterációra van szükség a feladat elvégzéséhez.
Az iterációk tervezése kritikus feladat a projekt tervezése során.
Page 41
41
RUP - szemléletIteratív fejlesztés
Pontos projekt vezetői követést igényelHibát követünk el ha nem vesszük komolyanFelhasználó folyamatos bevonásaElefántcsont torony kiiktatása
Előzetestervezés
Tervezés
Követelményelemzés Analízis és tervezés
Implementáció
Teszt
Kibocsátás
Értékelés
Menedzsment
RUP - kockázat csökkentése
Átadás
Kezdet
Kidolgozás
Építés
Előzetesiteráció
Tervezésiiteráció
Tervezésiteráció
Fejl. iteráció
Fejl. iteráció
Fejl. iteráció
Átadásiiteráció
Átadásiiteráció
Beüzemelés
Vízesés
Idő
Emberi erõforrás
KockázatKockázat