Podejście zorientowane obiektowo

W podejściu zorientowanym obiektowo nacisk kładzie się na ujęcie struktury i zachowania systemów informatycznych w małych modułach, które łączą zarówno dane, jak i proces. Głównym celem Object Oriented Design (OOD) jest poprawa jakości i produktywności analizy i projektowania systemu poprzez uczynienie go bardziej użytecznym.

W fazie analizy modele OO są używane do wypełnienia luki między problemem a rozwiązaniem. Sprawdza się dobrze w sytuacji, gdy systemy są poddawane ciągłemu projektowaniu, adaptacji i konserwacji. Identyfikuje obiekty w domenie problemowej, klasyfikując je pod względem danych i zachowania.

Model OO jest korzystny w następujący sposób -

Ułatwia zmiany w systemie niskim kosztem.
Promuje ponowne użycie komponentów.
Upraszcza problem integracji komponentów w celu skonfigurowania dużego systemu.
Upraszcza projektowanie systemów rozproszonych.

Elementy systemu obiektowego

Przejdźmy przez charakterystykę systemu OO -

Objects- Obiekt to coś, co istnieje w domenie problemu i można go zidentyfikować na podstawie danych (atrybutów) lub zachowania. Wszystkie podmioty materialne (student, pacjent) i niektóre niematerialne (konto bankowe) są modelowane jako obiekty.
Attributes - Opisują informacje o obiekcie.
Behavior- Określa, co obiekt może zrobić. Definiuje operacje wykonywane na obiektach.
Class- Klasa hermetyzuje dane i ich zachowanie. Obiekty o podobnym znaczeniu i przeznaczeniu zgrupowane razem jako klasa.
Methods- Metody określają zachowanie klasy. Nie są niczym innym jak działaniem, które może wykonać obiekt.
Message- Komunikat to wywołanie funkcji lub procedury z jednego obiektu do drugiego. Są to informacje wysyłane do obiektów w celu wyzwolenia metod. Zasadniczo komunikat to wywołanie funkcji lub procedury z jednego obiektu do drugiego.

Cechy systemu obiektowego

System zorientowany obiektowo ma kilka wspaniałych funkcji, które omówiono poniżej.

Kapsułkowanie

Hermetyzacja to proces ukrywania informacji. To po prostu połączenie procesu i danych w jedną całość. Dane obiektu są ukryte przed resztą systemu i dostępne tylko za pośrednictwem usług klasy. Pozwala na ulepszanie lub modyfikację metod używanych przez obiekty bez wpływu na inne części systemu.

Abstrakcja

Jest to proces wybierania lub wybierania niezbędnych metod i atrybutów do określenia obiektu. Skupia się na podstawowych cechach obiektu w odniesieniu do perspektywy użytkownika.

Relacje

Wszystkie klasy w systemie są ze sobą powiązane. Przedmioty nie istnieją w izolacji, istnieją w związku z innymi przedmiotami.

Istnieją trzy typy relacji między obiektami -

Aggregation - Wskazuje na związek między całością a jej częściami.
Association - W tym przypadku dwie klasy są ze sobą powiązane lub połączone w jakiś sposób, na przykład jedna klasa pracuje z drugą, aby wykonać zadanie, lub jedna klasa działa na inną klasę.
Generalization- Klasa podrzędna jest oparta na klasie nadrzędnej. Wskazuje, że dwie klasy są podobne, ale mają pewne różnice.

Dziedzictwo

Dziedziczenie to świetna funkcja, która pozwala na tworzenie podklas z istniejącej klasy poprzez dziedziczenie atrybutów i / lub operacji istniejących klas.

Polimorfizm i dynamiczne wiązanie

Polimorfizm to zdolność do przybierania wielu różnych form. Dotyczy to zarówno obiektów, jak i operacji. Obiekt polimorficzny to taki, którego typ prawdziwy ukrywa się w klasie nadrzędnej lub nadrzędnej.

W operacji polimorficznej operacja może być wykonywana w różny sposób przez różne klasy obiektów. Pozwala nam manipulować obiektami różnych klas, znając tylko ich wspólne właściwości.

Podejście strukturalne vs. Podejście zorientowane obiektowo

Poniższa tabela wyjaśnia, czym podejście zorientowane obiektowo różni się od tradycyjnego podejścia strukturalnego -

Podejście strukturalne	Podejście zorientowane obiektowo
Działa z podejściem odgórnym.	Działa z podejściem oddolnym.
Program jest podzielony na kilka podmodułów lub funkcji.	Program jest zorganizowany poprzez liczbę zajęć i obiektów.
Używane jest wywołanie funkcji.	Wykorzystywane jest przekazywanie wiadomości.
Ponowne użycie oprogramowania nie jest możliwe.	Możliwość ponownego wykorzystania.
Strukturalne programowanie projektowe zwykle pozostawiano do końcowych faz.	Programowanie projektowe zorientowane obiektowo wykonywane równolegle z innymi fazami.
Projektowanie strukturalne jest bardziej odpowiednie do offshoringu.	Nadaje się do rozwoju wewnętrznego.
Pokazuje wyraźne przejście od projektu do wdrożenia.	Niezbyt jasne przejście od projektu do wdrożenia.
Nadaje się do systemów czasu rzeczywistego, systemów wbudowanych i projektów, w których obiekty nie są najbardziej użytecznym poziomem abstrakcji.	Jest odpowiedni dla większości aplikacji biznesowych, projektów tworzenia gier, które mają zostać dostosowane lub rozszerzone.
Diagram DFD i ER modeluje dane.	Diagram klas, diagram sekwencji, diagram diagramu stanu i przypadki użycia - wszystkie one wnoszą swój wkład.
W ten sposób można łatwo zarządzać projektami dzięki jasno określonym fazom.	W tym podejściu projekty mogą być trudne do zarządzania ze względu na niepewne przejścia między fazami.

Język Unified Modeling Language (UML)

UML to język wizualny, który umożliwia modelowanie procesów, oprogramowania i systemów w celu wyrażenia projektu architektury systemu. Jest to standardowy język do projektowania i dokumentowania systemu w sposób obiektowy, który umożliwia architektom technicznym komunikację z programistą.

Jest zdefiniowany jako zestaw specyfikacji tworzonych i rozpowszechnianych przez Object Management Group. UML jest rozszerzalny i skalowalny.

Celem UML jest zapewnienie wspólnego słownictwa terminów obiektowych i technik tworzenia diagramów, które jest wystarczająco bogate, aby modelować każdy projekt rozwoju systemu, od analizy po implementację.

UML składa się z -

Diagrams - To obrazowe przedstawienie procesu, systemu lub jakiejś jego części.
Notations - Składa się z elementów, które współpracują ze sobą w schemacie, takich jak złącza, symbole, notatki itp.

Przykład notacji UML dla klasy

Notacja diagram instancji-UML

Operacje wykonywane na obiektach

Na obiektach wykonywane są następujące operacje -

Constructor/Destructor- Tworzenie nowych instancji klasy i usuwanie istniejących instancji klasy. Na przykład dodanie nowego pracownika.
Query- Dostęp do stanu bez zmiany wartości, nie ma skutków ubocznych. Na przykład znalezienie adresu konkretnego pracownika.
Update - Zmienia wartość jednego lub więcej atrybutów i wpływa na stan obiektu Na przykład zmiana adresu pracownika.

Zastosowania UML

UML jest bardzo przydatny do następujących celów -

Modelowanie procesu biznesowego
Opis architektury systemu
Pokazuje strukturę aplikacji
Przechwytywanie zachowania systemu
Modelowanie struktury danych
Budowanie szczegółowych specyfikacji systemu
Szkicowanie pomysłów
Generowanie kodu programu

Modele statyczne

Modele statyczne przedstawiają cechy strukturalne systemu, opisują jego strukturę i kładą nacisk na części, które składają się na system.

Służą do definiowania nazw klas, atrybutów, metod, podpisów i pakietów.
Diagramy UML, które reprezentują model statyczny, obejmują diagram klas, diagram obiektów i diagram przypadków użycia.

Modele dynamiczne

Modele dynamiczne pokazują behawioralne cechy systemu, tj. Sposób, w jaki system zachowuje się w odpowiedzi na zdarzenia zewnętrzne.

Modele dynamiczne identyfikują potrzebny obiekt i sposób, w jaki współpracują za pomocą metod i komunikatów.
Służą do projektowania logiki i zachowania systemu.
Diagramy UML reprezentują model dynamiczny, w tym diagram sekwencji, diagram komunikacji, diagram stanu, diagram aktywności.

Cykl życia rozwoju systemu zorientowanego obiektowo

Składa się z trzech procesów makro -

Analiza zorientowana obiektowo (OOA)
Projektowanie zorientowane obiektowo (OOD)
Implementacja obiektowa (OOI)

Działania związane z rozwojem systemów zorientowanych obiektowo

Rozwój systemów obiektowych obejmuje następujące etapy -

Analiza zorientowana obiektowo
Projektowanie zorientowane obiektowo
Prototyping
Implementation
Testowanie przyrostowe

Analiza zorientowana obiektowo

Ta faza dotyczy określenia wymagań systemowych i zrozumienia wymagań systemowych use-case model. Przypadek użycia to scenariusz opisujący interakcję między użytkownikiem a systemem komputerowym. Model ten przedstawia potrzeby użytkownika lub widok systemu przez użytkownika.

Obejmuje również identyfikację klas i ich relacji z innymi klasami w domenie problemowej, które składają się na aplikację.

Projektowanie zorientowane obiektowo

Celem tej fazy jest zaprojektowanie i udoskonalenie klas, atrybutów, metod i struktur, które są identyfikowane podczas fazy analizy, interfejsu użytkownika i dostępu do danych. Ta faza również identyfikuje i definiuje dodatkowe klasy lub obiekty, które obsługują implementację wymagania.

Prototypowanie

Prototypowanie pozwala w pełni zrozumieć, jak łatwe lub trudne będzie wdrożenie niektórych funkcji systemu.

Może również dać użytkownikom szansę skomentowania użyteczności i użyteczności projektu. Może dodatkowo zdefiniować przypadek użycia i znacznie ułatwić modelowanie przypadków użycia.

Realizacja

Wykorzystuje programowanie oparte na komponentach (CBD) lub szybkie opracowywanie aplikacji (RAD).

Rozwój oparty na komponentach (CBD)

CODD to uprzemysłowione podejście do procesu tworzenia oprogramowania przy użyciu różnych technologii, takich jak narzędzia CASE. Rozwój aplikacji przechodzi od tworzenia niestandardowego do montażu wstępnie zbudowanych, wstępnie przetestowanych i wielokrotnego użytku komponentów oprogramowania, które współpracują ze sobą. Programista CBD może łączyć komponenty, aby zbudować kompletny system oprogramowania.

Szybkie tworzenie aplikacji (RAD)

RAD to zestaw narzędzi i technik, których można użyć do zbudowania aplikacji szybciej niż jest to zwykle możliwe w przypadku tradycyjnych metod. Nie zastępuje SDLC, ale je uzupełnia, ponieważ koncentruje się bardziej na opisie procesu i można go doskonale połączyć z podejściem obiektowym.

Jego zadaniem jest szybkie zbudowanie aplikacji i stopniowa implementacja projektu wymagań użytkownika poprzez narzędzia takie jak Visual Basic, Power Builder itp.

Testowanie przyrostowe

Tworzenie oprogramowania i wszystkie jego działania, w tym testowanie, są procesem powtarzalnym. Dlatego może to być kosztowna sprawa, jeśli czekamy na testowanie produktu dopiero po jego całkowitym opracowaniu. Tutaj pojawia się testowanie przyrostowe, w którym produkt jest testowany na różnych etapach jego rozwoju.