Projektowanie zorientowane obiektowo: definicja, zasady i przykłady

Projektowanie obiektowe to proces planowania systemu współdziałających obiektów w celu rozwiązania problemu programowego. Jest to jedno z podejść do projektowania zabezpieczeń.

Zawiera enkapsulowane dane i procedury zgrupowane razem w celu reprezentowania obiektu. Interfejs definiuje, jak mogą one współistnieć, a program opisuje interakcję zestawów. Projektowanie obiektowe jest dyscypliną definiowania obiektów i ich procesów w celu rozwiązania problemu, który został zidentyfikowany i udokumentowany w analizie.

Po tym następuje opis podzbioru opartego na klasach, który nie obejmuje prototypowych podejść do obiektów, gdzie te nie są zwykle uzyskiwane przez tworzenie instancji klas, ale przez klonowanie innych. Projektowanie to metodologia projektowania zorientowanego obiektowo. Obejmuje proces dekompozycji i notację do reprezentacji zarówno stanów logicznych i fizycznych, jak i modeli dynamicznych projektowanego systemu.

Tematy projektowe

Dane wejściowe do projektowania zorientowanego obiektowo są dostarczane przez wyniki analizy. Należy zrozumieć, że artefakt nie musi być w pełni rozwinięty, aby służyć jako punkt odniesienia. Analiza i projektowanie mogą przebiegać równolegle. W praktyce wyniki jednego działania mogą zasilać inne w krótkiej pętli sprzężenia zwrotnego poprzez proces iteracyjny. Zarówno pierwsza, jak i druga czynność może być wykonywana etapami, artefakty mogą być stale budowane, a nie opracowane w całości za jednym razem.

Niektóre typowe tematy

Zastanów się nad najważniejszymi.

1. Model koncepcyjny.

Wyniki analizy i projektowania obiektowego są objęte koncepcją w zakresie przedmiotu. Model koncepcyjny jest wyraźnie wybrany jako niezależny od szczegółów implementacji, takich jak współbieżność lub przechowywanie danych.

2. Przypadek użycia.

Opis sekwencji zdarzeń, które łącznie powodują, że system robi coś użytecznego. Każdy przypadek użycia dostarcza jeden lub więcej scenariuszy, które przekazują projekt systemu zorientowanego obiektowo. To ona musi wchodzić w interakcje z użytkownikami, zwanymi aktorami, aby osiągnąć określony cel biznesowy lub funkcję.

Instancjami wykonującymi precedens mogą być użytkownicy końcowi lub inne systemy. W wielu przypadkach możliwości zastosowania tej metody są dodatkowo rozwinięte w postaci diagramów. Diagramy precedensowe służą do zdefiniowania aktora i wykonywanych przez niego procesów. Więcej na ten temat można przeczytać w książce Grady`ego Boocha Object-Oriented Design.

3. Schemat sekwencji systemu.

Jest to reprezentacja pokazująca, dla danego scenariusza, przypadki użycia, które generują aktorzy zewnętrzni, ich kolejność i możliwe działania międzysystemowe.

4. Dokumentacja interfejsu użytkownika.

Dokument, który pokazuje i opisuje wygląd produktu końcowego. Ten element nie jest obowiązkowy, ale pomaga w wizualizacji, co ułatwia projektantowi.

Relacyjny model danych

Jest to abstrakcyjny prototyp, który opisuje, w jaki sposób informacja jest reprezentowana i konsumowana. Jeśli obiektowa baza danych nie jest używana, relacyjny model danych powinien być zwykle tworzony przed działaniem, ponieważ wybrana strategia akceptacji projektowania obiektowego jest wynikiem procesu.

Możliwe jest jednak równoległe rozwijanie relacyjnego modelu danych, a wzrost artefaktu może stymulować dopracowanie innych komponentów. Więcej na ten temat napisano również w książce Buch, Object-Oriented Analysis and Design. Zauważ, że w tym nowym wydaniu Grady Bucha znajdziesz wiele praktycznych wskazówek dotyczących analizy, implementacji, projektowania i zarządzania projektami.

Koncepcje

Pięć filarów projektowania obiektowego to funkcje na poziomie implementacji osadzone w język programowania. Często określa się je tymi potocznymi nazwami:

1. Klasa obiektów.

Czym są? Klasa to ścisły związek lub relacja struktur danych z metodami lub funkcjami, które na nie oddziałują (tworzy się z niej obiekt). Każdy obiekt pełni funkcję. Jest on zdefiniowany przez swoje właściwości. Obiekt może być częścią klasy, która jest zbiorem podobnych obiektów.

2. Ukrywanie projektowania obiektowego systemów informatycznych, to zdolność do ochrony pewnych elementów przed wpływami zewnętrznymi.

3. Dziedziczenie.

Jest to zdolność klasy do rozszerzenia lub nadpisania funkcjonalności innej grupy. Tak zwana podklasa posiada całą sekcję, która jest pochodną (dziedziczoną) od nadklasy, a także posiada własny zestaw funkcji i danych.

4. Interfejs (Wśród technik projektowania obiektowego wyróżnia się tzw. wzorce. Interface).

Możliwość odroczenia implementacji metod oraz możliwość definiowania funkcji bez ich implementacji.

5. Polimorfizm (w szczególności podtyp) - możliwość zastąpienia obiektu jego podobiektami. A także możliwość, aby zmienny obiekt zawierał nie tylko ten obiekt, ale wszystkie jego składniki.

Koncepcje projektowe

Definiowanie obiektów, tworzenie diagramu klas z postaci koncepcyjnej zwykle pokazuje.

Identyfikacja atrybutów.

Potrzeba stosowania szablonów z gamy technik projektowania obiektowego. To nie jest gotowy produkt, ale opis rozwiązania powszechnego problemu w kontekście. Główna korzyści z używania wzorca projektowego jest to, że może on być ponownie zastosowany w wielu aplikacjach. Jest on również brany pod uwagę przy rozwiązywanie problemów, które mogą wystąpić w wielu różnych sytuacjach. Obiektowe wzorce projektowe Gamma zazwyczaj pokazują relacje i interakcje między klasami lub obiektami bez określania końcowych systemów aplikacji lub obiektów, które są w nie zaangażowane.

Definicja ramowa.

Jest to zazwyczaj zestaw bibliotek lub klas, które służą do implementacji standardowej struktury aplikacji dla danego system operacyjny. Poprzez konsolidację dużej ilości kodu wielokrotnego użytku w platformie, programista oszczędza wiele czasu, rozwiązując problem przepisywania dużej ilości standardowego kodu dla każdej nowo tworzonej aplikacji.

Wyjście z projektowania zorientowanego obiektowo

Diagram sekwencji musi zostać rozwiązany, aby dodać konkretne obiekty obsługujące zdarzenia systemowe. Jako równoległe pionowe linie pokazuje różne procesy, które działają jednocześnie, a jako poziome strzałki wymianę wiadomości między nimi w kolejności, w jakiej się pojawiają.

Diagram klas - jest typem Statyczna struktura UML, która opisuje systemy poprzez pokazanie ich atrybutów i relacji między nimi. Wiadomości i klasy zidentyfikowane poprzez rozwój diagramów sekwencji mogą służyć jako dane wejściowe dla automatycznych generowanie systemu globalnego.

Niektóre zasady i strategie projektowania

Osadzanie zależności jest często używane. Jaka jest podstawowa idea? Jeśli jakiś przedmiot zależy od istnienia jakiejś innej instancji, to konieczny jest osadzony w zależnym. Przykład projektowania zorientowanego obiektowo: przekazanie połączenia z bazą danych jako argumentu do konstruktora, zamiast tworzenia go wewnętrznie. Inny przykład użycia wzorca mostu: oddzielenie abstrakcji od jej implementacji tak, aby oba przedmioty mogły być zmieniane niezależnie.

Rozważ zasady projektowania obiektowego zależności acyklicznych. Należy pamiętać, że graf składowy (stopień granulacji zależy od zakresu pracy) nie powinien mieć cykli. Jest to również nazywane skierowanym grafem acyklicznym. Przykład analizy i projektowania zorientowanego obiektowo: załóżmy, że C zależy od B, który podlega A. Jeśli ta ostatnia jest również związana z C, to powstanie pętla.

Jaka jest zasada ponownego wykorzystania kompozytu? Preferowana jest polimorficzna kompozycja dziedziczenia. Po fazie analizy model konceptualny jest dalej rozwijany w obiektowy projekt IS. Tutaj niezależne technologicznie koncepcje analizy są mapowane na klasy wykonawcze, identyfikowane są ograniczenia i opracowywane są interfejsy, w wyniku czego powstaje model dla domeny rozwiązania.

Kroki projektowania obiektowego IS można zdefiniować w następujący sposób:

• Znajdowanie kontekstu systemowego.
• Projektowanie jego architektury.
• Identyfikacja obiektów w systemie.
• Tworzenie układów konstrukcyjnych.
• Specyfikacja interfejsów obiektów.
• Projekt.

Projektowanie systemów zorientowanych obiektowo obejmuje identyfikację kontekstu systemu, po której następuje projektowanie architektury.

Pierwsza koncepcja

Kontekst systemu ma części statyczne i dynamiczne. Pierwszy z nich jest tworzony poprzez projektowanie obiektowe, z wykorzystaniem prostego schematu blokowego, który rozciąga się na hierarchię podsystemów. Model ten jest reprezentowany przez pakiety UML. Kontekst dynamiczny opisuje, jak system wchodzi w interakcje ze swoim środowiskiem. Modeluje się go za pomocą diagramów przypadków użycia.

Architektura systemu jest projektowana w oparciu o kontekst oraz zgodnie z zasadami projektowania i obszarem tematycznym. Generalnie system rozkłada się na warstwy, a te rozkładają się na podsystemy.

Czym jest dekompozycja zorientowana obiektowo? Dekompozycja oznacza podział dużego złożonego systemu na hierarchię mniejszych składników o mniejszej złożoności. Każda główna część nazywana jest podsystemem. Dekompozycja obiektowa identyfikuje poszczególne autonomiczne obiekty w systemie i relacje między nimi.

Korzyści płynące z rozkładu:

• Poszczególne komponenty mają mniejszą złożoność i dlatego są bardziej zrozumiałe i łatwiejsze w zarządzaniu.
• Następuje podział pracy z wyspecjalizowanymi umiejętnościami.
• Pozwala na wymianę lub modyfikację podsystemów bez wpływu na inne części.

Zidentyfikowany paralelizm

Pozwala wielu obiektom odbierać zdarzenia i wykonywać wiele akcji w tym samym czasie. Równoległość jest identyfikowana i reprezentowana w modelu dynamicznym.

Aby to umożliwić, do każdego elementu równoległego przypisany jest osobny przepływ sterowania. Jeśli równoległość jest na poziomie obiektu, to dwa symetryczne obiekty mają przypisane dwa różne wątki sterujące. Jeśli dwie operacje jednego z nich mają charakter równoległy, jest on rozdzielany pomiędzy różne wątki.

Z równoległością wiążą się problemy integralności danych i wzajemnego blokowania się. Oznacza to, że należy opracować jasną strategię, gdy wymagana jest równoległość. Ponadto musi być on zidentyfikowany na samym etapie rozwoju i nie może być pozostawiony na etapie wdrażania.

Techniki projektowania obiektowego, wzorce projektowe

Podczas tworzenia aplikacji przyjmuje się pewne wspólne rozwiązania dla pewnych kategorii problemów. Są to na przykład wzorce projektowe. Można go zdefiniować jako udokumentowany zestaw bloków konstrukcyjnych, które można wykorzystać w określonych zadaniach związanych z tworzeniem aplikacji.

Niektóre częste techniki projektowania obiektowego (wzorce projektowe) można znaleźć we wzorcach projektowych:

• Wzór elewacji.
• Model do dzielenia widoku.
• Wzorzec obserwatora.
• Typ sterownika.
• Proxy - wzór.
• Zarządzanie wydarzeniami.

Podczas projektowania wzorców systemu obiektowego należy zidentyfikować zdarzenia, które mogą wystąpić w obiektach i odpowiednio je obsłużyć.

Zdarzenie jest specyfikacją znaczącego zdarzenia, które ma swoją lokalizację w czas i przestrzeń. Istnieją cztery typy, które mogą być modelowane, a mianowicie:

• Sygnał - nazwany obiekt rzucony przez jednego i przechwycony przez drugiego.
• Zdarzenie wywołania - zdarzenie synchroniczne reprezentujące wysłanie operacji.
• Proces czasu jest reprezentowany w czasie.
• Zdarzenie zmiany - zdarzenia reprezentujące modyfikację stanu.

Warunki brzegowe przetwarzania

Faza projektowania powinna uwzględniać inicjację i zakończenie systemu jako całości, jak również każdego podsystemu. Różne aspekty:

• Uruchomienie, t. е. przejście ze stanu niezainicjowanego do stanu ustalonego.
• wyłączenie systemu, tj. е. zamknięcie wszystkich działających wątków, wyczyszczenie zasobów i wysłanie wiadomości.
• Konfiguracja początkowa i w razie potrzeby rekonfiguracja.
• Przewidywanie awarii lub niepożądanego zakończenia systemu.
• Warunki brzegowe są modelowane przy użyciu podobnych przypadków użycia.

Konstrukcja obiektu

Po opracowaniu hierarchii podsystemów identyfikuje się elementy systemu i projektuje ich szczegóły. W tym momencie etap biegu projektant. Nacisk przenosi się z obszaru tematycznego na koncepcje komputerowe. Obiekty zidentyfikowane podczas analizy są wstępnie wdrażane w celu zminimalizowania czasu wykonania, zużycia pamięci i ogólnych kosztów.

Projektowanie obiektu obejmuje następujące etapy:

• Identyfikacja.
• Przedstawicielstwo. Zbudowanie modeli projektowych.
• Klasyfikacja operacji.
• Algorytm projektowania.
• Projektowanie relacji.
• Sprawowanie kontroli nad interakcjami zewnętrznymi.
• Grupowanie klas i asocjacji w moduły.

Identyfikacja obiektów

Jest to pierwszy etap projektowania. Obiekty zidentyfikowane podczas analizy obiektowej są grupowane w klasy i udoskonalane tak, aby nadawały się do rzeczywistej implementacji.

Funkcje tego etapu:

• Identyfikacja i specyfikacja klas w każdym podsystemie lub pakiecie.
• Definiowanie relacji i skojarzeń między zbiorami.
• Rozwój hierarchii (generalizacja, specjalizacja i dziedziczenie).
• Projekt jednostki.

Reprezentacja obiektu

Po zidentyfikowaniu klas należy je wyświetlić za pomocą technik modelowania. Ten krok polega zasadniczo na budowie diagramów UML.

Istnieją dwa rodzaje wzorców projektowych, które należy wytworzyć:

Statyczny. Do jego opisu używa się diagramów klas i obiektów.

Modele dynamiczne. Diagramy interakcji i stanów służą do jego opisania i pokazania relacji między klasami.

Klasyfikacja operacji

W tym kroku zadania wykonywane na obiektach są definiowane poprzez połączenie trzech modeli: obiektowego, dynamicznego i funkcjonalnego. Operacja definiuje, który powinien być zrobione, nie jako.

W tym zakresie należy wykonać następujące zadania:

• Opracowany jest diagram przejść stanów każdego obiektu w systemie.
• Operacje są zdefiniowane dla zdarzeń otrzymywanych przez podmioty.
• Zidentyfikowane przypadki, w których jedno zdarzenie powoduje inne w tym samym lub innym obiekcie.
• Podoperacje w działaniach zdefiniowane.
• Podstawowe działania są rozszerzone na diagramy przepływu danych.

Projektowanie algorytmów

Operacje na obiektach są definiowane za pomocą sekwencji. Algorytm to procedura krok po kroku rozwiązująca problem podany w działaniu. Skupiają się na tym, jak należy to zrobić.

Może istnieć więcej niż jeden algorytm właściwy dla danej operacji. Po zidentyfikowaniu alternatywnych sekwencji wybiera się optymalną dla danej dziedziny problemu. Metryki wyboru algorytmów:

• Złożoność obliczeniowa. Określa efektywność algorytmu, w zakresie, czasu obliczeń i zapotrzebowania na pamięć.
• Elastyczność. Pojęcie to określa, czy wybrany algorytm może być poprawnie i bez utraty spójności zaimplementowany w różnych środowiskach.
• Klarowność. Wskazuje, czy wybrany algorytm jest łatwy do zrozumienia i wdrożenia.

Projektowanie relacji

Strategia powinna być spisana na etapie projektowania obiektu. Podstawowe relacje obejmują asocjacje, agregacje i dziedziczenie.

W zakresie skojarzeń projektant powinien wykonać następujące czynności:

• Określenie, czy relacja jest jedno- czy dwukierunkowa.
• Analizuj ścieżki stowarzyszeń i aktualizuj je w razie potrzeby.

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

• Konfiguracja klas i ich powiązań.
• Definiowanie systemów abstrakcyjnych.
• Stwórz warunki, aby w razie potrzeby można było wymieniać zachowania.

Kontrola ćwiczeń

Twórca obiektu może włączyć do strategii modelu statechart refinementy. W projekcie systemu zdefiniowana jest podstawowa dynamiczna polityka podmiotowa.

Podejścia do wdrażania modelu dynamicznego:

1. Przedstawić państwo jako miejsce w programie.

Jest to tradycyjne podejście oparte na procedurach, dzięki której Lokalizacja kontroli określa stan. Ostateczny automat może być zaimplementowany jako program. Przejście generuje instrukcję wejściową, główna ścieżka sterowania generuje sekwencję instrukcji, gałęzie tworzą warunki, a ścieżki wsteczne tworzą pętle lub iteracje.

2. Mechanizm automatów skończonych.

To podejście bezpośrednio reprezentuje termin poprzez jego klasę. Wykonuje automat skończony poprzez zestaw przejść i akcji dostarczonych przez aplikację.

3. Kontrola - zadania równoległe.

W tym podejściu obiekt jest implementowany jako zapytanie w języku programowania lub systemie operacyjnym. Tutaj zdarzenie jest zaimplementowane jako wywołanie krzyżowe, zachowując nieodłączną równoległość rzeczywistych obiektów.

Klasy opakowań

W każdym dużym projekcie ważne jest, aby starannie rozdzielić implementację na moduły lub pakiety. Klasy są grupowane razem podczas tworzenia obiektów, co pozwala na współpracę wielu stowarzyszeń.

Różne aspekty opakowań:

1. Ukrywanie informacji wewnętrznych przed widokiem zewnętrznym. Dzięki temu klasa może być postrzegana jako "czarna skrzynka", a zmiany w implementacji mogą być dokonywane bez konieczności modyfikowania kodu przez klientów.

2. Spójność elementów. Część (taka jak klasa, operacja lub moduł) jest powiązana, jeśli jest zorganizowana według spójnego planu i wszystkie jej części są nierozłączne, czyli służą wspólnemu celowi.

Podstawy budowy modułów fizycznych:

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

2. Klasy ściśle powiązane powinny znajdować się w jednym module, natomiast klasy niepowiązane lub luźno zgrupowane powinny być umieszczone w oddzielnych częściach.

3. Moduły powinny mieć wysoki poziom interakcji pomiędzy swoimi komponentami.

Optymalizacja projektu

Model analityczny gromadzi logiczne informacje o systemie, a komponent projektowy dodaje szczegóły, aby wspierać efektywny dostęp do nich. Program powinien być zoptymalizowany przed wdrożeniem, aby zwiększyć wydajność produkcji. Celem usprawnienia jest minimalizacja kosztów w kategoriach czasu, przestrzeni i innych metryk.

Jednak optymalizacja projektu nie powinna być nadmierna, ponieważ łatwość implementacji, łatwość utrzymania i rozszerzalność są również ważnymi kwestiami. W praktyce jest to wyraźnie widoczne. Programiści wiedzą, że idealnie zoptymalizowany projekt jest bardziej wydajny, ale mniej wielokrotnego użytku. Kreator musi więc znaleźć równowagę między tymi dwoma elementami.

Różne rzeczy, które możesz zrobić, aby go poprawić:

• Dodaj zbędne skojarzenia.
• Pominięcie nieużywanych skojarzeń.
• Optymalizacja algorytmów.
• Zachowaj atrybuty pochodne, aby uniknąć ponownego obliczania złożonych wyrażeń.

Przyjrzyjmy się bliżej niektórym punktom.

Dodaj zbędne skojarzenia.

Podczas optymalizacji projektu sprawdź, czy tworzenie nowych stowarzyszeń może zmniejszyć koszty dostępu. Chociaż te nadmiarowe skojarzenia mogą nie dodawać żadnych informacji, mogą one zwiększyć efektywność całego modelu.

Wyeliminowanie nieużywanych skojarzeń.

Posiadanie zbyt wielu skojarzeń może uczynić system niezrozumiałym i zmniejszyć ogólną wydajność. tzn. wszystkie nieużywane związki są usuwane podczas optymalizacji.

Poprawa algorytmów.

W systemach zorientowanych obiektowo struktura danych jest optymalizowana poprzez współpracę. Po stworzeniu projektu klasy należy poprawić operacje i algorytmy.

Optymalizację uzyskuje się poprzez:

• Zmiana kolejności zadań obliczeniowych.
• Zmiana kolejności pętli.
• Usuwanie martwych ścieżek w algorytmie.
• Zachowanie atrybutów pochodnych.