Scenariusz: Zmiana projektu z wykorzystaniem wizualizacji i modelowania
Upewnij się, że system oprogramowania spełnia potrzeby użytkowników przy użyciu narzędzi do wizualizacji i modelowania w programie Visual Studio. Użyj narzędzi, takich jak mapy kodu, diagramy zależności i diagramy klas, aby:
Aby zobaczyć, które wersje programu Visual Studio obsługują każde narzędzie, zobacz Obsługa wersji dla narzędzi architektury i modelowania.
Wyjaśnienie wymagań użytkowników i procesów biznesowych.
Wizualizowanie i eksplorowanie istniejącego kodu.
Opisz zmiany w istniejącym systemie.
Sprawdź, czy system spełnia wymagania.
Zachowaj spójność kodu z projektem.
Ten przewodnik:
Opisuje, jak te narzędzia mogą przynieść korzyści projektowi oprogramowania.
Pokazuje, jak można używać tych narzędzi, niezależnie od podejścia programistycznego, z przykładowym scenariuszem.
Aby dowiedzieć się więcej o tych narzędziach i obsługiwanych przez nich scenariuszach, zobacz:
Omówienie scenariusza
W tym scenariuszu opisano epizody z cyklu życia tworzenia oprogramowania dwóch fikcyjnych firm: Dinner Now i Unitye Publishing. Kolacja teraz zapewnia internetową usługę dostarczania posiłków w Seattle. Klienci mogą zamówić posiłki i zapłacić za nie w witrynie internetowej Dinner Now. Zamówienia są następnie wysyłane do odpowiedniej lokalnej restauracji do dostawy. Bristole Publishing, firma w Nowym Jorku, prowadzi kilka firm zarówno off, jak i w Internecie. Na przykład uruchamiają witrynę internetową, w której klienci mogą publikować recenzje restauracji.
Pragae niedawno nabył Kolację Teraz i chce wprowadzić następujące zmiany:
Zintegruj swoje witryny internetowe, dodając możliwości przeglądu restauracji do kolacji teraz.
Zastąp system płatności Dinner Now systemem Firmy Integratore.
Rozwiń usługę Kolacja teraz w całym regionie.
Kolacja teraz używa SCRUM i eXtreme Programming. Mają bardzo wysokie pokrycie testowe i bardzo mało nieobsługiwanego kodu. Minimalizują ryzyko, tworząc małe, ale działające wersje systemu, a następnie dodając funkcje przyrostowo. Opracowują swój kod w krótkich i częstych iteracji. Dzięki temu często zmieniają się zmiany, refaktoryzują kod i unikają "dużego projektu z góry".
Następnie utrzymuje znacznie większą i złożoną kolekcję systemów, z których część ma ponad 40 lat. Są one bardzo ostrożne w zakresie wprowadzania zmian ze względu na złożoność i zakres starszego kodu. Są one zgodne z bardziej rygorystycznym procesem projektowania, preferując projektowanie szczegółowych rozwiązań oraz dokumentowanie projektu i zmian występujących podczas opracowywania.
Oba zespoły używają diagramów modelowania w programie Visual Studio, aby ułatwić im opracowywanie systemów spełniających potrzeby użytkowników. Używają serwera Team Foundation Server wraz z innymi narzędziami, aby ułatwić im planowanie, organizowanie i zarządzanie pracą.
Aby uzyskać więcej informacji na temat serwera Team Foundation Server, zobacz:
Role diagramów architektury i modelowania w programowaniu oprogramowania
W poniższej tabeli opisano role, które te narzędzia mogą odgrywać w wielu i różnych etapach cyklu życia tworzenia oprogramowania:
| Narzędzie/rola | Modelowanie wymagań użytkownika | Modelowanie procesów biznesowych | Architektura systemu i projektowanie | Wizualizacja i eksploracja kodu | Weryfikacja |
|---|---|---|---|---|---|
| Diagram języka specyficznego dla domeny (DSL) | Tak | Tak | Tak | ||
| Diagram zależności, walidacja warstwy | Tak | Tak | Tak | ||
| Mapa kodu | Tak | Tak | Tak | ||
| Projektant klas (oparte na kodzie) | Tak |
Aby narysować diagramy zależności, należy utworzyć projekt modelowania w ramach istniejącego rozwiązania lub nowego. Te diagramy należy utworzyć w projekcie modelowania. Elementy diagramów zależności znajdują się w projekcie modelowania, ale nie są przechowywane w typowym modelu. Mapy kodu i diagramy klas platformy .NET utworzone na podstawie kodu istnieją poza projektem modelowania.
Zobacz:
Instrukcje: Dodawanie diagramów klas do projektu (Projektant klas)
Modelowanie SDK dla Visual Studio — języki specyficzne dla domeny
Uwaga
Składnik Przekształcanie szablonu tekstu jest automatycznie instalowany w ramach obciążenia programistycznego rozszerzenia programu Visual Studio. Można go również zainstalować na karcie Poszczególne składniki Instalator programu Visual Studio w kategorii Zestawy SDK, biblioteki i struktury. Zainstaluj składnik Zestawu SDK modelowania na karcie Poszczególne składniki.
Oba zespoły używają również weryfikacji zależności, aby upewnić się, że kod w ramach programowania pozostaje zgodny z projektem. Zobacz:
Uwaga
Niektóre wersje programu Visual Studio obsługują walidację zależności i wersje map kodu tylko do odczytu na potrzeby wizualizacji i modelowania. Aby sprawdzić, które wersje programu Visual Studio obsługują tę funkcję, zobacz Obsługa wersji dla narzędzi do architektury i modelowania.
Omówienie i przekazywanie informacji o systemie
Nie ma określonej kolejności używania diagramów modelowania programu Visual Studio, więc można ich używać zgodnie z potrzebami lub podejściem. Zazwyczaj zespoły ponownie przeglądają swoje modele iteracyjnie i często w całym projekcie. Każdy diagram oferuje konkretne mocne strony, które pomagają zrozumieć, opisać i komunikować różne aspekty systemu w ramach opracowywania.
Kolacja Teraz i Pragae komunikują się ze sobą i z uczestnikami projektu przy użyciu diagramów jako wspólnego języka. Na przykład kolacja teraz używa diagramów do wykonywania tych zadań:
Wizualizowanie istniejącego kodu.
Komunikowanie się z Platformą o nowych lub zaktualizowanych historiach użytkowników.
Zidentyfikuj zmiany wymagane do obsługi nowych lub zaktualizowanych historii użytkowników.
Używa diagramów do wykonywania tych zadań:
Dowiedz się więcej o procesie biznesowym Kolacja teraz.
Zapoznaj się z projektem systemu.
Porozumuj się z kolacją Teraz o nowych lub zaktualizowanych wymaganiach użytkownika.
Dokumentuje aktualizacje systemu.
Diagramy są zintegrowane z serwerem Team Foundation Server, dzięki czemu zespoły mogą łatwiej planować i śledzić swoją pracę oraz zarządzać nimi. Na przykład używają modeli do identyfikowania przypadków testowych i zadań programistycznych oraz szacowania ich pracy. Zawiera linki elementów roboczych serwera Team Foundation Server do elementów modelu, dzięki czemu mogą monitorować postęp i upewnić się, że system spełnia wymagania użytkowników. Na przykład łączą przypadki użycia z elementami roboczymi przypadków testowych, aby zobaczyć, że przypadki użycia są spełnione po zakończeniu wszystkich testów.
Zanim zespoły zaewidencjonują zmiany, zweryfikują kod względem testów i projektu, uruchamiając kompilacje, które obejmują walidację zależności i testy automatyczne. Pomaga to upewnić się, że zaktualizowany kod nie powoduje konfliktu z projektem i nie przerywa wcześniej działających funkcji.
Identyfikowanie zmian w istniejącym systemie
Kolacja teraz musi oszacować koszt spełnienia nowego wymagania. Zależy to częściowo od tego, ile ta zmiana wpłynie na inne części systemu. Aby ułatwić im zrozumienie tego, jeden z deweloperów Dinner Now tworzy te mapy i diagramy na podstawie istniejącego kodu:
| Mapa lub diagram | Pokazuje |
|---|---|
| Mapa kodu Zobacz: - Zależności mapy w ramach rozwiązań - Przeglądanie i ponowne rozmieszczanie map kodu - Dostosowanie map kodu przez edycję plików DGML |
Zależności i inne relacje w kodzie. Na przykład kolacja teraz może rozpocząć się od przejrzenia map kodu zestawu w celu omówienia zestawów i ich zależności. Mogą przejść do szczegółów map, aby eksplorować przestrzenie nazw i klasy w tych zestawach. Kolacja Teraz może również tworzyć mapy umożliwiające eksplorowanie określonych obszarów i innych rodzajów relacji w kodzie. Używają Eksplorator rozwiązań do znajdowania i wybierania obszarów i relacji, które je interesują. |
| Diagram klas oparty na kodzie Zobacz Instrukcje: dodawanie diagramów klas do projektów (klasa Projektant). |
Istniejące klasy w kodzie |
Na przykład deweloper tworzy mapę kodu. Dostosowuje swój zakres, aby skupić się na obszarach, które będą miały wpływ na nowy scenariusz. Te obszary są zaznaczone i wyróżnione na mapie:
Mapa kodu przestrzeni nazw
Deweloper rozszerza wybrane przestrzenie nazw, aby zobaczyć ich klasy, metody i relacje:
Rozszerzona mapa kodu przestrzeni nazw z widocznymi linkami między grupami
Deweloper analizuje kod w celu znalezienia klas i metod, których dotyczy problem. Aby zobaczyć efekty każdej zmiany podczas ich wprowadzania, ponownie wygeneruj mapy kodu po każdej zmianie. Zobacz Wizualizowanie kodu.
Aby opisać zmiany w innych częściach systemu, takie jak składniki lub interakcje, zespół może narysować te elementy na tablicach. Mogą one również narysować następujące diagramy w programie Visual Studio, aby można było przechwycić, zarządzać i zrozumieć szczegóły obu zespołów:
| Diagramy | Opisuje |
|---|---|
| Diagram klas oparty na kodzie Zobacz Instrukcje: dodawanie diagramów klas do projektów (klasa Projektant). |
Istniejące klasy w kodzie. |
Zachowaj spójność kodu z projektem
Kolacja teraz musi upewnić się, że zaktualizowany kod pozostaje zgodny z projektem. Tworzą diagramy zależności, które opisują warstwy funkcjonalności w systemie, określają dozwolone zależności między nimi i kojarzą artefakty rozwiązania z tymi warstwami.
| Diagram | Opisuje |
|---|---|
| Diagram zależności Zobacz: - Tworzenie diagramów zależności z kodu - Diagramy zależności: Odwołanie - Diagramy zależności: Wskazówki - Weryfikacja kodu przy użyciu diagramów zależności |
Logiczna architektura kodu. Diagram zależności organizuje i mapuje artefakty w rozwiązaniu programu Visual Studio na abstrakcje grup nazywanych warstwami. Te warstwy identyfikują role, zadania lub funkcje wykonywane przez te artefakty w systemie. Diagramy zależności są przydatne do opisywania zamierzonego projektu systemu i weryfikowania zmieniającego się kodu względem tego projektu. Aby utworzyć warstwy, przeciągnij elementy z Eksplorator rozwiązań, mapy kodu, widok klas i przeglądarkę obiektów. Aby narysować nowe warstwy, użyj przybornika lub kliknij prawym przyciskiem myszy powierzchnię diagramu. Aby wyświetlić istniejące zależności, kliknij prawym przyciskiem myszy powierzchnię diagramu zależności, a następnie kliknij polecenie Generuj zależności. Aby określić zamierzone zależności, rysuj nowe zależności. |
Na przykład na poniższym diagramie zależności opisano zależności między warstwami i liczbą artefaktów skojarzonych z każdą warstwą:
Diagram zależności
Aby upewnić się, że konflikty z projektem nie występują podczas tworzenia kodu, zespoły używają weryfikacji zależności w kompilacjach uruchamianych w usłudze Azure DevOps. Tworzą również niestandardowe zadanie MSBuild, aby wymagać weryfikacji zależności w operacjach ewidencjonowania. Używają raportów kompilacji do zbierania błędów walidacji.
Zobacz:
Ogólne Wskazówki tworzenia i używania modeli
Większość diagramów składa się z węzłów połączonych wierszami. Dla każdego typu diagramu przybornik zawiera różne rodzaje węzłów i linii.
Aby otworzyć przybornik, w menu Widok kliknij pozycję Przybornik.
Aby utworzyć węzeł, przeciągnij go z przybornika do diagramu. Niektóre rodzaje węzłów muszą być przeciągane do istniejących węzłów. Na przykład na diagramie składników należy dodać nowy port do istniejącego składnika.
Aby utworzyć wiersz lub połączenie, kliknij odpowiednie narzędzie w przyborniku, kliknij węzeł źródłowy, a następnie kliknij węzeł docelowy. Niektóre wiersze można tworzyć tylko między niektórymi rodzajami węzłów. Po przeniesieniu wskaźnika do możliwego źródła lub obiektu docelowego wskaźnik wskazuje, czy można utworzyć połączenie.
Planowanie i śledzenie pracy
Diagramy modelowania programu Visual Studio są zintegrowane z programem Team Foundation Server, dzięki czemu można łatwiej planować i śledzić pracę oraz zarządzać nimi. Oba zespoły używają modeli do identyfikowania przypadków testowych i zadań programistycznych oraz szacowania ich pracy. Interfejs Apie tworzy i łączy elementy robocze serwera Team Foundation Server z elementami modelu, takimi jak przypadki użycia lub składniki. Pomaga to monitorować postęp i śledzić ich pracę z powrotem do wymagań użytkowników. Pomaga to im upewnić się, że ich zmiany nadal spełniają te wymagania.
W miarę postępu pracy zespoły aktualizują swoje elementy robocze, aby odzwierciedlały czas spędzony na swoich zadaniach. Monitorują również stan pracy i zgłaszają je przy użyciu następujących funkcji serwera Team Foundation Server:
Codzienne spalenie raportów , które pokazują, czy zakończą planowaną pracę w oczekiwanym czasie. Generują inne podobne raporty z serwera Team Foundation Server w celu śledzenia postępu usterek.
Arkusz iteracji, który korzysta z programu Microsoft Excel, aby ułatwić zespołowi monitorowanie i równoważenie obciążenia między jego członkami. Ten arkusz jest połączony z serwerem Team Foundation Server i koncentruje się na dyskusji podczas regularnych spotkań postępu.
Pulpit nawigacyjny programowania korzystający z programu Office Project do informowania zespołu o ważnych informacjach o projekcie.
Zobacz:
Informacje o narzędziach Agile i zarządzaniu projektami Agile
Wykresy, pulpity nawigacyjne i widżety (Azure DevOps Services)
Testowanie, weryfikowanie i Synchronizacja kod
Gdy zespoły wykonują każde zadanie, sprawdzają swój kod w kontroli źródła i otrzymują przypomnienia z serwera Team Foundation Server, jeśli zapomną. Zanim serwer Team Foundation Server zaakceptuje swoje ewidencjonowania, zespoły uruchamiają testy jednostkowe i walidację zależności, aby zweryfikować kod pod kątem przypadków testowych i projektu. Używają serwera Team Foundation Server do regularnego uruchamiania kompilacji, zautomatyzowanych testów jednostkowych i walidacji zależności. Pomaga to upewnić się, że kod spełnia następujące kryteria:
To działa.
Nie powoduje to przerwania wcześniej działającego kodu.
Nie powoduje konfliktu z projektem.
Kolacja Teraz ma dużą kolekcję testów automatycznych, które Może być ponownie używane, ponieważ prawie wszystkie nadal mają zastosowanie. Może również opierać się na tych testach i dodawać nowe, aby uwzględnić nowe funkcje. Oba programy używają również programu Visual Studio do uruchamiania testów ręcznych.
Aby upewnić się, że kod jest zgodny z projektem, zespoły konfigurują kompilacje w usłudze Azure DevOps w celu uwzględnienia walidacji zależności. Jeśli wystąpią jakiekolwiek konflikty, raport zostanie wygenerowany ze szczegółami.
Zobacz:
Aktualizowanie systemu przy użyciu wizualizacji i modelowania
Powinna teraz zintegrować swoje systemy płatności. W poniższych sekcjach przedstawiono diagramy modelowania w programie Visual Studio, które ułatwiają wykonywanie tego zadania:
Zobacz:
Wizualizowanie istniejącego kodu: Mapy kodu
Mapy kodu pokazują bieżącą organizację i relacje w kodzie. Elementy są reprezentowane przez węzły na mapie, a relacje są reprezentowane przez łącza. Mapy kodu mogą ułatwić wykonywanie następujących rodzajów zadań:
Zapoznaj się z nieznanym kodem.
Dowiedz się, gdzie i w jaki sposób proponowana zmiana może mieć wpływ na istniejący kod.
Znajdź obszary złożoności, naturalne zależności lub wzorce lub inne obszary, które mogą korzystać z poprawy.
Na przykład kolacja teraz musi oszacować koszt aktualizacji składnika PaymentProcessing. Zależy to częściowo od tego, ile ta zmiana wpłynie na inne części systemu. Aby pomóc im to zrozumieć, jeden z deweloperów Dinner Now generuje mapy kodu z kodu i dostosowuje zakres fokusu na obszarach, które mogą mieć wpływ na zmianę.
Na poniższej mapie przedstawiono zależności między klasą PaymentProcessing a innymi częściami systemu Kolacja teraz, które są wyświetlane jako wybrane:
Mapa kodu dla systemu płatności Kolacja teraz
Deweloper bada mapę, rozwijając klasę PaymentProcessing i wybierając jej składowe, aby zobaczyć obszary, których potencjalnie dotyczy problem:
Metody wewnątrz klasy PaymentProcessing i ich zależności
Wygenerują następującą mapę dla systemu płatności w Integratorze, aby sprawdzić jego klasy, metody i zależności. Zespół widzi, że system Integratore może również wymagać pracy w celu interakcji z innymi częściami kolacji Teraz:
Mapa kodu dla systemu płatności Firmy Integratore
Oba zespoły współpracują ze sobą, aby określić zmiany wymagane do zintegrowania tych dwóch systemów. Decydują się na refaktoryzację niektórych kodu, aby ułatwić aktualizowanie. Klasa PaymentApprover zostanie przeniesiona do przestrzeni nazw DinnerNow.Business i będzie wymagać pewnych nowych metod. Klasy Dinner Now, które obsługują transakcje, będą miały własną przestrzeń nazw. Zespoły tworzą elementy robocze i używają ich do planowania, organizowania i śledzenia ich pracy. Łączą elementy robocze z elementami modelu, w których jest to przydatne.
Po reorganizacji kodu zespoły generują nową mapę kodu, aby zobaczyć zaktualizowaną strukturę i relacje:
Mapa kodu z reorganizacją kodu
Ta mapa pokazuje, że klasa PaymentApprover znajduje się teraz w przestrzeni nazw DinnerNow.Business i ma kilka nowych metod. Klasy transakcji Dinner Now mają teraz własną przestrzeń nazw PaymentSystem, co ułatwia późniejsze radzenie sobie z tym kodem.
Tworzenie mapy kodu
Aby uzyskać szybki przegląd kodu źródłowego, wykonaj następujące kroki, aby wygenerować mapę kodu:
W menu Architektura kliknij pozycję Generuj mapę kodu dla rozwiązania.
Aby uzyskać szybki przegląd skompilowanego kodu, utwórz pustą mapę kodu, a następnie przeciągnij pliki zestawów lub pliki binarne na powierzchnię mapy.
Aby eksplorować określony kod lub elementy rozwiązania, użyj Eksplorator rozwiązań, aby wybrać elementy i relacje, które chcesz wizualizować. Następnie możesz wygenerować nową mapę lub dodać wybrane elementy do istniejącej mapy. Zobacz Mapowania zależności między rozwiązaniami.
Aby ułatwić eksplorowanie mapy, zmień układ tak, aby odpowiadał on rodzajom zadań, które chcesz wykonać.
Aby na przykład wizualizować warstwy w kodzie, wybierz układ drzewa. Zobacz Przeglądanie i rozmieszczanie map kodu.
Podsumowanie: Mocne strony Mapy kodu
Mapy kodu ułatwiają:
Dowiedz się więcej o organizacji i relacjach w istniejącym kodzie.
Zidentyfikuj obszary, na które może mieć wpływ proponowana zmiana.
Znajdź obszary złożoności, wzorców, warstw lub innych obszarów, które można ulepszyć, aby ułatwić konserwację, zmienianie i ponowne używanie kodu.
Związek z innymi diagramami
| Diagram | Opisuje |
|---|---|
| Diagram zależności | Logiczna architektura systemu. Użyj walidacji zależności, aby upewnić się, że kod pozostaje spójny z projektem. Aby ułatwić identyfikowanie istniejących zależności lub zamierzonych zależności, utwórz mapę kodu i elementy powiązane z grupą. Aby utworzyć diagram zależności, zobacz: - Tworzenie diagramów zależności z kodu - Diagramy zależności: Wskazówki |
| Diagram klas (oparty na kodzie) | Istniejące klasy w kodzie dla określonego projektu. Aby wizualizować i modyfikować istniejącą klasę w kodzie, użyj Projektant klasy. Zobacz Instrukcje: dodawanie diagramów klas do projektów (klasa Projektant). |
Definiowanie słownika typów: diagramy klas
Diagramy klas definiują jednostki, terminy lub pojęcia, które uczestniczą w systemie i ich relacjach ze sobą. Na przykład można użyć tych diagramów podczas programowania, aby opisać atrybuty i operacje dla każdej klasy, niezależnie od ich języka implementacji lub stylu.
Aby pomóc Firmom opisywać i omawiać jednostki, które uczestniczą w przypadku użycia płatności procesowych, narysują następujący diagram klasy:
Przetwarzanie jednostek płatności na diagramie klasy
Na tym diagramie pokazano, że klient może mieć wiele zamówień i różne sposoby płacenia za zamówienia. BankAccount i CreditCard dziedziczą po płatności.
W trakcie opracowywania Firma Używa następującego diagramu klasy do opisania i omówienia szczegółów każdej klasy:
Przetwarzanie szczegółów płatności na diagramie klasy
Rysowanie diagramu klas
Diagram klas ma następujące główne funkcje:
Typy, takie jak klasy, interfejsy i wyliczenia:
Klasa to definicja obiektów, które mają określone cechy strukturalne lub behawioralne.
Interfejs definiuje część zewnętrznego widocznego zachowania obiektu.
Wyliczenie to klasyfikator zawierający listę wartości literałów.
Atrybuty to wartości określonego typu, które opisują każde wystąpienie klasyfikatora. Klasyfikator to ogólna nazwa typów, składników, przypadków użycia, a nawet aktorów.
Operacje to metody lub funkcje, które mogą wykonywać wystąpienia klasyfikatora.
Skojarzenie wskazuje jakiś rodzaj relacji między dwoma klasyfikatorami.
Agregacja to skojarzenie wskazujące współdzieloną własność między klasyfikatorami.
Kompozycja jest skojarzeniem wskazującym relację całościową między klasyfikatorami.
Aby wyświetlić agregacje lub kompozycje, ustaw właściwość Agregacja dla skojarzenia. Udostępnione pokazuje agregacje i złożone pokazuje kompozycje.
Zależność wskazuje, że zmiana definicji jednego klasyfikatora może zmienić definicję innego klasyfikatora.
Uogólnienie wskazuje, że określony klasyfikator dziedziczy część swojej definicji z klasyfikatora ogólnego. Realizacja wskazuje, że klasa implementuje operacje i atrybuty oferowane przez interfejs.
Aby utworzyć te relacje, użyj narzędzia Dziedziczenie . Alternatywnie realizacja może być reprezentowana jako lizak.
Pakiety to grupy klasyfikatorów, skojarzeń, linii życia, składników i innych pakietów. Relacje importu wskazują, że jeden pakiet zawiera wszystkie definicje innego pakietu.
Jako punkt wyjścia do eksplorowania i omawiania istniejących klas można użyć klasy Projektant do tworzenia diagramów klas na podstawie kodu.
Podsumowanie: Mocne strony diagramów klas
Diagramy klas ułatwiają definiowanie:
Wspólny słownik terminów do użycia podczas omawiania potrzeb użytkowników i jednostek uczestniczących w systemie. Zobacz Wymagania użytkownika modelu.
Typy używane przez części systemu, takie jak składniki, niezależnie od ich implementacji. Zobacz Modelowanie architektury aplikacji.
Relacje, takie jak zależności, między typami. Można na przykład pokazać, że jeden typ może być skojarzony z wieloma wystąpieniami innego typu.
Związek z innymi diagramami
| Diagram | Opis |
|---|---|
| Diagram zależności | Zdefiniuj logiczną architekturę systemu w odniesieniu do klas. Użyj walidacji zależności, aby upewnić się, że kod pozostaje spójny z projektem. Zobacz: - Tworzenie diagramów zależności z kodu - Diagramy zależności: Odwołanie - Diagramy zależności: Wskazówki - Weryfikacja kodu przy użyciu diagramów zależności |
| Mapa kodu | Wizualizowanie organizacji i relacji w istniejącym kodzie. Aby zidentyfikować klasy, ich relacje i metody, utwórz mapę kodu, która pokazuje te elementy. Zobacz: - Zależności mapy w ramach rozwiązań |
Opis architektury logicznej: diagramy zależności
Diagramy zależności opisują logiczną architekturę systemu, organizując artefakty w rozwiązaniu w grupach abstrakcyjnych lub warstwach. Artefakty mogą być wieloma rzeczami, takimi jak przestrzenie nazw, projekty, klasy, metody itd. Warstwy reprezentują i opisują role lub zadania wykonywane przez artefakty w systemie. Możesz również uwzględnić walidację warstwy w operacjach kompilacji i ewidencjonowania, aby upewnić się, że kod pozostaje zgodny z jego projektem.
Aby zachować spójność kodu z projektem, Dinner Now i Pragae użyj następującego diagramu zależności, aby zweryfikować swój kod w miarę rozwoju:
Diagram zależności dla kolacji teraz zintegrowany z Pakietem
Warstwy na tym diagramie łączą się z odpowiednimi artefaktami rozwiązania Dinner Now (Kolacja teraz) i Firme .. Na przykład warstwa Biznesowa łączy się z przestrzenią nazw DinnerNow.Business i jej elementami członkowskimi, które teraz obejmują klasę PaymentApprover. Warstwa dostępu do zasobów łączy się z przestrzenią 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. Gdy zespoły aktualizują swój kod, walidacja warstw jest wykonywana regularnie w celu przechwytywania konfliktów w miarę ich występowania i szybkiego rozwiązywania problemów przez zespoły.
Zespoły współpracują ze sobą, aby stopniowo integrować i testować dwa systemy. Najpierw upewniają się, że usługa PaymentApprover i reszta kolacji teraz współpracują ze sobą pomyślnie przed rozpoczęciem przetwarzania płatności.
Poniższa mapa kodu przedstawia nowe wywołania między aplikacją Dinner Now i PaymentApprover:
Mapa kodu ze zaktualizowanymi wywołaniami metod
Po potwierdzeniu, że system działa zgodnie z oczekiwaniami, Kolacja teraz komentuje kod PaymentProcessing. Raporty sprawdzania poprawności warstwy są czyste, a wynikowa mapa kodu pokazuje, że nie istnieją już zależności PaymentProcessing:
Mapa kodu bez przetwarzania płatności
Rysowanie diagramu zależności
Diagram zależności ma następujące główne funkcje:
Warstwy opisują logiczne grupy artefaktów.
Łącze to skojarzenie między warstwą a artefaktem.
Aby utworzyć warstwy na podstawie artefaktów, przeciągnij elementy z Eksplorator rozwiązań, mapy kodu, widok klas lub przeglądarkę obiektów. Aby narysować nowe warstwy, a następnie połączyć je z artefaktami, użyj przybornika lub kliknij prawym przyciskiem myszy powierzchnię diagramu, aby utworzyć warstwy, a następnie przeciągnij elementy do tych warstw.
Liczba w warstwie pokazuje liczbę artefaktów połączonych z warstwą. Te artefakty mogą być przestrzeniami nazw, projektami, klasami, metodami itd. Podczas interpretowania liczby artefaktów w warstwie należy pamiętać o następujących kwestiach:
Jeśli warstwa jest połączona z artefaktem zawierającym inne artefakty, ale warstwy nie łączy się bezpośrednio z innymi artefaktami, wówczas liczba uwzględnia tylko połączony artefakt. Jednak inne artefakty są uwzględniane w analizie podczas walidacji 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 uwzględniać 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 uwzględnia tych artefaktów.
Aby wyświetlić artefakty połączone z warstwą, kliknij prawym przyciskiem myszy zależność, a następnie kliknij polecenie Wyświetl łącza , aby otworzyć Eksploratora warstw.
Zależność wskazuje, że jedna warstwa może używać funkcji w innej warstwie, ale nie odwrotnie. Zależność dwukierunkowa wskazuje, że jedna warstwa może używać funkcji w innej warstwie i na odwrót.
Aby wyświetlić istniejące zależności na diagramie zależności, kliknij prawym przyciskiem myszy powierzchnię diagramu, a następnie kliknij polecenie Generuj zależności. Aby opisać zamierzone zależności, rysuj nowe.
Zobacz:
Podsumowanie: Mocne strony diagramów zależności
Diagramy zależności ułatwiają:
Opis logicznej architektury systemu zgodnie z funkcjami jego artefaktów.
Upewnij się, że kod w ramach programowania jest zgodny z określonym projektem.
Związek z innymi diagramami
| Diagram | Opis |
|---|---|
| Mapa kodu | Wizualizowanie organizacji i relacji w istniejącym kodzie. Aby utworzyć warstwy, wygeneruj mapę kodu, a następnie grupuj elementy na mapie jako potencjalne warstwy. Przeciągnij grupy z mapy do diagramu zależności. Zobacz: - Zależności mapy w ramach rozwiązań - Przeglądanie i ponowne rozmieszczanie map kodu |
Zasoby zewnętrzne
| Kategoria | Linki |
|---|---|
| Fora | - Narzędzia wizualizacji i modelowania programu Visual Studio - Visual Studio Visualization & Modeling SDK (DSL Tools) |