PODSTAWY PROJEKTOWANIA SYSTEMÓW INFORMATYCZNYCH

I.WPROWADZENIE

Do metod analitycznych projek­towania zalicza się te metody, które umożliwiają, zdefiniowanie formalnego (abstrakcyjnego) modelu systemu informatycznego przez zas­tosowanie rozbioru (analizy) tego systemu na części składowe. Najbar­dziej znanymi tego typu metodami są:

• metody projektowania strukturalnego (structured ap­proach);

• metody projektowania obiektowego (object-oriented approach).

Algorytmem nazywa się opis czynności, jakie należy wykonać w stosunku do określonych obiektów, aby osiągnąć pewien założony cel. Program zdefiniuje się jako realizację pewnego algo­rytmu w konkretnym języku programowania, umożliwiającą wykonanie tego algorytmu za pomocą komputera. System oprogramowania jest to zbiór programów współpracujących w celu wykonania ogólnego, złożonego oraz wieloaspektowego zadania i realizujących dobrze zdefiniowane operacje (czynności, obliczenia) odnoszące się do poszczególnych aspektów zadania ogólnego.

Przez system informatyczny należy rozumieć system oprogramowania osadzony na pewnej konfiguracji sprzętowej, której składniki umożliwiaj, ele­mentom oprogramowania tego systemu (efektywną,) realizację poszczególnych zadań oraz wzajemna komunikację i działający w określonym środowisku zgodnie z dobrze określonymi regułami (np. reguły reakcji systemu na polecenia operatora).

Systemami informatycznymi są na przykład: sieci komputerowe (opro­gramowanie wraz z węzłami sieci (komputerami), okablowaniem, modułami umożliwiającymi transmisję danych (most - bridge, ruter - router) itp.), systemy monitorujące/diagnostyczne procesy przemysłowe (oprogramowanie wraz z urządzeniami sensorycznymi, okablowaniem, specjali­zowanymi urządzeniami elektronicznymi wstępnie przetwarzającymi dane, komputerami, terminalami itp.).

Podstawowym powodem problemów występujących w trakcie konstrukcji systemów informatycznych, systemów oprogramowania (a nawet dużych pro­gramów) jest ich złożoność. Po przekroczeniu pewnego progu złożoności pro­jektant (programista) przestaje "panować" nad przygotowywanym produk­tem, ponieważ całościowe zrozumienie funkcjonowania systemu w różnych jego aspektach i na dowolnym poziomie szczegółowości przekracza możliwości człowieka. Rozwiązaniem tego problemu może być strukturalizacja sys­temu według określonych kryteriów. Jest ona główną ideą przedstawionych tu metod, a rodzaj przyjętych kryteriów jest tym, co różni poszczególne metody. Wspólną cechą metod analitycznych projektowania są natomiast mniej więcej te same założenia dotyczące charakteru złożoności systemów informatycznych.

1. Złożony system możemy przedstawić w postaci struktury hierar­chicznej. Oznacza to, że system możemy dekomponować na zbiór podsystemów, z których każdy możemy dekomponować na zbiór pod­systemów itd., aż dojdziemy do najniższego interesującego nas poziomu szczegółowości.

2. Proces dekompozycji przedstawiony w punkcie 1 nie jest (całkowicie) arbitralny. Kryterium określające, na jakie części należy podzielić w danym kroku system (podsystem), jest oparte na obserwacji dynamiki interakcji między składowymi elementarnymi systemu.. Składowe o dużej dynamice wzajemnych interakcji należy grupować w podsystemy. Dynamika interakcji między podsystemami powinna być mała.

3. Systemy informatyczne mają, tendencji do rozrastania się. Zjawisko to może mieć charakter niezamierzony (np. wskutek wzrastających wymagań użytkowników należy ulepszyć obecną wersję całego sys­temu (rozwój jakościowy), czy też dołączyć podsystem dostarczający nową nieprzewidzianą wcześniej funkcję) lub zamierzony (np. w me­todzie prototypowania konstruktor oprogramowania zakłada, że sys­tem będzie ewoluował z prostego systemu o podstawowej funkcjo­nalności w stronę bardziej złożonych form wychodzących naprzeciw życzeniom użytkowników. Zamierzona ewolucja systemu jest typowym założeniem metod obiektowych.

II.POJĘCIE PROJEKTOWANIA SYSTEMÓW INFORMATYCZNYCH

Projektowanie systemów informatycznych można podzielić na pięć zasadniczych faz:

1. Analiza systemu. Na tę fazę składają. się:

1. sformalizowanie zbioru wymagań stawianych przed systemem,

b) zdefiniowanie funkcjonalnego modelu systemu opisującego:

· interakcje systemu ze światem zewnętrznym,

· strukturę systemu,

· przepływ danych i sterowania między elementami systemu,

· abstrakcyjne struktury danych,

· dynamikę (zachowanie się) systemu.

Produktem tej fazy jest tzw. model logiczny systemu.

2. Projektowanie systemu. W tej fazie na podstawie modelu (pro­jektu logicznego) systemu projektuj się fizyczną strukturę systemu, tzn. definiuje się elementy oprogramowania (software) systemu (pro­gramy, procedury, funkcje, bloki itp.) oraz interakcje między nimi (np. wywołania), a także składniki sprzętowe (hardware), a następnie określa sposób przypisania (alokacji) elementów oprogramowania do składników sprzętowych.

3. Implementacja systemu. Faza ta polega na zakodowaniu algorytmów w konkretnym języku programowania i utworzeniu struktury systemu oprogramowania zgodnie ze specyfikacją struktury fizycznej systemu.

4. Instalacja i testowanie systemu oraz usuwanie błędów. W fazie instalacji dokonuje fizycznej alokacji elementów oprogramowania do składników sprzętowych zgodnie z projektem struktury fizycznej systemu. Następnie sprawdza się poprawność działania systemu w środowisku użytkownika i eliminuje błędy.

5. Pielęgnacja i dalszy rozwój systemu. Faza ta rozpoczyna się w chwili przekazania systemu użytkownikowi. Jej podstawowymi celami są: ciągła eliminacja błędów, które ujawniają. się w trakcie korzystania z systemu przez użytkowników, oraz poszerzanie możliwości i polep­szanie parametrów systemu zgodnie z sugestiami użytkowników.

III. CHARAKTERYSTYKA METOD ANALITYCZNYCH PROJEKTOWANIA SYSTEMÓW INFORMATYCZNYCH

Wprowadzenie metod analitycznych było odpowiedzią na problem złożoności systemów informatycznych. Jakkolwiek metody te są bardzo zróżnicowane tak co do podstawowych koncepcji, jak i sposobu ich wyrażania, możemy wyróżnić trzy wspólne ich cechy. Są to:

1. Przywiązanie dużej wagi do etapu analizy systemu, w szczególności do budowy abstrakcyjnego modelu systemu.

2. Zastosowanie zasady rozbioru (dekompozycji) modelu systemu jako podstawowej koncepcji i, co się z tym wiąże, zdefiniowanie szczegółowych kryteriów i sposobów dokonywania tej dekompozycji.

3. Zdefiniowanie modelu logicznego oraz modelu fizycznego (tak dla warstwy oprogramowania, jak i dla warstwy sprzętowej) w postaci grafopodobnych struktur przedstawianych za pomocą ściśle określonych konwencji notacyjnych.

Zasada rozbioru modelu systemu jest stosowana w metodach anality­cznych dwojako

. Po pierwsze, opis systemu jest rozwarstwiony pod kątem trzech podstawowych aspektów:

· architekturę systemu (w warstwach oprogramowania i sprzętowej),

· jego zachowanie (opis dynamiki),

· jego strukturę logiczną, (tzn. strukturę danych i strukturę funkcjo­nalną) .

Po drugie, dokonuje się dekompozycji systemu w każdym z wyżej wymienionych wymiarów. Dekompozycji tej dokonujemy na zasadzie poziomów abstrakcji. Zasada ta polega na podziale systemu na poziomy tworzące hierarchię, z których każdy stanowi uogólniony model systemu w postaci powiązanych ze sobą, elementów składowych, opisujący jedynie istotne (dla tego poziomu) aspekty systemu i pomijający nieistotne.

W metodach analitycznych wykorzystuje się dwa rodzaje operacji ab­strakcji prowadzące do dwóch typów hierarchii:

1. hierarchii kompozycyjnej (composition/aggregation/part-of hierarchy),

2. hierarchii uogólniającej (generalization/inheritance/kind-of hierarchy).

Hierarchia kompozycyjna opisuje rozbiór złożonych obiektów (procesów, struktur danych itp.) na prostsze elementy składowe.

Hierarchia uogólniająca opisuje, jak pewne bardziej szczegółowe kategorie zawierają się pojęciowo (semantycznie) w bardziej ogólnych kategoriach.

Dekompozycji systemu w metodach strukturalnych dokonujemy przede wszystkim na podstawie hierarchii kompozycyjnej, a w metodach obiek­towych na podstawie obu typów hierarchii.

Jakkolwiek szczegółowe kryteria dekompozycji (i ich szczegółowa inter­pretacja) są dla każdej z obu grup metod specyficzne, to wspólne jest przyjęcie dwóch podstawowych kryteriów, a mianowicie:

1. kryterium spójności elementów składowych systemu (cohesion),

2. kryterium więzi między elementami składowymi systemu (coupling).

Przez spójność elementu składowego systemu rozumie się charakterystykę określającą, jak mocno są wzajemnie związane lub w jak dużym stopniu odnoszą się do siebie wewnętrzne składniki pierwotne (procesy, obiekty, pro­cedury itp.), z których ten element jest zbudowany. Na charakterystykę tę składa się wiele czynników. Samo kryterium mówi, że powinno się tak dekomponować system, aby uzyskać jak największą spójność poszczególnych jego elementów na wszyst­kich poziomach abstrakcji.

Kryterium więzi między elementami składowymi stanowi, że dekom­pozycji systemu należy dokonywać w taki sposób, aby zminimalizować siłę powiązań między tymi elementami na każdym poziomie abstrakcji. Im mniejsza bowiem jest siła tych powiązań, tym bardziej elementy są niezależne, co z kolei powoduje, że cały system jest mniej złożony i dzięki temu bardziej niezawodny.

Wyróżnia się trzy warstwy metod analitycznych projektowania.

Pierwszą, i zdecydowanie kluczową, warstwę stanowią, podstawowe koncepcje ogólnej "filozofii" leżącej u podstaw danej metody. Na koncepcje te mają wpływ następujące czynniki:

· rodzaj systemów oprogramowania, którymi są szczególnie zaintere­sowani twórcy metody

· uwypuklenie najważniejszych (w opinii twórców metody) źródeł złożoności systemów i problemów związanych z projektowaniem tych systemów.

Spostrzeżenie to jest bardzo ważne, gdyż prowadzi do wniosku, że:

· nie istnieją, uniwersalne metody projektowania,

· nawet jeśli udało nam się dobrać odpowiednią. metodę do typu pro­jektowanego przez nas systemu, to na pryncypia metody powinniśmy spojrzeć poprzez specyfikę naszego systemu i traktować je raczej jako wskazówkę i pomoc, a nie jak na absolutne zasady, krępujące nas w trakcie projektowania.

Drugą warstwą są praktyczne wskazówki dotyczące procesu projektowa­nia. Są one zwykle rezultatem wieloletnich doświadczeń związanych z posługiwaniem się daną metodą, i dlatego mogą być stosowane z mniejszą dozą krytycyzmu.

I wreszcie trzecia warstwa - konwencje notacyjne, czyli to, co czyni z metod analitycznych "krainę chaosu" i powoduje wiele nieporozumień, zwłaszcza wśród początkujących użytkowników. Najczęściej spotykanym błędem jest redukowanie metod strukturalnych i obiektowych do poziomu graficznych konwencji notacyjnych, przy równoczesnym braku znajomości dwóch wcześniej wymienionych warstw.

IV. PODSTAWOWE KONCEPCJE PROJEKTOWANIA STRUKTURALNEGO

Koncepcje leżące u podstaw modelowania logicznego i fizycznego systemu mają swoje źródło w kryteriach, pod których kątem charakteryzuje się tak pożądane cechy kon­struowanego systemu informatycznego, jak i pożądane cechy samego procesu realizacji projektu konstrukcji systemu.

Można wyróżnić następujące kryteria:

1. Zgodność z funkcjonalną specyfikacją wymagań ( (functional) requirements specification fulfillment).

2. Wydajność (performance). Wydajność systemu jest charakteryzowana przez zbiór parametrów odpowiadających "osiągom" systemu (np. czas reakcji na wystąpienie pewnych sytuacji). Pożądana wydajność jako specyfikacja parametryczna systemu jest określana w fazie analizy strukturalnej, a rzeczywista wydajność jest sprawdzana w fazie testów zaimplementowanego systemu.

3. Koszty projektu. Wydatki poniesione w związku z projektem muszą zmieścić się w budżecie przeznaczonym na budowę i pielęgnację sys­temu.

4. Czas trwania projektu. Cecha ta jest jednym z najsłabszych punktów projektów informatycznych. Czas trwania projektu nie powinien przekroczyć założonego terminu zakończenia prac, a poszczególne etapy powinny być realizowane zgodnie z przyjętym harmonogramem.

5. Bezpieczeństwo (safety). Kryterium brane pod uwagę szczególnie w wypadku systemów czasu rzeczywistego. Cecha powodująca, że w razie wystąpienia błędu w systemie spadek jego wydajności jest "łagodny" i nie stanowi zagrożenia dla środowiska (graceful degradation) albo wręcz pełna funkcjonalność i wydajność są zachowane (fault-tolerant opera­tion).

6. Przyjazność (user-friendliness). Cecha określająca łatwość posługi­wania się systemem przez użytkownika. Bardzo ważna cecha przy posługiwaniu się systemem przez nieprofesjonalnych użytkowników.

7. Niezawodność (reliability). Ta cecha jest zwykle mierzona za pomoc wskaźnika określającego średni czas między awariami. Jest cechą krytyczną w systemach czasu rzeczywistego.

8. Pielęgnowalność (maintainability). Cecha mierzona za pomocą, wskaźnika określającego średni czas potrzebny na usunięcie błędu będącego przyczyną awarii i przywrócenie systemu do stanu używalności.

9. Efektywność (efficiency). System powinien efektywnie wykorzystywać dostępne (i zwykle niewystarczające całkowicie) zasoby. Przez za­soby nie należy rozumieć tu jedynie zasobów sprzętowych, tj. pro­cesora, pamięci operacyjnej, pamięci zewnętrznej itp., ale również za­soby ludzkie.

10. Modyfikowalność (modifiability). Cecha określ~,ją,ca, jak łatwe jest przystosowywanie systemu do zmieniających się wymagań użytkownika (np. rozbudowa systemu).

11. Elastyczność (flexibility). Cecha określająca, czy i w jakim stopniu system może wykonywać zadania będące nieznacznymi odmianami zadania, dla którego został zaprojektowany i zaimplementowany, bez dokonywania modyfikacji jego implementacji. Do cechy tej przywiązuje się ostatnio coraz więcej wagi.

Pierwsze sześć kryteriów ma silny związek z etapem analizy struktural­nej, którego pierwszą, fazą jest sformalizowanie zbioru wymagań. Wyma­gania te można podzielić w następujący sposób.

A. Wymagania dotyczące konstruowanego systemu:

· funkcjonalne - określające, co system powinien robić, tzn. jakie funkcje powinien realizować (w tym, co system powinien robić w wypadku wystąpienia błędów),

· parametryczne (wydajność) - określające, "jak dobrze" system powinien realizować te funkcje,

· komunikacyjne - definiujące sposób komunikacji systemu z użyt­kownikiem (przyjazność), a także z innymi systemami.

B. Wymagania dotyczące samego projektu, w ramach którego system jest konstruowany:

· koszty realizacji,

· czas realizacji.

Zadaniem analityka systemów informatycznych jest nie tylko upewnienie się, że zaproponowany model logiczny systemu:

· stanowi rzeczywiście rozwiązanie problemu opisanego przez użytkowni­ka (adekwatność modelu w stosunku do pierwotnego opisu problemu) oraz że

· rozwiązanie to obejmuje wszystkie aspekty opisanego problemu, włączając warunki brzegowe, sytuacje awaryjne itp. (kompletność modelu),

W projektowaniu strukturalnym podstawowym pojęciem jest moduł (module), które jest używane do określenia podstawowego składnika sys­temu oprogramowania. Modułem nazywamy sekwencję instrukcji programu wyodrębnioną z tego programu za pomocą ograniczników i mającą identy­fikator, przez który możemy odwołać się do niej jako do całości.

Wyróżnia się dwa podstawowe kryteria dekompozycji: kryterium spójności modułów oraz kryterium więzi międzymodułowych, które są używane w metodach strukturalnych oraz obiektowych. Dwa moduły są, mocno związane (highly coupled), jeśli zachodzą między nimi silne wzajemne relacje, uniemożliwiające zrozumienie działania jednego z nich bez znajomości drugiego. Moduły niezwiązane (ang. decoupled, uncoupled) są niezależne w powyższym sensie, co oznacza, że mogą być implementowane i modyfikowane osobno.

1. Ze względu na rodzaje odwołań między modułami wyróżniamy trzy rodzaje systemów.

1. System połączony minimalnie (minimally-connected system) - to system, w którym wszystkie wywołania modułów (i powroty z nich) ograniczają się do pojedynczych (unikatowych) punktów przekazywania sterowania, a wszystkie dane są przekazywane przez parametry (wejściowe i wyjściowe).

2. Systemem połączonym normalnie (normally-connected system) nazywamy system, w którym dopuszczamy:

· więcej niż jeden punkt wejścia do wywoływanego modułu (przy dalszym zachowaniu parametrycznego przekazywania danych),

· więcej niż jeden punkt powrotu do wywołującego modułu pod warunkiem, że alternatywne punkty powrotu są jawnie określone w tym module.

3. Jeśli system nie jest połączony ani minimalnie, ani normalnie, to jest to system połączony patologicznie (pathologically-connected system).

2. Przepływ komunikacji między modułami w systemie może mieć charakter:

1. Jednokierunkowego przepływu danych.

2. Dwukierunkowego przepływu danych.

3. Jednokierunkowego przepływu sterowania.

4. Dwukierunkowego przepływu sterowania.

Im wyższego poziomu jest typ komunikacji (przy typach będących kom­binacjami powyższych typów bierzemy pod uwagę typ o największym indeksie), tym silniejsza więź występuje między modułami.

3. Wyróżniamy cztery podstawowe sposoby wiązania modułów.

1. Moduły łączy więź danych (data coupling), jeśli wszystkie dane w trakcie ich komunikacji są przekazywane przez parametry (wejściowe i wyjściowe). W tym wypadku wyróżniamy jeszcze: bardziej preferowane przekazywanie parametrów przez wartość (przekazujemy "kopię" danych do modułu wywoływanego) oraz przekazywanie parametrów przez adres (przekazujemy rzeczywisty adres miejsca, gdzie dane się znajdują. i wywoływany moduł ope­ruje bezpośrednio na tych danych).

2. Moduły są połączone więzią cechy (stamp coupling), jeśli odwołują się do wspólnej dla nich (ale nie globalnej) współdzielonej struk­tury danych.

3. Moduły są połączone więzią wspólną (common coupling), jeśli odwołują się do tej samej globalnej struktury danych.

4. Moduły są związane treściowo (content-coupled), jeśli jeden z nich odwołuje się bezpośrednio do treści drugiego.

4. Ze względu na złożoność interfejsu między modułami wyróżnia się:

1. Interfejs prosty (niewielka liczba parametrów).

2. Interfejs złożony (duża liczba parametrów).

Kryterium spójności modułów. W metodyce projek­towania strukturalnego wyróżniamy osiem stopni "mocy" spójności modułów (omówimy je od najlepszej do najgorszej sytuacji).

1. Moc funkcjonalna (functional cohesion) występuje, gdy każdy ele­ment składowy modułu jest niezbędnym elementem realizacji do­brze określonej (pojedynczej, niezłożonej) funkcji przypisanej temu modułowi.

2. Moc informacyjna (information cohesion) występuje, gdy jeden moduł wykonuje kilka dobrze określonych (pojedynczych, niezłożonych) wza­jemnie niezależnych funkcji, z których każda odnosi się do tej samej struktury danych.

3. Moc sekwencyjna (sequential cohesion) modułu oznacza, że zgrupowano w nim sekwencję elementów realizujących kolejne etapy przetwarzania pewnych struktur danych, tzn. dane wyjściowe - wyniki poprzedniego etapu są danymi wejściowymi następnego etapu.

4. Moc komunikacyjna (communicational cohesion) modułu występuje, gdy moduł składa się z elementów realizujących pewien algorytm, przy czym elementy te operują na tej samej strukturze danych i/lub pro­dukują te same dane wyjściowe.

5. Moc proceduralna (algorytmiczna) (procedural cohesion) modułu oz­nacza, iż składa się on z elementów, które realizują. w całości pewien al­gorytm (procedurę) wykorzystywany do rozwiązania określonego zada­nia w systemie (przy czym poszczególne elementy nie muszą, być powiązane ze względu na przetwarzane struktury danych).

6. Moc klasyczna w terminologii anglojęzycznej jest określana jako tem­poral cohesion, tzn. moc związana z fazą (określonym okresem czasu) procesu przetwarzania danych.

7. Moc logiczna (logical cohesion) modułu jest rezultatem zgrupowania w nim wielu, w istocie różnych, funkcji należących do tej samej klasy ze względu na rodzaj procesu przetwarzania danych.

8. Moc przypadkowa (coincidental cohesion) modułu oznacza, że między jego elementami składowymi nie występują znaczące relacje.

Spójność modułowa jest jednym z najbardziej "wymiernych" kryteriów używanych przy ocenie modularyzacji systemów informatycznych. W lite­raturze możemy spotkać nawet liczbowe skale, które mogą, być używane do mierzenia jakości modularyzacji. Na przykład:

10 - moc funkcjonalna,

9 - moc sekwencyjna,

7 - moc komunikacyjna,

5 - moc proceduralna (algorytmiczna),

3 - moc klasyczna,

1 - moc logiczna,

0 - moc przypadkowa.

V. PODSTAWOWE KONCEPCJE PROJEKTOWANIA OBIEKTOWEGO

Podstawowe pojęcia

System informatyczny w podejściu obiektowym jest postrzegany jako zbiór tzw. obiektów oraz klas, między którymi zostały zdefiniowane relacje roz­maitych rodzajów. Obiektem (object) albo instancją (instance) nazywamy element należący do pewnej dziedziny (zbioru), który jest specyfikowany w tej dziedzinie przez następujące trzy charakterystyki:

· stan wewnętrzny (state),

· sposób zachowania ( behaviour),

· tożsamość unikatową (identity).

Stan obiektu określamy przez przypisywanie w dyskretnych momentach aktualnych wartości zmiennym składającym się na strukturę obiektu. Każdą taka zmienną, odpowiadającą pewnej właściwości obiektu, nazywamy obiek­tem członkowskim lub polem (member object, field) danego obiektu.

Przez sposób zachowania obiektu rozumiemy taką. jego charakterystykę, która określa, jakie operacje (operations) mogą być dokonywane na nim przez inne obiekty, jakie operacje może on wykonywać na innych obiektach oraz jakie są konsekwencje dokonywania tych operacji w sensie zmian stanów danego obiektu i obiektów, które były z nim w interakcji.

Rozróżnia się pięć podstawowych operacji (operatorów):

· konstruktor (constructor) powoduje utworzenie obiektu wraz z ewen­tualnym zainicjowaniem zmiennych jego stanu (początkowego),

· modyfikator (modifier) powoduje zmianę stanu obiektu,

· selektor (selector) udostępnia informację o stanie innego obiektu, nie powodując przy tym jego zmiany,

· iterator (iterator) umożliwia dostęp do całej struktury obiektu przez sekwencyjne (iteracyjne) udostępnianie jej poszczególnych elementów w ściśle określony sposób (np. według dobrze określonego porządku przeglądania struktury),

· destruktor (destructor) niszczy obiekt.

· warunki wstępne (preconditions) operacji, czyli niezmienniki umożliwia­jące wykonanie operacji; niespełnienie warunków wstępnych oznacza, że obiekt żądający wykonania operacji nie zapewnił warunków jej re­alizacji i dlatego obiekt dostarczający usługi nie może jej wykonać;

· semantyka (semantics) operacji będąca opisem przebiegu operacji;

· warunki końcowe (postconditions) operacji, tj. niezmienniki, jakie muszą być spełnione po wykonaniu operacji; ich niespełnienie oznacza, że obiekt dostarczający usługi nie wykonał operacji tak, jak powinien, co świadczy, że obiekt żądający wykonania operacji nie powinien mieć zaufania do jej rezultatu;

· sytuacje szczególne (exceptions) będące wskazaniem, że pewne niez­mienniki nie zostały lub nie mogą być spełnione; oznacza to, że wykonanie operacji zostało zaniechane, a informacja o niemożności jej wykonania i przyczynach tego faktu jest przesłana do obiektu żądającego wykonania operacji.

W metodach obiektowych dokonuje się podziału na trzy podstawowe typy obiektu ze względu na charakter jego związków operatorowych z innymi obiektami.

Są, nimi:

· obiekty, które dokonuj, operacji na innych obiektach, ale nigdy nie podlegają operacjom ze strony innych obiektów, nazywane aktorami (actors),

· serwery (servers), czyli obiekty podlegające operacjom ze strony in­nych obiektów i nie operujące na innych obiektach,

· agenci (agents) będący obiektami, które operują na innych obiektach i mogą być przedmiotem operacji ze strony innych obiektów.

Ostatnią charakterystyką obiektu jest tożsamość unikatowa, która oz­nacza, iż obiekt jest unikatowo identyfikowalny spośród innych obiektów.

Drugim podstawowy pojęciem projektowania obiektowego jest klasa (class). Definiuje się jako zbiór obiektów o takiej samej strukturze i o takim samym zachowaniu. Jedną z podstawowych koncepcji projektowania obiektowego jest idea enkapsulacji, tj. chowania informacji wewnątrz składowych modelu. Koncepcja ta jest zrealizowana w praktyce przez rozwarstwienie każdej klasy na:

· warstwę zewnętrzną, tzw. interfejs (interface),

· warstwę wewnętrzną, zwaną implementacją (implementation).

Warstwa zewnętrzna definiuje wzorce zachowania się klasy w stosunku do innych klas, głównie przez zadeklarowanie zbioru operacji dotyczących obiektów tej klasy. Tak więc warstwa ta określa sposób zachowania się obiektów danej klasy. W podejściu obiektowym istnieje możliwość uprzywilejowania obiektów pewnej klasy we wspomnianym sensie przez zadeklarowanie tej klasy jako tzw. klasy zaprzyjaźnionej (friend class).

Poniżej obszaru prywatnego warstwy zewnętrznej znajduje się warstwa wewnętrzna. W warstwie tej znajdują się opisy (w formie algorytmicznej) sposobu realizacji operacji zadeklarowanych w warstwie zewnętrznej, gwarantującego określone zachowanie się klasy oraz definicje struktury klasy.

Warunki konieczne i pożądane metodyki projektowania obiektowego

Na początku lat dziewięćdziesiątych osiągnięto pewne porozumienie, polegające na wyodrębnieniu czterech warunków koniecznych metodyki obiektowej, tj. abstrakcji, modu­larności, hierarchizacji i enkapsulacji, oraz trzech pożądanych warunków: trwałości, typowania i współbieżności.

Abstrakcja

Abstrakcję (abstraction) zdefiniuje się jako uogólniony model obiektu, opisujący istotne z pewnego punktu widzenia cechy tego obiektu i pomijający nieistotne. Koncepcja jest prosta i intuicyjna, czego nie można, niestety, powiedzieć o jej praktycznej realizacji, to znaczy o metodzie (metodach) wyodrębniania klas abstrakcji w procesie analizy dziedziny problemu, który mamy rozwiązać przez dostarczenie systemu informatycznego.

W wypadku metod obiektowych specjalne znaczenie nadajemy dwóm rodzajom abstrakcji. Są. to:

· abstrakcja kompozycyjna,

· abstrakcja uogólniająca.

Z abstrakcją kompozycyjną mamy do czynienia, jeśli zbiór pewnych obiektów (pojęć) tworzy nową jakość.

Abstrakcja uogólniająca polega na utworzeniu nowej jakości na podstawie cech obiektów (pojęć) należących do pewnego zbioru, charakteryzującej się cechami, które są wspólne dla tych obiektów.

Hierarchizacja

Koncepcja hierarchizacji (hierarchy) leży u podstaw metod obiektowych.

W zależności od tego, jakiego typu operacji abstrakcji używamy, otrzy­mujemy dwa podstawowe typy struktur - hierarchii. Są nimi: hierarchia kompozycyjna (composition/aggregation/part-of-hierarchy) oraz hierarchia uogólniająca (generalization/inheritance/kinf of hierarchy). Fakt, iż pewna klasa jest uogólnieniem innej klasy (innych klas), wyrażamy w podejściu obiektowym przez określenie między nimi tzw. relacji dziedziczenia (inhe­ritance relationship). Dziedziczenie dotyczy dwóch podstawowych charak­terystyk klasy, tj. struktury i/lub zachowania.

Modularność

Zasada modularności (modularity) została przejęta przez podejście obiek­towe od szkoły strukturalnej.

Polega ona na dekompozycji systemu na zbiór modułów, które powinny być spójne i słabo związane. W metodach obiek­towych, stosując kryterium spójności modułów staramy się uzyskać nie tyle moc funkcjonalną, ale moc informacyjną. Oznacza to, że dekompozycję kończy się nie wtedy, kiedy uzyska się jedną funkcję - operację, ale gdy uzyska się zbiór takich elementarnych operacji, z których każda odnosi się do tej samej struktury danych.

Takie kryterium analizy (rozkładu) modelu fizycznego jest naturalną konsekwencją faktu, że konstrukcja modelu logicznego w szkole obiektowej ogniskuje się wokół pojęcia obiektu, a w szkole strukturalnej model logiczny budujemy przez funkcjonalną dekompozycję do poziomu funkcji (operacji) elementarnych.

Enkapsulacja

Koncepcja enkapsulacji (encapsulation) neutralizuje skutki, jakie mogą mieć wpływ na złożoność systemu informatycznego w wypadku zastosowania sposobu modularyzacji opisanego powyżej. Jeśli tworzymy moduły wykonujące kilka funkcji wokół pewnej struktury danych, to biorąc pod uwagę fakt, iż nie są one już tak "elementarne" jak w wypadku modułów o mocy funkcjonalnej, będziemy starali się "schować" wewnątrz takiego modułu tak wspomniana strukturę danych, jak i sposób realizacji tych funkcji.

W celu sformalizowania praw dostępu do warstwy zewnętrznej (tutaj rozu­mianej jako zbiór operacji) danej klasy, interfejs dzielimy na następujące trzy obszary:

· obszar publiczny (public), zawierający ten fragment warstwy zewnętrz­nej klasy, który jest widzialny dla wszystkich innych klas widzialnych z tej klasy,

· obszar chroniony (protected), czyli fragment interfejsu klasy, który nie jest widzialny przez inne klasy z wyjątkiem jej podklas,

· obszar prywatny (private), będący najbardziej "intymnym" obszarem, który nie jest widzialny przez inne, niż dana, klasy.

Trwałość

Zasada trwałości (persistence) jest związana ze specyfiką obiektów jako ele­mentów pamiętających swój stan zenkapsulowany w warstwie wewnętrznej. Trwałość oznacza więc w tym wypadku cechę obiektu polegającą na tym, iż obiekt utworzony przez operator typu konstruktor istnieje nawet po zakończeniu działania programu zawierającego ten konstruktor i po ponownym uru­chomieniu programu możemy odwołać się do tego obiektu.

Pojęcie to możemy rozszerzyć na środowisko rozproszone. Wówczas obiekty wykreowane w jednym miejscu tego środowiska mogą migrować w inne miejsca i być używane przez inne systemy (nawet jeśli sys­temy te używają innych reprezentacji fizycznych). Postulat trwałości w metodyce obiektowej utorował drogę obiektowo zorientowanym systemom zarządzania bazami danych (object-oriented database management systems), które znajdują obecnie szerokie zastosowanie w tych gałęziach informatyki, w których mamy do czynienia z zastosowaniem złożonych algorytmów i równocześnie potrzebą przetwarzania i zapamiętywania dużych ilości danych (np. w systemach Computer Aided Engineering CAE, Manufac­turing Planning and Control MPC itp.).

Typowanie

Typowanie (typing) dotyczy raczej programowania obiektowego niż pro­jektowania obiektowego. Polega on ona "sztywnym" przypisaniu obiektowi konkretnej klasy, zwanej wtedy również typem (type) obiektu. Oz­nacza to, że w sytuacji, w której zostało zdeterminowane użycie obiektu o określonym typie, nie możemy (lub możemy przy założeniu przestrzegania pewnych dobrze określonych warunków) użyć obiektu o innym typie.

Ze względu na typowanie języki programowania możemy podzielić na:

· silnie typowane (strongly typed),

· słabo typowane (weakly typed),

· nietypowane (untyped).

W językach silnie typowanych nie istnieje możliwość zastosowania ope­racji przy braku zgodności typów obiektów. W językach nietypowanych taka zgodność nie jest sprawdzana. Języki słabo typowane wymagają w zasadzie zgodności typów, ale istnieje możliwość osłabienia reguł typowania.

Współbieżność

Współbieżność (concurrency) wykonywania się zadań w systemach infor­matycznych i obiektowe podejście do ich projektowania to koncepcje wza­jemnie się wspomagające.

Ze względu na współbieżność modelowane systemy dzielimy na:

· systemy sekwencyjne (sequential systems), w których w danym mo­mencie ma się do czynienia z jednym obiektem, który jest czynny; po­zostałe obiekty są nieczynne, a pobudzenie jednego z nich do działania polega na przesłaniu wiadomości z czynnego obiektu, który następnie przechodzi w stan nieczynny; obiekty, które aktywując inny obiekt zachowują się w taki właśnie sposób, nazywamy obiektami sekwen­cyjnymi; mogą one również występować w systemach drugiego typu omawianych poniżej;

· systemy współbieżne (concurrent systems), w których więcej niż jeden obiekt może być czynny w danym momencie; obiekty takie przez cały czas są czynne i nie potrzebują aktywacji z zewnątrz, dlatego nazy­wamy je obiektami aktywnymi (active objects).

W wypadku systemów współbieżnych podstawowym problemem jest problem synchronizacji działania dwóch lub więcej obiektów aktywnych (ak­torów lub agentów) żądających wykonania operacji przez pewien obiekt dostarczający usług. Jest to znany z teorii systemów współbieżnych prob­lem wzajemnego wykluczania procesów (mutual exclusion) w dostępie do współdzielonych zasobów.

W projektowaniu obiektowym rozróżniamy dwa główne typy obiektów, nad którymi obiekty aktywne dokonują, operacji. Są to:

· obiekty strzeżone (guarded objects),

· obiekty synchroniczne (synchronous objects).

Obiekty strzeżone zawierają jako obiekt członkowski tzw. wartownika (guard). Wartownik jest wyrażeniem logicznym, które określa warunki, jakie muszą być spełnione, aby obiekt aktywny (klient) zlecił obiektowi strzeżonemu wykonanie pewnej usługi.

Tak więc klient (aktor albo agent) powinien zachowywać się zgodnie z następującym protokołem:

· uzyskać dostęp do obiektu strzeżonego (w momencie pozytywnego wyniku, jaki daje wartownik),

· dokonać operacji nad tym obiektem,

· zwolnić dostęp do obiektu.

Oznacza to, że w wypadku obiektów strzeżonych aktywni klienci muszą. wykonywać pewne akcje zabezpieczające wzajemne wykluczanie według ustalonego protokołu. Jeśli stosujemy obiekt synchroniczny, to bierze on na siebie odpowiedzialność za synchronizację dostępu aktywnych procesów do wspólnego zasobu.

---