Objektumorientált tervezés: meghatározás, elvek és példák

Az objektum-orientált tervezés az interakciós objektumok rendszerének tervezési folyamata egy szoftverprobléma megoldása érdekében. Ez a szoftverfejlesztés egyik megközelítése.

Egy elem kapszulázott adatokat és eljárásokat tartalmaz, amelyek egy objektumot ábrázolnak. Az interfész meghatározza, hogyan létezhet egymás mellett, a program pedig leírja a halmazok kölcsönhatását. Az objektumorientált tervezés az objektumok és folyamataik meghatározásának tudománya az elemzés során azonosított és dokumentált probléma megoldására.

Az alábbiakban egy osztályalapú részhalmaz leírása található, amely nem tartalmazza az objektum prototípus - alapú megközelítéseket, amikor ezeket általában nem osztályok példányainak létrehozásával, hanem mások klónozásával érik el. A tervezés objektum-orientált tervezési módszertan. Ez magában foglalja a bomlási folyamatot, valamint a logikai és fizikai állapotok ábrázolásának jelölését, valamint a tervezett rendszer dinamikus modelljeit.

Tervezési Témák

Az objektumorientált tervezés bemenetét az elemzési kimenet biztosítja. Meg kell érteni, hogy egy műtárgyat nem kell teljes mértékben úgy megtervezni, hogy referenciapontként szolgáljon. Az elemzés és a tervezés párhuzamosan történhet. A gyakorlatban az egyik művelet eredményei rövid visszacsatolási hurokban iteratív folyamaton keresztül táplálhatják a másikat. Mind az első, mind a második művelet szakaszokban hajtható végre, a tárgyak folyamatosan növelhetők, és nem fejleszthetők ki teljesen egyszerre.

Néhány tipikus elem

Fontolja meg a legfontosabbat.

1. Koncepcionális modell.

Az objektumorientált elemzés és tervezés eredményeit a terület fogalma lefedi. A fogalmi modellt kifejezetten úgy választják meg, 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.

2. Használati eset.

Olyan eseménysorozatok leírása, amelyek együttesen arra vezetnek, hogy a rendszer valami hasznosat csinál. Minden használati eset egy vagy több forgatókönyvet tartalmaz, amelyek objektum-orientált rendszertervezést közvetítenek. Egy adott üzleti cél vagy funkció elérése érdekében kölcsönhatásba kell lépnie a felhasználókkal, az úgynevezett szereplőkkel.

A felhasználási esetek végrehajtói lehetnek végfelhasználók vagy egyéb rendszerek. Sok esetben ennek a módszernek az alkalmazási lehetőségeit diagramok formájában fejlesztették ki. A Use case diagramokat a színész és az általuk végrehajtott folyamatok azonosítására használják. Bővebben olvashat Gradi Butch "objektum-orientált tervezés"című könyvében.

3. Rendszer szekvencia diagram.

Ez egy olyan kép, amely egy adott forgatókönyv számára bemutatja a külső résztvevők által generált események felhasználási eseteit, sorrendjét, valamint a lehetséges rendszerközi műveleteket.

4. Felhasználói Felület Dokumentációja.

Papír, amely bemutatja és leírja a végtermék megjelenését. Ez az elem opcionális, de segít a megjelenítésben, ami megkönnyíti a tervező számára.

relációs adatmodell létrehozása

Ez egy absztrakt prototípus, amely leírja az információk bemutatását és felhasználását. Ha az objektumadatbázist nem használják, akkor a relációs adatmodellt általában a művelet előtt kell létrehozni, mivel az objektumorientált tervezés elfogadására választott stratégia a folyamat kimenete.

Lehetséges azonban egy relációs adatmodell párhuzamos kidolgozása, a műtárgy növekedése pedig ösztönözheti más komponensek finomítását. Erről bővebben Butch "Object-oriented analysis and Design"című könyvében is szerepel. Ne feledje, hogy a Gradi Bucha új kiadásában sok gyakorlati tippet talál az elemzéssel, a megvalósítással, a tervezéssel és a projektmenedzsmenttel kapcsolatban.

Fogalmak

Az objektumorientált tervezés öt alapja a beépített megvalósítási szintű funkciók programozási nyelv. Gyakran a következő közös nevekkel hívják őket:

1. Objektum osztály.

Mi ez? Az osztály az adatstruktúrák szoros kapcsolata vagy érintése az őket érintő módszerekkel vagy funkciókkal (ennek alapján objektum jön létre). Minden elem egy funkciót hajt végre. Ezt a tulajdonságai határozzák meg. Egy objektum része lehet egy osztálynak, amely hasonló elemek gyűjteménye.

2. Az információs rendszerek objektum-orientált tervezésének elrejtése az a képesség, hogy megvédje egyes komponenseket a külső hatásoktól.

3. Öröklés.

Ez egy lehetőség arra, hogy egy osztály kibővítse vagy újradefiniálja egy másik csoport funkcionalitását. Az úgynevezett alosztálynak van egy teljes szakasza, amely a szuperosztályból származik (örökölt), valamint saját függvényekkel és adatokkal is rendelkezik.

. Interfész (az objektumorientált tervezés technikái között vannak úgynevezett minták. Az absztrakt gyári felület az egyik).

A módszer végrehajtásának elhalasztásának képessége, valamint a funkciók meghatározásának képessége azok végrehajtása nélkül.

5. Polimorfizmus (különösen altípus) - az objektum alobjektumokkal való helyettesítésének képessége. Amellett, hogy egy változó objektum nemcsak ezt az objektumot, hanem annak összes összetevőjét is tartalmazhatja.

A fogalmak fejlesztése

Objektumok definiálása, osztálydiagram létrehozása fogalmi formából általában egy entitást jelenít meg.

Az attribútumok azonosítása.

Az objektumorientált tervezési technikák gamma mintáit kell használni. Ez nem késztermék, hanem egy közös probléma megoldásának leírása a kontextusban. A fő a használat előnye a tervezési minta az, hogy több alkalmazásban újra felhasználható. Azt is figyelembe kell venni, hogy problémák megoldása, ez sok különböző helyzetben felmerülhet. A Gamma objektum-orientált tervezési minták általában az osztályok vagy objektumok közötti kapcsolatokat és kölcsönhatásokat mutatják anélkül, hogy megadnák az alkalmazások végrendszereit vagy az azokban részt vevő objektumokat.

Szerkezet meghatározása.

Ez általában olyan könyvtárak vagy osztályok halmaza, amelyeket egy adott alkalmazás szabványos struktúrájának megvalósítására használnak operációs rendszer. Nagy mennyiségű újrafelhasználható kód kombinálásával a fejlesztő sok időt takarít meg, mivel megoldja azt a feladatot, hogy nagy mennyiségű szabványos kódot írjon át minden új fejlesztendő alkalmazáshoz.

Az objektumorientált tervezés következtetései (eredményei)

A szekvencia diagramot meg kell oldani a rendszer eseményeit kezelő konkrét objektumok hozzáadásához. Párhuzamos függőleges vonalak formájában mutatja be az egyidejűleg élő különböző folyamatokat, vízszintes nyilak formájában-az üzenetek cseréjét közöttük megjelenésük sorrendjében.

Egy osztálydiagramot - egy Típus statikus UML struktúra, amely leírja a rendszereket az attribútumok és a köztük lévő kapcsolatok bemutatásával. A szekvencia diagramok fejlesztésével azonosított üzenetek és osztályok bemeneti adatokként szolgálhatnak az automatikus globális rendszer létrehozása.

Néhány tervezési elv és stratégia

Gyakran használják a függőségi injekciót. Mi a fő ötlet? Ha az elem bármely más példány jelenlététől függ, akkor a szükséges be van ágyazva a függőbe. Példa az objektumorientált tervezésre: az adatbázis-kapcsolat argumentumként történő átadása a konstruktornak, ahelyett, hogy belsőleg létrehozná. Egy másik példa a hídminta felhasználásával: az absztrakció elválasztása a megvalósításától, hogy mindkét alany függetlenül megváltoztatható legyen.

Tekintsük az aciklikus függőségek objektum-orientált tervezésének elveit. Ne feledje ,hogy az összetevők grafikonja (a részletesség mértéke a munka mennyiségétől függ) nem tartalmazhat ciklusokat. Ezt irányított aciklusos gráfnak is nevezik. Példa az objektumorientált elemzésre és tervezésre: tegyük fel, hogy C függ B-től, amely alárendelt az a alanynak. Ha ez utóbbi a C-hez is kapcsolódik, akkor lesz egy hurok.

Mi az összetett újrafelhasználás elve? Előnyben részesítik a polimorf öröklési összetételt. Az elemzési szakasz után a fogalmi modellt tovább fejlesztik objektum-orientált IP-tervezéssé. Itt a technológiailag független elemzési koncepciókat implementációs osztályokhoz rendelik, korlátokat azonosítanak és interfészeket fejlesztenek ki, ami a megoldástartomány modelljét eredményezi.

Az objektumorientált IC tervezés szakaszai a következőképpen határozhatók meg:

• A rendszer kontextusának megkeresése.
• Az építészet tervezése.
• Objektumok azonosítása a rendszerben.
• Épület tervezési elrendezések.
• Objektum interfészek specifikációja.
• Tervezés.

Az objektumorientált rendszertervezés magában foglalja a kontextus meghatározását, majd az architektúra létrehozását.

Az első koncepció

A rendszer környezetének statikus és dinamikus részei vannak. Az első az objektumorientált tervezésnek köszönhetően jött létre egy egyszerű folyamatábra segítségével, amely az alrendszerek hierarchiájává bővül. Ezt a modellt UML csomagok képviselik. A dinamikus kontextus leírja, hogy a rendszer hogyan működik együtt a környezetével. A használati esetdiagramok segítségével modellezik.

A rendszer architektúráját a kontextus alapján, a tervezés elveivel összhangban, valamint a tárgyterület figyelembevételével fejlesztik ki. Általános szabály, hogy a rendszer rétegekre van osztva, és alrendszereket alkotnak.

Mi az objektum-orientált bomlás?? A bomlás azt jelenti, hogy egy nagy komplex rendszert kisebb komplexitású kisebb komponensek hierarchiájára osztunk. Minden fő részt alrendszernek neveznek. Az objektumorientált bomlás azonosítja az egyes autonóm objektumokat a rendszerben és a köztük lévő kapcsolatot.

A bomlás előnyei:

• Az egyes komponensek kevésbé összetettek, ezért érthetőbbek és kezelhetőbbek.
• A speciális készségekkel rendelkező munkaerő megoszlik.
• Ez lehetővé teszi az alrendszerek cseréjét vagy módosítását anélkül, hogy más alkatrészeket érintene.

A párhuzamosság azonosítása

Lehetővé teszi, hogy több objektum fogadjon eseményeket, és egyszerre több műveletet hajtson végre. A párhuzamosságot egy dinamikus modellben azonosítják és mutatják be.

Ennek engedélyezéséhez minden párhuzamos elemhez külön vezérlőáram tartozik. Ha a párhuzamosság az objektum szintjén van, akkor két szimmetrikus objektumhoz két különböző vezérlőáramot rendelnek. Ha egyikük két művelete párhuzamos a természetben, akkor a különböző szálak között oszlik meg.

A párhuzamosság összefügg az adatintegritási problémákkal és a holtpontokkal. Vagyis egyértelmű stratégiát kell kidolgozni, amikor párhuzamosságra van szükség. Ezenkívül már a fejlesztési szakaszban meg kell határozni, és nem lehet elhagyni a végrehajtási szakaszban.

Objektumorientált tervezési technikák, tervezési minták

Az alkalmazások fejlesztésekor néhány általánosan elfogadott megoldást fogadnak el bizonyos problémakategóriákra. Ezek például a tervezősablonok. Ez lehet meghatározni, mint egy dokumentált sor építőelemek, hogy lehet használni bizonyos típusú alkalmazás fejlesztési feladatokat.

Az objektumorientált tervezés néhány általános technikája (tervezési minták) megtalálható a tervezési mintákban:

• Homlokzati rajz.
• Szétválasztási modell megtekintése.
• Megfigyelő minta.
• A model view controller modellje.
• Proxy Sablon.
• Rendezvényszervezés.

Egy objektumorientált rendszer mintáinak tervezése során az objektumokban előforduló eseményeket ennek megfelelően kell azonosítani és feldolgozni.

Az esemény egy olyan jelentős esemény specifikációja, amelynek helye van idő és tér. Négy típus modellezhető, nevezetesen:

• Az egyik által dobott, a másik által elfogott jelnevű objektum.
• A hívásesemény egy művelet küldését jelentő szinkron esemény.
• Az idő folyamata az idő múlásával jelenik meg.
• Esemény módosítása - állapotmódosítást képviselő esemény.

Határfeltételek feldolgozása

A tervezési szakaszban figyelembe kell venni a rendszer egészének inicializálását és befejezését, valamint az egyes alrendszereket. Különböző szempontok:

• Startup,. azaz. átmenet egy nem inicializált állapotból egy stabil állapotba.
• Rendszer leállítása, t. e. az összes futó szál Bezárása, erőforrások törlése és üzenetek küldése.
• Kezdeti konfiguráció és szükség esetén újrakonfigurálás.
• Rendszerhibák vagy nem kívánt leállások előrejelzése.
• A határfeltételeket hasonló használati esetek felhasználásával modellezik.

Objektum tervezés

Az alrendszerek hierarchiájának kidolgozása után azonosítják a rendszerben lévő elemeket, és megtervezik azok részleteit. Ezen a színpad , a tervező dolgozik. A hangsúly a tárgykörről a számítógépes koncepciókra vált. Az elemzési időszak alatt azonosított objektumokat a végrehajtás érdekében kiszorítják a végrehajtási idő, a memóriafelhasználás és az általános költségek minimalizálása érdekében.

Az objektum kialakítása a következő lépéseket tartalmazza:

• Azonosítás.
• Teljesítmény. Építési tervezési modellek.
• A műveletek osztályozása.
• Tervezési algoritmus.
• Kapcsolat kialakítása.
• A külső interakciók ellenőrzése.
• Kötegelt osztályok és társítások modulokba.

Objektum azonosítása

Ez a tervezés első szakasza. Az objektumorientált elemzés periódusaiban azonosított objektumok osztályokba vannak csoportosítva, és úgy finomítják őket, hogy alkalmasak legyenek a tényleges megvalósításra.

Ennek a szakasznak a funkciói:

• Az osztályok azonosítása és finomítása az egyes alrendszerekben vagy csomagokban.
• A halmazok közötti kapcsolatok és asszociációk meghatározása.
• Hierarchia fejlesztés (általánosítás, specializáció és öröklés).
• Egységek tervezése.

Objektum Ábrázolása

Az osztályok azonosítása után modellezési technikákkal kell bemutatni őket. Ez a szakasz valójában magában foglalja az UML diagramok elkészítését.

Kétféle tervezési modellt kell előállítani:

Statikus. Osztály - és objektumdiagramokat használunk annak leírására.

Dinamikus modellek. Az interakciós és állapotdiagramokat használják az osztályok közötti kapcsolatok leírására és bemutatására.

A műveletek osztályozása

Ebben a szakaszban az alanyokon végzett feladatokat három modell kombinálásával határozzák meg: objektum, dinamikus és funkcionális. A művelet meghatározza, mit kell kell tenni, nem hogyan.

E tekintetben a következő feladatokat kell elvégezni:

• Kidolgozták a rendszer egyes objektumainak állapotainak átmeneti diagramját.
• A műveletek az elemek által fogadott eseményekre vannak meghatározva.
• Azonosított esetek, amikor egy esemény másokat okoz ugyanabban vagy egy másik objektumban.
• A műveletek alműveletei meg vannak határozva.
• Az alapvető műveletek kibővültek az adatfolyam-diagramokra.

Algoritmus fejlesztés

Az objektumok műveleteit egy sorozat segítségével határozzuk meg. Az algoritmus egy lépésenkénti eljárás, amely megoldja a műveletben felvázolt problémát. Arra összpontosítanak, hogyan kell ezt megtenni.

A műveletnek több algoritmusa is lehet. Amint meghatározzák az alternatív szekvenciákat, az optimálisat választják a problémás területre. Az algoritmus kiválasztásának mutatói:

• A számítások összetettsége. Meghatározza az algoritmus hatékonyságát, a számítási idő és a memóriaigény szempontjából.
• Rugalmasság. Ez a koncepció határozza meg, hogy a választott algoritmus megfelelően megvalósítható - e a megfelelőség elvesztése nélkül a különböző környezetekben.
• Clarity. Megmutatja, hogy a választott algoritmus könnyen érthető-e és megvalósítható-e.

Kapcsolat kialakítása

Ezt a stratégiát az objektum tervezési szakaszában kell rögzíteni. A fő kapcsolatok közé tartoznak az asszociációk, aggregációk, örökségek.

A csatlakozásokat illetően a tervezőnek a következőket kell tennie:

• Határozza meg, hogy a kapcsolat egyirányú vagy kétirányú-e.
• Elemezze az asszociációs útvonalakat, és szükség esetén frissítse őket.

Ami az örökséget illeti, a tervezőnek a következőket kell tennie:

• Konfigurálja az osztályokat és azok társításait.
• Absztrakt rendszerek definiálása.
• Hozzon létre feltételeket, hogy szükség esetén lehetőség legyen a viselkedés cseréjére.

Az ellenőrzés végrehajtása

Az objektum fejlesztője finomításokat tartalmazhat az állapotdiagram modell stratégiájában. A rendszer tervezésekor meghatározzák a dinamikus téma alapvető politikáját.

A dinamikus modell megvalósításának megközelítései:

1. Képviselje az államot mint helyet a programban.

Ez az eljárásokon alapuló hagyományos megközelítés, amelyben az ellenőrzés helye határozza meg az állapotot. A véges állapotú gép programként valósítható meg. Az átmenet képezi a bemeneti operátort, a fő vezérlőút utasítások sorozatát generálja, az ágak feltételeket hoznak létre, a visszatérési útvonalak pedig ciklusokat vagy iterációkat alkotnak.

2. A véges állapotú gép mechanizmusa.

Ez a megközelítés közvetlenül egy kifejezést képvisel az osztályán keresztül. Véges automatát hajt végre az alkalmazás által biztosított átmenetek és műveletek halmazán keresztül.

3. Menedzsment-párhuzamos feladatok.

Ezzel a megközelítéssel az objektum kérdésként kerül megvalósításra egy programozási nyelven vagy egy operációs rendszerben. Itt az esemény feladatközi hívásként valósul meg, megőrzi a valós objektumok eredendő párhuzamosságát.

Csomagolási osztályok

Bármely nagy projektben fontos, hogy a megvalósítást gondosan terjesszék modulokba vagy csomagokba. Objektumok létrehozásakor az osztályok csoportosulnak, ami lehetővé teszi több társadalom együttműködését.

A csomagolás különböző szempontjai:

1. A belső információk elrejtése a megjelenésből. Ez lehetővé teszi, hogy az osztályt "fekete dobozként" kezelje, és megváltoztassa a megvalósítást anélkül, hogy az ügyfeleknek módosítaniuk kellene a kódot.

2. Az elemek konzisztenciája. Egy rész (például egy osztály, művelet vagy modul) akkor kapcsolódik egymáshoz, ha egy elfogadott terv szerint szerveződik, és minden része elválaszthatatlan, Vagyis közös célt szolgál.

A fizikai modulok építésének alapjai:

1. Az osztályoknak hasonló dolgokat vagy összetevőket kell képviselniük ugyanabban az összetett objektumban.

2. A szorosan kapcsolódó osztályoknak egy modulban kell lenniük, a nem kapcsolódó vagy lazán csoportosított osztályokat pedig külön részekbe kell helyezni.

3. A moduloknak magas szintű interakcióval kell rendelkezniük összetevőik között.

Tervezés optimalizálása

Az elemzési modell logikai információkat gyűjt a rendszerről, a projekt összetevője pedig részleteket ad hozzá a hatékony hozzáférés támogatásához. A megvalósítás előtt a programot optimalizálni kell a kimenet hatékonyabbá tétele érdekében. A fejlesztés célja a költségek minimalizálása idő, tér és egyéb mutatók tekintetében.

A tervezés optimalizálása azonban nem lehet túlzott, mivel a megvalósítás egyszerűsége, a karbantarthatóság és a bővíthetőség szintén fontos kérdések. A gyakorlatban ez jól látható. A fejlesztők tudják, hogy a tökéletesen optimalizált kialakítás hatékonyabb, de kevésbé újrafelhasználható. Így a mesternek egyensúlyt kell találnia közöttük.

Különböző dolgok, amelyeket javítani lehet:

• Redundáns asszociációk hozzáadása.
• Kihagyja a fel nem használt csatlakozásokat.
• Algoritmusok optimalizálása.
• Származtatott attribútumok mentése az összetett kifejezések újraértékelésének elkerülése érdekében.

Nézzünk néhány pontot részletesebben.

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

A projekt optimalizálása során ellenőrzik, hogy az új szakszervezetek létrehozása csökkentheti-e a hozzáférési költségeket. Bár ezek a redundáns asszociációk nem adhatnak információt, javíthatják az Általános modell hatékonyságát.

A fel nem használt szakszervezetek kizárása.

Ha túl sok asszociáció van, a rendszer megfejthetetlenné válhat, és csökkentheti az általános hatékonyságot. Vagyis az optimalizálás során az összes fel nem használt szakszervezet törlődik.

Algoritmusok fejlesztése.

Objektumorientált rendszerekben az adatszerkezet optimalizálása együttműködés alapján történik. Az osztályprojekt létrehozása után javítani kell a műveleteket és az algoritmusokat.

Optimalizálás érhető el:

• A számítási problémák sorrendjének permutációi.
• Változások a ciklusok végrehajtásának sorrendjében.
• Halott utak eltávolítása az algoritmusban.
• Származtatott attribútumok mentése.