Objektum orientált software fejlesztés (Bevezetés)

Miskolci Egyetem Általános Informatikai Tanszák

Objektum orientált software fejlesztés (Bevezetés) Ficsor Lajos Miskolci Egyetem Általános Informatikai Tanszék

Út az objektum orientált szemléletig 1. Klasszikus módszerek: program = adatszerkezetek + algoritmusok Alapkérdés: mi legyen a strukturálás alapja? 1. Processz alapú módszerek (top-down) A struktúrálás alapja a függvény. Példa: strukturált analízis és tervezés SADT Ficsor Lajos

Objektum orientált software fejlesztés

OOSE /

2

Út az objektum orientált szemléletig 2. Hiányosságai: nem veszi figyelembe a software "fejlődő" természetét feltételezi, hogy van "top" (eseményvezérelt rendszer?) háttérbe szorul a program adatszerkezete nem "termel" újrafelhasználható elemeket. Jó a kis-közepes rendszerek esetén illetve a tervezés tanulása során. Ficsor Lajos

Ficsor Lajos


OOSE /

3

OOSE / 1


Út az objektum orientált szemléletig 3. 2. Adat alapú tervezési módszerek A struktúra alapja az adatszerkezet. Példa: Jackson módszer, SSADM Sajátosságai: rugalmasabb, inkább biztosít újrafelhasználható elemeket jobban segíti a program módosítását. Ficsor Lajos


OOSE /

4

Út az objektum orientált szemléletig 4. 3. Hibrid módszerek Példa: strukturált programozás (Dijsktra) Megpróbálja párhuzamosan finomítani az adatés függvénystruktúrát. Hátrány: ez is top-down módszer.

Ficsor Lajos


OOSE /

5

Objektum orientált fejlesztés alapelve 1 Az adatalapú fejlesztési módszerekből nőtt ki. Program: egymással kommunikáló objektumok halmaza. Struktúra: az osztályok közötti reláció Viselkedés: az objektumok közötti üzenetváltások

Ficsor Lajos

Ficsor Lajos


OOSE /

6

OOSE / 2


Objektum orientált fejlesztés alapelve 2 A programkészítés folyamatát modellkészítésnek tekintjük. Bertrand Meyer-től származó definíció: Software rendszerek felépítése absztrakt adattípusok implementációinak strukturált együtteséből.

Ficsor Lajos


OOSE /

7

Az OO modell előnyei áttekinthetőség nem kell informatikusnak lennie az olvasónak, így alkalmas a megrendelővel történő egyeztetésre könnyen módosítható, átstrukturálható, kiegészíthető az elvi modell könnyen transzformálható implementációs modellé Ficsor Lajos


OOSE /

8

Az OO szemlélet absztrakciós eszköz Az objektum: egyediséggel rendelkező diszkrét entitás jellemzői: attribútumok, műveletek attribútum együttes: objektum állapot, ennek időbeli változása az objektum viselkedése műveletek(operations): implementálva módszernek (method) hívjuk Ficsor Lajos

Ficsor Lajos


OOSE /

9

OOSE / 3


OO absztrakció (folytatás) objektumok közötti interakciók: (message passing, event generating) üzenet(message), esemény (event) (lehet szintén objektum!) csak biztosított interface-en keresztül történhet. a műveletek valósítják meg Ficsor Lajos


OOSE /

10

OO absztrakció (folytatás) Példányosítás Általánosítás és pontosítás Kifizetés kifiz dátuma végösszeg

Kp kifizetés kiad biz.

Ficsor Lajos

Átutalásos kfizetés pénzf. jelzõszám


OOSE /

11

OOSE /

12

OO absztrakció (folytatás) Polimorfizmus Alakzat forgatás()

Kör

Elipszis

forgatás()

forgatás()

Ficsor Lajos

Ficsor Lajos


Téglalap forgatás()

OOSE / 4


OO absztrakció (folytatás) Absztrakt osztály (csak interfészt specifikál) Paraméterezett osztály (osztályok mintája)

Ficsor Lajos


OOSE /

13

OO szemlélet absztrakciós eszközei

Ficsor Lajos


OOSE /

14

Objektum orientált technológiák programnyelvek (OOP) software tervezés (OOD) software specifikáció (OOA) software követelmény analízis (OORA) adatbázisok (OODBMS) interaktív felhasználói felületek (GUI) osztott rendszerek (CORBA, DCOM, RMI)

Ficsor Lajos

Ficsor Lajos


OOSE /

15

OOSE / 5


OORA Formális módszerekkel a legkevésbé ellátott terület. A legutóbbi időkre tehető a próbálkozás ilyen módszerek kidolgozására.

Ficsor Lajos


OOSE /

16

OOA 1. A rendszer megkívánt viselkedésének leírása. Felfedezzük a problématér (domain) lényeges osztályait, illetve objektumait és kapcsolataikat, a követelmény analízis felhasználásával. Pl. egy repülőgépes helyfoglaló rendszerben ilyenek lesznek Járat, Jegy, Utas, Légitársaság, Operátor stb Ficsor Lajos


OOSE /

17

OOSE /

18

OOA 2. Osztály (vagy objektum) lehet: esemény (helyfoglalás) szerep (utas) szervezeti egység (légitársaság) (al)rendszer (repülőgép) process (járat, azaz repülés egyik helyről a másikra) hely (célállomás) eljárás, függvény Ficsor Lajos

Ficsor Lajos


OOSE / 6


OOD 1. Feladata megtalálni és kiválasztani a megoldási tér osztályait és objektumait, azok viszonyait és együttműködésük módját A megoldási tér osztályai – problématér osztályainak a leképezései – a megoldás céljából a tervező által létrehozott osztályok

Ficsor Lajos


OOSE /

19

OOD 2. Az analízis és a tervezési fázis nem válik el élesen az OOSD-ben! A fejlesztés az inkrementális életciklus modellt (fejlesztési stratégiát) használja, és iteratív jellegű. Egy lépés (iteráció), amely egyre részletesebb absztrakciós szinten ciklikusan ismétlődik: Ficsor Lajos


OOSE /

20

OOD 3. Start

Stop

Objektumok (és osztályaik) azonosítása

Az osztályok, kapcsolatok és operációk implementálása

Statikus struktúra kialakítása (Osztályok és kapcsolataik definiálása)

Modell értékelése

Dinamikus struktúra kialakítása (Processek és operációk definiálása) Ficsor Lajos

Ficsor Lajos


OOSE /

21

OOSE / 7


OOD 4. A folyamat akkor ér véget, ha nem szükséges további absztrakciós szint a felfedezett osztályok és objektumok már létező (újrahasznosítható) software komponensek kombinációival implementálhatók

Ficsor Lajos


OOSE /

22

OOSE /

23

OOD 5. Lehetséges absztrakciós szintek: problématér réteg (ez mindig van!) felhasználói interface réteg file-rendszer réteg processz management réteg adatbáziskezelő réteg eszköz interface réteg stb. Ficsor Lajos


A modellalkotás modellalkotás alapproblémái A fejlesztés alapvető problémái: A fejlesztendő rendszer komplex, tehát a modellje is az. Biztosítani (és ellenőrizni) kell, hogy a modell valóban a megoldandó feladatot reprezentálja. Megoldási lehetőségek: Inkrementális és iteratív fejlesztés Modell nézetek Ficsor Lajos

Ficsor Lajos


OOSE /

24

OOSE / 8


Inkrementum, iteráció Nem egyszerre építjük fel a teljes modellt (inkrementális életciklus modell) Ha szükséges, még az inkrementumok felépítését is részekre (iterációkra) osztjuk. Előnyök: Egyszerre viszonylag egyszerű feladatot kell megoldani Gyakori részeredmény, amely ellenőrizhető Ficsor Lajos


OOSE /

25

Nézetrendszer 1. Nem egy modellt készítünk el, hanem a rendszer különböző nézőpontú modelljeit Előnyök A rendszer egyszerűbben átlátható, ha egyszerre csak egy adott nézőpontból kell vizsgálni. A különböző nézőpontból készített modellek összevethetők, és a modell helyességének ellenőrzésére használhatók fel. Ficsor Lajos


OOSE /

26

OOSE /

27

Nézetrendszer 2. Nézőpontok: Problématér – Használati nézet

Megoldási tér – Strukturális, statikus nézet – Dinamikus nézet – Implementációs nézet – Környezeti nézet

Ficsor Lajos

Ficsor Lajos


OOSE / 9


Használati nézet A rendszer a felhasználó nézőpontjából Ezt a modellt a követelmény analízis és a specifikációs fázis állítja elő Ez tekinthető a problématér modelljének

Ficsor Lajos


OOSE /

28

OOSE /

29

Strukturális, statikus nézet A rendszer egységei és azok kapcsolata A megoldási tér osztályai, objektumai

Ficsor Lajos


Dinamikus nézet A rendszer egyes részeinek (objektumainak) viselkedése a működés során. – A részek lehetséges állapotai – Milyen események következtében megy egyik állapotból a másikba – Az üzenetküldések sorozata (időben) – Egy adott állapotban végrehajtandó tevékenységsor Ficsor Lajos

Ficsor Lajos


OOSE /

30

OOSE / 10


Implementációs nézet A megoldáshoz szükséges szoftver elemek, és azok kapcsolatai

Ficsor Lajos


OOSE /

31

Környezeti nézet A rendszer működéséhez szükséges hardware és software erőforrások, és ezek kapcsolatai

Ficsor Lajos


OOSE /

32

Objektum orientált módszerek 1. A módszerek részei: lépések (fázisok) leírása (feladatok és eredményeik) jelölésrendszer fejlesztési vezérelvek (pl. hogyan azonosíthatjuk az objektumokat?)

Ficsor Lajos

Ficsor Lajos


OOSE /

33

OOSE / 11


Objektum orientált módszerek 2. eszközök (CASE rendszer, vagy alacsonyabb szintű segédeszközök) pragmatizmusok, heurisztikus elvek (a gyakorlati alkalmazások összegyűjtött tapasztalatai).

Ficsor Lajos


OOSE /

34

Imertebb fejlesztési módszertanok 1. OMT (Object Modelling Technique, Rumbaugh, 1991, majd 1993) OOD (Object Oriented Design, Booch, 1991, majd 1993) OOA (Object Oriented Analysis, Coad & Yourdon, 1991) OOSD (Object-Oriented Structured Design, Wasserman, 1990) Ficsor Lajos


OOSE /

35

Imertebb fejlesztési módszertanok 2. HOOD (Hierachical Object Oriented Design, 1989) Responsibility -Driven Design, Wirfs & Buck, 1990 OOSE (Object Oriented Software Engineering, Jacobson, 1992) RUP (Rational Unified Process) (UML + fejlesztési folyamat ajánlás, 1998-1999) Ficsor Lajos

Ficsor Lajos


OOSE /

36

OOSE / 12

Objektum orientált software fejlesztés (Bevezetés)

Recommend Documents