Analiza i projektowanie obiektowe - Object-oriented analysis and design

Rozwój oprogramowania
Główne działania
Paradygmaty i modele
Metodologie i ramy
Dyscypliny wspierające
Praktyki
Przybory
Normy i zbiory wiedzy
Glosariusze
Wytyczne

Analiza i projektowanie zorientowane obiektowo ( OOAD ) to techniczne podejście do analizy i projektowania aplikacji, systemu lub biznesu poprzez zastosowanie programowania obiektowego , a także wykorzystanie modelowania wizualnego w całym procesie tworzenia oprogramowania w celu kierowania komunikacją z interesariuszami i jakością produktu.

OOAD w nowoczesnej inżynierii oprogramowania jest zwykle przeprowadzane w sposób iteracyjny i przyrostowy. Wynikiem działań OOAD są odpowiednio modele analityczne (dla OOA) i modele projektowe (dla OOD). Intencją jest, aby były one stale udoskonalane i ewoluowane w oparciu o kluczowe czynniki, takie jak ryzyko i wartość biznesowa.

Historia

We wczesnych dniach technologii obiektowej przed połową lat 90. istniało wiele różnych konkurencyjnych metodologii tworzenia oprogramowania i modelowania obiektowego , często powiązanych z określonymi dostawcami narzędzi do wspomaganej inżynierii oprogramowania (CASE). Brak standardowych notacji, spójnych terminów i wskazówek dotyczących procesu były wówczas głównymi problemami, co obniżyło wydajność komunikacji i wydłużyło krzywe uczenia się.

Niektóre z dobrze znanych wczesnych metodologii obiektowych zostały zainspirowane przez guru, takich jak Grady Booch , James Rumbaugh , Ivar Jacobson (The Three Amigos ), Robert Martin , Peter Coad , Sally Shlaer , Stephen Mellor i Rebecca Wirfs-Brock .

W 1994 roku Trzej Amigos z Rational Software rozpoczęli współpracę nad opracowaniem Unified Modeling Language (UML). Później, razem z Philippe Kruchtenem i Walkerem Roycem (najstarszym synem Winstona Royce'a ), poprowadzili udaną misję połączenia ich własnych metodologii, OMT , OOSE i metody Boocha , z różnymi spostrzeżeniami i doświadczeniami innych liderów branży w Rational Unified Process (RUP), kompleksowy przewodnik po iteracyjnych i przyrostowych procesach oraz ramy do nauki najlepszych praktyk branżowych w zakresie tworzenia oprogramowania i zarządzania projektami. Od tego czasu rodzina Unified Process stała się prawdopodobnie najpopularniejszą metodologią i modelem odniesienia dla analizy i projektowania obiektowego.

Przegląd

Cykl życia oprogramowania jest zwykle podzielony na etapy, od abstrakcyjnych opisów problemu do projektów, a następnie kodu i testowania, a na końcu do wdrożenia. Najwcześniejsze etapy tego procesu to analiza i projektowanie. Faza analizy jest często nazywana „pozyskiwaniem wymagań”.

Waterfall modelu .
OOAD jest przeprowadzane w sposób iteracyjny i przyrostowy, zgodnie z formułą ujednoliconego procesu .

W niektórych podejściach do tworzenia oprogramowania - zwanych łącznie modelami wodospadowymi - granice między poszczególnymi etapami mają być dość sztywne i sekwencyjne. Termin „wodospad” został ukuty dla takich metodologii, aby oznaczać, że postęp szedł sekwencyjnie tylko w jednym kierunku, tj. Po zakończeniu analizy, a dopiero potem rozpoczęto projektowanie, i rzadko (i uważano je za źródło błędu), gdy problem projektowy wymagały zmiany modelu analitycznego lub gdy problem z kodowaniem wymagał zmiany w projekcie.

Alternatywą dla modeli kaskadowych są modele iteracyjne. To wyróżnienie zostało spopularyzowane przez Barry'ego Boehma w bardzo wpływowym artykule na temat jego Spiral Model for iterative software development. Dzięki modelom iteracyjnym można równolegle pracować na różnych etapach modelu. Na przykład możliwe jest - i nie jest to postrzegane jako źródło błędów - praca nad analizą, projektowaniem, a nawet kodowaniem, wszystko tego samego dnia, a problemy z jednego etapu wpływają na problemy z innego. Nacisk na modele iteracyjne polega na tym, że tworzenie oprogramowania jest procesem wymagającym dużej wiedzy i że rzeczy takie jak analiza nie mogą być w pełni zrozumiane bez zrozumienia problemów projektowych, że problemy z kodowaniem mogą wpływać na projekt, że testowanie może dostarczyć informacji o tym, jak kod, a nawet projekt powinien zostać zmodyfikowany itp.

Chociaż możliwe jest tworzenie zorientowanych obiektowo przy użyciu modelu wodospadu, w praktyce większość systemów zorientowanych obiektowo jest opracowywana w sposób iteracyjny. W rezultacie w procesach zorientowanych obiektowo „analiza i projektowanie” są często uwzględniane w tym samym czasie.

Paradygmat obiektowy kładzie nacisk na modułowość i możliwość ponownego użycia. Celem podejścia zorientowanego obiektowo jest spełnienie zasady „otwarte - zamknięte” . Moduł jest otwarty, jeśli obsługuje rozszerzenie lub jeśli moduł zapewnia standardowe sposoby dodawania nowych zachowań lub opisywania nowych stanów. W paradygmacie zorientowanym obiektowo często osiąga się to poprzez utworzenie nowej podklasy istniejącej klasy. Moduł jest zamknięty, jeśli ma dobrze zdefiniowany stabilny interfejs, z którego muszą korzystać wszystkie inne moduły, i który ogranicza interakcję i potencjalne błędy, które mogą zostać wprowadzone do jednego modułu przez zmiany w innym. W paradygmacie zorientowanym obiektowo jest to osiągane poprzez definiowanie metod, które wywołują usługi na obiektach. Metody mogą być publiczne lub prywatne, tj. Pewne zachowania, które są unikalne dla obiektu, nie są narażone na działanie innych obiektów. Zmniejsza to źródło wielu typowych błędów w programowaniu komputerów.

Cykl życia oprogramowania jest zwykle podzielony na etapy, od abstrakcyjnych opisów problemu do projektów, a następnie kodu i testowania, a na końcu do wdrożenia. Najwcześniejsze etapy tego procesu to analiza i projektowanie. Rozróżnienie między analizą a projektowaniem jest często opisywane jako „co vs. jak”. W analityce programiści współpracują z użytkownikami i ekspertami dziedzinowymi, aby zdefiniować, co ma robić system. Szczegóły implementacji mają być w większości lub całkowicie (w zależności od metody) ignorowane na tym etapie. Celem fazy analizy jest stworzenie funkcjonalnego modelu systemu bez względu na ograniczenia takie jak odpowiednia technologia. W analizie zorientowanej obiektowo odbywa się to zazwyczaj poprzez przypadki użycia i abstrakcyjne definicje najważniejszych obiektów. Kolejna faza projektowania udoskonala model analityczny i dokonuje potrzebnej technologii oraz innych wyborów dotyczących implementacji. W projektowaniu obiektowym nacisk kładzie się na opisanie różnych obiektów, ich danych, zachowania i interakcji. Model projektowy powinien zawierać wszystkie wymagane szczegóły, aby programiści mogli zaimplementować projekt w kodzie.

Analiza zorientowana obiektowo

Celem każdej analizy w cyklu życia oprogramowania jest stworzenie modelu wymagań funkcjonalnych systemu, który jest niezależny od ograniczeń implementacyjnych.

Główna różnica między analizą obiektową a innymi formami analizy polega na tym, że w podejściu zorientowanym obiektowo organizujemy wymagania wokół obiektów, które integrują zarówno zachowania (procesy), jak i stany (dane) wzorowane na obiektach świata rzeczywistego, z którymi system oddziałuje. W innych lub tradycyjnych metodologiach analitycznych dwa aspekty: procesy i dane są rozpatrywane osobno. Na przykład dane mogą być modelowane za pomocą diagramów ER , a zachowania za pomocą schematów blokowych lub schematów strukturalnych .

Typowe modele używane w OOA to przypadki użycia i modele obiektowe . Przypadki użycia opisują scenariusze standardowych funkcji domeny, które system musi wykonać. Modele obiektów opisują nazwy, relacje klas (np. Circle jest podklasą Shape), operacje i właściwości głównych obiektów. Aby ułatwić zrozumienie, można również tworzyć makiety lub prototypy interfejsu użytkownika.

Projektowanie zorientowane obiektowo

Główny artykuł: Projektowanie obiektowe

Podczas projektowania zorientowanego obiektowo (OOD) programista stosuje ograniczenia implementacyjne do modelu koncepcyjnego utworzonego w analizie zorientowanej obiektowo. Takie ograniczenia mogą obejmować platformy sprzętowe i programowe , wymagania dotyczące wydajności, trwałe przechowywanie i transakcje, użyteczność systemu oraz ograniczenia narzucone przez budżet i czas. Pojęcia użyte w modelu analizy, która jest niezależna technologia, są mapowane na klasy i interfejsy wynikające w modelu domeny roztwór, czyli szczegółowy opis realizacji , jak system ma być zbudowany na konkretnych technologiach.

Ważne tematy podczas OOD obejmują również projektowanie architektur oprogramowania poprzez stosowanie wzorców architektonicznych i wzorców projektowych z zasadami projektowania zorientowanego obiektowo.

Modelowanie obiektowe

Główny artykuł: Modelowanie obiektowe

Modelowanie obiektowe (OOM) to typowe podejście do modelowania aplikacji, systemów i domen biznesowych przy użyciu paradygmatu zorientowanego obiektowo w całym cyklu życia oprogramowania . OOM jest główną techniką intensywnie wykorzystywaną zarówno w działaniach OOD, jak i OOA w nowoczesnej inżynierii oprogramowania.

Modelowanie obiektowe zazwyczaj dzieli się na dwa aspekty pracy: modelowanie dynamicznych zachowań, takich jak procesy biznesowe i przypadki użycia , oraz modelowanie struktur statycznych, takich jak klasy i komponenty. OOA i OOD to dwa odrębne poziomy abstrakcyjne (tj. Poziom analizy i poziom projektowania) podczas OOM. Unified Modeling Language (UML) i SysML są dwa popularne międzynarodowe języki standardowe stosowane do modelowania obiektowego.

Korzyści z OOM to:

Sprawna i skuteczna komunikacja

Użytkownicy zwykle mają trudności ze zrozumieniem obszernych dokumentów i kodów języków programowania. Diagramy modeli wizualnych mogą być bardziej zrozumiałe i mogą pozwolić użytkownikom i interesariuszom na przekazywanie programistom opinii na temat odpowiednich wymagań i struktury systemu. Kluczowym celem podejścia obiektowego jest zmniejszenie „luki semantycznej” między systemem a rzeczywistością oraz skonstruowanie systemu przy użyciu terminologii, która jest prawie taka sama, jakiej używają interesariusze w codziennym biznesie. Modelowanie zorientowane obiektowo jest podstawowym narzędziem ułatwiającym to.

Przydatna i stabilna abstrakcja

Modelowanie pomaga w kodowaniu. Celem większości nowoczesnych metodologii oprogramowania jest najpierw odpowiedzieć sobie na pytania „jakie”, a następnie odpowiedzieć na pytania „jak”, tj. Najpierw określić funkcjonalność, jaką ma zapewnić system bez uwzględnienia ograniczeń implementacyjnych, a następnie zastanowić się, jak wprowadzić konkretne rozwiązania do tych abstrakcyjnych wymagań i dopracuj je w szczegółowych projektach i kodach, uwzględniając ograniczenia, takie jak technologia i budżet. Modelowanie obiektowe umożliwia to poprzez tworzenie abstrakcyjnych i przystępnych opisów zarówno wymagań systemowych, jak i projektów, tj. Modeli, które definiują ich podstawowe struktury i zachowania, takie jak procesy i obiekty, które są ważnymi i cennymi zasobami programistycznymi o wyższym poziomie abstrakcji powyżej konkretnego i złożonego kodu źródłowego .

Zobacz też

Bibliografia

Dalsza lektura

  • Grady Booch . „Analiza i projektowanie zorientowane obiektowo z aplikacjami, wydanie trzecie”: http://www.informit.com/store/product.aspx?isbn=020189551X Addison-Wesley 2007.
  • Rebecca Wirfs-Brock , Brian Wilkerson, Lauren Wiener. Projektowanie oprogramowania zorientowanego obiektowo . Prentice Hall, 1990. [ Praktyczne wprowadzenie do programowania i projektowania obiektowego. ]
  • Teoria projektowania zorientowanego obiektowo : elementy składowe OOD i notacje do ich reprezentowania (z naciskiem na wzorce projektowe).
  • Martin Fowler . Wzorce analizy: modele obiektów wielokrotnego użytku . Addison-Wesley, 1997. [ Wprowadzenie do analizy obiektowej z modelami konceptualnymi ]
  • Bertrand Meyer . Konstrukcja oprogramowania zorientowana obiektowo . Prentice Hall, 1997
  • Craig Larman . Stosowanie UML i wzorców - wprowadzenie do OOA / D i rozwoju iteracyjnego . Prentice Hall PTR, wyd. 2005., mnnm, n, nnn
  • Setrag Khoshafian. Orientacja obiektowa .
  • Ulrich Norbisrath, Albert Zündorf, Ruben Jubeh. Modelowanie oparte na historii . Amazon Createspace. p. 333., 2013. ISBN   9781483949253 .

Linki zewnętrzne