Architektura systemu oprogramowania modelowania

Artykuł
03/12/2013

Aby zapewnić, że system oprogramowania lub aplikacji spełnia potrzeby użytkowników, można tworzyć modele w Visual Studio Ultimate jako część opisu ogólnej struktury i zachowanie systemu oprogramowania lub aplikacji.Przy użyciu modeli, można także opisać desenie, które są używane w procesie projektowania.Te modele pomóc Ci zrozumieć istniejącej architektury, omawianie zmian i wyraźnie komunikować swoje zamiary.

Celem modelu jest, aby zmniejszyć niejasności, które występują w języku naturalnym opisy i pomagające użytkownikowi i współpracowników do wizualizacji projektu i w celu przedyskutowania alternatywnych projektów.Model można używać wraz z innych dokumentów lub dyskusji.Przez siebie model nie reprezentuje pełną specyfikację architektury.

[!UWAGA]

W tym temacie "system" oznacza oprogramowanie, które tworzysz.To może być duży zbiór wielu składników sprzętowych i programowych, lub jedną aplikację lub część aplikacji.

Architektura systemu można podzielić na dwa obszary:

Projekt wysokiego poziomu.Opisuje główne składniki i ich wzajemne powiązania ze sobą w celu zaspokojenia każdego zapotrzebowania.Jeśli system jest duża, 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 stosowane w całym wzorów składników.Wzór opisuje sposób postępowania do osiągnięcia celu programowania.Za pomocą te same wzory przez cały projekt, zespół może zmniejszyć koszty wprowadzania zmian i tworzenia nowego oprogramowania.

Wysokiego poziomu projektu

Wysokiego poziomu projektu zawiera opis głównych składników systemu i jak współdziałają ze sobą w celu osiągnięcia celów projektu.Działania wymienione poniżej są zaangażowane w opracowywanie projektu wysokiego szczebla, chociaż niekoniecznie w określonej kolejności.

Jeśli aktualizujesz istniejący kod, może zacząć opisując głównych składników.Upewnij się, zrozumieć, wszelkie zmiany potrzeb użytkowników i następnie dodać lub zmodyfikować interakcje między składnikami.Jeśli tworzysz nowy system, Rozpocznij od opis głównych cech potrzeb użytkowników.Następnie zbadać sekwencji interakcje dla przypadków użycia głównego, a następnie skonsolidować sekwencji do projektowania składnika.

W każdym przypadku to jest przydatne, aby rozwijać różnych działań, równolegle i tworzenie kodu i analiz na wczesnym etapie.Należy unikać próbuje wypełnić jeden z tych aspektów, przed rozpoczęciem drugiego.Zazwyczaj wymagania i zrozumienie najlepszym sposobem, aby zaprojektować system zmieni podczas pisania i testują kod.W związku z tym należy rozpocząć zrozumienie i kodowanie główne cechy, wymagania i swój projekt.Wypełnij w kolejnych iteracji projektu.

Zrozumienie wymagań.Punktem wyjścia każdy wzór jest zrozumienie potrzeb użytkowników.
Wzorce architektoniczne.Wyborów dokonywanych przez użytkownika — informacje podstawowe technologie i elementy budowy systemu.
Składniki i ich interfejsom.Możesz narysować diagramy składników, aby pokazać głównych części systemu i wyświetla interfejsy, przez które współdziałają ze sobą.Interfejsy każdego składnika Dołącz wszystkie wiadomości, które wskazanego diagramy sekwencji.
Interakcje między składnikami.Dla każdego przypadku użycia, zdarzenia lub wiadomości przychodzących można narysować diagram sekwencji pokazujący współdziałania głównych składników systemu do osiągnięcia wymaganej reakcji.
Model danych składników i interfejsów.Możesz narysować diagramy klas opisujący informacje przekazywane między składnikami i zapisany w składniki.

Zrozumienie wymagań

Wysokiego poziomu projekt kompletnego wniosku jest najbardziej efektywny sposób rozwijany wraz z modelu wymagania lub inne informacje na temat potrzeb użytkowników.Aby uzyskać więcej informacji na temat modeli wymagania, zobacz Wymagania użytkownika modelowania.

Jeśli system, że w wypadku opracowywania jest składnikiem w układzie, część lub wszystkie wymagania mogą zostać zawarte w interfejsów programistycznych.

Model wymagania dostarcza tych zasadniczych rodzajów informacji:

Pod warunkiem interfejsów.Podany interfejs Wyświetla listę usług lub operacje, które układu lub części należy podać dla jego użytkowników, zarówno użytkowników i innych składników oprogramowania.
Wymaganych interfejsów.Wymagany interfejs Wyświetla listę usług lub operacje, które można użyć układu lub części.W niektórych przypadkach można zaprojektować wszystkich tych usług w ramach własnego systemu.W pozostałych przypadkach zwłaszcza w przypadku, gdy projektujesz składnik, który można łączyć z innymi składnikami w wielu konfiguracjach wymaganego interfejsu zostanie ustawiona ze względów zewnętrznych.
Jakość usługi.Wydajności, bezpieczeństwa, niezawodności i innych celów i ograniczeń, które muszą być spełnione przez system.

Model wymagania są zapisywane z punktu widzenia użytkowników systemu, zarówno osób jak i innymi składnikami oprogramowania.Nie wiedzą niczego wewnętrznych mechanizmów działania systemu.Z drugiej strony w modelu architektonicznego zadaniem gracza jest, aby opisać wewnętrznych mechanizmów działania i pokazać, jak spełniają one użytkowników potrzebuje.

Utrzymanie oddzielnych wymagań oraz modeli architektonicznych jest przydatna, ponieważ to sprawia, że łatwiej omawiać wymagania z użytkownikami.Pomaga także refaktoringu projektu i należy rozważyć alternatywne architektury, podczas gdy prowadzenie wymagania bez zmian.

Dwie alternatywne metody można dzielić wymagania i architektonicznych modeli:

Przechowywać w takie samo rozwiązanie, ale różnych projektów.Pojawią się one jako oddzielne modele w Eksploratorze modelu UML.Inni członkowie zespołów może pracować jednocześnie w modelach.Ograniczone rodzaje śledzenia mogą być tworzone między modelami.
Umieścić je w ten sam model UML, ale w różnych pakietach.Ułatwia to śledzenia zależności między modelami, ale uniemożliwia więcej niż jedna osoba naraz działanie na modelu.Ponadto bardzo dużym modelem będzie trwało dłużej, aby załadować do programu Visual Studio.To podejście jest zatem mniej korzystne dla dużych projektów.

Ilość szczegółów, które powinny się w wymagania lub model architektoniczny zależy od skali projektu oraz rozmiar i dystrybucyjnej zespołu.Małych zespołów w krótkim projektu może być słowa nie szkicowanie diagram klasy koncepcje biznesowe oraz niektóre wzorce projektowania; dużego projektu rozłożone w więcej niż jeden region, należy znacznie bardziej szczegółowo.

Wzorce architektoniczne

We wczesnej fazie rozwoju musisz wybrać główne technologie i elementów, od których zależy projekt.Następujące obszary, w których przeprowadza się tych opcji:

Podstawy Wybór technologii, takich jak wybór między bazy danych systemu plików i wybór między aplikację sieciową i klienta sieci Web i tak dalej.
RAM wyborów, takie jak wybór między Windows Workflow Foundation lub ADO.NET Entity Framework.
Wybór metody integracji, na przykład między magistralą usługi enterprise lub kanał typu punkt-punkt.

Te opcje są często określane przez jakość usługi takie jak skala i elastyczność i mogą być wykonane, aby szczegółowe wymagania są znane.W dużej ilości pamięci konfigurację sprzętu i oprogramowania są silnie ze sobą powiązane.

Opcjami wybranymi wpływa na sposób używania i interpretować model architektoniczny.Na przykład w systemie, który używa bazy danych, skojarzenia na diagramie klasy może reprezentować stosunków lub klucze obce w bazie danych, w systemie, który jest oparty na plikach XML, stowarzyszenia może wskazywać odsyłacze, które używa składni XPath.W systemie rozproszonym wiadomości w diagramie sekwencji może reprezentować wiadomości na drut; w samodzielna aplikacja reprezentują wywołań funkcji.

Składniki i ich interfejsom

Główne zalecenia w tej sekcji są następujące:

Umożliwia tworzenie diagramów składnika, aby pokazać głównych części systemu.
Narysuj zależności między składniki lub ich interfejsy, aby wyświetlić strukturę systemu.
Używać interfejsów na składowe pokazanie usług, że każdy składnik zawiera lub wymaga.
W dużych konstrukcji możesz narysować diagramy oddzielnych do rozkładu każdy składnik na mniejsze części.

Punkty te są opracowane w pozostałej części tej sekcji.

Składniki

Centralna widoki modelu architektury są diagramy składników, które pokazują głównych części systemu i jak są zależne od siebie nawzajem.Aby uzyskać więcej informacji na temat diagramy składników, zobacz Diagramy składników UML: odwołania.

Części wyświetlone diagram składników UML

Diagram składników typowe dla dużej ilości pamięci może zawierać składniki takie jak te:

Prezentacja.Składnik, który zapewnia dostęp do użytkownika, zwykle działających w przeglądarce sieci Web.
Składniki usługi sieci Web.Zapewnia połączenie między klientami i serwerami.
Być wyposażone w kontrolery sprawy.Prowadzi użytkownika przez kroki każdego scenariusza.
Podstawowa biznesowych.Zawiera klasy, które są oparte na klasach w modelu wymagania, implementuje operacji na kluczach i nakłada ograniczenia w zakresie działalności.
Baza danych.Służy do przechowywania obiektów biznesowych.
Rejestrowanie i składniki obsługi błędów.

Zależności między składnikami

Oprócz samych elementów można pokazać zależności między nimi.Strzałka zależność między dwoma składnikami pokazuje, że zmiany w projekcie jednej mogą mieć wpływ na projekt, z drugiej strony.Zazwyczaj dzieje się tak, ponieważ jeden składnik korzysta z usług lub funkcji, które są dostarczane przez inne części, bezpośrednio lub pośrednio.

Architektura dobrze rozbudowane ma Wyczyść układ zależności, w których te warunki są spełnione:

W wykres zależności nie ma żadnych pętli.
Składniki mogą być organizowane na warstwy, w których każdy zależność sięga od składnika w jednej warstwie składnik w następnego.Wszystkie zależności między dwóch warstw go w tym samym kierunku.

Można pokazać zależności bezpośrednio między składnikami, lub gdy mogą wykazać zależności między wymagane i przewidziane interfejsów, które są dołączone do składników.Za pomocą interfejsów, można zdefiniować, jakie operacje są używane w każdym zależność.Zazwyczaj wyświetlane są zależności między składnikami, gdy diagramy są pierwszy sporządzona, a następnie zastępuje zależności między interfejsami, po dodaniu więcej informacji.Obie wersje są poprawne opisy oprogramowania, ale wersja z interfejsami zapewnia bardziej precyzyjnie niż wcześniejszej wersji.

Zarządzanie zależności jest najbardziej istotne dla produkcji w utrzymaniu oprogramowania.Diagramy składników powinny odzwierciedlać wszystkie zależności w kodzie.Jeśli kod już istnieje, upewnij się, że wszystkie zależności są wyświetlane na wykresach.Jeśli kod jest rozwijany, upewnij się, że nie obejmuje zależności, które nie są planowane w diagram składników.Ułatwiające znalezienie zależności w kodzie, można wygenerować diagramy warstwy.Aby ułatwić zapewnienie spełniania Twoich kryteriów planowanych zależność, może sprawdzać poprawność kodu przeciwko diagramy warstwy.Aby uzyskać więcej informacji, zobacz Warstwy diagramów: odwołania.

Interfejsy

Umieszczając interfejsów na części, można rozdzielić i główne grupy działań, które zostały udostępnione przez każdy składnik o nazwie.Na przykład składniki w sieci web systemu sprzedaży może być interfejsem, dzięki któremu klienci zakupu towarów, interfejs za pomocą którego dostawcy zaktualizować ich katalogi i trzeciego interfejsu za pomocą którego system jest zarządzany.

Składnik może zawierać dowolną liczbę przewidzianych i wymaganych interfejsów.Pokaż usług, które danego składnika jest dostępna dla innych modułów w celu pod warunkiem interfejsów.Interfejsy wymagane Pokaż usługi używane przez składnik w innych składnikach.

W przypadku zdefiniowania oba dostarczone i wymaganych interfejsów, pomoże Ci to oddzielne składnika czysto od pozostałej części projektu, tak, że można użyć następujących technik:

Umieść składnik do wiązki testów, w którym elementów otoczenia są symulowane przez wiązki testów.
Rozwijanie składnika niezależnie od innych składników.
Ponownie wykorzystać składnik w innych kontekstach przez połączenie interfejsach do innych składników.

Umożliwia zdefiniowanie listy operacji w interfejsie, można utworzyć inny widok interfejsu na diagramie klasy UML.Aby to zrobić, zlokalizuj interfejsu w Eksploratorze modelu UML i przeciągnij go na diagram klasy.Następnie można dodać operacje do interfejsu.

Operację za pomocą interfejsu UML może reprezentować dowolny sposób, w którym można wywołać zachowanie składnika.Może ona przedstawić żądanie usługi sieci Web, sygnału lub interakcji innych świadczeń lub wywołanie funkcji zwykłego programu.

Aby ustalić, jakie operacje, aby dodać, należy utworzyć diagramy sekwencji, aby pokazać, jak wzajemną interakcję składników.Zobacz interakcje między składnikami.Każdy z tych diagramy sekwencji pokazuje wzajemne oddziaływania zachodzące, w przypadku użycia różnych.W ten sposób można stopniowo dodać do listy operacji w interfejsie każdego składnika, jak można poznać przypadkami użycia.

Rozkładu składnika na części

Można zastosować procedurę, którą opisano w poprzednich paragrafach na każdej części.

W ramach każdej części składowej jej składników podrzędnych można wyświetlić jako części.Część skutecznie jest atrybutem elementowi, który jest rodzajem klasy.Każda część ma swój własny typ, który może być elementem.Można umieścić ten składnik na diagramie i pokazać jego części.Aby uzyskać więcej informacji, zobacz Diagramy składników UML: wytyczne.

Warto zastosować tę technikę całego systemu.Rysowania go jako samodzielne części i pokazać jego główne części, jako części.Pomaga to jasno zidentyfikować interfejsów systemu ze światem zewnętrznym.

Gdy projekt dla składnika używa innego składnika, często jest taka możliwość o tym, czy do reprezentowania go w ramach lub jako oddzielny składnik, którego dostęp za pośrednictwem interfejsu wymaga.

Użyj części w następujących sytuacjach:

Projektowanie składnika nadrzędnego należy zawsze używać część homologację typu.W związku z tym Projekt części jest integralną częścią projektowania składnika nadrzędnego.
Składnik nadrzędny ma nie konkretnych istnienie własnej.Na przykład można mieć koncepcyjne składnik o nazwie warstwy prezentacji, która reprezentuje zbiór prawdziwe składników, które obsługują widoków i interakcji użytkownika.

Należy użyć oddzielnych składników udostępniane za pośrednictwem interfejsów wymagane w następujących sytuacjach:

Wymagające składnik może być połączony za pośrednictwem swoich interfejsów do różnych składników dostarczający w czasie wykonywania.
Projekt jest taka, że byłoby łatwo zastąpić inną jeden dostawca.

Korzystanie z wymaganych interfejsów jest zazwyczaj korzystniejsze zużycia części.Mimo, że projekt może trwać dłużej, ostatecznego systemu jest bardziej elastyczne.Jest również łatwiejsze do testów podzespołów oddzielnie.Dzięki temu mniej sprzęgu w swoich planach rozwoju.

Interakcje między składnikami

Główne zalecenia w tej sekcji są następujące:

Służy do identyfikowania przypadków użycia systemu.
W każdym przypadku użycia narysuj jeden lub więcej diagramów, aby pokazać, jak składnikami systemu osiągnięcia wyników wymaganych przez współpracę między sobą oraz z użytkownikami.Zazwyczaj są diagramy sekwencji lub diagramy aktywności.
Umożliwia określenie wiadomości odbierane przez każdy składnik interfejsów.
Opisać operacje w interfejsach.
Powtórz procedurę dla każdego składnika, pokazujący, jak oddziałują jego części.

Na przykład w sieci web systemu sprzedaży, modelu wymagania zdefiniować zakupu klienta jako przypadek użycia.Można utworzyć diagram sekwencji pokazać interakcje, że klient ma się ze składnikami w warstwy prezentacji i wykażą interakcji z magazynu i składniki obsługi kont.

Identyfikowania inicjujący zdarzeń

Prace wykonane przez większość systemów oprogramowania można wygodnie podzielone przez odpowiedzi, które daje do różnych danych wejściowych lub zdarzeń.W przypadku wszczęcia może być jedną z następujących zdarzeń:

Pierwsza akcja w przypadku użycia.Model wymagania może się pojawić jako krok w przypadku użycia lub akcja na diagramie aktywności.Aby uzyskać więcej informacji Diagramy przypadków użycia UML: wytyczne i Diagramy aktywności UML: wytyczne.
Wiadomość w interfejs programistyczny.Jeśli system, że w wypadku opracowywania jest składnikiem w układzie, powinny być opisane jako operacja w jednym z interfejsów składnika.Zobacz składniki i ich interfejsom.
Określony warunek, który jest monitorowana przez system lub wydarzeń takich jak porze dnia.

Opisz obliczeń

Narysuj diagramy sekwencji, aby pokazać, jak składniki zareagować na zdarzenie początkowe.

Narysuj kształt linia życia dla każdej instancji składnika, która bierze udział w typowej kolejności.W niektórych przypadkach może być więcej niż jedno wystąpienie każdego typu.Jeśli masz opisane całego systemu jako samodzielne części, powinno być jednej linii życia dla każdej części, którą zawiera.

Aby uzyskać więcej informacji, zobacz Diagramy sekwencji UML: wytyczne.

Diagramy aktywności są również przydatne w niektórych przypadkach.Na przykład jeśli składniki mają ciągły przepływ danych, można go opisać jako przepływ obiektu.Jeśli składnik ma skomplikowanego algorytmu, można go opisać jako przepływ sterowania.Upewnij się, aby było jasne, który składnik wykonuje akcję, na przykład za pomocą komentarzy.Aby uzyskać więcej informacji, zobacz Diagramy aktywności UML: wytyczne.

Określić operacje

Diagramy Pokaż operacje, które są wykonywane przez każdego składnika, albo reprezentowany, jak wiadomości na diagramie sekwencji lub akcji w diagramie aktywności.

Zebrać te operacje razem dla każdego składnika.Tworzyć interfejsy świadczone na składniku i dodać operacje do interfejsów.Zazwyczaj oddzielny interfejs jest używany dla każdego typu klienta.Operacje najłatwiej są dodawane do interfejsów w Eksploratora modelu UML.W ten sam sposób zbierania operacje, które używa każdego składnika z innymi składnikami i umieścić je w wymaganych interfejsów przytwierdzona do elementu.

Przydaje się dodać komentarze do diagramów aktywności lub sekwencję klatek, należy zwrócić uwagę, co zostało osiągnięte po każdej operacji.Można także napisać efekt każdej operacji w jego Lokalnego Postcondition właściwość.

Model danych składników i interfejsów

Służy do definiowania parametrów i zwracają wartości każdej operacji w interfejsów składników.Gdzie operacje stanowią wywołania, takich jak żądania usługi sieci Web, parametry są tych rodzajów informacji, które są wysyłane jako część żądania.W przypadku, gdy kilku wartości są zwracane z operacji, można używać parametrów z kierunek wartość właściwości równa się.

Każda wartość parametru i powrotu ma typu.Można zdefiniować tych typów za pomocą diagramów klas UML.Nie trzeba przedstawić szczegóły implementacji na schematach.Na przykład jeśli, które opisują dane przesyłane w formacie XML, można użyć skojarzenia w celu przedstawienia wszelkiego rodzaju odsyłacza między węzłami XML, a klasy służą do reprezentowania węzłów.

Komentarze służą do opisywania ograniczeń biznesowych stowarzyszeń i atrybuty.Na przykład jeśli wszystkie elementy na zamówienie klienta muszą pochodzić z tego samego dostawcę, aby opisać to w odniesieniu do związków między zamawianie towarów i zapasów w katalogu produktów oraz między element wykazu i jego dostawcy.

Wzorce projektowe

Wzorzec projektowania jest konspekt jak zaprojektować określonemu aspektowi oprogramowania, szczególnie takiej, która powtarza się w różnych częściach systemu.Poprzez przyjęcie jednolitego podejścia w projekcie, można zredukować koszty projektowania, zapewnienia spójności w interfejsie użytkownika i zredukować koszty rozumienia i zmiana kodu.

Pewne wzorce ogólne zasady projektowania, takie jak obserwatora są dobrze znanych i szeroko stosowane.Ponadto istnieją wzorców, które mają zastosowanie tylko do projektu.Na przykład w systemie sprzedaży w sieci Web będzie kilka operacji w kodzie gdzie zmian do zamówienia nabywcy.W celu zapewnienia, stan zamówienia jest wyświetlany poprawnie na każdym etapie, wszystkie te operacje należy wykonać konkretnego protokołu aktualizacji bazy danych.

Części prac architektury oprogramowania jest ustalenie, jakie wzory powinny być przyjęte w projekcie.Wynika to zazwyczaj proces ciągły, nowych wzorców i ulepszeń do istniejących wzorców, które mogą zostać odnalezione w miarę postępów projektu.Jest to przydatne do organizowania planu rozwoju, tak aby wykonywać każdy swoje wzorce głównych projektowe na wczesnym etapie.

Większość wzorach projektowych można częściowo zawarte w kodzie struktury.Część wzorca może być zmniejszona do domagania się od wykonawcy użyć poszczególnych klas lub składniki, takie jak warstwa dostępu do bazy danych, które zapewnia, że baza danych jest obsługiwana prawidłowo.

Wzorzec projektowania jest opisany w dokumencie, a zazwyczaj zawiera następujące segmenty:

Nazwa.
Opis kontekstu, w którym stosuje się.Jakie kryteria należy sporządzić programistą, należy rozważyć zastosowanie tego wzorca?
Krótkie wyjaśnienie, które rozwiązuje problem.
Model główne części i ich relacji.Mogą to być klasy lub składników i interfejsów, ze stowarzyszeniami i współzależności między nimi.Elementy są zazwyczaj podzielić na dwie kategorie:
- Elementy, które dewelopera musi zostać zreplikowane we wszystkich częściach kodu, w których używany jest wzorzec.Typy szablonów służy do opisywania tych.Aby uzyskać więcej informacji, zobacz Diagramy przypadków użycia UML: odwołania.
- Elementy opisujące framework klasy, które należy używać autora.
Model wzajemnego oddziaływania między części, za pomocą diagramy sekwencji lub działania.
Konwencje nazewnictwa.
Opis jak wzór rozwiązuje problem.
Opis odmiany, które deweloperzy mogą być zdolne do przyjęcia.