Tantermi tervezési ajánlás
A tervezési osztály egy vagy több osztály absztrakcióját mutatja be a rendszer megvalósításában; A pontos tárgy, amelyhez megfelel, függ a végrehajtási nyelvtől. Például olyan objektumorientált nyelvben, mint a C ++, a tervezési osztály egy egyszerű osztálynak felelhet meg. Az Ada nyelvben egy osztály megfelelhet a csomag látható részében meghatározott speciális típushoz.
Az osztályok objektumokat definiálnak. amelyek viszont alkalmazzák a használati eseteket. Az osztály a rendszerobjektumok használati esetek implementációjának, valamint az összes korábban kifejlesztett objektummodellnek a követelményein alapul.
Az osztály sikere nagyban függ a végrehajtási környezettől. Például az osztály és annak objektumainak helyes mérete függ a programozási nyelvtől. A Hell nyelvén megfelelőnek tűnhet, hogy a Smalltalk nem lesz sikeres. Az osztályokat egy adott jelenségre kell leképezni a végrehajtási nyelvben, és az osztály szerkezetének olyannak kell lennie, hogy az eredmény jó kód legyen.
Bár a végrehajtási nyelv jellemzői befolyásolják a tervezési modellt, biztosítani kell, hogy az osztály struktúrája könnyen érthető és módosítható legyen. Az osztályt úgy kell kifejleszteni, mintha osztályokat és beágyazódást lehetett volna végezni, bár a végrehajtási nyelvben nem támogatott.
Az egyetlen lehetőség, hogy a tárgyak elérhessék vagy befolyásolhassák egy adott objektum attribútumait vagy kapcsolatait, kihasználják működésének előnyeit. Egy objektum műveletét az osztály határozza meg. A műveletek lehetővé teszik, hogy olyan konkrét viselkedést hajtson végre, amely befolyásolhatja az objektum attribútumait és kapcsolatait, és más műveletek végrehajtását eredményezheti. A művelet egy tagfüggvénynek felel meg a C ++-ban és egy függvényben vagy eljárásban az Ada nyelvben. Az objektumhoz hozzárendelt viselkedés attól függ, hogy milyen szerepet tölt be a felhasználási eset megvalósításában.
A műveleti specifikációban a paraméterek formális paraméterek. Minden paraméternek van egy neve és egy típusa. A műveletek és azok paramétereinek meghatározásához használhatja a végrehajtási nyelv szintaxisát és szemantikáját, ezért ezek a műveletek és paraméterek a végrehajtás nyelvén már a kódolás megkezdésekor kerülnek meghatározásra.
Az újrahasznosító berendezés rendszerében az "Átvételi alap" osztály objektumai monitorozzák, hogy hány tétel van az ügyféllel. A fogadó alap objektum magatartása magában foglalja a visszaküldött objektumok számának növelését. Ezt a műveletet az insertItem művelet végzi. amely az objektumra utal.
Műveletek meghatározásakor használja a végrehajtási nyelv szintaxisát és szemantikáját.
A művelet majdnem mindig meghatározza az objektum viselkedését. Egy művelet megadhatja az osztály viselkedését is - ebben az esetben osztályműveletnek nevezik. Ezt az UML-ben lehet modellezni a művelet megfelelő hatókörének megadásával.
A művelet a következő területekre terjedhet ki:
- Nyilvánosan elérhető. A műveletet a modell összes eleme látja, kivéve magát az osztályt.
- Biztonságos. a műveletet csak az osztály, alosztályai és barátai látják (különböző nyelveken lehetnek különböző nevek)
- Private. A műveletet csak az osztály maga és barátai látják
- Realizálható. A művelet csak az osztályon belül látható.
Kivételes esetekben közszférát kell alkalmazni. Csak akkor, ha a művelet egy másik osztályhoz szükséges.
A védett hatókört alapértelmezésben kell használni; megvédi a műveletet a külső osztályoktól való használattól, ami elősegíti a gyenge kötődést és a magatartás beágyazódását.
Magától értetődően alkalmazni kell, ha meg akarjuk akadályozni egy művelet örököltségét származtatott osztályokkal. Ez lehetővé teszi, hogy a származtatott osztályokat elválasszuk az alaposztályoktól, és kevesebb erőfeszítést fordítsunk a nem használt öröklött műveletek eltávolítására vagy megszüntetésére.
A megvalósítási terület a legszigorúbb; Olyan esetekben használják, amikor maga a művelet csak az osztály által használható. Ez egyfajta magánszemély. ami elégséges a legtöbb esetben.
Egy objektum válaszolhat az üzenetre különböző módon, attól függően, hogy milyen állapotban van; Az objektum viselkedését az állam függvényében a hozzárendelt állapotdiagram határozza meg. Az objektum minden lehetséges állapotára vonatkozóan az állapotdiagram azt írja le, milyen üzeneteket fogadhat az objektum, milyen műveleteket fog végrehajtani, és azt, hogy az objektum milyen állapotban mozog. További információért lásd: Technológia: állapotdiagram.
Együttműködés egy dinamikus objektumközi kölcsönhatás, amelyben az objektumok információcserét küld egymásnak küldött üzenetek elküldésével. Az üzenetet közvetlenül a Smalltalkra küldi, és felhívja az Ada alprogramját. Az üzenet a fogadó objektumra kerül, amely elindítja a belső műveletet. Az üzenet jelzi az elvégzendő művelet nevét és a szükséges paramétereket. Ha minden paraméterre üzenetet küld, az aktuális paraméterek (formális paraméterértékek) vannak megadva.
Üzenetek továbbítása az objektumok között a felhasználási eset végrehajtásakor Az objektumok közötti átkapcsolás a műveletek elindításaként az interakciós diagramokban található meg. Az ábrákról lásd: Technológia: Sequence Diagram and Technology: Kommunikációs diagram.
Az attribútum egy objektum megnevezett tulajdonsága. Az attribútumnév egy olyan főnév, amely egy attribútum szerepét írja le egy objektumra vonatkozóan. Az attribútumnak kezdõ érték lehet egy objektum létrehozásakor.
Csak akkor szimulálja az attribútumokat, ha egyszerűsíti az objektum megértését. Ha egy objektum tulajdonság mint attribútumot modellez, akkor csak akkor következik, ha ez a tulajdonság csak erre az objektumra vonatkozik. Ellenkező esetben a tulajdonságot egy olyan társulási vagy aggregációs kapcsolattal kell modelleznie, amelyik objektumot képviseli az adott tulajdonsággal.
Nem mindig könnyű azonnal eldönteni, hogy a koncepciót külön objektumként vagy egy másik objektum attribútumaként kell-e modellezni. A felesleges objektumok hozzáadása a modellhez túlterheli a dokumentációt és növeli a munka mennyiségét. Emiatt meg kell állapítania a rendszer koncepciójának fontosságát meghatározó kritériumokat.
- Kész. Az objektum és az attribútum közötti választást nem a koncepció valós életben való fontossága, hanem a használati eset végrehajtása során való hozzáférés szükségessége határozza meg. Ha az elemhez való hozzáférés gyakori, akkor objektumként modellezzük.
- Az elkülönítés futás közben. Amikor a használati eseteket objektumokként végzik el, a modellkoncepciókat külön kezelik.
- Kapcsolatok más fogalmakkal. A modell fogalmai szorosan kapcsolódnak más fogalmakhoz és soha nem használják külön-külön, de mindig közvetve az objektumon keresztül, mint az objektum attribútuma.
- A kapcsolat követelményei. Ha valamilyen oknál fogva kapcsolatba kell hoznia egy elemet két irányból, akkor ellenőrizze újra, hogy kiderüljön-e, hogy különálló objektum legyen. Két objektum nem társíthatja az attribútumtípus egy példányát.
- A megjelenés gyakorisága. Ha az elem csak a futásidő alatt létezik, akkor ne objektumként formázzuk. Modellelje azt mint objektum attribútumát, amely végrehajtja a kívánt viselkedést, vagy egyszerűen adja meg a megfelelő objektum leírásában.
- Komplexitás. Ha az objektum attribútumai miatt túl bonyolultvá válik, átruházza az attribútumok egy részét más objektumokra. Nézzétek azonban, hogy nincs túl sok ilyen tárgy. Másrészt az elemek nagyon egyszerűek lehetnek. Például, a kategóriába attribútumok tartalmazzák 1) elemek elég egyszerű közvetlenül támogatott legegyszerűbb típusai a végrehajtás nyelven, például egészek C ++, és 2) elemek, amelyek elég egyszerű megvalósítani független alkalmazás komponensek végrehajtása környezetben, például , String a C ++-ban és a Smalltalk-80-ban.
A különböző rendszerekben a fogalom másképpen modellezhető. Az egyik rendszerben a koncepció olyan fontos lehet, hogy objektumként jobban modellezhető. A másikban másodlagos szerepet játszhat, és jobb, ha azt mint objektum attribútumát modellezzük.
Például egy légitársaságnak tervezett rendszernek támogatnia kell az indulást.
Az indulási járatokat támogató rendszer. Engedje meg a repülőtéri személyzetnek, hogy támogassa az indulás indulását. Minden induláskor meg kell határozni az indulási időt, a repülést és a rendeltetési helyet. Ezt az indulási osztály objektumával lehet modellezni az indulási idő attribútumaival. repülés és rendeltetési hely.
Ha a rendszert egy utazási iroda számára tervezték, a helyzet némileg eltérhet.
A járatok célállomásai saját célt szolgálnak - Úti cél.
Természetesen az indulás, a repülés és a célállomás ideje is szükségessé válik. Azonban a követelmények eltérőek lesznek, mivel az utazási iroda érdekel a repüléshez a meghatározott célállomásra. Ezért különálló objektumot kell létrehoznia a célállomásra. Tárgyak Indulás és rendeltetési hely. természetesen tisztában kell lennie egymással, amelyhez az egyes osztályok között létrejön egy társulás.
Az osztályban meghatározandó attribútumok kiválasztásakor figyelembe kell venni bizonyos fogalmak fontosságát. Az autó kategóriájának jellemzői. kétségkívül más lesz, attól függően, hogy a tárgyai a jármű regisztrációs rendszerének vagy az autógyárak rendszerének részét képezik-e.
Végül a szabályokat, amelyek meghatározzák, hogy mit kell objektumként ábrázolni, és mi, mint attribútumok, nem abszolút. Elméletileg mindent objektumként lehet modellezni, de ez túl megterhelõ. Egy egyszerű szabály az, hogy egy objektumot olyan tárgyaként kezelünk, amelyeket egy adott szakaszban más objektumokra való utalás nélkül használunk. Ezenkívül nem szükséges az objektum minden tulajdonságának az attribútummal történő modellezése - elég csak az objektum megértéséhez szükséges tulajdonságok szimulálása. Nem kell a részlethez szorosan kapcsolódó részleteket modellezni: a fejlesztőnek kell maradnia.
Osztályjellemzők
Az attribútum szinte mindig meghatározza az objektum tulajdonságait. Egy attribútum megadhatja az osztály tulajdonságait is - ebben az esetben osztálytulajdonságnak hívják. Ezt az UML-ben lehet modellezni az attribútum megfelelő hatókörének megadásával.
Egy objektum beágyazhat egy elemet, amelynek értéke változhat az objektum viselkedésétől függetlenül. Ez lehet valami, ami valójában egy külső elem, de nem mint egy téma. Például hagyja a rendszer határait úgy választani, hogy az érzékelőberendezés a határaikon belül maradjon. Az érzékelő ezután beilleszthető egy objektumba, így az általa mért érték generál egy attribútumot. Ezt követően ez az érték folyamatosan vagy időszakosan változhat, függetlenül attól, hogy ez az objektum befolyásolja-e a rendszer bármely más objektumát.
A hőmérőt objektumként lehet modellezni; az objektumnak a hőmérsékletnek megfelelő attribútummal kell rendelkeznie, és értéke megváltozik a környezeti hőmérséklet megváltozása miatt. Más objektumok lekérdezhetik az aktuális hőmérsékletet a hőmérő objektumon végzett művelet végrehajtásával.
Az attribútum hőmérséklet értéke spontán változik a tárgy hőmérőben.
Továbbra is szimulálhat egy kapszulázott értéket, amely ilyen módon változik normál attribútumként, de meg kell adnia az objektumosztályban, hogy spontán változik.
Az attribútumnak a következő területei lehetnek:
- Nyilvánosan elérhető. egy attribútum látható az osztályt tartalmazó csomagon belül és kívül is.
- Biztonságos. az attribútumot csak az osztály maga, alosztályai és barátai látják (különböző nyelveken lehetnek különböző nevek)
- Private. csak az osztályt tulajdonolja és barátai látják
- Realizálható. csak az osztály maga látja az attribútumot.
A védett hatókört alapértelmezésben kell használni; megvédi az attribútumot a külső osztályoktól való használattól, ami megkönnyíti a gyenge kötési és beágyazási viselkedést.
Egy adott hatókört kell használni, ha el szeretné kerülni az attribútum öröklését származtatott osztályokból. Ez lehetővé teszi, hogy a származtatott osztályokat elválasszuk az alaposztálytól, és kevesebb erőfeszítést fordítsunk arra, hogy eltávolítsuk vagy megszüntessük a fel nem használt öröklődő attribútumokat.
A megvalósítási terület a legszigorúbb; Olyan esetekben használják, ahol az attribútum csak az osztály által használható. Ez egyfajta magánszemély. ami elégséges a legtöbb esetben.
Egyes osztályok összetett absztrakciókat képviselhetnek, összetett szerkezettel rendelkeznek. Az osztály modellezése során a tervező bemutathatja belső résztvevő elemeit és azok összefüggéseit, hogy megbizonyosodjon arról, hogy a megvalósító helyesen hajtja végre az ebben az osztályban folytatott együttműködést.
Az UML 2.0-ban az osztályok strukturált osztályok. amely lehet belső szerkezete és kikötői. Az osztályokat fel lehet bontani olyan összekapcsolt alkatrészek készleteire, amelyek szintén lebomlanak. Egy osztály beágyazható a külső forrásokból érkező kommunikációnak a deklarált interfészek alá tartozó távoli összeköttetésekhez való átvitelével.
Így a klasszikus diagramok osztály osztályok (pl. Egyesületek, kompozíciók és aggregációk) és attribútumok megjelenítésén túl a tervező összetett szerkezeti diagramot is alkalmazhat. Ez a diagram lehetővé teszi a fejlesztő számára annak bemutatását, hogy a belső részek milyen esetekben játszanak szerepüket egy adott osztály egy példáján.
A témával kapcsolatos további információk és az összetett struktúrák diagramjait lásd: Koncepció: Strukturált osztály.