Obiektowe modelowanie systemów informatycznych



Pobieranie 8,01 Mb.
Strona7/113
Data23.10.2017
Rozmiar8,01 Mb.
1   2   3   4   5   6   7   8   9   10   ...   113

Język definiowania obiektów ODL


ODL jest językiem specyfikacji, którego celem jest definiowanie interfejsów lub sygnatur operacji dla typów obiektów zgodnych z ODMG 2.0. Ten język jest oparty na języku IDL – definicji interfejsu grupy OMG. Wykorzystanie ODL pozwoli realizować przenośność schematów baz danych. ODL jest ekwiwalentem języka DDL w relacyjnych bazach danych. Za dopomogą ODL można zdefiniować atrybuty obiektów, wyznaczyć związki pomiędzy różnymi typami obiektów oraz definiować sygnatury operacji obiektów. Specyfikacja ODL nie zawiera zasobów realizacji algorytmów operacji. Realizacja operacji musi być opisana w konkretnym języku programowania (np. C++, Java).

Składni ODL zawierają następne konstrukcji:



Definiowanie interfejsów i klas

Format ODL dla definiowania klas i interfejsów jest taki samy jako w językach Java lub C++.



Class nazwa_klasy

{

// elementy klasy



};

Interface nazwa_interfejsu

{

//elementy interfejsu



};

W przypadkach, gdy klasa realizuje jeden lub więcej interfejsów, nazwiska ostatnich muszą być oddzielone przez „:”.



Class nazwa_klasy: nazwa_interfejsu1:nazwa_interfejsu2

{

// elementy klasy



};

Kiedy klasa dziedziczy inne klasę to trzeba wykorzystywać następny format:



Class nazwa_klasy extends nazwa_nadklasy : nazwa_interfejsu

{

// elementy klasy



};

Obiektowy model pozwoli się grupować wszystkie obiekty, mające ten samy typ do jednej ekstensji (extent). Ekstensja to jest zestaw aktualnie istniejących obiektów danej klasy. W odróżnieniu od pojęcia klasy, która jest abstrakcją wirtualną, ekstencja to jest specjalna struktura danych skojarzoną z daną klasą, której zadaniem jest przechowywanie wszystkich obiektów będących wystąpieniami tej klasy i realne istniejącymi. W przypadkach, gdy klasa należy do ekstentu, format ma następną postać:


Class nazwa_klasy extends nazwa_nadklasy : nazwa_interfejsu

( extent nazwa_extentu)

{

// elementy klasy



};

Na rys.19 są pokazane interfejsy i klasy bazy danych.



Rys.19


Listing tej bazy w języku ODL :

Interface Osoba


{

};

interface Pracownik : Osoba

{

};

class Student : Osoba



(extent students)

{

};



class wykladowca : Pracownik

(extent wykladowcy)

{

};

class kierowca : Pracownik



(extent Pracownicy)

{

};



Deklarowanie atrybutów

Dla deklarowania atrybutu trzeba wyznaczyć nazwę i typ:



Attribute typ nazw_atr;

Typ atrybutu może być prymitywnym(integer, real, itp) lub należeć do zadeklarowanej klasy. Typ nie może należeć do zadeklarowanego interfejsu, bo interfejs nie może mieć implementacji. W przypadkach, gdy atrybut zawiera zbiór wartości lub obiektów, format deklarowania musi mieć następną postać:



Attribute set nazw_atr;

W przypadkach deklarowania zbiorów atrybutów klasa lub interfejs zawierają wszystkie te atrybuty, a nie odwołania do nich. Każda klasa lub interfejs mogą zawierać klucz. Klucz może być zdefiniowany w takim formacie:



key lista_atrybutów;

Przykład:



Class Address

{

attribute string ulica;



attribute string miasto;

attribute string zip;

};

Interface Osoba



{

attribute string id;

attribute string nazwisko;

attribute Address adresa;

attribute set phone;

key id;

};

Wyznaczenie związków

Związki wyróżniają się od atrybutów w ten sposób, że zawierają identyfikatory obiektów, a nie sami obiekty. W definicji związku musi być wyznaczony inny koniec połączenia (nazwę połączenia w połączonej klasie). Format definiowania związków ma następną postać:

Relationship połączona_klasa nazw_związku

Inverse połączona_klasa :: nazw_związku_w_połączoney_klasie;

Na rys.20 są pokazane dwa klasy „Wykładowca” oraz „Student”, który połączone pomiędzy sobą związkiem „jeden do wielu”.


Rys. 20


Deklarowanie tego połączenia w ODL w następnym listingu:

Class wykladowca

{

// atrybuty



relationship student dyplomant

inverse student ::promotor;

....


};

class student

{

// atrybuty



relationship wykladowca promotor

inverse wykladowca dyplomant;

};



Dodawanie operacji

Format definiowania operacji ma następną postać:

Typ_ powrotnej_wartości nazwe_operacji (lista_prametrów)

Raises (lista_wyjątków ) ;

W każdej operacji trzeba wyznaczyć typ powrotnej wartości lub typ void, jeśli operacja nie wraca wartości. W nawiasach musi być wyznaczona lista parametrów. Także za dopomogą słowa kluczowego Raises mogą być wyznaczone wyjątki, które może generować operacja. Lista parametrów może zawierać parametry trzech postaci:



  • In – dla przesyłania tylko wejściowych parametrów;

  • Out – dla definiowania parametrów wyjściowych;

  • Inout – dla wejściowych/ wyjściowych.

Format listy parametrów:

{in/out/inout} typ_danych_param1 nazw_param1,

{in/out/inout} typ_danych_param2 nazw_param2,

...


{in/out/inout} typ_danych_paramN nazw_paramN

Przykład:



Class wykladowca

{

// atrybuty



// związki

boolean addStudent (in Student iStudent);

Boolean removeStudent (in Student iStudent)

Raises (noSuchStudent);

Student [ ] getStudents ();



}



1   2   3   4   5   6   7   8   9   10   ...   113


©operacji.org 2017
wyślij wiadomość

    Strona główna