ADVANCED DESIGN PATTERNS

ADVANCED DESIGN PATTERNS CAPITA SELECTA Behorend bij het afstudeerproject: Generiek framework voor administratieve toepassingen in een webgeoriënteerde omgeving

Henk van de Ridder 834518719

December 2006, versie 3 Open Universiteit Nederland, faculteit Informatica Masteropleiding Technische informatica

CS Advanced Design Patterns

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 2

3

4 5

Inleiding..........................................................................................................................3 Design patterns .............................................................................................................4 2.1 Sofware engineering.......................................................................................4 2.2 Design patterns volgens GoF ......................................................................5 2.3 Design Patterns na GoF ...............................................................................7 2.4 Patterns en practices bij administratieve software ontwikkeling ...........8 2.5 Patterns of Enterprise Application Architecture................................... 10 Design Patterns binnen moderne ontwikkelomgevingen.................................. 12 3.1 .NET: Microsoft.......................................................................................... 12 3.2 J2EE: Java2 Enterprise Edition................................................................ 15 3.3 RoR: Ruby-On-Rails................................................................................... 19 3.4 Wetenschappelijk onderzoek .................................................................... 21 3.5 Vergelijking van de moderne ontwikkelomgevingen ........................... 22 Afronding.................................................................................................................... 26 Literatuur..................................................................................................................... 27

Henk vd Ridder,OU 834518719

2


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-, producten 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 834518719

3

CS Advanced Design Patterns 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 1994. 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


4

CS Advanced Design Patterns [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.


5


Naam

Scope Doel Variatiemogelijkheden Purpose: Creational: het aanmaken van nieuwe objecten

- Factory

Class

- Abstract Factory

Object

- Builder

Object

- Prototype

Object

- Singleton

Object

De creatie van een concrete klasse via een interface definiëren. Het bieden van een interface voor het aanmaken van verwante objecten De creatie van samengestelde objecten afzonderen Het aanmaken van objecten door middel van het kopiëren van een prototype. 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 - Bridge

Class/ Object Object

- Composite

Object

- Decorator

Object

- Façade

Object

- Flyweight

Object

- Proxy

Object

Omzetten ven een specifieke interface naar gewenste interface Ontkoppelen van abstractie en implementatie Uniformeren van het samenstellen van boomstructuren Dynamisch toevoegen van functionaliteit aan een object Aanbieden van een uniforme interface naar een subsysteem Uniformeren van het omgaan met grote hoeveelheden objecten 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

- Template Method - Chain of responsibility - Command

Class

Object

- Iterator

Object

Het definiëren van een template voor het algoritme Het dynamisch bepalen van de uit te voeren taken Het inpakken van een opdracht in een object Het doorlopen van lijsten

- Mediator

Object

Object

Het definiëren hoe een groep objecten elkaar informeert - Memento Object Het externaliseren van de state van een object - Observer Object Definiëren van een 1 op n relatie tussen objecten. - State Object De presentatie van de ‘inhoud van een object’ - Strategy Object Het bepalen van een concreet verwerkingsalgoritme - Visitor Object Het toevoegen van extra functionaliteit Tabel 1: Design patterns volgens GoF

De samenstelling en uitvoering van de doeltaal De stappen in een algoritme Het toewijzen van uit te voeren taken De keuzemogelijkheid van uit te voeren taak De soort lijst die doorlopen moet worden. Hoe de communicatie over en weer tussen objecten uitgevoerd wordt. Welke gegevens van een object bewaard blijven Hoe de afhankelijke objecten geïnformeerd worden Welke states een object kan hebben Het verwerkingsalgoritme Welke functionaliteit een klasse biedt

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.


6


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.


7


Naam

Beschrijving

Decoupling

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

Variant State handling Control Virtual machines Convenience

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-ViewController, 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: ServiceOriented 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 834518719

8

CS Advanced Design Patterns -

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


9

CS Advanced Design Patterns 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 ObjectRelational 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 834518719

10


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 ModelView-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.


11


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


12

CS Advanced Design Patterns 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


13


-

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.


14

CS Advanced Design Patterns 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


15

CS Advanced Design Patterns gebracht: naast Sun ook door IBM-Websphere, Oracle, Bea-Weblogic en AppleWebobjects. 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:


16

CS Advanced Design Patterns 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.


17

CS Advanced Design Patterns 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.


18


-

-

-

-

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


19

CS Advanced Design Patterns dan 500.000 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 2005. 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 834518719

20

CS Advanced Design Patterns Het eenmalig genereren van de applicatie waarbij de directory structuur wordt aangemaakt. Hierbij hoeft alleen de databasetoegang: serviceinstantie, login en password in een configuratiebestand vastgelegd te worden. - Het genereren van de tabelmodellen en applicatiecontrollers. Deze manier van werken wordt ‘scaffolding’ genoemd, waarbij automatisch de applicatieonderdelen voor het tonen en muteren van de gegevens uit databasetabellen afgeleid worden. Scaffolding is vergelijkbaar met het idee van prototyping. In tegenstelling tot prototyping is het product van scaffolding bruikbaar om door te bouwen naar een productiesysteem. -

Helaas is de Ruby omgeving bij de gewone webserver hosting abonnementen (vrijwel) niet verkrijgbaar. Daar is gestandaardiseerd op PHP (Linux) of ASP (Windows). Het RoRframework is echter zodanig krachtig dat het al door meerdere partijen is geïmplementeerd in de programmeertaal PHP [WAC06]. Al deze implementaties zijn nog behoorlijk prematuur, met een gunstige uitzondering voor het Symfony project waarvan ook een uitgebreid online handboek voorhanden is. [SYM06]. Symfony is een Objectgeoriënteerd PHP5 framework voor het bouwen van robuuste applicaties voor grotere bedrijven. Technisch gezien omvat Symfony de volgende onderdelen: - Database Abstraction Layer (Creole) die zorgt voor de koppeling met een relationele database naar keuze (o.a. MySQL, PostgresQL, Oracle, Microsoft SQL server, etc). Herkenbaar hier zijn de GoF: Design Patterns Façade en Factory - Object Relational Mapping Layer (Propel), die zorgt voor de ‘vertaalslag’ tussen de objectstructuur van de applicatie en de tabellenstructuur van de relationele database. Heel herkenbaar hierbij zijn de Object-Relational Structural Design Patterns van Fowler. - Model-View-Controller Layer (Mojavi), die zorgt voor de afhandeling van gebruikersinteracties volgens het MVC design pattern. Symfony, als afgeleide van het RoR framework, is ook heel sterk gericht op programmaconventies van waaruit de applicatie zonder noemenswaardige configuratie is af te leiden. Generatoren zorgen voor het aanmaken van een beginapplicatie met een vaste directorystructuur. Gegevensvelden op webformulieren worden rechtstreeks afgeleid uit de database tabelvelden. Tabelrelaties worden afgeleid uit de naamgevingen van primary en foreign keys. Naast de functionaliteit van het RoR framework biedt Symfony de volgende mogelijkheden: - Internationalisatie: Volgens de I18n standaard kunnen teksten in verschillende talen beschikbaar gesteld worden. Taalafhankelijke gegevens, bijvoorbeeld artikelomschrijving kunnen taalafhankelijk verwerkt worden. - Authenticatie en autorisatie via zogenaamde credentials

3.4

Wetenschappelijk onderzoek

Voor de vergelijking van de moderne software ontwikkelomgevingen zijn er een aantal wetenschappelijke publicaties interessant. Allereerst kan opgemerkt worden dat op het gebied van Java/J2EE de beschrijving van het open-source content management systeem MMBase [BEC05] opvalt. Dit content management systeem is zodanig open opgezet dat


21

CS Advanced Design Patterns inpassing van nieuwe soorten content eenvoudig te realiseren is. Programmeren is niet nodig: het beschrijven van de nieuwe content (in XML) geeft voldoende informatie. De software-engineerings factor change wordt hiermee expliciet ingevuld. MMBase kiest er ook voor om op punten waar de J2EE nog onvoldoende is uitontwikkeld een eigen aanpak te volgen. Niet wetenschappelijke vergelijkingen van J2EE en .NET zijn er op internet veel aanwezig, maar de afweging J2EE en .NET is meer een soort ‘geloofstrijd’ te noemen. Qua werkwijze en structuur lijken beide omgevingen heel veel op elkaar. Beide omgevingen zijn gebaseerd op een virtuele machine (CLR versus JVM) die de volledige portabiliteit van de applicaties beoogd. Beide omgevingen zijn volledig client/server en webgeoriënteerd. Het onderscheid wordt voornamelijk gezocht in de performance aspecten: een belangrijke referentie applicatie is de zogenaamde Petshop. Deze J2EE applicatie heeft als doel om de mogelijkheden van de J2EE omgeving te demonstreren. Toen Microsoft met zijn .NET omgeving is de markt kwam is deze referentie-applicatie ook binnen de .NET omgeving gebouwd. Binnen de internet-omgeving zijn hierover talrijke artikelen geproduceerd. Een toonaangevend artikel is J2EE and .NET (Reloaded) [MID03] Op het gebied van performance blijkt .NET duidelijk de meerdere van J2EE. Op het gebied van betrouwbaarheid en programmeersnelheid zijn de verschillen vrijwel nihil. In het kader van design patterns is door Rudzki onderzoek gedaan naar J2EE en .NET Er is een vergelijking gemaakt door een identieke functionaliteit met Façade respectievelijk Command design Pattern te implemeteren. Bij het Façade Pattern wordt de functionaliteit via methodes geïmplementeerd. Bij het Command Pattern wordt elke functie via een eigen Class geïmplementeerd. Het Façade Pattern bleek veel beter te functioneren dan het Command Pattern. Hoewel J2EE veel beter lijkt te performen blijkt uit de onderzoek dan een vergelijking tussen .NET en J2EE moeilijk te maken valt. De invloed als een applicatie op één computer draait of verdeeld is over meerdere computers is vele malen groter als de keuze tussen .NET of J2EE. Ditzelfde is in het onderzoek van Cecchet e.a. ook al aangetoond [CEC02]. Deze studie laat zien dat binnen J2EE dezelfde functionaliteit op verschillende manieren geïmplementeerd kan worden. Het gebruik van een eenvoudige structuur, die afwijkt van wat SUN als wenselijk aanbeveelt, blijkt veel betere te performen dan het realiseren van dezelfde applicatie die volledig volgens de ‘regels van de kunst’ als client/server is opgezet. [RUD06].

3.5

Vergelijking van de moderne ontwikkelomgevingen

Bij het vergelijken van de beschrijvingen van de moderne applicatie ontwikkelomgevingen in het kader van patterns en practices vallen de volgende zaken op: - Lagenstructuur - Model View Controller - Design patterns - OR Mapping - Toepassing van XML - Datagerichtheid Lagenstructuur De drie ontwikkelomgevingen gaan in principe uit van een applicatiearchitectuur in drie min of meer onafhankelijke lagen: presentatie (of client), applicatie (of business) en data (of EIS). Het concept van de drie-lagen architectuur is al in 1992 door Berson geintroduceerd


22

CS Advanced Design Patterns [BER92].

Deze drie-lagen architectuur biedt de mogelijkheid om alle lagen op verschillende computers de implementeren. Essentieel hierbij is dat elke laag zijn eigen specifieke taak krijgt om de programmatuur zodanig te bouwen dat de presentatie laag alleen maar de presentatie verzorgd, de applicatielaag de bedrijfsregels, dat is de logica, implementeert en de datalaag alleen verantwoordelijk is voor de data-integriteit. De noodzaak van de scheiding tussen presentatielaag en applicatielaag is wetenschappelijk aangetoond in de paper: “Enforcing Strict Model-View Separation in Templated Engines” [PAR04]. In verband met gebruikersvriendelijheid wordt deze strikte scheiding bij webapplicaties niet altijd gehandhaaft, wat tot gevolg heeft dat delen van de software gedupliceerd worden. Over de scheiding tussen applicatielaag en databaselaag wordt meer gediscussieerd. De aanbeveling bij .NET om voor de database koppeling gebruik te maken van stored procedures leidt vaak tot het onderbrengen van de logica in de datalaag. Verder geldt ook dat storied procedures in tegenstelling tot SQL niet gestandaardiseerd zijn en leidt het gebruik ertoe dat alleen de specifieke database aan de applicatie gekoppeld kan worden. Door Fowler [FOW03] wordt deze drie-lagen architectuur ook als uitgangspunt van elke applicatie genomen. Wel maakt hij de kanttekening dat voor eenvoudige applicaties, die alleen maar gebaseerd zijn op het rechtstreeks manipuleren van de gegevens in de gegevenstabellen, de middelste laag achterwege kan blijven. Verder geeft hij aan dat De drie-lagen architectuur wordt in de GoF beschrijving [GAM01] niet benoemd. Bij de beschrijving van Tichy [TIC98] staat de lagenstructuur genoemd onder decoupling. Dit is ook de essentie van de drie-lagen architectuur: het ontkoppelen van de drie wezenlijke onderdelen van de een applicatie. Model View Controller Het MVC pattern wordt door de genoemde ontwikkelomgevingen als essentieel gezien voor de realisatie van de presentatielaag. Het model levert de te presenteren gegevens aan, de view verzorgt de presentatie van de data aan de gebruiker en de controller verzorgt de afhandeling van acties die de gebruiker initieert. De onderdelen model en view zijn qua structuur bij alle ontwikkelomgevingen vrijwel identiek. De manier waarop de controller geïmplementeerd wordt verschilt. Er wordt onderscheid gemaakt tussen componentgerichte en applicatiegerichte architectuur [TAO02]. Bij een applicatiegerichte architectuur wordt gebruik gemaakt van een centrale controller die alle gebruikersacties opvangt en verder verdeelt. Vooral J2EE beveelt dit aan en noemt deze centrale controller de front controller. RoR gaat uit van een zogenaamde component gerichte controller: elk op zichzelf staande gebruikersinteractie heeft een eigen controller. .NET geeft geen specifieke voorkeur. Voordeel van de RoR aanpak is het verkrijgen van de onafhankelijkheid in verschillende applicatiecomponenten, nadeel is echter dat centrale acties als authorisatie en authenticatie via de component gerichte controller gerealiseerd moet worden. Door Fowler [FOW03] wordt onder de groep web presentation patterns dit ook aangeduid als code-duplicatie die voorkomen kan worden met de front controller. Zoals daar al is opgemerkt onderkent de GoF beschrijving [GAM01] het MVC pattern niet expliciet. Tichy [TIC98] rangschikt het MVC pattern onder compound, dat wil zeggen samengesteld uit andere basis patterns. Fowler [FOW03] geeft een uitgebreide beschrijving van de verschillende mogelijkheden om het MVC pattern bij webpresentatie te realiseren. Met name voor de view wijst hij op de alternatieven: 1) embedded scripttaalen als Java Sever Pages (JSP), active server pages (ASP) en PHP, 2) templates en 3) transformatie talen als XSLT. De afweging welke van deze groepen er gekozen wordt is een keuze van complexiteit versus aanpasbaarheid. Design Patterns


23

CS Advanced Design Patterns Naast de lagenstructuur en MVC wordt in de beschrijving van de moderne ontwikkelomgevingen vooral gerelateerd aan de GoF design patterns: façade en factory [GAM01]. De façade wordt vooral gebruikt om applicaties onder te verdelen in op zichzelf staande onderdelen: componenten of services genoemd. De façade is de ene gedefinieerde interface waarmee de toegang tot het component of service verkregen kan worden. Door Fowler [FOW03] wordt de façade vooral bruikbaar geacht voor de koppeling tussen de drie lagen. Ook is de façade de basis voor de koppelingen met webservices. Het factory pattern wordt vooral gebruikt voor het kunnen creëren van de objecten zonder dat de definitie als volledig bekend hoeft te zijn in de aanroepende onderdeel. Hoewel niet als zodanig benoemd maakt elke moderne ontwikkelomgeving gebruik van het iterator pattern voor het doorlopen van lijsten met objecten. Voor lijsten met objecten wordt in het algemeen de collection gehanteerd in de basisvormen zoals reeds gedefinieerd door Knuth [knu73]. Wat wel opvalt is dat er weinig aandacht is binnen de ontwikkelomgevingen voor de patterns die als doel hebben om functionaliteit flexibel te maken. De hiervoor beschreven patterns als decorator, command, strategy en visitor worden vrijwel niet benoemd. Fowler benoemt alleen strategy in zijn domain model pattern. Hierdoor is de plaats van het zo veelbelovende objectifier pattern van Zimmer [ZIM95] niet te bepalen. OR mapping OR mapping omvat de afbeelding van de applicatieobjecten structuur op relationele databases. Twee belangrijke verschillen zijn dat objecten uniek gerefereerd worden met behulp van het objectid, relationele tabellen hebben primary en foreign keys nodig. Het andere verschil is dat de objectenstructuur relaties via inheritance (is_a relatie) en collections (has-relatie) onderkent terwijl het genormaliseerde relationele model alleen 1:n relaties kent. Bij de moderne ontwikkelomgeving wordt geprobeerd om de OR-mapping buiten de applicatie om te configureren. Belangrijk onderzoek hierna is gedaan door Keller [KEL97]. De patterns en practices rond OR mapping spelen allen binnen administratieve applicaties die object geörienteerd ontwikkeld zijn en waarbij er een koppeling naar relationele databases plaatsvindt, zoals met de bovengenoemde ontwikkelomgevingen .NET, J2EE en RoR. Zowel GoF als Tichy besteden er geen aandacht aan. Fowler daarentegen besteedt er heel veel aandacht aan. Voor hem is het voor administratieve applicaties van groot belang om de afbeelding van applicatie-objecten op de relationele database tabellen zeer zorgvuldig uit te voeren. Bijna 50% van zijn beschrijving gaat hierover. Toepassing van XML Binnen de J2EE en .NET omgeving wordt het XML formaat gebruikt voor het vastleggen van de configuraties. Voordeel van het XML formaat is dat de data geautomatiseerd controleerbaar is met DTD of XSD schema’s. Een document in XML is ook voor de mens leesbaar. Binnen de .NET omgeving wordt XML ook gebruikt voor elke definitie van inen externe datastructuren. In de praktijk werkt dit alleen als de XML tijdens het ontwikkelproces automatisch gegenereerd wordt, maar het handmatig programmeren wordt als onnodig omslachtig gezien. Met name bij aanpassingen van de software is automatisch genereren vrijwel niet mogelijk. Het RoR framework maakt er om reden van onnodige complexiteit geen gebruik van. In het kader van de design patterns speelt het wel of niet gebruiken van XML geen rol. Datagerichtheid In eerste instantie zijn de moderne ontwikkelomgeving vooral datagericht. Dat wil zeggen dat ze zich vooral richten op functies voor het gecontroleerd beheren van gegevens. Dit is


24

CS Advanced Design Patterns ook de belangrijkste taak van administratieve applicaties. Hiernaast speelt ook organisatorische of proceskant. Immers het administratieve werk wordt verdeeld over verschillende personen en afdelingen, waarbij de werkzaamheden gecoördineerd moeten worden. Dit wordt samengevat onder het begrip: workflow. Wetenschappelijk onderzoek hierna is gedaan door van der Aalst [AAL00]. .NET verwijst naar de workflowoplossingen van tools als biztalk orchestration [NET02]. In de beschrijving van J2EE wordt de proceskant wel specifiek meegenomen, maar een concrete invulling blijft achterwege. Binnen RoR is vrijwel geen aandacht voor de proceskant van de software. Duidelijk is dat moderne ontwikkelomgeving de software vooral datagericht laten ontwikkelen en daarop de user interfaces afstemmen. Het inpassen van de user interfaces in het proces dient dan door op zichzelf staande workflow software verzorgd te worden. Ook dit dient in het te ontwikkelen framework meegenomen te worden.


25


4

Afronding

Allereerst kan geconcludeerd kan worden dat het begrip design pattern een belangrijke rol speelt binnen de softwareontwikkeling van administratieve toepassingen. Het begrip design patterns vinden we in de wetenschappelijke literatuur die al enkele jaren oud is. Design patterns worden daarin aanbevolen om de complexiteit van het software bouwen te verkleinen. Tevens bieden design patterns handvatten om de aanpasbaarheid van de software te bevorderen. Het oude begrip design-for-change, waarmee bedoeld wordt dat software ontwikkeld moet worden die gemakkelijk aan te passen is aan veranderende omstandigheden, heeft nog steeds waarde. Recente literatuur richt zich meer op software ontwikkeling onder de begrippen architectuur en model in plaats van pattern. Qua technische uitvoering is met name het begrip web services op dit moment heel erg in. In het kader van het te ontwikkelen framework dient nader onderzoek plaats te vinden naar service oriented architecture (SOA) [ERL05] en model driven development (MDD) [OMG06]. De basis van de design patterns is gelegd door de GoF. De in hun publicatie beschreven design patterns worden nog steeds aanbevolen binnen de moderne software ontwikkelomgevingen. De GoF beperken zich tot designs voor objectgeoriënteerde software. Voor het te ontwikkelen framework dient breder gekeken te worden. Allereerst spelen business patterns een rol immers voor administratieve verwerkingen zijn er nu eenmaal wettelijke en administratief organisatorische vereisten, zoals dat op een factuur BTW moet worden vermeld. Deze patterns dienen nader onderzocht te worden door bestaande administratieve en ERP oplossingen nader te bestuderen. Hierna komen de systeemgerichte patterns van hoe men nu eenmaal gewend is dat administratieve toepassingen werken. Voor administratieve toepassingen, aangeduid met de term: enterprise applications, zijn de specifieke design patterns gevonden en beschreven door Fowler. Deze design patterns zijn met in de moderne ontwikkelomgeving .NET, J2EE en RoR geïmplementeerd. Op zich is dit niet verwonderlijk immers design patterns zijn niet ‘invented’ maar ‘discovered’ [FOW03]: ze beschrijven een algemeen aanvaarde juiste oplossing voor een herkenbaar probleem. Bij het in het afstudeerproject te ontwikkelen framework kunnen de door Fowler beschreven design patterns als leidraad genomen worden. Vanuit het bestuderen van de moderne software ontwikkelomgevingen kan het volgende in het te ontwikkelen framework overgenomen worden: - De 3-lagen architectuur: presentatie, applicatie en data. - De user interface opbouwen met het MVC design pattern. - De koppeling tussen de objectgeoriënteerde software en de relationele databases uitvoeren met OR mapping. - De vereisten voor standaardfuncties voor authenticatie en authorisatie. - De onafhankelijke ondersteuning van werkprocessen via workflow. Binnen .NET en J2EE is er een complexe configuratieslag nodig om de software in gebruik te nemen. RoR gaat uit van het principe dat configuratie alleen nodig is voor uitzonderingen. Omdat de RoR-aanpak veel minder complex is dan J2EE en .NET en in verband met de bedrijfsgrootte waar afstudeerproject zich op richt zal deze RoR-aanpak ook binnen het te ontwikkelen framework meegenomen worden.


26


5

Literatuur

[AAL00] Advanced Workflow Patterns (CoopIS 2000), Aalst WMP vd, Hofstede AHM t, Kiepuszewski B, Springer-Verlag, 2000

Barros AP,

[BEC05] MMBase: An open-source content management system, Becking J, Course S, Enk G v, Hangyi H, Lahaye J J M, Ockeloen D, Peters R, Rosbergen H, Wendel de Joode R van, IBM SYSTEMS JOURNAL, VOL 44, NO 2, 2005 [BER92] Client/Server Architecture, Berson A., McGraw-Hill, ISBN 0070050767, 1992 [BOO99] The Unified Modelling Language User Guide, Booch G, Rumbaugh J, Jacobson I, Addisson Wesley ISBN 0201571684, 1999 [BRO00] Large-Scale component-based development, Brown A. W., Prentice Hall, ISBN: 013088720X, 2000 [BRU03] Object-Oriented Software Engineering: Using UML, Patterns, and Java, Bruegge B, Dutoir A H, Prentice Hall, ISBN: 0130471100, 2003 [BUS96] Pattern-Oriented Software Architecture, Buschmann F, Wiley ISBN: 0471958697, 1996 [BUS01] Patterns@Work, Buschmann F., http://www4.informatik.tumuenchen.de/~prehofer/oo-vorles/PatternsAtWork.pdf, 2001 [CEC02] Performance comparison of middleware architecture for generating dynamic web content, Cecchet E, Margeurite J, Zwaenenpoel W, Proceedings of the ACM/IFIP/USENIX International Middleware Conference, 2003 [DAB00] Using software architectures and design patterns for developing distributed applications, Dabous F T, Rabhi F A, Yu H, (ook gepubliceerd op Software Engineering Conference, 2004. Proceedings. 2004 Australian, ISBN: 0769520898 Proceedings. 2004 Australian), Citeseer.ist.psu.edu nr. 705822, 2000 [ERL05] Service oriented architecture, concepts, technology and design, Erl T, Prentice Hall, ISBN 0131858580, 2005 [FAY97] Object Oriented Application Frameworks, Fayad M, Schmidt D C, Communications of the ACM, Vol. 40, No 10 1997 [FOW03] Patterns of Enterprise Application Architecture, Fowler, Addison Wesley US, ISBN: 0321127420, 2003 [GAM95] Design patterns, elements of reusable object-oriented software, Gamma e.a. Addison Wesley, ISBN 0201633612, 1995 [GHE02]: Fundamentals of Software Engineering, 2e ed. Ghezzi C, Jazayeri M, Mandioli D, Prentice Hall, ISBN 0133056996, 2002 Henk vd Ridder,OU 834518719

27


[HIB05a] Rolling with Ruby on Rails, Hibbs C, artikel: http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html 2005 [HIB05b] Rolling with Ruby on Rails, Part 2, Hibs C, artikel: http://www.onlamp.com/pub/a/onlamp/2005/03/03/rails.html 2005 [HIB06] Relational Persistence for Java and .NET, auteurs onbekend, http://www.hibernate.org 2006 [HIL06] Pattern Language of Programming Design, auteurs onbekend, http://hillside.net/plop/2006/ , 2006 [HOO03] Smart Online Guide, http://86.90.89.221/Smart/INDEX.HTML, Hoogendoorn, S www.sanderhoogendoorn.com, 2003 [IBM04] Patterns: Service-Oriented Architecture and Web Services, Ang J, Arsanjani A, Chua S, Comte P, Endrei M, Krogdahl P, Luo H, NewlingT, zie:http://www.redbooks.ibm.com/redbooks/pdfs/sg246303.pdf , 2004 [JOH97] Frameworks = Components + patterns, Communications of the ACM, vol 40, no 10, 1997 [KEL97] Mapping Objects to Tables A Pattern Language, Keller W, Proceedings EuroPLoP 1997, zie ook: http://www.objectarchitects.de/ObjectArchitects/orpatterns, 1997 - 2004 [KNU73] Fundamental algorithms, The art of computer programming, vol 1, sec edition, Knuth D E, Addison Wesley, 1973 [LIG05] Systeemontwikkeling met J2EE een pragmatische benadering, Ligtmans R. Solidium, Academic Service, ISBN 9039523894, 2005 [MAR03] Agile Software Development, principles, Patterns and Practices, Martin, C.M. Prentice Hall, ISBN 0135974445, 2003 [MCC05] Four Days on Rails, McCreesh J, zie: http://www.rails4days.pwp. blueyonder.co.uk/Rails4Days.pdf , 2005 [MIC06a] Microsoft Pattern & practices developer center, diverse auteurs, http://msdn.microsoft.com/practices/, 2006 [MIC06b] Microsoft Developers Network (MSDN), diverse autuers, http://msdn.microsoft.com/library/, 2006 [MID03] J2EE and .NET (Reloaded) Yet Another Performance Case Study, The middleware company, http://www.middleware-company.com/casestudy/, 2003 [NET02] Application Architecture for .NET: Designing Applications and Servicec – patterns & practices, Microsoft Press, ISBN 0735618372, 2002


28

CS Advanced Design Patterns [OMG06] OMG Model Driven Architecture, Object management groep, zie: http://www.omg.org/mda/, 2006 [OUM02] Werkboek Design Patterns T26311, Stuurman e.a., Open Universiteit, ISBN 9035820231, 2002 [PAR72] On the criteria to be used in decomposing systems into modules, Parnas D.L. Communications of the ACM 15(2), Dec. 1972 [PAR78] Designing software for ease of extension and contraction, Parnas D.L. International Conference on Software Engineering, 1978 [PAR04] Enforcing Strict Model-View Separation in Template Engines, Parr T. ACM ISBN 158113844X/04/005, 2004 [RUD06] Performance implications in distributed applications: case studies in J2EE and .NET, Rudzki, J, Systa T. Proceedings of the ISSTA 2006 workshop ISBN 1595934596, 2006 [SHA02] Design patterns explained, Shalloway e.a., Addison-Wesley, ISBN 0201715945, 2002 [SPR06] The Spring framework, auteurs onbekend, website: http://www.springframework.org, 2006 [STR06] The Apache Struts Project, auteurs onbekend, website http://struts.apache.org, 2006 [SUN01] Core J2EE Patterns: Best Practices and Design Strategies, Alur D, Crupi J, Malks D, Prentice Hall, ISBN 0130648841, 2001 [SUN02]: Designing Enterprise Applications with the J2EE Platform, Singh I, Stearns B, Johnson C, Prentice Hall, ISBN 0201787903, 2002 [SUN04]: Designing Web Services with the J2EE 1.4 Platform, Singh I, Brydon S, Murray G, Ramachandran V, Violleau T, Stearns B, Addison-Wesley , ISBN 0321205219, 2004 [SUN06] The Java™ EE 5 Tutorial For Sun Java System Application Server Platform Edition 9, auteurs onbekend, website: http://java.sun.com/javaee/5/docs/tutorial/doc/index.html, 2006 [SYM06] Symfony book, http://www.symfony-project.com/get/trunk/symfonybook.pdf, versie aug. 2006 [TAO02] Component vs- application-level MVC architecture, Tao Y., ASEE/IEEE Frontiers in Education conference T2G-7, Boston, 2002 [THO05] Agile programming: Design to Accomodate Change, Thomas D, IEEE Vol 22, no3, mei/juni 2005


29

CS Advanced Design Patterns [TIC95] A Catalogue of General-Purpose Design Patterns. Tichy WF, in Proc. Technology of Object-Oriented Languages and Systems (TOOLS 23), IEEE Computer Society, 1998 [VLI00] Software Engineering, Principles and Practices, Vliet, H v John Wiley & Sons Ltd, ISBN 0471975087, 2000 [W3C06a] Web Services Addressing 1.0 - SOAP Binding, Gudgin M, Hadley M, Rogers T, website: http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509, 2006 [W3C06b] W3C Technical Reports and Publications, diverse auteurs, website: http://www.w3.org/TR/#Recommendations, 2006 [WAC06] PHP MVC Frameworks, WACT, http://www.phpwact.org/php/mvc_frameworks, 2006 [WAG01] DYA: snelheid en samenhang in business- en ICT-architectuur, Wagter R, Berg M vd, Luijpers J, Steenbergen M, Tutein Nolthenius, ISBN 9072194624, 2001 [ZIM95] Relationships between design patterns Zimmer W, in Patterns Languages of Program Design, Coplien JO, Schmidt DC, Pages 345 – 364 Addison-Wesley, 1995


30

ADVANCED DESIGN PATTERNS

Recommend Documents