Architektura oparta na komponentach

Architektura oparta na komponentach skupia się na dekompozycji projektu na poszczególne komponenty funkcjonalne lub logiczne, które reprezentują dobrze zdefiniowane interfejsy komunikacyjne zawierające metody, zdarzenia i właściwości. Zapewnia wyższy poziom abstrakcji i dzieli problem na podproblemy, z których każdy jest powiązany z partycjami składowymi.

Podstawowym celem architektury opartej na komponentach jest zapewnienie component reusability. Komponent hermetyzuje funkcjonalność i zachowanie elementu oprogramowania w jednostce binarnej wielokrotnego użytku i samodzielnego wdrażania. Istnieje wiele standardowych struktur składowych, takich jak COM / DCOM, JavaBean, EJB, CORBA, .NET, usługi sieciowe i usługi gridowe. Technologie te są szeroko stosowane w projektowaniu lokalnych aplikacji GUI, takich jak graficzne komponenty JavaBean, komponenty MS ActiveX i komponenty COM, które można ponownie wykorzystać, po prostu przeciągając i upuszczając.

Projektowanie oprogramowania zorientowanego na komponenty ma wiele zalet w porównaniu z tradycyjnymi podejściami obiektowymi, takimi jak -

Skrócony czas na rynku i koszty rozwoju dzięki ponownemu wykorzystaniu istniejących komponentów.
Zwiększona niezawodność dzięki ponownemu wykorzystaniu istniejących komponentów.

Co to jest komponent?

Komponent to modułowy, przenośny, wymienny i wielokrotnego użytku zestaw dobrze zdefiniowanych funkcji, który zawiera jego implementację i eksportuje jako interfejs wyższego poziomu.

Komponent to obiekt oprogramowania, przeznaczony do interakcji z innymi komponentami, obejmujący określoną funkcjonalność lub zestaw funkcji. Ma wyraźnie zdefiniowany interfejs i jest zgodny z zalecanym zachowaniem, wspólnym dla wszystkich komponentów w architekturze.

Komponent oprogramowania można zdefiniować jako jednostkę kompozycji z interfejsem określonym w umowie i tylko jawnymi zależnościami kontekstowymi. Oznacza to, że komponent oprogramowania może być wdrażany niezależnie i podlega kompozycji stron trzecich.

Widoki komponentu

Komponent może mieć trzy różne widoki - widok obiektowy, widok konwencjonalny i widok związany z procesem.

Object-oriented view

Komponent jest postrzegany jako zbiór jednej lub więcej współpracujących klas. Każda klasa domeny problemu (analiza) i klasa infrastruktury (projekt) są wyjaśnione w celu zidentyfikowania wszystkich atrybutów i operacji, które mają zastosowanie do jej implementacji. Obejmuje również zdefiniowanie interfejsów, które umożliwiają klasom komunikację i współpracę.

Conventional view

Jest postrzegany jako element funkcjonalny lub moduł programu, który integruje logikę przetwarzania, wewnętrzne struktury danych wymagane do implementacji logiki przetwarzania oraz interfejs, który umożliwia wywołanie komponentu i przekazanie do niego danych.

Process-related view

W tym widoku, zamiast tworzyć każdy komponent od podstaw, system buduje z istniejących komponentów utrzymywanych w bibliotece. W trakcie formułowania architektury oprogramowania komponenty są wybierane z biblioteki i wykorzystywane do zapełnienia architektury.

Komponent interfejsu użytkownika (UI) obejmuje siatki, przyciski zwane kontrolkami, a komponenty narzędziowe udostępniają określony podzbiór funkcji używanych w innych komponentach.
Inne popularne typy komponentów to te, które wymagają dużej ilości zasobów, nie są często dostępne i muszą być aktywowane przy użyciu podejścia just-in-time (JIT).
Wiele komponentów jest niewidocznych, które są rozpowszechniane w aplikacjach biznesowych przedsiębiorstwa i aplikacjach internetowych, takich jak Enterprise JavaBean (EJB), komponenty .NET i komponenty CORBA.

Charakterystyka elementów

Reusability- Komponenty są zwykle zaprojektowane do ponownego wykorzystania w różnych sytuacjach w różnych zastosowaniach. Jednak niektóre komponenty mogą być zaprojektowane do określonego zadania.
Replaceable - Komponenty można dowolnie zastępować innymi podobnymi komponentami.
Not context specific - Komponenty są zaprojektowane do działania w różnych środowiskach i kontekstach.
Extensible - Komponent można rozszerzyć z istniejących komponentów, aby zapewnić nowe zachowanie.
Encapsulated - Komponent AA przedstawia interfejsy, które umożliwiają wywołującemu korzystanie z jego funkcjonalności i nie ujawniają szczegółów procesów wewnętrznych ani żadnych wewnętrznych zmiennych lub stanów.
Independent - Komponenty są zaprojektowane tak, aby mieć minimalne zależności od innych komponentów.

Zasady projektowania opartego na komponentach

Projekt na poziomie komponentu można przedstawić za pomocą reprezentacji pośredniej (np. Graficznej, tabelarycznej lub tekstowej), którą można przetłumaczyć na kod źródłowy. Projekt struktur danych, interfejsów i algorytmów powinien być zgodny z dobrze ugruntowanymi wytycznymi, aby pomóc nam uniknąć wprowadzania błędów.

System oprogramowania jest rozkładany na nadające się do wielokrotnego użytku, spójne i zamknięte w kapsułkach jednostki.
Każdy składnik ma własny interfejs, który określa wymagane porty i dostarczone porty; każdy komponent ukrywa swoją szczegółową implementację.
Komponent powinien zostać rozbudowany bez konieczności wprowadzania kodu wewnętrznego lub modyfikacji projektu istniejących części komponentu.
Składnik zależny od abstrakcji nie zależy od innych konkretnych składników, które zwiększają trudność w zbędności.
Łączniki łączy komponenty, określając i regulując interakcję między komponentami. Typ interakcji jest określony przez interfejsy komponentów.
Interakcja komponentów może przybrać formę wywołań metod, wywołań asynchronicznych, emisji, interakcji opartych na komunikatach, komunikacji strumieniowej danych i innych interakcji specyficznych dla protokołu.
W przypadku klasy serwerów należy utworzyć wyspecjalizowane interfejsy do obsługi głównych kategorii klientów. W interfejsie należy określić tylko te operacje, które są istotne dla określonej kategorii klientów.
Komponent może rozszerzać się na inne komponenty i nadal oferować własne punkty rozszerzeń. Jest to koncepcja architektury opartej na wtyczkach. Dzięki temu wtyczka może oferować inny interfejs API wtyczki.

Wytyczne dotyczące projektowania na poziomie komponentów

Tworzy konwencje nazewnictwa dla komponentów, które są określone jako część modelu architektonicznego, a następnie udoskonala lub rozwija jako część modelu na poziomie komponentów.

Pobiera nazwy komponentów architektonicznych z domeny problemu i zapewnia, że mają one znaczenie dla wszystkich interesariuszy, którzy przeglądają model architektoniczny.
Wyodrębnia jednostki procesu biznesowego, które mogą istnieć niezależnie, bez skojarzonej zależności od innych jednostek.
Rozpoznaje i odkrywa te niezależne jednostki jako nowe komponenty.
Używa nazw składników infrastruktury, które odzwierciedlają ich znaczenie specyficzne dla implementacji.
Modeluje wszelkie zależności od lewej do prawej i dziedziczenie od góry (klasa bazowa) do dołu (klasy pochodne).
Modeluj wszystkie zależności komponentów jako interfejsy, zamiast przedstawiać je jako bezpośrednią zależność między komponentami.

Przeprowadzanie projektowania na poziomie komponentów

Rozpoznaje wszystkie klasy projektowe, które odpowiadają domenie problemu zdefiniowanej w modelu analitycznym i modelu architektonicznym.

Rozpoznaje wszystkie klasy projektowe, które odpowiadają domenie infrastruktury.
Opisuje wszystkie klasy projektowe, które nie są nabywane jako komponenty wielokrotnego użytku, i określa szczegóły komunikatu.
Identyfikuje odpowiednie interfejsy dla każdego komponentu i opracowuje atrybuty oraz definiuje typy danych i struktury danych wymagane do ich wdrożenia.
Opisuje szczegółowo przepływ przetwarzania w ramach każdej operacji za pomocą pseudokodu lub diagramów aktywności UML.
Opisuje trwałe źródła danych (bazy danych i pliki) i identyfikuje klasy wymagane do zarządzania nimi.
Opracowuje i opracowuje reprezentacje behawioralne dla klasy lub komponentu. Można to zrobić, opracowując diagramy stanu UML utworzone dla modelu analitycznego i badając wszystkie przypadki użycia, które są istotne dla klasy projektu.
Opracowuje diagramy wdrażania, aby zapewnić dodatkowe szczegóły implementacji.
Pokazuje lokalizację pakietów kluczy lub klas komponentów w systemie przy użyciu instancji klas i wyznaczeniu określonego sprzętu i środowiska systemu operacyjnego.
Ostateczną decyzję można podjąć, stosując ustalone zasady i wytyczne projektowe. Doświadczeni projektanci rozważają wszystkie (lub większość) alternatywnych rozwiązań projektowych przed ustaleniem ostatecznego modelu projektowego.

Zalety

Ease of deployment - Wraz z pojawieniem się nowych kompatybilnych wersji łatwiej jest zastąpić istniejące wersje bez wpływu na inne komponenty lub system jako całość.
Reduced cost - Zastosowanie komponentów firm trzecich pozwala rozłożyć koszty rozwoju i utrzymania.
Ease of development - Komponenty implementują dobrze znane interfejsy w celu zapewnienia określonej funkcjonalności, umożliwiając rozwój bez wpływu na inne części systemu.
Reusable - Stosowanie komponentów wielokrotnego użytku oznacza, że można je wykorzystać do rozłożenia kosztów rozwoju i utrzymania na kilka aplikacji lub systemów.
Modification of technical complexity - Komponent modyfikuje złożoność poprzez użycie kontenera komponentów i jego usług.
Reliability - Ogólna niezawodność systemu wzrasta, ponieważ niezawodność każdego pojedynczego komponentu zwiększa niezawodność całego systemu poprzez ponowne użycie.
System maintenance and evolution - Łatwa zmiana i aktualizacja implementacji bez wpływu na resztę systemu.
Independent- Niezależność i elastyczna łączność komponentów. Niezależny rozwój komponentów przez różne grupy równolegle. Produktywność w zakresie tworzenia oprogramowania i przyszłego rozwoju oprogramowania.