Objektumorientált tervezés

Objektumok, osztályok

Az objektumorientált tervezés során a rendszert az objektumok mentén építjük fel, ahol az objektum

  • valóság absztrakcióját adja
  • biztosít egy elvárt funkcionalitást
  • adat es működés egymásba burkolásából épül fel

Egy adott feladatban az objektumokat be kell azonosítnaunk azáltal, hogy

  • milyen funkciókat azonsítottunk az elemzés során, és azok milyen adatokkal dolgoznak
  • a valóságban milyen építőelemeket tudnánk megfeleltetni a funkcióknak

A tervezés fázisai

A tervezés általában több fázisból épül fel, amely során finomítunk a terven, mivel meglehetősen nehézkes már az első fázis alapján beazonosítani a szükséges objektumokat, és azok felépítését.

Ezért, minden fázisban

  • bevezethetünk új osztályokat a beazonosított feladatokra
  • tovább pontosíthatjuk a már létező osztályok felépítését, az implementációs megkötéseket
  • felbonthatunk osztályokat, amennyiben túl bonyolulttá, túl szerteágazóvá válnak
  • összevonhatunk osztályokat, amennyiben túlzottan elaprózódnak

A tervezés alapelvei (SOLID)

  • Single responsibility principle
  • Open/Closed principle: a programegységek nyitottak a kiterjeztésre, de zártak a nódosításra
  • Liskov substitution principle: az objektumok helyettesíthetőek altípusaik példányával
  • Interface segregation principle: egy általános interfész helyett több kliens specifikus interfész
  • Dependency inversion principle: az absztrakciótól függünk, nem a konkretizációtól

Az architektúra

Szoftver architektúrának nevezzük a szoftver fejlesztése során meghozott elsőfleges tervezési döntések halmazát.

Ezek erősen kihatnak a rendszer felépítésére, viselkedésére, és megváltoztatásuk később nehézkes.

A fő feladata a rendszer magas szintű működésének meghatározása, a komponensek és relációk kiépítése.

Minták a tervezésben

A monolitikus architektúra

A legegyszerűbb felépítést adja.

  • nincsenek programegységekbe szétválasztva a funkciók
  • a felületet megjelenítő kód vegyül az adatkezeléssel, a tevékenységek végrehajtásával

A modell/nézet architektúra

Különválasztja a felhasználói felülettel kapcsolatos részeket a ténylegesen a feladat megoldását szolgáló funkcionalitástól.

  • a modell tartalmazza a feladat végrehajtását szolgáló programegységet (üzleti logikát)
  • a nézet tartalmazza a grafikus felhasználói felület megvalósítását,a felület elemeit és az eseménykezelőket
  • a nézet ismerheti a modell interfészét, és hívhatja annak publikus műveleteit
  • a modellnek semmilyen tudomása nincs a nézetről, csak eseményeken keresztül kommunikálhat vele

Csomagdiagram

Célja a rendszer felépítése a logikai szerkezet mentén, azaz az egyes csomagok azonosítása és a beléjük tartozó osztályok bemutatása.

A csomagok között is létrehozhatunk kapcsolatokat (függőség, asszociáció, általánosítás, megvalósítás).

Továbbiak:

  • use: a csomag felhasznál egy másikat
  • nesting: a csomag egy másiknak a része
  • import: a csomag betölti a másikat
  • merge: a csomag tartalmazza, és kibővíti a másik teljes funkcionalitását.

A szoftverrendszer

Szoftver: programok + dokumentáció + konfiguráció + adatok

  • mivel a megoldandó feladatok összetettek lehetnek, a megoldást lehet csak több program tudja megadni
  • végrehajtás során ezek egymással kommunikálnak

Az egymással kommunikáló programok rendszerét szoftverrendszernek nevezzük. Ezek részeit komponenseknek.

Komponensek

Adott funkcionalitásért felel és fizikailag elkülönül.

  • önállóan felhasználható, telepíthető
  • a belső működése rejtett, a kapcsolatot interfészek bisztosítják
  • szolgáltathat ilyan funkcionalitást, amelyet más komponensek használnak fel
  • felhasználhat más komponenseket is

Komponensek például

  • asztali alkalmazás
  • mobil alkalmazás
  • weblap
  • adatbázis

Feloszthatjuk így is:

  • végrehajtható állományok
  • könyvtárak

Komponensdiagram

Ismerteti a rendszer komponenseit, az interfészeket és a köztük fennálló kapcsolatokat (connector)

Telepítési diagram

A szoftverrendszert kihelyezési és környezeti szempontból ábrázolja.

Ismeri azon csomópontokat (node), amelyeken az egyes alkotóelemei (artifact) találhatóak.

A rendszer alkotóeleme lehet bármilyen, fizikailag elkülönülő tartozéka a szoftvernek.

A rendszer egy csomópontja lehet egy hardware eszköz, és egy végrehajtási felület, amely biztosítja a szoftverek futását.

Adatformátumok

Minden, a szoftver számára bemenetként, vagy kimenetként szolgáló adat formátumát, felépítését meg kell adnunk.

Összetett adatok esetén támaszkodhatunk létező formátumokra:

  • CSV
  • XML
  • JSON

A rendszerterv

A tervezés eredménye a szoftver rendszerterve, amely tartalmazza:

  • a program statikus szerkezetét
  • a program dinamikus szerkezetét
  • a tárolt, kezelt, és eredményül adott adatok formáját
  • a programok belső és külső interfészeinek leírását
  • ajánlásokat az implementáció számára

A rendszerterv felépítése:

  1. előszó (célközönség, dokumentum-történet)
  2. bevezetés (szoftver célja, helye, szükségessége )
  3. fogalomtár
  4. rendszer architektúra (csomag-, komponens-, állapotdiagram)
  5. adattervezés
  6. rendszertervezés (statikus terv, dinamikus terv, interfész leírás, algoritmusok)
  7. felhasználói felület
  8. implementációs ajánlások
  9. függelék (pl.: adatbázis terv, becsült hardware szükségletek)
  10. tárgymutató

Források