Obiektowe modelowanie systemów informatycznych



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

Obiektowe bazy danych


Obiektowe bazy danych 1

Perspektywy rozwoju baz danych 2

Obiektowe modelowanie systemów informatycznych. 12

Zasady reprezentacji danych w obiektowych bazach danych 32

Standardy obiektowe OMG 35

Obiektowo – relacyjne bazy danych 53

Cele tworzenia UML 62

Model pojęciowy UML 65

Architektura systemu informatycznego 76

Życiowy cykl tworzenia systemu informatycznego 78

Diagramy klas (Class diagram) 79

Diagramy przypadków użycia (Use Case diagram) 89

Diagramy interakcji (Interaction diagram) 105

Przykład projektowania systemu informatycznego 117

Diagramy Stanów (State diagram) 131

Diagramy czynności (Activity diagram) 141

Diagramy komponentów (component diagram) 145

Diagramy wdrożenia (deployment diagram) 147

Wzorce do wyznaczenia odpowiedzialności obiektów. 149

Wzorce architektury aplikacji WWW 156

Rozszerzenie języka UML dla modelowania aplikacji WWW 158

Reguły formalne wykorzystania stereotypów klas dla stworzenia diagramów UML 163

165

Modelowanie aplikacji ASP w UML 165

Modelowanie aplikacji JSP w UML 171

Modelowanie komponentów Enterprise JavaBeans (EJB) 182

Zarządzanie transakcjami w obiektowo-relacyjnych bazach danych 192

Pytania kontrolne po kursu „Obiektowe Bazy danych”. 224



Perspektywy rozwoju baz danych

Rozwój historyczny


Historyczny rozwój systemów baz danych można podzielić na trzy generacje.

Pierwsza generacja charakteryzowała się oddzieleniem informacji logicznych i fizycznych. Po raz pierwszy do opisania struktur fizycznych z logicznego punktu widzenia zastosowano modele danych. W szczególności, na podstawie grafu opracowano modele: hierarchiczny i sieciowy.

Cechą charakterystyczną drugiej generacji są systemy relacyjne. Systemy te są oparte na nowym i prostym podejściu do organizacji danych, na relacji lub tabeli, która umożliwia znacznie lepsze rozróżnienie logicznego i fizycznego modelu danych. Systemy relacyjne obejmują również języki o dużych możliwościach, chociaż o ograniczonej mocy wyrażania. Fizyczna niezależność danych oznacza, że fizyczne przechowywanie danych jest przezroczyste(niewidoczne) dla użytkownika i w zasadzie może być zmieniane bez konieczności równoczesnego zmieniania logicznego układu danych. Języki relacyjne są zorientowane na zbiory ( w przeciwieństwie do orientacji na rekordy w modelach hierarchicznych) i stąd mogą być językami nieproceduralnymi lub deklaratywnymi. Przetwarzanie orientowane na zbiory oznacza, że tabele relacyjnej bazy danych mogą podlegać przetwarzaniu w całości, przy użyciu specjalnych operatorów, nie ma więc potrzeby przechodzenia przez poszczególne krotki z danej relacji.

Natomiast systemy relacyjne osiągnęły granice swoich możliwości w takich zastosowaniach jak:


  • CAD (Computer Aided Design - Projektowanie wspomagane komputerem) ,

  • CASE (Computer Aided Software Engineering – Inżyneria oprogramowania wspomagana komputerem),

  • GIS (Geographic Information System – System informacji geograficznej).

CAD wspomagają na stworzenie projektów technicznych. Baza danych CAD może zawierać dani różnych projektów mechanicznych, budowlanych oraz elektrotechnicznych. Na przykład budynków, samolotów, układów skalonych. Te projekty mają identyczne charakterystyki:

  • Duża ilość różnych typów danych oraz każdy z tych typów może mieć niewiele oddzielnych egzemplarzy.

  • Każdy projekt może zawierać dużo komponentów, które mogą być podzielone na oddzielnie niezależnie projekty.

  • Każdy projekt nie jest statycznym oraz może mieć ewolucję w czasie. Wszystkie zmiany trzeba odwzorować we wszystkich prezentacjach projektu.

  • Modyfikacja danych projektu może spowodować zmiany w innych części projektu, które są związane pomiędzy sobą.

  • Każdy komponent projektu może mieć dużo alternatyw realizacji dlatego trzeba przechowywać w bazie danych oddzielnie wersji komponentów.

  • W realizacji projektu mogą uczestniczyć setki projektantów, które mogą wspólnie pracować nad różnymi wersjami oddzielnych komponentów oraz całego projektu. Baza danych musi odwzorowywać niesprzeczne oraz uzgodnione decyzje końcowego produktu.

CASE wspomagają analizę, modelowanie i projektowanie systemów informatycznych. Systemy te zapewniają środki do rysowania diagramów, pewne (zwykle ograniczone) środki do automatycznego generowania kodu. Baza danych CASE może zawierać dani pro różne etapy życiowego cyklu oprogramowania oraz poszczególne komponenty. CASE - projekty mogą być dużymi oraz dla ich realizacji są potrzebne wiele projektantów. Narzędzie CASE pozwalają wspólnie wykorzystać schemat projektu, kody, dokumentację oraz odwzorowywać związki pomiędzy komponentami Przykładami systemów CASE są:

  • PowerDesigner

  • PowerBuilder

  • C++Builder

  • MSVisualStudio

  • JavaBuilder

  • RationalRose i in.

GIS pozwalają przechowywać informację o pewnym terytorium (zwykle mapy o różnej skali, przeznaczeniu, poziomie szczegółowości i typie odwzorowanej informacji), oraz przetwarzający i udostępniający tę informację w postaci wizualnej. Większość tych danych są otrzymane w wyniku badań geologicznych oraz lotniczych zdjęć fotograficznych. Dlatego te dani maja duży zakres.

Te przyczyny spowodowały rozwój obiektowej technologii baz danych. Obecnie rozwój ten jest w szczytowej fazie. Obiektowe, obiektowo-relacyjne oraz rozszerzone relacyjne systemy baz danych mogą być uważane za trzecią generację, która staje się dostępna na rynku. Generacja ta w znacznym stopniu rozszerza możliwości czysto relacyjnych systemów, a celem jej jest integracja języków programowania baz danych oraz języków stworzenia aplikacji.

Podstawowym pojęciem obiektowej technologii jest to, że oprogramowanie musi umożliwiać wielokrotne wykorzystanie oddzielnych swoich „części”. Te części zawierają standardowe komponenty, które mogą być definiowane jednokrotnie oraz wielokrotnie wykorzystane.

Tradycyjna technologia stworzenia oprogramowania odróżniana jest od technologii stworzenia i sterowania bazami danych. Technologia relacyjnych baz danych skupi się na statycznych zasadach przechowywania informacji, lecz technologia oprogramowania na aspektach dynamicznych. Trzecia generacja SZBD pozwoli stworzenie aplikacji oraz sterowanie bazami danych rozpatrzyć jako jeden proces, który nazywa się procesem obiektowego projektowania. Relacyjny SZBD opiera się na założeniu, iż dane i związane z nimi programy są od siebie oddzielone. Celem obiektowych baz danych jest integracja danych i programów.



Ograniczenia relacyjnych baz danych


Opiszemy przykład zastosowania relacyjnej bazy danych, żeby ocenić ograniczenia modelu relacyjnego. Przypuścimy baza musi zawierać dane przedsiębiorstw, zwłaszcza następne jednostki danych:

  • Firma ma nazwę, centralę, kilka oddziałów i dyrektora;

  • Oddziały mają nazwę, biuro, kierownika i pracowników;

  • Osoby mają nazwisko, wiek i miejsce zamieszkania;

  • Pracownicy są osobami posiadającymi specyficzne kwalifikację, wynagrodzenie, posadę.

Na rys.1 jest pokazany model konceptualny, który odwzorowuje dziedzinę przedmiotową systemu informacyjnego. Model konceptualny nie jest modelem relacyjnym. Ten model służy dla definiowania związków semantycznych pomiędzy encjami oraz dla stworzenia tabel modelu relacyjnego. Model konceptualny nie zależy od typu DBMS (SZBD).



Rys.1


Model fizyczny jest pokazany na rys.2. Model fizyczny to jest graficzne odwzorowanie modelu relacyjnego. Kod DDL dla stworzenia tabel bazy danych jest nadany w listingu 1. Należy zaznaczyć, że te relacje nie są jedyną możliwą reprezentacją relacyjną. Ale reprezentacja w tej postaci jest konieczna, jeśli mają być uwzględnione wymagania normalizacji do trzeciej postaci normalnej.

Rys.2


Listing 1

%%==============================================================

%% DBMS name: Sybase SQL Anywhere 5.5

%% Created on: 2003-12-06 23:16:06

%%==============================================================

%%==============================================================

%% Table: FIRMA

%%==============================================================

create table FIRMA (

IDFIRMY integer not null,

NAZWA varchar(20) not null,

ULICA varchar(20) not null,

MIEJSCOWOSC varchar(20) not null,

primary key (IDFIRMY)

);

%%==============================================================



%% Table: ODDZIAL

%%==============================================================

create table ODDZIAL (

NAZWAODDZ varchar(20) not null,

IDFIRMY integer not null,

ULICA varchar(20) not null,

MIEJSCOWOSC varchar(20) not null,

primary key (NAZWAODDZ, IDFIRMY)

foreign key FK_ODZIALY_FIRMY (IDFIRMY) references FIRMA (IDFIRMY)

on update restrict on delete restrict;

);
%%==============================================================

%% Table: OSOBA

%%==============================================================

create table OSOBA (

PESEL integer not null,

NAZWISKO varchar(20) not null,

WIEK varchar(10) not null,

ZAMIESZKANIE varchar(15) not null,

primary key (PESEL)

);

%%==============================================================



%% Table: PRACOWNIK_ADMINISTRACYJNY

%%==============================================================

create table PRACOWNIK_ADMINISTRACYJNY (

PESEL integer not null,

NAZWAODDZ varchar(20),

IDFIRMY integer,

NAZWISKO varchar(20) not null,

WIEK varchar(10) not null,

ZAMIESZKANIE varchar(15) not null,

POSADA varchar(10) not null,

WYNAGRODZENIE integer not null,

STOPIEN_NAUKOWY varchar(10),

primary key (PESEL)

foreign key FK_DYREKTOR_FIRMY (IDFIRMY)references FIRMA (IDFIRMY)

on update restrict on delete restrict;

foreign key FK_PRACOWNI_JEST_OSOBA (PESEL) references OSOBA (PESEL)

on update restrict on delete restrict;

foreign key FK_KIEROWNIK_ODDZIALU (NAZWAODDZ) references ODDZIAL

(NAZWAODDZ)

on update restrict on delete restrict;

);

%%==============================================================



%% Table: PRACOWNIK_ODDZIALU

%%==============================================================

create table PRACOWNIK_ODDZIALU (

PESEL integer not null,

NAZWAODDZ varchar(20) not null,

NAZWISKO varchar(20) not null,

WIEK varchar(10) not null,

ZAMIESZKANIE varchar(15) not null,

KWALIFIKACJA varchar(20),

WYNAGRODZENIE integer not null,

POSADA varchar(10) not null,

primary key (PESEL)

foreign key FK_PRACOWNI_JEST_OSOBA (PESEL) references OSOBA (PESEL)

on update restrict on delete restrict;

foreign key FK_PRACOWNIK_ODDZIALU (NAZWAODDZ) references ODDZIAL

(NAZWAODDZ)

on update restrict on delete restrict;

);
Relacyjny model zawiera ograniczenia oraz niedostateczne wsparcie dla stworzenia aplikacji bazodanowych. Do tych ograniczeń można odnieść:



  1. Niemożliwość wykorzystania atrybutów złożonych. Model relacyjny nie może prezentować dani o złożonej strukturze hierarchicznej, ponieważ związki między danymi zawierają tylko płaskie relacje. Wszystkie relacje są realizowane na jednym poziomie oraz nie mogą odwzorować semantykę hierarchiczną. Atrybuty złożone (na przykład adres osoby lub firmy) nie mogą być reprezentowane bezpośrednio, ich składowe muszą być deklarowane indywidualnie. W powyższym przykładzie nie można używać złożony typ danych „CENTRALA”, rozumiany jako adres, składający się z „Ulicy” i „Miejscowości”. Ponieważ taka struktura nie może być reprezentowana w modelu relacyjnym, atrybut „CENTRALA” musi zostać wyeliminowany i zastąpiony przez „Ulice” i „Miejscowość”.

  2. Niemożliwość wykorzystania atrybutów zbiorowych. Zgodnie z definicją modelu relacyjnego oddzielnie pola relacji mogą zawierać tylko wartości atomowe. Jednak w różnych aplikacjach CAD oraz GIS wykorzystają się złożone zbiorowe obiekty. Na przykład trzeba zaprojektować bazę danych działek ziemi, każda działka w tej bazie jest wielokątem z koordynatami oddzielnych kątów. Problem polega w tym, że nie wiemy zawczasu ilość tych koordynat dla każdej działki. Atrybuty zbiorowe w modelu relacyjnym (na przykład oddziały firmy) muszą być rozróżnialne od atrybutów jednowartościowych i reprezentowane w innym schemacie relacyjnym. W powyższym przykładzie przedsiębiorstwo może mieć kilka oddziałów oraz ewentualny atrybut „Oddziały” stanowił by zestaw wartości. Obecność tego atrybutu w tabeli „Firma” spowodowało by redundancję na poziomie wierszy (powtarzanie wszystkich szczegółów przedsiębiorstwa dla każdego oddziału) . W celu uniknięcia redundancji oraz w rezultacie normalizacji do pierwszej postaci normalnej konieczne jest zastosowanie drugiej relacji „Oddział”, w której znajdują się tylko oddziały wszystkich przedsiębiorstw. Aby ustalić związek między oddziałami i dotyczącymi ich informacjami szczegółowymi (z tabeli „Firma”), taka dekompozycja wymaga wprowadzenia kluzy głównego oraz obcego w tabeli „Oddział”.

  3. Wykorzystanie agregacji i specjalizacji powoduje stworzenia nowych schematów relacyjnych. Przykład specjalizacji pokazany jako związki pomiędzy tabelami „OSOBA”, „PRACOWNIK ODDZIAŁU”, „PRACOWNIK ADMINISTRACYJNY”. Pracownicy to jest specjalny typ osób. Agregacja i specjalizacja pomagają w lepszym reprezentowaniu informacji nie ma ich jednak w modelu fizycznym (relacyjnym).

  4. Model relacyjny nie może adekwatne modelować dani. Oddzielnie dani mogą być zdefiniowane przez kluczy obce. Np. Atrybut „Dyrektor” nie jest bezpośrednio definiowany w relacji „Firma”, lecz wyznaczony przez klucz obcy w innej relacji - „Pracownik administracyjny”. Taki sposób zadania atrybutów encji nie jest oczywistym. Naruszenie integralności danych w tym przypadku może powodować stratę informacji. Oprócz tego, konsekwencją realizacji w modelu relacyjnym różnych związków semantycznych może być to, że definiowanie zapytań SQL może stać się komplikowanym. Wywołanie każdego obiektu z modelu relacyjnego potrzebuje wykorzystania dużej ilości operacji połączenia (JOIN) tabel.

  5. Aplikacja jest uzależniona od struktury tabel bazy. Aplikacja, która jest połączona z relacyjną bazą danych musi „wiedzieć” strukturę modelu fizycznego bazy danych. Zmiany na poziomie modelu fizycznego mogą powodować zmiany w poleceniach SQL do bazy danych na poziomie tej aplikacji. Żeby nie być uzależnionym od modelu fizycznego, trzeba wykorzystywać zachowywane procedury oraz trygery. Niestety nie każdy SZBD zawiera możliwości tworzenia zachowywanych procedur oraz trygerów. Standardy oraz możliwości tych procedur w SZBD różnych producentów różnią się.

  6. Istnienie niezgodności impedancji między językami baz danych i językami programowania. Współcześnie zasoby programowania obiektowego nie mają alternatyw i są głównymi współczesnymi narzędzi projektanta. Jednak, rozszerzenie możliwości języków obiektowych potrzebuje obecności efektywnego mechanizmu przechowywania oddzielnych obiektów w bazach danych. To znaczy projekt obiektowego systemu może zawierać dwa typy obiektów : obiekt ulotny ( istnieje tylko w terminie aktywności aplikacji) oraz obiekt trwały (persistent obiect). Obiekt trwały nie zmienia się swego stanu pomiędzy kolejnymi uruchomieniami programu i może być przechowywany na stałe w bazie danych. Przechowywanie obiektów w bazie relacyjnej natyka się na trudności. Problem polega w tym, co zagnieżdżenie języka SQL w języki obiektowe powoduje utratę abstrakcyjności programowania obiektowego. W przypadkach wykorzystania relacyjnych modelów danych programista musi myśleć kategoriami relacyjnymi. Relacyjne SZBD zawierają dwupoziomowy model przechowywania danych (rys.3 ) Dla przetwarzania typów danych modelu relacyjnego do modelu obiektowego z powrotem, program obiektowy musi zawierać specjalne klasy dla tego przetwarzania. Systemy obiektowe oraz modele relacyjne realizują różne paradygmaty, które są niekompatybilne.

  7. Ograniczony zbiór operacji w modelu relacyjnym. W modelu relacyjnym są dostępne tylko dwa konstruktora: „Wiersz” i „Zbiór”, służące do strukturyzacji informacji. Konstruktor typu „zbiór” może być użyty tylko jednokrotnie do zdefiniowania relacji jako zbioru wierszy. Konstruktor typu „Zbiór” może być zastosowany tylko do obiektów typu „Wiersz”, a konstruktor „Wiersz” tylko do wartości atomowych. To ograniczenie nie pozwoli się skutecznie odwzorowywać zachowanie obiektów światu rzeczywistego. Na przykład aplikacji GIS wykorzystają kropki, linii, grupy linii, wielokąty. Dla tych obiektów są potrzebne nowe operacji wyznaczenia odległości, przejścia oraz inne.


Rys. 3



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


©operacji.org 2017
wyślij wiadomość

    Strona główna