Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
U kunt delen van uw toepassing genereren of configureren op basis van een model.
Het model vertegenwoordigt de vereisten meer rechtstreeks dan de code. Door het gedrag van de toepassing rechtstreeks vanuit het model af te leiden, kunt u veel sneller en betrouwbaarder reageren op gewijzigde vereisten dan door de code bij te werken. Hoewel enige initiële werkzaamheden vereist zijn om de afleiding in te stellen, wordt deze investering geretourneerd als u wijzigingen in de vereisten verwacht of als u van plan bent om verschillende varianten van het product te maken.
De code van uw toepassing genereren op basis van een model
De eenvoudigste manier om code te genereren is met behulp van tekstsjablonen. U kunt code genereren in dezelfde Visual Studio-oplossing waarin u het model behoudt. Voor meer informatie, zie:
Code genereren op basis van een Domain-Specific-taal
Deze methode is eenvoudig incrementeel toe te passen. Begin met een toepassing die alleen werkt voor een specifiek geval en kies een paar delen ervan die u wilt variëren van het model. Wijzig de naam van de bronbestanden van deze onderdelen zodat ze tekstsjabloonbestanden (.tt) worden. Op dit moment worden de bron-.cs bestanden automatisch gegenereerd op basis van de sjabloonbestanden, zodat de toepassing werkt zoals voorheen.
Vervolgens kunt u één deel van de code nemen en vervangen door een tekstsjabloonexpressie, waarmee het model wordt gelezen en dat deel van het bronbestand wordt gegenereerd. Ten minste één waarde van het model moet de oorspronkelijke bron genereren, zodat u de toepassing opnieuw kunt uitvoeren en dit werkt zoals voorheen. Nadat u verschillende modelwaarden hebt getest, kunt u doorgaan met het invoegen van sjabloonexpressies in een ander deel van de code.
Deze incrementele methode betekent dat het genereren van code meestal een benadering met een laag risico is. De resulterende toepassingen voeren meestal bijna net zo goed uit als een handgeschreven versie.
Als u echter begint met een bestaande toepassing, zult u merken dat er veel herstructurering nodig is om het verschillende gedrag te scheiden dat wordt beheerd door het model, zodat ze onafhankelijk kunnen worden gevarieerd. We raden u aan dit aspect van de toepassing te beoordelen wanneer u de kosten van uw project inschatten.
Uw toepassing configureren vanuit een model
Als u het gedrag van uw toepassing tijdens runtime wilt variëren, kunt u het genereren van code niet gebruiken, waardoor broncode wordt gegenereerd voordat de toepassing wordt gecompileerd. In plaats daarvan kunt u uw toepassing ontwerpen om het model te lezen en het gedrag ervan dienovereenkomstig te variëren. Voor meer informatie, zie:
Procedure: Een model openen vanuit een bestand in programmacode
Deze methode kan ook incrementeel worden toegepast, maar er is meer werk aan het begin. U moet de code schrijven waarmee het model wordt gelezen en een framework instellen waarmee de waarden toegankelijk zijn voor de variabeleonderdelen. Het algemeen maken van de variabele onderdelen is duurder dan het genereren van code.
Een algemene toepassing presteert meestal minder goed dan de specifieke tegenhangers. Als de prestaties van cruciaal belang zijn, moet uw projectplan een evaluatie van dit risico bevatten.
Een afgeleide toepassing ontwikkelen
Mogelijk vindt u de volgende algemene richtlijnen nuttig.
Begin specifiek en generaliseer vervolgens. Schrijf eerst een specifieke versie van uw toepassing. Deze versie moet in één set voorwaarden werken. Wanneer u tevreden bent dat het correct werkt, kunt u een deel ervan laten afleiden van een model. Breid de afgeleide onderdelen geleidelijk uit.
Ontwerp bijvoorbeeld een website met een specifieke set webpagina's voordat u een webtoepassing ontwerpt die pagina's weergeeft die in een model zijn gedefinieerd.
Modelleer de verschillende aspecten. Identificeer de aspecten die variëren, ofwel tussen de ene implementatie en een andere, of na verloop van tijd wanneer de vereisten veranderen. Dit zijn de aspecten die moeten worden afgeleid van een model.
Als de set webpagina's en koppelingen tussen deze pagina's bijvoorbeeld verandert, maar de stijl en opmaak van de pagina's altijd hetzelfde is, moet het model de koppelingen beschrijven, maar hoeft de indeling van de pagina's niet te worden beschreven.
Afzonderlijke zorgen. Als de variabele aspecten kunnen worden onderverdeeld in onafhankelijke gebieden, gebruikt u afzonderlijke modellen voor elk gebied. Met ModelBus kunt u bewerkingen definiëren die van invloed zijn op beide modellen en beperkingen ertussen.
Gebruik bijvoorbeeld één model om navigatie tussen de webpagina's en een ander model te definiëren om de indeling van de pagina's te definiëren.
Modelleer de vereiste, niet de oplossing. Ontwerp het model zodat het de gebruikersvereisten beschrijft. Ontwerp daarentegen de notatie niet volgens de variabele aspecten van de implementatie.
Het webnavigatiemodel moet bijvoorbeeld webpagina's en hyperlinks tussen deze pagina's vertegenwoordigen. Het webnavigatiemodel mag geen fragmenten van HTML of klassen in uw toepassing vertegenwoordigen.
Genereren of interpreteren? Als de vereisten voor een bepaalde implementatie zelden worden gewijzigd, genereert u programmacode van het model. Als de vereisten vaak kunnen veranderen of samen kunnen bestaan in meer dan één variant in dezelfde implementatie, schrijft u de toepassing zodat deze een model kan lezen en interpreteren.
Als u bijvoorbeeld uw websitemodel gebruikt om een reeks verschillende en afzonderlijk geïnstalleerde websites te ontwikkelen, moet u de code van de site genereren op basis van het model. Maar u gebruikt uw model om een site te beheren die elke dag verandert, dan is het beter om een webserver te schrijven die het model leest en de site dienovereenkomstig presenteert.
UML of DSL? Overweeg om uw modellerings notatie te maken met behulp van stereotypen om UML uit te breiden. Definieer een DSL als er geen UML-diagram is dat past bij het doel. Maar vermijd het breken van de standaard semantiek van UML.
Een UML-klassediagram is bijvoorbeeld een verzameling vakken en pijlen; met deze notatie kun je in theorie alles definiëren. We raden u echter niet aan het klassediagram te gebruiken, behalve waar u in feite een set typen beschrijft. U kunt bijvoorbeeld klassediagrammen aanpassen om verschillende typen webpagina's te beschrijven.