UML modellezés¶
Képernyőtervek¶
-
Webalkalmazás szabásmintái
-
Gondoljuk át, hogy mit hol fognak elérni a látogatók
-
Ajánlott eszközök:
UML alapjai¶
A szoftverfejlesztési módszertanok megjelenésével még nagyobb hangsúly és igény alakult ki az előzetes tervezésre. Az UML (Unified Modeling Language) segítségével többrétegű rendszermodelleket tudunk ábrázolni, de fontos, hogy az egyes UML diagramok nem definiálják a fejlesztési lépések egymásutániságát. Az UML tehát egy grafikus modellező nyelv
A szoftverfejlesztési életciklusban a modellezés tipikusan a kezdeti szakaszokra jellemző (lásd 1-2. mérföldkő). Hatása egyértelmű, alapos és helyes tervezés mellett az implementáció során a hibák kisebb eséllyel jelennek meg, javításuk pedig könnyebbé válik.
A modellezés során össze kell gyűjtenünk a projekt legfontosabb jellemzőit:
-
milyen résztvevői lesznek a projektnek
-
mit kell megvalósítani a projekt során
-
milyen komponensei, alrendszerei lesznek a rendszernek
Az UML tehát használható:
-
objektumorientált modellezésére, tervezésre
-
adott probléma specifikációjára
-
adott probléma megoldására
-
dokumentációhoz
-
grafikus szemléltetéshez több nézetben
Az UML diagramok típusai:
-
struktúrális: a modell statikus architektúrájának definiálására alkalmasak, pl. class diagram, package diagram
-
viselkedés: a modell statikus elemeinek együttműködését, az egyes elemek viselkedését írhatjuk le pl. use case diagram, sequence diagram
A legfrisebb UML speficikáció itt érhető el: https://www.omg.org/spec/UML/
Tipp
Ha egy diagramon nem fér el az összes objektum „szépen”, akkor részekre bontva mutassuk be a rendszert.
Cél a teljes rendszer bemutatása
A példákban előfordulhatnak hiányos osztályok (pl. adattagok vagy metódusok nélkül) a gyorsabb megértés/áttekintés érdekében, azonban a II. mérföldkő esetén a teljes rendszer modellezése a cél, így minden lényeges metódust/adattagot/használati esetet/stb. fel kell tüntetni.
Class diagram¶
Az osztálydiagram a probléma megoldását leíró szerkezeti diagram. Elemei tipikusan: osztályok, interfészek, csomagok
Asszociáció¶
Az asszociáció jele az egyszerű vonal. Az asszociáció iránya is jelölhető két osztály között, ha nincs a vonalon nyílhegy, az kétirányú kapcsolatot jelent. A nyíl (vagy annak hiánya) azt jelenti, hogy a másik oldalon álló osztály ismeri, használhatja az osztályt. Azaz a Person osztály használhatja a House osztályt.
Aggregáció¶
Az aggregáció speciális asszociációnak tekinthető. Egyik objektum része a másiknak. Nem erős tartalmazás, rész-egész kapcsolatot jelent, a "rész" önállóan is létező entitás, pl. egy autó motorja és kerekei, ezek önállóan is léteznek (pl. megvásárolhatók). Az aggregáció jele a két osztály között húzott vonal, egy üres rombusszal a tartalmazó oldalán. Azaz a Room önállóan is pl. bérbeadható, de része a House objektumnak.
Kompozíció¶
Speciális aggregáció, fizikai, erős tartalmazást jelent. A rész soha nem jöhet létre a tartalmazó előtt, és biztosan megszűnik a tartalmazóval együtt, pl. képernyő ablak és a gördítő sáv viszonya. A kompozíció jele a két osztály között húzott vonal, egy teli rombusszal a tartalmazó oldalán. Azaz a Structure nélkül a House nem létezhet.
Öröklődés¶
Az öröklődés során az osztály megosztja a tulajdonságát több másik osztállyal. Megkülönböztetünk származtatott osztályokat és az ősosztályt. Az örökődés jele a két osztály között húzott vonal, egy üres háromszöggel az ősosztály oldalán. A tulajdonságokat elengendő a legfelsőbb szinten definiálni (Room), azokat a leszármazottak örökölni fogják (Kitchen, Bathroom, Living Room).
Sztereotípusok¶
Az UML az egyéni jelölések bevezetését is támogatja, hogy minden segítséget megadjon a szoftverfejlesztőknek ahhoz, hogy könnyedén modellezhessék az egyéni/különleges rendszereket is. Ezt az egyéni jelöléstant sztereotípusoknak fogjuk nevezni, amit << és >> jelöléssel fogunk ellátni. Tipikus sztereotípusok a következők:
-
Boundary, azaz határ osztályok:
-
rendszer környezete és belseje közötti kommunikációt valósítják meg
-
interfészt képeznek a felhasználó vagy más rendszer/szereplő felé
-
felhasználói interfész is ide tartozik
-
-
Control, azaz vezérlő osztályok:
-
használati eset(ek) szekvenciális viselkedését valósítják meg „használati eset végrehajtását” végzi
-
általában egy szereplő/használati eset párhoz hozzátartozik egy vezérlő osztály
-
-
Entity, azaz entitás osztályok:
-
olyan információt/viselkedést modellez, amely általában hosszú életű
-
valós világ entitásai, kevésbé érzékenyek a környezetük változásaira
-
általában alkalmazás-függetlenek
-
Nagy rendszereknél elkerülhetetlen az osztályok csoportosítása, ehhez érdemes csomagjelölést használni. Ez hierarchikus szerkezetet biztosít és magasabb szintű absztrakciót valósít meg. Ahogyan azt a bevezetés is említi, az UML diagramoknak figyelembe kell venniük a rendszer komponenseit, rétegeit. Jelenleg talán az MVC modell még kevésbé ismert - hiszen a következő gyakorlaton kerül bemutatásra - viszont érdemes ilyen szempontból is áttekinteni az osztálydiagramokat (a lenti diagram jelenleg hiányos, hiszen nem tartalmazza sem az attribútumokat, se a metódusokat):
Package diagram¶
A csomag diagram lényegében az alkalmazás összes csomagját és a köztük fenálló függőseket ábrázolja. A függőség jelölése szaggatott vonallal történik, a nyíl a függőség irányába mutat, pl. az Ordering csomag függ a DatabaseControl csomagtól.
Use Case diagram¶
A használati eset diagram a rendszer viselkedését modellezi funkcionalitás szempontjából. A legmagasabb absztrakciót valósítja. A rendszert a felhasználó, megrendelő szemszögéből modellezi. Összességében megvilágítja a rendszer tervezett funkcióit, a rendszer környezetét és ezek kapcsolatait.
A használati eset további követelménye, hogy a megrendelő által érthető legyen. Adjuk meg pontosan a használati esetet elindító eseményt. Az eseményáramlást külső szemszögből mutatjuk be, nem taglaljuk a rendszer belső működését. Adjuk meg hogy mi alapján ellenőrizhető hogy a használati eset elérte célját.
A következő kapcsolatokat jelöljük:
-
asszociáció: felhasználó és használati eset közötti kommunikáció, általában ige, folytonos vonallal jelöljük
-
általánosítás: egyik használati eset vagy aktor általánosabb formája a másiknak, jelölése: folytonos vonal, egy üres háromszöggel az ős oldalán
-
kiterjesztés: egyik használati eset kiterjeszti újabb funkcionalitással a másikat, az extend kulcsszót használjuk, jelölése: szaggatott vonallal a kiterjesztett használati eset irányába mutató nyíllal
-
tartalmazás: egyik használati eset tartalmazza a másikat, az include kulcsszót használjuk, jelölése: szaggatott vonallal a tartalmazó használati eset irányba mutató nyíllal
Figyeljünk arra, hogy a webalkalmazásunk összes funkcionális követelményét ábrázoljuk!
Sequence diagram¶
A szekvencia diagram objektum kölcsönhatásokat mutat be az idő függvényében. A szenárióban szereplő objektumokat és osztályokat ábrázolja a közöttük küldött üzenetekkel.
Idő-orientált nézet, az üzenetek a szenárió funkcionalitását valósítják meg. A használati esetekkel szoros kapcsolatban állnak.
A diagram elemei:
-
objektumok, amelyektől egy szaggatott vonallal jelzett életvonal indul, amely felülről lefelé az idő múlását jelképezi
-
üzenetváltások, amelyeket az egyes objektumok között, a küldő életvonalától a fogadóéig rajzolt nyíllal jelöljük
Használjunk az osztálydiagramban is feltüntetett metódusokhoz hasonló/megegyező elnevezést a kölcsönhatások ábrázolásához!
Entity Relationship Diagram¶
Az egyed-kapcsolat diagram nem tartozik az UML diagramok közé, viszont az adatbázistervezésben kulcsfontossági szerepet játszik. Az egyed-kapcsolat diagram a tárolandó adatok és kapcsolataik grafikus ábrázolására szolgál. Az egyed-kapcsolat diagram háromféle összetevőt tartalmaz:
-
egyedek: természetben megtalálható elemek vagy elvont fogalmak, amelyek attribútumait szeretnénk tárolni, jelölése: téglalap
-
attribútumok: az egyedeket az attribútumaikkal írjuk le, jelölése: elipiszis, ha primary key attribútumot aláhúzással jelöljük
-
kapcsolatok:
-
egy az egyhez kapcsolat (1:1), jelölése: a két egyed összekötésével ábrázoljuk egyszerű vonallal
-
egy a többhöz kapcsolat (1:N), jelölése: a két egyed összekötésével ábrázoljuk, egyszerű vonal N jelzéssel
-
több a többhöz kapcsolat (N:M), jelölése: a két egyed összekötésével ábrázoljuk, egyszerű vonal N és M jelzéssel
-
Egyed-kapcsolat diagram kapcsolatainak leképezése relációs adatbázissémákká: a kapcsolatot leképezzük egy külön relációsémába oly módon, hogy a kapcsolat neve lesz a relációséma neve, a relációséma attribútumait pedig a kapcsolódó egyedek kulcsai és a kapcsolati attribútumok alkotják. Ezután meghatározzuk a leképezett relációséma kulcsát, és ha az megegyezik valamely egyed kulcsával, akkor a kapcsolatból leképezett relációsémát beolvasztjuk az egyedből leképezett relációsémába.
-
1:1 kapcsolat esetén: tetszőlegesen választhatunk, hogy melyik egyedhez ágyazzuk be
-
1:N kapcsolat esetén: általában az N-oldai egyedből leképezett relációsémával vonható össze
-
N:M kapcsolat esetén nem vonható össze egyik egyedből leképezett relációsémával sem
Ajánlott eszközök¶
Az ezen az oldalon megjelenített UML diagramok a draw.io rajzolóprogram segítségével készültek. Ennek a nagy előnye, hogy böngészőben is használható és a felhasználható objektumok széles választéka áll rendelkezésünkre. Az UML diagramok rajzolását nem kell a nulláról elkezdeni, az oldalon szereplő .png kiterjesztésű képek közvetlenül importálhatóak a draw.io-ba.
UML diagram létrehozásához alkalmas eszközök:
-
Draw.io: https://draw.io/
-
StarUML: https://staruml.io/
-
és még számtalan további: https://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools