Obiektowe modelowanie systemów informatycznych

Obiektowe bazy danych

OBIEKTOWE BAZY DANYCH..................................................................................................................1

PERSPEKTYWY ROZWOJU BAZ DANYCH..........................................................................................4

ROZWÓJ HISTORYCZNY................................................................................................................................4OGRANICZENIA RELACYJNYCH BAZ DANYCH..............................................................................................6REPREZENTACJA NIERELACYJNA................................................................................................................12

OBIEKTOWE MODELOWANIE SYSTEMÓW INFORMATYCZNYCH.........................................14

ZASADY OBIEKTOWOŚCI.............................................................................................................................14OBIEKTY.....................................................................................................................................................18KLASY........................................................................................................................................................22

ZASADY REPREZENTACJI DANYCH W OBIEKTOWYCH BAZACH DANYCH.......................34

STANDARDY OBIEKTOWE OMG.........................................................................................................37

STANDARD OBIEKTOWYCH BAZ DANYCH ODMG 2.0...............................................................................37JĘZYK DEFINIOWANIA OBIEKTÓW ODL.....................................................................................................41SERWER OBIEKTOWYCH BAZ DANYCH FIRMY O2 TECHNOLOGY...............................................................45STANDARD OMG CORBA........................................................................................................................46ARCHITEKTURA ORACLE NETWORK COMPUTING ARCHITEKTURE (NCA)...............................................53

OBIEKTOWO – RELACYJNE BAZY DANYCH...................................................................................55

JĘZYK SQL-3.............................................................................................................................................57ARCHITEKTURA ORSZBD POSTGRESQL..................................................................................................61

CELE TWORZENIA UML.........................................................................................................................64

DEFINICJA MODELU...................................................................................................................................64OGÓLNE CECHY UML................................................................................................................................65

MODEL POJĘCIOWY UML.....................................................................................................................67

BLOKI KONSTRUKCYJNE UML...................................................................................................................67REGUŁY UML............................................................................................................................................77STEREOTYPY W UML.................................................................................................................................77

ARCHITEKTURA SYSTEMU INFORMATYCZNEGO.......................................................................78

ŻYCIOWY CYKL TWORZENIA SYSTEMU INFORMATYCZNEGO.............................................80

DIAGRAMY KLAS (CLASS DIAGRAM)................................................................................................81

MODELOWANIE DZIEDZINY PROBLEMU......................................................................................................81ANALIZA DZIEDZINY PROBLEMU ZA DOPOMOGĄ KART CRC....................................................................86DIAGRAMY KLAS MODELU PROJEKTOWANIA............................................................................................87DEKOMPOZYCJA NA KLASY W MODELU PROJEKTOWANIA.........................................................................89

DIAGRAMY PRZYPADKÓW UŻYCIA (USE CASE DIAGRAM)......................................................91

WYMOGI DO SCENARIUSZY PRZYPADKÓW UŻYCIA....................................................................................92PRZYKŁADY EWENTUALNYCH BŁĘDÓW PRZY OPRACOWANIU SCENARIUSZY PRZYPADKÓW UŻYCIA.......94DEFINIOWANIE PRZYPADKÓW UŻYCIA (USE CASE)....................................................................................95DEFINIOWANIE AKTORÓW (ACTORS)..........................................................................................................97DEFINIOWANIE ASOCJACJI (ASSOCIATION).................................................................................................98DEFINIOWANIE UOGÓLNIEŃ (GENERALIZATIONS)......................................................................................99

1

DEFINIOWANIE ZALEŻNOŚCI (DEPENDENCIES).........................................................................................101DOKUMENTOWANIE ORAZ KONSTRUOWANIE PRZYPADKÓW UŻYCIA......................................................107

DIAGRAMY INTERAKCJI (INTERACTION DIAGRAM)................................................................108

DIAGRAM PRZEBIEGU(SEQUENCE DIAGRAM)...........................................................................................109DIAGRAM KOOPERACJI (COLLABORATION DIAGRAM)..............................................................................116TECHNIKI MODELOWANIA DIAGRAMÓW INTERAKCJI...............................................................................118

Modelowanie przepływu sterowania za dopomogą diagramów przebiegu........................................119

PRZYKŁAD PROJEKTOWANIA SYSTEMU INFORMATYCZNEGO...........................................120

STWORZENIE DIAGRAMU PRZYPADKÓW UŻYCIA (USE CASE DIAGRAM)................................................120STWORZENIE DIAGRAMU PRZEBIEGU (SEQUENCE DIAGRAM)..................................................................122STWORZENIA DIAGRAMU KLAS (CLASS DIAGRAM).................................................................................125

Wyznaczenie klas oraz związków pomiędzy nimi................................................................................125

DIAGRAMY STANÓW (STATE DIAGRAM).......................................................................................134

DIAGRAMY CZYNNOŚCI (ACTIVITY DIAGRAM)..........................................................................144

DIAGRAMY KOMPONENTÓW (COMPONENT DIAGRAM).........................................................148

DIAGRAMY WDROŻENIA (DEPLOYMENT DIAGRAM)...............................................................150

WZORCE DO WYZNACZENIA ODPOWIEDZIALNOŚCI OBIEKTÓW.......................................152

WZORZEC INFORMATION EXPERT............................................................................................................153WZORZEC CREATOR.................................................................................................................................154WZORZEC LOW COUPLING.......................................................................................................................155WZORZEC HIGH COHESION......................................................................................................................156WZORZEC CONTROLLER..........................................................................................................................157

WZORCE ARCHITEKTURY APLIKACJI WWW..............................................................................158

WZORZEC ARCHITEKTURY THIN WEB CLIENT........................................................................................158WZORZEC ARCHITEKTURY THICK WEB CLIENT......................................................................................159

ROZSZERZENIE JĘZYKA UML DLA MODELOWANIA APLIKACJI WWW............................160

STEREOTYPY DO MODELOWANIA KLAS:...................................................................................................160

REGUŁY FORMALNE WYKORZYSTANIA STEREOTYPÓW KLAS DLA STWORZENIA DIAGRAMÓW UML.................................................................................................................................165

MODELOWANIE APLIKACJI ASP W UML.......................................................................................167

MODELOWANIE APLIKACJI JSP W UML........................................................................................173

MODELOWANIE KOMPONENTÓW ENTERPRISE JAVABEANS (EJB).....................................184

KOMPONENTY SESYJNE............................................................................................................................187KOMPONENTY ENCYJNE...........................................................................................................................192

ZARZĄDZANIE TRANSAKCJAMI W OBIEKTOWO-RELACYJNYCH BAZACH DANYCH. .194

CECHY TRANSAKCJI.................................................................................................................................194ANOMALNE HISTORII PRZETWARZANIA TRANSAKCJI.............................................................................198PRZETWARZANIE TRANSAKCJI NA RÓŻNYCH POZIOMACH IZOLACJI........................................................202SZEREGOWALNOŚĆ TRANSAKCJI.............................................................................................................206ZARZĄDZANIE TRANSAKCJAMI W JĘZYKU SQL.......................................................................................209METODY STEROWANIA WSPÓŁBIEŻNOŚCIĄ TRANSAKCJI NA RÓŻNYCH POZIOMACH IZOLACJI................213

Metody blokowania danych................................................................................................................213Algorytm blokowania dwufazowego...................................................................................................214Zakleszczenia transakcji.....................................................................................................................218Metody znaczników czasowych...........................................................................................................220

2

ODTWARZANIE BAZY DANYCH.................................................................................................................221Odtwarzanie bazy danych przy uszkodzeniach pamięci ulotnej.........................................................221Odtwarzanie bazy danych przy uszkodzeniach pamięci trwałej.........................................................225

Pytania kontrolne po kursu „Obiektowe Bazy danych”.........................................................................226

3

Perspektywy rozwoju baz danych

Rozwój historycznyHistoryczny 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.

4

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

5

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 danychOpiszemy 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).

6

Rys.1Model 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.

7

Rys.2Listing 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)

8

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,

9

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ł”.

10

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ć

11

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

Reprezentacja nierelacyjna Rozpatrzymy poprzedni przykład w środowisku nierelacyjnym. Zakładamy, że te środowisko ma następujące cechy:

1. Deklaracje typów danych są tak elastyczne jak C++ lub innym języku programowania.

2. Obiekty mogą być identyfikowane unikatowo niezależnie od ich wartości. Służą temu identyfikatory obiektów, umożliwiające odwołania między obiektami.

3. Możliwe jest ponowne użycie informacji przez: Odwoływanie się do obiektów z różnych miejsc, a więc nowe informacje mogą

być zestawiane z informacji istniejących. Inaczej mówiąc, nowe obiekty są tworzone z obiektów istniejących, które stają się ich składnikami i mogą być

12

traktowane jako podobiekty; technika ta nosi nazwę agregacji lub, czasem asocjacji.

Definiowanie specjalizacji między pewnymi informacjami przez dziedziczenie struktury i zachowanie.

Baza danych firmy może być opisana w następujący sposób:Firma : [

Nazwa: String,Centrala: Adres,Oddziały: { Oddział},Dyrektor: Pracownik ]

Oddział: [Nazwa: String,Biuro: Adres,Kierownik: Pracownik,Pracownicy: {Pracownik}]

Adres: [Ulica: String,Miejscowość: String]

W powyższych definicjach zastosowane są notacje: [...] – typ krotkowy, {...} – typ zbiorowy. Dla definicji firmy jest wykorzystana agregacja. Firma składa się z łańcucha znaków (Nazwa), obiektu typu Adres (Centrala), zbioru obiektów z elementami typu oddział (Oddziały) oraz z obiektu typu Pracownik (Dyrektor). Trzeba podkreślić, że odwołanie jest realizowane bezpośrednio do nazwy danego typu. W wyniku tego dla konkretnej firmy wartość atrybutu „Centrala” stanowi odwołanie do konkretnego obiektu typu Adres, wartość atrybutu Dyrektor jest odwołaniem do obiektu typu Pracownik. Identyfikatory obiektów potrzebne w takim schemacie odwołań mogą być zrealizowane za pomocą nazw unikatowych na poziomie logicznym lub za pomocą adresów (wirtualnych) na poziomie przechowywania. W porównaniu z modelem relacyjnym nie ma tu potrzeby dodawania kluczy obcych FOREIGN KEY, ponieważ atrybuty są powiązane z nazwanymi typami.Niżej są wyznaczone pracownicy firmy. Każdy pracownik jest specjalizacją osoby:Osoba: [

Nazwisko: String,Wiek: Integer,MiejsceZam: Adres,Tabor: {Pojazd}]

Pracownik is-a Osoba: [Kwalifikacje: {String},Wynagrodzenie: Integer,Rodzina: {Osoba}]

13

Tutaj, poprzez dziedziczenie, struktura „Osoba” jest ponownie użyta dla pracowników. Dlatego wszystkie atrybuty zdefiniowane dla osoby - „Nazwisko”, „Wiek”, „MiejsceZam”, „Tabor” – są również zdefiniowane dla pracownika, oprócz atrybutów, które są dla niego specyficzne – „Kwalifikacje”, „Wynagrodzenie” i „Rodzina”. W sposób analogiczny jest opisana informacja dotycząca pojazdu:Pojazd: [

Model: String,Producent: Firma,Kolor: String]

Samochód is-a Pojazd: [Napęd: NapędPojazdu,Nadwozie: String]

NapędPojazdu : [Silnik: SilnikSpalinowy,SkrzyniaBiegów: String]

SilnikSpalinowy: [Moc: Integer,Pojemność: Integer]

Dla definicji polecenia, wywalającego dani pro pracownika o nazwisku „Kowalski”, który jest zatrudniony w oddziale „Koszalin” firmy „Emka” w obiektowej adaptacji trzeba zapisać:SELECT e.Nazwisko, e.Wiek, e. MiejsceZam, e.kwalifikacje, e. Wynagrodzenie, e.Rodzina(0).Wiek FROM e IN Pracownik, c IN Firma, s IN OddziałWHERE c.Nazwa =’Emka’ AND

s IN c.Oddziały ANDs.Biuro.Miejscowość = ‘Koszalin’ ANDe IN s.Pracownicy ANDe.Nazwisko = ‘Kowalski’

Obiektowe modelowanie systemów informatycznych.

Zasady obiektowości Stworzenie oprogramowania systemów informatycznych może być realizowane przez następne sposoby: Proceduralny, Predykatywny, Obiektowy.Proceduralny sposób jest skierowany na przedstawienie programu jako mnóstwa procedur, które są wywoływane w wyznaczonej kolejności.

14

Proceduralny sposób jest skojarzony z projektowaniem strukturalnym. Głównym etapem projektowania strukturalnego jest dekompozycja funkcjonalna. Wadami projektowania strukturalnego są: Niemożliwość przekazywania odpowiedzialności do innych komponent

funkcjonalnych; Problemy z obsługą zmian w projektu; Problemy z zabezpieczeniem danych globalnych przez nieprawidłowo działające

funkcji. Dekompozycja funkcjonalna stanowi naturalne podejście do każdego złożonego problemu. Jednym z problemów związanych ze stosowaniem dekompozycji funkcjonalnej jest to, że prowadzi ona do powstania jednego programu „głównego” odpowiedzialnego za kontrolowanie wszystkich podprogramów. Jest to naturalny rezultat podziału dużych funkcji na mniejsze, niemniej jednak metoda ta nakłada na program główny zbyt dużą odpowiedzialność- musi on zapewnić, że wszystko będzie działać poprawnie, jak również koordynować pracę funkcji i wywołać je w odpowiedniej kolejności, dlatego też zastosowanie dekompozycji funkcjonalnej często powoduje powstanie bardzo złożonego kodu. Predykatywny sposób jest skierowany na realizację celu za dopomogą teorii predykatów oraz na realizację reguł typu „If - Then” . W ten sposób realizują się systemy ekspertowe. Obiektowy sposób jest skierowany na przedstawieniu programu jako mnóstwa obiektów, które komunikują pomiędzy sobą. Teraz nie można wyznaczyć sposób najlepszy we wszystkich dziedzinach praktycznego zastosowania. Każdy sposób ma swoje zalety. Razem z tym sposób obiektowy może być wykorzystany w dużej ilości przypadków. Przy wykorzystaniu sposobu proceduralnego programista tworzy procedury, które w celu realizacji zadań muszą wywołać jedna drugą. Każda procedura realizuje swój algorytm obróbki danych. Przy wykorzystaniu sposobu obiektowego programista tworzy obiekty programowe z wyznaczonym zachowaniem oraz reakcją na zdarzenia zewnętrzne. Te obiekty współdziałają między sobą, realizują zadania, otrzymają oraz dostarczają dani do innych obiektów. Z programowaniem obiektowym jest skojarzone projektowanie obiektowe. Programowanie jest skierowane do prawidłowego oraz skutecznego wykorzystania wyznaczonych języków oprogramowania. Projektowanie obiektowe zawiera analizę oraz konstruowanie systemu w wyglądu zbioru obiektów, które połączone między sobą. Projektowanie dowolnego systemu potrzebuje wykorzystania technik dekompozycji – to znaczy rozdzielenia złożonego systemu na odrębne

15

komponenty. Istnieją dwa główne schematy dekompozycji: dekompozycja algorytmiczna oraz dekompozycja obiektowa. Dekompozycja algorytmiczna polega na rozdzieleniu złożonego procesu na odrębne czynności lub algorytmy. Ta dekompozycja wykorzysta się przy projektowaniu programów dla komputerów w sposób proceduralny. Dekompozycja obiektowa zawiera rozdzielenie systemu komplikowanego na oddzielne autonomiczne komponenty, które są obiektami światu rzeczywistego (lub wirtualnego). Te komponenty nazywają się prosto obiektami. Obiekt zawiera opis czynności oraz dane, które są skojarzone tylko z tym obiektem. Dekompozycja obiektowa systemów informatycznych zawiera następne zasady: Abstrakcja (abstraction) Hermetyzacja lub kapsułkowanie (encapculation) Modularność (modularity) Hierarchia (hierarchy).AbstrakcjaAbstrakcja jest: ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub

mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów oraz

wprowadzanie pojęć lub symboli oznaczających takie cechy.Aparat abstrakcji jest wygodne narzędzie dla modelowania złożonych systemów (i nie tylko informatycznych !). Przy stworzeniu pojęcia w ramach wyznaczonego zadania skupimy się tylko na istotnych właściwościach konkretnego obiektu oraz wyabstrahujemy od nie istotnych. Na przykład, w abstrakcji „Zegarek” wyróżniamy tylko właściwość „Czas” oraz wyabstrahujemy od formy tego zegarku, producenta itd.Każda abstrakcja zawiera formowanie wyznaczonych właściwości obiektu, które wyróżniają go od innych. Abstrakcja skupi się na zewnętrznej prezentacji obiektu oraz pozwoli oddzielić główne cechy zachowania obiektu od go realizacji. Przykład abstrakcji. Przepuszczamy trzeba stworzyć program komputerowy dokładnie symulujący działanie stosu atomowego. Ten program musi zawierać wystarczająco wiele informacji, aby móc uwzględniać, co się zdarzy, gdy dyspozytor będzie kierował procesami w stosie. Ale dla tego rodzaju programu zapewne nieważny okaże się typ oraz numer fabryczny generatora elektrowni, więc można go odfiltrować. Hermetyzacja lub kapsułkowanieHermetyzacja oraz abstrakcja są wzajemne dopełniające pojęcia. Hermetyzacja lub kapsułkowanie to jest:

16

zamknięcie pewnego zestawu bytów programistycznych w „kapsule” o dobrze określonych granicach;

oddzielenie abstrakcyjnej specyfikacji tej kapsuły od jej implementacji; ukrycie części informacji zawartej w tej kapsule dla operacji z zewnątrz obiektu.

Abstrakcja skupi się na zewnętrznym zachowaniu obiektu oraz hermetyzacja kryje realizację tego zachowania.

Przykład kapsułkowania. Telewizor prezentuje różne programy telewizyjne. Szczegóły operacji, które potrzebne dla wyświetlania tych programów są ukryte dla użytkownika.Są rozliczone dwie koncepcji hermetyzacji: hermetyzacja ortodoksyjna oraz hermetyzacja ortogonalna. W hermetyzacji ortodoksyjnej wszelkie operacje, które można wykonać na obiekcie, są określone przez metody przypisane do obiektu (znajdujące w jego klasie i nadklasach); bezpośredni dostęp do atrybutów obiektów jest niemożliwy. Oznacza to często, że każdy atrybut obiektu musi być wyposażony w dwie metody: CzytajWartość( ) i ZmieńWartość( ); takie założenie przyjmuje np. Standard CORBA. W hermetyzacji ortogonalnej (C++, Java) dowolny atrybut obiektu i dowolna metoda mogą być prywatnymi (niedostępnymi z zewnątrz) lub publicznymi. ModularnośćModularność to jest możliwość dekomponowania systemu na części o dobrze określonych granicach oraz o dobre wyspecyfikowanym interfejsie pomiędzy poszczególnymi częściami. Modularność pozwoli zgrupować logiczne zależne abstrakcje w jedyny moduł. HierarchiaHierarchia jest przeznaczona dla formowania z różnych abstrakcji struktury hierarchicznej systemu. Taka struktura upraszcza system oraz projekt tego systemu pozostaje zrozumiałym dla projektanta tak i dla użytkownika. Hierarchia jest wykorzystywana na różnych poziomach opisu systemu. W systemach obiektowych są dwa typy hierarchii: Dziedziczenie – związek typu „jest” („is a” – hierarchia) Agregacja – związek typu „część” („part of” - hierarchia).Dziedziczenie to jest związek pomiędzy klasami obiektów określający przekazywanie cech (definicji atrybutów, metod, itd.) z nadklasy do jej podklas. Np. Obiekt klasy „Pracownik” dziedziczy wszystkie własności (definicji atrybutów, metody) określone w ramach klasy „Osoba”. Dziedziczenie jest podstawowym mechanizmem sprzyjającym ponownemu użyciu wyznaczonej abstrakcji („Osoba”) w innych abstrakcjach („Pracownik”).

17

Agregacja to jest związek pomiędzy klasami obiektów, modelujący stosunek całości do jej części (np. stosunek samochodu do kół i silnika). Obiekty są powiązane związkiem agregacji, jeżeli jeden z nich można uważać za część drugiego, zaś cykl i czas życia tych obiektów są jednakowe. Agregacja jest dużo korzystna w wykorzystaniu razem z dziedziczeniem:

1. Agregacja realizuje fizyczne grupowania struktury obiektów2. Dziedziczenie pozwala na wielokrotnie wykorzystywanie tej struktury.

ObiektyObiekt jest konkretna reprezentacja abstrakcji, która wyznaczona w czasie oraz w przestrzeni. Obiekt jest odróżnialny od innych obiektów, ma nazwę i dobrze określone granice. Struktura i zachowanie podobnych obiektów są wyznaczone w uogólniającej ich klasie. Terminy „egzemplarz klasy” oraz „obiekt” mają te same znaczenie. Przykład obiektu „Krzesło” jest pokazany na rys.4 Każdy obiekt zawiera listę właściwości oraz operacji.

Rys. 4Obiektom przypisuje się cechy takie jak tożsamość, stan i operacje.Tożsamość to jest właściwość obiektu, która wyróżnia ten obiekt od innych. W przypadku „Krzesło” tożsamość to jest numer inwentarzy. Stan obiektu wyznaczony jest przez właściwości(atrybuty) oraz potocznymi ich wartościami. Operacja to jest implementacja pewnej usługi (algorytmu), której wykonania można zażądać od wszystkich obiektów wyznaczonej klasy. Metoda to jest synonim operacji dla klasy. Obiekt może otrzymywać polecenia (komunikaty) od innych obiektów dla zmiany stany przez inicjację własnych operacji. Każdy komunikat może zawierać wyznaczone

18

parametry. Obiekt może inicjować analogiczne komunikaty do innych obiektów. Zachowanie(synonim behawior) ( ang. behavior) obiektu wyznacza w jaki sposób obiekt wpływa na inne obiekty oraz narazi się sam tego wpływu. Zachowanie jest funkcją od zestawu metod (operacji) i stanu obiektu. Dla obiektu „Krzesło” są wyznaczone taki operacji: Kupić(), Sprzedać(), Zważyć(), Przenieść(), Pofarbować(). Operacja to jest serwis, który oferuje obiekt do klientów. Istnieje 5 typów tego serwisu:

1. Modyfikator (pozwoli zmienić się stan obiektu);2. Selektor (pozwoli się czytać stan obiektu, ale nie może zmienić ten stan);3. Iterator (pozwoli mieć dostęp do oddzielnych części obiektu w wyznaczonej

kolejności);4. Konstruktor ( tworzy nowy obiekt oraz inicjalizuje stan tego obiektu);5. Destruktor ( skasuje obiekt oraz uwolni obszar pamięci RAM tego obiektu).

Przykłady operacji:Typ operacji OperacjaModyfikator Ustalić_cenę_artykułu () :integer Selektor Otrzymać_cenę_artykułu ( ) :integerIterator Otrzymać_listę_artykułów () :stringKonstruktor Stworzyć_artykuł (nazwa, kategoria)Destruktor Kasować_artykuł ()Wszystkie metody wyznaczonego obiektu składają się protokół tego obiektu. Protokół to jest dopuszczalne zachowanie obiektu. Operacje protokółu mogą być podzielone na oddzielne grupy zachowania. Te grupy wyznaczają roli, które są oferowane klientom oraz realizowane przez obiekt. Schemat Protokołu i go roli są pokazane na rys.5

Rys.5Relacji między obiektami

19

Projektant musi analizować nie oddzielnie obiekty pojedyncze, lecz natomiast współdziałanie tych obiektów, które wyznacza zachowanie całego systemu. W książkę Gradego Boocha jest taka fraza: „Samolot to jest zespól komponentów, każdy z których pojedyncze dąży się wpaść do ziemi, lecz natomiast dzięki uzgodnionemu współdziałaniu wszystkich tych komponentów przezwycięży się tę tendencją”. Obiekt współdziała z innymi obiektami poprzez relacje. Relacja to jest związek, który pozwoli: Obiektu , który jest klientem wywołać operacje obiektu, który jest serwerem; Przesłać dane pomiędzy obiektami.Relacji pomiędzy dwoma obiektami mogą być zrealizowane przez komunikaty. Komunikat to jest sygnał skierowany do obiektu, wywołujący określoną metodę lub operację, którą należy wykonać na obiekcie. Komunikat może mieć parametry. Komunikat można uważać za wywołanie procedury związanej z obiektem, uruchamianej w środowisku (wewnątrz) obiektu. Przykład komunikatów pomiędzy 4 obiektami jest pokazany na rys. Na tym rys.6 jest pokazana następna kolejność komunikatów:

1. Obiekt „Order” poleca obiektu „Dostawa” dostawę zamówienia.2. Obiekt „Dostawa” informuje obiekt „Magazyn” pro konieczność odejmowania

wyznaczonej ilości towarów w zamówieniu. 3. Obiekt „Magazyn” analizuje poziom zapasu towarów. 4. W przypadkach kiedy ten poziom jest niżej minimalnego, obiekt „Magazyn”

formuje komunikat do obiektu „Zakup” pro zamówienie nowych towarów.

Rys.6Obiekt, jako uczestnik relacji może zrealizować jedną z trzech następnych roli:

20

Aktor - to jest obiekt, który może oddziaływać na inne obiekty, oraz nigdy nie może narazić się oddziaływaniu przez inne obiekty;Serwer – to jest obiekt, który nigdy nie może oddziaływać na inne obiekty, oraz może zrealizować polecenia od innych obiektów;Agent – to jest obiekt, który może oddziaływać na inne obiekty oraz zrealizować polecenia od innych obiektów.Na rys.7 są pokazane:Tom – to jest aktor;Meri, wzmacniacz – to są serwery;Centrum muzykalne – to jest agent.

Rys.7

KlasyPojęcia klasy oraz obiektu są połączone pomiędzy sobą. Klasa to jest abstrakcja istotnych cech (właściwości oraz operacje) zbioru obiektów o zbliżonych własnościach. Innymi słowy klasa to jest opis obiektów, które mają te same właściwości, operacje oraz semantykę. Jakikolwiek obiekt jest egzemplarzem klasy. Klasa zawiera się reprezentację wewnętrzną oraz reprezentację zewnętrzną. Reprezentacja wewnętrzna nazywa się realizacją klasy. Reprezentacja zewnętrzna nazywa się interfejsem klasy. Interfejs składa się z sygnatur wszystkich metod, zmiennych i konstant, które mogą być użyte w stosunku do obiektów egzemplarzy tej klasy. Interfejs może być podzielony na trzy części: Publiczna (public) – która jest dostępna wszystkim klientom - obiektom innych klas; Zabezpieczona (protected) – która jest dostępna obiektom tej samej klasy, obiektom

podklasy oraz obiektom klasy zaprzyjaźnionej (friend class);

21

Prywatną (private) – która jest dostępna tylko obiektom tej samej klasy oraz obiektom klasy zaprzyjaźnionej.

Klasa zaprzyjaźniona to jest klasa, która posiada dostęp do wszystkich części tej klasy – publicznej, zabezpieczonej oraz prywatnej.Związki Związek to jest relacja między klasami. W modelowaniu obiektowym najważniejszymi rodzajami związków są :

1. Asocjacja;2. Dziedziczenie i uogólnienie;3. Agregacja;4. Zależność.

Asocjacja (association) wyznacza związek semantyczny pomiędzy różnymi klasami obiektów. Asocjacja to jest „klej”, który jednoczy się wszystkie elementy systemu. Semantyką asocjacji jest pewna liczba „nitek” (powiązań) łączących obiekty będące wystąpieniami klas połączonych przez asocjację. Bez asocjacji system jest zbiorem izolowanych klas. Klasa biorąca udział w asocjacji odgrywa pewną określoną rolę. Role to jest „oblicze”, które klasa przy jednym końcu powiązania prezentuje klasie przy drugim końcu.Na rys.8 jest pokazany przykład asocjacji „jeden do wielu” pomiędzy klasą „Firma” oraz klasą „Osoba”.

Rys.8Asocjacja zawiera powiązania w dowolnym kierunku. To znaczy, że: Dla każdego egzemplarzy klasy „Osoba” jest wyznaczony jeden egzemplarz klasy

„Firma”, w którym pracuje osoba; Dla każdego egzemplarzy klasy „Firma” są wyznaczone wszystkie osoby,

zatrudnione w tej firmie.Asocjacja reprezentuje związek strukturalny między obiektami. To znaczy, że trzeba wyznaczyć ilość obiektów, które mogą być połączone przez jeden egzemplarz powiązania. Ta ilość nazywa się liczebnością roli asocjacji. Liczebność podana przy jednym końcu asocjacji wskazuje, ile obiektów tej samej klasy musi być połączone z każdym obiektem klasy znajdującej się na końcu przeciwnym. Liczebność można ustalić na dokładnie jeden(1), zero lub jeden(0..1), dowolnie wiele (0..*) albo co najmniej jeden (1..*). Może to być także inna pewna ustalona liczba.Asocjacja umożliwia przechodzenie(nawigację) pomiędzy powiązanymi obiektami w dowolnym kierunku, dlatego asocjacja jest utożsamiana z

22

powiązaniami wskaźnikowymi przy realizacji tych obiektów. Przykład realizacji wyższe pokazanych klas w środowisku JAVA jest pokazany w następnym listingu:Listing.2 /*********************************************************************** Module: Firma.java Author: hadginov Purpose: Defines the Class Firma

***********************************************************************/

import java.util.*;public class Firma

{public Osoba [] zatrudnia;

}/*********************************************************************** Module: Osoba.java Author: hadginov Purpose: Defines the Class Osoba_

***********************************************************************/

import java.util.*;public class Osoba

{public Firma pracuje;

}

Dziedziczenie (inheritance) i uogólnienie (generalization). Dziedziczenie to jest związek pomiędzy klasami obiektów określający przekazywanie cech (definicji atrybutów, metod, itd.) z nadklasy do jej podklas. Dziedziczenie realizuje związek typu „jest” (hierarchią „is a”). Np. (Rys.9) obiekt klasy „Pracownik” dziedziczy wszystkie własności (definicje atrybutów, metody) określone w ramach klasy „Osoba”.

23

Rys. 9Dziedziczenie jest podstawowym mechanizmem sprzyjającym ponownemu użyciu rezultatów projektowania. Dziedziczenie często nazywają innym terminem Uogólnieniem lub Generalizacją. Przykład skryptów wyższe pokazanych klas w środowisku JAVA jest pokazany w listingu 3:Listing 3/*********************************************************************** Module: Osoba.java Author: hadginov Purpose: Defines the Class Osoba **********************************************************************/import java.util.*;public class Osoba{

public String Nazwisko;public String Imie;public int RokUrodz;public int Wiek()

{// TODO: implementreturn 0;

}}/*********************************************************************** Module: Pracownik.java Author: hadginov

24

Purpose: Defines the Class Pracownik ***********************************************************************/

import java.util.*;public class Pracownik extends Osoba

{public int Zarobek;public int Firma;public int ZarobekNetto()


}public int ZminZarobek()


}}Hierarchia dziedziczenia nie musi kończyć się na dwóch poziomach. Podklasa (subclass) jednej klasy może być nadklasą (superclass) innej klasy. Podklasa często ma własne nieodziedziczone atrybuty. Na przykład klasa „Ssak” dziedziczy klasę „Zwierzę”. Ale oddzielny „Ssak” ma włosy i daje mleko, oraz nie są to cechy odziedziczone z klasy „Zwierzę”.Podklasy są ważną częścią modelu, gdyż ostatecznie są potrzebne egzemplarzy tych klas. W tym celu jest wykorzystywana klasa abstrakcyjna (abstract class), która zawiera własności (np. metody, atrybuty) dziedziczone przez jej podklasy, ale nie posiadająca bezpośrednich wystąpień obiektów. Klasa abstrakcyjna stanowi się wyższy poziom abstrakcji przy rozpatrywaniu pewnego zestawu obiektów. Np. Pokazana wyżej klasa „Osoba” jest klasą abstrakcyjną, o ile zdefiniowane mogą być jej podklasy: „Pracownik”, „Student”, „Emeryt”. Klasa abstrakcyjna jest najczęściej używana do zdefiniowania wspólnego interfejsu dla pewnej liczby podklas. Klasa abstrakcyjna może mieć (nie musi) metody (operacje) abstrakcyjne, tj. takie, które są zdefiniowane w tej klasie, ale których implementacja znajduje się (jest oczekiwana) w jej bezpośrednich podklasach. Z Uogólnieniem(dziedziczeniem) jest połączony Polimorfizm. Polimorfizm to jest możliwość istnienia wielu metod o tej samej nazwie w różnych podklasach (dziedziczonych z tej samej nadklasy), powiązana z możliwością wyboru konkretnej metody podczas czasu wykonania. Potomek dziedziczy wszystkie właściwości przodka, a w szczególności jego atrybuty

25

i operacje. Najczęściej, choć nie zawsze, potomek ma także własne cechy oprócz tych , które odziedziczył po przodku. Operacja potomka mająca tę samą sygnaturę, co operacja przodka jest ważniejsza (ma pierwszeństwo). Przykład wykorzystania polimorfizmu jest pokazany na rys.10

Rys.10Przykład skryptów wyższe pokazanych klas w środowisku JAVA jest pokazany w listingu 4. Listing 4/*********************************************************************** Module: dokument.java Author: hadginov Purpose: Defines the Class dokument **********************************************************************/import java.util.*;public class dokument{

public int otwierac()


}}/*********************************************************************** Module: czasopismo.java Author: hadginov Purpose: Defines the Class czasopismo **********************************************************************/import java.util.*;public class czasopismo extends dokument{}

26

/*********************************************************************** Module: ksiezka.java Author: hadginov Purpose: Defines the Class ksiezka **********************************************************************/import java.util.*;public class ksiezka extends dokument{}/*********************************************************************** Module: rachunek_bankowy.java Author: hadginov Purpose: Defines the Class rachunek_bankowy **********************************************************************/import java.util.*;public class rachunek_bankowy extends dokument{

public int otwierac()


}}Klasa może nie mieć żadnego przodka, a może mieć jednego lub więcej. Klasę bez przodków, ale z co najmniej jednym potomkiem, nazywają się korzeniem lub klasą podstawową, a klasę bez potomków – liściem. Jeśli klasa ma jednego przodka, to mówią o dziedziczeniu pojedynczym; jeśli są ich więcej, to mówią o wielodziedziczeniu.Agregacja. Agregacja to jest hierarchia typu „part of” . Zwykla asocjacja dwóch klas (hierachia „is a”) jest związkiem strukturalnym równorzędnych partnerów. Oznacza to, że powiązane klasy znajdują się na tym samym poziomie pojęczowym, czyli żadna nie jest ważniejsza. Może się jednak zdarzyć, że trzeba zapisać związek „calość – część”, w którym jedna z klas reprezentuje większy element („calość”) składający się z mniejszych („części”). Ten rodzaj związku nazywają się agregacją, wyrażoną zależnością „ma”: obiekt – całość ma obiekty – części. Agregacja to jest szczególny przypadek asocjacji. Na diagramie jest wyróżniana przez dodanie do zwykłego symbolu asocjacji pustego rombu po stronie całości.Przykład agregacji jest pokazany na rys.11

27

Rys.11Przykład skryptów wyższe pokazanych klas w środowisku JAVA jest pokazany w listingu 5. Listing 5./*********************************************************************** Module: Firma.java Author: hadginov Purpose: Defines the Class Firma **********************************************************************/import java.util.*;public class Firma{}/*********************************************************************** Module: Dzial.java Author: hadginov Purpose: Defines the Class Dzial **********************************************************************/import java.util.*;public class Dzial{

public Firma ma;

}Taka postać agregacji ma jedynie znaczenie pojęciowe. Pusty romb wskazuje, co jest częścią, a co całością – nic więcej. Wynika z tego, że agregacja zwykła nie zmienia znaczenia „nawigacji” między całością a częściami, jak również nie wyznacza zależności między czasem życia całości a czasem życia części.Istnieje jeszcze pewien rodzaj agregacji, tak zwaną kompozycja (composition) lub agregacja całkowitą. Związek kompozycji oznacza, że

28

dana część może należeć tylko do jednej całości. Co więcej, część nie może istnieć bez całości, pojawia się i jest usuwana razem z całością. To znaczy, części o nieustalonej liczebności mogą powstawać po utworzeniu całości, ale potem żyją i umierają razem z nią. Takie części są usuwane przez śmiercią całości. Klasycznym przykładem związku typu „kompozycja” jest zamówienie i pozycja zamówienia: pozycja zamówienia nie występuje oddzielnie (poza zamówieniem), nie podlega przenoszeniu od jednego zamówienia do innego zamówienia i znika w momencie kasowania zamówienia. Kompozycja jest szczególnym rodzajem asocjacji. Na diagramie wyróżniają się przez dodanie do zwykłej asocjacji zaczernionego rombu po stronie całości. Rys.12 ilustruje zastosowanie agregacji i kompozycji.

Rys.12Każde wystąpienie obiektu „Punkt” należy albo do obiektu „Wielobok”, albo do obiektu „Okrąg”; nie może należeć do dwóch obiektów naraz. Wystąpienie obiektu „Styl” może być dzielone przez wiele obiektów „Wielobok” i „Okrąg”. Usunięcie obiektu „Wielobok” powoduje kaskadowe usunięcie wszystkich związanych z nim obiektów „Punkt”, natomiast nie powoduje usunięcia związanego z nim obiektu „Styl”. Przykład skryptów wyższe pokazanych klas w środowisku JAVA jest pokazany w listingu 6. Listing 6./*********************************************************************** Module: Wielobok.java Author: hadginov Purpose: Defines the Class Wielobok **********************************************************************/import java.util.*;public class Wielobok

29

{public Punkt ma_punkty[3..*];public Styl ma_Styl;

}/*********************************************************************** Module: Punkt.java Author: hadginov Purpose: Defines the Class Punkt **********************************************************************/import java.util.*;public class Punkt{}/*********************************************************************** Module: Styl.java Author: hadginov Purpose: Defines the Class Styl **********************************************************************/import java.util.*;public class Styl{

public int kolor;public int czyWypelniony;

}/*********************************************************************** Module: Okrag.java Author: hadginov Purpose: Defines the Class Okrag **********************************************************************/import java.util.*;public class Okrag{

public int promien;public Styl ma_Styl;public Punkt ma_centr;

}Zależność. Zależność to jest związek użycia. Zmiany dokonane w specyfikacji jednej klasy (niezależnej) mogą mieć wpływ na inną klasą (zależną), która używa pierwszą, ale niekoniecznie na odwrót. Na diagramie związek ten jest przedstawiony jako linia przerywana z grotem skierowanym na klasę niezależną. Z zależności należy korzystać wtedy, kiedy trzeba podkreślić, że obiekty klasy zależnej używają się obiekty klasy niezależnej. Najczęściej korzystają się z tego typu związków, kiedy trzeba pokazać, że jedna klasa używa drugiej jako argumentu w sygnaturze operacji. Na rys 13. jest pokazany przykład wykorzystania zależności. W tym przypadku

30

pokazano, że metoda PlayOn() klasy „FilmClip” wykorzysta obiekt klasy „Channel” jako parametr wejściowy.

Rys. 13Przykład skryptów wyższe pokazanych klas w środowisku JAVA jest pokazany w listingu 7. Listing 7./*********************************************************************** Module: FilmClip.java Author: hadginov Purpose: Defines the Class FilmClip **********************************************************************/import java.util.*;public class FilmClip{

public String name;public void start()

{// TODO: implement

}public int stop()


}public int reset()


}/** @param Parameter_1 */public int playOn(Channel c)


}

}

31

/*********************************************************************** Module: Channel.java Author: hadginov Purpose: Defines the Class Channel **********************************************************************/import java.util.*;public class Channel{}Przeciążanie przesłanianie i późne wiązanieZgodnie z polimorfizmem ta sama metoda, ale z różną implementacją, może być zdefiniowana kilka razy w hierarchii klas. Nazwy oddzielnych metod w tej hierarchii mogą być przeciążone (overloading)(перегрузка). Jeśli jest wysyłany komunikat do obiektu, to powinna być wykonana najdokładniejsza implementacja danej metody. Ta implementacja przesłania (overriding)(перекрывает) wszystkie inne możliwe implementacje. Aby zrealizować takie przesłanianie, wymagane jest późne wiązanie implementacji do wywołań metody, które powoduje odsunięcie decyzji o tym, co ma być wykonane do czasu uruchomienia.Zgodnie z zasadą enkapsulacji, powszechne jest stosowanie tych samych nazw komunikatów w różnych kontekstach. Rozważmy komunikat o nazwie WYSWIETLY, który może być przesłany do obiektów „OSOBA” oraz „SAMOCHOD” które są podklasami klasy „DOKUMENT” (Rys.14). Ten komunikat powinien być zrozumiały przez obiekty „OSOBA” w ten sposób, że wartości atrybutów osoby otrzymującej ten komunikat mają być wyświetlone w postaci tabeli. Dla obiektów „SAMOCHOD” ten komunikat musi powodować wyświetlanie trójwymiarowego rysunku.

Rys.14Na rys.15 są pokazane związki oraz relacje pomiędzy pojęciami: klasą i obiektem; metodami , komunikatami i zachowaniem obiektów; typami klas, wartościami i stanami obiektów.

32

Rys.15

Zasady reprezentacji danych w obiektowych bazach danychObiektowość w odniesieniu do baz danych łączy pojęcia z różnych dziedzin, a przynajmniej z dziedzin następujących:1. Z obszaru języków programowania: abstrakcyjne typy danych i zasada enkapsulacji,

jak również kompletność obliczeniowa języka programowania.Abstrakcyjny typ danych (abstract data type, ADT) to jest typ struktury danych skojarzony z operacjami działającymi na elementach tego typu. Bezpośredni dostęp do składowych takiej struktury danych nie jest możliwy, dzięki czemu jej szczegóły implementacyjne (np. Zestaw i reprezentacja atrybutów) są niewidoczne. Klasycznym przykładem abstrakcyjnego typu danych jest stos, wraz z operatorami takimi jak PUSH (połóż element na wierzchołku stosu), POP (zdejmij element z wierzchołka stosu), TOP (odczytaj element znajdujący się na wierzchołku stosu) i EMPTY (sprawdź, czy stos jest pusty). Po zadeklarowaniu lub utworzeniu zmiennej X jako stosu, wszelkie operacje na tej zmiennej odbywają się poprzez powyższe cztery operatory.

Kompletność obliczeniowa (Turing power) to jest charakterystyka ustalająca moc języka programowania na poziomie ustalonym przez maszynę Turinga. Język SQL ma brak kompletności obliczeniowej, bo nie zawiera takich konstrukcji jako pętli, IF... THEN...ELSE...

33

2.Z obszaru techniki oprogramowania: rozszerzalność i ponowne wykorzystanie kodu oraz zasada modularyzacji.

3. Z obszaru modelowania danych: zagnieżdżone relacje oraz uogólnienia modelu relacyjnego w powiązaniu z semantycznymi modelami danych.

Semantyczny model danych (semantic data model) to jest model danych wprowadzający pojęcia takie jak: generalizacja, specjalizacja, (generalizacja to jest przeciwieństwo do specjalizacji) asocjacja, agregacja, klasyfikacja, które ułatwiają odwzorowanie modelowanego fragmentu rzeczywistości w jej abstrakcyjny obraz pojęciowy (na prz. Model encja – związek ).W celu osiągnięcia bardziej adekwatnej reprezentacji danych obiektowa baza danych musi mieć następujące zasady:

1. Deklaracje typów są tak elastyczne jak w językach programowania.2. Obiekty mogą być identyfikowane unikatowe niezależnie od ich wartości. Muszą

służyć temu identyfikatory obiektów, umożliwiające odwołania między obiektami. Identyfikator obiektu (Object Identifier –OID) musi być przypisany do obiektu przy go stworzeniu. OID służy do odróżnienia obiektu od innych obiektów. Generacja identyfikatorów to jest funkcja Obiektowego SZBD (OSZBD).

3. Możliwe jest ponowne użycie informacji przez: Wykorzystania agregacji, która pozwoli na odwoływanie do obiektów z różnych

miejsc, a więc nowe informacje mogą być zestawiane z informacji istniejących. Inaczej mówiąc, nowe obiekty są tworzone z obiektów istniejących, które stają się składnikami i mogą być traktowane jako podobiekty (Przykład Samochód, nadwozie, silnik, skrzynia biegów to agregacja).

Wykorzystanie specjalizacji między pewnymi informacjami, co umożliwia następnie dziedziczenie struktury i zachowania.

4. Struktura modelowanych obiektów może być w razie potrzeby zagnieżdżona; różne struktury tego rodzaju mogą się wzajemnie do siebie odwoływać lub mogą być wprowadzone jako specjalizacje innych.

5. Obiekty mogą być wyposażane w zachowanie, łączące pewne operacje z tymi obiektami.

Definicje zarówno struktury bazy danych, jak i zachowania muszą być rozszerzalnymi w sensie logicznym. Oznacza to, że nawet po zakończeniu projektu bazy danych można zdefiniować i dodać nowe atrybuty i nowe operacji do istniejącego zbioru. Cecha ta umożliwia ewolucję bazy danych.

Każdy obiekt musi zawierać strukturę i zachowanie. Strukturę obiektu tworzą atrybuty, których wartościami mogą być skalar, zbiory lub odwołania do innych obiektów. Zbiór wartości obiektu tworzy stan obiektu. Zachowanie się obiektu wynika z metod, które mogą być wykonane na obiekcie.

Dostęp do stanu obiektu musi być realizowany przez przesyłanie komunikatów. Gdy obiekt otrzymuje komunikat, który rozumie, jest inicjowane wykonywanie związanej z nim metody.

34

6. Obiekty o takiej samej strukturze i takim samym zachowaniu są grupowane w klasy. Każdy obiekt jest instancją jednej klasy. Komunikaty przekazywane między obiektami są realizowane na podstawie informacji zdefiniowanych w danej klasie. Typową sekwencję występującą podczas przekazywania komunikatów jest pokazana na rys.16. Obiekt Klasy 2 wysyła komunikat Kom 2 do obiektu z klasy 1. Odbiorca sprawdza klasę, aby określić sposób reakcji na ten komunikat. Ponieważ w Klasie 1 można wykonać Kom 2, a dokładniej za pomocą Met 2, do obiektu jest przekazywana odpowiedź zawierająca tę metodę, a następne jest ona wykonywana przez obiekty.

Rys.167. Klasy są zorganizowane w hierarchię, która jest tworzona przez definiowanie

klasy jako specjalizacji jednej lub kilku innych klas. Klasy podporządkowane noszą nazwę podklas, a klasy nadrzędne – nadklas. Podklasy dziedziczą strukturę i zachowanie z odpowiednich nadklas. Jeśli podklasa ma własną strukturę i zachowanie, to zastępuje dziedziczenie.

35

Powyższe zasady charakteryzują paradygmat obiektowości, znajdujący zastosowanie w różnych kontekstach, na przykład w językach programowania, systemach operacyjnych oraz bazach danych.

Standardy obiektowe OMGObecnie zakłada się, że systemy obiektowych baz danych działają na komputerach z obiektowymi systemami operacyjnymi i współpracują z obiektowymi językami programowania. W niedalekiej przyszłości wszystkie systemy obliczeniowe będą systemami rozproszonymi, opartymi na architekturze klient – serwer. Wobec rosnącego znaczenia technologii obiektowej Obiect Management Group (OMG), duże konsorcjum przemysłowe w kierunku określenia standardów, skupił swoje działanie w dwóch obszarach: obiektowości i systemach rozproszonych. Oba obszary są traktowane jako zasadnicze dla przyszłego rozwoju przetwarzania informacji. Systemy obiektowych baz danych są skojarzone z systemami obiektowymi i systemami rozproszonymi, dlatego w ramach OMG była stworzona podgrupa ODMG, która zaproponowała standard systemów obiektowych baz danych.

Standard obiektowych baz danych ODMG 2.0ODMG(Obiect Database Management Group) to jest organizacja utworzona przez firmy rozwijające obiektowe bazy danych. Ta organizacja stawi sobie cel określenie standardów w dziedzinie obiektowych baz danych. Podstawą standardów obiektowych baz danych są ramowa architektura OSZBD, opracowana przez ODMG. Ta architektura wyznaczy ogólną ramową budowę systemu oprogramowania, który określa składowe, powiązania pomiędzy składowymi, wzajemne interakcje oraz przepływ informacji. Schemat tej architektury jest pokazany na rys. 17

36

Rys. 17Architektura ODMG 2.0 realizuje jednopoziomowy model przechowywania danych(rys. 18).Ten model nie potrzebuje przekształcenia formatu danych pamięci zewnętrznej do formatu danych w pamięci operatywnej. Dostęp do BD jest realizowany tylko z poziomu działającego programu użytkownika oraz nie jest potrzebne przekształcenie danych otrzymanych z pamięci zewnętrznej. Ten program jest stworzony przez konsolidację kodów obiektowego języka programowania, „Runtime”-procedur biblioteki klas OSZBD, Runtime procedur biblioteki klas języka programowania. Obiekty w bazie danych są przechowywane nie w tabelach relacyjnych, lecz bezpośrednio na dysku, zgodnie z ich OID.

37

Rys.18Standard ODMG definiuje następujące części realizujące założenia obiektowej architektury BD:

1. Model obiektowy. Precyzuje znaczenie podstawowych pojęć obiektowości, takich jak obiekty, klasy, metody, dziedziczenie, hermetyzacja. Ustala również podstawowe założenia dotyczące struktur danych przechowywanych przez system. Takimi strukturami są obiekty, atrybuty i związki (relationships). Klasy obiektów podlegają dziedziczeniu i hermetyzacji. ODMG wprowadza także pojęcie literału, czyli wartości, której nie można modyfikować. Istotnym założeniem modelu obiektowego ODMG jest mocna kontrola typów oraz pełna dowolność w zakresie kombinacji konstruktorów typów masowych(kolekcji), takich jak zbiór, wielozbiór, sekwencja i tablica dynamiczna.

W terminologii ODMG wielozbiór (multiset, bag) to jest jeden z konstruktorów typów klas. Wartość typu wielozbiór można dowolnie zwiększać o nowe elementy, lub usuwać elementy w niej zawarte. Porządek elementów nie ma znaczenia. W odróżnieniu od zbioru, wielozbiór może zawierać identyczne elementy, np. {1,3,3,6,3,1} jest wielozbiorem zawierającym 6 elementów, w tym dwie jedynki, trzy trójki i szóstkę. Taki wielozbiór jest równoważny np. {6,3,3,3,1,1}, ale nie jest równoważny wielozbiorowi {1,3,6}.

Sekwencja (sequence) to jest także konstruktor typów klas. Obiekt typu „sekwencja” jest kontenerom zawierającym wiele elementów. Wartość typu „sekwencja” może być dowolne rozszerzona o nowe elementy oraz można w niej usunąć elementy istniejące. W odróżnieniu od zbioru i wielozbioru, porządek

38

elementów w sekwencji ma znaczenie i jest wykorzystywany przez niektóre operatory, np. DajPierwszy, DajNastępny, DajOstatni, itp.

Tablica dynamiczna to jest kolekcja czyli konstruktor typów masowych. Tablica dynamiczna jest podobna do sekwencji, z możliwością dowolnego rozszerzania na końcu oraz z dostępem poprzez indeks wiersza tablicy.

Założenia modelu obiektowego ODMG umożliwia tworzenie obiektów o dowolnej liczbie poziomów hierarchii oraz o dowolnej złożoności. Model obiektowy ODMG jest rozszerzeniem modelu OMG CORBA.

2. Język definicji obiektów ODL (Object Definition Language). Jest wzorowany na języku IDL wg OMG CORBA. Projektant bazy danych opisuje w ODL jej strukturę. Jest to niezbędne zarówno do rozumienia znaczenia danych , jak i sposobu, w jaki są one odwzorowane w zapamiętane struktury. Schemat w ODL specyfikuje przechowywane dane na pewnym poziomie abstrakcji poprzez podanie ich typów, klas i metod, przyjmując, że tę funkcję będą skutecznie pełnić związane z nim obiektowe języki programowania (C++, Smalltalk i Java).

3. Format wymiany obiektów. Ustała reprezentację obiektów przy ich wymianie pomiędzy różnymi systemami zarządzania bazą danych.

4. Język zapytań OQL (Obiect Query Language). Jest przeznaczony do wyszukiwania danych w celu ich dalszego przetwarzania lub wyprowadzenia na zewnątrz. W odróżnieniu od SQL, OQL nie zajmuje się operacjami aktualizacyjnymi, oddelegowując je do języków programowania. OQL jest językiem o wysokim poziomie abstrakcji, deklaracyjnym (określa cel wyszukiwania, a nie akcje prowadzących do tego celu, makroskopowym (równolegle działanie na wielu obiektach) i naturalnym dla użytkowników.

5. Wiązanie do języka C++. Określa zasady połączenia ODL i OQL z językiem C++ oraz specyfikuje zestaw klas (interfejsów) umożliwiających takie połączenie. C++ jest językiem bardzo popularnym. Wadą tego języka jest wykorzystywanie cech niskiego poziomu – arytmetyki wskaźników. Wskaźnik to jest identyfikator obiektu, adres dyskowy, adres w pamięci operatywnej, który może być użyty przez kod programu jako wartość zmiennej lub atrybutu. Wskaźniki są podstawowym sposobem implementacji powiązań asocjacyjnych pomiędzy obiektami. Wskaźniki zaimplementowane w C++ wykorzystują fizyczne adresy pamięci, a nie odwołania do danych lub obiektów w sposób logiczny. To uzależni realizację aplikacji obiektowej od platformy komputerowej, oraz powoduje możliwość niebezpiecznych intencji programu w przypadkach naruszenia mechanizmów adresacji. Dlatego wskaźniki mogą być przyczyną poważnych błędów.

6. Wiązania do języków Smalltalk i Java. W języku JAVA termin „wskaźnik” jest zastąpiony terminem „referencja”. Referencja to jest identyfikator obiektu używany przez program. W odróżnieniu od wskaźnika prowadzi nie do adresu w pamięci, lecz do danej lub obiektu. Wiązania do języków Smalltalk i Java mają założenia podobne do wiązania do C++. W odróżnieniu od C++ występują inne ograniczenia. Smalltalk i Java nie mają wielodziedziczenia, co wymaga okrojenia modelu obiektowego i ODL.

39

Standard ODMG 2.0 wykazuje wady, w związku z czym nie został w pełny sposób zaimplementowany w żadnym systemu obiektowym.

Język definiowania obiektów ODLODL 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; Deklarowania atrybutów; Wyznaczenie związków; Dodawanie sygnatur operacji; Wyznaczenie list parametrów; Definiowanie wyjątków .Definiowanie interfejsów i klasFormat 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

40

};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.19Listing tej bazy w języku ODL :Interface Osoba{};interface Pracownik : Osoba{};class Student : Osoba(extent students){};class wykladowca : Pracownik(extent wykladowcy)

41

{};class kierowca : Pracownik(extent Pracownicy){}; Deklarowanie atrybutówDla 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 <typ> 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 <string> phone;key id; };Wyznaczenie związkówZwią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;

42

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

Rys. 20Deklarowanie tego połączenia w ODL w następnym listingu: Class wykladowca {// atrybutyrelationship <set> student dyplomant

inverse student ::promotor;....};class student{// atrybutyrelationship wykladowca promotor

inverse wykladowca dyplomant;…};Dodawanie operacjiFormat 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_paramNPrzykład:

43

Class wykladowca {// atrybuty// związkiboolean addStudent (in Student iStudent);Boolean removeStudent (in Student iStudent)

Raises (noSuchStudent);

Student [ ] getStudents ();…}

Serwer obiektowych baz danych firmy O2 TechnologySystem O2 został udostępniony przez firmę O2 Technology. W O2 występują pojęcia schematu bazy danych, za pomocą których są definiowane klasy i ich hierarchie. O2 zawiera obiektową wersję SQL. O2 ma architekturę klient – serwer, zawierającą następujące składowe (rys.20a): Trzon, zwany O2Engine, system niezależnej od języka bazy obiektów, która

obsługuje model obiektówO2 i administrację schematu; O2Look, graficzne narzędzie do tworzenia, prezentacji i edycji obiektów bazy

danych; O2SQL, język zapytań podobny do SQL; O2Tools, środowisko programowania z graficzną przeglądarką, edytorami,

debugerem i dokumentacją schematu; Język C++.

Rys.20a

44

O2Engine składa się z trzech poziomów. Najwyższy poziom tworzy Menedżer schematu, który jest odpowiedzialny za tworzenie, użycie, modyfikowanie i usuwanie, metod i nazw globalnych. Ponadto jego zadanie obejmuje realizację dziedziczenia i sprawdzanie spójności schematu. Poziom środkowy tworzy menedżer obiektu i organizuje operacje na obiektach, łącznie z wysyłaniem komunikatów (wywołania metod). Ponadto jest on odpowiedzialny za aspekty wewnętrzne, takie jak trwałość, struktury indeksów i grupowanie. Najniższy poziom składa się z rozwiniętego systemu WiSS (Wisconsis Storage System), który spełnia tu funkcję inteligentnego serwera dysków.Architekturę klient – serwer O2 Engine stanowi serwer stron fizycznych. Tylko najniższy poziom O2 Engine jest na serwerze (jest pokazane na rys 20a). To rozdzielenie jest możliwe, ponieważ nowoczesne stacje robocze mają dostateczne możliwości przetwarzania, aby przejąć znaczną część funkcji systemu. Zgodnie z tym podziałem serwer nie rozpoznaje obiektów. Oznacza to , że żadne zapytanie lub metoda nie mogą być wykonane bezpośrednio na serwerze.

Standard OMG CORBAStandard obiektowego modelu ODMG 2.0 jest podmnóstwem standardu CORBA(Common Object Reqest Broker Architecture). Standard CORBA jest opracowany przez OMG (Object Management Group). OMG skupi się na opracowaniu standardów współdziałania pomiędzy heterogenicznymi, rozproszonymi systemami, obiektowymi i nieobiektowymi. Obiekty, reprezentujące składowe programowe oraz stworzone zgodnie z nowymi standardami będą współdziałały w heterogenicznych środowiskach sprzętowych i programowych, wymieniając i oferując usługi oraz przekazując komunikaty w celu uruchomienia programów, wykonania obliczeń, dostępu do baz danych itp. Aby zrealizować tę wizję, należy osiągnąć dwa ważne cele: Współoperatywność, tzn. możliwość współpracy różnych części oprogramowania w

heterogenicznym i rozproszonym środowisku; Właściwa integrację nowo opracowanych i istniejących systemów.Zarządzanie obiektami rozproszonymi (Distributed Obiect Management – DOM) zgodnie z rekomendacjami OMG może być realizowane przy następnych warunkach:

1. Struktury danych i funkcjonalność systemów DOM są reprezentowane jako hermetyczne obiekty, komunikujące się drogą wysyłania komunikatów do zdefiniowanych interfejsów.

45

2. Dla aplikacji klientów jest możliwy przezroczysty dostęp do obiektów serwera bez znajomości dokładnej lokalizacji, wewnętrznej reprezentacji lub stosowanego języka dostępu.

Zarządzanie obiektami rozproszonymi łączy pojęcia modeli systemów obiektowych i rozproszonych, środowisko integracji aplikacji i obiektowe bazy danych, przedstawiając projektantowi wszystkie dostępne w sieci DOM zasoby jako zbiór dostępnych obiektów, które mogą być łączone odpowiednio do zastosowań. Schemat systemu zarządzania rozproszonymi obiektami (Distribiuted Obiect Management System – DOMS) jest pokazany na rys.21 .

Rys. 21DOMS składa się z następujących elementów: Dowolnej liczby węzłów, na których działają programy użytkowe, systemy baz

danych lub proste obiekty – są to dostępne zasoby. Zbiorów klientów, którzy również mogą być programami użytkowymi, narzędziami

programowymi lub prostymi obiektami i którzy wydają zlecenia obsługiwane przez zasoby.

Pośredników zleceń . Dostawcy usług informują ten składnik o dostępnych funkcjonalnościach. Klienci mogą zwracać się do tego pośrednika, chcąc się dowiedzieć, który z obiektów w systemie może dostarczyć żądanej usługi.

W zasadzie istnieją dwa typy pośredników: Pośrednik jest nazywany „handlowcem” (trader), jeśli jest ściśle ograniczony do

funkcji pośrednika, tzn. ustala tylko połączenia między klientem a serwerem. (patrz rys. 21.a).

Pośrednik jest nazywany brokerem, jeśli przekazuje zlecenie usługi do serwera, a później przekazuje wyniki z powrotem do klienta. Jeśli broker, do którego się zwrócono, nie może dostarczyć zleconej usługi, to może się skonsultować się z innymi brokerami. OMG popiera tą koncepcję pośrednictwa.

46

Rys. 21 aCelem rekomendacji OMG jest stworzenie modelu obiektów, który może być stosowany do obsługi integracji rozproszonych aplikacji. W zasadzie byłoby możliwe utworzenie takich aplikacji w sposób modułowy, z poszczególnymi modułami lub składnikami wywołującymi się wzajemnie za pośrednictwem zdefiniowanych interfejsów.Ogólne ramy działań OMG po realizacji DOMS są określone przez Architekturę Zarządzania Obiektami (Obiekt Management Architecture –OMA), która jest wzorcowym obiektowym modelem OMG, co pokazano na rys. 22. OMA jest wizją wysokiego poziomu kompletnego środowiska rozproszonego, składa się z czterech głównych części: Obiekty aplikacji (Aplication Objects). OMA jest ukierunkowana na aplikacje, które

są współoperatywne, przenośne i nadające się do ponownego użycia. Dlatego obiekty aplikacji są specyficzne dla poszczególnych aplikacji użytkownika końcowego i reprezentują obiekty biznesowe lub programy użytkowe działające na tych obiektach. Ten rozdaj obiektów obejmuje np. Word, Excel, i inne aplikacje użytkownika.

Pośrednik zleceń obiektów(Object Request Broker –ORB). Jest to główny składnik pośredniczący między rozproszonymi obiektami, przesyłający wywołania metod do odpowiednich obiektów docelowych i zwracający wyniki do obiektów wywołujących.

47

Wspólne usługi obiektów (Object Services). Usługi te wspierają komunikację między rozproszonymi obiektami. Obejmują one podstawowe funkcje, takie jak zabezpieczenie, przetwarzanie zdarzeń, trwałość obiektów, obsługę transakcji, zapytań, związków(asocjacji) między obiektami i inne.

Wspólne udogodnienia (Common Facilities). Tworzą one zbiór obiektów o przeznaczeniu ogólnym (np. Obsługa błędów, drukowanie, poczta elektroniczna) wymagane przez wiele aplikacji.

Rys. 22CORBA działa jako główna architektura DOM, nadająca konkretny kształt Architekturze Zarządzania Obiektami (OMA), treści, funkcjonalności i interfejsom pośrednika. Celem standardu CORBA jest uzyskanie możliwości współdziałania pomiędzy niekompatybilnymi systemami, pracującymi na różnych platformach sprzętowych i programowych, oddalonych geograficznie. Osiągnięcie tego celu wymagało zwiększenia poziomu abstrakcji w taki sposób, aby różnice implementacyjne nie miały znaczenia. Dlatego konsorcjum OMG nigdy nie poprzestawało na standardach binarnych. Ten poziom abstrakcji osiąga się poprzez opis obiektów w uniwersalnym języku IDL (Interface Definition Language), który oprócz struktury obiektów ustala także specyfikację metod działających na obiektach oraz zależności dziedziczenia. Do współdziałania konieczne jest także określenie odwzorowania (mapping) implementacji obiektów na abstrakcyjną postać implikowaną przez IDL. Temu celowi poświęcony jest adapter obiektów BOA (Basic Object Adapter). Ten adapter jest specyficzny dla wyznaczonego języka programowania. Na rys.23 jest pokazana architektura standardu CORBA oraz przesyłanie zleceń statycznych i dynamicznych pomiędzy klientem i obiektem.

48

Rys. 23Podstawowym elementem standardu CORBA jest pośrednik zamówień (Obiect Request Broker, ORB), skupiający w sobie wymienione wyżej funkcjonalności niezbędne do przetwarzania rozproszonych obiektów i współdziałania. ORB jest pośrednikiem spełniającym funkcję brokera. Broker przekazuje zlecenie usługi do serwera, a później przekazuje wyniki z powrotem do klienta. Jeśli broker, do którego się zwrócono, nie może dostarczyć zleconej usługi, to może się skonsultować z innymi brokerami. Pakiety ORB klienta i obiektu komunikują się ze sobą w sieci komputerowej przy pomocy protokółu IIOP (Internet Inter –ORB Protocol). Standard CORBA składa się w istocie z trzech części:

1. Zbioru interfejsów wywołań2. Pośrednika zamówień obiektowych (ORB)3. Zbioru adapterów obiektów.

Każdy pośrednik ORB musi mieć magazyny interfejsów oraz implementacji. Skompilowane interfejsy można odzyskiwać z magazynu interfejsów za pomocą interfejsu do pośrednika ORB. Skompilowane fragmenty programów, nazywane serwerami obiektów, które mogą implementować takie interfejsy, mogą być również rejestrowane w magazynie implementacji pośrednika ORB. Po otrzymaniu zamówień wywołań obiektu takiego serwera, pośrednik ORB potrafi ten serwer ładować i uruchamiać przez adapter obiektu.

49

W celu wydajnego ustawiania argumentów w obie strony należy posłużyć się specyficznym dla danego pośrednika ORB kompilatorem OMG IDL, który wygeneruje namiastki (Stub) i szkielety (skeleton). Namiastka wygląda jako obiekt pośredniczący, który przekazuje wszystkie wywołania od aplikacji użytkownika za pośrednictwem ORB do rzeczywistego obiektu docelowego. Szkielet odbiera informacje, dokonuje ustawienie argumentów i bezpośrednio wywołuje metodę docelową. Szkielet także akceptuje wartości zwracane i wysyła je z powrotem do namiastki. Powiązanie pomiędzy aplikacją (odwołującą się do obiektów) i implementacją obiektów może mieć charakter statyczny lub dynamiczny, w zależności od tego, czy wiązanie następuje w czasie kompilacji czy też w czasie wykonania. W przypadku statycznym, z wyrażenia IDL jest generowany automatyczne namiastek (stub), czyli fragment kodu, który jest konsolidowany z aplikacją klienta. Po stronie serwera obiektów z wyrażenia IDL generowany jest szkielet (skeleton) implementacji, który projektant musi zapełnić konkretnym kodem implementacyjnym wyspecyfikowanych metod. W przypadku dynamicznym, dostęp następuje bezpośrednio poprzez odwołania dynamiczne, na zasadzie protokołu wywołań dynamicznych DII (Dynamic Invocation Interface), analogicznym RPC.Repozytorium implementacji jest bazą danych, zawierającą informacje lub implementacje obiektów serwera, które mogą być użyte przez adapter obiektu. Może ono obejmować nazwę i lokalizację pliku przechowującego kod do wykonania dla obiektu. Natomiast repozytorium interfejsu zawiera opisy IDL znanych aktualnie interfejsów obiektów, które mogą być użyte do definiowania nowych aplikacji lub do konstruowania (przez klienta) zleceń dynamicznych.Z chwilą zarejestrowania obiektu serwera u pośrednika ORB, pośrednik „wie” jak w razie potrzeby uaktywnić ten serwer. Aby można było rozstrzygnąć, na której maszynie rozpocząć pracę serwera, każdy zarejestrowany obiekt ma swoją maszynę macierzystą, której używa się do uruchomienia serwera. Programy czysto użytkowe, które tylko wywołują obiekty, nie eksportując żadnego z własnych, nie rejestrują się u pośrednika ORB, nie mogą więc być przed niego uruchomione. System obiektowej bazy danych może być dołączony do implementacji CORBA, tak że odpowiedni ORB będzie zastosowany do zarządzania dostępami do obiektów przechowywanych w bazach danych. W ten sposób aplikacje uzyskują dostęp do baz danych przez pośrednika, a w rzeczywistości maja dostęp do wszystkich systemów baz danych dołączonych do tego pośrednika. Przy wykorzystaniu odpowiednich usług CORBA możliwy jest dostęp do wielu baz danych w ramach jednej

50

aplikacji. Podejście to ilustruje rys.24 , na którym do pośrednika jest dołączony jeden system bazy danych.

Rys. 24Wszystkie obiekty w ramach rozproszonej architektury obiektów mogą być same traktowane jako obiektowa baza danych. Z tego punktu widzenia CORBA nie jest już tylko mechanizmem komunikacyjnym, ale pełni funkcje wewnętrznego narzędzia implementacji, tzn. może występować jako system bazy danych, co pokazano na rys. 25

51

Rys. 25

Architektura Oracle Network Computing Architekture (NCA) Jako przykład narzędzia do realizacji rozproszonych systemów baz danych w standardzie CORBA posłuży decyzję firmy ORACLE. Network Computing Architekture (NCA) jest przeznaczona dla tworzenia rozproszonych środowisk oraz realizuje trzywarstwowy model „Klient – Serwer” (rys.25 a). ORACLE NCA jest uzasadniona na następnych standardach: Technologii CORBA (Common Request Broker Architekture), która jest

przeznaczona dla sterowania rozproszonymi obiektami Protokołu HTTP i języka HTML dla WEB środowiska Protokołu IIOP (Internet Inter–Object Protocol), który jest wykorzystywany przez

technologię CORBA dla współdziałania obiektów pomiędzy sobą. W środowisku Internet ten protokół jest transportowy, specyfikuje sposób wymiany komunikatów pomiędzy obiektami poprzez protokół TCP/IP. Na odmianę od protokołu HTTP, IIOP może pamiętać dane pro wywołania obiektów oraz ich połączenia.

Języka definicji interfejsu – IDL (Interface Definition Language), który jest opracowany przez OMG (Object Management Group) dla opisu interfejsów, które są niezależnymi od języka oprogramowania.

Architektura NCA zawiera obiektowy mechanizm CORBA z takimi komponentami:

52

Cartridges (nabój z ang.) - to jest biblioteka klas obiektów, która pozwoli projektantom dodawać nowe funkcji do aplikacji. To oprogramowanie może połączy się do jakikolwiek warstwy „Klient – Serwer”. Specyfikacji NCA pozwala tworzyć cartridges w dowolnym środowisku oprogramowania, np. Java, C++, itp. Wszystkie cartridges będzie pracować niezależne od systemu operacyjnego.

Protokóły oraz standardowe interfejsy, które pozwalają współdziałać pomiędzy sobą przez szyna (lub magistral) programowy ICX (Inter-Cartridge eXchange). Szyna (lub magistral) programowy to jest zbiór interfejsów oraz obiektów, które udostępniają przezroczyste różne cartridges jeden do drugiego. Każdy cartridge może odwołać do innego cartridge.

Klienci, serwery aplikacji, serwery baz danych, które są bazowymi komponentami trzywarstwowej architektury

CASE - środowisko dla opracowania oraz sterowania cartridges oraz aplikacjami.

53

Rys.25 a.

Obiektowo – relacyjne bazy danychWady modelu relacyjnego powodowały rozwój obiektowych baz danych. Obiektowe technologie modelowania danych nie wykorzystają w żaden sposób relacyjne modele danych. Główną jednostką modelu relacyjnego jest tabela, która przechowuje wszystkie dani. Głównym elementem modelu obiektowego jest obiekt z wyznaczonymi wartościami atrybutów(stanem obiektu) oraz operacjami. Klasyczny model relacyjny oraz model obiektowy są niekompatybilne.Razem z tym relacyjne modeli danych posiadają na rynku systemów baz danych mocne pozycji oraz mają dużą ilość stałych klientów. Dlatego otrzymała rozwój inna gałąź systemów baz danych zwaną systemami obiektowo – relacyjnymi. W tych systemach położono nacisk na spojrzenie

54

relacyjne, uzupełniając je pojęciami obiektowymi. Producenci oraz projektanci komercyjnych produktów relacyjnych SZBD odrzucają pretensje konkurentów - zwolenników obiektowych baz danych oraz proponują ewolucyjną zmianę istniejących systemów relacyjnych. Argumentami zwolenników relacyjnych baz danych zostały zły rezultaty efektywności poszukiwania komplikowanych zapytań w obiektowych bazach danych. Zgodnie z opinią zwolenników obiektowo relacyjnych SZBD (ORSZBD) tradycyjny mechanizm stworzenia relacji trzeba wykorzystywać oraz dopełnić go operacjami z obiektami. Główne doróbki w dziedzinie obiektowo relacyjnych baz danych zostali realizowane w opracowaniu standardu SQL3 oraz w szeregu produktów ORSZBD: Informix, DB2 (firmy IBM), Oracle-8, Sybase Adaptive Server, PostgreSQL i innych. Amerykański informatyk, profesor Stonebraker ( kierownik projektu PostgreSQL w Uniwersytecie Berkeley) zaproponował klasyfikację SZBD w zależności od złożoności schematów i rozszerzalności danych aplikacji oraz od wymóg do złożoności realizacji zapytań k tym danym. Schemat tej klasyfikacji jest pokazany na rys. 26W dolnym lewym kwadrancie są aplikacje dla obrabiania prostych danych, które nie potrzebują komplikowanych wymóg dla stworzenia zapytań. Te aplikacje wykorzystają dla przechowywania danych system plików komputera. Przykładami takich aplikacji mogą być Word, Framemaker i inne.

55

Rys. 26W dolnym prawym kwadrancie są aplikacje, które obrabiają komplikowane dani, ale nie mają dużych wymóg do stworzenia złożonych zapytań do tych danych. Te aplikacji potrzebują wykorzystania OSZBD. W górnym lewym kwadrancie są aplikacje, które realizują proste konstrukcji danych, ale potrzebują złożonych zapytań do tych danych. Do tej kategorii można odnieść aplikacje, które wykorzystają relacyjne SZBD. W górnym prawym kwadrancie są aplikacje, które potrzebują obrabiania złożonych danych oraz realizacji złożonych zapytań do tych danych. Do tej kategorii można odnieść aplikacje, które wykorzystają ORSZBD.

Język SQL-3Dowolny model danych (relacyjny czy obiektowy) łączy w sobie następne trzy aspekty:

Strukturalny, deklarujący zasady organizacji struktury bazy danych; Poprawnościowy, wyznaczający wewnętrzną poprawność danych,

zgodność z więzami integralności; Manipulacyjny, Wyznaczający zasoby do manipulowania danymi w

bazie danych. Struktura obiektowego modelu jest stworzona za dopomogą następnych konceptualnych pojęć :

Inkapsulacja

56

Dziedziczenie Polimorfizm.

Integralność obiektowego modelu bazy danych jest zrealizowana za dopomogą:

Realizacji o dziedziczenia pomiędzy klasami odpowiednich obiektów w sposób automatyczny na poziomie zarządzania OBD

Możliwością zrobić niewidocznymi oddzielnie atrybuty i metody dla innych obiektów

Stworzenia procedur kontroli wewnętrznej .Manipulacja danymi musi być zrealizowana na poziomie dowolnego języka obiektowego.Zalety OBD:

1. Naturalny sposób prezentacji danych światu rzeczywistego. W modelu relacyjnym wszystkie relacji są na jednym poziomie bez możliwości wykorzystania danych z typem hierarchicznym. To uniemożliwi się przekształcenie podobnych związków hierarchicznych modelu „Encja-związek” do modelu relacyjnego. Oprócz tego model obiektowy może być wykorzystany na różnych poziomach abstrakcji.

2. Możliwość wykorzystania dowolnych typów danych oraz metod skojarzonych z nimi.

Wady OBD:1. Są nieobecne zasoby nieproceduralne do wywołania obiektów z OBD.

Wszystkie wywołania obiektów muszą być zrealizowane przez odpowiednie procedury stworzone przez programistę. Optymalizacja tych procedur jest przełożona na programistę.

2. Są nieobecne możliwości w sposób deklaratywny definiować warunki integralności OBD :

Definicji integralności encji i odwołań za dopomogą klucze pierwotnych i obcych (przy pomocy słów kluczowych PRIMARY KEY i REFERENCES);

Tworzenia trygerów.Dla realizacji integralności OBD trzeba pisać odpowiedni kod proceduralny.

Język SQL-3 (SQL-99) jest nowym standardem języka SQL, opracowany przez ANSI (American National Standard Institute) oraz ISO. SQL-3 jest następcą i rozszerzeniem SQL-92. W założeniu, ma to być uniwersalny język programowania dla relacyjnych baz danych z elementami obiektowości. Specyfikacja SQL-3 przewiduje następne główne obiektowe rozszerzenia SQL2 (Major Object-Oriented SQL Extensions – MOOSE):

57

Rozszerzenie obecnego systemu typów SQL o abstrakcyjne typy danych (abstract data type ADT). ADT mogą być typami wartościowymi oraz typami obiektowymi. Typy wartościowe działają jako typy domenie (Domain) w SQL2. Typy obiektowe obsługują obiekty z identyfikatorem niezależnym od wartości.

W deklaracji struktury ADT mogą być zastosowane konstruktory typu sekwencja (LIST), zbiór(SET), wielozbiór (MULTISET).

Tabela może być zdefiniowana jako podtabela jednej lub kilka innych tabel (Hierarchia tabel jako forma specjalizacji).

Wywołania metod i funkcji z wnętrza wyrażenia SELECT.Te rozszerzenia włączają metody, identyfikatory obiektów, podtypy i dziedziczenie, polimorfizm i integrację z językami zewnętrznymi. Pewne usprawnienia zostały także dodane do konstrukcji definiujących tablice, typy wierszy, identyfikatory wierszy oraz mechanizm dziedziczenia. Dodatkowe udogodnienia włączają struktury sterujące i typy parametryzowane. Dzięki temu SQL-3 może zostać uniwersalnym językiem programowania do tworzenia, utrzymywania i wyszukiwania trwałych obiektów. Jednocześnie, deklarowana jest kompatybilność „w dół” ze standardem SQL-2. Każda tablica w SQL-3 ma predefiniowaną kolumnę (nazwaną IDENTITY), która zawiera identyfikatory jej wierszy. Daje to możliwość używania tych identyfikatorów w innych tablicach, czyli tworzenia ( de facto) powiązań wskaźnikowych.Abstrakcyjny typ danych (Abstract Data Types - ADT) to jest typ danych definiowany przez użytkownika. Ten typ danych także nazywa się typem danych użytkownika (User Defined Types UDT). ADT mogą być wykorzystane jako typy wbudowane (np.,CHAR, INT, FLOAT). ADT zawierają dwie kategorii: typy rozróżnione (distinct type) oraz typy strukturalne. Typem rozróżnionym jest typ uzyskany poprzez nadanie nowej nazwy dla już zdefiniowanego typu. Nowy typ jest traktowany jako oddzielny (nieporównywalny) typ. Koncepcja typów rozróżnionych jest oparta na nazwowej zgodności typów. Np. W SQL3 można podać następujące deklaracje:CREATE DISTINCT dolar_usa AS DECIMAL(9,2);CREATE DISTINCT polski_zl AS DECIMAL(9,2);Po takiej deklaracji porównanie wartości typu „dolar_usa” z wartością typu „polski_zl” powoduje błąd typu. Abstrakcyjne typy danych oznaczają, że wartości przechowywane w ramach tablic użytkownik może skojarzyć z metodami. W takim przypadku wartości te nie są dostępne bezpośrednio, lecz wyłącznie poprzez te metody (co stanowi istotę hermetyzacji). Metody mogą być pisane w SQL-3 lub w innych językach. Możliwe jest deklarowanie atrybutów obliczanych (lub inaczej, metod funkcyjnych).Przykład stworzenia nowego typu danych w SQL-3:

58

Create type Address (number char (6),street char (30),aptno integer,city char (30),state char (2),zip integer

);Przykład stworzenia tablicy z wyznaczonym typem danych:

Create table Addresses of Address;

Nowe typy danych mogą wykorzystane w kolumnach w postaci nie atomarnej. W następnym listingu jest zdefiniowana tablica „People” z nowym typem danych „Person”:Сreate table People of new type Person (

name char (30),address Address,birthdate date,

);Przykład stworzenia obiektowego typu danych:CREATE OBJECT TYPE Osoba

( Nazwisko VARCHAR (30),Wiek INT,Adresa Address);

W SQL 3 jest wyznaczony nowy typ danych Row (krotka). To jest konsekwencja elementów danych „nazwa pola / typ danych”, które mogą składać wiersz tablicy. Wartość zmiennej typu ROW potrzebuje jedną kolumnę w tabeli. Przykład wykorzystania typu Row:CREATE TABLE oddzial (

id VARCHAR (3)localaddress ROW( street VARCHAR(25),

city VARCHAR(15),pcode ROW( city_id VARCHAR(3),

part_id VARCHAR(3))));INSERT INTO oddzialVALUES (‘b01’,(‘Sniadeckich 2’, ‘Koszalin’,(‘75’, ‘453’)));Dziedziczenie może być realizowane prze frazę „under”. W poniższym listingu nowy typ „Employee” zawiera odwołanie do obiektu, który jest w tablice „Departament”. Odwołanie zawiera identyfikator (OID) jednego z obiektów tej tablicy: Create type Employee under Person (

empno char(10),dept ref(Department)

);

59

W instrukcji Create table można zdefiniować typy danych oraz metody dostępu do nowych typów danych:Create table People of new type Person (

name char(30),address Address,birthdate datefunction age(:р ref(Person)) return date;begin

current_age:=:р.birthdate-current_date;return current_age;

end; );

Architektura ORSZBD PostgreSQLPostgreSQL to jest System zarządzania bazami danych opracowany na uniwersytecie w Berkeley przez profesora Stonebrakera. ORSZBD PostgreSQL został stworzony w ramach projektów badawczych, dlatego nie jest produktem komercyjnym i może być pobierany za darmo dla wykorzystania w projektach nie komercyjnych. Może być realizowany na platformach UNIX oraz Windows. W PostgreSQL są wprowadzone następne cechy obiektowości do modelu relacyjnego: Abstrakcyjne typy danych Dani typu „Procedura” Reguły (trygery).ORSZBD PostgreSQL podtrzyma temporalny model przechowywania danych oraz dostępu do tych danych. To znaczy, że dla dowolnego obiektu, który był stworzony w moment t1 oraz został usunięty w moment t2 , w BD są przechowywane wszystkie stany tego obiektu pomiędzy momentami t1 oraz t2. Modele nie temporalne przechowają tylko ostatnie modyfikowane stany obiektów. Jakakolwiek zmiana stanu obiektu w moment t nie pozwoli odczytać dani w poprzedni moment. Architektura ORSZBD PostgreSQL realizuje model Klient – Serwer. Sesja z SZBD zawiera następne wspólnie działające procesy: Postmaster – to jest proces, który steruje wszystkimi zewnętrznymi oraz

wewnętrznymi procesami (proces – demon).Ten proces może wydzielić pamięć operatywną dla innych procesów oraz inicjalizuje procesy.

Postgres - to jest wewnętrzny proces serwera, który realizuje polecenia klienta. Postmaster zawsze inicjalizuje nowy Postgres – proces dla każdej aplikacji klienta. Ten proces może być uruchomiany tylko na serwerze.

Aplikacja klienta – to jest program, który może być uruchomiany na stacji klienta. Aplikacja może być połączona z Postgres tylko przez Postmaster.

Jeden proces Postmaster może sterować mnóstwem baz danych które są instalowane na serwerze. Aplikacja dla dostępu do bazy danych musi

60

wywołać bibliotekę funkcji API C++ LIBPQ. Za dopomogą tych funkcji polecenie klienta jest skierowano do Postmastera, który tworzy proces serwera oraz łączy aplikację z serwerem. Od tego momentu procesy klienta oraz serwera współdziałają pomiędzy sobą bez pomocy Postmastera. Postmaster jest aktywny cały czas, przy tym oczekuje polecenia na dostęp aplikacji do baz danych oraz lub na ich odłączenie. API LIBPQ C++ pozwoli aplikacji klienta zrealizować w ciągu jedną sesji dużo połączeń z serwerem BD.PostgreSQL pozwoli realizować dostęp aplikacji klientów do baz danych nie tylko w trybie lokalnym, ale i w trybie oddalonym przez protokół TCP/IP. System bezpieczeństwa ograniczy dostęp do baz danych. Użytkownik oddalony musi mieć w pliku pq_hba konto z IP adresem swojej stacji. Schemat współdziałania procesów PostgreSQL zawiera następne czynności (rys. 27):

1. Aplikacja użytkownika wywoła Postmaster przez wyznaczony socket;2. Postmaster inicjalizuje proces serwera (Postgres);3. Aplikacja łączy bezpośrednio z procesem serwera;4. Aplikacja łączy się z wielu procesami.

Rys. 27

61

Cele tworzenia UMLUML ( Unifed Modeling Language) pojawił się w latach 1994-1999, kiedy znaczne wzrosła liczba metod obiektowych. Wielu użytkowników miało kłopoty ze znalezieniem języka modelowania, który w pełni odpowiadałby ich potrzebom. UML to jest rezultat zjednoczenia metod Boocha, Jacobcona oraz Rumbaugha po modelowaniu systemów obiektowych. Język to jest zasób wyrazów i form określanych przez reguły gramatyczne, służący ludziom jako narzędzie porozumienia się. Język modelowania to taki język, w którym słownictwo i gramatyka są podporządkowane pojęciowej i fizycznej reprezentacji systemu. Główne cele stworzenia UML:1. Modelować system obiektowo – od opracowania koncepcji do wytworzenia

działającego produktu (artefaktu).2. Wskazać problemy związane ze zwiększaniem skali złożonych systemów.3. Opracować język modelowania wygodny dla ludzi i maszyn.UML bazuje się na koncepcji modelowania komponentów systemu informatycznego.

Definicja Modelu. Modelowanie prowadzi do lepszego zrozumienia systemu. Model jest uproszczeniem rzeczywistości. Model udostępnia rzuty systemu; może być planem szczegółowym lub ogólniejszym. W modelu są uwzględnione wszystkie istotne elementy, natomiast są pominięte szczegóły, które nie odpowiadają przyjętemu poziomowi abstrakcji. Każdy system może być opisany z wielu punktów widzenia za pomocą różnych modeli. Każdy model jest zatem znaczeniowo domknięta abstrakcja systemu. Wyróżniamy modele struktury, które odwzorowują statyczną budowę systemu, oraz modele zachowania, które opisują aspekty dynamiczne. Przez modelowanie osiągamy cztery cele:1. Łatwiej możemy wyobrazić sobie system taki, jaki jest, lub taki, jaki chcemy, żeby

był.2. Modelowanie umożliwia wyspecyfikowanie struktury i zachowania systemu.3. W wyniku modelowania otrzymujemy szablony, które ułatwiają sterowanie

działaniami w trakcie tworzenia systemu.4. Modele stanowią dokumentację podjętych przez nas decyzji.Modele złożonych systemów trzeba opracowywać dlatego, że nie jesteśmy w stanie ogarnąć tych systemów w całości. Zdolność człowieka do panowania nad złożonością czegoś ma swoje granice. Modelowanie umożliwia zawężenie problemu, który rozwiązujemy. Możemy wtedy skupić się na jednym jego aspekcie.

62

Budowniczowie, elektronicy i matematycy mają swój powszechnie akceptowany język. Taki wspólny język do modelowania przyda się także twórcom oprogramowania.Język to zasób wyrazów i form określanych przez reguły gramatyczne, służący ludziom jako narzędzie porozumiewania się. Język modelowania to taki język, w którym słownictwo i gramatyka są podporządkowane pojęciowej i fizycznej reprezentacji systemu. UML jest zatem znormalizowanym językiem zapisywania projektu systemu.

Ogólne cechy UMLUML to graficzny język do: obrazowania, specyfikowania, tworzenia, dokumentowaniaelementów systemów informatycznych. Umożliwia standaryzacje sposobu opracowania przekrojów systemu, obejmujących obiekty pojęciowe, takie jak procesy przedsiębiorstwa(procesy biznesowe) i funkcje systemowe, a także obiekty konkretne, takie jak klasy zaprogramowane w ustalonym języku, schematy baz danych i komponenty programowe nadające się do ponownego użycia.UML stosuje się do klasy języków, opisujących w sposób formalny modele systemów. To oznaczy, że wszystkie statyczne i dynamiczne komponenty realnych systemów są odwzorowane w modelu w sposób formalny. Pojęcie „nieformalne modelowanie” może zawierać np. werbalny opis zadania, widoki programu, raporty poleceń do systemu itp. Z badań statystycznych wynika, że większość producentów oprogramowania nie wykonuje żadnych formalnych modeli lub wykonuje ich bardzo mało. Im prostsze projekt, tym mniej prawdopodobne podjęcie formalnego modelowania. Niestety nieformalne modele nie mogą stanowić język, który może być zrozumiały projektantom oraz użytkownikom. Obrazowanie rezultatów projektowania Z punktu wzoru wielu programistów projekt systemu informatycznego to są tylko skrypty kodów programów. Oczywiście pewne sprawy najlepszej przedstawić w postaci kodu wyznaczonego tekstowego języka oprogramowania, np. C++, JAVA, Pascal, COBOL itd. Jest to najbardziej bezpośredni sposób zapisywania wyrażeń i algorytmów. W takich wypadkach programista buduje jednak pewne modele, często jedynie w swojej głowie. Takie podejście ma wady. Po pierwsze, komunikacja pomiędzy oddzielnymi projektantami całego systemu za pomocą takich modeli jest nieprecyzyjna w wypadkach, kiedy mogą być wykorzystywane

63

różne języki oprogramowania przez tych projektantów. Oprócz tego, istnieją takie aspekty systemu komputerowego, których nie da się opanować bez pomocy modeli, umożliwiających przekroczenie ograniczenia tekstowego języka oprogramowania. Tak, analizując kod wszystkich klas, można dostrzec znaczenie hierarchii, ale nie da się natychmiast zrozumieć wszystkich jej konsekwencji. Po drugie, jeśli programista nie utrwalił w jakiś sposób modeli, które powstały w jego głowie, informacje w nich zawarte przepadają na zawsze. Gdy programista przeniesie się do innej firmy, wymyślone przez niego modele można w najlepszym wypadku odtworzyć częściowo.Opracowanie modeli systemu w UML rozwiązuje problem, związany z komunikacją między członkami zespołu programistycznego: modele, formalne realizowane w sposób wizualny, wspomagają porozumiewanie pomiędzy projektantami. Pewne aspekty tego projektu najłatwiej modelować za pomocą skryptu, inne – graficzne. W komplikowanych systemach istnieją struktury, których nie da się przedstawić za pomocą języka oprogramowania. UML jest językiem graficznym. Z każdym symbolem graficznym skojarzona jest określona semantyka. Dzięki temu programista może przygotować w UML model, który będzie jednoznacznie zrozumiany przez innego programistę, a nawet przez inne narzędzie.Specyfikowanie projektuSpecyfikowanie oznacza tu opracowanie modeli, które są precyzyjne, jednoznaczne i pełne. W szczególności UML wspomaga specyfikowanie wszystkich ważnych decyzji analitycznych, projektowych i implementacyjnych, które muszą być podejmowane w trakcie wytwarzania i wdrażania systemu informacyjnego.Tworzenie skryptów projektu UML nie jest językiem programowania graficznego, ale modele w nim napisane mogą być wprost powiązane z wieloma językami programowania. Oznacza to, że można przekształcić model UML w taki język, jak JAVA, C++, Visual Basic, PowerBuilder, albo w tabele relacyjnej bazy danych lub trwałą składnicę obiektowej bazy danych. To, co najlepiej wyrazić graficzne, jest właśnie w taki sposób przedstawione w UML, podczas gdy to, co łatwo wyrazić tekstowo, jest zapisywane w języku oprogramowania.To przekształcenie umożliwia inżynierię do przodu, to znaczy generowanie kodu w języku programowania na podstawie modelu w UML. Odwrotne przekształcenie, czyli rekonstrukcja modelu na podstawie implementacji (inżynieria wstecz) także jest możliwe.

64

UML umożliwia nie tylko bezpośrednie przekształcanie modeli, ale też wykonywanie ich symulacje systemów oraz dostrajanie elementów wdrożonych systemów.Dokumentowanie projektuW poprawnym procesie tworzenia oprogramowania oprócz kodu wykonywalnego powstaje wiele artefaktów. Artefakt to jest dokument, raport lub program, który został utworzony. Są to : wymagania, architektura, projekt, kod źródłowy, plany projektu, testy, prototypy, kolejne wersje.Zależnie od różnych okoliczności niektóre z tych artefaktów w realnym projekcie mogą być opracowywane mniej lub bardziej formalnie. Wszystkie są przedstawiane na zakończenie kolejnych etapów prac. Odgrywają istotną rolę w kontrolowaniu, ocenianiu i przekazywaniu informacji o systemie między projektantami podczas procesu tworzenia. UML obejmuje dokumentowanie architektury systemu i wszystkich jego szczegółów. W UML można modelować nie tylko oprogramowanie. Za pomocą UML można projektować systemy nie związane z oprogramowaniem (np. przepływ pracy w ministerstwie, struktura i zachowanie systemu opieki zdrowotnej oraz projektowanie sprzętu komputerowego).

Model pojęciowy UMLModel pojęciowy UML zawiera trzy składniki:

1. Podstawowe bloki konstrukcyjne.2. Regule określające sposób łączenia tych bloków.3. Podstawowe mechanizmy językowe w UML.

Bloki konstrukcyjne UMLUML uwzględnia trzy rodzaje bloków konstrukcyjnych:

1. elementy (lub encji),2. związki,3. diagramy.

Elementy to jest najważniejsza abstrakcja w modelach UML, a związki to są powiązania między elementami. Diagramy służą do grupowania istotnych elementów. Elementy

65

Za dopomogą elementów można tworzyć różne modele. W UML istnieją cztery rodzaje elementów: strukturalne, czynnościowe, grupujące, komentujące.

Elementy strukturalne. Elementy strukturalne w modelach UML wyrażone rzeczownikami. Stanowią najbardziej statyczne części modelu, reprezentujące składniki pojęciowe albo fizyczne. Istnieją siedem rodzajów elementów strukturalnych.1.Klasa (Class) to opis zbioru obiektów, które mają takie same atrybuty, operacje, związki i znaczenie. Klasa realizuje jeden lub więcej interfejsów. Na diagramie jest pokazana jako prostokąt, który zwykle zawiera nazwę, atrybuty i operacje. Na rys.28 jest pokazany przykład klasy.

Rys.282. Interfejs (Interface) to jest zestaw operacji, które wyznaczają usługi oferowane przez

klasę lub komponent. Interfejs definiuje zatem zewnętrznie obserwowalne zachowywanie takiego elementu. Może reprezentować pełne zachowanie klasy lub komponentu lub jedynie część zachowania. Określa zbiór deklaracji operacji(czyli ich sygnatur), ale nigdy zbiór implementacji operacji. Interfejs jest zawsze powiązany z realizującą go klasą lub komponentem. Na diagramie jest przedstawiany jako okrąg, z nazwą obok, lub jako prostokąt, zawierający nazwę oraz metody interfejsu. Przykłady interfejsów są pokazane na rys. 29.

Rys.29

66

window

++

sizepolozenie

: int: int

+++...

open ()close ()move ()...

: void: void: void...

ISpelling

++

grammar ()lex ()

: int: int

3. Kooperacja (Collaboration) definiuje interakcję. Jest to zestaw ról i innych bytów, współdziałających w celu wywołania pewnego zachowania niemożliwego do osiągnięcia w pojedynkę. Kooperacja wiąże się zatem zarówno ze strukturą, jak i z zachowaniem modelu. Pojedyncza klasa może brać udział w wielu kooperacjach. Kooperacje reprezentują więc implementację wzorców, które składają się na system. Na diagramie są przedstawione jako elipsy o przerwanej linii brzegowej, zazwyczaj tylko z nazwami w środku.

Rys. 304 Przypadek użycia (Use case) to opis zbioru ciągów wykonywanych przez system w celu dostarczenia danemu aktorowi (Actor) godnego uwagi wyniku. Służy do określenia w modelu struktury zachowania systemu. Jest urzeczywistniany przez kooperację. Graficzne jest przedstawiany na diagramie jako elipsa o ciągłej linii brzegowej, zazwyczaj tylko z nazwą w środku (rys. 31).

Rys.315 Klasa aktywna (Active class) to jest obiekty, w skład których wchodzi co najmniej jeden proces lub wątek (Threads). Takie obiekty mogą samodzielnie rozpocząć przepływ sterowania. Klasa aktywna jest podobna do zwykłej klasy, z tym że jej obiekty reprezentują elementy działające równolegle z innymi. Na diagramie jest przedstawiona jak klasa, z tą tylko różnicą, że obramowanie prostokąta jest pogrubione.

67

rejestracja

Uzytkownik

Rys. 326. Komponent (Component) to fizyczna, wymienna część systemu, która wykorzystuje i

realizuje pewien zbiór interfejsów. W każdym systemie można spotkać wiele rodzajów wdrożonych komponentów (np. COM+ lub Java Beans), a także komponentów , będących rezultatami (artefaktami) w procesie wytwarzania (np. Pliki z kodem źródłowym). Komponent to fizyczne opakowanie elementów logicznych, takich jak klasy, interfejsy i kooperacje. Graficzne jest przedstawiany na diagramie jako prostokąt z bolcami, zazwyczaj tylko z nazwą w środku.

Rys.337 Węzeł (Node) to fizyczny składnik działającego systemu. Reprezentuje zasoby obliczeniowe. Ma zwykle pewną ilość pamięci i zdolność przetwarzania. Zbiór komponentów może się znajdować w węźle, a czasem może przemieszczać się między węzłami. Węzeł jest przedstawiony na diagramie jako sześcian, zazwyczaj tylko z nazwą w środku.

Rys.34Tych siedem omówionych elementów to podstawowe składniki zapisanego w UML modelu struktury. Istnieją także pewne warianty tych pojęć: aktorzy, sygnały i klasy funkcji usługowych (rodzaje klas), procesy i wątki (rodzaje klas aktywnych), programy, dokumenty, pliki, biblioteki, witryny i tabele (rodzaje komponentów).

68

Elementy czynnościowe.Elementy czynnościowe (Behavioral things) to dynamiczna część modelu w UML. Są wyrażone czasownikami w czasie i w przestrzeni. Wyróżniają się dwa rodzaje takich elementów.1. Interakcja (Interaction) to zachowanie polegające na wymianie komunikatów między

objektami w pewnym otoczeniu, w pewnym celu. Za dopomogą interakcji można zdefiniować zarówno zachowanie zespołu obiektów, jak i pojedynczą operacje. Składa się z wielu innych bytów, w tym komunikatów, ciągów akcji (w odpowiedzi na komunikat) i połączeń (między obiektami).

Komunikat jest przedstawiony na diagramie jako strzałka, zawsze z nazwą operacji.

Rys.352 Maszyna stanowa (State machine) określa algorytm zachowania obiektu w formie ciągu stanów, jakie obiekt lub interakcja przyjmuje w odpowiedzi na zdarzenia zachodzące w czasie ich życia. Określa też ich odpowiedzi na te zdarzenia. Za jej pomocą może być zdefiniowane zachowanie pojedynczej klasy lub kooperacji. Maszyna stanowa składa się z innych elementów, takich jak stany, przejścia (między stanami), zdarzenia (które powodują przejścia) i czynności (odpowiedzi na zdarzenia). Stan jest przedstawiany na diagramie jako prostokąt z zaokrąglonymi rogami, zazwyczaj z nazwą i podstanami (jeśli istnieją) w środku (Rys.36)

Rys.36Owe dwa elementy (interakcja i maszyna stanowa) to podstawowe składniki modelu zachowania zapisanego w UML. Zgodnie z semantyką są zwykle powiązane z różnymi elementami strukturalnymi – głównie z klasami, kooperacjami i obiektami.Elementy Grupujące.Elementy Grupujące Odgrywają w UML rolę organizacyjną. Są to bloki, na które dany model może być rozłożony. Podstawowym rodzajem tego typu elementu jest pakiet. Pakiet służy do grupowania elementów. Może zawierać elementy strukturalne, czynnościowe, a nawet inne elementy grupujące. W odróżnieniu od komponentu (który istnieje w czasie wykonania programu) jest bytem pojęciowym, to znaczy istnieje jedynie w czasie tworzenia

69

oprogramowania. Na diagramie jest przedstawiony jako skoroszyt z fiszką, zazwyczaj tylko z nazwą w środku, ale czasami też z zawartością (rys.37). Pakiety są podstawowymi elementami grupującymi, za pomocą których można usystematyzować model zapisany w UML.

Rys.37Elementy komentujące.Elementy komentujące odgrywają w UML rolę objaśniającą. Są to adnotacje, których można używać w celu opisania, uwypuklenia lub zaznaczenia dowolnych składników modelu. Podstawowym rodzajem tego typu elementu jest notatka. Jest to symbol umożliwiający skojarzenie dodatkowych ograniczeń i objaśnień z pojedynczym bytem lub grupą bytów. Na diagramie jest przedstawiana jako prostokąt z zagiętym rogiem, z komentarzem tekstowym lub graficznym w środku. (rys.38)

Rys.38Notatka to podstawowy element komentujący, który może się pojawić w modelu zapisanym w UML. Zwykle używa się jej w celu wzbogacenia diagramu o ograniczenia i objaśnienia, które najłatwiej wyrazić za pomocą formalnego lub nieformalnego tekstu.Związki w UMLW UML są uwzględnione cztery rodzaje związków:

1. Zależność,2. Asocjacja (powiązanie),3. Uogólnienie,4. Realizacja.

Zależność (Dependency) to związek semantyczny (znaczeniowy) między dwoma elementami. Zmiany dokonane w definicji jednego z tych elementów(niezależnego) mogą mieć wpływ na znaczenie drugiego (zależnego). Na diagramie związek ten jest przedstawiany jako linia przerywana, zazwyczaj z grotem i nazwą (rys. 39)

70

Rys.39Na tym rysunku jest pokazana klasa „Perpheral tester” która wykorzystuje interfejs „Peripheral”. To znaczy, że realizacji klasy„Perpheral tester” będą wykorzystali metody tego interfejsu przy odwołaniu do klas, które implementują interfejs„Peripheral”(na rys.40 te klasy nie są pokazane). Asocjacja (association) ( lub inny termin –„powiązanie”) to związek strukturalny, który określa zbiór wiązań między obiektami. Szczególnym przypadkiem powiązania jest agregacja (składanie), które wyznacza więź między całością a częściami. Asocjacja jest przedstawiana na diagramie jako linia ciągłą, z nazwą asocjacji, z nazwami oddzielnych ról i oznaczeniami liczebności (rys.)

Rys.40Uogólnienie (Generalization) to związek między dwoma bytami: ogólnym (przodek) i szczegółowym (potomek), czyli związek uogólnienie – uszczegółowienie. Obiekt bytu szczegółowego może być używany w zastępstwie obiektu bytu ogólnego. W takim związku potomek ma strukturę i zachowanie przodka. Uogólnienie jest przedstawiane na diagramie jako linia ciągła zakończona zamkniętym, niewypełnionym grotem wskazującym przodka związku (rys.41 )

Rys.41Realizacja (Realization) to jest związek semantyczny (znaczeniowy) między klasyfikatorami, z których jeden określa kontrakt, a drugi zapewnia wywiązanie się z niego. Takie związki występują najczęściej między interfejsami a klasami i komponentami oraz między przypadkami użycia a

71

kooperacjami. Na diagramie realizacja jest przedstawiona jako kombinacja symboli uogólniania i zależności (rys.42)

Rys.42Diagramy w UMLDiagram to jest schemat przedstawiający zbiór bytów. Najczęściej jest grafem, w którym wierzchołkami są elementy (encji), a krawędziami związki. Różne diagramy pozwalają przedstawić system z różnych punktów widzenia. Każdy diagram to swego rodzaju rzut systemu. Z wyjątkiem najbardziej banalnych sytuacji daje jednak niepełny obraz bytów składających się na system. Ten samy byt może się pojawić na wszystkich diagramach, lub tylko na niektórych(co się zdarza najczęściej) lub na żadnym (przypadek wyjątkowy). Istnieją dziewięć rodzajów diagramów:

1. Diagram klas,2. Diagram obiektów,3. Diagram przypadków użycia,4. Diagram przebiegu,5. Diagram kooperacji,6. Diagram stanów,7. Diagram czynności,8. Diagram komponentów,9. Diagram wdrożenia.

Przykład diagramów UML oraz ich związki jest pokazany na rys. 42a

72

Bankowy system wypłaty gotówki (bankomat)

Rys. 42aNa diagramie klas (Class diagram) mogą się znaleźć klasy, interfejsy, kooperacje i związki między nimi. Jest to najczęściej spotykany diagram w modelach obiektowych. Odnosi się do statycznych aspektów perspektywy projektowej. Diagram klas uwzględniający klasy aktywne dotyczy aspektów perspektywy procesowej.Na diagramie obiektów (Object diagram) przedstawia się obiekty i związki między nimi. Diagram ten wyobraża statyczny zrzut pewnych egzemplarzy elementów występujących na diagramie klas. Podobnie jak diagram klas, odnosi się do statycznych aspektów perspektywy projektowej lub procesowej. Na diagramie przypadków użycia (Use case diagram) przedstawia się przypadki użycia, aktorów (to jest specyficzny rozdaj klas) i związki między nimi. Diagram ten odnosi się do statycznych aspektów perspektywy

73

przypadków użycia. Przydaje się zwłaszcza do wyznaczenia i modelowania zachowania systemu.Diagram przebiegu (Sequence diagram) i diagram kooperacji (Collaboration diagram) to są rodzaje diagramu interakcji (Interaction diagram), na którym przedstawia się interakcję jako zbiór obiektów i związków między nimi, w tym też komunikaty, jakie obiekty przekazują między sobą. Diagram przebiegu obrazuje kolejność przesyłania komunikatów w czasie. Na diagramie kooperacji kładzie się nacisk na organizację strukturalną obiektów wymieniających komunikaty. Oba te diagramy są izomorficzne, to znaczy można je przekształcać jeden w drugi.Diagram stanów (Statechart diagram) przedstawia maszynę stanową składającą się ze stanów, przejść zdarzeń i czynności. Odnosi się do modelowania dynamicznych aspektów systemu. Jest szczególnie przydatny w modelowaniu zachowania interfejsów, klas i kooperacji. Przedstawia reakcje obiektów na ciągi zdarzeń i dlatego nadaje się do projektowania systemów interakcyjnych.Diagram czynności (Activity diagram) to jest szczególny przypadek diagramu stanów, który obrazuje strumień kolejno wykonywanych czynności wewnątrz systemu. Odnosi się do modelowania dynamicznych aspektów systemu. Jest bardzo przydatny w modelowaniu funkcji systemu. Kładzie się na nim nacisk na przepływ sterowania między obiektami. Diagram komponentów (Component diagram) obrazuje uporządkowanie komponentów i zależności między nimi. Odnosi się do statycznych aspektów perspektywy implementacyjnej. Ściśle wiąże się z diagramem klas, ponieważ zwykle każdemu komponentowi są przyporządkowane pewne klasy, interfejsy i kooperacje.Diagram wdrożenia (Deployment diagram) obrazuje konfigurację poszczególnych węzłów działających w czasie wykonania i zainstalowane na nich komponenty. Odnosi się do statycznych aspektów perspektywy wdrożeniowej. Wiąże się z diagramem komponentów, ponieważ zwykle każdy węzeł zawiera co najmniej jeden komponent.Diagram przypadków użycia to jeden z pięciu rodzajów diagramów UML, które służą do modelowania dynamiki systemu (pozostałe cztery to diagramy czynności, diagramy stanów, diagramy przebiegu i diagramy kooperacji). Diagramy przypadków użycia są głównym narzędziem do modelowania zachowania systemu, podsystemu lub klasy. Każdy z nich przedstawia zbiór przypadków użycia i aktorów oraz związki między nimi.Diagramy przypadków użycia służą do modelowania perspektywy przypad-ków użycia systemu, a w tym do opisywania otoczenia systemu, podsystemu lub klasy lub określania wymagań dotyczących zachowania tych bytów.

74

Diagramy przypadków użycia są szczególnie przydatne w obrazowaniu, specyfikowaniu i dokumentowaniu zachowania bytu. Dzięki nim systemy, podsystemy i klasy stają się bardziej przystępne i zrozumiałe. Diagramy te bowiem przedstawiają byt od zewnątrz.

Reguły UMLBloki konstrukcyjne UML nie mogą być połączone pomiędzy sobą na chybił trafił. Jak w każdym innym języku, tak w UML obowiązują pewne reguły określające, jak poprawny model ma wyglądać. Poprawny model powinien być wewnętrznie spójny oraz zgodny z innymi powiązanymi z nim modelami.W UML istnieją reguły semantyczne (znaczeniowe) dotyczące: Nazw – jak można nazywać elementy (encji) związki i diagramy; Zasięgu – jaki jest kontekst, który nadaje nazwie specyficzne znaczenie; Widoczności – w jaki sposób nazwy mogą być widziane i używane; Spójności – jak elementy są ze sobą logicznie powiązane i czy są właściwe. Wykonywania – co oznacza działanie lub symulowanie modelu dynamicznego.

Stereotypy w UMLJęzyk UML zapewnia standardowe środki wyrazu przydatne do zapisywania projektu systemu. Należy jednak pamiętać, że nie ma tak uniwersalnego języka, w którym dałoby się wyrazić wszystkie możliwe niuanse każdego modelu dowolnego systemu w każdej dziedzinie zastosowania i w każdym czasie. Z tego właśnie powodu UML jest językiem otwartym. Można go rozszerzać, ale w kontrolowany sposób. Takim sposobem mogą wystąpić stereotypy. Stereotyp umożliwia rozszerzanie słownictwa UML. Można tworzyć nowe bloki konstrukcyjne, wywodzące się z tych już istniejących, ale specyficzne dla danego zadania. Stereotyp to jest mechanizm kategoryzacji elementów. W językach C++ oraz JAVA wykorzystują się wyjątki. W tych językach są one klasami, choć traktowanymi w szczególny sposób. Wyjątki muszą być zgłaszane i obsługiwane. Dla obrazowania elementów wyjątków w modelu mogą być wykorzystywane standardowe bloki konstrukcyjne klas stereotypem <<exception>>. Przykładem wykorzystania stereotypu jest interfejs. Interfejs obejmuje tylko operacje, bez atrybutów. Jest to zestaw operacji, które można wielokrotnie wykonywać w modelu. Zamiast wymyślać nowy element reprezentujący interfejs, można użyć ikony klasy z napisem <<Interfejs>> umieszczonym nad nazwą klasy.

75

Architektura systemu informatycznegoObrazowanie, specyfikowanie, tworzenie i dokumentowanie systemu informatycznego wymaga podejścia do niego z kilku punktów widzenia. Różni uczestnicy procesu projektowania patrzą na zadanie z innej perspektywy i na innym etapie jego życia. Można wyznaczyć następne kategorii projektantów: użytkownicy, analitycy, programiści, specjaliści od integracji systemu, osoby wykonujące testy, autorzy dokumentacji technicznej, kierownicy projektu. Każdy z tych kategorii projektantów ma swój punkt widzenia oraz może wnieść do projektu nowe decyzji. Architektura systemu to jest najważniejszy artefakt, jaki może być wykorzystany do zapanowania nad wszystkimi punktami widzenia. Umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura to zbiór znaczących decyzji dotyczących: Organizacji systemu komputerowego, Wyboru elementów strukturalnych i ich interfejsów, z których system jest

zbudowany, Zachowania tych elementów, opisanego w kooperacjach, Składania elementów strukturalnych i czynnościowych w coraz większe podsystemy, Stylu architektonicznego, według którego tworzy się konstrukcję systemu, to znaczy

charakterystycznych elementów statycznych, i dynamicznych oraz interfejsów, kooperacji i składania.

Architektura oprogramowania dotyczy nie tylko jego struktury i zachowania, ale także stosowania go, jego funkcjonalności, efektywności, odporności, możliwości ponownego użycia, ograniczeń ekonomicznych i technologicznych oraz estetyki. Na rys.43 jest przedstawiony sposób zobrazowania architektury systemu informatycznego – pięciu powiązanych ze sobą perspektyw. Każda z nich dotyczy organizacji i struktury systemu, ale w każdej z nich kładzie się nacisk na pewien ustalony aspekt systemu.

76

Rys.43W Perspektywie przypadków (Use case view) użycia bierze się pod uwagę zachowanie systemu widziane oczyma użytkowników, analityków i osób wykonujących testy. Nie definiuje się rzeczywistej organizacji systemu, a opisuje się czynniki wpływające na kształt architektury systemu. W UML aspekty statyczne tej perspektywy wyraża się za pomocą diagramów przypadków użycia, a dynamiczne za pomocą diagramów interakcji, diagramów stanów i diagramów czynności.W Perspektywie projektowej (Design view) kładzie się nacisk na klasy, interfejsy i kooperacje, które razem składają się na słownictwo danego zadania i na rozwiązania tego zadania. Perspektywa ta pomaga w zapisywaniu wymagań funkcjonalnych, czyli usług, które system powinien udostępniać swoim użytkownikom. W UML aspekty statyczne tej perspektywy wyraża się za pomocą diagramów klas i diagramów obiektów, a dynamiczne za pomocą diagramów interakcji, diagramów stanów i diagramów czynności.W Perspektywie procesowej (Process view) zwraca się uwagę na wątki i procesy, które kształtują mechanizmy współbieżności i synchronizacji w systemie. Dotyczy ona głównie efektywności, skalowalności i przepustowości systemu. W UML aspekty statyczne i dynamiczne tej perspektywy są przedstawiane na takich samych rodzajach diagramów jak w wypadku perspektywy projektowej, z tą tylko różnicą, że główny nacisk kładzie się na klasy aktywne, które reprezentują procesy i wątki.W Perspektywie implementacyjnej (Implemetation view) znaczenie mają komponenty i pliki, użyte do scalenia i udostępnienia systemu fizycznego. Wiąże się ona z zarządzaniem konfiguracją poszczególnych wersji systemu,

77

złożonych z rozmaitych niezależnych komponentów i plików, które można zespolić na wiele sposobów, aby otrzymać działający system. W UML aspekty statyczne tej perspektywy wyraża się za pomocą diagramów komponentów, a dynamiczne za pomocą diagramów interakcji, diagramów stanów i diagramów czynności.W Perspektywie wdrożeniowej (Deployment view) kładzie się nacisk na węzły, składające się na sprzęt, na którym system będzie uruchamiany. Wiąże się ona głównie z rozmieszczeniem, dostarczeniem i instalacją części systemu fizycznego. W UML aspekty statyczne tej perspektywy wyraża się za pomocą diagramów stanów i diagramów czynności.Każda z tych pięciu perspektyw jest autonomiczna. Poszczególni uczestnicy projektowania systemu informatycznego mogą skoncentrować się na tym fragmencie architektury systemu, który ich najbardziej interesuje. Perspektywy ściśle się ze sobą wiążą. Np. Węzły w perspektywie wdrożeniowej zawierają komponenty z perspektywy implementacyjnej, które z kolei reprezentują fizyczną realizację klas, interfejsów, kooperacji i klas aktywnych z perspektywy projektowej i procesowej. UML umożliwia zatem wyrażenia każdej z tych perspektyw i ich wzajemnych oddziaływań.

Życiowy cykl tworzenia systemu informatycznegoUML jest w zasadzie niezależny od przyjętych procedur projektowych, co oznacza , że nie jest dostosowany do jakiegokolwiek szczególnego cyklu tworzenia oprogramowania. Przynosi jednak największe korzyści w procesie, który jest: Ukierunkowany na przypadki użycia systemu, Architekturocentryczny, Iteracyjny i przyrostowy (inkremencyjny).W procesie ukierunkowanym na przypadki użycia systemu, to właśnie one służą do określania pożądanego zachowania systemu, do weryfikacji i atestowania jego architektury oraz do testowania go. Są także wykorzystywane w porozumiewaniu się członków zespołu programistycznego między sobą.W procesie architekturocentrycznym właśnie architektura jest najważniejszym artefaktem używanym do wyrażenia koncepcji tworzonego systemu, konstruowania go, zarządzania nim i do rozwijania go.Plonem procesu iteracyjnego jest ciąg kolejnych działających wersji systemu. Proces przyrostowy polega na systematycznym dopełnianiu architektury systemu w celu utworzenia tych wersji, przy czym każda z nich zawiera pewne nowe składniki i ulepszenia, które nie występują w wersji poprzedniej. Proces iteracyjny i przyrostowy zarazem jest jednocześnie

78

procesem sterowanym ryzykiem (Risk – driven), ponieważ przy tworzeniu każdej nowej wersji kładzie się nacisk na wyeliminowanie czynników, które najbardziej zagrażają powodzeniu na danej iteracji. Proces ukierunkowany na przypadki użycia systemu, architekturocentryczny, iteracyjny i przyrostowy można podzielić na etapy lub fazy (Phase). Etap to jest okres między kolejnymi głównymi kamieniami milowymi procesu, w którym zostały osiągnięty pewne ściśle ustalone cele, ukończone produkty pracy i podjęto decyzje o przejściu do następnego etapu.

Diagramy klas (Class diagram)Diagram klas obrazuje pewien zbiór klas, interfejsów i kooperacji oraz związki między nimi. Jest grafem złożonym z wierzchołków i krawędzi. Diagramów klas używa się do modelowania statycznych aspektów perspektywy projektowej. Diagramy przypadków użycia to są dynamiczne aspekty. Wiąże się z tym w głównej mierze modelowanie słownictwa systemu(dziedziny problemu), kooperacji lub schematów. Diagramy klas stanowią bazę wyjściową dwóch innych diagramów, a mianowicie diagramów komponentów i diagramów wdrożenia.Diagramy klas zawierają następujące elementy: klasy, interfejsy, kooperacje, zależności, uogólnienia i powiązania.Na diagramach klas mogą się znaleźć również pakiety lub podsystemy, używane do grupowania elementów modelu. Diagramy klas mogą być w dwóch postaci: Diagramy klas konceptualnych dziedziny problemu Diagramy klas modelu projektowania.UML nie zawiera odrębnych artefaktów dla projektowania tych diagramów. Dla tych dwóch diagramów są wykorzystywane te same narzędzie oraz jeden artefakt „Diagram klas”.

Modelowanie dziedziny problemuDziedzina problemu (problem domain) (lub dziedzina przedmiotowa, słownictwo systemu) to jest fragment świata rzeczywistego będący przedmiotem rozważań przy obiektową analizie i projektowaniu systemu informacyjnego. Głównej składnią tej analizy musi być dekompozycja problemu na oddzielnie klasy pojęć lub klasy konceptualne. Modelowanie dziedziny problemu powoduje wszystkim innym etapom modelowania.

79

Model dziedziny problemu to jest przedstawienie wizualne klas konceptualnych zgodnie z pojęciami tej dziedziny. Klasa konceptualna to jest pojęcie światu rzeczywistego. Te klasy muszą być głównymi wśród wszystkich pojęć i abstrakcji dziedziny modelowania oraz składać się słownictwo systemu. W klasach konceptualnych nie jest wyznaczone zachowanie systemu. Pojęcia, kategorii i abstrakcji tego słownictwa muszą być wykorzystywane w opisu scenariuszy diagramów przypadków użycia oraz innych diagramów dynamicznych. W ten sposób realizują się związki między modelami statycznymi i dynamicznymi. W odróżnieniu od klas konceptualnych klasy programowe (klasy projektowania) to są specyfikacji lub realizacji komponentów systemu, które odwzorowują zachowanie systemu, np. Okna dialogowe, Interfejs z bazą danych itp.W UML słownictwo systemu prezentuje się w wyglądu zbioru diagramów klas, na których nie jest koniecznym zdefiniowanie operacji oraz atrybutów. Model dziedziny problemu nie jest diagramem klas lub komponentów programowych, z tego modelu nie można wygenerować kod. Ostatecznie definiowanie atrybutów oraz operacji klas będzie zrealizowano na kolejnych etapach modelowania obiektowego przy projektowaniu diagramów interakcji oraz diagramów klas. Model dziedziny problemu może odwzorować następne elementy: Konceptualne klasy. Związki semantyczne między konceptualnymi klasami. Atrybuty konceptualnych klas.Przy projektowaniu modelu dziedziny problemu, kolejnej analizie i wyznaczeniu przypadków użycia mogą być realizowano kilka iteracji. Model dziedziny problemu musi być uściślony na każdej z tych iteracji. Przy tym, mogą być zdefiniowane nowe konceptualne klasy, atrybuty, związki semantyczne. Przykład modelu dziedziny problemu jest pokazany na rys.44 . Ten model jest stworzony dla modelowania systemu informacyjnego sprzedaży artykułów w sklepie. Scenariusz zakupu - sprzedaży może mieć następny wygląd:

1. Klient(Customer) wchodzi do sklepu (Store), wybiera towary (item) oraz idzie do aparatu kasowego(register).

2. Kasjer (Cashier) odkrywa nowy zakup (Sale).3. Kasjer odczyta identyfikator towaru i wprowadzi go do systemu

informacyjnego.4. System informacyjny odczyta nazwę odebranego towaru, go opis(description) i

cenę(price). Kasjer powtórzy czynności p.3,4 dla każdej pozycji towaru (SalesLineItem).

80

5. Kasjer informuje klienta pro wartość wypłaty (Payment) i otrzymuje pieniędzy.6. Klient płaci się oraz system modyfikuje dani sklepu zgodnie z rezultatami

zakupu.7. System rejestruje zakup w rejestrze(Register) sklepu.8. System drukuje paragon .

Rys.44

Pomiędzy klasami konceptualnymi mogą być ustalone związki, kiedy niema wątpliwości odnośnie realizacji programowej tych klas. W klasach mogą być ustalone atrybuty, kiedy one są oczywistymi. W przypadkach, kiedy nie do końca jasnym jest zachowanie klasy oraz czy musi być obiekt rzeczywisty klasą lub atrybutem, lepiej zostawić klasy konceptualne w ogóle bez związków oraz obiekty rzeczywiste w postaci klasy.Na rys. 44 a jest pokazany fragment modelu dziedziny problemu razem ze związkami pomiędzy klasami konceptualnymi.

81

Rys. 44 aKlasy konceptualne modelu dziedziny problemowej mogą być wyznaczone różnymi sposobami. Rozpowszechnionymi sposobami wyznaczenia klas konceptualnych są sposoby:

1. Wydzielenie rzeczowników z opisów scenariuszy przypadków użycia.2. Wykorzystanie listy kategorii klas konceptualnych.3. Wykorzystanie wzorców analizy dziedziny problemu.4. Analiza dziedziny problemu za dopomogą kart CRC.

Przykład wydzielenia rzeczowników z opisu scenariuszu przypadków użycia jest pokazany wyżej. Przez czcionkę grubą są pokazane rzeczowniki. Rzeczowniki z tego opisu mogą być klasami konceptualnymi, ale to nie jest koniecznie. Rzeczowniki w tym opisu mogą wystąpić jako atrybuty konceptualnych klas lub klasami i atrybutami klas z innych podsystemów. Trzeba szczególnie analizować każdego pretendenta klasy konceptualnej. Wadą tego sposobu jest także to, że język naturalny może mieć niejednoznaczne pojęcia w swoich definicjach. Tak, dla opisu tej samej klasy konceptualnej mogą być wykorzystywane różne rzeczowniki oraz niektórzy rzeczowniki mogą mieć wiele różnych wartości. Niemniej ten sposób pozwoli otrzymać informacje dla analizy modelu dziedziny problemu. Wykorzystanie listy kategorii klas konceptualnych potrzebuje poprzedniego stworzenia listy kategorii. Przykład list kategorii klas konceptualnych dla

82

dziedzin „Sprzedaży – zakupu” oraz „Zarezerwowania biletów lotniczych” jest pokazany w tabeli.

Tabela. Kategoria klas konceptualnych

Dziedzina problemu „System sprzedaży – zakupu towarów”

Dziedzina problemu „System rezerwowania biletów na samoloty”

Obiekty fizyczne Register (rejestr), tablica zamówień

Airplane (samolot)

Specyfikacji, opisy obiektów

ProductSpecification (opis towaru)

FightDescription (opis polotu)

Placówki Store (Sklep) Airport (lotnisko)Transakcji Sale (zakup), Payment

(wypłata), Zamówienie Reservation (rezerwowanie)

Elementy transakcji SalesLineItem (element zakupu), dostawa

Roli Cashier (kasjer) Pilot Kontenery innych obiektów Store (Sklep), koszyk,

ZamówienieBin (bunkier), Airplane(samolot)

Zawartość kontenerów Item (element) Passenger (pasażer)Systemy zewnętrzne CreditPaymentAutorization

System (system autoryzacji wypłaty kredytowych)

AirTrafficControl (system sterowania ruchem samolotów)

Działy, organizacje SalesDepartment (dział sprzedaż)

ObiectAirline (linii lotnicze)

Zdarzenia Sale (Sprzedaż), Payment (wypłata)

Flight (polot), Crash (awaria), Landind (lądowanie)

Reguły RefundPolicy (reguły powrotu towaru)

CancellationPolicy (reguły anulowania zamówienia)

Katalogi ProductCatalog (katalog towarów), PartsCatalog (katalog części)

Wydruki, notatki, zapisy Receipt (paragon), Ledger (książka księgowa)

Maintenancelog (dziennik obsługiwania)

Usługi finansowe LineOfCredit(linia kredytowa)

LineOfCredit(linia kredytowa)

Stworzenie modelu dziedziny problemu zawiera następne czynności:1. Wyznaczenia listy pretendentów klas konceptualnych.2. Graficzne odwzorowanie klas konceptualnych.3. Dodawanie asocjacji, które odwzorowują związki semantyczne.4. Dodawanie atrybutów, które wyznaczają wymogi informacyjne.

Przy wyznaczeniu atrybutów modelu dziedziny problemu trzeba postępować zgodnie z następnymi rekomendacjami:

83

1. Do modelu dziedziny problemu trzeba dodawać tylko te atrybuty, dla których są wyznaczone wymogi w scenariusze przypadków użycia lub dla których trzeba przechowywać informację. Np. każdy paragon musi zawierać datę oraz czas sprzedaży, dlatego w klasie konceptualną „Sale” są wyznaczone atrybuty „date” i „time”. W ogóle klasy konceptualne mogą nie zawierać atrybutów.

2. Typy atrybutów muszą być podstawowymi typami danych oraz nie zawierać typów obiektowych. W przypadkach, gdy atrybut klasy konceptualnej jest typem obiektu innej klasy, trzeba do modelu dziedziny problemu dodać nową klasę oraz wyznaczyć związki semantyczne między klasami. Ta rekomendacja jest ilustrowana rys. 45

Rys.453. Liczebność asocjacji nie jest konieczna w modelu dziedziny problemu.4. Operacji do klas konceptualnych można dodawać tylko po analizie przypadków

użycia.5. Nazwy klas konceptualnych muszą odwzorować semantykę dziedziny problemu.

Analiza dziedziny problemu za dopomogą kart CRCDla wyznaczenia zobowiązań klas obiektów oraz dla definicji związków między klasami można wykorzystać karty CRC (Class-Responsibility-Collaborator cards) (klasa – odpowiedzialność – współpraca ). Karta ta jest rekwizytem metody, mającej na celu wyjaśnienie konceptualnych klas obiektów w systemie oraz ich asocjacji. Kartę taką zapełnia się dla każdej klasy. Wewnątrz karty wpisuje się nazwę klasy, określa się związek tej klasy z procesami zachodzącymi w danej dziedzinie przedmiotowej (odpowiedzialność), oraz określa się związek tej klasy z innymi klasami(współpraca). Przykład CRC kart dla dziedziny przedmiotowej „Sprzedaż towarów” jest pokazany w tabelach . Karty CRC muszą mieć ograniczony rozmiar fizyczny (6 x 10 cm). To powoduje koncentrację tylko istotnych operacji w każdą klasie. W przypadkach kiedy operacji w klasie za dużo trzeba stworzyć nową klasę. Metoda CRC kart najczęściej jest wykorzystana w przypadkach „burzy mózgów”.

84

Class: Sale (Zakup)Responsibility (odpowiedzialność) Collaborator (współpraca)1.Stworzenie pozycji zakupu Register,SalesLineItem2.Obliczenie wartości zakupu SalesLineItem, Register3.Rozrachunek z klientem Register, Payment

Class:Register (Rejestracja)Responsibility (odpowiedzialność) Collaborator (współpraca)1. Stworzenie nowego zakupu Sale2. Dodawanie pozycji zakupu Sale, Store 3. Wyznaczyć cenę zakupu Sale4. Wyznaczyć resztę Sale5. Przechować zakup w bazie danych Sale, Store

Class: Store (Sklep)Responsibility (odpowiedzialność) Collaborator (współpraca)1. Wyznaczyć cenę i opis towaru przez ID

Register, Item

2. Przechować zakup w bazie danych Register

Class:Item (artykuł)Responsibility (odpowiedzialność) Collaborator (współpraca)1. Otrzymać cenę i opis towaru z BD Store

Class:SalesLineItem (pozycja towaru)Responsibility (odpowiedzialność) Collaborator (współpraca)1. Obliczyć wartość pozycji zakupu Sale, Item

Class:Payment (Zakup)Responsibility (odpowiedzialność) Collaborator (współpraca)1. Obliczyć resztę Sale

Diagramy klas modelu projektowania Diagram klas modelu projektowania ilustruje specyfikacji programowych klas oraz interfejsów aplikacji. Taki diagram zawiera następną informację: Klasy, asocjacji i atrybuty klas Interfejsy z operacjami oraz konstantami Metody klas Informację o typach atrybutów Sposoby nawigacji Zależności.

85

Diagramy klas konceptualnych (słownictwo systemu) odwzorowują pojęciowe byty. W odróżnieniu od diagramów klas konceptualnych diagramy klas projektowania odwzorowują definicji tylko realizacji programowych. Żadna klasa nie może istnieć w izolacji. Każda klasa działa w kooperacji z innymi, żeby zrealizować zadania niemożliwe do wykonania w pojedynkę. Oprócz utrwalenia słownictwa systemu trzeba wyznaczyć sposoby współpracy wszystkich elementów wymienionych w słowniku. Diagram klas jest przeznaczony dla tych celów. Każdy diagram klas modeluje jedną kooperację systemu. Modelowanie kooperacji musi być realizowane zgodnie z podanymi wytycznymi: Identyfikacja przypadku użycia, który trzeba modelować. Przypadek użycia jest

pewną funkcją lub zachowaniem części modelowanego systemu. Te zachowanie jest wynikiem interakcji zestawu klas, interfejsów i innych elementów.

Dla każdego przypadku użycia trzeba wyznaczyć klasy, interfejsy i inne kooperacje, które biorą udział w rozważanej kooperacji. Dla tych elementów trzeba ustalić związki. Ten samy element może uczestniczyć w wielu kooperacjach.

Trzeba skorzystać się ze scenariuszy przypadków użycia, aby sprawdzić diagram oraz wyznaczyć brakujące elementy.

Dla każdej klasy trzeba wyznaczyć zobowiązania, które muszą być przekształcone w atrybuty i operacje. Zobowiązanie to jest usługa lub zbiór usług, które są prezentowane przez klasę.

Na rys.46 przedstawiony jest zbiór klas z implementacji robota. Na diagramie położono nacisk na klasy realizujące przemieszczanie się robota po pewnej trasie. Diagram zawiera klasę abstrakcyjną (silnik) z dwoma potomkami „SilnikSterujacy” i „SilnikGlowny”. Obie klasy dziedziczą operacji po swoim przodku – klasie „Silnik”i zarazem są częściami innej klasy „Napęd”. Klasa „Wykrywacz trasy” jest w związkach jeden – do – jeden z klasą „Napęd” i jeden – do – wielu z klasą „wykrywaczKolizji”. Na diagramie nie ma atrybutów ani operacji klasy „Wykrywacz trasy”, ale są jej zobowiązania. Każda z tych może występować w innych diagramach, na których mogą być nowe klasy oraz związki z tymi klasami.

86

Rys.46

Dekompozycja na klasy w modelu projektowaniaPrzy wyznaczeniu przypadków użycia i stworzeniu modelu dziedziny przedmiotowej trzeba wyznaczyć obiekty programowe, które będą uczestniczyć w modelu projektowania. Te obiekty są realnymi obiektami programu. Obiekty programowe muszą być stworzone na bazie klas dziedziny przedmiotowej z wykorzystaniem nowych stereotypów klas, które realizują funkcji aplikacji. Na rys. 46a jest pokazany schemat stereotypów klas, które mogą być użyte w modelu projektowania.

Rys.46a

87

Dla wyznaczenia struktury klas programowych jest bardzo przydatny model architektury MVC (Model – View - Controller) . Główna idea architektury MVC polega w sprowadzeniu do minimum związków pomiędzy klasami programowymi. Dla każdej klasy trzeba wyznaczyć zobowiązania zgodnie z następnymi stereotypami: <<Model>>, <<View>>, <<Controller>>.Klasy stereotypu <<Model>> są przeznaczone dla przechowywania danych w bazie danych oraz dla realizacji dostępu do nich. Obiekty tej klasy mogą otrzymywać polecenia od obiektów klasy <<View>>, formować odpowiedzi, oraz komunikaty pro swoje stany. Klasy stereotypu <<Controller>> są przeznaczone dla modyfikacji obiektów <<Model>>. Te modyfikacji są realizowane zgodnie z logiką aplikacji w odpowiedź na czynności użytkownika (np., naciśnięcie przycisków, przesyłanie formularza itp.). Oprócz tego obiekt <<Controller>> informuje obiekt <<View>> co trzeba odwzorować w odpowiedź na czynności użytkownika.Klasy stereotypu <<View>> są przeznaczone za odwzorowywanie danych otrzymanych od obiektów klasy <<Controller>>Schemat architektury MVC jest pokazany na rys.47 Przykładem realizacji MVC może być aplikacja zegarka o następnej architekturze: Klasa <<Model>> jest odpowiedzialna za pomiary czasu. Ta klasa zawiera metodę,

która komunikuje pro czas w odpowiedz na polecenie od klasy <<View>>. Klasa <<Controller>> modeluje mechanizm dla ustalenia wartości czasu. Klasa <<View>> wyznacza formę zegarka.

Rys. 47

88

Diagramy przypadków użycia (Use Case diagram)Przypadek użycia (Use Case) to jest konstrukcja, która pomaga analitykowi wspólnie z użytkownikami określić, jak system ma być używany. Zbiór przypadków użycia opisuje system za pomocą pojęć określających, co użytkownicy zamierzają z nim robić.Każdy przypadek użycia to jest zbiór scenariuszy opisujących używanie systemu. Każdy scenariusz to jest ciąg zdarzeń. Każdy ciąg jest inicjowany przez osobę, przez inny system, przez jakieś urządzenie lub upływ czasu. Byty, które inicjują ciąg zdarzeń, nazywają się aktorami. Rezultatem zainicjowanego ciągu jest coś, co służy aktorowi, który dokonał inicjacji, albo innemu aktorowi.Diagram klas jest narzędzie projektanta systemu, odwzorowujące system z punktu widzenia tego projektanta. Użytkownikom często trudno wyrazić słowami, w jaki sposób zamierzają korzystać z systemu. Tworzenie przypadków użycia to jest wspólne działanie użytkowników oraz projektantów. Podstawą omawianego działania jest skłonienie użytkowników do udziału we wczesnym stadium analizowania i projektowania systemu. Zwiększa to prawdopodobieństwo, że system ostatecznie stanie się przydatnym i przyjaznym narzędziem. Diagramy przypadków użycia – diagram czynnościowy służący do obrazowania zachowania systemu w taki sposób, aby użytkownicy mogli zrozumieć jak z niego korzystać. Na ogół zawierają one takie elementy jak: przypadki użycia, aktorzy, zależności, uogólnienia i asocjacji (powiązania).Za pomocą diagramów przypadków użycia dokonuje się:

modelowania otoczenia systemu (wyznaczenie granicy wokół całego systemu i na wskazaniu leżących poza nim aktorów);

modelowania wymagań stawianych systemowi (określenie co system powinien robić, niezależnie od tego jak ma to robić - znane jest otoczenie i sposób porozumiewania się z systemem, ale nie jego wnętrze).

Każdy oddzielny przypadek użycia (element Use Case) odwzorowuje wyznaczony aspekt funkcji systemu. Wszystkie elementy Use Case składają się pełny zbiór tych funkcji. Ten sposób dekompozycji pozwala opracować elementy Use Case dla różnych funkcji, oraz potem zjednoczyć ich razem. To znaczy, że w każdy wyznaczony moment czasu można skupić się na jednym problemu oraz realizować równolegle projektowanie różnych części systemu. Każdemu zadaniu użytkownika może odpowiadać oddzielny przypadek użycia. Modelując otoczenie systemu należy postępować zgodnie z podanymi wytycznymi:

89

1. Zidentyfikować aktorów działających wokół systemu:W tym celu należy rozważyć, które grupy:

potrzebują pomocy systemu do realizacji swoich zadań, są niezbędne do realizacji systemu, są w interakcji z urządzeniami zewnętrznymi, wypełniają drugorzędne funkcje,2. Należy uporządkować podobnych aktorów za pomocą uogólnień.3. Dla zwiększenia czytelności modelu można (jeżeli trzeba) dodać stereotypy do

aktorów.4. Umieścić zdefiniowanych aktorów na diagramach przypadków użycia i

zdefiniować powiązania z przypadkami użycia.Modelowanie otoczenia systemu jest przydatne przy tworzeniu złożonych systemów z wzajemnie powiązanymi podsystemami. Modelując wymagania stawiane systemowi należy postępować zgodnie z podanymi wytycznymi:

1. Określić otoczenie systemu i zidentyfikować otaczających go aktorów;2. W przypadku każdego aktora należy rozważyć działania, których on oczekuje lub

wymaga od systemu i zapisać te działania w postaci przypadków użycia;3. Wyselekcjonować powtarzające się fragmenty działań i utworzyć z nich nowe

przypadki użycia, które będą dołączane prze inne przypadki użycia;4. Wydzielić warianty działań i umieścić je w nowych przypadkach użycia, które

rozszerzają główne ciągi zdarzeń innych przypadków użycia;5. Do modelowanego systemu można dołączyć notatki określające wymagania

niefunkcjonalne;

Wymogi do scenariuszy przypadków użycia Przypadki użycia to są wymogi funkcjonalne do systemu informatycznego. Przypadek użycia opisuje, co system robi, ale nie określa, jak to robi. Wymogi mogą mieć werbalny oraz formalny kształt. Opisy przypadków użycia mogą być realizowane przez: ciągi zdarzeń scenariusze.Zapisując ciąg zdarzeń, trzeba uwzględnić informację o tym, jak i kiedy przypadek użycia zaczyna się i kończy, kiedy dochodzi do jego interakcji z aktorami i jakie obiekty są przekazywane. Należy także podać główny ciąg zdarzeń i inne, alternatywne.Zazwyczaj na początku ciąg zdarzeń przypadku użycia opisuje się tekstowo przez scenariusze. UML pozwoli stworzyć werbalne oraz formalne opisy wymóg do systemu informatycznego, które mogą być przechowywane w specyfikacji każdego przypadku użycia. Formalny sposób opisu może być realizowany przez diagramy interakcji (przebiegu oraz kolaboracji).

90

Werbalny sposób może być realizowany przez scenariusze. Często scenariusze nazywają ciągami zdarzeń nie wyróżniając te dwa pojęcia. Scenariusze są dla przypadków użycia tym, czym dla klas obiekty, to znaczy są egzemplarzami przypadków użycia. Scenariusze muszą zawierać następne rodzaje:

1. Główny wykonawca (aktor) scenariuszu, dla którego jest wyznaczona konsekwentność zdarzeń.

2. Inne osoby, które są zaciekawione w tym przypadku użycia oraz wymogi tych osób. Scenariusz musi realizować wymogi różnych kategorii użytkowników, które w sposób pośredni mogą otrzymać rezultaty.

3. Warunki wstępne (precondition). To są warunki, które muszą być spełnione przed uruchomieniem scenariuszy.

4. Warunki końcowe (postcondition). To są warunki, które muszą być spełnione po uruchomieniu scenariuszy.

5. Scenariusz główny (główny proces). To jest główna konsekwencja czynności, która wyznacza przypadek użycia. Ta konsekwencja nie zawiera opis algorytmu z warunkami oraz rozgałęzieniem. Scenariusz główny zawiera następne komponenty:

współdziałanie między wykonawcami; weryfikacja z boku systemu ( np. sprawdzenie identyfikatora towaru); zmiana stanu systemu, wstawianie lub modyfikacja niektórych bytów.

Każde zdanie scenariusza musi być w krótkiej oraz zrozumiałej formie oraz mieć postać: rzeczownik – czasownik - rzeczownik.

6. Rozszerzenia lub scenariuszy alternatywne. Scenariusze alternatywne to są rozgałęzienie scenariuszu głównego. W tym rozdziale muszą być wyznaczone warunki rozgałęzienia oraz reakcje na te warunki. Scenariusz alternatywny musi być skojarzony z punktami scenariusza głównego.

7. Wymogi specjalne. W tym rozdziału są wymogi nie funkcjonalne, ewentualne parametry wydajności, prędkości, efektywności.

8. Lista technologii i typów danych ( Np. wykorzystanie kart elektronicznych, typy kodowania towarów).

9. Częstotliwość wykorzystania.10. Pytania które jeszcze nie otrzymały rozwiązania.

Przykład scenariuszy przypadku użycia „Sprzedaż towarów”.Główny wykonawca. Kasjer.Osoby które są zaciekawione w tym przypadku użycia oraz wymogi tych osób. Kasjer. Chce szybko oraz precyzyjne wprowadzić informacje pro towary oraz

wyznaczyć cenę zakupu. Błąd przy wyznaczeniu ceny będzie poprawiony przez pensję kasjera.

Klient. Chce kupić towar oraz szybko załatwić zakup, otrzymać paragon dla ewentualnego powrotu towaru.

Firma. Chce precyzyjne zachować transakcję pro zakup oraz zadowolić klienta.Warunki wstępne. Kasjer jest identyfikowany oraz sprawdzony na autentyczność.

91

Warunki końcowe. Dani pro zakup są przechowywane w bazie danych. Paragon jest stworzony.Scenariusz główny.

1. Klient wchodzi do sklepu, wybiera towary oraz idzie do aparatu kasowego.2. Kasjer odkrywa nowy zakup.3. Kasjer odczyta identyfikator towaru i wprowadzi go do systemu informacyjnego.4. System informacyjny odczyta nazwę odebranego towaru, go opis i cenę. Kasjer

powtórzy czynności p.3,4 dla każdej pozycji towaru.5. Kasjer informuje klienta pro wartość wypłaty i otrzymuje pieniędzy.6. Klient płaci się oraz system modyfikuje dani sklepu zgodnie z rezultatami zakupu.7. System rejestruje zakup w rejestrze sklepu.8. System drukuje paragon .

Rozszerzenia lub scenariuszy alternatywne.3a. Błąd identyfikatora.

1. System komunikuje pro błąd oraz skasuje wprowadzenie towaru.3-6a. Klient rezygnuje się z zakupu jednego z towarów.

2. Kasjer wprowadzi identyfikator towaru dla usuwania z zakupu.3. System odwzorowuje cenę zakupu bez usuniętego towaru.

5a. Klient komunikuje pro ulgę (jest pracownikiem tego przedsiębiorstwa). 4. Kasjer formuje zapytanie pro ulgę.5. Kasjer wprowadzi dani klienta.6. System wyznacza ulgę dla klienta.

Przykłady ewentualnych błędów przy opracowaniu scenariuszy przypadków użycia1. Zamiast opisu punktu scenariusza w postaci czynności: rzeczownik – czasownik – rzeczownik, piszą wymogi funkcjonalne do systemu.Wymogi wyznaczają to, co system musi realizować. Scenariusz opisuje czynności użytkownika oraz reakcję na nich systemu. Tekst scenariusza musi być specyfikacją zachowania systemu. Ten tekst może być ewentualne rozmieszczony w lewej części diagramu przebiegu, żeby było zrozumiałe w jaki sposób system ( przedstawiony obiektami oraz komunikatami) realizuje swoje zachowanie.

Scenariusz główny( Use Case – „Zmienić zawartość koszyka”)Nieprawidłowe 1.Kiedy Klient zachce zmienić ilość towaru w koszyku, to system musi

zachowywać nową ilość towaru, oraz potem wylicza i odwzorowuje nową wartość zakupu.

Prawidłowe 1. Na stronie Koszyka Klient zmieni się ilość towaru w koszyku oraz wciśnie się przycisk „Ponowić”. 2. System zachowa dani pro ilość towaru , a potem odwzorowuje na stronie Koszyka nową wartość zakupu. Scenariusz alternatywny (musi zawierać na początku warunek IF... THEN)

92

Nieprawidłowe System usuwa towar z koszyka, kiedy ilość towaru zostanie równą 0Prawidłowe Kiedy Klient wpisze wartość 0 jako nową ilość towaru, to system

usuwa towar z koszyka. 2. W scenariuszu opisują bezpośrednio same atrybuty oraz metody zamiast sposobów ich wykorzystywania.

Scenariusz główny (Use Case – „Dostarczyć Towar”Nieprawidłowe 1.Odbiorca towaru zgodnie z każdym Wierszem Zamówienia w

Zamówieniu formuje paczkę towarów dla klienta.2. Odbiorca odczytuje kody kreskowe z listy opakowania. 3.System realizuje metodę „Zmienić stan zamówienia”, żeby zmienić stan zamówienia na „zrealizowane”, oraz potem wywoła metodę „zmienić ilość towaru w bazie danych” dla każdej pozycji towaru.4.Odbiorca oddaje paczkę dostawce.

Prawidłowe 1.Odbiorca towaru zgodnie z każdym Wierszem Zamówienia w Zamówieniu formuje paczkę towarów dla klienta.2. Odbiorca odczytuje kody kreskowe z listy opakowania. 3. System zmieni się stan zamówienia na „zrealizowane”.4. System modyfikuje ilość towarów z listy w bazie danych. Scenariusz główny (Use Case – „Przegląd listy towarów”

Nieprawidłowe 1.Klient wciśnie się przycisk „Kategoria” na Stronie Przeglądu Artykułów”2.System wywoła metodę „Odwzorować Podkategorii” obiektu „Kategoria”.

Prawidłowe 1.Klient wciśnie się przycisk „Kategoria” na Stronie Przeglądu Artykułów”2. System odwzorowuje podkategorii danej kategorii.

Definiowanie przypadków użycia (use case)Przypadek użycia to jest opis zbioru ciągów akcji (i ich wariantów) wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku. Na diagramie przypadek użycia jest przedstawiany w postaci elipsy (Rys.48).

wprowadz pin karty

Rys.48 Przypadek użycia

93

Przypadki użycia można grupować w pakiety, tak jak klasy. Przypadki użycia można uporządkować także przez zdefiniowanie uogólnień między nimi oraz związków zawierania i rozszerzania. Chodzi o wydzielenie wspólnych fragmentów zachowania(przez usunięcie ich z obejmujących je przypadków użycia) lub wspólnych wariantów (przez wklejanie ich do rozszerzających je przypadków użycia).Wskazanie na przypadku użycia powoduje wyświetlenie okna właściwości Use Case Properties (rys.49).

Rys 49. Okno dialogowe Use Case Properties

Pole „Name” określa nazwę przypadku użycia podawanej zwyczajowo w formie krótkiego wyrażenia z czasownikiem w trybie rozkazującym na początku, określającego pewną czynność pochodzącą ze słownictwa modelowanego systemu.Nazwa może zostać poprzedzona nazwą pakietu, w którym dany przypadek użycia został zdefiniowany. Wówczas mamy do czynienia z nazwą ścieżkową składającą się z nazwy pakietu, oddzielających dwukropków i nazwy prostej przypadku użycia.

94

Definiowanie aktorów (actors)Aktor reprezentuje zbiór ról odgrywanych przez użytkowników przypadku użycia podczas interakcji z nim. Zwykle jest to rola dla człowieka, urządzenia lub innego systemu.Np. w systemu bankowym wyróżniamy takich aktorów jak: klient banku oraz system bankowy(Rys.50).

kl ient System bankowy

Rys.50. Aktorzy systemu bankowego.

Wskazanie na aktorze powoduje wyświetlenie okna właściwości „Actor Properties”(rys.51).

Rys. 51. Okno dialogowe „Actor Properties”

Modelując otoczenie systemu należy zidentyfikować aktorów działających wokół systemu. Należy rozważyć jakie elementy systemu są potrzebne do realizacji określonych zadań, a jakie wypełniają drugorzędne funkcje.

95

Rys. 51. Lista aktorów i przypadków użycia przykładowego projektu

Aktorzy oddziaływają na przypadki użycia poprzez związki asocjacji.

Definiowanie asocjacji (association)Asocjacja to jest związek strukturalny, który określa zbiór wiązań (rys.52). Wiązanie to połączenie między obiektami (aktorami a przypadkami użycia).

Rys.52Nie można definiować asocjacji pomiędzy dwoma przypadkami użycia czy też dwoma aktorami. Powiązania mają za zadanie wiązać aktorów będących poza systemem z przypadkami użycia opisywanego systemu (rys.53).

wprowadzanie numeru pin

kl ient

wprowadzanie pin

Rys.53 Powiązanie aktora z przypadkiem użycia

Wskazanie na asocjacji powoduje wyświetlenie okna właściwości „Association Properties”(Rys.54).

96

Cel ŹródłoNazwa powiązania

<< Nazwa stereotypu >>

Rys.54 Okno dialogowe Association Properties

Lista stereotypów umożliwia wprowadzenie własnego stereotypu, ale nie jest to wymagane ponieważ aktorzy są poza systemem modelowanym przez przypadki użycia.

Definiowanie uogólnień (generalizations)Uogólnienie to związek między dwoma bytami: ogólnym (przodek) i szczegółowym (potomek), czyli związek: uogólnienie-uszczegółowienie(rys.55). Obiekty bytu szczegółowego mogą być używane w zastępstwie bytu ogólnego.

Rys. 55

97

RodzicDziecko

Nazwa uogólnienia


Niżej jest pokazano jako związek uogólnienia zdefiniowano pomiędzy dwoma nowymi aktorami (klient-maestro, klient-visa), którzy podlegają aktorowi ogólnemu (klient)(rys.56).

kl ient

kl ient maestrokl ient visa

Rys. 56. Aktorzy powiązani związkiem uogólnienia na diagramie „use case”.

Wskazanie na związku powoduje wyświetlenie okna właściwości „Generalization Properties” (rys.57).

Rys. 57. Okno dialogowe Generalization Properties.

W rozwijanej liście „Stereotype” dostępny jest stereotyp <<implementation>>, stosowany w przypadku implementacji uogólnienia.

98

W przypadku systemu bankomatu uogólnienie „klient” – „klient visa” znajduje się poza modelowanym systemem, więc nie jest implementowany. W rozwijanej liście „Visibility” dostępne są następujące atrybuty: public, private, protected, package, które określają zakres dostępu obiektów klas dziecka do rodzica.Dla podanego uogólnienia występuje związek pomiędzy obiektem ogólnym (klient) a obiektem szczegółowym (klient visa).Uogólnienie między przypadkami użycia jest jak uogólnienie między klasami. Oznacza, że przypadek użycia – potomek dziedziczy całe zachowanie i znaczenie po przypadku użycia – przodku. Potomek może dodać do odziedziczonego zachowania nowe elementy, a może też to zachowanie zupełnie zmienić. Przykład uogólnienia między przypadkami użycia jest pokazany na rys.58

Rys.58Potomek może zawsze zastąpić swego przodka (zarówno przodek, jak i potomek mogą mieć egzemplarze konkretne).

Definiowanie zależności (dependencies)Zależność to związek semantyczny (znaczeniowy) między dwoma elementami. Zmiany dokonane w definicji jednego z tych elementów (niezależnego - Influent) mogą mieć wpływ na znaczenie drugiego (zależnego - Dependent) (Rys.59).

<<include>>wprowadzanie pin Sprawdzenie PIN

Rys.59 Zależność pomiędzy dwoma przypadkami użycia.

99

Wskazanie na zależność powoduje wyświetlenie okna właściwości „Dependency Properties”(rys.60).

Rys.60. Okno dialogowe „Dependency Properties”

W rozwijanej liście Stereotype dostępne są następujące stereotypy:Access, bind, call, derive, ejb-ref, extend, friend, import, include, instantiate, refine, sameFile, trace, use. Wskazanie określonego stereotypu umożliwia wybór bloków konstrukcyjnych specyficznych dla konkretnego zadania(Rys.61).

Rys.61Nazwa stereotypu umieszczana jest zwykle w cudzysłowy ostrokątne np. <<include>>. Każdy stereotyp może mieć także przypisany charakterystyczny symbol używany zamiast standardowego.

100

CelŹródłoNazwa zależności


Związek zawierania (include) między przypadkami użycia polega na tym, że bazowy przypadek użycia jawnie włącza zachowanie innego przypadku użycia w miejscu przez siebie określonym. Włączany przypadek użycia nigdy nie występuje samodzielnie – jego egzemplarze mogą być tylko częścią większego, zawierającego go przypadku użycia. Mówią, że bazowy przypadek użycia zasysa (заимствует) zachowanie włączonego przypadku użycia. Związku zawierania używa się w celu uniknięcia wielokrotnego opisywania tego samego ciągu zdarzeń lub tych samych scenariusze. Wspólne zachowanie jest definiowane w odrębnym przypadku użycia, który jest włączany przez bazowe przypadki użycia. Taki związek jest w istocie przykładem delegowania – pewien zbiór zobowiązań systemu jest specyfikowany w jednym ze składników modelu ( w zawieranym przypadku użycia), a inne części modelu (pozostałe przypadki użycia) włączają ten zbiór zobowiązań, ilekroć jest im potrzebny.Związek zawierania obrazuje się w postaci zależności stereotypyzowanej jako <<include>>. Na rys.62 są pokazane przykłady związków <<include>> między przypadkami użycia.

Rys.62Związek rozszerzania między przypadkami użycia polega na tym, że bazowy przypadek użycia w sposób domniemany (неявный) włącza zachowanie innego przypadku użycia w miejscu określonym pośrednio

101

(косвенно) przez rozszerzający przypadek użycia. Bazowy przypadek może wystąpić samodzielnie, ale pod pewnymi warunkami jego zachowanie może być rozszerzone przez zachowanie innego przypadku użycia. Przypadek bazowy może być rozszerzony jedynie w ściśle określonych miejscach, nazywanych miejscami rozszerzania. W takim związku jest realizowane dołączenie zachowania przypadku użycia rozszerzającego do przypadku użycia bazowego.Związek rozszerzania służy do modelowania fragmentów przypadku użycia postrzeganych przez użytkownika jako opcjonalne zachowanie systemu. Związek rozszerzania obrazuje się w postaci zależności stereotypyzowanej jako <<extend>> . Za dopomogą zależności <<extend>> można oddzielić działania opcjonalne od wymaganych. Związek rozszerzania wyznacza przerywanie scenariuszu elementu bazowego Use Case dla wstawiania scenariuszu innego elementu Use Case (rozszerzającego). Element bazowy Use Case musi zawierać miejsce rozszerzenia. Miejsca rozszerzania bazowego przypadku użycia mogą być wymienione w dodatkowej sekcji jego symbolu. Są to etykiety, które mogą się pojawić w opisie ciągu zdarzeń bazowego przypadku użycia. Element bazowy Use Case nie może istnieć samodzielnie. Na rys.63, a, b, są pokazane przykłady rozszerzania.

Rys. 63

102

Rys.63a

Rys. 63b

103

Lista stereotypów wykorzystywanych przy zależnościachNazwa stereotypu

Znaczenie

access Wskazuje, że źródło ma dostęp do publicznych składników celubind Wskazuje, że źródło tworzy egzemplarz wzorca docelowego z

użyciem danych aktualnych parametrów call Wskazuje, że źródło wywołuje cel. Oba te byty muszą być operacjamiderive Wskazuje, że źródło można wyznaczyć na podstawie celuextend Wskazuje, że docelowy przypadek użycia rozszerza znaczenie

źródłowego przypadku użycia w ściśle określonym miejscu rozszerzenia

friend Wskazuje, że źródło ma szczególny dostęp do wnętrza celuimport Rodzaj dostępu, który oznacza, że zawartość publiczna celu zostanie

dołączona do obszaru nazw źródłainclude Wskazuje, że źródłowy przypadek użycia jawnie przyłącza docelowy

przypadek użycia w miejscu określonym przez źródłoinstantiate Wskazuje, że źródło tworzy egzemplarz celurefine Wskazuje, że źródło jest na doskonalszym poziomie abstrakcji niż celtrace Wskazuje, że cel jest historycznie przodkiem źródłause Wskazuje, że znaczenie źródła zależy od znaczenia części publicznej

celu Liczba stereotypów może być rozszerzana. Mechanizm ten ułatwia dostosowanie języka UML do nowych technologii.

Dokumentowanie oraz konstruowanie przypadków użyciaCelem diagramów przypadków użycia jest dokumentowanie oddzielnych przypadków, aktorów i związków między nimi. Dla dokumentowania mogą być wykorzystywane następne zakładki okna właściwości (Properties) przypadku użycia:

1. Action Steps – opis scenariusza głównego oraz alternatywnego 2. Extension Points – opis warunków, aktywacji źródłowego scenariusza, który

rozszerza za dopomogą związku <EXTEND> docelowy scenariusz. (IF THEN)3. Exceptions – Opis reakcji na zdarzenia przy realizacji tego przypadku użycia.4. Pre-Conditions – Warunki początkowe, które muszą być spełnione dla

rozpoczęcia przypadku użycia. N.p. obecność wyznaczonej informacji w bazie danych lub poprzednia realizacja innego przypadku użycia.

5. Post-Conditions - Warunki końcowe, które muszą być spełnione po realizacji tego przypadku użycia. N.p. stworzenie obiektu zakupu. W tej części dokumentacji mogą być wyznaczone przypadki użycia, które muszą być uruchomiane po realizacji tego przypadku użycia.

Dla opracowania przypadków użycia trzeba wykorzystywać następne rekomendacje:

104

Nie należy modelować związki asocjacji pomiędzy aktorami. Aktorzy są kontekstem systemu, to znaczy przypływ informacji pomiędzy aktorami realizuje się na zewnętrz systemu. Pomiędzy aktorami mogą być tylko związki dziedziczenia.

Pomiędzy oddzielnymi przypadkami użycia w dużej ilości wypadków mogą być związki tylko dwóch typów: <<Include>> oraz <<Extend>>. Związki na diagramie przypadków użycia wyznaczają tylko jakie przypadki użycia mogą dostępne w systemie. Związki nie definiują kolejność realizacji tych przypadków użycia! Dla odwzorowania kolejności realizacji oddzielnych przypadków użycia wykorzystują się diagramy przebiegu. Kolejny przypadek użycia może być wyznaczony także w zakładce „Post-Conditions”.

Każdy przypadek użycia musi być inicjowany przez aktora. To oznaczy, że dla każdego przypadku użycia musi być wyznaczona strzałka komunikacji od aktora do tego przypadku użycia ( Wyjątkiem są związki <<Include>> oraz <<Extend>> ). Strzałka komunikacji w ten sposób wyznaczy się inicjatora komunikacji. Inicjatorem może występować aktor, oraz w tym wypadku strzałka jest skierowana od aktora do przypadku użycia. Kiedy inicjatorem występuje system, strzałka komunikacji jest skierowana od przypadku użycia do aktora. Strzałka komunikacji nie definiuje kierunek przepływu informacji pomiędzy aktorem i przypadkiem użycia, informacja może przepływać w dwóch kierunkach, strzałka wyznaczy tylko inicjatora komunikacji!

Baza danych może być warstwą umowną pod diagramem przypadków użycia. Jeden przypadek użycia może wprowadzać dani do bazy danych, inny przypadek użycia może odczytywać te dani.

Diagramy interakcji (Interaction diagram)Diagram interakcji to jest diagram ułatwiający zrozumienie zależności w przepływie sterowania. Metody realizujące to sterowanie są rozproszone w wielu klasach modelu, co powoduje trudności ze zrozumieniem ich wzajemnej zależności i interakcji. Diagramy interakcji służą do opisu zależności przy przesyłaniu komunikatów dla pewnej grupy obiektów, do modelowania dynamicznych aspektów systemu. Uwzględnia się na nich konkretne i prototypowe egzemplarze klas, interfejsów, komponentów i węzłów, a także komunikaty przekazywane między nimi. Te wszystkie byty są rozpatrywane w kontekście pewnego scenariusza ilustrującego zachowanie systemu. Diagramy interakcji mogą występować samodzielnie; wtedy służą do obrazowania, specyfikowania, tworzenia i dokumentowania dynamicznych aspektów ustalonego zestawu obiektów. Mogą także być użyte do modelowania jednego specyficznego przepływu sterowania w przypadku użycia.

105

Diagram interakcji to wspólna nazwa dla diagramu przebiegu i diagramu kooperacji. Każdy diagram przebiegu i każdy diagram kooperacji są jednocześnie diagramami interakcji, a każdy diagram interakcji jest albo diagramem przebiegu, albo diagramem kooperacji. Diagramy przebiegu i diagramy kooperacji są izomorficzne, to znaczy można swobodnie przekształcać jeden w drugi, bez groźby utraty informacji.

Diagram przebiegu(Sequence diagram)Diagram przebiegu (Diagram sekwencji) to jest diagram interakcji, na którym kładzie się nacisk na kolejność komunikatów w czasie. Przedstawia się na nim zbiór obiektów i komunikaty, jakie obiekty wysyłają i odbierają. Obiekty to zwykle nazwane lub anonimowe egzemplarze klas, choć mogą, także reprezentować egzemplarze innych elementów, takich jak kooperacje, komponenty i węzły. Komunikat to specyfikacja środka łączności między obiektami, przenoszącego zlecenia wykonania określonych czynności. Otrzymanie egzemplarza komunikatu można uważać za egzemplarz zdarzenia.Akcja spowodowana przekazaniem komunikatu może spowodować realizacje procedury obliczeniowej. Akcja może prowadzić do zmiany stanu obiektu. W UML wyróżnia się następne rodzaje komunikatów (control flow) (rys. 64):

Rys.64Asynchronous – obiekt nadawca komunikatu nie będzie oczekiwał rezultatu od obiektu odbiorcy. Obiekt nadawca może stworzyć inne paralelne komunikaty. Ten typ komunikatu jest analogiem skrzyni pocztowej. Procedure Call – dochodzi do wywołania operacji oraz innych włożonych komunikatów na obiekcie odbiorcy. Obiekt nadawca nie może wysłać kolejny komunikat dopóki nie otrzyma odpowiedz pro zakończenie aktywacji od obiektu odbiorcy. Obiekt może wysyłać komunikat do samego

106

siebie; oznacza to lokalne wywołanie operacji. Ten typ komunikatu jest synchronicznym. Return– dochodzi do przekazania wartości wywołującemu. Zazwyczaj ten typ komunikatu jest skojarzony z „Procedure Call”.Undefined – to jest domyślny typ komunikatu. Oznaczy się płaski (неструктурированный) przepływ sterowania (ciągi płaskie). W ten sposób jest odwzorowany nieproceduralny przepływ sterowania. Ustalić typ komunikatu można w oknie „Properties” komunikatu, w zakładce „Detail”, w polu „Control flow” (rys. 65).

Rys. 65Różnica między ciągami płaskim a proceduralnym polega na tym, że ciągi płaskie stosują się do modelowania interakcji związanych z przypadkami użycia, obejmującymi system jako całość, wraz z aktorami z jego otoczenia. W takich przebiegach sterowanie przepływa między kolejnymi krokami, bez względu na zagnieżdżenia. We wszystkich pozostałych wypadkach korzysta się z ciągów proceduralnych, gdyż reprezentują one zwykłe zagnieżdżone wywołania operacji, jakie występują w większości języków programowania.W UML mogą być realizowane następne typy akcji, który są związane z komunikatami:Create – Dochodzi do utworzenia nowego obiektu.Destroy – Dochodzi do zniszczenia obiektu. Może on też popełnić samobójstwo, niszcząc sam siebie. Ustalić typ akcji komunikatu w oknie „Properties” komunikatu, w zakładce „Detail”, w polu „Action” (rys.66).

107

Rys.66Na diagramie przebiegu uwypukla się kolejność komunikatów w czasie. Jest diagramem interakcji obrazującym interakcję jako zbiór obiektów i związków między nimi oraz komunikaty, jakie obiekty przekazują między sobą. Diagram ma postać tabeli, w której obiekty są ułożone wzdłuż osi X, a komunikaty wzdłuż osi Y, uporządkowane według czasu ich wysłania. Taki sposób obrazowania ułatwia czytelnikowi diagramu zrozumienie przepływu sterowania w czasie. Przykład diagramu przebiegu jest pokazany na rys.67

. rys. 67

Caller – abonent dzwoniący Exchange – centrala telefoniczna Receiver – abonent odbierający Lift receiver – podnieść słuchawkę Dial tone - ton w słuchawce (zezwolenie wprowadzenia numeru)Dial digit - wybieranie cyfry

108

Ringing tone - ton dzwonkaPhone rings –uruchomienie dzwonka Answer phone - podniesienie słuchawki Stop tone - koniec tonu Stop rinding – koniec dzwonienia Przykład diagramu przebiegu automatu wypłaty gotówki jest pokazany na rys. 67a.

1: akceptacja karty

17: oddanie karty()

16: wydanie wydruku()

15: wydanie gotowki()

14: zmniejszenie stanu konta()

13: weryfikacja stanu konta()

12: wyplata()

9: wybor operacj i wyplaty()

8: wyswietl formularz wyboru operacj i

11: wprowadzanie kwoty()

10: wyswietlenie formularza do wyplaty

7: weryfikacja pin()

6: wprowadzenie pin()

5: wyswietlenie formularza do wprowadzenia pin

4: otwarcie konta()

3: inicjal izacja terminala()

2: czytanie nr karty()

kl ient

:czytnik kart :konto:term inal :automat wyplaty gotowki

Rys. 67aDiagramy przebiegu maja dwie cechy, które odróżniają je od diagramów kooperacji. Po pierwsze, występują na nich linie życia obiektów – pionowe przerywane kreski reprezentujące czas istnienie obiektów. Większość obiektów z diagramu interakcji żyje przez czas trwania interakcji. Znajdują się one w górnej części diagramu, a ich linie życia biegną od góry do dołu. Podczas interakcji mogą powstawać nowe obiekty. Ich linie życia rozpoczynają się w chwili odebrania przez nie komunikatu stereotypowanego jako <<create>>. Pewne obiekty są niszczone. Ich linie życia kończą się w chwili odebrania

109

przez nie komunikatu stereotypowanego jako <<destroy>> (ich śmierć jest dodatkowo oznakowana wielką literą X). Po drugie, na diagramach przebiegu jest uwzględniony ośrodek sterowania – podłużny , cienki prostokąt reprezentujący okres wykonywania przez obiekt jakiejś akcji osobiście albo z użyciem procedury podrzędnej. Górna krawędź tego prostokąta znajduje się na tej samej wysokości co początek akcji, a dolna – na wysokości zakończenia akcji (może być dodatkowo oznaczona komunikatem przekazania). Na rys.68 jest pokazany diagram przebiegu. Obiekt „Client” tworzy obiekt „Transaction”, który żyje w ciągu wprowadzenia zmian do bazy danych przez obiekt „ODBCProxy”. Transakcja zawiera dwa procesy modyfikacji danych. Te procesy są realizowane przez obiekt „ODBCProxy”. Po wprowadzeniu zmian w bazie danych obiekt „Transaction” formuje komunikat „Commited”. Po zakończeniu transakcji obiekt „Transaction” jest usunięty przez komunikat „Destroy”.

rys.68Przy projektowaniu diagramów przebiegu może być wykorzystany następny sposób, zawierający dwa etapy:Etap 1. Na diagramu trzeba odwzorować informację górnego poziomu, która jest potrzebna końcowym użytkownikom systemu oraz nie zawiera szczegółów realizacji. Komunikaty w tym diagramu nie są skojarzone z operacjami, oraz obiekty także nie są skojarzone z konkretnymi klasami. Diagramy na tym etapie są potrzebne analitykom, użytkownikom oraz osobom, które są specjalistami w procesach biznesowych. Tak diagram,

110

który opisuje kooperację wpisywania danych użytkownika do bazy danych może mieć ewentualne następny wygląd (rys. 68a).

Rys. 68aEtap 2. Diagram, otrzymany na poprzednim etapie jest zadaniem do projektowania więcej szczególnego diagramu. Analizując pierwszy diagram, użytkownicy muszą go uzgodnić. Diagram po uzgodnieniu trzeba rozszerzyć szczegółami konkretnych klas programowych. W tym celu trzeba stworzyć obiekt (lub obiekty) które odpowiadają za konsekwentność zdarzeń scenariusza głównego. Ten obiekt-menedżer jest pokazany na rys. 68b. Każdy przypadek użycia może mieć wiele diagramów przebiegu, oraz w tych diagramach musi być ten samy obiekt menedżer. Zadaniem tego obiektu jest kontrola wszystkich przepływów informacji w wyznaczonym przypadku użycia.

111

Rys. 68bObiekt-menedżer jest obiektem dla sterowania, to znaczy on nie realizuje procesów biznesowych. Obiekt-menedżer formuje komunikaty do innych obiektów oraz jest odpowiedzialnym za czynności tych obiektów. Zaletą wykorzystania obiektu-menedżera jest oddzielenie logiki biznesowej od logiki wyznaczającą konsekwencję zdarzeń w systemu. Kiedy będzie została konieczność zmiany istniejącej konsekwencji zdarzeń, to zmiany te potrzebują modyfikacji tylko jednego obiektu-menedżera. Na diagramu mogą być stworzone inne obiekty z różnymi odpowiedzialności , np. : ubezpieczenie, diagnostyka, związek z bazą danych.Przy zachowaniu informacji w bazie danych lub przy otrzymaniu informacji z bazy można wykorzystać dwa następne rozwiązania:

1. Logika biznesowa jest połączona z logiką bazy danych. Ten przypadek jest pokazany na rys. 68c. Oprócz zachowania metod biznesowych (np. zatrudnienie pracownika) ten obiekt realizuje aktualizację informacji w bazie danych. Obiekt „John Doe” może wiedzieć wszystko o bazie danych i dla tego zachowuje siebie sam. W tym przypadku, przy zmianach bazy danych trzeba dokonać zmian w każdym obiekcie.

2. Logika biznesowa jest oddzielona od logiki bazy danych. Ten przypadek jest pokazany na rys. 68d. W tym przypadku trzeba stworzyć obiekt – menedżer transakcji, którego zadaniem jest komunikacja z bazą danych.

112

Rys. 68c

Rys.68d

Diagram kooperacji (collaboration diagram)Diagram kooperacji (kolaboracji) jest diagramem interakcji, na którym uwypukla się związki strukturalne między obiektami wysyłającymi i

113

odbierającymi komunikaty. Graficznie jest to zestaw wierzchołków i krawędzi.Diagram kooperacji to diagram interakcji, na którym kładzie się nacisk na organizacje strukturalną obiektów, które wysyłają i odbierają komunikaty. Przedstawia się na nim zbiór obiektów, połączenia miedzy nimi oraz wysyłane i odbierane przez nie komunikaty. Te obiekty to zwykle nazwane lub anonimowe egzemplarze klas, choć mogą także reprezentować egzemplarze innych elementów, takich jak kooperacje, komponenty i węzły. Diagramy kooperacji dotyczą dynamicznych aspektów systemu.Na diagramie kooperacji uwypukla się organizację obiektów uczestniczących w interakcji. Kolaboracja pomiędzy obiektami włącza dwa aspekty: statyczną strukturę uczestniczących obiektów, włączając związki, atrybuty i operacje (jest to nazywane „kontekstem kolaboracji”), oraz sekwencję komunikatów wymienianych pomiędzy obiektami dla realizacji konkretnego zadania. Diagram kolaboracji może być rozrysowany dla pewnych typów obiektów, dla pewnych operacji lub dla pewnych przypadków użycia. W odróżnieniu od diagramów przebiegu wymiar czasu nie jest tu bezpośrednio odwzorowany(ale może być częściowo odwzorowany przez odpowiednią numerację komunikatów). Natomiast odwzorowane są powiązania pomiędzy obiektami(prezentujące pewną część powiązań z diagramu klas). Opracowanie takiego diagramu zaczynamy od rozmieszczenia tych obiektów jako wierzchołków grafu. Następnie obrazujemy wiązania łączące obiekty jako krawędzie grafu. Na koniec dodajemy do wiązań komunikaty wysyłane i odbierane przez obiekty. Taki diagram ułatwia czytelnikowi zrozumienie przepływu sterowania w kontekście organizacji strukturalnej współpracujących obiektów. Przykład diagramu kolaboracji jest pokazany na rys.69

114

rys. 69

Techniki modelowania diagramów interakcji Diagramy przebiegu i diagramy kooperacji są równoważne, ponieważ reprezentują tę samą informację . Mówią, że te diagramy są równoważne w sensie semantycznym. Jeden z tych diagramów może być przekształcony do innego bez groźby utraty informacji. Równoważność nie oznacza jednak, że oba diagramy jawnie obrazują tę samą informację. Diagram kooperacji przedstawia sposób połączenia obiektów, a diagram przebiegu nie. Analogicznie diagram przebiegu obrazuje wyniki komunikatów, a diagram kooperacji nie. Oba diagramy są jednak związane z tym samym podstawowym modelem.Diagramy interakcji służą do obrazowania dynamicznych aspektów systemu. Aspekty te mogą obejmować interakcje wszystkich rodzajów egzemplarzy we wszystkich perspektywach architektonicznych, w tym egzemplarze klas, interfejsów, komponentów i węzłów. Diagramy interakcji mogą być użyte do modelowania pewnych dynamicznych aspektów systemu w otoczeniu systemu jako całości , podsystemu, operacji lub klasy. Najczęściej diagramy interakcji są używane dla modelowania scenariuszy przypadków użycia.Wykorzystanie diagramów interakcji dla modelowania dynamicznych aspektów systemu może być realizowano przez dwa sposoby:Modelowanie przepływu sterowania z uwzględnieniem kolejności komunikatów w czasie. Do wykonania tego zadania trzeba używać diagram

115

przebiegu, w którym jest położony nacisk na kolejność przekazywania komunikatów w miarę ich pojawiania się. Ta metoda jest szczególnie przydatna do obrazowania dynamicznego zachowania w kontekście scenariusza przypadku użycia. Za dopomogą tej metody można także wyznaczyć operacji klas obiektów.Modelowanie przepływu sterowania z uwzględnieniem organizacji strukturalnej obiektów. Do wykonania tego zadania trzeba używać diagram kooperacji, w którym jest położony nacisk na związki strukturalne między egzemplarzami uczestniczącymi w interakcji oraz na komunikaty przesłane między tymi egzemplarzami. Przykład diagramu kooperacji automatu wypłaty gotówki jest pokazany na rys. 69a.

15: wydanie gotowki ()16: wydanie wydruku()

13: weryfikacja stanu konta()14: zmniejszenie stanu konta()

7: weryfikacja pin()

12: wyplata()

5: wyswietlenie formularza do wprowadzenia pin

6: wprowadzenie pin()

8: wyswietl formularz wyboru operacj i

9: wybor operacj i wyplaty()

10: wyswietlenie formularza do wyplaty

11: wprowadzanie kwoty()

4: otwarcie konta()

17: oddanie karty()

3: inicjal izacja terminala()1: akceptacja karty

kl ient

:terminal

:czytnik kart

:automat wyplaty gotowki

:konto

Rys. 69a.

Modelowanie przepływu sterowania za dopomogą diagramów przebieguModelowanie przepływu sterowania z uwzględnieniem kolejności komunikatów w czasie trzeba wprowadzić przy obecności diagramów przypadków użycia oraz słownictwa systemu. Diagram przebiegu pozwoli wyznaczyć zobowiązania klas systemu, wyznaczyć główne operacji klas oraz ich zachowanie. Dla stworzenia diagramów przebiegu trzeba postępować zgodnie z podanymi tu wytycznymi.

1. Ustalić otoczenia interakcji. To może być system, podsystem, operacja systemowa, operacja klasy, klasa, jeden ze scenariuszy przypadku użycia lub kooperacja.

116

2. Zidentyfikować obiekty biorące udział w interakcji. Te obiekty muszą być ułożone na diagramie przebiegu od lewej strony do prawej. Po lewej stronie trzeba umieścić najważniejsze obiekty, a po prawej ich mniej ważnych sąsiadów.

3. Wyznaczyć za pomocą komunikatów narodziny i śmierć obiektów. Komunikat inicjujący interakcję musi być umieszczony u góry diagramu, a kolejne komunikaty pod nim, idąc w dół między liniami życia.

4. Dla zobrazowania zagnieżdżonych komunikatów lub chwil, w których są przeprowadzane obliczenia, trzeba dodać do linii życia obiektów ośrodek sterowania.

Przykład projektowania systemu informatycznego Rozpatrzymy technologię wykorzystania diagramów UML na przykładzie stworzenia modelu „Systemu informatycznego rejestracji kursów edukacyjnych w Uczelnie”. Dla stworzenia dziedziny przedmiotowej trzeba wyznaczyć kategorii użytkowników oraz wymogi do systemu.Ten system musi być wykorzystany przez następne grupy użytkowników: Profesora – dla wyznaczenia przedmiotu kursu Studenta - dla wyboru potrzebnego przedmiotu Rejestratora – dla formowania planu zajęć Systemem ewidencji wypłat - dla wyznaczenia wysokości wypłat za nauczanie. Każdy z tych kategorii użytkowników ma swoje wymogi do systemu oraz do scenariuszy współpracy z systemem. Scenariuszy są źródłem informacji dla wyznaczenia diagramu klas dziedziny przedmiotowej (słownictwa systemu). Celem projektowania jest stworzenie diagramu klas projektu systemu informatycznego. Diagram klas projektu systemu różni się od diagramu klas dziedziny przedmiotowej tym, że oprócz klas konceptualnych zawiera klasy programowe (np. dialogowe okna, klasy sterujące programem, serwlety, aplety, komponenty JavaBeans, itp.). Klasy programowe są niezbędne w realizacji każdego projektu. Obecność tych klas wyznacza projektant systemu. Klasy programowe mogą nie występować jako klasy osobni, lecz rozszerzać klasy konceptualne. To znaczy do metod klas konceptualnych dodają funkcjonalność klas programowych.UML nie zawiera sztywnej technologii wykorzystania diagram oraz nie definiuje ilości tych diagram. Diagramy mogą być realizowane w różnych kolejności. W tym przykładzie diagram klas będzie stworzony po diagramu przebiegu.

Stworzenie Diagramu Przypadków Użycia (Use Case diagram)Modelowanie systemu informatycznego rozpoczynamy od stworzenia Diagramu Przypadków Użycia. Z początku trzeba wyznaczyć aktorów, oddzielnie przypadki użycia oraz związki pomiędzy nimi. Dziedzina

117

problemowa systemu informatycznego zawiera 4 aktorzy: Student, Profesor, Registrar oraz Billing System (rys. 70).

Rys.70Dla każdego aktora trzeba wyznaczyć odpowiednie przypadki użycia (elementy Use Case) oraz scenariuszy systemu. Etap wyznaczenia przypadków użycia nazywają się etapem dekompozycji funkcji systemu. Element Use Case jest częścią zachowania systemu, lub częśćą funkcjonalności systemu. Dla identyfikacji elementów Use Case trzeba analizować współdziałanie każdego aktora z systemem. Model Systemu informatycznego rejestracji kursów edukacyjnych w Uczelnie zawiera następne typy współdziałania aktorzy z systemem : Aktor Student chce zarejestrować się do kursu (element Use Case - Rejestracja) Aktor Billing System otrzyma informację pro rejestracje studentów dla obliczenia

wysokości wpłat za nauczania oraz wypłat na prowadzenie zajęć. Ten aktor jest systemem zewnętrznym dla „Systemu informatycznego rejestracji kursów w Uczelnie”

Aktor Profesor chce otrzymać listę kursu lub stworzyć nowy kurs (element Use Case - Formowanie listy kursów)

Aktor Registar musi sterować planami zajęć (element Use Case - Sterowanie planami zajęć).

Pomiędzy aktorami i elementami Use Case trzeba ustalić związki. Dla wyznaczenia kierunku inicjacji współdziałania ( kto jest inicjatorem? ) trzeba wykorzystać skierowane groty (uni – directional arrows) . W Systemie informatycznym dla rejestracji kursów edukacyjnych aktor Student jest inicjatorem współdziałania z elementem Use Case Rejestracja, który

118

natomiast jest inicjatorem współdziałania z aktorem Billing System. Aktor Profesor inicjuje element Use Case Formowanie listy kursów. Aktor Registar inicjuje element Use Case Sterowanie planami zajęć. Rezultaty wprowadzania tych danych do diagramu Przypadków Użycia w środowisku PowerDesigner 9.5 są pokazane na rys. wyżej. Panel przeglądarki stworzonych obiektów tego diagramu jest pokazany na rys.71

Rys.71

Stworzenie diagramu przebiegu (Sequence Diagram)Zachowanie (funkcjonalność) każdego elementu Use Case może być odwzorowane w sposób graficzny w oddzielnym diagramu przebiegu. Ten diagram odwzorowuje jeden z możliwych scenariuszy plonu zdarzeń elementu Use Case, np., dodawanie studenta do kursu. Diagramy przebiegu zawierają obiekty oraz komunikaty pomiędzy nimi, które realizują zachowanie elementu Use Case. Rozpatrzymy stworzenie diagramu realizującego rejestrację studenta. Stworzymy nowy diagram przebiegu w środowisku PowerDesigner. Przeniesiemy aktora „Student” z panelu przeglądarki projektu do diagramu przebiegu. W scenariuszu rejestracji student musi uzupełnić formularz ze swoimi danymi, potem odesłać ten formularz do systemu. Dla realizacji tej części scenariusza potrzebny jest obiekt „Registration Form” , który otrzymuje informację od studenta. Celem tego obiektu jest wizualizacja formularza na komputerze użytkownika oraz przesyłanie danych do innych obiektów. Stworzymy ten obiekt oraz komunikaty „Uzupełnić formularz” (fill in information) i „Submit” (rys.72 ).

119

Rys.72Oczywiście obiekt „Registration Form” nie jest obiektem ostatnim w ciągu obiektów przepływu informacji. Kolejnym obiektem musi być obiekt sterujący „Manager”. Ten obiekt musi otrzymać od obiektu „Registration Form” komunikat pro dodawanie studenta do wyznaczonego kursu oraz sterować innymi obiektami dla realizacji funkcji scenariusza przypadku użycia. Przypuścimy, że nazwisko studenta jest „Joe” oraz kurs jest wyznaczony jako „Math 101”. Komunikat między obiektem„Registration Form” oraz stworzonym obiektem „Manager” jest pokazany na rys.73

Rys.73Manager to jest obiekt pośredni, który współdziała jednocześnie z formularzem oraz ze zbiorem innych obiektów - kursów edukacyjnych. Dla obsługiwania polecenia studenta musi być obiekt-kurs „Math 101”. Obiekt „Manager” musi przekazać do tego obiektu komunikat „Add Joe” (rys.74 ).

120

Rys.74Obiekt – kurs nie może przyjmować samodzielnych decyzji pro dodawanie studentów do kursów nauczania. Dla dodawania studentów do kursu można definiować obiekt specjalnej klasy: „oferta kursów”. Przypuścimy, że obiekt „Section 1” jest egzemplarzem tej klasy. Obiekt-kurs „Math 101” musi z początku polecić do obiektu „Section 1” z zapytaniem, czy można dodać studenta do wyznaczonego kursu. Na diagramie stworzymy komunikat „Accepting students?” pomiędzy obiektami „Math 101” oraz „Section 1”. Przypuścimy, że taka możliwość istnieje (w tym przykładzie wariant alternatywny nie będziemy rozpatrywać). Następnym komunikatem od obiektu „Math 101” do obiektu „Section 1”musi być komunikat „Add Joe” (rys.75).

Rys.75Za edukację trzeba płacić. Wszystkie kwestie finansowe realizują się przez system zewnętrzny „Billing System”. Ten system jest reprezentowany przez obiekt „Bill”. Obiekt „Bill” realizuje interfejs do „Billing System”. Obiekt Manager przesyła się komunikat do obiektu „Bill” pro konieczność

121

stworzenia rachunku dla wpłaty za studia oraz przesyłania tego rachunku do studenta „Joe” (rys.76 ).

Rys. 76

Stworzenia diagramu klas (Class Diagram)Każdy obiekt jest reprezentacją odpowiedniej klasy. Przy stworzeniu diagramu przebiegu byli wykorzystane obiekty, które nie są skojarzone z klasami. Teraz trzeba wyznaczyć te klasy. Definicja klas w diagramu klas zawiera następne kroki: Wyznaczenie klas oraz związków pomiędzy nimi Wyznaczenie zachowania kazdej klasy.

Wyznaczenie klas oraz związków pomiędzy nimiDla wyznaczenia klas oraz związków między nimi obiekty diagramu przebiegu trzeba zgrupować. Można zidentyfikować obiekty i klasy w sposób następujący: Obiekt „Registration form” jest obiektem klasy „Regform” Obiekt „Manager” jest obiektem klasy „Manager” Obiekt „Math 101” jest obiektem klasy „Course” Obiekt „Section 1” jest obiektem klasy „CourseOffering” Obiekt „Bill” jest interfejsem systemu zewnętrznego (Systemu ewidencji wypłat).Trzeba stworzyć nowy diagram klas, oraz rozmieścić oznaczone klasy. Na rys.77 jest pokazany nowy diagram w przeglądarce projektu.

122

Rys.77Na rys.78 są pokazane klasy modelu.

Rys. 78Dla każdej klasy można stworzyć opis w zakładce „Notes” okna właściwości klasy. Proces stworzenia scenariuszy, diagramów przebiegu oraz diagramów klas jest procesem iteracyjnym. Ten proces trzeba przedłużać dopóki istnieje możliwość stworzenia nowych klas, nowych komunikatów lub nowych scenariuszy przypadków użycia. Dla definicji współdziałania obiektów pomiędzy sobą trzeba wyznaczyć szlaki komunikacji między klasami. Żeby widzieć w jaki sposób obiekty mogą „rozmawiać” między sobą na diagramie klas, trzeba zbadać diagram przebiegu. Obiekty mogą komunikować, jeżeli istnieje związek między klasami. Na diagramie klas mogą być wyznaczone dwa typy związków: asocjacja i agregacja. Analizując diagram przebiegu można wyznaczyć następne asocjacji: Od klasy RegForm do klasy Manager Od klasy Manager do klasy Course Od klasy Manager do interfejsu BillingSystem (rys.79 )

123

Rys.79Asocjacja wyznacza związki między obiektami tego samego poziomu. Agregacja realizuje związki hierarchiczne, np. związki między całością i części. Agregacja może być wyznaczona między klasami Course oraz CourseOffering. Każda oferta kursu CourseOffering jest częścią agregatu – klasy Course (rys.80).

Rys.80

124

Dla wyznaczenia ilości obiektów, które mogą uczestniczyć w asocjacjach oraz agregacjach trzeba ustalić właściwości „Multiplicity” w zakładce „Detail” okienka „Properties” odpowiedniego związku (asocjacji lub agregacji). Każda musi mieć właściwości. Struktura każdej klasy jest wyznaczona przez je właściwości. Np., oferta kursu „CourseOffering” jest właściwością klasy „Course”. Klasa „CourseOffering” zawiera właściwość „NumStud” – ilość studentów (rys. 81).

Rys.82Wyznaczenie zachowania klasZachowanie klasy jest wyznaczone przez zbiór je operacji. Początkowa informacja pro operacji jest w diagramu przebiegu. Każdy komunikat na tym diagramu inicjuje operację w odpowiedniej klasie. Komunikaty muszą być przekształcone w operacje. Na diagramie przebiegu wszystkie obiekty muszą reprezentować klasy. Wyznaczymy klasę dla obiektu „Section 1”. Otworzymy diagram przebiegu oraz uruchomimy okno „Properties” dla obiektu „Section 1”. W polu „Classifier” trzeba otworzyć listę rozwianą wszystkich klas modelu i ustalić klasę „CourseOffering”(rys.83 ).

125

Rys.83Diagram przebiegu będzie miał następny wygląd (rys. 84). Nazwisko obiektu teraz zawiera i nazwisko klasy.

126

Rys.84Po wyznaczeniu klasy trzeba uzupełnić klasę operacjami. Każdy komunikat będzie miał nowe nazwisko – nazwisko operacji klasy , która jest uruchomiana. Na rys. jest pokazana zakładka „Detail” okna „Message Properties” operacji „Add Joe” między obiektami „Math 101” oraz „Section 1: CourseOffering”. Trzeba kliknąć przycisk „Create” sprawa obok pola „Operation” (rys.85 ).

Rys.85W nowym oknie „Operation Properties” (rys.86 ) trzeba wyznaczyć nową operację klasy „CourseOffering”.

127

Rys.86W oknie „Message Properties” już jest widoczna nazwa operacji i trzeba wpisać nazwę je argumentu (rys.87). Na diagramie przebiegu zamiast poprzedniej nazwy komunikaty jest wyświetlana nazwa operacji.

Rys.87Na rys.88 jest pokazano stworzenie operacji z nazwiskiem „OfferingOpen” dla komunikatu „accepting students?”

128

Rys.88Diagram przebiegu dla tych dwóch operacji będzie miał wygląd na rys.89

Rys.89Dla klasy „CourseOffering” można rozpatrzyć kod w Jawie (rys.90 )

129

Rys. 90Ostateczny wygląd diagramu przebiegu z wyznaczonymi operacjami jest pokazany na rys.91

Rys. 91Na rys. 92 w lewym okienku jest pokazane drzewo klas z operacjami oraz ich atrybutami.

130

Rys. 92

Diagramy Stanów (State diagram)Diagram stanów (state diagram, state-machine diagram, statechart diagram) to jest diagram, w którym węzłami są stany jakiegoś procesu ( w sensie czynności, które są wykonywane przez ten proces), zaś krawędzie oznaczają przepływ sterowania (przejścia) pomiędzy tymi stanami. Diagram stanu jest przeznaczony dla modelowania zachowania obiektów tylko jednej klasy! To znaczy, że wszystkie stany na tym diagramu są stanami obiektów tylko tej samej klasy. W przeciwieństwie do diagramów stanów diagramy przebiegu mogą modelować zachowanie obiektów różnych klas.W metodykach analizy i projektowania systemów informatycznych diagramy stanów mogą występować na różnych poziomach abstrakcji, gdzie poziom bardziej szczegółowy jest rozwinięciem poziomu bardziej abstrakcyjnego. Diagram stanów to jeden z pięciu rodzajów diagramów UML służących do modelowania dynamicznych aspektów systemu: przypadków użycia, przebiegu, kooperacji, czynności i stanów. Diagramy stanów mogą być stworzone dla następnych elementów UML: Klas (konceptualnych oraz programowych), Przypadków użycia.

131

Cały system informatyczny może być przedstawiony w postaci klasy, dlatego diagram stanów może być wykorzystywany dla modelowania całego systemu lub go części. Diagram stanów to jest maszyna stanowa, która pokazuje kolejność stanów modelowanego obiektu. W odróżnieniu od diagramów czynności (którą będziemy rozpatrywać później), diagramy stanów służą do modelowania zachowania obiektów reaktywnych, to znaczy obiektów, których działania są najlepiej określane przez ciąg odpowiedzi na zdarzenia wywołane w otoczeniu tych obiektów (ich kontekstu). Zwykle taki obiekt jest bezczynny do chwili zajścia zdarzenia. Gdy ono nastąpi, jego reakcja najczęściej zależy od wcześniejszych zdarzeń. Po zakończeniu akcji spowodowanych zdarzeniem obiekt znów jest bezczynny i czeka na następne zdarzenia. W wypadku tego rodzaju obiektów należy kłaść nacisk na stany stabilne, oraz na zdarzenia uruchamiające przejścia i akcje wykonywane przy każdej zmianie stanu.W przeciwieństwie do diagramów stanu, Diagramy czynności (aktywności) służą dla odwzorowania procesów biznesowych, to znaczy do modelowania przepływu czynności lub operacji procesu przetwarzania informacji. Diagram czynności pokazuje nie stany obiektów, lecz etapy realizowanych obliczeń lub czynności procesu biznesowego, zakładając przy tym, że zdarzenia (zewnętrzne oraz wewnętrzne) w ciągu tego procesu są nieobecne. Diagramy czynności lepiej nadają się do definiowania kolejno wykonywanych czynności, tak jak robi się to na schemacie blokowym algorytmu.Wadą diagramów stanu oraz czynności jest to, że te diagramy nie wpływają na ostateczny kod wygenerowany przez PowerDesigner (lub inne CASE narzędzie). Jednak to nie oznaczy, że te diagramy są zbyteczne. Diagram stanu jest modelem obiektu klasy programowej lub przypadku użycia . Ten model jest realizowany za dopomogą pojęć i formalizmów teorii maszyn stanowych. To pozwoli przedstawić zachowanie obiektu w postaci oddzielnych stanów oraz przejść pomiędzy nimi. Zgodnie z teorią maszyn stanowych jakakolwiek złożona maszyna stanowa może być podzielona na zwykle maszyny stanowe. Dekompozycja zachowania klas po stanach pozwoli wyznaczyć i definiować metody i atrybuty tych klas. Zgodnie ze standardem UML diagram stanów odwzorowuje następne czynności: Zbiór stanów modelowanej klasy lub przypadku użycia Zdarzenia które inicjują przejścia pomiędzy oddzielnymi stanami oraz w samych

stanach Akcji, które są realizowane w stanach Akcji, które są realizowane w przejściach. Na rys. 93 jest pokazany diagram stanów obiektów klasy „Authentification”. Obiekty tej klasy są przeznaczone dla walidacji użytkownika systemu informacyjnego. Rezultatem analizy zachowania obiektów tej klasy są następne stany: Editing - początkowy stan obiektu Validating – stan walidacji danych wpisanych przez użytkownika

132

Validated – użytkownik ma prawa dostępu Refused - użytkownik nie ma prawa dostępu Canceled – użytkownik przekroczył czas na walidację.Początkowym stanem obiektu jest stan „Editing” w którym Użytkownik edytuje swój identyfikator oraz hasło. Z tego stanu jest możliwe przejście do stanu „Validating” lub do stanu „Canceled”. Do stanu „Canceled” przejście będzie realizowane po przekroczeniu czasu wyłącznika zegarowego. Do stanu „Validating” przejście będzie realizowane po kliknięciu przyciska „SUBMIT”. W stanie „Validating” realizują się polecenia do bazy danych z danymi użytkownika. W przypadku istnienia odpowiednich uprawnień obiekt przechodzi do stanu „Validated”, w innym przypadku – do stanu „Refused”.

Rys. 93Przejścia pomiędzy stanami na diagramu są pokazane przez strzałki . Każda strzałka odpowiada wyznaczonemu zdarzeniu, które powoduje przejście do następnego stanu. Stan obiektu to jest okoliczność lub sytuacja, w jakiej się obiekt znajduje w czasie swego życia, kiedy spełnia jakiś warunek, wykonuje jakąś czynność lub czeka na jakieś zdarzenie. Stan obiektu ma następne atrybuty i składniki: Name – nazwa stanu Classifier – klasa obiektu Composite – obecność podstanów (stanów włożonych) Actions – akcje wykonywane – odpowiednio – przy wejściu do stanu, w stanie i przy

wyjściu z niego Deferred events – zdarzenia odroczone – to jest lista zdarzeń, które są generowane

przez system, ale nie są obsługiwane w tym stanie. Te zdarzenia są odraczane i umieszczane w kolejce, po czym są obsługiwane w innym stanie.

Dependencies – zależności , są to związki z innymi stanami.

133

Wszystkie atrybuty i składniki stanów mogą być wyznaczone w oknie „State Properties” PowerDesignera.Wszystkie zdarzenia mogą być następnych typów: Zdarzenia zewnętrzne( lub zdarzenia systemowe). Te zdarzenia są inicjowane przez

zewnętrzne warunki, np. naciśnięcie przycisku „wprowadź” dla przesyłania danych formularza pro identyfikator ta hasło użytkownika. Zdarzenia zewnętrzne najczęściej są odwzorowane na diagramach przebiegu.

Zdarzenia wewnętrzne. Te zdarzenia są inicjowane przez wewnętrzne warunki, np. odpowiedź serwera pro nieobecność uprawnień Użytkownika („denial”).

Wszystkie zdarzenia w modelu mogą być wyznaczone w PowerDesigner za dopomogą opcji menu MODEL>EVENTS oraz mogą być definiowane jako trygery w przejściach. Na rys.94 jest pokazana tabela dla definiowania zdarzeń w modelu oraz lista tych zdarzeń.

Rys.94Na rys.95 jest pokazany katalog obiektów „Events” w przeglądarce PowerDesignera. Zdarzenie „Submit” zawiera parametry.

Rys.95Każdy stan diagramy stanów może być skojarzony z odpowiednią klasą. Na rys.96 jest pokazane okno „State Properties” oraz pole „Classifier” gdzie może być wyznaczona klasa dla tego stanu.

134

Rys.96Diagram stanów skojarzony z klasą wyznaczy sposób reakcji obiektów klasy na wszystkie zdarzenia. To znaczy, że diagram dokładnie definiuje dla każdego stanu obiektu odpowiednią akcję, która musi być zrealizowana przy zdarzeniu. Ten samy obiekt może realizować różne akcji na wyznaczone zdarzenie w zależności od stanu obiektu. Realizacja akcji może spowodować zmianę stanu obiektu. Opis przejścia na diagramu stanów w tym przypadku musi zawierać opis zdarzenia i akcję. Pełny opis przejścia (transition) na obrazku diagramu ma następny format:Trigger_Event ( parameters) [condition] / actionKażdy z składników tego formatu jest opcjonalny. To znaczy, że w przypadkach kiedy przejście jest oczywiste (przejście bez zdarzenia) w ogóle może nie być opisu. Wszystkie komponenty opisu przejścia mogą być zadane w oknie „Properties transition” na diagramu stanów. Niżej jest podany opis głównych właściwości i atrybuty przejścia: Trigger_Event (parameters) – zdarzenie uruchamiające(razem z argumentami),

którego otrzymanie oznacza, że jeśli warunek dozoru (condition) jest spełniony, to przejście może być uruchomione.

Condition – warunek dozoru, to znaczy wyrażenie logiczne, którego wartość jest wyznaczona w chwili otrzymania zdarzenia uruchamiającego. Jeśli tą wartością jest prawda, przejście może być uruchomione.

Action – akcja, to znaczy wykonywana niepodzielna procedura obliczeniowa, która może mieć bezpośredni wpływ na obiekt będący właścicielem maszyny stanowej i pośredni wpływ na inne obiekty znajdujące się w jego zasięgu.

135

Operation – operacja (metoda) klasy, która może być (nie konieczne) bezpośrednio skojarzona z akcją.

Przykład opisu przejścia:Przycisk_myszy_naciśnięty(prawy_przycisk)[wewnątrz_okna]/uruchomienie_menu kontekstu Na rys.97 pokazane jest okno „Transition Properties” gdzie można wyznaczyć wszystkie parametry opisu przejścia.

Rys.97Wewnątrz każdego stanu mogą być różne typy zdarzeń. Każdy stan obiektu zawiera następne wbudowane stereotypy zdarzeń: Entry, Do, Exit. Do tych stereotypów mogą być dodane inne. Ze zdarzeniami są skojarzone akcji, które mogą być zrealizowane. Np., mogą być wyznaczone w zdarzeniach następne typy akcji: Entry – to są akcji, które muszą być realizowane przy wejściu do stanu Do – to są akcji które muszą być realizowane w tym stanie Exit – to są akcji, które muszą być realizowane przy wyjściu ze stanu.W poprzednim przykładzie w stanu „Validating” są realizowane następne akcji: Entry / Wyświetlanie informacji od użytkownika przy wejściu do stanu Do / Polecenie do serwera z danymi użytkownika w tym stanie Exit / Zamknięcie okna z danymi użytkownika.Na rys.98 jest pokazane okno „State Properties”, gdzie można wyznaczyć akcję dla każdego typu zdarzeń.

136

Rys. 98Modelując zachowanie obiektu reaktywnego, można określić jego akcji przez skojarzenie ich z przejściami lub zmianami stanów. Maszyna stanowa, której wszystkie akcję są związane z przejściami, jest nazywana maszyną Mealy’ego. Maszyna stanowa, której wszystkie akcję są związane ze stanami, jest nazywana maszyną Moore’a. PowerDesigner pozwoli opracować diagramy stanowe z kombinacją maszyn Moore’a i Mealy’ego. Na rys.99 jest pokazany przykład definiowania akcji jednocześnie w stanach i w przejściach.

Rys.99Ważną cechą maszyn stanowych są stany włożone. Stany włożone pozwalają realizować dekompozycję przy modelowaniu komplikowanego zachowania. Stan włożony jest częścią innego superstanu (composite state), który jest jego rodzicem. Stany typu „Composit” są stanami abstrakcyjnymi. Przejścia pomiędzy stanami abstrakcyjnymi oraz innymi stanami na diagramu można traktować jako przejścia z dowolnymi stanami włożonymi, które są częścią stanów rodzicieli. Na rys.100 jest pokazano okno „State Properties” stanu„Validating”, gdzie można definiować ten stan jako superstan, zawierający stany włożone.

137

Rys.100Na rys.101 jest pokazana znaczka stanu „Composite” na rysunku diagramu.

Rys.101Przy definiowaniu stanu jako superstanu „Composit” automatyczne jest stworzony nowy diagram stanu rys. 102

138

Rys.102Modelowanie obiektów reaktywnych za dopomogą diagramu stanów musi zawierać następne kroki:

1. Ustalenie otoczenia (kontekstu) maszyny stanowej: klasę, przypadku użycia lub systemu.

2. Wyznaczenie stanu początkowego i końcowego obiektu.3. Zidentyfikowanie stanów stabilnych obiektu. Z początku trzeba wyznaczyć stany

najwyższego poziomu, a potem ewentualne ich podstany. 4. Ustalenie porządku częściowego stanów stabilnych w historii życia obiektu.5. Wyznaczenia zdarzeń, które mogą uruchamiać przejścia między stanami. 6. Sprawdzenie czy wszystkie stany są osiągalne pod wpływem pewnej kombinacji

zdarzeń oraz czy nie ma stanów – pułapek, których nigdy nie da się opuścić. Na rys. 103 jest pokazany przykład diagramu stanu dla obiektów klasy „Telefon”.

139

Rys.103Obiekt może być w dwóch stanach: Idle – oczekiwanie Active – aktywnym.Przejście do stanu aktywnego jest powodowane przez zdarzenie „off hook” (podnieść słuchawkę) przy warunku połączenia telefonu do sieci. Te przejście powoduje akcję „Plaj dial tone” .Wyjście ze stanu aktywnego jest powodowane przez zdarzenie „on hook” (pokłaść słuchawkę). Stan „Active” jest superstanem oraz zawiera stany włożone (Rys.104 )

Rys.104Na rys. są pokazane stany : „Playing dial Tone” – stan gwizdka “Dialing” – wybranie numeru „Connecting” – połączenie „Talking” – rozmowa. Z każdego z tych stanów może być przejście do stanu „Idle” przy zdarzeniu „On hock”.Diagramy stanów najlepsze są przydatne dla modelowania zachowania obiektu w różnych przypadkach użycia. Te diagramy nie pozwalają modelować współdziałanie różnych obiektów. Diagramy stanów należy wykorzystać razem z innymi diagramami. W zależności od treści modelowanych procesów mogą być proponowane następne rekomendacji: Dla opisu zachowania współdziałających obiektów w jednym przypadku użycia

trzeba wykorzystać diagramy przebiegu. Dla opisu zachowania wspólnych czynności dla wielu obiektów oraz przypadków

użycia trzeba wykorzystać diagramy czynności.

140

Dla opisu zachowania obiektu w różnych przypadkach użycia trzeba wykorzystać diagramy stanów.

Diagramy czynności (Activity diagram)Diagram czynności (diagram aktywności) to jest jeden z pięciu rodzajów diagramów UML służących do modelowania dynamicznych aspektów systemu: przypadków użycia, przebiegu, kooperacji, czynności i stanów. Diagram czynności to jest szczegółowa postać maszyny stanowej, która zawiera mechanizmy sieci Petri. Diagram czynności jest w istocie schematem blokowym, który przedstawia przepływ sterowania od czynności do czynności. Jedyną różnica koncepcyjną jest to, że pojawiają się na tych schematach elementy synchronizacji równoległych procesów (przejścia sieci Petri) . Czynność jest wieloetapowym działaniem wykonanym na maszynie stanowej. Jej wynikiem jest pewna akcja, która składa się z niepodzielnych obliczeń prowadzących do zmiany stanu systemu lub przekazania wartości. Pojęcie „Akcja” ma taki samy zmysł, jako w diagramu stanów. Akcją jest np. wywołanie operacji, wysłanie sygnału, utworzenie lub zniszczenie obiektu, zwykłe obliczenie itp. Diagram czynności jest grafem złożonym z wierzchołków i krawędzi. Wierzchołkami mogą być: stany czynności (proste i złożone), stany obiektów, elementy rozgałęzienia (decyzji), elementy rozwidlania i scalania ścieżek, stan początkowy, stan końcowy.Stan czynności prosty zawiera jedną niepodzielną akcję, która nie może być dekomponowana oraz żadne zdarzenie nie może przerwać wykonania tej akcji. W przeciwieństwie do stanów prostych, stany złożone mogą być dekomponowane. Reprezentowane przez nie czynności można przedstawić na dodatkowych diagramach czynności. Oprócz tego takie stany są podzielne, to znaczy mogą być przerwane. Krawędziami na diagramu czynności są przejścia (Transitions), obrazujące ścieżki między stanami czynności. W przeciwieństwie do przejść diagramów stanów przejścia w diagramie czynności nie są skojarzone z zdarzeniami oraz w przejściach nie mogą być zrealizowane akcji. W zakładce „Trygger” okna „Transistion Properties” wszystkie pola są szare. Akcji mogą być realizowane tylko w stanach czynności (!). Taki przejścia określają się jako automatyczne lub zakończeniowe (Triggerless), ponieważ sterowanie jest przekazywane dalej natychmiast po ukończeniu prac

141

związanych ze stanem źródłowym. To oznaczy się, gdy tylko skończy się akcja danego stanu źródłowego, zostaje wykonana akcja kolejnego stanu. Na rys.105 jest pokazany proces opłacania towaru przez kartkę elektroniczną klienta. Diagram czynności zawiera następne stany: Process payment – proces odczytu danych karty i weryfikację (stan złożony) Update customer account – modyfikacja konta klienta Log error – rejestracja błędów Notify payment failure – komunikat pro błędy Notify payment success – komunikat pro sukces Na diagramu jest pokazany także stan obiektu „Customer account [updated]”. Ten stan jest skojarzony z akcją „Update customer account”.

Rys.105

Przepływ sterowania jest określony stanem początkowym oraz stanem końcowym. Na diagramu czynności istnieje rozgałęzienie przez blok decyzji. Rozgałęzienie opisuje się ścieżki alternatywne. Na rys.106 jest pokazany włożony diagram czynności, który jest dekompozycją stanu „Process payment”. Dekompozycja stanu „Process payment” zawiera dwie akcji: Provide card data – odczyt danych z karty Verify card validity – weryfikacja karty.

142

Rys.106Dla modelowania komplikowanych procesów informatycznych często podzielają te procesy na grupy. Każda grupa reprezentuje jednostkę przedsiębiorstwa odpowiedzialną za przydzielone czynności. Każda taka grupa w UML nosi nazwę toru (Swimlanes) ( jak tory na pływalni). Przykład diagramu czynności zawierającego tory jest pokazany na rys.107 Ten diagram modeluje proces założenia nowego konta dla klienta. Wszystkie czynności są podzielone pomiędzy trzema torami: Działem Obsługi klienta Działem Obsługi kont Klientem.

Rys.107

143

Każdy tor ma nazwę, która musi być unikatowa w obrębie jednego diagramu. Tor nie wpływa na kod generowany przez model oraz nie ma żadnego szczególnego znaczenia, oprócz tego , że może zobowiązaniom realizacji części czynności opisywanej przez diagram.Tory mogą być stworzone w trybie menu „MODEL-> ORGANIZATION UNITS”, oraz potem przeniesione z brousera do diagramu.Obiekty w szczególny sposób biorą udział w przepływach sterowania zobrazowanych na diagramach czynności. Na poprzednim rysunku są pokazane czynności związane z założeniem konta klienta. „Konto” to jest klasa modelu. Oddzielnie akcji diagramu czynności tworzą egzemplarzy obiektów tej klasy oraz wpływają na ich stan. Takie wystąpienia stanów obiektów z akcjami nazywają się przepływami obiektów, ponieważ reprezentują uczestnictwo obiektu w przepływie sterowania. Zaletą diagramów czynności jest możliwość modelowania równoległych procesów. Wadą jest nieobecność jawnych związków pomiędzy akcjami i obiektami. Diagramy czynności trzeba wykorzystać w następnych przypadkach: Dla analizy przypadków użycia. Przy modelowaniu przypadków użycia nie jest

konieczne związki pomiędzy obiektami i akcjami. Na tym etapie trzeba wyznaczyć jakie akcji w ogóle muszą być w zachowaniu systemu informacyjnego. Połączenie metod i obiektów może być realizowane za dopomogą diagramów przebiegu i kooperacji.

Dla analizy czynności w różnych przypadkach użycia, które współdziałają pomiędzy sobą.

Dla modelowania oddzielnych operacji. W tym wypadku diagramy czynności spełniają funkcję schematów blokowych, na których przedstawia się szczegóły przeprowadzanych obliczeń. Bardzo ważne są tu rozgałęzienia, rozwidlenia i scalenia. Przy tym otoczenia diagramu obejmuje parametry operacji i jej obiekty lokalne.

Diagramy komponentów (component diagram)Statyczne oraz dynamiczne diagramy modelują logikę systemu oraz logikę oprogramowania. Diagram komponentów oraz diagram wdrożenia opisują reprezentację systemu w świecie rzeczywistym. Te dwa diagramy nazywają się diagramami realizacji. Diagram komponentów to jest diagram pokazujący strukturę komponentów oprogramowania, ich związki i przepływ komunikatów oraz interfejsy ze światem zewnętrznym. Jest to graf, w którym węzłami są komponenty, zaś strzałki prowadzą od klienta pewnej informacji do jej dostawcy.

144

Komponent to jest fizyczna, wymienna(заменяемая) część systemu, która wykorzystuje i realizuje pewien zbiór interfejsów. Na diagramie jest przedstawiany jako prostokąt z bolcami.Najczęściej komponent reprezentuje następne części systemu informatycznego: Binarne pliki (.EXE) Pliki kodu źródłowego programu Pliki danych programu Pliki dikumentów Pliki DLL (Dynamic Link Library) Przechowywane procedury bazy danych Tablicy bazy danych.Komponenty są podobne klasam: mają nazwy, realizacją, pewien zbiór interfejsów, mogą brać udział w związkach zależności, uogólnieniach i powiązaniach, mogą być zagnieżdżone, mogą mieć egzemplarze, mogą uczestniczyć w interakcjach. Różnice pomiędzy klasami a komponentami: Klasy reprezentują abstrakcje logiczne, a komponenty – elementy fizyczne. Innymi

słowy, komponenty mogą żyć na węzłach (komputerach), a klasy nie. Komponenty reprezentują fizyczne opakowanie składników logicznych, to znaczy

komponent jest skafandrem klasy. Klasy są bezpośrednimi właścicielami atrybutów i operacji. Komponenty w zasadzie

mają jedynie operacje, które są udostępniane przez ich interfejsy. Tak okno „Component Properties” diagramu komponentów w ogóle nie zawiera zakładki „Atributes”.

Przykład diagramy komponentów jest pokazany na rys.108

Rys.108Główne cechy komponentów są w następnych punktach: Komponent nie może istnieć bez klasy oraz klasa nie może być zrealizowana bez

komponentu. Klasie jest potrzebny skafander którym dla niej jest komponent. Puste skafandry nic nikomu nie potrzebne, dlatego komponent może zawierać jednocześnie wiele różnych klas z ich operacjami. Tak, specyfikacja „Component Properties”

145

zawiera zakładkę „Classes”, gdzie można wyznaczyć klasy wchodzące do komponentu.

Komponent może być włożony do innego komponentu. Komponent jest wymienna część systemu. Jeden komponent może być zamieniony

przez inny, mający ten samy interfejs. Komponent nie może być wdrożony częściowo, a tylko w całości.

Różnice pomiędzy pakietami klas oraz komponentami:

Pakiet (Package) to jest logiczna część systemu, zawierająca klasy w tej samej dziedzinie zachowania (np. klasy okien, menu w Jawie są w jednym pakiecie Java.awt). Komponent odwzorowuje poziom fizyczny systemu oraz może zawierać klasy w różnych dziedzinach zachowania.

Klasy abstrakcyjne oraz interfejsy nie mogą występować w wielu pakietach, natomiast wiele komponentów mogą implementować te same interfejsy.

Każdy pakiet logiczny może być skojarzony z wiele komponentami.Interfejs to jest zestaw operacji, które wyznaczają usługi oferowane przez klasę lub komponent. Przykład komponentu, który zawiera interfejsy : Invoice, InvoiceLocal, InvoiceHome, InvoiceLocalHome, - jest pokazany na rys. 109

Rys. 109Dodawać do modelu nowy interfejs można na diagramu klas lub w przeglądarce projektu. Ustalić interfejs w komponencie można w zakładce „Interfejs” okna „Component Properties” (rys.110 )

Rys.110

146

Diagramy wdrożenia (deployment diagram)Diagram wdrożenia (diagram rozprzestrzeniania) to jest diagram pokazujący konfigurację elementów czasu wykonania: komponentów sprzętowych, komponentów oprogramowania, oraz związanych z nimi obiektów. Diagram wdrożenia jest grafem, gdzie węzłami są elementy czasu wykonania połączone przez linie odwzorowujące ich połączenia komunikacyjne. Węzeł to jest fizyczny składnik działającego systemu, reprezentuje zasoby obliczeniowe, ma pamięć i zdolność przetwarzania.Węzły przypominają komponenty: mają nazwy, mogą brać udział w zależnościach, uogólnieniach, mogą być zagnieżdżone, mogą mieć egzemplarze, mogą uczestniczyć w interakcjach. Istnieją jednak istotne różnice między węzłami a komponentami: Komponenty uczestniczą w działaniach systemu, a węzły realizują działania

komponentów. Komponenty reprezentują fizyczne opakowanie elementów logicznych, a węzły

reprezentują fizyczne wdrożenie komponentów.Pierwsza wymieniona różnica pokazuje, że komponenty mogą działać tylko na węzłach. Druga różnica wskazuje na istnienie związku między klasami, komponentami i węzłami. W szczególności komponent jest fizyczną implementacją klas, a węzeł jest miejscem wdrożenia komponentów. Klasa może być implementowana przez jeden lub więcej komponentów; z kolei komponent może być wdrażany na jednym lub więcej węzłach. Związek między węzłem a wdrożonymi na nim komponentami można zobrazować za pomocą zależności. W większości wypadków nie ma jednak potrzeby przedstawienia tych zależności na diagramu. Lepszym rozwiązaniem jest umieszczenie tej informacji w specyfikacji węzła. Przykład diagramu wdrożenia systemu bankowego jest pokazany na rys. Na diagramu są pokazane dwa węzły systemu bankowego dla wypłaty gotówki przez bankomat. Węzeł „System Bankowy” zawiera komponent „Konto”. Ten węzeł jest połączony z węzłem „Bankomat” przez asocjację „Jeden do wielu”. Węzeł „Bankomat” zawiera trzy komponenty : „Automat”, „Czytnik”, „Terminal”. Na rys.111 odwzorowane jednocześnie specyfikacja oraz zależności dla węzła „Bankomat”.

147

Rys.111

148

„Gdyby budowniczowie budowaliście budynki w ten sposób jako programiści piszą swój kod programu , wystarczyłoby jednego dzięcioła, żeby poruszyć światową cywilizację”.

Wzorce do wyznaczenia odpowiedzialności obiektów. Odpowiedzialność opisuje zachowanie obiektu. Istnieją dwa typy odpowiedzialności:

1. Wiedzie (knowing)2. Czynności (doing)

Do typu odpowiedzialności skojarzonymi z czynnościami obiektów są następne wytyczne:

Realizacja czynności bezpośrednio tym samym obiektem, np. obliczenia lub tworzenie egzemplarzy innych klas.

Inicjacja czynności innych obiektów. Koordynacja oraz sterowanie czynnościami innych obiektów

Do typu odpowiedzialności skojarzonymi z wiedzami obiektów są następne wytyczne: Obecność informacji o prywatnych inkapsulowanych danych. Obecność informacji o połączonych obiektach. Obecność informacji pro obliczenia.

Na rys. 1 jest pokazany diagram przebiegu. Odpowiedzialnością czynnościową obiektów Sale jest tworzenie obiektów SalesLineItem oraz obiektów Payment.

Rys. 1

149

Obiekt Sale jest odpowiedzialnym za obecność informacji pro cenę zakupu - odpowiedzialność skojarzona z wiedzami. Ten rodzaj odpowiedzialności wypływa z diagram klas konceptualnych. Dla wyznaczenia odpowiedzalności pomiędzy klasami są wykorzystane wzorce GRASP (General Resposibility Assigment Software Patterns) (Ogólne wzorce wyznaczenia odpowiedzalności w systemach programowych):

Information Expert Creator High Cohesion Low Coupling Controller.

Wzorzec Information Expert.Decyzja: Wyznaczyć odpowiedzialność dla tej klasy, która ma informację dla realizacji tej odpowiedzialności. Problem. Jakie jest główne podejście do wyznaczenia odpowiedzialności pomiędzy klasami?Przykład .Wyznaczyć, które obiekty i z jakich klas zawierają informację dla obliczenia sumy sprzedaży? Klasy mogą być wyznaczone w modeli projektowej lub w modeli dziedziny problemu:

1. Kiedy w modeli projektowej są odpowiednie klasy trzeba wykorzystać najpierw te klasy.

2. W innym przypadku trzeba precyzować klasy dziedziny problemu dla utworzenia klas programowych.

Fragment diagramu dziedziny problemu jest pokazany na rys. 2

Rys.2

150

Dla obliczenia sumy są potrzebne sumy cząstkowe wszystkich towarów w SalesLineItem. Obiekt Sale jest Ekspertem informacyjnym, bo wie jakie są towary w obiekcie Sale. Obiekt SalesLineItem wie ilość towaru oraz gdzie można pobrać go cenę. Ten obiekt jest także Ekspertem informacyjnym.Fragment diagramy obiektów jest pokazany na rys. 3

Rys.3Tablica odpowiedzialności klas wzorca Information Expert

Klasa odpowiedzialnośćSale Wiedzie ogólnej sumy sprzedażySalesLineItem Wiedzie cząstkowej sumy sprzedażyProductCatalog Wiedzie ceny towaru

Wzorzec CreatorDecyzja: Wyznaczyć odpowiedzialność do klasy B tworzyć egzemplarzy klasy A w następnych przypadkach:

Klasa B agreguje obiekty klasy A. Klasa B zawiera (contains) obiekty klasy A. Klasa B pisze egzemplarzy obiektów klasy A. Klasa B wykorzysta obiekty klasy A. Klasa B zawiera dani do inicjalizacji klasy A

Problem. Kto jest odpowiedzialnym za stworzenie egzemplarzy klas?

151

Rys.4Obiekt Sale agreguje obiekty SalesLineItem, dlatego on musi odpowiadać za stworzenie tych obiektów. Obiekt Register wykorzysta obiekt SALE oraz zawiera dani do inicjalizacji tego obiektu. Rys. 1, 4

Wzorzec Low CouplingDecyzja: Wyznaczyć odpowiedzialność obiektów klas w ten sposób, żeby stopień powiązań klas pomiędzy sobą była mała. Problem. W jaki sposób uniezależnić wpływ możliwych zmian oprogramowania oraz zwiększyć możliwość wielokrotnego wykorzystania? Stopień powiązania (coupling) obiektu to jest ilość związków z obiektami różnych klas. Wysoki stopień powiązania powoduje następne wady:

Zmiany w powiązanych klasach powodują zmiany w tej klasie Trudno zrozumieć każdą klasę w pojedynce Komplikuje się powtórne wykorzystanie tej samej klasy w innych kooperacjach,

bo ta klasa na sztywne jest połączona z klasami, które nie są potrzebne w innych kooperacjach.

Przykład nieprawidłowego wykorzystania wzorca(rys.5):

152

Zgodnie z wzorcem Creator Obiekt Register tworzy obiekt Payment oraz potem przesyła ten obiekt jako parametr P do obiektu Sale.

Rys.5Przykład prawidłowego wykorzystania wzorca (rys.6):Obiekt register tworzy się obiekt sale. Obiekt Sale tworzy się obiekt Payment.

Rys.6

Wzorzec High Cohesion Decyzja: Wyznaczyć odpowiedzialność w sposób pozwalający otrzymać wysoki stopień zaczepienia wewnątrz każdego obiektu. Problem. W jaki sposób można sterować poziomem komplikacji klas?Stopień zaczepienia to jest miara powiązania zobowiązań wewnątrz obiektów klasy. Obiekt klasy ma wysoki stopień zaczepienia w przypadkach, kiedy wszystkie go zobowiązania są skojarzone pomiędzy sobą . Obiekty z niskim stopniem zaczepienia realizują zachowania nie skojarzone pomiędzy sobą. Wadami niskiego stopnia zaczepienia są:

Trudność porozumienia zachowań klasy przez projektanta. Komplikacji przy powtórnym wykorzystaniu kodu klasy. Trudności na etapie konserwacji Słaba niezawodność , częste zmiany.

Przykład. Trzeba stworzyć egzemplarz obiektu Payment oraz powiązać go z obiektem realizującym sprzedaż – Sale. Realizacja z niskim stopniem zaczepienia ( rys 5). W tym przykładzie klasa Register realizuje następne funkcje:

153

1. Tworzy się egzemplarz P klasy Payment - operacja createPayment() w klasie Payment.

2. Tworzy komunikat do klasy Sale dla przekazania obiektu P- operacja addPayment (P) w klasie Sale.

Realizacja z wysokim stopniem zaczepienia ( rys 6). W tym przykładzie klasa Register realizuje następną funkcję:

1. Tworzy się egzemplarz klasy Sale.Oprócz tego te rozwiązanie ma mały stopień powiązania pomiędzy klasami. Wzorzec High Cohesion ma analogię w świecie rzeczywistym. Pracownik w firmie działa nie efektywne, kiedy pełni dużo różnych funkcji, którzy mogą być rozproszone wśród innych pracowników. Z pojęciem zaczepienie jest skojarzona modułowość oprogramowania. Moduł programowy zawiera metody i klasy z dużym stopniem zaczepienia. Powiązanie oraz zaczepienie są skojarzony pomiędzy sobą. Złe powiązanie powoduje słabe zaczepienie.

Wzorzec ControllerDecyzja: Delegowanie zobowiązań dla obrabiania zdarzeń systemowych do klasy, która może pełnić jeden s następnych warunków:

Klasa prezentuje cały system, lub podsystem (kontroler zewnętrzny) Klasa prezentuje scenariusz pewnego przypadku Użycia który może mieć

stereotypy <USECASE>Handler, <USECASE>Coordinator lub <USECASE>Session.

W drugim przypadku dla wszystkich zdarzeń systemowych w ramach tego samego scenariusza musi być wykorzystana ta sama klasa-kontroler. Klasy realizujące interfejsy z użytkownikom nie mogą pełnić funkcje kontrolerów. Klasy interfejsów otrzymują komunikaty od użytkowników i przekazują ją do kontrolerów. Problem. Jaka klasa musi odpowiadać za obrabianie zdarzeń systemowych? Zdarzenie systemowe to jest zdarzenie na wyższym poziomie które jest inicjowane przez aktora. Zdarzenia systemowe są skojarzone z operacjami systemowymi, zwłaszcza z operacjami, którzy realizują się przez system( w odpowiedź na zdarzenia systemowe). Np. , przy kliknięciu przycisku „wypłata” zostanie wygenerowane zdarzenie systemowe pro zakończenie transakcji handlowej. Kontroler to jest obiekt odpowiadający za realizację operacji systemowych. Kontroler nie może być jednocześnie interfejsem użytkownika. Przykład. Zdarzeniami – operacjami systemowymi są:

endSale() enterItem() makeNewSale() makePayment()

Na rys. 1 dla realizacji funkcji kontrolera została wybrana klasa Register, która prezentuje cały system. W przypadkach, kiedy kontroler jest stworzony dla scenariusza przypadku Użycia każdy przypadek użycia musi mieć swój kontroler. Kontrolery przypadków użycia należy wykorzystać kiedy kontroler prezentujący cały system ma mały stopień zaczepienia oraz jest obciążony odpowiedzialności.

154

Wzorce architektury aplikacji WWWKażda aplikacja WWW może zawierać następne komponenty architektury : HTML/XML browser na komputerach klienta Serwer WWW Serwer aplikacji Protokół HTTP (lub inny) Strony na poziomie serwera WWW Strony na poziomie browsera.Wzorce projektowe aplikacji WWW odwzorowują strukturę jednostek programowych realizujących zadania aplikacji. Wzorzec zawiera zbiór podsystemów z wyznaczeniem ich zobowiązań. Istnieją trzy ogólnych wzorce WWW:

1. Wzorzec na bazie „chudego klienta” (Thin Web Client). Klient wykorzysta przeglądarkę z formularzami do uzupełniania. Wszystkie operacji z logiką biznesową realizują się na serwerze. Komunikacja z klientem realizuje się przez protokół HTML.

2. Wzorzec na bazie „tłustego klienta” (Thick Web Client). Klient może wykorzystać dynamiczny HTML, aplety Java, kontrolki ActiveX. Komunikacja z klientem realizuje się przez protokół HTML.

3. Wzorzec na bazie mechanizmów dostarczania WWW (Web Delivery). Dla komunikacji pomiędzy klientem a serwerem oprócz protokołu HTTP mogą wykorzystać się IOOP, DCOM, CORBA oraz inne które są wykorzystane dla połączenia z obiektami rozproszonymi. Browser jest wykorzystany jako kontener systemu rozproszonych obiektów.

Wzorzec architektury Thin Web Client. Główne komponenty architektury wzorca architektury Thin Web Client są pokazane w „Pattern_WEB”. Na tym schemacie są pokazane:Browser - Przeglądarka (Client browser) - zawiera formularzy HTML, wykorzysta się jako interfejs z klientem. Zawiera możliwości przechowywania i wywołania danych cookie. Serwer WWW – to jest punkt główny dla dostępu wszystkich browserów do aplikacji WWW. W zależności od żądania serwer WWW może inicjować odpowiednie procesy. Rezultatem jest strona HTML. Protokół HTTP - to jest element architektury opisujący ustalenia związku pomiędzy klientem a serwerem. Protokół HTTP nie popiera pamięć łącza. Za każdym razem przy wymianie informacji pomiędzy klientem a serwerem trzeba ustalić nowe łącze. Protokół HTTP może mieć rozszerzenie w postaci protokołu SSL (Secure Cockets Layer). W takim przypadku dani są zaszyfrowane.

155

Strony HTML (HTML page) – to są strony WWW z interfejsem użytkownika, którzy nie potrzebują procesów obrabiania skryptów, bo nie zawierają żadnych kodów oprócz znaczników HTML. Strony serwerowe (Server page) - to są strony WWW, którzy muszą wywołać procesy do obrabiania swoich scenariuszy(ASP,JSP). Te strony mają dostęp do wszystkich resursów logiki biznesowej, baz danych oraz do systemów zewnętrznych. Serwer aplikacji - to jest główne narzędzie do realizacji procesów biznesowych. Serwer aplikacji może być realizowany w tej samej przestrzeni procesu, że serwer WWW. Głównym zadaniem serwera aplikacji jest realizacja kodów scenariuszy procesów biznesowych. Serwer aplikacji został wydzielony do oddzielnego elementu architektury. Główne zasady zachowania wzorca Thin Web Client :

1. Logika biznesowa aplikacji jest uruchomiana tylko jako odpowiedź na polecenie odpowiedniej strony WWW przez klienta.

2. Klient współdziała z systemem przez protokół HTTP dla otrzymania stron z serwera WWW. Kiedy polecana strona jest plikiem HTML, to serwer WWW bezpośrednio przesyła je do klienta.

3. Kiedy strona serwera zawiera scenariusz, to ten scenariusz musi być opracowany przez serwer aplikacji. Serwer aplikacji interpretuje scenariusz i w razie potrzeby zwraca się do resursów serwera , np. do Serwera baz danych, Serwera poczty elektronicznej, innych systemów itp.

4. Dla uruchomienia logiki biznesowej musi być ustalone łącze pomiędzy klientem a serwerem. Po obrabianiu scenariusza z logiką biznesową łącze pomiędzy klientem a serwerem będzie rozerwane.

Wzorzec architektury Thick Web ClientW tym wzorcu dla realizacji logiki biznesowej w części klienskiej aplikacji wykorzystają się komponenty JavaBean, ActiveX lub aplety Java. Mogą być także wykorzystane scenatiusze klienckie. Główne zasady zachowania wzorca Thick Web Client :

1. Logika biznesowa aplikacji jest uruchomiana tylko jako odpowiedź na polecenie odpowiedniej strony WWW przez klienta oraz część logiki biznesowej może być zrealizowane na poziomie klienta.

2. Strona klienta może zawierać scenariusze, komponenty ActiveX, aplety Java. Scenariusze mogą być wykorzystane dla sprawdzenia danych. Scenariusze zawierają zdarzenia, którzy są częścią modelu obiektowego DOM (Document Object Model).

3. Interfejs DOM pozwoli scenariuszom klienckim mieć dostęp do dokumentów XML.

156

Rozszerzenie języka UML dla modelowania aplikacji WWWRozszerzenie języka UML musi wykorzystać mechanizmy którzy pozwalają stworzyć nowe typy „elementów budowlanych” w modelu. Rozszerzenie zawiera następne właściwości tych elementów: Stereotypy (stereotype) Wartości tegowane (tagged value) Ograniczenia (constraint).Stereotyp to jest rozszerzenia słownika UML. Stereotyp pozwala skojarzyć z nowym elementem modelu nowy sens semantyczny. Stereotyp może być zastosowany do dowolnego elementu. Na diagramie stereotyp jest odwzorowany w znacznikach <<stereotyp>> klasy.Wartość tegowana to jest rozszerzenie właściwości elementu modelu. Większość elementów modelu już mają skojarzone z nimi właściwości. Na przykład wszystkie klasy mają nazwiska, atrybuty itp. Wartość tegowana pozwoli ustalić nową właściwość, która będzie skojarzona z każdym elementem. Na diagramie wartość tegowana jest odwzorowana za dopomogą wierszy w nawiasach().Ograniczenia to są rozszerzenia semantyki języka. To są reguły definiujące w jaki sposób elementy modelu mogą współpracować z innymi elementami. Ograniczenia wyznaczają warunki, którzy są niezbędne dla stworzenia całego modelu. Dani ograniczenia na diagramie mogą być odwzorowane za dopomogą wierszy w nawiasach{}.

Stereotypy do modelowania klas:1. Strona serwera.Stereotyp Server PageKlas metamodeli KlasaOpis To jest model strony WWW która zawiera skrypty scenariuszy.

Scenariusze współdziałają z bazami danych, logiką biznesową, systemy zewnętrzne oraz innymi resursami serwera. Operacji tej klasy - to są funkcji scenariusza. Atrybuty – to są zmienne to są zmienne widoczne w zasięgu całej strony.

Ograniczenia Strony serwerowe mogą mieć związki asocjacyjne tylko z obiektami serwera

Wartości tegowane

Zasób dla stworzenia scenariusza (JavaScript, Vbscript, Perl itd)

157

2.Strona klienta Stereotyp Client PageKlas metamodeli KlasaOpis Egzemplarzem strony klienckiej jest strona WWW w formacie HTML,

elementy interfejsu oraz część logiki biznesowej która jest uruchomiana w scenariuszy na poziomie klienta. Te scenariusze są interpretowane przez przeglądarkę. Operacji tej klasy (funkcji) - to są funkcji scenariusza którzy zostali zdefiniowane w deskryptorach strony. Atrybuty – to są zmienne którzy widoczne oraz dostępne każdej funkcji strony. Strony klienckie mogą mieć asocjacji z innymi stronami klienta oraz serwera.

Ograniczenia - Wartości tegowane

TitleTag – Tytuł strony, który odwzorowuje przeglądarka. BaseTag - Adres bazowy URLBodyTag – Zbiór atrybutów dla deskryptora <body> , którzy wyznaczają odpowiednie właściwości, np. tekst, kolor itp.

3.Formularz Stereotyp FormKlas metamodeli KlasaOpis Ta klasa jest zbiorem pól typu Input oraz jest częścią strony klienckiej. Ta

klasa może być przekształcona bezpośrednio w deskryptor HTML <form>. Atrybuty tej klasy to są pola tekstowe, typu Input, Password, Radio i inne. Klasa nie zawiera żadnych operacji. Wszystkie operacji na formularzu to są funkcji strony klienckiej, zawierającą ten formularz.


Metoda Get lub POST

4.Układ ramek Stereotyp FramesetKlas metamodeli KlasaOpis Ta klasa jest układ ramek (frameset) który może być kontenerem kilka

stron WWW. Zawartością każdej ramki może być strona WWW lub inna ramka. Klasa ze stereotypem <<Frameset>> musi być przekształcona w układ ramek strony WWW oraz znacznik HTML <frame> ..</frame>.


Rows, Cols - to są wartości właściwości „rows” oraz „cols” znacznika HTML <frameset>

158

5.Ramka Stereotyp TargetKlas metamodeli KlasaOpis Ta klasa jest oddzielnej ramką docelowej (target) w której mogą być

odwzorowane strony WWW. Ograniczenia - Wartości tegowane

-

Stereotypy modelowania asocjacji 1.LinkStereotyp LinksKlas metamodeli Asocjacja Opis To jest link ze strony klienckiej (Client Page) do innej strony klientckiej

lub do strony serwerowej (Server Page). Asocjacja <<Links>> przekształcona jest do znacznika <a> HTML


Parameters - Lista parametrów, którzy są przekazane razem z poleceniem do strony

2.Targeted LinkStereotyp Targeted linksKlas metamodeli Asocjacja Opis To jest link do innej strony klienckiej która musi być odwzorowana w

innej ramce. Asocjacja <<Links>> przekształcona jest do atrybutu „target” znacznika <a> HTML .


Parameters - Lista parametrów, którzy są przekazane razem z poleceniem do stronyTarget - imię ramki docelowej gdzie będzie odwzorowana strona.

3.Frame Content Stereotyp Frame ContentKlas metamodeli Asocjacja Opis To jest agregacja innych ramek lub stron klienckichOgraniczenia - Wartości tegowane

RowCol

159

4.Submit Stereotyp SubmitKlas metamodeli Asocjacja Opis Asocjacja Submit łączy się klasy <form> oraz <server page>. Formularzy

przekazują wartości swoich pól dla obrabiania na poziomie serwera. Serwer WWW obrabia stronę <server page>, która otrzyma dani z formularza.


Parameters – Lista parametrów , którzy muszą być przekazane do strony.

5.BuidStereotyp BuildKlas metamodeli Asocjacja Opis <build> to jest typ asocjacji pomiędzy stronami <server page> oraz

<client page>. Strony <server page> istnieją tylko na serwerze oraz są przeznaczone dla stworzenia stron klienta. Ta asocjacja wyznaczy, jaka strona <server page> ma zobowiązanie stworzyć odpowiednią stronę <client page>. Ta asociacja jest skierowana od <server page> do <client page>, strona kliencka nie wie , przez którą stronę <server page> została stworzona.


-

6.RedirectStereotyp RedirectKlas metamodeli Asocjacja Opis To jest asocjacja która wyznaczy przejście pomiędzy stronami <client

page> <server page> lub < Frameset>Ograniczenia - Wartości tegowane

-

7.Protokół IIOP (Internet Inter –ORB Protocol)Stereotyp IIOPKlas metamodeli Asocjacja Opis Asocjacja odwzorowuje mechanizm współpracy pomiędzy obiektami

klienta a serwera przez protokół IIOP. Ta asocjacja łączy się komponenty JavaBeans z EJB na serwerze.


-

160

8.Mechanizm RMIStereotyp RMIKlas metamodeli Asocjacja Opis To jest mechanizm przekazania parametrów pomiędzy apletami Java i

komponentami Java Beans do innych komponentów Java Beans na innych komputerach.


-

161

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

Od DOClient Page Server Page Frameset Target Form

Client Page link link link Dependency AggregationTargeted link Targeted link Targeted linkRedirect Redirect Redirect

Server Page Build Redirect RedirectRedirect Build

Frameset Frame Content Frame Content Frame ContentTarget - - - - -Form - Submit

162

163

Modelowanie aplikacji ASP w UMLTechnologia ASP jest technologią klient-serwer. Główne logiczne elementy aplikacji ASP są pokazane na rys. 111a. Główną cechą ASP jest rozdzielenie obiektów na dwie postaci: postać klienta i postać serwera. To oznaczy, że każdy obiekt może istnieć jednocześnie w postaci skryptu ASP na serwerze WWW oraz w postaci strony HTML w przeglądarce klienta. Standardy UML nie zawierają bezpośrednio zasobów dla modelowania technologii ASP. Dla stworzenia diagramów klas, przebiegu i kooperacji trzeba wykorzystywać mechanizmy rozszerzenia UML. Rozszerzenie może być realizowane przez nowe stereotypy klas UML. Strony ASP niestety nie są obiektami, które reprezentują klasy z ich metodami. Obiekty ASP są procedurami. Proces obrabiania strony ASP polega na uruchomianiu całego skryptu ASP ( od pierwszego operatora do ostatniego tego skryptu). Wszystkie funkcji na tym skrypcie będą uruchomiane po kolejce przy odwołaniu do tej strony ASP. Kod skryptu można rozpatrywać jako jedną metodę typu main().Na rys. 111 b jest pokazane diagram przypadków użycia systemu sprzedaży artykułów przez internet.

rys.111a

164

Rys. 111 b.Scenariusze oddzielnych przypadków użycia są pokazane niżej: Przypadek użycia „ Rejestracja ”. Scenariusz główny:1. Klient naciśnij się przycisk „Rejestracja”. 2. System odwzorowuje stronę rejestracji.3. Klient uzupełni formularz rejestracji oraz naciśnij się przycisk „Logowanie” .4. System sprawdzi się dani klienta z kontem w bazie danych. 5.System formuje obiekt sesji użytkownika. System formuje strone z trybami menu użytkownika . Scenariusz alternatywny:1a. Kiedy klient naciśnij się przycisk „ Nowe konto”, System wywoła przypadek użycia „ Nowe konto”.5a. Kiedy klient wpisal niepoprawne hasło, system formuje komunikat oraz proponuje nowe logowaniePost-Condition: 1.Strona klienta zawiera przyciski z dostępem do innych stron systemu.2.Została zformowana zmienna sessijna „Log=YES”Przypadek użycia „Nowe konto”.Scenariusz główny. 1. Klient wpisze swoje imię, adres poczty elektronicznej oraz hasło (2 razy), potem

naciśnij się przycisk „Nowe konto”.2. System sprawdzi się poprawność danych.3. System tworzy obiekt z danymi klienta oraz zachowa dani klienta do bazy danych.

165

4. System formuje stronę początkową Klienta Scenariusze alternatywne.1.a. Kiedy Klient nie uzupełnił pole „Imię” system formuje komunikat pro błąd oraz proponuje wpisać imię.1.b. Kiedy format poczty elektronicznej nie jest prawidłowy system formuje komunikat pro błąd oraz proponuje wpisać adres poczty elektronicznej.1.c. Kiedy Klient wpisał krótkie hasło, system formuje komunikat pro błąd oraz proponuje wpisać dłużcie hasło.1.d. Kiedy dwa hasła klienta wyróżniają się system formuje komunikat pro błąd oraz proponuje wpisać nowe hasło.Przypadek użycia „Zmienić zawartość koszyka”Scenariusz główny. 1. Na Stronie Przeglądania Koszyka Klient zmieni się ilość Towaru i naciśnij przycisk

„Ponowić”2. System przechowa informacje pro ilość towaru, po tym oblicza nową cenę i

odwzorowuje te dani3. Klient naciśnij przycisk „Kontynuować zakup”. System wróci się z powrotem do

wywołującego przypadku użycia. Scenariusze alternatywne.1a. Kiedy Klient zmieni się ilość Towaru na 0, to system usuwa Towar z koszyku.1b. Kiedy Klient naciśnij przycisk „Usuwać” (a nie „Ponowić”), to system usuwa Towar z koszyku.1c. Kiedy Klient naciśnij przycisk „Potwierdź Zamówienie”, to system odwołuje się do przypadku użycia „Potwierdzenie zamawiania”.Przypadek użycia „Stworzenie zamawiania”.Scenariusz główny. 1. Klient nacisnął się przycisk „Utwórz Zamówienie”. 2. System sprawdzi się zawartość koszyka. System wylicza się ceny towarów dla każdej

pozycji koszyka, podatki, wartość dostawy oraz wartość całego zamawiania. 3.System formuje rachunek zamawiania (Paragon) z danymi klienta, nazwami pozycji towarów, ich cenami, ceną całego zamawiania, wartością dostawy, podatkami oraz odwzorowuje wszystko na stronie Klienta.

4. Klient potwierdzi zamawianie naciśnięciem przycisku „Zamów” 5. System przechowa zamawianie w pliku zamówień. System wywołuje przypadek

użycia „ Dostawa zamawiania”.Scenariusze alternatywne.1a. Kiedy Klient nacisnął przycisk „Return” odwołuje się do poprzedniego przypadku użycia.4.a. Kiedy Klient nacisnął przycisk „Skasuj” System usuwa dani koszyku i odwołuje się do poprzedniego przypadku użycia.4b. Kiedy Klient nacisnął przycisk„Zamów” oraz koszyk jest pusty system formuje komunikat „Koszyk Pusty!” oraz wróci się do poprzedniego przypadku użycia.Pre-Condition: Klient nacisnął przycisk „Potwierdź Zamówienie”.Post-Condition: Zamawianie jest w pliku zamówień.

166

Przykład realizacji związków klas przy realizacji sprzedaży jest pokazany na rys. 111 c. Na tym rysunku jest wykorzystane stereotypy <<ServerPage>> oraz <<ClientPage>> klas stron ASP. Związki realizują stereotypy<<Build>> oraz <<link>>.

rys. 111 cDiagram przebiegu przypadku użycia „Rejestracja” jest pokazany na rys. 111 d.

167

Rys 111 dDiagram przebiegu Przypadku użycia ”Stworzenie zamawiania” jest pokazany na rys. 111e.

Rys. 111 e.

168

Ten diagram nie zawiera konkretnych obiektów. Wszystkie obiekty są reprezentowane przez obiekt „System”. Ten samy diagram z konkretnymi obiektami jest pokazany na rys. 111f.

Rys. 111f.Diagram kooperacji Przypadku użycia ”Stworzenie zamawiania” jest pokazany na rys. 111g.

169

Rys 111 g

Modelowanie aplikacji JSP w UMLStrona JSP zawiera kod JAVA, który jest implementowany do dokumentu HTML. Tegi HTML odwzorowują statyczną część dokumentu oraz tegi specjalne JSP odwzorowują go dynamiczną część. Wywołanie strony JSP na serwerze powoduje uruchomienie kodu części dynamicznej tej strony, oraz rezultat obrabiania tegów specjalnych razem z częścią statycznej musi być przesyłany do klienta. W technologii JSP Strony JSP są wykorzystywane dla realizacji funkcji prezentacyjnej, to znaczy dla odwzorowania rezultatów obrabiania informacji (stereotyp klasy VIEW w modelu MVC). Dla realizacji funkcji logiki biznesowej (stereotyp klasy CONTROLLER w modelu MVC) w technologii JSP mogą być wykorzystywane serwlety, komponenty JavaBean, komponenty J2EE. Serwlety realizują się w kontenerach serwletów (WEB-kontenerach), które są w serwerach WWW. Aby realizować żądania klienta za pomocą serwletów, serwer WWW musi obsługiwać interfejs Javy Servlet API. Serwer WWW musi zatem posiadać wbudowaną obsługę serwletów. Serwlety reprezentują klasy Java, oraz rozszerzają jedną z dwóch klas

170

realizacji: HttpServlet (serwlet HTTP) lub GenericServlet (serwlet uniwersalny) . Życiowy cykl serwleta(rys.113) klasy GenericServlet zawiera trzy główne metody: Init() – inicjalizacja serwleta, Service () obsługiwanie polecenia klienta, Destroy() usuwanie serwleta.

Rys. 113Metoda Service () to jest główna metoda serwleta, która realizuje logikę. W tej metodzie muszą być zrealizowane następne czynności: Otrzymanie poleceń od klienta Czytanie danych polecenia Stworzenie i zapisywanie obiektów dla odpowiedzi.Serwlety są sterowane przez polecenia od stron JSP lub innych serwletów. Do serwleta może być przesłany uzupełniony formularz zawierający różne pola. Kiedy serwer WWW (kontener serwleta) otrzyma polecenia do serwleta, on inkapsuluje otrzymane dani w obiekt ServletRequest (obiekt polecenia) i przesyła ten obiekt jako pierwszy parametr do metody service(). Po tym serwlet może realizować obrabianie obiektu polecenia za dopomogą następnych metod interfejsu ServletRequest: getCharacterEncoding – otrzymać format kodowania w obiekcie polecenia isSecure – czy był wykorzystywany bezpieczny kanał getParameterNames – otrzymać listę parametrów polecenia getRemoteAddr – otrzymać IP klienta getParameter – otrzymać wartość parametru

171

Polecenie zawsze potrzebuje odpowiedzi. Odpowiedź może być realizowana przez obiekt ServletResponse, który jest przesyłany przez drugi parametr do metody service(). Obiekt ServletResponse zawiera metody dla generacji kodu na stronie JSP: getOutputStream – deskryptor obiektu ServletOutputStream dla binarnych danych getWriter - deskryptor obiektu PrintWriter dla znakowych danych – pozwoli

generować tegi dla stron JSP oraz inne. Klasa HttpServlet rozszerza klasę GenericServlet oraz dlatego dziedziczy wszystkie metody GenericServlet. Klasa HttpServlet oprócz bazowych metod zawiera metody dla obrabiania poleceń HTTP (Rys 113a): doGet() – obrabia polecenia HTTP GET doPost() - obrabia polecenia HTTP Post doPut() - obrabia polecenia HTTP Put doDelete() - obrabia polecenia HTTP Delete doOptions() - obrabia polecenia HTTP OPTIONS doTrace() - obrabia polecenia HTTP Trace.

rys.113aJest docelowym stworzenie każdego serwleta realizować oddzielnie dla wyznaczonego zadania lub funkcji. Komplikowane zadania w ten sposób będą realizowane za dopomogą wielu serwletów. Sterowanie tymi serwletami może być realizowane przez wykorzystanie interfejsu RequestDispatcher. Ten interfejs zawiera następne metody:

172

Forward. Za dopomogą tej metody serwlet przekazuje polecenie innemu WEB komponentu (stronie WWW lub serwletu). Ta metoda pozwoli formować ciągi serwletów, każdy z których formuje swoje dane i przekazuje ich do kolejnego serwletu.

Include. Ta metoda pozwoli włączyć treść jednego WEB komponenta do innego serwleta.

Technologia wykorzystywania stron JSP jest bardzo podobna do serwletów. W rzeczywistości, skrypty JSP są kompilowane do postaci serwletów. Strona JSP jest plikiem, który w czasie pracy serwera WWW jest przekształcany w serwlet. Poważną różnicą pomiędzy skryptami JSP a serwletami jest sposób kodowania: strony JSP nie są czystym kodem Javy, koncentruje się na interfejsu użytkownika. Skrypty JSP nie wymagają kompilatora Javy. Komponenty JavaBeans odróżniają się od standardów Enterprise JavaBeans. JavaBeans to są klasy Javy zawierające standardowy zestaw metod get() i set(). Są komponentami Javy wielokrotnego użytku zawierającymi własności, zdarzenia i metody (podobne do kontrolek ActiveX firmy Microsoft), które można łatwo wykorzystać w celu stworzenia (często wizualnych) aplikacji Javy. JavaBeans są znacznie mniejsze od Enterprise JavaBeans , mogą być wykorzystywane dla do budowy większych komponentów lub całych aplikacji. JavaBeans nie są komponentami przeznaczonymi do natychmiastowego stosowania, wymagają pewnej obróbki. Ponieważ komponenty te nie mogą funkcjonować samodzielnie, nie wymagają specjalnego środowiska uruchamiania ( jako komponenty Enterprise JavaBeans). Ponieważ JavaBeans są zwykłymi klasami Javy, nie potrzebują serwera aplikacji do instalacji, niszczenia czy łączenia z innymi usługami. W technologii JSP strona klienta może być stworzona następnymi sposobami: bibliotek plików HTML Za dopomogą serwletów Za dopomogą komponentów JavaBeans. Modelowanie technologii JSP w UML zawiera trudności które polegają w tym, że każdy komponent JSP(skrypt) istnieje w dwóch postaci :

1. W postaci strony WWW na stronie klienta;2. W postaci skryptu części kodu, który musi być realizowany na stronie serwera.

To nie pozwoli wykorzystać standardowe konstrukcji UML dla diagramów klas, systemów informatycznych w technologii JSP. Jednak UML zawiera mechanizmy rozszerzenia, które można wykorzystać dla modelowania WEB procesów. Dla modelowania technologii JSP w standardzie UML trzeba rozdzielić każdy komponent JSP na dwa klasy:

173

1. Strona klienta <<ClientPage>>. Ta klasa modeluje zachowanie elementu JSP na stronie klienta oraz wszystkie zewnętrzne go prezentacje. Strony klienta mogą mieć asocjacji z resursami na stronie klienta, np. z innymi stronami klienta, apletami, formularzy, komponentami JavaBeans itp.

2. Strona serwera <<ServerPage>>. Ta klasa odwzorowuje zachowanie komponentu JSP na stronie serwera. Strony serwera mogą mieć relacji z resursami na stronie serwera., np. zewnętrzne systemy, bazy danych, serwletami, z innymi stronami na stronie serwera.

Relacja pomiędzy stroną klienta a stroną serwera ma charakter „ jest pobudowany” , typ tej relacji jest pokazany na rys.114 .

Rys. 114Strona klienta oprócz związków ze własną stroną serwera może mieć także relacje z następnymi obiektami: Innymi stronami aplikacji. Relacje mogą być wejściowymi lub wyjściowymi ze

stereotypem <<Link>>. Apletami. Aplety modelują się w wyglądzie klas ze stereotypem <<Java Applet>>.

Relacji pomiędzy stroną klienta oraz apletem występują jako agregacji. Aplet to jest specjalna klasa Java, kontenerem której jest przeglądarka klienta. Aplet działa na stacji klienta oraz jest wywołany przez specjalne tegi przeglądarki.

Formularzami. Formularz pozwoli otrzymać dani klienta przez przeglądarkę. Formularz modeluje się w postaci klasy ze stereotypem <<Form>>. Pola formularza muszą być atrybutami tej klasy.

Przykład różnych relacji strony klienta jest pokazany na rys 115.

174

Rys.115Związki elementu JSP na stronie serwera mogą występować w następnych kategoriach:

1. Z innymi stronami serwera za dopomogą relacji <<Forward>> oraz <<Include>>.2. Z Serwletami za dopomogą relacji <<Forward>>. Serwlet to jest specjalna klasa

Java, która jest analogiczna apletu, ale działa tylko na serwerze WWW. Serwlety są przeznaczone dla obrabiania poleceń protokołu HTTP od WWW-klienta. Serwlet nie ma swego interfejsu graficznego. Kontenerem dla serwletu jest serwer WWW.

3. Z obiektami niejawnymi za dopomogą asocjacji. Do obiektów niejawnych mogą być odniesione obiekty następnych typów:

Request – identyfikuje polecenie, które inicjuje aktywację strony Serwera Response – odpowiedź na polecenie PageContext - dostęp do atrybutów strony Session - obiekt sesji Application – obiekt aplikacji Out – obiekt dla zapisywania do W/W Config – obiekt konfiguracji serwletu Page – bezpośrednio sam element JSP Exception – wątek, który formuje komunikat pro błędy.

4. Z komponentami JavaBeans za dopomogą asocjacji ze stereotypem <<UseBean>>. Ta relacja odwzorowuje obecność tegu JSP:USEBEAN, który pozwoli wywołać JavaBeans ze stron JSP (patrz poprzedni rysunek)

5. Z innymi klasami za dopomogą asocjacji UML

175

6. Z bibliotekami tegów. Strony JSP mogą mieć tegi, które wyznaczają klasy do wywołania z bibliotek. Taki relacji modelują się jako zależności pomiędzy stroną JSP oraz klasy bibliotek tegów.

7. Z komponentami J2EE. Strona serwera może wywołać metody komponentu J2EE. Taka relacja jest odwzorowana przez związek asocjacji pomiędzy stroną serwera oraz interfejsami komponentu J2EE.

Przykład diagramu klas z związkami stron serwera JSP jest pokazany na rys 116.

Rys 116Rozpatrzymy model obiektowy systemu informatycznego banku rys. 117.

176

Rys. 117.Scenariusz przypadku użycia „Wejście do systemu” zawiera następnie kroki:Scenariusz główny:1. Klient uruchomi stronę logowania2. System wyświetli się formularz3. Klient uzupełni się formularz

4.Klient przesyła się swoje dani do systemu

5. System sprawdzi się dani klienta6. System uruchomi przypadek użycia „Lista operacji”Scenariusz alternatywny6.a IF Klient nie ma uprawnień THEN System formuje stronę dla logowania Realizacja p.4 scenariusza może być realizowana przez serwlet. Diagram przebiegu, który realizuje ten scenariusz jest pokazany na rys. 118. Strona serwera login.JSP jest wejściem tego przypadku użycia. Ta strona formuje stronę klienta loginClient.JSP, która zawiera formularz „Form” i jest uruchomiana na stacji klienta. Kiedy użytkownik uzupełni się formularz oraz przesyła go do serwera, serwlet otrzyma rezultaty. Dla sprawdzenia poprawności danych klienta serwlet może odwołać bezpośrednio do bazy

177

danych lub wywołać obiekty encji J2EE (na diagramu te związki nie są pokazane). Kiedy logowanie nie będzie skutecznym, serwlet sformuje komunikat pro błędy i wróci się do strony login.JSP .

Rys.118Inaczej , kiedy logowanie jest skutecznym, serwlet wywoła stronę main.JSP. Na rys.119 jest pokazany diagram kooperacji tego przypadku użycia.

Rys 119Diagram klas jest pokazany na rys. 120.

178

Rys.120Przypadek użycia „Lista operacji” jest przeznaczony dla wyznaczenia operacji dostępnych klientowi po logowaniu. Te operacji są skojarzone z każdym klientem i są przechowywane w bazie danych. Przypadek użycia zawiera następne kroki:1. System czyta dani klienta .2. System formuje stronę z operacjami dostępnymi klientowi.Ten przypadek użycia można rozpatrzyć bardziej szczegółowe, wykorzystując komponenty JSP:

1.System uruchomi serwlet dla formowania listy dostępnych operacji.2.Serwlet odczyta dani z bazy danych i danych sesji.3.Serwlet przechowa dani w obiekcie Bean.4.Serwlet przechowa sam obiekt Bean w sesji.5.Serwlet uruchomi skrypt dla formowania strony z listą operacji.

Diagram klas jest pokazany na rys. 121. Na rys. 122 jest pokazany diagram przebiegu tego przypadku użycia. Serwlet otrzyma dani od formularza, przesyła te dani do komponentu JavaBeans za dopomogą metody setTransactinfo() oraz formuje polecenie do strony ListTransact.JSP. Komponent ListTransact.JSP uruchomi Bean TransactInfo za dopomogą tegu <jsp:UseBean..>, otrzyma dani klienta oraz odwzorowuje informację dla użytkownika formując stronę ListTransact.Jsp_Client.

179

Na rys. 123 ten samy diagram jest skojarzony z klasami. Na rys. 124 jest pokazany diagram kooperacji tego przypadku użycia.

Rys. 121

Rys. 122

180

Rys. 123

Rys.124

Modelowanie komponentów Enterprise JavaBeans (EJB)Enterprise Java Beans (EJB) jest komponentową architekturą aplikacji działających po stronie serwera, która znacznie upraszcza proces budowy,

181

przeznaczonych dla przedsiębiorstw , rozproszonych aplikacji komponentowych a Javie. Główne cele EJB to są opracowanie następnych składni projektu : środowisko oraz narzędzie dla projektowania aplikacji rozproszonych; możliwości dla wielokrotnego wykorzystywania komponentów w różnych

platformach; szablony dla projektowania oraz realizacji aplikacji w środowisku Enterprise Java.Dla realizacji tych celi technologia EJB zawiera następne zasadnicze koncepcje: Kontener. Komponenty EJB są uruchomiane nie bezpośrednio na serwerze, a w

kontenerze. Kontener to jest obiekt programowy, który jest uruchomiany na serwerze oraz jest odpowiedzialnym za sterowanie komponentami. Kontener tworzy środowisko dla uruchomiania komponentów EJB. Kontener jest odpowiedzialnym za sterowanie cyklem życiowym komponentów EJB. W ogóle technologia J2EE wykorzysta następne typy kontenerów:

Kontener aplikacji Java, może zawierać odrębne aplikacje Java (Wirtualna maszyna Java).

Kontener apleta, tworzy środowisko dla uruchomiania apleta (Maszyna wirtualna Przeglądarki) .

WEB – kontener, może zawierać komponenty WEB: serwlety, strony JSP (WWW Serwer) .

Kontener EJB (czyli serwer aplikacji), może zawierać komponenty EJB(Serwer aplikacji). Kontener EJB działa jako warstwa pośrednia pomiędzy kodem klienta a komponentem EJB.

Rys.125Na rys. 125 jest pokazany schemat współdziałania obiektów oraz interfejsów technologii EJB. Główne pojęcia wykorzystywane w EJB mają następne definicji:

182

o Egzemplarz komponentu EJB jest egzemplarzem obiektu klasy komponentu napisanej w Javie. Zawiera implementacje metod biznesowych zdefiniowanych w zdalnym i lokalnym interfejsie. Egzemplarz komponentu EJB nie obsługuje sieci i nie zawiera żadnych instrukcji związanych z komunikacją sieciową.

o Interfejs domowy jest interfejsem Javy wspomagającym wykorzystanie obiektów EJB. W kodzie klienta pracującego z obiektami EJB trzeba korzystać się z interfejsu domowego w celu wygenerowania obiektu EJB. Interfejs domowy jest przystosowany do pracy w sieci, ponieważ klienci korzystają z niego za jej pośrednictwem.

o Obiekt domowy jest wygenerowaną przez kontener implementacja interfejsu domowego. Obiekt domowy obsługuje komunikację sieciową w sposób zgodny z protokołem RMI-IIOP.

o Interfejs zdalny jest interfejsem Javy wyliczającym metody biznesowe udostępniane przez klasę komponentu EJB. W technologii EJB klient zawsze komunikuje się ze zdalnym interfejsem, a nigdy z egzemplarzem komponentu EJB. Interfejs zdalny jest przystosowany do pracy w sieci i spełni się założenia protokołu Java RMI-IIOP.

o Obiekt EJB jest wygenerowaną przez kontener implementacją zdalnego interfejsu. Jest przystosowanym do pracy w sieci pośrednikiem pomiędzy klientem a egzemplarzem komponentu, który obsługuje niezbędne zadania wykonywane przez oprogramowanie pośredniczące. Wszystkie wywołania klienta przechodzą przez obiekt EJB, który przekazuje je do egzemplarzy komponentu.

Szablon Proxy. Komponenty EJB budują się nie w postaci jednolitą lecz na bazie szablonu Proxy. To oznaczy, że komponent jest podzielony na obiekt klienta oraz oddalony obiekt. Użytkownik może współdziałać tylko z interfejsami obiektu klienta. Na rys. 126 jest pokazany schemat interfejsu Proxy. Obiekt Proxy reprezentuje oddalony obiekt RealSubject przez swój interfejs z klientem. Związek z oddalonym obiektem jest realizowany przez asocjację pomiędzy klasami Proxy oraz RealSubject. Oba te obiekty realizują interfejs Subject.

183

Rys. 126 Deskryptor rozmieszczenia . Zawiera opis sposobu zarządzania

cyklem życia komponentów, trwałością kontrolą transakcji czy usługami bezpieczeństwa. Kontener przegląda deskryptor w celu realizacji tych wymagań. W ten sposób jest realizowana możliwość przysposobienia komponentów EJB bez modyfikacji kodów. Deskryptor rozmieszczenia jest plikiem XML.

Specyfikacja EJB zawiera 3 rodzaje komponentów:

1. Komponenty sesyjne (SesionBeans). 2. Komponenty encyjne (EntityBean).3. Komponenty sterowane komunikatami(Message-driven

Beans).

Komponenty sesyjneKomponenty sesyjne są związane z logiką aplikacji, z obiektami procesu biznesowego, implementują logikę biznesową, oraz różne algorytmy i czynności dla klienta. Przykładowo, komponent sesyjny może notować ceny, realizować zamówienie, dokonywać transakcji bankowych, operacji z koszykiem klienta w sklepie, operować na bazie danych, wykonywać skomplikowane obliczenia itp. Komponenty sesyjne mogą być dwóch podtypów:

Stanowe (stateful) komponenty sesyjne Bezstanowe(stateless) komponenty sesyjne.

Stan sesji to są dani, które odwzorowują połączenie oddzielnego (konwersację) klienta z obiektem sesji. Stanowe komponenty zapamiętują swój stan reprezentujący sesję z oddzielnym klientem. Te komponenty pozwalają klientom przerywać sesję oraz potem przedłużać ją z tym samym obiektem sesji. Decyzję pro przerywanie sesji oraz pro zapamiętywanie stany komponentu musi być realizowana tylko przez kontener - Klient nie może bezpośrednio oddziaływać na zachowanie komponentu. Bezstanowe komponenty nie mogą przechowywać swoich stanów. Bezstanowy komponent sesyjny utrzymuje konwersację obejmującą tylko pojedyncze wywołanie metody. Po zakończeniu każdego wywołania metody kontener może wybrać, czy usuwać

184

bezstanowy komponent sesyjny z pamięci czy tworzyć go ponownie. Przykład diagramu klas bezstanowego komponentu sesyjnego jest pokazany na rys. 127. Ten komponent jest przeznaczony dla realizacji procesów biznesowych przypadku użycia „Koszyk” w sklepie Internetowym.

Rys.127Na tym rys. są pokazane klasy oraz interfejsy:

koszykBean (stereotyp „EJBSession”) - klasa realizacji komponentu. Klasa realizacji zawiera kody realizacji wszystkich metod, zdefiniowanych oraz wywołanych w domowym, zdalnym i innych interfejsach, oraz metod, które są potrzebne dla realizacji życiowego cyklu komponentu. Metody życiowego cyklu są wywołane przez kontener.

koszyk (stereotyp „EJBRemote”) – interfejs zdalny. To jest główny interfejs reprezentujący komponent dla aplikacji użytkownika. Klient zawsze komunikuje z tym interfejsem dla wywołania metod biznesowych.

koszykHome (stereotyp „EJBRemoteHome”) – interfejs domowy. Przez ten interfejs realizuje się wygenerowanie obiektów EJB w kontenerze.

koszykLocal (stereotyp „EJBLocal”) – interfejs lokalny, jest bardziej wydajną wersją zdalnego interfejsu. Ten interfejs trzeba używać w przypadkach, gdy komponent EJB działa w tym samym

185

procesie. Wywołanie metod biznesowych nie będzie przechodziło przez namiastki, szkielety, wywołania sieciowe.

koszykLocalHome (stereotyp „EJBLocalHome”) – lokalny interfejs domowy, jest bardziej wydajną wersją interfejsu domowego. Ten interfejs jest interfejsem domowym dla interfejsu koszykLocal.

Klasa realizacji rys.127 zawiera metody: ejbCreate(). Dla każdej metody typu create() w interfejsie domowym musi być

odpowiednia metoda ejbCreate() w klasie realizacji. Np. dla metody typu create() z nazwą create2() w interfejsie domowym musi być odpowiednia metoda ejbCreate2() w klasie realizacji. Uruchomienie metod ejbCreate() realizuje się przez kontener.

ejbRemove(). Ta metoda powoduje usunięcie obiektu EJB oraz może być wywołana przez metodę remove() interfejsów lub przez kontener.

setSessionContext(). Kontener tworzy obiekt kontekstu dla inkapsulacji danych w sesji komponentu. Obiekt kontekstu to jest brama do kontenera, zawiera dani o aktualnym stanie kontenera, metody dla obrabiania tej informacji oraz metody dla sterowania transakcjami. Obiekt EJB może wykorzystać te metody oraz informację. Metoda setSessionContext() udostępni obiekt kontekstu dla EJB.

Metody biznesowe – addItem(), removeAll(), showCartContens(), checkout(), confirmCheckout(), removeItem(). Te metody potrzebne dla realizacji przypadku użycia.

ejbPassivate(), ejbActivate(). Te metody są potrzebne tylko dla stanowych komponentów sesyjnych.

Znak tego komponentu na diagramu komponentów jest pokazany na rys. 128.

Rys.128Cyklem życia komponentów steruje kontener. Diagram stanów bezstanowego komponentu sesyjnego jest pokazany na rys. 129. Ten diagram zawiera dwa stany:

1. Nie istnieje egzemplarz komponentu2. Gotowy.

186

Wszystkie metody, które powodują przejścia pomiędzy stanami nie są inicjowane przez klienta. Kontener samodzielnie decyduje pro wywołanie tych metod. Przejście od stanu 1 do stanu 2 może być powodowane wywołaniem metody create(...) interfejsu domowego. Kontener w tym przypadku tworzy obiekt EJB wywołując następne metody klasy realizacji:

1. Class.newinstance() – to jest konstruktor klasy EJB.2. setSessionContext() – to jest kontekst w obiekcie EJB.3. ejbCreate(...) – to jest odpowiednia metody create(...) w klasie realizacji.

Diagram przebiegu, który realizuje przypadek użycia „koszyk” przez komponent sesyjny „Koszyk” jest pokazany na rys. 130.

Rys. 129

187

Rys. 130

188

Komponenty encyjneKomponenty encyjne reprezentują trwałe dane, dokonywają inkapsulację danych w bazie danych. Te komponenty mają zasoby synchronizacji obiektowych reprezentacji danych (O-R odwzorowanie) w aplikacji klienta z danymi w bazie danych. Przykładami tych komponentów mogą być:

Informacje o koncie bankowym (numer konta, saldo, itp.) Dane o zasobach ludzkich (nazwiska, działy, wynagrodzenia pracowników, itp.) Informacja o klientach(nazwiska, adresy, telefony, itp.).

Komponent encyjny składa się ze standardowego zbioru plików wymaganych dla wszystkich komponentów, jak:

interfejs zdalny, interfejs lokalny; interfejs domowy, interfejs lokalny domowy; klasę komponentu EJB; deskryptor rozmieszczenia.

Wiele egzemplarzy komponentu encyjnego może reprezentować te same dane. Każdy komponent encyjny może obsługiwać w danej chwili tylko jednego klienta. Różnicami pomiędzy komponentami encyjnymi a komponentami sesyjnymi są następne klasy:

Klasa komponentu encyjnego odwzorowuje definicję encji ze schematu bazy danych. Przykładowo, klasa komponentu encyjnego może odwzorowywać definicję tabeli relacyjnej bazy danych. W takim przypadku egzemplarz klasy komponentu encyjnego odwzorowuje wiersz tej tabeli.

Klasa klucza głównego pozwala odróżnić od siebie wszystkie komponenty encyjne. Klucz główny jest obiektem, który może zawierać dowolną liczbę atrybutów.

Przeznaczenie metod komponentu encyjnego:

setEntityContext (), unsetEntityContext() - wywoływane przez kontener EJB. Przy wywołaniu metody set komponent przechowa informację pro obiekt kontekstu w zmiennej lokalnej obiektu EJB. Przez obiekt kontekstu obiekt EJB może mieć dostęp do rozmaitych danych, jak na przykład informacji o transakcjach, bezpieczeństwie. Interfejs kontekstu zawiera metody: getEJBObject(), getPrimaryKey() i in.

ejbCreate () – wywoływana przez obiekt domowy (kontener), inicjalizuje egzemplarz komponentu w pamięci operacyjnej. Dla każdej metody ejbCreate () klasy komponentu musi być zdefiniowana metoda Create () interfejsu domowego. Klient wywołuje z obiektu domowego metodę create(), która przekazuje jego żądanie metodzie komponentu ejbCreate (). Rezultatem wywołania metody ejbCreate () jest wskaźnik obiektu klucza głównego, zaś obiekt domowy przy wywołaniu metody Create () zwraca wskaźnik obiektu EJB.

ejbRemote () - wywoływana przez obiekt domowy (kontener). Aby usunąć dane komponentu encyjnego z bazy danych, klient musi wywołać metodę remove() z obiektu EJB lub zarówno z interfejsu domowego. Metoda ta powoduje, że kontener wywołuje metodę ejbRemote () w komponencie.

189

ejbLoad () – wywoływana przez kontener, wczytuje dane z pamięci stałej do znajdujących się w pamięci operacyjnej pól komponentu encyjnego.

ejbStore () – wywoływana przez kontener, zapisuje dane przechowywane aktualnie w polach egzemplarza komponentu do pamięci stałej.

ejbActivate () - wywoływana przez kontener w momencie wyciągania egzemplarza z puli komponentu. Proces ten, zwany aktywacją, oznacza, że kontenerłączy komponent z konkretnym obiektem EJB i z jego kluczem głównym. Ta metoda powinna pozyskiwać zasoby (np. gniazda), które komponent będzie potrzebował po przypisaniu do konkretnego obiektu EJB.

ejbPassivate () - wywoływana przez kontener w momencie umieszczania egzemplarza w puli komponentu. Proces ten, zwany pasywacją, oznacza, że kontener rozłącza komponent i konkretny obiekt EJB z jego kluczem głównym. Ta metoda powinna zwalniać zasoby (np. gniazda) pozyskane w metodzie ejbActivate (). Podczas pasywacji egzemplarz komponentu musi zachować także zachować swój stan w pamięci stałej. Aby zapisać w bazie danych pola egzemplarza. Kontener przed pasywacją wywołuje metodę ejbStore(). Podobne, podczas aktywacji, aby wczytać dane do egzemplarza komponentu, kontener musi wywoływać metodę ejbLoad().

Istnieją dwa sposoby utrwalania komponentów encyjnych:

1. Zarządzanie trwałością przez komponent2. Zarządzanie trwałością przez kontener.

W przypadku komponentów encyjnych samych zarządzających trwałością, za stworzenie odpowiednich struktur w bazie danych odpowiada metoda ejbCreate() oraz za usuwanie danych z bazy danych odpowiada metoda ejbRemote().

190

Zarządzanie transakcjami w obiektowo-relacyjnych bazach danychCelem systemu zarządzania transakcjami jest takie sterowanie operacjami w bazie danych, aby były one wykonane z możliwie wysokim współczynnikiem współbieżności i aby przeciwdziałać naruszeniu spójności bazy danych. Realizacja tego celu została osiągnięta za pomocą odpowiednich protokołów zarządzania transakcjami.

Cechy transakcjiZ punktu wzoru SZBD transakcja to jest ciąg operacji na bazie danych które muszą być zrealizowane przez tego samego użytkownika lub programu zewnętrznego. Mechanizm transakcji zawiera możliwości zatwierdzenia wszystkich zmian w bazie danych w razie skutecznej realizacji wszystkich operacji lub wycofania wszystkich zmian w razie niepowodzenia jednej z nich. Każda transakcja w momencie inicjowania otrzymuje jednoznaczny identyfikator. Identyfikator ten jest następne związany z każdą operacją składającą się na transakcję. Do operacji tych należą: - czytanie danej x przez transakcję ,

- zapisanie danej x przez transakcję ,

- odrzucenie (wycofanie) transakcji (operacja ABORT),

- zatwierdzenie transakcji (operacja COMMIT).

Mówiąc o danej mamy na myśli jednostki danych na różnych poziomach granulacji – może to być dana elementarna, rekord, zbiór rekordów wyznaczonych przez warunek, tabela bazy danych itp.Przykład 1. Rozważmy system bankowy, w skład którego wchodzą: Baza danych zawierająca dane KONTO1 i KONTO2 wskazujące stan dwóch różnych kont w banku; Program zwracający stan podanego konta:

Info(konto) {X:= read(konto);Return(x);}

Program realizujący przekazanie podanej kwoty z jednego konta na drugie:Przelew(konto_z, konto_na, kwota) {X:= read(konto_z);X:= x-kwota;Write(konto_z,x);

191

X:= read(konto_na);X:= x+kwota;Write(konto_na,x);

}Każde wykonywanie dowolnego z tych programów powoduje utworzenie nowej transakcji. Jeśli w systemie istnieje wiele stanowisk komputerowych, z których programy te mogą być wywoływane, to wiele z tych transakcji będzie współbieżnych, co oznacza, że przed zakończeniem jednej transakcji rozpoczynana jest następna (inicjowana z innego stanowiska komputerowego). To oznaczy, że oddzielne operacji różnych transakcji mogą być przyplątane w różnych szeregach.

Każda transakcja tworzona dla wywołania programu info(KONTO1) ma postać:

= i=1,2,…,

jeśli czytanie zakończyło się pomyślnie lub

= i=1,2,…,

jeśli czytanie się nie powiodło (na przykład podmiot wydający to polecenie nie miał wystarczających uprawnień).

Podobnie, każde wywołanie programu przelew() z konkretnymi parametrami KONTO1 i KONTO2 powoduje utworzenie nowej transakcji dla i=1,2,…, którą możemy zapisać jako ciąg następujących operacji na bazie danych:

= ,

gdzie:

operacja - odczytuje stan konta KONTO1,

operacja - zapisuje nowy stan konta KONTO1,

operacja - odczytuje stan konta KONTO2,

operacja - zapisuje nowy stan konta KONTO2,

oznacza pomyślne zakończenie transakcji(jej zatwierdzenie).

Transakcja może mieć również inną postać, jeśli po którejś operacji system powoduje jej odrzucenia z powodu na przykład przerwania łączności z bazą danych, rozwiązywania problemu zakleszczenia, naruszenia warunku spójności (mówiącego na przykład, że stan konta nie może być niższy niż określona kwota), braku wystarczających uprawnień, itp. Wówczas transakcja może wyglądać następująco:

192

= ,

= ,

= ,

= .

W stosowanym zapisie transakcji abstrahujemy zarówno od konkretnych wartości, jak i od operacji wykonywanych poza bazą danych (operacji w pamięci operacyjnej, obszarze roboczym, interakcja z użytkownikiem lub z innymi systemami).Transakcje i protokoły zarządzania transakcjami muszą spełniać postulat ASOT (atomowość, spójność, odizolowanie, trwałość). Angielski termin ACID (atomocity, consistency, isolation, durability). Postulat ten rozumiany jest następująco:1. Atomowość – każda transakcja stanowi pojedynczą i niepodzielną jednostkę

przetwarzania (a także odtwarzania) – w transakcji nie ma więc podtransakcji. Każda transakcja jest bądź wykonana w całości, bądź też żaden jej efekt nie jest widoczny w bazie danych - „Wszystko lub niczego”.

2. Spójność – transakcja rozpoczynając się w spójnym stanie bazy danych pozostawia bazę danych w stanie spójnym (tym samym lub innym). Jeśli transakcja narusza warunki spójności bazy danych, to SZBD powoduje jej odrzucenie.

3. Odizolowanie – zmiany wykonywane przez transakcję nie zatwierdzoną nie są widziane przez inne transakcje (chyba, że przyjęty poziom izolacji na to zezwala).

4. Trwałość – zmiany w bazie danych dokonane przez transakcję zatwierdzoną są trwałe w bazie danych, tzn. nawet w przypadku awarii systemu musi istnieć możliwość ich odtworzenia.Przykład 2. Rozważmy transakcje z przykładu 1. Atomowość oznacza, że transakcję

= ,

musimy traktować jako niepodzielną całość. Nie można więc przyjąć, że na przykład system utrwala wykonanie w bazie danych dwóch pierwszych operacji zakładając, że po jakimś czasie zrealizuje dwie następne operacje. Bałaby to koncepcja wyróżniania podtransakcji, co w tradycyjnych systemach baz danych jest niedopuszczalne. Jeśli więc z jakiegoś powodu wykonanie transakcji ulegnie przerwaniu ( na przykład w wyniku awarii) po dwóch pierwszych operacjach, to system musi zapewnić wycofanie dokonanych zmian. Spójność oznacza, że system nie dopuści do zatwierdzenia transakcji, która naruszy jakikolwiek warunek spójności bazy danych. W rozważanym

193

przypadku warunkiem spójności może być wymaganie, aby stan rachunku bankowego był zawsze większy od zera (statyczny warunek spójności) lub suma stanów kont po wykonaniu transakcji była taka sama jak przed jej wykonaniem (dynamiczny warunek spójności).Odizolowanie oznacza, że zmiany wykonane przez jedną transakcję nie są widoczne dla innych transakcji dopóty, dopóki transakcja ta nie zostanie zatwierdzona. Rozważmy jednak następujący ciąg operacji:

gdzie jest transakcja programu przelew(), a transakcja programu info(). Transakcja odczytuje stan konta KONTO2, zanim jeszcze transakcjazmieniająca ten stan konta została zatwierdzona. Naruszony jest więc rygorystyczny warunek odizolowania. Trwałość oznacza, że zmiany wprowadzone do bazy danych przez transakcję, która została zatwierdzona są w tej bazie danych trwałe, a więc również w przypadku różnorodnych awarii (z wyłączeniem fizycznego zniszczenia nośnika danych) musi istnieć mechanizm ich odzyskiwania.Z punktu widzenia stosowanych protokołów (algorytmów) zarządzania transakcjami istotne jest przyjęcie pojęcia konfliktowości operacji, tzn. przyjęcie, jakie operacje są konfliktowe, a jakie nie. Z góry można określić, jakie operacje nigdy nie będą konfliktowe, a mianowicie operacje i

nie są konfliktowe, jeśli:a) , tj. Gdy pochodzą z tej samej transakcji,b) , tj. Gdy dotyczą różnych danych (lub rozłącznych zbiorów danych),c) gdy żadna z nich nie jest operacją zapisu,d) co najmniej jedna z nich pochodzi od transakcji, która w chwili wydania drugiej

została już zakończona (zatwierdzona lub odrzucona).

W pozostałych przypadkach możemy mieć do czynienia, ale nie musimy, z konfliktowością. Z warunkiem koniecznym, ale nie dostatecznym, operacji

i są w konflikcie wtedy, gdy:a) – operacje pochodzą z dwóch różnych transakcji,b) co najmniej jedna z tych operacji jest operacją zapisu,c) – operacje dotyczą tej samej danej (przecinających się zbiorów danych),d) obydwie transakcje, z których pochodzą rozważane operacje są aktywne,

e) druga z operacji ( ) powoduje zmianę zbioru danych (wyznaczonego

przez pewną formułę ) na których działa pierwsza operacja ( ).

194

Definiowanie konfliktowości zależy ponadto od intencji użytkownika dotyczącej poziomu wzajemnego odizolowania transakcji od siebie. Użytkownik ma więc w istocie wpływ na interpretację cechy odizolowania. Standardem ISO wyróżniają się cztery poziomy izolacji, a tym samym cztery poziomy konfliktowości operacji: 0,1,2,3.Im wyższy poziom izolacji transakcji (konfliktowości) tym niższa współbieżność, a więc dłuższy czas wykonywania transakcji, ale jednocześnie większa niezawodność przetwarzania i jego bezpieczeństwo z punktu widzenia zachowania spójności bazy danych.Mówiąc o współbieżnym wykonywaniu operacji mamy na myśli wykonywanie operacji pochodzących z różnych transakcji i to w czasie, gdy obydwie te transakcje są aktywne. Transakcje, których operacje wykonywane są współbieżnie, nazywamy transakcjami współbieżnymi.

Anomalne historii przetwarzania transakcjiZ punktu widzenia analizy poprawności protokołów (algorytmów) zarządzania transakcjami istotnie jest analizowanie historii przetwarzania transakcji. Historia taka znana jest po wykonaniu wyznaczonego zbioru transakcji.Definicja 1. Niech będzie zbiorem transakcji. Ciąg

operacji pochodzących z transakcji należących do zbioru nazywamy historią przetwarzania transakcji za zbioru . Jeśli operacja

poprzedza operację w historii H, to stosować będziemy zapis .

Definicja 2. Mówimy, że transakcja czyta z transakcji daną , jeśli

jest ostatnią transakcją aktywną, która zapisała . Mówimy, że

transakcja zapisuje w transakcji daną , jeśli odczytała i

pozostaje transakcją aktywną w momencie zapisu przez .1. Nieodtwarzalne historie przetwarzania. Przypuśćmy, że transakcja zmieniła wartość danej , a następnie

transakcja wczytała i na podstawie jej wartości zmieniła wartość

danej w bazie danych. Przypuśćmy dalej, że transakcja została

195

zatwierdzona , a po tym zdarzeniu powstała konieczność odrzucenia transakcji . Należałoby więc wycofać wszystkie zmiany, jakie

wprowadziła w bazie danych transakcja , a także wszystkie

konsekwencje tych zmian – w szczególności więc zmianę wartości danej .

Ta ostatnia operacja jest jednak niemożliwa, gdyż transakcja , która tę zmianę wykonała jest już zatwierdzona. Zaistniała więc sytuacja, w której baza danych jest nieodtwarzalna. Przykład 3.Rozważmy historię przetwarzania

azwcywxrxwH 1122211 ][][][][:.

opisuje przetwarzanie nieodtwarzalne. Transakcja czyta z transakcji

, , i jest zatwierdzana przed odrzuceniem ,

. Operacja może oznaczać zapis wartości danej

wyznaczonej na podstawie wartości danej . Zmiany tej jednak nie można

wycofać podczas wycofywania konsekwencji transakcji , gdyś transakcja

została wcześniej zatwierdzona.Powodem opisanej anomalii jest to, że transakcja czytająca dane z innej transakcji została zatwierdzona w czasie aktywności transakcji, z której czytała. Aby sytuacji takiej uniknąć, należałoby czekać z zatwierdzeniem transakcji do czasu, aż zostanie zatwierdzona transakcja T 1 .

Przyjmujemy więc, że historia opisuje przetwarzanie odtwarzalne, jeśli każda transakcja jest zatwierdzana po zatwierdzeniu wszystkich transakcji, z których czyta. To znaczy, że musi być później (lub ).2. Historie przetwarzania z kaskadą odrzuceń.Przestrzeganie zasady odtwarzalności nie jest wystarczające. Mimo jej przestrzegania może dojść do sytuacji, gdy odrzucenie jednej transakcji pociągnie za sobą konieczność odrzucenia zależnej od niej (w jakimś sensie) innej transakcji, odrzucenie tej drugiej może spowodować konieczność odrzucenia trzeciej itd., co może prowadzić do kaskady odrzuceń.

196

Niech na przykład transakcja wczyta dane zmienione przez nie

zatwierdzoną jeszcze transakcję . Przypuśćmy, że transakcja zostaje po tym zdarzeniu odrzucona. Konsekwencją tego jest także konieczność odrzucenia transakcji . Ale już wpisała dani do innych pół tabel bazy

danych ( ][2

uw ). Może to spowodować konieczność kaskadowego odrzucania wielu transakcji. Przykład 4.Rozważmy następującą historie powstałą z historii :

azwuwxrxwH 112212 ][][][][:.

opisuje przetwarzanie odtwarzalne. Jednak wykonanie operacji a1 powoduje odrzucenie (wycofanie) transakcji i w konsekwencji kaskadowe

odrzucenie transakcji .Sytuacji tej można uniknąć, jeśli czytanie danych zmienionych przez transakcje jest dopuszczalne dopiero wtedy, gdy transakcje te zostały już zatwierdzone. Historia opisuje przetwarzanie bez kaskady odrzuceń, jeśli transakcji czyta dane zapisane przez transakcje już zatwierdzone.To znaczy, że ][2 xr musi być później (lub ).3. Historie przetwarzania z anomalią powtórnego czytania.Przypuśćmy, że transakcja czyta daną , a następnie transakcja

zapisuje nową wartość danej i jest zatwierdzana ( transakcja zapisuje

w transakcji ). Jeśli teraz transakcja ponownie przeczyta daną , to

może się okazać, że dana ta ma inną wartość. Transakcja dysponuje więc dwiema różnymi wartościami tej samej danej. Może zdarzyć się też sytuacja, że transakcja usunie daną . Wówczas przy próbie

ponownego czytania, transakcja ma informację, że danej nie ma w bazie danych. Opisana anomalię nazywa się anomalią powtórnego czytania.Przykład 5.Rozważmy historię przetwarzania transakcji:

197

cyrczwywyrxwH 22111213 ][][][][][:

W występuje anomalia powtórnego czytania, gdyś między dwoma

wystąpieniami operacji czytania, , wystąpiła operacja zapisu

, czyli

][][][ 212 yrywyr .Historie nazywa się historią bez anomalii powtórnego czytania, jeśli transakcja nie może zapisywać danych czytanych przez transakcje jeszcze nie zatwierdzone.4. Historie przetwarzania z fantomami.Przypuśćmy, że transakcja wczytała z tabeli zbiór rekordów

spełniających warunek . Następne inna transakcja, , dołączyła do

nowy rekord spełniający warunek i została zatwierdzona. Jeśli

ponownie odwoła się do rekordów tabeli spełniających warunek , to okaże się, że tym razem zbiór ten jest inny. Podobna sytuacja wystąpi, jeśli transakcja dokona takiej modyfikacji rekordu nie spełniającego

warunku , że po jej wykonaniu rekord warunek ten będzie spełniał.

Ten nowy rekord pojawiający się w obszarze zainteresowań transakcji nazywany jest fantomem lub zjawą. Przykład 6.Rozważmy historię przetwarzania

curczwurH 221124 ][][][:.

W historii może wystąpić zjawisko fantomów. Jeśli bowiem operacja

wczytuje zbiór rekordów spełniających warunek , operacja

spowoduje, że zbiór takich rekordów ulegnie zmianie (na przykład

tak zostaną zmienione pola rekordu , że po zmianie rekord będzie

198

spełniał warunek ), to powtórne wykonywanie operacji zwróci inny zbiór rekordów.Problem fantomów jest nieco podobny do anomalii powtórnego czytania. Jednak tym razem brak jest bezpośredniego konfliktu między wykonywanymi operacjami. Konflikt ten zauważalny jest dopiero wtedy, gdy uwzględnione są warunki, jakie spełniają zbiory danych, na których wykonywane są operacje.

Przetwarzanie transakcji na różnych poziomach izolacjiPrzyjęcie konkretnego poziomu izolacji wiąże się z określonymi problemami – zbyt niski poziom zapewni zwiększenie współczynnika współbieżności, ale może doprowadzić do niekorzystnych cech związanych z zachowaniem spójności bazy danych. Poziom zbyt wysoki może powodować nieuzasadnione opóźnianie transakcji. Czytanie danych z transakcji nie zatwierdzonych (poziom izolacji 0)Czytanie danych z transakcji nie zatwierdzonych możliwe jest przy przyjęciu poziomu izolacji 0, tzn., gdy za konfliktowe uważa się tylko parę operacji zapisu, a dwie operacji, z których jedna jest operacja odczytu, nie są operacjami konfliktowymi. W standardzie SQL ten poziom izolacji nazywany jest także READ UNCOMMITED (popularne określany jako „brudne czytanie”). Można, więc czytać dane zmieniane przez transakcję, która nie została zatwierdzona. Reguły współbieżności dla tego poziomu izolacji przedstawiono w tablice 1, gdzie operacje w lewej kolumnie traktowane są jako wcześniejsze od operacji w górnym wierszu, T oznacza, że operacje mogą być wykonywane współbieżnie, czyli nie są konfliktowe, N oznacza brak współbieżności, a więc konfliktowość.Tablica 1. Reguły współbieżności dla poziomu izolacji 0 – READ UNCOMMITED

Read WriteRead T TWrite T N

Przyjęcie tego rodzaju współbieżności operacji może doprowadzić do braku odtwarzalności, kaskady odrzuceń, anomalii powtórnego czytania oraz do pojawiania fantomów. Zaletą jest jednak to, że uzyskujemy wysoki współczynnik współbieżności transakcji.Zakaz czytania danych z transakcji nie zatwierdzonych (poziom izolacji 1).Zakaz czytania danych z transakcji nie zatwierdzonych wprowadza poziom izolacji 1. Poziom ten w standardzie SQL określany jest także jako READ COMMITTED. Przy tym poziomie izolacji dopuszczalne jest jednak zapisywanie danych w transakcjach nie zatwierdzonych. Za konfliktowe

199

uważa się wówczas takie pary operacji, gdzie pierwsza jest operacją zapisu, a druga czytania lub obydwie są operacjami zapisu. Dwie operacje, z których pierwsza jest operacją czytania, a druga operacją zapisu nie są, więc konfliktowe. Można, zatem zapisywać dane, które zostały przeczytane przez transakcję jeszcze nie zatwierdzoną. Tablica 2. Reguły współbieżności dla poziomu izolacji 1 – READ COMMITED

Read WriteRead T TWrite N N

Przyjęcie tego rodzaju współbieżności eliminuje anomalie związane z brakiem odtwarzalności i z kaskadą odrzuceń. Nie chroni jednak przed anomalią związaną z powtórnym czytaniem ani przed pojawianiem się fantomów. Zakaz czytania i zapisywania danych w transakcjach nie zatwierdzonych (poziom izolacji 2).Zakaz czytania w transakcjach nie zatwierdzonych i zakaz zapisywania w nich związany jest z przyjęciem konfliktowości na poziomie 2, gdy za konfliktowe uważa się takie pary operacji, gdzie, co najmniej jedna jest operacją zapisu. W standardzie SQL określa się go także jako REPEATABLE READ. Za niekonfliktowe uważa się tylko operacje czytania. Jeśli więc transakcja nie zatwierdzona przeczytała jakąś daną, to dana ta może być tylko czytana przez inną transakcję. Jeśli natomiast transakcja nie zatwierdzona zapisała jakąś daną, to nie można jej ani odczytać, ani tym bardziej zapisać dopóty, dopóki transakcja ta nie zostanie zatwierdzona. Reguły współbieżności operacji mają wówczas postać przedstawioną w tablicy 3.Tablica 3. Reguły współbieżności dla poziomu izolacji 2 – REPEATABLE READ

Read WriteRead T NWrite N N

Przyjęcie tego rodzaju współbieżności eliminuje anomalie powtórnego czytania. Nie eliminuje natomiast problemu fantomów.Historie szeregowalne (poziom izolacji 3)Rozwiązanie problemu fantomów wymaga poszerzenia rozważanych dotychczas pojęć współbieżności i konfliktowości w kierunku

200

uwzględnienia formuł (predykatów) definiujących zbiory danych, na których działają rozważane transakcje.Niech dane będą operacje ][o i ][p pochodzące z dwóch różnych i

aktywnych transakcji ( i są formułami określającymi zbiory danych,

na których działają operacje) oraz niech ][p . Przyjmijmy oznaczenia:

a) })(|{ xxX - zbiór danych spełniających warunek bezpośrednio

przed wykonaniem operacji ,

b) - zbiór danych spełniających warunek bezpośrednio przed

wykonaniem operacji ,

c) - zbiór danych spełniających warunek bezpośrednio po

wykonaniu operacji ][p.

Pojęcie współbieżności operacji rozszerzamy obecnie następująco:1. Dwie operacji i są zawsze współbieżne.

2. Dwie operacje i są współbieżne, jeśli zbiór, na którym

działa druga z tych operacji, jest rozłączny ze zbiorem związanym z wykonaniem pierwszej z nich oraz wykonanie drugiej operacji nie zmieni zbioru związanego z wykonaniem pierwszej. Formalnie :

oraz .

3. Operacje oraz są współbieżne, jeśli zbiór, na

którym działa druga z tych operacji, jest rozłączony ze zbiorem związanym z wykonaniem pierwszej z nich. Formalnie:

.Reguły współbieżności przedstawiono w tablicy 4.Tablica 4. Reguły współbieżności dla poziomu izolacji 3 - SERIALIZABLE

Read[ ]

Write [ ]

201

Read[ ] T T T N

Write [ ] T N T N

Przyjęcie tego rodzaju współbieżności eliminuje wszystkie problemy w tym również problem fantomów. Ten poziom izolacji określa się w standardzie SQL jako SERIALIZABLE. Według standardu jest to domyślny poziom izolacji.

202

Szeregowalność transakcji Celem zarządzania transakcjami jest uzyskanie poprawnych historii przetwarzania. Pojęcie poprawności rozpatrywane jest na przyjętym poziomie izolacji. Definicja 3. Niech będzie zbiorem transakcji, a

niech będzie historią przetwarzania transakcji ze zbioru . Historię H nazywamy

sekwencyjnej, jeżeli dla każdych dwóch transakcji, wszystkie operacje jednej z nich poprzedzają wszystkie operacje drugiej. W przeciwnym wypadku historia jest współbieżna. Definicja 4. Niech będzie zbiorem transakcji, a

niech będzie historią przetwarzania transakcji ze zbioru .Grafem szeregowalności historii H nazywamy graf G(H)= (V,E), gdzie:

V – zbiór wierzchołków równy zbiorowi , - zbiór krawędzi, przy czym krawędź wtedy i tylko

wtedy, gdy istnieją konfliktowe operacje i pochodzące z transakcji

odpowiednio i takie, że .Wierzchołkami w grafie szeregowalności są więc transakcje ze zbioru , a krawędź oznacza, że istnieją konfliktowe operacje i

pochodzące z transakcji odpowiednio i , gdzie poprzedza . Jeśli kolejność operacji konfliktowych w H jest taka, że określana przez nią relacja nie jest relacją częściowego porządku , to taka historia nie jest poprawna oraz graf szeregowalności jest acyklicznym (niepoprawnym).Szeregowalność jest poprawna, kiedy rezultat operacji je historii jest taki samy jako rezultat operacji historii sekwencyjną, a graf szeregowalności jest grafem acyklicznym.Zgodnie z powyższą definicją, sekwencję operacji jest wyznaczona na podstawie kolejności konfliktowych operacji występujących w historii przetwarzania H. Do badania poprawności historii przetwarzania wykorzystuje się analizę grafów szeregowalności.

203

Tablica 5. Przykład grafu, który nie jest Szeregowanym

Transakcja realizuje operacje przelewu kont. Transakcja realizuje operacje

kapitalizacji kont. Dla początkowego stanu kont =100, =400 przy poprawnej

szeregowalności : a) =220; =330, jeżeli ( -> ) lub b) =210; =

340, jeżeli ( -> ).

Transakcja Transakcja

begin transaction Read (x) x := x+100 Write (x) X=200 begin transaction

Read (x) x := x * 1.1 Write (x) X=220(!) Read (y) y := y * 1.1 Write (y) Y=440

Read (y) commit y := y - 100 Write (y) Y=340(!)commit

Graf szeregowalności transakcji tabl.5.

204

Tablica 6. Przykład grafu, który jest Szeregowanym




340, jeżeli ( -> ).


begin transaction Read (x) x := x+100 Write (x) X=200 begin transaction

Read (x) x := x * 1.1 Write (x) X=220

Read (y)y := y - 100Write (y) Y=300commit Read (y)

y := y * 1.1 Write (y) Y=330 commit

Graf szeregowalności transakcji tabl.6.

205

Łatwo wykazać (Bernstein, 1987), że jeśli graf szeregowalności jest acykliczny, to odpowiadająca mu historia przetwarzania jest poprawna – zorientowany graf acykliczny jest bowiem graficzną formą reprezentacji zbioru częściowo uporządkowanego. Jeśli natomiast w grafie szeregowalności istnieje jakikolwiek cykl, to odpowiadająca mu historia przetwarzania jest na pewno niepoprawna. Szeregowalność oznacza, że zbiór operacji występujących w historii H możemy ułożyć w ciąg, w którym operacje poszczególnych transakcji nie przeplatają się, ale jednocześnie zachowana jest kolejność wszystkich operacji konfliktowych. Taka historia przetwarzania odpowiada szeregowemu wykonywaniu transakcji, stąd historie generujące częściowy porządek w zbiorze transakcji nazywamy historiami szeregowalnymi. Zauważmy, że w przypadku wystąpienia pętli lub cyklu w grafie szeregowalności odpowiadającym historii H nie dałoby się przekształcić H w historie przetwarzania szeregowego.

Zarządzanie transakcjami w języku SQLTransakcji mają właściwość ASOT. Transakcja rozpoczyna się w chwili wydania polecenia inicjującego transakcję (begin transaction...). Charakterystyki transakcji określa się za pomocą komend SET TRANSACTION i SET CONSTRAINTS o składni:SET TRANSACTION lista-opcji

opcje:

tryb dostępu: READ ONLY, READ WRITErozmiar obszaru diagnostyk: DIAGNOSTICS SIZE nPoziom izolacji: ISOLATION LEVEL izolacja

izolacja: SERIALIZABLE (domyślna)REPEATABLE READ,READ COMMITED,READ UNCOMMITED.

SET CONSTRAINTS { lista-warunków/ ALL}

{ DEFERRED / IMMEDIATE }SET CONSTRAINTS ustała tryb sprawdzania warunków spójności na natychmiastowy (IMMEDIATE) lub opóźniony (DEFERRED).Przyjęcie określonego poziomu izolacji może być źródłem problemów omówionych wcześniej. W tablice 7 jest pokazany związek poziomów izolacji z problemami przetwarzania transakcji.Tablica 7. Poziom izolacji Brak

odtwarzalnościAnomalia powtórnego

Fantomy

206

czytania0: READ UNCOMMITED T T T1: READ COMMITED N T T2: REPEATABLE READ N N T3: SERIALIZABLE N N N

Przykłady przetwarzania bazy danych na różnych poziomach izolacji.Przypuśćmy, że w bazie danych istnieje tabela Towar o postaci przedstawionej w tablicy 8.Tablica 8. Przykładowa tabela bazy danych „Towar”.

Nazwa Cena Stan200MMX 320 20233MMX 370 50

Poziom izolacji 0. Przy poziomie izolacji 0 możliwe jest czytanie danych zmienionych przez transakcje jeszcze nie zatwierdzone. Mówi się wówczas o „brudnym czytaniu”. Dopuszczenie takiego czytania bardzo zwiększa współbieżność przetwarzania, ale jednocześnie może doprowadzić do udostępniania nieprawdziwych danych z bazy danych, co ilustruje przykład w tablicy 9.Tablica 9. Historia przetwarzania transakcji na poziomie izolacji 0 zapis-odczytTransakcja T1 Transakcja T2set transaction isolation level 0 set transaction isolation level 0begin transaction update Towar set Cena = 300Where Nazwa = ‘200MMX’T1 zmienia cenę

begin transaction select Cena from Towarwhere nazwa = ‘200MMX’T2 czyta zmienioną cenę

RollbackT1 wycofuje zmianę

T2 posiada niepoprawną informację o cenieZerowy poziom izolacji może być stosowany tylko w takich transakcjach, o których wiemy, że nawet w przypadku błędnych danych nie spowodują poważnych negatywnych konsekwencji. Można go stosować na przykład dla transakcji, których zadaniem jest tylko udzielanie informacji z bazy danych.Poziom izolacji 1. Cechą charakterystyczną tego poziomu izolacji jest to, że możliwe jest aktualizowanie przez transakcję T2 danych wczytanych przez nie

207

zakończoną jeszcze transakcję T1. Po powtórnym odwołaniu się do tych samych danych transakcji T1 można uzyskać sprzeczne informacje.

Tablica 10. Historia przetwarzania transakcji na poziomie izolacji 1: odczyt-zapisTransakcja T1 Transakcja T2set transaction isolation level 1 set transaction isolation level 1begin transactionselect Cena, Stan from Towarwhere Nazwa = ‘200MMX’T1 czyta cenę i stan towaru

begin transactionupdate Towar set Cena = 310where Nazwa = ‘200MMX’T2 zmienia cenę wczytaną przez T1

select sum(Cena*Stan) from Towarwhere Nazwa = ‘200MMX’T1 czeka na zakończenie T2

CommitWykonanie oczekującej operacji ‘select’ dla T1. Wynik jest sprzeczny z poprzednią operacją ‘select’

Poziom izolacji 2.W poziomie izolacji 2 mamy zagwarantowanie, że przy ponownym odwołaniu się do tych samych danych dostajemy identyczne informacje.Tablica 11. Historia przetwarzania transakcji na poziomie izolacji 2: odczyt-zapis-odczytTransakcja T1 Transakcja T2set transaction isolation level 2 set transaction isolation level 2begin transactionselect Cena, Stan from Towarwhere Nazwa = ‘200MMX’T1 czyta cenę i stan towaru

begin transactionupdate Towar set Cena = 310where Nazwa = ‘200MMX’T2 czeka na zakończenie T1

select sum (Cena*Stan) from Towarwhere Nazwa = ‘200MMX’T1 oblicza wartość towaruCommit

Wykonanie oczekującej operacji ‘update’

208

dla T2. Poziom izolacji 2 zabezpiecza przed modyfikacją wczytanych danych, ale nie przed dołączeniem nowych wierszy. Sytuację te ilustruje historia przetwarzania podana w tablicy 12.Tablica 12. Historia przetwarzania na poziomie izolacji 2: odczyt-dołączenie-odczytTransakcja T1 Transakcja T2set transaction isolation level 2 set transaction isolation level 2begin transactionselect Cena, Stan from Towarwhere Nazwa = ‘200MMX’T1 czyta cenę i stan towaru

begin transactioninsert into Towarvalues (‘200MMX’, 250,10)T2 dołącza nowy wiersz „fantom”Commit

Select sum (Cena*Stan) from Towarwhere Nazwa =’200MMX’T1 oblicza wartość towaru. Wynik jest sprzeczny z poprzednią operacją select

Poziom izolacji 3.Przed pojawieniem się fantomów chroni poziom izolacji 3. Przy tym poziomie izolacji przetwarzanie z tablicy 12 miałoby historię podaną w tablicy 13.Tablica 13. Historia przetwarzania transakcji na poziomie izolacji 3: odczyt-dołączenie-odczytTransakcja T1 Transakcja T2set transaction isolation level 3 set transaction isolation level 3begin transactionselect Cena, Stan from Towarwhere Nazwa = ‘200MMX’T1 czyta cenę i stan towaru

begin transactioninsert into Towarvalues (‘200MMX’, 250, 10)T2 czeka na zakończenie T1

Select sum (Cena*Stan) from Towarwhere Nazwa =’200MMX’T1 oblicza wartość towaru.Commit

Wykonanie „insert” przez T2

209

Metody sterowania współbieżnością transakcji na różnych poziomach izolacji. Sterowanie współbieżnością transakcji realizuje się przez przetwarzanie historii niepoprawnych do historii szeregowalnych. Szeregowalność może być realizowana za dopomogą blokowania danych oraz metody znaczników czasowych.

Metody blokowania danych.Blokowanie to jest protokół, który jest wykorzystywany dla równoległego dostępu do danych przez różnych transakcji. Z każdą daną X jest związana blokada (lock). Kiedy niektóra transakcja otrzyma dostęp do danych, mechanizm blokowania nie dopuści się dostęp do tych samych danych od innych transakcji. Wyróżniają się dwa podstawowe typy blokad: blokadę współdzieloną (shared lock), blokadę wyłączną ( exclusive lock).Operacje na danej nie powodujące jej uaktualnienia powinny być poprzedzone założeniem blokady współdzielonej. Operacje uaktua¼niające daną po¼inny być poprzedzonej założeniem na niej blokady wyłącznej. Ze względu na proces blokowania, dane w bazie danych mogą występować w jednym z trzech stanów: dana nie zablokowana - 0 dana zablokowana dla odczytu - Read (współdzieloną - shared lock) dana zablokowana dla zapisu - Write (wyłączną - exclusive lock).Blokada może być ustalona dla różnych poziomów detalizacji danych: wartość kolumny tabeli wiersz tabeli tabela, widok baza danych.Realne blokada realizuje się za dopomogą oddzielnych bitów w polu danych. Wartość tych bitów odpowiada typu blokady. Mechanizm blokowania zawiera zasoby sterowania kolejkami dla blokowania danych.Główne reguły protokołu blokowania danych: Transakcja która ustaliła się blokadę danej „dla odczytu” (Read) może tylko czytać

oraz nie może tę daną uaktualnić. Transakcja która ustaliła się blokadę danej „dla zapisu” (Write) może czytać oraz

uaktualnić tę daną. Transakcja realizuje się zgodnie z protokółem blokowania dwóch fazowego(two-

phase locking): wszystkie operacje blokowania poprzedzają pierwszą operację odblokowania.

Operacja czytania transakcji nie jest operacją konfliktową,

dlatego blokada „dla odczytu” (Read) jednej danej może być ustalona jednoczesne przez wielu transakcji. Natomiast blokada „dla zapisu” (Write)

210

operacji transakcji blokuje dostęp do danej przez inne transakcji. Protokół blokowania danych przez transakcji zawiera następne kroki:

Jakakolwiek transakcja , która potrzebuje dostęp do obiektu , musi z początku

ustalić blokadę tego obiektu . Blokada może bycz ustalona „dla odczytu” (Read) lub „dla zapisu” (Write). W ostatnim przypadku dostęp do czytania oraz do zapisu

obiektu będzie miała tylko transakcja, która ustaliła blokadę Write.

Blokada będzie ustalona skuteczne, kiedy obiekt nie ma żądnej blokady.

W tych przypadkach, kiedy obiekt jest już zablokowany przez inne transakcję,

menedżer SŻBD musi analizować czy jest typ blokady nowej kompatybilnym z

typem blokady ustalonej wcześniej. Kiedy transakcja potrzebuje dla obiektu

typ blokady Read oraz ten obiekt jest już wcześniej zablokowany blokadą Read przez

inną transakcją , to transakcja będzie miała dostęp dla odczytu obiektu

równolegle z transakcją . W innych przypadkach transakcja będzie w stanu

oczekiwania (Wait) dopóki, dopóty jest aktualna blokada obiektu przez

transakcją .

Transakcja utrzyma blokadę obiektu dopóki, dopóty przez sposób jawny nie

odblokuje go. Odblokowanie może być spowodowane w razie skutecznego zatwierdzenia transakcji (Commit) lub w razie je wycofania (Rollback). Po

odblokowaniu obiektu od transakcji inne transakcji mogą „widzieć” obiekt

.

Transakcja może rozszerzyć swoje blokadę „dla odczytu” (Read) obiektu do

poziomu blokady „dla zapisy” (Write), kiedy inne transakcje nie mają blokad tego obiektu.

Algorytm blokowania dwufazowegoNajszerzej stosowanym w praktyce jest algorytm blokowania dwufazowego (two-phase locking) oznaczony przez 2PL. Istotą tego algorytmu są następne założenia:

211

Każda transakcja zawiera dwie fazy: fazę blokowania (ekspansji) oraz fazę odblokowania (zwijania).

W fasie blokowania transakcja musi uzyskać blokady wszystkich danych, do których będzie dokonywać dostępu. Moment założenia wszystkich żądanych blokad, równoznacznych z zakończeniem fazy blokowania, jest nazywany punktem akceptacji (commit point).

W fazie odblokowania (po operacji commit lub rollback), następuje zdejmowanie wszystkich nałożonych blokad. Ponadto w fazie tej nie można zakładać nowych blokad.

Diagram czasowy fazę blokowania (ekspansji) oraz fazę odblokowania (zwijania) jest pokazany na rys. 44.W algorytmie 2PL odczyt danej możliwy natychmiast po nałożeniu blokady tej danej, a więc w fazie blokowania , natomiast zapis jest możliwy dopiero w po osiągnięciu przez transakcję punktu akceptacji, a więc w fazie odblokowania.Operacja zapisu jest wykonywana następująco. Założenie blokady wyłącznej („dla zapisu” (Write) ) jest równoznaczne z wykonaniem zapisu wstępnego w obszarze roboczym związanym z zapisywaną daną. Zapis właściwy jest realizowany dopiero w fazie odblokowania, w momencie zdejmowania blokady tej danej na podstawie zawartości obszaru roboczego.

212

Tablica 14 . Przykład protokołu dwufazowego .


kapitalizacji kont. Dla początkowego stanu kont X 0 =100, Y 0 =400 przy poprawnej

szeregowalności : a) X k =220; Y k =330, jeżeli (T 1 -> ) lub b) =210; =

340, jeżeli ( -> ).

213


begin transaction begin transactionWrite_Lock (x) Write_Lock (x)Wait Read (x)Wait x := x * 1.1 Wait Write (x) X=110Wait Write_Lock (y)Wait Read (y)Wait y := y * 1.1 Wait Write (y) Y=440Wait commit / Unlock(x),Unlock(y) Read (x) x := x+100 Write (x) X=210 (+)Write_Lock (y) Read (y) y := y - 100 Write (y) Y=340 (+)commit/ Unlock(x),Unlock(y)

Tablica 15. Przykład niepoprawnego grafu szeregowalności , realizowanego przez protokół, który nie jest dwufazowym.




340, jeżeli ( -> ).


begin transactionWrite_Lock (x) begin transaction Read (x) Write_Lock (x) x := x+100 Wait Write (x) /Unlock(x) X=200 Wait

Read (x) x := x * 1.1 Write (x), Unlock(x) X=220(!)

Write_Lock (y) Write_Lock (y)Wait Read (y)

214

Wait y := y * 1.1 Wait Write (y) Y=440 Wait commit / Unlock(y) Read (y) y := y - 100 Write (y) Y=340(!)commit/ Unlock(y)

Zakleszczenia transakcji.Zakleszczenie (deadlock) to jest sytuacja przy dwóch fazowym blokowaniu transakcji, powstająca wtedy, gdy transakcja blokuje daną i żąda

dostępu do danej , podczas gdy transakcja blokuje daną i żąda

dostępu do danej ; żadna z tych transakcji nie może kontynuować swojego przebiegu. Możliwe są zakleszczenia, w których uczestniczy wiele transakcji.

Tablica 16. Przykład zakleszczenia transakcji


begin transaction begin transactionWrite_Lock (y) Write_Lock (x) Read (y) Read (x) y := y - 100 x := x * 1.1 Write (y) Write (x)Write_Lock (x) Write_Lock (y)Wait... Wait...

Jedynym sposobem walki z zakleszczeniem transakcji jest wycofanie jednej z zakleszczonych transakcji. Główne strategii walki z zakleszczeniem transakcji: Wykrywanie zakleszczeń Zapobieganie zakleszczeń.

Wykrywanie zakleszczeń.

Wykrywanie zakleszczeń może być realizowane przez graf oczekiwania transakcji (wait-for-graf). Ten graf odwzorowuje zależność jednej transakcji od drugiej. Przykład grafu

215

jest pokazany na fig 45. Każdy wierzchołek odpowiada transakcji. Krawędź ->

oznacza, że transakcja czeka na odblokowanie danej X przez transakcje .

Pętla w grafu oczekiwań jest warunkiem koniecznym oraz dostatecznym istnienia zakleszczeń transakcji. Algorytm wykrywania zakleszczeń zawiera następnie kroki:1. Wyznaczenia początkowej wartości interwału T pomiędzy dwoma kolejnymi

generacjami grafu oczekiwań transakcji. Przy małym T, częste wykrywanie zakleszczeń powoduje obciążenie procesora oraz małą wydajność SZBD. Przy dużym T transakcje, które są zakleszczone, mogą być nie wyznaczone w ciągu interwału T .

2. Generacja grafu zakleszczeń po zakończeniu interwału T . 3. Analiza grafu zakleszczeń:

If zakleszczenia istnieją Then wycofanie transakcji, która jest w pętle grafu oczekiwań;

T:=T/2;

GOTO 2;Else

216

T:=2T;

GOTO 2; EndIf

Metody znaczników czasowych.

Metody znaczników czasowych(Timestamp ordering) są alternatywą do metod szeregowałności historii przetwarzania transakcji przez blokowania danych. Te metody są wykorzystywane w przypadkach, kiedy konflikty pomiędzy transakcjami są rzadkie. Dla usunięcia konfliktów nie jest potrzebny graf oczekiwania transakcji. Definicja. Znacznik czasowy (Timestamp) transakcji T, czyli TS(T), jest jej unikalnym identyfikatorem, który wyznaczy się czas zjawy transakcji T w SZBD. Znaczniki są przydzielone transakcjom w kolejności, w której transakcje pojawiają się w SZBD.Również z transakcjami, w bazie danych z każdą daną (X) są związane następne dwie wartości znaczników czasowych:Read_TS(X) –największy (najstarszy) znacznik czasowy spośród wszystkich transakcji, które pomyślnie odczytały daną X.Wtrite_TS(X) - największy (najstarszy) znacznik czasowy spośród wszystkich transakcji, które pomyślnie zapisały daną X.Implementacja algorytmu znaczników czasowych dla operacji odczytywania danych:Read ( ,X) beginIf (Write_TS (X)==TRUE) Then

< abort and restart it with a new Timestamp>;Else begin< Read X>;Read_TS (X) <-- max (Read_TS(X), TS( ));End;End Read;Dla realizacji operacji odczytywania daną X transakcja czyta typ znacznika czasowego daną X. Kiedy ten typ ma wartość Write_TS(X) ustaloną przez inną transakcję , transakcja będzie wycofana oraz startowana z nowym znacznikiem czasowym. Kiedy typ znacznika czasowego daną X jest Read_TS (X) ustalony przez inną transakcję , ten

217

typ zmieni się na największy znacznik (najstarszy) spośród transakcji

oraz . Implementacja algorytmu znaczników czasowych dla operacji zapisywania danych:

Write( ,X) begin

If (TS ( ) <Read_TS(X) or TS( )<Write_TS(X)) Then

< abort and restart it with a new Timestamp>;Else begin<Write X>Write_TS(X) <--TS( );End;End Write;Dla realizacji operacji zapisywania daną X transakcja czyta z początku typ znacznika czasowego daną X ustalonego wcześniej przed inną transakcją. Kiedy ten znacznik jest

starszy czym znacznik , transakcja będzie wycofana już z nowym znacznikiem

czasowym. Kiedy transakcja jest starsza od etykiety znacznika czasowego daną (X ),

dana (X ) będzie miała nową wartość: Write_TS(X) <--TS( ).

Zaleta metody znaczników czasowych:Wykorzystanie metody nie powoduje zakleszczeń transakcji.Wada metody znaczników czasowych:Dużo często jest wykorzystywane wycofanie transakcji.

Odtwarzanie bazy danychOdtwarzanie bazy danych (Recovery Data Base) to jest proces przywrócenia je do poprawnego stanu zgodnie z postulatem ASOT. Baza danych wykorzystuje się dwa typy pamięci: ulotną trwałą.Wyróżniają się następny typy awarii, które powodują konieczność odtwarzania danych: uszkodzenia pamięci ulotnej; uszkodzenia pamięci trwałej.

Odtwarzanie bazy danych przy uszkodzeniach pamięci ulotnejPamięć ulotna jest pamięć operacyjna, a pamięć trwała jest pamięć dyskowa. Pomiędzy tymi dwoma typami pamięci musi być gwarantowane odwzorowanie. Pamięć ulotna zawiera specjalne bufory I/O mające na celu zmniejszenie liczby kosztownych operacji dostępu do wolnej pamięci dyskowej. Bloki dyskowe najczęściej są sprowadzone do bufora i pamiętane tam jako strony w buforze. Informacje o tym, jakie bloki dyskowe

218

znajdują się w buforze , są przechowywane w tablicy bufora (lookaside table). Te bloki mogą zawierać informacje o danych BD. Kiedy w buforze zabraknie miejsca jakaś strona będzie zrzucona na dysk zgodnie ze strategią LRU, według której na dysk zostaje strona najmniej używana. Wszystkie strony w buforze zawierają rezultaty aktualizacji transakcji współbieżnych w bazie danych oraz zostają w buforze aż: zostaną usunięte w wyniku zastosowania strategii LRU, zostaną zapisane na dysku po zadanym czasie.Mówią, że strona w buforze jest „brudna”, jeżeli zastała uaktualniona przez transakcję od czasu ostatniego zapisu na dysk. Brudne strony mogą pozostawać w buforze jeszcze długo po tym, jak uaktualniające je transakcje zostały zaakceptowane. Przypuścimy, że wystąpił zanik napięcia. Jeżeli aktualizowane strony nie były zapisywane na dysk, to będzie stracona informacja o aktualizacjach. Z kolei zapisywanie strony na dysk zaraz po jej aktualizacji powoduje małą wydajność SZBD. Wydajność SZBD w tym przypadku byłaby wyznaczona wydajnością dysku magnetycznego. Oprócz tego, natychmiastowe zapisywanie danych może doprowadzić do niespójności, jeśli okazałoby się później, że transakcja, która dokonała modyfikacji, nie została zaakceptowana. Transakcja zostanie więc odrzucona, ale zmiany przez nią wprowadzone pozostaną. SZBD musi zapewnić atomowość i trwałość transakcji oraz dostarczyć mechanizm wycofania transakcji (wycofania zmian przez nie zaakceptowaną transakcję). Zasadą odtwarzania bazy danych jest przechowywanie zbytecznych danych, które odwzorowują konsekwentność operacji aktualizacji transakcji. Te dani są w dzienniku transakcji (pliku logu), który zawiera historię przetwarzania wszystkich transakcji od momentu ostatniego zapisywania dziennika na dysk. Istnieją dwa warianty realizacji dziennika transakcji:1. Realizacja oddzielnego logu dla każdej transakcji2. Realizacja ogólnego logu dla wszystkich transakcji.W pierwszym wariancie każda transakcja chroni historię zmian bazy danych przez operacji tej samej transakcji. Lokalne logi mogą być wykorzystywane dla indywidualnych wycofań oddzielnych transakcji. Oprócz logów lokalnych w tym wariancie jest potrzebny log ogólny dla wyznaczenia kolejności oraz parametrów czasowych wszystkich transakcji. Ten wariant pozwoli realizować szybkie wycofanie oddzielnych transakcji, ale potrzebuje jednoczesnego podtrzymywania wielu logów. Wariant drugi realizuje wykorzystywanie tylko jednego logu. Ten dziennik zawiera informacje pro wszystkie transakcje.Przykład fragmentu dziennika jest pokazany w tabl.14.Tabl.14.Num_Rec

Id_tr Time Operacja Object Old_ m New_ m PPtr NPtr

1 T1 10:12 Start 0 22 T1 10:13 Update Staff

SL2120 30 1 8

3 T2 10:14 Start 0 44 T2 10:16 Insert Staff

SG3712 3 5

219

5 T2 10:17 Delete Staff SA9

90 4 6

6 T2 10:17 Update Dzial Dz16

12 13 5 9

7 T3 10:18 Start 0 118 T1 10:18 Commit 2 09 T2 10:19 Commit10 T3 10:20 Insert Dzial

Dz1940 7 11

11 T3 10:21 Commit 10 0 Przeznaczenie atrybutów kolumn tabl. 14 jest następujące: „Num_Rec” - identyfikator rekordu logu; „Id_tr” – identyfikator transakcji; „Time” – znacznik czasowy operacji transakcji; „Operacja” – typ operacji transakcji; „ Object” – identyfikator obiektu danych, który był wykorzystywany przez operację

transakcji; „ Old_ m” – kopia obiektu danych do realizacji operacji transakcji; „New_ m” - kopia obiektu danych po realizacji operacji transakcji; „PPtr” – wskaźnik na poprzedni rekord w logu, który zawiera operację tej samej

transakcji; „NPtr” - wskaźnik na następny rekord w logu, który zawiera operację tej samej

transakcji. Plik logu jest rozmieszczony w buforu pamięci ulotnej. Rekordy buforu logu mogą być wykorzystywane dla wycofania oddzielnych transakcji przez instrukcje ROLLBACK. Natomiast w przypadkach awarii pamięci ulotnej mogą być stracone wszystkie rekordy logu. W celu odtwarzania bazy danych w tych przypadkach, trzeba mieć kopię logu na dysku oraz ta kopia musi być uzgodniona ze stanem bazy danych. Istnieje protokół WAL(Write Ahead Log), który reglamentuje kolejność zapisywania bufora logu na dysk. W skróci go można określić stwierdzeniem: „zanim zapiszesz coś na dysk najpierw zapisz na dysk bufor logu”. Innymi słowy przed zapisywaniem obiektu bazy danych na dysk, najpierw trzeba zapisać log. Sama baza danych może nie zawierać wszystkich zmian, które odwzorowuje log, ale te zmiany można wprowadzić przez uruchomianie wyznaczonych transakcji w logu. Bufor logu jest zapisywany na dysk w dwóch przypadkach: przy akceptacji jakikolwiek transakcji przez operację COMMIT; przy zdarzeniu licznika czasu (timer). W przypadku awarii pamięci ulotnej menedżer odtwarzania bazy danych musi analizować stan transakcji w logu, która zapisywała rekordy do bazy w moment awarii. Jeżeli transakcja wykonała operację akceptacji (commit) , to menedżer odtwarzania bazy danych musi powtórzyć wszystkie je operacje z początku – wykonać operację REDO. REDO polega na wczytaniu do buforu strony z danymi bazy danych, potworzeniu jej aktualizacji i zapisywaniu tej strony na dysk. Nowa wartość zapisywanego rekordu do bazy jest pobierana z rekordu logu.

220

Kiedy ta transakcja nie była zaakceptowana, to menedżer odtwarzania bazy danych musi wycofać wszystkie je rezultaty – od końca do początku – wykonać operację UNDO. UNDO polega na wczytaniu do buforu danej strony z danymi bazy danych, „odkręceniu” jej aktualizacji i zapisywaniu strony na dysk. Poprzednia wartość danych jest pobrana z rekordu logu.Na fig.46 jest pokazany przykład wykorzystywania logu dla odtwarzania bazy danych. Stan bazy danych moment tlpc (time of last physical consistency) jest zapisany na dysku. W moment tf (time failure) wystąpiła awaria. Dla odtwarzania bazy danych trzeba odczytać wszystkie strony pamięci trwałej, które odwzorowują stan bazy danych na moment tlpc, do bufora pamięci operacyjnej oraz odczytać plik logu. W logu są historie transakcji :T1 – T5. Dla odtwarzania bazy danych trzeba realizować następne czynności: Transakcja T1 była zatwierdzona do momentu tlpc, je rezultaty są w pamięci trwałej

bazy danych, dlatego operacji odtwarzania dla tej transakcji nie są potrzebne. Część rezultatów transakcji T2 są w pamięci trwałej. Żeby dostarczać postulat

atomowości (ASOT) trzeba powtórzyć wszystkie operacji T2 z początku (wykonać operację REDO).

Część rezultatów transakcji T3 są w pamięci trwałej, ale ta transakcja nie została zatwierdzona. Dla transakcji T3 trzeba odkręcić je operacji od końca do samego początku (wykonać operację UNDO).

Rezultaty transakcji T4 są nieobecne w pamięci trwałej. Dla transakcji T4 trzeba wykonać operację REDO, bo do momentu awarii została już zatwierdzona.

Dla transakcji T5 nie trzeba żądnych czynności odtwarzania, bo rezultaty tej transakcji są nieobecne w pamięci trwałej.

221

Odtwarzanie bazy danych przy uszkodzeniach pamięci trwałejDla odtwarzania bazy danych przy uszkodzeniach dysków trzeba mieć zarchiwowane kopie bazy danych oraz dziennik transakcji od momentu ostatniej archiwacji. Odtwarzanie poczyna się z kopiowania danych z je kopii. Potem dla wszystkich transakcji, które są zaakceptowane realizuje się operacja REDO.Dla archiwacji bazy danych musi być wyznaczony termin przez administratora bazy danych. Ten termin może być wyznaczony automatyczne po przepełnieniu dziennika transakcji.

222

Pytania kontrolne po kursu „Obiektowe Bazy danych”.

1. Ograniczenia relacyjnych baz danych. Reprezentacja nierelacyjnych baz danych.2. Zasady obiektowości – abstrakcja, hermetyzacja, modularność, hierarchia.

Obiekty. Relacji między obiektami. Klasy. Związki między klasami. 3. Standardy obiektowych baz danych. Standard obiektowych baz danych ODMG

2.0. Język definiowania obiektów ODL.4. Obiektowo relacyjne bazy danych. Język SQL-3. Architektura ORSZBD

PostgreSQL.5. Standardy systemów rozproszonych. Standard OMG CORBA.6. Cele tworzenia UML. Definicja modelu. Ogólne cechy UML. Model pojęczowy

UML.7. Diagramy klas UML. Modelowanie dziedziny problemu. Diagram klas modelu

projektowania. Model MVC (Model View Controller).8. Diagramy przypadków użycia. Scenariusze przypadków użycia. Diagramy

interakcji.9. Diagramy stanów. Diagramy czynności. Diagramy komponentów, wdrożenia.10. Wzorce do wyznaczenia odpowiedzialności obiektów.11. Wzorce architektury aplikacji WWW. Wzorzec architektury Thin Web Client.

Wzorzec architektury Thick Web Client. Rozszerzenie języka UML dla modelowania aplikacji WWW. Modelowanie aplikacji ASP w UML

12. Modelowanie aplikacji JSP w UML.13. Modelowanie komponentów Enterprise JavaBeans (EJB).14. Zarządzanie transakcjami w obiektowo relacyjnych bazach danych. Cechy

transakcji. Anomalne historii przetwarzania transakcji.15. Przetwarzanie transakcji na różnych poziomach izolacji.16. Szeregowalność transakcji. Zarządzanie transakcjami w języku SQL.17. Metody sterowania współbieżnością transakcji. Metody blokowania danych.

Algorytm blokowania dwufazowego. Zakleszczenie transakcji. Metody znaczników czasowych.

18. Odtwarzanie baz danych. Odtwarzanie przy uszkodzeniach pamięci ulotnej. Odtwarzanie przy uszkodzeniach pamięci trwałej.

223

Documents

Obiektowe modelowanie systemów informatycznych