UML

Unified Modelling Language

Az elemzés, megvalósítás és tesztelés fázisában használatos dokumentációs eszköz

Diagramok változatai - Összefoglaló

Szerkezeti nézet

Viselkedési nézet

Használati eset

Használati eset - Tartalma

• Funkciók, szolgáltatások
• A szolgáltatás hatóköre (kiknek)
• Követelmények a környezet felé
• Tartalmazási, rákövetkezési kapcsolat, ami az egyes funkciók között fenn kell álljon

Precedes - Rákövetkezési kapcsolat, nem végrehajtható enélkül a rákövetkező szolgáltatás

Extend - Szükséges kiterjesztése a funkcióknak

Elemei

Használati esetek

Tevékenységek (Funkciók, szolgáltatások), melyek a kívülről azonosíthatóak és kezdeményezhetőek (publikusak)

Részei

• Include
  • A használati eset egy jól elkülöníthető, önállóan is kezdeményezhető részére mutat
    • A hivatkozott rész nélkül a tartalmazó tevékenység nem lenne teljes (hanem absztrakt)
• Extend
  • Egy önmagában is teljes (tehát nem absztrakt) használati eset opcionális kiegészítő esetre mutat

Rákövetkezési sorrendje

• Precedes
  • Aktor által közvetlenül kezdeményezhető tevékenységek közötti sorrendet jelöli ki
  • Precedencia
• Invokes
  • A tevékenységet feltétlen követő másik tevékenység (az aktor akaratától függetlenül)
    • Szükséges, nem elkerülhető

Esetek közötti származtatás

Amikor egy általánosan megfogalmazott használati esetnek több eltérő konkrét változata is beazonosítható.

Kapcsolatok

Használati esetek közötti kapcsolatok, melyek rámutatnak az esetek alábbi elemeire:

• Az esetek részekre bontása
  • Plusz funkciókkal történő kiegészítés
• Az esetek sorrendje
• Általános használati esetből származás

Aktorok

Külső szereplők, vagy az rendszer vezérlői. Itt kategorizálhatóak az aktorok, illetve azok multiplicitása.

Aktor multiplicitása - Meghatározza, hogy egyfajta aktorból hány darab lehet

Felhasználói történet - user story

A használati eset önmagában elégséges információ a megvalósítandó rendszerről, hiszen a nevezésen túl nem mond sokat

A felhasználói esetek csoportonként ("As a...") történő táblázatos leírásban részletesen ki lehet fejteni a felhasználói tevékenységeket:

• Tevékenység neve
• Előfeltételek megléte
  • GIVEN
• Milyen események hatására következik be
  • WHEN
• Hatása, eredménye
  • THEN

Minta

Példa - Sokszögek

Objektum diagram

A populáció leírására szolgál

Populáció - Az adott pillanatban létező objektumok

Objektum diagram - Tartalma

• Az osztálya
  • Objektumok ugyanolyan adattagokkal és metódusokkal
• Neve (opcionális)
• Állapota
  • Az adattagok értékei határozzák meg

Pro tipp, a felső sor tartalmát szokás aláhúzni

A metódusok ebben nincsenek feltüntetve

Objektum diagram - Példa

b : Bag

Vec = [0, 0, 0, 5, 2, ...]

max = 4

[] - rögzített elemszám

<> - Változó elemszám

Objektumok kapcsolatai

Objektum kapcsolatok - Tartalma

Céljai

• Objektum hivatkozhat másik objektumra
  • Például arra, aminek részét képezi
• Objektum üzenhet más objektumnak
  • Szignált
  • Metódus hívás

Egy kapcsolatban az egyik objektumnak ismernie kell a másik objektum hivatkozását

Tárolhatja adattagjában, megkaphatja paraméterként, akár példányosíthatja is.

Kapcsolatok formái

A kapcsolatot egy folytonos vonal jellemzi, annak milyenségét lehet alakítani

• Nyíl
  • Hivatkozás
• Rombusz
  • Tartalmazás

Metódusok

Objektumok felelősségi köre

Egy objektum metódusai az objektum adattagjain végeznek olyan műveleteket, amelyek a feladat megoldásának egy részéért felelősek.

A metódus objektumhoz rendelésével kijelöljük az objektumnak a feladat megoldásában játszó felelősségi körét

Fontos emlékezni az "Egy felelősségi kör" elvére

lásd. SOLID

Kommunikációs diagram

Kommunikációs diagram - Tartalma

Az egymással kapcsolatba kerülő objektumok közötti üzenetváltások (Metódus hívások, signals)

Hasonlít az objektum diagramhoz, de nem tünteti fel az oöbjektumok adattagjait, cserébe mutatja az üzenetek irányát és tartalmát.

Üzenetküldés módja

• Szinkron
  • A küldő objektum megvárja, amíg a fogadó feldolgozza az üzenetet, és ennek esetleges eredményét megkapva folytatja tevékenységét
  • Jelölése: ―\(\blacktriangleright\)
• Aszinkron
  • Az üzenet küldése után a küldő és a fogadó objektumok tevékenységei párhuzamosan folynak
  • Jelölése: \(\rightarrow\)

Egyéb jelölések

• Sorszámozható
• []-ben megadhatóak az előfeltételek
• Jelölhető, ha az üzenet ciklikusan ismétlődik

Osztály diagram

A tervezett rendszer működése során létrejövő populációk általános leírására szolgál

Fontos, hogy egy osztály diagramnak több objektum diagrammot is meg lehet feleltetni (mondhatjuk úgy is, hogy az objektum diagrammok absztrakciója).

• Egy osztály azonos típusú adattagjait és metódusait írja le
• Szoftver tervezését támogatja, de alkalmas az elemzésnél, vagy a megvalósítás leírására

Osztály diagram - Tartalma

• Osztálynév
• Adattagok
  • Tulajdonság, attribútum, mező
  • Névvel, típussal, egyéb jellemzőkkel
• Metódusok
  • Művelet, tagfügyvény
  • Szignatúrájával, egyéb jellemzőkkel

Láthatóságok

• Privát -
  • Külsőleg nem elérhető
    • Leszármazottaknak sem (erről később)
• Publikus +
  • Kívülről elérhető
    • Csak annyi legyen publikus, amennyit feltétlen szükséges (SOLID)
• Védett #
  • A leszármazottak láthatják csak

Példa osztály diagram

A felhasználói típusokat osztályok formájában adjuk meg OEP tervezéskor

Az osztály diagrammok a modelelzés során folyamatosan bővülnek, alakulnak

Tervezéskor hiányozhat belőle

• Attribútumok, metódusok
• Elemzéskor hiányozhat a típus és a láthatóság
• A kapcsolatok fokozatosan kerülnek megjelenítésre

Kiegészítés

• Jellegzetességeket <<...>> jelzéssel megadhatóak
  • pl <<interface>>,<<enumeration>>,<<singleton>>
• Általánosítva is felírható
  • generikus-, sablon-osztály
  • Paramétereket veszünk fel ilyenkor a típus helyett
• Az adatagokhoz plusz információ
  • = kezdőérték, amit majd a konstruktor állít be
  • {...} megszorítások (típus invariáns)
• Metódus extrák
  • Kiegészítő infó (pl. query, override, virtual) {...} jelzéssel
  • Metódus csoportok
    • <<getter>> - Adattagok értékét lekérdező metódusok
    • <<setter>> - Adattagok értékét felülíró metódusok

Szekvencia diagram

Szekvencia diagram - Tartalma

• Üzenetváltások időrendi sorrendjére
• A rendszer, vagy egy részének lehetséges működésére
  • Várhatóan több készül belőle
• Elemzés és teszteléskor használatos

Szekvencia diagram - elemei

• Osztályszerep
  • Jellemzően csak egy objektum, de leket akár több osztály is
• Osztályszerep életvonala
  • A "függőleges szaggatott vonal"
  • Egy osztályszerep létezésére
• Osztályszerep aktivációs életvonala
  • A "hosszú, elnyújtott téglalap"
  • Azon időszak, amelyben az osztályszerepet betöltő objektum épp metódust hajt végre (vezérlés alatt áll)
• Üzenet
  • A "Vízszintes nyilak"
  • Objektumok közti információ átadás
    • Egymás alatt az időrendi sorrendet mutatja
    • Feltüntethető a két üzenet közt eltelt idő is

Szinkron üzenetek

Amikor a küldő objektum átadja a vezérlést a fogadó objektumnak, és a saját tevékenységét mindaddig blockolja, amíg a fogadó objektum ezt fel nem oldja.

Előfordulása

• Metódus hívása
  • Az üzenet címkéje a metódus neve és paraméterei
• Szinkronizációs üzenet
  • A küldő objektum vár a választa
• Időhöz kötött várakozó üzenet
  • A küldő objektum megjelölt ideig vár visszajelzést

Példa üzenetküldések

Aszinkron üzenetek

Amikor a küldő szerep az üzenet elküldése után nem szakítja meg a saját tevékenységét, nem feltétlenül vár a visszajelzésre.

Előfordulása

• Aszinkron szignál (akár paraméterekkel is), vagy metódus hívás
  • A futtatás külön szálon történik
• Randevú üzenet
  • A küldő megjelölt ideig vár arra, hogy a fogadó objektum fogadja az üzenetet

Speciális üzenetek

Jellemzően nem szükséges megjelölni őket, minden esetre \(\exist\)-IK

• Visszatérési üzenet
  • Ha szinkron üzenetre válasz, ez oldja fel a blokkolást
• Példányosító (create) üzenet

Szekvencia diagram hierarchiája

A diagram egyes részei elrejthetőek az olvashatóság érdekében

• Egy osztályszerep elfedheti a szerepet alkotó objektumok közti üzenetváltásokat
• Kiemelhető a diagram szűkebb időintervalluma is (ref)
• Kijelölhetünk fragmenteket, amelyek
  • Ciklikusan ismétlődnek (loop)
  • Csak adott feltétel esetén történik (alt,opt)
  • Párhuzamosan futnak (par)

Állapotgép

Egy objektum állapotváltozásainak nyomon követésére szolgál

Állapotgép - Tartalma

• Fizikai állapot
  • Az objektum adatai által felvett értékek együttese
• Logikai állapot
  • Közös tulajdonságú fizikai állapotok halmaza
• Aktív állapot
  • Ebből mindíg csak egy lehet
• Állapot-átmenet
  • Két aktív átmenet között

Jelölés irányított gráffal

• Csúcsok az objektum állapotai
• Az irányított élek az átmenetek
  • Ha metódus hívás hatására keletkezik, akkor annak neve feltüntethető

Állapotgép - Példa

Kotlin UML Összefoglalója Fontosság szerint

No. 1. Osztály diagram

• Itt mutatod be az osztályt, interfészt
  • Nevével
  • Absztrakciójával
• Megadod adattagjait
  • Típussal
  • Típus invariánssal
  • Lehetséges kezdőértékkel
• Itt vezeted be a metódusokat
  • Szignatúrával
  • Láthatósággal
  • Virtualitással és egyéb kiegészítő infóval
• Könnyen szerkeszthető, benne van a lényeg

Garantált UML élmény, 10/10

No. 2. Állapotgép

• Az állapotok közti ugrások megjelenítésére
• Életciklus könnyen reprezentálható
• A metódusok hatásai szemléltethetőek

Can be done cool, Android :3, 8/10

No. 3. Kommunikációs diagram

• Jelzések megadása irányukkal
• Szinkronizáció és precedencia opcionálisan

Asszinkronnál még hasznos lehet, can be a mess tho, 6/10

Objektum Diagram

• Opcionálisan az objektum nevével
• Osztály diagram mintájára
• Egy példány (kizárólag) adattagjainak állásával

Béna osztály diagram, uncsi, 5/10

Használati eset - User Story

• A metódusok főbb infói
  • Előfeltételei
  • Előfurdulás
  • Hatása
• Bőven dokumentálható leírás szegmenssel
  • Esetleg feleslegesen sok sallang

Ha kell az oldal, ok, feleslegesen Óriási táblázat, 3/10

Szekvencia

• Idővonal a kommunikáció kronológiájának bemutatására
• Ciklusok, aszinkron vezérlések láthatóak

It's a mess, and ugly as my ass, 1/10