OOAD – Objektumorientált tervezés

Az elemzési fázis után a konceptuális modellt objektumorientált modellé fejlesztik tovább az objektumorientált tervezés (OOD) segítségével. Az OOD során az elemzési modellben szereplő technológiafüggetlen fogalmakat implementáló osztályokra képezik le, korlátokat azonosítanak, és interfészeket terveznek, ami a megoldási tartomány modelljét eredményezi. Dióhéjban, részletes leírás készül, amely meghatározza, hogyan kell a rendszert konkrét technológiákra építeni

Az objektumorientált tervezés szakaszai a következőképpen azonosíthatók: –

• A kontextus meghatározása az rendszer
• Rendszerarchitektúra tervezése
• A rendszer objektumainak azonosítása
• Tervezési modellek felépítése
• Objekt interfészek meghatározása

Rendszertervezés

Objekt-orientált rendszertervezés magában foglalja a rendszer kontextusának meghatározását, amelyet a rendszer architektúrájának megtervezése követ.

• Kontextus – A rendszer kontextusának van egy statikus és egy dinamikus része. A rendszer statikus kontextusát a teljes rendszer egyszerű blokkdiagramjának segítségével tervezzük meg, amelyet alrendszerek hierarchiájává bővítünk. Az alrendszerek modelljét UML csomagokkal reprezentáljuk. A dinamikus kontextus azt írja le, hogy a rendszer hogyan lép kölcsönhatásba a környezetével. Ezt használati esetdiagramokkal modellezik.

• Rendszerarchitektúra – A rendszer architektúráját a rendszer kontextusa alapján tervezik meg az architektúra tervezési elveinek, valamint a szakterületi ismereteknek megfelelően. Jellemzően a rendszert rétegekre tagolják, és az egyes rétegeket dekomponálják az alrendszerek kialakítására.

Objektorientált dekompozíció

A dekompozíció egy nagy komplex rendszer kisebb komplexitású komponensek hierarchiájára való felosztását jelenti, az oszd meg és uralkodj elvei alapján. A rendszer minden egyes nagyobb komponensét alrendszernek nevezzük. Az objektumorientált dekompozíció azonosítja a rendszer egyes autonóm objektumait és az ezek közötti kommunikációt.

A dekompozíció előnyei: –

• Az egyes komponensek kisebb komplexitásúak, így érthetőbbek és kezelhetőbbek.

• Ez lehetővé teszi a speciális képességekkel rendelkező munkaerő megosztását.

• Ez lehetővé teszi az alrendszerek cseréjét vagy módosítását anélkül, hogy az más alrendszereket érintene.

Párhuzamosság

A párhuzamosság lehetővé teszi, hogy egynél több objektum egyszerre fogadjon eseményeket, és egynél több tevékenységet hajtsanak végre egyidejűleg. Az egyidejűség azonosítása és megjelenítése a dinamikus modellben történik.

Az egyidejűség lehetővé tételéhez minden egyidejű elemhez külön vezérlőszálat rendelünk. Ha az egyidejűség objektumszintű, akkor két egyidejű objektumhoz két különböző vezérlőszálat rendelünk. Ha egy objektum két művelete egyidejű természetű, akkor az objektumot különböző szálak között osztják fel.

Az egyidejűség az adatintegritás, a holtpont és az éhezés problémáival jár. Ezért világos stratégiát kell készíteni minden olyan esetben, amikor párhuzamosságra van szükség. Emellett az egyidejűséget már a tervezési szakaszban azonosítani kell, és nem lehet a megvalósítási szakaszra hagyni.

Minták azonosítása

Az alkalmazások tervezése során a problémák bizonyos kategóriáira néhány általánosan elfogadott megoldást fogadunk el. Ezek a tervezési minták. A mintát úgy definiálhatjuk, mint az alkalmazásfejlesztési problémák bizonyos típusainál alkalmazható építőelemek dokumentált halmazát.

Egyes általánosan használt tervezési minták: –

• Façade pattern
• Model view separation pattern
• Observer pattern

.

• Modell nézet vezérlő minta
• Feliratkozás minta
• Proxy minta

Események vezérlése

A rendszertervezés során, a rendszer objektumaiban előforduló eseményeket kell azonosítani és megfelelően kezelni.

Az esemény egy jelentős esemény specifikációja, amely időben és térben helyhez kötött.

Az eseményeknek négy típusa modellezhető, nevezetesen –

• Signal Event – Egy objektum által dobott és egy másik objektum által elkapott, megnevezett objektum.

• Call Event – Egy művelet feladását jelentő szinkron esemény.

• Time Event – Az idő múlását jelentő esemény.

• Change Event – Az állapot változását jelentő esemény.

Handling Boundary Conditions

A rendszertervezési fázisban foglalkozni kell a rendszer egészének, valamint az egyes alrendszereknek az inicializálásával és megszüntetésével. A különböző dokumentálandó szempontok a következők –

• A rendszer indítása, azaz a rendszer átmenete a nem inicializált állapotból az állandósult állapotba.

• A rendszer megszüntetése, azaz, az összes futó szál lezárása, az erőforrások és a küldendő üzenetek megtisztítása.

• A rendszer kezdeti konfigurálása és szükség esetén a rendszer újrakonfigurálása.

• A rendszer hibáinak vagy nem kívánt befejezésének előrejelzése.

A határfeltételek modellezése határhasználati esetek segítségével.

Objekttervezés

Az alrendszerek hierarchiájának kialakítása után a rendszer objektumainak azonosítása és részleteinek megtervezése. Itt a tervező részletezi a rendszertervezés során választott stratégiát. A hangsúly az alkalmazási terület fogalmairól a számítógépes fogalmakra helyeződik át. Az elemzés során azonosított objektumokat kivésik a megvalósításhoz azzal a céllal, hogy minimalizálják a végrehajtási időt, a memóriafogyasztást és a teljes költséget.

Az objektumtervezés a következő fázisokat foglalja magában –

• Objektum-azonosítás
• Objektum-reprezentáció, ill, tervezési modellek felépítése
• műveletek osztályozása
• algoritmusok tervezése
• kapcsolatok tervezése
• külső kölcsönhatások vezérlésének megvalósítása
• osztályok és asszociációk modulokba csomagolása

Objektazonosítás

Az objektumtervezés első lépése az objektumazonosítás. Az objektumorientált elemzés fázisaiban azonosított objektumokat osztályokba csoportosítják és finomítják, hogy azok alkalmasak legyenek a tényleges megvalósításra.

Ez a szakasz funkciói: –

• Az egyes alrendszerek vagy csomagok osztályainak azonosítása és finomítása

• Az osztályok közötti kapcsolatok és társítások meghatározása

• Az osztályok közötti hierarchikus kapcsolatok tervezése, ill, az általánosítás/specializáció és az öröklések

• Az aggregációk megtervezése

Objektreprezentáció

Amikor az osztályokat azonosítottuk, azokat objektummodellezési technikákkal kell reprezentálni. Ez a szakasz lényegében UML-diagramok készítését jelenti.

Kétféle tervezési modellt kell készíteni –

• Statikus modellek – A rendszer statikus szerkezetének leírása osztálydiagramok és objektumdiagramok segítségével.

• Dinamikus modellek – A rendszer dinamikus szerkezetének leírására és az osztályok közötti kölcsönhatás bemutatására kölcsönhatási diagramok és állapotdiagramok segítségével.

Műveletek osztályozása

Ebben a lépésben az OOA fázisban kidolgozott három modell, nevezetesen az objektummodell, a dinamikus modell és a funkcionális modell kombinálásával határozzuk meg az objektumokon végrehajtandó műveleteket. Egy művelet azt határozza meg, hogy mit kell elvégezni, és nem azt, hogy hogyan kell elvégezni.

A műveletekkel kapcsolatban a következő feladatokat végzik –

• A rendszer egyes objektumainak állapotátmeneti diagramját dolgozzák ki.

• A műveleteket az objektumok által fogadott eseményekre definiálják.

• Azokat az eseteket azonosítják, amikor egy esemény más eseményeket vált ki ugyanazon vagy különböző objektumokban.

• A műveleteken belüli alműveleteket azonosítják.

• A főműveleteket adatáramlási diagramokká bővítik.

Algoritmustervezés

Az objektumokban lévő műveleteket algoritmusok segítségével definiálják. Az algoritmus egy olyan lépésenkénti eljárás, amely megoldja a műveletben lefektetett problémát. Az algoritmusok arra összpontosítanak, hogy hogyan kell elvégezni.

Egy adott műveletnek több algoritmus is megfelelhet. Az alternatív algoritmusok azonosítása után kiválasztjuk az adott problématerületre optimális algoritmust. Az optimális algoritmus kiválasztásának mérőszámai a következők: –

• Computational Complexity – A komplexitás meghatározza az algoritmus hatékonyságát a számítási idő és a memóriaigény szempontjából.

• Flexibilitás – A rugalmasság azt határozza meg, hogy a kiválasztott algoritmus megfelelően, a megfelelőség elvesztése nélkül megvalósítható-e különböző környezetekben.

• Megérthetőség – Ez határozza meg, hogy a választott algoritmus könnyen érthető és megvalósítható-e.

Kapcsolatok tervezése

A kapcsolatok megvalósításának stratégiáját az objektumtervezési fázisban kell kimunkálni. A fő kapcsolatok, amelyekkel foglalkozunk, az asszociációkat, az aggregációkat és az örökléseket foglalják magukban.

A tervezőnek a következőket kell tennie az asszociációkkal kapcsolatban –

• Ezonosítani, hogy egy asszociáció egyirányú vagy kétirányú.

• Elemezze az asszociációk útját, és szükség esetén frissítse azokat.

• Az asszociációkat sok-sok kapcsolat esetén különálló objektumként, vagy egy-egy vagy egy-sok kapcsolat esetén más objektumra mutató hivatkozásként valósítsa meg.

Az öröklések tekintetében a tervezőnek a következőket kell tennie –

• Az osztályok és társításaik beállítása.

• Az absztrakt osztályok meghatározása.

• Megoldja, hogy a viselkedések szükség esetén megoszthatók legyenek.

A vezérlés megvalósítása

Az objektumtervező finomításokat építhet be az állapottérképes modell stratégiájába. A rendszertervezés során a dinamikus modell megvalósításának alapstratégiája készül. Az objektumtervezés során ezt a stratégiát a megfelelő megvalósítás érdekében találóan megszépítik.

A dinamikus modell megvalósításának megközelítései a következők –

• Az állapotot a programon belüli helyként ábrázolni – Ez a hagyományos eljárásvezérelt megközelítés, amely szerint a vezérlés helye határozza meg a program állapotát. Egy véges állapotú gépet programként lehet megvalósítani. Az átmenet egy bemeneti utasítást, a fő vezérlési útvonal az utasítássorozatot, az elágazások a feltételeket, a visszafelé vezető utak pedig a ciklusokat vagy iterációkat alkotják.

• Állaggépmotor – Ez a megközelítés közvetlenül egy állapotgépet ábrázol egy állapotgépmotor osztályon keresztül. Ez az osztály az alkalmazás által megadott átmenetek és műveletek halmazán keresztül hajtja végre az állapotgépet.

• Vezérlés mint párhuzamos feladatok – Ebben a megközelítésben egy objektumot feladatként implementálnak a programozási nyelvben vagy az operációs rendszerben. Itt egy eseményt feladatok közötti hívásként valósítanak meg. Ez megőrzi a valódi objektumok eredendő párhuzamosságát.

Az osztályok csomagolása

Minden nagy projektben fontos az implementáció aprólékos felosztása modulokra vagy csomagokra. Az objektumtervezés során az osztályokat és objektumokat csomagokba csoportosítják, hogy több csoport együttműködve dolgozhasson a projekten.

A csomagolás különböző aspektusai –

• A belső információk elrejtése a külső szemlélő elől – Lehetővé teszi, hogy egy osztályt “fekete dobozként” tekintsenek rá, és lehetővé teszi az osztály implementációjának módosítását anélkül, hogy az osztály bármely kliensének módosítania kellene a kódot.

• Elemek koherenciája – Egy elem, például egy osztály, egy művelet vagy egy modul akkor koherens, ha következetes terv alapján szerveződik, és minden része belsőleg kapcsolódik egymáshoz úgy, hogy közös célt szolgál.

• Fizikai modulok felépítése – A fizikai modulok felépítése során a következő irányelvek segítenek –

  • A modulban lévő osztályoknak hasonló dolgokat vagy komponenseket kell képviselniük ugyanabban az összetett objektumban.

  • A szorosan kapcsolódó osztályoknak ugyanabban a modulban kell lenniük.

  • A nem kapcsolódó vagy gyengén kapcsolódó osztályokat külön modulokban kell elhelyezni.

  • A moduloknak jó kohézióval kell rendelkezniük, azaz, nagyfokú együttműködés a komponensek között.

  • A modulnak alacsony csatolással kell rendelkeznie más modulokkal, azaz a modulok közötti kölcsönhatásnak vagy egymásrautaltságnak minimálisnak kell lennie.

Tervezési optimalizálás

Az elemzési modell a rendszer logikai információit rögzíti, míg a tervezési modell részleteket ad hozzá a hatékony információhozzáférés támogatása érdekében. A terv megvalósítása előtt optimalizálni kell, hogy a megvalósítás hatékonyabbá váljon. Az optimalizálás célja a költségek minimalizálása az idő, a hely és más mérőszámok tekintetében.

A tervezés optimalizálása azonban nem lehet túlzás, mivel a könnyű megvalósíthatóság, a karbantarthatóság és a bővíthetőség szintén fontos szempontok. Gyakran tapasztalható, hogy a tökéletesen optimalizált tervezés hatékonyabb, de kevésbé olvasható és újrafelhasználható. A tervezőnek tehát egyensúlyt kell találnia a kettő között.

A tervezés optimalizálásához a következő különböző dolgokat lehet tenni: –

• Redundáns asszociációk hozzáadása
• Nem használható asszociációk elhagyása
• Az algoritmusok optimalizálása
• A származtatott attribútumok mentése az összetett kifejezések újraszámításának elkerülése érdekében

Redundáns asszociációk hozzáadása

A tervezés optimalizálása során, ellenőrzik, hogy új asszociációk levezetésével csökkenthetők-e a hozzáférési költségek. Bár ezek a felesleges asszociációk nem adnak hozzá semmilyen információt, növelhetik a teljes modell hatékonyságát.

Nem használható asszociációk felvétele

A túl sok asszociáció jelenléte megfejthetetlenné teheti a rendszert, és ezáltal csökkentheti a rendszer teljes hatékonyságát. Ezért az optimalizálás során az összes nem használható asszociáció eltávolításra kerül.

Az algoritmusok optimalizálása

Az objektumorientált rendszerekben az adatszerkezet és az algoritmusok optimalizálása együttműködő módon történik. Miután az osztálytervezés elkészült, a műveleteket és az algoritmusokat kell optimalizálni.

Az algoritmusok optimalizálása –

• A számítási feladatok sorrendjének átrendezésével
• A ciklusok végrehajtási sorrendjének megfordítása a funkcionális modellben meghatározottól

érhető el.

• Holt utak eltávolítása az algoritmuson belül

A származtatott attribútumok mentése és tárolása

A származtatott attribútumok azok az attribútumok, amelyek értékét más attribútumok (alapattribútumok) függvényében számítják ki. A származtatott attribútumok értékeinek újraszámítása minden alkalommal, amikor szükség van rájuk, időigényes eljárás. Ennek elkerülése érdekében az értékek kiszámíthatók és a kiszámított formájukban tárolhatók.

Ez azonban frissítési anomáliákat okozhat, azaz az alapattribútumok értékeinek olyan változását, amelynek nincs megfelelő változás a származtatott attribútumok értékeiben. Ennek elkerülése érdekében a következő lépéseket tesszük –

• Az alapattribútum értékének minden egyes frissítésével a származtatott attribútum is újraszámításra kerül.

• A származtatott attribútumok újraszámítása és frissítése nem minden egyes frissítés után, hanem periodikusan, csoportosan történik.

Tervezési dokumentáció

A dokumentáció minden szoftverfejlesztési folyamat lényeges része, amely rögzíti a szoftver elkészítésének menetét. A tervezési döntéseket minden nem triviális szoftverrendszer esetében dokumentálni kell, hogy a tervezést másoknak át lehessen adni.

Hasznosítási területek

A jó dokumentáció – bár másodlagos termék – nélkülözhetetlen, különösen a következő területeken –

• A több fejlesztő által fejlesztett szoftverek tervezésénél
• A szoftverek iteratív fejlesztési stratégiáinál
• A szoftverprojekt későbbi verzióinak fejlesztésénél
• A szoftver értékelésénél
• A tesztelés feltételeinek és területeinek megtalálásához
• A szoftver karbantartásához.

Tartalom

A hasznos dokumentációnak alapvetően a következő tartalmakat kell tartalmaznia –

• magas szintű rendszerarchitektúra – Folyamatábrák és modulábrák

• Főbb absztrakciók és mechanizmusok – Osztályábrák és objektumábrák.

• Scenáriók, amelyek a fő szempontok viselkedését szemléltetik – Viselkedési diagramok

Jellemzők

A jó dokumentáció jellemzői –

• Pontos és ugyanakkor egyértelmű, következetes és teljes

• követhető a rendszer követelményspecifikációjához

• jól strukturált

• leíró helyett diagrammatikus