Använda modeller i utvecklingsprocessen

I Visual Studio kan du använda en modell som hjälper dig att förstå och ändra ett system, ett program eller en komponent. En modell kan hjälpa dig att visualisera den värld där systemet fungerar, förtydliga användarnas behov, definiera systemets arkitektur, analysera koden och se till att koden uppfyller kraven.

Information om vilka versioner av Visual Studio som stöder varje typ av modell finns i Versionsstöd för arkitektur- och modelleringsverktyg.

Modeller kan hjälpa dig på flera sätt:

Med modelleringsdiagram kan du förtydliga de begrepp som ingår i krav, arkitektur och design på hög nivå. Mer information finns i Modellanvändarkrav.
Att arbeta med modeller kan hjälpa dig att exponera inkonsekvenser i kraven.
Genom att kommunicera med modeller kan du kommunicera viktiga begrepp mindre tvetydigt än med naturligt språk. Mer information finns i Modellera appens arkitektur.
Ibland kan du använda modeller för att generera kod eller andra artefakter, till exempel databasscheman eller dokument. Modelleringskomponenterna i Visual Studio genereras till exempel från en modell. Mer information finns i Generera och konfigurera din app från modeller.

Du kan använda modeller i en mängd olika processer, från extrem agil till hög ceremoni.

Använda modeller för att minska tvetydigheten

Modelleringsspråket är mindre tvetydigt än naturligt språk, och det är utformat för att uttrycka de idéer som vanligtvis krävs under programvaruutveckling.

Om ditt projekt har ett litet team som följer agila metoder kan du använda modeller för att förtydliga användarberättelser. I diskussioner med kunden om deras behov kan skapandet av en modell generera användbara frågor mycket snabbare, och över ett bredare område av produkten, än att skriva topp- eller prototypkod.

Om ditt projekt är stort och innehåller team i olika delar av världen kan du använda modeller för att kommunicera kraven och arkitekturen mycket mer effektivt än du kan i klartext.

I båda fallen resulterar skapandet av en modell nästan alltid i en betydande minskning av inkonsekvenser och tvetydigheter. Olika intressenter har ofta olika förståelse för den affärsvärld där systemet fungerar, och olika utvecklare har ofta olika förståelse för hur systemet fungerar. Att använda en modell som fokus för en diskussion exponerar vanligtvis dessa skillnader. Mer information om hur du använder en modell för att minska inkonsekvenser finns i Krav för modellanvändare.

Använda modeller med andra artefakter

En modell är inte i sig en kravspecifikation eller en arkitektur. Det är ett verktyg för att uttrycka vissa aspekter av dessa saker tydligare, men inte alla begrepp som krävs under programvarudesign kan uttryckas. Modellerna bör därför användas tillsammans med andra kommunikationsmedel, till exempel OneNote-sidor eller stycken, Microsoft Office-dokument, arbetsobjekt i Team Foundation eller klisterlappar på projektrumsväggen. Förutom det sista objektet kan alla dessa objekttyper länkas till elementdelar i modellen.

Andra aspekter av specifikationen som vanligtvis används tillsammans med modeller är följande. Beroende på projektets skala och format kan du använda flera av dessa aspekter eller inte använda några alls:

Användarberättelser. En användarberättelse är en kort beskrivning, som diskuteras med användare och andra intressenter, av en aspekt av systemets beteende som kommer att levereras i en av projektets iterationer. En typisk användarhistoria börjar "Kunden kommer att kunna ...." En användarberättelse kan introducera en grupp med användningsfall eller definiera tillägg för användningsfall som har utvecklats tidigare. Genom att definiera eller utöka användningsfallen blir användarberättelsen tydligare.
Ändra begäranden. En ändringsbegäran i ett mer formellt projekt liknar en användarberättelse i ett agilt projekt. Den flexibla metoden behandlar alla krav som ändringar i vad som utvecklades i tidigare iterationer.
Beskrivning av användningsfall. Ett användningsfall representerar ett sätt på vilket en användare interagerar med systemet för att uppnå ett visst mål. En fullständig beskrivning innehåller mål, huvudsekvenser och alternativa sekvenser av händelser och exceptionella resultat. Ett användningsfallsdiagram hjälper dig att sammanfatta och ge en översikt över användningsfallen.
Scenarier. Ett scenario är en ganska detaljerad beskrivning av en händelsesekvens som visar hur systemet, användare och andra system fungerar tillsammans för att ge intressenterna ett värde. Det kan ha formen av ett bildspel i användargränssnittet eller en prototyp av användargränssnittet. Den kan beskriva ett användningsfall eller en sekvens av användningsfall.
Ordlista. Projektets kravordlista beskriver de ord som kunderna diskuterar sin värld med. Användargränssnittet och kravmodellerna bör också använda dessa termer. Ett klassdiagram kan hjälpa till att klargöra relationerna mellan de flesta av dessa termer. Att skapa diagram och ordlista minskar inte bara missförstånden mellan användare och utvecklare, utan visar också nästan alltid missförstånd mellan olika affärsintressenter.
Affärsregler. Många affärsregler kan uttryckas som invarianta begränsningar för associationer och attribut i kravklassmodellen och som begränsningar för sekvensdiagram.
Design på hög nivå. Beskriver de viktigaste delarna och hur de passar ihop. Komponent-, sekvens- och gränssnittsdiagram är en viktig del av en design på hög nivå.
Designmönster. Beskriv de designregler som delas mellan olika delar av systemet.
Testspecifikationer. Testskript och mönster för testkod kan använda aktivitets- och sekvensdiagram på ett bra sätt för att beskriva sekvenser av teststeg. Systemtester bör uttryckas i termer av kravmodellen så att de enkelt kan ändras när kraven ändras.
Projektplan. Projektplanen eller kvarvarande uppgifter definierar när varje funktion ska levereras. Du kan definiera varje funktion genom att ange vilka användningsfall och affärsregler som implementeras eller utökas. Du kan antingen referera till användningsfall och affärsregler direkt i planen, eller så kan du definiera en uppsättning funktioner i ett separat dokument och använda funktionsrubrikerna i planen.

Använda modeller i iterationsplanering

Även om alla projekt skiljer sig åt i sin skala och organisation planeras ett typiskt projekt som en serie iterationer på mellan två och sex veckor. Det är viktigt att planera tillräckligt med iterationer så att feedback från tidiga iterationer kan användas för att justera omfånget och planerna för senare iterationer.

Du kanske tycker att följande förslag är användbara för att dra nytta av fördelarna med modellering i ett iterativt projekt.

Skärpa fokus när varje iteration närmar sig

När varje iteration närmar sig använder du modeller för att definiera vad som ska levereras i slutet av iterationen.

Modellera inte allt i detalj i de tidiga iterationerna. I den första iterationen skapar du ett klassdiagram för huvudobjekten i användarordlistan, ritar ett diagram över de viktigaste användningsfallen och ritar ett diagram över huvudkomponenterna. Beskriv inte något av dessa i detalj eftersom detaljerna ändras senare i projektet. Använd de termer som definierats i den här modellen för att skapa en lista över funktioner eller större användarberättelser. Tilldela funktionerna till iterationer för att ungefär balansera den uppskattade arbetsbelastningen i hela projektet. Dessa tilldelningar ändras senare i projektet.
Försök att implementera förenklade versioner av alla de viktigaste användningsfallen i en tidig iteration. Utöka dessa användningsfall i senare iterationer. Den här metoden hjälper till att minska risken för att upptäcka en brist i kraven eller arkitekturen för sent i projektet för att göra något åt det.
I slutet av varje iteration håller du en kravworkshop för att i detalj definiera de krav eller användarberättelser som kommer att utvecklas i nästa iteration. Bjud in användare och affärsintressenter som kan bestämma prioriteringar, samt utvecklare och systemtestare. Tillåt tre timmar för att definiera krav för en iteration på 2 veckor.
Målet med workshopen är att alla ska komma överens om vad som kommer att uppnås i slutet av nästa iteration. Använd modeller som ett av verktygen för att förtydliga kraven. Resultatet från workshopen är en iteraringsbacklogg: det vill säga, en lista över utvecklingsuppgifter i Azure DevOps/Team Foundation och testsviter i Microsoft Test Manager.
I kravworkshopen diskuterar du designen endast i den mån du behöver fastställa uppskattningar för utvecklingsuppgifterna. Annars kan du fortsätta att diskutera systembeteendet som användarna kan uppleva direkt. Håll kravmodellen separat från arkitekturmodellen.
Icke-tekniska intressenter har vanligtvis inga problem med att förstå UML-diagram, med viss vägledning från dig.

Länka modell till arbetsobjekt

Efter kravworkshopen går du vidare med informationen om kravmodellen och kopplar modellen till utvecklingsuppgifter. Du kan göra detta genom att länka arbetsobjekt i Team Foundation till element i modellen.

Du kan länka alla element till arbetsobjekt, men de mest användbara elementen är följande:

Kommentarer som beskriver affärsregler eller tjänstkravskvalitet. Mer information finns i Modellanvändarkrav.

Länka modell till tester

Använd kravmodellen för att vägleda utformningen av godkännandetesterna. Skapa dessa tester samtidigt med utvecklingsarbetet.

Mer information om den här tekniken finns i Utveckla tester från en modell.

Beräkna återstående arbete

En kravmodell kan hjälpa dig att uppskatta projektets totala storlek i förhållande till storleken på varje iteration. Genom att utvärdera antalet och komplexiteten i användningsfallen och klasserna kan du uppskatta det utvecklingsarbete som krävs. När du har slutfört de första iterationerna kan en jämförelse av de krav som omfattas och kraven som fortfarande ska täckas ge ett ungefärligt mått på kostnaden och omfattningen för resten av projektet.

I slutet av varje iteration granskar du tilldelningen av krav till framtida iterationer. Det kan vara användbart att representera tillståndet för programvaran i slutet av varje iteration som ett undersystem i ett användningsfallsdiagram. I dina diskussioner kan du flytta användningsfall och användningsfallstillägg från ett av dessa undersystem till ett annat.

Abstraktionsnivåer

Modeller har en mängd abstraktioner i förhållande till programvaran. De mest konkreta modellerna representerar programkod direkt, och de mest abstrakta modellerna representerar affärsbegrepp som kanske eller kanske inte representeras i koden.

En modell kan visas via flera typer av diagram. Information om modeller och diagram finns i Skapa modeller för din app.

Olika typer av diagram är användbara för att beskriva designen på olika abstraktionsnivåer. Många av diagramtyperna är användbara på mer än en nivå. Den här tabellen visar hur varje typ av diagram kan användas.

Designnivå	Diagramtyper
Affärsprocess Genom att förstå kontexten där systemet ska användas kan du förstå vad användarna behöver från det.	- Konceptuella klassdiagram beskriver de affärsbegrepp som används i affärsprocessen.
Användarkrav Definition av vad användarna behöver från systemet.	– Affärsregler och tjänstkvalitetskrav kan beskrivas i separata dokument.
Design på hög nivå Systemets övergripande struktur: de viktigaste komponenterna och hur de kopplas ihop.	– Beroendediagram beskriver hur systemet struktureras i beroendedelar. Du kan verifiera programkoden mot beroendediagram för att säkerställa att den följer arkitekturen.
Kodanalys Diagram kan genereras från koden.	– Beroendediagram visar beroenden mellan klasser. Uppdaterad kod kan verifieras mot ett beroendediagram. – Klassdiagram visar klasserna i koden.

Externa resurser

Kategori	Links
Videor	MSDN How Do I Videos: How to Create and Use UML Models and Diagrams (Visual Studio Ultimate) MSDN How Do I Series: UML Tools and Extensibility (Visual Studio Ultimate)
Forum	- Visual Studio Visualiserings- och modelleringsverktyg - Visual Studio Visualization & Modeling SDK (DSL Tools)
Bloggar	Microsoft DevOps
Tekniska artiklar och tidskrifter	MSDN Architecture Center

Anmärkning

Komponenten Transformering av textmall installeras automatiskt som en del av arbetsbelastningen för utveckling av Visual Studio-tillägget. Du kan också installera den från fliken Enskilda komponenter i Visual Studio Installer under kategorin SDK:er, bibliotek och ramverk . Installera SDK-komponenten modellering från fliken Enskilda komponenter .

Feedback

Var den här sidan till hjälp?

Last updated on 2025-10-31