Korzystanie z modeli podczas procesu projektowania

Artykuł
06/10/2015

W Visual Studio Ultimate, można użyć modelu, aby ułatwić zrozumienie i zmienić systemu, aplikacji lub składnika.Model może pomóc w wizualizacji świata, w którym system działa, wyjaśnienia potrzeb użytkowników, określenia struktury przyszłego systemu, analizować kod i sprawdzić, czy Twój kod spełnia wymagania.

Zobacz kanału 9 wideo: poprawy architektury przez modelowanie.

Jak używać modeli

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

Diagramy modelowania rysunku pomaga wyjaśnienia pojęciami związanymi z wymagań, architektury i projektowania wysokiego poziomu.Aby uzyskać więcej informacji, zobacz Modelowanie — Wymagania dla użytkownika.
Praca z modelami może pomóc w wystawiać niespójności w wymaganiach.
Komunikowanie się z modeli pomaga komunikować się ważne pojęcia niecałe niejednoznacznie z użyciem języka naturalnego.Aby uzyskać więcej informacji, zobacz Modelowanie architektury oprogramowania.
Modele niekiedy mogą być używane do generowania kodu lub inne przedmioty, takie jak schematy bazy danych lub dokumentów.Na przykład składniki modelowania z Visual Studio Ultimate są generowane z modelu.Aby uzyskać więcej informacji, zobacz Generowanie i konfigurowanie aplikacji z modeli.

Można użyć modeli w wielu różnych procesów, od krańcowych ceremonii agile wysoki.

Korzystania z modeli w celu zmniejszenia niejednoznaczności

Język modelowania jest mniej niejednoznaczna niż języka naturalnego, i jest przeznaczony do realizowania pomysłów, zazwyczaj wymagane podczas tworzenia oprogramowania.

Jeżeli projekt zawiera małych zespołów zgodnie z praktyki agile, można użyć modeli, aby pomóc w określeniu historyjek użytkownika.W dyskusjach z klientem dotyczące ich potrzeb w zakresie tworzenia modelu może generować właściwe pytania znacznie szybciej, a na szerszym obszarze produktu, niż pisanie kodu kolekcji lub prototypu.

Jeśli projekt jest duży i zawiera zespołów w różnych częściach świata, można użyć modeli, aby pomóc w przekazaniu wymagań i architektury bardziej efektywnie, niż można w postaci zwykłego tekstu.

W obu przypadkach tworzenia modelu prawie zawsze powoduje znaczne zmniejszenie niespójności i niejasności.Zainteresowane podmioty często mają różne rozumienie świata biznesu, w którym działa system, a poszczególni programiści często mają różne rozumienie tego, jak działa system.Za pomocą modelu jako tematem dyskusji zwykle uwidacznia tych różnic.Aby uzyskać więcej informacji na temat używania modelu ograniczenie niespójności, zobacz Modelowanie — Wymagania dla użytkownika.

Inne przedmioty za pomocą modeli

Model nie jest sama specyfikacji wymagań lub architekturze.Jest to narzędzie do wyrażania wartości niektórych aspektów tych rzeczy, Jaśniej, ale nie wszystkie pojęć, które są wymagane podczas projektowania oprogramowania może być wyrażona.Modele powinna być używana razem z innych środków komunikacji, takie jak program OneNote strony lub akapity, dokumentów programu Microsoft Office, elementów pracy w Team Foundation, lub notatek programu Sticky Notes na ściany pomieszczenia projektu.Z wyjątkiem ostatniego elementu wszystkie z tych typów obiektów można połączyć części elementów modelu.

Oto inne aspekty specyfikacji, które zwykle są używane wraz z modeli.W zależności od tego, rozmiar i styl projektu może użyć kilku z tych aspektów lub nie używać żadnego w ogóle:

Historyjek użytkownika.Historyjka użytkownika jest krótki opis omówione z użytkowników i innych zainteresowanych stron, aspektu działania systemu, które zostaną dostarczone w jednym z iteracji projektu.Historia typowy użytkownik rozpoczyna się, "odbiorcy będą mogli..." Historyjka użytkownika może być wprowadzenie grupy przypadków użycia, lub można zdefiniować rozszerzenia przypadków użycia, które zostały wcześniej opracowane.Definiowanie lub rozszerzanie przypadki użycia pomaga zwiększyć jaśniejsze historii użytkownika.
Żądania zmiany.Żądanie zmiany w projekcie bardziej formalnych jest bardzo podobne do historii użytkownika w projekcie agile.Podejście agile co został opracowany w poprzednich iteracji traktuje wszystkie wymogi jako zmiany.
Użyj opisu sprawy.Przypadek użycia reprezentuje jeden sposób, w którym użytkownik użyje systemu w celu osiągnięcia konkretnego celu.Pełny opis zawiera cel, głównej i alternatywnej sekwencji zdarzeń i wyjątkowe wyniki.Diagram przypadków użycia pomaga podsumować i zawierają omówienie przypadków użycia.
Scenariusze.Scenariusz jest dość szczegółowe informacje na temat sekwencja zdarzeń pokazujący, jak system, użytkowników i innych systemów współpracują ze sobą aby zapewnić wartość dla zainteresowanych stron.Może to przybrać formę slide show interfejsu użytkownika lub prototyp interfejsu użytkownika.Można opisać jeden przypadek użycia lub sekwencji przypadkami użycia.
Słownik pojęć.Glosariusz wymagania projektu zawiera wyrazy, z którymi klienci omówienia ich świat.Modelach interfejs i wymagań użytkowników także należy używać tych terminów.Diagram klasy może pomóc w jasno określić relacje między większość tych terminów.Tworzenie diagramów i słownik nie tylko zmniejsza nieporozumień między użytkownikami i deweloperów, ale prawie zawsze uwidacznia nieporozumień między zainteresowanych podmiotów gospodarczych.
Reguły biznesowe.Wiele reguł biznesowych może być wyrażona jako niezmienne ograniczenia stowarzyszenia i atrybuty w modelu klasy wymagania, a jako ograniczenia diagramy sekwencji.
Wysokiego poziomu projektu.Opis głównych części i jak one pasują do siebie.Składnik, sekwencji i diagramy interfejsu są główną częścią projektu wysokiego poziomu.
Wzorce projektowe.Opisz zasady projektowania, które są współużytkowane przez różne części systemu.
Przetestuj specyfikacje.Skrypty testowe i wzory dla kodu testu potrafi wykorzystać diagramy aktywności i sekwencji do opisania sekwencji kroków testu.Testy systemu muszą być wyrażone w modelu wymagania, tak aby łatwo mogą one ulec zmianie po zmianie wymagań.
Plan projektu.Plan projektu lub zaległości definiuje, kiedy zostanie dostarczona każdej funkcji.Każdej funkcji można zdefiniować, podając co przypadków użycia i reguł biznesowych to implementuje lub rozszerzenie.Można albo odwołujesz się do przypadków użycia i reguły biznesowe bezpośrednio w planie, lub można zdefiniować zestaw funkcji w oddzielnym dokumencie i używać funkcji tytuły w planie.

Korzystania z modeli w Planowanie iteracji

Mimo że wszystkie projekty są odmienne w swej skali i organizacji, typowy projekt jest planowany jako szereg iteracji od dwóch do sześciu tygodni.Warto zaplanować wystarczająco dużo iteracji, aby umożliwić opinii od początku iteracji, aby służyć korygowaniu zakres i plany w zakresie kolejnych iteracji.

Może być przydatne następujące sugestie korzyści z modelowania w projekcie iteracyjne.

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

Gdy zbliża się każdej iteracji, należy użyć modeli, pomoc w określeniu, co ma być dostarczony na końcu iteracji.

Nie modelu wszystkiego w szczegółach w początku iteracji.W pierwszej iteracji utworzyć diagram klasy dla głównych pozycji w słowniku użytkownika, narysuj diagram przypadków użycia głównych i utworzyć diagram głównych składników.Nie opisują którejkolwiek z powyższych w szczegółach, ponieważ szczegół zmieni się w dalszej części projektu.Umożliwia utworzenie listy funkcji lub historyjek użytkownika główne pojęcia zdefiniowane w tym modelu.Funkcje należy przypisać do iteracji w taki sposób, aby około Równoważenie obciążenia szacowany trwania całego projektu.Tych przydziałów zmieni się w dalszej części projektu.
Staramy się, jak wdrażać uproszczone wersje wszystkich najważniejszych przypadków użycia w początku iteracji.Rozszerzenia te przypadki użycia w kolejnych iteracji.Takie podejście pomaga w ograniczeniu ryzyka odkrywania wadę w wymaganiach lub architektury zbyt późno w projekcie, aby coś z tym zrobić.
Pod koniec każdej iteracji przytrzymaj klawisz warsztat wymagania zdefiniowanie szczegółowych wymagań lub historyjek użytkownika, które będą realizowane w następnej iteracji.Zapraszanie użytkowników i zainteresowanych stron biznesowych, którzy mogą podjąć decyzję, priorytetów, a także programistów i testerów systemu.Zezwalaj na trzy godziny określenie wymogów dla iteracji 2 tygodnie.
Celem warsztatów jest dla wszystkich użytkowników do wyrażenia zgody, co będzie spełniany przez koniec następnej iteracji.Używać jako jedno z narzędzi do modeli, aby jasno określić wymagania.Dane wyjściowe warsztatów są zaległości iteracji: oznacza to, wykaz rozwoju zadań w Team Foundation i przetestować suites w Microsoft Test Manager.
W warsztacie wymagania omówienia projektu tylko wtedy, kiedy zachodzi potrzeba określenia szacowana w zadaniach rozwoju.W przeciwnym razie należy dyskusji do zachowania systemu, które użytkownicy mogą doświadczyć bezpośrednio.Czy model wymagania przechowywać oddzielnie od modelu architektonicznego.
Nietechnicznym stronom projektu zwykle nie ma problemów, w zrozumieniu diagramy UML, za pomocą wskazówek od Ciebie.

Model łącza do elementów pracy

Po warsztatów wymagania opracować szczegółowe informacje o modelu wymagania i Połącz model zadań związanych z rozwojem.Można to zrobić przez połączenie elementów pracy w Team Foundation do elementów w modelu.Aby dowiedzieć się jak to zrobić, zobacz Łączenie elementów modeli i elementów pracy.

Można połączyć dowolny element z pozycjami roboczymi, ale najbardziej przydatne elementy są następujące:

Przypadki użycia.Przypadek użycia można połączyć zadania rozwoju, które go wdroży.
Należy użyć rozszerzeń sprawy.Jeśli tylko jeden z aspektów przypadek użycia zostanie wprowadzony w jednej iteracji, można rozdzielić na przypadek użycia bazy, łącznie z jednego lub kilku rozszerzeń.Rozszerzenia są przypadki użycia, połączone z podstawą obudowy z zależnością «rozszerzenie».Aby uzyskać więcej informacji na temat użycia rozszerzenia, zobacz Diagramy przypadków użycia UML: Odwołanie.
Komentarz opisujący reguły biznesowe lub jakość usługi.Aby uzyskać więcej informacji, zobacz Modelowanie — Wymagania dla użytkownika.

Model łącze do badań

Użyć modelu wymagania do kierowania projekt badań odbiorczych.Tworzenie tych testów równocześnie z prac rozwojowych.

Aby uzyskać więcej informacji na temat tej techniki, zobacz Tworzenie testów z modelu.

Oszacowanie pracy pozostałej

Model wymagania może pomóc w oszacowanie całkowitego rozmiaru projektu w odniesieniu do wielkości każdej iteracji.Oceny liczbę i złożoność przypadki użycia i klas mogą pomóc w oszacowaniu prac rozwojowych, które będą wymagane.Kiedy ukończono pierwszej iteracji kilka, porównanie wymagań określonych i wymagania nadal na pokrycie może dać przybliżone miara kosztu i zakres pozostałej części projektu.

Pod koniec każdej iteracji z recenzją przypisania wymogów w odniesieniu do przyszłości powtórzeń.Może to być przydatne do reprezentowania Państwa oprogramowania na końcu każdej iteracji jako podsystem w diagramie przypadku użycia.W dyskusji można przenieść przypadki użycia i używać sprawa rozszerzenia z jednego z tych podsystemów do drugiego.

Poziomy abstrakcji

Modele mają szereg abstrakcji w oprogramowaniu.Najbardziej konkretnych modeli reprezentuje bezpośrednio kodu programu, a najbardziej abstrakcyjne wzory stanowią koncepcje biznesowe, które mogą lub nie może być reprezentowany w kodzie.

Model mogą być oglądane przez kilka rodzajów diagramów.Aby uzyskać informacje o modelach i diagramów, zobacz Modele projektowania dla projektowania oprogramowania.

Różnego rodzaju diagramu przydają się do opisu projektu na różnych poziomach abstrakcji.Wiele typów diagramów są przydatne w więcej niż jeden poziom.W tej tabeli pokazano, jak można użyć każdego rodzaju diagramu.

Poziom projekt	Typy diagramów
Proces biznesowy Opis kontekstu, w którym będą używane systemu pomaga zrozumieć, co użytkownicy potrzebują z niego.	Diagramy aktywności opisują przepływ pracy między ludźmi i systemów, aby osiągnąć cele biznesowe. Diagramy koncepcyjne klasy opisują koncepcje biznesowe używane w ramach procesu biznesowego.
Wymagań użytkowników Definicja użytkownicy potrzebują z systemu.	Diagramy przypadków użycia podsumowanie interakcji, które użytkowników i innych systemów zewnętrznych mają w systemie w wypadku opracowywania.Do każdego przypadku użycia, aby szczegółowo opisać można dołączyć inne dokumenty. Diagramy klas UML opisano typy informacji, które użytkownicy i system się przekazać na temat. Reguły biznesowe i jakość usługi można określić w oddzielnych dokumentach.
Wysokim poziomie projektu Ogólna struktura systemu: główne składniki i jak oni para razem.	Diagramy warstwy opisują, jak są podzielone na części współzależne.Można sprawdzić poprawność kodu programu przeciwko diagramów warstwy w celu zapewnienia, że przystępuje do architektury. Diagramy składników pokazuje interfejsy części, określając wiadomości i usług, które są dostarczane i wymagane przez każdy składnik. Diagramy sekwencji pokazują sposób komunikacji między składnikami do wdrożenia w każdym przypadku użycia. Diagramy klas UML opisują interfejsy składników i typy danych przekazywanych między składnikami.
Wzorce projektowe Konwencje i metod rozwiązywania problemów projektowych, które są używane we wszystkich częściach projektu	Diagramy klas UML opisują struktur wzoru Diagramy sekwencji lub aktywności Pokaż interakcje i algorytmów
Analiza kodu Kilka typów diagramu mogą być generowane z kodu.	Diagramy sekwencji pokazać interakcje między obiektami w kodzie. Diagramy warstwy pokazać zależności między klasami.Zaktualizowany kod mogą być sprawdzone przed diagram warstwy. Diagramy klas pokazać klasy w kodzie.

Zasoby zewnętrzne

Kategoria	Łącza
Filmy wideo
Fora	Visual Studio wizualizacji & Narzędzia do modelowania Visual Studio wizualizacji & Modelowanie SDK (narzędzia DSL)
Blogi	Visual Studio Informatykami + Team Foundation Server Blog
Artykuły techniczne i arkuszy	Dziennik architektury - problem 23: Modelowanie architektura i procesy
Inne witryny	Centrum MSDN architektura Architektura Visual Studio — wskazówki dotyczące oprzyrządowania