UML05.qxd
8/30/2006
3:04 PM
Page 95
5 Alkalmazásmodellezés A fejezetben tárgyalt témák • Miért szükséges az alkalmazások modellezése? – A másik válasz – A kérdés háttere • A teljes alkalmazást modellezni kell? • Mi a helyzet a programozási nyelvekkel? • Milyen részletességgel kell modellezni az alkalmazásokat? • Hogyan modellezi az alkalmazásokat az UML? – Az osztálydiagramok alapjainak áttekintése • Osztályok • Mûveletek • Társítások • Egyéb társításjelzések – Az osztálydiagramokról bõvebben • Halmaz és összetétel • Általánosítás • Társításosztályok • Megszorítások – A sorrenddiagramokról bõvebben • Haladóknak • Kifejezések • Összefoglalás • Ellenõrzõ kérdések
UML05.qxd
96
8/30/2006
3:04 PM
Page 96
UML földi halandóknak
Miért szükséges az alkalmazások modellezése? Meglepõ módon erre a kérdésre elõször azt a választ adhatjuk, hogy vannak esetek, amikor az alkalmazás modellezése valószínûleg indokolatlan. Nem feltétlenül szükséges például, ha hétköznapi alkalmazásról van szó, vagy ha a fejlesztõeszközök elég hatékonyak az alkalmazás egy jelentõs részének „összeállításához”, illetve ha a fejlesztõk korábban már készítettek hasonló alkalmazásokat, ezért pontosan tudják, hogyan valósítsák meg az adott megoldást. Az üzlet szempontjából nélkülözhetetlen, komoly alkalmazások létrehozásakor azonban elengedhetetlen az alkalmazásmodellezés. A 2. fejezetben felsoroltunk néhány okot, amiért fontos a vállalkozások modellezése, és ezen okok jó része igaz az alkalmazások modellezésére is. Elõször is, rendkívül fontos átlátni, hogy mi az, ami már rendelkezésre áll, hiszen a legtöbb fejlesztés nem érintetlen területen történik. Általában adott valamilyen meglévõ rendszer, illetve szoftver, amelyet a csapat esetleg nem ismer, és amelyet módosítani vagy bõvíteni kell. A meglévõ alkalmazásokat könnyebb egy modell áttekintésével megérteni, mint a kódjukat olvasgatva.
Stafétabot (ismét) A 2. fejezetben tárgyaltuk azt az esetet, amikor egy olyan, rendkívül fontos alkalmazást örököltem, ami nem rendelkezett leírással, a kód és az adatállományok egy része hiányzott, és senki nem értette (számos fejlesztõ került már ilyen helyzetbe). Emlékezhetünk, hogy két hétbe telt megismerni az alkalmazást, és még több idõre volt szükség a mögötte húzódó elképzelések megértéséhez és az alkalmazás újból mûködõképessé tételéhez. További elvesztegetett idõt és felmerülõ költséget jelentett az olyan felhasználókkal foglalkozni, akik nem értették, hogy az alkalmazás hogyan, illetve miért mûködik úgy, ahogy mûködik. Ha rendelkezésre állt volna az alkalmazás modellje, a problémák és az azokkal járó kiadások elkerülhetõek lettek volna. Lássuk azonban a történet többi részét. Az alkalmazás némi „felújítás” után nagyon jó állapotba került, mindene mûködött, minden részének szerepe tisztázódott, és változatkövetõ rendszer felügyelte. Még elõzetes dokumentáció is készült hozzá. Minden sínen volt tehát, viszont az alkalmazásnak nem volt modellje (a szervezet, ahol dolgoztam, nem foglalkozott alkalmazásmodellezéssel). Volt néhány kisebb, nem jelentõs hiba, amelyeknek még a nyomára kellett bukkanni, de ezek nem gátolták a mûködést, és nem akadályozták volna az átadást. Ilyenkor kell szabadságra menni. Meg is tettem, és felfrissülten tértem vissza, készen arra, hogy folytassam az alkalmazás felújítását. Munka közben felfigyeltem néhány különös eseményre, amit korábban nem tapasztaltam. Az alkalmazás továbbra is elég jól mûködött, de olyan dolgokat csinált, amiket nem kellett volna, például idõnként két üzenetet küldött a kezelõnek. Vajon
UML05.qxd
8/30/2006
3:04 PM
Page 97
5. fejezet • Alkalmazásmodellezés szándékosan, mondjuk az alkalmazás egy olyan eldugott része miatt mûködött így, amelyet nem vizsgáltam meg, vagy hibás viselkedésrõl van szó? Biztos voltam benne, hogy az alkalmazás nem így mûködött, mielõtt elmentem. Miután pár napig böngésztem a kódot, észrevettem, hogy néhány apróbb változtatás történt benne. További nyomozás után kiderült, hogy az egyik új felhasználó a felettesemnél panaszkodott a program mûködésére, és a fõnök valamiért úgy döntött, hogy „rendbe hozza” a kódot anélkül, hogy bárkinek is szólna. Igen, megváltoztatta az alkalmazás mûködését csupán azért, hogy ennek az egy felhasználónak a kedvében járjon. Eközben számos új, valódi hibát idézett elõ. Ha rendelkezésre állt volna a program modellje, képes lett volna megfelelõ változtatást végezni, de csakúgy, mint sok programozó, aki valamilyen szoftvert örökölt, nem rendelkezett modellel. Gyorsan felmérte a kódot, és módosításokat végzett, amivel anélkül „oldotta meg” a „problémát”, hogy felismerte volna az ezzel létrehozott mellékhatásokat (hibákat).
1. Az alkalmazások modelljeit – különösen a bonyolultabb, kényesebb programokét – idõbe telik létrehozni, de még több idõt takaríthatnak meg, amikor változtatásokat kell végezni a szoftveren. 4. Ha szabadságra megyünk, zárjuk le a kódot. A beállításkezelés létfontosságú a sikeres fejlesztéshez.
Az is indokolja az alkalmazások modellezését, hogy új alkalmazások tervezésekor a változások gyakran a tervezési szakasz közben történnek. Ha rendelkezésre áll egy modell, sokkal könnyebben felmérhetjük a módosítások hatását, mivel látjuk az alkalmazás azon részeit, amelyeket befolyásolnak. Ahogy a Stafétabot (ismét) részben leírtak mutatják, ha meg kell változtatni a kódot, a tervezési modellek vizsgálatával megállapítható, hogy a javasolt változások nem tesznek-e kárt az alkalmazásban egy másik helyen. Az alkalmazás grafikus modellje segítségével sokkal könnyebben eldönthetjük, hogy a felépítés megfelel-e az üzlet követelményeinek. A szó szoros értelmében rámutathatunk az adott követelményt kielégítõ elemre, ahelyett, hogy egy szöveges leíráscsoportra mutatnánk. Végül, ahogy korábban is említettük, a modellek „gyújtópontként” szolgálnak, ami lehetõvé teszi, hogy az érdekeltek megtárgyalják és megoldják a felépítéssel kapcsolatos kérdéseket. Ahogy az Egyesült Államok egykori elnöke, Dwight Eisenhower mondta: „A terv semmi – a tervezés minden”. Nem csak magukról a modellekrõl van szó, hanem arról
97
UML05.qxd
98
8/30/2006
3:04 PM
Page 98
UML földi halandóknak a folyamatról, illetve elmélkedésrõl, amelyet a rendkívüli jelentõségû modellek létrehozásához végeznünk kell. A modellezés gondolkodásra késztet bennünket, és az átgondolás eredményeként jobb felépítést alakíthatunk ki.
A másik válasz Azok számára, akik azt kérdezik, hogy miért kell modellezni az alkalmazásokat, van még egy válaszunk, ami elég egyszerû: már amúgy is modellezünk, csak nem nevezzük a nevén. Emlékezzünk a modelleknek az 1. fejezetben leírt meghatározásaira: a modell egy elkészítendõ dolog ábrázolása. A legtöbb szoftverfejlesztõ részlegnél, ha végigmegyünk a fülkék között, különféle modelleket látunk a táblákra firkálva: A programok és azok alprogramjainak szerkezetét modellezõ blokkvázlatokat, a programok vezérlõ folyamatát modellezõ folyamatábrákat, hosszú, osztott téglalapokat, amelyek a mezõk szerkezetét, és egymáshoz kapcsolódó négyzetek hálózatát, amelyek egy webhely hivatkozásait modellezik – és igen, még egy-két UML diagramot is. Ezek mind modellezési módszerek. A modellezés csupán a rendszerek elemzésének, illetve tervezésének részeként használt eljárás, amelyet az olvasók többsége már minden bizonnyal alkalmaz, csak nem szabványos módon. Az UML mindössze szabványos megközelítést, jelrendszert és jelentést ad a modellezési tevékenységekhez.
A kérdés háttere Gyakran valójában más kérdések (vagy félelmek) rejlenek a mögött a kérdés mögött, hogy miért szükséges az alkalmazások modellezése. A legtöbben, akik azt kérdezik, hogy miért kell modellezni az alkalmazásokat, már tudják a választ. A valódi kérdés más tényezõkre vonatkozik. A vezetõk például gyakran azért teszik fel ezt a kérdést, mert valójában amiatt aggódnak, hogy a modellezés túl sok idõt vesz igénybe. Nem ismerik fel, hogy a kódolás gyakran a befejezetlen tervezésbõl eredõ okok miatt emészti fel a fejlesztés erõforrásainak java részét. A felépítés meghatározásának feladata a programozókra hárul, és a kód írása közben kell elvégezniük azt. Ahogy korábban mondtuk, valójában modellezünk (azaz tervezünk), csak másként nevezzük. Vannak olyan vezetõk is, akik a megírt kódsorok számával mérik a haladást; õk általában a szoftverfejlesztés „Vigyázz, kész, kódolás!” iskolájának követõi. Ez helytelen (de sajnos elterjedt) hozzáállás az iparban. Aki magára ismer, olyan jelentõsebb szempontokra is gondoljon, mint a vállalkozás igényeinek kiszolgálása, rugalmas felépítés létrehozása, jó minõségû termék készítése és a modellezés sok más elõnye, amit ebben és a korábbi fejezetekben említettünk. A költségek is szerepet játszanak annak eldöntésében, hogy modellezzünk-e vagy sem. Nem maga a modellezés jelent költséget (ahogy a fejezet egy korábbi részében kifejtettük, ezt a feladatot egyébként is elvégezzük majd, akár szabványosan modellezünk, akár nem).
UML05.qxd
8/30/2006
3:04 PM
Page 99
5. fejezet • Alkalmazásmodellezés Az az elõzetes befektetés a valódi költség, amelyet vagy szakképzett munkaerõre fordítunk, vagy arra, hogy a jelenlegi személyzetet megtanítsuk a helyes modellezésre. Ez az „egyszeri” költség azonban minden késõbbi munkánál megtérül, elsõsorban a kevesebb újratervezés és hibajavítás által (emlékezzünk a 3.1. ábra táblázatára). A szándékunk szerint mûködõ alkalmazás létrehozására kell összpontosítani (ha nem azt csinálja, amit a megrendelõ szeretne, az összes idõ és pénz kárba vész), illetve az alkalmazás teljes élettartamára számított kiadásokra. Elvégre a vezetõk feladatának része a munkaerõ fejlesztése is, igaz? Hasonlóképpen, azoknak a programozóknak, akik ezt a kérdést felteszik – és akiket az elõzõ fejtegetések egyike sem érint –, érdemes elgondolkodniuk: miért ne akarnának új szaktudásra szert tenni? Hiszen a programozó alkalmazhatósága a szaktudásában rejlik. Továbbá, miért akarna valaki csak kódoló lenni ahelyett, hogy megdolgozna a „programtervezõ mérnök” címért? Megelégszünk azzal, hogy szögeket verünk be, vagy katedrálisépítõvé akarunk válni? Az UML maradandó, ezért érdemes bõvítenünk vele a képességeinket.
A teljes alkalmazást modellezni kell? Amikor csak lehet, érdemes a teljes alkalmazást (vagy rendszert) modellezni, így tudatos irányítás alatt tarthatjuk az alkalmazás szerkezetét és felépítését. Néhány esetben például, amikor nem az egész rendszert felügyeljük, nem tudjuk teljes egészében modellezni azt, mégis nagyon hasznos lehet, ha modellezzük az irányításunk alatt álló részeket.
Lyukasabb, mint egy svájci sajt Rendszerintegrátorként egy igen nagy projekten dolgoztam (és így a rendszer megvalósításának egyetlen elemét sem befolyásolhattam közvetlenül), és egy mások által a rendszerkövetelményekben meghatározott, meglehetõsen összetett gyártási forgatókönyv került elém. Még csak akkoriban kezdtem megismerkedni az objektumközpontú megoldásokkal, és úgy döntöttem, hogy elkészítem a forgatókönyv állapotdiagramját. (Egy késõbbi fejezetben megtudjuk majd, hogy az állapotdiagramok általában egy meghatározott objektum állapotát ábrázolják. Úgy döntöttem, hogy a teljes forgatókönyvön kipróbálom ezt a módszert.) Nagy meglepetésemre kiderült, hogy számos hézag van a gyártási forgatókönyvben. Sok esetben ugyanis nem határozta meg, hogy mi történjen bizonyos, gyakran fennálló körülmények között. Más szóval, ha ez a forgatókönyv megvalósul, csúfos kudarcot vallott volna. A rendszernek ez a része nem az „enyém” volt, a modellezés által mégis sok mindent megtudhattam róla, és megtalálhattam a hibáit, ami lehetõvé tette, hogy fontos változtatásokat javasoljak.
99
UML05.qxd
100
8/30/2006
3:04 PM
Page 100
UML földi halandóknak
1. Ne féljünk kreatív módon alkalmazni a modellezési eljárásokat (például nem objektumokról, hanem egy egész rendszerrõl készítünk állapotdiagramot)! Ha megfelelõ módon használjuk azokat (azaz nem hagyjuk figyelmen kívül a diagram vagy a módszer alapelveit), új lehetõségeket fedezhetünk fel, amelyekkel remekül hasznosíthatjuk ezeket az eljárásokat. Az UML-rendõrség nem fogja ránk törni az ajtót, ha így teszünk.
Ha meglévõ rendszerrel van dolgunk (esetleg bõvítenünk kell azt, vagy javítani, illetve cserélni kell egy részt úgy, hogy közben mûködõképes maradjon), dönthetünk a „beburkolás” mellett. Ilyenkor külsõ felületréteggel „vesszük körül”, amely ugyanazokat a meglévõ felületeket biztosítja a külsõ alkalmazásoknak, de lehetõvé teszi a benne rejlõ technológia megváltoztatását. Modellezéskor csak a rendszer vagy az alkalmazás felületét modellezzük, a belsõ részekét nem (a fejezet egy késõbbi részében, az osztályok tárgyalásakor visszatérünk a felületek modellezésére). Ez azt is lehetõvé teszi, hogy új felületeket adjunk a rendszerhez, a meglévõk megbontása nélkül. (Igaz, hogy az új felületek használhatják a régieket, de ezt a csomagolás elrejti.) Így megváltoztathatjuk a belsõ megvalósítást, úgy, hogy a felület változatlan marad. Amennyiben a költségvetés, az idõ vagy a személyzet szakképzettségének hiánya (vagyis ha nincs sok olyan emberünk, aki képes megoldani a modellezést) korlátoz bennünket, csak a rendszer legfontosabb részeit modellezzük. Megtehetjük például, hogy csak az elsõdleges feladatokat modellezzük részletesen. Az alkalmazás vagy a rendszer minden kockázatos elemét modellezni kell. Ha az alkalmazás valósidejû, akkor modellezni kell; ebben az esetben nem kockáztathatunk meg egy rossz, kevéssé ismert felépítésen alapuló fejlesztést. Elvégre ha nem tudjuk elérni, hogy az alapvetõ elemek mûködjenek, miért foglalkozzunk egyáltalán a kevésbé fontos részekkel?
Mi a helyzet a programozási nyelvekkel? A programozási nyelvek sokat fejlõdtek az újrahasznosítható összetevõkönyvtárak, hatékony programozási keretrendszerek és hasonlók megjelenésével. Viszont az, hogy egy nyelvet „objektumorientált”-nak (objektumközpontúnak) neveznek, még nem jelenti azt, hogy helyettesítheti a megfelelõ objektumközpontú elemzést és tervezést. Egy programozási nyelv – még ha felhasználható szerkezeti elemeket is tartalmaz – nem biztosíthatja a megfelelõ felépítést, és azt sem, hogy az alkalmazás megfelel a megrendelõ igényeinek. Ez olyan, mintha azt mondanánk, hogy ha egy gyártónak sikerül elõre összeszerelt kerekeket beszereznie, és kisteherautókban alkalmaznia azokat, akkor az elkészült jármû megfelel majd a megbízhatósági szabványoknak, és jól irányítható lesz. A nyelvek és az eszközök nem helyettesíthetik a megfelelõ elemzést és tervezést.
UML05.qxd
8/30/2006
3:04 PM
Page 101
5. fejezet • Alkalmazásmodellezés
Milyen részletesség gel kell modellezni az alkalmazásokat? Azok, akik készek modellezni az alkalmazásaikat, gyakran megkérdezik, mikor kell áttérni a modellezésrõl a megvalósításra, vagy hogy mennyi részletet tartalmazzanak a modellek. Bizonyos esetekben a lehetõ legrészletesebb modell készítése a legjobb: például ha rendkívül fontos, illetve érzékeny rendszereket modellezünk, amilyen egy beültetett orvosi eszköz (ilyenkor életek forognak kockán), vagy amikor a rendszer hibája rendkívüli gazdasági következményekkel jár. Az ilyen nagy horderejû végeredmény indokolja, hogy a lehetõ legrészletesebben modellezzük az alkalmazást. Szintén részletes modellezést igényelnek az olyan helyzetek, amikor a teljesítmény vagy a megbízhatóság rendkívül fontos, csakúgy, mint amikor külsõsöket bízunk meg a fejlesztéssel. Miben hasonlítanak ezek a helyzetek? Olyan esetek, amikor az alkalmazás teljes körû meghatározásával (vagyis modellezésével) csökkenteni kell a tervezési kompromisszumokat. Senki sem szeretne kezdõ programozókra bízni olyan kulcsfontosságú tervezési döntéseket, amelyek befolyásolhatják az elsõdleges tényezõket, mondjuk a teljesítményt vagy a biztonságot. A kezdõ programozó például esetleg úgy valósítja meg a kódot, hogy csökkentse a memóriafelhasználást. Ez ugyan ártalmatlannak tûnhet, de lehet, hogy számunkra nem a memóriakihasználás fontos, hanem hogy kiemelkedõ sebességû rendszert kapjunk. Ezeket a fontos felépítésbeli kompromisszumokat nem szabad a megvalósításig halogatni. Az ilyen létfontosságú rendszerek teljes és részletes modelljét el kell készíteni, hogy azt kapjuk, amire valóban szükségünk van. A kevésbé kényes munkáknál általában az idõbeosztás, a költségvetés és a személyzet szakképzettsége határozza meg, hogy milyen részletes modellt készítünk. Általában jobb, ha a modell minél több részletet tartalmaz, de sokszor gyakorlatiasan egyensúlyba kell hozni a tényezõket. Az egyik jelzés, amire érdemes figyelni, a változás gyorsasága. Ha a modell részletei folyamatosan változnak, például ha a leírt mûveletek gyakran módosulnak, valószínûleg még nincs itt az ideje, hogy a modellek a fejlesztés megvalósítási szakaszába lépjenek, mert a felépítés még nyilvánvalóan kiforratlan. Mielõtt továbblépnénk, meg kell várnunk, amíg beáll egy elfogadható mértékû állandóság (mivel a változás soha nem szûnik meg). Természetesen az „elfogadható” meghatározása az adott cégtõl függ, amikor azonban a változás aránya alacsony, állandó szintre kerül, valószínûleg készen állunk rá, hogy hozzáfogjunk a felépítésmodellek megvalósításához.
Hogyan modellezi az alkalmazásokat az UML? Az üzleti modell meghatározza, hogy miért építjük a rendszert (azaz, hogy miként támogatja a vállalkozást), a feladatmodellek megmutatják, hogy a szereplõk hogyan használják majd a rendszert, a felépítésmodellek pedig meghatározzák a rendszer kezdeti szerkezetét. Ezzel a tudással felszerelkezve készen állunk az alkalmazás modellezésére. Ezek az elõzetes modellek korlátozzák az alkalmazás „formáját”. Az üzleti- és a feladatmodellek határt
101
UML05.qxd
102
8/30/2006
3:04 PM
Page 102
UML földi halandóknak szabnak a felépítési térnek (ami jó, mert a megoldások összességét egy megoldástérre korlátozza). A felépítésmodellek határozzák meg a megoldás átfogó szerkezetét. Ily módon a modellek fejlesztésével szabályozhatjuk a munka idõbeosztását és költségeit.
Az osztálydiagramok alapjai – ismétlés A korlátok meghatározását követõen leggyakrabban az osztálydiagram szolgál az alkalmazás statikus szerkezetének ábrázolására. Az osztálydiagramokkal korábban, a 4. fejezetben ismerkedtünk meg, ahol láttuk a felépítésmodellezés céljából történõ alkalmazásukat. Azok kedvéért, akik átugrották azt a részt, újra áttekintjük az osztálydiagramok néhány alapelvét – mivel ezek az alkalmazásmodellezés velejárói –, majd megvizsgálunk néhány további modellezési elemet, amelyek ezekben a diagramokban szerepelnek. Osztályok Az osztálydiagram az alkalmazás fontos osztályait és azok más osztályokhoz fûzõdõ kapcsolatait mutatja. Az osztályok elsõsorban a rendszerben szereplõ „dolgokat” ábrázolják. A kezdeti modellek (üzleti követelmények, felépítés) fejlesztése során már számos fontos osztályra bukkanunk. A többi modell nélkül sokkal nehezebb megtalálni ezeket az osztályokat, de nem lehetetlen. Ha nem rendelkezünk kezdeti modellekkel, tekintsük az alkalmazás problémamegfogalmazását, és válasszuk ki a valós dolgokat: könyvelés, repülõgép, megrendelõ, termék, közvetítõ, jelentés és így tovább (lásd az 5.1. ábrát). Ezek lesznek a területi osztályok vagy tartományosztályok, amelyeknek szerepelniük kell a diagramokban. A modell fejlõdése során a nem valós dolgok is osztályokként jelennek meg: ilyenek többek között a feldolgozást irányító vezérlõ osztályok.
5.1. ábra Osztály, amely egy bolygót ábrázol
De mik az osztályok a szoftver megvalósításának szempontjából? Az osztályok hasonló objektumok egy csoportját írják le, olyan sablonok, amelyek az objektumok létrehozására szolgálnak az alkalmazásban.
A szabályok megszegése Az UML modellek tárgyalásakor gyakran egyenértékûként használják az „osztály” és az „objektum” kifejezést. Ez szigorúan véve nem helyes, de ha észben tartjuk, hogy az osztály a leírás, és az objektum a megvalósítás, nem lehet gond. Nem kell amiatt izgulni, hogy a modellezés „Hatalmas Varázslói” megtudják, mit tettünk.
UML05.qxd
8/30/2006
3:04 PM
Page 103
5. fejezet • Alkalmazásmodellezés Ahogy egy süteményformával sok egyforma süteményt készíthetünk, ugyanúgy, ha rendelkezésre áll egy „Bolygó” nevû osztály, akkor a Bolygó osztály segítségével is több bolygó objektumot hozhatunk létre az alkalmazásban. Egy csomó egyforma bolygó talán nem túl érdekes, ahogy azonban az egyforma süteményeket változatossá tehetjük reszelékkel, cukormázzal vagy ételszínezékkel, a többalakúság (polimorfizmus) alkalmazásával az osztályokat is egyedivé tehetjük (errõl a fejezet késõbbi részében lesz bõvebben szó). Rögzítenünk kell az osztályok fontos adatait. Ezt a jellemzõk (attribútumok) – ezek a 4. fejezet szerkezetre vonatkozó leírásaihoz hasonlóak, de itt az alkalmazás felépítését jellemzik – alkalmazásával tehetjük meg. A jellemzõk határozzák meg az alkalmazáshoz szükséges osztályok lényeges tulajdonságait – nem az összes tulajdonságot, csak azokat, amelyek alkalmazhatók az adott problémára. Ha például az alkalmazás a bolygóknak a Naprendszerben elfoglalt helyét modellezi, a Bolygó osztály valószínûleg rögzíti a bolygónak a Naptól mért távolságát és a pályáját (lásd az 5.2. ábrát), de a magösszetételét nem.
5.2. ábra Jellemzõkkel ellátott Bolygó osztály
Kedves lakó! Az osztályokban szereplõ jellemzõk határozzák meg az osztály által rögzíteni kívánt elvont fogalom természetét. Ez kulcsfontosságú lehet a projekt sikere szempontjából. Egyszer részt vettem egy olyan munka záróértékelésen, amely „komoly gondokkal” küszködött. Az egyik probléma forrása a „Cím” osztály volt. A csoportnak az volt az elképzelése a „cím”-rõl, hogy az otthonunk helyét jelöli. Ugyan a cím ezen felfogása nem helytelen, az adott alkalmazás szempontjából azonban mégsem volt a legszerencsésebb, mert az alkalmazás nem házak elhelyezkedésével foglalkozott, hanem levelezõprogram volt. Ebben a környezetben a cím megfelelõbb leírása az lett volna, hogy „az a hely, ahová levelet küldünk” (ami lehet az otthonunk, utazás során egy szálloda, betegség esetén kórház, hétvégi ház és így tovább).
103
UML05.qxd
104
8/30/2006
3:04 PM
Page 104
UML földi halandóknak
1. Ügyeljünk, hogy az osztályok és azok jellemzõi az alkalmazás szempontjából megfelelõ fogalmat rögzítsék!
A jellemzõket az adatok összefüggésében is vizsgálhatjuk. Az objektumközpontú elemzés és tervezés egy egységbe zárja (betokozza) az adatokat és a feldolgozást. A jellemzõk az osztály belsejébe ágyazott adatok. Az osztályban szereplõ adatok (jellemzõk) a jellemzõk láthatóságától függõen más osztályok számára is elérhetõk lehetnek. A jellemzõk nyilvános, védett, privát vagy csomag láthatósággal rendelkezhetnek (lásd az 5.1. táblázatot). 5.1. táblázat Láthatóság Privát Védett Nyilvános Csomag
Láthatóságfajták
Jelölés # + ~
Jelentés Ezeket a jellemzõket csak maga az osztály érheti el. Ezeket a jellemzõket az osztály minden gyermekosztálya elérheti. Ezeket a jellemzõket bármelyik osztály elérheti. Ezeket a jellemzõket az adott csomag összes osztálya elérheti.
Elméletben az osztályok összes jellemzõjének privátnak kell lennie, hogy biztosítsuk az erõs betokozást (ami megakadályozza, hogy a jellemzõket más objektumok elérjék vagy megváltoztassák, kivéve ha a tulajdonos objektum lehetõvé teszi ezt). Ennek ellenére kerülhetünk olyan helyzetbe, például részletes tervezés vagy megvalósítás során, amikor „enyhíteni” kell a betokozás mértékét. Ilyen esetekben eltérõ láthatósági szintek alkalmazásával nagyobb hozzáférést biztosíthatunk az osztályok jellemzõihez. Ha azonban nincs kifejezetten szükség más láthatóságra, a jellemzõknek privátnak kell maradniuk. Mit csinálnak tehát az osztályok? Ezt az osztály mûveletei határozzák meg. Mûveletek A mûveletek az osztályok által biztosított szolgáltatások. A mûveletek az osztályszimbólum harmadik rekeszében láthatók. Azok a mûveletek, amelyek hozzáférést biztosítanak a jellemzõkhöz, általában az osztály többi végrehajtó függvényével azonos helyen tárolódnak (lásd az 5.3. ábrát). A külsõ objektumok így kapnak hozzáférést a tulajdonos objektum privát jellemzõihez. Lehet, hogy nem maga az osztály hajtja végre az összes mûveletet, de az osztály felelõs azért, hogy valami elvégezze a mûveleteket (például egy másik objektum, amely ténylegesen teljesíti a feladatot). Ilyenkor az osztály vezérlõ osztályként mûködik, az alkalmazás egészét vagy egy részét irányítva.
UML05.qxd
8/30/2006
3:04 PM
Page 105
5. fejezet • Alkalmazásmodellezés
5.3. ábra A Bolygó osztály a hozzáadott mûveletekkel
A rendelkezésre álló diagram kiforrottságától függõen lehet, hogy csak a mûvelet neve látható. Ahogy egy mûvelet fejlõdik, kialakul a teljes aláírása, amelyben megjelenik a neve, a paraméterei, az alapértelmezett értékei, a visszatérési típusa és így tovább (lásd 5.4. ábra). Az, hogy mennyi részletet írunk le, attól függ, hogy az adott szervezet hogyan alkalmazza a modellezést, azaz hogy mennyi részletre van szükség, mielõtt átadhatjuk a felépítést a programozóknak a megvalósításhoz.
5.4. ábra A Bolygó osztály a mûvelet-aláírásokkal
A szabályok megszegése II. Ahhoz hasonlóan, ahogy az „osztály” és az „objektum” kifejezést rokon értelmûként használjuk, amikor UML modellekrõl van szó (ahogy a fejezet korábbi részében taglaltuk), a „mûvelet” és a „függvény” szó is azonos jelentéssel fordul majd elõ, ami elvileg szintén helytelen. A mûvelet egy olyan szolgáltatást
105
UML05.qxd
106
8/30/2006
3:04 PM
Page 106
UML földi halandóknak ír le, amelyet az osztálya biztosít, a (tag)függvény viszont az adott mûvelet megvalósítása. Számos függvény (megvalósítás) teljesíthet egy mûveletet. Ha például adott egy Rendezés mûvelet, a függvény buborékos rendezéssel, hasító rendezéssel vagy más rendezési algoritmussal is megvalósíthatja a mûveletet.
Találkozhatunk {abstract} (elvont) jelölésû mûveletekkel is. Ez azt jelzi, hogy nem az adott osztály valósítja meg a mûveletet, hanem az egy gyermekosztályban valósul meg, ahol ugyanaz a mûvelet a gyermek mûveletrekeszében is szerepel. Ez az egyik lehetõség, hogy egy mûvelet egyedi megvalósításokkal rendelkezzen. A „tölt” mûvelet például teljesen más módon valósulna meg a „Puska” és a „Fúvócsõ” osztályban. Ez a többalakúság fogalmának központi gondolata (lásd az 5.5. ábrát): ha a gyermek olyan mûveletet ír le, amely a szülõosztályban is szerepel, akkor a gyermek mûvelete felülbírálja a szülõ mûveletét. Ily módon a gyermek mûködése módosíthatja vagy felválthatja a szülõ viselkedését.
5.5 ábra Többalakúság
Az osztályok mûveletei lehetnek olyan függvények, amelyeket az osztály saját akaratából, vagy olyanok, amelyeket más objektumok utasítására hajt végre. A mások által kérhetõ mûveleteket befolyásolhatja a láthatóság (lásd a korábbi 5.1. táblázatot), ami a mûveletekre ugyanúgy érvényes, mint a jellemzõkre. Egy másik UML elem, amely korlátozhatja, hogy más osztályok milyen szolgáltatásokat kérhetnek, a felület. A felület csupán egy mûveletcsoport, amelyet egy külsõ elem láthat, és ezáltal meghívhat (lásd az 5.6. ábrát). Az osztály tervezõje határozza meg, hogy a felület milyen mûveleteket tesz láthatóvá.
UML05.qxd
8/30/2006
3:04 PM
Page 107
5. fejezet • Alkalmazásmodellezés
5.6. ábra Felülettel rendelkezõ osztály
Társítások Ahogy a 4. fejezetben kifejtettük, a társítások a rendszerobjektumok közötti kapcsolatot mutatják. Jellemzõen az objektumok közötti adatátviteli csatornákat ábrázolják, amelyek a korábban tárgyaltaknak megfelelõen lehetnek kétirányúak vagy egyirányúak. Az irányítottságot (más szóval vezérelhetõséget) általában a tervezési szakasz késõbbi részében kell meghatározni, amikor már többet tudunk arról, hogy a feldolgozás hogyan keresztezi a társításokat. Így kiderül, miként kell optimalizálni a társítások megvalósítását. Egyéb társításjelzések A társítások végén megjelenõ jelzésekrõl (például mennyiség, rombusz) szintén szó esett a 4. fejezetben. Gyakran találkozunk majd néhány másikkal is.
5.7. ábra Szerepnevek
A szerepnevek a társítás végén jelenhetnek meg. Ezek a társítás szerepnevekkel megegyezõ végén található osztályokat írják le. A szerepnév azt jelöli, hogy az osztály az adott kapcsolatban hogyan viselkedik majd a hozzá társított osztállyal. Ez hasonlít ahhoz, ahogy
107
UML05.qxd
108
8/30/2006
3:04 PM
Page 108
UML földi halandóknak az életben is több szerepet játszunk. A szerzõ másként viselkedik mérnökként és befektetõként (noha elõfordulhatnak azonos viselkedésformák). Egy mérnök olvashat, elemezhet, tervezhet, építhet és így tovább. Egy befektetõ olvashat, elemezhet, eladhat, vásárolhat, könyvelést vezethet és hasonló tevékenységeket végezhet (lásd az 5.7. ábrát). Ilyen módon a szerepnevek elkülönítik az osztályaik viselkedését. A szerepnevek különválasztják az egy osztály és egy másik osztály közötti társításban megfigyelhetõ viselkedéseket, a minõsítõk viszont azokat az objektumcsoportokat különítik el, amelyek társításban vehetnek részt. Lássunk néhány példát a Bérlista és az Egyén osztály alkalmazásával.
5.8. ábra Jelzés nélküli társítás
Az 5.8. ábrán azt láthatjuk, hogy a Bérlista részleg fizet az Egyénnek. Az 5.9. ábra azt mutatja, hogy a szerepnév hozzáadásával hogyan lehet egyértelmûbbé tenni a dolgokat: a Bérlista fizet az Egyénnek, aki alkalmazottként (és nem vállalkozóként vagy gyártóként) viselkedik. Egyik diagram sem igazán pontosan körülírt.
5.9. ábra Szerepnévvel ellátott társítás
Amikor az 5.10. ábrán látható módon minõsítõt (az alkalmazott számát) adunk a diagramhoz, tudjuk, hogy csak az adott Egyén objektum vesz részt a társításban (azaz csak a meghatározott alkalmazottszámmal rendelkezõ Egyén kap fizetést). Ha ehhez hozzáteszünk egy mennyiséget, további információval bõvítjük a modellt. Az 5.11. ábrán láthatjuk, hogy a 0..1 mennyiség miatt a Bérlista vagy senkinek nem fizet (ami azt jelenti, hogy az alkalmazottszám nem tartozik alkalmazotthoz), vagy egy adott alkalmazottnak fizet.
5.10. ábra Szerepnévvel és minõsítõvel ellátott társítás
UML05.qxd
8/30/2006
3:04 PM
Page 109
5. fejezet • Alkalmazásmodellezés
5.11. ábra Szerepnévvel, minõsítõvel és mennyiséggel ellátott társítás
A minõsítõ és a mennyiség megváltoztatásával az 5.12. ábrán is látható új jelentést kapunk, ahol a Bérlista több teljes munkaidõs alkalmazottnak fizet (a részmunkaidõs alkalmazottakat a „teljes munkaidõs” minõsítõ kizárja).
5.12. ábra Szerepnévvel és egy objektumcsoportot kijelölõ minõsítõvel ellátott társítás
Az osztálydiagramokról bõvebben Halmaz és összetétel A 4. fejezetben említettünk két rokon társítást: a halmazt (aggregation) és az összetételt (composition). (Az UML 2.0-ban az összetétel társítást összetett halmaznak is nevezik.) Az 5.13. ábrán láthatjuk a két társítást.
5.13. ábra A halmaz és az összetétel társítás
A halmazt üres (vagy lyukas), az összetételt kitöltött rombusz jelöli. A rombusz mindkét esetben a társítás „Teljes” végén jelenik meg. Ezeket a társításokat a következõképpen kell értelmezni: „a Rész az Egész része” illetve „az Egésznek van egy Része” (az adott részek számát a társítás rész végénél szereplõ mennyiség határozza meg). Ezek a társítások azt a különleges jelentést hordozzák, hogy a társítás egyik eleme a másik „része”. A halmaz és az összetétel között az jelenti a különbséget, hogy milyen szoros a részt vevõ elemek közötti kapcsolat. A halmaz lazább társítás, míg az összetétel sokkal szorosabb összetartozást jelöl. Az összetételben a Részek csak egy Egész részei lehetnek, továbbá az Egész megszûnésekor az összes része is megsemmisül (sõt az Egész feladata gondoskodni arról, hogy a részei megszûnjenek). Az 5.14. ábra egy zseblámpa példáján mutatja be ezeket a kapcsolatokat.
109
UML05.qxd
8/30/2006
110
3:04 PM
Page 110
UML földi halandóknak
5.14. ábra Egy zseblámpa halmaza és összetétele
A zseblámpának van egy kapcsolója. Ez összetétel, mivel a kapcsoló annak az egy zseblámpának a része. Ha eldobjuk (megsemmisítjük) a zseblámpát, a kapcsoló is követi. Az elemet viszont eltávolíthatjuk a zseblámpából, és egy másikban alkalmazhatjuk, ezért ez a kapcsolat halmazként jelenik meg. Ügyeljünk azonban, hogy ezek a „rész–egész” kapcsolatok nem csak kézzel fogható (fizikai) elemekre érvényesek. Egy Egyénnek például lehet Hite, Márkaneve vagy Piaci értéke is. Általánosítás A fejezet egy korábbi részében felbukkant az általánosítás kapcsolat (lapozzunk vissza az 5.5. ábrához). A társítás nyílhegyénél szereplõ osztályok a fölérendelt osztályok, a társítás másik végén szereplõ osztályok pedig az alárendelt osztályok. A fölé- és alárendelt osztályok kapcsolata a gyermek–szülõ kapcsolathoz hasonlítható. A gyermek- (alárendelt) osztályok öröklik a szülõ- (fölérendelt) osztályok jellemzõit, mûveleteit és kapcsolatait.
Fegyver
5.15. ábra Általánosítás
UML05.qxd
8/30/2006
3:04 PM
Page 111
5. fejezet • Alkalmazásmodellezés Az 5.15. ábra egy ilyen kapcsolatot szemléltet. A szülõ (Fegyver) a súly, a hossz és a hatótávolság jellemzõvel rendelkezik. A gyermekek (a Puska és a Fúvócsõ) öröklés révén átveszik ezeket a tulajdonságokat, vagyis ezeknek is lesz súlyuk, hosszuk és hatótávolságuk, annak ellenére, hogy az alosztályokban ez nem feltétlenül jelenik meg külön. Ugyanez igaz a mûveletekre is – a gyermekek a szülõktõl öröklik azokat. Ebben a példában – ahogy korábban is kifejtettük – a gyermekosztályok felülbírálják (vagyis átformálják) a „tölt” mûveletet. Társításosztály ok Elõfordul, hogy amikor elkezdjük összekapcsolni az osztályokat (társításokon keresztül), olyan helyzetbe kerülünk, amikor nem maguk az osztályok, hanem a közöttük lévõ kapcsolat a lényeg. Az 5.16. ábra például egy olyan befektetõt jelenít meg, aki különbözõ részvényekbe fektet be.
5.16. ábra Alaptársítás
Ha az alkalmazásnak ki kell számítania a befektetés adóvonzatát, akkor ismernie kell olyan adatokat, hogy mikor vásárolták és adták el a részvényt, az árfolyamokat és így tovább. A vásárlás dátuma tehát a befektetõ jellemzõje? Egyértelmûen nem. A részvényé? Nem igazán, mivel a vásárlás idõpontja nem a részvény belsõ tulajdonsága. Ez az információ a befektetõ és a részvény kapcsolatát írja le, és nem az osztályokét. Ebben a helyzetben a kapcsolat a lényeg.
5.17. ábra Társításosztály
111
UML05.qxd
112
8/30/2006
3:04 PM
Page 112
UML földi halandóknak Hol rögzítjük tehát ezt az információt? Társításosztályokban. (Amikor már azt gondoltuk, hogy biztonságban vagyunk, és megértettük az összes osztályokkal és társításokkal kapcsolatos dolgot, akkor jön a csavar.) A társításosztályok olyan társítások, amelyek rendelkeznek az osztályok bizonyos tulajdonságaival. A következõ példában a kulcsfontosságú információ, amire szükség van, a részvény és a befektetõ birtokviszonyával kapcsolatos (lásd az 5.17. ábrát). A Birtokviszony társításosztály tartalmazza a két másik osztály közötti kapcsolat fontos adatait. (A társításosztályokat gyakran látjuk még a több elem közötti társításoknál.) A befektetõ nélkül nincs vásárlás, a részvény nélkül viszont nincs mit megvenni: együtt van szükség a befektetõre és a részvényre. A kapcsolat nem létezhet a két társított osztály létezése nélkül, így a társításosztály sem. Megszorítások Az UML által biztosított megszorítások lehetõvé teszik, hogy érthetõbbé és kifejezõbbé tegyük a tervet. A megszorítások olyan jelölések, amelyek tovább korlátozzák vagy pontosítják a modellelemeket. Az 5.18. ábránál visszatérünk a bérlista példájához. Ha a vállalatnál minden héten fizetést osztanak, hozzáadhatunk egy olyan megszorítást, amely kifejezi ezt (a kapcsos zárójelben látható). A megszorítások lehetnek idõbeli, sorrendbeli megszorítások, egyedi tulajdonságok, vagy bármi, ami az adott helyzetben szükséges.
5.18. ábra Megszorítás
A sorrenddiagramokról bõvebben Ahogy az osztálydiagramok az alkalmazás statikus szerkezetét ábrázolják, a sorrenddiagramok képesek az alkalmazás dinamikus viselkedésbeli jellegének megjelenítésére. Mint azt a 2. és a 3. fejezetben elmondtuk, azt mutatják, hogy az alkalmazás objektumai miként mûködnek együtt, hogy üzenetek alkalmazásával elérjék a kívánt végeredményt. A diagramok másik felhasználási területe (vagyis az alkalmazásmodellezés) további bizonyíték a sokoldalúságukra. Az állapotdiagramot – amely szintén viselkedésdiagram – a 8. fejezetben tárgyaljuk. A következõ diagramok példával szemléltetik a sorrenddiagramok használatát az alkalmazásmodellezésben. Az 5.19. ábra egy orvosi feljegyzéseket kezelõ rendszer együttmûködésszabályozó alrendszerét mutatja.
UML05.qxd
8/30/2006
3:04 PM
Page 113
5. fejezet • Alkalmazásmodellezés
5.19. ábra Együttmûködési feladatdiagram
Ebben a példában a „LACS átadása” feladatra összpontosítunk. Ahhoz, hogy megfeleljenek a szabályozási követelményeknek, az egészségügyi intézményeknek adatokat kell szolgáltatniuk a kormánynak a gondozásukban álló betegekrõl. Ezt az egészségügyi feljegyzéscsoportot Legkisebb Adatcsoportnak (LACS) nevezik. A sorrenddiagram a rendszer dinamikus mûködését rögzíti (lásd 5.20. ábra).
5.20. ábra Együttmûködési sorrenddiagram
113
UML05.qxd
114
8/30/2006
3:04 PM
Page 114
UML földi halandóknak A diagram üzenetfolyamát követve láthatjuk, hogy az Ügyintézõ létrehoz egy „Köteget”, ahová a LACS-ok kerülnek. A kiválasztott LACS-ok a Köteghez adódnak, majd az Adatközvetítõhöz kerülnek, és így tovább, ahogy a mûveletsor folytatódik. Ez a sorrenddiagram bemutatja a rendszer elemei közötti dinamikus kölcsönhatásokat. Ez biztosítja az alapot az elemek szerkezetének meghatározásához, ami az 5.21. ábrán – ez a „LACS átadása” feladat osztálydiagramja – látható. Az objektumközpontú rendszertervezés meglehetõsen sok ismétléssel jár. Az osztályfelépítés fejlesztésekor a tervezõ rájött, hogy új rendszerelem kell a Kötegek létrehozásához és átadásához. Így láthatjuk, hogy a diagramban megjelenik egy Kötegkezelõ. Egy szigorú rendszerben frissítenék a sorrenddiagramot, hogy az tartalmazza a Kötegkezelõt. Az alkalmazástervezés elõrehaladtával gyakran fordulnak elõ ismétlések és változások a különbözõ diagramok között. (Ha valaki meg szeretné érteni az itt szereplõ példa folyamatát és fejlõdését az üzleti modellezéstõl az alkalmazásig, a szerzõk UML for Database Design [NAIB3] címû könyvében megtalálja a tanulmány részletes kidolgozását.)
5.21. ábra Együttmûködési osztálydiagram
UML05.qxd
8/30/2006
3:04 PM
Page 115
5. fejezet • Alkalmazásmodellezés
Haladóknak A következõ témákat érdemes tanulmányozni: • Az osztályokban a név, a jellemzõk és a mûveletek rekeszén kívül további rekeszek szerepelhetnek. Keressünk példát az alkalmazásukra. • Vizsgáljuk meg a származtatott jellemzõk gyakran alkalmazott elvét. • Tanulmányozzuk a függõség viszonyt. • Derítsük ki a megvalósításosztályok, a típusok és a paraméterezett osztályok (más néven sablonosztályok) közötti különbséget. • Az ebben a fejezetben szereplõ társítások mindig két osztályt kapcsolnak össze. Vannak helyzetek, amikor kettõnél több osztály vesz részt egyetlen kapcsolatban. Tanulmányozzuk az „n-es kapcsolatokat”. • Hasonlítsuk össze és állítsuk szembe egymással a sorrenddiagramokat és az együttmûködési diagramokat.
Kifejezések Felület Osztály Többalakúság UML-rendõrség Láthatóság Aláírás Felülbírálás Jelzés Minõsítõ Halmaz Összetartozás Megszorítások Általánosítás
Beburkolás Objektum Fogalom Betokozás Mûvelet Elvont Társítás Szerepnév Mennyiség Összetétel Társításosztály Jellemzõ Öröklés
115
UML05.qxd
116
8/30/2006
3:04 PM
Page 116
UML földi halandóknak
Összefoglalás A fejezet elején felsoroltuk az alkalmazások modellezése mellett szóló érveket. Rámutattunk, hogy az átlagos rendszertervezõ blokkvázlatok, folyamatábrák és hasonló módszerek segítségével már eleve modellezi az alkalmazásokat. Megtudtuk, hogy a szabványos (UML alkalmazásával történõ) modellezés egyaránt hasznos az új és az öröklött alkalmazásoknál, különösen, ha a program rendkívül fontos, bonyolult, illetve folyamatosan változik. Megvizsgáltuk az alkalmazásmodellezés személyes és szakmai indokait is. Ez után körüljártuk azt a kérdést, hogy milyen szélességben és mélységben kell modellezni az alkalmazásokat. Ugyan az a legjobb, ha a teljes alkalmazást modellezzük, de az alkalmazás vagy a rendszer egyes részeinek modellezéséhez szükséges különbözõ követelményeket és megoldásokat is megismertük. Azt is megtanultuk, hogy nem szabad azt hinni, hogy a programozási nyelvek helyettesíthetik a megfelelõ elemzést és tervezést. Végül megismertük az osztálydiagramokban található fõ elemeket: a jellemzõkkel és mûveletekkel rendelkezõ osztályokat és az azok közötti társításokat. Bevezettük a többalakúság, a betokozás, a láthatóság és a megszorítások fogalmát. Elsajátítottuk a szerepnevek, a minõsítõk és a mennyiségjelzések használatát. Ezen kívül összehasonlítottunk két különleges társítást: a halmazt és az összetételt. Végül az általánosítást és az öröklést is tárgyaltuk.
Ellenõrzõ kérdések 1. Igaz vagy hamis? „A többalakúság elve azt mondja, hogy az osztályok adatai rejtettek a külsõ egységek számára, és csak belsõ egységek érhetik el azokat, az osztály által biztosított mûveleteken keresztül.” 2. Milyen korlátozást alkalmaznak a szerepnevek egy osztályra? 3. A minõsítõk azon osztályok meghatározott objektumait jelölik ki, amelyek... a. a társítás minõsítõhöz közelebbi végén találhatók. b. a társítás távolabbi végén találhatók. 4. Igaz vagy hamis? „Egy halmazban az Egész megsemmisülésekor nem feltétlenül semmisül meg az összes Rész.” 5. Az alábbiak közül melyik nem láthatóságfajta? a. Privát b. Részleges c. Látszólagos d. Nyilvános e. Elvont f. Csomag g. Védett
[NAIB3] Naiburg, Eric J. és Robert A. Maksimchuk. 2001. UML for Database Design. Boston, MA: Addison-Wesley.
