Onderzoeksrapport Projectgroep Microsoft Oslo

Transcriptie

1 Onderzoeksrapport Projectgroep Microsoft Oslo Project Minor EAD 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

2 MAN AG EMEN TS AMEN V ATTIN 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. Doelstelling: het streven naar verbeteren van software kwaliteit, het verhogen van productiviteit en het reduceren van complexiteit en kosten. 2. 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 - Onderzoeksrapp ort - Projec tgroep Microso ft Oslo

3 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. 3 VAN 45 - Onderzoeksrapp ort - Projec tgroep Microso ft Oslo

4 INHO UDS O PG AVE 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 Wat zijn principes en concepten? Model Driven Architecture Verkenning Definitie Model Driven Architecture MDA concepten MDA Principes Beschouwing MDA Domain Driven Design Verkenning Definitie Concepten Principes Beschouwing DDD Domain Specific Language (DSL) Definitie Concepten Principes Voordelen Nadelen Wat is de gemeenschappelijke context voor MDA, DDD en DSL? doelstelling modelleren Gemeenschappelijke context Conclusie Positionering van Microsoft Oslo Ontwikkelingen van Microsoft Oslo De taal M Quadrant P. 4 VAN 45 - Onderzoeksrapp ort - Projec tgroep Microso ft Oslo

5 Intellipad SQL Service Modeling Services UML Contrastering Microsoft Oslo t.o.v. MDA, DDD en DSL Conclusie Aanbevelingen Literatuurlijst P. 5 VAN 45 - Onderzoeksrapp ort - Projec tgroep Microso ft Oslo

6 VO ORWOO 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. 6 VAN 45 - Onderzoeksrapp ort - Projec tgroep Microso ft Oslo

7 INLEIDING PROBLEEMSTELLING 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. ON DERZO EK SVRAAG 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. Verkenning MDA, DDD en DSL 2. Positionering van Microsoft Oslo 3. Contrastering Microsoft Oslo t.o.v. MDA, DDD en DSL SCOPE 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 DEELVRAGEN Om de opgestelde hoofdonderzoeksvraag uiteindelijk goed te kunnen beantwoorden zijn er per deelonderzoek, onderstaande sets van deelvragen gedefinieerd. VERK EN NING 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. 7 VAN 45 - Onderzoeksrapp ort - Projec tgroep Microso ft Oslo

8 POSITIONERING VAN MICRO SO FT OS 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? CONT RAST ERING MICROSO FT OSLO 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? STRATEGIE & METHODEN In dit subhoofdstuk volgt een verantwoording van de gebruikte bronnen en onze onderzoeksstrategie. ON DERZO EK SMAT ERIAAL 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. 8 VAN 45 - Onderzoeksrapp ort - Projec tgroep Microso ft Oslo

9 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 begrepen zijn. Een vergelijking is te maken met de VS.NET, ECLIPSE en NETBEANS IDE 1. Deze IDEs bieden allemaal mogelijkheden voor het refactoren 2 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 2 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) P. 9 VAN 45 - Onderzoeksrapp ort - Projec tgroep Microso ft Oslo

10 VE RKENNIN G MDA, DDD E N 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. WAT 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. 10 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

11 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. 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. 2. 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. 3. 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. 11 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

12 MODEL DRIVEN ARCHI TE CTURE 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. VERKENNING DEFINI TI E MODEL DRI VEN AR CHITECT 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. Er zijn specificaties voor uitwisselbaarheid, herbruikbaarheid en portabiliteit van software componenten gebaseerd op standaard modellen. 2. 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. 12 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

13 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 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. 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. 2. Platform Independent Viewpoint: de focus van deze viewpoint is de systeemoperatie. De specificaties binnen deze viewpoint zijn onafhankelijk van het doelplatform van het systeem. 3. Platform Specific Viewpoint: deze viewpoint introduceert de nodige details voor een specifiek platform. MDA Views 1. 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. 2. 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. 13 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

14 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 CONCEPT 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. 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. 2. 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. 14 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

15 while another model might assume the availability a particular set of tools for the CORBA platform. (OMG, 2003) 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. 3. 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 AFBEELDING 1 (OMG, 2003) voor het doelplatform en bevat de nodige implementatie details. 4. 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 PRI N CIPES Onderstaand de principes die kunnen worden gedestilleerd uit de verkenning van MDA. 1. MDA specificeert drie modellen CIM (computation independent model), PIM (platform independent model) en PSM (platform specific model). 2. 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. 15 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

16 dienen in hoge mate van compleetheid te worden gespecificeerd om interpretatie en transformatie door een machine mogelijk te maken. 3. 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. 4. 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). 5. Enkel het PIM model is verplicht in MDA. Overige nodige transformaties kunnen worden gebakken in een commercieel MDA product. 6. 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. BESCHOUWI NG 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. 16 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

17 - 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. 17 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

18 DO MAI N DRIVE N DESI GN VERKENNING DEFINI TI 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. AFBEELDING 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. CONCEPT 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. 18 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

19 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 AFBEELDING 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. 19 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

20 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. PRINCIPES 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. AFBEELDING 4 DOMAIN DRIVEN. 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. Gebruik het separation of concerns principe door implementatie van een gelaagde architectuur (layered architecture). 3. Elimineer overbodige associaties. 4. Organiseer code in modules en deel deze logisch in op basis van UL. 5. 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. 20 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

21 BESCHOUWI NG 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. 21 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

22 DO MAI N SPE CIFIC LAN GUAGE (DSL) DEFINITIE 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 AFBEELDING 5 (SPINELLIS, 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 naar de host taal. De Cee Gee Language 3 is een voorbeeld van een EDSL waarbij de AFBEELDING 6 (SPINELLIS, 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 P. 22 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

23 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). CONCEPTEN 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. PRINCIPES 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. 23 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

24 afbeeldingen. (Een algemene term voor DSLs gericht is op het bouwen van zakelijke gegevensverwerkende systemen is 4th Generation Language (4GL)) VOORDELEN 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) NADELEN 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. 24 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

25 WAT IS DE GE MEENS CHAP PELI JKE CON TEXT VOO 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. DOELSTELLING De methodieken MDA, DDD en DSL beschouwend op beoogde doelstelling kan vastgesteld worden dat ze alle drie onderstaande doelstellingen nastreven: 1. Verbeteren van software kwaliteit in termen van onderhoudbaarheid, uitbreidbaarheid, gebruiksvriendelijkheid en toegevoegde waarde voor de business. 2. Reduceren van complexiteit. 3. Verhogen van productiviteit. 4. 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. 25 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

26 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. GEMEEN S CHAP PELI JK E CO NT EXT 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. 26 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

27 CONCLUSI 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. 27 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

28 POSI TIONERIN G V AN MICROSOF T OSLO 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. ONTWIKKELINGEN VAN MICROSOFT OSLO 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. 28 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

29 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. AFBEELDING 7 P. 29 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

30 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 Constraints kunnen zowel op velden van types als op extents zelf beschreven worden. Deze kunnen binnen SQL Server 2008 worden vertaald naar respectievelijk Check- Constraints 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. 30 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo

31 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) QUADRANT 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 gebruiker kan dit doen door deze binnen AFBEELDING 8 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. 31 VAN 45 - Onderzoeksrapport - Projec tgroep Microso ft Oslo