Udostępnij za pośrednictwem

Modelowanie architektury aplikacji

  • Artykuł

Aby zapewnić, że system oprogramowania lub aplikacja spełnia potrzeby użytkowników, możesz utworzyć modele w programie Visual Studio w ramach opisu ogólnej struktury i zachowania systemu oprogramowania lub aplikacji. Za pomocą modeli można również opisać wzorce używane w całym projekcie. Te modele pomagają zrozumieć istniejącą architekturę, omówić zmiany i wyraźnie przekazać swoje intencje.

Aby sprawdzić, które wersje programu Visual Studio obsługują tę funkcję, zobacz Obsługa wersji dla narzędzi do architektury i modelowania.

Celem modelu jest zmniejszenie niejednoznaczności występujących w opisach języka naturalnego oraz ułatwienie tobie i współpracownikom wizualizowania projektu i omawiania alternatywnych projektów. Model powinien być używany razem z innymi dokumentami lub dyskusjami. Sam model nie reprezentuje pełnej specyfikacji architektury.

Uwaga

W tym temacie "system" oznacza tworzone oprogramowanie. Może to być duża kolekcja wielu składników oprogramowania i sprzętu lub jednej aplikacji lub części aplikacji.

Architekturę systemu można podzielić na dwa obszary:

  • Projekt wysokiego poziomu. W tym artykule opisano główne składniki i sposób interakcji ze sobą w celu spełnienia każdego wymagania. Jeśli system jest duży, każdy składnik może mieć własny projekt wysokiego poziomu, który pokazuje, jak składa się z mniejszych składników.

  • Wzorce projektowe i konwencje używane w projektach składników. Wzorzec opisuje konkretne podejście do osiągnięcia celu programowania. Korzystając z tych samych wzorców w całym projekcie, zespół może zmniejszyć koszty wprowadzania zmian i tworzenia nowego oprogramowania.

Projekt wysokiego poziomu

Projekt wysokiego poziomu opisuje główne składniki systemu i sposób interakcji ze sobą w celu osiągnięcia celów projektu. Działania na poniższej liście są zaangażowane w opracowywanie projektu wysokiego poziomu, chociaż niekoniecznie w określonej sekwencji.

Jeśli aktualizujesz istniejący kod, możesz zacząć od opisania głównych składników. Upewnij się, że rozumiesz wszelkie zmiany wymagań użytkownika, a następnie dodaj lub zmodyfikuj interakcje między składnikami. Jeśli tworzysz nowy system, zacznij od zrozumienia głównych funkcji potrzeb użytkowników. Następnie możesz eksplorować sekwencje interakcji dla głównych przypadków użycia, a następnie skonsolidować sekwencje w projekcie składników.

W każdym przypadku pomocne jest opracowanie różnych działań równolegle oraz opracowanie kodu i testów na wczesnym etapie. Unikaj próby wykonania jednego z tych aspektów przed rozpoczęciem innego. Zazwyczaj zarówno wymagania, jak i zrozumienie najlepszego sposobu projektowania systemu zmieni się podczas pisania i testowania kodu. Dlatego należy zacząć od zrozumienia i kodowania głównych funkcji wymagań i projektu. Wypełnij szczegóły w kolejnych iteracji projektu.

  • Opis wymagań. Punktem wyjścia każdego projektu jest jasne zrozumienie potrzeb użytkowników.

  • Wzorce architektoniczne. Dokonane wybory dotyczące podstawowych technologii i elementów architektury systemu.

  • Model danych składników i interfejsów. Diagramy klas można narysować, aby opisać informacje przekazywane między składnikami i przechowywane wewnątrz składników.

Opis wymagań

Ogólny projekt kompletnej aplikacji jest najbardziej efektywnie opracowywany wraz z modelem wymagań lub innym opisem potrzeb użytkowników. Aby uzyskać więcej informacji na temat modeli wymagań, zobacz Wymagania użytkownika modelu.

Jeśli opracowywany system jest składnikiem w większym systemie, część lub wszystkie wymagania mogą być wbudowane w interfejsy programowe.

Model wymagań zawiera następujące podstawowe informacje:

  • Udostępnione interfejsy. Udostępniony interfejs zawiera listę usług lub operacji, które system lub składnik musi zapewnić swoim użytkownikom, niezależnie od tego, czy są użytkownikami ludzkimi, czy innymi składnikami oprogramowania.

  • Wymagane interfejsy. Wymagany interfejs zawiera listę usług lub operacji, których może używać system lub składnik. W niektórych przypadkach będzie można zaprojektować wszystkie te usługi w ramach własnego systemu. W innych przypadkach, zwłaszcza jeśli projektujesz składnik, który może być połączony z innymi składnikami w wielu konfiguracjach, wymagany interfejs zostanie ustawiony przez zagadnienia zewnętrzne.

  • Wymagania dotyczące jakości usług. Wydajność, bezpieczeństwo, niezawodność i inne cele i ograniczenia, które muszą spełniać system.

    Model wymagań jest napisany z punktu widzenia użytkowników systemu, niezależnie od tego, czy są to ludzie, czy inne składniki oprogramowania. Nic nie wiedzą o wewnętrznych działaniach systemu. Natomiast twoim celem w modelu architektonicznym jest opisanie wewnętrznych elementów roboczych i pokazanie, jak spełniają potrzeby użytkowników.

    Oddzielenie wymagań i modeli architektonicznych jest przydatne, ponieważ ułatwia omówienie wymagań z użytkownikami. Pomaga również refaktoryzować projekt i rozważyć alternatywne architektury, zachowując jednocześnie niezmienione wymagania.

    Ilość szczegółów, które należy umieścić w wymaganiach lub modelu architektury, zależy od skali projektu oraz rozmiaru i rozkładu zespołu. Mały zespół w krótkim projekcie może pójść nie dalej niż szkicowanie diagramu klas pojęć biznesowych i niektórych wzorców projektowych; duży projekt rozproszony w więcej niż jednym regionie wymagałby znacznie większej szczegółowości.

Wzorce architektury

Na wczesnym etapie projektowania musisz wybrać główne technologie i elementy, od których zależy projekt. Obszary, w których należy dokonać tych wyborów, obejmują następujące elementy:

  • Podstawowe opcje technologiczne, takie jak wybór między bazą danych i systemem plików, a wybór między aplikacją sieciową a klientem internetowym itd.

  • Opcje struktury, takie jak wybór między programem Windows Workflow Foundation lub ADO.NET Entity Framework.

  • Opcje metody integracji, na przykład między magistralą usług przedsiębiorstwa lub kanałem punkt-punkt.

    Te opcje są często określane przez wymagania dotyczące jakości usług, takie jak skalowanie i elastyczność, i można je wykonać przed określeniem szczegółowych wymagań. W dużym systemie konfiguracja sprzętu i oprogramowania jest silnie powiązana.

    Wybrane opcje wpływają na sposób używania i interpretowania modelu architektury. Na przykład w systemie, który korzysta z bazy danych, skojarzenia w diagramie klasy mogą reprezentować relacje lub klucze obce w bazie danych, podczas gdy w systemie opartym na plikach XML skojarzenia mogą wskazywać odwołania krzyżowe używające programu XPath. W systemie rozproszonym komunikaty na diagramie sekwencji mogą reprezentować komunikaty w sieci; w aplikacji samodzielnej mogą reprezentować wywołania funkcji.

Wzorce projektowe

Wzorzec projektu to konspekt projektowania konkretnego aspektu oprogramowania, zwłaszcza taki, który powtarza się w różnych częściach systemu. Przyjmując jednolite podejście w projekcie, można zmniejszyć koszty projektowania, zapewnić spójność w interfejsie użytkownika oraz zmniejszyć koszty zrozumienia i zmiany kodu.

Niektóre ogólne wzorce projektowe, takie jak Observer, są dobrze znane i powszechnie stosowane. Ponadto istnieją wzorce, które mają zastosowanie tylko do projektu. Na przykład w systemie sprzedaży internetowej będzie kilka operacji w kodzie, w którym zmiany są wprowadzane do zamówienia klienta. Aby upewnić się, że stan zamówienia jest dokładnie wyświetlany na każdym etapie, wszystkie te operacje muszą postępować zgodnie z określonym protokołem w celu zaktualizowania bazy danych.

Częścią pracy architektury oprogramowania jest określenie, jakie wzorce należy zastosować w projekcie. Jest to zwykle ciągłe zadanie, ponieważ nowe wzorce i ulepszenia istniejących wzorców zostaną odnalezione w miarę postępu projektu. Warto zorganizować plan programowania, aby na wczesnym etapie wykonywać poszczególne główne wzorce projektowe.

Większość wzorców projektowych można częściowo uosabiać w kodzie struktury. Część wzorca można zmniejszyć, aby wymagać od dewelopera używania określonych klas lub składników, takich jak warstwa dostępu do bazy danych, która zapewnia prawidłowe obsługę bazy danych.

Wzorzec projektu jest opisany w dokumencie i zazwyczaj zawiera następujące części:

  • Name.

  • Opis kontekstu, w którym ma zastosowanie. Jakie kryteria należy wziąć pod uwagę podczas stosowania tego wzorca przez dewelopera?

  • Krótkie wyjaśnienie problemu, który rozwiązuje.

  • Model głównych części i ich relacji. Mogą to być klasy lub składniki i interfejsy, ze skojarzeniami i zależnościami między nimi. Elementy zwykle należą do dwóch kategorii:

  • Konwencje nazewnictwa.

  • Opis sposobu rozwiązywania problemu przez wzorzec.

  • Opis odmian, które deweloperzy mogą wdrożyć.

Powiązana zawartość