Transcript 04 - johanyak.hu

Szoftvertechnológia
4. ELŐADÁS
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
1
Objektum diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
2
Sokszög
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
3
Kölcsönhatási diagramok



Sorrend diagram – kevés résztvevő sok
üzenettel
Kommunikációs diagram – sok résztvevő
kevés üzenettel
Időzítés diagram – kevés résztvevő,
komplex időbeli egymásra hatás
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
4
Sorrend diagram




Üzenetváltásokat ábrázol, amelyek több,
kölcsönhatásban lévő partner között zajlanak le
A partnerek lehetnek osztályok, aktorok,
komponensek, csatlakozók és csomópontok.
Akkor érdemes használni, ha kevés résztvevő
(partner) van, de azok sok üzenetet küldenek.
Az életvonalon látható üres téglalapot
aktivációs résznek nevezzük, ilyenkor csinálhat
valamit az adott szereplő.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
5
Sorrend diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
6
http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/353/Enterprise-Architect-for-Business-Analysts.aspx
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
7
Sorrend diagram
http://www2.pms.ifi.lmu.de/publikationen/diplomarbeiten/Sacha.Berger/illustrations/UML/SequenceDiagram-initiatingPhoneCall.pdf.png
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
8
Sorrend diagram
Kommunikációs diagram

ha sok résztvevő van és azok viszonylag
kevés üzenetet küldenek egymásnak.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
10
Kommunikációs diagram
http://afruj.wordpress.com/2008/07/28/the-unified-modeling-language-uml-part-8/
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
11
Időzítés diagram

kevés résztvevő, komplex időbeli egymásra
hatás
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
12
Kölcsönhatás áttekintő
diagram

A kölcsönhatás áttekintő diagram kicsit
kilóg a sorból, mivel ő az előző három fajta
módon megrajzolt (de ugyanarra a
rendszerre vonatkozó) diagramok között
fennálló összefüggéseket a
tevékenységdiagramok vizuális eszközeivel
fejezi ki. Ő valóban egy áttekintést nyújt.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
13
Kölcsönhatás áttekintő
diagram

Olyan, mintha egy tevékenységdiagramot
rajzolnánk (kezdőpont, végpontok, elágazás,
stb.), de a tevékenységek helyett ref-ek
állnak (referenciák). A referenciák általában
egy sorrenddiagramra vonatkoznak, amit már
részletesen megrajzoltunk. A példában
mindkét ref mögött létezik egy-egy
ugyanilyen nevű sorrenddiagram, ami
megmutatja a bejelentkezés és a felhasználó
megrendeléseinek a részleteit.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
14
Kölcsönhatás áttekintő diagram
EA 7.1 Unregistered
Trial
Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
sd View
Orders
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
ref
EA 7.1 Unregistered Trial Version
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
bej elentkezés
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
EA 7.1 Unregistered Trial Version EA 7.1
Unregistered
Trial Version EA 7.1 Unregistered T
[hibás
jelszó]
hozzáférés
megtagadva
[azonosított
felhasználó]
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
EA 7.1 UnregisteredrefTrial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
a rendelései megnyitása és megmutatása
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered T
kilépés
Dr. Johanyák
Zs. Csaba
Szoftvertechnológia
15
EA 7.1 Unregistered Trial
Version
EA -7.1
Unregistered
Trial Version EA 7.1 Unregistered
T
2014
Üzenettípusok



Az első háromfajta kölcsönhatási diagramban
egyaránt a következő háromfajta üzenettípust
használjuk.
Kérés: Szinkron üzenet. Kérés alkalmával a
küldő szünetelteti aktivitását (vár) és a fogadó
aktiválása következik be. (pl. telefonálás)
Válasz: Szinkron üzenet. A kérést küldő a
válaszüzenet hatására újra aktiválódik.
Szignál: Aszinkron üzenet, vagyis a küldő nem
szünetelteti az aktivitását az üzenet elküldése
után, hanem tovább dolgozik. (pl. levélküldés)
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
16
Kérés, válasz és szignál
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
17
Komplex interakció
Az első háromfajta kölcsönhatási diagramban
szerepelhetnek. Folyamatok egész halmazát
reprezentálhatják, amelyeket az interakciós
operátorok kötnek össze.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
18
Interakciós operátorok









strict operátor – szigorú sorrend
ref operátor – névvel hivatkozik más
interakciókra
opt operátor – opcionális
alt operátor – alternatívák (választási lehetőség)
brk operátor - megszakítás
seq operátor – sorrend, de nem szigorú sorrend,
mint a strict-nél
loop operátor – ciklus, ismétlés
par operátor – párhuzamosság
… (vannak még továbbiak)
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
19
Interakciós operátorok
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
20
Szoftvertechnológia
IMPLEMENTÁLÁS
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
21
Implementálás





A technológiai részletek kidolgozása, a
tényleges kód előállítása
Komponens tervezés, adatszerkezet tervezés
Felhasználói interakció megtervezése,
felülettervek
Integrálás (modulok összekapcsolása).
Dokumentáció: objektum d., csomag d.,
komponens d.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
22
Csomag diagram


Az UML-elemek csoportosítására, közös
névtérben való elhelyezésére alkalmas
Tartalmazhat további csomagot
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
23
Csomag láthatóság és útvonal
megadás

Public (default) – más névtérből is látható,
private

Teljes minősített név egymásba ágyazásnál:
gyökércsomag_neve::csomag_neve::elemnév

Relatív útvonal <<import>>-al
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
24
Csomagok közötti kapcsolatok



<<import>> a csomag összes elemét vagy
egy elemet láthatóvá tesz a másik csomag
számára
<<access>> privát import, ez az elem nem
importálható tovább újabb csomagokba
<<merge>> összeolvasztás, a
csomagimportálás egy fajtája, a beolvasztott
része lesz a beolvasztónak
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
26
Összetevő (komponens)
diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
27
Komponens


Komponens: a rendszer fizikailag létező és
kicserélhető része, feltéve, hogy az új
komponens csatlakozási felülete (interfésze)
megegyezik a régivel.
Az osztály és a komponens fogalma nagyon
hasonló az UML-ben
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
28
Interfész


Van nyújtott (szolgáltatott) interfész (kör a
jele)
Van elvárt (required) interfész (félkör a jele)
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
29
Összetevő diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
30
Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Un
Interfészek
összefogása
Trial Version
EA 7.1 Unregistered
Trial Version EA 7.1 Un
csatlakozóba
(portba)
Trial Version EA 7.1 Unregistered Trial Version
EA 7.1 Un
Trial Version
EA
7.1 Unregistered Trial Version EA 7.1 Un
cmp Component
Model
Trial Version EA 7.1 Unregistered
Trial Version EA 7.1 Un
összekötő
szerv er
kliens
Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Un
Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Un
Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Un
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
31
Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Un
Kialakítási diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
32
Kihelyezési/telepítési diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
33
Ismétlés és kiegészítés a tervezés témakörhöz
Szoftvertechnológia
ADATBÁZISOK
MODELLEZÉSE
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
34
ER modell
Forrás:
http://www
.inf.unideb
.hu/~fazek
asg/oktata
s/Adatbazi
sok/adatb
elm_nyh_
pdf.PDF
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
35
Relációs modell
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
36
Leképezési szabályok




Egyedtípus → reláció
Összetett attribútumok → komponensekre
bontás → reláció
Kulcsattr. → elsődleges kulcs
N:M kapcsolat → kapcsolat reláció
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
37
Kiinduló relációk
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
38
Normálformák
1.
2.
3.
A táblázat minden cellájában csak egy
attribútum érték szerepel (1NF)
Minden nem kulcs (másodlagos) attribútum
funkcionálisan teljesen függ minden kulcstól
(2NF)
Nincs olyan másodlagos attribútum, ami
tranzitívan függne valamilyen kulcstól
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
39
Entity Framework
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
40
Entity Framework modell
kialakítása






Id
Egyedtípus → entitás
Összetett attribútumok → komponensekre
bontás → entitás
Kulcsattr. → elsődleges kulcs (Entity key)
N:M kapcsolat → kapcsolat
Automatikusan keletkező navigációs
tulajdonságok
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
41
Szoftvertechnológia
IMPLEMENTÁLÁS FOLYTATÁS
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
42
Prototípus

A szoftverrendszer kezdeti verziója, amelyet arra
használnak, hogy




Támogatott tevékenységek a követelménytervezési
folyamatban



bemutassák a koncepciókat
kipróbálják a tervezési opciókat
jobban megismerjék a problémát és annak lehetséges
megoldásait
követelmények feltárása
követelmények validálása
Felhasználható


Felhasználók képzésére
Rendszer tesztelésére
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
43
A prototípus készítés előnyei









A funkciók bemutatásakor azonosítani lehet a szoftverfejlesztők
és a felhasználók közötti félreértéseket
A szoftverfejlesztésen dolgozók hiányos és/vagy ellentmondásos
követelményekre akadhatnak
Hamar a rendelkezésünkre áll egy működő rendszer, így
demonstrálhatjuk a vezetőségnek az alkalmazás
megvalósíthatóságát és hasznosságát
A prototípus felhasználható a valódi rendszer specifikációjának
megírásakor
A rendszer jobban használható lesz
A rendszer jobban illeszkedik a felhasználói igényekhez
Jobb a tervezés minősége
Jobb a rendszer karbantarthatósága
Kevesebb erőfeszítés szükséges a fejlesztéshez
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
44
Prototípus típusai

Evolúciós prototípus - készítésének
célja egy működő rendszer átadása a
végfelhasználóknak

Eldobható prototípus - készítésének
célja a rendszerkövetelmények validálása
vagy származtatása.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
45
Gyors prototípus készítési
technikák

Magas szintű nyelvek (3GL, 4GL)

Komponensek és alkalmazások összeépítése


Alkalmazási szinten
Komponens szinten
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
46
Programozási nyelvek

1. generációs: gépi szintű nyelv/utasítások,
kapcsolókkal vitték be
Kép forrása
http://en.wikipedia.org/wik
i/File:360-91-panel.jpg
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
47
Programozási nyelvek


2. generációs (2GL): assembly nyelvek – van
logikai struktúra, lassú fejlesztés
3. generációs (3GL): magasszintű nyelvek,
strukturált programozás támogatása,
kényelmi funkciók, nem kell a programozó
kidolgozzon minden egyes részletet
pl. C, C++, C#, Java, BASIC and Delphi
gyorsabb fejlesztés, de sok hibalehetőség
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
48
Programozási nyelvek


4. generációs(4GL): kereskedelmi/üzleti célú
szoftverek fejlesztéséhez, magasabb
absztrakciós szint
még gyorsabb fejlesztés kevesebb hibával, cél a
fejlesztési költségek csökkentése
PowerBuilder, jelentés generáló rendszerek,
form generáló rendszerek, adatfeldolgozó
rendszerek: SAS, SPSS
Pl: http://en.wikipedia.org/wiki/Fourthgeneration_programming_language#Some_fourt
h-generation_languages
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
49
Programozási nyelvek

5 GL: mesterséges intelligencia nyelvek,
feladatmegoldás a korlátok/kényszerek
megadásával, logikai nyelvek - ?
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
50
Az objektum-orientált tervezés
néhány kérdése



Mik az objektumok?
Alapelvek: egységbezárás, öröklődés,
többrétűség, adatrejtés
Vezérlés – szolgáltatáskérés



Szinkron kommunikáció
Aszinkron kommunikáció
Ütemezés – szabályozott megosztott hozzáférés
erőforráshoz


Nem preemptív – pl. szemaforok
Preemptív
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
51
Az objektum-orientált tervezés
néhány kérdése


Objektum belső állapota
Objektumok élettartama





Perzisztens objektumok: élettartamuk hosszabb
mint a program futási ideje
Tranziens objektumok
Nagyszámú perzisztens objektum 
adatbáziskezelő rendszer alkalmazása
RDB ha sok objektum, de kevés osztály
OODB
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
52
OBJEKTUM ORIENTÁLT
SZOFTVERFEJLESZTÉSI
MÓDSZERTANOK
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
53
Objektum orientált
szoftverfejlesztési módszertanok

OMT

Booch

RUP
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
54
Object Modeling Technique
(OMT)








Rumbaugh, Blaha, Premerlani, Eddy és Lorensen 1991
Egyszerű objektum orientált szoftverfejlesztési módszertan
Jelölésrendszerének számos elemét átvették az UML-ben
Alapgondolat: az OO gondolkodás közelebb áll az emberi
problémamegoldáshoz, mint a korábbi próbálkozások
A követelmény elemzés és tervezési fázis támogatására
dolgozták ki
Szekvenciális. Először a követelmény elemzés, majd a tervezés
Mindegyik fázisban a kis lépések ciklikusan ismétlődnek
Nem hangsúlyozza ki a tényleges implementációt, a tesztelést és
a többi alaptevékenységet (fázist)
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
55
A modellezés célja (Rumbaugh )




A fizikai egységek tesztelése még beépítés
előtt (szimuláció),
Kommunikáció a megrendelővel
Megjelenítés (vizualizáció)
Bonyolultság csökkentése
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
56
OMT




Három modell kidolgozását javasolja
Objektum modell: a rendszer építőelemei 
OM diagramok: objektumok és osztályok közötti
statikus kapcsolatok
Dinamikus modell: építőelemek közötti
kölcsönhatás (események, állapotok átmenetek)
 állapot diagram és esemény folyam diagram
Funkcionális modell: a rendszer eljárásai
adatfolyam/áramlás szempontból  adatfolyam
diagramok
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
57
Objektum diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
58
OMT fázisai

Elemzés - feladatmeghatározás (célok és alapkoncepciók

Rendszertervezés fázis
 A rendszer felépítése (architektúra)
 Alrendszerek meghatározása
 Alrendszerek folyamatokhoz rendelése figyelembe véve a
párhuzamos végrehajtást és együttműködést
 Perzistens adattárolás (adatbázis)
 Megosztott – globális információ kezelése,
 Határesetek vizsgálata, prioritások meghatározása
Objektum tervezés fázis
 Implementációs terv elkészítése
 Osztályok és algoritmusok definiálása
 Adattárolás optimalizálás
 Öröklődés, asszociáció, aggregáció, alapértelmezett értékek
vizsgálata


felsorolása is)
Szoftver implementálás
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
59
Booch módszertan




Grady Booch
A grafikus jelölésrendszer egy része bekerült az
UML-be
Az követelmény elemzési és a tervezési fázist fedi le
Négy modellt dolgoz ki a feladatról





Logikai modell (az osztályok és objektumok)
Fizikai modell
Statikus modell
Dinamikus modell
A modellek dokumentálására használt diagramok


Osztály, objektum, modul,
Állapot, kölcsönhatás, folyamat
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
60
Booch osztálydiagram
Forrás: http://en.wikipedia.org/wiki/File:Booch-diagram.png
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
Forrás: Grady Booch: ObjectOriented Analysis and Design. With
Applications, 2nd edition, AddisonWesley Longman, ISBN 0-80535340-2, 1994
61
Osztálydiagram példa
Forrás: Grady Booch: ObjectOriented Analysis and Design. With
Applications, 2nd edition, AddisonWesley Longman, ISBN 0-80535340-2, 1994
Hidrokultúrás kertészeti rendszer
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
62
Booch objektum diagram
Forrás: http://users.csc.calpoly.edu/~dbutler/tutorials/winter96/rose/node7.html
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
63
Booch modul diagram
Dr. Johanyák Zs. Csaba - Szoftvertechn.
Szoftvertechnológia
- 20092014
Forrás: http://users.csc.calpoly.edu/~dbutler/tutorials/winter96/rose/node8.html#picmodule_diagram
64
Booch állapot átmenet diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
Object-Oriented Systems
65
Development
Bahrami
© Irwin/ McGraw-Hill
Booch - Fázisok

Követetelmény-elemzés (analízis) – ciklikusan
ismétli a három részfeladatot




Követelmények a megrendelő szempontjából (a rendszer
feladatainak és struktúrájának magasszintű leírása)
Domain elemzés (osztályok attribútumok, öröklődés,
metódusok + állapot diagramok az objektumokhoz)
Validálás
Tervezés (design) – ciklikusan ismétli a
részfeladatokat



Logikai tervezés
Fizikai tervezés (Végrehajtási szálak, folyamatok,
teljesítmény, adattípusok, adattstruktúrák)
Prototípus létrehozása és tesztelése
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
66
Egységesített eljárás – Rational
Unified Process





A három legelterjedtebb szoftverfejlesztési
módszer egységesítésével jött létre 1997-ben
(OMT + Booch + OOSE)
Rational Unified Process (RUP) IBM
Világszerte elterjedt fejlesztési módszertan
Nagyon sok előző módszertanból merít
Keret módszertan -> testre kell szabni
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
67
Főbb jellemzői

Használati eset vezérelt (use case driven)


Architektúra központú (architecture centric)


A rendszer fejlesztésének elején meghatározott használati
esetek végigkísérik a teljes fejlesztést
A teljes fejlesztést meghatározza a rendszer architektúrája
Iteratív és inkrementális (növekvő)

Az egyes iterációk során a rendszer újabb verzióit
fejlesztjük, készítjük el. Az egyes iterációk
munkafolyamatokból állnak
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
68
Architektúra központú fejlesztés





Architektúra: strukturálisan fontos elemek és ezek
kapcsolata
A rendszer nagy léptékű tagolását írja elő
Nehezen megváltoztatható, a rendszer egész
élettartama alatt változatlan
A helyes architektúra meghatározása kulcsfontosságú:
ha itt hibázunk, akkor ennek a kijavítása nagyon sokba
kerül
A klasszikus példa: ház
 Alaprajz
 Homlokzati rajz
 Elektromos kábelezés és berendezések
 Épületgépészet, vízvezetékek, fűtés
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
69
Az architektúra célja






Lehetővé teszi a bonyolultság kezelését
Átláthatóvá tesz a fejlesztést
Könnyebben felismerhetőek az
újrafelhasználható elemek
Átlátható projekt menedzsment
Kockázatok csökkentése
Lehetővé válik a párhuzamos fejlesztés
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
70
RUP
Munkafolyamatok
Fázisok:
Előkészítés Kidolgozás Megvalósítás Átadás
Követelmények
Tervezés
Implementáció
Teszt
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
Ábra: http://www.quattrosoft.hu/szolgaltatasok/szoftverfejlesztes
71
RUP – mérföldkövek - iterációk




Minden fázis vége a fejlesztés egy-egy jól meghatározott
mérföldkövét (milestone) jelenti, azaz olyan pontot, ahol egy
célt kell elérnünk, illetve ahol kritikus döntéseket kell meghozni.
A fázisok további kisebb egységekre, iterációkra (iteration)
bonthatók. Minden iteráció egy teljes, illetve részben önálló
fejlesztési ciklust jelent, mivel az iteráció végén egy működő és
végrehajtható alkalmazásnak kell felállnia, az iteráció végén a
rendszer újabb, bővített funkcionalitású verziója készül el.
Minden egyes iteráció egy-egy mini fejlesztés.
Az Egységesített Eljárás iterációi tervezettek és szigorúan
ellenőrzöttek. Az iterációk számát és időtartamát, az egyes
iterációk feladatát és az általuk előállított termékeket, az iterációs
munkafolyamatok résztvevőit előre tervezik.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
72
RUP – átlós jelleg
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
Ábra: http://www.quattrosoft.hu/szolgaltatasok/szoftverfejlesztes
73
Átlós jelleg



Az előkészítés fázisában a legnagyobb hangsúly a
követelmények rögzítésére helyeződik, a többi
tevékenység pedig jóval kisebb mértékben kap
szerepet, tesztelés pedig gyakorlatilag nincs is.
A későbbi iterációkban, illetve fázisokban ez a
hangsúly fokozatosan áthelyeződik a technikaibb
jellegű tevékenységekre.
Az átadás fázisában már elsősorban tesztelés
zajlik, így elemzés, tervezés és implementáció a
tesztekre vonatkozóan és azok eredményeitől
függően válik szükségessé, míg a követelmények
összegyűjtése már nem kap szerepet.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
74
A fejlesztés fázisai




Előkészítés
 a rendszer eredeti ötletét olyan részletes elképzeléssé
dolgozzuk át, mely alapján a fejlesztés tervezhető lesz, a
költségei pedig megbecsülhetők;
 megfogalmazzuk, hogy a felhasználók milyen módon fogják
használni a rendszert, itt azonosítjuk a kulcsfontosságú
használati eseteket, azaz a rendszer alapvető
szolgáltatásait.
 milyen alapvető belső szerkezetet, architektúrát alakítunk ki.
Kidolgozás
 a „használati eseteket” részleteiben is kidolgozzuk;
 alaparchitektúra kialakítása (Executable Architecture
Baseline);
 az alaparchitektúra segítségével a teljes fejlesztés
folyamata ütemezhető, és a költségei is tisztázhatók.
Megvalósítás
 a rendszer iteratív és inkrementális növelése.
 a teljes rendszert kifejlesztjük (tervezés, kódolás).
Átadás
 bétaváltozatok, tesztelés, módosítás
 dokumentációk, egyéb kapcsolódó termékek
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
75
Dr. Johanyák Zs. Csaba - Szoftvertechnológia 2014
76
A fázisok erőforrás- és időigénye
egy átlagos fejlesztés esetében
65%
5%
10%
20%
30%
50%
Fázisok: Előkészítés Kidolgozás
Megvalósítás
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
10%
10%
Átadás
77
Idő- és erőforrásigény


A különböző jellegű fejlesztéseknél az egyes
fázisok idő illetve erőforrás igénye lényegesen
különbözhet. Például egy létező termék újabb
verziójánál az előkészítő fázis majdnem nullára
zsugorodhat, s a kidolgozási fázis is rövid lehet.
Ugyanakkor egy ismeretlen szakterülten,
ismeretlen eszközökkel végzett fejlesztés
esetében az előkészítés igen hosszú ideig
tarthat.
Általános jellegzetesség, hogy az építési fázis a
leghosszabb és a legnagyobb erőforrás igényű.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
78
Idő- és erőforrásigény


Viszonylag általános jellegzetesség, hogy az
előkészítő fázisnak jellemzően nagyobb az idő,
mint az erőforrás igénye. Az elkészítő fázisban
viszonylag kevés ember s viszonylag csekély
intenzitással foglalkozik a projekttel.
A megvalósítási fázisnak jellemzően nagyobb az
erőforrás és arányosan kisebb az időigénye,
mivel ez a fázis viszonylag jól párhuzamosítható,
a már jól definiált feladatokon párhuzamosan
sok fejlesztő dolgozhat
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
79
Egy iteráció munkafolyamatai (RUP)






Üzleti modellezés (Business Modeling): a készítendő rendszer üzleti
(szakterületi) környezetének vizsgálata
Követelmények (Requirements): a rendszer működésével kapcsolatos kezdeti
elképzelések összegyűjtése (a felhasználó szemszögéből)
Elemzés (Analysis): követelményeket a fejlesztők szempontjának megfelelően
rendezzük át, így azok együttessen a rendszer egy belső képét határozzák meg,
mely a további fejlesztés kiindulópontja lesz. Rendszerezzük és részletezzük az
összegyűjtött használati eseteket, valamint azok alapján meghatározzuk a
rendszer alapstruktúráját.
Tervezés (Design): az elemzés során kialakított szerkezeti váz teljessé tétele. A
tervezésnek a rendszert olyan szinten kell vázolnia, melyből az közvetlenül,
egyetlen kérdés és probléma felvetése nélkül implementálható.
Implementáció (Implementation): forráskódok, bináris és futtatható állományok,
szövegek, képek, stb. előállítása. Az állományok előállítása egyben azok
függetlenül végrehajtható, önálló tesztjeit is jelenti.
Teszt (Test): Megtervezzük és implementáljuk a teszteket, azok eredményeit
szisztematikusan feldolgozzuk, majd hibák vagy hiányosságok esetén újabb
tervezési vagy implementációs tevékenységeket hajtunk végre.
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
80
Egységesített Eljárás architektúrája
Megvalósítás
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
81
E lő készítés
Dr.oJohanyák
Zs. Csaba - Megvalósítás
Szoftvertechnológia
- 2014
K id
lg o zás
É p ítés
Ü z le ti m o d e ll
K ö ve te lm é n y m o d e ll
E le m zé s i m o d e ll
T e rve zé s i m o d e ll
Im p le m e n tá c ió s m .
T e szt m o d e ll
Ü z le ti m o d e ll
K ö ve te lm é n y m o d e ll
E le m zé s i m o d e ll
T e rve zé s i m o d e ll
Im p le m e n tá c ió s m .
T e szt m o d e ll
Ü z le ti m o d e ll
K ö ve te lm é n y m o d e ll
E le m zé s i m o d e ll
T e rve zé s i m o d e ll
Im p le m e n tá c ió s m .
T e szt m o d e ll
Ü z le ti m o d e ll
K ö ve te lm é n y m o d e ll
E le m zé s i m o d e ll
T e rve zé s i m o d e ll
Im p le m e n tá c ió s m .
T e szt m o d e ll
Az egyes termékcsoportok eltérő növekedése
Á tad ás
82
RUP irodalom



http://www.sze.hu/~heckenas/okt/RUP.pdf
http://www.iit.unimiskolc.hu/iitweb/export/sites/default/users/fic
sorl/Targyak/Infterv/Segedletek/swprochand.
pdf
http://courses.cs.tamu.edu/lively/cpsc606/rup.
ppt
Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2014
83