ADVANCED DESIGN PATTERNS

Transcriptie

1 ADVANCED DESIGN PATTERNS CAPITA SELECTA Behorend bij het afstudeerproject: Generiek framework voor administratieve toepassingen in een webgeoriënteerde omgeving Henk van de Ridder December 2006, versie 3 Open Universiteit Nederland, faculteit Informatica Masteropleiding Technische informatica

2 Samenvatting In dit verslag wordt het onderzoek beschreven van de zoektocht naar de patterns en practices voor de ontwikkeling van software voor administratieve systemen. Doel is het inventariseren van de algemene design patterns en het gebruik hiervan te bepalen in de moderne ontwikkelomgevingen als J2EE.NET en Ruby-on-Rails (RoR). Startpunt voor het literatuuronderzoek vormt de standaard opsomming van design patterns van de GoF. Deze design patterns beperken zich tot het ontwerp en de bouw van de objectgeoriënteerde softwareonderdelen. Voor de ontwikkeling van administratieve applicaties, ook wel enterprise applications genoemd, zijn door Fowler design patterns beschreven. Deze design patterns blijken ook in de moderne ontwikkelomgevingen volop aanwezig te zijn. J2EE,.NET en Ruby-on-Rails baseren zich op de n-tier architectuur, wat ook een pattern is, en op de design patterns: model-view-controller (MVC), factory en façade. Het factory design pattern vinden we vooral terug in de object relational mappings: koppelingen tussen objecten en relationele databases. Bij het in het afstudeerproject te ontwikkelen framework kunnen de door Fowler beschreven design patterns als leidraad genomen worden. Aanvullend onderzoek is nodig voor Inhoud 1 Inleiding Design patterns Sofware engineering Design patterns volgens GoF Design Patterns na GoF Patterns en practices bij administratieve software ontwikkeling Patterns of Enterprise Application Architecture Design Patterns binnen moderne ontwikkelomgevingen NET: Microsoft J2EE: Java2 Enterprise Edition RoR: Ruby-On-Rails Wetenschappelijk onderzoek Vergelijking van de moderne ontwikkelomgevingen Afronding Literatuur Henk vd Ridder,OU

3 1 Inleiding Dit verslag van de Capita Selecta Advanced Design Patterns is onderdeel van de afstudeeropdracht: Generiek framework voor administratieve toepassingen. De doelstellingen van deze afstudeeropdracht volgen uit de onderstaande samenvatting van de afstudeeropzet van juni 2006: De afstudeeropdracht Generiek framework voor administratieve toepassingen omvat het ontwerpen en realiseren van een algemeen toepasbaar framework voor administratieve applicaties in een webgeoriënteerde omgeving. De administratieve applicaties dienen ter ondersteuning van het primaire bedrijfsproces van serviceverlenende bedrijven. De opdracht omvat allereerst een literatuurstudie over de theoretische design patterns en practices gerelateerd aan de praktisch voorgestelde oplossingen in de Java/J2EE,.NET en open source omgevingen. Op basis van het in de literatuurstudie verkregen inzicht zal functioneel en technisch een applicatieframework ontworpen worden, waarmee snel administratief georiënteerde applicaties gebouwd kunnen worden. Essentieel is dat het framework een oplossing biedt voor het generiek vastleggen van product specifieke kenmerken binnen de product-, order- en serviceprocessen. Het gaat hier om het kunnen definiëren van gegevensvelden waarvan aantal, naam en type bepaald worden door de productcategorie. Ook de workflow-processen dienen gestuurd te worden door de productcategorie en gegevenswaarden van de specifieke kenmerken Een eerste stap in het afstudeerproject is het in kaart brengen van de bestaande moderne oplossingen voor het realiseren van software binnen administratieve omgevingen. Onder software voor een administratieve omgeving wordt verstaan het registreren van, verwerken van en rapporteren over de administratieve gegevens binnen een bedrijfsproces, zoals klant-, order-, product- en servicegegevens. Het ontwikkelen van software is veelal een moeizame klus. Deze klus begint met het bepalen van de eisen waaraan de software moet voldoen, gevolgd door het opstellen van een functioneel ontwerp. Hierna start de ontwikkeling met het technisch ontwerp gevolgd door het programmeren. Na uitgebreide testen en het opleiden van de gebruikers kan de software in gebruik genomen worden [BRU02]. Al meer dan 10-tal jaren speelt het begrip design patterns in het softwareontwerp en het programmeren een rol. Een informele omschrijving van een design pattern is een standaardoplossing voor een algemeen probleem in een bepaalde context [BOO99]. Het voordeel van het hebben van een standaardoplossing voor deelproblemen is dat niet elk deelprobleem weer opnieuw uitgezocht, uitgewerkt en uitgetest hoeft te worden. Verder bieden design patterns een begrippenkader: het verwijzen naar de standaardoplossing geeft al voldoende informatie hoe een bepaalde oplossing geïmplementeerd moet worden. In deze Capita Selecta wordt zoektocht gedaan naar design patterns, die het fundament kunnen vormen voor het in het afstudeerproject te ontwikkelen framework Allereerst wordt het ontstaan van design patterns onderzocht. Van daaruit wordt onderzocht welke design patterns specifiek voor administratieve software in een webgeoriënteerde omgeving bekend zijn. Hierna worden deze design patterns getoetst op hun rol binnen de op dit moment leidende moderne ontwikkelomgevingen:.net, J2EE en open source oplossingen rond Ruby-On-Rails. Deze moderne ontwikkelomgevingen worden tevens onderzocht op aanvullende praktische ontwikkelrichtlijnen Het onderzoek omvat het bestuderen van de gevonden literatuur en het beschrijven wat er in deze literatuur naar voren wordt gebracht. Henk vd Ridder,OU

4 2 Design patterns Wanneer in de softwareliteratuur gesproken wordt over design patterns wordt vrijwel altijd verwezen naar het boek: Design Patterns, Elements of Reusable Object-Oriented Software van Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, e.a. [GAM01] uit Dit boek geeft een gestructureerd opzet van standaardoplossingen voor het ontwerpen van herbruikbare object georiënteerde software. Hierna is de trend ontstaan om bij het beschrijven van hulpmiddelen voor de softwareontwikkeling te praten over patterns en practices om aan te geven hoe de software het beste ontwikkeld kan worden. Bijvoorbeeld het design pattern model-view-controller (MVC) wordt in webgeoriënteerde softwareontwikkeling altijd benoemd [NET02][SUN02][HIB05a]. In de volgende paragraven wordt allereerst bepaald welke rol het begrip design pattern speelt binnen het vakgebied Software engineering. Na de beschrijving van de design patterns volgens Design Patterns, Elements of Reusable Object-Oriented Software worden de patterns en practices beschreven voor de software ontwikkeling van administratieve software, ook wel enterprise applications genoemd. 2.1 Sofware engineering Het vakgebied software engineering houdt zich bezig met de bestudering van de aspecten die een rol spelen bij het bouwen, beheren en onderhouden van grote softwaresystemen waarbij meerdere teams software engineers betrokken zijn. Het uiteindelijke doel is dat er kwalitatief goede software wordt geschreven. Elk boek over software engineering [BRU03][GHE02][VLI00] heeft zo zijn eigen opsomming van de aspecten die de kwaliteit van software bepalen. Het boek: Object-Oriented Software Engineering: van Bruegge [BRU03] beschrijft expliciet dat de softwarekwaliteit bepaald wordt door de mate waarin de factoren: complexity en change ingebed worden in de softwareontwikkeling. Met complexity wordt gedoeld op de veelomvattende functionele en technische eisen waar een softwaresysteem aan moet voldoen. Het begrip change omvat de steeds weer veranderende eisen tijdens de software ontwikkeling en het anticiperen op toekomstige wijzigingen in de software als gevolg van veranderingen in de bedrijfsvoering, organisatie en technologie nadat een applicatie in gebruik is genomen. De factor complexity wordt verminderd door de software in te delen in overzichtelijke, herbruikbare delen. Het indelen van software: modularisatie is al decennia lang onderdeel van studie binnen de software engineering [PAR72]. De theorie voor het bepalen wat een goede module is vervat in de woorden koppeling en cohesie: een goede module bestaat uit software met een hoge cohesie, dat is interne afhankelijkheid en een lage koppeling, dat is externe afhankelijkheid [VLI00]. Ook design patterns hebben als doel de complexiteit te beheersen door herbruikbare ontwerpen van standaardoplossingen te beschrijven. Andere ICT-termen, gerelateerd aan design patterns, die ook als doel hebben om de complexity te beheersen zijn architectuur, framework en component: - Een architectuur omvat het vastleggen van het geheel van principes en modellen waarmee de informatievoorziening van een organisatie wordt vormgegeven [WAG01]. Een van de principes van de architectuur kan zijn dat de software in het bedrijf met behulp van frameworks ontwikkeld wordt. - Een framework is een herbruikbaar applicatieskelet waarvan de specifieke opvulling bepaald wordt door het bedrijfsproces waarvoor de applicatie dient Henk vd Ridder,OU

5 [FAY97]. design patterns en componenten vormen de onderdelen van een framework [JOH97]. - Een component is een op zich zelf staande herbruikbare deelapplicatie [BRO00]. Als design pattern komt een component ontwerptechnisch overeen met het design pattern: façade. Een goede keuze van componenten is naast de factor complexity ook positief voor de factor change De factor change wordt ook verminderd door een juist ontwerp van de modulen van een applicatie. Bij een goed ontworpen beperken de wijzigingen zich dan tot enkele onderdelen of componenten [BRO00]. Het bijbehorende begrip design-for-change (DfC) is enerzijds al oud [PAR78], anderzijds is het één van de steunpilaren van de moderne manier van software ontwikkelen: agile programming [THO05][MAR03]. Design patterns hebben ook als doel om de aanpasbaarheid van de software te bevorderen OUM02]. Uit het bovenstaande kunnen we concluderen dat design patterns een wezenlijk onderdeel vormen binnen het vakgebied software engineering en als zodanig zeer relevant voor de realisatie van kwalitatief hoogwaardige software. Binnen het afstudeerproject zullen ze waar mogelijk benut moeten worden. 2.2 Design patterns volgens GoF Het boek: Design Patterns, Elements of Reusable Object-Oriented Software van Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides [GAM01] beschrijft 23 design patterns voor het ontwikkelen van object georiënteerde software. Deze vier schrijvers worden in de literatuur vaak aangeduid met de afkorting GoF (Gang of Four). Hierbij wordt verwezen naar de Chinese leiders in de jaren 90 van de vorige eeuw. Net zoals die Chinese leiders een revolutie binnen het communisme brachten hebben deze vier schrijvers een revolutie in de software ontwikkeling teweeg gebracht. De basisgedachten van de GoF worden verduidelijkt in het boek: Design Patterns Explained van Shalloway e.a. [SHA02] en luiden: - Design to interfaces: Baseer ontwerpen op interfaces en leidt de concrete klassen af uit de interfaces. Het doel is onafhankelijke klassen te verkrijgen, waardoor aanpassing van één klasse geen consequenties heeft voor andere klassen. - Favor composition over inheritance: Eén van de pijlers van objectgeoriënteerde ontwikkelen is inheritance. Het nadeel is dat elke klasse in een inheritance-hiërachie afhankelijk is van alle bovenliggende klassen, waardoor aanpassingen (changes) moeilijk te realiseren zijn, doordat de aanpassing binnen de hele hiërarchie een rol speelt. Compositie doorbreekt deze afhankelijkheid door klassen via een relatie naar elkaar te laten verwijzen en zo geen hiërarchie via inheritance te laten ontstaan. - Find what varies and encapsulate it: Door op zich zelf staande verwerkingen af te zonderen verkrijgt men klassen met een eenduidige verwerking. Dit wordt in nietobject georiënteerde programmeertalen aangeduid met koppeling en cohesie. In tabel 1 wordt een opsomming gegeven van de design patterns volgens GoF. Bij elk design pattern staat de scope, het doel en de variatiemogelijkheden, die ermee beoogd worden. Scope is het onderscheid waar het pattern op gericht is: de definiërende klasse of een specifiek Object Variatie staat in dit verband synoniem voor de mogelijkheden tot change. Tabel 1 geeft slechts een beknopte beschrijving van doel en variatiemogelijkheden, voor een uitgebreide toelichting wordt verwezen naar het boek van de GoF. Henk vd Ridder,OU

6 Naam Scope Doel Variatiemogelijkheden Purpose: Creational: het aanmaken van nieuwe objecten - Factory Class De creatie van een concrete klasse via een interface definiëren. - Abstract Factory Object Het bieden van een interface voor het aanmaken van verwante objecten - Builder Object De creatie van samengestelde objecten afzonderen - Prototype Object Het aanmaken van objecten door middel van het kopiëren van een prototype. - Singleton Object Afdwingen dat een klasse maar één instantie krijgt. Het bepalen van de specifieke te creëren subklasse. Welk specifiek object er concreet wordt aangemaakt. Hoe een samengesteld object wordt gecreëerd Welk object er wordt aangemaakt. n.v.t. Purpose: Structural: het indelen van klassen en objecten - Adapter Class/ Omzetten ven een specifieke Object interface naar gewenste interface - Bridge Object Ontkoppelen van abstractie en implementatie - Composite Object Uniformeren van het samenstellen van boomstructuren - Decorator Object Dynamisch toevoegen van functionaliteit aan een object - Façade Object Aanbieden van een uniforme interface naar een subsysteem - Flyweight Object Uniformeren van het omgaan met grote hoeveelheden objecten - Proxy Object Plaatsvervangende tussenpersoon bieden voor een ander object De interface naar een object De concrete implementatie van een object De concrete samenstelling van een objectstructuur De functionaliteit van het object De interface naar een subsysteem Het verminderen resource-eisen van object De afgeschermde toegang tot een object Purpose Behavioral: de interactie en taakverdeling tussen de objecten - Interpreter Class Het omvormen naar een doeltaal De samenstelling en uitvoering van de doeltaal - Template Class Het definiëren van een template De stappen in een algoritme Method voor het algoritme - Chain of Object Het dynamisch bepalen van de uit Het toewijzen van uit te voeren taken responsibility te voeren taken - Command Object Het inpakken van een opdracht in een object De keuzemogelijkheid van uit te voeren taak - Iterator Object Het doorlopen van lijsten De soort lijst die doorlopen moet worden. - Mediator Object Het definiëren hoe een groep objecten elkaar informeert Hoe de communicatie over en weer tussen objecten uitgevoerd wordt. - Memento Object Het externaliseren van de state van Welke gegevens van een object een object bewaard blijven - Observer Object Definiëren van een 1 op n relatie Hoe de afhankelijke objecten tussen objecten. geïnformeerd worden - State Object De presentatie van de inhoud Welke states een object kan hebben van een object - Strategy Object Het bepalen van een concreet Het verwerkingsalgoritme verwerkingsalgoritme - Visitor Object Het toevoegen van extra Welke functionaliteit een klasse biedt functionaliteit Tabel 1: Design patterns volgens GoF In tabel 1 komt het Model-View-Controller (MVC) design pattern niet voor. In de introductie van het boek van de GoF wordt uitgelegd dat MVC opgebouwd is uit de design patterns: observer, composite en strategy. Henk vd Ridder,OU

7 De bovenstaande opsomming van design patterns is beperkt is tot het doelgebied: herbruikbare objectgeoriënteerde software en gericht op het bepalen van interfaces, klassen en objecten bij het ontwikkelen van objectgeoriënteerde software. Toen het boek in 1994 verscheen was men immers nog heel sterk bezig met de overgang van procedurele naar objectgeoriënteerde software. De waarde van deze design patterns voor de realisatie van een concreet applicatieproject wordt geïllustreerd in de presentatie Patterns at Work van Buschmann [BUS01]. Buschmann was met zijn boek Pattern-Oriented Software architecture [BUS96] ook één van de voortrekkers van design patterns.voor het in het afstudeerproject te ontwikkelen framework zullen deze design patterns als basis gebruikt worden, immers de software voor het framework zal ook objectgeoriënteerd ontwikkeld worden. De verwachting is echter dat naast deze algemene design patterns er meer design patterns en practices zijn die gebruikt kunnen worden. Met name voor de aspecten webgeoriënteerd en administratief zullen design patterns en practices gezocht worden. 2.3 Design Patterns na GoF Na de GoF-publicatie is veelvuldig onderzoek gedaan naar deze design patterns. Hierbij heeft men zich o.a. gericht op verbeteren van de classificatie en het onderkennen van aanvullende design patterns. Classificatie is bedoeld om te bepalen welk design pattern in welke situatie van belang is. Alleen het opstellen van een verzameling design patterns is niet nuttig, maar het kunnen vinden van een design pattern bij een bepaald probleem maakt de verzameling toepasbaar. Een interessante publicatie is Relationships between Design Patterns [ZIM95] van Zimmer. Allereerst onderkent hij dat de design patterns: bridge, builder, command, iterator, observer, state, strategy en visitor allemaal gericht zijn op het objectiveren, dat is groeperen van een bepaald gedrag. Hij plaatst deze patterns onder één basis pattern: objectifier. Ook geeft hij een gestructureerde beschrijving van de relaties tussen de design patterns. Hierna geeft hij een classificatie van de design patterns waarbij hij de vraag probeert te beantwoorden: welke design patterns moeten wanneer gebruikt worden. Zijn classificatie omvat: - Basis design patterns en technieken, die vrijwel altijd van toepassing bij objectgeoriënteerde software ontwikkeling zoals adapter en objectifier. - Design patterns voor bepaalde software problemen, zoals bridge en state. - Design patterns voor een specifiek applicatie domein, zoals interpreter. Met name de onderkenning van objectifier, als basis design pattern om de software zo flexibel mogelijk te laten zijn, is interessant voor het in het afstudeerproject te ontwikkelen applicatie framework. Door elk soort gedrag op een generieke wijze te verpakken in een objectifier wordt het mogelijk om software wijzigingen als gevolg van wijzigingen in het gewenste gedrag te beperken tot aanpassingen binnen de objectifier. Een ander belangrijk vraagpunt is of de design patterns volgens de GoF omschrijving wel alles omvatten. In de publicatie A Catalogue of General-Purpose Design Patterns [TIC98] wordt door Tichy een catalogus van meer dan 100 algemeen toepasbare patterns beschreven. Tichy beperkt zich niet tot objectgeoriënteerde software maar hij combineert de design patterns van de GoF met patterns die al veel langer, veelal impliciet, toegepast worden, zoals module en layer, pipes, filters en eventhandling. Tichy rangschikt de patterns op basis van de problemen die ermee opgelost worden. Dit omdat een ontwerper uitgaat van een probleemstelling en daar een oplossing voor zoekt. Verder maakt hij onderscheid tussen algemeen toepasbare en applicatiespecifieke design patterns. In tabel 2 worden de groepen patterns weergegeven. Henk vd Ridder,OU

8 Naam Decoupling Variant State handling Control Virtual machines Convenience Beschrijving Het indelen van software systemen in onafhankelijke delen (replaceable, reusable). Al vanaf 50-er jaren gangbaar. Bijv. Module, Abstract Data Type (bijv. database, Client-server, Manager-Collection, Iterator), Layer (Bijv. Sandwhich, Façade, Bridge, Proxy), Pipeline, Event notification (catch, throw, call-back, propagator), Framework De verschillen objecten uniform behandelen: Superclass, Visitor, Template, Abstract factory De manipulatie van de state van een object: Singleton, Prototype, Flyweight, Memento De besturing van de programma-executie en methode selectie: Blackboard, Command, Chain of Responsibility, Strategy, State, Master-Slave, Process Control De simulatie van een processor: Interpreter, Rule-based interpretor Het concentreren van vaak gebruikte code: Default, Null, Convenience class Compound Verzameling patterns, waarbij de onderliggende patterns zichtbaar zijn: Model-View- Controller, BureauCracy, Active Bridge Concurrency Verzameling patterns die parralel en gelijktijdige excutie besturen, bijv. Semaphore, Monitor, Event Loop, Daemon, Transaction, etc Distribution Oplossing van problemen in gedistribueerde systemen, bijv Protocol Stack, Router, Client/Server, Broker, etc Tabel 2: groepen Patterns volgens Tichy Voor het te ontwikkelen framework in het afstudeerproject zal ook verder gekeken worden dan alleen de bepaling van de juiste objecten. Doordat het framework een volledige applicatie zal omvatten zijn daarbij patterns uit de groepen decoupling, voor de indeling van de applicatie in lagen, en control, voor de wijze waarin het gedrag geplaatst wordt, bruikbaar. Ook variant en compound zullen zijn zinvol. De overige groepen zijn meer gericht op de computerarchitectuur dan op applicaties. Illustratief is dat er nog steeds onderzoek plaats vindt naar design patterns: onder de naam Pattern Language of Programs (PLoP) [HIL06] wordt nog jaarlijks een conferentie georganiseerd. 2.4 Patterns en practices bij administratieve software ontwikkeling Het afstudeerproject is gericht op het ontwikkelen van administratieve software. In de vorige paragraaf is aandacht besteed aan de algemene design patterns. De zoektocht gaat nu verder met de vraag welke design patterns specifiek voor webgeoriënteerde administratieve software relevant zijn. Één van de grotere, maar zeker het oudste bedrijf wat zich richt op administratieve software is IBM. In het IBM redbook Patterns: Service- Oriented Architecture and Web Services [IBM04] worden de volgende groepen patterns en practices voor webgeoriënteerde, door IBM e-business genoemd, applicaties onderkent: - Business patterns: Patterns voor het verzorgen van de interacties tussen gebruikers, bedrijven en gegevens voor eenvoudige end-to-end applicaties. - Integration patterns: Patterns voor het verbinden van de eenvoudige business patterns zodat een geïntegreerde applicatie ontstaat met volledige bedrijfsbrede functionaliteit. - Composite patterns: Patterns voor het combineren van business patterns en Integration patterns tot (zeer) geavanceerde algemeen toepasbare e-business applicaties. - Custom designs: Patterns als de composite patterns maar dan specifiek bedoeld voor een bepaald bedrijf of groep bedrijven waarbij specifiek de behoeften van deze bedrijven geïmplementeerd zijn. Henk vd Ridder,OU

9 - Application and runtime patterns: Patterns voor het beschrijven van de vorm van de applicaties zoals deze passen bij de gebruikerswensen - Product mappings: Patterns voor het samenstellen van standaardcomponenten tot een bruikbare oplossing. - Guidelines: Practices met de richtlijnen voor ontwerp, realisatie in bedrijfstelling en beheer van e-business applicaties. De samenhang tussen deze groepen patterns en practices staat afgebeeld in figuur 1. Figuur 1: E-business Patterns en Practices volgens IBM Uit deze groepering van patterns en practices volgt dat er bij het ontwikkelen van administratieve software verschillende deelgebieden onderscheiden moeten worden en dat elk deelgebied eigen design patterns heeft. Ook kunnen we concluderen dat naast de technische design patterns van de voorgaande paragraven ook de toepassingsgerichte (business) patterns noodzakelijk zijn bij de applicatiebouw. Webgeoriënteerde software valt onder de categorie gedistribueerde applicaties. Meer wetenschappelijk is door Dabous e.a. [DAB00] onderzoek gedaan naar de te onderscheiden deelgebieden waar design patterns toegepast kunnen worden. Zij concluderen dat de design patterns in drie hoofdgroepen zijn te verdelen: - Business design processen: waarbij het vooral gaat om design patterns te benoemen in de voor business mensen (de softwaregebruikers) begrijpbare terminologie. - Service based design patterns waarbij design patterns benoemd worden in het domein van de koppelingen tussen de verschillende applicaties (de middleware). - Technology based patterns: waarbij design patterns vooral gericht op de technische implementatie beschreven zijn in de technische terminologie. Deze drie hoofdgroepen komen globaal gezien overeen met indeling volgens IBM. De hoofdgroep business design processen komt grotendeels overeen met de business patterns van IBM, Service based design patterns met composite en het niet technische deel van de Henk vd Ridder,OU

10 integration patterns en de hoofgroep technology based patterns met runtime patterns, product mappings en het technische deel van de integration patterns. De door IBM benoemde guidelines worden door Dabous ingevuld door in projecten te kiezen voor een iteratief proces, inclusief prototyping voor het bepalen van de juiste toe te passen design patterns. In hun artikel laten zij ook voor een concreet applicatieproject zien hoe de design patterns bepaald worden. De relatie van deze patterngroeperingen met de design patterns volgens GoF is niet direct te leggen. Het abstractieniveau van de in deze paragraaf genoemde patterns is meer gericht op de realisatie van grote applicaties en de inpassing hiervan in grote organisaties. De design patterns volgens GoF komen pas te voorschijn bij het technisch ontwerp van details van deze applicaties. De verbinding kan deels gelegd worden door de in de vorige paragraaf aangeduide indeling van Tichy. De door hem aangegeven groep decoupling vinden we hier terug in het onderscheiden van verschillende groepen patterns. De conclusie van deze paragraaf is dat voor het in het afstudeerproject te ontwikkelen generieke framework ook gebruik gemaakt kan worden van de in deze paragraaf beschreven design patterns. Het framework zal de software voor de administratieve gebruiker gaan leveren. Allereerst dient de ontwikkelaar, die deze software met het framework bouwt, ondersteunt te worden in de vertaalslag van de gebruikerswensen, zoals opgesteld met behulp van business patterns, naar het framework. Verder kan in het framework gebruik gemaakt worden van de bovengenoemde design patterns die betrekking hebben op het koppelen van softwareonderdelen zowel onderling als met externe toepassingen. De hier genoemde design patterns zijn echter op een zodanig hoog abstractieniveau dat voor de concrete realisatie van het framework meer gedetailleerde design patterns op het gebied van applicatiearchitectuur welkom zijn. 2.5 Patterns of Enterprise Application Architecture Het begrip Enterprise applications is een aanduiding van het geheel aan administratieve software waarmee een grotere onderneming bestuurd kan worden. Door Fowler is in 2003 geprobeerd om een totale opsomming te maken van alle patterns die gebruikt worden voor het ontwikkelen van deze software. In zijn boek: Patterns of Enterprise Application Architecture [FOW03] beschrijft hij 51 patterns, die worden ingedeeld in de volgende groepen: - Domain Logic Patterns: Patterns voor het indelen van de logica in modulen lagen en transacties. - Data Source Architectural Patterns: Patterns voor het koppelen met records in database tabellen. - Object-Relational Behavioral Patterns: Patterns voor het koppelen van objectgegevens aan fysieke database tabelgegevens. - Object-Relational Structural Patterns: Patterns voor het uitvoeren van Object- Relational Mappings (ORM), dat wil zeggen het maken van een vertaalslag tussen de interne objecten structuur en de externe database structuur. - Object-Relational Metadata Mapping Patterns: Patterns voor het overdragen van de metadata (veldnamen en typen) tussen objecten- en databasestructuur. - Web Presentation Patterns: Patterns voor het beschrijven van de manieren hoe webgebruikersinteracties uitgevoerd kunnen worden. - Distribution Patterns: Patterns voor het collectief overdragen van objectgegevens. - Offline Concurrency Patterns: Patterns voor het veilig kunnen uitvoeren van asynchrone transacties. Henk vd Ridder,OU

11 - Session State Patterns: Patterns voor de tussentijdse opslag van de applicatie-states. - Base Patterns: Algemene patterns voor het verwerken van administratieve gegevens. Naast een uitgebreide beschrijving van elk design pattern in de bovenstaande groepen wordt door Fowler een toelichting gegeven over de afwegingen die de software ontwerper kan maken voor de keuze van een bepaald design patterns. Deze afwegingen zijn gegroepeerd rond de volgende titels: - Layering: beschrijft de noodzaak om een applicatie in de drie hoofdlagen: presentatie, bedrijfsdomein (bussiness rules) en dataopslag te verdelen. - Organizing Domain Logic: beschrijft de overwegingen om de domeinlogica (dat is de eigenlijke verwerkingen) te organiseren. Er worden drie soorten onderkent: procedureel, objectgeoriënteerd en gegevenstabelgeoriënteerd. - Mapping to Relational Databases: werkt de verschillen afbeeldingsmogelijkheden uit voor objecten op relationele tabellen en relationele relaties. - Web Presentation: geeft aan hoe de presentatie en verwerking van HTML pagina s kan plaatsvinden. Beschrijft de mogelijkheden van de Controller uit het Model- View-Controller (MVC) design pattern. - Concurrency: betreft de patterns voor de problemen die te maken hebben met gelijktijdig gebruik van een applicatie door meerdere gebruikers. Aspecten als locking, transactions en offline concurrency worden besproken. - Session state: beschrijft de werkwijze voor tussentijdse opslag tussen webpagina s. Het meest bekende voorbeeld is het winkelwagentje bij on-line shops. - Distribution strategies: geeft bruikbare oplossingen voor het verdelen van de object-gegevens in client-server applicaties en het gebruik van interfaces. Daar waar van toepassing verwijst Fowler in zijn beschrijving naar de design patterns volgens GoF. Net als Tichy onderkent hij dat er veel meer design patterns zijn. Ook het aspect van het zoeken van de juiste design pattern voor een concreet softwareprobleem ondervangt hij. Verder kiest hij als vertrekpunt uitdrukkelijk voor de business: zijn design patterns zijn bedoeld voor de administratieve software. Voor webgeoriënteerde applicaties worden onder de titel web presentation de design patterns uitgewerkt. De conclusie is dat alle applicatiegerichte aspecten van het in het afstudeerproject te ontwikkelen framework aan bod komen. Deze design patterns kunnen de basis vormen voor het in het afstudeerproject te realiseren framework. In het kader van het afstudeerproject zijn deze patterns ook zeer interessant omdat de publicatie is ontstaan na de eerste ontwikkelingen van de moderne administratieven software ontwikkelomgevingen:.net en J2EE. Deze patterns zijn ook afgeleid uit de praktijk van software ontwikkeling met.net en J2EE. In de volgende hoofdstukken worden deze ontwikkelomgevingen beschreven. Onderzocht wordt of deze ontwikkelomgevingen aansluiten bij deze Patterns of Enterprise Application Architecture en welke aanvullende practices er zinvol zijn. Henk vd Ridder,OU

12 3 Design Patterns binnen moderne ontwikkelomgevingen Het doel van dit hoofdstuk is aan te geven welke patterns en practices er voor de ontwikkeling van administratieve applicaties binnen de moderne ontwikkelomgevingen herkenbaar zijn. In dit hoofdstuk wordt een verkenning uitgevoerd naar de moderne ontwikkelomgevingen:.net en J2EE. Daarnaast wordt ook aandacht besteed aan de nietcommerciële omgevingen binnen de open source gebaseerd op Ruby-on-Rails. Bij deze verkenning ligt de nadruk op het herkennen van de design patterns en het zoeken van aanvullende ontwikkelpractices in de documentatie van de moderne ontwikkelomgevingen. 3.1.NET: Microsoft Basis voor de beschrijving van.net is het door Microsoft uitgegeven document: Application Architecture for.net: Designing Applications and Services [NET02] aangevuld met informatie verkregen uit diverse publicaties in de on-line kennisbank van Microsoft: MSDN [MIC06a][mic06b]..NET is het door Microsoft ontwikkelde framework voor webgeoriënteerde software ontwikkeling. Enerzijds is.net een doorontwikkeling van het Distributed Component Object Model (DCOM) voor client-server oplossingen. Anderzijds is.net een antwoord op de populariteit van de concurrerende J2EE Java omgevingen..net wordt als leidend gezien op het gebied van webservices. Het door Microsoft ontwikkelde protocol Simple Object Access Protocol (SOAP) is de defacto standaard voor de aanroep van webservices [W3C06]. De kern van.net wordt gevormd door de zogenaamde Common Language Runtime (CLR). Bij het programmeren in een door.net ondersteunde programmeertaal worden de instructies niet rechtstreeks vertaald naar machinetaal maar naar de machinetaal onafhankelijke Microsoft Intermediate Language (MSIL). Op moment van uitvoeren vindt door de CLR een Just In Time (JIT) omzetting naar machinecode plaats. Ook alle programmabibliotheken zijn in MSIL, zodat elke.net programmeertaal van dezelfde functies gebruik kan maken. De belangrijkste door Microsoft ondersteunde programmeertalen zijn Visual Basic en Visual C#, maar hiernaast zijn zowel door Microsoft als andere leveranciers ook talen als C++, Java en zelfs PHP mogelijk. De Microsoft Visual Studio.NET omgeving vormt het gereedschap voor de.net ontwikkelaar. De structuur van.net omvat de volgende elementen: -.NET framework class library: Het fundament van alle binnen de.net aangeboden functionaliteit in de vorm van klassen, interfaces en waardentypen. - ADO.NET: Het platform voor gegevenstoegang tot relationele databases. Door Microsoft wordt SQL-server gepropageerd, maar ook toegang tot bijvoorbeeld Oracle is mogelijk. - ASP.NET: Het platform voor de ontwikkeling van webgeoriënteerde toepassingen. Voor de gewone (client-)applicaties is er de WinForms omgeving. Een cruciaal onderdeel van de.net omgeving is extensible Markup Language (XML). XML wordt gebruikt voor de interne weergave van de gegevensstructuren, datasources Henk vd Ridder,OU

13 genoemd. XML verzorgt ook bij de uitwisseling van data tussen cliënt, server en webservices. Het SOAP protocol is zelf volledig geïmplementeerd met XML. De architectuur van de applicaties die ontwikkeld kunnen worden met.net is in figuur 2 weergegeven. Figuur 2:.NET architectuur Binnen.NET wordt de applicatie in vier lagen verdeeld met elk een aantal componenten: - Cliënt: omvat de interacties met de gebruikers o User Interface (UI) Components: de visuele componenten die zorgen voor de gebruikersinteracties: gegevenstonen, -invoer en validatie. o User Process Components: sturen het proces van dataverzameling van een bepaalde gebruikersactie: bijv. order ingeven: selectie klant, uitgeven order, vastleggen orderregels, etc. - Business: bevat de bedrijfsregels en applicatiefuncties o Service Interfaces (ook wel Business Façades genoemd): doel is het tonen van de bedrijfsregels (business logic) als een service, die extern aangeroepen kan worden o Business Workflows: coördineren van langdurende, meer-staps verwerkingsprocessen bijvoorbeeld de stappen vastlegging, uitlevering en facturering van verkooporder: o Business Components: de implementatie van de bedrijfsregels (business rules) en werktaken (business tasks). o Business Entities: verzorgen de eenvoudige informatieverstrekking over de business entiteiten als relaties, producten, orders, etc. - Data: de vastlegging van de gegevens Henk vd Ridder,OU

14 o Service Agents: doel is het isoleren, standaardiseren en verzorgen van de koppelingen met de externe webservices. o Data Access Logic Components: de logica om de dataverzamelingen (o.a. databases) te benaderen. - Systeemservices: systeemfuncties die bij elke applicatie nodig zijn. o Security: het centraal afhandelen van autorisatie en authenticatie. o Operational Management: het kunnen laten uitvoeren van operationeel beheer van de applicaties. o Communication: het afhandelen van de communicatie met gebruikers, inen externe systemen. Voor de dagelijkse praktijk is door het bedrijf Ordina een eigen implementatie van het.net framework ontwikkeld: de SMART-Microsoft Software Factory [HOO03]. Dit framework komt qua techniek grotendeels overeen met het.net framework, maar het biedt daarbij een volledige inbedding in de software engineering methodieken. Helaas is hiervan geen openbare gedetailleerde publicatie beschikbaar. Microsoft geeft in Application Architecture for.net: Designing Applications and Services [NET02] aan dat de scheiding van een applicatie in de hierboven genoemde componenten of applicatielagen als cruciaal gezien wordt. Voor de koppelingen tussen de applicatielagen gaat Microsoft uit van XML. In een XML document staan dan alle parameters benoemd en van een waarde voorzien. Een XML document kan dan door middel van een XML Schema Definitie (XSD) op geldigheid gecontroleerd worden. Voor elk applicatie laag worden een aantal ontwerprichtlijnen gegeven, die ook als zodanig opgevat kunnen worden als patterns en practices: Cliënt - De cliëntlaag wordt opgesplitst volgens het MVC-pattern: UI-components vormen de presentatielaag en UI process componenten vormen de controllerlaag. De businesslaag representeert het model - Er dient rekening gehouden te worden met de mogelijkheden en beperkingen van verschillende interactiemogelijkheden zoals: windows formulieren, webformulieren, mobiele devices en document gebaseerde interactie met Word of Excel. - Voor de UI processcomponenten dient rekening gehouden te worden met globalisatie en lokalisatie: de applicaties dienen in verschillende landen, talen en culturen gebruikt kunnen worden. Business - De businesslaag is de plaats waar zich de functionaliteit van de applicatie moet bevinden. - Geadviseerd wordt om zoveel mogelijk gebruik te maken van asynchrone communicatie bij webservices. Hiermee wordt een lage koppelingsgraad met externe systemen verkregen. - De gegevensrepresentatie dient zoveel mogelijk in XML of in ADO.NET datasets plaats te vinden. Data - Alle externe data moet afgeschermd worden van de applicatie via data access logic components. De belangrijkste taken hiervan zijn: o Abstractie van de onderliggende database of messages technologie en het zorgen voor eenduidige interfaces met de business laag. o Verzorgen van de create, read, update en delete (CRUD) akties. Henk vd Ridder,OU

15 - Microsoft adviseert om reden van performance om alle queries en data operaties zoveel mogelijk als stored procedures binnen de database aan te brengen. - De aggregatie van data over meerdere datasources (databases, message brokers, etc) dient door de business lagen verzorgd te worden. Systeemservices - Security is het centraal zorgdragen voor authenticatie, authorisatie en beveiligde gegevensoverdracht. De volgende practices worden aanbevolen: o Zorg altijd voor controle van externe invoer aan de poort. o Authentication, dat is het identificeren van de gebruiker, dient altijd plaats te vinden o Authorisatie, dat is het beperken van de toegang tot delen van de applicatie, dient via rollen en rechten verzorgd te worden. o Auditing en logging dient van alle akties plaats te vinden. - Operationeel management van de.net omgeving dient zorg te dragen dat beheer van de applicatie mogelijk is. Dit omvat exception management, monitoring en configuratie. - Communication omvat de realisatie van de communicatie tussen de verschillende applicatielagen. Afweging dient gemaakt te worden tussen de oude, maar snelle, DCOM mogelijkheden en de nieuwe, met meer overhead.net mogelijkheden van XML en webservices. Binnen de beschrijving van.net worden de volgende design patterns met name genoemd: - MVC: de inrichting van de user interface. - Pipeline: het sequentieel uitvoeren van acties - Event: het onafhankelijk kunnen starten van activiteiten. - Façade: het afschermen van de business componenten zodat alleen de functionaliteit van buitenaf zichtbaar is. De business componenten zelf dragen zorg voor de wijze van interactie met de services. - Factory: de wijze hoe data sources en services gekoppeld worden. Naast deze expliciet benoemde patterns kunnen ook de overige binnen.net voorgestelde oplossingen herleid worden naar de opsomming in het boek: Patterns of Enterprise Application Architecture van Fowler [FOW03]. Uitgaande van de beschrijving van.net wordt de reeds gemaakte conclusie dat die patterns een goede basis vormen voor het in het afstudeerprojcet te ontwikkelen framework, bevestigd. 3.2 J2EE: Java2 Enterprise Edition Basis voor de beschrijving van de J2EE omgevingen vormen de door Sun on-line beschikbaar gestelde boeken: Designing Enterprise Applications with the J2EE platform, second edition [SUN02] en Designing Web Services with the J2EE platform [SUN04]. J2EE staat voor Java Platform 2, Enterprise Edition. Vanaf 1999 wordt deze ontwikkelomgeving door Sun, ontwikkelaar van de programmeeromgeving Java, gepropageerd als de industriestandaard voor het ontwikkelen van client-server Java applicaties. De Java omgeving is machine onafhankelijk en draait zowel op Windows, Mac, Linux, Unix, Solaris en zelfs op IBM-mainframes. De kern van J2EE is de standaardisatie voor de J2EE-applicatieserver. In tegenstelling tot.net is J2EE geen gesloten product: J2EE applicatieservers worden door meerdere belangrijke leveranciers op de markt Henk vd Ridder,OU

16 gebracht: naast Sun ook door IBM-Websphere, Oracle, Bea-Weblogic en Apple- Webobjects. Ook verkrijgbaar in open source o.a.: Redhat-Jboss en Apache-Geronimo. Applicaties worden onafhankelijk ontwikkeld en kunnen in principe op elke J2EEgestandaardiseerde applicatieservers in productie genomen worden. De applicatieontwikkelaar hoeft zich alleen bezig te houden met het realiseren van de bedrijfsregels in de applicatie. De systeemzaken zoals: sessiebeheer, transactiebeheer, databasekoppelingen, koppelingen met andere systemen, communicatie tussen cliënt en server, etc. worden verzorgd door de applicatieserver. De basisstructuur voor de J2EE omgeving is in figuur 3 weergegeven [SUN02]: Figuur 3: J2EE basisstructuur De J2EE omgeving is bedoeld voor een n-tier (=laag) applicatie: - Cliënt: de laag waar de gebruikers van de applicatie zitten. Er zijn vele vormen mogelijk: volledige, cliënt-applicatie, thin en rich webcliënts, java-applets, etc. - Middle: de laag waar zich de business logica van de applicatie zich bevindt. Deze logica kan via zogenaamde containers binnen de J2EE omgeving aangesproken worden als: o Entiteit: rechtstreekse data uit de database o Stateless of statefull websessie o Asynchrone message server o Webservice (via de gestandaardiseerde SOAP, WDSL en UDDI protocollen [W3C06a]) - EIS: de laag waarin zich de te verwerken data (de entiteiten) bevindt. Dit kunnen zowel relationele databases, externe applicaties als webservices zijn. Het.NET onderdeel systeemservices vinden we bij J2EE deels terug in het containerconcept. Binnen de J2EE omgeving worden de ontwikkelde applicatiedelen ondergebracht in containers. De container draagt zorg voor de communicatie over de lagen heen en tussen de verschillende componenten in een laag. Het maakt daarbij niet uit of elke laag of component zich op een eigen machine bevindt of dat alle lagen samengevoegd zijn op één machine.voor de applicatieontwikkelaar is dit transparant: hij hoeft er tijdens de softwareontwikkeling geen rekening mee te houden. Dit geldt ook voor de aspecten: Henk vd Ridder,OU

17 security en operational management, die geheel door de J2EE applicatieserver verzorgd dienen te worden. Voor internetgebaseerde cliënts kan gebruik gemaakt van de browser cliënt. HTMLpaginas met embedded Java worden met Java Server Pages (JSP) geschreven. Door J2EE wordt voor webapplicaties het MVC pattern geadviseerd. J2EE biedt hiervoor ondersteuning, maar dwingt het niet af. Java is een objectgeoriënteerde programmeertaal. De representatie van de business data en logica in J2EE vindt met behulp van objecten plaats. Bij gebruik van relationele databases als opslag moet er een vertaalslag plaatsvinden tussen de objectenstructuur en het databaseschema. Object data moet vertaald worden naar entiteiten en entiteit velden. Object relaties moeten vertaald worden naar bijvoorbeeld foreign keys bij 1:n relaties en relatietabellen bij n:m relaties. Dit wordt Object Relational Mapping (ORM) [KEL97] genoemd. J2EE biedt hiervoor ondersteuning in de vorm van container-managed persistence en container-managed relationships, bean managed Persistence en Java Data Objects (JDO). Een in de praktijk toe te passen richtlijn voor het ontwikkelen van J2EE software wordt beschreven in het boek Systeemontwikkeling met J2EE van Ligtmans [LIG05] Deze pragmatische handleiding, zoals de ondertitel luidt, geeft richtlijnen om in de praktijk bruikbare J2EE applicaties te bouwen. Naast de door Sun aangegeven werkwijzen worden een aantal open source producten aanbevolen: - Invulling van de MVC-structuur met Struts [STR06]. Naast het invullen van de MVCstructuur biedt Struts ook ondersteuning voor invoer validatie en globalisatie. - Invulling van de OR mapping met Hibernate [HIB06]. Hibernate biedt een veel uitgebreidere OR mapping dan standaard J2EE. - Invulling van de koppeling tussen J2EE componenten en resources als databases en messaging systemen met Spring [SPR06]. Het Spring framework biedt hiervoor eenvoudig configureerbare koppelingen. In documenten waarop deze beschrijving is gebaseerd [SUN02], [SUN06] worden een groot aantal richtlijnen en aanwijzingen, zogenaamde practices, gegeven op welke manier applicaties het best gebouwd kunnen worden. De meest relevante practices, onderverdeeld worden naar de drie applicatielagen en de systeemservices, zijn: Cliënt - Houdt bij de presentatie van de user interface rekening met de beperkingen van de client, zoals weinig interactiviteit bij Web formulieren. - Het valideren van de gebruikersinvoer moet in elk geval in de applicatielaag plaatsvinden. Controle op de cliënt is niet voldoende. - Zorg voor een secure verbinding tussen cliënt en server. - Cliënts gaan er vanuit dat tussenresultaten over pagina s heen bewaard blijven. Elke GUI-soort heeft zijn eigen manier om dit te realiseren. Middle: - Zorg dat alle business logica in deze laag wordt geplaatst. In cliënt-laag (=presentatie) mag geen business logica voorkomen. - Laat de koppeling met de EIS-laag zo onafhankelijk mogelijk plaatsvinden. Binnen J2EE daarom zoveel mogelijk gebruik maken van de mogelijkheden voor container-managed persistence, -relationships en transactie beheer. Henk vd Ridder,OU

18 EIS: - zorg voor een zo onafhankelijk mogelijk, op zichzelf staande koppeling. Systeemservices: - Er dient veel aandacht besteedt te worden aan beveiliging: authenticatie, autorisatie en auditing dienen goed geregeld te worden. Benut de mogelijkheden van J2EE voor het declaratief, dat wil zeggen buiten de source om, vastleggen van security zaken. - Internationalization: wanneer applicaties in meerdere talen beschikbaar moet zijn, dan dient vanaf het begin daar bij applicatieontwikkeling rekening mee gehouden te worden. De binnen de J2EE omgeving toegepaste design patterns zijn door Sun uitvoerig beschreven [SUN01]. Deze design patterns voor de applicatielagen cliënt en middle worden in figuur 4 weergegeven. De design patterns Data Access Object en de Service Activator leggen de koppeling met een database, EIS-systeem of Webservice. Onder figuur 4 volgt een korte beschrijving van elk design pattern. Ter illustratie wordt bij de design patterns een verwijzing gelegd naar de design patterns volgens GoF en de design patterns volgens Fowler. Henk vd Ridder,OU

19 - Application Controller: Het toewijzen van de request aan business objecten of functies. GoF: Command, Fowler: Application Controller - Business Delegate: Het verminderen van de koppeling tussen de Client (Web) laag en de Business logica laag.. Dit Design Pattern kan gebruik maken van de Adapter of Proxy Pattern. GoF: Adapter - Composite Entity: Het combineren van één of meerdere database of EIS entiteiten tot één, voor de toepassing, logische business entiteit. GoF: Façade - Composite View: Het samenstellen van een webpagina cq. layout uit vaste (header, footer, etc) en variabele delen. GoF: Composite - Data Access Object (DAO): Het op een generieke wijze toegankelijk maken van de data sources, zoals database-tabellen. GoF: Factory Method, Abstract Factory, Fowler: Data Mapper, Table Gateway - Front Controller: Het zorgen voor één centrale toegang tot de applicatie, zodat de juiste verwerking kan plaatsvinden. GoF: Façade, Fowler: Front Controller - Intercepting Filter: Het voor- en/of nabewerken van de webrequests. Een voorbeelden is het doen van de authenticiteit controle. Er kunnen meerdere filterstappen plaatsvinden GoF: Decorator, Template. - Model-View-Controller: Het ontkoppelen van de data, applicatieverwerking en presentatie. Fowler: Model View Controller. - Service Locator: Het vereenvoudigen van de toegang van de client tot de business services door koppelen van logische namen aan fysieke resources. GoF: Builder, Fowler: Gateway - Session Facade: Het coördineren van de bewerkingen over meerder business objecten in een workflow. GoF: Façade. - Transfer Object: doel is het afhandelen van de overdracht van business data tussen de lagen. GoF: Façade - Value List Handler: doel is het kunnen presenteren van lijsten met data en verdelen over pagina s. GoF: Iterator. - View Helper: doel is het omvormen van de business data in presenteerbare vorm. Fowler: Transform View. - View Dispatcher: doel is om als deel van de controller een request toe te wijzen aan een business object of functie. Bij het vergelijken van deze J2EE lijst met design patterns volgens Gof valt het op dat in deze moderne softwareontwikkelomgeving de revolutionaire invloed van de GoF nog steeds speelt. 3.3 RoR: Ruby-On-Rails Het doel van dit hoofdstuk is uit te werken welke patterns en practices en bij open source oplossingen gebaseerd op het Ruby-On-Rails (RoR) framework van toepassing zijn. Deze beschrijving kijkt naar de echte Ruby On Rails zoals deze beschreven wordt in de documentatie op de RoR websites: [RUB06], [HIB05a], [HIB05b] en [MCC05]. Verder is gekeken naar de implementatie met de programmeertaal PHP van het RoR-framework in het open source project: Symfony [SYM06]). PHP is de programmeertaal die gebruikt zal gaan worden binnen het afstudeerproject. Binnen de open source gemeenschap zijn nog vele andere frameworks voor het ontwikkelen van webgeoriënteerde applicaties te vinden. Ter illustratie een google zoekopdracht met de woorden Open source en application framework levert meer Henk vd Ridder,OU

20 dan hits op. Deze borduren voort op het MVC principe, Struts-framework en OR mappings. Ruby-On-Rails heeft echter een eigen aanpak, die op dit moment (zomer 2006) in de belangstelling staat. Ruby is een objectgeoriënteerde programmeertaal die rond 1993 in Japan is ontstaan. Kenners zeggen dat de programmeertaal echt OO is en de beste elementen van Smalltalk, Python, Perl en PHP in zich heeft [HIB05a], [HIB05b]. Ruby is breder bekend geworden in de context van het RoR framework eind 2004, begin RoR is een open source applicatie framework voor webapplicaties die gebaseerd zijn op een database backend. RoR hanteert voor dit framework de volgende conventies [HIB05]: - Less software: hoe minder regels code er geschreven hoeven te worden hoe sneller een applicatie gebouwd kan worden en hoe minder fouten er in de code kunnen zitten. - Convention over configuration: het configureren van de applicaties is niet nodig als vanuit de conventie, dat wil zeggen direct uit programmacode, afgeleid kan worden hoe de applicatiedelen gekoppeld zijn. Bijvoorbeeld een database-tabel categories is by convention gekoppeld aan class-definitie category. Met name configuraties met XML zoals bij.net en J2EE gebruikelijk is wordt binnen het RoR framework als not-done gezien. XML wordt als onnodig ingewikkeld gezien. - Don t repeat yourself (DRY): RoR is een multi-tier framework, maar alle lagen werken zodanig met elkaar samen dat herhaling van bijvoorbeeld definitie van veldnamen niet nodig is. Het RoR-framework is volledig gebaseerd op model-view-controller (MVC) pattern, wat als volgt gebruikt wordt: - Model: representeert de gegevens (of informatie) binnen de applicatie via o het datamodel: de tabellen vastgelegd in de relationele database en tabelrelaties o de Object Relational Mapping (ORM) laag die de mapping verzorgt tussen tabellen en klassen, records en objecten, data manipulatie instructies en SQL queries. - Controller: deze verzorgt het opvangen van de gebruikers-requests via de frontcontroller en het aanroepen van de applicatieverwerkingen via actions. - View: deze verzorgt de presentatie aan de gebruiker met behulp van: o Templates: standaard layouts voor de presentatie van statische informatie. o Code fragments: ondersteunende software waarmee de modelgegevens gepresenteerd worden. Verder wordt gebruik gemaakt van een aantal patterns zoals deze beschreven zijn door Fowler [FOW03] voor het verzorgen van de object relational mapping (ORM), zoals: - Association Table Mapping: Het creëren van een extra tabel voor het vastleggen van de has_a relatie (ook wel n:m relatie) - Single, Class en Concrete Table Inheritance voor het implementeren van de is_a relatie (ook wel inheritance) Het RoR-framework is bedoeld voor 3-tier applicaties. Hierbij is de cliënt een gewone webbrowser. Op de server draait de applicatie die opgebouwd is uit twee delen: de applicatielogica gerealiseerd in de Ruby programmatuur en de gegevens in een relationele database. In principe is het mogelijk om een werkende applicatie te krijgen door de volgende drie stappen te doorlopen: - Het definiëren van de tabellen in de relationele database. Voor het vastleggen van tabel- en veldnamen dienen naamgevingconventies gevolgd te worden. Henk vd Ridder,OU