A tárgy keretében a hallgatók. Szoftverrendszerek Fejlesztése

Tartalomjegyzék

Szoftver Tervezés és Technológia

1. Bevezetés, probléma megfogalmazás, megoldási paradigmák 2. A szoftver mint termék előállításának folyamata, a szoftver életciklus modelljei 3. A szoftverfolyamat alapvető tevékenységei 4. Projekt menedzsment 5. Unified Modeling Language (UML) 6. Rational Unified Process (RUP)

Dr. Tick József Katona Krisztina Kurdi Zsombor Óbudai Egyetem Neumann János Informatikai Kar Szoftvertechnológia Intézet ÓE-NIK-SZTI


1

ÓE-NIK-SZTI

Oktatási cél:


2

Ajánlott irodalmak Ian Sommerville:

A tárgy keretében a hallgatók megismerkednek a szoftvertechnológia alapvető paradigmáival, a szoftver tervezés, fejlesztés metodikájával, különös tekintettel az objektum-orientált modellezésen alapuló modern megoldásokra. A hallgatók a gyakorlatok során jártasságot szereznek a CASE eszköz segítségével történő objektumorientált szoftverfejlesztésben. ÓE-NIK-SZTI


3

Szoftverrendszerek S ft d k Fejlesztése Panem kiadó, Budapest 1. kiadás: 2002 2 bő 2. bővített ít tt kiadás: ki dá 2007

ÓE-NIK-SZTI


4

1

Roger S. Pressman:

Helmut Balzert:

Software Engineering

Lehrbuch L h b h der d Software-Technik

A Practitioner’s Approach McGRAW-HILL Int. Ed., 2005 ISBN 007 123840 9

ÓE-NIK-SZTI


Spektrum p Akademischer Verlag g Heidelberg, Berlin 1998 ISBN 3 8274 0065 1

5

ÓE-NIK-SZTI


6

Egy elgondolkodtató példa: példa:

1. Bevezetés, probléma megfogalmazás, megoldási paradigmák

ÓE-NIK-SZTI


7

Építészet

Szoftverfejlesztés

Egy pici építmény

Egy kis program

(tervezés (t é nélkül élkül gyorsan „összeütjük”)

(h (hasonló ló képpen) ké )

ÓE-NIK-SZTI


8

2

Családi ház

Közepes méretű Program

( (vázlat, , terveztetés,, terv engedélyeztetés, kivitelező megbízása, töbé-kevésbé terv szerinti megépítés, használatba vétel engedélyeztetése)

( (interjúk, j , tervezgetés, g , programozás, tesztelés, módosítás, módosítás, módosítás … átadás.)

ÓE-NIK-SZTI


9

Felhőkarcoló

Nagy méretű szoftver projekt

(Analízis, nagyon hosszú, alapos, tervezés, gyors, terv szerinti kivitelezés, elenyésző számú változtatás)

(Analízis, tervezés, implementálás, tesztelés, sok-sok módosítás)

ÓE-NIK-SZTI


10

A probléma a

Miért ?

KOMPLEXITÁS Talán, mert a beton 28 nap alatt megköt ! ... és a szoftver ? …

ÓE-NIK-SZTI


11

ÓE-NIK-SZTI


12

3

1. Bevezetés 1.1 Mi a probléma ? A rendszerköltségen belül a hardver / szoftver arány változása

Szoftverfejlesztési költségek: NASA Hold-projekt: 1.000.000.000 $ (8 év)

Rendszerköltség 100% 90%

„That’s one small step for (a) man, one giant leap for mankind”

Hardver Szoftver

1961. Május j 25. Az amerikai Kongresszus ülésén

10% 1957 ÓE-NIK-SZTI

1987

Idő


13

1969. Július 20. „The eagle has landed”

A szoftver ipar az USA-ban a ‘80-as években 10.000.000.000 $/év termel ÓE-NIK-SZTI


14

A szoftverfejlesztés tradicionális fázisai: Analízis Tervezés Implementáció Tesztelés Követés

Tulajdonképpen mi a drága benne? A szoftverfejlesztés melyik fázisa drága?

ÓE-NIK-SZTI


15

ÓE-NIK-SZTI


16

4

A szoftverfejlesztés fázisainak költség arányai:

ÓE-NIK-SZTI

Javítás 1/6 1/ 6

Analízis Analízis Tervezés Implementáció Implement áció Tesztelés Tes ztelés 1/3


TovábbTovábbfejlesztés 2/3

17

A szoftverfejlesztés költségarányai a követés nélkül:

Tesztelés Tesztelés 1/2

ÓE-NIK-SZTI

Adaptáció Adaptáció 1/6 1/ 6


18

Hib bák száma

Növeljük a tesztelés intenzitását?

Analízis Anal ízis Tervezés 1/3

Költségek

Követés 2/3

A követés költségeinek megoszlása:

Kódolás 1/6 Intenzitás Inten zitás ÓE-NIK-SZTI


19

ÓE-NIK-SZTI


20

5

1.2 A szoftverkrízis

Jó tudni … z

A szoftverprojektek 31%-át „lelövik” mielőtt elkészül!

2% azonnal ment

z

A szoftverprojektek 53%-a 90%-kal túllépi az előre tervezett költségeket!

z

9%-a a nagy, és 16%-a a kis szoftverprojekteknek nem készül el határidőre!

z

A szoftverprojektek 56%-a már az analízis fázisában elcsúszik! ÓE-NIK-SZTI


21

Előzmények (a programozás hőskora) z z z

A mai fogalmak szerint gyenge hardver Gyenge fejlesztői szoftver ellátottság Monolitikus programozás – Nehezen becsülhető előre a szükséges erőforrás mennyisége – Nehezen határidőzhető a feladat – Körülményes a team-munka – nem teljes körű a tesztelés (triviális hibák még futáskor is kibukhatnak (interpreterek)) – Nagyon nehézkes a program módosítása, bővítése – Személyiség függő programok ÓE-NIK-SZTI


23

30% soha nem ment, de kifizették

20% alapos l átdolgozás után ment

3% javítás után ment

45% soha nem ment rendesen

ÓE-NIK-SZTI


22

A szoftver krízis tünetei z z z

z

Megbízhatatlanok a szoftverek (nem tudja a speckót, p , nem szűri az inputot, p , nem robosztus)) Nehezen alkalmazkodnak a konfiguráció változásához A fejlesztés nehézkes (részprogramok összeállítása nehézkes, körülményes a tesztelés, nem hatékonyy a team-munka)) Nem informatívak a szoftverek (nincs korrekt hibajelzés, merev input oldal, stb.)

ÓE-NIK-SZTI


24

6

A szoftverkrízis okai (folyt.)

A szoftverkrízis okai A minőségi követelmények változása

A szoftverek méretének növekedése maga után vonta a komplexitás növekedését (min. négyzetes az összefüggés) összefüggés).

Futási idő minimalizálás Tárigény minimalizálás

A fejlesztési módszerek nem tartottak lépést a változással. Felhasználóbarát felület Feltétlen megbízhatóság Könnyű karbantarthatóság Könnyű továbbfejleszthetőség Gyors, olcsó kivitelezhetőség Határidők pontos betartása Egyéniség független fejlesztés ÓE-NIK-SZTI


A felhasználói környezet változása (a felhasználók száma, felkészültsége, az alkalmazási körülmények gyökeresen megváltoztak.

25

ÓE-NIK-SZTI


26

E. W. Dijkstra

A krízisből kivezető út

1930-2002

Software Engineering Konferencia 1968. Október 7-11. Garmisch, NSZK

2002 Austin 2002,

1968, Garmisch

ÓE-NIK-SZTI


27

ÓE-NIK-SZTI


28

7

Megoldás A szoftverkészítés technologizálása Új elvek, módszerek és eszközök kifejlesztése (CASE) Szoftverszabványok bevezetése, szoftver minőségbiztosítás Új programozási paradigmák alkalmazása

ÓE-NIK-SZTI


29

Új programozási Paradigmák

ÓE-NIK-SZTI


30

Strukturált programozás (SP, SD, SA)

Moduláris programozás („Divide et Impera”)

ÓE-NIK-SZTI


31

ÓE-NIK-SZTI


32

8

Objektum-Orientált programozás (OOP, OOD, OOA, OOAD)

A szoftver jellemzői A hagyományos termékek készítésének folyamata Analizs Vázlatos tervezés Részletes tervezés Fizikai megvalósítás

ÓE-NIK-SZTI


33

ÓE-NIK-SZTI

hibaarán ny

A szoftver termék esetében eltérő a megvalósítás fázisa – Nincs „átültetés” az anyagba – Nem kell figyelembe venni a tervezés során z Anyagjellemzőket z Megmunkálási g módok jjellemzőit

z

34

A hagyományos termékek hibaarány görbéje

A szoftver termékek esetében: z


gyerekbetegségek

öregedés, kopás

A szoftver „nem kopik el” idő

ÓE-NIK-SZTI


35

ÓE-NIK-SZTI


36

9

A szoftver termékek hibaarány görbéje

hibaarán ny

A gyerekbetegségek okai: z tervezési-, gyártási-, szerelési hibák z hibás anyagok, IC-k, stb.

az elkopás okai: z öregedés, hőmérsékleti-, mechanikus-, környezeti behatások

Konstans az elavulásig

idő

Ez az ideális, illetve változtatás nélküli állapot. ÓE-NIK-SZTI


37

ÓE-NIK-SZTI


38

A szoftver termékek hibaarány görbéje a változtatásokat is figyelembe véve hibaarán ny

Változtatások

Győztes csapaton ne változtass! ??? idő

A változtatások újabb hibákat eredményeznek, melyek a termékben összegződnek. ÓE-NIK-SZTI


39

ÓE-NIK-SZTI


40

10

2. A szoftver mint termék előállításának folyamata, a szoftver életciklus modelljei j A szoftverfolyamat modellje a szoftverfolyamat absztrakt reprezentációja egy adott speciális p aspektusból.

z

z

z

Szokásos típusai lehetnek: ÓE-NIK-SZTI


41

ÓE-NIK-SZTI

Mit nevezünk modellnek?

42

A modellek különböző célokat szolgálhatnak:

a rendszer megértést segítő absztrakció z elhanyagolja a lényegtelen részleteket z a modell kizárólag az eredeti rendszer lényegi elemeit tartalmazza z

z z z z

LÉNYEGI ELEM ? -- lényeges a vizsgálat szempontjából Szoftver Tervezés és Technológia


Modellek például: Építészeti modellek, Modellvasút, Claudia Schiffer, Naomi Campbell, …

Modellezési koncepció

ÓE-NIK-SZTI

Munkafolyam modell (tevékenységek sorrendje, bemenetei, kimenetei, függőségei) Az adatfolyam vagy tevékenység modell (mindegyik tevékenység valamilyen adattranszfomációt hajt végre. Azt reprezentálja, hogyan alakul át a folyamat bemenete kimenetté az emberek, vagy számítógépek által végrehajtott tevékenységek során). A szerepkör / cselekvés modell(a szoftverfolyamatban résztvevő emberek szerepköreit és felelősségüket ábrázolja.)

43

a komplexitás csökkentése kommunikáció az ügyféllel a rendszer vizsgálata megépítése előtt vizualizálás

ÓE-NIK-SZTI


44

11

2.1 A vízesés (waterfall) modell A szoftverfolyamatok osztályozása: z z z z

Hagyományos szemléletű, erősen szeparált fázisokat tartalmazó modell.

Vízesés modell Evolúciós fejlesztés Formális rendszerfejlesztés Újrafelhasználás alapú fejlesztés

ÓE-NIK-SZTI

Az eredeti vízesés modellt 1970-ben W. W. Royce publikálta.


Követelmények meghatározása

45

A Royce féle vízesés modell

Rendszer és szoftvertervezés

ÓE-NIK-SZTI

46

Jellemzők: z z

Implementáció és egységteszt


z

szisztematikus, szekvenciális, top-down modell d ll a hagyományos mérnöki szemléletet követi leginkább elterjedt (legrégibb) modell

Integráció és rendszerteszt

Működtetés és karbantartás I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 ÓE-NIK-SZTI


47

ÓE-NIK-SZTI


48

12

Problémák: z z z z z

Előnyök:

a valós projektek ritkán követnek szekvenciális modellt nehezen valósítható meg az iteráció az egész modell a specifikáció minőségétől függ a projekt elején meglévő kezdeti bizonytalanságot nem tudja kezelni nagyon gy későn lát a megrendelő g működő programot

ÓE-NIK-SZTI


z z z

49

Recommended Approach to Software Development NASA/GSFC-SEL http://sel.gsfc.nasa.gov ÓE-NIK-SZTI

modellt ad a különböző fázisokhoz tartozó módszerek elhelyezésére logikus, könnyen érthető, kézenfekvő modell sok tapasztalat halmozódott fel

ÓE-NIK-SZTI


50

The spread of activities Throughout the development life cycle NASA/GSFC-SEL http://sel.gsfc.nasa.gov


51

ÓE-NIK-SZTI


52

13

A prototípus készítés folyamata

2.2 Az evolúciós modell

Gyors tervezés Kommunikáció Modellezés, gyors megvalósítási terv

Egy kezdeti implementációt (prototípust) a felhasználókkal véleményeztetünk és soksok verzión keresztül addig finomítjuk, amíg a megfelelő rendszert el nem érjük. Prototípus véleményezés

Prototípus készítés

R. S. Pressman: Software Engineering ÓE-NIK-SZTI


53

ÓE-NIK-SZTI


54

Az evolúciós fejlesztés modellje

Prototípus típusok: Specifikáció

z z z

Termék prototípus Rész-prototípus Interfész prototípus

Vázlat leírása

Fejlesztés

Validálás

Kezdeti verzió

Közbenső verziók Végleges verzió

I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 ÓE-NIK-SZTI


55

ÓE-NIK-SZTI


56

14

Az evolúciós fejlesztések típusai, problematikája

2.3 Formális rendszerfejlesztés

Típusok z Feltáró fejlesztés z Eldobható prototípus készítése

A formális rendszerfejlesztés jellegében a vízesés modellhez hasonlít. Lényege a specifikáció futtatható formába transzformálása formális matematikai eszközökkel

Problémák z A folyamat nehezen menedzselhető z A rendszerek struktúrája nem megfelelő z Minőségbiztosítási problémák z Speciális eszközök és technikák igénye ÓE-NIK-SZTI


57

A leglényegesebb különbségek a vízesés modell és formális modell között: 1.

2.

ÓE-NIK-SZTI


58

A formális rendszerfejlesztés fázisai Követelmények meghatározása

A követelményspecifikáció yp részletes matematikai jelölésekkel leírt formális specifikálás. A tervezés, implementáció, egységteszt egy transzformációs folyamat (a formális specifikáció transzformációk során programmá válik).

Formális specifikáció

Formális transzformáció

Integráció és rendszerteszt

ÓE-NIK-SZTI


59

ÓE-NIK-SZTI


60

15

A formális modell előnyei

A formális transzformáció menete z Formális specifikáció

R1

R2

Futtatható program

R3

z P1

P2

P3

P4

A transzformációs folyamat során a kezdeti formális specifikáció transzformálódik egyre jobban kifejtett, de matematikailag korrekt rendszerreprezentációvá. Minden egyes lépés további finomítás mindaddig, amíg a formális Specifikáció vele ekvivalens programmá nem válik.

z



61

ÓE-NIK-SZTI

z

z z

Mills, Cobb, Linger, Prowell munkái nyomán Formális, inkrementális fejlesztési modell Alapgondolata, hogy a szoftverhibák elkerülhetők egy szigorú átvizsgálási folyamat segítségével. A rendszerkomponensek modultesztelését helyettesítő átvizsgálások a komponensek specifikációjukkal való konzisztenciájuk ellenőrzése

ÓE-NIK-SZTI



62

A Cleanroom fejlesztés fő jellemzői

A Cleanroom szoftverfejlesztés z

A transzformációk korrektek, így könnyű a verifikációjuk, a sok kis lépés után a program lényegében a specifikáció szisztematikus transzformációja. Annak bizonyítása, hogy a program megfelel a specifikációnak, más paradigmákkal szemben itt egyszerű, hiszen sok kis ellenőrzéssé csökken a transzformációk során. Használata nagyon előnyös olyan rendszerek rendszerek, vagy részrendszerek esetében, ahol elsődleges a rendszer biztonsága, megbízhatósága és annak autentikus bizonyítása.

z

z z z

63

Formális specifikáció (a kifejlesztendő rendszer formális modelljének megadása állapot-átmenet modellel) Inkrementális fejlesztés (a szoftver fejlesztés folyamatát jól definiálható inkrementumokra osztjuk) Strukturált programozás (kis számú konstrukció alkalmazása, lépésenkénti finomítás) Statikus verifikáció (nem a hagyományos értelemben vett modul modul- és integrációs teszt) A rendszer statisztikai tesztelése (a rendszer specifikációjával párhuzamosan kifejlesztett működési profilon alapuló teszt) ÓE-NIK-SZTI


64

16

A Cleanroom fejlesztési folyamat LingerLingerféle modellje (1994) Rendszer

A cleanroom fejlesztés előnyei z

formális meghatározása

Szoftver inkrementumok Definiálása

Működési profil f fejlesztése

Strukturált Program készítése

Kód formális átvizsgálása

Statisztikai tesztek tervezése

Inkrementum integrálása

z

z

Integrált rendszer tesztelése

Először a kritikus funkciókat valósítják meg és az inkrementumokkal haladnak a kevésbé kritikusok felé. (Így a kritikus van legtöbbet tesztelve). A specifikáció és a terv folyamatos átdolgozás alatt áll, diszkrét inkrementumok formájában (élő kapcsolat a felhasználóval, kitűnő változáskövetés)) Állapot alapú rendszermodell, kiegészítő modellek, Æ jól definiált transzformációk sorozata Æ korrekt szoftver



65

A cleanroom fejlesztés a számok tükrében… z z

z

z

15 projektet (5 MSLOC) elemezve a hibák száma: 3.3 / KSLOC (a hagyományos 30-50 /KSLOC-kal szemben) A hibák a cleanroom esetében tipikusan p kódolási hibák és nem tervezési, specifikációs hibák, mint az a hagyományos esetben szokásos US Army’s Life Cycle Software Engineering Center jelentése szerint: a termelékenység 121 SLOC / emberhónapról 559 SLOC / emberhónapra nőtt a teljes ciklusra vonatkoztatva (hibák száma: 1.14/KSLOC) NASA-nál a hibák száma 7/KSLOC-ról 4.3-6/KSLOCra csökkent a cleanroom bevezetésével ÓE-NIK-SZTI


67

ÓE-NIK-SZTI


66

2.4 ÚjrafelhasználásÚjrafelhasználásorientált fejlesztés Tisztázandó kérdések: z z z z z

Mi az újrafelhasználás Mi az előnye az újrafelhasználás-orientált fejlesztésnek Mi az, ami újrafelhasználható Az újrafelhasználás formái (tervezett, nem tervezett) Az újrafelhasználás költség-komponensei

ÓE-NIK-SZTI


68

17

Azz újrafelhasználás mértéke

Az újrrafelhasználás gya akorisága

Az újrafelhasználás mértéke

Az újrafelhasználásújrafelhasználás-orientált fejlesztés folyamata Követelmények specifikációja

Komponenselemzés

Követelmények módosítása

Fejlesztés és integráció

Rendszertervezés újrafelhasználással

Rendszer validáció

Az újrafelhasznált elem mérete, komplexitása ÓE-NIK-SZTI


69

ÓE-NIK-SZTI


70

Inkrementális fejlesztés

2.5 Folyamatiteráció

z z

z

Inkrementális fejlesztés (a specifikáció, a tervezés, az implementálás kis inkrementális lépésekben valósul meg).

z

Spirális fejlesztés (belülről kifelé tartó spirálvonalat követ a fejlesztés).

ÓE-NIK-SZTI


z

z z

71

Mills ajánlotta 1980-ban Cél az átdolgozások számának csökkentése a f j fejlesztési é i folyamatban. f Lehetőséget ad a megrendelőnek bizonyos a követelményekkel kapcsolatos döntések későbbre halasztására. A fejlesztés jól meghatározott inkremensekben történik. Ha egy inkremens elkészül, átadásra kerül, azt a megrendelő akár használatba is veheti

ÓE-NIK-SZTI


72

18

A projekt előrehaladása

Az inkrementális fejlesztés modellje

Vázlatos kö t l é követelmények k meghatározása

Rendszerinkremens fejlesztése

Követelmények I k Inkremensekhez kh rendelése

Inkremens validálása

Szoftver funkcionalitása

Kommunikáció

Rendszer A hit ktú ájá k Architektúrájának megtervezése

Inkremens integrálása

Analízis, tervezés

n. inkremens

Kódolás,, tesztelés Validálás Szállítás, visszajelzés

3. inkremens

Rendszer validálása

2. inkremens 1. inkremens

Végleges rendszer R. S. Pressman: Software Engineering ÓE-NIK-SZTI

z

z

z z


73

ÓE-NIK-SZTI

Projekt idő


Az inkrementális fejlesztés előnyei

A RAD Modell

A szoftver már menetközben használhatóvá válik a megrendelő számára (kritikus követelmények teljesülnek először) A megrendelők használhatják a korábbi inkremenseket, mint prototípusokat a későbbi inkremensekhez Kisebb a kockázata a projekt kudarcának, biztonságos fejlesztés A legkritikusabb funkciókat teszteljük legtöbbet (azok készülnek el először)

(Rapid Application Development)

ÓE-NIK-SZTI


z z z z z

75

74

JJ. Martin publikálta 1991-ben Inkrementális modell Kifejezetten rövid fejlesztési ciklus (60-90 nap) „High-speed” adaptációja a vízesés modellnek A nagy sebesség a „component based construction” , „software reuse”, „automatic code generation” technikák alkalmazásával érhető el.

ÓE-NIK-SZTI


76

19

A RAD vázlatos modellje

z z z z

Különböző teamek dolgoznak párhuzamosan a tervezés fázisától a különböző funkciókon A team tagjainak sokoldalúnak kell lennie A megrendelő szakemberei is részt vesznek a teamek munkájában Modern fejlesztői környezetet használ RAD-et támogató tool-ként hirdetik magukat: – Microsoft Visual Studio .NET – Sun Java Studio Creator – BEA Web Logic Workshop – Borland C# Builder – IBM WebSphere Studio Application Developer

Team #n Modelling Business Modelling Data Modelling Process Modelling

Communication

Planing Team #1 Modelling Business Modelling Data Modelling Process Modelling


77

A RAD modell problémái z

z z


ÓE-NIK-SZTI

60 – 90 days


78

A BoehmBoehm-féle spirál modell

Nagy projektek esetén nagy a humán erőforrás igény az elegendő számú RAD-team felállításához Ha a rendszer nehezen modularizálható, a komponensek elkészítése problematikus Magas műszaki kockázat esetén a RAD nem működik biztonságosan

ÓE-NIK-SZTI

Construction Component reuse authomatic code generation, testing

Construction Component reuse authomatic code generation, testing R. S. Pressman: Software Engineering

ÓE-NIK-SZTI

Deployment Inte egration, Delivery Feedb back

z

79

z z

Boehm publikálta 1988-ban 1988 ban A valós fejlesztést jól követő modell

Prof. Dr. Barry Boehm University of Souther California

ÓE-NIK-SZTI


80

20

A spirál minden ciklusa négy szektorra bontható: 1. Célok kijelölése (célok, alternatívák, megszorítások, kockázatok meghatározása 2. Kockázat becslése, csökkentése (kockázat elemzés, kockázati tényezők csökkentésére intézkedés kidolgozása 3. Fejlesztés és validálás (a következő szintű termék fejlesztése, a kockázat analízis eredményének függvényében fejlesztési modell választása 4. Tervezés (a következő fázis, ciklus megtervezése ÓE-NIK-SZTI


81

A BoehmBoehm-féle spirál modell ciklusai és lépései Cycle

Step

Cycle 1 – Early analysis

Step 1: Objectives, Alternatives, and Constraints Step 2: Risk Analysis and Prototype Step 3: Concept of Operation Step 4: Requirement and Life cycle Plan Step 5: Objectives, Alternatives, and Constraints p 6: Risk Analysis y and Prototype yp Step

Cycle 2 – Final analysis

Step 7: Simulations, Models and Benchmarks Step 8: Software Requirements and Validation Step 9: Development Plan Step 10: Objectives, Alternatives, and Constraints Step 11: Risk Analysis and Prototype

Cycle 3 - Design

Step 12: Simulations, Models and Benchmarks Step 13: Software Product Design Validation and Verification Step 14: Integration and Test Plan S Step 15 15: Obj Objectives, i Al Alternatives, i and dC Constraints i Step 16: Risk Analysis and Operational Prototype

Cycle 4 – Implementation and testing

Step 17: Simulations, Models and Benchmarks Step 18: Detailed Design Step 19: Code Step 20: Unit, Integration and Acceptance Testing Step 21: Implementation (Deployment)

ÓE-NIK-SZTI


A Boehm--féle Boehm spirál-spirál modell



82

2.6 „Agile Software Pocesses” 2001 ben 17 neves szoftver fejlesztő alapította 2001-ben meg az „Agile Allience”-t és fogalmazta meg a „Manifesto for Agile Software Development”et

83

ÓE-NIK-SZTI


84

21

A legfontosabb elvek

– A haladás legjobb mértéke a működő szoftver – „Agile process” fenntartható fejlődést ösztönöz – A fejlesztőknek és a megrendelőnek egy állandó ütemet kell fenntartani a fejlesztési folyamatban – A kiváló műszaki színvonalra és a jó tervre folyamatosan ügyelni kell – Egyszerűség – csak az igazán fontos feladat elvégzése – Az önszerveződő, aktív teamektől származnak a legjobb megoldások (szerkezetekre, követelményekre, tervekre) – Rendszeres időközönként a teamnek önvizsgálatot kell tartani és viselkedését esetleg módosítani

– Első rendű szempont a megrendelő maradéktalan g kielégítése – Flexibilitás a követelmények változásával szemben – Működő szoftver gyors átadása (inkrementálisok) – Az üzleti szakembereknek és a fejlesztőknek napi kapcsolatban kell lenniük – Motivált szakembereket gyűjts a projekt köré, t teremtsd t d meg a ffeltételeket ltét l k t a munkájukhoz káj kh – Szorgalmazd a szemtől-szembeni párbeszédet a teamen belül az információ cserére

ÓE-NIK-SZTI


85

ÓE-NIK-SZTI

z z z z z z z

Extreme Programming (XP) Adaptive Software Development (ASD) Dynamic Software Development Method (DSDM) Scrum Crystal Feature Driven Development (FDD) Agile Modeling (AM)

z z z

Beck publikálta először 1999-ben Inkrementális megközelítés OO alapon Ajánlott szabályok és praktikumok 4 alapvető aktivitás: – – – –

Planing Design Coding Testing

www.agilealliance.org www.extremeprogramming.org ÓE-NIK-SZTI


86

Extrém programozás (XP)

Ezen elveket követő módszerek: z


87

ÓE-NIK-SZTI


Kent Beck

88

22

Az extrém programozás vázlatos modellje Simple design CRC cards Spike solutions User stories Iteration plan A Acceptance t test t t

design

planing coding

Release Software increment

testing

R. S. Pressman: Software Engineering ÓE-NIK-SZTI

Pair programming Continous integration No overtime Unit test Acceptance test


89

Az extrém programozás szabályai (2)

Az extrém programozás szabályai (1) Planning User stories are written. Release planning creates the schedule. Make frequent small releases. The project velocity is measured measured. The project is divided into iteration. Iteration planing starts each iteration. Move people around. A stand-up meeting starts each day. Fix XP when it breaks. Designing Si li it Simplicity. Choose a system metaphor. Use CRC cards for design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible. ÓE-NIK-SZTI


90

A változtatás költségeinek alakulása

Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. production code is p pair p programmed. g All p Only one pair integrates code at a time. Integrate often Use collective code ownership. Leave optimization till last. No overtime. Testing T ti All code must have unit tests. All code must pass all unit tests before it can be released. When a bug is found tests are created. Acceptance tests are run often and the score is published.

www.khatovaretech.com

ÓE-NIK-SZTI

ÓE-NIK-SZTI


91


92

23

Katedrális <<-> Bazár ?

ÓE-NIK-SZTI

„A Linux felborított sok dolgot, amelyről úgy gondoltam, ismerem. Hirdettem a kis eszközök, a gyors modellalkotás és a lépésenkénti fejlődést elősegítő programozás unixos igéjét évekig. Ugyanakkor abban is hittem, hogy létezik egy bizonyos összetettség, amely fölött egy centralizáltabb, apriori megközelítés szükséges. Hittem benne, hogy a legfontosabb szoftverek (az operációs rendszerek és az olyan igazán nagy eszközök, mint az Emacs programozói szerkesztő) szükségszerűen a katedrálisokhoz hasonlóan épülnek, egyéni varázslók által, óvatosan ügyeskedve, vagy mágusokból álló, elszigetelt kis csoportok által, idő előtti bétaverziók nélkül. nélkül Linus Torvalds fejlesztői stílusa – adj ki korán és gyakran, adj ki mindent, amit csak tudsz, a kuszaságig légy nyílt – meglepetésként ért. Nem volt itt semmiféle csöndes, tiszteletteljes katedrálisépítés, a Linux-közösség a különféle tennivalók és megközelítések nagy, fecsegő bazárjára hasonlított (ezt leginkább azok a Linuxarchívumok jelképezik, amelyek bárkitől elfogadják a beküldött dolgokat), amelyből egy koherens és stabil rendszer látszólag csak valami csoda folytán születhetne. Az a tény, hogy a bazár stílus működni látszott, és nem is rosszul, határozottan sokkoló volt. Ahogy jártam az utamat, nemcsak egyéni projekteken dolgoztam keményen, hanem annak a megértésén is, hogy a linuxos világ miért veszi olyan jól az akadályokat a katedrálisépítők számára aligha elképzelhető sebességgel, ahelyett, hogy egyszerűen darabjaira esne.” E. S. Raymond http://magyar-irodalom.elte.hu/robert/szovegek/bazar/


93

3.1 Szoftverspecifikáció (analízis) A követelmények tervezésének fázisai: 1. Megvalósíthatósági tanulmány készítése –

3. A szoftverfolyamat alapvető tevékenységei 3.1 Szoftverspecifikáció (Analízis) 3.2 Szoftver tervezés és implementáció 3.3 Programozás és tesztelés 3.4 Szoftver validáció (tesztelés) 3.5 Szoftverevolúció (karbantartás, követés)

ÓE-NIK-SZTI

Követelmények feltárása és elemzése Követelmények specifikációja

Követelmények feltárása és elemzése

2. –

94

3.1.1 A követelménytervezés folyamata Megvalósíthatósági tanulmány

Gyors gazdasági, műszaki elemzés a megvalósításra és az ü üzemeltetésre lt té vonatkozóan tk ó


Követelmények validálása

Meglévő rendszerek vizsgálata, modellek, prototípusok készítése, konzultáció a megrendelővel

Követelmény specifikáció készítése

3. –

A rendszerkövetelmények és a felhasználói követelmények megfogalmazása, egységes dokumentumba foglalása

Megvalósítg hatósági jelentés

Követelmény validáció

4. –

Rendszermodellek

Felhasználói és Rendszerkövetelmények

Követelmények Kö t l é k dokumentumai

A követelmények valószerűségének, konzisztenciájának, teljességének vizsgálata, hibák keresése I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002

ÓE-NIK-SZTI


95

ÓE-NIK-SZTI


96

24

3.1.2 A specifikációt támogató technikák

Módszer: - először kötetlen beszélgetés, informálódás a rendszer alapvető kérdései iránt. (Ki fogja használni a rendszert? Mi lesz az előnye a rendszer használatának?)

a.) Előzetes interjú módszer jellemzők: – – – –

- ezután a rendszer jellemzőivel kapcsolatos kérdéskör kerül elő (Hogy jellemezné, milyen ismereteket kell majd magánviselnie az elkészült rendszernek? Milyen környezetben kell majd üzemelnie a rendszernek?)

a személyek nem ismerik egymást tartanak a félreértésektől hatnak esetleges régi rossz tapasztalatok ugyanakkor mindkét fél sikerorientált

Az előzetes interjú célja a jég “megtörése”.

ÓE-NIK-SZTI


97

Probléma: A megrendelő g és a vevő tudat alatt “mi és ők” csoportokat képez és ebben gondolkodik. Nem alakul ki igazi team munka (félreértések, lényeges info elvész, stb.) Megoldás: FAST Az analízis és specifikáció p korai fázisát,, az információ gyűjtést támogató team-orientált szisztematikus módszer.


ÓE-NIK-SZTI


98

Lényege:

b.) FAST (Facilitated Application Specification Techniques)

ÓE-NIK-SZTI

- A harmadik kérdéscsoport az interjú hatékonyságára irányul. (Lényegretörő kérdéseket tettem fel? Van valami, amit meg kellen még kérdeznem?)

99

A felhasználók és fejlesztők közös teamet hoznak létre a probléma identifikációjára, a megoldás elemeinek kijelölésére, a megoldással szemben támasztott követelmények előzetes meghatározására. Alapvető jellemzők: - Az üléseket semleges fél vezesse - Az ülés előkészítésének, a meghívottak köre kialakításának szabályai rögzítve legyenek - a napirend rögzítse a teendőket, de adjon lehetőséget az ötletek szabad kifejtésére - Elnököt kell kijelölni az ülés irányítására - Definíciós mechanizmus használata ajánlott (táblázat, tábla, Pinwand stb.) ÓE-NIK-SZTI


100

25

FAST-ülés előkészítése: minden résztvevőt megkérnek, hogy készítsen: - a rendszert körülvevő környezet objektumainak listája - a rendszert alkotó objektumok listája - azon eljárások, f.vények listája, amelyek manipulálják ezen objektumokat. - kényszerfeltételek és működési kritériumok listája (a listáknak nem kell komplettnek lenni)

ÓE-NIK-SZTI


101

5.) Rész-teamek képzése, minispecifikációk elkészítése, minden egyes elemre. 6.) A rész-teamek bemutatják az általuk elkészített minispecifikációkat (Itt felvetődhetnek új minispecifikációkat. objektumok, kényszerfeltételek, funkciók, stb) Vita a listákról, megoldatlan problémák listájának felvétele. 7.) A minispecifikációk elkészülte után a részteamek elkészítik a validációs kritériumokra tett jjavaslatokat. 8.) Az eddigi ülések anyagaiból egy kijelölt csoport összeállítja a specifikációt.

ÓE-NIK-SZTI


103

Alkalmazott módszertan az üléseken: 1.) az első ülésen minden résztvevőnek igazolnia kell a termék szükségességét 2.) az elkészített listák ismertetése Pinn-wall, vagy mágnes tábla használata, a listaelemek csoportosíthatók, t íth tók áthelyezhetők áth l h tők llegyenek, k kiegészítések legyenek lehetségesek (A vita tilos!) 3.) az ismertetett listák vitája, új ötletek felvétele a táblára, de törölni tilos, redundanciák összevonása 4.) konszenzusos lista vitával való kialakítása, törlés is és módosítás is megengedett (eredmény: konszenzusos lista) ÓE-NIK-SZTI


102

A pontos specifikáció nagyon fontos! Az Airbus A320 fedélzeti szoftverének specifikációja szerint a repülőgép fékezőrendszer működésének logikája: z

„földön" = mindkét főkeréken a nyomás legalább 12 tonna

z

„sugárfék engedélyezve" = „földön"

z

„kerék fék engedélyezve" = „Ha legalább az egyik főkerék sebessége nagyobb 72 csomónál" vagy ( „főldőn" és „a rádiós magasságmérő 3 méternél kisebb távolságot mutat a főldtől" )

ÓE-NIK-SZTI


104

26

z z

1988-ban rendszerbe állítva, 5 év repülés után … 1993. szeptember 14. Varsó, a Lufthansa 2940-es járata Frankfurt felől leszálláshoz készülődött …

Hogyan fordulhat elő, hogy egy 5 éve jól működő szoftver meghibásodik ? z z z z z

… 2 halott, 45 sebesült … ÓE-NIK-SZTI


105

Időjárás: viharos eső, szél 160 fokról 25 Km/h, vastag vízréteg a kifutón (aquaplaning) A pilóták a szabványos eljárást alkalmazták (emelt sebesség, enyhe jobbra döntés) A jobboldali kerekek értek földet először és csak 9 másodperccel később a bal oldaliak. 9 másodpercig á d i semmilyen il fék nem működött űködött A bal oldali kerekek teljes leérkezése után léptek működésbe a fékek

ÓE-NIK-SZTI


106

3.2 Szoftvertervezés és implementáció 3.2.1 A tervezési folyamat tevékenységei:

5. Adatszerkezet tervezés A rendszer implementációjában használt adatszerkezetek

1. Architekturális tervezés

részletes tervezése

A rendszert alkotó alrendszerek és azok kapcsolatainak p azonosítása, dokumentálása

6. Algoritmus tervezés

2. Absztrakt specifikáció

A szolgáltatások biztosításához szükséges algoritmusok részletes megtervezése

Minden egyes alrendszer szolgáltatásainak absztrakt specifikálása, peremfeltételekkel, megszorításokkal együtt

3. Interfész tervezés Minden egyes alrendszer interfészének megtervezése, d k dokumentálása tálá

4. Komponens tervezés A szolgáltatások komponensekhez rendelése, a komponensek interfészének meghatározása ÓE-NIK-SZTI


107

ÓE-NIK-SZTI


108

27

3.2.2 A tervezési folyamat általános modellje

3.2.3 A tervezés általános elvei

Követelmények specifikációja

z z Architekturális tervezés

Absztrakt specifikáció

Interfész tervezés

Komponens tervezése

Adatszerkezet tervezése

z

Algoritmus tervezése

z z

Rendszerarchitektúra

Szoftverspecifikáció

Interfészspecifikáció

KomponensSpecifikáció

Architektúraspecifikáció

Absztrakció Finomítás Modularitás (kohézió, csatolás) Programszerkezet kialakítás Információ rejtés

Algoritmusspecifikáció



109

ÓE-NIK-SZTI

Absztrakció 1. szint


110

Finomítás A lépésenkénti finomítás módszerét Wirth ajánlotta 1971-ben.

(A problémára és környezetére orientáló megfogalmazás)

Párhuzamosan finomítható program és adatszerkezet (pl: rendezés). rendezés) a finomítás a funkcionális primitívekig tart. Minden finomítási lépés egy-egy döntést igényel. (strukturáló objektum és szempont.

........ ........ n. szint

(procedurális orientációjú leírás)

Absztrakciós stratégiák:) soros (egy strukturáló objektum van

Prof. Dr. Niclaus Wirth ETH Zürich Pascal, Oberon 8 egyetem díszdoktora

z

Az absztrakció segít koncentrálni a lényegesre, elhanyagolva a lényegtelent, mindhárom területen alkalmazható (data design, procedual design, architectural design) ÓE-NIK-SZTI


111

– tiszta ti t ((adatorietált, d t i tált eljárás ljá á orientált,) i tált ) – kereszt (pl. információs rendszerek) – ortogonális z

párhuzamos ÓE-NIK-SZTI


112

28

p1 - probléma; c(p) - a probléma komplexitása E(p) - a megoldáshoz szükséges ráfordítás (pl: költség) ha C(p1) > C(p2)

E(p1) > E(p2)

C(p1+p2) > C(p1) + C(p2) E(p1+p2) E(p1 p2) > E(p1) + E(p2)

(Tapasztalati képlet)

költség

Modularitás

A teljes szoftver költség alakulása a modularizálás függvényében Költség/modul

„M”

Ebből következik, hogy bontsuk szét sok apró, pici modulra a feladatot. ÓE-NIK-SZTI


113

Minimális költségek tartománya ÓE-NIK-SZTI

Probléma: nem lehet M-et előre megmondani.

Az effektív modularizálás (modulokra bontás) titka a funkcionális függetlenség. Ez azt jelenti, hogy jól körbe kell tudni határolni azon területet, amely egy modulba vonva logikusan összekapcsolódik és nem kommunikál sokat a külvilággal. (A másik szempont, hogy ezek aránylag egyszerű funkciók legyenek.)


114

A kohézió a modul kompaktságát, integritását, feladatorientált „tisztaságát”, tisztaságát” belső összetartását ill ill. homogenitását (a feladat szempontjából) fejezi ki. A kohézió egy spektrumként fogható fel a gyengétől az erősig. Törekedni kell e minél erősebb kohézióra.

A funkcionális függetlenség mérésére két jellemző szolgál: - kohézió - csatolás Szoftver Tervezés és Technológia

modulok száma

Kohézió

A modulok mérete (és így a száma) függ a feladat jellegétől nem lehet a modulokat „ész nélkül” szétbontani (funkcionalitás, integritás, kohézió, csatolás)

ÓE-NIK-SZTI

Interfész költség

115

ÓE-NIK-SZTI


116

29

Programszerkezet kialakítás

Csatolás

Fan-out

Egy spektrumként adható meg a laza csatolástól a szoros csatolásig.

mélység

A csatolás a modul kapcsolatának intenzitását, erősségét fejezi ki más modulokhoz (adat és vezérlési kapcsolat).

Törekedni kell a minél lazább csatolás kialakítására.

Fan-in szélesség

ÓE-NIK-SZTI


117

ÓE-NIK-SZTI


118

Információ rejtés 1972-ben Parnas publikálta az információ rejtés fogalmát.

Ajánlások a programszerkezet kialakításánál: z z z

Lényege: A program elemek (modulok) csak az interfészen keresztül kapcsolódnak a külvilághoz. Belső változók, rutinok, eljárások nem érhetők el a külsők számára.

Minimalizálni kell a fan-outokat és fan-ineket A mélység és a szélesség ne legyen 7-8-nál nagyobb Törekedni kell az egy bemenetű és egy kimenetű modulokra

David L. Parnas

Előnye: z Jól definiált interfész z Minőségi biztonság modulok cseréje, javítása esetén (a hiba is be van zárva) ÓE-NIK-SZTI


119

ÓE-NIK-SZTI


120

30

Jackson Structured Programming

3.2.4 Tervezési módszerek

Michael A. Jackson publikálta 1974-ben z

Struktúráló objektum: adattér Strukturáló szempont: szemantikus szint

Adatszerkezet orientált – JSP (Jackson)

z

Adatfolyam orientált – SA (DeMarco), SD (Yourdon, Constantine,

z

Objektum orientált – OOSE (Jacobson), OMT (Raumbught & all), UML (Raumbught Booch, (Raumbught, Booch Jacobson)

Alkalmazott elvek: Michael A. Jackson z a probléma hierarchikus (top-down) lebontása z a lépésenkénti finomítás módszere z kizárólag elemi részgráfok alkalmazása (Böhm és Jacopini tétel alapján: szekvencia, szelekció és iteráció használata) Alkalmazott formalizmusok: z szerkezeti ábra (a program- és adatszerkezethez) z funkcionális leírás (pszeudokód szerű) a programszerkezet leírásához

ÓE-NIK-SZTI


121

Alapszerkezetek

ÓE-NIK-SZTI


122

Szelekció

Szekvencia A

A

A A1 A1

A seq A1 A2 A3 A end ÓE-NIK-SZTI

A2

Adatszerkezetnél: pl: l rekord k d

A2

A1

A3

Programszerkezetnél: egymásután á tá végrehajé h j tandó műveletek

A select – feltétel A1 A or A2 A end

A select - feltétel A1 A end

Adatszerkezetnél: változó rekord Programszerkezetnél: feltételes utasítás Szoftver Tervezés és Technológia

123

ÓE-NIK-SZTI


124

31

Egy példa a jelölésrendszer használatára

Iteráció

A

A

A1

B

*

A iter while – feltétel A1 A end

C

D

E

F

*

H

I

G

*

Adatszerkezetnél: fájl Programszerkezetnél: ciklus ÓE-NIK-SZTI

J


125

Példa:

ÓE-NIK-SZTI

K


A bemenő adatszerkezet terve

Adott a TÖRZS nevű bemenő állomány, mely rekordjának felépítése: név, cím, iskolai végzettség kódja Tervezzünk programot, amely kilistázza az egyetemet végzett dolgozók (iskolai végzettség kódja = E) nevét nevét, címét és számát az alábbi formában:

TÖRZS

REKORDOK

REKORD

Egyetemi végzettségű dolgozók: Név: …….. …….. …….. ……..

126

Cím: …….. …….. …….. ……..

EGYETEMI VÉGZ.

* NEM EGYET. VÉGZ.

A …….. Dolgozóból egyetemet végzett ……..

ÓE-NIK-SZTI


127

ÓE-NIK-SZTI


128

32

A programszerkezet kialakításának menete

A kimenő adatszerkezet terve LISTA

FEJSOROK

LISTA TEST

Bemenő adatszerkezet

Programszerkezet

ÓE-NIK-SZTI


Kimenő adatszerkezet

ZÁRÓSOR

*

REKORD

EGYETEMI VÉGZ.

ÓE-NIK-SZTI


129

A programszerkezet terve

A módszer tervezési lépései 1. Az adatszerkezetek elkészítése A feladat szövegének elemzése alapján elkészítjük a bemenő és kimenő adatszerkezeteket a három alapelem ((szekvencia,, szelekció,, iteráció)) segítségével. g g (Annyi ( y bemenő és kimenő adatszerkezetet ábrázolunk, ahány fizikailag létező állomány van. Sorrend nem számít.)

LISTA

ELŐKÉSZÍTÉS

FELDOLGOZÁS

130

BEFEJEZÉS

*

REKORD FELDOLG.

2. A programszerkezet elkészítése az adatszerkezet alapján EGYETEMI VÉGZ.

NEM EGYET. VÉGZ.

3. A tevékenységek összeállítása "összeírjuk" az összes felmerülő tevékenységet valamint feltételt és sorszámmal látjuk el. ÓE-NIK-SZTI


131

ÓE-NIK-SZTI


132

33

Strukturált analízis (SA) 4. A tevékenységek elhelyezése a programszerkezetben Meg kell keresni azt a programelemet, amelyhez az adott tevékenység a legközelebb áll.

Demarco 1979-ben fektette le az alapjait (foglalta össze)

5. A funkcionális leírás elkészítése Leírjuk a teljes programot (pszeudókódban) a célnyelvtől független formában (konkrét tevékenységeket, feltételeket, logikai kapcsolatokat tartalmaz)

ÓE-NIK-SZTI


Jellemzői: 20 éves fejlődési folyamat eredménye modellezési technika - adat és vezérlési áramlást és tartalmat ír le - a funkcionalitás és viselkedés szerint particionál 133

Data Flow Diagram (DFD) External Entity Process

Adat

Adat tároló

ÓE-NIK-SZTI


134

0-s szintű DFD

külső egyed (információ forrás vagy nyelő)

External entity

External entity Computer Based System

Folyamat (Információ transzformációt hajt végre)

External entity

Adat elem vagy azok gyűjtő fogalma A nyíl mutatja az információ áramlás irányát irányát.

External entity

A0 0-s szintű i tű DFD csak k egy buborékot b b ék t tartalmaz, t t l amii nem más, mint a rendszer szoftver. Ezt szokás még: Context model, vagy Fundamental system Model-ként is nevezni.

Adat tároló (tetszőleges típusú, stacktől adatbázisig) Szoftver Tervezés és Technológia

ÓE-NIK-SZTI

Tom Demarco

135

ÓE-NIK-SZTI


136

34

A DFD egyértelműen maghatározza, melyek a külső egyedek, mi az, ami része a rendszernek és mi az, ami nem. (Hol vannak a rendszer határai.)

A DFD-t kiegészítjük két leírással: a.) Data Dictionary, Adatszótár (DD)

A DFD az információ áramlását írja le, nem blokk diagram! (sorrendiséget nem tartalmaz) A DFD-t finomítjuk, a buborékokat felvágjuk. (meddig finomítunk, melyek a finomítás szabályai)

ÓE-NIK-SZTI


137

b.) Process Specification (PSPEC) A folyamat szöveges megfogalmazása. (Algoritmust, megszorításokat, és egyéb részleteket tartalmazó kiegészítő leírás.) (A PSPEC megadásának formái)

ÓE-NIK-SZTI


1-es szintű DFD

Példa: SafeHome system

Control panel

0-ás szintű DFD

Control panel

Display information

Alarm type

SafeHome Software

Sensors

Configure request

Sensor status

Telephone number tones

Interact With user

Control Panel display

Configuration info Activate/ Deactivate system t


Display Messages and status

Alarm Process password

Alarm

Telephone line

R. S. Pressman: Software Engineering (third edition)

Control Panel display

Start/ stop

Password

Sensors

ÓE-NIK-SZTI

Configure Configuration data system

User commands and data

User commands and data

138

Sensor status

Monitor sensors

Telephone line

R. S. Pressman: Software Engineering (third edition) 139

ÓE-NIK-SZTI


140

35

2-es szintű DFD

Format for display

Configuration info

Strukturált tervezés (SD)

Sensor information

Constantine, Myers, Steven nyomán Constantine és Yourdon dolgozta ki.

Sensor ID type, location

Configuration data Asses against set-up

Alarm data

Generata Alarm signal

Alapmű: E. Yourdon, L. Constantine: Structured Design, Prentice-Hall 1979

Alarm type

Sensor ID type Dial phone

Read sensors

T l h Telephone number tones

p A DFD típusai: 1.) transzformáció folyam (bejövő folyam transzformációs folyam - kimenő folyam) 2.) tranzakció folyam (egy „tigger” adat tranzakciókat indít el lásd.) Larry Constantine

R. S. Pressman: Software Engineering (third edition) ÓE-NIK-SZTI


Adatfolyam orientált „Tranzakció” tervezés

Edward Yourdon

Alkalmazhatóság: igen széleskörű, hiszen a problémák jelentős része leírható információáramlással (DFD)

141

ÓE-NIK-SZTI


142

Tervezési heurisztikák

DFD finomítása „Transzformáció”

Folyam típusa

Tranzakció központ és adat elérési út azonosítása

Bejövő/kimenő kötegek azonosítása

Tranzakciós szerkezet leképezése

Szerkezet leképezése

Tranzakció analízis

Transzformáció analízis

Szerkezet faktorizálása Szerkezet finomítása a tervezési heurisztikákkal Interfész és g globális adatszerkezet leírások elkészítése Ellenőrzés Részletes tervezés

1.) A programszerkezet kialakításakor vegyük figyelembe a csatolást és a kohéziót /modulok (funkciók) összevonása, szétválasztása/. 2.) Kerüljük a nagy Fan-Out-tal rendelkező szerkezeteket. Inkább a kiegyensúlyozott, arányos szerkezetekre törekedjünk 3.) A hatást kiváltó modul vezérlési körében legyen az a modul, amire hatással van. 4.) A modul-interfészek komplexitásának csökkentésére, a konzisztencia növelésére kell törekedni. 5.) Törekedjünk „emlékezet nélküli” modulok kialakítására (azonos inputra mindig azonos választ ad). 6.) Törekedjünk az „egy bemenet-egy kimenet” modulok létrehozására. 7.) A modulok csoportosítása különböző kényszer feltételek miatt. pl.: portabilitás



143

ÓE-NIK-SZTI


144

36

Példa: SafeHome

Példa: SafeHome


R. S. Pressman: Software Engineering (third edition)


145

3.3 Programozás és tesztelés

Hibajavítás megtervezése

Hiba kijavítása


146

A programozásnál is ügyelni kell … 1999. szeptember 23-án 9 hónapig tartó, több mint 190 millió Km utazás után a NASA mars szondája elérte a vörös yg bolygót.

A programozás lépései A programozás dokumentumai A ttesztelés t lé ffajtái jtái A tesztelés menete A tesztelés dokumentumai

Hiba behatárolása

ÓE-NIK-SZTI

Program újratesztelése

A telemetria vétele után a földről elküldött parancssorozat alapján a szonda mars körüli pályára kezdett állni. A folyamatos telemetria adatok rendben voltak. 5 perc után a szonda eltűnt és soha nem sikerült vele kapcsolatot teremteni…

A szoftver belövési folyamata I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 ÓE-NIK-SZTI


147

ÓE-NIK-SZTI


148

37

A NASA belső vizsgálata a következőket állapította meg: A mars szonda szoftverén két team dolgozott. A kódolás fázisában az egyik team az angol mértékegységeket has nálta (inch használta (inch, láb, láb mérföld mérföld, font) a másik team a metrikus rendszert (cm, m, km, kg). Így amikor a földön a telemetriától 125 mérföld felszín feletti magasságot kaptak, akkor az valójában 125 Km volt. A parancssorozatban kiküldött rossz paraméterek kö k éb a szonda következtében d megsemmisült. i ül

ÓE-NIK-SZTI


149

Verifikáció: A terméket jól készítjük el? (a termék megfelel-e a specifikációnak, illetve a funkcionális és nem funkcionális követelményeknek) Validáció: A megfelelő terméket készítjük el? (a termék megfelel-e a vevő elvárásainak, ezért a validáció már a követelmények megfogalmazásánál kezdődik) A V&V végig követi a teljes fejlesztési folyamatot.


A verifikáció és a validáció (V&V) azon ellenőrző és elemző folyamatok összessége, amelyek célja annak vizsgálata, hogy a szoftver megfelel a specifikációnak. Ennek része a hagyományos értelemben vett szoftvertesztelés is.

ÓE-NIK-SZTI


150

A V&V folyamaton belül 2 technika használható:

Boehm megfogalmazásában:

ÓE-NIK-SZTI

3.4 Verifikáció, validáció validáció,, tesztelés

151

1., A szoftver átvizsgálások A rendszer fejlesztése során keletkező dokumentumok (követelmény-dokumentáció (követelmény-dokumentáció, tervek tervek, ábrák ábrák, forrássorok, stb.) ellenőrzése. Ezek statikus technikák, mert nem szükséges hozzá a program futtatása (a korai szakaszban még nincs is program) 2., A szoftver tesztelések Az elkészült A lké ül szoftver f ellenőrzése ll ő é különböző külö bö ő tesztadatok d k futtatásával. Ellenőrizzük a szoftver kimeneteit, a futás közbeni viselkedését és a teljesítményét. Ez ún. dinamikus technika, mivel a szoftver futtatását igényli. ÓE-NIK-SZTI


152

38

A szoftver verifikálásának, validálásának, tesztelésének helye a szoftverfolyamatban.

Átvizsgálási technikák: z

Szoftver átvizsgálása

z z

Követelmények specifikációja

Magasszintű terv

Formális specifikáció

Részletes terv

Szoftver

Szoftver tesztelése

Prototípus

Programátvizsgálások Automatikus forráskód elemzés F Formális áli verifikáció ifiká ió

A statikus technikával csak a program és a specifikáció közötti megfelelőséget tudja vizsgálni. Így nem vizsgálható pl.: a megbízhatóság, bí h tó á teljesítmény. t lj ít é A tesztelés nem nélkülözhető.



153

ÓE-NIK-SZTI

z

Hiányosságtesztelés (célja a program és a specifikáció között meglévő hiányosságok felderítése. Célirányos, tervezett vizsgálat vizsgálat.)) Statisztikai tesztelés (célja a program teljesítményének, megbízhatóságának vizsgálata. Tükrözniük kell a valós felhasználói bemeneteket és azok gyakoriságát. Becslés adható a megbízhatóságra a működés közben mért hibák alapján, alapján illetve illet e a teljesítményre teljesítmén re a statisztikai statis tikai tesztadatok feldolgozásánál rögzített paraméterek - pl.: futási idő, válaszidő, stb - alapján) ÓE-NIK-SZTI


154

A „belövési” folyamat

A tesztelések fajtái: z


155

A V & V az a folyamat, amelyik megállapítja, hogy a szoftverben vannak-e hiányosságok. A bbelövés lö é az a folyamat, f l t amely l behatárolja b h tá lj és é kijavítja kij ítj ezeket a hiányosságokat. Jellemzők: z Igen magas fokú nyelvi környezet ismeretet igényel z Nehezen algoritmizálható, szabályok nehezen adhatók meg z Speciális célszoftverek segíthetik a hiba megtalálását ÓE-NIK-SZTI


156

39

A szoftver belövési folyamat

A hiba behatárolását követően kijavítjuk, majd rendszert újra validáljuk. Ez lényegében a tesztek újbóli megismétlését jelenti, amit szokás regressziós tesztelésnek nevezni.

Teszteredmények

Hiba behatárolása

Specifikáció

Hibajavítás megtervezése

Tesztesetek

Hiba kijavítás

Program újratesztelése

A regressziós tesztelés célja annak vizsgálata, hogy a hiba kijavítása során nem követtünk-e el újabb hibát. A regressziós tesztelés során elvben az összes tesztet megismételjük minden javítási lépés után. A gyakorlatban ez igen nagy ráfordítást igényelne igényelne, így csak a módosított rész és annak függőségeihez tartozó teszteseteket ismételjük meg. (Alapos teszt terv és dokumentáció szükséges ennek kivitelezéséhez)



157

A hagyományos szoftvertsztelés A tesztelési folyamat szakaszai : z Egység teszt (a rendszerkomponensek egymástól független tesztelése [tesztágy szükségessége]). z Modul teszt (az egymástól függő komponensek egységbe zárt rendszerének önálló tesztelése). z Alrendszer teszt (az alrendszert alkotó modulok egymás közötti kapcsolatának ellenőrzése [tipikus az interfész probléma]) z Rendszer teszt (az alrendszerek integrált egysége az alrendszer. l d T Tesztelése t lé során á az alapvető l tő rendszertulajdonságok vizsgálata történik). z Átvételi teszt (a rendszer tesztelése valódi adatokkal, az előre rögzített vakidációs kritériumok teljesülésének ellenőrzése).

ÓE-NIK-SZTI


158

A szoftver tesztelési folyamat Egységteszt

Modulteszt

Alrendszerteszt

Rendszerteszt

Átvételiteszt

Komponens tesztelés

Integrációs tesztelés

Felhasználói tesztelés



159

ÓE-NIK-SZTI


160

40

Szoftverek átvizsgálása

A tesztelési fázisok a szoftver folyamatban Követelmények meghatárog zása

Rendszerspecifikáció p

Átvételi teszt terve

Szolgáltatás

Rendszertervezés

Rendszerintegrációs teszt terve

Átvételi teszt

Részletes tervezés

Alrendszerintegrciós teszt terve

RendszerIntegrációs teszt

Modul és EgységKódolás, és -tesztelés

AlrendszerIntegrációs teszt




Mit vizsgálhatunk? g z Rendszermodellt, Specifikációt, z Magas szintű nyelven megfogalmazott metakódot, z Bármilyen dokumentumot, mely a szoftverfolyamat része

161

A szoftverátvizsgálás jellemzői: z Sokkal olcsóbb a tesztelésnél z Az egyes programelemek elszigetelten vizsgálhatók z Elhanyagolhatók a hibák kölcsönhatásai z A hiba detektálása közvetlenül történik (nem valamilyen rossz értékből derül ki a hiba) z Egyes vizsgálatok szerint az átvizsgálás nem csak olcsóbb, hanem hatékonyabb is mint a tesztelés z Fagan szerint egy program hibáinak 60 százaléka felderíthető átvizsgálással z Az átvizsgálás során a minőség és a szabványoknak való megfelelőség is ellenőrizhető ÓE-NIK-SZTI

A szoftver átvizsgáláshoz nem kell programot futtatni, így a fejlesztés korai szakaszában, a programok implementációja előtt, verifikációs technikaként használható. Azonban kiterjedhetnek a szoftverfolyamat bármely dokumentumára: követelmény specifikáció, vázlatos és részletes tervekre, adattervekre, teszttervekre, stb.

163

ÓE-NIK-SZTI

z z z z


162

A dinamikus viselkedés vizsgálatára, a megbízhatóság becslésére nem alkalmas az átvizsgálás Működési hatékonyság, y g, szűk keresztmetszet nem határozható meg segítségével A felhasználói felület validálása nem végezhető el az átvizsgálás során Rendszerszinten a bonyolultság miatt gyakorlatilag nem alkalmazható

ÓE-NIK-SZTI


164

41

Programátvizsgálások

Mi indokolja az átvizsgálások hatékonyságát? z Egyetlen átvizsgálással több különböző hiba is felderíthető, míg a tesztelés általában tesztenként csak egy hibát hoz ki. z A felhalmozódott tapasztalatok segítenek a kritikus részek ellenőrzésében. (Az átvizsgálást végző, rutinos szakember „tudja, hogy mit kell nézni”)

A programátvizsgálás lényege: egy különböző háttérrel rendelkező tagokból álló p a pprogram g forráskódját j gondosan, g , sorról,, sorra csoport átnézi.

Kritikus programszerkezetek: Pointeres kezelés, több kilépési ponttal rendelkező cciklusok, uso , bonyolult bo yo u t vezérlési ve é és szerkezetek s e e ete

Az átvizsgálás egy formális folyamat, melyet egy, legalább 4 főből álló team végez.

Az átvizsgálás célja a hiányosságok, hibák felderítése

Az átvizsgálás nem helyettesíti a tesztelést, hanem kiegészíti azt! ÓE-NIK-SZTI


165

Különböző szerepkörök definiáltak a csoportban Fagan szerint: – Szerző (a program vagy dokumentum elkészítésért és a hibák kijavításáért felelős) – Olvasó (felolvassa, illetve elmagyarázza a kódot vagy dokumentumot) – Tesztelő (a tesztelés szempontjából vizsgálja a kódot) – Moderátor (az átvizsgálás folyamatát szervezi, vezeti))

ÓE-NIK-SZTI


166

Az átvizsgálási folyamat Tervezés

Új verzió

Áttekintés Egyéni előkészítés

Átdolgozás

Felülvizsgálati találkozó

Grady és Van Slack, illetve Gilb és Graham egyéb funkciók bevezetését javasolták



167

ÓE-NIK-SZTI


168

42

A programátvizsgálás hatékonyságának jellemzői: z Az áttekintő szakasz során kb. 500 LOC/óra tekinthető át. z Az egyéni előkészület során kb. 125 LOC/óra vizsgálható meg z A találkozó során 90-125 LOC/óra vizsgálható át. Az AT&T-nél gyűjtött adatok szerint: z Egy 4 fős csapat 100 LOC-ot kb 1 embernapnyi ráfordítással vizsgál át. z Ha átvizsgálás helyett tesztelnének, akkor több, mint a duplája ráfordításra lenne szükség. ÓE-NIK-SZTI


169

A statikus elemzés szakaszai: 1., A vezérlés folyamatának elemzése (többszörös be, illetve kilépési ponttal rendelkező ciklusok vizsgálata, nem használt kódrészek felderítése, stb.) 2., Az adathasználat á elemzése é (inicializálás (i i i li álá nélkül élk l használt változók, kétszer ír egy változóba, de senki nem olvassa, deklarált, de fel nem használt változók felderítése) 3., Interfészelemzés (gyengén típusos nyelveknél h használható, álh tó pl.: l C C, a fü függvény é és é eljárás ljá á deklarációval, paraméterekkel, visszatérési értékekkel kapcsolatos hibákat vizsgálja) ÓE-NIK-SZTI


171

Automatizált statikus elemzés Az automatizált statikus programelemző szoftverek a program forráskódját analizálva derítenek fel hibákat, hiányosságokat. (pl: nem inicializált változók, nem h használt ált változók, ált ók a tartományon t t á túlmutató túl t tó adatértékek) d té ték k) Az automatizált statikus elemzővel felismerhető hibák: z Adathibák (inicializálás, deklarálás, rossz értékadás, stb.) z Vezérlési hibák (hibás vezérlési szerkezetek, ciklusok, gg y , eljárások, j , stb.)) nem hívott függvények, z Input/Output hibák (a típusnak nem megfelelő I/O form.) z Interfészhibák (paraméterek típusütközése, stb.) z Tárkezelési hibák (védett területre írás, stb.) ÓE-NIK-SZTI


170

4., Az információáramlás elemzése (a bemenő és kimenő változók közötti függéseket deríti fel, a programban használt értékek származtatását gyűjti ki, ami segítséget nyújthat az átvizsgálásokhoz.) 5 Útvonalelemzés 5., Ú l l é (azonosítja ( í j a program összes ö lehetséges végrehajtási útvonalát, és kigyűjti az ezeken az útvonalakon végrehajtott utasításokat.) Az automatizált statikus elemzőkre különösen azon nyelveknél van szükség, amelyek gyengén típusosak, vagy a fordítójuk kevés ellenőrzést végez. Nem helyettesíti az átvizsgálást, illetve a tesztelést, csak kiegészíti! ÓE-NIK-SZTI


172

43

Az átvételi tesztet szokás „alfa tesztnek” is nevezni. Egyedi megrendelő esetén az alfa teszt a megrendelő bevonásával történik. Nem egyedi szoftverek esetében az alfa tesztet általában egy béta teszt is követi. Átvételi teszt terve

Szolgáltatás

„béta teszt”

Rendszerintegrációs teszt terve

Átvételi teszt „alfa teszt”

3.5 Szoftverevolúció (szoftver karbantartás, szoftver követés) A hagyományos szemlélet szerint a fejlesztés és a karbantartás két élesen elkülönülő tevékenység. Az újabb felfogás szerint a kettő szerves egységet alkot és inkább a szoftver evolúciójának fogható fel.

RendszerIntegrációs teszt



173

3.5.1 A rendszer evolúciójának folyamata

ÓE-NIK-SZTI


174

4. Projekt menedzsment A projekt menedzsment fő területei:

Rendszerkövetelmények meghatározása

Meglévő rendszerek értékelése

Rendszerváltozások előterjesztése

Meglévő rendszerek

Rendszerek módosítása

Új rendszer

4.1 Projekt tervezése 4.2 Projekt ütemezése 4.3 Projekt mérése 4.4 Projekt becslése 4.5 Kockázat menedzsment, kockázat kezelés 4.6 Projekt követés és ellenőrzés 4.7 Team-szervezési megoldások



175

ÓE-NIK-SZTI


176

44

Mi a projekt? z z z z z

Projekt méretek

Jól definiált cél Előre rögzített határidő és részhatáridők Meghatározott erőforrások (költségvetés) Tervezett tevékenység Alapvető jellemzőiben egyedi

DIN 69901: „Ein Projekt ist ein Vorhaben, bei dem innerhalb einer d fi i t Zeitspanne definierten Z it ein i definiertes d fi i t Ziel Zi l erreicht i ht werden soll, und das sich dadurch auszeichnet, dass es im Wesentlichen ein einmaliges Vorhaben ist.”

ÓE-NIK-SZTI


177

Megnevezés

Résztvevők száma

Időtartam

Program nagysága

Mini projekt

1

1-4 hét

500 LOC

Kis projekt

1

11-12 hónap

1-5 KLOC

féléves feladat

Közepes projekt

2-5

1-2 év

5-50 KLOC

Compiler

Nagy p j projekt

5-100

2-3 év

50-100 KLOC

Op. rend-szer

Szuper projekt

100-1000

3-5 év

1 MLOC

Nagy Op. rendszer

Mega projekt

2000-5000

5-10 év

1-10 MLOC

SDI

ÓE-NIK-SZTI

4.1 projekt tervezése

z z

z

A megrendelő és a fejlesztő közösen meghatározzák: – a projekt céljait – a megvalósítandó rendszer fő funkcióit – kvantitatív mérőszámokat a funkciók jellemzésére Alternatív megoldási módokban állapodnak meg a tervezési tér növelése érdekében költség, határidő, erőforrás korlátok tisztázása

ÓE-NIK-SZTI


egyszerű Pascal pr pr.


178

A projekt terv típusai

A szoftver projekt előkészítése: z

Példa

z

z z z

179

Minőségi terv (a projektben használandó minőségi eljárásokat és szabványokat tartalmazza) Validációs terv (a rendszer validációhoz szükséges megközelítési módot, erőforrásokat és ütemterveket határozza meg) Konfigurációkezelési terv (a konfiguráció kezeléséhez szükséges eljárásokat és szerkezeteket tartalmazza) Karbantartási terv (a rendszer karbantartásához szükséges ük é kö követelményeket, t l é k t költ költségeket é k t ttartalmazza) t l ) Munkaerő-fejlesztési terv (a projektteam tagjainak szakmai fejlődését tartalmazza)

ÓE-NIK-SZTI


180

45

A projektterv felépítése (szakaszai)

A projektterv készítésének folyamata A projekt megszorításainak megállapítása A projekt paraméterek kezdeti értékének rögzítése A mérföldkövek és a részeredmények rögzítése while A projekt még nincs kész és „nem lőtték le” A projekt ütemtervének összeállítása Tevékenységek indítása az ütemtervnek megfelelően Várakozás A projekt előrehaladásának vizsgálata A projekt becsült paramétereinek felülvizsgálata A projekt ütemtervének frissítése A megszorítások és részeredmények újratárgyalása

1., Bevezetés Meghatározza a projekt célját, alapvető jellemzőit, g (erőforráskorlátok, ( , a menedzselés megszorításait időkorlátok) 2., Projekt szervezet Megadja a projekthez rendelt team vagy teamek összetételét, a tagok szerepköreit, feladataikat, felelősségüket 3., Kockázatelemzés Számba veszi a lehetséges projekt kockázatokat, elkerülésükhöz szükséges stratégiákat, bekövetkezésük esetén szükséges tevékenységeket.

if probléma merül fel Műszaki felülvizsgálat és átdolgozás

ÓE-NIK-SZTI


181

4., Hardver és szoftver erőforrás követelmények Rögzíti, hogy a fejlesztéshez pontosan milyen hardver és szoftver eszközökre van szükség. Amennyiben ezeket be kell szerezni, úgy tartalmazza a költségbecslést is. 5., Munka felosztása Tartalmazza a projekt tevékenységekre bontását az egyes tevékenységekhez tartozó részeredményekkel és mérföldkövekkel együtt. 6., Projekt ütemterve Megadja az egyes tevékenységek közötti függőségeket, a mérföldkövek eléréséhez szükséges becsült időt, valamint a tevékenységekhez rendelt becsült emberi erőforrásokat. 7., Figyelési és jelentéskészítési mechanizmusok (projekt követés és ellenőrzés) Meghatározza a menedzser által elkészítendő jelentéseket, azok leadási idejét, valamint az alkalmazandó projekt követési, ellenőrzési technikákat).

ÓE-NIK-SZTI


183

ÓE-NIK-SZTI


182

Mérföldkövek a projektben z z

z z

A mérföldkövek alkalmazása egy eszköz a projekt követésére. A mérföldkövek tipikusan a projekt egyes szakaszainak végét jelzik (esetenként ritkább, máskor sűrűbb bontásban). A mérföldkövekhez jelentések (report) tartoznak A mérföldkövek kapcsolódhatnak belső részeredményekhez, vagy külső, leszállításra kerülő részeredményekhez (pl: specifikáció, stb.)

ÓE-NIK-SZTI


184

46

Mérföldkövek a követelményspecifikáció folyamatában Tevékenységek

Megvalósíthatósági vizsgálat

Követelmény elemzés

Prototípus fejlesztés

Tervtanulmány

Követelmények meghatározása

Megvalósít Megvalósíthatósági jelentés

Felhasználói követelmények

Értékelési É jelentés

Szerkezeti terv

RendszerRendszer követelmények


Mérföldkövek


185

A projekt ütemezés folyamata Tevékenységek azonosítása

Szoftver követelmények

ÓE-NIK-SZTI


Ökölszabályok: Ö z Ha a tevékenység 8-10 hetet meghaladna, szét kell bontani z Mindig tervezzünk tartalékot a nem várt problémákra (3050%) ÓE-NIK-SZTI


186

Oszlopdiagramok (Tevékenység diagramok) z Tartalmazza az adott tevékenység felelősét (munkavégzőjét) és a tevékenységek kezdési és befejezési időpontjait

Erőforrások becslése a tevékenységekhez

I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002

Az ütemezéshez ismerni kell: z A tevékenység egységeket z Időigényüket z Erőforrásigényüket z Függőségeiket z A folyamatok, részfolyamatok sorrendiségeit z A párhuzamosítható tevékenységeket z Egyéb korlátokat, illetve peremfeltételeket

A projekt ütemterv ábrázolásának lehetőségei

Tevékenységek függőségi viszonyainak azonosítása

Emberek tevékenységekhez rendelése

4.2 Projekt ütemezése

Projektdiagrammok készítése

Tevékenységhálók z A tevékenységek közötti függőségeket ábrázolja

Tevékenység- és oszlopdiagrammok 187

ÓE-NIK-SZTI


188

47

A tevékenységhalmazból generált tevékenységháló:

Példa a projekt ütemtervre Adott egy projekt tevékenységhalmaza:

Tevékenység

(T-tevékenység, M-mérföldkő)

Időtartam (nap)

Függőségek

T1

8

T2

15

T3

15

T4

10

T5

10

T2, T4 (M2)

T6

5

T1, T2 (M3)

T7

20

T1 (M1)

T8

25

T4 (M5)

8 nap T1 T1(M1)

99/7/4

T3

99/7/25

5 nap

M3

T6

M2

T5

M6 T11 99/9/5

99/8/11 M7

M8 15 nap

10 nap

T10

15

T3, T6 (M4)

99/7/18

T5, T7 (M7)

M5

T11

7

T9 (M6)

T12

10

T11 (M8)

T12

25 nap T8

Vég

A kritikus út jelölése

99/9/19



189

ÓE-NIK-SZTI

A tevékenységhalmazból generált tevékenységdiagram 8/15

99/8/25 7 nap

10 nap

15

8/8

T9

M4

99/7/25

T9

7/11 7/18 7/25 8/1

99/8/4

T7

T2

10 nap T4

15 nap

20 nap

T10

ÓE-NIK-SZTI

8/22 8/29

9/5

Le ehetséges késés

Kezd. T4 T1 T2 M1 T7 T3


7/4

7/11 7/18 7/25 8/1

M6

9/12 9/19

T11

T3 T9

Anne

T10

9/5

T12

M2

M7

8/22 8/29

T1 Jane

T9

8/15

T8

M3 T6 T5

8/8

T4 Fred

M5 T8

M4

190

A munkatársak lekötöttsége az idő függvényében

9/12 9/19

tevékenyység

I. Sommerville: Szoftve errendszerek fejlesztése, Panem, 2002

15 nap

M1

15 nap

Kezdet


7/4

99/7/14

T2 T6

T10

T7

Jim Mary

T5

T11 M8 T12 Vég ÓE-NIK-SZTI


191



192

48

Egy hagyományos szoftver projekt ütemezése

mérföldkő ÓE-NIK-SZTI

. . .

. . .

. . .

. . .

. . .

. . .

terv áttekintés

. . .

követelmény áttekintés

. . .

analízis

. . .

szerkezeti- és adat tervezés

egység teszt

. . .

egység terv kódo- kód áttervezés bejárás lás tekintés

teszt tervezés

teszteljárás tervezés

példa:

integrációs teszt

validációs teszt

Adott 4 fejlesztő 5KLOC/év kapacitással Ha egy csoportban dolgoznak -> 20 KLOC/év !!! Ebből lejön azonban a kommunikációs veszteség, ami 250 LOC/év !! (4x5000) - (6x250) = 18500 4625 LOC/fő Ha hozzáadunk még két embert a csoporthoz: (6x5000) - (15x250) = 26250 4375 LOC/fő

tesztterv áttekintés


Az emberi erőforrások ütemezésének kérdése

193

ÓE-NIK-SZTI


194

A projektidő alakulása a résztvevők számának függvényében

Az összefüggés nem lineáris! Nem érdemes csoportban dolgozni !? Érdemes mert: z sokszor a projekt méretei miatt nem is lehet másként megoldani z jobb a minőség és a megbízhatóság mint a „magányos farkasok” esetében z nem fog mindenki, mindenkivel „beszélgetni”

Projekt idő 1 elmélet (kommunikáció nélkül) gyakorlati tapasztalat járulékos kommunikáció

Brooks törvénye Ha egy elcsúszott projekthez plusz embert rendelsz, az tovább fog csúszni !

1

Prof. Dr. F. P. Brooks

2

4

8

Résztvevők 16 száma

(az IBM-360 és az OS/360 Projektmenedzsere) ÓE-NIK-SZTI


195

ÓE-NIK-SZTI


196

49

4.3 Projekt mérése Ütemezési módszerek: z PERT (Program Evaluation and Review Technique) z CPM (Critical Path Method)

A szoftver mérése a szoftver mint termék, illetve a szoftver készítési folyamat szignifikáns jellemzőinek számszerűsítésével foglalkozik (szoftver metrikák). A szoftver metrikák lehetnek: z Vezérlési metrikák (a szoftver folyamattal kapcsolatosak, pl: hibák száma, ráfordítások, idők) z Prediktor metrikák (a szoftver termékkel kapcsolatosak pl: a modul ciklomatikus komplexitása) kapcsolatosak,

Lehetővé teszik: z kritikus út meghatározását z a feladatok legvalószínűbb g idő-ütemezését z idő-ablakok meghatározását (legkorábbi, legkésőbbi befejezés / kezdés, indítási idő-intervallumok)

ÓE-NIK-SZTI


A vezetői döntéshozatalt mindkét típus befolyásolhatja 197

ÓE-NIK-SZTI


198

A mérések kategorizálása A mérés célja

Mennyire közelíti meg a specifikációt a termék

A mérések több célt szolgálhatnak:

A termelési folyamat értékelése

A termék mérése esetén z a termék minőségének értékelése A folyamat mérése esetén z az alkalmazott módszerek, eszközök hatékonyságának értékelése z a fejlesztők termelékenységének elemzése z a következő projektek becslési fázisához bázis-értékek kialakítása, a meglévő értékek javítása ÓE-NIK-SZTI


Modularitás foka, logikai komplexitás, stb.

199

Mennyiségi és minőségi adatok közvetlen gyűjtésén és kiértékelésén alapuló módszer Közvetett mérési módszer elvonatkoztatott l tk t t tt szempontok alapján (hipotetikus változók bevezetése). A fejlesztők véleményének értékelésén alapuló módszer. ÓE-NIK-SZTI

Műszaki jellemzők mérése Minőség mérése Termelékenység mérése Méret-orientált mérési módszerek Funkció-orientált mérési módszerek Ember-orientált mérési módszerek Szoftver Tervezés és Technológia

200

50

Méret-orientált mérési módszer

KLOC Termelékenység =

Közvetlen mérési módszer, a mérés tárgya az elkészült termék és a készítés folyamata. Projekt neve

Ráfordítás [ember/év]

Költség [ezer$]

KLOC

A

30

141

11

B

70

200

C

40

.

.

.

ÓE-NIK-SZTI

.

Hibák száma

Részt Résztvevők száma

500

19

4

30

1500

61

8

155

21

700

5

6

.

.

.

.

.

.

Doku. Doku [oldal]

.

.

.


Ráfordítás Hibák száma Minőség = Ráfordítás Költség Fajlagos költség = KLOC Doku Fajlagos doku =

.

KLOC

201

ÓE-NIK-SZTI


202

Funkció--orientált mérési módszer Funkció A „LOC számolása” helyett a szoftver funkcionalitása kerül előtérbe. A módszer alkalmas a komplexitás kezelésére.

A módszer jellemzői: z

mennyiségi mérőszámokon alapuló egyszerű módszer (oldalak száma, száma sorok száma, száma emberek száma száma, stb stb.))

( ) Albrecht: Function Point Method (1979)

z

nem igényel tapasztalatot, szaktudást a kiértékelés

A Function Point (FP) valamilyen számszerűsíthető jellemzőből származtatható.

z

nem veszi figyelembe a komplexitást, a szoftver sajátosságait

z

Tipikus jellemzők, melyeket a módszer alapul vesz: felhasználói inputok száma (adat) z felhasználói f lh álói outputok t t k száma á (adat) ( d t) z felhasználói interakciók száma (vezérlés) z fájlok száma z külső interfészek száma (pl.: hálózat) z

csak azonos típusú projektek összehasonlítására, becslésére használhatók fel a mérőszámok

ÓE-NIK-SZTI


203

ÓE-NIK-SZTI


204

51

A módszer lépései:

2., A komplexitás értékelése

1., A számértékeket tartalmazó táblázat kitöltése. Jellemzők

Szám

Súlyfaktor

Érték

Egyszerű

Átlagos

Komplex

Felhasználói inputok száma

3

4

6

Felhasználói outputok száma

4

5

7

Felhasználói interakciók száma

3

4

6

Fájlok száma

7

10

15

Külső interfészek száma

5

7

11

Példák a komplexitást kifejező tényezőkre: z Mennyire szükséges üzembiztos mentés? z Mennyire szükséges az osztott feldolgozás? z Mennyire legyen a kód újrafelhasználható? (lásd: Jones, C.: Programming Productivity, McGraw-Hill, 1986.)

Teljes összeg ÓE-NIK-SZTI


Módszer: 14 kérdésre adandó 0..5 értékű, osztályzat jellegű válasz összege adja a SUM(Fi), a komplexitást kifejező tényezőt. tényezőt (max. (max érték = 70)

205

ÓE-NIK-SZTI

3., A táblázat és a válaszok alapján FP meghatározása


206

Költség Fajlagos költség =

FP= [Teljes összeg] x [0.65 + 0.01 x SUM(Fi)] A komplexitástól függően a [teljes összeg] 0.65 ... 1.35 te módosulhat. ódosu at -tel

FP Doku F jl Fajlagos doku d k = FP

FP Termelékenység =

Jellemzők: z adat alapú, ami azért előnyös, mert az adatok a fejlesztés korai szakaszában már ismertek, míg a LOC csak a végén z programozási nyelv független z részben szubjektív z a LOC alapúval szemben az értékelés szaktudást, tapasztalatot igényel

Ráfordítás Hibák száma Minőség = Ráfordítás

ÓE-NIK-SZTI


207

ÓE-NIK-SZTI


208

52

Objektum--orientált mérési módszer Objektum

z

Az OO projektek esetén is alkalmazható pl. az FP alapú mérési módszer. Pontosabb mérési módszerre tett javaslatot: Lorenz, M., Kidd, J : Object J.: Object-oriented oriented Software Metrics Metrics, Prentice Prentice-Hall, Hall 1994 z

Javasolt paraméterek: z A szcenáriók száma (a felhasználó és az alkalmazás közti interakciókat írják le – erősen korrelál az alkalmazás méretével) z Kulcs osztályok száma ( az OO analízis korai szakaszában már definiált, erősen független osztályok – korrelál a számuk a rendszer kifejlesztéséhez szükséges ráfordítással, a szükséges tesztesetek számával ÓE-NIK-SZTI


209

z

Támogató osztályok száma (nem tartoznak közvetlenül a rendszer probléma specifikus funkcióihoz pl. UI osztályok, szerviz osztályok – számuk jó indikációt ad a rendszer kifejlesztéséhez szükséges ráfordításra, és a g reuse lehetőségére A kulcs osztályokat támogató osztályok átlagos száma GUI alkalmazás esetén a támogató/kulcs osztály arány 2-3, nem GUI alkalmazás esetén 1-2 (mivel a kulcs osztályok már az analízis korai fázisában ismertek, így következtethetünk a teljes alkalmazás méretére Alrendszerek száma – a rendszer komplexitásának jó indikátora

ÓE-NIK-SZTI

Use--CaseUse Case-orientált mérési módszer

210

4.4 Projekt becslése

Coming soon … ? … ! C

Potenciális előnyök a use-case-ek metrikákban történő felhasználása esetén: z A szoftver folyamat korai szakaszában rendelkezésre állnak z A rendszer funkcionalitását (legalább a felhasználó oldaláról) jól jellemzik z Programozási nyelvtől, környezettől függetlenek z Számuk arányos a rendszer nagyságával és a szükséges tesztesetek számával Problémák ami miatt még nincs széleskörű használat: Problémák, z A use-casek mérete, bonyolultsága – nem szabványosított, – erősen függ az alkalmazott absztrakciós szinttől z


A becslés tárgya: z ráfordítás z költség z időtartam A becslést nehezítő tényezők: z a projekt nagysága, komplexitása z Időkorlát z erőforráskorlát z emberi (mennyiségi, minőségi) z hardver (speciális egységek: analizátor, stb.) z szoftver eszközök

Nehéz megadni a use-case / ráfordítást ÓE-NIK-SZTI


211

ÓE-NIK-SZTI


212

53

Dekompozíción alapuló technikák Mindegyik technika alapja a bonyolult, nagy rendszer szétbontása kezelhető részekre. A kiindulás minden g számszerűsített esetben a feladat vázlatos,, lehetőleg leírása (scope).

A becslési technikák csoportosítása: Dekompozíción alapuló technikák • LOC vagy FP orientált • ráfordítás becslés z Tapasztalati becslési modellek z

I. LOC vagy FP orientált technikák lépései: A., Meghatározzuk az egyes modulok LOC-ját (három értéket adunk meg: optimista, valószínű, pesszimista)

ÓE-NIK-SZTI


213

optimista + 4 x valószínű + pesszimista E= 6 C., Kitöltjük a táblázatot

A

LOC

Számított érték

optimista

valószínű

pesszimista

1800

2000

2500

Számított LOC

Becsült Ft/LOC

Becsült LOC/hó

Költség [Ft]

Ráfordítás [ember-hó]

A

2050

800

270

1.640.000

7.6

B

983

1200

75

1 179 600 1.179.600

13 1 13.1

C

6166

700

300

4.316.200

20.5

D

1233

1500

110

1.849.500

11.2

8.985.300

52.4

2050

B

700

1000

1200

983

5000

6000

8000

6166

D

900

1200

1700

1233

Összeg

214

Modul neve

Összeg

C

ÓE-NIK-SZTI


D., Meghatározzuk a becsült költség és ráfordítás értékeket

B., Képezünk modulonként egy súlyozott átlagot

Modul neve

ÓE-NIK-SZTI

Az eltérő súlyok a különböző modultípusok komplexitáskülönbségeit fejezik ki. Az értékek az előző projektek méréseiből származnak és projektenként finomíthatók.

10432 Szoftver Tervezés és Technológia

215

ÓE-NIK-SZTI


216

54

II. Ráfordítás becslés A módszer jellemzői: z z z z

A LOC orientált részletesebb,, finomabb felbontást igényel, Az FP orientált nagyobb, komplexebb egységeket képes kezelni. A módszer nagy tapasztalatot, jó „érzéket” kíván, hiszen a projekt elején tényszámok nincsenek, A becslésnél nagy a bizonytalanság. bizonytalanság

ÓE-NIK-SZTI


217

Módszer: Egy „rutinos öreg róka” megbecsüli az egyes tevékenységek ember-hónap ráfordítás igényeit minden modul esetében. A kii kiindulás d lá ennél él a módszernél ód él is i a projekt j kt vázlatos á l t leírása. l í á Modul

Tevékenységek ráfordításai [ember-hó]

Összeg

neve

Analízis

Tervezés

Kódolás

Tesztelés

A

1.5

2.5

0.5

3.5

8

B

2

5

1

4

12

C

3

8

1

8

20

D

2

4

0.5

3.5

10 50

Összeg

8.5

18.5

3

19

Fajlagos ktg. [eFt]

300

200

60

120

Költség [eFt]

2.550

3.900

180

2.280

ÓE-NIK-SZTI


8.910 218

Tapasztalati becslési modellek A módszer jellemzői: z z z z

A különböző komplexitású modulok különböző súllyal szerepelnek Az egyes tevékenységek súlyozása eltérő Igen nagy rutint igényel (indirekt becslés), jól kell ismerni a rendszer típusát és a fejlesztőcsapatot Jól használható az előző módszer kontroljaként

Jellemzőik: z Általában méretből indul ki z Tartalmaz exponenciális komponenst a méret – komplexitás viszony kifejezésére z Az algoritmus miatt nem okvetlenül pontos a becslés, nagyban függ a paraméterek jó becslésétől z általános formája: Projekt nagyságát fejezi ki (tipikusan 1 .. 1,5)

Munka = A x

méretB

A forrássorok száma Ráfordítás ÓE-NIK-SZTI


219

ÓE-NIK-SZTI

xM Folyamat-, termék-, és fejlesztési jellemzők

A helyi szervezetet, illetve a fejlesztett szoftver típusát jellemzi Szoftver Tervezés és Technológia

220

55

A becslési bizonytalanság

A COCOMO modell

4x

COCOMO = Constructive Cost Model Barry Boehm: Software Engineering Economics, Prentice Hall,, 1981

2x

x

Megvalósíthatóság

Követelmények

Tervezés

Kód

Átadás

0 5x 0,5x

X – a munkahónapok száma

0,25x

ÓE-NIK-SZTI

Jellemzői: z Jól dokumentált z Szabadon hozzáférhető z Széles körben használt z Hosszú ideje használt, több verziót fejlesztettek ki, sok tapasztalat halmozódott fel


221

ÓE-NIK-SZTI


222

A COCOMO 81 A COCOMO projektosztályai:

Jellemzői: z Feltételezi a vízesés modell alapú fejlesztést z A szoftver túlnyomó többsége még nem létezik A modell szintjei: Model-1 (alap COCOMO) Egyszerű, egyváltozós modell, a sorok számán alapszik. Model-2 (középszintű COCOMO) A LOC LOC-on on kívül szubjektív költségtényezők határozzák meg a ráfordítást. Model-3 (fejlett COCOMO) A Model-2 jellemzőit a szoftver technológia fázisaira (analízis, tervezés, stb.) szétbontva határozza meg. ÓE-NIK-SZTI


223

Kis méretű projekt projekt, j , egyszerű gy feladat,, kis team,, Relatív kis méretű p jól felkészült szakemberek Közepes méretű projekt Közepes bonyolultságú feladat, közepes méretű projekt, vegyes összetételű team. Nagy méretű projekt B Bonyolult l l hardver h d körülmények kö ül é k kö között, ö kényszer-feltételek mellett fejlesztendő projektek (pl.: légi -irányítási rendszer)

ÓE-NIK-SZTI


224

56

COCOMO Model-2

COCOMO Model-1

E = ab x (KLOC) bb ahol:

E = ai x (KLOC)bi x EAF

D = cb x (E) db

Projekt mérete

ab

bb

cb

db

ki kis

24 2.4

1 05 1.05

25 2.5

0 38 0.38

közepes

3.0

1.12

2.5

0.35

nagy

3.6

1.20

2.5

0.32

ÓE-NIK-SZTI

ahol: E - ráfordítás [ember-hónap] EAF - költség befolyásoló tényezők

E - ráfordítás [ember-hónap] [ember hónap] D - a projekt időtartama [naptári hónap]


Költség befolyásoló tényezők: Termék jellemzők z Igényelt szoftver megbízhatóság z Felhasznált adatbázis mérete z A termék bonyolultsága 225

Hardver jellemzők z Run-time kényszerfeltételek z Memória kényszerfeltételek z Virtuális gép kényszerfeltételek z Igényelt válaszidő korlátok Személyi jellemzők z Analizáló szakember kapacitás igény z Szoftver technológus szakember kapacitás igény z Alkalmazói gyakorlat z Virtuális gép gyakorlat z Programozási nyelv gyakorlat P j k jellemzők Projekt j ll ők z Szoftver tool-ok használata z Szoftver technológiai módszerek használata z Igényelt fejlesztési ütemezés ÓE-NIK-SZTI


ÓE-NIK-SZTI


226

Kiértékelés: 1., mind a 15 kérdésre egy 6 fokozatú skála segítségével 2., táblázat alapján EAF megállapítása (tipikusan: 0.9-1.4) Együtthatók:

Projekt mérete kis

227

ai

bi

32 3.2

1 05 1.05

közepes

3.0

1.12

nagy

2.8

1.20

ÓE-NIK-SZTI


228

57

A COCOMO 2 modell azonosított szintjei:

A COCOMO 2

z

Jellemzői: z z

z z

Elismeri a szoftverfejlesztés különböző szemléleteit (prototípus készítés, komponens alapú fejlesztés, 4GL, stb) A modell szintjei itt már nem a becslések részletesebbé válását jelentik A szintek a szoftverfejlesztési j folyamat y tevékenységeihez kapcsolódnak

z

Korai prototípuskészítési szint ( a méretet objektumokkal becsli, a ráfordítás mértéke méret/termelékenység képlettel számítható ki.) Korai tervezési szint (a rendszerkövetelményekhez y kezdeti tervezetet készítünk. A becslések valamilyen funkciópontokon alapulnak, amelyet a forráskód sorainak számává alakítunk át. A képlet alakja marad az egységes formátumú, a szorzóknak egy egyszerű halmaza kapcsolódik hozzá) Posztarchitekturális szint (a rendszer architekturájának elkészülte után már aránylag pontos becslés tehető a szoftver méretére. Itt a becslések már több szorzót tartalmaznak ezekkel a személyi kapacitások, tartalmaznak, kapacitások a termék és a projekt jellemzői fejezhetők ki.) Részletesebben lásd a Sommerville könyvben!



229

4.5 Kockázat menedzsment, Kockázatkezelés Mi a kockázat?

ÓE-NIK-SZTI

z

Projektkockázat (kihatással van a teljes projektre pl: erőforrások rendelkezésre állása, ütemterv betartása, költségvetés tartása, kollégák kiválnak a projektből, vezetőségváltás)

z

Termékkockázatok (kihatással van a fejlesztés alatt álló termék minőségére, teljesítményére, pl.: fejlesztőeszköz elégtelensége, elvárások jelentős változása)

z

Üzleti kockázatok ((a szoftver fejlesztését j végző g szervezetre hat ki, pl: konkurens termék kerül a piacra, megváltozik a cég stratégiája, technológiaváltás)

Mi a „haszna” és az „ára” a kockázat kezelésnek? „If you don’t actively attack the risks, they will actively attack you”

230

A kockázati kategóriák csoportosítása (kockázat típusok):

Hogyan jellemezhetjük? Érdemes-e vele foglalkozni?


Tom Gilb ÓE-NIK-SZTI


231

ÓE-NIK-SZTI


232

58

A kockázatkezelés folyamata és dokumentumai

A kockázatkezelés fázisai: 1., Kockázat azonosítás (a lehetséges kockázatok közül meghatározza a valószínű kockázatokat) 2., Kockázat elemzés (megbecsüli a kockázat bekövetkezésének valószínűségét és kihatását) 3., Kockázat tervezés (intézkedési tervek készítése a kockázat csökkentésére, illetve a teendőkre a bekövetkezésének esetére)

Kockázat azonosítás

Kockázat elemzés

Kockázat tervezés

Potenciális kockázatok listája

Sorrendbe állított kockázatok listája

Kockázat elkerülésiés vészhelyzeti tervek

Kockázat figyelés

Kockázat becslése

4., Kockázat figyelés (állandó monitorozás és terv revízió) I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 ÓE-NIK-SZTI


233

ÓE-NIK-SZTI

Kockázat azonosítás Cél:

cél:

Módszer: checklist alkalmazása

a potenciális kockázatok vizsgálata két szempontból: - bekövetkezésének valószínűsége - következményei

A kockázat elemzés lépései:

Eredmény: Potenciális kockázatok listája Példák kockázatokra: Műszaki-, technológiai-, emberi-, szervezeti-, hardver-, eszköz-, követelmény-, becslési kockázat


234

Kockázat elemzés

kiválasztani a lehetséges kockázatok közül a potenciális kockázatokat.

ÓE-NIK-SZTI


235

z

A bekövetkezés valószínűségének számszerűsítése (alkalmazható skálák: bináris, minőségi, mennyiségi)

z

A bekövetkezéskor fellépő következmények leírása

z

A kockázat kihatásának becslése

z

A kockázat elemzés pontosságának megfogalmazása ÓE-NIK-SZTI


236

59

A kihatás mértéke lehet: z jelentéktelen, z elviselhető, z jelentős, z súlyos, z katasztrofális

237

Kidolgozandó a kockázat elkerüléséhez szükséges stratégiák, és a bekövetkezésekor elvégzendő teendőket tartalmazó tervek. Kockázat elkerülési stratégiák: azon tevékenységeket és megszorításokat tartalmazza, melyek segítségével csökkenteni igyekszünk a kockázat bekövetkezésének valószínűségét. (pl: bizonytalan elemek lecserélése g ) megbízhatóra) Kockázat minimalizációs stratégiák: célja a kockázat bekövetkezésekor, annak kihatásának csökkentése (pl: redundanciák, átfedések, tartalékok beépítése) Szoftver Tervezés és Technológia

katasztrofális

sűrű

Kockázat tervezés

ÓE-NIK-SZTI

súlyos

p közepes

ÓE-NIK-SZTI


238

Vészhelyzeti tervek: a kockázati veszélyeztetettség fokára vonatkozó referencia szinteket, a kockázat bekövetkezésekor szükséges teendőket, a helyzet megoldásához tartalékolandó erőforrások leírását tartalmazza. Csúszás mérttéke


jelentős s

ritka

A bekövetkezés gyakorisága lehet: z ritka z közepes z sűrű ÓE-NIK-SZTI

elviselh hető

jelenték ktelen

Melyikre lehet felkészülni?

Veszélyes terület

Pillanatnyi érték Túlköltés mértéke 239

ÓE-NIK-SZTI


240

60

Kockázat figyelés, (követés) Általános szabály:

A teljes projekt során szükséges tevékenységek: z z z z

az azonosított kockázatok bekövetkezési valószínűségének figyelése A kockázat elkerülési terv végrehajtásának ellenőrzése Szükség esetén a tervek módosítása Kockázati esemény bekövetkezése esetén vészhelyzeti terv végrehajtása, hatás ellenőrzése

A kockázatmenedzsment költsége ideális esetben a projekt költségvetésének g 3-5 százaléka. Ha a kockázat menedzsment költsége eléri a projektköltség 15 százalékát, akkor meg kell gondolni, hogy szükséges-e egyáltalán (a kockázat menedzsment, vagy a projekt maga)

Nagy projektek esetén az azonosított kockázatok száma: 30-40 (felkészülés, erőforrás tartalékolás drága) ÓE-NIK-SZTI


241

ÓE-NIK-SZTI

Célja: a projekt előrehaladásának figyelemmel kísérése a sikeres befejezés érdekében. A projekt követés alapja a tervezés során elkészült ütemezés é és é az abban elhelyezett mérföldkövek. é f Vilfredo Pareto (1848-1923) olasz közgazdász, statisztikus, egyetemi tanár

A Pareto 80/20-as szabály y alkalmazása a kockázat menedzsmentre A projekt alatt bekövetkező kockázatok 80%-át lefedi az előzetesen becsült kockázat 20%-a. ÓE-NIK-SZTI


242

4.6 Projekt követés és ellenőrzés

Pareto 80/20-as szabálya Alkalmazása a z A hagyományos j Projektmenedzsmentben z A modern projektmenedzsmentben z A bürokráciában


243

Módszerei: rendszeres „status report meeting” (pl. minden hétfőn) z a projektbe beiktatott review-ok kiértékelése z „mérföldkövek” elhelyezése a projektben z a feladatok indítási idejének ellenőrzése, összehasonlítás a tervezett értékkel z informális meeting-ek a „local guru-kkal” z

ÓE-NIK-SZTI


244

61

4.7 TeamTeam-szervezési megoldások Ezen módszerek egymással párhuzamosan is használatosak.

„Kell egy csapat !”

Irányítás: z ha minden rendben, rendben akkor minimális tevékenység z ha probléma merül fel: – helyzetfelmérés, erőforrás felmérés – intézkedési terv kidolgozás – esetleges projekt átütemezés

Hogyan menedzseljem?

(Sándor Pál: Régi idők focija, Minarik Ede, mosodás, a Csabagyöngye C b ö SC M Menedzsere) d )

Hogyan szervezzem?

Hogyan fejlesszem?

ÓE-NIK-SZTI


245

ÓE-NIK-SZTI

Jellemzői

Jellemzői:

z

z z z z

A programozás á „hőskorára” hő k á ” jjellemző ll ő Az átlagos programozók egy kiváló képességű, vagy autokrata egyéniségű programozó (vezető) keze alá dolgoztak Nem volt tervezés (feladat szétbontás, integrálás, stb.) mindent a vezető döntött el Az ő képességei határozták meg a program minőségét Fejletlen információs rendszer (gyakorlatilag nincs) A dokumentáció gyakran utólag készül

z z z z z z

ÓE-NIK-SZTI

246

Homogén csoport elv

Géniusz elv

z



247

Ap programozás g egy gy későbbi fázisára jjellemző Az elv, hogy nem kell vezető a csoportba (demokratikus működés: a csoport minden tagja egyenrangú) Döntéseket közösen hoztak, a modularizálást közösen végezték el A programozás egyénileg történt, az integrálásnál jött az „integrációs BUMM” A modulok „személyesek” a teljes program személytelen Az információs rendszer nem fejlett, információ áramlás nincs

ÓE-NIK-SZTI


248

62

Horizontális szervezési elv

z

Jellemzői z

z

z

A programozási, programtervezési módszerek fejlődésével kialakult a specializálódás specializálódás, szakosodás (külön tervező szakember, külön programozó szakember, stb.) A programozás egyes részfeladataira tehát specializált csoportok rendszere alakult ki: – rendszertervezők, rendszerszervezők – programozók * – kódolók * – tesztelők

z

A feladatot mindegyik csoport a saját szempontjai szerint feldolgozza és továbbítja az alatta lévő szintekre Fejlett információs rendszer és információ továbbítás Az egyes csoportok közötti kapcsolat pontosan szabályozott Csoportok

szintek i t k

A *-gal jelölt csoportok minden munkánál, illetve szoftverháznál megtalálhatók, míg a többi esetleges ÓE-NIK-SZTI


249

VezetőprogramozóVezetőprogramozó-csoport elv

ÓE-NIK-SZTI


250

A vezetőprogramozó-csoport felépítése Szakemberek

Jellemzők: z Az igen jó képességű programozók hatékonyságának növelése érdekében magas szintű kiszolgálásuk z A csoportot egy három tagú mag alkotja, amelyhez időlegesen kapcsolódnak egyéb szakemberek z Dinamikus, a feladathoz jól illeszkedő struktúra

A vezetőprogramozó-csoport magja Adminisztrátor Vezető programozó

Eszköz létrehozója

Tartalék programozó

Operációsrendszer-specialista Könyvtáros

Nyelvspecialista Tesztspecialista

Külső kapcsolat I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 ÓE-NIK-SZTI


251

ÓE-NIK-SZTI


252

63

Nagyvállalati projekt menedzsment

Portfolió menedzsment:

EPM – Enterprise Project Management

A portfolió menedzsment a projektek azonosításának, fontossági sorrendbe állításának és beruházásának y , amely y a vállalati stratégiával g állandó folyamata, összehangoltan történik. Az üzleti feltételek és a költségvetések változásakor az „agilis” vállalatok proaktívan értékelik és kiigazítják a portfóliót úgy, hogy a kockázattűrésükkel összhangban optimális megtérülést érjenek el. A portfoliójukat bölcsen kezelő vállalatok megalapozott kompromisszumokat kötnek a projektek között, között és erőforrásaikat megfelelően átirányítva biztosítják, hogy csak olyan tevékenységekre fordítsanak időt, amelyek a végcélhoz szükségesek. www.microsoft.com/hun ÓE-NIK-SZTI

www.microsoft.com/hun Szoftver Tervezés és Technológia

253


254

Együttműködés és kommunikáció:

Erőforrás menedzsment: Az egyének jelentik a szervezet legértékesebb és gyakran a legdrágább tőkéjét. Ez elengedhetetlenül fontossá teszi a megfelelő személyek rendelését a megfelelő f l lő projektcsapatokhoz, j k kh h hogy a termelékenység lék é költség hatékony módon a lehető legnagyobb legyen. A csapat képzettségi adatainak és rendelkezésre állásának teljes körű ismerete szükséges a szervezet munkaportfoliónak megfelelő stratégiai erőforráskölcsönzést, - fejlesztést és - felállítást végezni.

www.microsoft.com/hun ÓE-NIK-SZTI

ÓE-NIK-SZTI

A lehető legnagyobb mértékű koordinálás és részvétel a jobb termelékenység érdekében A hatékony együttműködés és kommunikáció alapvető a projektek sikeréhez. sikeréhez Világos kommunikációs folyamatok révén a csoport tagjai megoszthatják tudásukat, együtt készíthetik el a feladatokat és a leadandó anyagokat, gyorsan igazodhatnak a változásokhoz. A projektekben részt vevő csoportok tagjai egyre távolabb vannak egymástól szervezeti és földrajzi értelemben is; ez veszélyezteti a termelékenységet, é olyan és l ttechnológiát h ló iát ttesz szükségessé, ük é é amii értelmesen kapcsolja össze a csoporttagokat a koordináció és a minőség fenntartása érdekében. www.microsoft.com/hun


255

ÓE-NIK-SZTI


256

64

Projektmenedzsment Termékek és szolgáltatások szállítása esetén is a szervezetnek be kell tartania a projektek határidejét és költségvetését. Az ügyfelek elégedettségének fenntartása és elvárásainak teljesítése megköveteli, hogy ne legyenek hibák és késések. A versenyképességhez a vállalatok növekvő mértékben tesznek kezdeményezéseket a projektek folyamatos javítására a ciklusidők rövidítése, a költségek leszorítása és a g révén. Mindehhez szakképzett p minőségellenőrzés egyének, szabványos folyamatok és magas szintű technológia szükséges, hatékony projektmenedzsment irányításával.

5. Unified Modeling Language 5.0 Bevezetés 5.1 Az UML fogalma 5.2 Történeti áttekintés 5.3 Az UML jellemzői 5 4 Az UML kritikája 5.4 5.5 Az UML építőkövei 5.6 Diagramok

www.microsoft.com/hun ÓE-NIK-SZTI


257

ÓE-NIK-SZTI


258

A programozási nyelvek fejlődése

5.0 Bevezetés Objektum Orientált programozási nyelvek (OOP)

Objektum orientált tervezés (OOD)

j orientált analízis ((OOA)) Objektum

Objektum orientált analízis és tervezés (OOAD) www.oose.de ÓE-NIK-SZTI


259

ÓE-NIK-SZTI


260

65

Jelentősebb OO módszertanok 1.

a figyelembe vett komponensek:

Coad-Yourdan: OO analízis és tervezés (OOAD), (1991)

Jellemzője: z szerényebb eszközrendszerrel rendelkező, z több szintű, több komponensű fejlesztési módszertan

z z z

az alkalmazott szintek: z osztály & objektum z struktúra z szegmens (subject) z attributum z szolgáltatás (service) ÓE-NIK-SZTI

z


261

probléma-terület probléma terület humán interakció feladat (task) menedzsment adat menedzsment

ÓE-NIK-SZTI


262

2. WirfsWirfs-Brock et al., Responsibility Driven Design

A Coad Coad--Yourdan OOAD vázlata

Jellemzői: z

Szolgáltatás

ÓE-NIK-SZTI

Adat me enedzsment

Attribútum

Feladat enedzsment me

Szegmens

Humán interakció

Struktúra

Prob bléma terület

Osztály és objektum

z

z


263

Új szemléletű módszer, melyre jellemző az antropomorph megközelítés. A rendszert egymással együttműködő és „szövetkező” objektumok (ügynökök) alkotják, melyek gy jól j meghatározott g funkció és felelősségg mindegyikéhez kötődik. Az objektumok közti kommunikációt „szerződések” (contract) rögzítik.

ÓE-NIK-SZTI


264

66

Class Responsibility Card Osztálynév

3. Jacobson: ObjectObject-Oriented Software Engineering (OOSE) (1992)

Absztrakt / konkrét

Ős osztályok Utód osztályok Felelősségek

A módszer öt modellt használ az analízis és tervezés fázisaiban:

Együttműködés

z z z z z ÓE-NIK-SZTI


265

követelmény modell analízis modell tervezési modell implementációs modell teszt modell

ÓE-NIK-SZTI


266

Use Case példa Use Case alapú megközelítés:

z

felhasználók azonosítása s erepek meghatározása szerepek meghatáro ása interakciók számbavétele

z

rendszer viselkedésének

z z

Értékesítés

Panasz főnök Érdeklődés ügyfél Rendelés

eladó ÓE-NIK-SZTI


267

ÓE-NIK-SZTI


268

67

4. Booch: ObjectObject-Oriented Design (OOD) (1991) A rendszer statikus leírására használt diagrammok: z Osztálydiagram z Objektumdiagram z Moduldiagram z Folyamatdiagram A dinamikus viselkedés leírására használt diagramok: Á Állapotdiagram z Időzítésdiagram (Timing diagram) z

ÓE-NIK-SZTI


269

A BoochBooch-féle OOD felépítése

logikai nézet

osztály struktúra objektum struktúra

fizikai nézet

modularchitektúra folyamatarchitektúra

ÓE-NIK-SZTI

5. Rumbaugh: Object Modeling Technique (OMT)


270

Objektum modell

J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen: Object-Oriented Modelling Technique Prentice-Hall Internat., 1993

RENDSZER

A rendszert három különböző nézetből három modell képezi le. z Objektum modell z Dinamikus modell z Funkcionális F k i áli modell d ll

Funkcionális modell ÓE-NIK-SZTI


271

ÓE-NIK-SZTI

Dinamikus modell


272

68

Az OO módszertanok fejlődése

Az Objektum modell a rendszer struktúráját, szerkezetét ábrázolja. – Osztály diagramm – Objektum diagramm A Dinamikus modell a rendszer viselkedését képezi le. – Szcenárió – Esemény diagramm – Állapotátmenet ábra A funkcionális modell a rendszer funkcionalitását reprezentálja. – Adatfolyam diagramm

www.oose.de ÓE-NIK-SZTI


273

ÓE-NIK-SZTI


274

5.1 Az UML fogalma

Az UML fogalma

„The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems. It is a general-purpose modeling language that can be used with all major object and component methods, and that can be applied to all application domains (e.g., health, finance, telecom, aerospace) and implementation platforms (e (e.g., g J2EE, .NET).”1

„A A Unified U ifi d Modeling M d li Language L ( (egységes é modellező d ll ő nyelv) rendszerek elemeinek specifikálására, megalkotására és dokumentálására szolgáló vizuális nyelv. Általános célú modellező nyelv, amely minden nagy objektum és komponens alapú módszerrel használható bármely alkalmazási területen (pl. egészségügy, pénzügy, telekommunikáció, légi i á í á ) és irányítás) é implementációs i l á ió platformon l f ( l J2EE, (pl. J2EE .NET).”1

1. Unified Modeling Language (UML) Specification: Infrastructure v2.0 (www.omg.org)

1. Unified Modeling Language (UML) Specification: Infrastructure v2.0 (www.omg.org)

ÓE-NIK-SZTI


275

ÓE-NIK-SZTI


276

69

A kialakulás időrendje

5.2 Az UML keletkezése

Év

z Alapvetően három módszer egységesítéséből egységesítéséből, összedolgozásából alakult ki: • Grady Booch: Booch Methode (BOOCH) • Jim Rumbaugh: Object Modeling Technique (OMT) • Ivar Jacobson: Object-Oriented Software Engeneering (OOSE)

Esemény

1994 október 1994. któb

Booch és Rumbaugh módszerének egyesítése

1995. október

Unified Method 0.8 Jacobson csatlakozik,

1995. ősz

z Közreműködött az Object Management Group (OMG), az objektum-orientált szakma legjelentősebb szervezete

Fejlesztés kezdete:

módszerét integrálják

1997. jjanuár

UML 1.0

1997. szept./1998…

UML 1.1/ UML 1.2 …

2005.

UML 2.0

2008. ÓE-NIK-SZTI


277

ÓE-NIK-SZTI

5.3 Az UML jellemzői

z z z

z

Hamar de-facto de facto szabvánnyá vált A szoftveripar domináns modellező nyelvévé emelkedett Széles körben sikerrel alkalmazzák az egészségügytől az e-kereskedelemig S él kö ű együttműködés Széleskörű ütt űködé eredménye d é több vezető cég között: pl. Hewlett-Packard, IBM, Microsoft, Oracle, Unisys…

ÓE-NIK-SZTI


278

Célok az UML tervezésénél z

z

2.2 Szoftver Tervezés és Technológia

z z z z z

279

A gyakorlatban jól használható, vizuális, kifejező modellező nyelv kialakítása A modell bővítését és specializálását p lehetővé tevő mechanizmusok biztosítása a nyelvben Programozási nyelvtől és fejlesztési módszertől független legyen Formális alap biztosítása a modellező nyelv megértéséhez Az OO alapú CASE eszközök piacának növekedését ösztönzése Magasabb szintű fejlesztési koncepciók támogatása A létező legjobb technikák integrálása

ÓE-NIK-SZTI


280

70

5.4 Az UML kritikája

Az UML alapvető tulajdonságai z z z

z z

Modellező nyelv, nem fejlesztési módszertan Grafikus szemléletet nyújt Lehetővé teszi szoftver-intenzív rendszerek specifikálását, konstruálását, vizualizálását és dokumentálását Munkafolyamatok, szervezetek, üzleti tevékenységek stb. leírására is alkalmas A gyakorlatban jól használható egyedi, osztott vagy konkurens rendszerek kezelésére

z

Dagályos nyelvezet – Diagramok közötti redundancia – Aligg használt diagramok g

z

Tanulási és megértési problémák

z

A jelölésrendszerek általános problémája

– Sokan használják, de kevesen értik igazán – Bizonyos rendszerek (itt OOP) jobban kifejezhetők, mint mások – A fejlesztő j hajlamos j az UML logikáját g j inkább követő megoldásokat választani z

Nehézkes átjárhatóság más modellezési technikákkal

Wikipdia, the free encyclopedia, Unified Modeling Language, 2009. szeptember 10. ÓE-NIK-SZTI


281

ÓE-NIK-SZTI

5.5 Az UML építőkövei

The UML Things

• Elemek z z z

Strukturális Viselkedési Annotációs Csoportos

Structural

Use Case Class Interface Component Node …

• Kapcsolatok z z z

282

Az UML építőkövei

Az UML szókincse három fő kategóriába sorolható, amelyek tovább bonthatók: z


Függőségi Asszociációs (társítási) Generalizációs (általánosítási, öröklődéssel kapcsolatos)

Behavioral

Relationships

Groupings

Interaction Package State machine Model Subsystem Framework

Annotational

Note

Diagrams

Use Case Dependency Class Association Generalization Sequence Statechart Activity …

• Diagramok … Ivar Jacobson, G. Booch, J. Rumbaugh: The Unified Software Development Process, Addison Wesley Longman, 1999 ÓE-NIK-SZTI


283

ÓE-NIK-SZTI


284

71

Kapcsolatok z z

5.6 Diagramok

A modellelemek közötti kapcsolatokat testesítik meg. F jtái Fajtái:

z

– Függőségi (Dependency) z z

z

Egyik elem változása hatással van a másik elemre Jele: szaggatott nyíl

– Asszociáció, társítás (Association) z z

z

Strukturális, szerkezeti összefüggés Jele: egyenes vonal

– Generalizáció (Generalization) z z

ÓE-NIK-SZTI

A modellben lévő információ grafikus g reprezentálása A szoftvert különböző nézőpontból és változó absztrakciós szinten láttatja Két fő csoportja: • Struktúrát modellező diagramok • Viselkedést modellező diagramok

Általános-speciális kapcsolata, öröklődés Jele: üres háromszög fejű nyíl Szoftver Tervezés és Technológia

Struktúra diagramok z A modell statikus architektúráját definiálják z A „dolgokat” írja le, amelyből a modell felépül z Időtől független elemek z Pl. • Osztálydiagram • Komponensdiagram

285

Dinamikus diagramok z A rendszer objektumainak dinamikus viselkedését mutatja z Az interakciók változatosságát ragadja meg z Időbeli változások sorozataként írható le z Pl. • Használati eset diagramja • Aktivitásdiagram

ÓE-NIK-SZTI


286

A diagramok osztályozása az Diagram UML 2.22.2-ben Structure Diagram

Class Diagram

Component Diagram

Composite Structure Diagram

Behavior Diagram

Object Diagram

Deployment Diagram

Activity Diagram

Package Diagram

Profile Diagram


287

ÓE-NIK-SZTI

State Machine Diagram

Interaction Diagram

Sequence Diagram Communication Diagram

ÓE-NIK-SZTI

Use Case Diagram

Timing Diagram

Interaction Overview Diagram


288

Wikipdia, the free encyclopedia, Unified Modeling Language, 2009. szeptember 10.

72

5.6.1 Áttekintés

Áttekintés - UML

Feladat:1 Liftek vezérlésének logikája többszintes épületben a következő megkötésekkel: z Minden liftnek szintenként egy gombja van. van A gomb megnyomásra világít, és megáll az adott emeleten. A világítás megszűnik, ha megállt a lift az emeleten. z A legfelső és a legalsó emeleten egy, a többin két gomb található az utazási irány megadására. A gombok megnyomásra kigyulladnak. Elalszanak, amikor egy lift megáll a kívánt emeleten, és a megfelelő irányba folyatatja az útját. z Amikor nincs hívás, akkor a lift az emeleten marad zárt ajtóval.

z z

Az UML egy modellező nyelv, amely a szemantikát és a jelölést határozza meg. Az analízishez a következő diagramokat használjuk: • Use Case diagram • Osztálydiagram

z

A tervezésnél az alábbiakat használjuk: • Szekvenciadiagram • Részletes osztálydiagram

1. http://www.geocities.com/SiliconValley/Network/1582/uml-example.htm 2005. okt. ÓE-NIK-SZTI


289

Áttekintés - Use Case diagram z

z

z

A rendszer használatának általános leírása Áttekintést ad a rendszer tervezett működéséről Laikus és szakember számára egyaránt érthető

ÓE-NIK-SZTI


Áttekintés – Osztálydiagram Az osztálydiagram megmutatja: •A rendszer statikus struktúráját

Lift

Lifthívás

Lift

vezérlés

Lift_Vezerlo

Ajtó

- kommunikál vele

Gomb világít/nem

*

•A belső struktúráját

Használó


vezérlés

1

Lift elindul/megáll

Gomb

•Kapcsolatait

Ajtó nyitás/zárás

Lift_Gomb

ÓE-NIK-SZTI

290

291

ÓE-NIK-SZTI


Szint_Gomb 292

73

Áttekintés – Részletes osztálydiagram

Áttekintés Szekvenciadiagram Lift_Gomb Lift_Vezérlő Lift szemlélteti AzUtas objektumok közötti üzenetváltások időbeli menetét GombNyomás

vezérlés

Lift világít : boolean szint : int

Ajtó

Zár ( ) Nyit ( )

- kommunikál vele Mozgás

* Gomb

SzintElérés Állj

világít : bool... VilágításBe ( ) VilágításKi ( ) Státusz ( )

Nyit

Zár

Lift_Gomb

Szint_Gomb

szintSzám : int

ÓE-NIK-SZTI


293

ÓE-NIK-SZTI

z z z z z z z z z

szintSzám : int irány : boolean


294

Diagram

5.6.2 Package Diagram z

Csomagdiagram (Package) Használati eset diagramja (Use Case) Osztálydiagram (Class) Objektumdiagram (Object) Szekvenciadiagram (Sequence) Kommunikációs diagram (Communication) Állapotdiagram (Statechart) Akti á ió diagram Aktivációs di (Activity) (A ti it ) Komponensdiagram (Component) Telepítési diagram (Deployment)

Structure Diagram

Class Diagram

Component Diagram


Behavior Diagram

Object Diagram

Deployment Diagram

Activity Diagram

Package Diagram

Profile Diagram


295

ÓE-NIK-SZTI

Use Case Diagram

Sequence Diagram



Interaction Diagram

Communication Diagram ÓE-NIK-SZTI

Ajtó zárva : boolean

1

VilágításBe

VilágításKi

vezérlés

szintAzon : int pozíció : int irány : boolean

Mozog ( ) Megáll ( ) Státusz ( )

Frissít

Lift_Vezerlo

Timing Diagram


296

74

Package Diagram

Package

Jellemzői: z A rendszert a legmagasabb absztrakciós szinten bontja fel z A logikailag összetartozó UML elemeket (főleg osztályok) csoportosítja z A csomagok között függőségi kapcsolatokat (pl. egyik elem a másikban változást idéz elő, üzenetküldés) ábrázolja Megjegyzés z A csomagok egymásba ágyazhatók z Jelölés: négyszög füllel z A csomag megfelelője Java környezetben a package, .NET környezetben a namespace ÓE-NIK-SZTI


297

Példák - Bolt Rendszer Rendelések

P a c k a g e D i a g r a m

Levlista UI

ÓE-NIK-SZTI

Példák - Színház Ütemezés

Jegypénztár

Ügyfélnyilvántartás

Jegyeladás

P a c k a g e

Jegynyilvántartás

Ü Üzemeltetés é

Beszerzés

Könyvelés

Bérezés

Rumbaugh, Jacobson, Booch: The Unified Modeling Language Referene Manual, 2004 ÓE-NIK-SZTI


P a c k a g e

Levlista Kezelo


298

D i a g r a m

TK Példa

Tervezés

Nyilvánosság

Vevok

299

D i a g r a m

Egy meteorológiai térkép rendszernek meteorológiai térképeket kell előállítania, távoli, felügyelet nélküli meteorológiai állomásoktól és egyéb adatforrásoktól, például p léggömböktől gg és műholdaktól mint összegyűjtött adatok alapján. A meteorológiai állomások adataikat egy körzeti számítógép kérésére megküldik a kérelmező gépnek. A körzeti számítógépes rendszer ellenőrzi a begyűjtött adatokat és integrálja a különböző adatforrásokból érkező adatokat. Az integrált adatokat archiválja és az archívum, valamint egy digitalizált térképadatbázis alapján létrehozza a helyi meteorológiai térképeket. térképeket A térképek egy speciális célú térképnyomtatón kinyomtathatók, majd szétoszthatók, vagy számos más módon megjeleníthetők. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 ÓE-NIK-SZTI


300

75

TK Példa - A meteorológiai térképrendszer alrendszerei z

«subsystem» Data display

«subsystem» Data collection Observer

5.6.3 Use Case Diagram z

Satellite

User interface

Map display

z

Comms

z Map

Weather station

Balloon

«subsystem» Data processing

Data checking

Map printer

«subsystem» Data archiving

Data storage

Data integration

Map strore

ÓE-NIK-SZTI

P a c k a g e

Data strore


301

Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002

D i a g r a m

z z z z z z


ÓE-NIK-SZTI

Diagram

Component Diagram


Deployment Diagram

Activity Diagram

Package Diagram

Profile Diagram


ÓE-NIK-SZTI

Use Case Diagram



Interaction Diagram

Timing Diagram


Eszköz a rendszer elvárt működésének specifikálásához z Tipikusan a követelmények feltárására használják: z

Behavior Diagram

Object Diagram

302

Use Case Diagram

Structure Diagram

Class Diagram


303

U s e

• Mi az, amit a rendszernek tudnia kell z

Kulcsfogalmak: • • • •

C a s e

Aktor (Actor) Használati esetek (Use Cases) Tárgy (Subject) Kapcsolatok (Connection)

ÓE-NIK-SZTI


304

D i a g r a m

76

A tárgy

Az aktor Felhasználók és más rendszerek, amelyek kapcsolatba lépnek a rendszerrel z Mindig a rendszeren kívül van z Szerepet definiál z Nem feltétlenül fizikai entitás z Jelölése: z

A rendszer maga, maga olyan szempontból, szempontból ahogy a használati esetek alkalmazzák z Jelölése: egy téglalap, melynek határa a rendszer határa z

ÓE-NIK-SZTI


Használati eset z z z

305

z

D i a g r a m

C a s e

Jelölése: ellipszis

ÓE-NIK-SZTI


307

C a s e

• Pálcikaember • Osztályként • Egyéb ikonnal, ami nem emberi voltára utal ÓE-NIK-SZTI


306

Kapcsolatok

Leírás

Jelölés

Association

A kommunikáció útja az aktor és használati eset között

Egyenes vonal vagy nyíl

Extend

Két használati eset között meghatározza a speciális, kiterjesztett viselkedés idejét és mikéntjét.

Szaggatott nyíl a kiterjesztéstől az alap felé.

Include

Két használati eset között. A tartalmazott eset az alap egy kiemelt része. része

Szaggatott nyíl az alap-tól a tartalmazott felé.

Generalization

Általános használati esetből vagy aktorból származik egy specifikusabb.

Folytonos nyíl üres háromszögű fejjel.

U s e

Aktorokkal működik együtt Speciális esetei:

U s e

D i a g r a m

Kapcsolatok

A rendszer ajánlott viselkedését írja le Nem utal a belső struktúrára Eredménye:

• Alapviselkedés variációja (include) • Kivételes viselkedés, hibakezelés (extend) z

C a s e

Use Case

• Megváltozik a rendszer állapota • Kommunikáció a környezettel z

U s e

Customer

D i a g r a m

ÓE-NIK-SZTI


U s e

308

C a s e D i a g r a m

77

Példák kapcsolatokra

Példák kapcsolatokra Include

Asszociáció

U s e C a s e

Extend

ÓE-NIK-SZTI


309

D i a g r a m

Példák – Place Order

U s e C a s e

Generalizációk

ÓE-NIK-SZTI


310

D i a g r a m

Áruvásárlás katalógusból

«extend» Rendelés

Katalógus igénylése

«include» «include»

«include» Fieztés

Vevoadatok felvitele

U s e

U s e

C a s e

C a s e

D i a g r a m

D i a g r a m

Termék megrendelése

KP-s fizetés

Kártyás fizetés

Unified Modeling Language (UML) Specification: Infrastructure v2.0 (www.omg.org) ÓE-NIK-SZTI


311

ÓE-NIK-SZTI


312

78

Use Case Diagram

Kiterjesztési pont (Extension point) point)

Use Case Diagram

Példák - ATM használat

•

Az extend kapcsolat minden kiterjesztett használati esethez tartalmaz egy kiterjesztési pontot

z

Meghatározza azt a pontot, ahol a viselkedés bizonyos feltételinél a használati eset kiterjeszthető egy másik használati esettel.

•

A feltételt és a kiterjesztési pontot az extend kapcsolathoz jegyzetként kell hozzácsatolni (Note Attachment). (UML 2.x-ben) Rumbaugh, Jacobson, Booch: The Unified Modeling Language Referene Manual, 2004 ÓE-NIK-SZTI


313

ÓE-NIK-SZTI


314

A számosság kifejezése az UML--ben (multiplicitás) UML

Példák - Iskola

Pontosan 1 1 U s e

0..1

C a s e

Megjegyzés: nyíllal jelölt asszociációk, a hatás irányát mutatják http://www.agilemodeling.com/artifacts, 2005. október ÓE-NIK-SZTI


315

D i a g r a m

0 * 0..*

1..*

ÓE-NIK-SZTI

Pontosan 1 Feltételes (0 vagy 1) F ltét l (d Feltételes (de több is i lehet) Legalább egy (de több is lehet)


316

79

Példák – ATM rendszer «subsystem» ATM rendszer

1 1 Ü Ügyfél 1

0..1

Pénzkivét Átutalás

0..1

0..* 0..* 1

0..1

Admin

1 Bank

Pénzbefizetés ATM regisztrálása a banknál

0..1

U s e

1

0..*

1 1

TK Példa

1

0..*

C a s e

Log olvasása 0..1

Megjegyzés: a számok a számosságot jelölik, a keret a tárgy határát Unified Modeling Language (UML) Specification: Infrastructure v2.0 (www.omg.org) ÓE-NIK-SZTI


317

D i a g r a m

TK Példa – A meteorológiai állomás használati esetei „A meteorológiai g állomás külső entitásokkal működik együtt az indítás és a leállítás, az összegyűjtött meteorológiai adatokból való jelentéskészítés, valamint a műszerek tesztelése és kalib-rálása céljából.”

Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 ÓE-NIK-SZTI

z z

Indítás

z z

Leállítás

U s e

Jelentéskészítés

???



318

5.6.4 Class Diagram

C a s e

Kalibrálás

Tesztelés

ÓE-NIK-SZTI

Egy meteorológiai térkép rendszernek meteorológiai térképeket kell előállítania, távoli, felügyelet nélküli meteorológiai g állomásoktól és egyéb gy adatforrásoktól,, mint például léggömböktől és műholdaktól összegyűjtött adatok alapján. A meteorológiai állomások adataikat egy körzeti számítógép kérésére megküldik a kérelmező gépnek. A körzeti számítógépes rendszer ellenőrzi a begyűjtött adatokat és integrálja a különböző adatforrásokból érkező adatokat. Az integrált adatokat archiválja és az archívum, valamint egy digitalizált térképadatbázis alapján létrehozza a helyi meteorológiai térképeket. térképeket A térképek egy speciális célú térképnyomtatón kinyomtathatók, majd szétoszthatók, vagy számos más módon megjeleníthetők.

319

D i a g r a m

z z z z z z


ÓE-NIK-SZTI


320

80

Diagram

Class diagram

Structure Diagram

Class Diagram

Component Diagram


Object Diagram

Deployment Diagram

Activity Diagram

Package Diagram

Profile Diagram

Use Case Diagram State Machine Diagram

Interaction Diagram

A modell (egy részének) statikus nézetét írja le z Objektumorientált bj k i l rendszer d építőelemeit l i mutatja z A rendszer osztályait és a közöttük lévő kapcsolatokat írja le z

Behavior Diagram

Gomb

Sequence Diagram

világít : bool...

Timing Diagram

VilágításBe ( ) VilágításKi ( ) Státusz ( )

Lift_Gomb




321

ÓE-NIK-SZTI


Window

Osztály UML-es szóhasználat:

Jelölés: három részből álló téglalap C l a s s

Láthatóságok: + public, - private, # protected, ~ package

ÓE-NIK-SZTI


Window + size : Area = (100,100) # visibility : Boolean = invisible + default-size : Rectangle # maximum-size : Rectangle - xptr : XWindow

Window Osztályszimbólum y részletek nélkül

+ display ( [inout] location : Point ) + hide ( ) + create ( ) - attachXwindow ( [inout] xwin : Xwindow )

– Név rész – Attribútum rész (opcionális) – Operátor rész (opcionális) z

322

D i a g r a m

Osztályok

+ display ( [inout] location : Point ) + hide ( )

– Attribútumok A ibú k – Operátorok z

Szint_Gomb szintSzám : int irány : boolean

szintSzám : int

+ size : Area + visibility : Boolean

z

C l a s s

323

D i a g r a m

Window display ( ) hide ( ) create ( ) attachXwindow ( )

Részletes osztálydeklaráció Jelölések: egyenlőségjel: kezdőérték

Osztálydeklaráció attribútumokkal

aláhúzás: osztályszintű operátor



324

C l a s s D i a g r a m

81

Az osztályok meghatározásának menete z z z z z

TK Példa Egy gy meteorológiai g térkép p rendszernek meteorológiai g térképeket kell előállítania, távoli, felügyelet nélküli meteorológiai állomásoktól és egyéb adatforrásoktól, mint például léggömböktől és műholdaktól összegyűjtött adatok alapján. A meteorológiai állomások adataikat egy körzeti számítógép kérésére megküldik a kérelmező gépnek. A körzeti számítógépes rendszer ellenőrzi a begyűjtött adatokat és integrálja a különböző adatforrásokból érkező adatokat Az integrált adatokat archiválja és az archívum, adatokat. archívum valamint egy digitalizált térképadatbázis alapján létrehozza a helyi meteorológiai térképeket. A térképek egy speciális célú térképnyomtatón kinyomtathatók, majd szétoszthatók, vagy számos más módon megjeleníthetők.

A leírásból (scope) válasszuk ki a főneveket. Szűrjük ki az egyértelműen nem a rendszerhez tartozó, csak az érthetőséget javító főneveket Szűrjük ki a szinonimákat, rokon értelmű főneveket. Keressünk rejtett főneveket (a szövegben explicite nem szerepel de a kultúrából következik) szerepel, Az így kapott jelöltekből válasszuk ki a rendszert alkotó objektumokat.



325

ÓE-NIK-SZTI

TK Példa - Osztályok WeatherStation

Interface

airTemperatures gournTemperatures windSpeeds p windDirections pressures rainfall

reportWeather ( ) calibrate lib t ( ) test ( ) startup ( ) shutdown ( )

z

collect ( ) summarise ( )

GroudThermometer temperature test ( ) calibrate ( )

Anemometer windSpeed windDirection test ( )

z C l a s s

Barometer pressure height test ( ) calibrate ( )



326

D i a g r a m

IÉlo

WeatherData

identifier


C l a s s

327

D i a g r a m

z

Operációk halmazát adja meg, melyet más osztályok megvalósítanak Az interfészt megvalósító osztály és az interfész között realizációs kapcsolat van Jelölés: – Osztályjelölés + <> sztereotípia – Kör

A dőlt betűs operátor- és osztálynevek az elem absztrakt voltát jelölik. ÓE-NIK-SZTI


C l a s s

IÉlo

Személy

328

D i a g r a m

82

Shape - x : int - y : int

Generalizációs kapcsolat Az öröklődést fejezi ki z Általános és specifikus osztály kapcsolata z

ÓE-NIK-SZTI

Circle

Polygon

- radius : int

- numSide : int

- tulaj : string - egyenleg : forint

C l a s s Vállalkozói számla


329

D i a g r a m

Könyvtári tagok osztályhierarchiája

Lakossági számla - hitelkeret : forint

ÓE-NIK-SZTI

- ügyintézo : string


Könyv

Kölcsönzo

C l a s s

kölcsönzött tételek max. kölcsönözheto

Alkalmazott osztály irodai telefon

Tanuló fo címszavak otthoni cím

Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 Szoftver Tervezés és Technológia

330

D i a g r a m

Hangfelvétel g

szerzo kiadás publikáció dátuma ISBN

beírtakozás ( ) kiírtakozás ( )

ÓE-NIK-SZTI

Vállalkozói számla

Példa többszörös öröklésre

KönyvtáriTag

Olvasó

C l a s s

+ befizetés ( [in] mennyit : forint ) + pénzkivétel ( [in] mennyit : forint )

név cím telefon tagsági szám

belépés

Operátornál kettőspont után a visszatérési érték van

Számla

Számla

Lakossági számla

Jelölés:

+ display ( ) : void

331

D i a g r a m

beszélo idotartam rögzítás dátuma

C l a s s

Hangos Könyv szalagok



332

D i a g r a m

83

Asszociációs kapcsolat Két osztály összekapcsolása z A legáltalánosabb reláció z Nyíllal jelölhető a navigálhatósága: z

Munkaállomás

*

Akárhány munkaállomás használhatja a nyomtatót, fordított ismertség nincs

Nyomtató

– A nyíl irányában ismeri az egyik a másikat

Multiplicitás jelöli, hogy hány példány vehet részt a kapcsolatban, az p az 1 alapértelmezett z Az objektumok szerepét a kapcsolaton jelölhetjük z

ÓE-NIK-SZTI


Tanár

C l a s s

333

D i a g r a m

Kettőnél több osztály között fennálló kapcsolat esetén az osztályokat rombusszal kapcsoljuk össze

ÓE-NIK-SZTI

járatszám : int indulásiIdo : DateTime repülésiIdo : minutes indulás : string érkezés : stirng

Repülogép 0..*

- repülo

- gépek

- létrehozás : DateTime + frissítés ( )

ÓE-NIK-SZTI

Számla - túllépettSzámlák - tulaj : string 0..* - egyenleg : forint 0.. + befizetés ( [in] mennyit : forint ) + pénzkivétel ( [in] mennyit : forint )


Tantárgy


334

D i a g r a m

A kapcsolatra vonatkozó információkat tartalmaz z Osztályként adható meg, szaggatott vonallak kapcsolódik az asszociációhoz z Az osztálynak attribútumai vannak z

- ID : string - típus : string

+ megérkezett ( )

HitelkeretTúllépésÉrtesítés

C l a s s

Asszociáció megadása osztállyal

Repüloút -

Hallgató

335


Részvénytársaság

*

- tulajdonos

- tulajdon

*

C l a s s

Befekteto

Részvény Mennyiség



336

D i a g r a m

84

Cég

*

- alkalmazzásban áll

- alkalmaz

0..*

Munka

Repüloút járatszám : int indulásiIdo : DateTime repülésiIdo : minutes indulás : string érkezés : stirng

fizetés

GyakoriUtas 0..*

- utas VezetékNév : string 0..* KeresztNév : string Azonosító : string

- út

Alkalmazott

0..1 - fonök

- beosztott *

Irányít

megérkezett ( )

C l a s s

kmJóváírás AlapKm p : integer g BónusKm : integer

http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/nov03 /t_modelinguml_db.pdf 2005. október ÓE-NIK-SZTI


337

D i a g r a m

A beosztott-főnök viszony két ember munkája közötti kapcsolat, nem egyszerűen két ember közötti kapcsolat, ezért ez egy asszociáció az asszociációs osztályon. Rumbaugh, Jacobson, Booch: The Unified Modeling Language Referene Manual, 2004 ÓE-NIK-SZTI

z z

Az asszociáció egyik formája z Az egyik osztály alárendeltje a másiknak z Tartalmazó-tartalmazott viszony, a tartalmazott túlélheti a tartalmazót z

z z C l a s s

Levél e é

1 Cím

ÓE-NIK-SZTI

* 1 Törzs



338

D i a g r a m

Kompozíciós kapcsolat

Aggregációs kapcsolat

*

C l a s s

A fizetés nem lehet a cég vagy az alkalmazott attribútuma, mert sok-sok kapcsolat van közöttük. A kapcsolat attribútumának kell l lennie. i

339

D i a g r a m

z

Az aggregáció erősebb formája A részek életciklusa egybeesik a tartalmazóéval Egy objektum csak egy tartalmazóhoz tartozhat A tartalmazó objektum felelős a részek létrehozásáért és megsemmisítéséért Osztott aggregáció:

C l a s s

– olyan ol an aggregáció, aggregáció ami nem kompozíció kompo íció – a tartalmazók osztozhatnak a részeken

ÓE-NIK-SZTI


340

D i a g r a m

85

Fiók

Window 1

# név : string # emailCím : string

1

1

- title 0..1

2

Slider

- body

Header

1

Névjegy

C l a s s


# név : string # elsodlegesElérés : string # tag - emailCím : string - faxSzám : string

Panel

A kompozíció p definíciója j jjól kötődik az automatikus szemétgyűjtés (garbage collection) fogalmához. Ha a tartalmazó objektum megsemmisül, a részre mutató is megsemmisül, és a rész elérhetetlenné válik, a szemétgyűjtő hatáskörébe kerül, visszaállítani lehetetlen.


341

D i a g r a m

Ügyfél

ÓE-NIK-SZTI

z

számla

z 1..* - részletek

szám típus pu lejáratiIdo Hitelesítés ( )

pénzmen

név bankID ba

mennyiség adóStátusz adó áu

Hitelesítés ( )

RészösszegSzámítás ( ) SúlySzámítás ( )

ÁruCikk 0..1

szállításiTömeg leírás á ÁrMegadás ( ) SúlyMegadás ( )

http://bdn.borland.com/article/0,1410,31863,00 2005. október ÓE-NIK-SZTI


# Szülo

C l a s s

http://www.sparxsystems.com.au/resources/tutorial alapján 2005. október

z

RendelésiAdatok

# név : string

+ Gyerek 0..*

A kompozíció tartalmazást, illetve tulajdonlást fejez ki a két osztály között. Például a névjegy értékeit tartalmazza a névjegyalbum.

z

Á ÁfaSzámolás ( ) ÖsszSzámolás ( ) ÖsszSúlySzámolás ( )

Csekk

0..*

Csoport

Az aggregáció mutatja, hogy a fiók használja a névjegyalbumot, de nem feltétlenül tartalmaz belőle példányt.

z

dátum 0..* státusz 1..*

+ csoportTagság


342

D i a g r a m

5.6.5 Object Diagram

Rendelés

név cím

0..* + csoport

Megjegyzés:

Összefoglalás - Rendelés

Készpénz

+ album

# név : string - tulaj

Megjegyzés:

Kártya

NévjegyAlbum

# album

0..* - névjegyek

- scrollbar

Fizetés

+ tulaj

343


z z z z z


ÓE-NIK-SZTI


344

86

Diagram

Structure Diagram

Object diagram

Behavior Diagram

z Class Diagram

Component Diagram


Object Diagram

Deployment Diagram

Activity Diagram

Package Diagram

Profile Diagram

Use Case Diagram

Sequence Diagram

ÓE-NIK-SZTI


Interaction Diagram

Communication Diagram Szoftver Tervezés és Technológia

z

z

345

ÓE-NIK-SZTI

z

Objektum vagy az osztály neve aláhúzva

– Attribútum rész z

középpont = (0,0) csúcsok = ((0, 0), (4, 0), (4, 3)) szegélySzín = fekete kitöltőSzín = fehér

Értékekkel

A metódusok (operációk) feltűntetésére nincs szükség, hiszen azok minden objektumban azonosak.

ÓE-NIK-SZTI



Osztálydiagram

Hasonlít az osztálydiagramok ábrázolásához Két része van: háromszög : Poligon – Névrész

O b j e c t

– Link: az asszociáció egy példánya

Objektumok jelölése z

z z

Timing Diagram


z

Objektum: egy osztály egy példánya Objektumdiagram: objektumokat és azok kapcsolatait mutatja egy adott pillanatban A rendszer adott időben vett állapotát reprezentálja Az objektum minden attribútumának van értéke Az objektum összeköttetésben áll más objektumokkal

347

346

D i a g r a m

Példa

Főiskola

Hallgató

-név : string -kurzusSzám : int -cím : string +...()

-név : string -azonosító : int -kor : int +...()

Az osztálydiagram egy lehetséges objekumdiagramja

O b j e c t

O b j e c t

D i a g r a m

D i a g r a m

ÓE-NIK-SZTI


348

87

Példa 2.

5.6.6 Sequence Diagram z

Osztálydiagram

z Az osztálydiagram egy lehetséges objekum-diagramja objekum diagramja

: Bank

bori : Személy

ábel : Személy

csilla : Személy

vezetéknév = Sóskuti utónév = Borbála házas = igen születésiIdő = 80/05/21

vezetéknév = Varga utónév = Ábel házas = nem születésiIdő = 76/07/31

vezetéknév = Csepregi utónév = Csilla házas = nem születésiIdő = 85/12/23

szakértő1 : Munka

menedzser : Munka

cím : string = szakértő belépés = 2005/07/23 fizetés : int = 220000

cím : string = menedzser belépés = 2000/01/01 fizetés : int = 350000 nagyéstársakft : Cég

z z

eladó : Munka cím : string = eladó belépés = 2005/01/31 fizetés : int = 150000

olcsóbolt : Cég

név = Nagy és Társa Kft társasági forma = kft

név : string = Olcsó Bolt társasági forma = bt

http://universalis.elibel.tm.fr/pub/instances/mars/Bank/imabers/bnkInstances.gif 2005. november ÓE-NIK-SZTI

z

ügyfél

ügyfél

ügyfél


349

O b j e c t D i a g r a m

z z z z z


ÓE-NIK-SZTI


350

Diagram

Sequence Diagram Structure Diagram

Class Diagram

Component Diagram


Behavior Diagram

Object Diagram

Deployment Diagram

Activity Diagram

Package Diagram

Profile Diagram


ÓE-NIK-SZTI

Use Case Diagram



Interaction Diagram

Timing Diagram


Viselkedési, interakciós diagram z Az A objektumok bj kt k interakcióit i t k ióit mutatja t tj az idő függvényében z Elemei: z

351

S e q u e n c e

– Objektumok, melyek részt vesznek az interakcióban – A ki kicserélt él üzentekk sorozata z

Explicit mutatja az időt, de nem jelöli az osztályok kapcsolatát

ÓE-NIK-SZTI


352

D i a g r a m

88

Jelölés z

Telefonhívás

Függőlegesen jelenik meg az idő

hívó

– Életvonal: az objektum időben való létezését jelenti – Aktivációs életvonal: az objektumhoz kapcsolódó műveletek hajtódnak végre z z z z

VonalatAd()


: Recepció

353

EllenőrizElérhetőSzobákat

FoglalásKérés() ElőjegyezSzobára() Create() : Foglalás ÁrKalkuláció() AjánlatTétel() FeltételekElfogadása() FizetésKérés() Fizetés()

Szo obafoglalás

SzabadSzobák()

ElőjegyezSzobára() FoglalásVéglegesítése()

ÓE-NIK-SZTI


http://government.popkin.com/images/umlsequencediagram.gif 2005. november

355

Kij l iAC ö é t() KijelziACsörgést()

Csörget() KagylótFel()

Megszakít()

Megszakít()

ÓE-NIK-SZTI


ÓE-NIK-SZTI


S e q u e n c e

SzabadSzobákKérés

Foglalható szobák()

Irányítás()

D i a g r a m

: Szoba

S e q u e n c e D i a g r a m

S e q u e n c e

D i a g r a m

354

D i a g r a m

Elektronik kus tételek k kiadása (S ommerville e) Sommerville

: Vendég

hívott

SzámotTárcsáz()

S e q u e n c e

Vízszintesen az interakcióban részt vevő objektumok vannak Egy gy objektum j téglalap g p jelölése j elhelyezkedhet y a diagram tetején vagy ahol létrejön Az üzenetek különböző típusúak lehetnek X jelzi az objektum megszűnését

ÓE-NIK-SZTI

központ KagylótFel()

356

Ian Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002, p. 201

89

Üzenettípusok z z

z z

z

Példák üzenettípusokra

Egyszerű üzenet: az aktív objektum átadja a vezérlést a passzív objektumnak Szinkronizációs üzenet: a küldő blokkolt állapotba kerül, amíg a fogadó nem fogadta az üzenetet Randevú üzenet: a fogadó várakozik arra, hogy a küldő üzenetet küldjön neki Aszinkron üzenet: a küldő folyamat nem szakad meg, nem érdekli őt, hogy mikor kapta meg a f dó az üzenetet fogadó ü t t Visszatérési üzenet: amikor az objektum a vezérlést visszaadja , gyakran nem tüntetjük fel

Sike Sándor, Varga László: Szoftvertechnológia és UML, ELTE Eötvös Kiadó, 2003 ÓE-NIK-SZTI


357

Szinkronizációs üzenet

S e q u e n c e D i a g r a m

Bence

Aszinkron üzenet

ÓE-NIK-SZTI


358

D i a g r a m

Médiafájl betöltése

S e q u e n c e

http://www.w3.org/TR/xhtml-print/formsUsageModel.jpg 2005. november Szoftver Tervezés és Technológia

EmailtKüld() ()

Sike Sándor, Varga László: Szoftvertechnológia és UML, ELTE Eötvös Kiadó, 2003

Böngészés és nyomtatás

ÓE-NIK-SZTI

Anna

S e q u e n c e

359

D i a g r a m

Médiafájl betöltése felhasználói felületen keresztül. A MediaPlayer osztály példánya értesíti az őt hívót a betöltött fájl tulajdonságairól, amely frissített felhasználói felületet eredményez.

S e q u e n c e

A vezérlés é lé visszai adását külön feltüntettük.

http://dekstpo.de/weblog/2004/03/sequence 2005. november ÓE-NIK-SZTI


360

D i a g r a m

90

Feltételek, ciklusok… z z z

Adatbázis--elérés Adatbázis

A diagramon belül beágyazott diagramrésszel ábrázoljuk A részek alrészekre oszthatók (vízszintes szaggatott vonallal), ha szükséges (pl. feltételnél) A rész viszonyát az egész diagramhoz a sarkába írt cím jelzi

ÓE-NIK-SZTI


361

S e q u e n c e

S e q u e n c e

D i a g r a m

D i a g r a m

ÓE-NIK-SZTI

ÓE-NIK-SZTI


362

Rendelés

Játék

http://www.liemur.co.uk/Articles/UMLInteractionFragments.htm 2005. november


http://sparxsystems.com.au/resources/uml2_tutorial/uml2_sequencediagram.html2005. nov.

363

S e q u e n c e

S e q u e n c e

D i a g r a m

D i a g r a m

ÓE-NIK-SZTI


364

91

5.6.7 Collaboration Diagram z z z z z z z z z z

Communication Co mmunication Diagram


ÓE-NIK-SZTI


z z z

Objektumok közti interakciót mutatja Az objektumdiagram j g és a szekvenciadiagram g keresztezése Szabad elrendezést enged az objektumok között (a szekvenicadiagramtól eltérően) – Így könnyebb adott objektum interakcióit áttekinteni – Az üzenetek időrendben számozottak

z

365

Az UML 1.x-ben Collaboration Diagramnak hívják

ÓE-NIK-SZTI

ÓE-NIK-SZTI


367

366

Webes könyvvásárlás

Felhasználók kezelése weben

http://www.dotnetcoders.com/web/learning/uml/diagrams/collaboration.aspx 2005. nov.


C o m m u n i c a t i o n

C o m m u n i c a t i o n

D i a g r a m

D i a g r a m

ÓE-NIK-SZTI


http://sparxsystems.com.au/EAUserGuide/communicationdiagram.htm2005. nov.

368

92

Tárgyjelentkezés

5.6.8 State Machine Diagram z C o m m u n i c a t i o n

ÓE-NIK-SZTI


369

http://www.agilemodeling.com/artifacts/communicationDiagram.htm. 2005. nov.

D i a g r a m

z z z z z z z z z

Csomagdiagram (Package) Használati eset diagramja (Use Case) Osztálydiagram (Class) Objektumdiagram (Object) Szekvenciadiagram (Sequence) Kommunikációs diagram (Communication) Állapotdiagram (Statechart, State Machine) Akti á ió diagram Aktivációs di (Activity) (A ti it ) Komponensdiagram (Component) Telepítési diagram (Deployment)

ÓE-NIK-SZTI


370

Diagram

Structure Diagram

Állapotdiagram

Behavior Diagram

z Class Diagram

Component Diagram


Object Diagram

Deployment Diagram

Activity Diagram

Package Diagram

Profile Diagram


ÓE-NIK-SZTI


– David Harel dolgozta ki a statechart diagramok alapelvét – Az UML state machine fogalma ezen alapszik

Use Case Diagram State Machine Diagram

Interaction Diagram

Timing Diagram


371

Elnevezés eredet: Elnevezés,

Egyetlen objektum vagy interakció állapotainak sorozatát írja le z Az állapotgép forrásosztályhoz kapcsolódik, és példányainak viselkedését specifikálja z

ÓE-NIK-SZTI


372

S t a t e M a c h i n e D i a g r a m

93

Az állapotdiagram elemei

Állapotdiagram – webes vásárlás S t a t e M a c h i n e

ÓE-NIK-SZTI


373

http://www.sparxsystems.com.au/resources/tutorial/dynamic_model.html 2005. nov.

D i a g r a m

S t a t e

Állapot z Belépési pont (entry point) z Kilépési pont (exit point) z Átmenet: z

M a c h i n e

– Állapotok közötti kapcsolat – Feltüntethetjük rajta: Az esemény nevét z A feltételt, ami az esemény kiváltásához szükséges z A végbemenő tevékenységeket z

ÓE-NIK-SZTI


374

D i a g r a m

Állapotok Egy gy állapot á apot az a objektum obje tu az a attribútumatt bútu éértékeinek té e e és csatolásainak absztrakciójaként értelmezhető. Egyszerű esetben minden különböző attribútum érték külön állapotnak tekinthető. Általános esetben az attribútum értékek és csatolások halmaza képez egy állapotot. Azon attribútumok, melyek az objektum viselkedését nem befolyásolják, melyek a vezérlésmintára nincsenek hatással, figyelmen kívül hagyhatók. (A vizsgálat szempontjából nem fontosak!) ÓE-NIK-SZTI


375

Az objektum viselkedését tekintve az állapot egy időtartamot jelent, mely két esemény között telik el. Az események és az állapotok összetartoznak. Az események állapotokat határolnak, és fordítva, az állapotok eseményeket terminálnak. Úgy az állapotok, állapotok mint az események az absztrakciós szint függvényei.

ÓE-NIK-SZTI


376

94

Események

Állapot jelölése z

S t a t e

Fontosabb részei: – Név – Be- és kilépési tevékenység (entry/exit) – Belső tevékenység (do)

M a c h i n e

Jelszóbekérés entry / password.reset() exit / password.test() do / suppress echo

ÓE-NIK-SZTI


377

Az események bekövetkezhetnek egy másik esemény előtt vagy után (okozati összefüggés). Lehetséges azonban, hogy az események nincsenek hatással egymásra (nincs okozati összefüggés). Az okozati összefüggés nélküli eseményeket é k t párhuzamos áh eseményekként é kké t kkezelhetjük. lh tjük (Az (A események időpontokat reprezentálnak, időtartam hozzájuk nem rendelhető.)

D i a g r a m

Az események a külvilágból érkező külső ingerek, melyek a rendszert „stimulálják”, melyekre a rendszernek meghatározott válaszokat kell adnia. Az események lehetnek belső ingerek, melyeket a rendszert alkotó objektumok bocsátanak ki. Az objektumok különböző eseményekre adott válaszai függenek azon objektum állapotától, mely az eseményt észleli. A reakció lehet: z nincs állapotváltozás z állapotváltozás z esemény küldése az eredeti objektumnak z esemény küldése egy harmadik objektumnak ÓE-NIK-SZTI


378

Példa: egy egyszerű cola automata

Egy esemény egy információ átvitelként is tekinthető egyik objektumtól egy másik objektumhoz.

ÓE-NIK-SZTI


379

ÓE-NIK-SZTI


380

95

Feltételek megadása Egy feltétel egy logikai függvény, mely igaz vagy hamis értéket vehet fel. A feltételek rendelhetők eseményekhez.

Egy hagyományos példa:

Az események feltételei mint „őr” viselkednek. Egy „őrzött” átmenet akkor aktív, ha amikor az esemény megtörténik, azzal egyidőben a feltétel is igaz.

a telefonálás

A feltételeket az eseménynév mögött [ ] jelek között adjuk meg.

ÓE-NIK-SZTI


381

Műveletek Műveletek: z Akció (nincs időtartama, eseményhez kapcsolódik) Jelölése: Esemény-1(Attribútum) [Feltétel-1]/Akció-1 Aktivitás (időtartammal rendelkezik, állapothoz kapcsolódik) Jelölése:

ÓE-NIK-SZTI



382

Bemeneti és Kimeneti akciók

Az események nem csak átmeneteket, hanem műveleteket is kiválthatnak.

z

ÓE-NIK-SZTI

383

Lehetőség van arra, arra hogy akciókat egy állapotba való belépéssel, vagy abból történő kilépéssel kössünk össze. Jelölés:

ÓE-NIK-SZTI


384

96

Belső akciók

Egy példa: várakozunk a jelszóra

Egy esemény akció végrehajtását kiválthatja anélkül, anélkül hogy az állapotot elhagyná. Ezen akciókat nevezzük belső akcióknak. Jelölés:

ÓE-NIK-SZTI


385

ÓE-NIK-SZTI


386

Példa: cola automata, még egyszer

TK példa – mikrohullámú sütő Teljes teljesítmény

Engedélyezett

Teljes teljesítmény Do/teljesítmény beállítása=600

Muködés

Do/'Kész' megjelenítése

Do/süto muködtetése

Idozíto Indítás

Ajtó zárva

Teljes teljesítmény

Ajtó zárva

Ido beállítása Do/szám beolvasása Exit/ido beállítása

Várakozás Do/ido megjelenítése

Ajtó nyitva

Fél teljesítmény

Törlés Ajtó nyitva Idozíto

Fél teljesítmény

Fél teljesítmény

Tiltott

Do/teljesítmény beállítása=300

ÓE-NIK-SZTI


387

ÓE-NIK-SZTI

Do/'Nem kész' megjelenítése


Várakozás Do/ido megjelenítése

388

97


5.6.9 Activity Diagram

Tárgyjelentkezés z z z z z z z z z z ÓE-NIK-SZTI


389


ÓE-NIK-SZTI


390

http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm 2005. nov.

Diagram

Aktivációs diagram

Structure Diagram

Behavior Diagram

z z

Class Diagram

Component Diagram


Object Diagram

Deployment Diagram

Activity Diagram

Package Diagram

Profile Diagram


Interaction Diagram

z z

– Használati esetek részletezésére – Rendszerszintű funkciók modellezésére z


ÓE-NIK-SZTI

Use Case Diagram


Timing Diagram


391

Tevékenységek procedurális folyamatait modellezi Eljárások szekvenciális és konkurens lépéseit írja le Egy tevékenység összes lehetséges folyamatát mutatja Használható: Fókuszál: – A tevékenységek sorrendjére – A feltételekre, melyek kiváltják a tevékenységeket

ÓE-NIK-SZTI


392

A c t i v i t y D i a g r a m

98

Jelölések z z z z z z

Hogyan jutunk a főiskolára

Tevékenységi állapot: objektum tevékenységét jelöli Á Átmenet Kezdeti állapot Végállapot Szinkronizációs vonal: párhuzamos folyamatok elején j és végén g használjuk j A tevékenységek oszlopokba rendezhetők objektumok vagy feladatok szerint

ÓE-NIK-SZTI


A c t i v i t y

393


395

D i a g r a m

Metra: a HÉV Chicagó környékén

ÓE-NIK-SZTI



D i a g r a m

394

http://www.developer.com/design/article.php/2247041 2005. november

Vásárlás

Kurzus smenedzs selés

ÓE-NIK-SZTI

http://www.developer.com/design/article.php/10925_2247041_2 2005. november

A c t i v i t y

ÓE-NIK-SZTI


396


99

5.6.10 Component Diagram z z

Péld Példa: kávé-kávé főzés

z z A c t i v i t y

ÓE-NIK-SZTI Szoftver Tervezés és Technológia http://www.objectmentor.com/resources/articles/cplxtrns.pdf 2005. november

397

D i a g r a m

z z z z z z


ÓE-NIK-SZTI


398

Diagram

Komponensdiagram Structure Diagram

Class Diagram

Component Diagram


Behavior Diagram

Object Diagram

Deployment Diagram

Activity Diagram

Package Diagram

Profile Diagram

Sequence Diagram



Interaction Diagram


Use Case Diagram

Timing Diagram


399

Története: A komponensek lényege új irányt vett az UML 2.0-ban az addigi fizikai szemlélethez képest. Itt a komponensek az elemek fizikai fogalmától elkülönültek, fogalmi modellként használhatók. Halványy különbség van a struktúrált osztály és a komponens között. ÓE-NIK-SZTI


Rumbaug, Jacobson, Booch: The Unified Modeling Language Reference Manual

400

C o m p o n e n t D i a g r a m

100

Komponens jelölése

Komponens A fizikai és logikai rendszer azon moduláris rés eit írja le, részeit le amel amelyek ek kifelé látható viselkedése jobban leírható, mint a megvalósításuk. z A kifelé látható viselkedéseket interfészek halmaza reprezentálja. z Két nézőpontot mutatnak: z

– Definiálják a rendszer részeinek külső arculatát – Megvalósítják a rendszer funkcionalitását ÓE-NIK-SZTI


401

C o m p o n e n t D i a g r a m

Interfészek – Provided interface: olyan összetartozó szolgáltatások halmaza, amelyeket a komponens elérhetővé tesz – Required interface: a komponensnek meg kell kapnia a szolgáltatást

ÓE-NIK-SZTI


Két nézet – Téglalap és a <> kulcsszó – Téglalap benne a komponens ikonnal (az (a UML 1-es 1 es verzióiban er ióiban ez e jelölte a komponenst a téglalap helyett)

ÓE-NIK-SZTI


402


D i a g r a m

Az utazáskomponens belső komponensei

Interfészek

z

z

C o m p o n e n t

403

C o m p o n e n t

C o m p o n e n t

D i a g r a m

D i a g r a m

A kis négyzetek a komponensek határain portot jelölnek. ÓE-NIK-SZTI



404

101

5.6.11 Deployment Diagram

Iskolai szoftver komponensei z z z C o m p o n e n t

ÓE-NIK-SZTI


405


D i a g r a m

z z z z z z z


ÓE-NIK-SZTI


406

Diagram

Structure Diagram

Deployment Diagram

Behavior Diagram

z Class Diagram

Component Diagram


Object Diagram

Deployment Diagram

Activity Diagram

Package Diagram

Profile Diagram

Sequence Diagram



Interaction Diagram


Use Case Diagram

Timing Diagram


407

z z

A rendszer futási idejű architektúráját modellezi A hardverelemek (nodes) konfigurációját mutatja, valamint a szoftverelemek leképzését node-okra Node: – Erőforrást modellez (pl. számítógép, lemezmeghajtó) – Eszközök és futtatható környezetek ilyenek – Legalább memóriával, gyakran feldolgozó képességgel rendelkeznek

ÓE-NIK-SZTI


408

D e p l o y m e n t D i a g r a m

102

Hálózat

ÓE-NIK-SZTI


ATM

409

http://sparxsystems.com.au/resources/uml2_tutorial/uml2_deploymentdiagram.html 2005. nov.

D e p l o y m e n t

D e p l o y m e n t

D i a g r a m

D i a g r a m

ÓE-NIK-SZTI


410


Iskolai szoftver 5.6.12 További diagramok D e p l o y m e n t

ÓE-NIK-SZTI


http://www.agilemodeling.com/artifacts/deploymentDiagram.htm 2005. november

411

D i a g r a m

Az UML 22.x-ben x ben újdonság: z Composite Structure Diagram z Timing Diagram z Interaction Overview Diagram z Profile P fil Diagram Di

ÓE-NIK-SZTI


412

103

Composite Structure Diagram z z z

Struktúra diagram Az osztály, komponens stb. belső struktúráját és a rendszer más részeihez való kapcsolódását mutatja Az osztálydiagrammal ellentétben az osztályt alkotó elemek összetételét mutatja: – – – –

Interfészek Portok Részek Kollaboráció

ÓE-NIK-SZTI


413

C o m p o s i t e S t r u c t u r e D i a g r a m

C o m p o s i t e

Camcorder strukturált osztály portokkal

S t r u c t u r e

A négyszög belsejében lévő port (test signal) a port rejtettségre utal (a láthatósága private).

ÓE-NIK-SZTI


415

D i a g r a m

C o m p o s i t e

Autó és részei UML1.x-ben osztálydiagrammal

UML2.0-ban composite structure diagrammal

C Car Car w

4

1 e Engine

Wheel 2

Axis

ÓE-NIK-SZTI

w:Wheel[4]

2 a:Axle

1 e:Engine

1


414

Kollaboráció -- Együttműködés Semmi köze a Collaboration Diagramhoz, ami az UML1.x-ben volt z Statikus struktúra z Együttműködő részek struktúráját mutatja, amelyek együttesen látnak el kívánt feladatokat z Gyakran patternt valósít meg z Jelölése: szaggatott ellipszis a kollaboráció nevével z

ÓE-NIK-SZTI


416

S t r u c t u r e D i a g r a m

C o m p o s i t e S t r u c t u r e D i a g r a m

104

C o m p o s i t e

Lakásvásárlás

ÓE-NIK-SZTI


417

C o m p o s i t e

Jegyeladás

S t r u c t u r e

S t r u c t u r e

D i a g r a m

D i a g r a m

ÓE-NIK-SZTI

Timing Diagram


418

Rendelés

Viselkedési interakció diagram z A szekvenciadiagram bemutatásának alternatív módja z Explicit mutatja egy életvonalon az állapotokban p bekövetkezett változásokat z Valósidejű alkalmazásoknál hasznos z

ÓE-NIK-SZTI


419

T i m i n g

T i m i n g

D i a g r a m

D i a g r a m

ÓE-NIK-SZTI


420

105

Pénzfelvétel

Különbség a szekvenciadiagramhoz képest A tengelyen balról jobbra az idő nő z Az életvonalak függőlegesen, elkülönült részekben találhatók z Az életvonal le-fel ugrál, az állapotok változását mutatva z Mindenegyes függőleges helyzet külön állapotot jelent z Az állapotok sorrendje nem feltétlen bír jelentéssel z

ÓE-NIK-SZTI


421

Interaction Overview Diagram Viselkedési interakciós diagram z Az aktivációs diagram variációja, mely magában foglalja a szekvenciadiagramot z A szekvenciadiagram jelölését használja az aktivációs diagramból g vett döntésekkel és elágazásokkal z

ÓE-NIK-SZTI


423

T i m i n g

T i m i n g

D i a g r a m

D i a g r a m

ÓE-NIK-SZTI


422

Felvétel főiskolára

I n t e r a c t i o n


O v e r v i e w

O v e r v i e w

D i a g r a m

D i a g r a m

ÓE-NIK-SZTI


424

106


Rendelés

O v e r v i e w

ÓE-NIK-SZTI


425

D i a g r a m

Profile Diagram A profil diagram az UML különböző platformokra való testreszabását segíti elő z Általános kiterjesztést tesz lehetővé z A testreszabáshoz z

– sztereotípiákat, – tag-eket, – megszorításokat definiálhatunk. ÓE-NIK-SZTI


426

Osztályok sztereotípiái

Sztereotípia

z

Lehetővé teszi a tervező számára, számára hogy az UML nyelvezetét kiterjessze z Így a már létezőkből új modellelemek definiálhatók z Amelyek y speciális p tulajdonságot j g határoznak meg egy adott probléma megoldásához z Jelölése: << és >> közé írt szó z

A sztereotípiák legtipikusabb példája, hogy az analízis fázisában az osztályokat nem részletezve adjuk meg, hanem megadjuk az osztály jellegét, más néven sztereotípiáját: – Boundary z z

Határosztály A rendszer és az aktorok közötti illesztő felület

– Control z z

Boundary

Vezérlő osztály Má objektumok Más bj kt k vezérlése é lé

– Entity z z

Control

Egyed osztály Információ tárolása Entity

ÓE-NIK-SZTI


427

ÓE-NIK-SZTI


428

107

Sztereotípiával megadott osztályok

Profil diagram z

class Vezetői osztálydiagram

Banki v ezető

Az UML 2.2-ben a testreszabásokat egy profilban kell definiálni – Mi Minden d sztereotípiát t tí iát egy profil fil elemben l b határozunk meg

Vezetői kezelőfelület

Kimutatáskészítő

Kimutatás

(from Aktorok)

ÓE-NIK-SZTI


429

ÓE-NIK-SZTI

Összefoglaló feladat


430

Feladat

Rumbaugh, Jacobson, Booch: The Unified Modeling Language reference Manual, 2004 3. UML Walkthrough fejezet alapján z A fejezet célja egyszerű példán keresztül bemutatni a magas szintű UML fogalmakat z Az összefoglaló nem törekszik teljeskörű bemutatásra z

ÓE-NIK-SZTI


431

Készítsünk szoftvert egy színházi jegypénztárnak, amely számítógépre szeretné vinni az általa végzett tevékenységeket

ÓE-NIK-SZTI


432

108

Package Diagram

Use Case Diagram

Az ábra a teljes színházi rendszer csomagokra bontását tartalmazza a függőségi kapcsolatokkal együtt. ÓE-NIK-SZTI


433

Class Diagram

A képen a jegypénztár használati eset diagramja látható. ÓE-NIK-SZTI


434


A képen a jegypénztár osztálydiagramja látható. ÓE-NIK-SZTI


435

ÓE-NIK-SZTI


436

109

ÓE-NIK-SZTI


A jegyvásárlás használati eset szekve enciadiagramja

Sequence Diagram

Communication Diagram

A jegyeladás részletének kommunikációs diagramja a fejlesztés egy későbbi szintjén. ÓE-NIK-SZTI


439

ÓE-NIK-SZTI


A mű színpadra a állításának aktivitás diagramja. d


A jegy életciklusának állapotdiagramja.

ÓE-NIK-SZTI


438

Activity Diagrram

437

440

110

Component Diagram

Deployment Diagram A hitelkártyávval történő jegyvásárláss komponensei.

ÓE-NIK-SZTI


441

ÓE-NIK-SZTI


442

Tartalom 6. The Unified Software Development Process & Rational Unified Process (RUP)

ÓE-NIK-SZTI


443

Mi a szoftverfejlesztési módszertan? z Unified Process z Rational Unified Process (RUP) z Példa z

ÓE-NIK-SZTI


444

111

Szoftver = Termék

Szoftverfejlesztési módszertan Felhasználói igények g y

Van szolgáltatási V l ált tá i funkciója f k iój z Van előállítási költsége z Van előállítási határideje z Van minősége z

Szoftverfejlesztési módszertan

Az előállításához technológiára van szükség ÓE-NIK-SZTI


Szoftverrendszer

445

ÓE-NIK-SZTI

Szoftverfejlesztési módszertan Felhasználói igényeket transzformál szoftverrendszerré z A jó módszertan z

– Általános (többféle feladat esetén alkalmazható) – Fejlődőképes (alkalmazkodik a változásokhoz)

ÓE-NIK-SZTI


447


446

Szoftverfejlesztési módszertan z

Meghatározza, hogy kinek, Meghatározza kinek mit, mit mikor kell csinálnia ahhoz, hogy elérhesse a megadott célt

z

A módszertan alapjai: – – – –

Technológiák Eszközök Es kö ök Emberek Szervezetszintű munkamenet

ÓE-NIK-SZTI


448

112

Szoftverfejlesztési módszertan z

Technológiák – A korra jellemző technológiák meghatározzák az eljárás hatékonyságát z z z z z

z

Programozási nyelvek Fejlesztői környezetek Operációs rendszerek Hálózati lehetőségek …

z

Emberek – A fejlesztési folyamatban résztvevők képzettsége befolyásolja a hatékonyságot z z

z


Szervezetszintű munkamenet – A szoftverfejlesztők nem egyedül dolgoznak – A módszertannak illeszkednie kell a napi valósághoz, a tényleges munkamenethez

– A fejlesztéshez használt eszközök befolyásolják a hatékonyságot – Az eljárás és az eszközök párhuzamosan fejlődnek 449


ÓE-NIK-SZTI

450

Felhasználói igények

Modellalkotás

Fejlesztés

Sike Sándor, Varga László: Szoftvertechnológia és UML Szoftver Tervezés és Technológia



„ emberi „Az e be tevé tevékenységek e ysége so során á kialakult a a u t az a a gyakorlat, hogy a probléma megoldását először egy a probléma számára alkalmas rendszerben konstruáljuk meg, azaz létrehozzuk a megoldás absztrakt modelljét, és csak azután kerül sor a megoldás realizálására. Például lerajzoljuk a megépítendő házat, és csak azután fogunk hozzá annak felépítéséhez. felépítéséhez ”

ÓE-NIK-SZTI

Aktuális tudás Rövid távon megszerezhető tudás

– A fejlesztés bizonyos lépéseinek számítógépes támogatásával csökkenthetjük a képzettség-igényt

Eszközök

ÓE-NIK-SZTI


451

Szoftverrendszer ÓE-NIK-SZTI


452

113

Unified Process z

Rational Unified Process (RUP)

Egyesített: a három legelterjedtebb eljárás egyesítésével jött létre

A Unified Process-re Process re épül z A Rational (később IBM) cég fejlesztési módszertana z

– Jacobson – Booch – Rumbaugh z

Egységesített: egységes jelölésmód az egész világon ilá

z

A módszertan elvek elvek, módszerek és fejlesztést támogató eszközök egysége

A tervezés során az UML diagramjait használja. ÓE-NIK-SZTI


453

ÓE-NIK-SZTI

Történelmi áttekintés


454

Történelemi áttekintés

Ericsson fejlesztési gyakorlata

z

1991 99 – Object Modeling ode g Technique ec que

z

1991 – Booch Method

(J. Rumbaugh – General Electric)

Objectory Process (1987 – 1995)

(G. Booch – Rational Software)

Rational fejlesztési gyakorlata Rational Objectory Process (1996 – 1997)

z

1992 – Object-Oriented Systems Engineering

z

1994 – J. J Rumbaugh → Rational Software 1995 – I. Jacobson → Rational Software 1997 – UML 1998 - RUP

(I. Jacobson – Ericsson)

UML

z Rational Unified Process

z Egyéb források

z

(1998 – ) ÓE-NIK-SZTI


455

ÓE-NIK-SZTI


456

114

UML és RUP z

A RUP jellemzői z

G Booch, G. Booch J. J Rumbaugh, Rumbaugh II. Jacobson:

– a szoftvert komponensekből építi fel – a komponensek a megfelelő interfészeken keresztül kommunikálnak egymással – a rendszer funkcionalitása különféle komponensek hozzáadásával könnyen alakítható

The Unified Modeling Language User Guide z

z

Komponensalapú

J. Rumbaugh, G. Booch, I. Jacobson:

z

Modellszemléletű

The Unified Modeling Language Reference Manual

z

Használati eset vezérelt

I. Jacobson, J. Rumbaugh, G. Booch:

z

Architektúra-centrikus

The Unified Software Development Process

z

Iteratív és inkrementális

ÓE-NIK-SZTI


– a rendszert különféle modelleken keresztül közelíti meg – a fejlesztés középpontjában a megrendelővel egyeztetett use case-ek állnak – a használati esetek pontos felmérése, majd megvalósítása elengedhetetlen a projekt sikeréhez – Kiemelt hangsúlyt kap a rendszer architektúrája, az egységbezárás és a laza csatolás általi felépítés.

457

ÓE-NIK-SZTI

A RUP felépítése z

Fázisok – – – –

z

Előkészítés (Inception) Kidolgozás (Elaboration) Építés (Construction) Átadás (Transition)

ÓE-NIK-SZTI


458

A RUP felépítése

Munkamenetek – Követelmények meghatározása (Requirements) – Analízis (Analysis) – Tervezés (Design) – Fejlesztés (Implementation) – Tesztelés (Test) – …


459

ÓE-NIK-SZTI


460

115

Előkészítés / Inception z

Kidolgozás / Elaboration

Követelmény-feltáráson Követelmény feltáráson van a hangsúly

z

z

z

Költségek, erőforrások, határidők meghatározása Kockázatok elemzése – Kockázatlista

z

– Prototípus (kezelőfelület) Szoftver Tervezés és Technológia

Analízis modell Design modell Telepítési modell Implemetációs modell,

z

Az építés fázis menetének megtervezése

z

A tesztelés megtervezése

– Iterációs terv

Döntés születik a megvalósíthatóságról

ÓE-NIK-SZTI

A rendszer struktúrájának meghatározása – – – –

– Ütemterv – Erőforrás-felhasználási terv z

Az analízisen van a hangsúly g y – Kritikus funkcionalitás – Szerkezeti elemek

– Áttekintés (Use-Case modell) – Szójegyzék

– Teszt modell 461

ÓE-NIK-SZTI

Építés / Construction z

Az összes funkcionalitás kifejlesztése

A program beillesztése a felhasználási környezetébe z Felhasználói elégedettség mérése z Költségek ellenőrzése z A projekt lezárása z A követés megkezdése z

A program tesztelése – Alfa teszt – Béta teszt

z

Felhasználói leírás készítése

z

Az átadás megtervezése

462

Átadás / Transition

– Működő prototípus z


– Felhasználói kézikönyv – Iterációs terv ÓE-NIK-SZTI


463

ÓE-NIK-SZTI


464

116

A RUP felépítése (teljes üzleti folyamat)

A fázisok időidő- és erőforrásigénye Előkészítés

Kidolgozás

Megvalósítás

Átadás

Erőfeszítés

~5%

20%

65%

10%

Idő

10%

30%

50%

10%

ÓE-NIK-SZTI


465

ÓE-NIK-SZTI

A RUP modelljei Use-Case Use Case modell z Analízis modell z Design modell z Telepítési modell z Implementációs I l tá ió modell d ll z Teszt modell z (Adat modell) Szoftver Tervezés és Technológia

466

Use--Case modell Use A felhasználó igényeinek leírása z Használati eset diagramok

z

ÓE-NIK-SZTI


z

– Felhasználók (aktorok) – Szolgáltatások (használati esetek) – Használati esetek leírása ((forgatókönyv) g y ) z

467

Az egyes diagramok csoportosítása (csomagok)

ÓE-NIK-SZTI


468

117

Analízis modell

Design modell

A Use Use-Case Case modell részletezése z Osztály diagramok

z

z

z z

– Az Analízis modell osztályaiból kiinduló részletesebb felbontás – Adattagokkal és műveletekkel bővítve

– Osztályok és kapcsolataik realizálják a szolgáltatásokat z

z

Kollaborációs diagramok g


z

Állapotdiagram – Állapotok – Állapot-átmenetek

469

ÓE-NIK-SZTI

Telepítési modell


470

Implementációs modell

A Use Use-Case Case modell elosztása z A Design modell alapján készül z Deployment diagram

A Use Use-Case Case modell implementációja z A Design modell alapján készül z Komponens diagramok

z

z

– Csomópontok – Hálózati kapcsolatok z

Szekvencia diagramok – A kollaborációs diagramok alapján készül – A Design modell osztálydiagramjaira épül

– A kommunikációs folyamatok realizálják az egyes forgatókönyveket ÓE-NIK-SZTI

A Use Use-Case Case modell megvalósítása Az Analízis modell alapján készül Osztály diagramok

– A Design modell osztályainak megvalósítása az gy komponensekben p egyes

Az alrendszerek (csomagok) megkönnyítik a modell felosztását

ÓE-NIK-SZTI


471

ÓE-NIK-SZTI


472

118

Teszt modell

Példa

A Use Use-Case Case modell tesztje z A Use-Case modell alapján készül z Use-Case jellegű modell z

– Teszt esetek – Teszt folyamatok z

z

Tervezzük meg egy ATM vezérlőszoftverét!

z

Funkciói: Pénzfelvétel z Pénzbefizetés z Átutalás z

Az egyes szolgáltatásokhoz kell teszteseteket készíteni

ÓE-NIK-SZTI


473

Use--Case modell Use

ÓE-NIK-SZTI


474

Analízis modell (osztály diagram) Adagoló

Pénzfelvétel

Kivét

Átutalás Ügyfél gy

Ügyfél

Pénztár UI

Átutalás

Pénz érzékelő

Befizetés

Számla

Pénzbefizetés

ÓE-NIK-SZTI


475

ÓE-NIK-SZTI


476

119

Analízis modell (kommunikációs diagram)

Design modell (osztálydiagram) Kártyaolvasó

Pénzszámláló

4 visszaigazolás 4. i i lá

5. pénzkiadás

Kijelző

Ügyfélkezelő

3. Ellenőrzés és levonás

:Adagoló

Adagoló szenzor

Billentyűzet 1. azonosítás

2. pénzkérés

:Kivét

:Számla

Ügyfél

Ügyfél

Tranzakciókezelő

Adagoló

Pénzfelvétel

:Pénztár UI

Számlakezelő A pénzfelvétel use-case kommunikációs diagramja ÓE-NIK-SZTI

477

Design model (szekvenciadiagram) :Kijelző

:Ügyfélkezelő

:Billentyűzet

:Pénzszámláló

Számla

A pénzfelvétel use-case osztálydiagramja


:Kártyaolvasó

Tárolt osztály

ÓE-NIK-SZTI


478

Design modell (állapotdiagram) :Tranzakciókezelő

PIN-re vár Kártya ID

Ügyfél

PIN

Kártya Kártya ID Kérés megjelenítése

Kérés megjelenítése

PIN? PIN

Ügyfélre vár

PIN

Nem hitelesített

hitelesítés

Összeg? Összeg

Összegre vár Összeg

Összeg

Van-e elég bankjegy? Van-e fedezet?

Pénzkiadás

…

Hitelesített

Hitelesítésre vár

Az ügyfélkezelő osztály állapotdiagramja ÓE-NIK-SZTI


479

ÓE-NIK-SZTI


480

120

Telepítési modell

Implementációs modell

ATM ATM

A program egyetlen csomóponton működik ÓE-NIK-SZTI


A rendszer egyetlen komponensből áll 481

ÓE-NIK-SZTI


482

121

A tárgy keretében a hallgatók. Szoftverrendszerek Fejlesztése

Recommend Documents