Szoftvertechnológia 2008/2009. tanév 2. félév 3. óra. Szoftvertechnológia

Átírás

1 Szoftvertechnológia Szabolcsi Judit 2008

2 (Ajánlott irodalom: R. A. Maksimchuk E. J. Naiburg: UML földi halandóknak. Kiskapu Kiadó, Budapest és Harald Störrle: UML 2. Panem Kiadó, Budapest 2007.) IV.4. Objektumdiagram A rendszerben egy adott idıpillanatban szereplı objektumok pillanatképét jeleníti meg. Itt az osztályokat példányosítjuk, ezek a példányok lesznek az objektumok. Az objektum rajzjele: Péter : hallgató : árucikk kód = 5123 név = kerékpár ár = Az elsı objektum a hallgató osztály Péter nevő példánya. A másik példa egy név nélküli, árucikk típusú objektumot mutat be, amit az attribútumai értékeivel jellemzünk. (Kód, név és ár attribútumai vannak.) Az osztály- és az objektumdiagram kapcsolata: classa 1..* classb a : classa :classb Az elsı rajz az osztálydiagram, ahol egy-sok típusú asszociációs kapcsolatban van a classa és a classb osztály. Ebbıl a második rajzon látható objektumdiagram készülhet, ahol az a nevő classa típusú objektum van összekapcsolva egy név nélküli, classb típusú multiobjektummal. Ami az osztálydiagramon reláció (itt a példában az asszociáció), azt az objektumdiagramon összekapcsolásnak nevezzük. Az objektumdiagram az osztálydiagram relációjának számosságát is mutatja, hiszen az a objektum sok (1..*) classb típusú objektummal van összekapcsolva. Másik példa: személy * gyerek Zsolt : személy apa gy gy Zoli : személy apa/anya 0..2 Lujza : személy anya gy gy Évi : személy Az elsı ábrán egy osztálydiagram látható, ahol a személy osztály saját magával van asszociációs kapcsolatban (reflexív asszociáció). Az anya/apa doboz neve minısítı, és az osztály objektumainak egy részhalmazát határozza meg. (Nyilván nem minden személy szülı, csak a személyek egy részhalmaza, csoportja.) A gyerek felirat az asszociációs vonal osztály felıli végén egy szerepkör.

3 A szerepkör azt írja le, hogy az adott relációban mi a szerepe a személy osztály tagjainak. Az asszociáció számossága: egy gyereknek 0, 1 vagy 2 (vér szerinti, élı) szülıje van, és minden szülınek *, vagyis akárhány (vér szerinti, élı) gyereke van. Ehhez az osztálydiagramhoz egy lehetséges objektumdiagram egy négytagú családot ábrázol, ahol Zsolt és Lujza személyeknél látható a minısítı (apa, illetve anya), Zoli és Évi pedig gyerekek (az ábrán gy betővel rövidítettem a gyerek szerepkört, helyhiány miatt). Látható tehát, hogy az objektumdiagramban az osztálydiagram osztálya(i)ból példányosított objektumok szerepelnek, olyan összekapcsolással, amit szintén az osztálydiagram relációi határoznak meg. Még egy utolsó példa: sokszög pont 3..* A {ordered} D S sokszög C B A : pont elsı S : sokszög B : pont második C : pont harmadik D : pont negyedik Az osztálydiagram sokszög és pont osztályát egy tartalmazás reláció köti össze. A reláció számossága 3..* vagyis egy sokszöghöz legalább 3 pont kell. Az {ordered} egy megszorítás, azt jelenti, hogy a pontok sorrendje fontos, nem cserélhetık fel. Az osztálydiagram mellett látható egy S nevő négyszög. A négyszög által meghatározott objektumdiagramot készítettem el. Az {ordered} megszorítást az objektumdiagramban a tartalmazás relációk pont felıli végére írt szerepkör (elsı, második, harmadik, negyedik) helyettesíti. IV. 5. Csomagdiagram Az UML-elemek csoportosítására, közös névtérben való elhelyezésére alkalmas. Csomag: Csomag

4 A csomagok tartalmazhatják egymást: adatbáziskezelı-rendszer SQL RDBMS fájlkezelı A csomagbeli elemekhez láthatóságot is rendelhetünk, de csak public és private-ot. Ha nincs megadva láthatóság, akkor az elem nyilvánosnak számít. A csomag összes nyilvános eleme minden más névtérbıl elérhetı a teljes minısített név segítségével (teljes minısített név: gyökércsomag_neve::csomag_neve::elemnév, ha a csomagokat egymásba ágyazzuk). A teljes minısített név használata azonban sokszor kényelmetlen. Egyrészt ezek a nevek nagyon hosszúak, másrészt a csomaghierarchia struktúrája így minden névbe bele lesz építve, ami a hierarchia átszervezését megnehezíti. Ezért kívánatos, hogy egyfajta relatív úttal is hivatkozni lehessen az elemekre. Ezt teszi lehetıvé az importkapcsolat: Utasnyilvántartó <<import>> személy as utas Adatbázis + személy Az ábra Utasnyilvántartó csomagja importálja a személy osztályt (publikus/public ezért van elıtte a plusz jel) az Adatbázis csomagból, és egyúttal utasnak nevezi át a saját névterében. Egy másik, csomagok között használható kapcsolatfajta a beolvasztás (merge): X <<merge>> Y Itt az X csomag olvasztja be Y-t, vagyis az Y csomag tartalmát Y::elemnév néven belerajzolhatjuk az X-be. IV.6. Összetevı diagram Komponens: a rendszer fizikailag létezı és kicserélhetı része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel.

5 A komponens nagysága változó lehet, az egy-két osztályt tartalmazó kis mérető komponenstıl az egész alrendszert tartalmazó nagy méretőig. (A komponens lehet egy EJB vagy Corba komponens is.) A komponens egy egységbezárt, önálló, teljes és ezáltal cserélhetı egység, amely függetlenül mőködtethetı, telepíthetı és összekapcsolható más komponensekkel. Az osztály és a komponens fogalma nagyon hasonló az UML-ben, már csak azért is, mert a komponens az UML-metamodellben (metamodell ami leírja a modell és a benne található diagramok kapcsolatát és jelentését) osztályok egy alosztálya, tehát rendelkezik az osztályok összes jellemzıjével. Egy példa komponensdiagramra: A komponenseket vagy az ábrán a téglalapok jobb felsı sarkában látható rajzjellel vagy a <<component>> sztereotípiával lehet megjelölni. A komponens rendelkezhet elvárt interfésszel (itt az Order (Rendelés) komponens rendelkezik három elvárt interfésszel), illetve nyújtott interfésszel (a gömb, az Account (Számla), a Customer (Vásárló) és a Product (Termék) komponensek rendelkeznek vele). Az interfészeket csatlakozóba (Port) foghatjuk össze (a rajzjele egy kis téglalap). Egy csatlakozó a komponens összes interakcióját összefogja, a nyújtott és az elvárt interfészeket, sıt ezek használati protokollját is. Egy bonyolult csatlakozót akár állapotautomataként (State Machine) is fel tudunk majd rajzolni (amikor megismerkedünk az állapotautomatákkal).

6 A következı két ábra ugyanazt jelenti. A kilens és a szerver nevő komponensek egy-egy összeillı nyújtott és elvárt interfésszel rendelkeznek. A második ábra ezt egyszerőbben mutatja be, az interfészeket és a kapcsolatukat egy összekötı (Connector) helyettesíti. red Trial Version cmp Component EA Model 7 red T kliens szerv er red T red Trial Version cmp Component EA Model 7 red T kliens összekötı szerv er red T IV.7. Összetett szerkezet diagram A teljes rendszer vagy egy összetettebb osztály felépítését írja le. Strukturált osztály: az osztály belsı szerkezetét is megmutatja. BalElsı: Kerék Autó ElsıTengely ElsıTengely JobbElsı: Kerék BalHátsó: Kerék HátsóTengely JobbHátsó: Kerék Rendszernél (egy légitársaság): A portokra nevet is írhatunk, itt pl. GUI- Graphical User Interface. AAA Foglalás GUI GUI Utasfelvétel GUI

7 IV.8. Kialakítás diagram Minden modellezett szoftverrendszer végül egy számítógép vagy számítógép-hálózat által lesz végrehajtva. Szoftver alatt itt a kódot, a hozzá tartozó adatokat és a beállítási, konfigurációs fájlokat is értjük. A kész fizikai rendszer (szoftver- és hardverkomponensek) felépítését mutatja be ez a diagramfajta. Kétféle megközelítés létezik, az elsı szerint a rendszerstruktúrát hangsúlyozzunk: deployment Deployment Model rial Version EA 7.1 Unregistered vtrial ezérlı Version EA 7.1 Unregistered Trial Version forgókapu beszállóautomata «device» kártyaolv asó Itt csomópontok (Node) vannak (a téglatest a rajzjele), amik között asszociációs kapcsolatok lehetnek. A <<device>> sztereotípiával ellátott csomópont egy fizikai eszközt jelent. A csomópontok neveit konkrétabban is megadhatjuk, pl.: bsza5 : beszállóautomata. Ebben az esetben az aláhúzás a csomópont példányosítását jelenti, ahogy az osztályokból konkrét objektumokat hoztunk létre, itt is hasonló dologról van szó. A második megközelítés szerint a szoftverösszetevık rendszerre való kihelyezését hangsúlyozzunk, ilyenkor a telepítés részletei a lényegesek. Ehhez a fajta kialakítási diagramhoz szükség van a mőtermék (Artifact) fogalmára. Mőtermék (Artifact): az információ egy fizikai darabja, pl.: állományok, a futási idejő adatszerkezetek a memóriában, az adatbázistáblák, ek, dokumentumok, stb. Ezek a mőtermékek helyezhetık ki a csomópontokra. Az ábrán az alkalmazásszerver csomópontra két mőterméket helyeztünk ki, egy weboldal típusút és egy dokumentum típusút (természetesen más sztereotípiákat is meg lehet adni):

8 T deployment Deployment Model T «device» szerv er T «execution environment» Trial Version EA 7.1 Unregistered alkalmazásszerv er Tria Trial Version EA 7.1 Unregistered weboldal Tria T dokumentáció T T T T Ezzel megismerkedtünk az összes szerkezeti diagrammal. A továbbiakban a viselkedési vagy más néven dinamikus diagramokkal fogunk foglalkozni. IV.9. Használati eset (use-case) diagram Ez a diagram a rendszer viselkedését írja le, ahogyan az egy külsı szemlélı szemszögébıl látszik. A rendszer belsı szerkezetérıl vagy viselkedésérıl nem tesz említést, ezzel nem foglalkozik. Általában a fejlesztési ciklus elején készítjük. Használati eset diagram készülhet egy már meglévı rendszerrıl (hogy a mőködését jobban megértsük), vagy egy tervezett rendszerrıl (hogy összegyőjthessük a rendszerkövetelményeket, hogy megmutathassuk a megrendelıknek, felhasználóknak, és hogy a kész rendszer teszteléséhez is használhassuk majd). A használati eset diagram a következı összetevıkbıl áll: Használati eset: tevékenységek sorozata, amelyet a rendszer végre tud hajtani a szereplıkkel kommunikálva. Rajzjele az ellipszis, amibe vagy alá odaírjuk a nevét. Trial Version uc Use Case Model Trial Version Trial Version Trial Version rendelés feladása

9 Szereplı (Actor): személy, csoport, szervezeti egység vagy fizikai eszköz, aki vagy ami kapcsolatba lép a rendszerrel. Rajzjele egy pálcikaemberke. nregistered Trial Version uc Use Ca... nregistered Trial Version nregistered Trial Version nregistered Trial eladó Version nregistered Trial Version Rendszerhatár (Boundary): a megvalósítandó rendszer és a szereplık közötti határ. uc Use Case Model eladó.1 Unregistered Trial Version EA kiszállítás 7.1 Unregistered Trial Version raktáros rendszer rendelés feladása fizetés pénztáros v ásárló Természetesen a szereplık, a use-case-ek és szereplı-use-case között kapcsolatok is lehetnek. A szereplık és a use-case-ek között általában asszociációs kapcsolat van, ahogy az a fenti ábrán is látszik. Use-case-ek között <<include>> és <<extend>> kapcsolat szokott leggyakrabban elıfordulni. Az <<include>> kapcsolat azt jelenti, hogy egy résztevékenységet kiemelünk az alap use-case tevékenységsorozatából és azt külön use-case-ben tüntetjük fel. Ezt a résztevékenységet aztán más use-case-ek is használhatják. Az <<extend>> kapcsolatnál a kiterjesztı megszakíthat egy másik use-case-t a mőködésében. A megszakított nem is tud a megszakító létezésérıl (mint a patchprogramoknál). Ezek választható feladatok, ellentétben az <<include>> feladatokkal, amik

10 kötelezıek. Az ábrán látható, hogy a nyíl mindig attól indul, aki csinálja azt a bizonyos kapcsolatfajtát (aki include-olja a másikat vagy aki kiterjeszti, megszakítja a másik mőködését): nregistered uc Use Trial Case Version Model EA 7.1 Unregistered Trial Version nregistered Tria aki csinálj a (alap/tartalmazó) nregistered Tria nregistered Tria nregistered Trial aki csinálj Version a EA 7.1 Unregistered alap, akit felülír a Trial Version (kiterj esztı) «include» «extend» nregistered Tria rész kiterj esztı Az <<include>> és az <<extend>> kapcsolat megkülönböztetésére jó módszer a következı négy kérdés megválaszolása: 1. Szabadon választható-e a feladat (a use-case által ábrázolt tevékenységsorozat)? 2. Az alapfeladat teljes-e a feladat nélkül is? 3. Feltételhez kötött-e a feladat végrehajtása? 4. A feladat megváltoztatja-e az alapfeladat viselkedését? Azért jók ezek a kérdések, mert <<include>> kapcsolat esetén mindre NEM-mel lehet válaszolni, <<extend>> kapcsolat esetén viszont mindre IGEN-nel. Nézzünk erre egy példát: uc Use Case Model gistered T szerkeszti a gistered Trial Version EA 7.1 dokumentumot Unregistered Trial Version EA 7.1 dokumentumot Unregistered Trial Version gistered T gistered Trial Version EA «extend» 7.1 Unregistered «extend» Tria gistered T helyesírást ellenıriz «include» szinonímát keres elmenti a gistered T gistered T A példa egy szövegszerkesztı alkalmazás (mondjuk a Word) mőködésének egy részletét mutatja be. A szerkeszti a dokumentumot a fı tevékenység. Ebbıl kiemeltük az elmenti a dokumentumot. Tegyük fel, hogy még csak most készítjük a diagramot és még csak a use-case-ek vannak meg, a

11 kapcsolatok nem. Tegyük fel az elsı kérdést: szabadon választható-e a feladat? Gondoljunk bele: a dokumentum elmentése funkció nélkül mire lenne jó egy szövegszerkesztı? Ebbıl adódik a második kérdésre is a válasz: ha ilyen fontos a mentés, akkor nem teljes nélküle az alapfeladat. A harmadik kérdésre a válasz kevésbé egyértelmő, hiszen minden szövegszerkesztı rákérdez, hogy akarja-e menteni a dokumentumot. A negyedik kérdésre viszont ismét egyértelmő választ adhatunk, hiszen a mentés nem változtatja meg a dokumentum szerkesztés lépéseit, mert szervesen közéjük tartozik ı is. Tehát a négy kérdésbıl háromra egyértelmő nem-mel tudtunk válaszolni, ezért ez biztosan <<include>> kapcsolat lesz. A helyesírást ellenıriz és a szinonímát keres feladatok közül csak az elsıt nézzük meg, gondolom senki számára nem meglepı, hogy ez a két tevékenység eléggé hasonló logikával mőködik a modellezés szempontjából. A helyesírás ellenırzés szabadon választható-e? Persze, hiszen ha én azt gondolom, hogy tudok helyesen írni, vagy nincs is az adott nyelvhez helyesírás ellenırzı modul, akkor is tudok szöveget szerkeszteni. Az alapfeladat teljes-e a feladat nélkül. Az elıbbi válasz alapján: igen. Feltételhez kötött-e a feladat végrehajtása? Itt megint érvelhetünk az igen és a nem válasz mellett is.(igen, mert be kell kapcsolni a helyesírás-ellenırzı funkciót.) A feladat megváltozatja-e az alapfeladat viselkedését? Igen, hiszen ha bekapcsoljuk ezt a funkciót, az általunk beírt szöveget meg fogja változtatni, vagy pirossal aláhúz egyes szavakat, vagy ha az automatikus javítás is be van kapcsolva, akkor át is írhatja az általunk begépelteket. Tehát mivel itt is három kérdésre határozottan igen-nel lehet válaszolni, ezért ez a kapcsolat <<extend>> típusú lesz. A use-case-ek között elıfordulhat még általánosítás kapcsolat is, pl. egy beléptetı-rendszer tervébıl egy részlet: red Trial Version uc Use Case Model EA 7.1 Unregistered Trial Version red Tria az ügyfél azonosítj a magát red Tria red Tria red Tria red Trial Version retina alapj EA án 7.1 Unregistered mágneskártyáv Trial al Version azonosítj a azonosítj a magát red Tria A személyek között is megadhatunk általánosítás kapcsolatot, pl. egy számítástechnikai bolt és szerviz dolgozói lehetnek eladók vagy szerelık:

12 uc Use Case Model dolgozó szerelı eladó Végül nézzük meg, hogyan ellenırizhetjük, hogy a use-case diagramunk jó-e! Erre használhatjuk a MiSzHaT-próbát. Mi A feladat azt írja le, hogy Mit kell csinálni és nem azt, hogy hogyan? Sz A feladatot a Szereplı nézıpontjából írtuk le és nem a rendszerébıl? Ha A feladat végrehajtása Hasznos a szereplı számára? T A use-case diagram Teljes forgatókönyvet ír le, nem maradt-e ki valami? Kérdések (A válaszok beküldhetık: március 2-a délig) 1. Készítsen egy éttermi use-case diagramot, amelyben szerepel a pincér, a vendég és a szakács is és legalább 4 használati esetet (feladatot) tartalmaz! (4 pont) 2. Készítsen egy kialakítás diagramot egy ön által ismert rendszerrıl (nem kell feltétlenül számítógépes rendszernek lennie, de érje el azt a bonyolultságot, hogy legalább 4-5 csomópont legyen benne, és ezek között valamilyen kapcsolat is álljon fenn). (4 pont)