obiektowe_metody_projektowania_systemow_informatycznych [mgr Wiki]

[[obiektowe_metody_projektowania_systemow_informatycznych]]
mgr Wiki

# Obiektowe projektowanie systemów informatycznych

Obiektowe projektowanie systemów informatycznych (ang. Object Oriented Design) Jest jednym z etapów wytwarzania obiektowego. Jego celem jest uściślenie definicji klas i obiektów zdefiniowanych w etapie analizy obiektowej. Wynikiem etapu jest baza do implementacji systemu w wybranym języku programowania.

Zaletą projektowania obiektowego (w stosunku do strukturalnego) jest to iż przy wytwarzaniu oprogramowania obiektowość umożliwia płynne przejście pomiędzy kolejnymi fazami cyklu życia oprogramowania a także ułatwia w początkowej fazie ( faza określania wymagań) przejście z dziedziny problemowej do dziedziny technologii informatycznych. Projekt obiektowy jest czytelny, łatwy w modyfikacji, co pozwala na jago szeroki zastosowanie.

Zasadniczą różnicą podejścia obiektowego od tradycyjnych metod jest to, że:

Podejście obiektowe nie opiera się na funkcjonalnej dekompozycji procesów zachodzących w świecie rzeczywistym, a na opisie obiektów rzeczywistych, które grają określoną rolę w tym świecie.

Wg OMT obiektowość jest sposobem myślenia i organizacji oprogramowania polegającym na wyodrębnianiu dyskretnych obiektów, które odwzorowują zarówno statyczną strukturę świata i danych, jak i zachowanie (behaviour)

Dzięki podejściu obiektowemu uzysujemy “gładkie” przejście od analizy, poprzez projekt aż do implementacji, ponieważ wszystkie te etapy odwołują się do tej samej wspólnej bazy pojęciowej (patrz: pojecia_zwiazane_z_obiektowoscia.doc)

Podejście obiektowe do projektowania systemów zakłada iterację (powtarzanie) następujących faz:

- Analiza: budowa modelu świata rzeczywistego
- Projektowanie systemowe: zagadnienia architektoniczne, podsystemy
- Projektowanie obiektowe: budowa modeli obiektowych opartych na wynikach analizy.
- Implementacja: zakodowanie projektu w języku programowania

Celem fazy projektowania jest opracowanie szczegółowego opisu implementacji systemu. Jednym z podstawowych założeń inżynierii oprogramowania jest dążenie do tego, aby struktura tworzonego oprogramowania jak najbardziej zachowała ogólną strukturę modelu tworzonego w poprzedniej fazie.

Metodyka OMT rozróżnia dwa etapy fazy projektowej:

Projekt systemu który dotyczy ogólnych zagadnień projektowych i decyzji strategicznych mających wpływ na ostateczną strukturę systemu(określa: podział na podsystemy, współbieżność,, przechowywanie danych, zarządzanie zasobami, sterowanie, warunki brzegowe) Wynikowy system jest organizowany w podsystemy na podstawie wyników analizy jak i założeń co do ogólnej architektury. Projektant musi podjąć decyzje dotyczące optymalizacji charakterystyk wydajnościowych, wybrać strategię rozwiązania tego problemu oraz podjąć decyzje odnośnie alokacji zasobów.

Szczegółowy projekt obiektów obejmuje kontynuacje i uściślenie modeli utworzonych w fazie analizy i modelowania( uściślenie definicji klas, rodziny klas dziedziczących, optymalizację modelu, projektowanie operacji, ukrywanie informacji) Projekt bazuje na wyniku analizy oraz wyniku projektowania systemowego. Zawiera wiele elementów implementacyjnych odnoszących się do struktury obiektowej oraz algorytmów (metod) przetwarzania potrzebnych do implementacji klas.

Projektowanie obywa się poprzez:

- Uszczegóławianie wyników analizy - poprzez podanie reguł odwzorowania notacji dla danych (notacji stosowanej w modelu pojęciowym - wyniku fazy analizy) w struktury tego języka programowania, który będzie wykorzystany do implementacji systemu. Uściślenie istniejących definicji klas.
- Uszczegóławianie metod:

       + Zastąpienie niektórych prostych metod publicznym dostępem do atrybutów
       + Zastąpienie niektórych atrybutów redundantnych (pochodnych) przez odpowiednie metody
       + Określenie dostępności dla atrybutów i metod (tylko w fazie w projekotowania)

- Określenie sposobów implementacji powiązań między obiektami poprzez określenie kierunków związków pomiędzy obiektami
- Określenie dziedziczenia klas

Techniki obiektowe określania powiązań między obiektami oraz określania dostępności atrybutów i metod są charakterystyczne tylko dla fazy projektowania. Notowane są w najstępujący sposób:

Oznaczenia powiązania(asocjacji): oprócz oznaczenia asocjacji zaznacza się też kierunek przesyłania komunikatów:

Oznaczenia dostępności dla atrybutów i metod:

(+) publiczny - dostępny dla wszystkich obiektów (#) zabezpieczony (protected) - dostęp dla obiektów danej klasy oraz jej specjalizacji (-) prywatny - dostęp tylko dla obiektów danej klasy

Przykład uzupełnionego w fazie projektowania stworzonego w fazie analizy diagramu klas:

W zorientowanej obiektowo notacji Booch(1994) w fazie projektoej dodatkowo określa się takie konstrukcje projektowe jak:

- Wzorce klas (szablony)
- Metaklasy, tj. klasy zawierające atrybuty i metody dotyczące klasy jako całości, a nie pojedynczych obiektów, np. atrybuty i metody statyczne (klasy).
- Wolne funkcje - funkcje nie będące metodami żadnej z klas.
- Stereotypy
- Spsosoby widoczności obiektu.

W fazie projektowania zorientowanej obiektowo tworzymy następujące modele które są uszczegółowieniem modeli uzyskanych w poprzednich fazach:

## Cechy metodyk obiektowych

- Przesunięcie trudu rozwoju na fazę analizy
- Większy nacisk na struktury danych, a mniejszy na funkcje, co wspomaga stabilność.
- Podejście iteracyjne raczej niż sekwencyjne. Cechy projektu są dodawane i wyjaśniane w kolejnych iteracjach
- Wykorzystuje pojęcia obiektowości dla celów modelowania pojęciowego oraz analizy i projektowania systemów informatycznych.
- Podstawowym składnikiem tych metodyk jest diagram obiektów, będący zwykle wariantem notacyjnym i pewnym rozszerzeniem diagramów encja-związek.
- Diagram obiektów zawiera takie elementy jak: klasy, w ramach klas specyfikacje atrybutów i metod, strukturę dziedziczenia pomiędzy klasami, związki asocjacji i agregacji, liczności tych związków, różnorodne ograniczenia oraz inne oznaczenia.
- Uzupełnieniem tego diagramu są inne, np. diagramy dynamiczne uwzględniające stany poszczególnych procesów przetwarzania i przejścia pomiędzy tymi stanami, diagramy zależności pomiędzy wywołaniami metod, np. diagram tropów komunikatów, diagramy fukcjonalne (będące zwykle pewną mutacją diagramów przepływu danych).

Kompletny projekt powinien zawierać :

- Poprawiony dokument opisujący wymagania
- Poprawiony model
- Uszczegółowiona specyfikacja projektu zawarta w słowniku danych
- Dokument opisujący stworzony projekt składający się z (dla obiektowych):

      • diagramu klas
      • diagramów interakcji obiektów
      • diagramów stanów
      • innych diagramów, np. diagramów modułów, konfiguracji
      • zestawień zawierających:
               • definicje klas
               • definicje atrybutów
               • definicje danych złożonych i elementarnych
               • definicje metod

- Zasoby interfejsu użytkownika, np. menu, dialogi
- Projekt bazy danych
- Projekt fizycznej struktury systemu
- Poprawiony plan testów
- Harmonogram fazy implementacji

Może się przydać:

Pojęcia związane z obiektowością:

pojecia_zwiazane_z_obiektowoscia.doc

Szczegółowy opis obiektowych metod programowania:

obiektowe_metody_projektowania_systemow.doc

obiektowe_metody_projektowania_systemow_informatycznych.txt · Last modified: 2006/05/20 16:13 by 213.134.178.167