Udostępnij za pośrednictwem

Przegląd scenariusza: zmiana projektu z wykorzystaniem wizualizacji i modelowania

  • Artykuł

Aby upewnić się, że oprogramowanie systemu spełnia wymagania użytkowników, użyj narzędzi wizualizacji i modelowania w programie Visual Studio Ultimate ułatwiających aktualizowanie lub modyfikowanie projektu systemu.Do tych narzędzi należą diagramy UML (Unified Modeling Language), diagramy warstw, grafy zależności oparte na kodzie, diagramy sekwencji i diagramy klas.Na przykład można użyć tych narzędzi do wykonywania następujących zadań:

  • Wyjaśnij procesy biznesowe i wymagania użytkowników.

  • Wizualizacja i eksploracja istniejącego kodu.

  • Opisz zmiany w istniejącym systemie.

  • Sprawdź, czy system spełnia wymagania.

  • Zachowuj kod zgodny z projektem.

W tym instruktażu wykorzystano przykładowy scenariusz do osiągnięcia następujących celów:

  • Stwórz omówienie narzędzi i ich zalet dla projektu oprogramowania.

  • Pokaż, jak zespoły mogą używać tych narzędzi w przykładowym scenariuszu, niezależnie od ich podejścia do projektowania.

Aby uzyskać więcej informacji o tych narzędziach i scenariuszach, które wspierają, zobacz:

W tym temacie

Sekcja

Opis

Omówienie scenariusza

Opisuje scenariusz przykładowy i jego uczestników.

Role architektury i diagramów modelowania w tworzeniu oprogramowania

Opisuje role, które narzędzia te mogą pełnić podczas cyklu rozwoju oprogramowania.

Opis i przekazywaniu informacji o systemie

Zapewnia zaawansowane omówienie sposobu uczestników przy użyciu narzędzi w tym scenariuszu.

Aktualizowanie systemu przy użyciu wizualizacji i modelowania

Zapewnia więcej szczegółów dotyczących każdego z narzędzi i tego jak mogą być używane w tym scenariuszu.

Omówienie scenariusza

W tym scenariuszu opisano odcinki z cyklu rozwoju oprogramowania dwóch fikcyjnych spółek: Dinner Now i Lucerne Publishing.Dinner Now zapewnia na terenie Seattle usługę dostarczania posiłków opartą na sieci Web.Klienci mogą zamawiać posiłki i zapłacić za na stronie internetowej Dinner Now.Zamówienia są następnie wysyłane do odpowiedniej lokalnej restauracji w celu dostarczenia.Lucerna Publishing, firma w Nowym Jorku, prowadzi kilka działalności zarówno w sieci Web jak i poza siecią.Na przykład uruchamiają witryny sieci Web, na których klienci mogą ogłaszać opinie o restauracjach.

Lucerna niedawno nabyła Obiad teraz i chce wprowadzić następujące zmiany:

  • Integrowanie ich witryn sieci Web przez dodanie możliwości przeglądu restauracji na obiad teraz.

  • Zamień system płatności na system Lucerny.

  • Rozwijanie węzła usługi Dinner Now dla całego regionu.

Dinner Now używa SCRUM i eXtreme Programming.Firma ma bardzo wysokie pokrycie testu i bardzo mało nieobsługiwanego kodu.Firma minimalizuje ryzyko tworząc małe, ale działające wersje robocze systemu, a następnie stopniowo dodając nowe funkcje.Firma opracowuje swój kod w krótkich i częstych iteracjach.Dzięki temu mogą bez obaw radzić sobie ze zmianami, często refaktoryzować kod i unikać problemów związanych z dużymi projektami.

Lucerna zachowuje zdecydowanie większą i bardzien złożoną kolekcję systemów, z których niektóre mają więcej niż 40 lat.Firma zachowuje wyjątkową ostrożność, jeśli chodzi o wprowadzanie zmian, z powodu złożoności i zakresu starszego kodu.Firma ma rygorystyczny proces tworzenia oprogramowania, preferując projektowanie szczegółowych rozwiązań i dokumentowanie projektu oraz zmian, które występują podczas pracy.

Oba zespoły korzystają z diagramów modelowania w Visual Studio Ultimate, aby ułatwić opracowanie systemów spełniających potrzeby użytkowników.Używają programu Team Foundation Server wraz z innymi narzędziami, aby pomóc im w planowaniu ich pracy, organizowaniu jej i zarządzaniu nią.

Aby uzyskać więcej informacji na temat Team Foundation Server, zobacz:

  • Planowanie i śledzenie pracy

  • Testowanie, sprawdzanie poprawności i ewidencjonowanie kodu zaktualizowanego

Role architektury i diagramów modelowania w tworzeniu oprogramowania

W poniższej tabeli opisano role, jakie mogą pełnić te narzędzia na wielu różnych etapach cyklu tworzenia oprogramowania:

Modelowanie wymagań użytkowników

Modelowanie procesów biznesowych

Architektura i projekt systemu

Wizualizacja kodu & Badanie

Weryfikacja

Diagram przypadków użycia (UML)

√

√

√

Diagram aktywności (UML)

√

√

√

√

Diagram klas (UML)

√

√

√

√

Diagram składników (UML)

√

√

√

√

Diagram sekwencji (UML)

√

√

√

√

Diagram języka specyficznego dla domeny (DSL)

√

√

√

Diagram warstwy, sprawdzenie poprawności warstwy

√

√

√

Wykres zależności (w oparciu o kod)

√

√

√

Diagram sekwencji (oparty na kodzie)

√

√

Projektant klasy (oparty na kodzie)

√

Eksplorator architektury

√

Aby narysować diagramy UML i diagramy warstw, należy utworzyć projekt modelowania jako część nowego lub istniejącego rozwiązania.Te diagramy należy utworzyć w projekcie modelowania.Elementy na diagramach UML są częścią wspólnego wzoru a diagramy UML są widokami modelu.Elementy na diagramach są umieszczone w projekcie modelowania, ale nie są one przechowywane we wspólnym modelu.Oparte na kodzie wykresy zależności, diagramy sekwencji i diagramy klas zwykle istnieją poza projektem modelowania.

Zobacz:

Niektóre elementy w ramach tego samego modelu mogą być używane w wielu lub w różnych diagramach w celu pokazania alternatywnych widoków architektury.Na przykład można przeciągnąć składnik do innego diagramu składników lub diagramu sekwencji, tak że może działać jako aktor.Zobacz Edytowanie modeli i diagramów UML.

Oba zespoły korzystają również ze sprawdzania poprawności warstw, aby upewnić się, że opracowywany kod pozostaje zgodny z projektem.

Zobacz:

  • Zachowywanie kodu zgodnie z projektem

  • Opisz logiczną architekturę: diagramy warstw

  • Walidacja kodu przy użyciu diagramów warstwy

    [!UWAGA]

    Program Visual Studio Premium obsługuje sprawdzanie poprawności warstw i wersje tylko do odczytu tych wykresów i diagramów na potrzeby wizualizacji i modelowania.

Opis i przekazywaniu informacji o systemie

Nie ma żadnej zalecanej kolejności używania diagramów modelowania programu Visual Studio Ultimate, więc można ich używać stosownie do potrzeb lub podejścia.Zwykle zespoły wracają do swoich modeli wielokrotnie i często w ciągu całego projektu.Każdy diagram oferuje szczególne zalety, aby ułatwić zrozumienie, opisać i zakomunikować różne aspekty systemu w fazie projektowania.

Dinner Now i Lucerne komunikują się ze sobą i z udziałowcami projektu za pomocą diagramów oraz ich wspólnego języka.Na przykład firma Dinner Now używa diagramów do wykonywania następujących zadań:

  • Wizualizacja istniejącego kodu.

  • Komunikuj się z usługą Lucerne w kwestii nowych lub zaktualizowanych przypadków użycia.

  • Zidentyfikuj zmiany, które są wymagane do obsługi nowych lub zaktualizowanych przypadków użycia.

Lucerna używa diagramów do wykonywania następujących zadań:

  • Dowiedz się więcej teraz na temat procesu obiadu biznesowego.

  • Omówienie konstrukcji systemu.

  • Komunikuj się z usługą Dinner Now w kwestii nowych lub zaktualizowanych wymagań uzytkownika.

  • Dokumentowanie aktualizacji systemu.

Diagramy są zintegrowane z programem Team Foundation Server, więc zespoły mogą łatwiej planować swoją pracę, zarządzać nią i ją śledzić.Na przykład używają modeli do identyfikowania przypadków testowych i zadań programistycznych i do szacowania pracy.Lucerna łaczy elementy robocze Team Foundation Server z elementami modelu tak, że można monitorować postęp i upewnić się, że system spełnia wymagania użytkowników.Na przykład łączą przypadki użycia z elementami roboczymi przypadku testowego, tak aby można było zobaczyć, że przypadki użycia są spełnione, gdy wszystkie testy zostały zakończone pomyślnie.

Zanim zespoły zaewidencjonują zmiany, sprawdzają poprawność kodu w stosunku do testów i projektu uruchamiając kompilacje, które obejmują sprawdzanie poprawności warstwy i zautomatyzowane testy.Pomaga to upewnić się, że zaktualizowany kod nie jest w konflikcie z projektowaniem i przerwać wcześniej działające funkcje.

Zobacz:

  • Opis roli systemu w procesie biznesowym

  • Opisywanie nowych lub uaktualnionych wymagań użytkownika

  • Tworzenie testów z modeli

  • Identyfikowanie zmian w istniejącym systemie

  • Zachowywanie kodu zgodnie z projektem

  • Ogólne porady dotyczące tworzenia i używania modeli

  • Planowanie i śledzenie pracy

  • Testowanie, sprawdzanie poprawności i ewidencjonowanie kodu zaktualizowanego

Opis roli systemu w procesie biznesowym

Lucerna chce się dowiedzieć więcej na temat procesu biznesowego Obiad teraz.Firma tworzy następujące diagramy w celu jasnego przedstawienia jej ustaleń z firmą Dinner Now:

Diagram

Opisuje

Diagram przypadków użycia (UML)

Zobacz:

  • Działania, które obsługuje system firmy Dinner Now

  • Osoby i systemy zewnętrzne, które wykonują działania

  • Główne składniki systemu obsługujące każde działanie

  • Części procesu biznesowego, które są poza zakresem bieżącego systemu, na przykład dostawy żywności

Diagram aktywności (UML)

Zobacz:

Przepływ kroków, które występują, gdy klient tworzy zamówienie

Diagram klas (UML)

Zobacz:

Podmioty gospodarcze i warunki, które są używane w dyskusji, oraz relacje między tymi jednostkami.Na przykład Zamówienie i Element menu są częścią słownictwa w tym scenariuszu.

Na przykład Lucerne tworzy poniższy diagram przypadków użycia, aby zrozumieć zadania, które są wykonywane na stronie internetowej firmy Dinner Now, i kto je wykonuje:

Diagram przypadków użycia UML

Diagram przypadków użycia UML

Poniższy diagram aktywności opisuje przepływ kroków, gdy klient tworzy zamówienie na stronie firmy Dinner Now w sieci Web.W tej wersji elementy komentarza określenie role i tworzą linie torów, które organizują etapy poprzez role:

Diagram aktywności UML

Diagram aktywności UML

Następujący diagram klas opisuje jednostki, które uczestniczą w procesie przetwarzania zamówień:

Diagram klas UML

Diagram klas UML

Opisywanie nowych lub uaktualnionych wymagań użytkownika

Lucerna chce zwiększającymi funkcjonalność systemu Obiad teraz tak, aby klienci mogli odczytywać opinie i dodawać opinie o restauracji.Aktualizuje następujące diagramy, dzięki czemu może opisać i omówić ten nowy wymóg z firmą Dinner Now:

Diagram

Opisuje

Diagram przypadków użycia (UML)

Zobacz:

Nowy przypadek użycia dla "Napisz recenzję restauracji"

Diagram aktywności (UML)

Zobacz:

Kroki, które występują, gdy klient chce napisać recenzję restauracji

Diagram klas (UML)

Zobacz:

Dane, które są wymagane, do przechowywania przeglądu

Na przykład poniższy diagram przypadków użycia zawiera nowy przypadek użycia „Napisz recenzję”, który reprezentuje nowe wymaganie.Jest wyróżniany kolorem pomarańczowym na diagramie w celu łatwiejszej identyfikacji:

Diagram przypadków użycia UML

Diagram przypadków użycia UML

Następujący diagram aktywności zawiera nowe elementy w kolorze pomarańczowym i opisuje przepływ kroków w nowym przypadku użycia:

Diagram aktywności UML

Diagram aktywności UML

Poniższy diagram klas zawiera nową klasę Review i jej relacje z innymi klasami, aby zespoły mogły omawiać jej szczegóły.Należy zauważyć, że klient i restauracja mogą mieć wiele opinii:

Diagram klas UML

Diagram klas UML

Tworzenie testów z modeli

Oba zespoły zgadzają się, że potrzebują przeprowadzić zestaw testów systemu i jego składników, zanim wprowadzą jakiekolwiek zmiany.Lucerna ma wyspecjalizowany zespół wykonujący system i testowanie poziomu składnika.Ponownie wykorzystuje on testy utworzone przez firmę Dinner Now i nadaje im strukturę za pomocą diagramów UML:

  • Każdy przypadek użycia jest reprezentowany przez jeden lub wiele testów.Elementy na diagramie przypadków użycia łączą się z elementami roboczymi Przypadek testowy w programie Team Foundation Server.

  • Każdy przepływ na diagramie aktywności lub systemowym diagramie sekwencji jest połączony co najmniej z jednym testem.Zespół testowy systematycznie sprawdza, czy przetestował wszystkie możliwe ścieżki, za pomocą diagramu aktywności.

  • Terminy używane do opisu testów są oparte na warunkach określonych przez diagramy przypadków użycia, klas i aktywności.

Zmieniają się wymagania, diagramy są aktualizowane, aby odzwierciedlać zmiany, więc również testy również są aktualizowane.Wymóg jest uważany za spełniony tylko wtedy, gdy testy zakończą się pomyślnie.Gdy jest to możliwe lub praktyczne, badania są określone i oparte na diagramach UML przed rozpoczęciem implementacji.

Zobacz:

Identyfikowanie zmian w istniejącym systemie

Dinner Now musi oszacować koszty realizacji nowego wymagania.Zależy to częściowo od tego, na ile ta zmiana wpłynie na inne części systemu.Aby pomóc im to zrozumieć, jeden z deweloperów Dinner Now tworzy następujące wykresy i diagramy z istniejącego kodu:

Wykres lub diagram

Pokazy

Wykres zależności

Zobacz:

Zależności i inne relacje w kodzie.

Na przykład firma Dinner Now może rozpocząć od przejrzenia wykresów zależności zestawów w celu obejrzenia zestawów i ich zależności.Może przechodzić do szczegółów grafów w celu eksplorowania obszarów nazw i klas w tych zestawach.

Dinner Now może również tworzyć wykresy pozwalające na zbadanie szczególnych obszarów i innych rodzajów relacji w kodzie.Używa Eksploratora architektury lub Eksploratora rozwiązań, aby pomóc im znaleźć i wybrać obszary i relacje, które ich interesują.

Diagram sekwencji (oparty na kodzie)

Zobacz Wizualizacja kodu na diagramach sekwencyjnych.

Sekwencja interakcji między wystąpieniami.

Diagramy sekwencji są generowane na podstawie definicji metod i pomagają zrozumieć, jak kod implementuje zachowanie metody.

Diagram klasy (oparty na kodzie)

Zobacz Porady: dodawanie diagramów klasy do projektu (Projektant klas).

Istniejące klasy w kodzie

Na przykład programistka używa Eksploratora architektury, aby zaznaczyć przestrzenie nazw, na których chce się skupić, i tworzy wykres zależności z kodu.Dostosowuje jego zakres, aby skupić się na obszarach, których dotyczy nowy scenariusz.Oto obszary zaznaczone i wyróżnione na grafie:

Wykres zależności nazw

Wykres zależności obszaru nazw

Deweloper rozwija wybrane obszary nazw, aby zobaczyć ich klasy, metody i relacje:

Wykres zależności nazw rozszerzonej

Rozwinięty wykres zależności przestrzeni nazw z widocznymi łączami między grupami

Deweloper bada kod, aby znaleźć klasy i metody, na które mają wpływ wprowadzone zmiany.Generuje diagramy sekwencji i diagramy klas na podstawie kodu w celu opisania i omówienia zmian.Zobacz Tworzenie wizualizacji kodu.

PoradaPorada

Aby zobaczyć skutki każdej zmiany po ich wykonaniu, należy ponownie wygenerować wykresy zależności i diagramy sekwencji z kodu po każdej zmianie.

Aby opisać zmiany dotyczące innych części systemu, takich jak składniki lub interakcje, zespół może narysować je na tablicach.Może również narysować następujące diagramy w programie Visual Studio, aby oba zespoły mogły przechwytywać szczegółowe informacje, zarządzać nimi i rozumieć je:

Diagramy

Opisuje

Diagram aktywności (UML)

Zobacz:

Przepływ kroków, które występują, gdy system zauważa, że klient ponownie składa zamówienie z restauracji, monitując klienta o napisanie recenzji.

Diagram klas (UML)

Zobacz:

Logiczne klays i ich relacje.Na przykład dodaje się nową klasę do opisania elementu Przegląd i jego relacji z innymi jednostkami, takich jak Restauracja, Menu i Klient.

Aby skojarzyć opinie z klientem, system musi przechowywać szczegóły klienta.Diagram klas UML może pomóc wyjaśnić te szczegóły.

Diagram klasy (oparty na kodzie)

Zobacz Porady: dodawanie diagramów klasy do projektu (Projektant klas).

Istniejące klasy w kodzie.

Diagram składników (UML)

Zobacz:

Części wysokiego poziomu systemu, takie jak witryna firmy Dinner Now w sieci Web i jej interfejsy.Niniejsze interfejsy określają sposób wzajemnej interakcji składników poprzez metody lub usługi, które zapewniają i wykorzystują.

Diagram sekwencji (UML)

Zobacz:

Sekwencja interakcji między wystąpieniami.

Na przykład poniższy diagram składników zawiera nowy składnik, który jest częścią składnika witryny sieci Web firmy Dinner Now.Składnik ReviewProcessing obsługuje funkcje tworzenia przeglądów i pojawia się wyróżniony kolorem pomarańczowym:

Diagram składników UML

Diagram składników UML

Na poniższym diagramie sekwencji przedstawiono sekwencję wzajemnych oddziaływań zachodzących, gdy witryna firmy Dinner Now w sieci Web sprawdza, czy klient zamawiał już coś z restauracji.Jeśli to prawda, prosi klienta o utworzenie recenzji, która jest wysyłana do restauracji i publikowane na witrynie sieci Web:

Diagram sekwencji UML

Diagram sekwencji UML

Zachowywanie kodu zgodnie z projektem

Dinner Now musi się upewnić, że zaktualizowany kod pozostaje zgodny z projektem.Tworzy diagramy warstw, które opisują warstwy funkcji w systemie, określa dozwolone zależności między nimi i kojarzy artefakty rozwiązania z tymi warstwami.

Diagram

Opisuje

Diagram warstwy

Zobacz:

Logiczna architektura kodu.

Diagram warstwy organizuje i mapuje artefakty w rozwiązaniu Visual Studio grup abstrakcyjnych nazywanych warstwami.Te warstwy określają role, zadania lub funkcje, które te artefakty pełnią w systemie.

Diagramy warstwy są przydatne do opisywania zamierzonego projektu systemy i sprawdzenia poprawności zmian kodu w stosunku do projektu.

Aby utworzyć warstwy, przeciągnij elementy z Eksploratora rozwiązań, wykresów zależności lub Eksploratora architektury.Aby narysować nowe warstwy, użyj przybornika lub kliknij prawym przyciskiem myszy powierzchnię diagramu.

Aby wyświetlić istniejące zależności na diagramie warstwy, kliknij prawym przyciskiem myszy powierzchnię diagramu warstwy, a następnie kliknij polecenie Wygeneruj zależności.Aby określić zależności zamierzone, narysuj nowe.

Na przykład poniższy diagram warstwowy opisuje zależności między warstwami i liczbą artefaktów, które są skojarzone z poszczególnymi warstwami:

Diagramy warstwowe płatności zintegrowanego systemu

Diagram warstwy

Aby upewnić się, czy nie występują konflikty z projektem podczas programowania kodu, zespoły sprawdzają poprawność warstw w kompilacjach, które są uruchamiane w programie Team Foundation Build.Tworzą one równie niestandardowe zadanie platformy MSBuild w celu wymagania sprawdzania poprawności warstwy w swoich operacjach ewidencjonowania.Używają raportów z kompilacji do zbierania błędów sprawdzania poprawności.

Zobacz:

Ogólne porady dotyczące tworzenia i używania modeli

  • Większość diagramów składa się z węzłów, które są połączone liniami.Dla każdego typu diagramu przybornik zawiera różne rodzaje węzłów i wierszy.

    Aby otworzyć przybornik, kliknij polecenie Przybornik w menu Widok.

  • Aby utworzyć węzeł, przeciągnij go z przybornika do diagramu.Niektóre rodzaje węzłów muszą zostać przeciągnięte do istniejących węzłów.Na przykład na diagramie składników nowy port musi być dodany do istniejącego składnika.

  • Aby utworzyć linię lub połączenie, kliknij odpowiednie narzędzie w przyborniku, kliknij węzeł źródła, a następnie kliknij węzeł docelowy.Niektóre linie mogą być tworzone tylko między pewnymi rodzajami węzłów.Gdy przesuniesz wskaźnik nad możliwe źródło lub miejsce docelowe, wskaźnik wskazuje, czy można utworzyć połączenie.

  • Podczas tworzenia elementów na diagramach UML są one również dodawane do wspólnego modelu.Diagramy UML w projekcie modelowania są widokami tego modelu.Elementy na diagramie warstwy są częścią projektu modelowania, nawet jeśli nie są one przechowywane we wspólnym modelu.

    Aby wyświetlić model, w menu Architektura wskaż polecenie Okna, a następnie kliknij przycisk Eksplorator modelu UML.

  • W niektórych przypadkach można przeciągnąć niektóre elementy z Eksploratora modelu UML do diagramu UML.Niektóre elementy w ramach tego samego modelu mogą być używane w wielu lub w różnych diagramach w celu pokazania alternatywnych widoków architektury.Na przykład można przeciągnąć składnik do innego diagramu składników lub diagramu sekwencji, aby był używany jako aktor.

  • Visual Studio Ultimate obsługuje UML 2.1.2.Przegląd ten zawiera opis najważniejszych funkcji diagramów UML w tej wersji, ale istnieje wiele książek, w których omówiono UML i jego zastosowania w szczegółach.

Zobacz Modele projektowania dla projektowania oprogramowania.

Planowanie i śledzenie pracy

Diagramy modelowania programu Visual Studio Ultimate są zintegrowane z programem Team Foundation Server, więc zespoły mogą łatwiej planować swoją pracę, zarządzać nią i ją śledzić.Oba zespoły używają modeli do identyfikowania przypadków testowych i zadań programistycznych i do szacowania pracy.Lucerna tworzy i łaczy elementy robocze Team Foundation Server z elementami modelu, takimi jak przypadki użycia lub składniki.Pomoże im to monitorować ich postęp i śledzić ich pracę odpowiednio do wymagań użytkowników.Pomoże im to upewnić się, że ich zmiany w dalszym ciągu spełniają te wymagania.

Wraz z postępem prac zespoły aktualizują elementy robocze, aby odzwierciedlić czas poświęcony na realizację tych zadań.Ponadto monitorują i raportują stan swojej pracy za pomocą następujących funkcji programu Team Foundation Server:

  • Codzienne raporty wygaszania informujące, czy planowane prace zostaną zakończone w oczekiwanym czasie.Generują inne podobne raporty z programu Team Foundation Server w celu śledzenia postępu usterek.

  • Arkusz iteracji używający programu Microsoft Excel, aby pomóc zespołowi w monitorowaniu i równoważeniu obciążenia pracą poszczególnych członków.Arkusz ten jest połączony z serwerem Team Foundation Server i dostarcza tematy do dyskusji podczas regularnie odbywanych spotkań.

  • Pulpit nawigacyjny prac rozwojowych używający Office Project do informowania zespołu o ważnych informacjach dotyczących projektu.

Zobacz:

Testowanie, sprawdzanie poprawności i ewidencjonowanie kodu

Wykonania poszczególne zadania zespoły ewidencjonują kod do kontroli wersji Team Foundation, a jeśli zapomną otrzymują przypomnienia z Team Foundation Server.Zanim Team Foundation Server zaakceptuje ewidencjonowania, zespoły uruchamiają testy jednostkowe i sprawdzanie poprawności warstwy, aby sprawdzić kod w oparciu o przypadki testowe i projekt.Regularnie używają programu Team Foundation Server do uruchamiania kompilacji, zautomatyzowanych testów jednostek i sprawdzania poprawności warstw.Pomaga to upewnić się, że dany kod spełnia następujące kryteria:

  • To działa.

  • Nie zprzerywa wcześniej działającego kodu.

  • Nie powoduje konfliktu z projektem.

Dinner Now ma duży zbiór zautomatyzowanych testów, z których może korzystać Lucerne, ponieważ prawie wszystkie nadal obowiązują.Lucerna można opierać się na tych testach i dodać nowe na pokrycie nowej funkcje.Obie używają Visual Studio Ultimate do uruchomienia testów ręcznych.

Aby upewnić się, że kod odpowiada wymaganiom projektu, zespoły konfigurują swoje kompilacje w programie Team Foundation Build, uwzględniając sprawdzanie poprawności warstwy.Jeśli wystąpią konflikty, generowany jest raport ze szczegółami.

Zobacz:

Aktualizowanie systemu przy użyciu wizualizacji i modelowania

Lucerna i obiad teraz muszą zintegrować swoje systemy płatności.W następujących sekcjach pokazano, że diagramy modelowania w programie Visual Studio Ultimate pomagają w wykonaniu tego zadania:

  • Omówienie wymagań użytkowników: diagramy przypadków użycia

  • Omówienie procesu biznesowego: diagramy aktywności

  • Opisz strukturę systemu: diagramy składników

  • Opisz interakcje: diagramy sekwencji

  • Wizualizacja istniejącego kodu: wykresy zależności

  • Definiuj słownik typów: diagramy klas

  • Opisz logiczną architekturę: diagramy warstw

Zobacz:

Omówienie wymagań użytkowników: diagramy przypadków użycia

Diagramy przypadków użycia stanowią podsumowanie działań obsługiwanych przez system i osób wykonujących te działania.Lucerna używa diagramu przypadków, aby dowiedzieć się o systemie Obiad teraz następujących informacji:

  • Klienci składają zamówienia.

  • Restauracje otrzymują zamówienia.

  • Brama zewnętrznego agenta rozliczeniowego płatności, której system płatności firmy Dinner Now używa do sprawdzania poprawności płatności, jest poza zasięgiem dla tej witryny sieci Web.

Diagram pokazuje również, jak główne przypadki użycia dzielą się na mniejsze przypadki użycia.Lucerna chce korzystać z jej własnego systememu płatności.Wyróżnia przypadek użycia Proces płatności innym kolorem, aby wskazać, że wymaga on zmiany:

Wyróżnianie proces płatności na diagram przypadków użycia

Wyróżnianie przetwarzania płatności na diagramie przypadku użycia

Jeśli czas tworzenia był krótki, zespół może omówić, czy chce, aby umożliwić klientom płacenie restauracjom bezpośrednio.Aby to pokazać, można zamienić przypadek użycia przetwarzania płatności na taki, który jest poza systemem Dinner Now.Następnie łączy klienta bezpośrednio z restauracją, wskazując, że teraz firma Dinner Now może tylko przetwarzać zamówienia:

Rescoping restauracji płatności na diagram przypadków użycia

Zmiana zakresu płatności restauracji na diagramie przypadku użycia

Zobacz:

Rysowanie diagramu przypadków użycia

Diagram przypadków użycia ma następujące cechy główne:

  • Aktorzy reprezentują role pełnione przez osoby, organizacje, maszyny lub systemy oprogramowania.Na przykład Klient, Restauracja i System płatności firmy Dinner Now są aktorami.

  • Przypadki użycia reprezentują interakcje między podmiotami i systemem w fazie projektowania. Mogą one reprezentować dowolną skalę interakcji — od jednego kliknięcia przyciskiem myszy lub wiadomości do transakcji trwającej wiele dni.

  • Skojarzenia powiązują aktorów z przypadkami użycia.

  • Większy przypadek użycia może zawierać mniejsze, na przykład, Utwórz zamówienie zawiera Wybierz restaurację.Można rozszerzyć przypadek użycia, który dodaje cele i kroki do przypadku rozszerzonego użycia, w celu wskazania, że przypadek użycia występuje jedynie w pewnych warunkach.Przypadki użycia można również dziedziczyć z innych przypadków użycia.

  • Podsystem reprezentuje system oprogramowania, które jest projektowane lub jeden z jego składników.To jest duże pole, które zawiera przypadki użycia.Diagram przypadków użycia wyjaśnia, co jest wewnątrz lub na zewnątrz granicy podsystemu.Aby wskazać, że użytkownik musi osiągnąć określone cele w inny sposób, narysuj te przypadki użycia poza granicą podsystemu.

  • Artefakty łączą elementy na diagramie z innymi diagramami lub dokumentami.

Zobacz:

Podsumowanie: zalety diagramów przypadków użycia

Diagramy przypadków użycia ułatwiają wizualizowanie:

  • Działania, które system obsługuje lub nie

  • Osoby i systemy zewnętrzne, które wykonują te działania

  • Główne składniki systemu obsługujące każde działanie, które można przedstawić jako podsystemy zagnieżdżone wewnątrz systemu nadrzędnego

  • Jak przypadek użycia można podzielić na mniejsze lub na odmiany

Stosunek do innych diagramów

Diagram

Opisuje

Diagram aktywności

Przepływ kroków w przypadku użycia i osoby, które wykonują te kroki w tym przypadku użycia.

Nazwy przypadków użycia często odzwierciedlają kroki na diagramie aktywności.Diagramy aktywności obsługują elementy, takie jak decyzje, scalenia, dane wejściowe i wyjściowe, przepływy współbieżne i tak dalej.

Zobacz:

Diagram sekwencji

Sekwencja interakcji między uczestnikami w przypadku użycia.

Zobacz:

Diagram klas (UML)

Jednostki lub typy, które uczestniczą w przypadku użycia.

Zobacz:

Omówienie procesu biznesowego: diagramy aktywności

Diagramy aktywności opisują przepływ kroków procesu biznesowego i zapewniają prosty sposób komunikowania przepływu pracy.Projekt rozwoju może mieć wiele diagramów aktywności.Zwykle działanie obejmuje wszystkie czynności, które wynikają z jednego z działań zewnętrznych, takich jak zamawianie posiłku, aktualizowanie menu lub dodanie nowej restauracji do działalności.Działanie może również opisywać szczegóły działań złożonych.

Lucerna aktualizacje następujący diagramie aktywności, aby pokazać, że Lucerna przetwarza płatności i płaci restauracjom.Zastępuje system płatności firmy Dinner Now systemem płatności firmy Lucerne, jak to podkreślono:

System płatności lucerny na diagram aktywności

Zastępuje system płatności Obiad teraz w diagramie aktywności

Zaktualizowany diagram pomaga firmom Lucerne i Dinner Now zwizualizować, jak system płatności firmy Lucerne jest dopasowany do procesu biznesowego.W tym wydaniu komentarze służą do definiowania ról, które wykonują czynności.Wiersze są używane do tworzenia torów, który organizują etapy za pomocą roli.

Zespoły mogą też rozważyć omówienie alternatywnego scenariusza, gdy klient płaci restauracji zamiast po dostarczeniu zamówienia.To spowodowałoby różne wymagania dotyczące systemu oprogramowania.

Poprzednio Obiad teraz zwrócił te diagramy na tablicy lub w programie PowerPoint.Teraz również używa programu Visual Studio Ultimate w celu narysowania tych diagramów, aby oba zespoły mogły przechwytywać szczegółowe informacje, rozumieć je i zarządzać nimi.

Zobacz:

Rysowanie diagramu aktywności

Diagram aktywności ma następujące cechy główne:

  • Węzeł początkowy, który określa pierwszą akcję działania.

    Diagram zawsze powinien mieć jeden z tych węzłów.

  • Akcje opisują kroki, podczas których użytkownik lub oprogramowanie wykonują zadanie.

  • Kontrole przepływu ukazują przepływ między działaniami.

  • Węzły decyzji reprezentujące rozgałęzienia warunkowe w strumieniu.

  • Węzły rozwidlające, które dzielą pojedyncze przepływy na przepływy współbieżne.

  • Węzły ostateczne działalności, które pokazują koniec działań.

    Chociaż te węzły są opcjonalne, warto uwzględnić je na diagramie, aby pokazać, gdzie kończy się działanie.

Zobacz:

Podsumowanie: zalety diagramów aktywności

Diagramy aktywności ułatwiają wizualizację i opisywanie przepływu sterowania i informacji między działaniami firmy, systemu lub programu.Jest to prosty i skuteczny sposób na odzwierciedlanie przepływu pracy podczas komunikowania się z innymi osobami.

Stosunek do innych diagramów

Diagram

Opis

Diagram przypadków użycia

Podsumowanie działań, które wykonuje każdy uczestnik.

Zobacz:

Diagram składników

Umożliwia wizualizację systemu jako zbiór części wielokrotnego użytku, które zapewniają lub zużywają działanie za pomocą wyraźnie określonych interfejsów.

Zobacz:

Opisz strukturę systemu: diagramy składników

Diagramy składników opisują system jako kolekcję osobnych części, które zapewniają lub zużywają działanie za pomocą wyraźnie określonych interfejsów.Części mogą być w dowolnej skali i połączone w dowolny sposób.

Aby pomóc firmom Lucerne i Dinner Now wizualizować i omówić składniki systemu i ich interfejsy, można utworzyć następujące diagramy składników:

Składniki zewnętrzne w systemie płatności

Składniki systemu płatności Dinner Now

Ten diagram przedstawia różne typy składników i ich zależności.Na przykład witryna sieci Web firmy Dinner Now oraz system płatności firmy Lucerne wymagają bramy zewnętrznego agenta rozliczeniowego płatności do sprawdzania poprawności płatności.Strzałki między składnikami przedstawiają zależności wskazujące, które składniki wymagają funkcji innych składników.

Aby używać z systemu płatności firmy Lucerne, należy zaktualizować witrynę sieci Web Dinner Now do użycia interfejsów PaymentApproval i PayableInsertion w systemie płatności Lucerne.

Poniższy diagram przedstawia określoną konfigurację składników dla witryny firmy Dinner Now w sieci Web.Ta konfiguracja oznacza, że dowolne wystąpienie witryny sieci Web składa się z czterech części:

  • CustomerProcessing

  • OrderProcessing

  • ReviewProcessing

  • Przetwarzanie płatności

Te części są wystąpieniami określonych typów składników i są połączone w następujący sposób:

Składniki wewnątrz obiad teraz witryny

Składniki wewnątrz witryny internetowej Dinner Now

Witryna firmy Dinner Now w sieci Web deleguje swoje zachowanie na te części, które obsługują funkcje witryny sieci Web.Strzałki między składnikiem nadrzędnym i jego składnikami członkowskimi pokazują delegacje wskazujące części obsługujące komunikaty, które składnik nadrzędny otrzymuje lub wysyła za pośrednictwem swoich interfejsów.

W tej konfiguracji składnik PaymentProcessing przetwarza płatności odbiorcy.Dlatego należy go zaktualizować w celu integracji z systemem płatności firmy Lucerne.W innych sytuacjach wiele wystąpień typu składnika może istnieć w tym samym składniku nadrzędnym.

Zobacz:

Rysowanie diagramu składników

Diagram składników ma następujące cechy główne:

  • Składniki reprezentujące oddzielene części funkcjonalności systemu.

  • Zapewnij porty interfejsu reprezentujące grupy wiadomości lub połączeń, których składniki wdrażają i są używane przez inne składniki lub systemy zewnętrzne.

  • Zapewnij porty interfejsu reprezentujące grupy wiadomości lub połączeń, których składniki wysyłają do innych składników lub systemów zewnętrznych.Tego rodzaju port opisuje operacje, których składnik co najmniej oczekuje od innych składników lub systemów zewnętrznych.

  • Części są członkami składników i są zazwyczaj wystąpieniami innych składników.Część jest fragmentem projektu wewnętrznego składnika nadrzędnego.

  • Zależności wskazujące składniki wymagają funkcjonalności innych składników.

  • Delegacje wskazujące części składnika obsługi wiadomości wysłanych lub odebranych przez składnik nadrzędny.

Zobacz:

Podsumowanie: zalety diagramów składników

Diagramy składników ułatwiają wizualizowanie:

  • System jako kolekcja osobnych części, niezależnie od ich implementacji języka i stylu.

  • Składniki z dobrze określonymi interfejsami, co ułatwia zrozumienie i aktualizację projektu w przypadku zmiany wymagań.

Stosunek do innych diagramów

Diagram

Opis

Wykres zależności

Umożliwia wizualizację organizacji i relacji w istniejącym kodzie.

Aby zidentyfikować potencjalne składniki, można utworzyć wykres zależności i pogrupować elementy według ich funkcji w systemie.

Zobacz:

Diagram sekwencji

Umożliwia wizualizację sekwencji wzajemnego oddziaływania między komponentami lub częściami wewnątrz składnika.

Aby utworzyć linię życia na diagramie sekwencji ze składnika, kliknij prawym przyciskiem myszy składnik, a następnie kliknij polecenie Utwórz linię życia.

Zobacz:

Diagram klas (UML)

Definiuj interfejsy na dostarczonych lub wymaganych portach i klasy, które implementują funkcjonalność składników.

Zobacz:

Diagram warstwy

Opisz logiczną architekturę systemu w powiązaniu ze składnikami.Użyj sprawdzania poprawności warstwy, aby upewnić się, że kod pozostaje zgodny z projektem.

Zobacz:

Diagram aktywności

Umożliwia wizualizację wewnętrznego przetwarzania, które składniki wykonują w odpowiedzi na wiadomości przychodzące.

Zobacz:

Wizualizacja istniejącego kodu: wykresy zależności

Wykresy zależności pokazują bieżącą organizacją i relacje w kodzie.Elementy są reprezentowane przez węzły na wykresie, a relacje są reprezentowane przez łącza.Wykresy zależności mogą Ci pomóc wykonać następujące rodzaje zadań:

  • Poznawanie nieznanego kodu.

  • Omówienie, gdzie i w jaki sposób proponowana zmiana może mieć wpływ na istniejący kod.

  • Znajdowanie obszarów złożoności, naturalnych warstw lub wzorców albo innych obszarów, które mogą skorzystać na poprawie.

Na przykład firma Dinner Now musi oszacować koszt aktualizacji składnika PaymentProcessing.Zależy to częściowo od tego, na ile ta zmiana wpłynie na inne części systemu.Aby pomóc im to zrozumieć, jeden z deweloperów Dinner Now tworzy wykresy zależności od kodu i dopasowuje ich zakres, skupiając się na obszarach, na które mogą mieć wpływ zmiany.

Następujący graf przedstawia zależności między klasą PaymentProcessing i innymi częściami systemu firmy Dinner Now, które zostaną wyświetlone jako zaznaczone:

Wykres zależności dla obiad teraz system płatności

Wykres zależności dla systemu płatności Dinner Now

Deweloper bada graf, rozwijając klasę PaymentProcessing i wybierając jej elementy członkowskie, aby zobaczyć obszary, których potencjalnie dotyczą zmiany:

Metody wewnątrz PaymentProcessing i zależności

Metody wewnątrz klasy PaymentProcessing i ich zależności

Firma generuje poniższy graf dla systemu płatności firmy Lucerne, aby mieć wgląd w jego klasy, metody i zależności.Zespół widzi, że system firmy Lucerne może również wymagać pracy nad interakcją z innymi częściami firmy Dinner Now:

Wykres zależności dla systemu płatności lucerny

Wykres zależności dla systemu płatności Lucerne

Oba zespoły współpracują w celu określenia zmian, które są wymagane do zintegrowania dwóch systemów.Firma decyduje się o zrefaktoryzować część kodu, dzięki czemu będzie łatwiejszy do aktualizacji.Klasa PaymentApprover zostanie przeniesiona do obszaru nazw DinnerNow.Business i będzie wymagać pewnych nowych metod.Klasy firmy Dinner Now, które obsługują transakcje, będą miały własny obszar nazw.Zespoły tworzą elementy robocze i używają ich do planowania, organizowania i śledzenia swojej pracy.Gdzie jest to użyteczne, łączą elementy robocze z elementami modelu.

Po reorganizacji kodu zespoły generują nowy wykres zależności, aby zobaczyć zaktualizowaną strukturę i relacje:

Wykres zależności z kodem zreorganizowanych

Wykres zależności z kodem zreorganizowanym

Ten wykres pokazuje, że klasa PaymentApprover znajduje się obecnie w obszarze nazw DinnerNow.Business i ma kilka nowych metod.Klasy transakcji firmy Dinner Now mają teraz własny obszar nazw PaymentSystem, dzięki czemu później będzie można łatwiej radzić sobie z tym kodem.

Tworzenie wykresu zależności

Podsumowanie: zalety diagramów zależności

Wykresy zależności pomagają w:

  • Dowiedz się o organizacji i relacjach w istniejącym kodzie.

  • Zidentyfikuj obszary, na które może mieć wpływ proponowana zmiana.

  • Znajdowanie obszarów złożoności, wzorów, warstw lub innych obszarów, które można poprawić, aby ułatwić utrzymania, zmianę i ponowne używanie kodu.

Stosunek do innych diagramów

Diagram

Opisuje

Diagram warstwy

Logiczna architektura systemu.Użyj sprawdzania poprawności warstwy, aby upewnić się, że kod pozostaje zgodny z projektem.

Aby ułatwić identyfikację istniejących lub planowanych warstw, można utworzyć wykres zależności i pogrupować pokrewne elementy.Aby utworzyć diagram warstwy, przeciągnij elementy z wykresu lub Eksploratora architektury.

Zobacz:

Diagram składników

Składniki, ich interfejsy oraz ich wzajemne relacje.

Aby pomóc w zidentyfikowaniu składników, można utworzyć wykres zależności i pogrupować elementy według ich funkcji w systemie.

Zobacz:

Diagram klas (UML)

Klasy, ich atrybuty i operacje, oraz ich relacje.

Aby pomóc w zidentyfikowaniu tych elementów, należy utworzyć dokument wykresu pokazujący te elementy.

Zobacz:

Diagram klasy (oparty na kodzie)

Istniejące klasy w kodzie.

Wizualizację i modyfikowanie istniejącej klasy w kodzie umożliwia Projektant klas.

Zobacz Porady: dodawanie diagramów klasy do projektu (Projektant klas).

Opisz interakcje: diagramy sekwencji

Diagramy sekwencji opisują serię interakcji między częściami systemu.Części mogą być w dowolnej skali.Na przykład mogą sięgać od poszczególnych obiektów w programie do dużych podsystemów lub podmiotów zewnętrznych.Interakcje mogą mieć dowolną skalę i typ.Na przykład mogą sięgać od pojedynczych komunikatów do rozszerzonych transakcji i mogą być wywołaniami funkcji lub komunikatami usługi sieci Web.

Pomocne dla firm Lucerne i Dinner Now w opisaniu i omówieniu przypadku użycia Przetwarzaniu płatności może być utworzenie poniższego diagramu sekwencji wynikającego z diagramu składników.Linie życia są lustrzanym odbiciem witryny firmy Dinner Now w sieci Web i jej części.Komunikaty wyświetlane między liniami życia odpowiadają połączeniom na diagramach składników:

Diagram kolejności proces płatności przypadek użycia

Diagram sekwencji dla przypadku użycia Przetwarzanie płatności

Diagram sekwencji pokazuje, że gdy klient tworzy zamówienie, witryna firmy Dinner Now w sieci Web wywołuje metodę ProcessOrder dla wystąpienia obiektu OrderProcessing.Następnie OrderProcessing wywołuje ProcessPayment na PaymentProcessing.Ten proces jest kontynuowany, dopóki brama zewnętrznego agenta rozliczeniowego płatności nie sprawdzi poprawność płatności.Dopiero wtedy kontrola zwraca witrynę sieci obiad teraz.

Lucerna musi oszacować koszt aktualizacji system płatności, ich integracji z systemem Obiad teraz.Aby pomóc im to zrozumieć, jeden z deweloperów tworzy diagramy sekwencji z istniejącego kodu przedstawiające istniejące interakcje:

Zobacz:

Rysowanie diagramu sekwencji

Diagram sekwencji ma następujące cechy główne:

  • Pionowe linie życia reprezentują aktorów lub wystąpienia obiektów oprogramowania.

    Aby dodać symbol aktora, który wskazuje, że uczestnik jest poza systemem w fazie projektowania, kliknij przycisk linii życia.W oknie Właściwości ustaw kctor na Prawda.Jeśli okno Właściwości nie jest otwarte, naciśnij klawisz F4.

  • Poziome komunikaty reprezentują wywołania metod, komunikaty usług sieci Web lub niektóre inne rodzaje komunikacji.Wystąpienia wykonania są pionowymi cieniowanymi prostokątami, które pojawiają się na liniach życia i reprezentują okresy, podczas których obiekty odbierające przetwarzają wywołania.

  • Podczas komunikacji synchronicznej obiektu nadawcy czeka na formant, aby <<wrócił>>, tak jak w regularnym wywołaniu funkcji.Podczas komunikacji asynchronicznej nadawca może natychmiast kontynuować.

  • Komunikaty <<tworzenia>> umożliwiają wskazanie konstrukcji obiektów przez inne obiekty.Powinna ona być pierwszą wiadomością wysłaną do obiektu.

Zobacz:

Podsumowanie: zalety diagramów sekwencji

Diagramy sekwencji pozwalają zwizualizować:

  • Przepływ sterowania, które przechodzi między aktorami i obiektami podczas wykonywania przypadku użycia.

  • Implementacja wywołania metody lub komunikatu.

Stosunek do innych diagramów

Diagram

Opis

Diagram klas (UML)

Definiuj klasy reprezentowane przez linie życia oraz parametry i zwracane wartości, które są używane w wiadomościach przesyłanych między liniami życia.

Aby utworzyć klasę z linii życia, kliknij prawym przyciskiem myszy linię życia, a następnie kliknij polecenie Utwórz klasę lub Utwórz interfejs.Aby utworzyć linię życia z typu na diagramie klasy, kliknij prawym przyciskiem myszy typ, a następnie kliknij polecenie Utwórz linię życia.

Zobacz:

Diagram składników

Opisz składniki, reprezentowane przez linie życia oraz interfejsy, które zapewniają i wykorzystują zachowanie reprezentowane przez wiadomości.

Aby utworzyć linię życia z diagramu składników, kliknij prawym przyciskiem myszy składnik, a następnie kliknij polecenie Utwórz linię życia.

Zobacz:

Diagram przypadków użycia

Podsumowanie interakcji między użytkownikami i składnikami na diagramie sekwencji jako przypadek użycia, który przedstawia cel użytkownika.

Zobacz:

Definiuj słownik typów: diagramy klas

Diagramy klas określają podmioty, terminy i pojęcia, które uczestniczą w systemie, oraz ich wzajemne relacje.Na przykład można użyć tych diagramów podczas programowania do opisania atrybutów i operacji dla każdej klasy, niezależnie od języka i stylu ich implementacji.

Aby pomóc firmie Lucerne opisać i omówić podmioty, które uczestniczą w przypadku użycia Przetwarzanie płatności, można narysować poniższy diagram klasy:

Proces płatności jednostek na diagram klasy

Jednostki procesu płatności na diagramie klasy

Ten diagram pokazuje, że klient może mieć wiele zamówień i płacić za zamówienia na różne sposoby.BankAccount i CreditCard są związane z Płatnością.

Podczas programowania Lucerne używa poniższego diagramu klas do opisania i omówienia szczegółów każdej klasy:

Przetwarzanie płatności szczegóły jednostki na diagram klasy

Szczegóły procesu płatności na diagramie klasy

Zobacz:

Rysowanie diagramu klas

Diagram klasy ma następujące cechy główne:

  • Typy takie jak klasy, interfejsy i wyliczenia:

    • Klasa stanowi definicję obiektów wyróżniających się szczególnymi cechami strukturalnymi i funkcjonalnymi.

    • Interfejs definiuje część widocznych zewnętrznych zachowań obiektu.

    • Wyliczenie jest klasyfikatorem, który zawiera listę wartości literałów.

  • Atrybuty to wartości pewnego typu, opisujące każde wystąpienie klasyfikatora.Klasyfikator to ogólna nazwa dla typów, składników, przypadków użycia a nawet aktorów.

  • Operacje są metodami lub funkcjami, które wykonują wystąpienia klasyfikatora.

  • Skojarzenie oznacza pewnego rodzaju relację między dwoma klasyfikatorami.

    • Agregacja jest skojarzeniem, które wskazuje wspólną własność między klasyfikatorami.

    • Kompozycja to skojarzenie ukazujące relacje między klasyfikatorami.

    Aby wyświetlić agregacje lub kompozycje, ustaw właściwość Agregacja w skojarzeniu.Opcja Udostępnione pokazuje agregacje, a opcja Kompozytowe — kompozycje.

  • Zależność wskazuje, że zmiana definicji jednego klasyfikatora może zmienić definicję innego klasyfikatora.

  • Generalizacja wskazuje, że dany klasyfikator dziedziczy od klasyfikatora ogólnego część jego definicji.Realizacja oznacza, że klasa implementuje operacje i atrybuty oferowane przez interfejs.

    Aby utworzyć te relacje, należy użyć narzędzia Dziedziczenie.Alternatywnie, realizacja może być reprezentowana jako lizak.

  • Pakiety są grupami klasyfikatorów, skojarzeń, linii życia, składników i inne pakietów.Relacje importu wskazują, że jeden pakiet zawiera wszystkie definicje innego pakietu.

Jako punktu wyjścia do badania i omawiania istniejących klas możesz użyć Projektanta klas, który służy do tworzenia diagramów klas z kodu.

Zobacz:

Podsumowanie: zalety diagramów klas

Diagramy klas pomagają określić:

  • Wspólny słownik terminów do wykorzystania podczas omawiania potrzeb użytkowników oraz jednostek, które uczestniczą w systemie.Zobacz Modelowanie — Wymagania dla użytkownika.

  • Typy, które są używane przez części systemu, takie jak składniki, niezależnie od ich implementacji.Zobacz Modelowanie architektury oprogramowania.

  • Relacje, takie jak zależności między typami.Na przykład można pokazać, że jeden typ może być skojarzony z wieloma wystąpieniami innego typu.

Stosunek do innych diagramów

Diagram

Opis

Diagram przypadków użycia

Definiuj typy używane do opisywania celów i etapów przypadków użycia.

Zobacz:

Diagram aktywności

Definiuj rodzaje danych, które przechodzą przez węzły obiektu, piny wejściowe, piny wyjściowe oraz węzły parametru działania.

Zobacz:

Diagram składników

Opisz składniki, ich interfejsy oraz ich wzajemne relacje.Klasa może również opisywać dokończyć kompletny komponent.

Zobacz:

Diagram warstwy

Definiuj logiczną architekturę systemu w powiązaniu z klasami.

Użyj sprawdzania poprawności warstwy, aby upewnić się, że kod pozostaje zgodny z projektem.

Zobacz:

Diagram sekwencji

Definiuj rodzaje linii życia i operacje, parametry, oraz wartości zwracane dla wszystkich wiadomości, które linia życia może odbierać.

Aby utworzyć linię życia z typu na diagramie klasy, kliknij prawym przyciskiem myszy typ, a następnie kliknij polecenie Utwórz linię życia.

Zobacz:

Wykres zależności

Umożliwia wizualizację organizacji i relacji w istniejącym kodzie.

Aby zidentyfikować klasy, ich relacje i metody, utwórz dokument wykresu pokazujący te elementy.

Zobacz:

Opisz logiczną architekturę: diagramy warstw

Diagramy warstwy opisują architekturę logiczną systemu organizowania artefaktów w twoich rozwiązaniach w abstrakcyje grupy, lub warstwy.Artefakty mogą być różne, mogą to być przestrzenie nazw, projekty, klasy, metody itd.Warstwy przedstawiają i opisują role lub zadania, które te artefakty pełnią w systemie.Można także dodać sprawdzenie poprawności warstwy w kompilacji i ewidencjonowaniu operacji, aby upewnić się, że kod pozostaje zgodny z jego zamysłem.

Aby zachować zgodność kodu z projektem, firmy Lucerne i Dinner Now używają poniższego diagramu warstwy do sprawdzania poprawności kodu, który jest opracowywany:

Diagramy warstwowe płatności zintegrowanego systemu

Diagram warstwy na obiad teraz zintegrowany z Lucerną

Warstwy na tym diagramie łączą się do odpowiednimi artefaktami rozwiązań firm Dinner Now i Lucerne.Na przykład warstwa biznesowa łączy się z przestrzenią nazw DinnerNow.Business i jej członkami, wśród których teraz jest klasa PaymentApprover.Warstwa dostępu do zasobów jest połączona z obszarem nazw DinnerNow.Data.Strzałki, lub zależności, określają, że tylko warstwa biznesowa może używać funkcji w warstwie dostępu do zasobów.Jako że zespoły aktualizują kod, regularnie przeprowadzane jest sprawdzanie poprawności warstw, co pozwala na wychwytywanie konfliktów w momencie ich wystąpienia i niezwłoczne ich rozwiązywanie.

Zespoły współpracują ze sobą nad stopniową integracją i testowaniem tych dwóch systemów.Najpierw upewniają się, że obiekt PaymentApprover i pozostała część pracy firmy Dinner Now dobrze ze sobą działają, zanim przejdą do pracy nad składnikiem PaymentProcessing.

Poniższy graf zależności pokazuje nowe wywołania między Dinner Now a PaymentApprover:

Wykres zaktualizowany zależności za pomocą zintegrowanego systemu

Wykres zależności ze zaktualizowanymi wywołaniami metod

Po potwierdzeniu, że system działa zgodnie z oczekiwaniami, usługa Dinner Now komentuje kod PaymentProcessing.Raporty sprawdzania poprawności warstwy są czyste, a otrzymany graf zależności pokazuje, że nie ma więcej zależności klasy PaymentProcessing:

Wykres zależności bez PaymentProcessing

Wykres zależności bez PaymentProcessing

Zobacz:

Rysowanie diagramu warstw

Diagram warstwy ma następujące cechy główne:

  • Warstwy opis grupy logicznej artefaktów.

  • Łącze jest skojarzeniem między warstwą a artefaktem.

    Aby utworzyć warstwy z artefaktów, przeciągnij elementy z Eksploratora rozwiązań, wykresów zależności lub Eksploratora architektury.Aby narysować nowe warstwy i łączyć je w artefakty, użyj przybornika lub kliknij prawym przyciskiem myszy powierzchnię diagramu, aby utworzyć warstwy, a następnie przeciągnij elementy do tych warstw.

    Liczba na warstwie pokazuje liczbę artefaktów, które są połączone z warstwą.Te artefakty mogą być obszarami nazw, projektami, klasami, metodami itd.Interpretując liczbę artefaktów na warstwie, należy pamiętać o poniższych:

    • Jeśli warstwa jest połączona z artefaktem, która zawiera inne artefakty, ale warstwy nie łączy się bezpośrednio z innymi artefaktami, liczba obejmuje tylko połączony artefakt.Jednak inne artefakty są uwzględniane dla analizy podczas sprawdzania poprawności warstwy.

      Na przykład jeżeli warstwa jest połączona z pojedynczą przestrzenią nazw, liczba połączonych artefaktów wynosi 1, nawet jeśli przestrzeń nazw zawiera klasy.Jeśli warstwa zawiera także łącza do każdej klasy w przestrzeni nazw, liczba będzie obejmować połączone klasy.

    • Jeśli warstwa zawiera inne warstwy, które są połączone z artefaktami, warstwa kontenerów jest także połączona z tymi artefaktami, mimo że liczba na warstwie kontenerów nie obejmuje tych artefaktów.

    Aby zobaczyć artefakty, które są połączone z warstwą, kliknij prawym przyciskiem myszy warstwę, a następnie kliknij opcję Wyświetl łącza, aby otworzyć eksploratora warstwy.

  • Zależność wskazuje, że jedna warstwa może korzystać z funkcjonalności w innej warstwie, ale nie odwrotnie.Dwukierunkowa zależność wskazuje, że jedna warstwę może korzystać z funkcjonaności w innej warstwie i odwrotnie.

    Aby wyświetlić istniejące zależności na diagramie warstwy, kliknij prawym przyciskiem myszy powierzchnię diagramu, a następnie kliknij polecenie Wygeneruj zależności.Aby opisać zależności zamierzone, narysuj nowe.

Zobacz:

Podsumowanie: zalety diagramów warstw

Diagramy warstwy pomogą ci:

  • Opisz logiczną architekturę systemu w oparciu o funkcjonalność artefaktów.

  • Upewnij się, że kod w opracowaniu odpowiada określonemu projektowi.

Stosunek do innych diagramów

Diagram

Opis

Wykres zależności

Umożliwia wizualizację organizacji i relacji w istniejącym kodzie.

Aby utworzyć warstwy, wygeneruj wykres zależności, a następnie zgrupuj elementy na wykresie jako potencjalne warstwy.Przeciągnij grupy z wykresu do diagramu warstw.

Zobacz:

Diagram składników

Opisz składniki, ich interfejsy oraz ich wzajemne relacje.

Aby zwizualizować warstwy, utwórz diagram składników, który opisuje funkcje różnych składników systemu.

Zobacz:

Zasoby zewnętrzne

Kategoria

Łącza

Fora

Blogi

Blog Visual Studio ALM + Team Foundation Server

Artykuły techniczne i dzienniki

The Architecture Journal - wydanie 23: Architektura — modelowanie i procesy

Inne witryny

Centrum MSDN architektury

Zobacz też

Koncepcje

Tworzenie wizualizacji kodu

Modele projektowania dla projektowania oprogramowania

Korzystanie z modeli podczas procesu projektowania

Używanie modeli w Agile Development

Walidacja systemu w czasie projektowania

Rozszerzanie diagramów i modeli UML