Objektumorientált tervezés

Ez a szócikk nem tünteti fel a független forrásokat, amelyeket felhasználtak a készítése során. Emiatt nem tudjuk közvetlenül ellenőrizni, hogy a szócikkben szereplő állítások helytállóak-e. Segíts megbízható forrásokat találni az állításokhoz! Lásd még: A Wikipédia nem az első közlés helye.

Ez a szócikk vagy szakasz lektorálásra, tartalmi javításokra szorul. A felmerült kifogásokat a szócikk vitalapja részletezi (vagy extrém esetben a szócikk szövegében elhelyezett, kikommentelt szövegrészek). Ha nincs indoklás a vitalapon (vagy szerkesztési módban a szövegközben), bátran távolítsd el a sablont! Csak akkor tedd a lap tetejére ezt a sablont, ha az egész cikk megszövegezése hibás. Ha nem, az adott szakaszba tedd, így segítve a lektorok munkáját!

Lásd még: Objektumorientált elemzés és tervezés

Az objektumorientált tervezés az a folyamat, amikor egy interaktív objektumokból álló rendszert tervezünk egy szoftveres probléma megoldásának céljából. Ez az egyik megközelítése a szoftvertervezésnek.

Egy objektum magába foglalja az egységbezárt adatokat és az eljárásokat, amelyekkel egy entitást alkot. Az objektuminterfész meghatározza, hogyan lehet az objektummal interakcióba lépni. Egy objektumorientált program ezen objektumokkal való interakciók által jellemezhető. Az objektumorientált tervezés szabályozza az objektumok meghatározását és ezek interakciójait egy probléma megoldása érdekében, amely az objektumorientált analízis során lett felfedezve és dokumentálva.

Az alábbiakban bemutatásra kerül az objektumorientált tervezés osztályalapú részhalmaza, amely nem foglalja magában az objektum prototípus-alapú megközelítéseit, ahol az objektumokat általában nem osztályok bemutatásával, hanem más (prototípus) objektumok klónozásával nyerik. Objektumorientált tervezés olyan tervezési módszer, amely magában foglalja az objektumorientált kisebb részekre bontásának folyamatát és egy jelölést a tervezendő rendszer logikai és fizikai, valamint állapot- és dinamikus modelljeinek ábrázolására.

Az objektumorientált tervezés bemenetét az objektumorientált analízis eredménye adja meg. Ezen eredménynek nem szükséges teljesen kifejlettnek lennie, ahhoz, hogy a tervezés bemeneteként használhassuk; az analízis és a tervezés történhet párhuzamosan, és a gyakorlatban az egyik tevékenység eredménye segítheti a másikat egy úgynevezett ismétlődő rövid visszajelzési ciklusban. Mind az analízis, mind a tervezés elvégezhető szakaszosan, és a rendszer folyamatosan fejlődhet, ahelyett, hogy egy nekifutásra lefejlesztésre kerüljön.

Az objektumorientált tervezés néhány tipikus bemenete a következőek:

• Koncepcionális modell: Az objektumorientált elemzés eredménye, rögzíti a problémakör fogalmait. A fogalmi modell kifejezetten úgy van megválasztva, hogy független legyen a megvalósítás részleteitől, például a párhuzamosságtól vagy az adattárolástól.
• Használati eset: Azon események sorozatának leírása, amelyek együttesen vezetnek ahhoz, hogy a rendszer valami hasznosat csináljon. Minden felhasználási eset egy vagy több forgatókönyvet tartalmaz, amelyek közvetítik, hogy a rendszer miként léphet kölcsönhatásba a felhasználókkal, úgynevezett szereplőkkel, egy adott üzleti cél vagy funkció elérése érdekében. A felhasználási eset szereplői lehetnek végfelhasználók vagy más rendszerek. Sok esetben a használati eseteket tovább fejlesztik használati eset diagrammá. Az esetdiagramok a szereplő (felhasználók vagy más rendszerek) és az általuk végrehajtott folyamatok azonosítására szolgálnak.
• Rendszer-sorrend diagram: A rendszer-sorrend diagram (RSD) egy kép, amely egy adott felhasználási eset egy adott forgatókönyve esetén megmutatja a külső szereplők által generált eseményeket, azok sorrendjét és a lehetséges rendszerek közötti eseményeket.
• Felhasználói felület dokumentációja (ha van): Olyan dokumentum, amely megmutatja és leírja a végtermék felhasználói felületének megjelenését és hangulatát. Ez nem kötelező, de elősegíti a végtermék megjelenítését, és ezáltal segíti a tervezőt.
• Relációs adatmodell (ha alkalmazható): Az adatmodell egy elvont modell, amely leírja az adatok ábrázolását és felhasználását. Ha nem használ objektum-adatbázist, akkor a relációs adatmodellt általában a tervezés előtt kell létrehozni, mivel az objektum-relációs leképezésre kiválasztott stratégia az OO tervezési folyamat kimenete. Lehetséges azonban a relációs adatmodell és az objektumorientált tervezési termékek fejlesztése párhuzamosan, és ezek fejlődése ösztönözheti más termékek finomítását.

Az objektumorientált tervezés öt alapfogalma a végrehajtási szintű szolgáltatások, amelyek beépülnek a programozási nyelvbe. Ezekre a jellemzőkre gyakran ezekkel a nevekkel hivatkoznak:

• Objektum/osztály: Az adatszerkezetek szoros összekapcsolása vagy társítása az adatokra ható módszerekkel vagy funkciókkal. Ezt osztálynak vagy objektumnak nevezzük (egy objektum egy osztály alapján készül). Minden objektum külön funkciókkal szolgál. Tulajdonságai határozzák meg, mi ez és mit tud tenni. Az objektum lehet egy osztály része, amely hasonló objektumok halmaza.
• Információ elrejtése: Az objektum egyes alkotóelemeinek külső elemekkel szembeni védelme. Ezt nyelvi kulcsszavak valósítják meg, amelyek lehetővé teszik egy változó magánjellegűvé tételét vagy védettségét a tulajdonos osztály számára.
• Öröklés: Az osztály képessége kiterjeszteni vagy felülbírálni egy másik osztály funkcionalitását. Az úgynevezett alosztálynak van egy egész része, amelyet a ősosztályból származtatunk (örökölünk), illetve saját funkcióival és adataival rendelkezik.
• Interfész (objektumorientált programozás): Egy metódus implementálásának elhalaszthatósága. Az a képesség, hogy meghatározzuk a függvények vagy metódusok szignatúráit azok implementálása nélkül.
• Polimorfizmus: Az a képesség, hogy egy osztályt annak alosztályával helyettesíthetünk. Egy objektumváltozó azon képessége, hogy nemcsak az objektumot, hanem az összes alobjektumát is tartalmazza.

• Objektumok meghatározása, osztálydiagram létrehozása a konceptuális diagramból: Általában az entitás osztályozása.
• Az attribútumok azonosítása.
• Használjunk tervezési mintákat (ha alkalmazható): A tervezési minta nem kész terv, hanem egy általános probléma megoldásának leírása egy környezetben.^[1] A tervezési minta használatának fő előnye, hogy több alkalmazásban is felhasználható. Úgy gondolhatunk rá, mint egy sablon, egy olyan probléma megoldására, amely sokféle helyzetben és / vagy alkalmazásban felhasználható. Az objektumorientált tervezési minták általában az osztályok vagy objektumok közötti kapcsolatokat és interakciókat adják meg, anélkül, hogy meghatározzák a végleges alkalmazásbeli osztályokat vagy objektumokat.
• Az alkalmazás keretrendszerének meghatározása (ha alkalmazható): Az alkalmazás keretrendszere általában olyan könyvtárak vagy osztályok összessége, amelyeket egy adott operációs rendszer alkalmazásának szabványos struktúrájának megvalósításához használnak. Ha nagy mennyiségű újrahasznosítható kódot von össze egy keretbe, sok időt takaríthat meg a fejlesztő számára, mivel megtakarítja azt az időt, hogy nagy mennyiségű standard kódot írjon minden új kifejlesztett alkalmazáshoz.
• Állandó objektumok / adatok azonosítása (ha alkalmazható): Azon objektumok azonosítása, amelyeknek az alkalmazás futási idejénél hosszabb ideig kell tartaniuk. Relációs adatbázis használata esetén tervezze meg az objektum reláció leképezését.
• Azonosítsa és határozza meg a távoli objektumokat (ha alkalmazható).

• Szekvenciadiagram: Bővítse a rendszer szekvencia diagramját az olyan objektumok hozzáadásával, amelyek kezelik a rendszer eseményeit.

A szekvencia diagram párhuzamos függőleges vonalként mutatja be az egyidejűleg élő különböző folyamatokat vagy objektumokat, és vízszintes nyilakként az egymás között kicserélt üzeneteket azok sorrendjében.

• Osztálydiagram: Az osztálydiagram egy statikus szerkezetű UML diagram, amely leírja a rendszer felépítését a rendszer osztályainak, attribútumainak és az osztályok közötti kapcsolatoknak a bemutatásával. A szekvenciadiagramok kidolgozása során azonosított üzenetek és osztályok felhasználhatók a rendszer globális osztálydiagramjának automatikus generálására.

• Függőség-injektálás: Az alapötlet az, hogy ha egy objektum függ attól, hogy van-e más objektum példánya, akkor a szükséges objektumot "injektálják" a függő objektumba; például egy adatbázis-kapcsolat átadása paraméterként a konstruktor számára ahelyett, hogy belsőleg létrehoznánk azt.
• Az aciklikus függőségek elve: A csomagok vagy komponensek függőségi gráfjának (a részletesség a fejlesztő munkakörétől függ) nem szabad ciklusokat tartalmaznia. Erre utal az irányított aciklikus gráf is.^[2] Például a C csomag függ a B csomagotól, amely az A csomagotól függ. Ha az A csomag szintén a C csomagon múlik, akkor lesz egy ciklusa.
• Kompozit újrafelhasználás elve: A tárgyak polimorf összetétele az öröklés helyett.^[1]

Ez a szócikk részben vagy egészben az Object-oriented design című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

• Objektumorientált programozás

• Objektumorientált elemzés és tervezés - áttekintés az UML használatával
• Larman, Craig. UML és minták alkalmazása - Harmadik kiadás
• Objektumorientált elemzés és tervezés
• LePUS3 és Z-osztály: formális modellezési nyelvek az objektumorientált tervezéshez