Kluczowe zasady
Architektura oprogramowania jest opisywana jako organizacja systemu, w którym system reprezentuje zbiór komponentów realizujących określone funkcje.
Styl architektoniczny
Plik architectural style, zwany także jako architectural pattern, to zbiór zasad kształtujących aplikację. Definiuje abstrakcyjne ramy dla rodziny systemów pod względem wzorca organizacji strukturalnej.
Styl architektoniczny odpowiada za -
Zapewnij leksykon komponentów i złączy wraz z zasadami ich łączenia.
Popraw partycjonowanie i zezwól na ponowne wykorzystanie projektu, dając rozwiązania często występujących problemów.
Opisz konkretny sposób konfiguracji zbioru komponentów (modułu z dobrze zdefiniowanymi interfejsami, wielokrotnego użytku i wymiennych) i łączników (łącze komunikacyjne między modułami).
Oprogramowanie stworzone dla systemów komputerowych prezentuje jeden z wielu stylów architektonicznych. Każdy styl opisuje kategorię systemu, która obejmuje -
Zestaw typów komponentów, które pełnią wymaganą funkcję przez system.
Zestaw łączników (wywołanie podprogramu, zdalne wywołanie procedury, strumień danych i gniazdo), które umożliwiają komunikację, koordynację i współpracę między różnymi komponentami.
Ograniczenia semantyczne, które definiują sposób integracji komponentów w celu utworzenia systemu.
Topologiczny układ komponentów wskazujący ich wzajemne relacje w czasie wykonywania.
Wspólny projekt architektoniczny
W poniższej tabeli wymieniono style architektoniczne, które można uporządkować według ich kluczowych obszarów zainteresowania -
| Kategoria | Styl architektoniczny | Opis |
|---|---|---|
| Komunikacja | Magistrala wiadomości | Zaleca użycie systemu oprogramowania, który może odbierać i wysyłać wiadomości przy użyciu jednego lub więcej kanałów komunikacji. |
| Architektura zorientowana na usługi (SOA) | Definiuje aplikacje, które udostępniają i wykorzystują funkcjonalność jako usługę przy użyciu umów i wiadomości. | |
| Rozlokowanie | Klient / serwer | Podziel system na dwie aplikacje, w których klient wysyła żądania do serwera. |
| 3-warstwowe lub N-warstwowe | Oddziela funkcje na osobne segmenty, przy czym każdy segment jest warstwą znajdującą się na fizycznie oddzielnym komputerze. | |
| Domena | Projektowanie oparte na domenie | Koncentruje się na modelowaniu domeny biznesowej i definiowaniu obiektów biznesowych na podstawie jednostek w domenie biznesowej. |
| Struktura | Oparte na komponentach | Podziel projekt aplikacji na funkcjonalne lub logiczne komponenty wielokrotnego użytku, które udostępniają dobrze zdefiniowane interfejsy komunikacyjne. |
| Warstwowy | Podziel uwagi aplikacji na ułożone w stosy grupy (warstwy). | |
| Zorientowany obiektowo | Na podstawie podziału obowiązków aplikacji lub systemu na obiekty, z których każdy zawiera dane i zachowanie właściwe dla obiektu. |
Rodzaje architektury
Z punktu widzenia przedsiębiorstwa istnieją cztery typy architektury, które łącznie określane są jako enterprise architecture.
Business architecture - Definiuje strategię biznesową, ład korporacyjny, organizację i kluczowe procesy biznesowe w przedsiębiorstwie i koncentruje się na analizie i projektowaniu procesów biznesowych.
Application (software) architecture - Służy jako plan dla poszczególnych systemów aplikacji, ich interakcji i relacji z procesami biznesowymi organizacji.
Information architecture - Definiuje logiczne i fizyczne zasoby danych oraz zasoby do zarządzania danymi.
Information technology (IT) architecture - Definiuje elementy składowe sprzętu i oprogramowania, które tworzą ogólny system informacyjny organizacji.
Proces projektowania architektury
Proces projektowania architektury koncentruje się na dekompozycji systemu na różne komponenty i ich interakcjach w celu spełnienia wymagań funkcjonalnych i niefunkcjonalnych. Kluczowe dane wejściowe do projektowania architektury oprogramowania to:
Wymagania generowane przez zadania analityczne.
Architektura sprzętu (architekt oprogramowania dostarcza z kolei wymagania architektowi systemu, który konfiguruje architekturę sprzętową).
Wynikiem lub wynikiem procesu projektowania architektury jest plik architectural description. Podstawowy proces projektowania architektury składa się z następujących kroków -
Zrozum problem
Jest to najważniejszy krok, ponieważ wpływa na jakość projektu, który następuje.
Bez jasnego zrozumienia problemu nie da się stworzyć skutecznego rozwiązania.
Wiele projektów i produktów oprogramowania jest uznawanych za niepowodzenia, ponieważ w rzeczywistości nie rozwiązały one ważnego problemu biznesowego lub nie mają rozpoznawalnego zwrotu z inwestycji (ROI).
Zidentyfikuj elementy projektu i ich relacje
Na tym etapie zbuduj podstawę do zdefiniowania granic i kontekstu systemu.
Rozkład systemu na główne komponenty w oparciu o wymagania funkcjonalne. Rozkład można zamodelować za pomocą macierzy struktury projektu (DSM), która pokazuje zależności między elementami projektu bez określania ziarnistości elementów.
Na tym etapie pierwsza weryfikacja architektury odbywa się poprzez opisanie wielu instancji systemu, a ten krok jest określany jako projekt architektoniczny oparty na funkcjonalności.
Oceń projekt architektury
Każdy atrybut jakości jest szacowany, więc w celu zebrania miar jakościowych lub danych ilościowych projekt jest oceniany.
Obejmuje ocenę architektury pod kątem zgodności z wymaganiami architektonicznymi atrybutów jakości.
Jeśli wszystkie szacunkowe atrybuty jakości są zgodne z wymaganym standardem, proces projektowania architektonicznego jest zakończony.
Jeśli nie, wkracza trzecia faza projektowania architektury oprogramowania: transformacja architektury. Jeśli obserwowany atrybut jakości nie spełnia jego wymagań, należy stworzyć nowy projekt.
Przekształć projekt architektury
Ten krok jest wykonywany po ocenie projektu architektonicznego. Projekt architektoniczny należy zmieniać, aż całkowicie spełni wymagania dotyczące atrybutów jakości.
Chodzi o dobór rozwiązań projektowych w celu poprawy atrybutów jakościowych przy jednoczesnym zachowaniu funkcjonalności domeny.
Projekt jest przekształcany przez zastosowanie operatorów projektu, stylów lub wzorów. W przypadku transformacji weź istniejący projekt i zastosuj operator projektu, taki jak dekompozycja, replikacja, kompresja, abstrakcja i udostępnianie zasobów.
Projekt jest ponownie oceniany iw razie potrzeby ten sam proces jest powtarzany wielokrotnie, a nawet wykonywany rekurencyjnie.
Transformacje (tj. Rozwiązania optymalizujące atrybut jakości) generalnie poprawiają jeden lub kilka atrybutów jakości, podczas gdy wpływają negatywnie na inne
Kluczowe zasady architektury
Poniżej przedstawiono kluczowe zasady, które należy wziąć pod uwagę podczas projektowania architektury -
Buduj, aby się zmienić, zamiast budować do końca
Zastanów się, jak aplikacja może wymagać zmian w czasie, aby sprostać nowym wymaganiom i wyzwaniom, i skorzystaj z elastyczności, aby to wspierać.
Zmniejsz ryzyko i model do analizy
Użyj narzędzi projektowych, wizualizacji, systemów modelowania, takich jak UML, aby uchwycić wymagania i decyzje projektowe. Można również przeanalizować wpływ. Nie należy formalizować modelu w stopniu, w jakim utrudnia to łatwe iterowanie i dostosowywanie projektu.
Używaj modeli i wizualizacji jako narzędzi do komunikacji i współpracy
Skuteczna komunikacja projektu, decyzji i bieżących zmian w projekcie ma kluczowe znaczenie dla dobrej architektury. Użyj modeli, widoków i innych wizualizacji architektury, aby skutecznie komunikować się i udostępniać projekt wszystkim interesariuszom. Umożliwia to szybkie przekazywanie zmian w projekcie.
Zidentyfikuj i zrozum kluczowe decyzje inżynieryjne i obszary, w których najczęściej popełniane są błędy. Zainwestuj w podejmowanie właściwych decyzji już za pierwszym razem, aby projekt był bardziej elastyczny i mniej podatny na zmiany w wyniku zmian.
Użyj podejścia przyrostowego i iteracyjnego
Zacznij od architektury bazowej, a następnie rozwijaj architektury kandydujące poprzez testowanie iteracyjne w celu ulepszenia architektury. Iteracyjnie dodawaj szczegóły do projektu w wielu przebiegach, aby uzyskać duży lub właściwy obraz, a następnie skup się na szczegółach.
Kluczowe zasady projektowania
Poniżej przedstawiono zasady projektowania, które należy wziąć pod uwagę, aby zminimalizować koszty, wymagania dotyczące konserwacji i zmaksymalizować możliwość rozbudowy, użyteczność architektury -
Rozdzielenie problemów
Podziel komponenty systemu na określone funkcje, tak aby nie zachodziły na siebie funkcje komponentów. Zapewni to wysoką spójność i niskie sprzężenie. Takie podejście pozwala uniknąć współzależności między elementami systemu, co pomaga w łatwym utrzymaniu systemu.
Zasada pojedynczej odpowiedzialności
Każdy moduł systemu powinien mieć jedną konkretną odpowiedzialność, co pomaga użytkownikowi w zrozumieniu systemu. Powinien również pomóc w integracji komponentu z innymi komponentami.
Zasada najmniejszej wiedzy
Żaden komponent lub obiekt nie powinien mieć wiedzy o wewnętrznych szczegółach innych komponentów. Takie podejście pozwala uniknąć współzależności i ułatwia konserwację.
Minimalizuj duży projekt z góry
Zminimalizuj duży projekt z góry, jeśli wymagania aplikacji są niejasne. Jeśli istnieje możliwość modyfikacji wymagań, unikaj tworzenia dużego projektu dla całego systemu.
Nie powtarzaj funkcji
Nie powtarzaj funkcjonalności określa, że funkcjonalność komponentów nie powinna się powtarzać i dlatego fragment kodu powinien być zaimplementowany tylko w jednym komponencie. Powielanie funkcjonalności w aplikacji może utrudniać wdrażanie zmian, zmniejszać przejrzystość i wprowadzać potencjalne niespójności.
Preferuj kompozycję zamiast dziedziczenia podczas ponownego korzystania z funkcji
Dziedziczenie tworzy zależność między klasami podrzędnymi i nadrzędnymi, a tym samym blokuje swobodne korzystanie z klas podrzędnych. Natomiast kompozycja zapewnia duży poziom swobody i redukuje hierarchie dziedziczenia.
Zidentyfikuj komponenty i pogrupuj je w warstwy logiczne
Elementy tożsamości i obszar zainteresowania, które są potrzebne w systemie, aby spełnić wymagania. Następnie pogrupuj te powiązane komponenty w warstwę logiczną, która pomoże użytkownikowi zrozumieć strukturę systemu na wysokim poziomie. Unikaj mieszania składników różnego rodzaju w tej samej warstwie.
Zdefiniuj protokół komunikacji między warstwami
Zrozum, w jaki sposób komponenty będą się ze sobą komunikować, co wymaga pełnej wiedzy na temat scenariuszy wdrażania i środowiska produkcyjnego.
Zdefiniuj format danych dla warstwy
Różne komponenty będą ze sobą współdziałać poprzez format danych. Nie mieszaj formatów danych, aby aplikacje były łatwe we wdrażaniu, rozszerzaniu i utrzymaniu. Staraj się zachować ten sam format danych dla warstwy, aby różne komponenty nie musiały kodować / dekodować danych podczas komunikacji między sobą. Zmniejsza narzut przetwarzania.
Składniki usług systemowych powinny być abstrakcyjne
Kod związany z bezpieczeństwem, komunikacją lub usługami systemowymi, takimi jak logowanie, profilowanie i konfiguracja, powinien być wyodrębniony w oddzielnych składnikach. Nie mieszaj tego kodu z logiką biznesową, ponieważ łatwo jest rozszerzyć projekt i utrzymać go.
Projektowanie wyjątków i mechanizm obsługi wyjątków
Zdefiniowanie wyjątków z wyprzedzeniem pomaga komponentom w elegancki sposób zarządzać błędami lub niepożądanymi sytuacjami. Zarządzanie wyjątkami będzie takie samo w całym systemie.
Konwencje nazewnictwa
Konwencje nazewnictwa należy wcześniej zdefiniować. Zapewniają spójny model, który pomaga użytkownikom łatwo zrozumieć system. Członkom zespołu łatwiej jest zweryfikować kod napisany przez innych, a tym samym zwiększy to łatwość utrzymania.