Używanie modeli w procesie tworzenia aplikacji

W programie Visual Studio możesz użyć modelu, aby ułatwić zrozumienie i zmianę systemu, aplikacji lub składnika. Model może pomóc w wizualizacji świata, w którym działa system, wyjaśnić potrzeby użytkowników, zdefiniować architekturę systemu, przeanalizować kod i upewnić się, że kod spełnia wymagania.

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

Modele mogą pomóc na kilka sposobów:

• Diagramy modelowania rysunku ułatwiają wyjaśnienie pojęć związanych z wymaganiami, architekturą i projektowaniem wysokiego poziomu. Aby uzyskać więcej informacji, zobacz Model user requirements (Wymagania użytkownika modelu).

• Praca z modelami może pomóc w ujawnieniu niespójności w wymaganiach.

• Komunikacja z modelami ułatwia komunikowanie ważnych pojęć mniej niejednoznacznie niż w przypadku języka naturalnego. Aby uzyskać więcej informacji, zobacz Modelowanie architektury aplikacji.

• Czasami można używać modeli do generowania kodu lub innych artefaktów, takich jak schematy bazy danych lub dokumenty. Na przykład składniki modelowania programu Visual Studio są generowane na podstawie modelu. Aby uzyskać więcej informacji, zobacz Generowanie i konfigurowanie aplikacji na podstawie modeli.

Modele można używać w wielu różnych procesach, od ekstremalnej elastyczności do wysokiej ceremonii.

Używanie modeli w celu zmniejszenia niejednoznaczności

Język modelowania jest mniej niejednoznaczny niż język naturalny i jest przeznaczony do wyrażania pomysłów zwykle wymaganych podczas tworzenia oprogramowania.

Jeśli projekt ma niewielki zespół przestrzega praktyk agile, możesz użyć modeli, aby ułatwić wyjaśnienie scenariuszy użytkowników. W dyskusjach z klientem na temat ich potrzeb tworzenie modelu może generować przydatne pytania znacznie szybciej i w szerszym obszarze produktu niż pisanie skokowego lub prototypowego kodu.

Jeśli projekt jest duży i obejmuje zespoły w różnych częściach świata, możesz użyć modeli, aby ułatwić bardziej efektywne komunikowanie wymagań i architektury niż w postaci zwykłego tekstu.

W obu przypadkach tworzenie modelu prawie zawsze powoduje znaczne zmniejszenie niespójności i niejednoznaczności. Różne osoby biorące udział w projekcie często mają różne informacje na temat świata biznesowego, w którym działa system, a różni deweloperzy często mają różne informacje na temat działania systemu. Użycie modelu jako fokusu dyskusji zwykle uwidacznia te różnice. Aby uzyskać więcej informacji na temat sposobu używania modelu w celu zmniejszenia niespójności, zobacz Wymagania użytkownika modelu.

Używanie modeli z innymi artefaktami

Model nie jest samą specyfikacją wymagań ani architekturą. Jest to narzędzie do wyrażania niektórych aspektów tych rzeczy bardziej wyraźnie, ale nie wszystkie pojęcia wymagane podczas projektowania oprogramowania można wyrazić. W związku z tym modele powinny być używane razem z innymi środkami komunikacji, takimi jak strony programu OneNote lub akapity, dokumenty pakietu Microsoft Office, elementy robocze w programie Team Foundation lub przyklejne notatki na ścianie pomieszczenia projektu. Oprócz ostatniego elementu wszystkie te typy obiektów mogą być połączone z elementami części modelu.

Inne aspekty specyfikacji, które są zwykle używane razem z modelami, obejmują następujące elementy. W zależności od skali i stylu projektu można użyć kilku z tych aspektów lub w ogóle nie używać ich:

• Scenariusze użytkownika. Historia użytkownika to krótki opis, omówiony z użytkownikami i innymi uczestnikami projektu, aspekt zachowania systemu, który zostanie dostarczony w jednej z iteracji projektu. Typowy scenariusz użytkownika rozpoczyna się "Klient będzie mógł...." Historia użytkownika może wprowadzić grupę przypadków użycia lub zdefiniować rozszerzenia przypadków użycia, które zostały wcześniej opracowane. Definiowanie lub rozszerzanie przypadków użycia ułatwia czytelne określenie historii użytkownika.

• Żądania zmiany. Żądanie zmiany w bardziej formalnym projekcie jest bardzo podobne do historii użytkownika w projekcie agile. Podejście zwinne traktuje wszystkie wymagania jako zmiany tego, co zostało opracowane w poprzednich iteracji.

• Opis przypadku użycia. Przypadek użycia reprezentuje jeden ze sposobów, w jaki użytkownik wchodzi w interakcję z systemem w celu osiągnięcia określonego celu. Pełny opis zawiera cele, główne i alternatywne sekwencje zdarzeń oraz wyjątkowe wyniki. Diagram przypadku użycia pomaga podsumować i przedstawić omówienie przypadków użycia.

• Scenariusze. Scenariusz to dość szczegółowy opis sekwencji zdarzeń pokazujący, jak system, użytkownicy i inne systemy współpracują ze sobą, aby zapewnić korzyści uczestnikom projektu. Może to mieć postać pokazu slajdów interfejsu użytkownika lub prototypu interfejsu użytkownika. Może on opisywać jeden przypadek użycia lub sekwencję przypadków użycia.

• Glosariusz. Słownik wymagań projektu opisuje słowa, z którymi klienci dyskutują swój świat. Interfejs użytkownika i modele wymagań powinny również używać tych terminów. Diagram klas może pomóc wyjaśnić relacje między większością tych terminów. Tworzenie diagramów i słownika nie tylko zmniejsza nieporozumienie między użytkownikami i deweloperami, ale także prawie zawsze ujawnia nieporozumienia między różnymi uczestnikami projektu biznesowego.

• Reguły biznesowe. Wiele reguł biznesowych można wyrazić jako niezmienne ograniczenia skojarzeń i atrybutów w modelu klas wymagań oraz jako ograniczenia dotyczące diagramów sekwencji.

• Projekt wysokiego poziomu. Opisuje główne części i sposób ich dopasowania. Diagramy składników, sekwencji i interfejsów są główną częścią projektu wysokiego poziomu.

• Wzorce projektowe. Opisz reguły projektowania, które są współużytkowane w różnych częściach systemu.

• Specyfikacje testowe. Skrypty testowe i projekty kodu testowego mogą dobrze wykorzystać diagramy działań i sekwencji do opisywania sekwencji kroków testów. Testy systemowe należy wyrazić pod względem modelu wymagań, aby można je było łatwo zmienić po zmianie wymagań.

• Plan projektu. Plan projektu lub zaległości definiuje, kiedy każda funkcja zostanie dostarczona. Każdą funkcję można zdefiniować, określając przypadki użycia i reguły biznesowe, które implementuje lub rozszerza. Możesz odwołać się do przypadków użycia i reguł biznesowych bezpośrednio w planie lub zdefiniować zestaw funkcji w osobnym dokumencie i użyć tytułów funkcji w planie.

Korzystanie z modeli w planowaniu iteracji

Mimo że wszystkie projekty różnią się w ich skali i organizacji, typowy projekt jest planowany jako seria iteracji z zakresu od dwóch do sześciu tygodni. Ważne jest, aby zaplanować wystarczającą liczbę iteracji, aby umożliwić przekazywanie opinii od wczesnych iteracji w celu dostosowania zakresu i planów dla późniejszych iteracji.

Poniższe sugestie mogą ułatwić realizację korzyści z modelowania w projekcie iteracyjnym.

Wyostrzanie fokusu w miarę zbliżania się każdej iteracji

W miarę zbliżania się każdej iteracji użyj modeli, aby określić, co należy dostarczyć na końcu iteracji.

• Nie modeluj wszystkiego szczegółowo we wczesnych iteracji. W pierwszej iteracji utwórz diagram klasy dla głównych elementów w słowniku użytkownika, narysuj diagram głównych przypadków użycia i narysuj diagram głównych składników. Nie opisz żadnego z tych elementów szczegółowo, ponieważ szczegóły zmienią się później w projekcie. Użyj terminów zdefiniowanych w tym modelu, aby utworzyć listę funkcji lub głównych scenariuszy użytkownika. Przypisz funkcje do iteracji, aby w przybliżeniu zrównoważyć szacowane obciążenie w całym projekcie. Te przypisania zmienią się później w projekcie.

• Spróbuj zaimplementować uproszczone wersje wszystkich najważniejszych przypadków użycia we wczesnej iteracji. Rozszerz te przypadki użycia w kolejnych iteracji. Takie podejście pomaga zmniejszyć ryzyko wykrycia wady wymagań lub architektury zbyt późno w projekcie, aby coś z tym zrobić.

• Pod koniec każdej iteracji zorganizuj warsztaty dotyczące wymagań, aby szczegółowo zdefiniować wymagania lub scenariusze użytkowników, które zostaną opracowane w następnej iteracji. Zaproś użytkowników i uczestników projektu biznesowego, którzy mogą decydować o priorytetach, a także deweloperów i testerów systemów. Zezwól na trzy godziny na zdefiniowanie wymagań dotyczących iteracji dwutygodniowej.

• Celem warsztatu jest dla wszystkich, aby uzgodnić, co zostanie osiągnięte do końca następnej iteracji. Użyj modeli jako jednego z narzędzi, aby ułatwić wyjaśnienie wymagań. Wynikiem warsztatu jest lista prac iteracji: czyli lista zadań programistycznych w programie Team Foundation i zestawach testów w programie Microsoft Test Manager.

• W warsztatach dotyczących wymagań omówimy projekt tylko w zakresie, w jakim trzeba określić szacunki dla zadań programistycznych. W przeciwnym razie należy zachować dyskusję na temat zachowania systemu, które użytkownicy mogą bezpośrednio doświadczyć. Zachowaj oddzielny model wymagań od modelu architektonicznego.

• Nietechniczne osoby biorące udział w projekcie zwykle nie mają problemów ze zrozumieniem diagramów UML, z pewnymi wskazówkami od Ciebie.

Łączenie modelu z elementami roboczymi

Po warsztatach dotyczących wymagań opracuj szczegóły modelu wymagań i połącz model z zadaniami programistycznymi. Można to zrobić, łącząc elementy robocze w programie Team Foundation z elementami w modelu.

Dowolny element można połączyć z elementami roboczymi, ale najbardziej przydatne elementy są następujące:

• Komentarze opisujące reguły biznesowe lub wymagania dotyczące jakości usług. Aby uzyskać więcej informacji, zobacz Model user requirements (Wymagania użytkownika modelu).

Łączenie modelu z testami

Użyj modelu wymagań, aby kierować projektowaniem testów akceptacyjnych. Utwórz te testy jednocześnie przy użyciu pracy programistycznej.

Aby dowiedzieć się więcej na temat tej techniki, zobacz Tworzenie testów na podstawie modelu.

Szacowanie pozostałej pracy

Model wymagań może pomóc oszacować całkowity rozmiar projektu w odniesieniu do rozmiaru każdej iteracji. Ocena liczby i złożoności przypadków użycia i klas może pomóc oszacować wymaganą pracę programistyczną. Po zakończeniu kilku pierwszych iteracji porównanie uwzględnionych wymagań i wymagania, które należy uwzględnić, mogą dać przybliżoną miarę kosztów i zakresu pozostałej części projektu.

Pod koniec każdej iteracji przejrzyj przypisanie wymagań do przyszłych iteracji. Może być przydatne reprezentowanie stanu oprogramowania na końcu każdej iteracji jako podsystemu na diagramie przypadków użycia. W dyskusjach można przenosić przypadki użycia i rozszerzenia przypadków użycia z jednego z tych podsystemów do innego.

Poziomy abstrakcji

Modele mają szereg abstrakcji w odniesieniu do oprogramowania. Najbardziej konkretne modele bezpośrednio reprezentują kod programu, a najbardziej abstrakcyjne modele reprezentują koncepcje biznesowe, które mogą lub nie mogą być reprezentowane w kodzie.

Model można wyświetlić za pomocą kilku rodzajów diagramów. Aby uzyskać informacje o modelach i diagramach, zobacz Tworzenie modeli dla aplikacji.

Różne rodzaje diagramów są przydatne do opisywania projektu na różnych poziomach abstrakcji. Wiele typów diagramów jest przydatnych na więcej niż jednym poziomie. W tej tabeli przedstawiono sposób użycia każdego typu diagramu.

Poziom projektu	Typy diagramów
Proces biznesowy Zrozumienie kontekstu, w którym będzie używany system, pomaga zrozumieć, czego potrzebują użytkownicy.	— Diagramy klas koncepcyjnych opisują pojęcia biznesowe używane w procesie biznesowym.
Wymagania użytkownika Definicja potrzeb użytkowników z systemu.	- Reguły biznesowe i wymagania dotyczące jakości usług można opisać w oddzielnych dokumentach.
Projekt wysokiego poziomu Ogólna struktura systemu: główne składniki i sposób ich łączenia.	- Diagramy zależności opisują, jak system jest ustrukturyzowany na współzależności części. Kod programu można zweryfikować na diagramach zależności, aby upewnić się, że jest on zgodny z architekturą.
Analiza kodu Diagramy można wygenerować na podstawie kodu.	— Diagramy zależności pokazują zależności między klasami. Zaktualizowany kod można zweryfikować na diagramie zależności. - Diagramy klas pokazują klasy w kodzie.

Zasoby zewnętrzne

Kategoria	Linki
Filmy wideo	Wideo w witrynie MSDN: Tworzenie i używanie modeli i diagramów UML (Visual Studio Ultimate) MSDN How Do I Series: UML Tools and Extensibility (Visual Studio Ultimate)
Fora	- Narzędzia wizualizacji i modelowania programu Visual Studio - Visual Studio Visualization & Modeling SDK (DSL Tools)
Blogi	Microsoft DevOps
Artykuły techniczne i czasopisma	Centrum architektury MSDN

Powiązana zawartość

• Korzystanie z modeli w programach Agile
• Tworzenie modeli aplikacji
• Wymagania modelu użytkownika
• Modelowanie architektury aplikacji
• Opracowywanie testów na podstawie modelu
• Tworzenie struktury rozwiązania modelowania

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.