OOAD - Projektowanie zorientowane obiektowo

Po fazie analizy model koncepcyjny jest dalej rozwijany w model zorientowany obiektowo przy użyciu projektowania zorientowanego obiektowo (OOD). W OOD koncepcje niezależne od technologii w modelu analizy są mapowane na klasy implementujące, identyfikowane są ograniczenia i projektowane są interfejsy, w wyniku czego powstaje model domeny rozwiązania. Krótko mówiąc, skonstruowano szczegółowy opis określający sposób budowy systemu w oparciu o technologie betonowe

Etapy projektowania zorientowanego obiektowo można określić jako -

• Definicja kontekstu systemu
• Projektowanie architektury systemu
• Identyfikacja obiektów w systemie
• Budowa modeli projektowych
• Specyfikacja interfejsów obiektów

Projekt systemu

Projekt systemu obiektowego obejmuje zdefiniowanie kontekstu systemu, a następnie zaprojektowanie architektury systemu.

• Context- Kontekst systemu ma część statyczną i dynamiczną. Kontekst statyczny systemu jest projektowany za pomocą prostego schematu blokowego całego systemu, który jest rozszerzany do hierarchii podsystemów. Model podsystemu jest reprezentowany przez pakiety UML. Dynamiczny kontekst opisuje, w jaki sposób system współdziała ze swoim otoczeniem. Jest modelowany za pomocąuse case diagrams.

• System Architecture- Architektura systemu jest projektowana w oparciu o kontekst systemu, zgodnie z zasadami projektowania architektonicznego oraz wiedzy dziedzinowej. Zazwyczaj system jest podzielony na warstwy, a każda warstwa jest rozkładana w celu utworzenia podsystemów.

Rozkład obiektowy

Dekompozycja oznacza podzielenie dużego złożonego systemu na hierarchię mniejszych komponentów o mniejszych złożoności, na zasadzie dziel i rządź. Każdy główny składnik systemu nazywany jest podsystemem. Dekompozycja obiektowa identyfikuje poszczególne autonomiczne obiekty w systemie i komunikację między tymi obiektami.

Zalety rozkładu to -

• Poszczególne komponenty są mniej skomplikowane, a więc bardziej zrozumiałe i łatwiejsze w zarządzaniu.

• Umożliwia podział kadr o specjalistycznych umiejętnościach.

• Umożliwia wymianę lub modyfikację podsystemów bez wpływu na inne podsystemy.

Identyfikacja współbieżności

Współbieżność umożliwia jednoczesne odbieranie zdarzeń przez więcej niż jeden obiekt i jednoczesne wykonywanie więcej niż jednego działania. Współbieżność jest identyfikowana i reprezentowana w modelu dynamicznym.

Aby włączyć współbieżność, do każdego współbieżnego elementu jest przypisany oddzielny wątek kontroli. Jeśli współbieżność jest na poziomie obiektu, dwa współbieżne obiekty mają przypisane dwa różne wątki kontroli. Jeśli dwie operacje na jednym obiekcie są z natury współbieżne, obiekt ten jest dzielony na różne wątki.

Współbieżność wiąże się z problemami związanymi z integralnością danych, impasem i głodem. Dlatego zawsze, gdy wymagana jest współbieżność, należy opracować jasną strategię. Poza tym współbieżność wymaga identyfikacji na samym etapie projektowania i nie można jej pozostawić na etapie wdrożenia.

Identyfikowanie wzorców

Projektując aplikacje, przyjmuje się powszechnie przyjęte rozwiązania dla pewnych kategorii problemów. To są wzorce projektowania. Wzorzec można zdefiniować jako udokumentowany zestaw bloków konstrukcyjnych, które mogą być używane w niektórych typach problemów związanych z tworzeniem aplikacji.

Niektóre powszechnie używane wzorce projektowe to -

• Wzór elewacji
• Wzór separacji widoku modelu
• Wzorzec obserwatora
• Wzorzec kontrolera widoku modelu
• Opublikuj wzorzec subskrypcji
• Wzorzec proxy

Kontrolowanie wydarzeń

Podczas projektowania systemu należy zidentyfikować zdarzenia, które mogą wystąpić w obiektach systemu i odpowiednio się nimi zająć.

Zdarzenie to specyfikacja znaczącego zdarzenia, które ma miejsce w czasie i przestrzeni.

Istnieją cztery typy zdarzeń, które można modelować, a mianowicie:

• Signal Event - Nazwany obiekt rzucony przez jeden obiekt i przechwycony przez inny obiekt.

• Call Event - Zdarzenie synchroniczne reprezentujące wysłanie operacji.

• Time Event - Wydarzenie reprezentujące upływ czasu.

• Change Event - zdarzenie reprezentujące zmianę stanu.

Obsługa warunków brzegowych

Faza projektowania systemu musi obejmować inicjalizację i zakończenie systemu jako całości, a także każdego podsystemu. Różne udokumentowane aspekty są następujące:

• Uruchomienie systemu, czyli przejście systemu ze stanu niezainicjalizowanego do stanu ustalonego.

• Zakończenie systemu, tj. Zamknięcie wszystkich uruchomionych wątków, oczyszczenie zasobów i wysyłanie komunikatów.

• Wstępna konfiguracja systemu i rekonfiguracja systemu w razie potrzeby.

• Przewidywanie awarii lub niepożądanego zakończenia systemu.

Warunki brzegowe są modelowane przy użyciu przypadków użycia granic.

Projektowanie obiektów

Po opracowaniu hierarchii podsystemów identyfikowane są obiekty w systemie i projektowane są ich szczegóły. Tutaj projektant szczegółowo przedstawia strategię wybraną podczas projektowania systemu. Nacisk przenosi się z koncepcji domeny aplikacji na koncepcje komputerowe. Obiekty zidentyfikowane podczas analizy są wytrawiane do wdrożenia w celu zminimalizowania czasu wykonywania, zużycia pamięci i całkowitego kosztu.

Projekt obiektu obejmuje następujące fazy -

• Identyfikacja obiektu
• Reprezentacja obiektów, czyli budowa modeli projektowych
• Klasyfikacja operacji
• Projektowanie algorytmów
• Projektowanie relacji
• Realizacja kontroli dla interakcji zewnętrznych
• Pakuj klasy i skojarzenia do modułów

Identyfikacja obiektu

Pierwszym krokiem projektowania obiektu jest identyfikacja obiektu. Obiekty zidentyfikowane w fazach analizy obiektowej są pogrupowane w klasy i dopracowane tak, aby nadawały się do rzeczywistej implementacji.

Funkcje tego etapu to -

• Identyfikowanie i udoskonalanie klas w każdym podsystemie lub pakiecie

• Definiowanie powiązań i powiązań między klasami

• Projektowanie hierarchicznych skojarzeń między klasami, tj. Uogólnienie / specjalizacja i dziedziczenie

• Projektowanie agregacji

Reprezentacja obiektu

Po zidentyfikowaniu klas należy je przedstawić za pomocą technik modelowania obiektów. Ten etap zasadniczo obejmuje tworzenie diagramów UML.

Istnieją dwa rodzaje modeli projektowych, które należy wyprodukować -

• Static Models - Opisywać strukturę statyczną systemu za pomocą diagramów klas i diagramów obiektów.

• Dynamic Models - Opisać dynamiczną strukturę systemu i pokazać interakcję między klasami za pomocą diagramów interakcji i diagramów wykresów stanu.

Klasyfikacja operacji

Na tym etapie operacje, które mają zostać wykonane na obiektach, są definiowane poprzez połączenie trzech modeli opracowanych w fazie OOA, a mianowicie modelu obiektowego, modelu dynamicznego i modelu funkcjonalnego. Operacja określa, co należy zrobić, a nie jak należy to zrobić.

Następujące zadania są wykonywane w odniesieniu do operacji -

• Opracowywany jest diagram przejść stanów każdego obiektu w systemie.

• Operacje są zdefiniowane dla zdarzeń odbieranych przez obiekty.

• Identyfikowane są przypadki, w których jedno zdarzenie wyzwala inne zdarzenia w tych samych lub różnych obiektach.

• Zidentyfikowano podoperacje w ramach działań.

• Główne działania zostały rozszerzone na diagramy przepływu danych.

Projektowanie algorytmów

Operacje na obiektach są definiowane za pomocą algorytmów. Algorytm to krokowa procedura, która rozwiązuje problem związany z operacją. Algorytmy koncentrują się na tym, jak to zrobić.

Danej operacji może odpowiadać więcej niż jeden algorytm. Po zidentyfikowaniu alternatywnych algorytmów wybierany jest optymalny algorytm dla danej dziedziny problemowej. Metryki wyboru optymalnego algorytmu to:

• Computational Complexity - Złożoność determinuje wydajność algorytmu pod względem czasu obliczeń i wymagań dotyczących pamięci.

• Flexibility - Elastyczność decyduje o tym, czy wybrany algorytm można odpowiednio zaimplementować bez utraty stosowności w różnych środowiskach.

• Understandability - To określa, czy wybrany algorytm jest łatwy do zrozumienia i wdrożenia.

Projektowanie relacji

Strategię implementacji relacji należy wyrysować na etapie projektowania obiektu. Główne relacje, które są uwzględniane, obejmują skojarzenia, agregacje i spadki.

Projektant powinien wykonać następujące czynności dotyczące skojarzeń -

• Określ, czy skojarzenie jest jednokierunkowe czy dwukierunkowe.

• Przeanalizuj ścieżkę skojarzeń i zaktualizuj je, jeśli to konieczne.

• Implementuj asocjacje jako odrębny obiekt, w przypadku relacji wiele-do-wielu; lub jako łącze do innego obiektu w przypadku relacji jeden do jednego lub jeden do wielu.

Jeśli chodzi o spadki, projektant powinien wykonać następujące czynności -

• Dostosuj klasy i ich skojarzenia.

• Zidentyfikuj klasy abstrakcyjne.

• Postaraj się, aby zachowania były udostępniane w razie potrzeby.

Wdrażanie kontroli

Projektant obiektów może wprowadzić udoskonalenia do strategii modelu wykresu stanu. W projektowaniu systemu tworzy się podstawową strategię realizacji modelu dynamicznego. Podczas projektowania obiektów strategia ta jest odpowiednio przystrojona do odpowiedniej implementacji.

Podejścia do implementacji modelu dynamicznego są następujące:

• Represent State as a Location within a Program- Jest to tradycyjne podejście oparte na procedurze, w którym lokalizacja kontroli określa stan programu. Maszyna skończonych stanów może zostać zaimplementowana jako program. Przejście tworzy instrukcję wejściową, główna ścieżka sterowania tworzy sekwencję instrukcji, gałęzie tworzą warunki, a ścieżki wstecz tworzą pętle lub iteracje.

• State Machine Engine- To podejście bezpośrednio reprezentuje automat stanowy poprzez klasę silnika automatu stanowego. Ta klasa wykonuje maszynę stanową za pomocą zestawu przejść i akcji udostępnianych przez aplikację.

• Control as Concurrent Tasks- W tym podejściu obiekt jest realizowany jako zadanie w języku programowania lub systemie operacyjnym. Tutaj zdarzenie jest realizowane jako wywołanie między zadaniami. Zachowuje nieodłączną współbieżność rzeczywistych obiektów.

Klasy opakowań

W każdym dużym projekcie ważne jest skrupulatne podzielenie implementacji na moduły lub pakiety. Podczas projektowania obiektów klasy i obiekty są grupowane w pakiety, aby umożliwić wielu grupom wspólną pracę nad projektem.

Różne aspekty pakowania to -

• Hiding Internal Information from Outside View - Pozwala na postrzeganie klasy jako „czarnej skrzynki” i pozwala na zmianę implementacji klasy bez konieczności modyfikowania kodu przez klientów klasy.

• Coherence of Elements - Element taki jak klasa, operacja czy moduł jest spójny, jeśli jest zorganizowany w spójny plan, a wszystkie jego części są ze sobą nierozerwalnie powiązane, tak aby służyły wspólnemu celowi.

• Construction of Physical Modules - Poniższe wskazówki pomagają przy konstruowaniu fizycznych modułów -

  • Klasy w module powinny reprezentować podobne rzeczy lub komponenty w tym samym obiekcie złożonym.

  • Ściśle połączone klasy powinny znajdować się w tym samym module.

  • Klasy niepodłączone lub słabo połączone należy umieścić w osobnych modułach.

  • Moduły powinny charakteryzować się dobrą spójnością, czyli wysoką współpracą między jego elementami.

  • Moduł powinien mieć niskie sprzężenie z innymi modułami, tj. Interakcja lub współzależność między modułami powinna być minimalna.

Optymalizacja projektu

Model analityczny przechwytuje logiczne informacje o systemie, podczas gdy model projektowy dodaje szczegóły, aby zapewnić skuteczny dostęp do informacji. Przed wdrożeniem projektu należy go zoptymalizować, aby wdrożenie było bardziej wydajne. Celem optymalizacji jest zminimalizowanie kosztów pod względem czasu, przestrzeni i innych wskaźników.

Jednak optymalizacja projektu nie powinna być przesadna, ponieważ łatwość implementacji, łatwość konserwacji i rozszerzalność są również ważnymi kwestiami. Często widać, że doskonale zoptymalizowany projekt jest bardziej wydajny, ale mniej czytelny i nadaje się do ponownego użycia. Dlatego projektant musi znaleźć równowagę między nimi.

Różne rzeczy, które można zrobić w celu optymalizacji projektu, to:

• Dodaj zbędne powiązania
• Pomiń nieprzydatne skojarzenia
• Optymalizacja algorytmów
• Zapisz atrybuty pochodne, aby uniknąć ponownego obliczania złożonych wyrażeń

Dodanie zbędnych skojarzeń

Podczas optymalizacji projektu sprawdza się, czy wyprowadzenie nowych skojarzeń może obniżyć koszty dostępu. Chociaż te zbędne skojarzenia mogą nie dodawać żadnych informacji, mogą zwiększyć wydajność całego modelu.

Pominięcie nieprzydatnych skojarzeń

Obecność zbyt wielu skojarzeń może spowodować, że system będzie nieczytelny, a tym samym zmniejszy ogólną wydajność systemu. Dlatego podczas optymalizacji wszystkie nieużyteczne skojarzenia są usuwane.

Optymalizacja algorytmów

W systemach zorientowanych obiektowo optymalizacja struktury danych i algorytmów odbywa się w sposób oparty na współpracy. Gdy projekt klasy jest już gotowy, operacje i algorytmy muszą zostać zoptymalizowane.

Optymalizację algorytmów uzyskuje się poprzez -

• Zmiana kolejności zadań obliczeniowych
• Odwrócenie kolejności wykonywania pętli od określonej w modelu funkcjonalnym
• Usuwanie martwych ścieżek w algorytmie

Zapisywanie i przechowywanie atrybutów pochodnych

Atrybuty pochodne to te atrybuty, których wartości są obliczane jako funkcja innych atrybutów (atrybutów podstawowych). Ponowne obliczanie wartości atrybutów pochodnych za każdym razem, gdy są potrzebne, jest procedurą czasochłonną. Aby tego uniknąć, wartości można obliczyć i zapisać w postaci wyliczonej.

Może to jednak powodować anomalie aktualizacji, tj. Zmianę wartości atrybutów podstawowych bez odpowiadającej im zmiany wartości atrybutów pochodnych. Aby tego uniknąć, podejmuje się następujące kroki -

• Przy każdej aktualizacji wartości atrybutu podstawowego, atrybut pochodny jest również ponownie obliczany.

• Wszystkie atrybuty pochodne są ponownie obliczane i aktualizowane okresowo w grupie, a nie po każdej aktualizacji.

Dokumentacja projektowa

Dokumentacja jest istotną częścią każdego procesu tworzenia oprogramowania, która rejestruje procedurę tworzenia oprogramowania. Decyzje projektowe muszą być udokumentowane dla każdego nietrywialnego systemu oprogramowania do przekazywania projektu innym osobom.

Obszary użytkowania

Chociaż jest to produkt drugorzędny, niezbędna jest dobra dokumentacja, szczególnie w następujących obszarach -

• Podczas projektowania oprogramowania, które jest rozwijane przez wielu programistów
• W iteracyjnych strategiach tworzenia oprogramowania
• Przy opracowywaniu kolejnych wersji projektu oprogramowania
• Do oceny oprogramowania
• Do znajdowania warunków i obszarów testowania
• Do konserwacji oprogramowania.

Zawartość

Korzystna dokumentacja powinna zasadniczo zawierać następującą treść -

• High–level system architecture - Diagramy procesów i schematy modułów

• Key abstractions and mechanisms - Diagramy klas i diagramy obiektów.

• Scenarios that illustrate the behavior of the main aspects - Diagramy behawioralne

funkcje

Cechy dobrej dokumentacji to -

• Zwięzłe, a jednocześnie jednoznaczne, spójne i kompletne

• Możliwość śledzenia zgodnie ze specyfikacjami wymagań systemu

• Well-structured

• Schematyczna zamiast opisowa