Programming | UML » Az UML története

Az UML története 1. Az 1990-es évek közepe - vezető módszertanok: • • • • • • • • • • Booch93 (Booch): erős a tervezés fázisában, népszerű az engineering-intenzív alkalmazásoknál. OMT2 (Rumbaugh) : erős az analízis fázis során, népszerű az adat-intenzív alkalmazásoknál. OOSE (Jacobson) : kiváló támogatást ad a "business engineering"-hez, és igazan csak ez támogatja a követelmény analízist. 1991-ben Grady Booch és Jim Rumbaugh (Rational Software Corporation) 1995 október: UML 0.8 1995-ben Ivar Jacobson is 1996. október: UML 091 1997. január 17: UML 10 (OMG-nek!) 1997. szeptember: UML 11 (szabvány!) az utolsó (szabványos) verzió az UML 1.3 (1999 novemberben elfogadva) Csertán Tanár Úr szerint: • • • Az 1995-95-ban nagy szakmai visszhangot váltott ki a létrehozására tett javaslatok 1996-ben áll össze a 3 "nagy" , és elkezdték az UML fejlesztését 1999-ben jelent meg az 1.0, amit az OMG

(Object Management Group) szabványosított (A szabványosításhoz az összes „nagy” csatlakozott) UML: Unified Modeling Language – egyesített modellező nyelv. (jelrendszer) Def.: • Egy nyelv szoftver rendszerek, üzleti rendszerek, és más nem szoftver rendszerek elemeinek specifikálásához, vizualizálásához, létrehozásához, és dokumentálásához. • Grafikus modellezési nyelv O.O fejlesztéshez Motíváció az UML létrehozásához: • Az objektum orientált (o.o), és más rendszerek modellezésének szüksége • Áttekinthetőséghez. • A komplettség ellenőrzéséhez • A kommunikációhoz. • Automatikus szoftverkészítéshez – programozás fejlődési iránya: gépi kódú, assembly, magas szintű programozási nyelvek, UML, ahol a modellből generál szoftvert a „fordító” (már létezik is!), • Szabványosítás – mindenki mást használ, jelen esetben minden cég a saját fejlesztési folyamatát Az UML fő célkitűzései •

• • • • • A rendszer (nem csak a software!) modellezése objektum orientált szemléletben. A módszer kiterjeszthető, bővíthető legyen a komplex, kritikus rendszerekre is Ember és gép által egyaránt könnyen használható kifejező, grafikus modellező nyelv definiálása. Programozási nyelv és fejlesztési folyamat függetlenség O.O eszközök terjedésének segítése Formális alap legyen a nyelvhez Magas szintű fejlesztés módszerek támogatása Az UML nyelv elemei 1. • • • • • Statikus struktúra diagramok: – use case – használati eset – diagramm – class – osztály - diagramm Viselkedés diagramok: – Állapottérkép diagramm (state diagram) – Tevékenység diagramm (activity diagram) – Kölcsönhatás diagram (interaction) – Szekvencia diagram (sequence) – Együttműködési diagram (collaboration) Kölcsönhatás diagramok (interacton diagramm): – Sorrend diagram (sequence diagram) – Együttműködési diagram

(collaboration diagram) Implementációs diagramok: – Komponens diagram (component diagram) – Feladat-kiosztási diagram (deployment diagram) Kiterjesztési mechanizmusok – kiegészítő jelölések, amelyek több diagramtípus által is használhatók Az UML nem módszertan! Kiterjesztési mechanizmusok • Az UML kiegészítő jelölései. Feladatai: – a szabványos jelölésrendszer "testre szabása" – a szabványos elemekkel nem leírható modell tulajdonságok rögzítése • Fajtái: – sztereotípia (stereotype): új modell elemek jelölésére – megszorítás (constraint): az UML más jelöléseivel meg nem adható tulajdonságok – kulcsszavas értékek (tagged values): modell elemek speciális jellemzőinek megadására – megjegyzések Megjegyzések Formája: Kapcsolható egy elemhez: Sztereotípia Formája: « megnevezés » • A minősített név előtt vagy fölött kell megadni. • Ikon is rendelhető hozzá. • Az egyes

ábratípusoknál speciális sztereotípiák jelennek meg. Megszorítások Formája: {megszorítás leírása } • A leírás lehet szöveges vagy formális. • A formális leírásra egy ajánlat: OCL (Object Constraint Language, IBM) Megadható: • minősített elem után vagy alatt • kapcsolt megjegyzésben Kulcsszavas értékek Formálisan ez is megszorítás • Adott névhez értéket rendel • Érték önállóan is szerepelhet • A fejlesztéssel kapcsolatos információkat is így rögzíthetjük • Példák: { persistent } {author="Ravetzky", version=0.99, date=000101} Használati eset diagram • • Use Case (használati eset): – célja: a rendszer szolgáltatásainak definiálása (mire képes a rendszer) – a r.sz-el szemben támasztott követelmények rögzítése (mit várunk el) A rendszer határait jelölhetjük ki. – Rendszer: amit el szeretnénk készíteni – Környezet: az a világ, ami a rendszert körülveszi – A rendszer

képességei: az elvárt viselkedésminták Aktor Jele: Aktor A felhasználó egy szerepe a rendszerben. Aktorok azonosítása: - kik használják közvetlenül a rsz-t? - ki felel a rsz karbantartásáért? - a rsz által használt külső erőforrások - a rsz-el kapcsolatban lévő más rendszerek - “ főnevek kikeresése “ – nem UML módszer a specifikációból Use case Egy jól meghatározott funkció, amelynek végrehajtása a rendszer és egy külső entitás közötti üzenetváltást kíván. Jele: Áruvásárlás A rendszer, az alrendszer vagy egy osztály által végrehajtott funkció-együttes. Pontos leírása is szükséges (szöveges vagy egyéb diagram) Rögzíteni kell azt, hogy mire, milyen módon használjuk a rendszert, azt, hogy mit csinál a r.sz, mik a szolgáltatásai, mit kell tudnia. (Igék kikeresése a specifikációból – nem UML feladat) Példa Fizetés a kasszánál: A vevő a kasszához megy a kiválasztott árukkal, a pénztáros

leolvassa a vonalkódokat, a rendszer elkészíti a blokkot, a vevő fizet, a pénztáros elveszi az összeget. Aktorok: vevő, pénztáros A rendszer válaszai: egységár a vonalkódokra Use-case-ek: vásárlás, blokkolás, fizetés kapcsolatok (sztereotípiák: pl.: <<communicates>> - alapértelmezés, nem jelölt) Aktor és use case között: asszociáció (jelölhető a számossága is, két irányú) Use case-ek között: • <<include>>: Az egyik h.e magában foglaljaa másikat (részletezés, vagy ismétlődés kezelése) <<include>> Bejelentkezés Jelszó ellenőrzés Itt: a bejelentkezés használati eset tartalmazza a jelszó ellenőrzést. • <<extend>>: Az egyik használati eset működését kiegészíti egy másik (többlet funkciók vagy speciális esetek, például hibakezelés, kivételkezelés esetén) <<extend>> Lekérdezés Nem létező rekord jelzése Itt: a lekérdezéskor jelzi a rendszer, ha az

amit keresünk az nem létezik. Aktorok vagy use case-ek között: általánosítás (generalization) Adminisztrátor Dolgozó Takarító Osztálydiagramok Osztályok és összefüggéseik ábrázolására, a rendszer elemei közti statikus strukturális modell. Objektum: – Kézzel fogható dolog. – Lehet egy koncepció – Lehet absztrakt dolog – Jól definiált határai vannak – A rendszer számára értelmes jelentéssel bír – jellemzői: • Állapota (tulajdonságok halmaza, tulajdonságok konkrét értékei, kapcsolatok) • Viselkedése: válaszok külső kérésre • Identitás: egyértelmű azonosító Lényeges tulajdonsága, hogy a rendszer egy jól körülhatárolható és meghatározott működésű része a r.sznek Rendelhető hozzá feladat, felelősség, funkció Osztály: – absztrakt objektum – Valamely közös tulajdonsággal jellemezhető objektumok leírása. Lehetőleg egy tulajdonság alapján csoportosítunk, így megmarad az a

tulajdonság, hogy jól körülhatárolt része a rendszernek Osztályok felállítása Entitás osztályok – – – Vezérlő osztályok – – – Határosztályok – – Osztály-diagramm elemek Konkrét adat köré szervezzük őket Valós dolog: információ + műveletek A rendszer belső működéséhez szükségesek A r.sz működésének ütemezése Más osztályok koordinálása Szekvenciális működésűek A r.sz határán állnak A felhasználó és a r.sz közti felület pl: párbeszéd ablak Osztály szimbóluma Attribútumok Név Formája: láthatóság név : típus = alapérték A láthatóság jelölése: Attributumok + public Metódusok # protected - private Formája: láthatóság név(paraméter) : típus{comment} • típus a visszatérési érték típusa • param a paraméterlista (vesszővel elv.) Objektum: Egyeszerű: Láthatósági név (paraméterlista) : típus Window Class : Név Kompozit: (attributumok) Texture 1 1 f.mozg() 01

VscrollBar Társítá, Kapcsolatok A leggyakrabban használt típus. Jellemzői: – Név – Szerepek – Számosság – Típus: – Asszociáció – Agregáció – Kompozíció – Általánosítás Asszociáció Kapcsolat az egyes osztályok között (kvalifikáció) Jele vonal, tulajdonságai: • Kapcsolat neve (nem szükséges) név v.mozg() 01 HscrollBa • • • Szerepkör (mindkét irányban) Irányítása (egy-vagy kétirányú vagy nincs) A szerepkörök számossága – n.m vagy n-m vagy n,m, ,k – n,m stb lehet 0 vagy * (végtelen) – * magában a 0.* -ot jelenti. Általánosítás Szülő-gyerek kapcsolat megvalósítása • Típus - altípus viszony • Az alosztály interface-e rendelkezik az ősosztály interfac-ének minden elemével • Öröklődés (származtatás) Példa: Aggregáció (összetétel) és kompozíció Kétféle egész - rész viszony: • aggregáció: a rész az egészhez tartozik, de önállóan is létező entitás •

kompozíció: a rész önmagában nem létezhet, csak valaminek a részeként. Parametrizált osztály Paraméterek Parametrizált osztály A konkretizálás paraméterei Konkretizált osztály Társítás osztály Terminál Gép Két osztály, vagy objektum közötti kapcsolat. Gyártás Kapacitás Kölcsönhatásdiagramok (interaction diagrams) A kölcsönhatás diagramok objektumokból és a közöttük lezajló üzenetváltásokból épülnek föl, így leírható velük, hogyan valósulnak meg a használati esetek objektumcsoportok együttes tevékenységsorozatai nyomán. A kölcsönhatás diagramok két típusa a szekvencia diagram (sequence diagram), mely objektumok közötti üzenetváltások időbeli sorrendjének leírására szolgál, illetve az együttműködési diagram (collaboration diagram), mely az objektumok kölcsönhatásait egymáshoz való kapcsolataik alapján adja meg. Szekvencia diagram A rendszer dolgai (elemei, objektumai) időben hogyan

működnek együtt egy-egy használati eset megvalósításának érdekében. Egy tipikus lefutást ír le Elemei: Név: osztály • Példaobjektumok, életvonallal, aktivitási szakasszal (vezérlési fókusszal) • Üzenete és stimulus (név, argumentum, feltétel, ismétlődés) • Eljáráshívás, a hívó megvárja az eljárás befejezését: • Vezérlésátadás (párhuzamos futásra ad lehetőséget): • Üzenetküldés: • Visszatérés eljáráshívásból: • Megjegyzések az ábrától balra Objektumok Idő Üzenet fajták Példa Együttműködési diagram Azt mutatja be, hogy a rendszer dolgai (elemek, objektumok) hogyan működnek együtt. Nem időcentrikus A Hangsúly a lehetséges kapcsolatokon van Az egyes objektumokat társítások kapcsolják egymáshoz, és ezek mellett jelennek meg az üzeneteket jelképező nyilak, melyeken címkeként az üzenetek neve szerepel. Elemei: • Példaobjektumok – Aktív: vastag keret vagy {active} megszorítás -

üzenetet küldhet másik objektumnak – Passzív - üzenet hatására aktivizálódik – Üzenet hatására létrejött objektum esetén ezt a neve mellé írt {New} címkével jelezzük – Üzenet hatására létrejött objektumot a {destroyed} – Létrejött és megszűnt: {transient} – multiobjektum: objektumok 1 csomagja • Üzenetek (név argumentum) - objektumok közötti nyilak, sorszámozva Együttműködési diagram 2. példa Állapot diagram Egy osztály belső állapotainak egymástól és különböző üzenetektől való függését írja le. Állapotgráf jellegű leírás a viselkedés megadására. Egy adott objektum • lehetséges állapotai • átmenetek az egyes állapotok között (állapotváltozások) – ehhez kapcsolható események – az objektum értékeihez kapcsolható feltételek [feltétel] formában –az imétlődés jelzése (*) • kezdő és végállapot • egy állapot részletezhető (struktúrált áll. diagram) Állapot

jelölése: Belső átmenetek Kompozit állapotok: - Soros - Párhuzamos - Szinkronizált - A B Tevékenység diagram - Több objektum közös viselkedésével valósul meg egy viselkedés. - Egy objektum egy módszerének leírása - Az állapottérkép diagram 1 állapotának kirészletezése Elemek: - Aktivitásállapotok (félkör oldalú "téglalapok"): az aktivitásállapot belső tevékenységet magába foglaló állapotot jelöl, melyhez legalább egy bemeneti, és legalább egy kimeneti állapotátmenet kapcsolódik. - Állapotátmeneteket (nyilak), - Feltételes elágazásokat (rombuszok) - Szinkronizációs pontok (vastag, vízszintes vonalak): az aktivitásdiagram olyan pontja, melyhez bemenő és kimenő állapotátmenetek kapcsolódnak (Párhuzamos elágazások és csatlakozások szinkronizációs pontok formájában írhatók le) • Időben lezajló változások ábrázolása a végrehajtandó tevékenységek és azok sorrendjének megadásával •

Alapjai: – munkafolyamat (work-flow) diagram – folyamatábra (flow chart) • Alapelemei: – tevékenységek, vagy aktivitásállapotok (ívelt oldalú téglalap) – átmenet (nyíl) – szinkronizációs vonal (vastag vízszintes vonaldarab) Komponens diagram A szoftvermodulok közötti kapcsolatokat szemlélteti • Komponensek: a rendszer fizikai alkotóelemei. • Definiált sztereotípiák: (futtatható kód, könyvtár, táblázat, fájl, doksi) Ebbe – «executable» csomagolhatunk logikai elemeket (osztály, felület, – «library» együttműködés) – «tables» Tipikusan: – «file» – forrás-állományok – «document» – könyvtárak – futtatható állományok Hozzáférés csak interfészen keresztül! – dokumentumok – adatfile-ok Komponens diagram - példa Feladat-kiosztási diagram A feladatkiosztási diagramok a működő rendszerünket alkotó szoftver és hardverkomponensek közötti fizikai kapcsolatokat írják le. Elemei: -

Csomópontok: a számítógépes rendszerünk fizikai erőforrásait reprezentálják, legtöbbször a hardver komponenseket - Csomópontok közötti kapcsolatok: az egyes elemek közötti kommunikációs csatornákat definiálják. - Komponensek: szoftvermodulok fizikai kódját testesítik meg, melyeknek megfeleltethetőknek kell lenniük a csomagdiagramokban megjelenő egyes csomagokkal. A komponensek közötti függőségek szintén meg kell egyezzenek a megfelelő csomagok közötti függőségekkel. A függőségek az egyes komponensek közötti kommunikáció tényét jelzik, a függőségek iránya pedig a kommunikációs folyamat kezdeményezőjére (az aktív elemre) utal. Tartalma: • A rendszer hardware elemei (csomópontok) és a közöttük levő fizikai viszonyok • A hardware és software elemek összerendelése