Objektumorientált elemzés és tervezés

A Wikipédiából, a szabad enciklopédiából

Az objektumorientált elemzés és tervezés (Object-oriented analysis and design, OOAD) az alkalmazás vagy rendszer elemzésének és tervezésének technikai megközelítése objektumorientált programozás alkalmazásával, valamint vizuális modellezés használatával a szoftverfejlesztési folyamat során az ügyfelekkel folytatott kommunikáció és a termékminőség írányának meghatározására.

A modern szoftverfejlesztésben az OOAD rendszerint iteratív és növekményes módon történik. Az OOAD tevékenységek kimeneti eredményei az objektumorientált elemzési modellek (OOA-hoz), illetve az objektumorientált tervezési modellek (OOD-hoz). Ezeknek a folyamatos finomítása és fejlesztése a cél, olyan kulcstényezők mentén, mint a kockázat és az üzleti érték.

Története[szerkesztés]

Az objektumorientált technológia korai napjaiban, az 1990-es évek közepe előtt a szoftverfejlesztésben és az objektumorientált modellezésben számos versengő módszer létezett, amelyek gyakran számítógéppel segített szoftverfejlesztési (CASE) eszközök részeihez kapcsolódtak. A szabványosított jelölések, a következetes kifejezések és a folyamatot jelző mutatók hiányossága jelentette akkoriban a legnagyobb gondot, ez rontotta a kommunikációs hatékonyságot és növelte a görbék megértéséhez szükséges időt.

Számos, még ma is jól ismert korai objektumorientált módszerek némelyike olyan szakértőktől származott és ihlette őket, mint Grady Booch, James Rumbaugh, Ivar Jacobson (the Three Amigos – a Három Barát), Robert C. Martin, Peter Coad, Sally Shlaer, Stephen J. Mellor és Rebecca Wirfs-Brock.

1994-ben a Három Barát elkezdett együtt dolgozni a Unified Modeling Language (UML) fejlesztésén. Később Philippe Kruchtennel és Walker Royce-szal (Winston Royce legidősebb fia) egy sikeres útra léptek azzal, hogy saját módszereiket, az OMT-t, az OOSE-t és a Booch-módszert egyesítsék más iparági vezetők különböző ötleteivel és tapasztalataival a Rational Unified Process-ba. (RUP). Szeleskörűen iteratív, növekvő folyamatútmutatókkal rendelkezik, egy keretrendszert is tartalmaz a szoftverfejlesztés és projektmenedzsment legjobb iparági gyakorlatainak megismeréséhez. Azóta a Unified Process család valószínűleg az objektumorientált elemzés és tervezés legnépszerűbb módszertanává és referenciamodelljévé vált.

Áttekintés[szerkesztés]

A vízesésmodell

A szoftver jellemzően életciklus-szakaszokra tagolódik, amelyek a probléma absztrakt leírásától a tervezésig, majd a kódolásig, tesztelésig és végül a telepítésig terjed. Ennek a folyamatnak a legelső szakasza az elemzés, majd ezt követi a tervezés. Az elemzési fázist gyakran „követelményfelmérésnek” is nevezik.

Az OOAD iteratív és folyamatosan növekvő módon történik, az egységes folyamat által megfogalmazott módon

A szoftverfejlesztés egyes megközelítéseiben – amelyeket összefoglaló néven vízesés-modelleknek neveznek – a szakaszok közötti határok meglehetősen merevek és sorrendjük nem változtatható. A vízesés kifejezést az ilyen módszerekre alkották meg, hogy jelezzék, hogy a folyamatoknak csak egy iránya van és azok sorrendje meghatározott, azaz amikor az elemzés befejeződik, és csak akkor kezdhetik el a tervezést, és ritka volt (és hibaforrásnak tekintették), amikor tervezési probléma merült fel és az módosítást igényelt az elemzési modellben, vagy amikor egy kódolási probléma miatt a tervezést kellett módosítani.

A vízesésmodellek alternatívái az iteratív modellek. Ezt a megkülönböztetést Barry Boehm népszerűsítette az iteratív szoftverfejlesztés spirálmodelljéről (Spiral Model for iterative software development) szóló igen befolyásos tanulmányában. Az iteratív modelleknek köszönhetően párhuzamosan lehet dolgozni a modell különböző szakaszaiban. Így például lehetséges – és nem tekintik hibaforrásnak –, hogy ugyanazon a napon dolgozzunk az elemzésen, a tervezésen, sőt a kódoláson is, és az egyik szakaszban esetlegesen felmerülő probléma hatással van egy másik szakasz problémájára. Az iteratív modellek esetében a hangsúly az, hogy a szoftverfejlesztés tudásintenzív folyamat, és hogy az olyan dolgokat, mint az elemzés, nem igazán lehet teljesen megérteni a tervezési problémák megértése nélkül, valamint hogy a kódolási problémák hatással lehetnek a tervezésre, továbbá hogy a tesztelés információkat szolgáltathat arról, hogy a kód vagy akár a tervezést hogyan kell módosítani.

Bár lehetséges objektumorientált fejlesztést végezni vízesésmodell segítségével, azonban a gyakorlatban a legtöbb objektumorientált rendszert iteratív módon fejlesztik le. Ennek eredményeként az objektumorientált folyamatokban az "elemzést és a tervezést" gyakran egyszerre veszik figyelembe a fejlesztés során.

Az objektumorientált paradigma a modularitást és az újrafelhasználhatóságot hangsúlyozza ki. Az objektumorientált megközelítés célja a nyílt/zárt elv kielégítése. Egy modul akkor nyitott, ha támogatja a bővítést, vagy ha a modul szabványosított módokat biztosít új viselkedések hozzáadására vagy új állapotok leírására. Az objektumorientált paradigmában ezt gyakran egy meglévő osztály új alosztályának létrehozásával érik el. Egy modul akkor zárt, ha rendelkezik egy jól meghatározott stabil interfésszel, melyet az összes többi modulnak használnia kell, és amely korlátozza a kölcsönhatásokat és a lehetséges hibákat, amelyek az egyik modulba jelentkezve a másik modulban történő változtatások idézhetnek elő. Az objektumorientált paradigmában ezt olyan metódusok meghatározásával érik el, amelyek szolgáltatásokat hívnak meg az objektumokon. A metódusok lehetnek nyilvánosak vagy privátok, azaz, az objektumra jellemző viselkedések nincsenek kitéve más objektumoknak. Mindezek nagy mértékben csökkentik a számítógépes programozásban felbukkanó gyakori hibák forrását.

A szoftver jellemzően életciklus szakaszokra tagolódik, amelyek a probléma absztrakt leírásától a tervezésig, majd a kódolásig, tesztelésig és végül a telepítésig terjed. Ennek a folyamatnak a legelső szakasza az elemzés, majd ezt követi a tervezés. Az elemzés és a tervezés közötti különbséget gyakran úgy írják le, hogy "mit vs. hogyan". Az elemzés fejlesztők a felhasználókkal és a szervezeti szakértőkkel együttműködve határozzák meg, mit kell tennie a programnak. A megvalósítás részleteit ebben a szakaszban nagyrészt vagy teljesen figyelmen kívül kell hagyni (az adott módszertől függően). Az elemzési szakasz célja a rendszer funkcionális modelljének megalkotása, függetlenül olyan korlátoktól, mint a megfelelő technológia. Az objektumorientált elemzésben ez jellemzően a használati eseteken (use case) és a legfontosabb objektumok absztrakt definícióin keresztül történik. A következő tervezési szakasz az elemzési modellt finomítja, és megalkotja a szükséges technológiát és egyéb megvalósítási lehetőségeket. Az objektumorientált tervezésben a hangsúly a különböző objektumok létrehozásán van és azok adatainak, viselkedéseinek és interakcióiknak meghatározásán. A tervezési modellnek tartalmaznia kell az összes szükséges részletet, hogy a programozók implementálni tudják a tervezést a kódban.

Objektumorientált elemzés[szerkesztés]

A szoftver életciklusában végzett bármilyen elemzési tevékenység célja egy olyan modell létrehozása a rendszer funkcionális követelményeiről, ami független a implementációs megkötésektől.

A legfontosabb különbség az objektumorientált elemzés és az egyéb elemzési formák között, hogy az objektumorientált megközelítésben olyan objektumok köré szervezzük az igényeket, amelyek a viselkedéseket (folyamatokat) és az állapotokat (adatokat) is integrálja a tényleges világból származó objektumok alapján, amikkel a rendszer kölcsönhatásba lépett. A hagyományos elemzési módszertanokban a két szempontot: a folyamatokat és az adatokat külön-külön veszik figyelembe. Például az adatok modellezhetők ER diagramokkal, a viselkedések pedig folyamatábrákkal vagy szerkezeti diagramokkal.

Az OOA-ban használt két általános modell a használati esetek (use cases) és az objektummodellek (object models). A használati esetek olyan forgatókönyveket írnak le a szabványos szakterületi funkciókhoz, amelyeket a rendszernek végre kell hajtania. Az objektummodellek leírják a neveket, osztálykapcsolatokat (például a kör az alakzatok egy alosztályába tartozik), műveleteket és a fő objektumok tulajdonságait. A felhasználói felület prototípusa is létrehozható a megértés segítése érdekében.

Objektumorientált tervezés[szerkesztés]

Az objektumorientált tervezés (OOD) során a fejlesztő implementációs megszorításokat alkalmaz az objektumorientált elemzésben előállított fogalmi modellre. Ilyen korlátozások lehetnek a hardver- és szoftverplatformok, a teljesítménykövetelmények, a tartós tárhely, a tranzakciók, a rendszer használhatósága, valamint a költségvetés és az idő miatti korlátok. A technológiafüggetlen elemzési modellben szereplő fogalmak implementációs osztályokra és interfészekre vannak leképezve, ami a megoldási szakterület modelljét eredményezi, tehát egy részletes leírás ad arról,hogy a rendszer milyen konkrét technikákra épülve jöjjön létre.

Az OOD során felmerülő fontos témakör még a szoftverarchitektúrák tervezése is, ami az architekturális minták és tervezési minták objektumorientált tervezési elvekkel történő alkalmazásával hozható létre.

Objektumorientált modellezés[szerkesztés]

Az objektumorientált modellezés (OOM) az alkalmazások, rendszerek és vállalati szakterületek modellezésének általános megközelítése az objektumorientált paradigma használatával a fejlesztés teljes életciklusa során. A modern szoftverfejlesztésben az OOM egy meghatorózó fő technika, melyet az OOD és az OOA tevékenységei erősen használnak.

Az objektumorientált modellezés jellemzően a munka aspektusának két részére bomlik szét: a dinamikus viselkedések, például az üzleti folyamatok és a használati esetek (use case) modellezésére, valamint a statikus struktúrák, például osztályok és komponensek modellezésére. Az OOM (objektumorientált modellezés) során az OOA (elemzési szint) és az OOD (tervezési szint) két különálló absztrakt szint. A Unified Modeling Language (UML) és a SysML az objektumorientált modellezéshez használt két legnépszerűbb nemzetközi szabványos nyelv.

Az OOM előnyei a következők:

Hatékony és eredményes kommunikáció

A felhasználóknak általában nehézséget okoz az anyagot teljesen átkaroló dokumentumok és a programozási nyelvi kódok pontos megértése. A vizuális modelldiagramok könnyebben érthetőek, és lehetővé teszik a felhasználók és a megrendelők számára, hogy visszajelzést adjanak a fejlesztőknek a rendszer megfelelő követelményeiről és felépítéséről. Az objektumorientált megközelítés kulcsfontosságú célja a rendszer és a valós világ közötti "szemantikai szakadék" csökkentése, valamint az, hogy a rendszer olyan terminológiával épüljön fel, amely szinte megegyezik az ügyfelek által a mindennapi üzleti életben használt szaknyelvvel. Ennek elengedhetetlen eszköze az objektumorientált modellezés használata.

Hasznos és stabil absztrakció

A kódolást nagyban segíti a modellezés. A legtöbb modern szoftvermódszer célja, hogy először a „mit” kérdésekkel foglalkozzon, majd a „hogyan” kérdéseket válaszolja meg. Más szavakkal először határozza meg a rendszer által biztosított funkcionalitást a megvalósítási korlátok figyelembevétele nélkül, majd fontolja meg, hogyan lehet konkrét megoldásokat készíteni ezekre az elvont követelményekre, és finomítsa azokat részletes tervekké és kódokká olyan megszorítások alapján, mint a technológia és a költségvetés. Az objektumorientált modellezés elérhetővé teszi ezeket azzal, hogy absztrakt és hozzáférhető leírásokat készít a rendszerkövetelményekről és a tervekről, mármint olyan modelleket hoz létre, amelyek meghatározzák alapvető struktúráikat és viselkedésüket, például a folyamatokat és az objektumokat, amelyek fontos és értékes fejlesztési eszközök, amik magasabb absztrakciós szinttel rendelkeznek, mint a konkrét és az egész összetett forráskód.

Jegyzetek[szerkesztés]

További információk[szerkesztés]

Kapcsolódó szócikkek[szerkesztés]

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Objektumorientált_elemzés_és_tervezés&oldid=26227195”