Tervezés¶
Bármilyen módszertannal is dolgozunk, a szoftverfejlesztés nem képzelhető el tervezés nélkül. A klasszikus fejlesztési módszertanok alkalmazásával a tervezés a specifikációt és az analízist követő lépés, az SRS (Software Requirements Specification) dokumentum alapján készül, jellemzően külön tervdokumentumban. A tervezésben számos szemléletet alkalmazhatunk (strukturált, adatvezérelt, folyamatvezérelt, stb.), amelyek a fejlesztendő rendszer függvényében választanak ki, de egy rendszer fejlesztése során párhuzamosan is alkalmazhatók. Az agilis módszertanok esetében a kiindulási alap a user storyk, amelyeket szükség esetén önállóan kidolgozható feladatokra, taskokra kell bontani. Ahhoz, hogy ez sikeres legyen, a user story-t meg kell érteni, azonosítani kell, hogy a felhasználó és a rendszer kapcsolata miképpen megy végbe, milyen funkcionalitásra van szükség a rendszerben, hogy a user storyban megfogalmazott követelményeknek megfeleljünk. Az azonosított (funkcionális) elemek képezik a taskokra bontás alapját, egy-egy task konkrétan egy-egy funkcionalitást, vagy részfunkcionalitást valósít meg, amennyiben az adott funkcionalitás komplex (pl. egy üzleti tranzakció). Míg a user story speciálisan az adott szakterület stakeholederei (érintettjei) által pontosan megfogalmazott elvárások, a taskokra bontást már a fejlesztői csapat végzi. A taskokra bontásban, a taskokban definiált funkcionalitás tervezésében számos segédeszköz áll rendelkezésre, amelyek közül napjainkban az UML a legelterjedtebb.
Az UML (Unified Modeling Language) szabványos, általános célú modellező nyelv, üzleti elemzők, rendszertervezők, szoftvermérnökök számára. A nyelv szabványosított, amelynek szervezése az OMG (Object Management Group) feladata. A nyelv aktuális verziója 2.5.1 Az UML diagramok nagy része korábbi modellezési módszertanokból átvett elem, illetőleg azok továbbfejlesztése. Maga az UML nem módszertan, hanem modellező eszköz, amely a szoftverfejlesztés különböző fázisaiban nyújt támogatást hatékony és jól interpretálható modellek készítéséhez.
UML felépítése¶
Az előadáson részletesen szó lesz róla, emlékeztetül az alábbi ábra: 
.
Itt az M0 szint az M1 osztályainak objektumait jelenti, legtöbb esetben ez a felhasználói modellünk konkrét objektumaira utal. Az M1 a problémaleíráshoz használt modellező szint, azaz itt definiáljuk az általunk vizsgált probléma leírását, itt tervezzük meg az elkészítendő alkalmazás osztályait, interakcióit, stb. Az M2 szinten találhatók azok a metaosztályok, amelyek példányait használjuk az M1-beli modelljeink felépítése során, azaz itt vannak definiálva az egyes UML diagramok és azok elemei. Az M3 szinten, a meta-meta modell szinten pedig azokat a definíciókat találjuk, amelyekből az UML (vagy más modellező nyelv) elemei felépíthetők. Mindezt azért érdemes tudni, mert az UML bővíthető, a bővítést pedig az M2 szinten és attól felfele végezhetjük el. Persze erre a gyakorlatban ritkán kerül sor, a meglévő diagramtípusok kellő támpontot adnak a legtöbb probléma modellezésére.
Modellező eszközök¶
Az elérhető modellező eszközök között számos terméket lehet találni az egyszerű UML rajzoló eszközöktől kezdve egészen a kódgenerálást támogató komplex modellező eszközökig. Ezekről egy listát találhatunk ezen a linken A komplexebb támogatást nyújtó eszközök azonban mind fizetősek. Egy-egy cég kínál community-edition változatot is, amelyek jól használhatók, de ezek jellemzően csökkentett funkcionalitású termékek, illetőleg nem használhatók kereskedelmi célú fejlesztésekhez. A tanuláshoz például a Visual Paradigm Community Edition is használható, de ebben reverse engineering funkció, illetőleg kód generálás nem elérhető. Azok kipróbálására érdemes a korlátozott ideig, kipróbálásra szánt verziókat is megnézni. A CE esetében egy gyors regisztráció után már használható is az eszköz.
Diagram típusok¶
A gyakorlatban az UML használata a különböző UML diagramokon keresztül történik. Mikor egy komplex problémát modellezünk, akkor azt különböző nézőpontokon keresztül tehetjük meg. Az egyes diagramtípusok pontosan ezeknek a nézőpontoknak a kifejezésére szolgálnak. Az UML esetében két csoportra oszthatjuk a diagramokat:
- szerkezeti diagramok
- viselkedési diagramok
Osztálydiagram¶
Szerkezeti diagram, amely osztályok (OOP) és azok közötti relációk ábrázolására szolgál. Az alábbi példa egy tipikus osztálydiagramot ábrázol:
.
A diagramban egy-egy box jelképez egy osztályt. Az osztály neve a box felső szakaszán látható. *Dőlt betűs szedéssel *az absztrakt osztályokat ábrázolják, azaz olyan osztályokat, amelyek nem példányosíthatók. A <<>> jelek szteretípiákat jelölnek, ezek valamilyen speciális, az osztályok között kitüntetett szereppel rendelkezők, ilyen a példában az Enum, ami a felsorolás típust jelenti.
Az osztálydiagramokon feltüntetik az adattagokat és a metódusokat is, egymástól vonallal elválasztva. Az adattagok esetében azok típusát, inicializált értékeit is fel lehet tüntetni, de ez nem mindig szokás. Hasonlóan a metódusok paraméterei és visszatérési értékük opcionálisan feltüntethető. Mind az adattagok, mind a metódusok esetén azok láthatósága is meg van jelölve. A + jelenti a publikus, a - a privát és a # a védett (protected) adattagokat, metódusokat.
A relációs kapcsolatok lehetnek az öröklés, vagy inkább specializáció, általánosítás, amelyet egy vastag végű nyíl jelképez. A nyíl az általánosabb osztály felé mutat: 
.
Az asszociációs kapcsolatok többfélék lehetnek. A legegyszerűbb esetben egy folytonos vonallal kötjük össze a két osztályt 
.
Amennyiben a kapcsolatnak értelmezhető iránya is van, ez lehet egy nyíl is. Az asszociciónak általában van neve, számossága és lehet iránya, szerepe. Ezek mind feltüntetésre kerülnek. A példánkban az Order és Payment között irányított kapcsolat van, tetszőleges rendeléshez legalább egy fizetés kapcsolódik (1..*). Olyan is lehetséges, mikor két osztályt egy harmadik kapcsol össze közös tulajdonság alapján
.
Rész-egész viszonyt kétféleképpen fejezhetünk ki:
- aggregációval
- kompozícióval
A kettő közötti különbség az, hogy kompozíció esetén a tartalmazott osztály objektuma nem létezhet a tartalmazó nélkül. Azaz a tartalmazó objektum törlésével a tartalmazott objektum is törlődik. Az aggregáció esetén az osztályok példányai egymástól függetlenül létezhetnek. A példánkon az Order és OrderDetail között aggregációs viszony van, a tartalmazó osztály az Order. Azonban ezen osztályok objektumai egymástól függetlenül is létezhetnek, a rendelés megszűnésével a tételei nem szűnnek meg automatikusan. A rész egész viszony esetében is értelmezhető mindaz, amit az asszociációra mondtunk, tehát leneve neve, szerepkörök adhatók meg, illetőleg a számosság is jelölhető.
Objektumdiagram¶
Strukturális M0 diagram, konkrét objetumok leírására szolgál. Hasonló felépítésű mint az osztálydiagram, de itt nem osztályról, hanem azok példányairól beszélünk. Ritkán használják őket, leginkább demonstrációs célra, vagy teszteléskor. Egy plda az objektum diagramra: 
Csomagdiagram¶
Akárcsak a programozási nyelvekben (C++ namespace, illetőleg Java package) az összetartozó osztályokat egy névtérbe, illetőleg csomagba szervezhetjük, az UML is lehetőséget ad nagyobb egységek, modulok modellezésére. Ezt a csomagdiagram segítségével tudjuk modellezni, amely szerkezeti diagram, az osztályoknál nagyobb egységek és azok kapcsolatainak, illetőleg függőségeinek ábrázolására.
Kompozit szerkezet diagram¶
UML 2-ben definiált szekezeti diagramtípus, amely osztályokat, interfészeket, csomagokat és kapcsolataikat tartalmazza. A digram a teljes rendszerről és annak részeiről együtt ad egy interpretációt.
Komponens diagram¶
Olyan szerkezeti diagram, amely a szoftver által nyújtott szolgáltatásokra, mint komponensek és a köztük lévő kapcsolatok ábrázolására helyezi a hangsúlyt. A komponensek ábrázolására speciális sztereotípival jelölt dobozokat használunk. A komponensek nyújthatnak szolgáltatást és igénybe vehetik más komponensek által nyújtott szolgáltatásokat. A nyújtott szolgáltatásokat kis körök, míg a szolgáltatás igényeket egy kisebb tányér jelképezi.
.
A szolgáltatások csatlakozópontjait (portokat) is jelölhetik, ezek kisebb téglalapok a komponens határán.
Telepítési diagram¶
A szoftverelemek telepítését ábrázoló szerkezeti diagram. A telepítés eszközei lehetnek hardver eszközök és szoftver elemek is, ez utóbbi például egy docker konténer is lehet. Hardver elemre példa lehet a munkaállomás vagy a szerver.
Használati eset diagram¶
Az üzleti elemzésben használt diagram, amely a modellezni kívánt jelenség viselkedését felhasználói oldalról megközelítve modellezi. Fontos, hogy az üzleti esetek leírása során az üzleti nyelvet és ne az informatika nyelvét használjuk. Ez a diagram a kommunikációs elem az ügyfelek és a fejlesztők között. Két főbb eleme van, az un. aktorok és a használati esetek.
A használati esetek grafikus ábrázolásán túl szokás azok lefolyását is megadni, mégpedig az egyes döntési pontokon alternatív lefutásokkal együtt. Ezeket szövegesen, akár user story módján is meg lehet adni. Meg kell adni a használati esetek elő és utófeltételeit is. A fizetős UML eszközök mindezeket strukturált módon rendelkezésre bocsátják. Az egyes elemekhez követelmányek, megszorítások is rendelhetők, így a használati eset diagram, amennyiben jól van elkészítve és hiánytalanul tartalmazza a lehetséges lefutásokat is, alkalmas a rendszertervezésre és közvetlenül tesztesetek generálására is. A használati esetek között két tipikus kapcsolat definiálható:
- Bennfoglalás (include): ebben az esetben A használati eset tartalmazza B használati esetet, a példán a Take Examination magába foglalja a Login Accountot, azaz lefutása esetén a Login is lefut.
- Kiterjesztés (extend): ekkor a kiterjesztett elem nem fut le kötelezően, de opcionálisan igen, a példában ilyen a Set Java Questions kiterjesztése a Prepare Question Bank használati esettel.
Az aktorok között ábrázolható adott esetben specializáció és általánosítás is.
Szekvencia diagram¶
Olyan viselkedésdiagram, amely az egyes komponensek közötti üzenetváltásokat modellezi időbeli sorrendjüket megtartva.
A komponensek lehetnek szoftverelemek és aktorok is. Az egyes objektumokhoz tartozik egy idővonal, amely az adott objektum (aktor, komponens) a kommunikáció során lévő aktív állapotát mutatja. Ez egy függőleges szaggatott vonal az objektumból kiindulva, az aktív állapot pedig telt téglalappal van jelölve. A kommunikációt időben és objektumtól objektumig nyíllal jelöljük és sorszámot is adunk nekik. A szolgáltatáskérés folytonos, míg a válasz üzenet szaggatott nyíllal jelölt. Az üzenetváltás megnevezése általában egy metódushívás lesz, tehát elemi művelet.
Kommunikációs diagram¶
A kommunikációs diagram, a szekvencia diagramhoz hasonlóan, objektumok közötti üzenetváltásokat képes ábrázolni, azonban ebben az esetben nem az üzenetváltások időbeliségére helyezzük a hangsúlyt, hanem az üzenetváltásokban részvevő objektumok közötti kapcsolatokra.
Az ábrán lévő kommunikáció diagramon speciális UML jelöléseket is látunk, amely az MVC (Model View Controller) nézethez kapcsolódik. 
Állapotgép diagram¶
Az állapotgép diagram az automataelméletből ismert Mealy és Moore gépek általánosítása. A rendszerünk viselkedését állapotátmenetekkel modellezi. Az állapotokat boxok, míg az átmeneteket nyilak jelölik. Az állapotátmenet feltételei a nyilakra írható. Két speciális állapot mellett (kezdő és végállapot) jelölhetnek csapdaállapotokat, illetőleg az átmenet megszakadását is. A diagramot kiegészíthetik még elágazásokkal.
~~~~
Az állapotokat jelképez boxokba az adott állapotban végrehajtható tevékenységeket is fel szokták sorolni. (Szekvenciális gépek modellezése esetén).
Aktivitás diagram¶
A folyamatábrák UML-beli megfelelje. A modellezni kívánt elemet procedurális elemekkel írja le. A diagram párhuzamos folyamatok ábrázolására is alkalmas, az ábrán ezt a fekete téglalap jelzi. Ezek az elemek mind folyamatok szétválasztására és összefésülésére is használhatók. Ábrázolhatók az aktorok és az általuk végrehajtott folyamatrészek is.
Időzítési diagram¶
Az egyes események időbeli lefutásának ábrázolására használt viselkedés diagram.
Üzleti folyamat diagram (BPMN)¶
Az üzleti folyamatok folyamatszemléletű modellezéséhez széles körben használt diagram, nem része az UML-nek, viszont hasonlít hozzá. A modell aktivitásokat, átjárókat, kapcsolatokat és eseményeket ábrázol.
A modellt gyakran használják a rendszerszervezők, a use case diagramokkal együtt igen elterjedt az üzleti modellezésben.
Rendszer modellezés (SysML)¶
A mérnöki rendszerek modellezésére használt diagram. Nem része az UML-nek, de használja annak diagramjait és annál flexibilisebb leírást biztosít az ipari rendszerek modellezéséhez. 9 diagramtípust tartalmaz
:
- Blokk definíciós diagram
- Belső blokkdiagram
- Csomagdiagram
- Használati eset diagram
- Követelmény diagram
- Aktivitás diagram
- Szekvencia diagram
- Állapotgép diagram
- Paraméter diagram
Demonstráció¶
Az órához kapcsolódó projekt demonstrációs feladat itt érhető el.
Feladat¶
- Válasszunk ki egy tetszőleges, már működő funkcionalitást a projekt tárgyát képező szoftverben és tekintsük át annak működését!
- Modellezzük a működést egy alkalmas UML diagram segítségével!
- Modellezzük a kiválasztott elem szerkezetét egy alkalmas UML diagram segítségével!
- Vegyünk egy megvalósításra javasolt issue-t, készítsük el a kapcsolódó user story-t, modellezzük use case diagrammal, majd ennek alapján készítsük el a taskokra bontást!