Software Engineering Szoftver fejlesztés
Követelmény (kezelés, elemzés, specifikáció) Elemzés Tervezés (Architektúra)
Engineering (Fejlesztés) {
System Engineering z
z
{
Software Engineering z
{
Business process engineering { üzleti folyamatok tervezése, szervezése { modellezzük az üzleti környezetet Product enginnering { termékek tervezése { modellezzük a terméket, annak használatát szoftver alkalmazásokat, eszközöket ad a fenti feladatok megoldására
Modellezés – általános eszköz z
leendő rendszer specifikációja és terve
1
Software Engineering Szoftver 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és Implementáció Tesztelés Telepítés
{
Fejlesztési termékek:
{ { { { {
z
fejlesztési lépések eredményei
2
Fejlesztés lépései
{
Vízesés modell szerint
Fejlesztés lépései {
Iteratív fejlesztési modell szerint
3
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 Engineering Szoftver fejlesztés Követelmények
4
Követelmények {
Követelmények z z
Követelmények összegyűjtése Követelmények elemzése {
z
konzisztencia, prioritások…
Követelmény specifikáció konzisztens és érthető követelmény definíció (pl. bemenet, kimenet stb.) { rendszer modell {
z
Követelmények validálása {
teljesség, ellentmondás-mentesség…
Követelmények – Módszerek {
Követelmények összegyűjtése z
{
pl. használati esetek; nem funkcionális…
Követelmények elemzése z
z z z z
information domain { adat feldolgozás { vezérlés funkció leírás – funkcionális modell viselkedés leírás – viselkedési modell partíciónálás (részekre bontás) prototípus készítés
5
Szoftver Engineering Szoftver fejlesztés Elemzés
Elemzés { {
{
{
Cél: elemzési modell készítése Fejlesztett rendszer részletes és teljes leírása első technikai reprezentáció (modell) Alternatívák: z z
Strukturált analízis Objektum orientált analízis
6
Strukturált elemzés {
Elemzési modell célja: z z
z
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) z
{
Entitás relációs diagram (entity relations.) z
{
Adat objektumok és az adatelemek egymáshoz való viszonyának leírása
Adat folyam diagram (dataflow) z
{
Rendszer által kezelt adatok leírása
Adat transzformáció és adat mozgatás, valamint az adat manipuláló funkciók leírása
Állapot átmeneti diagram (state trans.) z
Vezérlés leírása
7
Szoftver Engineering Szoftver fejlesztés Tervezés
Tervezés { {
Cél: tervezési modell készítése Tervezési modell z
{
Tervezés „fázisai” (Belady) z z z
{
direkt módon megvalósítható rendszer elemek leírása divergálás – alternatívák konvergálás – választás kreatív folyamat!! Æ döntések!
Alternatívák: z z
Strukturált tervezés Objektum orientált tervezés
8
Strukturált tervezés fázisai {
Adat tervezés z
{
Architektúra tervezés z z
{
strukturális felépítése a rendszernek Æ minták, specifikáció, részek…
Interfész tervezés z
{
adat könyvtár, ER Æ adat struktúrák
belső és külső kommunikáció
Komponens tervezés z
architektú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 z
felhasználói követelmények Æ rendszer összes követelmény lefedése { érthetőség { teljesség: adat, funkció, viselkedés {
z
minőségi kritériumrendszerek
9
Strukturált tervezés menete {
tipikusan iteratív folyamat z
{
absztrakt reprezentáció Æ konkrét reprezentáció
tervezési modell z z
teljes reprezentációja a szoftvernek különböző nézetek (aspektusok)
Általános tervezési elvek
10
Általános tervezési elvek {
Ne legyen „csőlátású” a tervező z
{
Az analízis modell és a tervezési modell összekapcsolása z
{
alternatívák felállítá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!” z
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ét Egységes terv z
{
Változás tűrő z
{
~egy embertől származna új rész integrálható
Robusztus z
hiba, túlterhelés stb. esetén lassan csökken a rendszer funkcionalitása
11
Á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áskor minőségi követelményeket figyelembe kell venni és mérni a tervezés folyamatában ellenőrizni kell a tervet a szemantikus hibák kijavítása érdekében z z
ellentmondások, redundancia… nem csak szintaktikusan kell ellenőrizni
Tervezési módszerek
12
Tervezési módszerekről általában {
Módszerek: z
{
segítség a döntéseknél, de…
Kérdések tervezéskor: z z
z
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ó z z
z
z
absztrakt: megoldás (modell) a probléma tér fogalmaival kevésbé absztrakt: keverednek a probléma tér fogalmai az implementációs tér fogalmaival közvetlenül megvalósítható megoldás leírás tervezés során az absztrakció csökken
13
Tervezési módszerek – Absztrakció II. {
Absztrakció típusai z
működés leírás (procedural) absztrakció {
z
adat absztrakció {
z
függvény név – függvény utasítások 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 modell elsősorban működés leírás kidolgozására lépésenkénti finomítása, részletezése a leírásnak
14
Tervezési módszerek – Modulokba szerverés {
{
komponensek névvel és elhatárolható funkcionalitással, önálló megvalósítással kezelhető legyen a rendszer „józan ésszel”
Modulok méretének meghatározása { { { { {
{
{
Probléma: p1, p2 Komplexitá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!!
15
Modulok mérete – fejlesztés költsége
befektetés (költség)
együttes modul fejlesztés
integráció
modulok száma
Szoftver architektúra
16
Szoftver architektúra {
{
{
{
rendszer általános felépítés, struktúrája komponensek (nem meghatározott a méretük) hierarchiája komponensek együttműködésének módja koncepcionális leírás
Szoftver architektúra leírása { {
strukturális modell framework modell z
{
absztraktabb, általános működés hasonló rendszerekben, tervezési minták
dinamikus modellek z
viselkedés (a rendszer hogyan változik külső hatásokra)
{
folyamat modellek
{
funkcionális modellek
{
leírása: Arhitectural Description Language
z
z
üzleti, technológia hierarchia
17
Strukturális modell {
Struktúra z z
Vezérlési hierarchia Adat elemek hierarchiája
Struktúra: vezérlési hierarchia {
modulok aktiválási sorrendje, alternatívái z z
{
{
fa szerkezetű ábrázolás Jackson diagram
meghatározható a vezérlés bonyolultsága definiálható a modulok láthatósága, kapcsolata
18
Architektúra meghatározása vezérlés alapján {
Horizontális bontás z z
{
bontás egy-egy külső funkció alapján könnyű tesztelni, kevés mellékhatás változtatáskor, bővíthető
Vertikális z z
vezérlő és munkavégző modulok változás általában a munkavégző modulokban Æ karbantarthatóbb (kevesebb mellékhatás)
Adat elemek hierarchiája (struktúra) { {
alap adat típusok adatszerkezetek: z z z
{
vektorok több dimenziós tömbök láncolt listák
hierarchikus adatszerkezetek
19
Általános elvek hierarchia tervezéséhez
Információ rejtés { { {
{
modularitás gyakorlati haszna modulok „önálló egységek” önállóan lehessen őket tervezni megvalósítani belső működés, szerkezet rejtett a külvilág elöl z z
adatszerkezetek vezérlés
20
Modulok tervezése {
Funkcionális függetlenség z z
{
Kohézió z z
{
kohézió (összetartozás) csatolás
együttműködés mértéke egy vagy több feladat (funkció) megvalósításában esetleges, logikai, állandó, procedurális…
Csatolás z z z z z
interfész bonyolultsága alapján hívási paramétereken keresztül vezérlő adatszerkezeteken keresztül globális adatszerkezeteken keresztül környezeti elemeken (eszközökön) keresztül
Szoftver architektúra tervezés
21
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ása alternatívák számbavétele megvaló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úra z
{
Adat folyam (data flow) z
{
z
{
pipe, batch …
„Call and return” architektúra z
{
Adat tároló központ + kliensek
program – alprogram remote procedure call (kliens-szerver)
Objektum orientált architektúra Rétegszerkezet
22
Strukturált architektúra tervezés
Adat modellezés {
Entitás-relációs diagram z
adat objektum – entitás {
z
attribútumok {
z
belső reprezentáció entitás rendszer által kezelt tulajdonságai
kapcsolatok {
modalitás z
{
kötelező, opcionális
számosság
23
Entitás-relációs diagram kiterjesztése {
Entitások hierarchikus viszonya z
~ fa struktúra {
z
entitások minősítése (~ attribútumok, kategorizálás, dimenzió)
kapcsolati modell {
részek definiálása
Funkció és információ áramlás modellezése { { {
Információ folyam leírás Adat folyam (data flow) diagram Lépés viselkedés leírás felé z z z
{
vezérlés intenzív működés idő kritikus műveletek kiterjesztett adat folyam diagram
Viselkedés leírás z
állapot átmenet diagram
24
Strukturált tervezés fázisai (volt) {
Architektúra kialakítása: z
Adat tervezés
z
Architektúra tervezés
{
{ {
{
adat könyvtár, ER Æ adat struktúrák strukturális felépítése a rendszernek Æ minták, specifikáció, részek…
Részletes tervezés: z
Interfész tervezés
z
Komponens tervezés
{
{
belső és külső kommunikáció architektúra terv elemei Æ implementálható program elemek, procedúrák, függvények stb.
Komponens tervezés módszerei {
procedural design z
{
döntések a részletekig
használható modellek z z z
folyamat vezérlési gráf (control flow graph) { vezérlési szerkezet dobozos jelölés (box notation) { vezérlési szerkezetek döntési táblák { szabályok rögzítése { feltételek (pl. bemenetek) Æ hatások (műveletek)
25
Objektum orientált tervezés
Objektum orientált tervezés {
{
{
Vezérlési hierarchia (struktúra) és adat hierarchia (struktúra) együtt Működő rendszer: együttműködő objektumok halmaza Objektum: adatok és műveletek (metódusok) egysége z z
z
adat ~ tulajdonság műveletek (metódusok) üzenettel aktivizálható működés objektum felelősségei
26
Objektum orientált tervezés {
{
Rendszer tervezése, modellezés, gondolkodás objektum orientált módon Rendszer fejlesztés támogatása: z
objektum orientált modellező, tervező, fejlesztő rendszerek (CASE)
Vezérlési hierarchia és adat hierarchia együttes meghatározása adatszerkezet
Az OO megközelítés a feladatot egyetlen egységes módon bontja fel. objektumstruktúra
vezérlési szerkezet
27
Objektum orientált megközelítés egyik előnye Strukturált szemlélet OO megközelítés
A funkcionális dekompozíció a folyamatnak csak az „időbeli” felosztását képes kifejezni.
A módszerekkel az összetett folyamat „térbeli”, azaz objektumokhoz rendelt felosztása is kifejezhető.
Objektum orientált modellezés {
Use case (használati eset) diagram z
{ { { { { {
nem kizárólag OO
Aktivitás diagram Szekvencia diagram Együttműködési (Collaboration) diagram Osztály diagram Állapot-átmenet diagram …
28
Use case (használati eset) diagram <
>
Jelentkező
Jelentkezés tanfolyamra
<<extend>>
Regisztrált személy jelentkezése
Tanfolyamok listájának megtekintése
<<extend>>
Új jelentkező
Aktivitás diagram: tevékenységek {
Aktivitás, tevékenység (activity) z
Valamilyen tevékenység, amit meg kell csinálni Bejelentkezés
Tanfolyam választása {
Szekvencia: a tevékenységet egy másik tevékenység követ
29
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
Tanfolyam választása [ van szabad hely ] [ nincs szabad hely ] Jóváhagyás
{
[ van darált kávé ]
[ nincs darált kávé ] [ nincs cola ]
Üzenet
[ van cola ] Üveg elovétele
30
Aktivitás diagram példa Készletek feltérképezése
[ nincs darált kávé ] [ nincs cola ]
[ van darált kávé ]
Darált kávé rakása a filterbe
Víz öntése a tartályba
[ van cola ]
Csésze elovétele
Üveg elovétele
Filter berakása a gépbe
Gép bekapcsolása Fozés
Ital elfogyasztása
Kávé kitöltése
Szekvencia diagram Hívó
Telefonvonal
Hívott
kagyló felemelése tárcsahang 1 tárcsázása
Idő
tárcsahang vége 9 tárcsázása 8 tárcsázása csöngetési hang
csöngetés kagyló felemelése
csöngetési hang vége
csöngetés vége
31
Szekvencia diagram : Jelentkezõ
: Jelentkezes Vezerles
"Regisztráció"
: DlgLogin
: Ugyfel
: Frm Jelentkezes
: Tanfolyam
UML : Tanfolyam UML19990301 : Tanfolyami
Regisztracio
Megjelenít
Beír "név", "jelszó" Megnyomja "OK" ügyfél-keresés Keres ügyfelet Megjelenít TanfolyamLista Tanfolyam-lista megjelenítése Kiválaszt "UML" IdõpontLista Idõpont lista megjelenítése Kiválaszt "1999.03.01" Van szabad hely? Jóváhagy Létrehoz
Együttműködési diagram 1: kagyló felemelése 3: 1 tárcsázása 5: 9 tárcsázása 6: 8 tárcsázása Telefonvonal
Hívó
9: Hívott
2: tárcsahang 4: tárcsahang vége 7: csöngetési hang 10: csöngetési hang vége se elé m le ó fe l y kag
e és get és vég n ö t s 8: c sönge c 11:
32
Együttműködési diagram 3: Beír "név", "jelszó" 4: Megnyomja "OK"
: Dlg Login
1: "Regisztráció"
5: ugyfelKereses("név", "jelszó") 2: megjelenít( )
: Jelentkezõ 9: Kiválaszt "UML" 12: Kiválaszt "1999.03.01" 14: Jóváhagy
: Frm Jelentkezes
: Ugyfel
: Jelentkezes Vezerles
6: megjelenít( ) 8: kiirTanfolyamLista( ) 11: kiirIdopontLista( )
10: idopontLista( ) UML : 7: tanfolyamLista( )Tanfolyam
15: letrehoz( ) 13: vanSzabadhely( ) : Tanfolyam
UML19990301 : TanfolyamiIdopont
Regisztracio : Regisztracio
Osztály diagram { { { {
osztályok kapcsolatok öröklés …
33
Osztály diagram: osztályok
<<entity>> Tanfolyam - megnevezes : string - idotartam : integer - tematika : string
<<entity>> TanfolyamiIdopont - kezdet : date - veg : date - hely : string
+ tanfolyamLista() + idopontLista()
+ vanSzabadhely()
<<entity>> Ugyfel - nev : string - lakcim : cim - felhasznaloiNev : string - jelszo : kodoltString + ugyfelKereses()
Osztály diagram: kapcsolatok Asszociáció neve
Alkalmazás
Cég
munkaadó
Szerepkör
munkavállaló
Személy
Szerepkör
34
Példa kapcsolatokra
Cég
Csúcspont
Alkalmazás * * munkaadó munkavállaló
Személy
{ordered}
Poligon
0..n
1
Osztálynak önmagával való asszociációja (self-association) <> Fonök
<> Beosztott 0..1
házasság
0..n
0..1 +feleség 0..1 +férj
Személy
+főnök 0..1
+beosztott * Szerepkör
Személy
Megvalósít
hierarchia
35
Asszociációs osztály Cég
*
*
+munkaadó
+munkavállaló
Személy
Alkalmazás Asszociációs osztály
fizetés : double
Részleg *
1 Asszociáció vagy attribútum?
Asszociáció attribútumai
Minősítő (qualifier) Számlatétel
Számla teljesítés dátuma fizetési határidõ
1
sorszám : int megnevezés * ár
Számla teljesítés dátuma fizetési határidõ
Számlatétel sorszám : int 1
1
megnevezés ár
36
Minősítő (qualifier) Ár Termék 1
Termék
eladásiÁr érvényességKezdete * érvényességVége
Ár érvényességKezdete: Date 1
1
eladásiÁr érvényességVége
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
37
Állapot-átmenet diagram Aktív Idő lejárt Idõ lejárt do: Szaggatott hang [ 15 mp lejárt ]
[ 15 mp lejárt ]
tárcsáz( n )
felveszi a hallgatót / tárcsahang Tárcsahang do: búgó hang
tárcsáz( n )[ nem teljes a szám
Tárcsázás
tárcsáz( n )[ érvénytelen a szám ]
Várakozó
hívó leteszi a kagylót / bontja a vonalat
Érvénytelen do: sípoló hang Foglalt do: foglalt hang
Beszélgetés
tárcsáz( n )[ érvényes a szám ] / kapcsol
[ foglalt a vonal ]
Kapcsolás
[ szabad a vonal ]
Csöngetés do: csöngetõ hang hívott felveszi / beszélgetés engedélyezése
--------------------------------------------
38
REZERVÁTUM
tartalom
A RUP szerkezete idő
39
Rational Unified Process {
A Rational Unified Process a szoftverfejlesztés életciklusát négy egymást követő fázisra bontja: z z z z
{
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 z z
Értékelni az eddigi eredményeket Dö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.
40
RUP - szemlélet {
Iteratív fejlesztés z z z z
Pontos projekt vezetői követést igényel Hibát követünk el ha nem vesszük komolyan Felhasználó folyamatos bevonása Elefántcsont torony kiiktatása Követelmény elemzés
Analízis és tervezés
Tervezés Implementáció
Előzetes tervezés
Menedzsment
Kibocsátás Értékelés Teszt
RUP - kockázat csökkentése Vízesés Emberi erõforrás
Kezdet
Kidolgozás
Építés
Kockázat
Kockázat Átadás
Előzetes iteráció
Tervezési iteráció
Tervezés iteráció
Fejl. iteráció
Fejl. iteráció
Fejl. iteráció
Átadási iteráció
Átadási iteráció
Beüzemelés
Idő
41
