Modellen gebruiken in uw ontwikkelingsproces

In Visual Studio kunt u een model gebruiken om een systeem, toepassing of onderdeel te begrijpen en te wijzigen. Met een model kunt u de wereld visualiseren waarin uw systeem werkt, de behoeften van gebruikers verduidelijken, de architectuur van uw systeem definiëren, de code analyseren en ervoor zorgen dat uw code voldoet aan de vereisten.

Zie Versieondersteuning voor architectuur en modelleringshulpprogramma's om te zien welke versies van Visual Studio elk type model ondersteunen.

Modellen kunnen u op verschillende manieren helpen:

• Met tekenmodelleringsdiagrammen kunt u de concepten van vereisten, architectuur en ontwerp op hoog niveau verduidelijken. Zie Gebruikersvereisten model voor meer informatie.

• Als u met modellen werkt, kunt u inconsistenties in vereisten weergeven.

• Door te communiceren met modellen kunt u belangrijke concepten minder dubbelzinnig communiceren dan met natuurlijke taal. Zie De architectuur van uw app modelleren voor meer informatie.

• Soms kunt u modellen gebruiken om code of andere artefacten, zoals databaseschema's of documenten, te genereren. De modelleringsonderdelen van Visual Studio worden bijvoorbeeld gegenereerd op basis van een model. Zie Uw app genereren en configureren op basis van modellen voor meer informatie.

U kunt modellen gebruiken in een breed scala aan processen, van extreme agile tot hoge ceremonie.

Modellen gebruiken om dubbelzinnigheid te verminderen

Modelleringstaal is minder dubbelzinnig dan natuurlijke taal en is ontworpen om de ideeën uit te drukken die doorgaans nodig zijn tijdens het ontwikkelen van software.

Als uw project een klein team heeft dat flexibele procedures volgt, kunt u modellen gebruiken om gebruikersverhalen te verduidelijken. In discussies met de klant over hun behoeften kan het maken van een model veel sneller nuttige vragen genereren, en in een breder gebied van het product, dan het schrijven van piek- of prototypecode.

Als uw project groot is en teams in verschillende delen van de wereld bevat, kunt u modellen gebruiken om de vereisten en architectuur veel effectiever te communiceren dan in tekst zonder opmaak.

In beide gevallen leidt het maken van een model vrijwel altijd tot een aanzienlijke vermindering van inconsistenties en dubbelzinnigheden. Verschillende belanghebbenden hebben vaak verschillende inzichten in de bedrijfswereld waarin het systeem werkt en verschillende ontwikkelaars hebben vaak verschillende inzichten over hoe het systeem werkt. Als u een model gebruikt als de focus van een discussie, worden deze verschillen meestal weergegeven. Zie Modelgebruikersvereisten voor meer informatie over het gebruik van een model om inconsistenties te verminderen.

Modellen gebruiken met andere artefacten

Een model is zelf geen specificatie van vereisten of een architectuur. Het is een hulpmiddel om bepaalde aspecten van deze zaken duidelijker uit te drukken, maar niet alle concepten die tijdens het softwareontwerp nodig zijn, kunnen worden uitgedrukt. De modellen moeten daarom samen met andere communicatiemiddelen worden gebruikt, zoals OneNote-pagina's of alinea's, Microsoft Office-documenten, werkitems in Team Foundation of plaknotities op de muur van de projectruimte. Naast het laatste item kunnen al deze objecttypen worden gekoppeld aan elementen van het model.

Andere aspecten van specificatie die gewoonlijk samen met modellen worden gebruikt, omvatten het volgende. Afhankelijk van de schaal en stijl van uw project, kunt u verschillende van deze aspecten gebruiken of helemaal geen gebruik maken van:

• Gebruikersverhalen. Een gebruikersverhaal is een korte beschrijving, besproken met gebruikers en andere belanghebbenden, van een aspect van het gedrag van het systeem dat wordt geleverd in een van de iteraties van het project. Een typisch gebruikersverhaal begint met 'De klant kan dat....' Een gebruikersverhaal kan een groep gebruiksvoorbeelden introduceren of uitbreidingen definiëren van gebruiksvoorbeelden die eerder zijn ontwikkeld. Het definiëren of uitbreiden van de use cases helpt het gebruikersverhaal duidelijker te maken.

• Wijzigingsaanvragen. Een wijzigingsaanvraag in een formeler project is vergelijkbaar met een gebruikersverhaal in een agile project. De agile aanpak behandelt alle vereisten als wijzigingen in wat in eerdere iteraties is ontwikkeld.

• Gebruiksvoorbeeldbeschrijving. Een use-case vertegenwoordigt één manier waarop een gebruiker met het systeem communiceert om een bepaald doel te bereiken. Een volledige beschrijving bevat het doel, de hoofd- en alternatieve reeksen gebeurtenissen en uitzonderlijke resultaten. Een use case-diagram helpt bij het samenvatten en bieden van een overzicht van de use cases.

• Scenario's. Een scenario is een redelijk gedetailleerde beschrijving van een reeks gebeurtenissen die laten zien hoe het systeem, gebruikers en andere systemen samenwerken om de belanghebbenden waarde te bieden. Het kan de vorm aannemen van een diavoorstelling van de gebruikersinterface of een prototype van de gebruikersinterface. Het kan één use-case of een reeks gebruiksvoorbeelden beschrijven.

• Glossarium. In de woordenlijst met vereisten van het project worden de woorden beschreven waarmee klanten hun wereld bespreken. De gebruikersinterface- en vereistenmodellen moeten deze voorwaarden ook gebruiken. Een klassediagram kan helpen bij het verduidelijken van de relaties tussen de meeste van deze termen. Het maken van de diagrammen en woordenlijst vermindert niet alleen misverstanden tussen gebruikers en ontwikkelaars, maar maakt ook bijna altijd misverstanden zichtbaar tussen verschillende zakelijke belanghebbenden.

• Bedrijfsregels. Veel bedrijfsregels kunnen worden uitgedrukt als invariante beperkingen voor de koppelingen en kenmerken in het model van de vereistenklasse en als beperkingen voor sequentiediagrammen.

• Ontwerp op hoog niveau. Beschrijft de belangrijkste onderdelen en hoe ze bij elkaar passen. Onderdeel-, reeks- en interfacediagrammen vormen een belangrijk onderdeel van een ontwerp op hoog niveau.

• Ontwerppatronen. Beschrijf de ontwerpregels die worden gedeeld over de verschillende onderdelen van het systeem.

• Testspecificaties. Testscripts en de ontwerpen voor testcode kunnen goed gebruikmaken van activiteits- en sequentiediagrammen om reeksen van teststappen te beschrijven. Systeemtests moeten worden uitgedrukt in termen van het vereistenmodel, zodat ze eenvoudig kunnen worden gewijzigd wanneer de vereisten veranderen.

• Projectplan. Het projectplan of de achterstand bepaalt wanneer elke functie wordt geleverd. U kunt elke functie definiëren door aan te geven welke use cases en bedrijfsregels worden geïmplementeerd of uitgebreid. U kunt rechtstreeks in het plan verwijzen naar de use cases en bedrijfsregels, of u kunt een set functies definiëren in een afzonderlijk document en de functietitels in het plan gebruiken.

Modellen gebruiken in iteratieplanning

Hoewel alle projecten in hun schaal en organisatie verschillen, wordt een typisch project gepland als een reeks iteraties tussen twee en zes weken. Het is belangrijk om voldoende iteraties te plannen zodat feedback van vroege iteraties kan worden gebruikt om het bereik en de plannen voor latere iteraties aan te passen.

Mogelijk vindt u de volgende suggesties nuttig om de voordelen van modellering in een iteratief project te realiseren.

Scherper de focus naarmate elke iteratie nadert

Wanneer elke iteratie nadert, gebruikt u modellen om te bepalen wat aan het einde van de iteratie moet worden geleverd.

• Modelleer niet alles in detail in de vroege iteraties. Maak in de eerste iteratie een klassediagram voor de belangrijkste items in de woordenlijst van de gebruiker, teken een diagram van de belangrijkste use cases en teken een diagram van de belangrijkste onderdelen. Beschrijf geen van deze details, omdat de details later in het project worden gewijzigd. Gebruik de termen die in dit model zijn gedefinieerd om een lijst met functies of belangrijke gebruikersverhalen te maken. Wijs de functies toe aan iteraties, zodat de geschatte werkbelasting in het hele project ongeveer wordt verdeeld. Deze toewijzingen worden later in het project gewijzigd.

• Probeer vereenvoudigde versies van alle belangrijkste use cases in een vroege iteratie te implementeren. Breid deze gebruiksvoorbeelden uit in latere iteraties. Deze aanpak vermindert het risico op het detecteren van een fout in de vereisten of de architectuur te laat in het project om er iets aan te doen.

• Bijna aan het einde van elke iteratie houdt u een workshop over vereisten om in detail de vereisten of gebruikersverhalen te definiëren die in de volgende iteratie ontwikkeld worden. Nodig gebruikers en zakelijke belanghebbenden uit die prioriteiten kunnen bepalen, evenals ontwikkelaars en systeemtesters. Drie uur toestaan om vereisten te definiëren voor een iteratie van 2 weken.

• Het doel van de workshop is voor iedereen om akkoord te gaan met wat er aan het einde van de volgende iteratie wordt bereikt. Gebruik modellen als een van de hulpprogramma's om de vereisten te verduidelijken. De output van de workshop is een iteratieachterstand: een lijst van ontwikkelingstaken in Team Foundation en testsuites in Microsoft Test Manager.

• Bespreek in de workshop vereisten het ontwerp alleen voor zover u schattingen voor de ontwikkelingstaken moet bepalen. Anders kunt u de discussie houden over systeemgedrag dat gebruikers rechtstreeks kunnen ervaren. Houd het vereistenmodel gescheiden van het architectuurmodel.

• Niet-technische belanghebbenden hebben meestal geen problemen met het begrijpen van UML-diagrammen, met enkele richtlijnen van u.

Model koppelen aan werkitems

Na de workshop vereisten kunt u de details van het vereistenmodel uitwerken en het model koppelen aan ontwikkelingstaken. U kunt dit doen door werkitems in Team Foundation te koppelen aan elementen in het model.

U kunt elk element koppelen aan werkitems, maar de handigste elementen zijn als volgt:

• Opmerkingen over bedrijfsregels of kwaliteit van servicevereisten. Zie Gebruikersvereisten model voor meer informatie.

Model koppelen aan tests

Gebruik het vereistenmodel om het ontwerp van de acceptatietests te begeleiden. Maak deze tests gelijktijdig met het ontwikkelwerk.

Zie Tests ontwikkelen vanuit een model voor meer informatie over deze techniek.

Resterende hoeveelheid werk schatten

Een vereistenmodel kan helpen bij het schatten van de totale grootte van het project ten opzichte van de grootte van elke iteratie. Door het aantal en de complexiteit van de use cases en klassen te beoordelen, kunt u de benodigde ontwikkelwerkzaamheden schatten. Wanneer u de eerste iteraties hebt voltooid, kan een vergelijking van de behandelde vereisten en de vereisten die nog moeten worden gedekt, een geschatte meting geven van de kosten en het bereik van de rest van het project.

Bekijk aan het einde van elke iteratie de toewijzing van vereisten voor toekomstige iteraties. Het kan handig zijn om de status van uw software aan het einde van elke iteratie weer te geven als subsysteem in een use-casediagram. In uw discussies kunt u use cases en use-case-extensies van een van deze subsystemen naar een andere verplaatsen.

Abstractieniveaus

Modellen hebben een scala aan abstractie ten opzichte van de software. De meest concrete modellen vertegenwoordigen programmacode en de meest abstracte modellen vertegenwoordigen bedrijfsconcepten die al dan niet in de code worden weergegeven.

Een model kan worden bekeken via verschillende soorten diagrammen. Zie Modellen voor uw app maken voor informatie over modellen en diagrammen.

Verschillende soorten diagram zijn handig voor het beschrijven van het ontwerp op verschillende abstractieniveaus. Veel van de diagramtypen zijn nuttig op meer dan één niveau. In deze tabel ziet u hoe elk type diagram kan worden gebruikt.

Ontwerpniveau	Diagramtypen
Bedrijfsproces Inzicht in de context waarin uw systeem wordt gebruikt, helpt u inzicht te krijgen in wat de gebruikers ervan nodig hebben.	- Conceptuele klassediagrammen beschrijven de bedrijfsconcepten die in het bedrijfsproces worden gebruikt.
Gebruikersvereisten Definitie van wat de gebruikers van uw systeem nodig hebben.	- Bedrijfsregels en kwaliteit van servicevereisten kunnen in afzonderlijke documenten worden beschreven.
Ontwerp op hoog niveau De algehele structuur van het systeem: de belangrijkste onderdelen en hoe ze samen worden gekoppeld.	- Afhankelijkheidsdiagrammen beschrijven hoe het systeem is gestructureerd in onderling afhankelijke delen. U kunt programmacode valideren op basis van afhankelijkheidsdiagrammen om ervoor te zorgen dat deze voldoet aan de architectuur.
Codeanalyse Diagrammen kunnen worden gegenereerd op basis van de code.	- Afhankelijkheidsdiagrammen tonen de afhankelijkheden tussen klassen. Bijgewerkte code kan worden gevalideerd op basis van een afhankelijkheidsdiagram. - In klassediagrammen worden de klassen in de code weergegeven.

Externe bronnen

Categorie	Links
video's	MSDN How Do I Video's: UML-modellen en -diagrammen maken en gebruiken (Visual Studio Ultimate) MSDN How Do I Series: UML Tools and Extensibility (Visual Studio Ultimate)
Forums	- Visual Studio-hulpprogramma's voor visualisatie en modellering - Visual Studio Visualization & Modeling SDK (DSL Tools)
Blogs	Microsoft DevOps
Technische artikelen en logboeken	MSDN Architecture Center

Verwante inhoud

• Modellen gebruiken in Agile-ontwikkeling
• Modellen voor uw app maken
• Gebruikersvereisten modelleren
• De architectuur van uw app modelleren
• Tests ontwikkelen op basis van een model
• Uw modelleringsoplossing structureren

Opmerking

Het onderdeel Text Template Transformation wordt automatisch geïnstalleerd als onderdeel van de ontwikkelworkload van de Visual Studio-extensie . U kunt deze ook installeren op het tabblad Afzonderlijke onderdelen van Visual Studio Installer, onder de categorie SDK's, bibliotheken en frameworks . Installeer het Modeling SDK-onderdeel op het tabblad Afzonderlijke onderdelen .