S DE R O NS I L
A
O
S TA SI
ÖTVÖS OE N
BU D A PE
ND
ST
E IN
E¨otv¨os Lor´and Tudom´anyegyetem Informatikai Kar Komputeralgebra Tansz´ek
M
TA * UNIV ER INA
Szoftverko enyek ¨vetelm´ modellez´ ese ´ es OPM Bese Antal
T´ emavezet˝ o: Dr. Kov´acs Attila
Budapest, 2009.
Diplomamunka-t´ ema bejelent˝ o A dolgozat t´ em´ aja A Object-Process-Methodology (OPM) egy u ´j, ´atfog´o modellez˝o eszk¨oz, amelynek seg´ıts´eg´evel alap¨osszetev˝ok egy sz˝ uk halmaz´ab´ol er˝osen kontextusf¨ ugg˝o szemantik´aval egyszer˝ ubben, ´erthet˝obben ´es k¨onnyebben le´ırhat´o rendszermodellek k´esz´ıthet˝ok. Az alapkoncepci´o k¨ ul¨onb¨oz˝o elemekb˝ol ´ep´ıtkezik (egy forr´as p´eld´aul az UML). Az OPM kiindul´opontja az, hogy mindent objektumnak tekinthet¨ unk. Ez mag´aban foglal k´ezzelfoghat´o ´es absztrakt objektumokat, tev´ekenys´egeket, m˝ uveleteket ´es esem´enyeket. A szoftverrendszereknek (mint minden rendszernek) h´arom f˝o aspektusa van: funkci´o (mi a szerepe a rendszernek), strukt´ ura (hogy van fel´ep´ıtve) ´es viselked´es (hogyan v´altozik az id˝o m´ ul´as´aval). Az OPM formailag egyszer˝ u grafik´at (OPD, Object-Process Diagram) term´eszetes nyelvi mondatokkal (OPL, ObjectProcess Language) egyes´ıt, hogy egyetlen integr´alt modellben fejezze ki a rendszerek funkcionalit´as´at, strukt´ ur´aj´at ´es viselked´es´et. A diplomamunka c´elja egy sz¨oveges szoftverk¨ovetelm´enyeket tartalmaz´o dokumentum formaliz´al´as´at t´amogat´o szoftver tervez´ese ´es implement´al´asa lenne, OPM alapokon. A formaliz´alt k¨ovetelm´enyrendszert ´ıgy tov´abbi automatikus vizsg´alatnak lehet al´avetni, ami gyors´ıtja ´es olcs´obb´a teszi a fejleszt´est.
i
ii
Nyilatkozat Alul´ırott, Bese Antal, az E¨otv¨os Lor´and Tudom´anyegyetem programtervez˝o matematikus hallgat´oja kijelentem, hogy ezt a diplomamunk´at meg nem engedett seg´ıts´eg n´elk¨ ul, saj´at magam k´esz´ıtettem, ´es a diplomamunk´aban csak a megadott forr´asokat haszn´altam fel. Minden olyan r´eszt, melyet sz´o szerint, vagy azonos ´ertelemben de ´atfogalmazva m´as forr´asb´ol ´atvettem, egy´ertelm˝ uen, a forr´as megad´as´aval megjel¨oltem.
........................ Bese Antal
iii
K¨ osz¨ onetnyilv´ an´ıt´ as Ez´ uton szeretn´em k¨osz¨onetemet kifejezni t´emavezet˝omnek, Dr. Kov´acs Attil´ anak, hogy ´ert´ekes megjegyz´eseivel ´es tan´acsaival mindig seg´ıts´egemre volt a dolgozat meg´ır´asa sor´an. H´al´aval tartozom a Csal´adomnak, akik mindenben t´amogattak, ´es lehet˝ov´e tett´ek, hogy egy´altal´an eljussak a dolgozat meg´ır´as´aig. Szeretn´em megk¨osz¨onni munkat´arsaimnak ´es bar´ataimnak, hogy meg´ert´essel ´es t¨ urelemmel voltak ir´antam a dolgozat´ır´as k¨ozben. V´egezet¨ ul pedig k¨ ul¨on k¨osz¨onetet szeretn´ek mondani ˝ tan´acsai mindig er˝ot adtak a munka folyam´an. M´arton Rit´anak, az O
iv
Tartalomjegyz´ ek Els˝ o.
K¨ ovetelm´ enykezel´ es ´ es a szoftverfolyamat
1. A szoftverfolyamat
1 2
1.1. Szoftverfejleszt´esi modellek . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2. Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.3. A megfelel˝o folyamatmodell kiv´alaszt´asa . . . . . . . . . . . . . . . .
8
2. K¨ ovetelm´ enyanal´ızis
9
2.1. Neh´ezs´egek a k¨ovetelm´enykezel´esben . . . . . . . . . . . . . . . . . .
9
2.2. Szoftverk¨ovetelm´enyek oszt´alyoz´asa . . . . . . . . . . . . . . . . . . . 11 2.3. Szoftver k¨ovetelm´enydokumentum . . . . . . . . . . . . . . . . . . . . 13 2.3.1. Els˝o r´esz – Az alkalmaz´as ´attekint´ese . . . . . . . . . . . . . . 13 2.3.2. M´asodik r´esz – Funkcion´alis k¨ovetelm´enyek . . . . . . . . . . . 15 2.3.3. Harmadik r´esz – F¨ uggel´ek . . . . . . . . . . . . . . . . . . . . 16 2.4. Szoftverk¨ovetelm´enyek specifik´al´as´anak m´odszerei . . . . . . . . . . . 16
M´ asodik.
Object-Process Methodology (OPM)
3. Dinamika
19 23
´ 3.1. Allapotok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2. Az input ´es output link . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3. A rendszer komplexit´as´anak kezel´ese . . . . . . . . . . . . . . . . . . 26 3.4. Procedur´alis linkek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.4.1. Transzform´al´o linkek . . . . . . . . . . . . . . . . . . . . . . . 27 3.4.2. Megenged˝o linkek . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.4.3. Felt´eteles linkek . . . . . . . . . . . . . . . . . . . . . . . . . . 31 v
´ TARTALOMJEGYZEK
vi
¨ 3.5. Osszefoglal´ as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4. Strukt´ ura
36
4.1. Struktur´alis rel´aci´o . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2. Struktur´alis linkek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2.1. K´etir´any´ u struktur´alis link . . . . . . . . . . . . . . . . . . . . 39 4.2.2. Struktur´alis linkek c´ımk´ez´ese
. . . . . . . . . . . . . . . . . . 40
4.2.3. R´eszv´eteli korl´at ´es sz´amoss´ag . . . . . . . . . . . . . . . . . . 42 4.2.4. Disztribut´ıv szab´aly ´es el´agaz´asok . . . . . . . . . . . . . . . . 45 4.3. A n´egy alapvet˝o struktur´alis rel´aci´o . . . . . . . . . . . . . . . . . . . 47 4.3.1. Aggreg´aci´o-r´eszv´etel . . . . . . . . . . . . . . . . . . . . . . . 48 4.3.2. Bemutat´as-jellemz´es . . . . . . . . . . . . . . . . . . . . . . . 51 ´ 4.3.3. Altal´ anos´ıt´as-specializ´aci´o . . . . . . . . . . . . . . . . . . . . 55 4.3.4. Oszt´alyoz´as-p´eld´anyos´ıt´as . . . . . . . . . . . . . . . . . . . . 59 ¨ 4.4. Osszefoglal´ as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Harmadik.
Szoftverk¨ ovetelm´ enyek modellez´ ese
5. Felhaszn´ al´ oi dokument´ aci´ o
62 65
5.1. Rendszerk¨ovetelm´enyek . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.2. A program ind´ıt´asa ´es telep´ıt´ese . . . . . . . . . . . . . . . . . . . . . 66 5.2.1. Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.2.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.3. A felhaszn´al´oi fel¨ ulet kezel´ese . . . . . . . . . . . . . . . . . . . . . . 67 5.3.1. F˝omen¨ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.3.2. Rajzt´abla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.3.3. Eszk¨ozt´ar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.4. K¨ovetelm´enydokumentum formaliz´al´asa . . . . . . . . . . . . . . . . . 72 5.5. Az alkalmaz´as modellj´enek testreszab´asa . . . . . . . . . . . . . . . . 74 5.5.1. Entit´asok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.5.2. Rel´aci´ok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 5.5.3. OPL mondatok . . . . . . . . . . . . . . . . . . . . . . . . . . 77
´ TARTALOMJEGYZEK
vii
6. Fejleszt˝ oi dokument´ aci´ o
79
6.1. Az alkalmaz´as modulszerkezete . . . . . . . . . . . . . . . . . . . . . 80 6.1.1. OPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.1.2. OPMdialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.1.3. OPMfigures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.1.4. OPMreqAnalApplication . . . . . . . . . . . . . . . . . . . . . 81 6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.1.6. images.png
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.1.7. sentenceReaderPackage . . . . . . . . . . . . . . . . . . . . . . 81 6.2. Oszt´alyhierarchia, a fontosabb oszt´alyok r´eszletez´ese . . . . . . . . . . 82 6.2.1. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.2.2. View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.2.3. Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.3. Tesztel´esi terv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 6.3.1. Modulteszt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 6.3.2. Funkcion´alis teszt . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.4. Az OPCAT ´es az OPMReqAnal ¨osszehasonl´ıt´asa . . . . . . . . . . . . 93
Negyedik.
¨ Osszegz´ es
95
6.5. A CD mell´eklet tartalma . . . . . . . . . . . . . . . . . . . . . . . . . 97
´ ak jegyz´ Abr´ eke 1.1. A Boehm-f´ele spir´alis modell . . . . . . . . . . . . . . . . . . . . . . .
5
1.2. A V-modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1. A nem funkcion´alis k¨ovetelm´enyek t´ıpusai . . . . . . . . . . . . . . . 12 2.2. Az OPM ´ep´ıt˝ok¨ovei . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1. Az ´allapotok grafikus megjelen´ıt´ese . . . . . . . . . . . . . . . . . . . 24 3.2. Az input ´es output linkek szem´eltet´ese a vil´ag´ıt´as p´eld´aj´an kereszt¨ ul . 25 3.3. Result link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.4. Consumption link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5. Effect link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.6. A h´ıv´o (invocation) link k¨ ul¨onb¨oz˝o jel¨ol´esi m´odjai . . . . . . . . . . . 29 3.7. Agent link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.8. Instrument link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.9. Egy bankautomata leegyszer˝ us´ıtett m˝ uk¨od´esi elve . . . . . . . . . . . 32 3.10. Condition link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.11. Agent condition link . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1. Egyir´any´ u, c´ımk´ezett struktur´alis link . . . . . . . . . . . . . . . . . . 38 4.2. Egyir´any´ u struktur´alis linkek ir´any´ıtotts´ag´anak jel¨ol´ese . . . . . . . . 38 4.3. K´etir´any´ u, c´ımk´ezett struktur´alis link . . . . . . . . . . . . . . . . . . 39 4.4. K´etir´any´ u struktur´alis linkek kifejez´ese egyetlen egyir´any´ u struktur´alis linkkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.5. K¨olcs¨on¨os struktur´alis rel´aci´ok jel¨ol´ese . . . . . . . . . . . . . . . . . 41 4.6. Cimke n´elk¨ uli struktur´alis linkek megfelel˝oi . . . . . . . . . . . . . . . 41 4.7. P´elda : egy gr´af o¨t cs´ ucspontb´ol ´all. . . . . . . . . . . . . . . . . . . . 42 viii
´ ´ JEGYZEKE ´ ABR AK
ix
4.8. P´elda : k´et gr´afnak kell, hogy legyen k¨oz¨os pontja . . . . . . . . . . . 43 4.9. P´elda : a gr´af p´aros sz´am´ u cs´ ucsponttal rendelkezik. . . . . . . . . . . 43 4.10. P´elda : a gr´af legal´abb kett˝o, legfeljebb ¨ot cs´ ucsponttal rendelkezik.
. 44
4.11. El´agaz´as az OPD-ben . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.12. Aggreg´aci´o-r´eszv´etel . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.13. El´agaz´as ´es rendez´es az aggreg´aci´oban . . . . . . . . . . . . . . . . . 49 4.14. Bemutat´as-jellemz´es . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.15. P´elda : jellemz˝ok az objektumorient´alt ´es OPM vil´agban . . . . . . . 53 4.16. A n´egy dolog-jellemz˝o kombin´aci´o . . . . . . . . . . . . . . . . . . . . 54 ´ 4.17. Altal´ anos´ıt´as-specializ´aci´o . . . . . . . . . . . . . . . . . . . . . . . . 56 4.18. P´elda : Vad´aszkuty´ak specializ´aci´oja. . . . . . . . . . . . . . . . . . . 56 4.19. P´elda : alul-, ´es fel¨ ulspecifik´al´as . . . . . . . . . . . . . . . . . . . . . 58 4.20. Oszt´alyoz´as-p´eld´anyos´ıt´as . . . . . . . . . . . . . . . . . . . . . . . . 59 4.21. A n´egy alapvet˝o struktur´alis rel´aci´o jel¨ol´ese . . . . . . . . . . . . . . . 60 5.1. Az OPMReqAnal alkalmaz´as f˝oablaka . . . . . . . . . . . . . . . . . . 67 ´ entit´as felvitele, illetve entit´as m´odos´ıt´asa . . . . . . . . . . . . . . 69 5.2. Uj ´ rel´aci´o felvitele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.3. Uj 5.4. A rajzt´abla finomhangol´asa . . . . . . . . . . . . . . . . . . . . . . . 71 5.5. K¨ovetelm´enydokumentum formaliz´al´asa . . . . . . . . . . . . . . . . . 72 5.6. Az alkalmaz´as modellj´enek testreszab´asa . . . . . . . . . . . . . . . . 75 5.7. Entit´asok/rel´aci´ok OPL mondatainak szerkeszt´ese . . . . . . . . . . . 77 6.1. Oszt´alydiagram – az OPMAbstractObject ´es kapcsolatai
. . . . . . . 82
6.2. Oszt´alydiagram – a sentenceReader ´es kapcsolatai . . . . . . . . . . 87 6.3. Oszt´alydiagram – az OPMfigure ´es kapcsolatai . . . . . . . . . . . . . 88 6.4. Az OPCAT felhaszn´al´oi fel¨ ulete . . . . . . . . . . . . . . . . . . . . . 94
T´ abl´ azatok jegyz´ eke 1.1. Agile Manifesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1. Szoftveres hib´ak jav´ıt´as´anak relat´ıv k¨olts´ege . . . . . . . . . . . . . . 10 3.1. Procedur´alis linkek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2. Felt´eteles linkek. 3.3. Megenged˝o linkek.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4. Transzform´al´o linkek . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.1. Tartom´any-r´eszv´eteli korl´atok r¨ovid´ıtett jel¨ol´ese . . . . . . . . . . . . 44 4.2. A n´egy alapvet˝o struktur´alis rel´aci´o jel¨ol´ese . . . . . . . . . . . . . . . 47 ´ 4.3. Altal´ anos struktur´alis rel´aci´ok . . . . . . . . . . . . . . . . . . . . . . 60 4.4. A n´egy alapvet˝o struktur´alis rel´aci´o t¨obb lesz´armazott eset´en . . . . . 61 6.1. A tartom´any-r´eszv´eteli korl´atok ´es a cardinalityEnum t´ıpus . . . . . 85
x
Bevezet˝ o Nagy rendszerek k¨ovetelm´enyeinek specifik´aci´oja a r´esztvev˝ok ´es c´eljaik azonos´ıt´as´at, majd mindezek alkalmas form´aban t¨ort´en˝o dokument´al´as´at jelenti. Az informatikai projekteknek rettent˝o szigor´ u elv´ar´asoknak kell megfelelni¨ uk, amik t´ ulnyom´or´eszt sz¨oveges m´odon defini´alt k¨ovetelm´enyek hatalmas halmaz´at jelentik. Napjainkban a dokument´al´as legink´abb term´eszetes nyelven t¨ort´enik, mely legnagyobb h´atr´anya f´elre´erthet˝os´ege ´es rugalmatlans´aga. Emellett a megrendel˝oi oldal ´erdekei azt k´ıv´anj´ak, hogy az ´ıgy defini´alt k¨ovetelm´enyek minden pontja marad´ektalanul teljes¨ ulj¨on, mik¨ozben a fejleszt˝ok v´altoz´asokra val´o reag´al´asa a lehet˝o leggyorsabb legyen. Az Object-Process Methodology-t formailag egyszer˝ u grafik´aja, ´es sz¨oveges reprezent´aci´oja alkalmass´a teszi szoftverrendszerek modellj´enek egyszer˝ u fel´ep´ıt´es´ere. A sz¨oveges k¨ovetelm´enydokumentumok nagy m´erete ´es rugalmatlans´aga adta a motiv´aci´ot a k¨ovetelm´enyek specifik´al´as´anak egy u ´jfajta m´odszer´ere, melynek alappill´ere ¨ lehet az OPM. Osszevetve a term´eszetes nyelvi specifik´aci´o kiv´alt´as´ara hivatott alternat´ıv m´odszerekkel, az OPM mellett sz´ol m´eg k¨onny˝ u ´erthet˝os´ege, ´es nagyfok´ u flexibilit´asa is. Meg´ert´es´ehez nem sz¨ uks´eges informatikai h´att´ertud´as, ´es ennek megfelel˝oen k¨onnyen alkalmazhat´o speci´alis szakter¨ uletek modellez´es´ere is. P´eldak´ent hozhat´o fel min˝os´egi szabv´anyok OPM-mel val´o le´ır´asa, melyek specifik´al´as´ahoz nem sz¨ uks´eges informatikusi v´egzetts´eg. Viszont k¨onnyen l´athat´o, hogy a szabv´anyok aktualiz´al´asa milyen er˝ofesz´ıt´eseket k´ıv´an, mely gyors´ıthat´o lenne az OPM haszn´alat´aval. Mi a helyzet a m´ar megl´ev˝o k¨ovetelm´eny-dokumentumokkal? K¨onnyen bel´athat´o, hogy nem ´eri meg a sz¨oveges specifik´aci´o mellett p´arhuzamosan OPM-alap´ u specifik´aci´ot fenntartani. A k¨ovetelm´eny-dokumentum formaliz´al´asa megold´ast jelenthet. A formaliz´al´as alatt azt ´ertj¨ uk, hogy minden egyes mondathoz hozz´a tudxi
˝ Bevezeto
xii
junk rendelni egy Object-Process Diagrammot. ´Igy l´etrehozhat´o egy, l´enyeg´eben v´eve egyszer˝ us´ıtett, sematikus ´abra a rendszermodellr˝ol. Az OPM grafikus modellj´ehez tartoz´o ekvivalens sz¨oveges reprezent´aci´o teljes m´ert´ekig lefedheti a r´egi term´eszetes nyelvi specifik´aci´ot (ak´ar helyettes´ıtheti is azt !). A diplomamunka c´elja, egy a formaliz´al´ast t´amogat´o, szoftver tervez´ese ´es implement´al´asa.
A dolgozat fel´ ep´ıt´ ese A dolgozatot n´egy r´eszre bontottam. Az els˝o r´eszben a szoftverfolyamat klasszikus m´odszertanainak ´attekint´es´en kereszt¨ ul bemutatom a szoftverk¨ovetelm´enyeket, majd a m´asodik r´eszben az Object-Process Methodology alapvet˝o dinamikai ´es struktur´alis aspektusait vizsg´alom meg. A harmadik r´esz a szoftveres k¨ovetelm´enyek formaliz´al´as´at t´amogat´o OPMReqAnal alkalmaz´as felhaszn´al´oi, ´es fejleszt˝oi le´ır´as´at tartalmazza. V´egezet¨ ul a negyedik r´eszben az el´ert eredm´enyek r¨ovid o¨sszefoglal´asa k¨ovetkezik.
“We learn to develop software by building, testing, and evolving models.” Victor Basili
Els˝ o r´ esz K¨ ovetelm´ enykezel´ es ´ es a szoftverfolyamat
1
1. fejezet A szoftverfolyamat Egy szoftver kialakul´asa mag´aban foglalja fejleszt´esi-, haszn´alati-, ´es karbantart´asi tev´ekenys´egek k¨orfolyamat´at. A szoftverrendszerek interakci´ok sorozat´an haladnak kereszt¨ ul, melyek befoly´asolj´ak fejleszt´es¨ uket, bevezet´es¨ uket, hat´ekony m˝ uk¨od´es¨ uket majd fenntart´asukat, ´es v´egezet¨ ul a kivon´asukat. Mi most szoftverrendszer alatt olyan nagy bonyolults´ag´ u rendszert ´ert¨ unk, mely m¨og¨ott mindig megtal´alhat´o maga a szoftverterm´ek. A szoftverrendszerek k¨oz¨os jellemz˝oje, hogy fejben tartva nem kezelhet˝oek a kidolgoz´as sor´an felhaszn´aland´o r´eszletek. Elk´esz¨ ult¨ uk ´altal´aban id˝oig´enyes, az egy napt´ari h´onapt´ol kezdve, ak´ar ´evekben is m´erhet˝o. Az el˝obbiek egyenes k¨ovetkezm´enye, hogy legritk´abb eseteket kiv´eve, csapatmunk´aban t¨ort´enik a fejleszt´es. De mit is jelent val´oj´aban a szoftverterm´ek elnevez´es? A szoftverterm´ek sz´am´ıt´og´epes programok, azok dokument´aci´oja ´es a kapcsol´od´o adatok ¨osszess´ege.
1.1. Szoftverfejleszt´ esi modellek Sz´amos k¨ ul¨onb¨oz˝o, a szoftver ´eletciklus´at le´ır´o, ´altal´anos szoftverfejleszt´esi modellt fejlesztettek ki az ut´obbi ´evtizedekben, melyek k¨ozel azonos terminol´ogi´at k¨ovetnek. Ezen paradigm´ak a szoftver evol´ uci´oj´at le´ırj´ak, de sok esetben hat´arozottan el˝o is ´ırj´ak. ´Igy megk¨ ul¨onb¨oztet¨ unk el˝o´ır´o, ´es le´ır´o szoftverfejleszt´esi modellek et, melyek k¨ ul¨onb¨oz˝o perspekt´ıv´ab´ol reprezent´alj´ak szoftverfolyamatot. Tipikus, ´es k¨onny˝ u vil´agosan el˝o´ırni egy ´eletciklus modellnek a szoftverrendszer fejleszt´es´enek elv´art l´ep´eseit, mik´entj´et. Sokkal k¨onnyebb, mint teljes´ıteni az elv´ar´asokat. Az el˝o´ır´o modellek nagyr´eszt intuit´ıvak, teh´at a benn¨ uk megfogalma2
1. FEJEZET. A SZOFTVERFOLYAMAT
3
zott elv´ar´asok sokszor tekinthet˝ok aj´anl´asnak, mintsem k¨otelez˝o ´erv´eny˝ u szab´alynak. ´ Eppen ez´ert teljesen mag´at´ol ´ertet˝od˝o, hogy esetenk´ent elhagyhat´oak – elkend˝ozhet˝oek, vagy ´altal´anos´ıthat´oak a szoftverfejleszt´es r´eszletei. Minden egyes szoftverrendszer fejleszt´ese m´as ´es m´as be´all´ıt´ast (absztrakci´os szintet) k¨ovetel meg a haszn´alt modellt˝ol. Term´eszetes, hogy k´ets´egek mer¨ ulnek fel az olvas´oban egy el˝o´ır´o modell l´etjogosults´ag´aval, illetve robusztuss´ag´aval szemben. M´asr´eszr˝ol, a szoftverfejleszt´es ´eletciklus´at le´ır´o modellek jellemzik egy adott szoftverrendszer fejleszt´es´enek jelenlegi ´allapot´at. Mint ilyenek, a le´ır´o modellek kev´esb´e ´altal´anosak, ´ıgy tagol´asuk is nehezebb. Sokszor ´evekben m´erhet˝o egy nagyobb rendszer fejleszt´ese, ´ıgy a fejleszt´esi inform´aci´ok vizsg´alata, kinyer´ese el´eg k¨or¨ ulm´enyes. Ez indokolja, hogy a le´ır´o modellek specifikusak az adott rendszerre szabva, ´es csak a szisztematikus elemz´es c´elj´aig ´altal´anosak. Ennek k¨ovetkezt´eben az id˝ok sor´an ink´abb az el˝o´ır´o t´ıpus´ u ´eletciklus modellek ker¨ ultek el˝ot´erbe. Nagy rendszerek eset´eben a programk´esz´ıt´es f´azisait hat j´ol tagolt r´eszre oszthatjuk, melyek v´egigk¨ovetik a szoftver teljes ´eletciklus´at. Term´eszetesen sz´amos m´as feloszt´as is elk´epzelhet˝o, a dolgozat sor´an a k¨ovetkez˝o tagol´ast haszn´alom [11]: 1. k¨ovetelm´enyek le´ır´asa, 2. specifik´aci´o, 3. tervez´es (v´azlatos tervez´es, r´eszletes tervez´es), 4. implement´aci´o, integr´aci´o, 5. verifik´aci´o, valid´aci´o, 6. rendszerk¨ovet´es, karbantart´as. A f´azisok k¨oz¨otti kapcsolatok le´ır´as´ara szolg´alnak a k¨ ul¨onf´ele szoftverfejleszt´esi modellek, melyek r´eszletes ismertet´es´ere most nem t´erek ki, de r¨oviden bemutat´asra ker¨ ulnek a legismertebbek. Build and Fix modell A szoftverfejleszt´es legegyszer˝ ubb modellje az u ´n. Build and Fix modell. Haszn´alata nagyon kis projektek eset´eben lehet c´elszer˝ u, ami´ kor gyors eredm´enyre van sz¨ uks´eg. Altal´ aban egy ember sz´am´ara is fejben
1. FEJEZET. A SZOFTVERFOLYAMAT
4
tarthat´o k¨ovetelm´enyspecifik´aci´oval rendelkez˝o rendszerek modellje. Alkalmaz´asa sor´an a k¨ovetend˝o strat´egia azt mondja, hogy fejlessz ´es tesztelj am´ıg a megrendel˝o nem el´egedett a rendszerrel. Legt¨obbsz¨or hib´as ´eletciklus-modellre adott p´eldak´ent tal´alkozunk vele, b´ar egyes esetekben indokolt lehet haszn´alata. V´ızes´ es modell A v´ızes´es modell egy szekvenci´alis szoftverfejleszt´esi modell, melyben a fejleszt´es menete egy l´epcs˝ozetesen al´ahull´o v´ızes´eshez hasonlatos, ahol az egyes l´epcs˝ofokok a fejleszt´es soron k¨ovetkez˝o f´azisainak felelnek meg. Az elnevez´es haszn´alata 1970-re ny´ ulik vissza, amikor is Winston W. Royce [1] ´ publik´alta a modellt. Erdekess´ eg, hogy az eredeti cikkben nem tal´aljuk meg a v´ızes´es modell elnevez´est, ezt a c´ımk´et csak k´es˝obb ragasztott´ak r´a. Royce szerint enn´el egyszer˝ ubb modell nem lehet m˝ uk¨od˝ok´epes nagy szoftver rendszerek fejleszt´ese sor´an. Evol´ uci´ os modell Az evol´ uci´os modell inkrement´alis m´odon szervezett, melyet neveznek m´eg protot´ıpusk´epz´esnek is. A fejleszt´es korai szakasz´aban l´etrehozott korl´atozott funkcionalit´assal rendelkez˝o rendszer finom´ıt´as´an alapul, teh´at a k¨ovetelm´enyspecifik´aci´oban r¨ogz´ıtett v´egc´el el´er´es´ehez protot´ıpusok sorozat´an kereszt¨ ul vezet. Az ily m´odon (inkrement´alisan) el˝o´all´ıtott protot´ıpusok a k¨oztes l´ep´esekben tov´abbi vizsg´alatoknak vethet˝ok al´a. Sokszor a k¨ovetelm´enyspecifik´aci´o finom´ıt´as´at is ekkor v´egzik. Boehm-f´ ele spir´ alis modell A ’80-as ´evek v´eg´en, Barry Boehm amerikai matematikus aj´anl´asa nyom´an sz¨ uletett meg a szoftverfolyamat elemz´es´enek ´es strukt´ ur´al´as´anak egy kock´azat-vez´erelt megk¨ozel´ıt´ese, a spir´alis modell [5]. A modell l´enyege a fejleszt´es iter´aci´oinak spir´alis form´aba t¨ort´en˝o szervez´ese. A fejleszt´es a spir´alis ment´en halad, ´ıgy t¨obb protot´ıpus is elk´esz¨ ulhet k¨ozben. Az iter´aci´ok a spir´alis forma egy-egy f´azis´aval jellemezhet˝oek, melyekre rendszerint a k¨ovetkez˝o elnevez´eseket haszn´alj´ak (l´asd az 1.1-es ´abr´at) : 1. Az el´erend˝o c´elok meghat´aroz´asa, a k¨ovetelm´enyspecifik´aci´o lehet˝o legr´eszletesebb kidolgoz´asa. 2. Az esetleges kock´azati t´enyez˝ok felder´ıt´ese, hat´asuk cs¨okkent´ese.
1. FEJEZET. A SZOFTVERFOLYAMAT
5
3. Fejleszt´es ´es tesztel´es, valid´aci´o. 4. A k¨ovetkez˝o iter´aci´os l´ep´es megtervez´ese. Kumul´alt k¨olts´eg
2. Az esetleges kock´azati t´enyez˝ok felder´ıt´ese
1. Az el´erend˝o c´elok meghat´aroz´asa
´ Attekint´ es
p1
4. A k¨ovetkez˝o iter´aci´os l´ep´es megtervez´ese
p2
p3
3. Fejleszt´es ´es tesztel´es
1.1. ´abra. A Boehm-f´ele spir´alis modell (ahol p1 , p2 a k¨oztes, m´ıg p3 a funkcionalit´as´aban v´egleges protot´ıpust jel¨oli) Rapid Application Development A Rapid Application Development (RAD) egy iterat´ıv, folyamat alap´ u alkalmaz´asfejleszt´esi modell, mely rendk´ıv¨ ul r¨ovid fejleszt´esi folyamatot hangs´ ulyoz. Eredetileg James Martin publik´alta 1991-ben [6]. A m´odszer egyar´ant mag´aban foglal iterat´ıv fejleszt´est ´es protot´ıpusk´epz´est. A RAD modell haszn´alat´aval lehet˝ov´e v´alik min˝os´egi szoftver term´ekek gyors elk´esz´ıt´ese, amivel hasznos er˝oforr´asokat szabad´ıthatunk fel, felt´eve ha a szoftver k¨ovetelm´enyei pontosan meghat´arozottak, ´erthet˝oek. V-modell A n´emet v´edelmi miniszt´erium ´altal kifejlesztett V-modell (1992) szemsz¨og´eb˝ol a programk´esz´ıt´es f´azisai egy V bet˝ ut id´eznek (l´asd az 1.2-es ´abr´at). A projekt ´eletciklusa a V bal sz´ar´an´al kezd˝odik a felhaszn´al´oi k¨ovetelm´enyek felder´ıt´es´evel, majd a V jobb sz´ar´an´al fejez˝odik be, a m´ar valid´alt rendszerrel. A V k´et sz´ar´anak tal´alkoz´as´an´al a rendszer implement´al´asa ´es integr´aci´oja t¨ort´enik. A V bal sz´ar´at nevezik dekompoz´ıci´os, m´ıg a jobb sz´ar´at integr´aci´os,
1. FEJEZET. A SZOFTVERFOLYAMAT
6
verifik´aci´os f´azisnak is. Tulajdonk´eppen a v´ızes´es modell egy tov´abbfejleszt´es´er˝ol van sz´o, melyben az egyes f´azisok eredm´eny´et azonnal ellen˝orzik, ´ıgy jav´ıtva a szoftver min˝os´eg´en. ¨ Uzemeltet´ es, karbantart´as
K¨ovetelm´eny valid´aci´o
K¨ovetelm´eny elemz´es
Rendszer tervez´es
´ Atviteli tesztel´es
Rendszer tesztel´es
Terv verifik´aci´o
Egys´eg ´es integr´aci´os tesztel´es
Program tervez´es
Implement´al´as
1.2. ´abra. A V-modell Rational Unified Process Az IBM ´altal aj´anlott Rational Unified Process [15], vagy k¨ozismertebb nev´en a RUP, egy folyamat k¨ozpont´ u keretrendszer, mely bizonyos fok´ u szabads´agot ad a szoftverfejleszt˝o kez´ebe ahhoz, hogy a modellt a c´elnak ´es sz¨ uks´egleteknek megfelel˝oen ´atalak´ıtsa. Kidolgoz´as´an´al csokorba gy˝ ujt¨ott´ek az ´evek sor´an legjobbnak ´ıt´elt gyakorlati modellek tov´abbgondol´asra alkalmas komponenseit, amivel egy sz´elesk¨or˝ uen haszn´alhat´o, ´altal´anos modellt kaptak. Az objektumorient´alt, UML-en alapul´o modellben f´azisokat ´es munkafolyamatokat k¨ ul¨onb¨oztetnek meg, mint a modell k´et dimenzi´oj´at. A fejleszt´es n´egy f´azisb´ol ´all, ´es minden f´azis egy vagy t¨obb iter´aci´ob´ol. A n´egy f´azis rendre: el˝ok´esz´ıt´es, kidolgoz´as, megval´os´ıt´as ´es ´atad´as. Az egyes f´azisokon bel¨ ul a munkafolyamatok elt´er˝o s´ ullyal szerepelnek. A fejleszt´es f´azisait nevezik m´eg dinamikus, m´ıg a munkafolyamatokat a rendszer statikus n´ez˝opontj´anak is. eXtreme Programming Az 1990-as ´evek elej´en Kent Beck ´es Ward Cunningham elgondol´asa alapj´an sz¨ uletett meg az eXtreme Programming (XP) m´odszer-
1. FEJEZET. A SZOFTVERFOLYAMAT
7
A szoftverfejleszt´es jobb m´odjait fedezz¨ uk fel az´altal, hogy csin´aljuk, ´es seg´ıt¨ unk m´asoknak is csin´alni. Ennek sor´an az al´abbi hangs´ uly-eltol´od´asokat tal´ altuk: Egy´ enek ´ es interakci´ oik, szemben az elj´ar´asokkal ´es eszk¨oz¨okkel. M˝ uk¨ od˝ o szoftver, szemben a teljesk¨or˝ u dokument´ aci´ oval. Egy¨ uttm˝ uk¨ od´ es az u ellel, szemben a szerz˝ od´esr˝ol val´o alkudoz´assal. ¨gyf´ V´ altoz´ asokra val´ o reag´ al´ as, szemben a terv k¨ovet´es´evel. Ez azt jelenti, hogy a jobb oldalon szerepl˝ o ´ert´ekek is fontosak, de a bal oldalon l´ev˝ oket fontosabbnak tartjuk. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas c 2001, a fenti szerz˝
ok. Ezt a nyilatkozatot szabadon lehet m´asolni, de csak egyben, ezzel a jogi nyilatkozattal egy¨ utt.
1.1. t´abl´azat. Agile Manifesto, http://agilemanifesto.org tana. N´egy alapvet˝o ´ert´ekre ´ep´ıtkezik, melyek a kommunik´aci´o, egyszer˝ us´eg, visszajelz´es ´es b´ators´ag. Emellett egyszer˝ u alaptev´ekenys´egek ´allnak a k¨oz´eppontj´aban: k´odol´as, tesztel´es, meghallgat´as ´es tervez´es. A modell kis projektcsapatok m´odszere, mely alkalmaz´asa kock´azatos projektek, illetve dinamikusan v´altoz´o k¨ovetelm´enyek eset´en lehet hat´ekony. Az XP egy fegyelmezett ´es ´atgondolt szoftverfejleszt´esi megk¨ozel´ıt´es, mely mindek¨ozben fokozott figyelemmel k´ıs´eri a megrendel˝o szerep´et. Bevonja a fejleszt´es menet´ebe, mintegy egyenrang´ u partnerk´ent egy¨ utt” fejleszt a pro” jektcsapat ´es megrendel˝o. Az u ¨gyf´el szempontj´ab´ol ´erdekes kih´ıv´as r´eszt venni – ak´ar mindenf´ele szak´ertelem n´elk¨ ul – a szoftverfejleszt´esben (innen az ext” reme” jelz˝o).
1.2. Agile Az Agile t¨ort´enete 2001-ben kezd˝od¨ott, amikor a kor pehelys´ uly´ u m´odszertanainak 17 jelent˝os k´epvisel˝oje (l´asd az 1.1 t´abl´azatot) ¨ossze¨ ult, hogy megbesz´elj´ek saj´at m´odszertanaik saj´atoss´agait. A mini konferenci´at az amerikai Utah ´allam egy s´ıp´aly´aj´ara szervezt´ek, ahol olyan m´odszertanok ki¨otl˝oi gy˝ ultek ¨ossze, mint az XP vagy
1. FEJEZET. A SZOFTVERFOLYAMAT
8
a Scrum. A c´el egy teljesen u ´j m´odszertan kidolgoz´asa volt. A legenda szerint hossz´ u napok eredm´enytelen tan´acskoz´asa ut´an siker¨ ult k¨oz¨os nevez˝ore jutniuk, viszont u ´j m´odszertant nem dolgoztak ki. Az´ert m´egsem volt teljesen haszontalan a konferencia, megalkott´ak az Agilis Ki´altv´anyt (Agile Manifesto), ezzel u ´tj´ara engedve az Agile m´odszertan´at. Az Agilis Fejleszt´es egy m´odszertan-csal´ad, filoz´ofia ´es nem egy konkr´et megk¨ozel´ıt´ese a szoftverfejleszt´esnek. Olyan nagy c´egek alkalmazz´ak, mint a Google, a Yahoo vagy a Microsoft. A legt¨obb megk¨ozel´ıt´esben az XP technik´ak tov´abbfejleszt´es´et haszn´alj´ak (b˝ovebben l´asd [7]).
1.3. A megfelel˝ o folyamatmodell kiv´ alaszt´ asa A fentiekben r¨oviden bemutatott modellek haszn´alata szerte´agaz´o lehet. Csak p´eldak´eppen, egy j´ol fel´ep´ıtett modell mag´aban foglalja a szoftverfejleszt´esi projektmunka szervez´es´et, tervez´es´et ´es u ¨temez´es´et is. Ezzel id˝ot, ´es p´enzt takar´ıthatunk meg, ´es ami m´eg fontosabb: tervezhet˝ov´e teszi a szoftverterm´ek el˝o´all´ıt´as´at. A projekth´aromsz¨og (id˝o, p´enz, min˝os´eg) lehet˝os´egek szerinti egyens´ uly´anak a meg˝orz´ese ´erdek´eben fontos, hogy mindig a megfelel˝o folyamatmodellt v´alasszuk. Sajnos az adott k¨or¨ ulm´enyek figyelembev´etel´evel sem lehet egy´ertelm˝ uen eredm´enyt hirdetni ezen folyamatmodellek k¨oz¨ott. A v´alaszt´as teljesen nyitott, nagyr´eszt a projektben r´esztvev˝o szervezetek bels˝o gyakorlat´at´ol, folyamatait´ol ´es ´ızl´es´et˝ol f¨ ugg. A legt¨obb szoftverfejleszt˝o szervezet a tradicion´alis folyamatmodellek egyik´et, vagy annak valamilyen testre szabott v´altozat´at haszn´alja, de elterjedt gyakorlat az is, hogy valamely szoftvertechnol´ogiai kutat´oint´ezet (pl.: az IBM, vagy az AT&Bell Laborat´oriumok) k´ıs´erletei alapj´an v´alasztanak fejleszt´esi paradigm´at. Victor Basili [3] volt els˝ok´ent sz´osz´ol´oja a tetsz˝olegesen, adott projekthez ´es szervezethez kialak´ıtott ´eletciklus-modellek fejleszt´es´enek. Tapasztalati u ´ton el´ert eredm´enyek alapj´an meg´allap´ıthatjuk, hogy a szoftverfolyamat modelleken kereszt¨ uli vizsg´alata akkor lehet a leghat´ekonyabb, ´es a legt¨obb el˝ony´et is akkor ´elvezhetj¨ uk, ha mindennapi szokv´anyos tev´ekenys´egeink k¨oz´e be´ep´ıtj¨ uk.
2. fejezet K¨ ovetelm´ enyanal´ızis A k¨ovetelm´enyanal´ızis a szoftverfejleszt´es egy olyan ´agazata, mely a val´os vil´ag szoftverrendszerekkel szembeni elv´ar´asaival foglalkozik. Term´eszetesen ide tartozik a kapcsol´od´o ter¨ uletek ismerete, amely seg´ıts´eg´evel lehet˝os´eg¨ unk ny´ılik egy adott rendszer m˝ uk¨od´es´et ´es evol´ uci´oj´at prec´ızen specifik´alni. Fontos, hogy a val´os vil´agban el˝ofordul´o ig´enyekr˝ol besz´el¨ unk, hiszen a fejleszt´es motiv´aci´oj´at adj´ak. Prec´ızen szeretn´enk specifik´alni, ami mag´aban foglalja a k¨ovetelm´enyek elemz´es´et, valid´al´as´at, defini´al´as´at ´es verifik´al´as´at. A valid´al´as sor´an arr´ol akarunk megbizonyosodni, hogy amit k¨ovetelm´enyk´ent r¨ogz´ıt¨ unk, az t´enyleg az amit a r´esztvev˝ok elv´arnak a rendszert˝ol, vagy sem. Defini´alnunk kell, hogy mit tervezzenek a szak´ert˝oink, de sohasem azt, hogy hogyan tegy´ek azt. A felhaszn´al´oi ig´enyek ´es a rendszer m˝ uk¨od´esi felt´eteleinek felt´ar´as´anak v´egezt´evel verifik´alni kell, teh´at az eredm´eny helyess´eg´er˝ol kell megbizonyosodnunk.
2.1. Neh´ ezs´ egek a k¨ ovetelm´ enykezel´ esben A szoftverfejleszt´es kulcsfontoss´ag´ u k´erd´ese eld¨ontetni, majd prec´ızen megfogalmazni a kifejlesztend˝o rendszerrel kapcsolatos elv´ar´asainkat. Nagy rendszerek k¨ovetelm´enyeinek specifik´aci´oja a r´esztvev˝ok ´es c´eljaik azonos´ıt´as´at, majd mindezek alkalmas form´aban t¨ort´en˝o dokument´al´as´at, tervez´es´et ´es ut´olagos implement´aci´oj´at jelenti. Ezzel a folyamattal sz´amos neh´ezs´eg j´ar egy¨ utt, ´ıgy nem v´eletlen, hogy a szoftverk¨ovetelm´enyek meghat´aroz´asa egyike a legnagyobb inform´aci´otechnol´ogiai pro9
´ ´IZIS ¨ 2. FEJEZET. KOVETELM ENYANAL F´ azis
10
Relat´ıv jav´ıt´ asi k¨ olts´ eg
K¨ovetelm´enyelemz´es
1–2
Tervez´es
5
Implement´aci´o
10
Egy´egteszt
20
Rendszerteszt
50
Karbantart´as
200
2.1. t´abl´azat. Szoftveres hib´ak jav´ıt´as´anak relat´ıv k¨olts´ege az egyes f´azisok sor´an bl´em´aknak [4]. A szoftverfolyamat ezen f´azis´anak kiemelt jelent˝os´ege van a projekt sikeress´eg´et tekintve. ´Igy, ha a k¨ovetelm´enyeket hib´asan fektett¨ uk le, akkor a szoftverfolyamat fennmarad´o f´azisai ´ertelmetlenn´e v´alhatnak. Ha a k¨ovetelm´enyelemz´es sor´an nem j´ol specifik´aljuk a rendszer m˝ uk¨od´es´et, ´es ez csak egy k´es˝obbi f´azisban der¨ ul ki (legyen ez p´eld´aul a tesztel´es), akkor a jav´ıt´asi k¨olts´egek k´ets´egess´e tehetik az eg´esz projekt sikeress´eg´et is. A hiba k´es˝obbi jav´ıt´as´anak k¨olts´ege ak´ar k´etsz´azszorosa is lehet a k¨ovetelm´enyelemz´es sor´an felt´art hib´ak jav´ıt´asi k¨olts´eg´ehez k´epest (l´asd a [2]-es ´es a 2.1-es t´abl´azatot). Fontos t´enyez˝o az egym´as k¨oz¨otti kommunik´aci´o. Ilyen nagy rendszerekn´el az absztrakt megfogalmaz´as´ u rendszertervek nehezen ´atl´athat´oak, egy nagy rendszer terveit egy szem´ely nem is tudja k´ezben tartani. A rendszer megrendel˝oi legt¨obbsz¨or nem tudj´ak mit v´arnak el a mag´at´ol rendszert˝ol, ami persze nem azt jelenti, hogy nem tudj´ak milyen szoftverrendszerre van sz¨ uks´eg¨ uk. Ink´abb jelenti azt, hogy a rendszer egyes funkci´oinak konkr´et le´ır´as´at nem tudj´ak olyan prec´ızen megfogalmazni, mint azt a tervez˝ok ´es a fejleszt˝ok elv´arn´ak. A folyamatban r´esztvev˝ok (bele´ertve a megrendel˝ot, a rendszer felhaszn´al´oit ´es fejleszt˝oit) sokan lehetnek, egym´ast´ol ak´ar f¨oldrajzilag is t´avol. C´elkit˝ uz´eseik a munkater¨ ulet¨ ukt˝ol ´es l´at´osz¨og¨ ukt˝ol f¨ ugg˝oen v´altozatosak, sokszor egym´asnak ellentmon´ d´oak. Altal´ aban nem mondj´ak ki explicit elv´ar´asaikat, vagy csak egyszer˝ uen neh´ez azt kifejezni, de el˝ofordulhat az is, hogy teljes´ıt´es¨ uk rajtuk k´ıv¨ ul´all´o okokb´ol lehetetlen.
´ ´IZIS ¨ 2. FEJEZET. KOVETELM ENYANAL
11
2.2. Szoftverk¨ ovetelm´ enyek oszt´ alyoz´ asa Egy szolg´altat´as vagy felt´etel magas szint˝ u absztrakt megfogalmaz´as´at´ol egy funkci´o r´eszletes matematikai le´ır´as´aig sok fajt´aja lehet a k¨ovetelm´enyeknek. Ezek alapj´an megk¨ ul¨onb¨oztethet¨ unk felhaszn´al´oi-, ´es rendszerk¨ovetelm´enyeket. A felhaszn´al´oi k¨ovetelm´enyek a rendszer szolg´altat´asair´ol ´es m˝ uk¨od´esi felt´eteleir˝ol, ´altal´aban term´eszetes nyelven megfogalmazott a´ll´ıt´asok. Legt¨obbsz¨or a megrendel˝o sz´am´ara ´ır´odnak, ´ıgy nyelvezete laza, mindenf´ele k¨ot¨otts´egekt˝ol mentes. A felhaszn´al´oi k¨ovetelm´enyeket sok, ´es k¨ ul¨onb¨oz˝o k´epzetts´eg˝ u szakember fogja olvasni, ´ıgy a • v´egfelhaszn´al´ok, • megrendel˝o menedzserei, • megrendel˝o m´ern¨okei, • ´es t¨obbek k¨oz¨ott a rendszertervez˝ok is. Erre a t´enyre figyelemmel kell lenni m´ar a k¨ovetelm´enyek kinyer´esekor is. A felhaszn´al´oi k¨ovetelm´enyek ´erdekes megk¨ozel´ıt´es´evel tal´alkozhatunk a [10]-es cikkben. A szerz˝ok esettanulm´anyokon kereszt¨ ul mutatj´ak be egy szoftverrendszer felhaszn´al´oi dokument´aci´oj´anak ´es k¨ovetelm´enydokumentum´anak hasonl´os´agait, ´es aj´anlatot tesznek a felhaszn´al´oi k¨ovetelm´enyek user’s guide”-szer˝ u meg´ır´as´ara. ” A rendszerk¨ovetelm´enyeket tartalmaz´o dokumentumra jellemz˝o, hogy j´ol struktur´alt, amely tartalmazza a rendszer ¨osszes funkci´oj´anak, szolg´altat´asainak ´es m˝ uk¨od´esi felt´eteleinek r´eszletes le´ır´as´at. Pontosan defini´alja, hogy mit kell a szoftverfejleszt˝oknek implement´alniuk (´es m´eg mindig nem a hogyan”-on van a hangs´ uly). ” Kett˝os szereppel rendelkezik, hiszen tekinthet˝o egyben aj´anlatt´eteli felh´ıv´asnak (elt´er˝o alternat´ıv´akat k´ın´alva), ´es egy j´ol megfogalmazott szerz˝od´esi alapnak is. A felhaszn´al´oi k¨ovetelm´enyekhez hasonl´oan a rendszerk¨ovetelm´enyek olvas´oi is sokf´el´ek lehetnek, p´eld´aul: • a rendszer v´egfelhaszn´al´oi, • a megrendel˝o m´ern¨okei, • rendszertervez˝ok ´es
´ ´IZIS ¨ 2. FEJEZET. KOVETELM ENYANAL
12
• szoftverfejleszt˝ok. A rendszerrel szemben t´amasztott k¨ovetelm´enyeket oszt´alyozhatjuk funkcion´alis, nem funkcion´alis ´es k¨ornyezeti (domain) k¨ovetelm´enyekre. A funkcion´alis, vagy viselked´esi k¨ovetelm´enyek a rendszer, vagy annak egy komponens´enek elv´art m˝ uk¨od´es´et ´ırj´ak le. A funkci´o jellemezhet˝o a bemen˝o adatok halmaz´aval, a viselked´es´evel, illetve a kimen˝o adatokkal. Egy funkcion´alis k¨ovetelm´eny lehet sz´am´ıt´as, technikai r´eszlet, adatmanipul´aci´o, vagy egy´eb feldolgoz´asi jelleg˝ u funkcionalit´as, ami kiel´eg´ıt egy haszn´alati esetet. Ezent´ ul besz´elhet¨ unk m´eg funkcion´alis felhaszn´al´oi k¨ovetelm´enyekr˝ol ´es funkcion´alis rendszerk¨ovetelm´enyekr˝ol is. El˝obbi magas szint˝ u ´all´ıt´asok, m´ıg ut´obbi r´eszletes le´ır´asok halmaza a rendszer elv´art m˝ uk¨od´es´er˝ol, szolg´altat´as´ar´ol. A funkcion´alis k¨ovetelm´enyek a rendszer pontos m˝ uk¨od´es´et hat´arozz´ak meg. Ezzel szemben a nem funkcion´alis, vagy min˝os´egi k¨ovetelm´enyek a rendszer ´atfog´o jellemz´es´ere szolg´alnak. A nem funkcion´alis k¨ovetelm´enyek a rendszer egy funkci´oj´ara, illetve szolg´altat´as´ara vonatkoz´o felt´etelek ´es k´enyszerek halmaza (l´asd a 2.1-es ´abr´at). Nem funkcion´ alis k¨ ovetelm´ enyek
Term´ekk¨ovetelm´enyek
Szervezetik¨ovetelm´enyek
K¨ uls˝o k¨ovetelm´enyek
Haszn´alhat´os´agi k¨ovetelm´enyek
Sz´all´ıt´asi k¨ovetelm´enyek
Egy¨ uttm˝ uk¨od´esi k¨ovetelm´enyek
Hordozhat´os´agi k¨ovetelm´enyek
Implement´aci´os k¨ovetelm´enyek
Etikai k¨ovetelm´enyek
Megb´ızhat´os´agi k¨ovetelm´enyek
Szabv´any¨ ugyi k¨ovetelm´enyek
Jogi k¨ovetelm´enyek
Hat´ekonys´agi k¨ovetelm´enyek
Teljes´ıtm´enyk¨ovetelm´enyek
Titokv´edelmi k¨ovetelm´enyek Biztons´agi k¨ovetelm´enyek
M´eretk¨ovetelm´enyek
2.1. ´abra. A nem funkcion´alis (min˝os´egi) k¨ovetelm´enyek t´ıpusai, [9] Az oszt´alyoz´as utols´o pontja a rendszerrel szemben t´amasztott dom´en k¨ovetelm´enyek, melyek olyan funkcion´alis, illetve nem funkcion´alis k¨ovetelm´enyek, amelyek
´ ´IZIS ¨ 2. FEJEZET. KOVETELM ENYANAL
13
a felhaszn´al´o k¨ornyezet´eb˝ol erednek. Speci´alis ter¨ uletei lehetnek az informatik´anak, de el˝ofordulhatnak teljesen elt´er˝o ismereteket megk¨ovetel˝o szakter¨ uletek speci´alis fo´ galmait kezel˝o k¨ovetelm´enyek is. Altal´ aban a megrendel˝o ipar´ag´anak egy szak´ert˝oje m˝ uk¨odik k¨ozre a k¨ornyezeti k¨ovetelm´enyek kinyer´esekor.
2.3. Szoftver k¨ ovetelm´ enydokumentum A k¨ovetelm´enyek kinyer´ese ut´an egy dokumentum ker¨ ul el˝o´all´ıt´asra, ami tartalmazza a felder´ıtett k¨ovetelm´enyeket (szoftver k¨ovetelm´enydokumentum). A tov´abbiakban bemutatom az IEEE1 ´altal 1993-ban kiadott szabv´anyt, ami a k¨ovetelm´enydokumentum lehets´eges v´az´ara ad egy javaslatot. Term´eszetesen nem musz´aj az IEEE aj´anl´as´at teljes m´ert´ekig k¨ovetni, viszont egy nagyon j´o kiindul´asi alapot ad.
2.3.1. Els˝ o r´ esz – Az alkalmaz´ as ´ attekint´ ese Ebben a r´eszben a k¨ovetelm´enydokumentum bemutatja az alkalmaz´as eg´esz´et, mintegy teljes k´epet adva arr´ol. Itt kell r¨ogz´ıteni • a rendszer c´elj´at, • azt hogy hogyan illeszkedik az u ´j rendszer a v´allalat u ¨zleti folyamataiba, ´es • a t¨obbi szoftverrendszerrel val´o interakci´o m´odj´at. C´ elok Ebben a fejezetben kell kifejteni a rendszer ´altal´anosan elfogadott c´eljait. Fontos a k¨ovetelm´enyanal´ızis kezd˝o l´ep´es´eben elv´egezni a c´elok felder´ıt´es´et, ugyanis hi´anyuk eset´en neh´ez tov´abbl´epni. A k´erd´es amire v´alaszolni kell: Mi c´elb´ol fejlesztj¨ uk a rendszert? A k´erd´esre a projektben szerepl˝o u ¨zleti szak´ert˝o, a fejleszt´es´ert felel˝os menedzser, illetve az u ¨gyf´el hivatott v´alaszolni. Az ˝o v´alaszaik alapj´an kell a k¨ovetelm´enyeket r¨ogz´ıteni. Hosszadalmas folyamat, mely sor´an a r´esztvev˝oknek kompromisszumokat kell k¨otni¨ uk a c´eljaik el´er´ese ´erdek´eben. 1 Institute
of Electrical and Electronic Engineers
´ ´IZIS ¨ 2. FEJEZET. KOVETELM ENYANAL
14
¨ Uzleti folyamatok Ez a fejezet szolg´al a v´allalat u ¨zleti folyamatainak le´ır´as´ara, ´es az u ´j rendszer ebben bet¨olt¨ott szerep´enek r¨ogz´ıt´es´ere. N´eh´any esetben sz¨ uks´eges lehet ezt a fejezetet k´et r´eszre bontani. Az els˝o r´eszbe a v´allalat m´ar megl´ev˝o folyamatainak le´ır´asa, m´ıg a m´asodikba az u ´j rendszer miatt sz¨ uks´eges j¨ov˝obeni folyamatok le´ır´asa ker¨ ul. Ha azonban nem v´altoztat az u ´j rendszer bevezet´ese a m´ar megl´ev˝o u ¨zleti folyamatokon, akkor maradhat egy fejezetben is. Felhaszn´ al´ oi szerepk¨ or¨ ok ´ es hat´ ask¨ or¨ ok A fejezetben t¨ort´enik meg a v´egfelhaszn´al´oi csoportok felsorol´asa, ´es azok, a szoftverrendszerben bet¨olt¨ott szerep´enek le´ır´asa. Lehet˝os´eg szerint az ¨osszes felhaszn´al´ot fel kell sorolni, aki valamilyen m´odon kapcsolatba lesz hozhat´o a rendszerrel, ugyanis a v´allalat u ¨zleti folyamatai att´ol f¨ ugg˝oen v´altozhatnak, hogy kik fogj´ak haszn´alni a rendszert. Ebben seg´ıthetnek k¨ ul¨onb¨oz˝o folyamat´abr´ak, stb. A k¨ ul¨onb¨oz˝o felhaszn´al´oi csoportoknak k¨ ul¨onb¨oz˝o hozz´af´er´esi jogosults´aga lehet, ezt vil´agosan fel kell t¨ untetni. Egy´ eb rendszerekkel val´ o k¨ olcs¨ onhat´ as Ebben a fejezetben kell le´ırni a rendszer m´as rendszerekkel val´o kapcsolat´at, ´es annak min˝os´eg´et. Abban az esetben ha az u ´j rendszer egy m´ar megl´ev˝o szoftverrendszer alrendszere lesz, akkor sz¨ uks´eges lehet k´et r´eszre bontani ezt a fejezetet. Az egyik r´eszben az alrendszerek k¨oz¨otti interakci´ok r¨ogz´ıt´ese t¨ort´enik meg, m´ıg a m´asik r´eszben az egy´eb rendszerekkel val´o kapcsolatok le´ır´asa ker¨ ul. Nem utols´o sorban r¨ogz´ıteni kell, hogy milyen interf´eszeket biztos´ıt a rendszer a t¨obbi rendszer fel´e, ´es milyen interf´eszeken k´epes a t¨obbivel kommunik´alni. ˝ Osrendszerek cser´ eje Abban az esetben ha egy m´ar megl´ev˝o (˝os)rendszer lecser´el´esek´ent j¨onne l´etre az u ´j rendszer¨ unk, akkor ezt a t´enyt, ´es a technikai r´eszleteket min´el pontosabban r¨ogz´ıteni kell. A technikai r´eszletek bonyolults´aga miatt, sok esetben ez egy k¨ ul¨on´all´o dokumentumban kap helyet. Terminol´ ogia Egy k¨ ul¨on´all´o szakaszban (esetleg egy k¨ ul¨on´all´o dokumentumban) ker¨ ulnek r¨ogz´ıt´esre a k¨ovetelm´enydokumentumban haszn´alt szakkifejez´esek magya´ r´azatai. Erdemes m´eg akkor is csatolni ezt a fejezetet, ha felesleges id˝opocs´ekol´asnak t˝ unik. ´Igy megbizonyosodhatunk arr´ol, hogy mindenki ugyanazt ´erti a dokumentum-
´ ´IZIS ¨ 2. FEJEZET. KOVETELM ENYANAL
15
ban szerepl˝o szakkifejez´esek alatt, mint mi.
2.3.2. M´ asodik r´ esz – Funkcion´ alis k¨ ovetelm´ enyek A k¨ovetelm´enydokumentum ezen r´esze r¨ogz´ıti vil´agosan, ´es prec´ızen hogy mit fog csin´alni a rendszer. A funkcion´alis k¨ovetelm´enyek meg´allap´ıt´as´ahoz c´elszer˝ u a haszn´alati eseteket ´es a kapcsol´od´o UML diagramot elk´esz´ıteni. Abban az esetben ha k¨otetlen sz¨oveggel szeretn´enk le´ırni a k¨ovetelm´enyeket, akkor figyelembe kell venn¨ unk, hogy ez a r´esz t¨obb, mint egy egyszer˝ u k¨ovetelm´enydokumentum – tekinthetj¨ uk szerz˝od´esnek is. Ez´ert fontos, hogy a rendszer egy szolg´altat´asa, vagy funkci´oja se maradjon ki a felsorol´asb´ol. A legt¨obb esetben sok apr´o fejezetre tagol´odik a dokumentumunk ezen r´esze, ugyanis minden egyes funkcionalit´as megk¨oveteli hogy k¨ ul¨on t´argyaljuk. Ha a v´egfelhaszn´al´okat csoportokba osztottuk, akkor ´erdemes ezen csoportok szerint is t´argyalni a k¨ovetelm´enyeket. Hasonl´o m´odon, ha a rendszer t¨obb val´os objektumot kezel, akkor azok szerinti k¨ovetelm´enyeket is csoportos´ıtva illik r¨ogz´ıteni. Van n´eh´any olyan k¨ovetelm´eny, melyeket mindenk´eppen fel kell sorolnunk. Ilyenek a biztons´aggal, k¨ovethet˝os´eggel (ki, ´es mikor v´altoztatott a dokumentumon), illetve az adminisztrat´ıv jelleg˝ u k´erd´esekkel foglalkoz´o k¨ovetelm´enyek. ´ Hat´ ok¨ or Erdemes egy k¨ ul¨on fejezetet sz´anni a hat´ok¨orre (scope), ahol az egyes fejleszt´esi f´azisokban elv´art funkcionalit´as r¨ogz´ıt´ese a c´el. Alternat´ıv megold´ask´ent el˝ofordulhat az is, hogy minden egyes r¨ogz´ıtett funkcionalit´as mell´e oda´ırjuk azt a f´azist ahol el kell k´esz¨ ulnie, viszont ez sokszor az ´erthet˝os´eg rov´as´ara t¨ort´enik. Sokkal jobb megold´as ezt egy k¨ ul¨on fejezetben ¨osszefoglalva taglalni, ´ıgy biztosak lehet¨ unk benne, hogy mindenki megtal´alja majd. Itt ´erdemes a f´elre´ert´esek elker¨ ul´ese v´egett azt is r¨ogz´ıteni, hogy a rendszer els˝o (illetve k´es˝obbi) kiad´asaiban milyen funkcionalit´asok nem fognak szerepelni. Hat´ ekonys´ ag Ha van valamilyen k¨ ul¨onleges hat´ekonys´agi elv´ar´as a rendszerrel ´ kapcsolatosan, akkor azt ebben a fejezetben kell t´argyalnunk. Erdemes szabatosan fogalmazni, ´es ha tehetj¨ uk fejezz¨ uk ki sz´amokban is a hat´ekonys´agi k¨ovetelm´enyeket. Fontos a hat´ekonys´ag m´erhet˝o oldala, hiszen mindenkinek m´ast jelent az, hogy az
´ ´IZIS ¨ 2. FEJEZET. KOVETELM ENYANAL
16
adatb´azist gyorsan kell el´ern¨ unk. Sokkal ´erthet˝obb, ´es pontosabb ha azt mondjuk, az adatb´azist t´ız m´asodpercen bel¨ ul kell el´ern¨ unk. Hasonl´oan az el˝oz˝o fejezethez, a hat´ekonys´agi elv´ar´asokat is beilleszthetj¨ uk az adott funkcionalit´as mell´e k¨ozvetlen¨ ul. Haszn´ alhat´ os´ ag Ha van haszn´alhat´os´agi k¨ovetelm´eny a rendszerrel szemben, akkor azt k¨ ul¨on fejezetben kell r´eszletesebben t´argyalni. Ilyen k¨ovetelm´eny lehet p´eld´aul a felhaszn´al´oi fel¨ ulet kezelhet˝os´eg´enek sebess´ege. Ez a r´esz nagyban hasonl´ıt ´ az el˝oz˝oh¨oz, a k¨ ul¨onbs´egek sokszor nem is fedezhet˝oek fel azonnal. Eppen ez´ert sok esetben ¨osszevont fejezetben tal´alkozunk a haszn´alhat´os´aggal ´es hat´ekonys´aggal. Konkurencia Konkurens m´odon m˝ uk¨od˝o rendszerekn´el fontos r´esze a k¨ovetel´ m´enydokumentumnak ez a fejezet. Erdemes id˝ot sz´anni r´a, ugyanis ´atl´athat´obb´a teszi a rendszert.
2.3.3. Harmadik r´ esz – Fu ek ¨ ggel´ A f¨ uggel´ekben lehet˝os´eg¨ unk ny´ılik minden olyan inform´aci´ot k¨ozz´etenni, mely igaz´ab´ol nem illik egyik kor´abban felsorolt fejezethez sem, viszont az ´erthet˝os´eg szempontj´ab´ol fontos jelent˝os´eggel b´ır.
2.4. Szoftverk¨ ovetelm´ enyek specifik´ al´ as´ anak m´ odszerei Az el˝oz˝oekben taglaltuk milyen form´aban lehet a kinyert k¨ovetelm´enyeket ´atl´athat´o m´odon, hat´ekonyan r¨ogz´ıteni. Viszont fontos aspektus m´eg, hogy milyen m´odszerek ´allnak rendelkez´es¨ unkre a szoftverk¨ovetelm´enyek konkr´et specifik´al´as´ara. Tal´an a legk´ezenfekv˝obb, ´es ehhez m´erten s˝ ur˝ un haszn´alt m´odszer a term´eszetes nyelv (pl. az angol vagy magyar nyelv) haszn´alata. Az ily m´odon, sz¨ovegesen specifik´alt k¨ovetelm´enyek sz´amos probl´em´at vetnek fel. Sokszor ´atl´athatatlan, ´es min´el prec´ızebb m´odon akarjuk megfogalmazni, olvas´asuk ann´al nehezebb is lesz. A funkcion´alis ´es nem funkcion´alis k¨ovetelm´enyek keveredhetnek, ´es szavakkal le´ırva k¨onnyen fogalmaz´odhatnak meg k¨ ul¨onb¨oz˝o k¨ovetelm´enyek egy¨ utt.
´ ´IZIS ¨ 2. FEJEZET. KOVETELM ENYANAL
17
A term´eszetes nyelvi specifik´aci´o ellen sz´ol nyelv¨ unk t´ ulzott flexibilit´asa is. Egy k¨ovetelm´enyt le lehet ´ırni egy r¨ovid t˝omondattal is, de f¨ ugg˝oen a k¨ovetelm´eny le´ır´oj´at´ol, ak´ar egy bekezd´es is sz´olhat ugyanarr´ol a k¨ovetelm´enyr˝ol. ´ A term´eszetes nyelvek eredend˝oen t¨obb´ertelm˝ uek, ´ıgy ez is gondot okozhat. Eppen ez´ert a k¨ovetelm´enyek megfogalmaz´asakor u u jel¨ol´esek ¨gyelni kell az egy´ertelm˝ haszn´alat´ara. A term´eszetes nyelvek el˝obb felsorolt h´atr´anyai ellens´ ulyozhat´oak k¨ovetelm´enysablonok haszn´alat´aval. Az ilyen struktur´alt term´eszetes nyelvek ugyan korl´atozz´ak az ´ır´oi szabads´agot, de j´oval ´atl´athat´obb, k¨ovethet˝obb k¨ovetelm´enydokumentum ´all´ıthat´o vel¨ uk el˝o. Egy egys´eges form´at hat´aroznak meg, ahol k¨ot¨ott terminol´ogi´aval (sablonok ´es standard form´atumok haszn´alat´aval) lehet megfogalmazni a k¨ovetelm´enyeket. P´elda lehet a korl´atoz´asokra, hogy a musz´aj” sz´o helyett mindenhol a ” kell” sz´ot k¨oteles haszn´alni a k¨ovetelm´eny-´ır´o. ” T¨obb alternat´ıv m´odszer is sz¨ uletett a term´eszetes nyelvi specifik´aci´o kiv´alt´as´ara. Haszn´alhatunk a k¨ovetelm´enyek absztrakt le´ır´as´ara form´alis nyelveket, nyelvtanokat (pl. BNF). Az ilyen matematikai elveken alapul´o le´ır´asi m´odok mell˝oznek mindenfajta f´elre´erthet˝o jel¨ol´est, t¨orekednek az egyszer˝ us´egre. Mindezek mellett, a form´alis le´ır´asi m´odokat a megrendel˝o ´altal´aban nem ´erti, ugyanis nem szak´ert˝oje az adott ter¨ uletnek. Ugyan az egy´ertelm˝ u jel¨ol´es a matematikai megfogalmaz´as mellett sz´ol, a megrendel˝ok idegenked´ese miatt nem terjedhettek el. Hasonl´o okok vetettek v´eget a tervle´ır´o nyelvek terjed´es´enek. A tervle´ır´o nyelvek a specifik´aci´ot a rendszer egy m˝ uk¨od´esi modellj´enek seg´ıts´eg´evel adj´ak meg. A haszn´alatos jel¨ol´esek hasonl´oak egy programnyelv absztrakt jel¨ol´eseihez. Tal´an a legnagyobb t´amogatotts´aggal rendelkeznek a formailag egyszer˝ u grafik´at haszn´al´o jel¨ol´esrendszerek. Ebben az esetben a k¨ovetelm´enyek megfogalmaz´asa valamilyen sz¨oveges le´ır´assal kieg´esz´ıtett grafikus nyelv seg´ıts´eg´evel lehets´eges. A grafikus jel¨ol´esek z´aszl´oshaj´oja az objektumorient´alt vil´ag szabv´anyos specifik´aci´os nyelve, az UML2 . A legfrissebb, UML 2.1.2-es verzi´oban m´ar t¨obb mint t´ızf´ele k¨ ul¨onb¨oz˝o diagramt´ıpust defini´al az OMG, melyek kateg´ori´akba ´es alkateg´ori´akba bonthat´ok. Amikor egy rendszer k¨ovetelm´enyeit UML seg´ıts´eg´evel specifik´aljuk, akkor azt t¨obb k¨ ul¨onb¨oz˝o, de logikailag ¨osszetartoz´o diagram seg´ıts´eg´evel tessz¨ uk 2 Object
Management Group (OMG): Unified Modeling Language, [14]
´ ´IZIS ¨ 2. FEJEZET. KOVETELM ENYANAL
18
(´ ugynevezett UML modellt hozunk l´etre). A k¨ovetelm´enyspecifik´aci´ohoz haszn´alatos diagramok a szekvencia diagram (sequence diagram), ´es a haszn´alati esetek (use case diagram) diagramjai. Az UML kritikusai szerint t´ ul nagy ´es bonyolult a szabv´any. A benne tal´alhat´o nagy sz´am´ u diagram j´o r´esz´et nem is haszn´alj´ak, ´es amiket haszn´alnak, azok redund´ans inform´aci´ot t´arolnak. A diagramok ´ertelmez´es´ehez sz¨ uks´eges az UML, ´es az alapvet˝o objektumorient´alt szeml´elet ismerete, ugyanis az UML a szoftverk¨ovetelm´enyek specifik´al´asa sor´an elvesz´ıti a term´eszetes nyelvek kifejez˝oerej´et. Sajnos ezek az ismeretek legt¨obbsz¨or nem ´allnak rendelkez´esre a k¨ovetelm´enydokumentum olvas´oi k¨or´eben. ´ Athidal´ o megold´ast jelent az OPM (Object-Process Methodology, [8]) haszn´alata, mely ´ep´ıtkezik az UML jel¨ol´esrendszer´eb˝ol. Az OPM formailag egyszer˝ u grafik´at (OPD, Object-Process Diagram) term´eszetes nyelvi mondatokkal (OPL, ObjectProcess Language) egyes´ıt, hogy egyetlen integr´alt modellben fejezze ki a rendszerek funkcionalit´as´at, strukt´ ur´aj´at ´es viselked´es´et. Az OPL haszn´alata miatt sz¨ uks´egtelenn´e v´alik a megrendel˝oi oldalr´ol egy u ´j specifik´aci´os nyelv ismerete, ´es ami a legfontosabb, ez nem jelent jelent˝osebb korl´atoz´asokat a k¨ovetelm´enydokumentumra n´ezve.
M´ asodik r´ esz Object-Process Methodology (OPM)
19
20 A szoftverrendszerek ´eletciklus´at fejleszt´esi ´es fenntart´asi tev´ekenys´egek k´ıs´erik. Az u ´j rendszerek specifik´aci´oja, tervez´ese, elemz´ese ´es megval´os´ıt´asa egyre nagyobb kih´ıv´asok el´e ´all´ıtja a rendszertervez˝oket. Mik¨ozben egyre fontosabb´a v´alnak a min˝os´egi szoftverek, addig a k¨olts´eghat´ekonys´agi t´enyez˝ok gyors fejleszt´esre, a term´ek mihamarabbi piacra ker¨ ul´es´ere ¨oszt¨on¨oznek. Ezen trendek ki´altanak egy minden r´eszletre kiterjed˝o m´odszertan´ert, mely k´epes az u ´j rendszerek ´altal felvetett kih´ıv´asoknak megfelelni. Az Object-Process Methodology, vagy r¨oviden OPM, kifejleszt´ese v´alasz erre az ig´enyre. Az OPM betekint´est enged olyan ¨osszetett rendszerek form´alis specifik´aci´oj´aba, amelyek szem´elyeket, t´argyakat ´es implicit tud´ast ¨olelnek fel. Egy form´alis rendszerfejleszt´esi paradigma, a term´ek ´eletciklus´anak ´es evol´ uci´oj´anak t´amogat´as´aval. A szoftverrendszereknek – mint minden rendszernek – h´arom f˝o aspektusa van: funkci´o (mi a szerepe a rendszernek), strukt´ ura (hogy van fel´ep´ıtve) ´es viselked´es (hogyan v´altozik az id˝o m´ ul´as´aval). Mivel az OPM nem tesz fel semmit a k´erd´eses rendszer jelleg´er˝ol, ´ıgy sz´amos k¨ornyezetben alkalmazhat´o. Szoftverrendszerek eset´en j´ol k¨or¨ ulhat´arolhat´o keretrendszert biztos´ıt a teljes ´eletciklus alkalmaz´asa sor´an a k¨ovetelm´enyek korai kinyer´es´et˝ol a rendszer tervez´es´en kereszt¨ ul a bevezet´es´eig ´es karbantart´as´aig. Az OPM formailag egyszer˝ u grafik´at3 term´eszetes nyelvi mondatokkal4 egyes´ıt, hogy egyetlen integr´alt modellben fejezze ki a rendszerek funkcionalit´as´at, strukt´ ur´aj´at ´es viselked´es´et. A m´odszertan k´et le´ır´asi m´odja szemantikailag ekvivalens egym´assal, m´egis agyunk k´et k¨ ul¨onb¨oz˝o r´esz´et, a nyelvi ´es vizu´alis ´eszlel´es ter¨ uleteit ´ dolgoztatja. Eppen ez´ert kifejez˝oereje m´as m´odszertanok f¨ol´e helyezhet˝o. Mindezt k¨onnyen elsaj´at´ıthat´o, ´erthet˝o m´odon teszi, ezzel kiv´al´o eszk¨ozt adva a rendszertervez´es kez´ebe. Az OPM-mel val´o tervez´es programoz´asi nyelvt˝ol f¨ uggetlen, ami teljes m´ert´ekig ´erthet˝o is. Intuit´ıv mivolt´ab´ol ad´od´oan k¨onnyed kommunik´aci´ot tesz lehet˝ov´e a fejleszt´esben r´esztvev˝ok ´es a megrendel˝o k¨oz¨ott. Ezzel egy id˝oben, az OPM formalit´asa lehet˝ov´e teszi a kigondolt rendszer nagy r´esz´enek teljes (´es nem csak csontv´az-szer˝ u”) – automatikusan elv´egezhet˝o – k´odgener´al´as´at ´es adatb´azis ” s´em´aj´anak kialak´ıt´as´at. Objektumok ´es folyamatok jelentik az OPM k´et f˝o ´ep´ıt˝oelem´et. Az egyetlen, e 3 Object-Process 4 Object-Process
Diagram, OPD Language, OPL
21
Object Object
Process(ing) state
(a) Objektum
(b) Folyamat
´ (c) Allapot
2.2. ´abra. Az OPM ´ep´ıt˝ok¨ovei kett˝ot˝ol k¨ ul¨onb¨oz˝o entit´as az ´allapot. Az ´allapot, nev´eb˝ol is ad´od´oan, objektumok valamilyen ´allapot´at jel¨oli, melyet az objektumon bel¨ ul jel¨ol¨ unk. Az objektumok jelenthetnek a tervez´es sor´an l´etez˝o, k´ezzel foghat´o ´es absztrakt objektumokat egyar´ant. A folyamatok valamilyen transzform´aci´o sor´an hat´assal vannak az objektumokra, l´etrehozz´ak, illetve felem´eszthetik ˝oket. Az ´allapotok nem ´allhatnak egymaguk, csak az objektumok jellemz´es´ere, azokkal egy¨ utt l´etezhetnek (az id˝o sor´an az objektumok mindig valamilyen ´allapotban vannak). Az objektumokat t´eglalapokkal, a folyamatokat ellipszisekkel, m´ıg az ´allapotokat lekerek´ıtett sark´ u t´eglalapokkal jel¨olj¨ uk (l´asd a 2.2-es ´abr´at). Az OPM-ben bevezettek bizonyos elnevez´esi konvenci´okat, melyek betart´asa k¨otelez˝o ´erv´eny˝ u. A sz¨oveges reprezent´aci´o angol nyelven t¨ort´enik, ´ıgy ennek megfelel˝oen az objektumok ´es folyamatok neveit nagy kezd˝obet˝ ukkel kell kezdeni, m´ıg a folyamatok elnevez´es´eben utalni kell a folyamat dinamik´aj´ara. Az angol nyelvben ezt az ing toldal´ekkal tehetj¨ uk meg. Abban az esetben, ha elmarad a nagy kezd˝obet˝ u vagy az ing toldal´ek, akkor az objektum eset´en az Object, folyamat eset´en a Process angol szavaknak kell k¨ovetni¨ uk az entit´as nev´et. Az ´allapotokra vonatkoz´oan nincsenek ilyen kik¨ot´esek. Az OPL nyelven ´ırt mondatok foglalt ´es nem foglalt szavakb´ol ´allnak. Nem foglalt sz´onak nevezz¨ uk a rendszer tervez˝oje ´altal bevezetett entit´asok (objektumok, folyamatok ´es ´allapotok) neveit, m´ıg foglalt szavaknak nevezz¨ uk az OPL mondat szerkezet´ehez tartoz´o szavakat, melyek egys´eges mondatt´a szervezik a nem foglalt szavakat. Az OPL mondatban f´ elk¨ ov´ er bet˝ ut´ıpussal szedettek a nem foglalt szavak, ezzel szemben a foglalt szavak nem f´elk¨ov´erek (norm´al antikva bet˝ ut´ıpus´ uak). Egy OPL mondat sokkal ink´abb olvashat´o, mint b´armely m´as szkript-, vagy programoz´asi nyelv. A nyelvtani fel´ep´ıt´es¨ uk hasonl´ıt az angol nyelv nyelvtan´ara, viszont nem k¨oveti teljes m´ert´ekig. Azonban amint l´atni fogjuk, k¨onnyen ´ertelmezhet˝o, vil´agos
22 szintaktik´at k¨ovetnek. Az entit´asok k¨oz¨otti kapcsolatok j´atssz´ak a habarcs szerep´et az OPM-mel val´o ´ep´ıtkez´es sor´an. Az OPM kapcsolatai k´et alapvet˝o csoportra bonthat´oak: • procedur´alis linkek, ´es • struktur´alis rel´aci´ok. A procedur´alis linkekr˝ol a 3. fejezetben, m´ıg a struktur´alis rel´aci´okr´ol a 4. fejezetben lesz sz´o b˝ovebben.
3. fejezet Dinamika A rendszer dinamik´aja a rendszer id˝obeni v´altoz´as´aval foglalkozik. A dinamika defini´alja hogyan m˝ uk¨odik a rendszer, c´elj´anak el´er´ese ´erdek´eben. Az OPM kifejleszt´es´enek fontos motiv´aci´oja volt a fenntarthat´o egyens´ uly megtart´asa a rendszer struktur´alis ´es procedur´alis aspektusa k¨oz¨ott. A m´odszertan egyetlen ¨osszef¨ ugg˝o modellben egyes´ıti a rendszer strukt´ ur´aj´at ´es m˝ uk¨od´es´et, viszont az al´abbi fejezet csak a rendszer dinamikai modellez´es´evel foglalkozik, avagy m´as szavakkal a rendszer m˝ uk¨od´es´evel ´es id˝obeni v´altoz´as´aval.
´ 3.1. Allapotok Az OPM-ben a folyamatok szolg´alnak a rendszer objektumainak valamilyen transzform´al´as´ara. A transzform´aci´o sor´an az objektumon valamilyen v´altoz´as k¨ovetkezik be, ´ıgy ennek jel¨ol´es´ere egy u ´j entit´as bevezet´ese v´alt sz¨ uks´egess´e. 3.1. defin´ıci´ o. Az ´allapot egy olyan szitu´aci´o vagy helyzet, melyben az objektum egy meghat´ arozott ideig l´etezhet. Ezut´an kijelenthetj¨ uk, hogy amikor egy folyamat k¨olcs¨onhat´asba ker¨ ul egy objektummal, akkor az objektum ´allapot´at megv´altoztatja. P´eld´anak ok´a´ert, a L´ampa objektumnak lehet be-, illetve kikapcsolt ´allapota, amit a Bekapcsol´as folyamat megv´altoztathat. Ezenfel¨ ul van m´eg egy megk¨ ul¨onb¨oztetett attrib´ utuma az objektumnak, a st´atusz. 3.2. defin´ıci´ o. A st´atusz az objektum egy olyan attrib´ utuma, amely ´ert´ekeit az objektum ´allapotainak halmaz´ab´ol veszi. 23
3. FEJEZET. DINAMIKA
24
Ennek megfelel˝oen, az OPM v´edett sz´ok´ent kezeli az angol Status sz´ot, mint olyan attrib´ utumot ami t¨obb, k¨ ul¨onb¨oz˝o ´allapot´ert´eket vehet fel. Az ´allapotokra hivatkozhatunk u ´gy is, mint a st´atusz k¨ ul¨onb¨oz˝o ´ert´ekei, vagy slot”-jai. A mindennapi ” nyelvben a st´atusz ´es ´allapot szavak szinonimak´ent szerepelnek, ´ıgy vigy´aznunk kell megfelel˝o haszn´alatukra, ugyanis k´et k¨ ul¨onb¨oz˝o fogalmat jel¨olnek. A tov´abbiakban ha az objektum st´atusz´ara hivatkozunk, akkor azon az objektum ¨osszes felvehet˝o ´allapot´at ´ertj¨ uk, m´ıg az objektum ´allapot´an a st´atusz´anak egy ´ert´ek´ere utalunk. A 3.1-es ´abr´an rendere l´athat´o mik´ent jel¨olj¨ uk az OPD-ben az ´allapotokat ha egy objektumnak egy, kett˝o, illetve enn´el t¨obb ´allapota van. Objektum
Objektum ´all.
´all1
(a)
Objektum ´all2
´all1
(b)
...
´alln
(c)
3.1. ´abra. Az ´allapotok grafikus megjelen´ıt´ese A megfelel˝o OPL mondatok az objektum nev´evel kezd˝odnek, majd a can be foglalt sz´o ut´an, az or foglalt sz´oval elv´alasztva az ´allapotok nevei k¨ovetkeznek. Az OPL mondatot pont z´arja. Az ilyen mondatokat ´allapotfelsorol´as t´ıpus´ u mondatoknak nevezz¨ uk. A 3.1 (b) OPD ´abra sz¨oveges reprezent´aci´oja l´athat´o k¨ovetkez˝o OPL mondatban: Objektum can be ´ all1 or ´ all2 .
3.2. Az input ´ es output link Tegy¨ uk fel, hogy van egy k¨oz¨ons´eges irodai l´amp´ank. Ha a lehet˝o legegyszer˝ ubb m´odon szeretn´enk modellezni l´amp´ank m˝ uk¨od´es´et, akkor azt mondhatjuk, hogy a l´amp´anak van egy bekapcsolt ´es egy kikapcsolt ´allapota. Ha bekapcsoljuk a l´amp´at, akkor az vil´ag´ıt, ´es ´ertelemszer˝ uen ha kikapcsoljuk elalszik. Az OPM nyelv´en megfogalmazva azt mondhatjuk, hogy van egy L´ ampa objektumunk a bekapcsolt ´es kikapcsolt ´allapotokkal. Emellett a l´ampa ´allapot´anak megv´altoztat´as´ahoz egy Vil´ ag´ıt´ as folyamatot is bevezet¨ unk. 3.3. defin´ıci´ o. Ahhoz, hogy egy objektum ´allapot´at megv´altoztassuk, legal´abb k´et ´allapottal kell rendelkezzen. Az input ´allapotba a folyamat hat´asa el˝ott, m´ıg az output
3. FEJEZET. DINAMIKA
25
´allapotba a folyamat hat´asa ut´an ker¨ ul az objektum. Egy folyamat hat´assal van az objektumra, amikor az objektum az input ´allapot´ab´ol az output ´allapot´aba ker¨ ul a folyamat v´egrehajt´ asa ut´an. Visszat´erve kis p´eld´ankra, a Vil´ag´ıt´as folyamat a L´ampa objektumot a kikapcsolt input ´allapot´ab´ol a bekapcsolt output ´allapot´aba viszi, teh´at a folyamat hat´assal van az objektumra. Az el˝obbieket a 3.2-es ´abra (a) r´esze fejezi ki az OPD nyelv´en k´et hasonl´o, h´aromsz¨ogben v´egz˝od˝o ny´ıllal. Az egyik ny´ıl az input ´allapotb´ol a folyamat
L´ampa L´ampa kikapcsolt
bekapcsolt
Vil´ag´ıt´as
Vil´ag´ıt´as
(a)
(b)
3.2. ´abra. Az input ´es output linkek szem´eltet´ese a vil´ag´ıt´as p´eld´aj´an kereszt¨ ul fel´e, m´ıg a m´asik ny´ıl a folyamat fel˝ol az output ´allapot fel´e mutat. 3.4. defin´ıci´ o. Input linknek nevezz¨ uk a megv´altoztatott objektum input ´allapota fel˝ol az objektumra hat´assal l´ev˝o folyamat fel´e ir´any´ıtott kapcsolatot. Output linknek nevezz¨ uk az objektumra hat´assal l´ev˝o folyamat fel˝ol az objektum output ´allapota fel´e ir´any´ıtott kapcsolatot. A 3.2-es ´abra (a) r´esz´evel ekvivalens OPL szkript a k¨ovetkez˝o :
L´ ampa can be kikapcsolt o r bekapcsolt . Vil´ ag´ıt´ a s P r o c e s s cha ng es L´ ampa from kikapcsolt t o bekap− csolt .
A magyar nyelvben igen ritka az ing-re v´egz˝od˝o, ´es ek¨ozben cselekv´est kifejez˝o sz´o, ez´ert legt¨obb esetben ki kel tenn¨ unk az angol Process sz´ot a folyamatnevek OPL szkriptj´eben.
3. FEJEZET. DINAMIKA
26
3.3. A rendszer komplexit´ as´ anak kezel´ ese A legt¨obb OPD ´abra nem annyira egyszer˝ u, mint azt a bevezet˝o p´eld´aban l´at¨ hattuk. Osszetett rendszerekben ´abr´akkal telezs´ ufolt, hatalmas diagrammokkal kell megbirk´oznunk. A komplexit´as kezel´ese az esetek nagy r´esz´eben d¨ont´esek sorozat´at jelenti. Ugyanis nem lehet teljesen bemutatni egy rendszert egyetlen nagy ´abr´an, csak az ´erthet˝os´eg rov´as´ara. Ez ford´ıtva is igaz, nem lehet egy minimaliz´alt, viszont ´erthet˝o ´abr´an, a rendszer eg´esz´et bemutatni. Tervez´esi megfontol´asaink sor´an e k´et param´eter k¨oz¨otti egyens´ uly megtal´al´asa a c´el. A komplexit´as kezel´es´ere a legt¨obb rendszerfejleszt´esi m´odszertan kidolgozott valamilyen strat´egi´at. Az UML, mint a legt¨obb objektumorient´alt m´odszertan, ezt a probl´em´at a rendszer m˝ uk¨od´es´enek ´es strukt´ ur´aj´anak sz´etv´alaszt´as´aval oldja meg, t¨obb k¨ ul¨onb¨oz˝o diagramon ´abr´azolva. Nem u ´gy az OPM, melynek legf˝obb ereje rejlik a rendszer ezen aspektusainak egy¨ uttes megjelen´ıt´es´eben. Az OPM m´odszertan´aban absztrakci´os szinteket vezetett be, melyek k¨oz¨ott be-, illetve kinagy´ıt´assal v´althatunk (in-zooming ´es out-zooming, l´asd a [8]-ban). ´Igy egyetlen r´eszlet sem veszik el, viszont b´armikor, magasabb absztrakci´os szintre l´epve, ´attekinthet˝obb k´ep kaphat´o a rendszer eg´esz´er˝ol. A m´odszertan egyik legegyszer˝ ubb eszk¨oze az absztrakci´ora az objektumok explicit ´allapot-reprezent´aci´oj´anak elnyom´asa. Ez az a´llapotok lekerek´ıtett sark´ u t´eglalapjainak elrejt´es´et jelenti. L´etezik az ´allapot elnyom´asnak inverz” m˝ uvelete is ” (´allapot kifejt´es), amikor a kor´abban elnyomott ´allapotokat u ´jra megjelen´ıtj¨ uk. Egy j´o p´eld´at l´athatunk az ´allapot elnyom´asra a 3.2-es ´abr´an. Az ´abra (a) r´esz´eben l´athat´o L´ ampa objektum ´allapotainak elnyom´asa ugyanazon ´abra (b) r´esz´eben l´athat´o.
3.4. Procedur´ alis linkek A procedur´alis linkek val´os´ıtj´ak meg a folyamatok ´es objektumok, vagy folyamatok ´es ´allapotok k¨oz¨otti kapcsolatokat. Az OPM folyamat-defin´ıci´oja kik¨oti, hogy egy folyamatnak legal´abb egy objektumra hat´assal kell lennie. Ugyan ezenfel¨ ul lehet t¨obb m´asik objektum is, mely l´etfontoss´ag´ u a folyamat lezajl´as´ahoz. ´Igy, a folyamat szempontj´ab´ol megk¨ ul¨onb¨oztethet¨ unk transzform´al´o ´es megenged˝o objektumokat.
3. FEJEZET. DINAMIKA
27
Hasonl´o m´odon megk¨ ul¨onb¨oztethet˝o k´et speci´alis procedur´alis link, a transzform´al´o ´es megenged˝o link.
3.4.1. Transzform´ al´ o linkek Egy folyamat hat´assal lehet egy objektumra, teh´at megv´altoztathatja annak bels˝o ´allapotait. De ez csak egy lehet˝os´eg, emellett sokkal drasztikusabb v´altoz´asokat is el˝oid´ezhet. Az objektum l´etez´ese f¨ ugghet a r´a hat´assal l´ev˝o folyamatt´ol, mivel a folyamat l´etrehozhatja, de meg is sz¨ untetheti azt. Vegy¨ uk p´eld´aul azt az objektumot melynek k´et ´allapota van: l´ etezik, illetve nem l´ etezik. Ezent´ ul att´ol f¨ ugg˝oen, hogy melyik ´allapotot vessz¨ uk input,- illetve output ´allapotnak, besz´elhet¨ unk az objektum megsz¨ untet´es´er˝ol ´es l´etrehoz´as´ar´ol. Az OPM m´odszertanban e k´et ´allapot implicit jelenl´et´evel mindig sz´amolnunk kell. Ezut´an m´ar kimondhatjuk, hogy mit jelentenek az OPM nyelv´en a transzform´aci´o ´es a transzform´al´o linkek. 3.5. defin´ıci´ o. A transzform´aci´o a megv´altoztat´as, termel´es ´es fogyaszt´as ´altal´ anos´ıt´asa, melyet a folyamat, hat´asa sor´an az objektummal tehet. A transzform´al´o linkek a procedur´alis linkek olyan speci´alis esetei, amelyek a transzform´ aci´o esem´enye sor´an k¨ozrej´atsz´o objektumokat ´es folyamatokat k¨otik o¨ssze. Egy objektum ´es egy folyamat k¨oz¨ott egyszerre legfeljebb egy transzform´al´o link helyezkedhet el. Az transzform´al´o linkkel ¨osszek¨ot¨ott objektumok ´allapotait elnyomjuk a m´ar kor´abban ismertetett m´odon. Termel˝ o (result) link Termel˝o, vagy m´as n´even result linknek nevezz¨ uk a folyamat hat´asa sor´an l´etrehozott objektum ´es a fo-
O
P
lyamat k¨oz¨otti ir´any´ıtott kapcsolatot. A kapcsolatot a folyamat fel˝ol, a l´etrehozott objektum fel´e ir´any´ıtott,
3.3. ´abra. Result link
h´aromsz¨ogben v´egz˝od˝o ny´ıllal jel¨olj¨ uk (l´asd a 3.3-as ´abr´at). A result link OPL mondat´aban az els˝o helyen szerepel a termel˝o folyamat, majd a yields kulcssz´o ut´an a l´etrehozott objektum k¨ovetkezik. A 3.3-as ´abra OPD diagramj´aval ekvivalens OPL szkript a k¨ovetkez˝o : P Process yields O.
3. FEJEZET. DINAMIKA
28
Fogyaszt´ o (consumption) link Fogyaszt´o, vagy m´as n´even consumption linknek nevezz¨ uk a folyamat hat´asa sor´an megsz¨ untetett ob-
O
P
jektum ´es a folyamat k¨oz¨otti ir´any´ıtott kapcsolatot. A kapcsolatot a megsz¨ untetett (felem´esztett) objektum
3.4. ´abra. Consumption
fel˝ol, a fogyaszt´o folyamat fel´e ir´any´ıtott, h´aromsz¨og-
link
ben v´egz˝od˝o ny´ıllal jel¨olj¨ uk (l´asd a 3.4-es ´abr´at). A consumption link OPL mondat´aban az els˝o helyen szerepel a fogyaszt´o folyamat, majd a consumes kulcssz´o ut´an a l´etrehozott objektum k¨ovetkezik. A 3.4-es ´abra OPD diagramj´aval ekvivalens OPL szkript a k¨ovetkez˝o : P Process consumes O. Megv´ altoztat´ o (effect) link Megv´altoztat´o, vagy m´as n´even effect linknek nevezz¨ uk a megv´altoztatott objektum, ´es a r´a hat´assal
O
P
l´ev˝o folyamat k¨oz¨otti ir´any´ıtatlan kapcsolatot. Jel¨ol´ese az OPD nyelv´en egy mindk´et v´eg´en h´aromsz¨ogben
3.5. ´abra. Effect link
v´egz˝od˝o ny´ıllal t¨ort´enik (l´asd a 3.5-¨os ´abr´at). A folyamat hat´assal van a vele kapcsolatban ´all´o objektummal, teh´at megv´altoztatja annak ´allapot´at egy nem meghat´arozott m´odon. Az effect link egyen´ert´ek˝ u az ugyanazon objektumot result-, ´es consumption linkkel ¨osszek¨ot˝o kapcsolattal. Visszat´erve az el˝oz˝o l´amp´as p´eld´ara, a 3.2-es ´abra (a) r´esz´eben kifejezett kapcsolat ekvivalens megfogalmaz´asa l´athat´o az effect link alkalmaz´as´aval az ´abra (b) r´esz´eben. Nem megengedett az ´allapot n´elk¨ uli objektumok (´allapotelnyom´as) egyidej˝ u o¨sszek¨ot´ese a transzform´al´o folyamattal input-, ´es output linkekkel. Az ilyen esetekben a megv´altoztat´o linket kell haszn´alnunk. Az effect link OPL mondat´aban az els˝o helyen szerepel a megv´altoztat´o folyamat, majd az affects kulcssz´o ut´an a megv´altoztatott objektum k¨ovetkezik. A 3.5-¨os ´abra OPD diagramj´aval ekvivalens OPL szkript a k¨ovetkez˝o : P Process affects O. Ez alapj´an a m´ar sokat id´ezett l´amp´as p´elda megv´altoztat´o linkkel megval´os´ıtott OPD diagramj´anak OPL mondata a k¨ovetkez˝o egyszer˝ u form´ara hozhat´o :
Vil´ ag´ıt´ a s a f f e c t s L´ ampa.
3. FEJEZET. DINAMIKA
29
H´ıv´ o (invocation) link A h´ıv´o, vagy m´as n´even invocation link kakukktoj´as a procedur´alis linkek k¨oz¨ott, ugyanis egyed¨ ulik´ent, a folyamatok k¨oz¨otti kapcsolat szerep´et t¨olti be. A defin´ıci´oval ellent´etben az invocation link nem v´altoztat meg egyetlen objektumot sem, vagy csak nagyon jelent´ektelen m´odon. M´egis a transzform´al´o linkek k¨oz¨ott t´argyaljuk, ugyanis szerepe nagyon hasonl´o hozz´ajuk. Mivel a rendszer objektumait elhanyagolhat´o m´odon transzform´alja, ´ıgy elhagyhat´o a h´ıv´ o folyamat ´es a megv´altoztatott objektum k¨oz¨otti kapcsolat szeml´eltet´ese, viszont a megv´altoztatott objektumon gyakorolt hat´asa m´as folyamat(ok) lezajl´as´at id´ezheti el˝o. Ez magyar´azza a h´ıv´o” ” elnevez´es l´etjogosults´ag´at. OPD-beli jel¨ol´ese a h´ıv´o folyamatt´ol a h´ıvott folyamat fel´e ir´any´ıtott, h´aromsz¨ogben v´egz˝od˝o vill´am”-mal t¨ort´enik. N´emely CASE eszk¨ozben kett˝oz¨ott h´aromsz¨og” ben v´egz˝od˝o ny´ıllal, vagy g¨ombbel jel¨olik (l´asd a 3.6-os ´abr´at). Az invocation link
P1
P2
P1
(a)
P2
(b)
P1
P2
(c)
3.6. ´abra. A h´ıv´o (invocation) link k¨ ul¨onb¨oz˝o jel¨ol´esi m´odjai OPL mondat´aban az els˝o helyen szerepel a h´ıv´o folyamat, majd az invokes kulcssz´o ut´an a h´ıvott folyamat k¨ovetkezik. A 3.6-os ´abra OPD diagramjaival ekvivalens OPL szkript a k¨ovetkez˝o :
P1 P r o c e s s i n v o k e s P2 P r o c e s s .
3.4.2. Megenged˝ o linkek K´epzelj¨ uk el, hogy sz¨ uks´eg¨ unk van egy k¨onyvre, viszont az u ¨zletben nem kaphat´o. Els´et´alunk az egyik k¨onyvt´arba, kik¨olcs¨on¨ozz¨ uk ´es elolvassuk a k¨onyvet. Tekints¨ unk el a k¨onyv hajtogat´as´ab´ol ´es lapozgat´as´ab´ol ad´od´o amortiz´aci´ot´ol. ´Igy miut´an elolvastuk, visszavissz¨ uk a k¨onyvt´arba (rem´elhet˝oleg) s´ertetlen ´allapotban. Kijelenthetj¨ uk, hogy nem v´altozott semmi, kiv´eve azt a nem elhanyagolhat´o t´enyt, hogy elolvastuk a h˝on ´ah´ıtott k¨onyvet. Az OPM nyelv´en az ilyen kapcsolatokat u ´gy fejez-
3. FEJEZET. DINAMIKA
30
z¨ uk ki, hogy a K¨ onyv objektum megenged˝oje (vagy haszn´alati esete) az Olvas´ as folyamat´anak. 3.6. defin´ıci´ o. Egy folyamat megenged˝o objektum´anak jelen kell lennie a folyamat lefut´as´ahoz, de a folyamat nem lehet r´a hat´assal. K´etfajta megenged˝o objektumot k¨ ul¨onb¨oztet¨ unk meg : 1. u ¨gyn¨ok, ´es 2. eszk¨oz. Az u ¨gyn¨ok kifejez´est a rendszer felhaszn´al´oi sz´am´ara tartja fenn az OPM, akik a rendszerrel, vagy annak egy r´esz´evel tartj´ak a kapcsolatot. 3.7. defin´ıci´ o. Az u ¨gyn¨ok olyan okos megenged˝o objektum, mely vez´erelni tudja az enged´elyezett folyamat lefut´as´at j´ozan ´esszel, illetve c´elorient´alt elk´epzel´eseivel. Az u ¨gyn¨ok a legt¨obb esetben egy konkr´et szem´ely, de lehet egy szervezet, vagy csoport is. L´enyeges szerepet t¨olt be a rendszer modellez´ese sor´an, ugyanis az u ¨gyn¨ok hat´arozza meg a rendszer emberi” r´esz´et. Az OPM u ¨gyn¨ok fogalma nagyon hasonl´o ” az UML haszn´alati esetek diagramj´aban (use case model) haszn´alatos p´alcikaemberrel. Az u ¨gyn¨okkel ellent´etben az eszk¨oz objektumok a rendszer fizikai objektumait jel¨olik, melyek term´eszetesen m´eg mindig nem v´altoznak a folyamatok hat´asa sor´an. 3.8. defin´ıci´ o. Az eszk¨oz egy fizikai, vagy informatikai (nem hum´an) megenged˝ o objektum. Az algoritmusok j´ol p´eld´azz´ak az OPM eszk¨oz fogalm´at. Egym´as ut´an ak´ar v´egtelen sokszor alkalmazhat´oak, m´egsem haszn´al´odnak el. Emellett lehet egy (csak olvashat´o) f´ajl is eszk¨oz az OPM-ben. Azonban ha a f´ajl ´ırhat´o is, m´ar nem nevezhetj¨ uk t¨obb´e eszk¨oz objektumnak, ugyanis ´allapotaira hat´assal lehetnek a folyamatok. A megenged˝o objektumok megenged˝o linkeken kereszt¨ ul kapcsol´odnak a folyamatokhoz. 3.9. defin´ıci´ o. Az OPM m´odszertan megenged˝o linkje egy olyan speci´alis procedur´alis link, amely a folyamatot a megenged˝o objektum´aval k¨oti o¨ssze. ¨ Ugyn ok link ¨
3. FEJEZET. DINAMIKA
31
¨ Ugyn¨ ok, vagy agent link nek nevezz¨ uk azt a speci´alis megenged˝o linket, mely a folyamatot az u ¨gyn¨ok objektum´aval k¨oti ¨ossze. A kapcsolatot az u ¨gyn¨ok objektum fel˝ol a folyamat fel´e ir´any´ıtott, fekete k¨orben
O
P
3.7. ´abra. Agent link
v´egz˝od˝o egyenes vonallal jel¨olj¨ uk (l´asd a 3.7-es ´abr´at). A jel¨ol´est nevezik m´eg fekete ” nyal´ok´anak” is. Az agent link OPL mondat´aban els˝o helyen szerepel az u ¨gyn¨ok objektum, majd a handles foglalt sz´o ut´an a kezelt folyamat neve k¨ovetkezik. A 3.7-es OPD diagramj´aval ekvivalens OPL szkript a k¨ovetkez˝o : O handles P Process. Eszk¨ oz link Eszk¨oz, vagy instrument link nek nevezz¨ uk azt a speci´alis megenged˝o linket, mely a folyamatot az esz-
O
P
k¨oz objektum´aval k¨oti ¨ossze. A kapcsolatot az eszk¨oz objektum fel˝ol a folyamat fel´e ir´any´ıtott, feh´er k¨orben
3.8. ´abra. Instrument link
v´egz˝od˝o egyenes vonallal jel¨olj¨ uk (l´asd a 3.8-as ´abr´at). A jel¨ol´est nevezik m´eg feh´er nyal´ok´anak” is. Az instrument link OPL mondat´aban ” els˝o helyen szerepel a megengedett folyamat, majd a requires foglalt sz´o ut´an az eszk¨oz objektum neve k¨ovetkezik. A 3.8-as ´abra OPD diagramj´aval ekvivalens OPL szkript a k¨ovetkez˝o : P Process requires O.
3.4.3. Felt´ eteles linkek Amint azt kor´abban t´argyaltuk, az objektumok egy vagy t¨obb ´allapottal is rendelkezhetnek, egy objektum adott ´allapota pedig er˝osen befoly´asolja a rendszer m˝ uk¨od´es´et. Vegy¨ unk p´eld´anak egy bankautomat´at (ATM automat´at). Ahhoz, hogy az automat´ab´ol p´enzt vehess¨ unk ki (vagy b´armilyen tranzakci´ot v´egezhess¨ unk) be kell u unk n´egyjegy˝ u k´odunkat. Ha helyes k´odot adunk meg, az automata enged´elyezi ¨tn¨ sz´amunkra a k´ert tranzakci´ot, egy´ebk´ent pedig valamilyen kultur´alt hiba¨ uzenetet ad. Term´eszetesen az el˝obb felv´azolt probl´ema modellez´es´ere is ad megold´ast sz´amunkra az OPM, m´egpedig a felt´eteles linkek form´aj´aban (l´asd a 3.9-es ´abr´at). A Hiteles´ıt´ es objektumnak k´et ´allapota lehet : sikeres, ´es sikertelen. Amennyiben a Hiteles´ıt´ es sikeres volt (a Hiteles´ıt´ es objektum a sikeres ´allapotba ker¨ ult), ak-
3. FEJEZET. DINAMIKA
32
Hiteles´ıt´es
sikeres
Tranzakci´okezel´es
sikertelen
Figyelmeztet´es
Hiteles´ıt´ e s can be siker es o r siker t elen . Tranzakci´ o kezel´ e s o c c u r s i f Hiteles´ıt´ e s i s siker es . Figyelmeztet´ e s o c c u r s i f Hiteles´ıt´ e s i s siker t elen .
3.9. ´abra. Egy bankautomata leegyszer˝ us´ıtett m˝ uk¨od´esi elve kor a Tranzakci´ okezel´ es folyamata k¨ovetekezik be. Egy´ebk´ent, ha a Hiteles´ıt´ es objektum a sikertelen ´allapotba ker¨ ul, a Figyelmeztet´ es folyamat k¨ovetkezik be. Felt´ eteles link Az el˝oz˝o p´elda OPD diagramj´aban k´et procedur´alis link l´athat´o (l´asd a 3.9-es ´abr´at). Els˝o r´an´ez´esre azt mondhatn´ank, hogy mindkett˝o a m´ar kor´abban
O s1
s2
bevezetett eszk¨oz link. Ha egy kicsit jobban megn´ezz¨ uk, akkor l´athatjuk, hogy az eml´ıtett kapcsolatok egy objektum ´allapotain kereszt¨ ul kapcsol´odnak az adott
P
folyamatokhoz, m´ıg egy eszk¨oz link k¨ozvetlen¨ ul az objektumhoz kapcsol´odna. Ezen k¨ ul¨on¨os fajta procedu-
3.10. ´abra. Condition link
r´alis linkeket nevezz¨ uk felt´eteles linkeknek. A felt´eteles, vagy condition link olyan megenged˝o link, amely a folyamatot az eszk¨oz objektum´anak egy meghat´arozott ´allapot´aval k¨oti ¨ossze. A kapcsolatot az eszk¨oz objektum ´allapota fel˝ol a folyamat fel´e ir´any´ıtott, feh´er k¨orben v´egz˝od˝o egyenes vo-
3. FEJEZET. DINAMIKA
33
nallal jel¨olj¨ uk (l´asd a 3.10-es ´abr´at). A link szemantikai jelent´ese szerint az objektum akkor, ´es csak akkor megenged˝oje a folyamatnak, ha az a felt´eteles link kiindul´opontj´anak ´allapot´aba ker¨ ul. A condition link OPL mondata, hasonl´oan az instrument linkhez, folyamat k¨ozpont´ u. A folyamat neve szerepel els˝o helyen, majd az occurs if foglalt szavak ut´an az eszk¨oz objektum k¨ovetkezik. Az is foglalt sz´o ut´an az eszk¨oz objektum kiv´alts´agos ´allapota z´arja a mondatot. Ezek alapj´an a 3.10-es ´abra OPD diagrammal ekvivalens OPL mondata a k¨ovetkez˝o : P Process occurs if O is s2 . ¨ Ugyn ok-felt´ eteles link ¨ A felt´eteles linkhez hasonl´o az u ¨gyn¨ok-felt´eteles link (vagy agent condition link ), azzal a k¨ ul¨onbs´eggel, hogy ebben az esetben a megenged˝o objektum az esz-
O s1
s2
k¨oz helyett u u. Ennek megfelel˝oen jel¨ol´ese ¨gyn¨ok t´ıpus´ az OPD-ben ugyan´ ugy t¨ort´enik mint az u ¨gyn¨ok linknek, de az u ¨gyn¨ok-felt´eteles link nem az objektumhoz,
P
hanem annak egy ´allapot´ahoz csatlakozik. Ebb˝ol ered˝oen OPL mondata is u ¨gyn¨ok centrikus, teh´at az u ¨gyn¨ok objektum nev´evel kezd˝odik. A 3.11-es ´abra OPD
3.11. ´abra. Agent condition link
diagramj´aval ekvivalens OPL szkript a k¨ovetkez˝o alak´ u : O must be s2 for P Process to occur. Az agent condition link kev´esb´e elterjedt, mint a felt´eteles link, ugyanis rendes esetben az u uk¨gyn¨ok objektumoknak nem sz¨ s´eges adott ´allapotba ker¨ ulni¨ uk ahhoz, hogy egy folyamat bek¨ovetkezzen.
3. FEJEZET. DINAMIKA
34
¨ 3.5. Osszefoglal´ as N´ ev
OPD jel¨ ol´ es
OPL mondat O consumes P Pro-
Fogyaszt´o
O
Termel˝o
O
P
P Process yields O.
Megv´altoztat´o
O
P
P Process affects O.
¨ Ugyn¨ ok
O
P
O handles P Process.
Eszk¨oz
O
P
P Process requires O.
H´ıv´o
P1
P2
P
cess.
P1 Process invokes P2 Process.
3.1. t´abl´azat. Procedur´alis linkek
N´ ev
Szimb´ olum
Forr´ as
C´ el
¨ Ugyn¨ ok-felt´eteles
´ Allapot
Folyamat
Felt´eteles
´ Allapot
Folyamat
3.2. t´abl´azat. Felt´eteles linkek.
3. FEJEZET. DINAMIKA
N´ ev
35
Szimb´ olum
Forr´ as
C´ el
¨ Ugyn¨ ok
Objektum
Folyamat
Eszk¨oz
Objektum
Folyamat
3.3. t´abl´azat. Megenged˝o linkek.
N´ ev
Szimb´ olum
Forr´ as
C´ el
Termel˝o
Objektum
Folyamat
Fogyaszt´o
Objektum
Folyamat
Input∗
´ Allapot
Folyamat
Output∗
´ Allapot
Folyamat
Objektum
Folyamat
Megv´altoztat´o∗∗
3.4. t´abl´azat. Transzform´al´o linkek. ∗ : Az input-, output linkek csak p´arban szerepelhetnek. ∗∗ : A megv´altoztat´o linkek eset´eben forr´as ´es c´el egyar´ant lehet objektum ´es folyamat.
4. fejezet Strukt´ ura Az el˝oz˝o fejezetben a rendszer dinamik´aj´aval, az OPM egyik legnagyobb er˝oss´eg´evel foglalkoztunk. Ha a dinamika a rendszer id˝obeni v´altoz´as´at mutatja be, akkor a strukt´ ura a rendszer statikus – id˝oben ´alland´o – viselked´es´et ´ırja le. A strukt´ ura egy viszonylag r¨ogz´ıtett, ´alland´o (hosszan tart´o) kapcsolat a rendszer komponensei, illetve r´eszei k¨oz¨ott. Dov Dori (l´asd [8]) szeml´eletesen fogalmaz amikor azt mondja, hogy a rendszer strukt´ ur´aja egy pillanatfelv´etelnek tekinthet˝o. A pillanatfelv´etel a rendszer egy bizonyos ´allapot´aban k´esz¨ ul, ahol az objektumok k¨oz¨ott valamilyen kapcsolat ´all fenn. Az OPM, ´es ´altal´aban a rendszertervez˝o m´odszertanok c´elkit˝ uz´ese ezt az ´allapotot a lehet˝o legr´eszletesebben ´es m´egis ´erthet˝oen le´ırni. Ellent´etben (p´eld´aul) az UML t´ızf´ele diagramj´aval, az OPM egy ´es ugyanazon diagramon kereszt¨ ul mutatja be a rendszer strukt´ ur´aj´at ´es viselked´es´et. Az al´abbi fejezet a rendszer statikus aspektus´anak vizsg´alat´aval, a rendszer strukt´ ur´aj´anak az OPM m´odszertan´aval t¨ort´en˝o ´abr´azol´as´aval foglalkozik.
4.1. Struktur´ alis rel´ aci´ o Ahhoz, hogy a struktur´alis rel´aci´okr´ol besz´elhess¨ unk, sz¨ uks´eges hogy bevezess¨ uk a rel´aci´o matematikai fogalm´at. 4.1. defin´ıci´ o. Legyenek A1 , A2, . . . , An (n ∈ N) az OPM objektumainak ´es folyamatainak halmazai, ´es R ⊆ A1 × A2 × · · · × An . Az a1 , a2 , . . . , an elemek R rel´aci´oban vannak, ha (a1 , a2, . . . , an) ∈ R. Ekkor R n-v´altoz´os rel´aci´o, m´ıg n = 2 esetben R bin´er rel´aci´o. Ha ∀(i, j = 1 . . . n) : Ai = A j , akkor R homog´en, k¨ ul¨onben inhomog´en rel´aci´o. 36
´ 4. FEJEZET. STRUKTURA
37
Egy rendszerben a struktur´alis rel´aci´ok mindig ´alland´oak, ´ıgy soha nem lehetnek esetlegesek vagy az id˝ot˝ol f¨ ugg˝oek. Az un´aris (teh´at az n = 1 eset) rel´aci´ok nagyon ritk´ak, ´es tekinthet˝oek a bin´aris rel´aci´ok speci´alis eseteinek, hiszen pont az alaphalmaz r´eszhalmazait adj´ak. Az n-v´altoz´os (n ≥ 3) rel´aci´ok pedig n darab bin´aris rel´aci´o halmaz´anak tekinthet˝oek, ahol a rel´aci´o egy elem ´es a marad´ek n−1 elem k¨oz¨ott ´all fenn. A struktur´alis rel´aci´ok jelent´est hordozhatnak k¨ ul¨onb¨oz˝o aspektusaiban (objektumok-objektumok, objektumok-folyamatok, stb. . . . ), de jellemz˝oen csak objektumok ´es folyamatok homog´en rel´aci´oival foglalkozunk a k´es˝obbiekben. 4.2. defin´ıci´ o. A bin´aris struktur´alis rel´aci´ok k´etir´ any´ uak, teh´ at ha a1 ´es a2 egy R rel´aci´oban ´allnak, akkor ez minden esetben azt is jelenti, hogy van egy olyan R′ rel´aci´o, melyre (a2 , a1 ) ∈ R′ . Form´alisan azt mondjuk, hogy (a1 , a2) ∈ R ⇐⇒ (a2 , a1 ) ∈ ∈ R′ . Ebben az esetben az R rel´aci´ot el˝orehalad´o, m´ıg az R′ rel´aci´ot h´atrafel´e halad´o struktur´alis rel´aci´onak nevezz¨ uk. 4.3. defin´ıci´ o. Egy R ⊆ A1 ×A2 bin´er rel´aci´o R−1 inverz´et a k¨ovetkez˝ok´eppen ´ertelmezz¨ uk : R−1 ⊆ A2 × A1 ´es R−1 = {(b, a) | (a, b) ∈ R}. Az R ´es R′ rel´aci´ok lehetnek egym´as inverzei, teh´at R−1 = R′ . Legyen R =sz¨ ul˝oje, m´ıg R′ =gyereke k´et bin´aris struktur´alis rel´aci´o. ´Igy, ha a1 sz¨ ul˝oje a2 , akkor a2 gyereke a1 is teljes¨ ul. Ebben az esetben az R rel´aci´ot nevezz¨ uk el˝orehalad´onak, m´ıg az R′ -t h´atrafel´e halad´onak (vagy ford´ıtva). Mint azt l´attuk, a struktur´alis rel´aci´ok elnevez´eseiben term´eszetes nyelvi elemeket is haszn´alhatunk. Az OPM-ben ez ´altal´aban angol szavak, sz´ok¨ozzel elv´alasztott sorozat´at jelenti. A szavak nem form´alnak teljes, nyelvtanilag t¨ok´eletes mondatokat, m´egis k¨onnyen ´erthet˝o form´aban fejezik ki a rel´aci´o szemantikai jelent´es´et.
4.2. Struktur´ alis linkek Am´ıg az el˝oz˝o fejezetben a rendszer dinamikus m˝ uk¨od´es´et illusztr´al´o kapcsolatokkal, a procedur´alis linkekkel foglalkoztunk, addig a rendszer komponensei (objektumai) k¨oz¨otti szerkezeti viszonyt az u ´gynevezett struktur´alis linkekkel jel¨olj¨ uk. 4.4. defin´ıci´ o. A struktur´alis link egy olyan homog´en bin´aris struktur´alis rel´aci´ o, mely a rendszer entit´asai k¨oz¨otti szerkezeti kapcsolatot grafikus m´odon fejezi ki.
´ 4. FEJEZET. STRUKTURA
38
A struktur´alis rel´aci´ok defin´ıci´oja megengedi, hogy folyamatok k¨oz¨otti rel´aci´or´ol besz´elj¨ unk, viszont err˝ol majd csak a k´es˝obbiekben lesz sz´o. Struktur´alis linkek eset´en mindig objektum-objektum t´ıpus´ u kapcsolatra gondolunk. A struktur´alis linkeket oszt´alyozhatjuk ´altal´anos linkekre, ´es a n´egy alapvet˝o struktur´alis rel´aci´ora, melyek a rendszer objektumai k¨oz¨otti f˝obb szerkezeti kapcsolatok le´ır´as´ara szolg´alnak (l´asd a 4.3-as r´eszt). A struktur´alis linket az egyik objektum fel˝ol, a m´asik objektum fel´e ir´any´ıtott ny´ıllal (−→) jel¨olj¨ uk. A rel´aci´ot valamilyen ´ertelmes c´ımk´evel is ell´athatjuk, melyet az objektumok k¨oz¨ott h´ uz´od´o egyenes felett helyez¨ unk el (l´asd a 4.1-es ´abr´at). Az szereti ´ am Ad´
´ Eva
4.1. ´abra. Egyir´any´ u, c´ımk´ezett struktur´alis link ¨osszekapcsolt entit´asok k¨oz¨otti c´ımk´et ´altal´aban a rendszertervez˝o hat´arozza meg, ezzel is er˝os´ıtve az entit´asok k¨oz¨otti szerkezeti kapcsolatot. ´ am ´es Eva) ´ A 4.1-es ´abra OPD diagramj´aban k´et objektumot (Ad´ l´athatunk, melyek a szereti struktur´alis rel´aci´oban ´allnak egym´assal. Form´alisan ezt u ´gy fe´ am, Eva) ´ jezhetj¨ uk ki (maradva a 4.1-es defin´ıci´o jel¨ol´esein´el), hogy (Ad´ ∈ szereti. A p´elda megfelel˝o OPL mondata a k¨ovetkez˝o :
´ am s z e r e t i Eva ´ . Ad´
Egyir´any´ u (unidirectional) struktur´alis linkek eset´en besz´elhet¨ unk ir´any´ıtotts´agr´ol, ´ıgy el˝ore-, ´es h´atrafel´e halad´o c´ımk´ez´esr˝ol is, b´ar kimondva mindig el˝orehalad´o t´ıpus´ unak jelezz¨ uk a linket (az OPL-ben: Aut´ o gyorsabb mint Bicikli. ´es Bicikli lassabb mint Aut´ o.). Az objektumot, mely fel˝ol a struktur´alis link eredete gyorsabb mint Aut´o
Bicikli
(a)
Aut´o
lassabb mint
Bicikli
(b)
4.2. ´abra. Egyir´any´ u struktur´alis linkek ir´any´ıtotts´ag´anak jel¨ol´ese sz´armaztathat´o, forr´as objektumnak nevezz¨ uk. Azt az objektumot pedig, mely fel´e a
´ 4. FEJEZET. STRUKTURA
39
struktur´alis link nyila mutat, c´el objektumnak nevezz¨ uk. A forr´as objektumt´ol a c´el objektum fel´e ir´any´ıtott struktur´alis link ir´any´ıtotts´ag´at el˝orehalad´onak, m´ıg a c´el objektum fel˝ol a forr´as objektum fel´e ir´any´ıtott linket h´atrafel´e halad´onak mondjuk.
4.2.1. K´ etir´ any´ u struktur´ alis link A 4.2-es ´abr´ar´ol leolvashat´o, hogy az Aut´ o objektum rel´aci´oban ´all a Bicikli objektummal, ´es viszont. Ezt az OPD-ben k´et, ellenkez˝o ir´any´ıtotts´ag´ u egyir´any´ u struktur´alis linkkel jel¨olj¨ uk. A bin´aris struktur´alis linkek antiszimmetrikus tulajdons´aga miatt ebben az esetben e k´et ´abra az OPD-ben helyettes´ıthet˝o egy k´etir´any´ u (bidirectional) struktur´alis linkkel (l´asd a 4.3-as ´abr´at). A k´etir´any´ u struktur´alis link gyorsabb mint Aut´o
Bicikli lassabb mint
4.3. ´abra. K´etir´any´ u, c´ımk´ezett struktur´alis link jel¨ol´ese az OPD-ben a k´et objektum k¨oz¨ott h´ uz´od´o, mindk´et v´eg´eben szigonyszer˝ uen (f´elbev´agott ny´ılban) v´egz˝od˝o egyenessel t¨ort´enik. A ny´ıl megmaradt sz´ara jelzi a struktur´alis rel´aci´o ir´any´ıtotts´ag´at. A helyettes´ıt´es ut´an az ´abra OPL mondata megegyezik a helyettes´ıt´es el˝otti mondattal, ´ıgy a 4.3-as ´abra OPL bekezd´ese a k¨ovetkez˝o lesz:
Aut´ o gyorsabb mint B i c i k l i . B i c i k l i lassabb mint Aut´ o.
Az OPL bekezd´es els˝o mondat´at nevezz¨ uk a k´etir´any´ u struktur´alis link el˝orehalad´o, m´ıg a m´asodik mondatot h´atrafel´e halad´o, OPL mondat´anak. A struktur´alis linkek OPL mondata nagyon egyszer˝ u szintaktikai jel¨ol´est haszn´al. A mondat els˝o hely´en a forr´as objektum neve szerepel, majd ezt a forr´as ´es c´el objektum k¨oz¨ott h´ uz´od´o struktur´alis rel´aci´o elnevez´ese k¨oveti (ez ak´ar t¨obb sz´o konkaten´aci´oja is lehet). A mondat v´eg´en a forr´as objektum neve ´all.
´ 4. FEJEZET. STRUKTURA
40
4.2.2. Struktur´ alis linkek c´ımk´ ez´ ese K´ etir´ any´ u struktur´ alis link transzform´ al´ asa egyir´ any´ uv´ a A k´etir´any´ u struktur´alis linkek mindk´et fel´en elhelyezhet˝oek ´ertelmez´est seg´ıt˝o c´ımk´ek. Az angol (´es n´eha a magyar) nyelvben a ford´ıtott ir´any´ u struktur´alis rel´aci´o c´ımk´eje gyakran az el˝orehalad´o rel´aci´o c´ımk´ej´enek szenved˝o alakj´aban ´all. Ezek a c´ımk´ek sokszor lehetnek redund´ansak, ´ıgy felesleges o˝ket megjelen´ıteni. Ugyanazon forr´as ´es c´el objektum k¨oz¨otti, szemantikailag megegyez˝o jelent´essel b´ır´o el˝orehalad´o ´es h´atrafel´e halad´o struktur´alis rel´aci´okat ´attranszform´alhatjuk egyetlen, egyir´any´ u struktur´alis linkk´e. A 4.4-es ´abra (a) pontj´aban egy k´etir´any´ u struktur´alis linkkel t´arolja Lemez
t´arolja
F´ajl
Lemez
F´ajl
t´arolva van
(a)
(b)
4.4. ´abra. K´etir´any´ u struktur´alis linkek kifejez´ese egyetlen egyir´any´ u struktur´alis linkkel fejezt¨ uk ki azt a t´enyt, hogy a lemezen t´aroljuk a f´ajlt. Ez viszont feleslegesen gener´al k´et ugyanolyan tartalommal b´ır´o OPL mondatot. A probl´ema megold´asa l´athat´o az ´abra (b) r´esz´eben, ahol a k´etir´any´ u struktur´alis linkb˝ol egyir´any´ ut k´esz´ıtett¨ unk, megtartva a k´etir´any´ u el˝orehalad´o (forward) c´ımk´ej´et. Ezzel ugyanazt a t´enyt sokkal egy´ertelm˝ ubben, ´es kevesebb r´aford´ıt´assal fejezt¨ uk ki. K´ etir´ any´ u struktur´ alis link k´ et egyforma c´ımk´ evel ´ am szereti Ev´ ´ at. De mi A 4.1-es ´abr´aban szerepl˝o p´eld´aban kifejezt¨ uk, hogy Ad´ ´ viszontszereti Ad´ ´ amot ? Egy u a helyzet, ha Eva ´jabb rel´aci´ot kell bevezetn¨ unk, azaz tulajdonk´eppen egy k´etir´any´ u struktur´alis linket gy´artunk, mely el˝ore-, ´es h´atrafel´e mutat´o c´ımk´ej´eben ugyanaz1 a rel´aci´o szerepel. Form´alisan megfogalmazva, ha (a1 , a2) ∈ R, akkor (a2 , a1 ) ∈ R is teljes¨ ul. Ez, ha lehet m´eg jobban redund´ans mint az el˝oz˝o p´elda volt. Ugyanarr´ol a szereti rel´aci´or´ol van sz´o, m´egis k´et k¨ ul¨onb¨oz˝o rel´aci´onak t¨ unteti fel az OPD ´es az OPL egyar´ant (l´asd a 4.5-¨os ´abra (a) r´esz´et). 1
Ez ´ıgy nem teljesen igaz, ugyanis az OPD-ben a k´et rel´aci´ o neve ugyan megegyezik, viszont
enn´el t¨ obbet sajnos nem mondhatunk r´oluk.
´ 4. FEJEZET. STRUKTURA
´ am Ad´
szereti
41
´ Eva
´ am Ad´
szeretik egym´ast
´ Eva
szereti
(a)
(b)
4.5. ´abra. K¨olcs¨on¨os struktur´alis rel´aci´ok jel¨ol´ese Az ilyen k¨olcs¨on¨os rel´aci´okat helyettes´ıthetj¨ uk egyetlen el˝orehalad´o c´ımk´evel, megtartva a k´etir´any´ u struktur´alis jel¨ol´est. A megfelel˝o OPL mondatokban is v´altoztatni k´enyszer¨ ul¨ unk hogyha nem akarjuk k´etszer ugyanazt a mondatot a bekezd´esben elhelyezni. A forr´as ´es c´el objektumot az and v´edett sz´oval v´alasztjuk el, majd ezut´an k¨ovetkezik a k¨olcs¨on¨os kapcsolatot le´ır´o kifejez´es. Az ´atalak´ıt´as ered´ am m´enye a 4.5-¨os ´abra (b) r´esz´eben l´athat´o, mely OPL mondata a k¨ovetkez˝o : Ad´ ´ and Eva szeretik egym´ ast. C´ımke n´ elku alis linkek ¨li struktur´ Mind az egyir´any´ u ´es k´etir´any´ u struktur´alis linkek eset´eben el˝ofordulhat, hogy elhagyjuk azok c´ımk´eit. Az ilyen u ¨res, vagy null c´ımk´evel rendelkez˝o rel´aci´ok szemantikai jelent´ese az egyir´any´ u esetben azt fejezi ki, hogy a k´et objektum rel´aci´oban (struktur´alis kapcsolatban) ´all egym´assal. Az OPL nyelv´en a relates to v´edett szavak konkaten´aci´oja fejezik ki ezt a kapcsolatot (l´asd a 4.6-os ´abra (a) r´esz´et). A k´etir´a-
A
relates to
(a)
are equivalent B
B
A
(b)
4.6. ´abra. Cimke n´elk¨ uli struktur´alis linkek megfelel˝oi ny´ u esetben a c´ımke elhagy´as´aval jelezz¨ uk, hogy a k´et (kapcsolatban ´all´o) objektum szemantikailag ekvivalens egym´assal. Ezt az OPL nyelv´en az are equivalent v´edett szavak konkaten´aci´oja fejezi ki, ezzel egy k¨olcs¨on¨os struktur´alis rel´aci´ot alkotva (l´asd a 4.6-os ´abra (b) r´esz´et).
´ 4. FEJEZET. STRUKTURA
42
4.2.3. R´ eszv´ eteli korl´ at ´ es sz´ amoss´ ag Pontos r´ eszv´ eteli korl´ at Az eddigiek sor´an amikor struktur´alis rel´aci´or´ol besz´elt¨ unk, a forr´as ´es c´el objektumok sz´am´at hallgat´olagosan egynek vett¨ uk. Azonban, ha t¨obb mint egy objektum vesz r´eszt a kapcsolatban, akkor ezek sz´am´anak korl´atoz´as´at jel¨oln¨ unk kell. A r´eszv´eteli korl´atot a struktur´alis link ment´en, az adott objektum mellett jel¨olj¨ uk. Az alap´ertelmezett korl´at egy, teh´at ha az objektumnak pontosan egy egyede vesz r´eszt a rel´aci´oban, akkor nem kell a r´eszv´eteli korl´atot ´all´ıtanunk. tartalmaz Gr´af
5 Cs´ ucspont
4.7. ´abra. P´elda : egy gr´af ¨ot cs´ ucspontb´ol ´all. Adott egy gr´af, ´es a annak cs´ ucspontjai. A 4.7-es ´abra Cs´ ucspont c´elobjektum´ara korl´atoz´ast vezett¨ unk be, ami alapj´an a tartalmaz struktur´alis rel´aci´oban a c´elobjektum pontosan ¨ot darab egyede vehet r´eszt. A korl´atoz´as OPL szinten is megjelenik:
Gr´ a f tartalmaz 5 Cs´ u cspont .
Az angol nyelvben az s” bet˝ uvel jel¨olj¨ uk a t¨obbessz´amot, amit term´eszetesen az ” OPL mondatokban is k¨ovetn¨ unk kellene. A kiss´e esetlen Cs´ ucspontoks” le´ır´as´at´ol ” ebben az esetben eltekintettem. Angolul ´ıgy hangzana az el˝obbi OPL mondat :
Graph contains 5 Nodes .
Hasonl´oan figyelni kell a t¨obbes sz´amra (igaz ford´ıtott ir´anyban), ha a r´eszv´eteli korl´atoz´as a forr´as objektum oldal´an jelenik meg. Ebben az esetben a rel´aci´o c´ımk´ej´enek a v´eg´er˝ol t˝ unhet el az egyes sz´amot jelent˝o s” toldal´ek. ´Igy azt a t´enyt, hogy ” k´et gr´afnak k¨oz¨os ponttal kell rendelkeznie, a 4.8-as ´abr´an l´athat´o OPD diagrammal ´es OPL mondattal fejezhetj¨ uk ki.
´ 4. FEJEZET. STRUKTURA
43 2
contains
Graph
Node
4.8. ´abra. P´elda : k´et gr´afnak kell, hogy legyen k¨oz¨os pontja. A megfelel˝o OPL mondat : 2 Graphs contain Node. Param´ eteres r´ eszv´ eteli korl´ at A r´eszv´eteli korl´at nem minden esetben hat´arozhat´o meg olyan egzakt m´odon, mint azt az el˝oz˝o p´eld´akban l´attuk. A nem ismert, vagy bizonytalan r´eszv´eteli korl´at jel¨ol´es´et az angol ´ab´ec´e kisbet˝ uivel tehetj¨ uk meg. Ez a param´eter a null´an´al nagyobb eg´esz sz´amok halmaz´ab´ol veheti fel ´ert´ek´et. Param´eteres r´eszv´eteli korl´atcontains
2n
Graph
Node
4.9. ´abra. P´elda : a gr´af p´aros sz´am´ u cs´ ucsponttal rendelkezik. A megfelel˝o OPL mondat : Graph contains 2n Nodes. tal megfogalmazhat´oak olyan rendszerszint˝ u megstor´ıt´asok, mint hogy egy gr´afnak p´aros sz´am´ u cs´ ucspontja legyen (l´asd a 4.9-es ´abr´at). Az OPM egyfajta v´edett sz´ok´ent” kezeli az m param´etert, ugyanis ugyanazon ” OPD-n bel¨ ul t¨obbsz¨or is el˝ofordulhat megszor´ıt´ask´ent. Az m-et haszn´aljuk a sok (meghat´arozhatatlan) kifejez´es´ere. Tartom´ any-r´ eszv´ eteli korl´ at A rel´aci´oban r´esztvev˝o entit´asok sz´am´at egy als´o-, ´es fels˝o hat´arral rendelkez˝o tartom´anyra is korl´atozhatjuk. Jel¨olj¨ uk ezt a tartom´anyt az [xmin , xmax ] z´art intervallummal, ahol xmin ≤ xmax . Egyenl˝os´eg eset´en pontos r´eszv´eteli korl´atr´ol besz´elhet¨ unk, ´es ugyan´ ugy jel¨olj¨ uk, mint az a 4.7-es ´abr´an l´athat´o. A tartom´any-r´eszv´eteli korl´atot a tartom´any als´o hat´ar´at a fels˝o hat´art´ol kett˝o egym´ast k¨ovet˝o ponttal elv´alasztva jel¨olj¨ uk, a k¨ovetkez˝o m´odon (l´asd a 4.10-es ´abr´at) : xmin ..xmax . ´Igy lehet˝os´eg¨ unk ny´ılik a legfeljebb ´es legal´abb t´ıpus´ u megszor´ıt´asok kifejez´es´ere.
´ 4. FEJEZET. STRUKTURA
44 contains
2..5
Graph
Node
4.10. ´abra. P´elda : a gr´af legal´abb kett˝o, legfeljebb o¨t cs´ ucsponttal rendelkezik. A megfelel˝o OPL mondat : Graph contains 2 to 5 Nodes. Ro esek ¨vid jelo ¨l´ A tartom´any-r´eszv´eteli korl´attal sz´amos, bonyolult megszor´ıt´as kifejez´es´ere is lehet˝os´eg¨ unk ny´ılik. Azonban ez t´ ul bonyolultt´a is teheti a diagrammok olvas´as´at, ez´ert bevezettek n´eh´any r¨ovid szimb´olumot a speci´alis tartom´any-r´eszv´eteli korl´atok ¨ jel¨ol´es´ere. Osszesen hatf´ele r¨ovid´ıt´est defini´alunk, mindegyiket k¨ ul¨onb¨oz˝o kifejez´essel Szimb´ olum
?
∗
(nincs)
1
+
m
0..1
0..m
1..1
1..1
1..m
m..n
an optional
optional
(nincs)
a/an
at least one
many
xmin ..xmax OPL kifejez´ es
4.1. t´abl´azat. Tartom´any-r´eszv´eteli korl´atok r¨ovid´ıtett jel¨ol´ese, ´es megfelel˝o OPL mondataik k¨ ul¨onb¨oztetve meg az OPL mondatokban (l´asd a 4.1-es t´abl´azatot). K´erd˝ojellel ( ?) jel¨olj¨ uk, ha a rel´aci´oban az objektum egy p´eld´anya csak opcion´alisan vesz r´eszt, teh´at vagy r´eszt vesz a kapcsolatban, vagy nem. Csillaggal (∗) viszont olyan opcion´alis kapcsolatot jel¨ol¨ unk, melyben a c´elobjektum tetsz˝oleges sz´am´ u egyede vehet r´eszt (ha r´eszt vesz egy´altal´an). Az eddigieknek megfelel˝oen nem jel¨olj¨ uk a csak egy p´eld´annyal r´esztvev˝o objektumokat. Ha m´egis jel¨olj¨ uk, akkor a megfelel˝o OPL mondatban ki kell tenn¨ unk az angol hat´arozott, illetve hat´arozatlan n´evel˝ot az objektum el´e. A rel´aci´oban legal´abb egy p´eld´annyal r´esztvev˝o objektumok jel¨ol´ese a plusz (+) szimb´olummal t¨ort´enik. Az olyan kapcsolatokat, melyek c´elobjektum´anak egyedeinek sz´am´at nem tudjuk biztosan, az m (many) r´eszv´eteli korl´atoz´assal l´atjuk el. Sz´ amoss´ ag Mind a struktur´alis rel´aci´o forr´as, ´es c´el objektum´anak oldal´an szerepelhet r´eszv´eteli megszor´ıt´as az eddigiekben ismertetett m´odon. A rel´aci´o sz´amoss´ag´at ezen
´ 4. FEJEZET. STRUKTURA
45
megszor´ıt´asok alapj´an defini´aljuk. 4.5. defin´ıci´ o. A sz´amoss´ag (kardinalit´as vagy multiplicit´as) a struktur´alis rel´aci´ o egy olyan attrib´ utuma, mely ´ert´eke a rel´aci´o k´et oldal´an szerepl˝o r´eszv´eteli megszor´ıt´asok k¨oz¨os ´ert´ek´et˝ol f¨ ugg. Ha a struktur´alis rel´aci´o forr´as oldal´an szerepl˝o r´eszv´eteli megszor´ıt´as [ fmin .. fmax ], m´ıg a c´el oldalon szerepl˝o [cmin ..cmax ] alak´ u, akkor a sz´amoss´agot ezen tartom´anyok egym´as ut´an ´ır´as´aval, az [ fmin .. fmax , cmin ..cmax ] tartom´annyal jel¨olj¨ uk. A multiplicit´as az adatb´azistervez´esben, ´ıgy az inform´aci´os rendszerek fejleszt´es´eben is fontos szerepet j´atszik. A r´eszv´eteli korl´atoz´asok – ha csak az el˝oz˝oekben bevezetett r¨ovid´ıtett jel¨ol´eseket haszn´aljuk – 52 -f´ele m´odon szerepelhetnek a rel´aci´okban, teh´at o¨sszesen huszon¨otf´ele sz´amoss´agr´ol besz´elhet¨ unk. Ez ´ıgy t´ uls´agosan bonyolult, ´es ´atl´athatatlan lenne, ez´ert az OPM ´atvette az adatb´azistervez´esben tradicion´alisan haszn´alt multiplicit´asokat, ezzel h´aromra reduk´alva a lehets´eges vari´aci´ok sz´am´at. Ezek alapj´an a struktur´alis rel´aci´ok sz´amoss´aga a k¨ovetkez˝o ´ert´ekek valamelyik´et veheti fel: • egy az egyhez (one-to-one, 1..1), • egy a sokhoz (one-to-many, 1..m), illetve • t¨obb a t¨obbh¨oz (many-to-many, m..m). Egy az egyhez a sz´amoss´aga a rel´aci´onak, ha a kapcsolat mindk´et oldal´an pontosan egy a r´eszv´eteli korl´at ´ert´eke (vagy ha az nincs felt¨ untetve egyik oldalon sem). Egy a sokhoz a rel´aci´o sz´amoss´aga, ha a rel´aci´o egyik oldal´an l´ev˝o r´eszv´eteli korl´at tartom´any´anak minimuma nagyobb null´an´al, ´es ugyanezen tartom´any maximuma egyn´el nagyobb, m´ıg a rel´aci´o m´asik oldal´an pontosan egy a r´eszv´eteli korl´at ´ert´eke. T¨obb a t¨obh¨oz a rel´aci´o sz´amoss´aga, ha a kapcsolat mindk´et oldal´an explicit megadott tartom´any-r´eszv´eteli korl´at minimuma egyn´el nagyobb.
4.2.4. Disztribut´ıv szab´ aly ´ es el´ agaz´ asok A struktur´alis rel´aci´okra ´epp´ ugy teljes¨ ul a disztributivit´as, mint azt az algebr´aban megszoktuk.
´ 4. FEJEZET. STRUKTURA
46
4.6. defin´ıci´ o. Tegy¨ uk fel, hogy a, b ´es c objektumok, ´es R egy struktur´alis rel´aci´ o. Az a R b ´es a R c rel´aci´ok akkor, ´es csak akkor teljes¨ ulnek, ha a R (b, c) is teljes¨ ul. Ezt nevezz¨ uk a struktur´alis rel´aci´ok disztributivit´as´anak. A 4.11-es ´abra (a) r´esz´eben egy olyan OPD diagramot l´athatunk, mely forr´as objektuma (V´ allalat) ugyanazon struktur´alis rel´aci´oval csatlakozik k´et k¨ ul¨onb¨oz˝o objektumhoz. A 4.6-os defin´ıci´o jel¨ol´eseit haszn´alva : a :=V´ allalat, b :=Programoz´ o,
V´allalat
foglalkoztat
foglalkoztat
V´allalat
Programoz´o
Menedzser
foglalkoztat
Programoz´o
Menedzser
(b)
(a)
4.11. ´abra. El´agaz´as az OPD-ben c:=Menedzser ´es R:=foglalkoztat. Ebb˝ol OPL szinten k´et k¨ ul¨on´all´o mondat k´esz¨ ul, mely kifejezi, hogy a v´allalat alkalmazza a programoz´ot ´es a menedzsert egyar´ant. A defin´ıci´o szerint fenn´al a disztributivit´as, amit az a´bra (b) r´esz´eben l´athat´o m´odon jel¨ol¨ unk az OPD-ben. ´Igy elker¨ ulhetj¨ uk az OPD ´es OPL bekezd´es felesleges t´ ulzs´ ufol´as´at, ugyanis a megfelel˝o objektumok neveit az and foglalt sz´oval konkaten´alva egy mondatt´a transzform´alhat´oak az eddigi mondatok. Ez alapj´an az ´abr´aval ekvivalens OPL mondat a k¨ovetkez˝ok´eppen n´ez ki az el´agaz´as elk´esz´ıt´ese ut´an: V´ allalat foglalkoztat Programoz´ o and Menedzser. A disztributivit´as szab´alya kiterjeszthet˝o b´armely n ∈ N sz´amra. ´Igy ak´armennyi azonos forr´as objektummal ´es k¨ ul¨onb¨oz˝o c´elobjektummal rendelkez˝o struktur´alis rel´aci´o ¨osszeolvaszthat´o egy k¨oz¨os rel´aci´ov´a. 4.7. defin´ıci´ o. K´et, vagy t¨obb azonos c´ımk´evel rendelkez˝o struktur´alis link o¨sszeolvaszt´as´at el´agaz´asnak nevezz¨ uk, mely ´ıgy egy azonos c´elobjektumb´ol indul´o struktur´alis linket ´agaztat el t¨obb k¨ ul¨onb¨oz˝o c´elobjektum fel´e. Az el´agaz´as nyel´enek a forr´ as
´ 4. FEJEZET. STRUKTURA
47
objektum sz´el´ehez csatlakoz´o vonalat, m´ıg az el´agaz´ as fogainak a c´elobjektumokhoz csatlakoz´o nyilakat nevezz¨ uk. Az el´agaz´as foka, a ny´elb˝ol kiindul´o fogak sz´am´aval egyezik meg.
4.3. A n´ egy alapvet˝ o struktur´ alis rel´ aci´ o A struktur´alis rel´aci´ok k¨oz¨ott tal´alhat´o n´eh´any speci´alis, a rendszertervez´es sor´an kimelt szereppel b´ır´o rel´aci´o. Az al´abbi struktur´alis rel´aci´okat szokt´ak alapvet˝ o struktur´alis rel´aci´okk´ent is eml´ıteni: • Aggreg´aci´o-r´eszv´etel, • Bemutat´as-jellemz´es, ´ • Altal´ anos´ıt´as-specializ´aci´o, ´es • Oszt´alyoz´as-p´eld´anyos´ıt´as. K¨ot˝ojellel elv´alasztott k´et sz´o jel¨oli minden esetben a n´egy rel´aci´o nev´et. A k¨ot˝ojel el˝ott az el˝orehalad´o (forward), m´ıg a k¨ot˝ojel ut´an a h´atrafel´e halad´o (backward) c´ımk´ez´esre utalva. A rel´aci´o el˝orehalad´o neve a struktur´alis hiearchia gy¨oker´et˝ol lefel´e haladva jellemzi az adott strukt´ ur´at, m´ıg a h´atrafel´e halad´o n´ev a strukt´ ura gy¨okere fel´e halad. Az alapvet˝o struktur´alis rel´aci´ok mindegyik´ehez tartozik forward ´es backward c´ımke, melyek k¨oz¨ ul rendre a term´eszetesebb hangz´as´ u ker¨ ult a k¨oztudatba.
N´ ev
Jel¨ ol´ es
Aggreg´aci´o-r´eszv´etel Bemutat´as-jellemz´es ´ Altal´ anos´ıt´as-specializ´aci´o Oszt´alyoz´as-p´eld´anyos´ıt´as 4.2. t´abl´azat. A n´egy alapvet˝o struktur´alis rel´aci´o jel¨ol´ese
´ 4. FEJEZET. STRUKTURA
48
Mind a n´egy alapvet˝o struktur´alis rel´aci´o jel¨ol´es´ere speci´alis h´aromsz¨og szimb´olumot vezettek be, elhagyva a t¨obbi struktur´alis linkre jellemz˝o ny´ılhegyet (l´asd a 4.2-es t´abl´azatot). Az egyenl˝o sz´ar´ u h´aromsz¨oget, a forr´as ´es c´elobjektumok k¨oz¨ott h´ uz´od´o vonal felez˝opontj´ara helyezz¨ uk, ´es egyik cs´ ucspontj´at a forr´as objektum fel´e ir´any´ıtjuk. A vonalnak ebben az esetben lehet egy, vagy t¨obb t¨or´espontja is. Az Aggreg´aci´o -r´eszv´etel az eg´esz ´es annak r´eszei k¨oz¨otti rel´aci´ot, a Bemutat´asjellemz´es pedig a dolog ´es annak tulajdons´agai (attrub´ utumok ´es m˝ uveletek) k¨oz¨otti ´ anos´ıt´as-specializ´aci´o az ´altal´anos dolog ´es annak speci´aliz´arel´aci´ot jel¨oli. Az Altal´ ci´oja k¨oz¨otti rel´aci´o, m´ıg az Oszt´alyoz´as-p´eld´anyos´ıt´as rel´aci´o szolg´al dolgok egy oszt´alya, ´es az oszt´aly p´eld´anyai k¨oz¨otti kapcsolat jel¨ol´es´ere.
4.3.1. Aggreg´ aci´ o-r´ eszv´ etel (Aggregation-Participation) Nagy rendszerek tervez´ese sor´an fontos a relat´ıve nagy, struktur´alis eg´eszek r´eszeit megad-
sabb absztrakci´os szinten l´ev˝o) dolgok tartalma-
consists of
aggreg´aci´o t´ıpus´ u rel´aci´ok fejezik ki a (maga-
is part of
del´es´et egy igen er˝os rel´aci´oban fejezi ki. Az
A
A
nunk. Az aggreg´aci´o, entit´asok egym´ashoz ren-
z´asi viszony´at egy, vagy t¨obb k¨ ul¨onb¨oz˝o (alacsonyabb absztrakci´os szinten l´ev˝o) entit´assal. A magasabb szinten l´ev˝o entit´ast nevezz¨ uk eg´esznek, vagy fel´ep´ıtm´enynek, m´ıg az alacsonyabb
B
B
(a)
(b)
4.12. ´abra. Aggreg´aci´o-r´eszv´etel
szinten elhelyezked˝oket r´eszeknek, illetve komponenseknek. Az aggreg´aci´o-r´eszv´etel, ugyan´ ugy mint a t¨obbi struktur´alis rel´aci´o, egy el˝orehalad´o ´es egy h´atrafel´e halad´o rel´aci´ob´ol ´all. Az aggreg´aci´ot (consists of ) nevezz¨ uk a rel´aci´o el˝orehalad´o r´esz´enek, mely az eg´esz fel˝ol a r´esz fel´e mutatja be a rel´aci´ot, ´es hivatkozik a r´eszekre. A r´eszv´etel (is part of ) pont az ellenkez˝oje ennek, ugyanis a komponensek ir´any´ab´ol n´ezi a rel´aci´ot, ´es ´ıgy az eg´eszet is (l´asd a 4.12-es ´abra (a) r´esz´et). A rel´aci´o kiemelt jelent˝os´eg˝ u a t¨obbi struktur´alis rel´aci´o k¨oz¨ott, ´ıgy az OPDben a jel¨ol´ese sem a megszokott m´odon t¨ort´enik. Az aggreg´aci´o-r´eszv´etel rel´aci´ot
´ 4. FEJEZET. STRUKTURA
49
egy fekete sz´ın˝ u egyenl˝o sz´ar´ u h´aromsz¨oggel jel¨olj¨ uk, mely egyik cs´ ucsa a rel´aci´o eg´esze fel´e ir´any´ıtott (l´asd a 4.12-es ´abra (b) r´esz´et). Az OPD-ben nem jel¨olj¨ uk a rel´aci´o el˝ore-, illetve h´atrafel´e halad´o c´ımk´eit. Ugyan mind a kett˝o c´ımke haszn´alhat´o lenne az OPL mondatokban, viszont felesleges telezs´ ufolni azt k´et hasonl´o jelent´es˝ u mondattal. Meg´allapod´as szerint, az OPM az el˝orehalad´o rel´aci´o c´ımk´ej´et haszn´alja az aggreg´aci´o-r´eszv´etel rel´aci´o OPL mondat´aban. Ezek alapj´an a 4.12-es ´abra OPD diagramj´aval ekvivalens OPL mondat a k¨ovetkez˝o : A consists of B. Disztributivit´ as Mint minden struktur´alis rel´aci´o, az aggreg´aci´o-r´eszv´etel rel´aci´o is disztribut´ıv – teh´at haszn´alhat´o a m´ar kor´abban megismert el´agaz´as ennek jel¨ol´es´ere. Vegy¨ unk p´eld´anak egy essz´et. Minden dolgozatnak van bevezet´ese, t´argyal´asa ´es befejez´ese. Ezt a tagol´ast l´athatjuk a 4.13-as ´abra (a) r´esz´eben.
Essz´e Essz´e Bevezet´es
T´argyal´as
Bevezet´es
T´argyal´as
(a)
Befejez´es
Befejez´es
(b)
4.13. ´abra. El´agaz´as ´es rendez´es az aggreg´aci´oban
Sorrendis´ eg N´emely esetben fontos lehet r¨ogz´ıteni az eg´esz objektum r´eszeinek valamilyen sorrendj´et. Az ´abra p´eld´aj´an´al maradva, az Essz´ e objektum az eg´esz, ´es a t¨obbi pedig neki r´esze. Egy essz´eben viszont k¨ot¨ott sorrendje van a fenti tagol´asnak, ´ıgy el˝obb k¨ovetkezik a bevezet´es, ´es csak k´es˝obb, a t´argyal´as ut´an j¨ohet a befejez´es. E sorrendis´eg jel¨ol´es´ere az OPD-ben – a 4.13-as ´abra (b) r´esz´eben l´athat´o m´odon – az eg´esz objektum r´eszeinek vertik´alis elrendez´ese ´all rendelkez´es¨ unkre. Az aggreg´aci´o-r´eszv´etel rel´aci´o a Sorrendis´eg (vagy Orderability) attrib´ utum´anak ´ert´eke
´ 4. FEJEZET. STRUKTURA
50
jel¨oli, hogy a rel´aci´oban r´esztvev˝o objektumok sorrendje m´ervad´o-e. Amennyiben az attrib´ utum ´ert´eke ordered, a r´esz objektumokat rendezett sorrendben kell venni. A sorrendis´eg attrib´ utum alap´ertelmezett ´ert´eke unordered, melyet a rel´aci´o jel¨ol´es´ere szolg´al´o fekete h´aromsz¨og mell´e ´ırt ordered kulcssz´oval, vagy az el˝obb le´ırt vertik´alis elrendez´essel lehet m´odos´ıtani. A sorrendis´eg megjelenik az OPD diagramhoz tartoz´o OPL bekezd´esben is, m´egpedig a mondat v´eg´ere ´ırt in this order foglalt szavak konkaten´aci´ojak´ent. A fentiek alapj´an a 4.13-as ´abra (b) r´esz´ehez tartoz´o OPL bekezd´es a k¨ovetkez˝o :
Essz´ e c o n s i s t s o f Bevezet´ e s , T´ a rgyal´ a s , and Befejez´ es , i n t h i s o r d e r .
Tranzitivit´ as Eddig nem esett sz´o a struktur´alis rel´aci´ok egy fontos tulajdons´ag´ar´ol, a tranzitivit´asr´ol. Tranzitivit´as alatt most ugyanazt ´ertj¨ uk, mint az elgebr´aban. 4.8. defin´ıci´ o. Tegy¨ uk fel, hogy a, b ´es c olyan entit´asok, melyeken az R struktur´alis rel´aci´o ´ertelmezve van. Az R struktur´alis rel´aci´o tranzit´ıv, ha a R b ´es b R c teljes¨ ul´ese eset´en az a R c is teljes¨ ul. ´ Altal´ anoss´agban nem jelenthet˝o ki, hogy a struktur´alis rel´aci´ok tranzit´ıvek, viszont az aggreg´aci´o-r´eszv´etel rel´aci´ora term´eszetes m´odon teljes¨ ul a defin´ıci´o. Ez megegyezik a h´etk¨oznapi gondolatmenet¨ unkkel, ugyanis ha az A objektum tartalmazza a B objektumot, ´es a B objektum tartalmazza a C objektumot, akkor az A objektum tartalmazza a C objektumot is. Folyamatok aggreg´ aci´ oja A n´egy alapvet˝o struktur´alis rel´aci´o mindegyike, ´ıgy az aggreg´aci´o-r´eszv´etel rel´aci´o is alkalmazhat´o folyamatokra, nem alkalmazhat´o viszont folyamatok ´es objektumok inhomog´en kapcsolat´anak jellemz´es´ere (objektumok csak objektumokat, folyamatok csak folyamatokat tartalmazhatnak).
´ 4. FEJEZET. STRUKTURA
51
4.3.2. Bemutat´ as-jellemz´ es (Exhibition-Characterization) A mindennapi ´eletben megk¨ ul¨onb¨oztetj¨ uk a minket k¨or¨ ulvev˝o t´argyakat ´es folyamatokat. Jellemz˝okkel, valamilyen r´ajuk jellemz˝o tulajdons´aggal ruh´azunk fel minden egyes dolgot. Az OPM fogalmaival gondolkodva, a dolog jelenthet objektumokat ´es folyamatokat egyA
kal. A dolog kifejezheti egy entit´as statikus ´es
4.9. defin´ıci´ o. Az OPM-ben a dolog fogalm´at haszn´aljuk az objektumok ´es folyamatok ´altal´anos´ıt´as´ara. A dolgot a meta
OPM2 -ben
A
exhibits
dinamikus aspektus´at egyar´ant.
characterizes
ar´ant, viszont nem keverend˝o ¨ossze az entit´asok-
B
B
(a)
(b)
egy el-
lipszisbe z´art t´eglalappal jel¨olj¨ uk, u ´gy mintha egy objektumot ´es egy folyamatot rajzoln´ank egym´as-
4.14. ´abra. Bemutat´as-jellemz´es
ra. Az OPM jellemz˝o (r¨oviden jellemz˝o vagy feature) olyan dolog, mely jellegzetes tulajdons´aggal l´at el egy m´asik dolgot. A defin´ıci´o alapj´an megk¨ ul¨onb¨oztethetj¨ uk a dinamikus viselked´essel rendelkez˝o dolgokat (folyamatok), ´es a statikus viselked´es˝ ueket (objektumok). A sorban m´asodik bemutat´asra ker¨ ul˝o alapvet˝o struktur´alis rel´aci´o a bemutat´asjellemz´es (r¨oviden jellemz´es), mely ¨osszek¨ot k´et dolgot (objektumot, vagy folyamatot). Hasonl´oan a t¨obbi struktur´alis rel´aci´ohoz, a jellemz´es is rendelkezik el˝ore-, illetve h´atrafel´e halad´o rel´aci´oval. Az el˝orefel´e halad´o rel´aci´oj´at bemutat´asnak (exhbition), m´ıg a h´atrafel´e halad´ot jellemz´esnek (characterization) nevezz¨ uk. A rel´aci´oban r´esztvev˝o k´et dolog k¨oz¨ ul az egyik jellemzi a m´asik dolgot, azaz tulajdons´agokkal l´atja el – ˝ot nevezz¨ uk jellemz˝o (feature) dolognak. A m´asik objektum bemutatja (vagy hordozza) a feature dolog ´altal k¨ozvet´ıtett jellemz˝ot – ˝ot nevezz¨ uk hordoz´onak. 4.10. defin´ıci´ o. A statikus viselked´essel rendelkez˝o jellemz˝oket – melyek speci´alis dolgok – attrib´ utumoknak, m´ıg a dinamikus viselked´essel rendelkez˝o jellemz˝oket m˝ uveleteknek nevezz¨ uk. 2A
jel¨ ol´es csak azon az absztrakt szinten jelenik meg, melyet meta OPM-nek nevez¨ unk. A meta
OPM-et az OPM m˝ uk¨ od´es´enek illusztr´al´as´ara hozt´ ak l´etre.
´ 4. FEJEZET. STRUKTURA
52
A jellemz´es igazi kakukktoj´as a t¨obbi alapvet˝o struktur´alis rel´aci´o k¨oz¨ott. Szemben a t¨obbi alapvet˝o rel´aci´oval, inhomog´en, azaz el˝ofordulhat objektum-folyamat ´es folyamat-objektum t´ıpus´ u rel´aci´o is. Pontosabban fogalmazva, n´egyf´ele (22 darab) kombin´aci´oban tal´alkozhatunk a jellemz´essel. Ezek rendre: 1. objektum – attrib´ utum, 2. objektum – m˝ uvelet, 3. folyamat – attrib´ utum, ´es 4. folyamat – m˝ uvelet. A rel´aci´o jel¨ol´es´ere egy speci´alis szimb´olumot vezettek be, ezzel jel¨olve a jellemz´es kiemelt szerep´et. A 4.14-es ´abra (b) r´esz´eben l´athat´o m´odon, egy feh´er egyenl˝o sz´ar´ u h´aromsz¨ogben foglalt kisebb, fekete sz´ın˝ u h´aromsz¨oggel ´abr´azolhatjuk. Az ´abra (a) r´esz´eben l´athat´o a rel´aci´o k´etir´any´ u struktur´alis rel´aci´oval t¨ort´en˝o jel¨ol´ese, ´es a forward, illetve a backward c´ımk´ei. A bemutat´as-jellemz´es rel´aci´o, anal´og m´odon az aggreg´aci´oval, az el˝orehalad´o rel´aci´o c´ımk´ej´et haszn´alja az OPL mondatokban, a h´atrafel´e halad´o rel´aci´o c´ımk´ej´et pedig elhagyjuk. Ennek megfelel˝oen az ´abra OPD diagramj´aval ekvivalens OPL mondat a k¨ovetkez˝o : A exhibits B. A bemutat´as-jellemz´es rel´aci´o egyar´ant disztribut´ıv, ´es tranzit´ıv is. Jellemz˝ ok az objektumorient´ alt ´ es OPM vil´ agban Az OPM m´odszertan´anak egyik legnagyobb er˝oss´ege, hogy mindent objektumk´ent kezel. Objektumk´ent kezeli az attrib´ utumokat, ´es m˝ uveleteket egyar´ant. Ez a legt¨obb objektumorient´alt m´odszertanb´ol hi´anyzik, nem kis dilemm´at okozva ezen m´odszertanok ´ertelmez´es´eben. Vegy¨ unk egy trad´ıcion´alis objektumorient´alt p´eld´at. A rendszerben szerepelhetnek szem´elyek, akik ismerik saj´at nev¨ uket ´es c´ım¨ uket. Minden szem´elynek lehet˝os´ege van elk¨olt¨ozni, ´ıgy c´ım´et megv´altoztathatja. A 4.15-¨os ´abra (a) r´esz´eben l´athat´o a p´elda megfelel˝o UML diagramja, az oszt´alydiagram. Mint az l´athat´o, az UML be´agyazza az oszt´aly attrib´ utumait ´es m˝ uveleteit (az UML-ben nevezik m´eg oszt´alyszint˝ u v´altoz´oknak ´es met´odusoknak is) mag´aba az oszt´alyba. De vajon milyen szerepet j´atszanak az oszt´aly attrib´ utumai ´es met´odusai az UML-ben, ha nem objektumok? Az UML valami m´ask´ent defini´alja az oszt´aly jellemz˝oit, de akkor mit˝ol
´ 4. FEJEZET. STRUKTURA
53
Szem´ely
Szem´ ely
+ N´ev + C´ım
C´ım
N´ev
+ K¨olt¨oz´es( )
K¨olt¨oz´es
(a)
(b)
4.15. ´abra. P´elda : Egy szem´ely jellemz˝oinek kifejez´ese (a) az UML oszt´alydiagramj´aval, (b) OPM seg´ıts´eg´evel objektumorient´alt a m´odszertan? Ezzel a k¨ozismert dilemm´aval az OPM nem szembes¨ ul, ugyanis a vil´agot objektumok, vagyis dolgok” egy nagy szem¨ uveg´en kereszt¨ ul ” szeml´eli. Az oszt´aly, vagyis az OPM paradigma objektum´anak jellemz˝oi lehetnek objektumok ´es folyamatok egyar´ant. Az OPM-ben eleg´ans m´odon jel¨olhetj¨ uk a m˝ uveletek hat´as´at egyetlen integr´alt modellben (l´asd A 4.15-¨os ´abra (b) r´esz´et). Az ´abr´aval ekvivalens OPL bekezd´es3 a k¨ovetkez˝o :
Szem´ e ly e x h i b i t s N´ e v and C´ım, a s w e l l a s K¨ olt¨ o z´ es P r o c e s s . K¨ olt¨ o z´ e s P r o c e s s a f f e c t s C´ım.
Mivel az UML-ben a szem´ely neve nem objektumk´ent szerepel, ´ıgy neh´ez feladat bevezetni a keresztn´ev ´es vezet´ekn´ev attrib´ utumokat. ´ Athidal´ o megold´ask´ent lecser´elhetj¨ uk a n´ev attrib´ utumot a k´et u ´j attrib´ utumra, de ez nem az igazi. Ezzel szemben az OPM az aggreg´aci´o, ´es sorrendis´eg fogalmak seg´ıts´eg´evel k¨onny˝ uszerrel alkot helyes sorrendben t´arolt nevet. Az objektum-attrib´ utum t´ıpus´ u jellemz´ es Az els˝o dolog-jellemz˝o kombin´aci´o az attrib´ utum fogalom szokv´anyos folytat´asa az objektumorient´alt megk¨ozel´ıt´esekhez k´epest, ´es tal´an a legterm´eszetesebb a megfogalmaz´asa. Egy objektum (itt attrib´ utum, A) jellemzi a magasabb szinten 3
Az o u struktur´alis rel´aci´ ok OPL bekezd´es´eben az as well as foglalt ¨sszevont jellemz´es t´ıpus´
szavak konkaten´ aci´ oja v´alasztja el az attrib´ utumok ´es m˝ uveletek felsorol´as´at.
´ 4. FEJEZET. STRUKTURA
54
elhelyezked˝o objektumot (O). Vagy ford´ıtva, O bemutatja az A-t. P´elda az objektum-attrib´ utum t´ıpus´ u jellemz´esre a 4.16-os ´abra (a) r´esz´eben l´athat´o, de l´athattunk p´eld´at m´ar az el˝oz˝o szakaszban is.
Szem´ely
Nyomtat´o
Nyomtat´as
Adat´atvitel
´ Eletkor
Nyomtat´as
Min˝os´eg
K´esleltet´es
(a)
(b)
(c)
(d)
4.16. ´abra. A n´egy dolog-jellemz˝o kombin´aci´o
Az objektum-m˝ uvelet t´ıpus´ u jellemz´ es A m´asodik dolog-jellemz˝o kombin´aci´o az objektum, ´es annak m˝ uvelete. A m˝ uveletet objektumorient´alt k¨ornyezetekben gyakran met´odusnak, vagy szolg´altat´asnak is nevezik. Jelen esetben azt mondjuk, hogy az alacsonyabb szinten l´ev˝o folyamat (m˝ uvelet, M) jellemzi a magasabb absztrakci´os szinten elhelyezked˝o objektumot (O). Ford´ıtva, O bemutatja M-et. Csak olyan folyamatok szerepelhetnek az ilyen t´ıpus´ u jellemz´esekben, melyek egyed¨ ul az ˝oket bemutat´o objektumra vannak hat´assal. Ez azt jelenti, hogy a m˝ uveletnek nem lehet mell´ekhat´asa a hordoz´o objektum hat´ask¨or´en k´ıv¨ ul. A 4.16-os ´abra (b) r´esz´eben l´athatunk egy p´eld´at objektum-m˝ uvelet t´ıpus´ u jellemz´esre. A Nyomtat´ as a Nyomtat´ o egy jellemz˝o m˝ uvelete, mely egyed¨ ul a nyomtat´ora van hat´assal. A folyamat-attrib´ utum t´ıpus´ u jellemz´ es Az el˝oz˝o kett˝o kombin´aci´o anal´og m´odon megfelelt az objektumorient´alt szeml´elet attrib´ utum, illetve met´odus fogalm´anak. Azonban az, hogy egy attrib´ utum folyamatot jellemez, explicit nem szerepel az objektumorient´alt vil´agban. Pedig a
´ 4. FEJEZET. STRUKTURA
55
folyamatoknak is lehetnek tulajdons´agaik, melyekkel jellemezhetj¨ uk ˝oket. ´Igy sz¨ uks´eges bevezetn¨ unk a rendszer modellez´ese sor´an hasznos folyamat-attrib´ utum t´ıpus´ u jellemz´est. Jelen esetben azt mondjuk, hogy egy objektum (attrib´ utum, A) jellemzi a magasabb szinten l´ev˝o folyamatot (F). Ford´ıtva, F bemutatja A-t. A 4.16-os ´abra (c) r´esz´eben l´athatunk egy p´eld´at az ilyen t´ıpus´ u jellemz´esekre (a nyomtat´ast jellemzi min˝os´ege). A folyamat-m˝ uvelet t´ıpus´ u jellemz´ es A negyedik, ´es egyben utols´o dolog-jellemz˝o kombin´aci´o a folyamat-m˝ uvelet t´ıpus´ u jellemz´es. Folyamatok folyamatokkal t¨ort´en˝o jellemz´ese az OPM egyik nehezen megfoghat´o fogalma, ugyanis a mindennapi ´eletben sem igaz´an szoktunk folyamatok m˝ uveleteir˝ol besz´elni. Az el˝oz˝o t´ıpushoz hasonl´oan, nem tal´alhat´o meg explicit az objektumorient´alt megk¨ozel´ıt´esekben. A legegyszer˝ ubben u ´gy foghat´o meg a fogalom, ha az id˝ore tekintettel fogunk hozz´a vizsg´alat´ahoz. Egyed¨ ul egy folyamat hat´asa id´ezhet el˝o v´altoz´ast egy attrib´ utumban, ezzel a folyamat hat´assal lesz az attrib´ utum hordoz´oj´ara is – ´ıgy jellemezve m˝ uveletk´ent a folyamatot. Felfoghat´o ez u ´gy is, hogy az objektum ´allapotai a folyamat hat´asa alapj´an a vizsg´alt t id˝opillanatban k¨ ul¨onb¨oz˝oek, mint egy kor´abbi t −∆t id˝oben. Akkor ´eszlelhetj¨ uk a v´altoz´ast, ha egy dolgot az id˝oben k´et k¨ ul¨onb¨oz˝o ponton vizsg´alunk. Ezek alapj´an a k´esleltet´es egy olyan folyamat, mely megv´altoztatja az ´atvitel folyamat´at (l´asd a 4.16-os ´abra (d) r´esz´et), ezzel jellemezve azt.
´ 4.3.3. Altal´ anos´ıt´ as-specializ´ aci´ o (Generalization-Specialization) Az eddigi struktur´alis rel´aci´okban, bele´ertve az aggreg´aci´ot ´es jellemz´est, mindig ´ dolgok valamilyen csoportj´aval foglalkoztunk. Altal´ anos dolgokr´ol besz´elt¨ unk, hasonl´oan az objektumorient´alt paradigma oszt´aly defin´ıci´oj´ahoz. Persze az oszt´aly fogalm´an´al egy kicsit t¨obbr˝ol – oszt´alyokr´ol, attrib´ utumokr´ol ´es met´odusokr´ol egy¨ uttesen besz´elt¨ unk. A fennmarad´o k´et alapvet˝o struktur´alis rel´aci´o ezen ´altal´anos objektum-, ´es folyamatcsoportok speci´aliz´aci´oj´aval ´es egyedeivel foglalkozik.
´ 4. FEJEZET. STRUKTURA
56
Az ´altal´anos´ıt´as-specializ´aci´o dolgok, ´es azok t´ıpusai k¨oz¨otti struktur´alis rel´aci´o. A szakiroda-
A
A
lom r¨oviden eml´ıti m´eg gen-spec n´even is (l´asd is a
j´an, az ´altal´anos struktur´alis rel´aci´ok jel¨ol´es´et˝ol
generalizes
a [8]-as 171. oldal´an). Kit¨ untetett szerepe alap-
elt´er˝oen, a dolog ´es t´ıpusa k¨oz¨ott h´ uz´od´o egyenesen elhelyezett feh´er sz´ın˝ u egyenl˝o sz´ar´ u h´aromsz¨oggel jel¨olj¨ uk (l´asd a 4.17-es ´abra (b) r´esz´et).
B
B
(a)
(b)
A rel´aci´o el˝orehalad´o r´esze az ´altal´anos dologt´ol a speci´alisig tart, amit a generalizes” c´ım” k´evel l´attak el. A ford´ıtott ir´any rel´aci´oj´anak
4.17. ´abra. ´ Altal´ anos´ıt´as-specializ´aci´o
c´ımk´eje pedig az is a” szavak konkaten´aci´ojak´ent ´ertelmezett. Meg´allapod´as sze” rint a gen-spec rel´aci´o az OPL-ben a h´atrafel´e halad´o rel´aci´o c´ımk´ej´et haszn´alja. Az angol kifejez´es sokkal jobban jellemzi ´ıgy a rel´aci´o szemantik´aj´at (B is an A ≡ B az egy A). Ak´ar t¨obbsz¨or¨os specializ´aci´o is elk´epzelhet˝o, ugyanis ´erv´enyes (mint
Vad´aszkutya
az ¨osszes alapvet˝o struktur´alis rel´aci´o eset´eben) a disztributivit´as szab´alya. A szab´aly ´ertelm´eben a speci´alis dolgokat el´agaz´assal k¨othetj¨ uk az ´altal´anos dologhoz, a gen-spec szim-
Vizsla
Kop´o
Kotor´ekeb
b´olum´at (△) pedig az el´agaz´as fogainak csatlakoz´as´ahoz kell illeszten¨ unk. A disztribut´ıv szab´aly alkalmaz´as´ara
4.18. ´abra. P´elda : Vad´aszkuty´ak specializ´aci´oja
l´athatunk egy p´eld´at a 4.18-as ´abra OPD diagramj´an, ahol a vad´aszkuty´akat h´aromf´ele speci´alis csoportra, vizsl´akra, kop´okra ´es kotor´ekebekre osztottuk. Az ´abra OPD diagramj´anak megfelel˝o OPL bekezd´es h´arom k¨ ul¨onb¨oz˝o mondatot kellene tartalmazzon, rendre jel¨olve a kutyafajt´ak specializ´aci´oj´at. Ezzel szemben az OPM ism´et, mint ezid´aig t¨obbsz¨or is, ¨osszevonja az azonos mondatokat : Vizsla, Kop´ o, and Kotor´ ekeb are Vad´ aszkutya. Term´eszetesen, illeszkedve a h´etk¨oznapi ´elet¨ unkh¨oz, a gen-spec rel´aci´o tranzit´ıv
´ 4. FEJEZET. STRUKTURA
57
is. Teh´at az ´altal´anos dolog speci´aliz´aci´oj´anak specializ´aci´oja, speci´alis esete az ´altal´anos dolognak. N´ezz¨ uk egy Kicsit szeml´eletesebben, egy p´eld´an kereszt¨ ul a gen-spec tranzitivit´as´at. Ha
Vizsla i s a Vad´ a szkutya . Vad´ a szkutya i s a Kutya .
akkor teljes¨ ul az is, hogy
Vizsla i s a Kutya .
Folyamatok speci´ aliz´ aci´ oja A gen-spec rel´aci´o ugyan´ ugy alkalmazhat´o az OPM folyamataira, mint objektumaira. Alkothatunk olyan folyamatokat, melyek egy ´altal´anos folyamat speci´alis eset´enek tekinthet˝oek (p´eld´aul a Port¨ orl´ es ´es Porsz´ıv´ oz´ as speci´alis Takar´ıt´ as-nak tekinthet˝o). Az OPD-ben nincs k¨ ul¨on jel¨ol´ese a folyamatok specializ´ac´oj´anak – ugyan´ ugy ´abr´azolhat´o, mint az objektumok eset´eben. Azonban az OPL m´ar tartalmaz kisebb v´altoztat´asokat. F˝oleg az angol nyelvhez igazod´as miatt, a rel´aci´o h´atrafel´e halad´o c´ımk´ej´eb˝ol az (angol) a” hat´arozatlan n´evel˝o kiker¨ ul az OPL-b˝ol. Hasonl´o okokb´ol ” kifoly´olag, az ¨osszevont mondatok v´eg´er˝ol elt˝ unik a t¨obbessz´amot jel¨ol˝o s” rag (az ” angol ing”, folyamatot jelz˝o k´epz˝o nem ker¨ ulhet t¨obbessz´amba). ” ¨ ¨ Or okl˝ od´ es Figyelemrem´elt´o el˝onye a gen-spec rel´aci´o haszn´alat´anak az implicit ¨or¨okl˝od´es amit el˝oid´ez. N´ezz¨ uk a legt¨obb objektumorient´alt paradigma o¨r¨okl˝od´es fogalm´at. ¨ ok¨olhet¨ Or¨ unk oszt´alyszint˝ u v´altoz´okat, met´odusokat – viszont a fogalom semmit sem mond az ˝os oszt´alyt megv´altoztat´o folyamatokr´ol, illetve a dinamik´ar´ol. Ezzel szemben az OPM ¨or¨okl˝od´es fogalma egy kicsit t´agabb l´at´oteret biztos´ıt a tervez˝o sz´am´ara. 4.11. defin´ıci´ o. A gen-spec rel´aci´o szemantikai jelent´ese induk´alja az ¨or¨okl˝od´es fogalm´at. A rel´aci´o forr´as oldalon l´ev˝o (´altal´anos) dolg´at az ¨or¨okl˝od´es ˝os´enek, m´ıg a
´ 4. FEJEZET. STRUKTURA
58
c´el oldalon l´ev˝o (speci´alis) dolgot az ¨or¨okl˝od´es ¨or¨ok¨os´enek nevezz¨ uk. Az OPM-ben az objektumok ´es folyamatok mellett ¨or¨okltethet˝oek a jellemz˝ok (attrib´ utumok ´es m˝ uveletek) ´es a rel´aci´ok (struktur´alis ´es procedur´alis) egyar´ant. Az unk az ¨or¨ok¨os¨okre oly m´odon, mintha az ˝os szerep´et j´at¨or¨okl˝od´es sor´an tekinthet¨ szan´ak az rendszerben. Implicit megkapj´ak az ˝os ¨osszes kapcsolat´at, ´ıgy r´eszt vesznek ugyanazokban a rel´aci´okban, melyekben az ˝os is r´eszt venne, ´es ugyanazon ´allapotokkal rendelkeznek, mint az ˝os (fel¨ ul´ır´as – overriding). Alul-, ´ es felu al´ as ¨lspecifik´ Az objektumok ´es folyamatok specializ´aci´oja megengedi, hogy az ´altal´anos folyamaton ´es objektumon kereszt¨ ul ´ertelmet adjunk a specializ´alt objektumok dinamikus aspektus´anak. N´ezz¨ uk a 4.19-es ´abra (a) r´esz´et, melyben az Ed´ eny objektum eszk¨oze a F˝ oz´ es folyamatnak. Emellett az ´abra (b) r´esz´eben az Ed´ eny objektum o¨sszes speci´aliz´aci´oja eszk¨oze a F˝ oz´ es megfelel˝o specializ´aci´oinak. Az OPM-ben egyik megEd´eny
Ed´eny
F˝oz´es
Grills¨ ut˝o
Grills¨ ut˝o
Grillez´es
Serpeny˝o
F˝oz´es
S¨ ut´es
Grillez´es
Serpeny˝o
(a)
S¨ ut´es
(b)
4.19. ´abra. P´elda : alul-, ´es fel¨ ulspecifik´al´as old´as sem szerencs´es, s˝ot helytelen. Az ´abra (a) r´esz´eben alulspecifik´alt, m´ıg a (b) r´eszben fel¨ ulspecifik´alt OPD diagram szerepel. Az alulspecifik´al´as ebben a kontextusban azt jelenti, hogy a rendszerterv olvas´oja csak nehezen tudja eld¨onteni, hogy az Ed´ eny objektum mely specializ´aci´oi sz¨ uks´egesek a F˝ oz´ es folyamat specializ´aci´oinak lefut´as´ahoz (mik az eszk¨oz¨ok). A fel¨ ulspecifik´alt OPD viszont t´ ul sok inform´aci´ot hordoz, kevesebb is elegend˝o lenne. A k´et ´altal´anos entit´as k¨oz¨otti procedur´alis link feleslegess´e v´alik, amint a specializ´alt entit´asokat ¨osszekapcsoltuk. A helyes megold´as az ´abra (a) r´esz´eben l´athat´o eszk¨oz link elhagy´asa, ´es a megfelel˝o speci´alis entit´asok eszk¨oz linkkel val´o ¨osszekapcsol´asa lenne.
´ 4. FEJEZET. STRUKTURA
59
4.3.4. Oszt´ alyoz´ as-p´ eld´ anyos´ıt´ as (Classification-Instantiation) A t´argyal´asban utols´o helyre ker¨ ult, b´ar az Vizsla
l´od´asunk t´argy´at – az egyedet – azonos nev˝ u objektumok egy csal´adj´ab´ol ragadjuk ki. A 4.20-as ´abr´an, egy p´eld´an kereszt¨ ul mutatom be a p´el-
Vizsla
classifies
´all´o az oszt´alyoz´as-p´eld´anyos´ıt´as rel´aci´o. Vizsg´a-
is an instances of
objektumorient´alt megk¨ozel´ıt´esekhez legk¨ozelebb
d´anyos´ıt´ast. A Vizsla objektum jel¨oli az ¨osszes vizsla oszt´aly´at, melynek egy j´ol meghat´arozott egyede Bety´ ar (a magyar vizsla). Amint az ´abr´a-
Bety´ar
Bety´ar
(a)
(b)
r´ol leolvashat´o, a p´eld´anyos´ıt´as rel´aci´ot egy feh´er
4.20. ´abra.
h´aromsz¨ogben elforgatott, kisebb, fekete h´arom-
Oszt´alyoz´as-p´eld´anyos´ıt´as
sz¨oggel jel¨olj¨ uk. A rel´aci´o ´ertelmez´es´enek aj´anlott ir´anya a lentr˝ol felfel´e, teh´at a h´atrafel´e halad´o ir´any. Az ilyen st´ılus´ u, p´eld´anyos´ıt´o mondatok az is an instance of foglalt szavakkal v´alasztj´ak el az oszt´aly egyed´et˝ol. A p´elda OPD diagramj´aval ekvivalens OPL mondat a k¨ovetkez˝o : Bety´ ar is an instance of Vizsla. A p´eld´anyos´ıt´as rel´aci´o is disztribut´ıv, ´ıgy besz´elhet¨ unk t¨obb OPL mondat ¨osszevon´as´ar´ol. A t¨obbes sz´amot ugyan´ ugy kezeli, mint az el˝oz˝o alapvet˝o struktur´alis rel´aci´ok, teh´at az are instances of foglalt szavak konkaten´aci´oj´ara v´altozik a rel´aci´o h´atrafel´e halad´o neve. Az oszt´alyoz´as-p´eld´anyos´ıt´as rel´aci´o ´ertelmezve van objektumok ´es folyamatok k¨oz¨ott egyar´ant. Az eddigiek sor´an mindig dolgok valamilyen oszt´aly´ar´ol besz´elt¨ unk, legyen az objektumok vagy folyamatok oszt´alya. Amikor objektumokr´ol besz´elt¨ unk, akkor objektumok egy olyan mint´aj´ara utaltunk, melyhez nagyon hasonl´o u ´j objektumokat gener´alhatunk. Nem besz´elt¨ unk m´eg az egyed fogalm´ar´ol az OPM-ben. 4.12. defin´ıci´ o. Dolgok sablona az oszt´aly. Az oszt´aly egy egy´ertelm˝ uen azonos´ıthat´o tagj´at az oszt´aly egyed´enek nevezz¨ uk. A dolog lehet objektum, vagy folyamat. Az oszt´aly ennek megfelel˝oen lehet objektumoszt´aly, ´es folyamatoszt´aly. Hasonl´oan, az egyed lehet objektumegyed, ´es folyamategyed. Az objektumegyedek az objektumoszt´aly, m´ıg a folyamategyedek a
´ 4. FEJEZET. STRUKTURA
60
folyamatoszt´aly egy´ertelm˝ uen azonos´ıthat´o p´eld´anyai. Az oszt´aly ´altal meghat´arozott sablon mindent tartalmaz ami ¨or¨ok¨olhet˝o volt. Mint m´ar l´attuk, ezek nemcsak jellemz˝ok, de struktur´alis, illetve procedur´alis rel´aci´ok is lehetnek. Egy egyed nem o¨r¨ok¨olhet olyan jellemz˝ot, melyet oszt´alya nem hordozott, ´ıgy nem lehet olyan ´allapota sem, mely oszt´aly´anak sincs. Egy objektumegyed egy´ertelm˝ uen azonos´ıthat´o a rendszerben, ´ıgy lehet˝ov´e v´alik, hogy egy id˝opillanatban kiragadva megvizsg´alhassuk attrib´ utumainak ´allapotait.
¨ 4.4. Osszefoglal´ as N´ ev
OPD jel¨ ol´ es
Struktur´alis rel´ aci´ o
O1
(felirat n´elk¨ ul)
O1
K´etir´ any´ u struktur´a-
O1
lis rel´ aci´ o
hivatkozik
megel˝ozi k¨oveti
O1
(felirat n´elk¨ ul)
OPL mondat O2
O1 hivatkozik O2 .
O2
O1 relates to O2 .
O2
O1 megel˝ ozi O2 . O2 k¨ oveti O1 .
O2
O1 and O2 are equivalent.
´ 4.3. t´abl´azat. Altal´ anos struktur´alis rel´aci´ok
(a) Aggreg´aci´ o
(b) Jellemz´es
´ (c) Altal´ anos´ıt´as (d) P´eld´ anyos´ıt´as
4.21. ´abra. A n´egy alapvet˝o struktur´alis rel´aci´o jel¨ol´ese
Struktur´ alis rel´ aci´ o
Egy OPD
Kett˝ o
OPL
OPD
OPL
B
B
A
A
C
D. C
D
A
B and C are As. B
A
C
B, C, and D are As. B
C
D
A
A
B is an instance of
B and C are in-
B, C, and D are in-
stances of A.
A. B
and D.
A exhibits B, C, and B
C
B is an A.
B
D
A
A
B
C
C B
A
Oszt´ alyoz´ as-p´eld´ anyos´ıt´ as
B
A exhibits B and
A exhibits B.
´ Altal´ anos´ıt´ as-specializ´ aci´ o
and C
A consists of B, C,
A
B
OPL
A consists of B
A consists of B.
Bemutat´ as-jellemz´es
OPD
A
A
Aggreg´aci´ o-r´eszv´etel
H´ arom
´ 4. FEJEZET. STRUKTURA
Lesz´ armazottak sz´ ama
C
stances of A. B
C
D
4.4. t´abl´azat. A n´egy alapvet˝o struktur´alis rel´aci´o t¨obb lesz´armazott eset´en 61
Harmadik r´ esz Szoftverko enyek ¨vetelm´ modellez´ ese az OPM seg´ıts´ eg´ evel – DEMO alkalmaz´ as –
62
63 Neh´ez egy komplex rendszer m˝ uk¨od´es´et k´ıv¨ ul´all´oknak ´erthet˝oen elmagyar´azni, de bemutat´asa sokszor komoly fejt¨or´es okozhat az adott ter¨ uleten j´artas szak´ert˝ok sz´am´ara is. Pr´ob´aljuk egyszer˝ us´ıteni a rendszer komplexit´as´at, kiragadjuk a f˝o gondolatokat, illetve ´altal´anos´ıtjuk a m˝ uk¨od´es´et. Ilyen estekben, m´eg ha nem is tudunk r´ola, valamilyen modellt alkalmazunk. Legt¨obb esetben a modell szorosan kapcsol´odik a le´ırt rendszerhez, teh´at specifikus jelrendszert alkalmaz. Mer˝oben m´as jelrendszere van az ´ep´ıt´eszetnek, a futballnak, vagy ak´ar az informatik´anak is, viszont kijelenthetj¨ uk, hogy szoftverrendszerek eset´eben sokkal ink´abb sz¨ uks´eg¨ unk van az absztrakci´ora mint m´as szakter¨ uletek eset´eben. M´ıg az ´ep´ıt´esz konkr´et tervrajzokat k´esz´ıt, addig a szoftverm´ern¨ok pr´ob´alja a szoftvert a lehet˝o legabsztraktabb m´odon ´abr´azolni, modellt k´esz´ıt. A modellt, mint azt a 2.4 fejezetben m´ar l´athattuk, t¨obbf´elek´eppen fel´ep´ıthetj¨ uk. De gondoljunk csak bele, ha gyorsan ´es ´erthet˝oen szeretn´enk az inform´aci´ot tov´abbadni, szinte minden esetben valamilyen k´epi megjelen´ıt´es adja a leggyorsabb eredm´enyt. Erre ´ep¨ ulnek korunk rekl´amjai, illetve a h´etk¨oznapi ´elet sz´amos ter¨ ulet´en er˝oteljesen alkalmazzuk a prezent´aci´okat, mint a k´epi inform´aci´o-tov´abb´ıt´as egyik legegyszer˝ ubb m´odj´at. Ezzel ellent´etben az informatik´aban a legelterjedtebb modellez˝o eszk¨oz a mai napig a term´eszetes nyelv, illetve a term´eszetes nyelv vegyes haszn´alata k´epi eszk¨oz¨okkel. A modellez´es sor´an modelleket ´ep´ıt¨ unk fel, legink´abb a tervez´esi f´azisban a k¨ovetelm´enyek kinyer´ese sor´an. K´es˝obb a fel´ep´ıtett modellt a k¨ovetelm´enydokumentumban fejtj¨ uk ki. A k¨ovetelm´enydokumentum a rendszer legfontosabb dokumentuma, ´es ennek megfelel˝oen elv´arhat´o a prec´ız ´es l´enyegre t¨or˝o meg´ır´asa. Nagy rendszerek eset´eben ez rendk´ıv¨ ul sok id˝ot vesz ig´enybe, nem is besz´elve a redund´ans le´ır´asi m´odb´ol ered˝o k´enyelmetlen m´odos´ıthat´os´agr´ol. T¨obb sz´az oldal sz´araz, szakzsargonnal telet˝ uzdelt sz¨ovegre kell gondolnunk, melyet a rendszert fejleszt˝o m´ern¨ok¨ok is csak fel¨ uletesen olvasnak el (ha egy´altal´an elolvass´ak). E dokumentumban m´ar egy kis m´odos´ıt´as is t´ ul sok id˝ot em´eszt fel. Meg kell keresni a m´odos´ıtand´o sz¨ovegr´eszt, majd az ¨osszes kapcsol´od´o ponton el kell v´egezni ugyanazt a m´odos´ıt´ast. Unalmas munka, ´es sok lehet˝os´eg van a hib´az´asra. El´eg csak egy helyen meghagyni a r´egi inform´aci´ot, ´es m´ar az is komoly probl´em´akat sz¨ ulhet a k´es˝obbiekben. Az el˝oz˝o r´eszben bemutatott OPM m´odszertan´anak felhaszn´al´as´aval elk´epzel-
64 het˝o a szoftver k¨ovetelm´enydokumentum´anak Object-Process Diagram-okon (OPD) alapul´o modellje, amib˝ol egyszer˝ u m´odon gener´alhat´o az angol nyelvhez k¨ozel´all´o sz¨oveges reprezent´aci´o (OPL). A modell rugalmass´aga megenged olyan apr´o m´odos´ıt´asokat, amelyek ugyan hat´assal lehetnek a rendszer eg´esz´ere, de ehhez elegend˝o az OPD egy pontj´an elv´egezni a m´odos´ıt´asokat. Ezzel elker¨ ulhetj¨ uk azt a hibalehet˝os´eget, melyet a term´eszetes nyelvi specifik´aci´ok mindig is magukban hordoztak. A m´ar megl´ev˝o k¨ovetelm´enydokumentumok formaliz´al´asa is elk´epzelhet˝o. A formaliz´al´as alatt azt ´ertj¨ uk, hogy minden egyes mondathoz hozz´a tudjunk rendelni egy OPD diagrammot. ´Igy ak´ar bonyolult k¨ormondatokb´ol is l´etrehozhat´o egy l´enyeg´eben v´eve egyszer˝ us´ıtett sematikus ´abra, melyhez tartoz´o OPL bekezd´es teljes m´ert´ekig lefedheti a r´egi term´eszetes nyelvi specifik´aci´ot (ak´ar helyettes´ıtheti is azt !). Az ily m´odon formaliz´alt k¨ovetelm´enyrendszert tov´abbi automatikus vizsg´alatnak lehet al´avetni, ami gyors´ıtja ´es olcs´obb´a teszi a fejleszt´est. Fel´ep´ıthet˝o a k¨ovetelm´enyrendszerben szerepl˝o objektumok szomsz´eds´agi gr´afja, m´erhet˝ov´e tehet˝o a rendszer komplexit´asa. Becsl´eseket lehet tenni a projekt sikeress´eg´et illet˝oen, a rendszer o¨sszehasonl´ıthat´o m´as hasonl´o szoftverekkel. . . Mint l´athat´o, rengeteg el˝oremutat´o felhaszn´al´asi lehet˝os´eg rejlik a k¨ovetelm´enyrendszer formaliz´al´as´aban. A dolgozatom k¨ovetkez˝o r´esz´eben bemutatok egy sz¨oveges szoftverk¨ovetelm´enyeket tartalmaz´o dokumentum OPM alapokon val´o formaliz´al´as´at t´amogat´o szoftvert. A szoftver tervez´esekor fontos szempont volt a b˝ov´ıthet˝os´eg, teh´at annak a lehet˝os´ege, hogy az OPM jelrendszer´et u ´j entit´asokkal eg´esz´ıthess¨ uk ki, illetve a m´ar megl´ev˝o rel´aci´ok ´es entit´asok viselked´ese k¨onnyen m´odos´ıthat´o, testreszabhat´o legyen. Ehhez egy er˝osen objektumelv˝ u, rugalmas programoz´asi nyelvet, a Java-t v´alasztottam. A modell elt´arol´as´ara egy modul´aris fel´ep´ıt´es˝ u, k¨onnyen szerkeszthet˝o ´es karbantarthat´o adatb´azisra volt sz¨ uks´eg. F˝o szempont volt a hordozhat´os´ag, ´ıgy a lehets´eges adatb´azisok k¨ore lesz˝ uk¨ ult a sz¨oveg alap´ u adatt´arol´asi m´odokra. ´Igy esett a v´alaszt´asom a web egyik legintenz´ıvebben haszn´alt dokumentum-t´ıpus´ara az XML-re. Term´eszetesen nem egy k´esz ipari alkalmaz´as fejleszt´ese volt a c´el, viszont a k¨ovetkez˝o szoftver seg´ıts´eg´evel egyszer˝ ubb rendszerek k¨ovetelm´enyeinek r¨ogz´ıt´ese, illetve egyszer˝ ubb k¨ovetelm´enydokumentumok formaliz´al´asa megoldhat´o.
5. fejezet Felhaszn´ al´ oi dokument´ aci´ o 5.1. Rendszerk¨ ovetelm´ enyek A program futtat´as´ahoz aj´anlott minim´alis rendszerkonfigur´aci´o a k¨ovetkez˝o : • Szem´ elyi sz´ am´ıt´ og´ ep: Intel Pentium 800-megahertzes (MHz) vagy nagyobb processzorral; Pentium IV aj´anlott. • Oper´ aci´ os rendszer : B´armely 32 bites oper´aci´os rendszer (b˝ovebben l´asd a speci´alis k¨ovetelm´enyekn´el). • Felbont´ as: 1024 × 768, de aj´anlott legal´abb 1280 × 768. • Mem´ oria: 256 MB RAM (minimum) ; 512 MB RAM (aj´anlott).
Speci´ alis k¨ ovetelm´ enyek Ahhoz, hogy a OPMReqAnal kliensprogramot k¨ozvetlen¨ ul a sz´am´ıt´og´ep¨ unkr˝ol futtathassuk, rendelkezn¨ unk kell a Java programoz´asi nyelv Sun ´altal k´esz´ıtett futtat´ok¨ornyezet legal´abb 1.5-¨os verzi´oj´aval. A futtat´ok¨ornyezet ingyenesen el´erhet˝o, let¨olthet˝o a k¨ovetkez˝o webc´ımr˝ol: http://java.sun.com/javase/downloads/index_jdk5.jsp
65
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
66
5.2. A program ind´ıt´ asa ´ es telep´ıt´ ese 5.2.1. Windows Windows oper´aci´os rendszer alatt intelligens telep´ıt˝oprogram seg´ıti az alkalmaz´as install´al´as´at sz´am´ıt´og´ep¨ unkre. Az telep´ıt´es idej´ere v´alaszthat´o az angol, illetve a magyar nyelv is. Tetsz˝olegesen ´all´ıthat´o az alkalmaz´as telep´ıt´esi u ´tvonala, illetve az, hogy k´esz´ıtsen-e sz´amunkra hivatkoz´ast a Windows Asztalon ´es a Start men¨ uben. A k´es˝obbiek sor´an a program elt´avol´ıt´as´at a Windows Programok hozz´aad´asa ´es elt´avol´ıt´asa ablakon kereszt¨ ul tehetj¨ uk meg. Az ablak a Start men¨ u – Vez´erl˝opult, majd a Programok hozz´aad´asa ´es elt´avol´ıt´asa elemre kattintva ´erhet˝o el. Emellett, a telep´ıt´eshez hasonl´oan, az alkalmaz´as elt´avol´ıt´as´at is intelligens program t´amogatja. Ezen uninstall funkci´o a Start men¨ ub˝ol ´erhet˝o el. Az alkalmaz´ast a telep´ıt´esi k¨onyvt´arj´ab´ol, illetve a telep´ıt´es sor´an l´etrehozott hivatkoz´asokon kereszt¨ ul ind´ıthatjuk el. Az alap´ertelmezett be´all´ıt´as szerint a k¨ovetkez˝o k¨onyvt´arba telep¨ ul fel a program, ´es az al´abbi futtathat´o ´allom´annyal ind´ıthat´o : C:\Program Files\OPMReqAnal\OPMReqAnal.exe
5.2.2. Linux A Linux disztrib´ uci´ok al´a nem k´esz¨ ult k¨ ul¨on telep´ıt˝o program, itt a felhaszn´al´o sajnos csak a termin´alon kereszt¨ ul ind´ıthatja az alkalmaz´ast. Ezek ut´an, felt´eve hogy a java parancs el´erhet˝o ´es az alkalmaz´as k¨onyvt´ar´aban ´allunk, a program a k¨ovetkez˝o paranccsal ind´ıthat´o : java -jar OPMReqAnal.jar Term´eszetesen a jar kiterjeszt´es˝ u ´allom´any egy´eb oper´aci´os rendszer alatt is hasonl´ok´eppen futtathat´o, de a Windows rendszerek nagyfok´ u elterjed´ese miatt rendelkez´esre ´all a teljes m´ert´ekig Windows kompatibilis verzi´o is.
Megjegyz´ esek az alkalmaz´ as futtat´ as´ ahoz A konfigur´aci´os ´allom´anyok ment´ese sor´an az alkalmaz´as a merevlemezre pr´ob´al ´ırni. Figyelj¨ unk, hogy a lemez egy ´ırhat´o k¨onyvt´ar´ab´ol ind´ıtsuk a programot ! Az
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
(a)
67
(b)
5.1. ´abra. Az OPMReqAnal alkalmaz´as f˝oablaka alkalmaz´as teljes m´ert´ekig hordozhat´o, ´ıgy nemcsak a fentebb ismertetett k´et oper´aci´os rendszer alatt haszn´alhat´o – hanem minden olyan rendszerben is, ahol a Java futtat´ok¨ornyezet el´erhet˝o.
5.3. A felhaszn´ al´ oi felu ese ¨ let kezel´ Az alkalmaz´as f˝oablaka h´arom r´eszre oszthat´o : • a f˝omen¨ ure, • rajzt´abl´ara, illetve • egy ´altal´anos eszk¨ozt´arra. A h´arom r´esz az el˝obb le´ırt sorrendben k¨ovetik egym´ast, mint ahogy azt az 5.1 ´abr´an is l´athat´o.
5.3.1. F˝ omenu ¨ A f˝omen¨ un kereszt¨ ul az al´abbi funkci´ok ´erhet˝oek el. A men¨ upontok neve ut´an z´ar´ojelben az adott funkci´ohoz tartoz´o gyorsbillenty˝ u szerepel – persze ha van hozz´arendelve. A men¨ upontok k¨oz¨otti gyors navig´aci´o seg´ıt´es´ere m´asodlagos gyorsbillenty˝ uk is l´eteznek, ezek a men¨ upont nev´eben al´ah´ uz´assal szerepelnek, ´es az ALT billenty˝ u ´es az al´ah´ uzott karakter egy¨ uttes lenyom´as´aval aktiv´alhat´oak. A CTRL,
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
68
illetve ALT szimb´olumsorozat a billenty˝ uzet azonos felirattal ell´atott billenty˝ uj´ere utal. • File ´ rajzt´abla l´etrehoz´asa, a megl´ev˝o eldob´asa vagy men◦ New (CTRL + N) : Uj t´ese. ◦ Save (CTRL + S) : A rajzt´abla tartalm´anak ment´ese raszteres JPG form´ atumba. ◦ Save XML (CTRL + ALT + S) : Az elk´esz¨ ult rendszerterv XML form´atumba ment´ese. ◦ Open (CTRL + O) : Szoftverk¨ovetelm´enyeket tartalmaz´o egyszer˝ u sz¨ovegf´ ajl megnyit´asa, a tartalm´anak bet¨olt´ese. ◦ Quit (CTRL + Q) : Kil´ep´es az alkalmaz´asb´ol. • OPM ◦ Entities: Az alkalmaz´as entit´asainak list´aja. Dinamikusan gener´ al´odik a config.xml konfigur´aci´os be´all´ıt´asokat tartalmaz´o f´ajl tartalma alapj´an. Ezen gener´alt almen¨ upontok seg´ıts´eg´evel ny´ılik lehet˝os´eg¨ unk u ´j, tetsz˝oleges entit´asok l´etrehoz´as´ara. ◦ Relations: Az alkalmaz´as rel´aci´oinak list´aja mely tartalma – hasonl´oan az el˝oz˝o men¨ uponthoz – dinamikusan j¨on l´etre (p´elda a tartalm´ara az 5.1 ´abra b r´esze). ◦ Generate OPL paragraph (F9) : A rajzt´abla OPD diagrammj´anak alapj´an legener´alja a megfelel˝o OPL bekezd´est, illetve felk´ın´alja annak ment´esi lehet˝ os´eg´et. • Settings a◦ Configuration (CTRL + F10) : A rajzt´abla megjelen´ıt´es´enek finomhangol´ sa. ◦ Model settings (CTRL + F11) : Az Entities, illetve Relations men¨ upontokban megjelen˝o – az alkalmaz´as ´altal haszn´alt – modellek testreszab´asa. ◦ About (F1) : Inform´aci´ok a programr´ol.
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
´ entit´ (a) Uj as felvitele #1
69
(b) A player” entit´ as m´odos´ıt´asa ”
´ entit´ (c) Uj as felvitele #2
´ entit´as felvitele, illetve entit´as m´odos´ıt´asa 5.2. ´abra. Uj
5.3.2. Rajzt´ abla A rajzt´abl´an jelennek meg az u ´jonnan gener´alt OPD diagramok. Az u ´j OPD elemek alap´ertelmezett helyzete a rajzt´abla bal fels˝o sark´an´al van, viszont az ´abr´ak helyzet´et az eg´errel k¨onny˝ uszerrel megv´altoztathatjuk a fogd ´es vidd (drag and drop) m´odszerrel. A t´ abla OPD elemeinek finomhangol´ asa ´ entit´as, illetve rel´aci´o felhelyez´ese a f˝omen¨ Uj u kor´abban ismertetett pontj´an kereszt¨ ul t¨ort´enik. Entit´asok eset´en az 5.2 ´abra (a) pontj´an l´athat´o dial´ogusablak seg´ıts´eg´evel adhatjuk meg az u ´j entit´ as l´etrehoz´as´ahoz sz¨ uks´eges alapvet˝o adatokat. Megadhat´o az entit´as c´ımk´eje (k¨otelez˝o param´eter), illetve a rajzt´abl´an l´ev˝o poz´ıci´oja (x ´es y
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
70
´ rel´aci´o felvitele 5.3. ´abra. Uj koordin´at´aja, l´asd az ´abra 1-essel jel¨olt blokkj´at). Amennyiben a modellben u ´gy defini´altuk, ´es az entit´as kiterjeszthet˝o valamilyen m´as entit´assal, akkor az ´abr´an 2-essel jel¨olt blokk is l´athat´ov´a v´alik, ahol l´etrehozhatjuk a lesz´armazottakat. Ha viszont olyan entit´ast v´alasztott a felhaszn´al´o amely ¨onmag´aban nem ´allhat, akkor az ´abra (c) r´esz´eben l´athat´o ablakban adhat´o meg az u ´j entit´as sz¨ ul˝oje. A m´ar felpakolt entit´ asok m´ odos´ıt´ asa az adott entit´ason, az eg´er jobb gombj´aval val´o kattint´assal lehets´eges. Ekkor az el˝obb megismert ablak jelenik meg, illetve ha az entit´as egy m´asik entit´ashoz valamely rel´aci´on kereszt¨ ul kapcsol´odik, akkor az 5.2 ´abra (b) pontj´aban l´athat´o ablak 3-mas pontja is l´athat´ov´a v´alik. Itt egy´ertelm˝ u m´odon, a Remove gombbal elt´avol´ıthat´o, m´ıg a Modify gombbal m´odos´ıthat´o az adott rel´aci´o. Rel´aci´ok eset´en az 5.3 ´abr´an l´athat´o dial´ogusablak seg´ıts´eg´evel adhatjuk meg az u ´j rel´ aci´ o l´etrehoz´as´ahoz sz¨ uks´eges alapvet˝o adatokat. Az ablak 2-es, illetve 3mas blokkj´aban adhat´o meg a rel´aci´o forr´as ´es c´el oldali entit´asa. Ugyanezen r´eszen adhat´o meg mindk´et oldali r´eszv´eteli korl´at is. Emellett az 1-es blokkban adhat´o meg az el˝ore-, ´es h´atrafel´e halad´o c´ımk´ez´es. A m´ar l´etrehozott rel´ aci´ ok m´ odos´ıt´ asa k¨ozvetlen¨ ul nem lehets´eges, csak a m´ar kor´abban ismertetett entit´asok m´odos´ıt´asa r´eszben le´ırtaknak megfelel˝oen.
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
71
5.4. ´abra. A rajzt´abla finomhangol´asa A t´ abla OPD elemeinek t¨ orl´ ese N´emely esetben sz¨ uks´eges lehet a t´abl´an l´ev˝o OPD elemek t¨orl´es´ere, melyet az ´abr´an val´o dupla kattint´assal kezdem´enyezhet¨ unk. Az alkalmaz´as minden esetben r´ak´erdez, hogy biztosak vagyunk-e a t¨orl´esben, ´es az igenl˝o v´alasz eset´en (Yes) t´avol´ıtja el az elemet a t´abl´ar´ol. A rel´aci´ok elt´avol´ıt´asa nem lehets´eges ilyen m´odon, viszont ha olyan entit´ast jel¨ol t¨orl´esre a felhaszn´al´o mely m´as entit´ashoz egy rel´aci´on kereszt¨ ul kapcsol´odik, akkor az adott rel´aci´o is t¨orl´esre ker¨ ul. Hasonl´o m´odon, ha az entit´as tartalmaz lesz´armazott (vagy gyerek) entit´asokat, akkor azok is elt´avol´ıt´asra ker¨ ulnek az entit´assal egy¨ utt. A rajzt´ abla finomhangol´ asa Az OPMReqAnal felhaszn´al´oi fel¨ ulete, ´ıgy a rajzt´abla megjelen´ese ig´enyeinknek megfelel˝oen alak´ıthat´o. A f˝omen¨ ub˝ol, illetve a CTRL + F10 billenty˝ ukombin´aci´o hat´as´ara az 5.4 ´abr´an l´athat´o dial´ogusablak seg´ıts´eg´evel ´all´ıthat´o t¨obbek k¨oz¨ott a t´abla m´erete (2-es blokk). A h´arom el˝ore defini´alt be´all´ıt´as mellett lehet˝os´eg¨ unk van k´ezzel, tetsz˝oleges m´eret˝ ure ´all´ıtani a rajzt´abl´at (custom). A m´eret megv´alaszt´as´aval azt szabjuk meg, hogy mekkora k´epet hozzon l´etre az alkalmaz´as az OPD ment´ese sor´an. Az ´abr´an 3-mas ponttal jel¨olt r´eszen lehet a t´abla h´atter´enek ´es keret´enek sz´ın´et be´all´ıtani a megfelel˝o gombra val´o kattint´assal. Az 1-es blokkban pedig az alkalmaz´as ind´ıt´asakor ´erv´enyes nagy´ıt´asi faktor ´all´ıthat´o.
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
72
5.5. ´abra. K¨ovetelm´enydokumentum formaliz´al´asa
5.3.3. Eszk¨ ozt´ ar A rajzt´abl´an tal´alhat´o ´abr´ak nagy´ıthat´oak (ALT+I), illetve kicsiny´ıthet˝oek (ALT + O) az eszk¨ozt´ar nagy´ıt´o ikonjai seg´ıts´eg´evel (a m´asodik ´es a harmadik ikon az eszk¨ozt´aron). Az ikonok mellett sz´azal´ekosan jelzi ki az alkalmaz´as az ´eppen aktu´alis nagy´ıt´asi faktort, ami 50%-t´ol eg´eszen 200%-ig terjedhet. Az eszk¨ozt´ar piros iksz-szel jel¨olt gombj´aval (ALT+D) h´ıvhat´o el˝o a t¨omeges t¨orl´es funkci´oja. ´Igy lehet˝os´eg¨ unk ny´ılik ak´ar t¨obb entit´as egyidej˝ u t¨orl´es´ere is. A felbukkan´o ablakban az OPMReqAnal felsorolja a t´abl´an l´ev˝o entit´asokat, melyek k¨oz¨ ul t¨orl´esre jel¨olhet¨ unk a CTRL billenty˝ u folyamatos nyomva tart´asa mellett ak´ar t¨obbet is. Az eszk¨ozt´ar utols´o ikonja a f˝omen¨ uben m´ar bemutatott – OPL bekezd´es gener´al´asa – funkci´ot h´ıvja (F9).
5.4. K¨ ovetelm´ enydokumentum formaliz´ al´ asa Az alkalmaz´as egyszer˝ u sz¨oveges form´atumban l´ev˝o k¨ovetelm´enydokumentumok formaliz´al´as´at t´amogatja. Ehhez els˝o l´ep´esben a formaliz´alni k´ıv´ant dokumentumot kell bet¨olten¨ unk, melyet a CTRL + O billenty˝ ukombin´aci´oval kezdem´enyezhet¨ unk. A dokumentum szerkezet´enek meg kell felelnie n´eh´any egyszer˝ u szab´alynak. T¨ob-
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
73
bek k¨oz¨ott minden mondat az angol nyelvben haszn´alatos ´ır´asjelek valamelyik´evel kell v´egz˝odj¨on, illetve a szavak k¨oz¨ott sz´ok¨oz, vagy white space kell ´alljon. Ahhoz hogy ezeket a szab´alyokat be tudjuk tartani, egy lebut´ıtott” dokumentum-t´ıpust ” kell haszn´alnunk. Nem kell ugyanis feldolgoznunk a k¨ovetelm´enydokumentum olyan r´eszeit, mint p´eld´aul1 : • tartalomjegyz´ek, • c´ımsorok, • felsorol´asok, • illetve a k¨ovetelm´enyelemz´eshez irrelev´ans r´eszek (jogi nyilatkozat, stb.). Az 5.5 ´abr´an l´athat´o ablakban l´athatjuk a bet¨olt¨ott, k¨ovetelm´enyeket tartalmaz´o dokumentum feldolgoz´as´at seg´ıt˝o kezel˝ofel¨ uletet. Az alkalmaz´as a sz¨oveget el˝osz¨or mondatokra, majd szavakra bontja. A mondatok k¨oz¨ott az 1-essel jel¨olt blokkban tal´alhat´o gombok seg´ıts´eg´evel lehet l´epkedni, m´ıg az aktu´alis mondat szavai a 2-essel jel¨olt blokkban vannak felsorolva. Ezen a ponton a felhaszn´al´o tud´as´ara hagyatkozik az program, ugyanis az aktu´alis mondat szavainak kategoriz´al´as´at manu´alisan kell elv´egezni. A 3-mas blokkban kiv´alaszthat´o, hogy nem elemzett, entit´as vagy rel´aci´o legyen a k¨ovetkez˝o kijel¨olt sz´o. Ezut´an a k´ıv´ant sz´ora kattintva, az a kiv´alaszt´asnak megfelel˝o sz´ınk´oddal lesz jel¨olve2 . Az 1-es blokk Add gombj´aval adhat´o hozz´a az ¨osszes kijel¨olt elem a t´abl´ahoz. Ekkor egy dial´ogusablakban lehet finom´ıtani a kor´abban megjel¨olt szavakat. Az alkalmaz´as el˝osz¨or az elemz´esre jel¨olt entit´asokat, majd a rel´aci´okat aj´anlja fel. Egym´as melletti k´et sz´o eset´en el˝osz¨or az els˝o sz´ot, majd a m´asodikat, v´eg¨ ul a kett˝ot egy¨ utt aj´anlja fel. T¨obb sz´o egym´as melletti kijel¨ol´ese eset´en is hasonl´ok´eppen j´ar el: el˝osz¨or az egy-, majd kett˝o-, stb. hossz´ u szavak k¨ovetkeznek az elemz´esben. Az 1 Felt´ etelezz¨ uk,
hogy a felhaszn´al´ o m´ar elv´egezte a sz¨ uks´eges el˝ofeldolgoz´asi m˝ uveleteket. Jelen
verzi´oban a szoftver nem rendelkezik ezen funkci´oval. 2 Ha a felhaszn´ al´ o a player” sz´ ora – mint entit´ asra – kattintott, akkor a bet¨olt¨ott dokumentum ” o¨sszes ugyanilyen szava entit´ ask´ent lesz megjel¨olve. Ezzel elker¨ ulhet˝o ugyanazon entit´ as t¨obbsz¨ori feldolgoz´ asa. Rel´ aci´ ok eset´en is jel¨ oli az alkalmaz´as az azonos szavakat, de az entit´ asokkal ellent´etben, rel´aci´ ok t¨ obbsz¨ or is feldolgozhat´ oak.
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
74
Accept gombbal elfogadhat´o az aktu´alis szekvencia (´ıgy a k¨ovetkez˝o csoport j¨on a feldolgoz´asi sorban), m´ıg az Ignore this sequence gombbal az adott csoport k¨ovetkez˝o lehet˝os´eg´et n´ezhetj¨ uk meg. Entit´asok ´es rel´aci´ok eset´en egyar´ant a Type leg¨ord¨ ul˝o men¨ ub˝ol v´alaszthat´o ki, hogy melyik konkr´et OPM elemre szeretn´enk lecser´elni az adott sz´ot (vagy sz´ocsoportot). Az elemz´es v´eg´ehez ´erve az Ok gombra kattintva v´egleges´ıthetj¨ uk d¨ont´eseinket (visszavon´asra nincs lehet˝os´eg). Ezut´an felhaszn´al´oi interakci´o csak azon entit´asok eset´eben sz¨ uks´eges, melyek egymagukban nem ´allhatnak. Az ˝o eset¨ ukben meg kell adnunk a sz¨ ul˝o entit´as nev´et a m´ar kor´abban bemutatott 5.2 ´abra (c) r´esz´eben l´atott ablakban. A rel´aci´ok eset´eben minden esetben meg kell adni a forr´as ´es a c´el oldali entit´ast (l´asd az 5.3 ´abr´at). Ezek ut´an az elk´esz¨ ult OPD diagrammok l´athat´ov´a v´alnak a rajzt´abl´an (l´ asd az 5.5 ´abra 4-es blokkj´at). Az elemz´es utols´o l´ep´esek´ent legener´altatjuk (F9) a felhelyezett ´abr´ak OPL bekezd´eseit. A logikai tartalom maradt ugyanaz, a megfogalmaz´as viszont kiss´e m´odosult, rem´elhet˝oleg csak t¨om¨orebb lett. Mondhatjuk azt, hogy formaliz´altuk a k¨ovetelm´enydokumentumot.
5.5. Az alkalmaz´ as modellj´ enek testreszab´ asa Az alkalmaz´as l´enyeges eleme az OPM elemek dinamikusan term´eszete. V´altoztathat´o az entit´asok, illetve rel´aci´ok megjelen´ese ´es m˝ uk¨od´ese egyar´ant. Az OPMReqAnal futtathat´o ´allom´anya mellett tal´alhat´o config.xml nev˝ u ´allom´any t´arolja a modell o¨sszes tulajdons´ag´at, mely a telep´ıt´es ut´an az OPM m´odszertan haszn´alat´ara van felk´esz´ıtve. Az XML ´allom´any k¨ozvetlen m´odos´ıt´asa nem aj´anlatos, haszn´aljuk minden esetben a program ´altal biztos´ıtott grafikus felhaszn´al´oi fel¨ uletet ! A modell konfigur´aci´oj´at a CTRL + F11 billenty˝ ukombin´aci´oval el˝oh´ıvhat´o dial´ogusablakon kereszt¨ ul tehetj¨ uk meg. A megjelen˝o dial´ogusablakon a k´et f˝o csoport k¨oz¨ott lehet v´alasztani (l´asd az 5.6 ´abra (a) r´esz´et), majd a leg¨ord¨ ul˝o mez˝oben kiv´alasztott modell m´odos´ıthat´o, illetve t¨or¨olhet˝o. A ment´es (Save) gombra kattintva nem ´erz´ekelhet˝o a v´altoz´as – ugyan´ ugy mint a konfigur´aci´os be´all´ıt´asokn´al – a m´odos´ıt´asok az alkalmaz´as u ´jraind´ıt´asa ut´an l´epnek ´erv´enybe.
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
75
(a)
(b) Entit´ as modellj´enek m´odos´ıt´asa
(c) Rel´ aci´ o modellj´enek m´odos´ıt´asa
5.6. ´abra. Az alkalmaz´as modellj´enek testreszab´asa
5.5.1. Entit´ asok Az u ´j entit´asok bevezet´esekor, illetve megl´ev˝o entit´asok m´odos´ıt´asakor meg kell adnunk n´eh´any alapvet˝o inform´aci´ot. Tal´an a legfontosabb tulajdons´ag az entit´as neve, mely megad´asa k¨otelez˝o – n´ev n´elk¨ ul nem l´etezhet entit´as. Defini´alnunk kell
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
76
az ´abra vizu´alis megjelen´es´et, teh´at azt az alakzatot ami egy u ´j entit´as kirajzol´asakor megjelenik. Az rendelkez´esre ´all´o alakzatok k¨oz¨ott a Shape panelon l´ev˝o leg¨ord¨ ul˝o list´ab´ol v´alaszthatunk (az 5.6 ´abra (b) r´esz´enek 1-es blokkja). Az OPL sentence gombra kattintva szerkeszthet˝oek az entit´ashoz tartoz´o OPL mondatok (l´asd 5.5.3). A 3-mas ponttal jel¨olt blokkban k´et eld¨ontend˝o k´erd´esre kell v´alaszt adnunk. Az Is Standalone panelon arra a k´erd´esre v´alaszolhatunk (igennel – Yes, vagy nemmel – No), hogy az entit´as ´allhat-e egymag´aban a rajzt´abl´an. A nemleges v´alasz azt jelenti, hogy csak akkor tehet˝o fel a t´abl´ara az ilyen t´ıpus´ u entit´as, ha a t´abl´an van legal´abb egy olyan entit´as, melynek lesz´armazottja lehet. A m´asik eld¨ontend˝o k´erd´es, hogy lehetnek-e lesz´armazottjai az entit´asnak (Is expandable panel). Ha itt igennel v´alaszolunk, akkor akt´ıvv´a v´alik az Allowable children panel, ahol megadhatjuk ism´et egy leg¨ord¨ ul˝o list´ab´ol kiv´alasztva az entit´ashoz kapcsolhat´o lesz´armazottakat (2-es blokk a k´epen). Az entit´ashoz sz´ıneket rendelhet¨ unk (4-es blokk). Az els˝o, a rajzeszk¨oz sz´ıne (Drawcolor), mely az entit´as c´ımk´ej´enek sz´ın´ere van hat´assal. A m´asodik gomb az entit´as h´atter´enek sz´ın´et szab´alyozza (Background color). Mind a k´et gombon kattintva egy k´enyelmes dial´ogus ablak jelenik meg, ahol k¨onnyed´en kiv´alaszthat´o a felhaszn´al´onak tetsz˝o sz´ın.
5.5.2. Rel´ aci´ ok A rel´aci´ok modelljeinek m´odos´ıt´asa nagyban hasonl´ıt az el˝obb ismertetett entit´asok bevezet´es´ehez, viszont a rel´aci´oknak nem lehet lesz´armazottjuk (´ıgy a megfelel˝o panel is elt˝ unt). Viszont egy u ´j k¨otelez˝o mez˝ovel b˝ov¨ ult a dial´ogusablak, a szintaxissal (Syntax, 5.6 (c) ´abra 2-es blokkja). A szintaxis panelon az szab´alyozhat´o, hogy milyen entit´asok jelenhetnek meg a rel´aci´o forr´as-, ´es c´eloldal´an. A szintaxis szerkeszthet˝o a panel gombjai ´es az entit´asok neveit tartalmaz´o leg¨ord¨ ul˝o mez˝o seg´ıts´eg´evel. Elt˝ unt a k´et eld¨ontend˝o k´erd´es is az ablakb´ol, helyett¨ uk n´egy m´asik opci´o lett v´alaszthat´o. Be´all´ıthat´o, hogy enged´elyezett-e a sz´amoss´ag forr´as-, ´es c´el oldalon; illetve hogy megengedhet˝o-e az el˝ore-, ´es h´atrafel´e mutat´o c´ımk´ez´es.
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
77
5.7. ´abra. Entit´asok/rel´aci´ok OPL mondatainak szerkeszt´ese
5.5.3. OPL mondatok Az 5.7 ´abr´an l´athat´o ablak jelenik meg mind az entit´asok, mind a rel´aci´ok OPL mondatainak szerkeszt´ese eset´en. Egy OPM elemnek ak´ar t¨obbfajta OPL mondata is lehet, viszont priorit´assal rendelkeznek azon mondatok melyek valamilyen opcionalit´ashoz k¨ot¨ottek. A ki´ert´ekel´es sor´an az opcionalit´as n´elk¨ uli OPL mondatok ker¨ ulnek feldolgoz´asra utolj´ara, mik¨ozben az azonos opcionalit´assal rendelkez˝o mondatok feldolgoz´asa fel¨ ulr˝ol lefel´e halad. Az alkalmaz´as be´ep´ıtett szintaktik´at alkalmaz a mondatok feldolgoz´as´ara. Egy entit´ as OPL mondat´ aban a $ jellel annot´alt entit´asn´ev helyettes´ıt˝odni fog a k´es˝obbiekben az entit´as c´ımk´ej´evel. Legyen p´eld´aul az Object entit´as OPL mondata a k¨ovetkez˝o : $Object can be @Object$State. Itt az $Object annot´aci´ot a gener´al´as sor´an az adott entit´as neve fogja helyettes´ıteni. R¨ogt¨on r´at´erhet¨ unk a p´elda v´eg´en szerepl˝o annot´aci´ora. Az @Object$State annot´aci´ot az Object t´ıpus´ u entit´as State t´ıpus´ u lesz´armazottj´anak a c´ımk´eje fogja helyettes´ıteni (children opcionalit´as). Term´eszetesen ha t¨obb lesz´armazottja is van az entit´asnak, akkor t¨obb
´ OI ´ DOKUMENTACI ´ O ´ 5. FEJEZET. FELHASZNAL
78
mondat is gener´al´odik hozz´a. A rel´aci´ok OPL mondataiban az entit´asok annot´alt neve ut´an az 1-es sz´ammal jel¨olj¨ uk az adott t´ıpus´ u forr´as oldali, m´ıg 2-essel a c´el oldali entit´ast. Teh´at ha a rel´aci´o annot´alt OPL mondata a k¨ovetkez˝o : $Object1 and $Object2 are related., akkor az $Object1 hely´ere a forr´as oldali objektum c´ımk´eje, m´ıg a kettessel annot´alt objektum hely´ere a c´el oldali objektum c´ımk´eje ker¨ ul. A parent opcionalit´as eset´en a $Process2 occures if @State1$Object is $State1. annot´alt OPL mondat @State1$Object r´esze a rel´aci´o forr´as oldali State entit´as´anak Object t´ıpus´ u sz¨ ul˝oj´enek c´ımk´ej´evel helyettes´ıt˝odik. A forwardTag ´es backwardTag opcionalit´as csak rel´aci´ok eset´eben relev´ans. Az opcionalit´as bekapcsol´as´aval a rel´aci´o el˝ore-, illetve h´atrafel´e halad´o c´ımk´eje helyettes´ıt˝odik a %forwardTag ´es %backwardTag annot´aci´ok hely´ere. Az 5.7 ´abra 2-es sz´ammal jel¨olt blokkja csak akkor v´alik akt´ıvv´a, ha a felhaszn´al´o szerkeszti az OPL mondatot, vagy u ´jat hoz l´etre. Mind a k´et esetben leg¨ord¨ ul˝o men¨ ub˝ol v´alaszthat´o az opcionalit´as, ´es szerkeszthet˝o k´ezzel az annot´alt OPL mondat. Az Entity leg¨ord¨ ul˝o men¨ u tartalmazza az o¨sszes entit´as nev´et, melyet annot´alva hozz´af˝ uzhet¨ unk az aktu´alisan szerkesztett mondat v´eg´ehez az Add gomb lenyom´as´aval.
6. fejezet Fejleszt˝ oi dokument´ aci´ o A program fejleszt´ese kiv´etel n´elk¨ ul ingyenesen felhaszn´alhat´o eszk¨oz¨ok seg´ıts´eg´evel, Ubuntu Linux1 oper´aci´os rendszer alatt t¨ort´ent. A v´alasztott fejleszt˝oi k¨ornyezet a Netbeans2 ingyenes integr´alt fejleszt˝oi k¨ornyezet´enek 6.1-es verzi´oja lett, mely er˝osen t´amogatja a Java3 programoz´asi nyelvet. A Java egy sz´eles k¨orben elterjedt objektumorient´alt programoz´asi nyelv, ahol az elk´esz´ıtett programok bin´aris k´odja (b´ajtk´odja) v´altoztat´as n´elk¨ ul futtathat´o k¨ ul¨onb¨oz˝o t´ıpus´ u sz´am´ıt´og´epeken, ez´altal az elk´esz´ıtett programok rendk´ıv¨ ul k¨onnyen hordozhat´oak. Ez a platformf¨ uggetlens´eg term´eszetesen azokra az architekt´ ur´akra korl´atoz´odik, amikre k´esz¨ ult a bin´aris k´odhoz ´ertelmez˝o (´ un. virtu´alis g´ep). Emellett Java forr´ask´odb´ol k¨ozvetlen¨ ul nat´ıv (g´epi) k´od is k´esz´ıthet˝o, amivel az alkalmaz´as hat´ekonys´aga nagyban jav´ıthat´o. Ugyanakkor hatalmas el˝ony, hogy a grafikus felhaszn´al´oi fel¨ ulet fejleszt´es´et lehet˝ov´e t´ev˝o Swing csomag minden platformon azonos kin´ezetet ad. Az alkalmaz´as ´altal haszn´alt ikonok egy r´esze az internetr˝ol szabadon let¨olthet˝o Boomy toolbar icon set csomagb´ol4 sz´armazik. 1 http://www.ubuntu.com/ 2
http://www.netbeans.org/
3 http://java.sun.com/ 4 http://miloszwl.deviantart.com
79
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
80
6.1. Az alkalmaz´ as modulszerkezete A programot h´et logikailag sz´etv´al´o csomagra bontottam. Ezek rendre a k¨ovetkez˝ok: • OPMreqAnal ◦ OPM, ◦ OPMdialogs, ◦ OPMfigures, ◦ OPMreqAnalApplication, ◦ XML, ◦ images.png, ´es ◦ sentenceReaderPackage. Az al´abbiakban r¨oviden bemutatom a csomagok tartalm´at, amit – a Model-ViewController tervminta alapj´an – a fontosabb oszt´alyok kiss´e r´eszletesebb magyar´azata k¨ovet. Az oszt´alyok jobb meg´ert´es´et seg´ıti az alkalmaz´asb´ol gener´alt HTML dokument´aci´o, mely a dolgozat CD mell´eklet´en tal´alhat´o meg. A gener´alt dokument´aci´ohoz a Sun Microsystems Javadoc nev˝ u eszk¨oz´et haszn´altam, mely k´epes a forr´ask´odban elhelyezett, bizonyos konvenci´oknak al´avetett kommentekb˝ol HTML-alap´ u dokument´aci´ot k´esz´ıteni.
6.1.1. OPM A csomag tartalmazza az alkalmaz´asban k¨ozponti szerepet bet¨olt˝o oszt´alyokat, azaz az OPMAbstractObject, OPMEntity, OPMRelation, OPMCardinality, annotateOPLSentence valamint labelPos, cardinalityEnum ´es optionalityEnum oszt´alyokat. Ezen oszt´alyok konkr´et objektumaiban t¨ort´enik a t´enyleges adatt´arol´as, az alkalmaz´as logikai r´eteg´et jelentik. Az OPMAbstractObject az OPM entit´asainak absztrakt modellj´et val´os´ıtja meg, m´ıg a fennmarad´o oszt´alyok ezen absztrakt oszt´aly lesz´armazottjai, illetve az adatt´arol´ashoz sz¨ uks´eges felsorol´asi t´ıpusok. Err˝ol b˝ovebben az oszt´alyhierarchia modell r´esz´eben lesz sz´o (82. oldal).
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
81
6.1.2. OPMdialogs Az alkalmaz´as formjait (ablakait) ´es a kapcsol´od´o oszt´alyokat tartalmazza a csomag. Ez al´ol egyetlen kiv´etel van, ez pedig a f˝oablak oszt´alya. A dial´ogusablakok d¨ont˝o h´anyada adatbek´er˝o, illetve megjelen´ıt˝o funkci´oval b´ır.
6.1.3. OPMfigures Az OPM csomaghoz szorosan kapcsol´od´o csomag az ottani oszt´alyok vizu´alis reprezent´aci´oj´at val´os´ıtja meg.
6.1.4. OPMreqAnalApplication A statikus bel´ep´esi pont – a f˝oablak – oszt´aly´at, ´es a hozz´a tartoz´o oszt´alyokat tartalmaz´o csomag.
6.1.5. XML Egyetlen oszt´alyt, a configReader-t tartalmazza a csomag. Ez az oszt´aly felel˝os a k¨ uls˝o adatok bet¨olt´es´e´ert, illetve a be´all´ıt´asok elment´es´e´ert.
6.1.6. images.png A csomag egyetlen c´elja az alkalmaz´as k´epeinek t´arol´asa (png form´atumban). Itt t´aroljuk az eszk¨ozt´ar ikonjait, illetve az OPM elemek miniat˝ urjeit.
6.1.7. sentenceReaderPackage A sz¨ovegf´ajlok feldolgoz´as´at v´egz˝o oszt´alyok csomagja.
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
82
parent
source sentences
annotate ➥ OPLSentence
OPMAbstractObject
0...*
OPMRelation
{abstract} destination
children
desCardinality
OPMEntity
srcCardinality
0...*
OPMCardinality
6.1. ´abra. Oszt´alydiagram – az OPMAbstractObject ´es kapcsolatai
6.2. Oszt´ alyhierarchia, a fontosabb oszt´ alyok r´ eszletez´ ese 6.2.1. Model OPMAbstractObject Az OPM elemeinek absztrakt oszt´alya. Az OPM entit´as ´es rel´aci´o fogalm´ahoz kapcsol´od´o alapvet˝o inform´aci´okat t´arolja, illetve az OPD-hez tartoz´o OPL mondatok lek´er´es´et val´os´ıtja meg. A f˝obb adattagok a k¨ovetkez˝ok: protected String name
= null ;
protected String caption
= null ;
protected OPMfigure figure
= null ;
protected OPMAbstractObject parent
= null ;
protected Vector
sentences = null ; A name adattag t´arolja a konkr´et OPM objektum nev´et (p´eld´aul Object, Process, Affect link, . . . ), m´ıg a caption a megjelen´ıtend˝o c´ımk´et. Rel´aci´ok eset´en ez a c´ımke az el˝orefel´e halad´o c´ımk´et jelenti, a h´atrafel´e halad´ot az OPMRelation oszt´aly t´arolja. A figure az OPM objektum ´abr´aj´ara, m´ıg a parent a hierarchi´aban felette elhelyezked˝o objektumra hivatkozik. Az oszt´aly met´odusai getter ´es setter
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
83
f¨ uggv´enyekkel ´all´ıtj´ak ezen adattagokat. A sentences v´edett adattag az OPM elemhez tartoz´o annot´alt OPL mondatok vektora. Nem k¨otelez˝o, hogy tartozzon az elemhez OPL mondat, viszont ha tartozik, akkor ak´ar t¨obb mondat is hozz´arendelhet˝o. A getOPLSentence publikus f¨ uggv´ennyel k´erhet˝o le az elem gener´alt OPL mondata. A f¨ uggv´eny az oszt´aly k´et m´asik absztrakt f¨ uggv´eny´et haszn´alja az annot´aci´ok helyettes´ıt´es´ere, melyek megval´os´ıt´asa a lesz´armazott oszt´alyok feladata. Ezek pedig a • String getOptionalOPLSentence(annotateOPLSentence s), ´es • String getStandardOPLSentence(annotateOPLSentence s) f¨ uggv´enyek. Az els˝o f¨ uggv´eny az elem opcion´alis, m´ıg a m´asodik az opcionalit´as n´elk¨ uli mondatokat dolgozza fel. Az annot´aci´ok helyettes´ıt´ese sor´an priorit´assal b´ırnak az opcionalit´assal rendelkez˝o mondatok. ´Igy, ha az elem rendelkezik opcionalit´assal, akkor el˝osz¨or az ilyen mondatokat dolgozzuk fel, ´es csak ut´ana t´er¨ unk r´a a t¨obbire. OPMEntity Az OPMAbstractObject oszt´aly eme lesz´armazottja val´os´ıtja meg az OPM entit´as fogalm´at. Mint ilyennek, term´eszetesen lehet felirata, saj´at c´ımk´eje ´es b˝ov´ıthet˝o u ´jabb entit´asokkal. A oszt´alyszint˝ u v´altoz´ok a k¨ovetkez˝ok: private boolean expandable
= false ;
private boolean standAlone
= false ;
private Vector<String> allowableChildren
= null ;
private Vector children = null ; Az els˝o logikai v´altoz´o (expandable) azt hivatott t´arolni, hogy az entit´as kiterjeszthet˝o-e u ´jabb entit´asokkal. A standAlone logikai v´altoz´o igaz ´ert´eke pedig olyan OPM entit´ast jel¨ol, mely csak akkor l´etezhet ha egy m´asik entit´as tartalmazza ˝ot. A k´et vektor az entit´as hierarchi´aban bet¨olt¨ott szerep´enek reprezent´al´as´ara hivatott. Ez alapj´an az allowableChildren vektor azon entit´asok neveit tartalmazza, melyekkel az entit´as kiterjeszthet˝o. A vektort akkor t¨oltj¨ uk fel elemekkel, ha az els˝o logikai v´altoz´o ´ert´eke igaz. A m´asodik vektor azon OPMAbstractObject t´ıpus´ u entit´asokat tartalmazza, melyek konkr´et lesz´armazottai az entit´asnak.
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
84
Az oszt´aly a gy´art´o tervminta alapj´an dolgozik. A konstruktor egy OPMEntity objektumot hoz l´etre, melyet a k´es˝obbiekben, mint gy´art´ot alkalmazhatunk (n´ehol modellk´ent hivatkozok r´a). A t´enyleges entit´as l´etrehoz´asa a publikus createEntity f¨ uggv´ennyel t¨ort´enik. A visszaadott objektum m´ar konkr´et ´abr´aval, illetve felirattal rendelkezik (alkalmaztuk a modellt). ´Igy megval´os´ıthat´o, hogy egyetlen oszt´aly alkalmazhat´o legyen az ¨osszes entit´as kezel´es´ere, f¨ uggetlen¨ ul azok speci´alis tulajdons´agait´ol. Az egyszer˝ us´eg kedv´e´ert ezt a m´odszert k¨ovettem a az OPMRelation oszt´allyal is a rel´aci´ok l´etrehoz´asa sor´an. Az egyetlen m´eg eml´ıt´esre ker¨ ul˝o met´odus az addChild, mely hozz´aadja a lesz´armazottak vektor´ahoz a param´eterben megadott OPMAbstractObject t´ıpus´ u objektumot. OPMRelation Az OPMAbstractObject m´asik lesz´armazottja az OPMRelation (l´asd a 6.1 ´abr´at), mely az OPM rel´aci´o fogalm´at val´os´ıtja meg. Az oszt´aly term´eszetesen ¨or¨okli ˝ose ¨osszes el´erhet˝o adattagj´at ´es met´odus´at, mik¨ozben a kor´abban eml´ıtett absztrakt met´odusokat megval´os´ıtja. Az oszt´aly f˝obb adattagjai a k¨ovetkez˝oek: private OPMAbstractObject source
= null ;
private OPMAbstractObject destination = null ; private Vector<String> allowableLHS
= null ;
private Vector<String> allowableRHS
= null ;
private OPMCardinality srcCardinality = null ; private OPMCardinality desCardinality = null ; private String backwardTag
= null ;
Ezen k´ıv¨ ul taratlmaz m´eg n´eh´any adattagot az oszt´aly, viszont azok szerepe az opcion´alisan megjelen´ıtend˝o el˝orefel´e-, illetve h´atrafel´e halad´o c´ımk´ez´es ´es a forr´as-, ´es c´el oldali kardinalit´asok enged´elyez´es´ere korl´atoz´odik. A source adattag a forr´as oldali, m´ıg a destination a rel´aci´o c´el oldali entit´as´ara hivatkozik. Ebb˝ol k¨ovetkezik, hogy az OPM-ben bevezetett disztributivit´as, az el´agaz´asok megval´os´ıt´asa hi´anyzik az alkalmaz´asb´ol.
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI cardinalityEnum
85
megfelel˝ oje az OPM-ben
QUESTION_MARK
?
STAR
*
ONE
1
PLUS
+
M
m
6.1. t´abl´azat. A tartom´any-r´eszv´eteli korl´atok ´es a cardinalityEnum t´ıpus Az allowableLHS (allowable left hand-side) t¨omb a forr´as oldalon megengedhet˝o OPM elemek nev´et tartalmazza. ´Igy csak olyan entit´as ker¨ ulhet a rel´aci´o forr´as oldal´ara, mely neve szerepel e t¨ombben. Az allowableRHS szerepe ugyanaz mint az el˝oz˝o´e, de itt a c´el oldali entit´asok szintaktik´aj´at ellen˝orizz¨ uk a t¨ombbel. R´eszv´eteli megszor´ıt´as lehet a rel´aci´o forr´as-, ´es c´el oldal´an is. Ennek megfelel˝oen az srcCardinality, ´es desCardinality adattagok szolg´alnak a rel´aci´o forr´as, illet˝oleg c´el oldali kardinalit´as´anak t´arol´as´ara. OPMcardinality Az Object-Process Methodology-ban a rel´aci´oban r´esztvev˝o entit´asok sz´am´at rendszerszint˝ u megszor´ıt´ask´ent korl´atozhatjuk. A kapcsolatokban megjelen˝o sz´amoss´agokat (kardinalit´as) reprezent´alja az oszt´aly, mely a konstruktorban param´eterk´ent (k¨ ul¨onb¨oz˝o form´atumokban) megadott kardinalit´ast helyes form´atumban t´arolja ´es jelen´ıti meg. Lehet˝os´eg van a kardinalit´ast sz¨oveges, numerikus ´es, a cardinalityEnum felsorol´asi t´ıpus seg´ıts´eg´evel, egyszer˝ us´ıtett form´aban is deklar´alni. Ez az egyszer˝ us´ıtett form´atum az OPM tartom´any-r´eszv´eteli korl´atok r¨ovid´ıtett jel¨ol´eseit t´amogatja (l´asd a 6.1 t´abl´azatot). Term´eszetesen az oszt´aly getOPL publikus met´odusa seg´ıts´eg´evel lek´erhet˝o a kardinalit´asnak megfelel˝o OPL mondat. annotateOPLSentence Ez az egyszer˝ u oszt´aly csup´an k´et adattagot, ´es a karbantart´asukhoz sz¨ uks´eges get, illetve set met´odusokat tartalmazza. Az oszt´aly k´et adattagja a k¨ovetkez˝o :
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI private String annotateSentence
86
= null ;
private optionalityEnum optionality = null ; Ahogy azt az OPMAbstractObject oszt´alyn´al l´attuk, az OPM elemek annot´alt OPL mondatait egy ilyen t´ıpus´ u elemeket tartalmaz´o t¨ombbe szervezve t´aroljuk. Az annotateSentence sz¨oveges adattag nyers form´aban tartalmazza az annot´alt OPL mondatot, m´ıg az optionality v´altoz´o az opcionalit´ast hat´arozza meg. Az optionality adattag lehets´eges ´ert´ekeit az optionalityEnum felsorol´asi t´ıpusb´ol veszi, melyek a k¨ovetkez˝oek lehetnek: • NONE (nincs opcionalit´as), • FORWARDTAG, • BACKWARDTAG, • CHILDREN, ´es • PARENT. Ezek mindegyike az annot´alt OPL mondathoz tartoz´o opcionalit´ast hat´arozza meg, mely ki´ert´ekel´ese az OPMEntity ´es OPMRelation oszt´alyokban t¨ort´enik. sentenceReader A sentenceReader oszt´aly a megadott forr´as (legyen az sz¨oveges f´ajl, vagy egyszer˝ u sz¨oveg) mondatokra, majd szavakra bont´as´at v´egzi el a megadott mondathat´arol´o karaktereknek megfelel˝oen. Adattagjai a k¨ovetkez˝oek: public final String defaultDelimiters = ".?! " ; private Vector<String> delimiters
= null ;
private Vector<sentence> sentences
= null ;
private sourceType source
= null ;
private String fileName
= null ;
Amennyiben a konstruktor h´ıv´asakor nem adjuk meg a mondathat´arol´o karaktereket, akkor az alap´ertelmezett be´all´ıt´ask´ent a szabv´anyos mondatv´egi ´ır´asjeleket
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
87
haszn´alja az oszt´aly (defaultDelimiters). A feldolgoz´as a doIt nev˝ u publikus met´odus hat´as´ara t¨ort´enik meg, ami a source v´altoz´o ´ert´ek´et˝ol f¨ ugg˝oen bontja mondatokra a forr´ast. Az ut´obbi adattag ´ert´eke a felsorol´asi t´ıpusnak megfelel˝oen FILE, vagy TEXT lehet. Amennyiben a feldolgoz´as megt¨ort´ent, a sentences nev˝ u t¨ombben mondatokra bontva t´aroljuk a sz¨oveget. sentence ´ es word Az sentenceReader ´altal haszn´alt sentence oszt´aly egy mondat t´arol´as´ara van felk´esz´ıtve, mely szavakb´ol ´allhat (word oszt´aly). Az oszt´alyhierarchia a 6.2 ´abr´an l´athat´o.
sentenceReader
sentences
sentence
words
0..*
word 0..*
6.2. ´abra. Oszt´alydiagram – a sentenceReader ´es kapcsolatai
configReader Az OPMReqAnal alkalmaz´as konfigur´aci´os be´all´ıt´asait a k¨ uls˝o config.xml f´ajl alapj´an ´all´ıtja be. Az oszt´aly eme XML5 dokumentum olvas´as´at SAX6 , m´ıg ´ır´as´at a DOM7 Java csomagokon kereszt¨ ul teszi meg. K¨ ul¨on t¨omb¨okben gy˝ ujti az entit´asok, illetve rel´aci´ok inform´aci´oit, m´ıg priv´at adattagjai a rajzt´abla megjelen´ıt´es´er˝ol is tartalmaznak inform´aci´okat. A k´es˝obbiekben ezen inform´aci´ok alapj´an hozhatjuk l´etre az OPM elemeit a t´abl´an. Az XML f´ajl mellett egy config.dtd nev˝ u DTD8 ´allom´any is tal´alhat´o. Ez felel a konfigur´aci´os ´allom´any ´erv´enyess´eg´e´ert. Egy XML dokumentum, ami azon k´ıv¨ ul, 5 XML:
Extensible Markup Language, Kiterjeszthet˝o Le´ır´ o Nyelv. A W3C ´altal aj´anlott ´altal´ a-
nos c´el´ u le´ır´ o nyelv adatok, illetve konfigur´aci´ os inform´aci´ ok t´ arol´as´ara. 6 SAX: Simple API for XML, egyszer˝ u alkalmaz´as-programoz´ oi interf´esz XML f´ajlokhoz. Egyszer˝ u soros olvashat´ os´ agot enged XML f´ajlokon. 7 DOM: Document Object Model, dokumentumok objektum-modellje. Altal´ ´ anos megold´as XML f´ajlok kezel´es´ere. 8 DTD: Document Type Definition, dokumentum t´ ıpus defin´ıci´ o.
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
0...*
OPMsketchBoard
88
OPMAbstractObject {abstract}
entity
figure
listener figures OPMfigure
OPMEntityMouse ➥ Listener
pressedFigure
OPMEntityFigure
{abstract}
OPMRelationFigure
6.3. ´abra. Oszt´alydiagram – az OPMfigure ´es kapcsolatai hogy helyesen form´azott, m´eg meg is felel egy adott s´em´anak, az ´erv´enyesnek nevezhet˝o. Ez azt jelenti, hogy a config.xml dokumentumnak meg kell felelnie a config.dtd s´em´anak ahhoz, hogy az alkalmaz´as futtathat´o legyen.
6.2.2. View OPMfigure Az absztrakt OPMfigure oszt´aly a Java Swing csomag Panel oszt´aly´anak kiterjeszt´ese, mely lesz´armazottai egyenk´ent a eddigiekben bemutatott OPM csomag oszt´alyaihoz tartoz´o ´abr´ak kirajzol´as´at v´egzik a k¨ovetkez˝o szereposzt´asban (l´asd a 6.3 ´abr´at) : • OPMEntity – OPMEntityFigure ´es
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
89
• OPMRelation – OPMRelationFigure. A kirajzol´as megval´os´ıt´asa a Panel ˝ososzt´aly paint met´odus´anak fel¨ uldefini´al´as´aval t¨ort´enik. Az oszt´aly egy v´edett, felsorol´as t´ıpus´ u (OPMshape) adattagja, a figureNum t´arolja el a lehets´eges geometriai alakzatok list´aj´at (k¨or, t´eglalap, stb.). Az OPMRelationFigure oszt´aly a megfelel˝o rel´aci´o forr´as-, ´es c´el oldali entit´asa k¨oz¨ott h´ uz´od´o ´abra megjelen´ıt´es´et szolg´alja. Gyakorlatilag a k´et entit´as k¨oz´eppontj´at ¨osszek¨ot˝o egyenes, ´es a befoglal´o t´eglalapok (egyenk´ent n´egy, a sarokpontokat o¨sszek¨ot˝o) egyeneseinek metsz´espontjai k¨oz¨ ul v´alasztjuk ki a minim´alis t´avols´ag´ ut. OPMsketchBoard Az alkalmaz´as rajzt´abl´aj´at megval´os´ıt´o oszt´aly, mely a Java Swing csomagj´anak Panel komponens´enek lesz´armazottja. Az el˝obbi figure oszt´alyokat erre a panelra pakoljuk fel, majd azokat k¨ ul¨on vektorokban t´aroljuk. Az addOPMobject ´es removeOPMentity met´odusok szolg´alnak az objektumok felhelyez´es´ere, illetve a panelr˝ol val´o t¨orl´es´ere. Itt t¨ort´enik az elk´esz¨ ult ´abra raszteres ment´ese is a saveAs met´odussal. A rajzt´abla zoom adattagja t´arolja a nagy´ıt´asi faktort. Ez a rajzt´abl´an l´ev˝o OPMfigure objektumok felirat´anak bet˝ ut´ıpus´ara van hat´assal, ami meghat´arozza ´ıgy a megjelen˝o ´abra m´eret´et is. Az oszt´aly egerez˝o m˝ uveleteit fel¨ ugyeli az OPMEntityMouseListener oszt´aly. Ez minden rajzt´abl´ara helyezett OPMEntity t´ıpus´ u objektumot figyel, megval´os´ıtja azok vonszol´as´at (l´asd a 6.3 ´abr´at). Formok, OPMdialogs Az alkalmaz´as OPMdialogs csomagja k¨ozponti szerepet t¨olt be a Model-ViewController (MVC) tervmint´aban, de ezen oszt´alyok r´eszletez´es´ere itt most nem t´erek ki. Mindegyik oszt´aly adatbek´er˝o, bet¨olt˝o funkci´oval rendelkezik, a t´enyleges m˝ uveletek elv´egz´ese az alacsonyabb szinten l´ev˝o oszt´alyokban t¨ort´enik.
6.2.3. Controller Az alkalmaz´as vez´erl˝oje ´es egyben statikus bel´ep´esi pontja az OPMreqAnalApp oszt´aly. Az oszt´aly tartalmazza az eszk¨ozt´ar, rajzt´abla, a modellek ´es konfigur´aci´os
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
90
be´all´ıt´asok bet¨olt´es´e´ert felel˝os oszt´aly egy-egy p´eld´any´at, melyek inicializ´al´as´at ´es kezel´es´et egyar´ant elv´egzi.
6.3. Tesztel´ esi terv 6.3.1. Modulteszt Az alkalmaz´as modultesztel´es´et a Java nyelv n´epszer˝ u tesztel˝o eszk¨oz´evel, a JUnit-tal v´egeztem9 . Term´eszetesen a modultesztnek csak a publikus f¨ uggv´enyek eset´eben van ´ertelme, viszont ism´etelhet˝o m´odon v´egrehajthat´o. A tesztel´est korl´atoztam az alkalmaz´as logikai r´eteg´enek oszt´alyaira, ´es kihagytam azok setter/getter met´odusait. Nagyon er˝os, ´es j´ol alkalmazhat´o m´odszer Java programok implement´al´as´ara a teszt-vez´erelt fejleszt´es (Test-Driven Development, TDD). N´emely funkci´o implement´al´asa sor´an alkalmaztam, de sajnos a fejleszt´es eg´esz´eben nem k¨ovettem a m´odszert. A TDD l´enyege, hogy az elj´ar´asok/f¨ uggv´enyek implement´al´asa el˝ott elk´esz´ıtj¨ uk a teszt eseteket. Term´eszetesen az ´ıgy elk´esz´ıtett tesztek hib´as eredm´eny adnak, mivel nincs m¨og¨ott¨ uk m˝ uk¨od˝o k´od. Az implement´aci´ot akkor nevezz¨ uk befejezettnek, ha az ¨osszes teszt eset sikeresen lefutott. ´Igy a tesztel´essel vez´erelhet˝o a fejleszt´es, biztosak lehet¨ unk benne hogy rendszer¨ unk a k¨ovetelm´enyeknek megfelel˝oen m˝ uk¨odik. Nagy el˝onye a JUnit alkalmaz´as´anak, hogy az alkalmaz´as evol´ uci´oja sor´an megtarthat´oak a kezdeti teszt esetek, ezzel regresszi´os tesztnek tekinthet˝o. Mivel mindig u ´jabb teszt esetekkel b˝ov¨ ul a kezdeti teszt halmaz, ´ıgy gyorsan bizonyosodhatunk meg arr´ol, hogy az alkalmaz´as u ´jabb funkci´oi nem rontj´ak el a m´ar kor´abbi implement´aci´ot. Az al´abbiakban ¨osszegy˝ ujt¨ottem az elk´esz¨ ult teszthalmazokat, melyek ¨osszesen 60 teszt esetet tartalmaznak. Mindegyik halmaz elnevez´es´eben utal a tesztelend˝o oszt´alyra, de term´eszetesen sz´amos ´atfed´es fedezhet˝o fel k¨oz¨ott¨ uk. N´emely oszt´aly nem szerepel az al´abbi teszt halmazok le´ır´as´aban, viszont tesztel´es¨ uk kiker¨ ulhetetlen volt a t¨obbi teszt eset lefut´as´ahoz. 9 www.junit.org
´es junit.sourceforge.net
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
91
OPMEntityTest Az OPMEntity oszt´aly kritikus, sokat tesztelt met´odusa a getOPLSentence. A tesztek sor´an olyan entit´asokat hoztam l´etre melyeknek • nem volt annot´alt OPL mondatuk (¨ ures a sentences t¨omb), • csak olyan opcion´alis annot´alt OPL mondatuk volt, mely felt´etele nem teljes¨ ult (CHILDREN opcionalit´as lesz´armazott n´elk¨ ul), • nem volt opcion´alis annot´aci´ojuk, • volt opcion´alis, ´es opcionalit´as n´elk¨ uli annot´alt mondata (a priorit´as tesztel´ese), • CHILDREN opcion´alis mondatukhoz t¨obb lesz´armazott tartozott, • t¨obb azonos t´ıpus´ u annot´alt mondatuk volt. Ezen fel¨ ul egyed¨ ul az addChild elj´ar´as tesztel´ese sz¨ uks´eges, a t¨obbi met´odus nem relev´ans a modulteszt szempontj´ab´ol. A teszt esetek implicit tartalmazt´ak az OPMAbstractObject egy r´esz´enek teszt¨ j´et, ´es lefedt´ek a standAlone, illetve expandable tulajdons´ag´ u entit´asokat is. Osszesen 9 teszt eset k´esz¨ ult az oszt´alyhoz. OPMRelationTest A rel´aci´ok tesztel´ese nagyban hasonl´ıtott az entit´asok el˝obb ismertetett tesztel´es´ehez, viszont itt sz´amolni kellett a forr´as-, ´es c´el oldali entit´asok k¨ ul¨onb¨oz˝o vari´aci´oj´ab´ol ad´od´o hibalehet˝os´eggel. K¨ ul¨onb¨oz˝o t´ıpus´ u rel´aci´okat hoztam l´etre, u ´gy hogy a lehet˝os´egekhez k´epest az o¨sszes fontos tulajdons´aguk fel legyen t¨oltve. A 13 teszt eset lefedi a rel´aci´ok mindk´et oldali kardinalit´as´at, illetve a k¨ ul¨onb¨oz˝o t´ıpus´ u OPL mondatokat. Az el˝oz˝o teszt halmazzal egy¨ utt implicit teszteli az OPMAbstractObject oszt´alyt. OPMCardinalityTest A kardinalit´asok oszt´aly´anak tesztel´ese sor´an tesztelve lett
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
92
• az egyszer˝ us´ıtett, ´es a • hossz´ u” form´atum´ u tartom´any-r´eszv´eteli korl´at megjelen´ıt´ese, illetve ” • a kardinalit´ashoz tartoz´o OPL mondat lek´er´ese. Az el˝oz˝o teszt halmazokkal ellent´etben egyszer˝ ubb, de sok kis tesztre volt sz¨ uks´eg az oszt´aly funkcionalit´as´anak teljes lefed´es´ehez, ´ıgy ¨osszesen 25 teszt eset k´esz¨ ult. sentenceReaderTest A sentenceReader oszt´aly tesztel´es´ehez ¨osszesen h´arom teszt eset k´esz¨ ult el, viszont mind a h´arom szerte´agaz´o be´all´ıt´asokat tartalmaz, ´ıgy teljes m´ert´ekig lefedik az oszt´aly funkcionalit´as´at. Az els˝o teszt sz¨oveges forr´asb´ol, m´ıg a m´asodik f´ajlb´ol dolgozik. A k´et teszt kimen˝o adatai meg kell hogy egyezzenek, ehhez a teszt csomag mellett elhelyezett sz¨oveges ´allom´any (testFile.txt) tartalma megegyezik az els˝o teszt eset bemen˝o adat´aval. A f´ajl t¨obb pontj´an v´eletlenszer˝ u m´odon helyeztem el sort¨or´est, illetve tabul´ator karaktereket. A doIt f¨ uggv´eny tesztel´ese sor´an mind a k´et esetben ugyanannyi mondatot, ´es mondatonk´ent ugyanannyi sz´ot olvasott be a program. Ezenfel¨ ul az eredm´enyt k´ezzel leellen˝oriztem, ami megegyezett az elv´art adatokkal. V´eg¨ ul a setDelimiters ´es getDelimiters f¨ uggv´enyeken kereszt¨ ul a sz´oelv´alaszt´o karaktereket m´od´ıt´as´anak hat´as´at vizsg´altam meg. sentenceTest A mondatokat reprezent´al´o oszt´aly tesztel´ese sor´an a k¨ovetkez˝o eseteket vizsg´altam: • Az egyenl˝os´eg oper´ator m˝ uk¨od´ese (equals), • a mondat szavainak elemz´ese hogyan hat a mondat elemzetts´eg´ere, • a mondat szavainak sz´ama – helyes-e a felbont´as, • u ´j szavak hozz´aad´asakor nem romlik-e el az el˝oz˝o teszt. A fenti n´egy k´erd´esk¨ort n´egy tesztesettel fedtem le. Ezek az esetek ugyan nem egy az egyben felelnek a k´erd´esekre, de az ¨osszes funkcionalit´as tesztel´ese megtal´alhat´o benn¨ uk, s˝ot, m´eg a word oszt´aly egy r´esz´et is lefedik.
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
93
wordTest A word oszt´aly tesztel´es´en´el figyelembe vettem, hogy az oszt´aly a JButton oszt´aly lesz´armazottja, ´ıgy egyed¨ ul az elemzetts´eget meghat´aroz´o setStatusFlag ´es isAnalyzed met´odusokat teszteltem. configReaderTest A konfigur´aci´os ´allom´any ´ır´as´at/olvas´as´at vizsg´al´o teszt halmaz ¨osszesen n´egy teszt esetet tartalmaz. Mind a n´egy esetben egyar´ant tesztel´esre ker¨ ult a f´ajl olvas´asa, ´es ´ır´asa is.
6.3.2. Funkcion´ alis teszt Grafikus alkalmaz´as l´ev´en a funkcion´alis teszt rendhagy´o m´odon t¨ort´ent. A el˝oz˝o modultesztel´es sikeress´ege ut´an a k¨ovetelm´enyekben megfogalmazott funkcionalit´as tesztel´es´ere elfogad´o (acceptance) eseteket defini´altam, majd azokat pr´ob´altam meg ul¨osszekattintani”. K¨ozben igyekeztem minden lehet˝os´eget v´egigpr´ob´alni, egy k´ıv¨ ” ´all´o fej´evel gondolkodni. Term´eszetesen neh´ez u ´gy tesztelni, hogy a fejleszt˝o ´es a tesztel˝o egyazon szem´ely. ´Igy lehet, hogy akaratlanul is elker¨ ulte a figyelmemet sz´amos hiba. Miut´an magam nem tal´altam hib´at, a program tesztel´es´ebe magas informatikai h´att´ertud´assal rendelkez˝o ismer˝os¨oket vontam be, akik mag´at a programot el˝otte nem ismert´ek. Az ´atad´as csak azut´an t¨ort´ent meg, hogy hib´at ˝ok sem tal´altak az alkalmaz´asban.
6.4. Az OPCAT ´ es az OPMReqAnal o ¨sszehasonl´ıt´ asa Az OPCAT (Object Process CASE Tool 10 ) fejleszt´es´et m´eg 1994-ben kezdte el az a kutat´ocsoport, melynek vezet˝oje Dov Dori 11 , az izraeli Technion12 egyetem professzora. 10 http://www.opcat.com 11 http://iew3.technion.ac.il/Home/Users/dori.phtml 12 Technion,
Israel Institute of Technology
˝ DOKUMENTACI ´ O ´ 6. FEJEZET. FEJLESZTOI
94
6.4. ´abra. Az OPCAT felhaszn´al´oi fel¨ ulete Az OPCAT egy igen er˝os alkalmaz´asfejleszt´esi ´es tervez´esi seg´edeszk¨ozz´e n˝otte ki mag´at az id˝ok sor´an, melyet sz´amos ipari szerepl˝o v´as´arolt m´ar meg. A program 2005-ben v´alt el´erhet˝ov´e, mely az´ota m´ar a harmadik verzi´on´al tart. Siker´ere jellemz˝o, hogy az IT szektor mellett t¨obb bank ´es a hadipar is haszn´alata mellett d¨ont¨ott. Az OPCAT az OPM ¨osszes el˝ony´et kihaszn´alja. Gyors v´alt´asra k´epes az OPL ´es OPD k¨oz¨ott, melyhez igen l´atv´anyos felhaszn´al´oi fel¨ uletet biztos´ıt. Az eszk¨oz haszn´alat´aval az tervez´esi f´azist´ol k¨ovethet˝o egy szoftver ´eletciklusa, majd az elk´esz¨ ult rendszertervb˝ol ak´ar k´esz k´od is gener´alhat´o. Mindezek mellett a k¨ovetelm´enyek kezel´es´et ink´abb t´amogatja, mint megval´os´ıtja. A k¨ uls˝o eszk¨oz¨okkel (DOOR, Requisit Pro,. . . ) elk´esz´ıtett k¨ovetelm´eny-dokumentumok import´alhat´oak az OPCAT-be, b´ar bel˝ol¨ uk k¨ozvetlen¨ ul OPD nem ´ep´ıthet˝o. T´amogatja viszont az ´ıgy beimport´alt k¨ovetelm´enyek dinamikus hozz´akapcsol´as´at a m´ar elk´esz¨ ult rendszerterv diagrammj´ahoz (l´asd a 6.4 ´abr´at). Ezzel szemben, igaz m´eg kezdetleges form´aban, de az OPMReqAnal seg´ıti a sz¨oveges k¨ovetelm´eny-dokumentumok formaliz´al´as´at. Nem utols´o sorban az OPM m´odszertana nincs bebetonozva u ´gy, mint az OPCAT-be, ez´altal b´armikor, a program m´odos´ıt´asa n´elk¨ ul lehets´eges a haszn´alt modell ´es jelk´eszlet megv´altoztat´asa.
Negyedik r´ esz ¨ Osszegz´ es
95
96 A dolgozat c´elja egy olyan szoftver tervez´ese, majd implement´al´asa volt, mely az OPM m´odszertan´anak felhaszn´al´as´aval sz¨oveges k¨ovetelm´eny-dokumentumok formaliz´al´as´ara k´epes. Diplomamunk´am sor´an fontosnak tartottam az OPM m¨og¨ott h´ uz´od´o elm´eleti h´atteret k¨oz´erthet˝oen visszadni, ´am a t´ema t´argyal´as´at nehez´ıtette az OPM hi´anyos irodalma. M´ıg az OPM sz¨ ul˝oatyja – Dov Dori – sz´amos cikket publik´alt az OPM k¨ ul¨onb¨oz˝o ter¨ uleteit ´erintve, addig m´as kutat´ok m´eg nem igaz´an foglalkoztak a t´em´aval. Sajnos egy kor´abbi diplomamunk´at kiv´eve magyar nyelv˝ u publik´aci´o nem ´allt rendelkez´esemre, ´ıgy az OPM specifikus kifejez´eseinek ford´ıt´asa sor´an legink´abb a saj´at ¨otleteimre kellett hagyatkoznom. Meg kell eml´ıtenem, hogy terjdelmi okok miatt nem foglalkoztam az OPM id˝obeli kiterjeszt´es´evel, ´es a val´os rendszerek fel´e val´o tov´abbfejleszt´es´enek lehet˝os´eg´evel (OPM/T). A dolgozat eredm´enyek´eppen elk´esz¨ ult programot OPMReqAnal n´evre kereszteltem. Az eredeti c´elkit˝ uz´eseket marad´ektalanul siker¨ ult megval´os´ıtani, b´ar az alkalmaz´as m´eg sz´amos tov´abbfejleszt´esi lehet˝os´eget rejt mag´aban, ezek k¨oz¨ ul egy-k´et ´erdekesebb funkci´ot felsorolok. • Az OPD diagrammok ment´ese univerz´alis, illet˝oleg saj´at f´ajlform´atumokra val´o kib˝ov´ıt´ese. P´eld´aul hasznos, ´es kev´es r´aford´ıt´assal kivitelezhet˝o lenne az svg, illetve eps form´atumokba val´o ment´es. • Hasonl´o m´odon megoldhat´o lenne az elemz´es elment´ese saj´at form´atumba, melyet k´es˝obb visszat¨oltve folytathat´o lenne a munka. • A kezelt sz¨oveges ´allom´anyok k¨ore b˝ov´ıthet˝o m´eg. Elk´epzelhet˝onek tartom, hogy doc form´atumot is kezeljen az alkalmaz´as. • A bet¨olt¨ott sz¨oveges ´allom´anyok egyes r´eszeinek elemz´esre jel¨ol´ese, illetve elemz´esb˝ol kihagy´asa hi´anyzik. • A grafikai megjelen´ıt´es csiszol´asa”. P´eld´aul az OPM disztribut´ıv struktur´alis ” rel´aci´oi t¨obb entit´as ¨osszekapcsol´asa eset´en ¨osszevonhat´oak lenn´enek. Ezzel kiss´e egyszer˝ us¨odne a gener´alt OPL bekezd´es is. ´ • Erdemes lenne egy olyan adatb´azis fenntart´asa, mely seg´ıts´eg´evel az adott sz´or´ol el tudn´ank d¨onteni, hogy az foglalt sz´o, ige, f˝on´ev, stb. A kor´abbi ismeretek
97 birtok´aban aj´anl´ast tehetn´enk az entit´asokra, illetve rel´aci´okra. ´Igy egy adapt´ıv algoritmus a k¨ovetelm´enydokumentum formaliz´al´as´at automatiz´alhatja, amivel a felhaszn´al´oi interakci´o t´enylegesen minimaliz´alhat´ov´a tehet˝o. • ... Mindezek mellett u ´gy ´erzem, hogy a kifejlesztett alkalmaz´assal egy univerz´alisan alkalmazhat´o eszk¨ozt adhatok az ´erdekl˝od˝o kez´ebe, melyen kereszt¨ ul az OPM haszn´alata bemutathat´o ´es tanulhat´o.
6.5. A CD mell´ eklet tartalma A mell´ekelt CD lemez tartalmazza a dolgozat digit´alis verzi´oj´at k¨ ul¨onb¨oz˝o form´atumokban (LATEX, dvi, postscript ´es pdf). Emellett az OPMReqAnal alkalmaz´as telep´ıt˝o ´es futtathat´o ´allom´anyai is megtal´alhat´oak a CD-n, term´eszetesen a forr´ask´oddal egyetemben. A k¨ovetkez˝o k¨onyvt´arstrukt´ ura seg´ıt eligazodni a lemezen: • / ◦ diplomamunka • latex DVI • ps • pdf ◦ OPMReqAnal • forraskod • javaDoc • windows • linux
Irodalomjegyz´ ek [1] W. W. Royce, Managing the Development of Large Software Systems”, Proce” edings of IEEE WESCON, pp. 1–9, 1970, http://www.cs.umd.edu/class/spring2003/ ➥ cmsc838p/Process/waterfall.pdf (2009. janu´ar) [2] B. W. Boehm, Software Engineering Economics”, Prentice-Hall, 1981 ” [3] V. R. Basili, H. D. Rombach. Tailoring the Software Process to Project Go” als and Environments”, Proc. 9th. Intern. Conf. Software Engineering, IEEE Computer Society, pp. 345–357., 1987 [4] F. Brooks, No Silver Bullet : Essence and Accidents of Software Engineering”, ” IEEE Computer, pp. 10–19., 1987 [5] B. W. Boehm, A Spiral Model of Software Development and Enhancement”, ” IEEE Computer, pp. 61–72, 1988 [6] J. Martin, Rapid Application Development, Macmillan Publishing Co., 1991, ISBN 0 02 376775 8 [7] J. Shore, S. Warden, The Art of Agile Development, O’Reilly, 2007, ISBN 0 59652767-5 [8] Dov
Dori,
Object-Process
Methodology,
Springer
Verlag,
2002,
IS-
BN 354 065 471 2 [9] I. Sommerville, Szoftverrendszerek fejleszt´ese, Panem, 2002, ISBN 963 545 311 6
98
´ IRODALOMJEGYZEK
99
[10] D. M. Berry, K. Daudjee, J. Dong, I. Fainchtein, M. A. Nelson, T. Nelson, L. Ou, User’s manual as a requirements specification: case studies”, Springer ” Verlag, pp. 67–82., 2003 [11] Sike S., Varga L., Szoftvertechnol´ogia ´es UML, ELTE E¨otv¨os Kiad´o, 2003, ISBN 963 463 587 3 [12] Sike S., Programoz´asi Technol´ogia II.”, ELTE-IK, pp. 27–34, 2007 ” http://people.inf.elte.hu/sike/pt2.ps (2009. janu´ar) [13] Az Object-Process Methodology hivatalos weboldala, 2009. janu´ar http://www.objectprocess.org/ [14] Az UML 2.1.2-es specifik´aci´oja, 2009. janu´ar, http://www.omg.org/spec/UML/2.1.2/ [15] IBM Rational Unified Process Web Site, 2009. janu´ar, http://www−306.ibm.com/software/awdtools/ ➥ rup/?S\_TACT=105AGY59\&S\_CMP=WIKI\&ca=dtl−08rupsite [16] eXtreme Programming Web Site, 2009. janu´ar, http://www.extremeprogramming.org/
c Bese Antal, 2009.
[email protected] [email protected]
