Techniki architektury

Podejście iteracyjne i przyrostowe

Jest to podejście iteracyjne i przyrostowe, składające się z pięciu głównych kroków, które pomaga w generowaniu kandydujących rozwiązań. To kandydujące rozwiązanie można dalej udoskonalać, powtarzając te kroki i ostatecznie tworząc projekt architektoniczny, który najlepiej pasuje do naszej aplikacji. Na koniec procesu możemy przejrzeć naszą architekturę i zakomunikować ją wszystkim zainteresowanym stronom.

To tylko jedno możliwe podejście. Istnieje wiele innych, bardziej formalnych podejść do definiowania, przeglądu i komunikowania architektury.

Zidentyfikuj cel architektury

Zidentyfikuj cel architektury, który tworzy architekturę i proces projektowania. Bezbłędne i zdefiniowane cele kładą nacisk na architekturę, rozwiązują właściwe problemy w projekcie i pomagają określić, kiedy bieżąca faza się zakończyła i jest gotowa do przejścia do następnej fazy.

Ten krok obejmuje następujące czynności -

• Na początku określ cele związane z architekturą.
• Zidentyfikuj konsumenta naszej architektury.
• Zidentyfikuj ograniczenia.

Przykłady działań związanych z architekturą obejmują tworzenie prototypu w celu uzyskania informacji zwrotnej na temat interfejsu użytkownika przetwarzania zamówień dla aplikacji sieci Web, tworzenie aplikacji do śledzenia zamówień klientów oraz projektowanie architektury uwierzytelniania i autoryzacji dla aplikacji w celu przeprowadzenia przeglądu bezpieczeństwa.

Kluczowe scenariusze

Ten krok kładzie nacisk na projekt, który ma największe znaczenie. Scenariusz to obszerny i obejmujący opis interakcji użytkownika z systemem.

Scenariusze kluczowe to te, które są uważane za najważniejsze scenariusze sukcesu Twojej aplikacji. Pomaga w podejmowaniu decyzji dotyczących architektury. Celem jest osiągnięcie równowagi między celami użytkownika, biznesowymi i systemowymi. Na przykład uwierzytelnianie użytkownika jest scenariuszem kluczowym, ponieważ jest to skrzyżowanie atrybutu jakości (zabezpieczenia) z ważną funkcjonalnością (sposobem logowania użytkownika do systemu).

Przegląd aplikacji

Zbuduj przegląd aplikacji, dzięki czemu architektura będzie bardziej dotykalna, łącząc ją z rzeczywistymi ograniczeniami i decyzjami. Składa się z następujących czynności -

Zidentyfikuj typ aplikacji

Zidentyfikuj typ aplikacji, niezależnie od tego, czy jest to aplikacja mobilna, bogaty klient, bogata aplikacja internetowa, usługa, aplikacja internetowa lub kombinacja tych typów.

Zidentyfikuj ograniczenia wdrażania

Wybierz odpowiednią topologię wdrażania i rozwiąż konflikty między aplikacją a infrastrukturą docelową.

Zidentyfikuj ważne style projektowania architektury

Zidentyfikuj ważne style projektowania architektury, takie jak klient / serwer, warstwowy, magistrala komunikatów, projekt oparty na domenie itp., Aby poprawić partycjonowanie i promować ponowne wykorzystanie projektu, zapewniając rozwiązania często powtarzających się problemów. Aplikacje często używają kombinacji stylów.

Zidentyfikuj odpowiednie technologie

Zidentyfikuj odpowiednie technologie, biorąc pod uwagę typ aplikacji, którą tworzymy, nasze preferowane opcje topologii wdrażania aplikacji i style architektoniczne. Wybór technologii będzie również zależał od polityki organizacji, ograniczeń infrastruktury, umiejętności zasobów i tak dalej.

Kluczowe problemy lub kluczowe punkty aktywne

Podczas projektowania aplikacji hotspoty to strefy, w których najczęściej popełniane są błędy. Zidentyfikuj kluczowe problemy na podstawie atrybutów jakości i zagadnień przekrojowych. Potencjalne problemy obejmują pojawienie się nowych technologii i krytycznych wymagań biznesowych.

Atrybuty jakości to ogólne cechy architektury, które wpływają na zachowanie w czasie wykonywania, projekt systemu i wrażenia użytkownika. Kwestie przekrojowe to cechy naszego projektu, które mogą dotyczyć wszystkich warstw, komponentów i poziomów.

Są to również obszary, w których najczęściej popełniane są poważne błędy projektowe. Przykładami problemów przekrojowych są uwierzytelnianie i autoryzacja, komunikacja, zarządzanie konfiguracją, zarządzanie wyjątkami i walidacja itp.

Rozwiązania kandydujące

Po zdefiniowaniu kluczowych punktów aktywnych zbuduj początkową architekturę podstawową lub pierwszy projekt wysokiego poziomu, a następnie zacznij wypełniać szczegóły, aby wygenerować architekturę kandydującą.

Kandydująca architektura obejmuje typ aplikacji, architekturę wdrażania, styl architektoniczny, wybór technologii, atrybuty jakości i zagadnienia przekrojowe. Jeśli architektura kandydata jest ulepszeniem, może stać się punktem odniesienia, na podstawie którego można tworzyć i testować nowe architektury kandydujące.

Sprawdź poprawność projektu rozwiązania kandydata pod kątem kluczowych scenariuszy i wymagań, które zostały już zdefiniowane, przed iteracyjnym wykonaniem cyklu i ulepszeniem projektu.

Możemy wykorzystać szpilki architektoniczne, aby odkryć określone obszary projektu lub zweryfikować nowe koncepcje. Skoki architektoniczne to prototypy projektowe, które określają wykonalność określonej ścieżki projektowej, zmniejszają ryzyko i szybko określają wykonalność różnych podejść. Testuj skoki architektoniczne pod kątem kluczowych scenariuszy i punktów aktywnych.

Przegląd architektury

Przegląd architektury jest najważniejszym zadaniem w celu zmniejszenia kosztów błędów oraz jak najszybszego znalezienia i rozwiązania problemów architektonicznych. Jest to ugruntowany, opłacalny sposób na zmniejszenie kosztów projektu i prawdopodobieństwa niepowodzenia projektu.

• Często przeglądaj architekturę na głównych etapach projektu oraz w odpowiedzi na inne znaczące zmiany architektoniczne.

• Głównym celem przeglądu architektury jest określenie wykonalności architektur bazowych i kandydujących, które prawidłowo weryfikują architekturę.

• Łączy wymagania funkcjonalne i cechy jakościowe z proponowanym rozwiązaniem technicznym. Pomaga również zidentyfikować problemy i rozpoznać obszary wymagające poprawy

Ewaluacje oparte na scenariuszach są dominującą metodą przeglądu projektu architektury, która koncentruje się na scenariuszach, które są najważniejsze z punktu widzenia biznesowego i które mają największy wpływ na architekturę.

Metoda analizy architektury oprogramowania (SAAM)

Pierwotnie był przeznaczony do oceny modyfikowalności, ale później został rozszerzony do przeglądu architektury pod kątem atrybutów jakości.

Metoda analizy kompromisów architektury (ATAM)

Jest to dopracowana i ulepszona wersja programu SAAM, który analizuje decyzje architektoniczne pod kątem wymagań dotyczących atrybutów jakości oraz tego, jak dobrze spełniają one określone cele jakościowe.

Active Design Review (ADR)

Najlepiej nadaje się do niekompletnych lub będących w toku architektur, które bardziej koncentrują się na zestawie problemów lub poszczególnych sekcji architektury naraz, niż na wykonywaniu ogólnego przeglądu.

Aktywne recenzje projektów pośrednich (ARID)

Łączy w sobie aspekt ADR polegający na przeglądaniu architektury będącej w toku z naciskiem na zestaw problemów oraz podejście ATAM i SAAM do przeglądu opartego na scenariuszach, koncentrującego się na atrybutach jakości.

Metoda analizy kosztów i korzyści (CBAM)

Koncentruje się na analizie kosztów, korzyści i skutków decyzji architektonicznych dotyczących harmonogramu.

Analiza zmian na poziomie architektury (ALMA)

Szacuje modyfikowalność architektury systemów informacji biznesowej (BIS).

Metoda oceny architektury rodzinnej (FAAM)

Szacuje architektury rodziny systemów informacyjnych pod kątem interoperacyjności i rozszerzalności.

Komunikowanie projektu architektury

Po ukończeniu projektu architektury musimy przekazać projekt innym interesariuszom, w tym zespołowi programistom, administratorom systemu, operatorom, właścicielom firm i innym zainteresowanym stronom.

Istnieje kilka dobrze znanych metod opisywania architektury innym: -

Model 4 + 1

To podejście wykorzystuje pięć widoków całej architektury. Wśród nich cztery widoki (pliklogical view, the process view, the physical view, i development view) opisują architekturę z różnych podejść. Piąty widok przedstawia scenariusze i przypadki użycia oprogramowania. Pozwala interesariuszom zobaczyć cechy architektury, które ich szczególnie interesują.

Język opisu architektury (ADL)

Podejście to służy do opisu architektury oprogramowania przed wdrożeniem systemu. Dotyczy następujących problemów - zachowanie, protokół i złącze.

Główną zaletą ADL jest to, że możemy przeanalizować architekturę pod kątem kompletności, spójności, niejednoznaczności i wydajności przed formalnym rozpoczęciem korzystania z projektu.

Modelowanie zwinne

To podejście jest zgodne z koncepcją, że „treść jest ważniejsza niż reprezentacja”. Zapewnia, że ​​utworzone modele są proste i łatwe do zrozumienia, wystarczająco dokładne, szczegółowe i spójne.

Dokumenty modelu Agile są skierowane do określonych klientów i realizują wysiłki tego klienta. Prostota dokumentu zapewnia aktywny udział interesariuszy w modelowaniu artefaktu.

IEEE 1471

IEEE 1471 to skrócona nazwa normy znanej formalnie jako ANSI / IEEE 1471-2000, „Zalecana praktyka dotycząca opisu architektury systemów intensywnie korzystających z oprogramowania”. IEEE 1471 wzbogaca treść opisu architektonicznego, w szczególności nadając określone znaczenie kontekstowi, widokom i punktom widzenia.

Język Unified Modeling Language (UML)

To podejście przedstawia trzy widoki modelu systemu. Plikfunctional requirements view (wymagania funkcjonalne systemu z punktu widzenia użytkownika, w tym przypadki użycia); the static structural view(obiekty, atrybuty, relacje i operacje, w tym diagramy klas); idynamic behavior view (współpraca między obiektami i zmiany stanu wewnętrznego obiektów, w tym diagramy sekwencji, aktywności i stanu).