UML osztálydiagram; Így nyomon követi az objektum tájolását! megtanulni programozni
Keylearnings:
- Az osztályok közötti kapcsolatok bemutatása egy UML osztálydiagrammal.
- Mit kell figyelembe venni egy objektum-orientált tervezésnél?
- Az attribútumok és módszerek megjelenítése az osztálydiagramon.
- Mi a sokféleség?
- Hogyan képviseli az osztályok közötti kapcsolatokat.
- Mi a különbség az összesítés és az összetétel között?
- Az öröklődés ábrázolása az UML osztálydiagramon.
Már tudjuk.
Hacsak nem teszed rosszul, a pokolba kerülsz!
És biztosan nem akarunk oda menni!
Mielőtt megnyomná a billentyűket, feltétlenül gondolkodjon el.
Szívesen megteheti ezt a kertben egy hűvös kólával. A lényeg, hogy kéznél legyen egy íróasztal és egy ceruza radírral.
Vagy használhatja az UMLet ingyenes szoftvert.
Mivel az objektum-orientált tervezés nagy előnye, hogy az alkatrészek és azok kapcsolatai grafikusan ábrázolhatók egy szoftverrendszerben.
Pontosan úgy, ahogy itt tettük egy négylábú baráttal.
Az úgynevezett UML osztálydiagram nagyon intelligens módszer az osztályok és kapcsolataik vizuális ábrázolására. Az UML az Unified Modeling Language rövidítést jelenti.
Az osztálydiagram egy olyan eszköz, amelyet sürgősen hozzá kell adnia az eszköztárához.
Mint minden eszköz, az UML osztálydiagramot is csak akkor használhatja hatékonyan, ha megértette annak alkalmazási területét.
Tehát először beszéljünk arról, hogy mi miatt kell aggódnunk egy objektum-orientált kialakításban.
Objektumorientált tervezés az UML osztálydiagrammal
Egy osztály három összetevőből áll. Minden osztálynak van neve, tulajdonságai (más néven attribútumok) és metódusai.
Osztályokból hozunk létre konkrét tárgyakat (példányosítás). Például a kutyaosztályból Snoopy névvel és 20 kg súlyú kutyapéldány lesz.
Az osztály attribútumai leírják az objektum állapotát, például egy kutya nevét és súlyát.
A módszerek viszont leírják egy tárgy viselkedését, és képességeket adnak neki, például azt, hogy a kutya ugathat.
Az UML osztálydiagramon ezt a három elemet vízszintes vonalak választják el egymástól. Kutya példánkban az osztálydiagram így néz ki:
Legfelül az osztály neve található. Esetünkben az osztályt kutyának hívják.
A középső rész az osztály attribútumait tartalmazza. Tehát a kutya neve és súlya.
Minden attribútumnak van egy adattípusa, amelyet kettőspont választ el az adott attribútum neve után.
A módszerek a paraméterlistával és a visszatérési értékkel együtt szerepelnek az UML osztálydiagram alsó részében, a kettőspont utáni visszatérési érték adattípusával.
Itt egy nagyon egyszerű kutyával van dolgunk. Az ugatásos módszer mellett osztályunk csak az attribútumokra vonatkozó getter és setter módszereket tartalmazza.
Nincs más?
Biztosan észrevetted már!
Az attribútumokat mínusz jellel láttuk el - a módszereket pedig + jellel.
Mint az objektum-orientált programozás alapjairól tudod, a példányváltozóknak nem szabad kívülről láthatónak lenniük, hogy megvédjék őket a manipulációtól, vagyis privátnak kell nyilvánítani őket.
A szakterületen jártas szakember kapszulázásról beszél.
És pontosan ez jelenti a mínusz jelet -. Egy attribútumot vagy metódust, amelyet megelőz egy mínuszjel, privátnak nyilvánítjuk, míg a pluszjel + egy nyilvánosként definiált attribútumot vagy módszert jelent.
Természetesen az attribútumok és a módszerek védettként is meghatározhatók.
A védettnek vagy definiált metódusnak nyilvánított attribútumoknak csak magán az osztályon és az összes alosztályon kell láthatónak lenniük.
Az UML osztálydiagramon a # hash jellel védett láthatóságot jelöljük.
Osztályváltozók az UML osztálydiagramon
Eddig attribútumaink mindig példányváltozók voltak. Kutyaosztályunk minden példánya külön memóriaterületet foglal el.
De mi van, ha meg akarjuk számolni a létrehozott kutyaobjektumok számát?
Ehhez szükségünk van EGY egész változóra, amelyhez minden kutyapéldány hozzáfér.
Egy ilyen változót osztályváltozónak hívunk, és a Java-ban a statikus kulcsszóval definiáljuk.
Az UML osztálydiagramon az osztályváltozókat aláhúzással jelölik.
Gyerünk! Vegyünk egy osztályváltozót a fenti osztálydiagramba, amellyel megszámlálhatjuk a megtermelt kutyák számát.
Ugye ez könnyű volt? Csak aláhúzással egész hundZaehler változót kellett hozzáadnunk az UML osztálydiagram attribútumrészéhez.
Többszörösség az UML osztálydiagramon
Eddig megkönnyítettük magunknak. Eddig attribútumaink csak primitív adattípusokból álltak. De mit tegyünk, ha tömböt vagy tömblistát akarunk használni?
Van erre úgynevezett sokaság.
Természetesen kutyánknak három kedvenc játéka van, mégpedig szeretője, Lego és egy baseball ütő.
És pontosan ebben a sorrendben!
Tehát szükségünk van egy tömbre, amely ezt a három elemet a megadott sorrendben képes megtartani.
Ehhez a játékokat elfogadó attribútum mögé írjuk az úgynevezett multiplicitást [1.3] és az azonosítót.
A tömb kapacitását a multiplicitás segítségével határozhatjuk meg [1.3]. A kiegészítéssel jelezzük, hogy a rágalmazó játékok rendezett adatstruktúra, amelyben a sorrend fontos.
Ezenkívül egy büszke kutya minden nap új tápot talál, amely tetszik neki.
Ezért szükségünk van olyan adatstruktúrára is, amely tetszőleges számú elemet képes befogadni. Ezenkívül az egyes hírcsatornákat csak egyszer, azaz egyértelműen kell elmenteni az adatszerkezetben.
Az UML biztosítja a sokaságot [*] és az azonosítót erre a célra.
Bővítsük tehát még egyszer az UML osztálydiagramunkat.
Kutyánknak tetszőleges számú kedvenc étele lehet. Mindegyik étel azonban egyértelműen csak a kedvenc étel tulajdonságában menthető el. Olyan csillagkép, mint: "A kedvenc ételeim az 1. pizza, a 2. pizza és a 3. pizza" nem lehetséges a címke miatt.
Állandók az UML osztálydiagramon
A programok karbantarthatóságának növelése érdekében meg kell határoznia azokat az értékeket, amelyek nem változnak konstansokban.
Az összes konstans közül a leghíresebb a Pi. A 3.14 írása helyett . bárhol is számolunk a Pi számmal, a Math.PI állandót használjuk. .
Az állandókat a kulcsszó segítségével Java-ban nyilvánítják véglegesnek, és az UML osztálydiagramban hozzáadják őket.
Az állandók gyakori használata a verziószám. Bővítsük tehát újra az UML osztálydiagramunkat.
Mivel az osztály változata a kutya minden példányánál megegyezik, a VERSION változó olyan osztályváltozó, amelyet alá kell húzni az osztálydiagramon.
Az UML osztálydiagramtól a programkódig
Erőfeszítéseink célja egy futtatható program.
Eddigi összes erőfeszítésünk csak akkor lesz előnyös, ha az osztálydiagramot a lehető legkönnyebben lefordíthatjuk Java forráskódba.
És pontosan erről akarunk gondoskodni legközelebb.
Itt található az osztálydiagramból generált forráskód.
A második és a harmadik sorban deklaráljuk a primitív attribútumok nevét és súlyát .
Ezután egy tömblistát használunk a kedvenc játékok tárolására, és egy HashSetet használunk kutyánk kedvenc ételeinek tárolására.
Ehhez HashSet-et használunk, mert az étkezések szerinti jelölés miatt egyértelműen el kell mentenünk az adatstruktúránkba.
Végül, de nem utolsósorban hozzáadjuk a hundZaehler statikus számláló változót és a VERSION konstansot attribútumként a hatodik és a hetedik sorban.
A módszereket a nyolc-tizenkettő sorok sorolják fel.
Ez azt is világossá teszi, hogy az UML osztálydiagram NEM képes. Az osztálydiagram csak azt írja le, hogy az osztály mely módszereket teszi elérhetővé. Nem ad azonban utalást arra, hogy miként kell megvalósítani e módszerek funkcionalitását.
Tehát az osztálydiagram nem segít algoritmus modellezésében. Ebből a célból azonban az UML más diagramokat is tartalmaz, például a szekvencia diagramot.
Így ábrázolja a kapcsolatokat az UML osztálydiagramjában
Őszintén! Eddig mindez csak bosszantó és nem segít.
Minden erőfeszítés nélkül egyetlen kutyaosztályt kalapálhatott volna a számítógépbe.
Csak akkor válik érdekessé, ha szoftveres rendszerünk nem csupán egyetlen osztályból áll, és szeretnénk leírni, hogy ezek az osztályok hogyan kapcsolódnak egymáshoz.
Ahogy a való életben vannak barátságos, romantikus vagy üzleti kapcsolatok, az objektumorientációban is különböző típusú kapcsolatok vannak.
Kezdjük az első típussal, nevezetesen a függőségekkel, amelyeket a szakirodalomban gyakran függőségeknek is neveznek.
Az UML osztálydiagram függőségei
A kutya éhes és ételtálból eszik.
A Fressnapf egy olyan objektum, amelyet egy Fressnapf osztályból hozunk létre, és az enni a kutya osztály egyik módszere, paraméterként Fressnapf példány.
A Fressnapf példány nem szerves része a kutyának, hanem csak az evési módszer feldolgozásáig alkalmazzák.
Egy ilyen kapcsolatot használati kapcsolatnak nevezünk, és az UML osztálydiagramban egy karakterisztikával ellátott nyíl segítségével mutatjuk be.
UML társítások
Voltál már menhelyen?
Egy állatmenhelyen vannak állatok (akik ezt gondolták volna), nyulak, macskák, egerek és kutyák is, akikről az állatkert gondozója gondoskodik.
A menhelyen nyilvánvalóan van kapcsolat a kutya és az állattartó között.
A kapcsolat azonban nem olyan erős, hogy az egyik ne lehessen a másik nélkül.
Az állattartó és a kutya is létezhet önmagában.
A kutya boldogan beilleszthető a családba, és vannak olyan állattartók, akik csak Knut jegesmedvére vigyáznak.
Az ilyen gyenge kapcsolatokat az osztályok közötti egyszerű összekötő vonal segítségével mutatják be.
UML összesítések és összetételek
Gyakran olyan osztályokkal kell megküzdenünk, amelyek attribútumként más osztályok példányait tartalmazzák.
Például az állatmenhelyen előfordulhat, hogy őrző és kutya van.
Itt azonban ismét fontos, hogy mind a nevelő kutya, mind az állatkert-őrző létezhessen az állatmenhely nélkül.
A nevelő kutya még szegényebb kutya az állatmenhely nélkül, az állattartó pedig munkanélküli állattartó az állatmenhely nélkül.
De mindkettő még mindig ott van. Az ilyen kapcsolatot aggregációnak nevezik, és gyémánt előjellel jelölik az UML osztálydiagramjában.
A kompozíció!
Erősebb asszociáció az úgynevezett kompozíció.
Az ilyen típusú asszociációval a kapcsolat olyan erős, hogy a "konténer objektum" törlésekor az integrált objektum is eltűnik.
Pontosan ez a helyzet a Fressnapf-ünkkel is!
Mert ha eldobjuk az étellel töltött edényt, elveszítjük a benne lévő ételt is.
A kompozíciót befejezett gyémánt szimbólummal jelöljük.
Miben különbözik az összesítés és az összetétel a megvalósításban?
Az összesítés és az összetétel közötti döntő különbség a kapcsolat erőssége.
Nézzünk meg egy példát.
Itt létrehozunk egy kutya példány bello-t, amelyet az otthonban osztályozunk az állatmenhely osztály konstruktorának felhasználásával.
Mi történik Bello-val, amikor töröljük a menedékpéldányt?
Semmi! Mivel a bello példány a saját memóriaterületén található, amely független attól a területtől, ahol az állatmenhely található.
A menedékpéldány csak hivatkozást tartalmaz a bello objektumra .
Ezért ebben az esetben összesítésről van szó.
Vessünk egy pillantást a kompozícióra.
Itt létrehozunk egy étellel töltött ételt.
Az ételt a Fressnapf konstruktor érvelésével állítjuk elő, ezért az étel a Fressnapf számára fenntartott memóriaterületen van.
Tehát mi történik a hírcsatornával, ha töröljük a tál példányát?
Helyesen! A tálzal elveszítjük az ételt is, ezért ebben az esetben kompozícióról van szó.
Öröklés az UML osztálydiagramon
Hiányzik valami? igen, én is!
A kutya négylábú barát, akárcsak egy macska vagy egy elefánt. Ezért bemutatjuk a négylábú barátok osztályát, amelyben megvalósítjuk a négylábú barát általános tulajdonságait, és levezetjük belőlük az állatokat kutyát, macskát stb.
Az öröklődést egy nyíl segítségével mutatják be az UML osztálydiagramjában.
A négylábú barát a kutya felsőbb osztálya, amelyben megvalósítjuk azokat a módszereket és tulajdonságokat, amelyek mind a négylábúaknál közösek.
A négylábú barát a kutya felsőbb osztálya, a négylábú osztályra mutató nyíllal jelezzük.
elmélet és gyakorlat
Az itt leírt eljárást vízesési modellnek nevezzük.
A vízesés modellnél feltételezzük, hogy minden követelményt ismerünk a kezdetektől, és azt is feltételezzük, hogy ezek nem változnak a teljes fejlesztési folyamat során.
A gyakorlatban ez a követelmény sajnos gyakran nem teljesül, ezért alkalmazzák az iteratív fejlesztést, amelyben a tipikus fejlesztési munka, például a tervezés, a megvalósítás és a tesztek párhuzamosan zajlanak.
Minden iterációs lépésben pontosítják azokat a követelményeket, amelyeknek a szoftvereknek meg kell felelniük.
Az agilis szoftverfejlesztés jelenleg itt a legfontosabb kutya.
Végül, de nem utolsósorban a következő videóban szeretném bemutatni, hogyan lehet az osztálydiagramot átalakítani forráskóddá.
Következtetés: Még akkor is, ha az UML osztálydiagram létrehozása kezdetben felesleges további erőfeszítésnek tűnik, a valóságban értékes előkészítő munkát végez, ami rengeteg hibajavítást takarít meg a megvalósítás során.
Dolgozott már az UML osztálydiagrammal? Mi a tapasztalata Csak hagyj egy megjegyzést!
Tetszett a cikk? Akkor azonnal kövessen minket a Facebookon!
Kim Peter
Szia, a nevem Kim, és nagyszerű programozóvá akarok válni. Részt veszel?