Onderzoeksrapport Projectgroep Microsoft Oslo

Onderzoeksrapport Projectgroep Microsoft Oslo Project Minor EAD 2009–2010 deeltijd

The modeling platform

Projectgroep: Mohamed Himi Guido van de Zand Marc Korthouwer Tino Willems Remco van den Berg

Project Begeleider ICA: Sander Leer Versie:

Final.

Datum:

20 januari 2010

M AN AG E M E N TS AM E N V A T TI N G De hoofdvraag die beantwoord wordt met dit onderzoeksrapport is: “In hoeverre ondersteunt Microsoft Oslo het gedachtegoed achter MDA, DDD en DSL en de principes en concepten die hier achter liggen?” In dit onderzoek is onderzocht wat Microsoft Oslo nu is, wat haar ontwikkelingen waren en waar het nu staat. Microsoft biedt met Oslo – wat nu door het leven gaat onder de naam SQL Server Modeling -, een basisset aan tools waarmee men een modelgedreven ontwikkeling ondersteunt. Deze ondersteuning bestaat uit een opslagmiddel voor UML2-modellen, een toolset voor het maken van een Domain Specific Language en de open gespecificeerde datamodelleertaal M. Conclusies Om te bepalen of Microsoft Oslo het gedachtegoed achter MDA, DDD en DSL ondersteunt, zijn deze drie methodieken in eerste instantie afzonderlijk onderzocht. Vervolgens is gekeken deze te verenigen zijn in een gemeenschappelijke context. Deze gemeenschappelijke context is onderkend en komt erop neer dat de onderzochte methodieken, elkaar treffen op twee hoofdpunten: 1. 2.

Doelstelling: het streven naar verbeteren van software kwaliteit, het verhogen van productiviteit en het reduceren van complexiteit en kosten. Modelleren: het centraal stellen van modellen en modelleren van software.

In het hoofdstuk “Contrastering Microsoft Oslo t.o.v. MDA, DDD EN DSL”, is gebleken dat Microsft Oslo, aan beide hoofdpunten voldoet. Hiermee is binnen het onderzoekskader, de ondersteuning van Microsoft Oslo, voor het gedachtegoed achter DDD, MDA en DSL, als volledig te beschouwen. In het subhoofdstuk “Contrastering MS Oslo ten opzichte van DDD”, is onderkend dat de huidige MS Oslo tooling, te beperkt is voor het realiseren van een enterprise applicatie. Binnen het onderzoekskader moet daarom gesteld worden, dat de ondersteuning van MS Oslo voor DDD, beperkt is. Als echter ontwikkeld wordt in het DOT NET platform van Microsoft en de combinatie MS Oslo met MS Visual Studio wordt beschouwd, dan kan gesteld worden dat de ondersteuning volledig is. Aangezien MS Oslo volledig integreert met de aankomende versies van MS Visual Studio, krijgt de DDD ontwikkelaar een coherente ontwikkelomgeving ter beschikking. Een groot pluspunt is de Repository van MS Oslo. De Repsitory zou de rol van de DDD Context Map kunnen spelen waarin de modellen kunnen worden opgeslagen en bewaakt. Met het MS Oslo onderdeel Quadrant, zijn de modellen in de verschillende contexten door verschillende ontwikkel teams te raadplegen en te bekijken. Met haar recentelijk voorziening, voor het importeren, opslaan en uitwisselen van UML2 modellen met behulp van het XMI (XML Model Interchange) formaat, lijkt MS Oslo een open deur te houden voor MDA. Modellen in MDA moeten volledig en compleet zijn, ten einde deze machinaal te kunnen transformeren tot uitvoerbare applicaties. UML alleen is niet genoeg voor een complete model specificatie. Verder biedt MS Oslo geen out of the box transformatie gereedschap voor realisatie van MDA model transformaties. Gelet op de huidige staat van MS Oslo moet gesteld worden dat de ondersteuning voor MDA vooralsnog beperkt is. Wil MS Oslo MDA ondersteunen, dan zou het moeten voorzien in de mogelijkheid voor het importeren en uitwisselen van modellen gebaseerd op de MDA MOF specificatie, waarvan UML2 en OCL twee implementaties zijn. Verder zal MS Oslo moeten voorzien in code-generatie en transformatie P.

2 VAN 45 - O n d e r z o e k s r a p p o r t - P r o j e c t g r o e p M i c r o s o f t O s l o

gereedschap, voor de nodige MDA model transformaties (CIM -> PIM -> PSM). Het is op dit moment niet vast te stellen of Microsoft een strategie heeft in deze richting. MS Oslo ondersteunt DSL volledig. Het modelleren binnen MS Oslo is gebaseerd op het maken van DSL modellen in de ‘M’ taal. Microsoft heeft eerder met haar DSL Tools platform, sterk ingezet op DSL’s en heeft hiermee veel ervaring op dit gebied. Een pluspunt is dat MS Oslo, de ontwikkelaar voorziet van een goede ontwikkelomgeving (code completion, syntax highlighting, parsers…) voor het ontwikkelen van DSL’s. Aanbevelingen In het kader van dit onderzoek kunnen nog enkele aanbevelingen worden geuit. Ten eerste en ten aanzien van Microsoft Oslo waar dit onderzoek zich op heeft gericht, moet gezegd worden dat MS Oslo veel potentie heeft om model gedreven software ontwikkeling op termijn effectief te ondersteunen. Vooral als het DOT NET platform van Microsoft in zijn geheel wordt beschouwd. Aangezien MS Oslo nog in de kinderschoenen staat is het advies om de ontwikkelingen nauwlettend te volgen, maar daadwerkelijke inzet nog af te wachten. Het onderzoeken van toepassing van model gedreven software ontwikkeling, inzet van code generatoren en de invloed hiervan op het ontwikkelteam was buiten de scope van dit onderzoek. Het is wel aan te bevelen om een apart onderzoek hiervoor uit te zetten.

P.


I N HO UD S O PG A VE Managementsamenvatting ............................................................................................................................ 2 Voorwoord ..................................................................................................................................................... 6 Inleiding .......................................................................................................................................................... 7 Probleemstelling ........................................................................................................................................ 7 Onderzoeksvraag .................................................................................................................................. 7 Scope..................................................................................................................................................... 7 Deelvragen ................................................................................................................................................. 7 Verkenning MDA, DDD en DSL .............................................................................................................. 7 Positionering van Microsoft Oslo .......................................................................................................... 8 Contrastering Microsoft Oslo t.o.v. MDA, DDD en DSL ........................................................................ 8 Strategie & Methoden ............................................................................................................................... 8 Onderzoeksmateriaal ............................................................................................................................ 8 Verkenning MDA, DDD en DSL ..................................................................................................................... 10 Wat zijn principes en concepten? ............................................................................................................ 10 Model Driven Architecture ........................................................................................................................... 12 Verkenning ............................................................................................................................................... 12 Definitie Model Driven Architecture ................................................................................................... 12 MDA concepten .................................................................................................................................. 14 MDA Principes..................................................................................................................................... 15 Beschouwing MDA .............................................................................................................................. 16 Domain Driven Design .................................................................................................................................. 18 Verkenning ............................................................................................................................................... 18 Definitie .............................................................................................................................................. 18 Concepten ........................................................................................................................................... 18 Principes.............................................................................................................................................. 20 Beschouwing DDD ............................................................................................................................... 21 Domain Specific Language (DSL)................................................................................................................... 22 Definitie ................................................................................................................................................... 22 Concepten ................................................................................................................................................ 23 Principes .................................................................................................................................................. 23 Voordelen ........................................................................................................................................... 24 Nadelen ............................................................................................................................................... 24 Wat is de gemeenschappelijke context voor MDA, DDD en DSL? ................................................................ 25 doelstelling .............................................................................................................................................. 25 modelleren............................................................................................................................................... 26 Gemeenschappelijke context.............................................................................................................. 26 Conclusie ............................................................................................................................................. 27 Positionering van Microsoft Oslo ................................................................................................................. 28 Ontwikkelingen van Microsoft Oslo ......................................................................................................... 28 De taal ‘M’ ............................................................................................................................................... 29 Quadrant .................................................................................................................................................. 31 P.


Intellipad .................................................................................................................................................. 32 SQL Service Modeling Services ................................................................................................................ 33 UML2 ....................................................................................................................................................... 33 Contrastering Microsoft Oslo t.o.v. MDA, DDD en DSL ................................................................................ 35 Conclusie ...................................................................................................................................................... 39 Aanbevelingen .............................................................................................................................................. 41 Literatuurlijst ................................................................................................................................................ 42

P.


V O O R W O O RD Beste lezer, Voor u ligt het onderzoeksrapport “Inzetbaarheid MS Oslo bij model gedreven software ontwikkeling” klaar. Dit onderzoek hebben we als een studentengroep uitgevoerd, voor de minor EAD (Enterprise Application Development), aan de HAN (Hogeschool van Arnhem en Nijmegen). Met dit onderzoek onderzoeken we in hoeverre Microsoft Oslo het gedachtegoed achter MDA (Model Driven Architecture), DDD (Domain Driven Design) en DSL (Domain Specific Language) en de principes en concepten die hier achterliggen ondersteunt. Belangrijk voor u als lezer om te weten is dat dit onderzoek is uitgevoerd in een periode dat het onderzochte hoofdonderwerp, Microsoft Oslo, nog volop in ontwikkeling is en waar in de loop van de tijd de definitie van Oslo door Microsoft zelf al enige malen is bijgesteld. De laatste definitie zoals bij ons bekend is SQL server modeling. Let wel, de onderzoekers gebruiken in dit onderzoek nog de codenaam OSLO. Dit onderzoek is interessant voor ontwikkelaars en projectleiders die betrokken zijn bij model gedreven software ontwikkeling, of zich hierop oriënteren. Als onderzoeksteam willen de onderzoekers tot slot nog hun begeleiders en docenten, Sander de Leer en Rody Middelkoop bedanken voor hun begeleiding en feedback. Namens het onderzoeksteam, veel leesplezier gewenst!

P.


INLEIDING

P ROBLEEMSTELLING De probleemstelling is aan het begin van het onderzoek gedefinieerd door onze opdrachtgever Sander Leer. Sander Leer heeft een bedrijf waar men vooruitstrevend bezig wil zijn binnen de software ontwikkelingsbranche gericht op “Enterprise Application Development”. Sander Leer vraagt ons concreet Model Driven Architecture, Domain Driven Design en Domain Specific Languages, hierna respectievelijk MDA, DDD en DSL te noemen, globaal te verkennen, en specifiek na te gaan in hoeverre Microsoft Oslo deze technieken/methodieken ondersteunt.

O N DE R ZO EK SV R A AG Om de voorgelegde probleemstelling te kunnen onderzoeken is deze vertaald naar de volgende hoofdonderzoeksvraag: “In hoeverre ondersteunt Microsoft Oslo het gedachtegoed achter MDA, DDD en DSL en de principes en concepten die hier achter liggen?” Het onderzoek is verdeeld in een drietal deelonderzoeken: 1. 2. 3.

Verkenning MDA, DDD en DSL Positionering van Microsoft Oslo Contrastering Microsoft Oslo t.o.v. MDA, DDD en DSL

S CO P E Doordat Microsoft Oslo nog volop in ontwikkeling is, is besloten om de onderzoeksvraag te beantwoorden aan de hand van de huidige staat van Microsoft Oslo / “SQL Server Modeling”. Dit betreft de periode vanaf half september 2009 tot eind november 2009.

D EELVRAGEN Om de opgestelde hoofdonderzoeksvraag uiteindelijk goed te kunnen beantwoorden zijn er per deelonderzoek, onderstaande sets van deelvragen gedefinieerd.

V ER K EN N I N G MDA, DDD -

EN

DSL

Wat zijn de principes en concepten achter Model Driven Architecture? Wat zijn de principes en concepten achter Domain Driven Design? Wat zijn de principes en concepten achter Domain Specific Languages? Wat is de gemeenschappelijke context van deze principes en concepten?

P.


P O SI T I O N E R I N G -

V AN

M I CRO SO FT O S LO

Hoe is Microsoft Oslo op dit moment te definiëren? Wat zijn de ontwikkelingen geweest van Microsoft Oslo in de tijd Uit welke onderdelen bestaat Microsoft Oslo en hoe en waarvoor kunnen deze onderdelen worden ingezet?

C O N T R A ST E R I N G M I C R O SO FT O S LO T . O . V . MDA, DDD -

EN

DSL

Wat zijn de vernieuwingen van Microsoft Oslo ten opzichte van MDA, DDD en DSL? Welke extra voordelen biedt Microsoft Oslo ten opzichte van de voordelen van MDA, DDD en DSL? Welke nadelen zijn er bij het gebruik van Microsoft Oslo ten opzichte van de technieken MDA, DDD en DSL? In hoeverre en op welke manier kan Microsoft Oslo bijdragen aan softwareontwikkeling binnen het terrein van “Enterprise Application Development”?

-

S TRATEGIE & M ETHODEN In dit subhoofdstuk volgt een verantwoording van de gebruikte bronnen en onze onderzoeksstrategie.

O N DE R ZO EK SM AT E R I A AL De te onderzoeken technieken MDA, DDD en DSL zijn recente ontwikkelingen in het vakgebied. Daarom is er niet zoveel literatuur in boekvorm beschikbaar. Ook Microsoft Oslo is nog volop in ontwikkeling en nog niet geformaliseerd. De onderzoekers zullen zich in dit onderzoek voornamelijk baseren op wetenschappelijke bronnen zoals artikelen en scripties, waarbij wordt gelet op de kwaliteit van de gebruikte bronnen en aanzien van de auteurs. Voor MDA zijn naast de artikelen ook de MDA specificaties van het OMG geraadpleegd. Echter gezien de complexiteit, de breedte van het onderwerp en de beperkt beschikbare tijd is hier geen uitgebreide studie naar gedaan. Voor DDD (Domain Driven Design) is aanvullend gebruik gemaakt van het boek “Domain Driven Design: Tackling Complexity in the heart of software” van Eric Evans (Evans, 2004). Eric Evans is de pionier achter DDD. Zowel Eric Evans, als dit boek van zijn hand, genieten hoog aanzien in de wereld van object georiënteerde software ontwikkeling. Voor DSL zijn diverse publicaties van Martin Fowler geraadpleegd. Martin Fowler was ten tijde van dit onderzoek bezig met een boek over dit onderwerp en publiceert met enige regelmaat artikelen over zijn bevindingen. Hij heeft ook naar Microsoft Oslo gekeken. Doordat Microsoft Oslo momenteel nog ontwikkeld wordt door Microsoft, zullen er vooral bij de beschrijving van dit onderdeel bronnen gebruikt worden van Microsoft zelf. Echter daar Microsoft een P.


commerciële partij is, zullen de onderzoekers de informatie kritisch tot zich nemen en hun conclusies voornamelijk baseren op hun eigen bevindingen. Strategie De onderzoekstrategie zal zich richten, op het beoordelen van in hoeverre Microsoft Oslo de concepten en de principes achter MDA, DDD en DSL ondersteund. Om dit goed te kunnen beoordelen, zal in eerste instantie een empirisch onderzoek zich richten, op het ophelderen van principes en concepten achter de methodieken DDD, MDA en DSL. Reden hiervoor is dat methodieken overstijgend zijn aan het commerciële product Oslo van Microsoft. Microsoft Oslo kan beschouwd worden als een toolset dat ontwikkelaars kunnen inzetten voor het toepassen van modelgedreven software ontwikkeling. De onderzoekers zijn van mening, dat deze tooling alleen beoordeeld en nuttig ingezet kan worden, als de achtergronden en het gedachtegoed helder en 1 begrepen zijn. Een vergelijking is te maken met de VS.NET, ECLIPSE en NETBEANS IDE . Deze IDEs bieden 2 allemaal mogelijkheden voor het refactoren van code. Effectief omgaan met de door deze IDEs aangeboden refactormogelijkheden, kan alleen als de IDE-gebruiker, bekend is met refactoren als paradigma in wetenschap en in practice. Microsoft Oslo kan pas goed beoordeeld worden,als er genoeg affiniteit mee is. De onderzoekers zullen daarom, daadwerkelijk Microsoft Oslo gaan installeren en ermee aan de slag gaan. Daar waar blijkt dat een onderzoeksvraag niet beantwoord kan worden, zal getracht worden een experiment te definiëren en uit te werken. Verder zijn de onderzoekers van mening dat introduceren van nieuwe concepten, alleen kan slagen als gebruikers ervan ook snappen wat de achtergronden hiervan zijn. Voor de opdrachtgever, betekent dit dat hij zijn ontwikkelaars hierin moet gaan opleiden. Het is dus zaak om te onderzoeken welke vaardigheden nodig zijn voor het toepassen van modelgedreven softwareontwikkeling. Als afronding van ons onderzoek, zullen de onderzoekers naast het presenteren van het onderzoek, ook een cursusdag verzorgen. Tijdens deze cursusdag, kunnen geïnteresseerde deelnemers kennis maken met Microsoft Oslo, MDA, DDD en DSL. De deelnemers zullen ook praktisch aan de slag gaan met het maken van een DSL in de M- taal van MS Oslo.

1

IDE: Integrated Development Environment –hulpmiddel voor software ontwikkeling Refactoren: door kleine verbeteringen de kwaliteit van de software verbeteren zonder aanpassen van functionaliteit. Een klassieke bron voor dit paradigma is het boek (Martin Fowler, 1999) 2

P.


V E RK E N N I N G MDA, DDD

EN

DSL

Het eerste deelonderzoek zal zich richten op de empirische verkenning van de methodieken MDA (Model Driven Architecture), DDD (Domain Driven Design) en DSL (Domain Specific Language). Het doel van dit deelonderzoek is deze verschillende methodieken te bestuderen en te analyseren, om te kijken of deze uiteindelijk naar elkaar gebracht kunnen worden in een gezamenlijke context. Deze context kan vervolgens gebruikt worden als basis voor het toetsen van of Microsoft Oslo het gedachtegoed achter MDA, DDD en DSL en de principes en concepten die hier achter liggen ondersteunt. Voor deze toetsing is het definiëren van de begrippen ‘principe’ en ‘concept’ binnen het onderzoekskader op zijn plaats.

W AT

ZIJN PRINCIPES EN CONCEPTEN ?

Alvorens de principes en concepten van de methodieken MDA, DDD en DSL te onderzoeken, moet helder zijn wat, binnen het onderzoekskader, verstaan wordt onder de begrippen ‘principe’ en ‘concept’. De definities van deze twee begrippen wordt hieronder gegeven. Definitie concept Volgens van Dale (W.Th. de Boer, 2003): con·cept het; o -en opzet, plan; ontwerp Onder ‘concept’ verstaan de onderzoekers de opzet van een bepaalde methodiek. Dat wil zeggen de voorgenomen manier waarop iets gebeurt of wordt toegepast. Concreet wordt verstaan onder ‘concept’, de voorgeschreven of aanbevolen methode of proces voor het toepassen van MDA, DDD of DSL vanuit het perspectief van de software ontwikkelaar, in de rol van gebruiker van de methodiek. Het concept moet de methodiek dusdanig kunnen onderscheiden van een andere methodiek, in die zin dat aan de hand van de beschrijving van het concept, de bijbehorende methodiek bepaald kan worden. Definitie principe Volgens van Dale (W.Th. de Boer, 2003): -

prin·ci·pe het; o -s overtuiging die aan al iemands handelen ten grondslag ligt; beginsel, grondbeginsel, -regel: in ~ op zichzelf be·gin·sel het; o -en, -s 1 eenvoudigste eigenschap; grondslag 2 overtuiging, principe: in ~ in principe grond·slag de; m -en fundament, beginsel: op christelijke ~ fun·da·ment het; o -en ondergronds, ondersteunend deel ve gebouw

-

Onder ‘principe’ verstaan de onderzoekers, de kerneigenschappen en beginselen die ten grondslag liggen aan een bepaalde methodiek (MDA, DDD, DSL). Met andere woorden de kernwaardes, hoofdzaken en essenties waarop deze methodiek is gebaseerd. In concrete zin; de fundamentele uitgangspunten en de verzameling voorwaardes waaraan, de softwareontwikkelaar als gebruiker van de methodiek, beslist aan moet voldoen, om juiste toepassing te kunnen claimen.

P.


Dit betekent dat de som van de principes van een methodiek, deze dusdanig moeten kunnen onderscheiden van een andere methodiek. Met andere woorden, kan gesteld worden, dat gegeven de verzameling principes, te bepalen is welke methodiek beschouwd wordt. Gebruik van de begrippen concepten en principes tijdens dit onderzoek Bij de beschouwing van de methodieken (MDA, DDD, DSL), zal bovenstaande definities van concepten en principes zo zuiver mogelijk gebruikt worden. Bij het vaststellen van de concepten, zullen de onderzoekers de voorgeschreven manier voor het toepassen van de methodiek omschrijven. Bij het vaststellen van de principes, zullen de onderzoekers de belangrijkste kernwaardes benoemen. Hoewel het kaf van het koren gescheiden moet worden, gaat de interesse meer uit naar de gedeelde concepten en principes van deze methodieken, dan wat deze onderscheidt. Reden hiervoor is drieledig: 1.

2.

3.

Primair hopen de onderzoekers, deze methodieken uiteindelijk, in een gemeenschappelijk perspectief of context te kunnen plaatsen. Deze gemeenschappelijke context is de basis voor het kunnen toetsen van Microsoft Oslo, ten einde de hoofdvraag te kunnen beantwoorden. Ten tweede vinden de onderzoekers, dat het niet per definitie zo hoeft te zijn dat concepten en principes van de ene methodiek, inzet of toepassing van een andere methodiek bij voorbaat hoeft uit te sluiten. Nagaan in hoeverre de methodieken elkaar kunnen complementeren, achten de onderzoekers dan ook zowel voor opdrachtgever als maatschappelijk relevant. Ten derde, meer praktisch geredeneerd, vanuit het perspectief van de software ontwikkelaar, is te stellen dat de softwareontwikkelaar, idealiter per project moet kunnen kiezen, wat het te realiseren product het beste dient. Net zoals combineren van projectmanagementmethodes (bijvoorbeeld Scrum i.c.m. RUP en/of Prince II) een toegevoegde waarde kan hebben voor een project, zou combineren van MDA, DDD en DSL of delen daarvan wellicht nuttig kunnen zijn.

P.


M O D E L D RI VE N A RC H I TE C T URE Hoewel diverse artikelen zich geweid hebben aan het onderwerp MDA, is moeilijk, klip en klaar, te duiden wat MDA nu werkelijk inhoudt. Voor de een is het een revolutie in softwareontwikkeling, voor de ander is het, het zoveelste nieuwe ‘buzzword’ in softwareland. In dit onderzoek doen de onderzoekers een poging om MDA in kaart te brengen en de MDA concepten en principes te destilleren. Zoals eerder gezegd wordt in dit onderzoek ook het praktische softwareontwikkelaar perspectief beschouwd; Hoe kan het worden gebruikt, en levert het iets nuttigs op. Gelukkig is er een MDA gids om ons hierin te helpen, ironisch genoeg, is deze sinds de introductie in 2003, niet meer aangepast.

V ERKENNING D E FI N I T I E M O D E L D R I V EN A R C HI T E CT UR E Model Driven Architecture (MDA) wordt ontwikkeld door de Object Management Group (OMG). De term is tevens een geregistreerde merknaam van deze organisatie. OMG is bekend van de UML (Unified Modeling Language), en het is daarom niet zo verbazingwekkend dat MDA hevig leunt op de UML. Volgens haar eigen zeggen, is de OMG opgericht om te helpen complexiteit en kosten te reduceren, en applicatie ontwikkeling te versnellen. Deze belofte wil zij waarmaken met MDA: “The Object Management Group (OMG) was formed to help reduce complexity, lower costs, and hasten the introduction of new software applications. The OMG is accomplishing this goal through the introduction of the Model Driven Architecture (MDA) architectural framework with supporting detailed specifications. These specifications will lead the industry towards interoperable, reusable, portable software components and data models based on standard models.” (OMG, 2003) In bovenstaande missie statement, worden een paar dingen gesteld over MDA: 1. 2.

Er zijn specificaties voor uitwisselbaarheid, herbruikbaarheid en portabiliteit van software componenten gebaseerd op standaard modellen. Het is een architectuur raamwerk.

De specificaties waar hier op gedoeld wordt, zullen later nog geïntroduceerd en kort omschreven worden. Een model binnen MDA is de beschrijving of specificatie van het systeem en zijn omgeving voor bepaalde bedoelingen. Modellen worden vaak gecombineerd zowel met tekeningen als met tekst.(OMG, 03) Wie de publicaties over MDA leest, zal vinden dat de term architectuur voor velen een verwarrende term is. In sommige artikelen wordt er een definitie gegeven van architectuur (Belo, 2004), maar meestal wordt de term onbehandeld overgeslagen. Enkelen beweren dat MDA feitelijk niks te maken heeft met architectuur (Cook, 2004). Daar de onderzoekers eerder een onderzoek gedaan hebben naar ‘architectuur raamwerken’ (M. Himi, 2009), en in het bijzonder het ‘Zachman framework’, doen zij een poging ‘architectuur’ binnen MDA op te helderen. P.


Wat is architectuur binnen MDA? In zijn publicatie “A framework for information systems architecture” uit 1987 (4), beschrijft John Zachman, een raamwerk om architecturen op te stellen en te beheren. Hij is op dit raamwerk gekomen door te kijken naar architecturen in de bouw en de industrie. (M. Himi, 2009). Een architectuur, is een soort classificatie schema, waarmee organisaties naar hun infrastructuren kunnen kijken, analyseren, beschrijven en naar anderen kunnen communiceren. Na de introductie van het Zachman framework is er een wildgroei aan architectuur raamwerken (TODAF, Soni, Nord en Hofmeister, Kruchten 4+1...etc.). Om enige standaardisatie in het geheel aan te brengen, heeft het IEEE (12) in 2000, de IEEE 1471 standaard ofwel “IEEE Recommended Practice Architectural Description of Software-Intensive Systems” (13) uitgebracht. Het IEEE 1471 biedt definities voor architectuurbeschrijvingen, die voornamelijk betrekking hebben op software informatie systemen. De standaard specificeert dat architecturen vanuit meerdere perspectieven (views), moeten worden bekeken, en de beschrijvingen daarvan altijd moeten voldoen aan de belangen van de stakeholders. Een view wordt volgens een voorgedefinieerde viewpoint gemaakt. Een viewpoint is een soort blauwdruk of abstractie voor een view, en beschrijft bijvoorbeeld welk stakeholders perspectief beschouwd wordt en welke technieken er worden gebruikt. De standaardspecificatie IEEE 1471 specificeert verder niet welke views en viewpoints er moeten zijn. Wie de MDA guide doorneemt zal daarin de begrippen ‘view’, ‘viewpoint’ tegenkomen. MDA definieert drie viewpoints en drie bijbehorende views: MDA Viewpoints 1.

2. 3.

Computation Independent Viewpoint: deze viewpoint focust zich op de omgeving van het systeem en de eisen. Details van de structuur en processen zijn verborgen of nog niet gedefinieerd. Platform Independent Viewpoint: de focus van deze viewpoint is de systeemoperatie. De specificaties binnen deze viewpoint zijn onafhankelijk van het doelplatform van het systeem. Platform Specific Viewpoint: deze viewpoint introduceert de nodige details voor een specifiek platform.

MDA Views 1.

2.

Computation Independent Model (CIM): dit is een instantie van het Computation Indipendent Viewpoint. Deze view houdt zich bezig met functioneel beschrijven van het systeem. In essentie is dit het systeem bekeken vanuit het perspectief van de domain expert, die alleen functionele domeinkennis heeft. Dit is de plek voor het domeinmodel. Platform Independent Model (PIM): deze view is een instantie van Platform Independent Viewpoint. Dit model heeft een gespecificeerde mate van platform onafhankelijkheid, dat het hergebruikt kan worden voor verscheidene andere platformen. P.


3.

Platform Specific Model (PSM): deze view is een instantie van de Platform Specific Viewpoint. Dit model combineert de specificatie uit het PIM, met de specifieke details van het gebruik van het systeem op een bepaald platform.

Hiermee is in ieder geval duidelijk dat MDA wel degelijk over architectuur gaat. We kunnen stellen dat MDA een architectuur framework is volgens de definities van de IEEE 1470 standaard. Dit wil overigens niet zeggen dat het de architectuur specificeert voor de MDA gebruiker. Het gaat hier om de MDA architectuur zelf. Echter zal de MDA gebruiker wel binnen zijn eigen architectuur deze MDA viewpoints moeten herkennen. Wellicht is dit een verklaring voor de verwarring. De onderzoekers hopen dat hiermee ‘architectuur’ binnen MDA, in een betere context is gezet.

MDA

CO N C EP T EN

MDA streeft naar het versnellen van applicatieontwikkeling en kostenreductie. Het idee is dat systemen op een abstract niveau gemodelleerd worden. De modellen worden in een paar transformatie slagen, van abstract naar concreet getransformeerd, tot uiteindelijk uitvoerbare code. Hierbij is van belang dat de modellen met een hoge mate van correctheid en precisie worden gespecificeerd, ten einde deze machinaal te kunnen transformeren. Een vergelijking is te maken met een industrieel productieproces, of een waardeketen. Elke transformatie is een bewerking waarbij waarde wordt toegevoegd voor de volgende schakel in de keten tot het eindproduct. Het MDA proces wordt hieronder beschreven: 1.

2.

Beschrijf een CIM (Computation Independent Model), een domeinmodel dat de functionele werking van het systeem beschrijft. Dit model mag geen enkele vorm van implementatie details bevatten. Dit is zeg maar het klassieke conceptuele domain model waar we bekend mee zijn uit de OOA&D (object oriented analyses and design) leer. Het CIM wordt getransformeerd naar een PIM (Platform Indipendent Model). Een model dat onafhankelijk is van doelplatform, en zich ook niet bekommert over implementatie details voor het systeem. Lastig is dat het OMG niet concreet maakt wat zij bedoelt met ‘onafhankelijk’ en ‘platform’, waardoor het PIM moeilijk te begrijpen is; Ten eerste als platform gezien wordt als implementatie detail, dan valt geen verschil te maken met het CIM. Ten tweede, wordt door velen platform geassocieerd met een besturingssysteem (Windows, UNIX), een virtuele machine (JVM), een middelware stack (J2EE, DOTNET). Vanuit deze beredenering, vraagt Martin Fowler, in zijn artikel (Fowler, PlatformIndependentMalapropism, 2003), zich af waarom je nog iets platform onafhankelijk wilt maken, als bijvoorbeeld Java dit voor je garandeert? In de MDA guide worden (Object, Flow, middelware, programmeertaal, protocol) aangedragen als voorbeelden van wat beschouwd kan worden als ‘platform’. Deze ruime, wellicht onlogische, interpretatie is niet alleen onduidelijk maar ook nog eens verwarrend. Het is op zijn minst niet gangbaar, dat bijvoorbeeld ‘object’ of ‘flow’ worden geassocieerd met ‘platform’. De MDA Guide is niet veel duidelijker over het begrip ‘onafhankelijk’. Ook dit begrip is erg ruim en open voor interpretatie. “Like most qualities, platform independence is a matter of degree. So, one model might only assume availability of features of a very general type of platform, such as remote invocation, P.


while another model might assume the availability a particular set of tools for the CORBA platform.” (OMG, 2003)

3.

4.

Bovenstaand statement is eveneens verwarrend. Er wordt gesteld dat een platform onafhankelijk model, afhankelijk kan zijn van, wat het OMG, eerder heeft bestempeld als platform (CORBA, RMI). Bovenstaande beschouwend, lijkt het erop dat de ontwikkelaar eerst moet definiëren wat voor hem een platform is. Deze definitie kan vervolgens gebruikt worden voor het maken van een PIM. In een volgende stap wordt het PIM gedecoreerd met zogenaamde ‘mappings’, waardoor er een ‘Marked PIM’ ontstaat. Voorbeelden van mappings zijn, xml tags, code annotaties, UML stereotypes… Het doel is dat een transformator, deze mappings machinaal moet kunnen interpreteren om de volgende gewenste transformatie uit te voeren. Aan de hand van de mappings kan het Marked PIM getransformeerd worden naar een PSM. Dit model is specifiek A FBEELDING 1 (OMG, 2003) voor het doelplatform en bevat de nodige implementatie details. Afhankelijk van wat beschouwd wordt als platform, zijn er vanuit deze stap meerdere vervolg stappen denkbaar. Het PSM kan getransformeerd worden naar een PIM, dat een andere definitie heeft van platform. Dit PIM zou dan op haar beurt getransformeerd kunnen worden naar een Marked PIM, dat vervolgens weer naar een PSM kan worden getransformeerd. Deze loop zou dus herhaaldelijk voor kunnen komen. Een codegenerator kan aan de slag gaan om de uiteindelijke applicatie te genereren.

MDA P R I N CI P ES Onderstaand de principes die kunnen worden gedestilleerd uit de verkenning van MDA. 1. 2.

MDA specificeert drie modellen CIM (computation independent model), PIM (platform independent model) en PSM (platform specific model). De modellen zijn gebaseerd op een standaard modelleertaal, dat een afgeleide is van de MDA MOF (Meta Object Facility). Een voorbeeld van een MOF compliant taal is UML2. Modellen P.


3. 4.

5. 6.

dienen in hoge mate van compleetheid te worden gespecificeerd om interpretatie en transformatie door een machine mogelijk te maken. Het specificeren van gedrag en regels wordt gedaan middels OCL (Object Constraint Language), dat ook een MDA specificatie is en eveneens een afgeleide van de MOF. In MDA worden diverse modellen getransformeerd van abstract naar concreet tot uitvoerbare code. De OMG standaard die dit in goede banen moet leiden is de MOF/QVT (MOF Query View Transformation). Enkel het PIM model is verplicht in MDA. Overige nodige transformaties kunnen worden gebakken in een commercieel MDA product. Als vendors zich aan de OMG standaarden houden, dan kunnen de modellen onderling worden uitgewisseld. Voor deze uitwisseling, moet een model getransformeerd kunnen worden naar XMI (XML Model Interchange) format. Dit format moet iedereen kunnen interpreteren.

B E S C HO UW I N G MDA Voordelen Onderstaand wat de onderzoekers betreft de voordelen van MDA: -

-

-

MDA modellen zijn uitwisselbaar. Dit opent deuren voor het ontwikkelen van MDA transformatie tooling. Het zelfde model kan worden gebruikt voor het genereren van dezelfde functionaliteit in verschillende technologieën. Transformatie en codegeneratie, verhogen de productiviteit en verlagen de ‘time to market’ en kosten. Door machinale transformatie en automatische codegeneratie is de kans op mens fouten en bugs aanzienlijk kleiner. Dit verhoogt de kwaliteit van het product. Hergebruik van modellen en transformatie specificaties voor realiseren nieuwe applicatie. Betere voorspelbaarheid in ontwikkeltijd en kosten. Kan ideaal toegepast worden als requirements en wensen nog niet geheel duidelijk zijn. Een prototype is snel ontwikkeld. De klant kan snel feedback geven. Het product kan snel worden bijgesteld. In theorie is het mogelijk dat ook mensen die geen verstand hebben van softwareontwikkeling een applicatie zouden kunnen bouwen m.b.v. een geavanceerde MDA tool.

Bovenstaande voordelen zijn meer het gevolg van codegeneratie. Voordelen gelden dus ook voor CASE tools en zijn dus niet specifiek voor MDA. De toegevoegde waarde van MDA ligt echter in het feit dat men ontwikkelt op basis van standaarden, waardoor modellen uitwisselbaar worden. Nadelen Onderstaand wat de onderzoekers betreft de nadelen van MDA -

Wanneer gewenste functionaliteit niet beschikbaar is, dient dit eerst gestandaardiseerd te worden binnen een model alvorens op basis van dit model de functionaliteit te gebruiken is. De ontwikkeltijd van “Nieuwe functionaliteit” is hierdoor vrij lang en heeft nog een lang testtraject te gaan. P.


-

-

Gebrek aan goede en algemeen geaccepteerde standaarden voor vastlegging van functionaliteit van een applicatie. Modellen moeten worden gespecificeerd met een hoge mate van correctheid en compleetheid. Dit is geen eenvoudige taak, en verreist ontwikkelaars die heel abstract kunnen denken en modelleren. Verder is het lastig om complexe business rules te modelleren. Er moeten veel details worden opgenomen in de modellen, waardoor modellen niet meer begrijpbaar worden voor domeinexperts. De MDA Standaarden zijn complex. Voor realisatie van nieuwe oplossingen is applicatiegeneratie uitstekend geschikt. Lastig wordt het als een nieuwe wens geïmplementeerd moet worden in een gegenereerd systeem. Moet dan de applicatie helemaal opnieuw gegenereerd worden? Nog lastiger als bestaande functionaliteit aangepast moet worden, waarbij ook de datastructuur verandert. Hoe kan de data worden geconverteerd, zonder verlies of corruptie van data?

Conclusie Voor de diverse MDA vendors, is MDA een futuristische revolutie. Deze vendors zijn bezig de nodige gereedschappen te ontwikkelen om applicaties te genereren op basis van MDA modellen. Voor anderen sceptici, is dit een déjà vu. De associatie is door deze groep snel gemaakt met de CASE tools (Computer Aided Software Engineering) uit de jaren 80, die dezelfde belofte niet hebben waargemaakt (Cook, 2004) (Fowler, Model Driven Architecture, 2004). Volgens de overlevering, hebben Case tools gefaald in het bedienen van de software ontwikkelaar met een consistente ontwikkelomgeving. Het lijkt erop dat MDA hetzelfde pad opgaat. Succes zal ervan afhangen of de MDA tool vendors erin zullen slagen om de ontwikkelaar goed te bedienen. Hij heeft immers niet veel aan MDA specificaties. Hij heeft gereedschap en bouwstenen nodig om functionaliteit te kunnen realiseren. De MDA beloftes, verhogen productiviteit, kwaliteit en uitwisselbaarheid, zijn wel idealen waar blijvend naar gestreefd moet worden. Het zou mooi zijn als dit ooit werkelijkheid wordt. Of dit op korte termijn zal gebeuren, is onwaarschijnlijk. Het is moeilijk te geloven dat softwareontwikkeling ooit voor iedereen toegankelijk wordt. Wellicht zullen niet IT’ers kleine simpele applicaties kunnen gaan maken voor het bijhouden van een eigen CD verzameling. Misschien zelfs een leden registratie voor de lokale fanfaren club. Echter voor het realiseren van bedrijfskritische applicaties zullen ontwikkelaars nog steeds nodig blijven. Zij zullen wel moeten beschikken over grote analytische vermogens om op hoog niveau te abstraheren en exact te kunnen modelleren.

P.


D O M AI N D RI VE N D E S I G N

V ERKENNING D E FI N I T I E In zijn boek ‘Domain Driven Design, Tackling Complexity is the heart of software’ (Evans, 2004), geeft Eric Evans een uitputtende theorie en een bibliotheek van software design patterns, voor het modelleren van probleemdomeinen. Menigeen die bekend is met UML, GOF design Patterns (Gamma, 1994) en OOA&D (object oriented analysis and design), zal bij het lezen van Evans boek, veel herkennen. Het boek is dan ook in zekere zin vergelijkbaar met het eveneens goede boek “Applying UML and Patterns“ (Larman, 2004), van Graig Larman. Echter presenteert Evans nieuwe wijsheden en ‘frisse’ ideeën over OO en modelleren. Evans wordt veel geprezen voor dit werk. Het boek gaat uit van de stelling dat het slagen van een applicatie afhankelijk is van hoe juist het probleemdomein gemodelleerd is. Het domein is het kloppende hart van de applicatie, en wat van grote waarde is voor de business die de applicatie gebruikt. Uiteraard is er een vorm van opslag nodig, wellicht in een relationele database, en zullen gebruikers ongetwijfeld een user interface nodig hebben om hun taken binnen het systeem uit te voeren. De user interface, database en overige technische benodigdheden, dienen namelijk maar één doel: ondersteunen van het probleemdomein. A FBEELDING 2 : DDD

Als we dan bedenken dat organisaties vaak moeten reorganiseren en werkwijzen moeten veranderen om de concurrentieslag te winnen, dan is het ook een natuurlijk gevolg dat het ondersteunende softwaredomein, net zo vaak mee moet veranderen. Om als IT beter opgewassen te zijn tegen deze complexe uitdaging, moeten ze de business goed kunnen verstaan en meesters worden in het maken van ondersteunende domeinmodellen die mee kunnen veranderen als de business verandert. Dit leren we in Evans DDD (domain driven design) leer.

C O N C EP T EN De focus van DDD is om een goed domeinmodel te realiseren voor de business. Daarvoor is het cruciaal dat de IT’er de domeinexpert goed begrijpt. De eerste stap, en meteen de kern, van DDD, is het bewerkstelligen van een zogeheten ‘Ubiquitous Language’ (UL); een taal die ontstaat tijdens de interactie tussen de ontwikkelaar en de domeinexpert. Deze taal bevat per definitie termen zoals door de domeinexpert worden gebruikt en uitgesproken. De domeinexpert is in de lead en de ontwikkelaar volgt en probeert middels interviewtechnieken zoveel mogelijk op te helderen. Aan de andere kant is het ook P.


belangrijk dat de domeinexpert het domeinmodel dat de ontwikkelaar tekent begrijpt. De ontwikkelaar zal hem de gebruikte UML notaties moeten uitleggen, waarbij hij zijn diagrammen conceptueel en simpel houdt. De UL komt verder in alles voor van code tot documentatie. Aanpassing in de UL betekent aanpassing in code, en aanpassing in code betekent aanpassing in UL. Het ontwikkelteam blijft continue brainstormen en nadenken over het domein en probeert impliciete aspecten expliciet te maken in het model. Dit levert een model dat zelf expressief is, en de communicatie daardoor vergemakkelijkt. Om te komen tot een dergelijk expressief model, is veel geduld nodig. Dit kan soms maanden duren. In dit proces kan iemand tot een zogeheten ‘Breakthrough’ komen. Dit is een ingenieus inzicht, waardoor een verandering in het model of een andere zienswijze, van zeer grote waarde is voor het oplossen van het probleem. Een ‘breakthrough’ vereenvoudigt het probleem en daarmee het model en zelfs de software, waardoor het onderhoud geminimaliseerd wordt en uitbreidingen makkelijker door te voeren zijn. Een nieuwe interessante filosofie is die van ‘Strategic Design’ waar een kwart van het Evans boek aan is geweid. Strategic Design is een verzameling enterprise-architectuur designpatronen voor het bewaken van consistentie en uniciteit in domeinmodellen binnen een grote organisatie. Het onderkende probleem, is dat er binnen een groot bedrijf meerdere teams software ontwikkelen. Deze teams worden verschillend aangestuurd en hebben elk een eigen perspectief op het probleemdomein. Een voorbeeld hiervan is bijvoorbeeld een domeinentiteit ‘Medewerker’. Voor de HRM applicatie dat door team A wordt ontwikkelt is alle informatie van ‘Medewerker’ van essentieel belang. Voor de Orderbeheer applicatie dat ontwikkelt wordt door team B, wordt ‘Medewerker’ misschien gezien als gebruiker. Slechts een aantal attributen van ‘Medewerker’, zoals voornaam, achternaam, personeelsnummer alsmede de systeemrollen zijn van belang. Hoewel het in beide voorbeelden waarschijnlijk over dezelfde medewerker gaat is het HR domein anders dan het Orderbeheer domein. Wat in het ene domein geldt hoeft niet in het ander te gelden. Het is mogelijk dat bedrijfs-policies kunnen verbieden, dat niet HR applicaties uitgebreide kennis hebben van privacy gevoelige gegevens of mogelijk zijn er technische beperkingen. Het gebruik van één groot domeinmodel is daarom niet haalbaar en mogelijk zelfs niet zinnig. DDD onderkent dit probleem en stelt dat het ook in deze situaties belangrijk is om softwareontwikkeling nog steeds te baseren op domeinmodellen. Echter moeten er maatregelen genomen worden voor het bewaken van consistentie en grenzen (Bounded Contexts) van deze modellen. De modellen worden opgenomen in een Context Map een soort van repository. Gedeelde domeinentiteiten kunnen worden opgenomen in een ‘Shared Kernel’, die iedereen kan gebruiken. Elke Bounded Context heeft een eigenaar. Indien mogelijk, kunnen teams opgesteld worden volgens een klant – leverancier verhouding (Customer / Supplier Teams). Het ene A FBEELDING 3 team is eigenaar van het model en voorziet het andere team in haar behoefte. Als het ene team kan leven met de tekortkomingen in het model van het P.


andere team, dan kan gewerkt worden volgens het (Conformist) principe. Het team hoeft dan geen eigen modeldefinitie erop na te houden. Als het technisch of politiek niet mogelijk is om teams te laten samenwerken, dan is het beter dat elk team haar eigen gang gaat en een eigen model/context gebruikt (Separate Ways). Ook in dit geval kan elk team nog gebruik maken van een Shared Kernel of met een ander team een Customer/Supplier verhouding hebben. Wat van belang is, is dat de grenzen en de context van elk domein duidelijk zijn en bewaakt worden.

P RI N CI P E S 1.

Maak onderscheid in entiteiten en value objecten (entities en value objects) a. Entity: dit is een domeinconcept dat voor de business een identiteit heeft. Bijvoorbeeld een Order met een uniek nummer, waarmee deze door de domeinexpert onderscheiden wordt van een andere Order. b. Value Object: dit is ook een domeinconcept, echter wordt deze gekend door zijn attributen en heeft voor de domeinexpert verder geen identiteit. Hetzelfde value object mag dus vervangen worden door een ander. Voorbeelden hiervan zijn attributen, een adres, een kleur, Een entiteit heeft een lifecycle die goed moet worden gecontroleerd. Een entiteit kan nooit van identiteit veranderen. Een entiteit kan een aggregaat zijn voor 1 of meerdere value objects.

A FBEELDING 4 D OMAIN D RIVEN .

Een value object daar en tegen kan geen aggregaat zijn voor een entiteit. Een value object is immutable, wat wil zeggen dat het na creatie niet meer kan veranderen. 2. 3. 4. 5.

Gebruik het separation of concerns principe door implementatie van een gelaagde architectuur (layered architecture). Elimineer overbodige associaties. Organiseer code in modules en deel deze logisch in op basis van UL. Meerdere domeinen kunnen naast elkaar bestaan. Bepaal in welke context een domein geldt. Zelfde concept kan voorkomen in twee verschillende domeinen met verschillende betekenis. Context bepaalt de betekenis. Als een deel van het domein hetzelfde is in meerdere contexten, dan dit deel isoleren in een gedeelde context. Bepaal een eigenaar van de gedeelde context. Bewaak deze in een multidisciplinair team, modelconsistentie door het bewaken van bounded contexts.

P.


B E S C HO UW I N G DDD DDD is een omvangrijke leer, hier zijn, voor dit onderzoek, de minimum aspecten uitgehaald. Het gaat om de kunst van het modelleren. De onderzoekers kunnen dit werk van Evans aan iedere ontwikkelaar betrokken bij software ontwikkelen van harte aanbevelen. Dit zijn de vaardigheden die men moet beheersen om het probleemdomein te begrijpen en een flexibele software oplossing te realiseren voor dat domein. Echter, moet men beseffen, dat het toepassen van DDD, veel geduld vraagt en veel interactie met domeinexperts, en dus niet geschikt als snelheid boven kwaliteit gaat. Dus eigenlijk maar voor een zeer beperkt aantal projecten geschikt. Daarnaast kan het alleen van toegevoegde waarde zijn, als DDD binnen het ontwikkelteam goed begrepen wordt.

P.


D O M AI N S PE CI F I C L AN G U A G E (DSL)

D EFINITIE DSL is een programmeertaal voor een specifiek probleemdomein (Fowler, MF Bliki: DomainSpecificLanguage, 2005). Tegenovergestelden van een DSL zijn bijvoorbeeld general-purpose programmeer talen zoals C, Java en C#. Deze geven bijna oneindig veel vrijheid. Hierdoor hebben programmeurs heel veel vrijheid bij het interpreteren van de specificaties en het schrijven van code. Een ander voorbeeld is de general-purpose modeleer taal zoals UML. Een DSL zorgt ervoor dat de programmeur minder vrijheid krijgt; het genereert 3GL-code op basis van een model (Jongsma, 2005). Domein specifieke talen kunnen worden onderverdeeld in twee typen (Cunningham & Cunningham, Inc., 2008): Freestanding Domain Specific Languages – talen die onafhankelijk zijn en geen extensie van een bepaalde host taal. Ze kunnen worden geïmplementeerd in elke willekeurige host taal. Bij het programmeren in een dergelijke DSL wordt enkel de functionaliteit, geboden door die DSL, gebruikt, Sommige DSLs van dit type bieden een manier om calls naar een algemene bibliotheek van subroutines te doen. De DSL kunnen we dan zien als een middel om de details en complexiteit van die bibliotheek te verbergen. Een veel voorkomende term voor DSLs gericht op het bouwen van zakelijke systemen, die de gegevens van de bedrijfsprocessen verwerken, is dan ook “4th Generation Language” (4GL). (van Deursen, Klint, & Visser, 2000) Embedded Domain Specific Languages – talen die

A FBEELDING 5 (S PINELLIS , 2001)

afhankelijk zijn van een host taal en gezien kunnen worden als extensies op die host taal. Vaak worden elementaire onderdelen van de host taal gebruikt voor de flow van het programma; de host taal wordt op diverse plaatsen aangeroepen en de DSL kan dan ook niet zonder zijn host taal. De macro’s in Microsoft Excel en ook veel Lisp macro’s vallen onder deze categorie; het macro systeem vertaalt de DSL 3 naar de host taal. De Cee Gee Language is een voorbeeld van een EDSL waarbij de

A FBEELDING 6 (S PINELLIS , 2001)

DSL een extensie op de compiler van de host taal biedt. Enkele voorbeelden van DSLs: CRobots – een oude DOS game waarin je het gedrag van een robot kunt programmeren 3

http://developer.nvidia.com/page/cg_main.html P.


Structured Query Language (SQL) – domein specifiek voor het raadplegen van databases. TexLanguage (LaTex, BibTex) – een typesetting taal ontwikkeld door Donald Knuth. Omdat DSLs expressiever zijn dan conventionele programmeertalen, is het mogelijk om de complexiteit te reduceren, waardoor ook het modelleren eenvoudiger en gemakkelijker wordt. Maar belangrijker is, dat DSLs volledig geautomatiseerde codegeneratie faciliteren vergelijkbaar met de manier waarop de hedendaagse compilers Assembler genereren op basis van een andere programmeertaal. (Tolvanen, 2006). De term DSL is niet nieuw (Consel, Fisher, Gray, Karsai, Mernik, & Tolvanen, 2009); er zijn eigenlijk altijd al “talen” geweest, die voor een specifiek domein zijn toegepast. DSL is een onderdeel van de software engineering methodologie Domain Specific Modeling (DSM) en heeft daar zijn populariteit aan te danken (Wikipedia, 2009). Hoewel we de steeds meer DSLs zien ontstaan, zal het waarschijnlijk nog wel even duren voordat men ze ook grootschalig toe zal gaan passen; programmeertalen zijn meer dan alleen technologieën, het zijn ook de gewoonten in de manier van denken, en niets verandert langzamer (Graham, 2003). Daar komt dan nog bij, dat het programmeren op een hoger abstractieniveau ook nog eens moeilijker is dan het “conventionele” programmeren (Clementson, Metaprogramming is hard, 2004).

C ONCEPTEN Een DSL kan het beste incrementeel worden opgebouwd (Tolvanen, 2006). Naarmate een DSL groter wordt, benadert deze het Interpreter patroon; bepaal, gegeven een taal, een representatie voor zijn grammatica evenals een tolk, die de representatie gebruikt om zinnen in de taal te interpreteren. DSM beoogt de volgende twee doelen (Kelly & Tolvanen, 2008): o Het niveau van abstractie vergroten tot voorbij het programmeren door de oplossing te specificeren in een taal, die de concepten en regels uit het probleemdomein gebruiken. o Het genereren van het uiteindelijke product in een gekozen programmeertaal.

P RINCIPES Een DSL verhoogt het abstractieniveau ten opzichten van het domein voor de programmeurs die ermee werken (Tolvanen, 2006). DSL is een programmeertaal voor een specifiek probleemdomein (Cunningham & Cunningham, Inc., 2008). DLS zijn klein en bieden slechts een beperkte set van notaties en abstracte begrippen (van Deursen, Klint, & Visser, 2000). DSLs zijn declaratief en kunnen bijgevolg worden beschouwd als specificatie talen (van Deursen, Klint, & Visser, 2000). Veel DSLs hebben een compiler, die een applicatie kan genereren vanuit het DSL programma. Andere zijn niet gericht op het definiëren van een programma, maar op libraries en/of componenten. Er bestaan ook DSLs die gericht zijn op het genereren van documenten en P.


afbeeldingen. (Een algemene term voor DSLs gericht is op het bouwen van zakelijke gegevensverwerkende systemen is 4th Generation Language (4GL))

V O O R D E L EN Door gebruik te maken van zelfdocumenterende codegeneratie verbeteren DSLs de productiviteit, betrouwbaarheid, onderhoudbaarheid en overdraagbaarheid. Een DSL drukt domeinkennis uit. Deze kennis kan worden vastgelegd met een DSL en maakt hergebruik van de kennis mogelijk. Door het reduceren van maatwerkcode verhogen DSLs de kwaliteit. De standaard architectuur van de applicatie en de artefacten kan worden gegenereerd. Van de gegenereerde code is al bewezen, dat die goed is en de gebruiker kan maatwerkcode toevoegen middels extension points. DSL programma's zijn kernachtig, grotendeels zelfdocumenterend, en kunnen worden hergebruikt voor andere doeleinden. Met DSLs kunnen oplossingen worden uitgedrukt in het idioom en op het abstractieniveau van het probleemdomein. Hierdoor kunnen domeindeskundigen zelf de DSL programma's begrijpen, valideren, wijzigen en vaak zelfs programmeren. DSLs maken validatie en optimalisatie op domeinniveau mogelijk. DSLs verbeteren de testbaarheid. (van Deursen, Klint, & Visser, 2000), (Verlaenen, 2008)

N A D EL E N Een van de belangrijkste nadelen van het gebruiken van een DSL zijn de kosten van het ontwerpen, implementeren en onderhouden van een DSL. (Verlaenen, 2008) De kosten voor opleiden van de DSL gebruikers. Beperkte beschikbaarheid van DSLs. Het is moeilijk de juiste scope te vinden voor de DSL. Het is lastig om de balans te vinden tussen domein specifieke en general-purpose taal. Het potentiële verlies aan efficiëntie in vergelijking met handgeschreven code.

P.


WAT

I S D E G E M E E N S C H A P PE L I J K E C O N TE X T VO O R

MDA, DDD

EN

DSL?

In dit hoofdstuk wordt nagegaan of er een gemeenschappelijke context bestaat voor de methodieken MDA, DDD en DSL. Vanuit deze gemeenschappelijke context kan Microsoft Oslo beter worden beoordeeld. Wellicht ten overvloede, er wordt vooral gekeken vanuit het perspectief van de ontwikkelaar.

DOELSTELLIN G De methodieken MDA, DDD en DSL beschouwend op beoogde doelstelling kan vastgesteld worden dat ze alle drie onderstaande doelstellingen nastreven: 1. 2. 3. 4.

Verbeteren van software kwaliteit in termen van onderhoudbaarheid, uitbreidbaarheid, gebruiksvriendelijkheid en toegevoegde waarde voor de business. Reduceren van complexiteit. Verhogen van productiviteit. Reduceren van kosten.

Er zijn wel subtiele verschillen te onderkennen in hoe elke methodiek bovenstaande doelstellingen wil bereiken. Deze verschillen betreffen vooral de focus en het concept. MDA legt de focus op verhogen van productiviteit en reductie van kosten en complexiteit. Het concept is gebaseerd op modeltransformatie van abstract-generiek naar concreet-specifiek en uiteindelijk codegeneratie. Verder kan gesteld worden dat in MDA, de kwaliteitwaarborg, meer versleuteld zit in de kwaliteit van modeltransformatie- en codegeneratie processen. Daar dit geautomatiseerde processen zijn is de kans op bugs kleiner. DDD legt de focus op het verhogen van de kwaliteit van het domeinmodel (het hart van het systeem). De doelstellingen kunnen worden gerealiseerd door een gedegen kennis in het probleemdomein en toepassing van OO en DDD design patronen. DSL richt zich op een specifiek probleemdomein. Een DSL is declaratie en begrijpelijk voor domeinexperts, waardoor domeinexperts zelf een model specificatie kunnen maken. De doelstellingen worden bereikt door code generatie.

P.


MODELLEREN Gekeken naar de drie methodieken die bovenstaande doelstellingen proberen te bereiken kan vastgesteld worden dat voor allen modelleren essentieel is. De eerste stap, en meteen de grootste uitdaging voor de ontwikkelaar, is een model te definiëren. Een model beschrijft een probleemdomein op een abstract niveau. Er zijn wel verschillen in benadering van modellering tussen de drie methodieken. In MDA moeten de modellen, zeker op PIM niveau, een hoge mate van compleetheid en correctheid bevatten. Ze moeten tenslotte machinaal geïnterpreteerd en getransformeerd moeten worden. Modellen worden gespecificeerd in een MOF taal zoals UML en OCL. Dit soort modellen is te technisch en daardoor niet inzetbaar in de communicatie met domeinexperts. Modellen op het CIM niveau kunnen echter wat algemener worden gedefinieerd. In DDD worden modellen zo simpel mogelijk gehouden zodat ze ook begrijpbaar zijn voor domeinexperts. In DSL moeten modellen net zoals bij DDD begrijpbaar zijn voor de domeinexperts. Een DSL is echter formeler en kan geïnterpreteerd en getransformeerd worden door een machine.

G E M E EN S CH AP P E LI JK E

CO N T E XT

Wat duidelijk is, is dat MDA, DDD en DSL dezelfde doelen nastreven. Ook is het modelleren in alle drie essentieel. MDA versus DDD MDA en DDD zijn niet direct met elkaar te verbinden. Echter zijn de onderzoekers van mening dat kennis van DDD enorm kan bijdragen aan kwaliteit van het model. MDA kan worden beschouwd als transformatie en generatiegereedschap. Gereedschap alleen is niet genoeg voor het ontwikkelen van een applicatie. De ontwikkelaar heeft vaardigheden nodig voor het begrijpen van het probleemdomein en op een abstract niveau kunnen modelleren. Deze vaardigheden zijn gevat in DDD. DDD versus DSL In DDD staat de Ubiquitous Language centraal. Vrij vertaald is UL een specifieke taal voor een specifiek domein. In feite is UL dus een DSL. Het enige verschil is dat DSL een door een machine kan worden geïnterpreteerd. De onderzoekers zijn van mening dat een DSL een formele UL is. Dit kan DDD verrijken. MDA versus DSL Hoewel MDA ervan uitgaat dat modellen gespecificeerd moeten worden in OMG standaarden zoals UML en OCL, zien de onderzoekers veel ruimte voor DSLs binnen MDA. DSLs kunnen heel goed ingezet worden voor transformaties en code generatie. Een DSL zou bijvoorbeeld ingezet kunnen worden voor het genereren van een gebruikersinterface of andere technische services zoals een database mapping.

P.


C O N C LU SI E Er kan gesteld worden dat de gemeenschappelijke context eruit bestaat, dat MDA, DDD en DSL dezelfde hoofddoelstelling hebben; namelijk “verbeteren van software kwaliteit en reduceren van complexiteit”. Bij de drie methodieken staat het modelleren centraal. De ontwikkelaar die een applicatie wenst te creëren op basis van het MDA gedachtegoed:” modelleren  transformeren  code genereren”, kan de methodieken gecombineerd gebruiken. Centraal staat dan het modelleren in een MDA modelleertaal. Voor enkele transformaties en code generaties kunnen DSLs heel goed van dienst zijn. Echter, de kwaliteit van de software is sterk afhankelijk van hoe goed de ontwikkelaar het probleemdomein zich eigen kan maken, hoe goed hij kan abstraheren en hoe goed hij een creatieve oplossing voor het probleem kan modelleren. Deze vaardigheden worden gegeven in de DDD leer. Hierin staat de UL (Ubiquitous language) centraal, en heeft als doel om een gemeenschappelijke taal te ontwikkelen en consistent te gebruiken tussen ontwikkelaar en businessexpert. De UL zou geformaliseerd kunnen worden in een DSL. Tijdens het UL proces groeit de kennis over het probleemdomein enorm. De ontwikkelaar is hierdoor beter in staat om de juiste abstracties te vinden. Dit komt de kwaliteit van de modellen ten goede.

P.


P O S I TI O N E RI N G

V AN

M I CR O S O F T O S L O

Voordat in dit hoofdstuk beschreven wordt wat Microsoft Oslo is, is het handig om eerst te kijken wat Microsoft zelf zegt over wat Oslo is en wat momenteel de huidige definitie is van Oslo. Dit is belangrijk omdat de definitie in de loop van de tijd aan verandering onderhevig is geweest. Om geen misverstanden te laten bestaan over welke definitie van Microsoft Oslo er gesproken wordt binnen het onderzoek, worden hieronder dus eerst de definities van Microsoft Oslo in de tijd besproken.

O NTWIKKELINGEN

V AN

M ICROSOFT O SLO

Sinds de bekendmaking van Microsoft, dat zij starten met Oslo op de PDC van 2007 (september) is de definitie van het Oslo-project de afgelopen 2 jaar meerdere malen bijgesteld. De definitie van Microsoft Oslo was in 2007: “A multiyear, multiproduct effort to simplify the application development lifecycle by enhancing .NET, Visual Studio, BizTalk and SQL Server” (Purdy, 2009) De volgende definitie van Oslo is beschreven door Aaron Skonnard na het bezoeken van de Microsoft PDC 2008 “Oslo is a new modeling platform being developed by the Connected Systems Division (CSD) at Microsoft. CSD includes the teams responsible for Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), BizTalk Server, and other related technologies. The “Oslo” modeling platform promises to simplify the way we design, build, and manage systems using these CSD technologies, as well as potentially many others down the road.” (Skonnard, 2008) Door deze wijzigingen in de definitie en ook de scope van Oslo raakten de klanten van Microsoft Oslo in verwarring wat Oslo nou precies inhoudt. Douglas Purdy zegt hierover het volgende: “Based on this, we made two decisions. We started using the term “Oslo” for only the modeling platform pieces of the overall vision. In addition, we would roll out a bunch of technologies in the .NET 4.0 wave.” (Purdy, 2009) En tijdens de laatste PDC in november 2009 is bekend gemaakt dat Oslo ondergebracht is binnen het Microsoft SQL-Server platform en is de codenaam Microsoft Oslo omgezet tot SQL-Server Modeling Services. Dit pakket wat voorheen doorging voor Oslo bestaat uit de volgende onderdelen: -

M language M language tools (MGrammar, MGraph) SQL Service Modeling Services Quadrant

P.


Microsoft Oslo bestaat uit 3 hoofdonderdelen, namelijk de taal ‘M’, de ‘SQL Server Modeling Database’ en Quadrant een tool waarmee data makkelijk op verschillende manieren visueel is weer te geven. Daarnaast wordt een aparte tekstuele tekstverwerker meegeleverd waarmee de taal M en overige dialecten en vertalingen mee bewerkt kunnen worden, genaamd Intellipad.

DE

TAAL

‘M’

De taal ‘M’ is een datamodelleringstaal die dus niet gezien moet worden als een programmeertaal, maar eerder als een datamodelleringstaal waarmee men het datamodel, dataconstraints, dataverzoeken (functies/queries) en de data zelf kan modelleren. Het onderdeel MSchema waaraan wordt gerefereerd als er gesproken wordt over de taal ‘M‘ zorgt voor het datamodel, de dataconstraints en de dataverzoeken. MGraph is de naam voor de notatie binnen M waarmee de data zelf beschreven wordt. MGrammar is een toevoeging aan ‘M’ waarmee de syntax van elke willekeurige codetaal beschreven kan worden. Syntax Microsoft heeft ervoor gekozen om de syntax van de ‘M’ developer-friendly te maken wat inhoudt dat de syntax in ‘M’ sterk lijkt op de C-syntax die ook binnen vele andere programmeertalen deels overgenomen en uitgebreid is. (MPNA) Vooral aan de herkenbare accolades en de wijze waarop commentaar kan worden toegevoegd aan de modellen is dit te herkennen. Hiernaast zijn er ook nieuwere zaken toegevoegd aan de syntax zoals het gebruik van Attributes, zoals attributes binnen C# gebruikt worden en zeer vergelijkbaar is met Annotations zoals deze met Java 5+ mogelijk zijn. Voor de exacte specificatie van de syntax en mogelijkheden van de taal ‘M’ heeft Microsoft de M “Community Specification Group” in het leven geroepen, deze groep van mensen is verantwoordelijk voor de totale M specificatie. Hiernaast is een korte definitie te zien van een rapport gemodelleerd in de taal M en dient als voorbeeld om een beeld te krijgen van de ‘M’-syntax.

A FBEELDING 7 P.


Functionaliteit M is dus een datamodelleringstaal waarmee men de datastructuur kan beschrijven, de relaties tussen de deze sets van data en de dataconstraints, dus datgene wat een dataset een dataset maakt. Ook dataverzoeken kunnen worden beschreven door een MQuery te specificeren. Datastructuren worden beschreven middels extents, Types bevatten de datastructuren. Deze kunnen uiteindelijk worden vertaald naar de tabellen in SQL-Server 2008. Constraints kunnen zowel op velden van types als op extents zelf beschreven worden. Deze kunnen binnen SQL Server 2008 worden vertaald naar respectievelijk CheckConstraints en insert-Triggers. M Language Tools Met MGrammar is het mogelijk om ook zelf de syntax van een DSL te beschrijven. Dit wordt gedaan door het beschrijven van de relatie tussen tokens en vrije tekst die door de eindgebruiker van de te beschrijven taal is op te geven. De tokens zijn de vaste onderdelen van de syntax, en kunnen keywords zijn, maar kunnen ook bestaan uit leestekens. Middels het bij de CTP meegeleverde Intellipad is het mogelijk om tijdens het schrijven van een DSL, gelijkertijd een editor te hebben waarbinnen tekst opgegeven in de te beschrijven taal wordt gevalideerd, als een editor voor de MGrammar van deze taal en een editor weer te geven voor het resultaat van de DSL. Deze laatste bevat de MGraph. MGraph is de output van de conversie uitgevoerd met MGrammer van de opgegeven tekst in de beschreven DSL en bestaat uit de data in de DSL beschreven in de vorm van syntax correcte M. M in vergelijking met SQL en XML Desondanks is de taal dusdanig ontworpen dat middels vertalingen alle informatie vastgelegd in M, vertaald kan worden naar Transact-SQL. (Het SQL-Dialect van Microsofts SQL-server platform). Zo zou men de Data Definition Language van SQL kunnen zien als de manier waarop datastructuren met M worden vastgelegd (d.m.v. types en extents). De DML (Data Manipulation Language) van SQL is weer te mappen op wat binnen M benoemd wordt als Query expressions. Hiermee zijn functies te definiëren die een bepaalde set van data beschrijft. Een andere vergelijking die snel getrokken is, is die van M versus XML/XSD. Ook met M is data direct te beschrijven zoals dit ook met XML mogelijk is. Maar ook de structuur van de data, het datamodel, en de constraints hierop, zoals deze beschreven worden met XSD kunnen binnen M worden vastgelegd. Deze vergelijking brengt direct een extra vergelijking met zich mee, namelijk die tussen de M variant MGrammar en XSLT. Beide zorgen voor transformatie van gegevens naar een ander formaat. Waar XSLT dit doet om het ene XML naar een ander XML format te transformeren kan MGrammar overweg met alle vormen van tekst. M in Visual Studio Met de SQL-Server Modeling CTP van November 2009 worden er mogelijkheden geboden om binnen Visual Studio 2010 Beta, M-modellen te definieren . Deze kunnen handgeschreven worden, maar kunnen ook gegenereerd worden vanuit een bestaande database. Daarnaast biedt Visual Studio 2010 (Beta) de P.


mogelijkheid om van de ‘M’ modellen klassen te genereren die dan gebruiksklaar als entity gebruikt kunnen worden en dus opgeslagen kunnen worden in de database, Microsoft gebruikt hiervoor het bestaande Microsoft Entity Framework. (Microsoft (MSDN), 2009)

Q UADRANT Visie ‘Quadrant’ is een datavisualisatie- en manipulatieomgeving. Het is een SQL-Server tool waarmee data en dus modellen binnen de ‘SQL-Server modeling services database’ op diverse manieren bekeken en gewijzigd worden. De zogeheten views op de data worden ook in de taal ‘M’ gedefinieerd en opgeslagen in de ‘SQL-Server modeling services database’. Volgens Microsoft is deze tool gemaakt met in het achterhoofd de vaak grote datasets binnen bedrijven en is deze tool bedoeld om juist binnen deze omgevingen makkelijk en snel deze grote hoeveelheden data, weer te geven en te navigeren. (Purdy, 2009) Visualisatie Quadrant bestaat uit een oneindig groot canvas (werkgebied) waarop men kan werken met zogeheten ‘Workpads’. Een workpad kan tekst bevatten (‘M’ of SQL) of kan bestaan uit een View waarmee data op een bepaalde manier bekeken kan worden. Standaard biedt Quadrant detailviews voor databaserecords, en views voor meerdere database records. Quadrant biedt de mogelijkheid om de gebruiker zijn eigen views te laten maken. De A FBEELDING 8 gebruiker kan dit doen door deze binnen Quadrant “in elkaar te klikken”, maar kan dit ook door deze te definiëren in de taal ‘M’ via de sourcefile van een View, of hij kan dit doen door een view op het model van een view te openen, deze te wijzigen en op te slaan. Ook kunnen sets van data gefilterd worden door gebruik te maken van voorgedefinieerde queries op de data, of door een runtime query balk die bovenaan een view zichtbaar te maken is. Hiernaast biedt Quadrant de mogelijkheid om add-ins te installeren. Deze add-ins kunnen worden geprogrammeerd met Visual studio en worden als dll aangeboden aan Quadrant. Met deze Add-ins is het mogelijk om.Net code uit te voeren, maar ook om de Quadrant runtime aan te sturen en deze bijvoorbeeld Views te laten openen, of om bijvoorbeeld Workpads te verplaatsen. P.


Manipulatie Datamanipulatie is mogelijk binnen Quadrant door in een detailview de eigenschappen van een record aan te passen. Ook kunnen er records worden toegevoegd aan de database middels het ‘Insert New Item’ commando binnen een view. Records verwijderen kan gedaan worden door op het kruisje te klikken naast de records die in sommige views zichtbaar zijn. Nadat deze wijzigingen op de data zijn gedaan kan de gebruiker middels het commando ‘Save Changes’ de wijzigingen doorvoeren in de database. Als er conflicten optreden of er wordt niet voldaan aan bepaalde constraints bij het aanpassen van een record worden deze nu zichtbaar in het standaard error-scherm (tevens een view op een tabel in de database).

A FBEELDING 9

In theorie is het mogelijk om met Quadrant een eenvoudige datagecentreerde applicatie te maken waarmee men betrekkelijk eenvoudig door de data kan scrollen en eigen Views kan maken zonder daadwerkelijk te programmeren. (Microsoft (PDC), 2009) In de praktijk blijken er momenteel nog een aantal dingen te schorten aan de werking van deze tool, maar doordat dit een CTP is en dus nog geen Bèta- of final versie is, zal hier verder geen oordeel over gegeven worden.

I NTELLIPAD Intellipad is een tekst editor met voor verschillende codetalen een eigen modus. Hiermee kunnen diverse talen gevalideerd en beschreven worden. Er zijn standaard plugins beschikbaar en het is mogelijk om zelf plugins te maken. Met een eigen plugin is het bijvoorbeeld mogelijk een modus te maken voor een eigen DSL. Hiernaast is een voorbeeld te zien van de DSL P.


A FBEELDING 10

modus, waarin een eigen DSL gemaakt wordt. In het midden is de MGrammar te zien, links de input en rechts wordt de uiteindelijke MGraph getoond.

SQL S ERVICE M ODELING S ERVICES Voordat de Community Technology Preview (CTP) van november was verschenen stond dit onderdeel bekend als de Microsoft Oslo Repository voor developers de plek om alle gemaakte modellen in op te slaan. Op de Microsoft site behorende bij de “SQL Server Modeling Service CTP november 2009” staat het volgende vermeld; “The repository and domains are now collectively called SQL Server Modeling Services. The Repository database still retains that name and is referred to as “the repository database”.

De SQL Service Modeling Database bestaat inmiddels dus uit meer dan allen een vaste plek binnen SQLServer 2008 waar de gemaakt modellen opgeslagen kunnen worden. De SQL Server Modeling Services is inmiddels uitgebreid, het wordt nu gepresenteerd als een rol van het SQL-Server platform dat het mogelijk maakt om op een eenduidige manier de diverse applicaties binnen het Microsoft Business segment met elkaar te laten communiceren. Alle informatie die gedeeld wordt tussen deze applicaties worden in M beschreven en dienen als een gemeenschappelijk domein. Voorbeelden van metamodellen die Microsoft inmiddels al heeft beschreven in M en vast ondergebracht heeft in de SQL-Server Modeling Services zijn onder andere de UML2 specificatie (2.1.1) (Microsoft (MSDN), 2010), Microsoft Identity Services wat de toekomstige vervanger is van de Active Directory Services en de standaard runtime tabellen van SQL-Server 2008 zelf. (Microsoft (PDC), 2009)

UML2 Voor de release van de SQL-Service Modeling Services in november 2009 was dit nog geen onderdeel van Oslo, maar stond dit bekend onder de codenaam project Rosario (Levinson, 2008). Doordat dit een subonderdeel is van de SQL-Server Modeling Services en in het grote raakvlakken heeft met de hoofdvraag van dit onderzoek wordt deze Service hieronder wat verder uitgelicht. De mogelijkheden die Microsoft op dit moment biedt binnen deze service is de mogelijkheid om UML2modellen opgeslagen als XMI bestanden te importeren naar SQL-Server waar ze dan opgeslagen kunnen worden in een aantal standaard readonly tabellen. Op het moment van schrijven biedt Microsoft nog geen mogelijkheid om deze modellen te updaten, slechts importeren, verwijderen en exporteren behoort tot de mogelijkheden. Voor het importeren en exporteren van de modellen van en naar XMI heeft Microsoft binnen de CTP een aantal tools beschikbaar gesteld. Naast de structuur van de specificatie biedt Microsoft in UML2 een API met hierin een aantal functies waarmee informatieverzoeken gedaan kunnen worden over de opgeslagen modellen in de UML2-Service. Denk hierbij aan zaken zoals welke klassen hebben een directe afhankelijkheid van supertype X, of hebben een functie Y. P.


Bronverantwoording De meeste informatie gebruikt om te komen tot de inhoud van dit hoofdstuk is afkomstig van Microsoft’s Developer Network. Deze informatie is te vinden via: http://msdn.com/data. Ook komen enkele onbeschreven beweringen voort uit eigen ervaring opgedaan door diverse proefprojecten met de verschillende onderdelen van de CTP. Waar direct aan de informatie gerelateerde bronnen zijn gebruikt, wordt dit aangegeven.

P.


C O N T R AS TE RI N G M I CR O S O F T O S L O T . O . V . MDA, DDD

EN

DSL

In het hoofdstuk “Wat is de gemeenschappelijke context voor MDA, DDD en DSL?”, is bepaald dat DDD, MDA en DSL bij elkaar gebracht kunnen worden in een gemeenschappelijke context. Deze gemeenschappelijke context, komt erop neer dat de onderzochte methodieken, elkaar treffen op twee hoofdpunten: 1. 2.


In dit hoofdstuk wordt in eerste instantie, getoetst of Microsoft Oslo te plaatsen is in de eerder gedestilleerde gemeenschappelijke context, ten einde de hoofdvraag “In hoeverre ondersteunt Microsoft Oslo het gedachtegoed achter MDA, DDD en DSL en de principes en concepten die hier achter liggen?”, te beantwoorden. Is Microsoft Oslo te plaatsen in de gemeenschappelijke context die gedeeld wordt door de methodieken DDD, MDA en DSL? Deze vraag kan beantwoord worden door Microsoft Oslo te toetsen op de twee hoofdpunten, ‘doelstelling’ en ‘modelleren’ uit de gemeenschappelijke context. Wat betreft het eerste hoofdpunt, ´doelstelling´, kan gesteld worden dat de doelstelling van MS Oslo, dezelfde is als de doelstelling uit de gemeenschappelijke context. Deze bewering wordt ondersteunt door onderstaande citaten, waarin Microsoft, haar doelstelling met MS Oslo weergeeft: "Oslo" is the codename for Microsoft's next generation application development platform. The goal of "Oslo" is to provide a 10x productivity gain across the application lifecycle (design, development, and management). "Oslo" uses domain-specific models, languages and tools to achieve this goal.” (Microsoft) “Oslo is a new modeling platform being developed by the Connected Systems Division (CSD) at Microsoft. CSD includes the teams responsible for Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), BizTalk Server, and other related technologies. The “Oslo” modeling platform promises to simplify the way we design, build, and manage systems using these CSD technologies, as well as potentially many others down the road.” (Skonnard, 2008) Zoals bovenstaande citaten duidelijk maken, en in het hoofdstuk ´Positionering Microsoft Oslo´ duidelijk naar voren komt, is MS Oslo een modeleer platform. Het ontwikkelen binnen MS Oslo, concentreert zich op het modelleren en het ontwikkelen op basis van modellen. Hiermee voldoet MS Oslo ook aan het tweede hoofdpunt, ´modelleren´, uit de gemeenschappelijke context. Gelet op bovenstaande, kan de conclusie getrokken worden dat Microsoft Oslo de twee hoofdpunten ´doelstelling´ en ´centraal stellen van modellen´ ondersteunt. Hiermee is Microsoft Oslo te plaatsen in de gemeenschappelijke context die gedeeld wordt door DDD, MDA en DSL.

P.


Deze conclusie is echter niet voldoende om de hoofdvraag volledig te beantwoorden. Het maakt alleen duidelijk dat Microsoft Oslo op een hoog en abstract niveau, het gedachtegoed achter DDD, MDA en DSL ondersteunt. Het ´gedachtegoed´ is één onderdeel van de hoofdvraag. Echter deze positieve conclusie voor wat betreft ondersteuning van het gedachtegoed, rechtvaardigt het verder kijken naar in hoeverre Microsoft Oslo, de principes en concepten achter DDD, MDA en DSL ondersteunt. In hoeverre ondersteunt Microsoft Oslo het gedachtegoed achter MDA, DDD en DSL en de principes en concepten die hier achter liggen? Microsoft Oslo is te plaatsen in de gemeenschappelijk context die gedeeld wordt door DDD, MDA en DSL. Dit is in de beantwoording van de vorige subvraag verder gemotiveerd. Hiermee kan geconcludeerd worden dat MS Oslo het gedachtegoed achter DDD, MDA en DSL volledig ondersteunt. In dit hoofdstuk wordt verder gekeken naar in hoeverre MS Oslo de principes en concepten achter DDD, MDA en DSL ondersteunt. Dit wordt gedaan door MS Oslo te contrasteren met de drie methodieken elk afzonderlijk. Contrastering MS Oslo ten opzichte van DDD Er is een duidelijke mismatch in de notie van modelleren tussen MS Oslo en DDD. Modelleren in MS Oslo is gericht op het modelleren van data en metadata met behulp van de M Language Tools. DDD daarentegen, focust op het modelleren van het domein, bij voorkeur, maar niet verplicht, met behulp van UML en OOP. Gezegd moet worden dat DDD, DSL niet uitsluit en MS Oslo ondersteuning biedt voor het importeren en opslaan van UML2 modellen in haar repository. MS Oslo kan een belangrijke ondersteuning verlenen aan DDD voor wat betreft Strategic Design. De Repsitory zou de rol van Context Map kunnen spelen waarin de modellen kunnen worden opgeslagen en bewaakt. Met Quadrant zijn de modellen in de verschillende contexten te raadplegen en te bekijken. “OSLO really opens up the possibilities of true domain-driven-design, very simply, by allowing different domain representations to be transformed into a standard structured data form. This affords different model-aware/assisted systems domains interaction with each other in their own dialects of the DSL, including visual dialects.” (Krishnan, 2008) De huidige beschikbare MS Oslo tooling alleen, is echter te beperkt voor realisatie van een volledige enterprise applicatie. Het is niet mogelijk om een gebruikers interface of een gelaagde architectuur te realiseren. Binnen het onderzoekskader moet daarom gesteld worden, dat de ondersteuning van MS Oslo voor DDD, beperkt is. Als echter ontwikkeld wordt in het DOT NET platform van Microsoft en de combinatie MS Oslo met MS Visual Studio beschouwd wordt, dan kan gesteld worden dat de ondersteuning volledig is voor DDD. Aangezien MS Oslo volledig integreert met de aankomende versies van MS Visual Studio, krijgt de DDD ontwikkelaar een coherente ontwikkelomgeving ter beschikking. Contrastering MS Oslo ten opzichte van MDA MS Oslo ondersteunt MDA met de voorziening voor het importeren en opslaan van MDA modellen (CIM, PIM, PSM) gebaseerd op UML2 met behulp van het XMI (XML Model Interchange) format. Het kunnen uitwisselen van modellen gebaseerd op MOF (UML2 en OCL) tussen tool vendors is een kernstreven van P.


MDA. MS Oslo ondersteunt echter, en nog maar zeer recent, alleen UML2. Hiermee kiest MS Oslo een eigen weg, en beperkt het de MDA droom, die ervan uitgaat dat er meerdere modelleertalen gebaseerd op MOF zullen ontstaan. Aanvullend moeten modellen in MDA volledig en compleet zijn teneinde deze machinaal te kunnen transformeren tot uitvoerbare applicaties. UML is niet genoeg voor een complete modelspecificatie, en OCL is nodig voor het specificeren van constraints. MS Oslo biedt verder geen out of the box transformatiegereedschap voor realisatie van MDA modeltransformaties. De inzetbaarheid van MS Oslo, is gezien de huidige staat, voor MDA zeer beperkt. Wel lijkt Microsoft met Oslo een deur open te houden voor mogelijke verdere ondersteuning van MDA/OMG specificaties. Na de toetreding van Microsoft aan de OMG werd het volgende gezegd; “In a prepared statement, Bob Muglia, senior vice president Microsoft’s server and tools business, said that modeling was going to be built in as a core part of the company’s application platform. He noted that Microsoft believes modeling will help make IT more dynamic, helping business analysts, developers and systems architects to work together more effectively to create and maintain applications.” (Worthington, 2008)

Contrastering MS Oslo ten opzichte van DSL MS Oslo ondersteunt DSL volledig. Het modelleren binnen MS Oslo is gebaseerd op het maken van DSL modellen in de ‘M’ taal. Microsoft heeft eerder met haar DSL Tools platform, sterk ingezet op DSL’s en heeft veel ervaring op dit gebied. Een pluspunt is dat MS Oslo, de ontwikkelaar voorziet van een goede ontwikkelomgeving (code completion, syntax highlighting, parsers…) voor het ontwikkelen van DSL’s. Beantwoording van de hoofdvraag Voor de beantwoording in hoeverre Microsoft Oslo het gedachtegoed achter MDA, DDD en DSL en de principes en concepten die hier achter liggen ondersteunt, kan gesteld worden, dat het gedachtegoed bestaande uit de doelstelling voor het verbeteren van softwarekwaliteit, het verhogen van productiviteit en het reduceren van complexiteit en kosten en het centraal stellen van modelleren en modellen, door MS Oslo volledig wordt ondersteund. De ondersteuning is ook als volledig te beschouwen voor wat betreft het ondersteunen van DSL. Modellen binnen Oslo worden gedefinieerd met behulp van de M DSL, waarvoor de geleverde ontwikkelomgeving goede ondersteuning biedt. Wat betreft MDA, kan gesteld worden dat MS Oslo de mogelijkheid biedt om MDA modellen (CIM, PIM, PSM), mits gedefinieerd in UML2 op te slaan. Een kernstreven van MDA is de uitwisselbaarheid van modellen. MS Oslo voorziet in de uitwisselbaarheid van modellen. Deze modellen zijn beschreven conform de L3 CMOF(Complete Meta Object Facility) standaarden (Microsoft (MSDN), 2010). Echter ontbreekt in de repository een model voor de onderliggende CMOF. Dit is een serieuze schending van de MDA filosofie waarbij er vanuit gegaan wordt dat op basis van de CMOF er naast UML2 ook andere modelleertalen zullen ontstaan. Deze talen worden doordat de vertaling naar CMOF niet te maken is binnen Oslo verder niet ondersteund. Ook heeft MS Oslo geen voorzieningen voor transformatie van MDA modellen en codegeneratie, waardoor een MDA ontwikkelaar niet volledig wordt bediend. Het lijkt erop P.


dat Microsoft een deur open houdt voor MDA en nu naast DSL’s ook UML serieus begint te nemen. Een verwachting over de toekomstige richting voor MDA binnen Microsoft is moeilijk uit te spreken. De verwachting van de onderzoekers is dat dit nauw zal samenhangen met een mogelijke trend richting Model gedreven softwareontwikkeling binnen de ICT. Binnen DDD kan MS Oslo een nuttige bijdrage leveren in het kader van ‘Strategic Design’. De repository van MS Oslo kan goed dienen als Context Map voor het opslaan van DDD modellen en het bewaken van model consistentie (‘Bounded Contexts’). Met Quadrant kunnen modellen door diverse ontwikkelteams worden bekeken en worden gemanipuleerd. Echter gelet op de huidige staat van MS Oslo, is het nog niet mogelijk om een reële enterprise-applicatie te realiseren. Hiermee is de voorlopige conclusie dat de ondersteuning van MS Oslo voor DDD, als beperkt, beschouwd moet worden.

P.


C O N CL US I E De conclusies ten aanzien van de methodieken DDD, MDA en DSL zijn getrokken in de respectievelijke hoofdstukken waarin deze methodieken zijn behandeld. In dit hoofdstuk wordt gefocust op conclusies aangaande de hoofdvraag: “In hoeverre ondersteunt Microsoft Oslo het gedachtegoed achter MDA, DDD en DSL en de principes en concepten die hier achter liggen?” Microsoft biedt met Oslo – wat nu door het leven gaat onder de naam SQL Server Modeling -, een basisset aan tools waarmee men een modelgedreven ontwikkeling ondersteunt. Deze ondersteuning bestaat uit een opslagmiddel voor UML2-modellen, een toolset voor het maken van een Domain Specific Language en de open gespecificeerde datamodelleertaal M. In het hoofdstuk “Wat is de gemeenschappelijke context voor MDA, DDD en DSL?”, is bepaald dat de methodieken DDD, MDA en DSL bij elkaar gebracht kunnen worden in een gemeenschappelijke context. Deze gemeenschappelijke context, komt erop neer dat de onderzochte methodieken, elkaar treffen op twee hoofdpunten: 1. 2


In het hoofdstuk “Contrastering Microsoft Oslo t.o.v. MDA, DDD EN DSL”, is gebleken dat Microsft Oslo, aan beide hoofdpunten voldoet. Hiermee is binnen het onderzoekskader, de ondersteuning van Microsoft Oslo, voor het gedachtegoed achter DDD, MDA en DSL, als volledig te beschouwen. In het subhoofdstuk “Contrastering MS Oslo ten opzichte van DDD”, is onderkend dat de huidige MS Oslo tooling, te beperkt is voor het realiseren van een enterprise applicatie. Binnen het onderzoekskader moet daarom gesteld worden dat de ondersteuning van MS Oslo voor DDD beperkt is. Als echter ontwikkeld wordt in het .NET platform van Microsoft en de combinatie MS Oslo met MS Visual Studio wordt beschouwd, dan kan gesteld worden dat de ondersteuning volledig is. Aangezien MS Oslo volledig integreert met de aankomende versies van MS Visual Studio, krijgt de DDD ontwikkelaar een coherente ontwikkelomgeving ter beschikking. Een groot pluspunt is dat de MS Oslo repository een goede ondersteuning kan bieden voor de Strategic Design filosofie van DDD. De Repsitory zou de rol van Context Map kunnen spelen waarin de modellen kunnen worden opgeslagen en bewaakt. Met het MS Oslo onderdeel Quadrant, zijn de modellen in de verschillende contexten door verschillende ontwikkel teams te raadplegen en te bekijken. Met haar recentelijk voorziening voor het importeren, opslaan en uitwisselen van UML2 modellen met behulp van het XMI (XML Model Interchange) formaat, lijkt MS Oslo een deur open te zetten voor MDA. Modellen in MDA moeten volledig en compleet zijn, ten einde deze machinaal te kunnen transformeren tot uitvoerbare applicaties. UML alleen is niet genoeg voor een complete modelspecificatie. Verder biedt MS Oslo geen out of the box transformatiegereedschap voor realisatie van MDA modeltransformaties. Gelet op de huidige staat van MS Oslo moet gesteld worden dat de ondersteuning voor MDA vooralsnog beperkt is. Wil MS Oslo MDA ondersteunen, dan zou het moeten voorzien in de mogelijkheid voor het importeren en uitwisselen van modellen gebaseerd op de MDA MOF specificatie, waarvan UML2 en OCL twee implementaties zijn. Verder zal MS Oslo moeten voorzien in codegeneratie en gereedschap voor P.


transformatie ten behoeve van de nodige MDA modeltransformaties (CIM -> PIM -> PSM). Het is op dit moment niet vast te stellen of Microsoft een strategie heeft in deze richting. MS Oslo ondersteunt DSL volledig. Het modelleren binnen MS Oslo is gebaseerd op het maken van DSL modellen in de ‘M’ taal. Microsoft heeft eerder met haar DSL Tools platform, sterk ingezet op DSL’s en heeft hiermee veel ervaring op dit gebied. Een pluspunt is dat MS Oslo, de ontwikkelaar voorziet van een goede ontwikkelomgeving (code completion, syntax highlighting, parsers…) voor het ontwikkelen van DSL’s.

P.


A A N B E VE L I N G E N In het kader van dit onderzoek kunnen nog enkele aanbevelingen worden geuit. Ten eerste en ten aanzien van Microsoft Oslo waar dit onderzoek zich op heeft gericht, moet gezegd worden dat MS Oslo veel potentie heeft om model gedreven software ontwikkeling op termijn effectief te ondersteunen. Vooral als het DOT NET platform van Microsoft in zijn geheel wordt beschouwd. Aangezien MS Oslo nog in de kinderschoenen staat is het advies om de ontwikkelingen nauwlettend te volgen, maar daadwerkelijke inzet nog af te wachten. Model gedreven software ontwikkeling is op zich niet nieuw maar is wel snel volwassen aan het worden. Initiatieven van MDA, opmars van DSL’s, alsmede investeringen vanuit de software-industrie en wetenschappelijk onderzoek, dragen hieraan bij. Het is niet te verwachten dat de softwareontwikkelaar, binnen afzienbare tijd overbodig zal worden. Wel is duidelijk dat zijn rol en manier van werken zullen gaan verschuiven. De trend zal zijn dat de ontwikkelaar meer zijn software zal modelleren i.p.v. programmeren. Code generatoren zullen steeds meer gaan zorgen voor de programmatuur. Inzet van code generatoren zal de productiviteit verhogen, waardoor er waarschijnlijk minder mankracht nodig zal zijn. Een vergelijking is wellicht te maken met het industrialisatieproces, dat veel handarbeid overbodig heeft gemaakt. Een modelgedreven aanpak vraagt een ontwikkelaar met grote analytische vermogens om op een hoog niveau te kunnen abstraheren en te modelleren. Zijn toegevoegde waarde zal bestaan uit zijn oplossingsvermogen voor probleemdomeinen van de business. Een aanbeveling die dan ook te maken is om een vervolgonderzoek te starten waarmee antwoord geven kan worden op de vraag hoe de kennis en kunde van het modelleren bijgebracht kan worden aan codegerichte ontwikkelaars. Waarbij met name aandachtspunten zullen zijn op de vraag welke invloeden er zijn op een ontwikkelteam, wanneer men model gedreven softwareontwikkeling toepast samen met het gebruik van codegeneratoren. En welke gevolgen heeft dit op de samenstelling binnen een ontwikkelteam. En wat is dan de beste manier van werken binnen dit ontwikkelteam.

P.


L I TE R A T U U RL I J S T Association, IEEE Standard. (sd). IEEE Recommended Practice Architectural Description of SoftwareIntensive Systems. Belo, W. (2004, Juni 1). Model driven architecture Specificeren van functionaliteit. Opgeroepen op 11 1, 2009, van CWI: http://homepages.cwi.nl/~paulk/thesesMasterSoftwareEngineering/WilfredBelo.pdf Boll, D. i. (sd). Complexiteit reductie door Architecture-frameworks. Vermindering van de intersubjectieve complexiteit door het werken aan een Enterprise Architectuur en het gebruik van het Zachman architectuur raamwerk. Brand, m. v. (2005, Decemeber 04). Hypes versus onderzoek in Software engineering. Opgeroepen op 11 02, 2009, van hva: http://www.hva.nl/lectoraten/documenten/ol07-041215-vandenbrand.pdf Clementson, B. (2004, December 20). Metaprogramming is hard. Opgeroepen op December 24, 2009, van Bill Clementson's Blog: http://bc.tech.coop/blog/041220.html Consel, C., Fisher, K., Gray, J., Karsai, G., Mernik, M., & Tolvanen, J.-P. (2009, April 10). DSLs: The Good, the Bad, and the Ugly. Orlando, Florida, USA. Cook, S. (2004, 01). Domain Specific Modeling and Model Driven Architecture. MDA Journal . Cunningham & Cunningham, Inc. (2008, December 24). Domain Specific Language. Opgeroepen op December 24, 2009, van Cunningham & Cunningham, Inc.: http://c2.com/cgi/wiki?DomainSpecificLanguage Danny Greefhorst, H. K. (sd). Dimensies in architectuur. Dikke Van Dale. Woordenboek. Dillen, E. v. (2007, April 27). DDD in de praktijk. Opgeroepen op November 2, 2009, van SDN: http://www.sdn.nl/SDN/Artikelen/tabid/58/view/View/ArticleID/2405/Domain-Driven-Design-in-dePraktijk.aspx Edwin van Dillen / Andre Boonzaaijer - Sogyo. (2007, November 8). DDD en DSL: een mooie combinatie! Opgeroepen op November 1, 2009, van edwinvandillen.nl: http://edwinvandillen.nl/wordpress/wpcontent/uploads/2007/11/dddendsl.pdf Evans, E. (2004). Domain Driven Design. Boston: Addison Wesley / Pearson Education Inc. Fokus franhofer. (2009, 01 02). Fokus Fraunhofer. Opgeroepen op 10 12, 2009, van Fokus: bron http://www.fokus.fraunhofer.de/en/motion/news_events/veranstaltungsreihen/ecmda/index.html Fowler, M. (2006). Applying Domain-Driven Design and Patterns. Boston: Addison Wesley / Pearson Inc. Fowler, M. (2005). MF Bliki: DomainSpecificLanguage. Opgeroepen op December 24, 2009, van Martin Fowler: http://martinfowler.com/bliki/DomainSpecificLanguage.html

P.


Fowler, M. (2004, 02). Model Driven Architecture. Opgeroepen op 10 04, 2009, van fowler.com: http://martinfowler.com/bliki/ModelDrivenArchitecture.html Fowler, M. (2003, 09 12). PlatformIndependentMalapropism. Opgeroepen op 10 03, 2009, van http://martinfowler.com/bliki/PlatformIndependentMalapropism.html Gamma, H. J. (1994). Design Patterns. Addison-Wesley. Graham, P. (2003, April). Beating the Averages. Opgeroepen op December 24, 2009, van Paul Graham: http://www.paulgraham.com/avg.html Groot, E. d. (2005, Augustus 31). CWI. Opgeroepen op November 3o, 2009, van Software kwaliteit van MDA tools: http://homepages.cwi.nl/~paulk/thesesMasterSoftwareEngineering/EdwinDeGroot.pdf H.A. Proper, W. v. (2002). De pragmatiek van architectuur. ibm. (2002, 01 01). IBM. Opgeroepen http://www.zurich.ibm.com/pdf/ebizz/gardner-etal.pdf

op

10

13,

2009,

van

IBM:

IEEE Standard Association. (sd). http://standards.ieee.org. Opgeroepen op 09 23, 2009 Iyutu. (2005, Oktober 25). Opgeroepen op Oktober 7, 2009, van wat is een concept: http://iuty.punt.nl/index.php?id=265304&r=1&tbl_archief Jongsma, E. (2005, December 1). Domain Specific Language SOFTWARE FACTORIES ONTRAADSELD. Opgeroepen op December 24, 2009, van Microsoft Download Center: http://www.google.nl/url?sa=t&source=web&ct=res&cd=2&ved=0CAkQFjAB&url=http%3A%2F%2Fdownl oad.microsoft.com%2Fdownload%2F2%2Fe%2Fe%2F2eec0dc6-7100-440a-978522d5e614624f%2FNet11_p33-36_1_05.pdf&ei=3brDSs7DOo_ZQaJuP3uCw&usg=AFQjCNF1s2MvON3eT4GuQk-x7AvkfPA3 Kelly, S., & Tolvanen, J.-P. (2008). Domain-Specific Modeling - Enabling full code generation. Hoboken, New Jersey: John Wiley & Sons, Inc. Krishnan, D. (2008, 12). infoQ. Opgeroepen op 01 10, 2010, van http://www.infoq.com/articles/naturallanguage-date-dsl-oslo Larman, G. (2004). Applying UML and patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Addison Wesley Professional. Levinson, J. (2008, April 18). Doing Architecture with Team System Rosario. Opgeroepen op January 19, 2010, van Visual Studio Magazine: http://visualstudiomagazine.com/articles/2008/04/18/doingarchitecture-with-team-system-rosario.aspx M. Himi, G. d. (2009). Verslag Zachman framework. M. Himi, G. d. (2009). Verslag Zachman framework.

P.


Martin Fowler, K. B. (1999). Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional. MDSD. (2005, 12 01). Model driven Software Development. Opgeroepen op 10 20, 2009, van MDSD: http://www.mdsd.info Microsoft (MSDN). (2009, November 23). Getting Started with SQL Server Modeling CTP and Visual Studio 2010. Opgeroepen op December 18, 2009, van Microsoft Developer Network: http://msdn.microsoft.com/en-us/library/ee713219(VS.85).aspx Microsoft (MSDN). (2010, Januari 1). MSDN UML2. Opgeroepen op 1 8, 2010, van Microsoft Developer Network: http://msdn.microsoft.com/en-us/library/dd857485(VS.85).aspx Microsoft (PDC). (2009, November 18). Building Data-Driven Applications Using Microsoft Project Code Name "Quadrant" and Microsoft Project Code Name "M". Opgeroepen op December 12, 2009, van Microsoft PDC 2009: http://microsoftpdc.com/Sessions/FT50 Microsoft (PDC). (2009, November 19). SQL Server Modeling Services: Using Metadata to Drive Application Design, Development and Management. Opgeroepen op Januari 8, 2010, van PDC 2009: http://microsoftpdc.com/Sessions/SVR19 Microsoft. (sd). Microsoft Connect. Opgeroepen op 1 10, 2010, van http://connect.microsoft.com/oslo Object Management Group. (2009, Juni 18). OMG Model Driven Architecture. Opgeroepen op November 22, 2009, van omg.org: http://www.omg.org/mda/ OMG. (2003). MDA Guide V1.0 .1 . OMG. (03, 03 01). OMG. Opgeroepen op 11 12, 2009, van OMG: http://www.omg.org/cgibin/doc?formal/03-03-01 OMG. (2003, Juni 01). OMG. Opgeroepen op November 15, 2009, van OMG: http://www.omg.org/cgibin/doc?omg/03-06-01.pdf Purdy, D. (2009, November 10). DouglasPurdy.com. Opgeroepen op November 24, 2009, van From “Oslo” to SQL Server Modeling: http://www.douglaspurdy.com Ralf Wolter, Thomas Zeeman, Edwin van Dillen - Sogyo. (2007, April). Publicaties Sogyo. Opgeroepen op Oktober 20, 2009, van sogyo.nl: http://www.sogyo.nl/wpcontent/uploads/Publicaties/DDD_SD_April_2007.pdf Renier, M. (2009, 09 19). http://en.wikipedia.org/wiki/QVT

QVT.

Opgeroepen

Runde. (2003, Maart 01). IFI. Opgeroepen http://heim.ifi.uio.no/~ketils/sardas/UIO-IFI-RR304.pdf

op

op

11

02,

November

2009,

20,

van

2009,

Wikipedia:

van

HEIM:

S, N. (2003, Mei 02). Agder University College. Opgeroepen op 11 13, 2009, van Master: http://student.grm.hia.no/master/ikt03/ikt6400/g04/selowarsun.pdf P.


Sessions, R. (2007). Exclusive interview with John Zachman. Tolvanen, D. J.-P. (2006, Februari 15). Domain-Specific Modeling: How to Start Defining Your Own Language. Opgeroepen op December 24, 2009, van DevX.com: http://www.devx.com/enterprise/Article/30550 van Deursen, A., Klint, P., & Visser, J. (2000, Februari 9). Domain-Specific Languages: An Annotated Bibliography. Opgeroepen op December 24, 2009, van Homepage of Arie van Deursen: http://homepages.cwi.nl/~arie/papers/dslbib/ Verlaenen, K. (2008, Maart). Middleware for Advanced Service Conﬁguration: a Policy-Based Approach. Leuven: Kris Verlaenen. Volter, M. (2004, Mei 20). Voelter. Opgeroepen op 10 30, 2009, van Pattern of model driven development: http://www.voelter.de/data/pub/MDDPatterns.pdf W.Th. de Boer, M. d. (2003). van Dale Pocketwoordenboel. Utrecht - Antwerpen: Van Dale Lexicografie. Wikipedia. (2009, October 19). Domain-specific language. Opgeroepen op December 24, 2009, van Wikipedia: http://en.wikipedia.org/wiki/Domain-specific_language Worthington, D. (2008, September 11). Microsoft joins Object Management Group. Opgeroepen op December 23, 2009, van sdtimes.com: http://www.sdtimes.com/link/32840 Zachman, J. (1987). A framework for information systems architecture.

P.


Onderzoeksrapport Projectgroep Microsoft Oslo

Recommend Documents