Gyurkó György

Az OO programozás és tervezés története 1960-as évek: SIMULA (véletlen folyamatokat szimuláló programok írása) az OO nyelvek őse 1970-es évek: Smalltalk tisztán objektumorientált nyelv; fejlesztő: Xerox PARC. – Széles körben a Smalltalk-80 válik ismertté (1980) 1980-as évek eleje: C++; fejlesztő: Bjarne Stroustrup az AT&T Bell laboratóriumban tól: Java, fejlesztő: Sun Microsystems, Inc. (webes alkalmazások) 1980-as évek második fele, 1990 évek eleje: OO elemzési tervezési módszertanok kialakulása 1990-es évek közepe, második fele: OO elemzést és tervezést támogató CASE eszközök megjelenése

Egyszerre több elemzési és tervezés módszertan Az 1980-as évek második felében, 1990-es évek elején létrejövő OO módszertanok: James Rumbaugh és munkatársai által kidolgozott OMT (Object Modeling Technique), Grady Booch által kidolgozott módszertan, Shlaer és Mellor által kidolgozott módszertan, Ivar Jacobson és munkatársai által kidolgozott OOSE (Object-Oriented Software Engineering), és még további módszertanok nagyobb informatikai cég műhelyéből Mindegyik saját jelölésrendszert használt!!!  UML

Az UML története 1994: Rumbaugh és Booch szándéknyilatkozata közös OO rendszerfejlesztési módszer kidolgozására 1995: Az OMT és a Booch módszerek egyesítésének vázlata (Unified Method 0.8) 1996: Csatlakozik Jacobson is. Hárman dolgozzák ki a Unified Method 0.9-et. 1997: Januárban Unified Modeling Language néven adják be az OMG (Object Management Group) független szabványszervezethez (konzorcium). Ez a verzió kapja az UML 1.0 jelölést szeptemberben megjelenik az UML 1.1, amelyet követően egyre több CASE gyártó terméke támogatja az UML-t : Sorban jelennek meg az UML újabb verziói 1.2: 1998, 1.3: 1999, 1.4: 2001, 1.5(munkaverzió): : UML : UML 2.0

Az UML áttekintése Diagramtechnikák A modellelemek csoportosítása – csomagok, csomagdiagramok UML kiterjesztési mechanizmusok (sztereotípusok és megszorítások)

Az UML diagramtechnikái Használati eset vetület (nézet) Funkcionális követelmények leírása Statikus modellek (szerkezeti modellezés) Osztályok definiálása, osztályok közötti viszonyok (általánosítás/specializáció, asszociációk, függések) esetleg objektumok és azok viszonyai Dinamikus modellek (viselkedésmodellezés) Objektumok együttműködése/kommunikációja, állapotváltozásai (cél az osztályok metódusainak meghatározása, a statikus modell finomítása) Üzleti folyamatok leírása tevékenység-diagrammal (cél: a követelmények meghatározása, pontosítása) Alkalmazás / komponensmodul működésének leírása tevékenység-diagrammal Kivitelezési modellek (architektúramodell) Komponensdiagram (az alkalmazás felépülése kódkomponensekből) Telepítési diagram

Modellelemek csoportosítása (csomagok, csomagdiagramok) Csomagok tartalmazási hierarchiája és függősége

Modellelemek csoportosítása (csomagok, csomagdiagramok) Csomagok közötti általánosítás és pontosítás

Az UML kiterjesztési mechanizmusai Az UML eszköztár kiterjesztése az alkalmazó szervezet igényei szerint Sztereotípusok (Stereotype) : a modellelemek több szempontú tipizálására, illetve újabb típusú modellelemek képzésére szolgálnak. Megszorítások (Constraint): a modellelemek olyan tulajdonságainak (element properties) megadására szolgálnak, amelyek az UML más jelrendszerével nem fejezhetők ki. Egyes – felsorolás típusú értékkel megadható – megszorításokat pedig a modellelemeknek a sztereotípiákon felüli, további tipizálására használnak, pl.: {abstract}, {transient}, {persistent}.

Sztereotípusok megadása - példák

Megszorítások megadása - példák

Követelmények kezelése Követelmények megállapítása, leírása Követelmények érvényességének nyilvántartása (rendszertervezési változatok) Követelmények teljesítésének követése

Követelmények típusai Funkcionális követelmények Nem funkcionális követelmények (pl. egyidejűleg kiszolgált felhasználók száma, skálázhatóság,...)

A Use Case modell célja: A funkciók / funkcionális követelmények meghatározása A rendszer határainak megvonása Felhasználó szerepkörök és jogosultságaik meghatározása A projekt által igényelt erőforrások becslése A projekt ütemezésének, idő- és költségtervezésének, megalapozása A tesztspecifikációk készítésének támogatása (a használati esetek képezik a felhasználói tesztesetek / tesztspecifikációk közvetlen bemenetét)

A használati eset diagram szimbólumai Használati esetek (use case-ek, „krumplik”): a rendszernek a felhasználó által látható funkciói, szolgáltatásai Felhasználói szerepkörök (aktorok, pálcikaemberek): felhasználói szerepek vagy kapcsolódó más alkalmazások Kapcsolatok (asszociációk): aktor és használati eset közötti kapcsolatok Függőségek: használati eset közötti viszonyok Általánosítás / specializáció: aktor-aktor, illetve eset- eset viszonyok

Egy áttekintő use case diagram

Magyarázatok a „KIR áttekintése” ábrához / 1 Miért kell modellezni az aktorokat mint szerepköröket? Mert a szerepkörökhöz így rendelhetők hozzá a szolgáltatások használatára vonatkozó jogok. Mit fejeznek ki az előző ábra általánosítás / specializáció értelmű nyilai? Azt, hogy a KIR felhasználó szerepkörnek specializációi az Érkeztető, az Iktató, az Ügyintéző, az Irattáros és a Rendszergazda szerepkörök. A milyen állításoknak van helye a KIR felhasználó szerepkör specifikációjában? Olyan állításoknak, amelyek közösen érvényesek minden felhasználóra, azaz a KIR felhasználó szerepkör minden specializációjára. Mit fejez ki egy aktor és egy használati eset közötti asszociáció? Azt, hogy az aktorral képviselt szerepkörnek joga van használni a használati esetet (szolgáltatást).

Magyarázatok a „KIR áttekintése” ábrához / 2 Milyen szolgáltatásokhoz van hozzáférése az Iktató szerepkörnek? A Kézbesítés és az Ügyiratkezelés szolgáltatás(csomagok)hoz. Mire való a megjegyzés szimbólum a diagramon? Olyan tudnivalókat közölhetünk vele, amelyeket a diagram nem tud kifejezni. Azonos konkrét felhasználónak (konkrét személynek) egyidejűleg lehet- e több szerepköre? Igen. Ugyanis az „Ezt a szerepkört is általában az iktató látja el az ügyintéző helyett”* megjegyzésből az következik, hogy lehet olyan felhasználó, aki egyszerre rendelkezik mind az Iktató, mind az Ügyintéző szerepkörrel. * Az „Ezt a szerepkört is általában az iktató látja el az ügyintéző helyett” megjegyzésből, nem következik, hogy az iktató ügyeket is elintéz. Inkább arról van szó, hogy a KIR egy iratkezelő rendszer neve, és az Ügyintézés szolgáltatáscsomag valójában az ügyintézésben érintett iratok keletkezésével, mozgásával, állapotváltozásával kapcsolatos adatok rögzítésére ad lehetőséget, de ezeket az adatokat mégsem az ügyintéző rögzíti ő csak olyan feljegyzéseket ír a mappára vagy a fizikailag (papíron) létező iratra, amelyek alapján az iktató el tudja végezni a rendszer által az ügyintézés következményeiről várt adatok bevitelét.

Az előző diagram „Küldemények kezelése” esetének kifejtése

Magyarázatok a „Küldemények kezelése” ábrához / 1 Az ábrán az Érkeztető felhasználót csak három használati esettel („krumplival”) köti össze asszociáció. Ez azt jelenti ez a felhasználó csak ezt a három szolgáltatást veheti igénybe (csak ezeket a „krumplikat” érheti el)? Nem. Igénybe veheti azok kötelező részeit ( >) és opcionális kiterjesztéseit ( >) is. – Másképpen: elérheti az összes „krumplit”, amelyhez (az említett három „krumpliból” vezet > és / vagy > sztereotípusú függésekből álló láncolat. Mit fejeznek ki a Küldeményadatok kezelése – általános használati esetből kiinduló > függések? Azt, hogy a Küldeményadatok kezelése – általános használati eset kötelezően tartalmazza a nyilakkal mutatott hat másik használati esetet (szolgáltatást). – Pl. a Küldeményadatok kezelése – általános használati esetben egy a felhasználó egy olyan képernyőt kezel, amelynek hat panelje van. (Ha a hat panel túl nagy felületet adna ki, elképzelhető az is, hogy a képernyőt hat füleslap alkotja.)

Magyarázatok a „Küldemények kezelése” ábrához / 2 Mit fejeznek ki az ábra használati esetei közötti általánosítás / specializáció értelmű nyilak? 1. A Küldeményadatok kezelése – általános használati esetnek specializációi a Küldeményadatok megtekintése és az Érkeztetés iktatás nélkül esetek. 2. A Küldeményadatok megtekintése esetnek specializációja a Küldeményadatok módosítása eset. Az ábrán az Érkeztető felhasználótól nem vezet > és / vagy > sztereotípusú függésekből álló láncolat a Küldeményadatok kezelése – általános használati esethez. Ezek szerint a felhasználó ezt az esetet nem használhatja? A felhasználó konkrétan a Küldeményadatok kezelése – általános használati esetet nem használhatja, hiszen az egy absztrakt használati eset, amely csak a konkrét esetek specifikációjának egyszerűsítésére szolgál azáltal, hogy azok specifikációjának közös elemi ebben kiemelhetők.

Magyarázatok a „Küldemények kezelése” ábrához / 3... Tehát a felhasználó Küldeményadatok kezelése – általános eset szolgáltatásait nem éri el? Amikor a felhasználó a Küldeményadatok kezelése – általános eset valamelyik specializációját használhatja, abban benne vannak (elérhetők) az általános esetnél specifikált szolgáltatások is. Mivel egyszerűsíti a Küldeményadatok kezelése – általános használati esetet jelenléte más használati esetek specifikációját? Azt a tényt, hogy a képernyő történetesen tartalmazza a Küldemény főbb adatai, a További beküldők, a Mellékletek,..., Csatolmányok paneleket / füleslapokat, nem kellett duplán, az Érkeztetés iktatás nélkül és a Küldeményadatok megtekintése eseteknél is specifikálni.

Példa a „Digitális óra” esettanulmányból Áttekintő változat Részletező változat

Példa az „Egy lakás biztonsági rendszere” esettanulmányból

Példa az „Egy szupermarket parkolási rendszere” esettanulmányból

Egy használati eset részleteinek kifejtése Másik - részletező - use case diagram Szöveges forgatókönyv (scenárió) A viselkedésmodellezésből vett technikák (szekvenciadiagram, tevékenységdiagram)