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

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

3

Fejlesztés lépései

Vízesés modell szerint

Fejlesztés lépései

Iteratív fejlesztési modell szerint

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

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

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

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

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

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

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

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

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

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

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

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!!

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

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

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

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

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

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

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

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

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

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)

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

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

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…

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

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 ]

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ő

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

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…

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

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

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

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

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

--------------------------------------------

39

REZERVÁTUM

A RUP szerkezete

tarta

lom

idő

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.

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