Wprowadzenie do architektury i projektowania oprogramowania

Architektura systemu opisuje jego główne komponenty, ich relacje (struktury) oraz ich wzajemne interakcje. Architektura i projekt oprogramowania obejmuje kilka czynników, takich jak strategia biznesowa, atrybuty jakości, dynamika człowieka, projektowanie i środowisko IT.

Możemy podzielić architekturę oprogramowania i projekt na dwie odrębne fazy: architekturę oprogramowania i projektowanie oprogramowania. WArchitecturedecyzje niefunkcjonalne są rzucane i oddzielane przez wymagania funkcjonalne. W projekcie wymagania funkcjonalne są spełnione.

Architektura oprogramowania

Architektura służy jako blueprint for a system. Dostarcza abstrakcji do zarządzania złożonością systemu i ustanowienia mechanizmu komunikacji i koordynacji między komponentami.

Definiuje structured solution spełnienie wszystkich wymagań technicznych i operacyjnych, przy jednoczesnej optymalizacji wspólnych atrybutów jakości, takich jak wydajność i bezpieczeństwo.
Co więcej, wiąże się z zestawem ważnych decyzji dotyczących organizacji związanych z tworzeniem oprogramowania, a każda z tych decyzji może mieć znaczący wpływ na jakość, łatwość konserwacji, wydajność i ogólny sukces produktu końcowego. Decyzje te obejmują -
- Wybór elementów konstrukcyjnych i ich interfejsów, za pomocą których zbudowany jest system.
- Zachowanie określone we współpracy między tymi elementami.
- Skład tych elementów strukturalnych i behawioralnych w duży podsystem.
- Decyzje architektoniczne są zgodne z celami biznesowymi.
- Organizacją kierują się style architektoniczne.

Projektowanie Oprogramowania

Projekt oprogramowania zapewnia design planopisujący elementy systemu, ich dopasowanie i współpracę w celu spełnienia wymagań systemu. Cele posiadania planu projektu są następujące:

Negocjowanie wymagań systemowych i ustalanie oczekiwań z klientami, działem marketingu i personelem zarządzającym.
Działaj jako plan podczas procesu rozwoju.
Kieruj zadaniami wdrożeniowymi, w tym szczegółowym projektowaniem, kodowaniem, integracją i testowaniem.

Następuje przed szczegółowym projektem, kodowaniem, integracją i testowaniem, a także po analizie domeny, analizie wymagań i analizie ryzyka.

Cele architektury

Podstawowym celem architektury jest identyfikacja wymagań, które mają wpływ na strukturę aplikacji. Dobrze zaprojektowana architektura zmniejsza ryzyko biznesowe związane z budową rozwiązania technicznego i tworzy pomost między wymaganiami biznesowymi a technicznymi.

Niektóre z innych celów są następujące -

Wyeksponuj strukturę systemu, ale ukryj szczegóły jego implementacji.
Zrealizuj wszystkie przypadki użycia i scenariusze.
Spróbuj odpowiedzieć na wymagania różnych interesariuszy.
Spełniaj wymagania funkcjonalne i jakościowe.
Zmniejsz cel własności i popraw pozycję rynkową organizacji.
Popraw jakość i funkcjonalność oferowaną przez system.
Zwiększ zewnętrzne zaufanie do organizacji lub systemu.

Ograniczenia

Architektura oprogramowania jest wciąż rozwijającą się dyscypliną w inżynierii oprogramowania. Ma następujące ograniczenia -

Brak narzędzi i ustandaryzowanych sposobów przedstawiania architektury.
Brak metod analizy pozwalających przewidzieć, czy architektura będzie skutkować wdrożeniem spełniającym wymagania.
Brak świadomości znaczenia projektu architektonicznego dla tworzenia oprogramowania.
Brak zrozumienia roli architekta oprogramowania i słaba komunikacja między interesariuszami.
Brak zrozumienia procesu projektowania, doświadczenia projektowego i oceny projektu.

Rola architekta oprogramowania

Architekt oprogramowania zapewnia rozwiązanie, które zespół techniczny może stworzyć i zaprojektować dla całej aplikacji. Architekt oprogramowania powinien mieć doświadczenie w następujących obszarach -

Ekspertyza projektowa

Ekspert w projektowaniu oprogramowania, w tym różnych metod i podejść, takich jak projektowanie obiektowe, projektowanie sterowane zdarzeniami itp.
Kieruj zespołem programistów i koordynuj prace rozwojowe w celu zapewnienia integralności projektu.
Powinien móc przeglądać propozycje projektów i kompromis między sobą.

Ekspertyza domeny

Ekspert w zakresie opracowywanego systemu i planowania ewolucji oprogramowania.
Pomoc w procesie badania wymagań, zapewniając kompletność i spójność.
Koordynacja definicji modelu domeny dla tworzonego systemu.

Wiedza technologiczna

Ekspert w zakresie dostępnych technologii, który pomaga we wdrożeniu systemu.
Koordynuj wybór języka programowania, frameworka, platform, baz danych itp.

Ekspertyza metodologiczna

Ekspert w zakresie metodologii tworzenia oprogramowania, które mogą zostać przyjęte podczas SDLC (Software Development Life Cycle).
Wybierz odpowiednie podejście do rozwoju, które pomoże całemu zespołowi.

Ukryta rola architekta oprogramowania

Ułatwia pracę techniczną członków zespołu i wzmacnia zaufanie w zespole.
Informatyk, który dzieli się wiedzą i posiada duże doświadczenie.
Chroń członków zespołu przed siłami zewnętrznymi, które rozpraszają ich uwagę i wniosą mniejszą wartość do projektu.

Elementy dostarczane architekta

Jasny, kompletny, spójny i możliwy do osiągnięcia zestaw celów funkcjonalnych
Funkcjonalny opis systemu, z co najmniej dwoma warstwami rozkładu
Koncepcja systemu
Projekt w postaci układu z co najmniej dwiema warstwami rozkładu
Pojęcie harmonogramu, atrybutów operatora oraz planów wdrożenia i operacji
Przestrzegany jest dokument lub proces zapewniający rozkład funkcjonalny oraz kontrolowana jest forma interfejsów

Atrybuty jakości

Jakość jest miarą doskonałości lub stanu wolnego od braków lub wad. Atrybuty jakości to właściwości systemu, które są niezależne od funkcjonalności systemu.

Wdrożenie atrybutów jakości ułatwia odróżnienie dobrego systemu od złego. Atrybuty to ogólne czynniki wpływające na zachowanie w czasie wykonywania, projekt systemu i doświadczenie użytkownika.

Można je sklasyfikować jako -

Statyczne atrybuty jakości

Odzwierciedlaj strukturę systemu i organizacji, bezpośrednio związaną z architekturą, projektem i kodem źródłowym. Są niewidoczne dla użytkownika końcowego, ale wpływają na koszty rozwoju i utrzymania, np .: modułowość, testowalność, łatwość konserwacji itp.

Dynamiczne atrybuty jakości

Odzwierciedlaj zachowanie systemu podczas jego wykonywania. Są bezpośrednio związane z architekturą systemu, projektem, kodem źródłowym, konfiguracją, parametrami wdrażania, środowiskiem i platformą.

Są widoczne dla użytkownika końcowego i istnieją w czasie wykonywania, np. Przepustowość, niezawodność, skalowalność itp.

Scenariusze jakości

Scenariusze dotyczące jakości określają, jak zapobiegać przekształcaniu się usterki w awarię. Można je podzielić na sześć części na podstawie ich specyfikacji atrybutów -

Source - Jednostka wewnętrzna lub zewnętrzna, taka jak ludzie, sprzęt komputerowy, oprogramowanie lub infrastruktura fizyczna, która generuje bodziec.
Stimulus - Stan, który należy wziąć pod uwagę, gdy pojawi się w systemie.
Environment - Bodziec występuje w określonych warunkach.
Artifact - Cały system lub jego część, np. Procesory, kanały komunikacyjne, trwała pamięć masowa, procesy itp.
Response - Czynność podejmowana po nadejściu bodźca, taka jak wykrywanie usterek, odzyskiwanie po awarii, wyłączanie źródła zdarzenia itp.
Response measure - Powinien mierzyć pojawiające się odpowiedzi, aby można było przetestować wymagania.

Wspólne atrybuty jakości

Poniższa tabela zawiera typowe atrybuty jakości, które musi mieć architektura oprogramowania -

Kategoria	Atrybut jakości	Opis
Cechy konstrukcyjne	Integralność koncepcyjna	Definiuje spójność i spójność całego projektu. Obejmuje to sposób projektowania komponentów lub modułów.
	Konserwowalność	Zdolność systemu do łatwego wprowadzania zmian.
	Możliwość ponownego użycia	Definiuje zdolność komponentów i podsystemów do wykorzystania w innych aplikacjach.
Jakość w czasie rzeczywistym	Interoperacyjność	Zdolność systemu lub różnych systemów do skutecznego działania poprzez komunikację i wymianę informacji z innymi systemami zewnętrznymi napisanymi i obsługiwanymi przez podmioty zewnętrzne.
	Łatwość zarządzania	Określa, jak łatwo administratorzy systemu mogą zarządzać aplikacją.
	Niezawodność	Zdolność systemu do utrzymania działania w czasie.
	Skalowalność	Zdolność systemu do radzenia sobie ze wzrostem obciążenia bez wpływu na wydajność systemu lub możliwość łatwego powiększania.
	Bezpieczeństwo	Zdolność systemu do zapobiegania złośliwym lub przypadkowym działaniom poza przewidzianymi zastosowaniami.
	Wydajność	Wskazanie zdolności systemu do wykonania dowolnej czynności w zadanym przedziale czasu.
	Dostępność	Określa odsetek czasu, przez który system jest funkcjonalny i działa. Można go mierzyć jako procent całkowitego przestoju systemu w zdefiniowanym okresie.
Cechy systemu	Wsparcie	Zdolność systemu do dostarczania informacji pomocnych w identyfikowaniu i rozwiązywaniu problemów, gdy nie działa poprawnie.
Cechy systemu	Testowalność	Miara tego, jak łatwo jest stworzyć kryteria testowe dla systemu i jego komponentów.
Cechy użytkownika	Użyteczność	Określa, jak dobrze aplikacja spełnia wymagania użytkownika i konsumenta, będąc intuicyjną.
Jakość architektury	Poprawność	Odpowiedzialność za spełnienie wszystkich wymagań systemu.
Jakość non-runtime	Ruchliwość	Zdolność systemu do pracy w różnych środowiskach obliczeniowych.
	Integralność	Możliwość sprawienia, aby oddzielnie opracowane komponenty systemu działały poprawnie ze sobą.
	Modyfikowalność	Łatwość, z jaką każdy system oprogramowania może dostosowywać zmiany w swoim oprogramowaniu.
Atrybuty jakości biznesowej	Koszt i harmonogram	Koszt systemu w odniesieniu do czasu wprowadzenia go na rynek, oczekiwanego czasu życia projektu i wykorzystania starszej wersji.
Atrybuty jakości biznesowej	Zbywalność	Korzystanie z systemu w kontekście konkurencji rynkowej.