Ontwerppatronen voor Ingebedde Systemen

Faculteit Wetenschappen Departement Computerwetenschappen Ontwerppatronen voor Ingebedde Systemen door Roos UWAERTS Promotor : Prof. dr. ir. E. STEEGMANS Proefschrift ingediend tot het behalen van de graad van Master in de informatica Academiejaar 2010 2011

c Copyright by K.U.Leuven Zonder voorafgaande schriftelijke toestemming van zowel de promotor(en) als de auteur(s) is overnemen, kopiëren, gebruiken of realiseren van deze uitgave of gedeelten ervan verboden. Voor aanvragen tot of informatie i.v.m. het overnemen en/of gebruik en/of realisatie van gedeelten uit deze publicatie, wendt u tot het Departement Computerwetenschappen, Celestijnenlaan 200A, 3001 Leuven, (016) 32 77 00 of via email: info@cs.kuleuven.be. Voorafgaande schriftelijke toestemming van de promotor(en) is eveneens vereist voor het aanwenden van de in dit afstudeerwerk beschreven (originele) methoden, producten en programma s voor industrieel of commercieel nut en voor de inzending van deze publicatie ter deelname aan wetenschappelijke prijzen of wedstrijden.

Faculteit Wetenschappen K.U. Leuven Departement Computerwetenschappen Academiejaar 2010 2011 Celestijnenlaan 200A 3001 Leuven (016) 32 77 00 Voornaam en naam student : Roos Uwaerts Titel : Engelse vertaling : Korte inhoud : Ontwerppatronen voor Ingebedde Systemen Design Patterns for Embedded Systems Embedded systemen zijn overal. Hun ontwikkelingsproces is echter lang en duur. Deze thesis maakt een studie over hoe ontwerppatronen kunnen bijdragen in de ontwikkeling van embedded systemen en hoe ze een vereenvoudiging van het ontwerpproces inhouden. Er wordt onderzocht hoever het onderzoek naar embedded ontwerppatronen staat, welke ontwerppatronen werden ontwikkeld en hoe deze patronen kunnen worden gerangschikt. Ook wordt bekeken op welke manier ontwerppatronen in de industrie worden gebruikt. Hieruit blijkt dat patronen niet gestructureerd worden toegepast. Het tweede deel van de thesis richt zich op het ontwikkelen van een embedded toepassing, met behulp van ontwerppatronen. Het gebruik van executable UML als ontwikkelingsproces voor embedded systemen wordt hier eerst gevalueerd. Met executable UML wordt een embedded systeem ontworpen. Eerst worden geen ontwerppatronen gebruikt. Erna wordt hetzelfde systeem ontworpen, met gebruik van ontwerppatronen. Het verschil tussen het ontwerp van deze systemen wordt geëvalueerd, waarbij het systeem waarbij ontwerppatronen werden gebruikt positief wordt beoordeeld. Proefschrift ingediend tot het behalen van de graad van Master in de informatica Promotor : Assessoren : Begeleiders : Prof. dr. ir. E. Steegmans Dr. ir. D. Preuveneers Dr. Ir. J. Boydens (KHBO) Dr. Ir. J. Boydens (KHBO) Ir. P. Cordemans (KHBO)

iv

Dankwoord Veel mensen hebben meegeholpen aan de totstandkoming van deze masterproef. In deze paragraaf wil ik hen bedanken voor hun steun, inzet en vertrouwen. Eerst en vooral zou ik graag mijn promotor, Prof. Dr. Ir. Eric Steegmans willen bedanken voor zijn uitstekende begeleiding tijdens het uitvoeren van deze masterproef. Zijn inzicht en kritische benadering hebben een duidelijke meerwaarde betekend. Ook wil ik mijn begeleiders Jeroen Boydens en Piet Cordemans bedanken, bij wie ik steeds terecht kon met mijn vele vragen. Ik bedank ook de mensen van E.D.&A., in het bijzonder Patrik Smout, voor het toelaten van de case study in hun bedrijf en alle hulp die ze mij daarbij geboden hebben. Daarnaast wil ik mijn familie bedanken. Zonder hun steun, zowel moreel als financieel, was de realisatie van deze masterproef niet mogelijk geweest. Ook voor het nalezen en verbeteren van de tekst kon ik steeds op hen rekenen. In het bijzonder bedank ik mijn vriend, Kristof, voor zijn onuitputtelijke geduld. Nog vele anderen uit mijn omgeving verdienen mijn dank voor de steun, interesse, hulp en suggesties die ze geboden hebben bij het maken van deze masterproef. v

Inhoudsopgave Dankwoord v Inleiding 1 I Onderzoek naar ontwerppatronen 4 1 Theoretische studie 5 1.1 Onderzoek naar embedded ontwerppatronen.................. 5 1.1.1 Industriële patronen............................ 6 1.1.2 Theoretische patronen........................... 6 1.2 Onderzoek naar Model-Driven Architecture(MDA) voor embedded systemen 9 1.3 Besluit........................................ 9 2 Industriële gevalstudie 10 2.1 Inleiding....................................... 10 2.2 Voorstelling van de gevalstudie.......................... 10 2.3 Het eerste project................................. 11 2.3.1 Analyse van ontwerppatronen....................... 11 2.3.2 Toegevoegde ontwerppatronen...................... 13 2.4 Het tweede project................................. 15 2.4.1 Analyse van ontwerppatronen....................... 15 2.4.2 Toegevoegde patronen.......................... 17 2.5 Besluit........................................ 19 II Toepassing van ontwerppatronen 21 3 Executable UML 22 3.1 Wat is executable UML............................... 22 3.2 Proces van executable UML............................ 24 3.2.1 Analyse................................... 24 3.2.2 Ontwerp................................... 27 3.2.3 Testen.................................... 29 3.2.4 Implementatie............................... 31 3.3 Tools voor executable UML............................ 31 3.4 Besluit........................................ 32 vi

INHOUDSOPGAVE vii 4 Gevalstudie: zonder ontwerppatronen 33 4.1 Opzet van de gevalstudie............................. 33 4.2 Uitwerking van de gevalstudie in executable UML................ 34 4.2.1 Analyse................................... 34 4.2.2 Testen.................................... 37 4.2.3 Ontwerp................................... 39 4.2.4 Implementatie............................... 41 4.3 Besluit........................................ 41 5 Gevalstudie: met ontwerppatronen 46 5.1 Inleiding....................................... 46 5.2 Toepassing van de patronen............................ 46 5.2.1 Analysefase................................. 46 5.2.2 Testfase................................... 46 5.2.3 Ontwerpfase................................ 46 5.2.4 Implementatie............................... 52 5.2.5 Evaluatie.................................. 52 5.3 Besluit........................................ 52 Besluit 63

Lijst van figuren 1.1 Structuur van het Virtual Machine patroon.................... 7 1.2 Toepassing van het Recursive Containment patroon.............. 8 2.1 Klassendiagram met verduidelijking van de lagen................ 14 2.2 Toepassing van het 5-layered patroon...................... 14 2.3 Klassendiagram met verduidelijking van het recursive containment patroon. 15 2.4 Klassendiagram en interactiediagram voor de veranderingen......... 18 2.5 Klassendiagram en interactiediagram na de veranderingen.......... 19 3.1 Domeingrafiek van de online boekenwinkel................... 25 3.2 Domeinmissieverklaring van het domein Web GUI............... 26 3.3 Use cases van de online boekenwinkel...................... 26 3.4 Activiteitsdiagram van de online boekenwinkel.................. 27 3.5 Klassendiagram voor het ordering domein van de online boekenwinkel.... 28 3.6 Toestandsdiagram voor de ShoppingCart klasse van de online boekenwinkel 29 3.7 Sequentiediagram van de acties in het ShoppingCart-toestandsdiagram... 30 3.8 Beschrijving van de testen van de use case Order Books van de online boekenwinkel...................................... 30 4.1 Domeingrafiek van het thermometer voorbeeld................. 34 4.2 Domeinmodel van het TemperatureSensor domein............... 36 4.3 Use cases van het thermometer voorbeeld................... 37 4.4 Activiteitsdiagram van het thermometer voorbeeld............... 39 4.5 Toestandsdiagram voor de eerste test van de use case start reading..... 41 4.6 Klassendiagram van het temperatuursensordomein............... 43 4.7 Toestandsdiagram van de loggerklasse..................... 44 4.8 Toestandsdiagram van de timerklasse...................... 45 5.1 Analysemodellen van het thermometervoorbeeld................ 54 5.2 Klassendiagram met het Interruptpatroon.................... 55 5.3 Toestandsdiagram van de loggerklasse na toepassing van het interruptpatroon 56 5.4 Toestandsdiagram van de timerklasse na toepassing van het interruptpatroon 57 5.5 Klassendiagram met het Pool Allocationpatroon................. 58 5.6 Toestandsdiagram van de loggerklasse met het Pool Allocation patroon... 59 5.7 Klassendiagram na toepassing van het Criticcal Section patroon....... 60 5.8 Toestandsdiagram van de loggerklasse met het Pool Allocation patroon... 61 5.9 Klassendiagram na toepassing van het recursive containment patroon.... 61 5.10 Klassendiagram na toepassing van het layered patroon............ 62 viii

Lijst van tabellen 3.1 Vergelijking tussen de actie-specifieke taal en Java............... 29 4.1 Beschrijving van de verschillende domeinen................... 35 4.2 Tekstuele beschrijving van de use cases..................... 38 4.3 Testen voor de use case Start Reading..................... 38 4.4 Testen voor de use case Process Daily Results................. 39 4.5 Testen voor de use case Request Statictic.................... 40 5.1 Testen voor de use cases Start Reading, Process Daily Results en Request Statistic....................................... 47 ix

Inleiding Deze thesis onderzoekt het gebruik van ontwerppatronen tijdens het ontwerp van embedded systemen. Ook het principe van model-driven ontwerp wordt onderzocht in het licht van embedded systemen. Embedded Systemen Ingebedde of embedded systemen zijn niet weg te denken uit de huidige samenleving. Denk aan keukenapparaten, auto s, televisietoestellen... Embedded systemen onderscheiden zich van gewone softwaresystemen, door hun beperkingen in bijvoorbeeld geheugen en rekenvermogen. Tevens blijven veel systemen oneindig lang doorlopen waardoor er extra aandacht moet besteed worden aan het vermijden van gefragmenteerd geheugen. Al dit soort beperkingen zorgen ervoor dat het ontwikkelingsproces meestal lang is en duur. Eén van de eerste systemen dat als embedded beschouwd kan worden, was de Apollo Guidance Computer in het Apollo-project [24] in het begin van de jaren zestig. Sindsdien zijn de prijzen voor componenten spectaculair gedaald en de capaciteit van het geheugen en rekenvermogen drastisch gestegen waardoor het aantal toepassingen van embedded systemen sterk toenam. Embedded systemen worden gebruikt in situaties waar voorheen het gebruik van een computer zelfs niet eens werd overwogen [24]. Ontwerppatronen Ontwerppatronen zijn vooral gekend in standaard softwareontwerp. Eric Gamma en de Gang of Four hebben met het boek Design Patterns [10] het gebruik van ontwerppatronen tot een standaard gemaakt in het ontwerp van grote softwaresystemen. Omdat embedded systemen op andere vlakken problemen ondervinden dan standaard softwaresystemen, helpen de standaard ontwerppatronen slechts in beperkte gevallen en kunnen embedded systemen niet profiteren van deze vooruitgang. Embedded systemen ondervinden bijvoorbeeld problemen op het vlak van taakbeheer. Hiervoor biedt Gamma geen patronen aan. Er zijn echter wel specifieke patronen ontwikkeld voor embedded systemen die dit probleem wel aanpakken. Andersom biedt Gamma het State patroon aan, waarmee een object anders kan reageren naarmate in welke toestand het zich bevindt. Enkel in grotere embedded systemen is het nuttig dit patroon te gebruiken (indien het nodig is). In kleinere systemen geeft dit patroon te veel overhead, omdat het geheugen hier te beperkt is. Model-driven architecure Model-Driven Architecture (MDA), in 2001 door de Object Management Group gedefinieerd, is een recente techniek om het ontwikkelingsproces van software te structureren. Het ontwerpproces bestaat uit het maken van drie verschillende modellen: het platformonafhankelijk model, het platform-specifiek model en een platform-definitie model. Deze 1

INLEIDING 2 modellen worden achtereenvolgens opgesteld. Het platform-onafhankelijke model bevat het ontwerp van het systeem, waarbij niet wordt ingegaan op platform-specifieke eigenschappen, zoals programmeertaal-specifieke datatypes of hardware gerelateerde operaties. Het platform-definitie model definieert de regels waarmee een platform-onafhankelijk model kan omgevormd worden tot een platform-specifiek model. Het platform-specifieke model tenslotte, is de vertaling van het platform-onafhankelijke model naar de gekozen programmeertaal en hardware. In de praktijk wordt het platform-definitie model meestal aangeboden door de tools die gebruikt worden voor model-driven design. Het platform-specifiek model kan dus, met behulp van een tool, automatisch worden gegenereerd. MDA biedt ook voor embedded systemen een manier van ontwerpen. Verschillende toonaangevende organisaties vermeldden MDA reeds als veelbelovend voor de embedded industrie. Doelstellingen en aanpak Het doel van deze thesis is, nagaan in welke mate specifieke ontwerppatronen voor embedded systemen bestaan en hoe ze bijdragen tot een vereenvoudiging van het embedded ontwikkelingsproces. Eerst wordt een algemeen onderzoek verricht naar ontwerppatronen die specifiek werden ontworpen voor embedded systemen. Er wordt onderzocht of en welke patronen reeds ontwikkeld werden en in welke context deze patronen dan gebruikt worden (architectuur van het systeem, implementatie,...). Dan wordt nagegaan of er een opdeling van de bestaande patronen kan gemaakt worden. Wanneer over ontwerppatronen wordt gesproken, wordt meestal ook een ontwerpmethode vermeld. In het geval van embedded systemen, is er een nieuwe tendens om model-driven ontwerp toe te passen. Er wordt ook onderzocht in hoeverre deze tendens zich heeft vertaald in onderzoek naar model-driven ontwerp van embedded systemen. Executable UML is een vorm van UML waarbij een manier is toegevoegd om acties van modellen te specificeren. Het is een manier om model-driven ontwerp toe te passen. Er wordt nagegaan in welke mate het executable UML-proces geschikt zou kunnen zijn voor het ontwerpen van embedded systemen. Wanneer het theoretische onderzoek naar patronen is afgerond, wordt een industrieel onderzoek verricht. Er wordt bekeken welke ontwerppatronen men in de praktijk toepast en of deze patronen volgens een bepaalde methode worden toegepast. Er wordt nagegaan of een bepaalde soort patronen vaker of minder vaak wordt toegepast dan een andere soort. Ook in verband met model-driven ontwerp wordt gekeken of deze of een andere ontwerpmethode wordt toegepast. De industriële gevalstudie werd in het bedrijf E.D.&A. gevoerd. Na het theoretische onderzoek en de studie van de industriële implementatie, wordt nagegaan op welke manier model-driven ontwerp en ontwerppatronen kunnen worden toegepast bij het ontwerp van embedded systemen. Hiervoor wordt een evaluatie gemaakt van het executable UML-proces in het kader van embedded systemen. Deze evaluatie wordt in de praktijk gezet door het toepassen van dit proces op een nog te ontwerpen embedded systeem. Het ontwerp wordt eerst zonder ontwerppatronen gemaakt waarna een evaluatie van het executable UML-proces wordt gemaakt. Tenslotte wordt hetzelfde systeem volgens hetzelfde proces ontworpen, maar met het gebruik van geschikte ontwerppatronen. Hier wordt aangetoond hoe het ontwerp van

INLEIDING 3 een embedded systeem kan vereenvoudigd worden door de toepassing van de ontwerppatronen. Overzicht van de tekst De thesis bestaat uit twee grote delen. Het eerste deel bevat het onderzoek naar de ontwikkeling en het gebruik van ontwerppatronen. In hoofdstuk 1 wordt nagegaan welk onderzoek er reeds is verricht naar het gebruik van ontwerppatronen in het ontwerp van embedded systemen. Hoofdstuk 2 bekijkt in welke mate ontwerppatronen reeds gebruikt worden in een industriële context. Het tweede deel van de tekst beschrijft hoe ontwerppatronen kunnen worden gebruikt in het ontwerp van een embedded systeem. In dit deel wordt een nieuw systeem ontworpen aan de hand van het executable UML-proces. Hoofdstuk 3 geeft een introductie tot het gebruik van executable UML om model-driven ontwerp toe te passen. Hoofdstuk 4 en 5 passen dit proces toe op de nieuwe toepassing, respectievelijk zonder en met toepassing van ontwerppatronen.

Deel I Onderzoek naar ontwerppatronen 4

Hoofdstuk 1 Theoretische studie van ontwerppatronen voor embedded systemen In dit hoofdstuk wordt een theoretische studie gemaakt van embedded ontwerppatronen. Eerst wordt onderzocht waarin ontwerppatronen voor embedded systemen verschillen van ontwerppatronen voor standaard softwaresystemen. Daarna worden de ontwerppatronen onderverdeeld in verschillende groepen volgens hun eigenschappen. Tenslotte wordt ingegaan op het gebruik van model-driven ontwerp bij embedded systemen. 1.1 Onderzoek naar embedded ontwerppatronen Embedded systemen verschillen van gewone computersystemen op verschillende vlakken. Embedded systemen zijn klein en slechts gericht op één algemene taak. Ze hebben vaak beperkt geheugen en rekenvermogen. Embedded real-time systemen hebben nog striktere vereisten. Zij moeten binnen een bepaalde tijdspanne een cruciale taak uitvoeren. Ook in hun ontwerpproces verschillen embedded systemen van gewone softwaresystemen. Wanneer een embedded systeem wordt ontwikkeld, moet hierbij ook rekening gehouden worden met eventueel reeds bestaande of nog te ontwerpen hardware. In beide gevallen gelden er strikte beperkingen voor de software. Het aanpassen van embedded hardware na softwareontwikkeling is doorgaans duur of onmogelijk, waardoor men moet proberen de software volledig te modelleren vooraleer over te gaan tot realisatie. Daarom is het ontwikkelingsproces van een embedded systeem relatief veel langer dan het ontwikkelingsproces van een gewoon softwaresysteem. Het systeem kan niet meer worden aangepast, dus mogen er geen fouten optreden, de software moet stabiel zijn en uitvoerig worden getest. Ondanks al deze vereisten wordt de ontwikkeling van embedded systemen vaak nog ongestructureerd aangepakt. De programmeur houdt weinig rekening met uitbreidbaarheid en leesbaarheid van de code, meestal is de enige vereiste dat de code efficiënt is. Enige structuur en methodiek aanbrengen in het ontwerpproces is nochtans niet moeilijk met behulp van ontwerppatronen, zij zorgen voor een overzichtelijke code en voor een gemakkelijke manier om veelvoorkomende problemen op te lossen. Wanneer over ontwerppatronen gesproken wordt, heeft men het meestal over de patronen voor grote softwaresystemen. Het werk van Erich Gamma en de Gang of Four, in het bijzonder hun boek over ontwerppatronen [10] heeft hierbij een grote rol gespeeld. Men vergeet doorgaans dat ontwerppatronen ook gebruikt kunnen worden in (eerder kleinere) embedded systemen. Ook hier kunnen ontwerppatronen een verschil maken, ze helpen 5

HOOFDSTUK 1. THEORETISCHE STUDIE 6 om de structuur van een programma duidelijker te maken. Ook veelvoorkomende problemen, zoals het plannen van taken (scheduling), beheer van het (beperkte) geheugen en de toegang tot resources, kunnen worden aangepakt met behulp van ontwerppatronen. Het gebruik van ontwerppatronen is een manier om stabiele code te verzekeren. Ontwerppatronen, zoals beschreven in [10], geven een beschrijving van een manier om een veelvoorkomend probleem op te lossen. Bij embedded systemen komen de meeste problemen voor daar waar ze zich onderscheiden van gewone computersystemen. Hierdoor zijn patronen voor gewone computersystemen slechts beperkt van toepassing en dit enkel op grotere embedded systemen. Ontwerppatronen voor embedded systemen spitsen zich dan ook toe op deze specifieke problemen. Mijn onderzoek naar ontwerppatronen voor embedded systemen toont dat deze kunnen worden opgesplitst in twee grote groepen: de industriële ontwerppatronen, ontwikkeld voor een bepaalde hardware, en de puur theoretische ontwerppatronen, die door de programmeur worden aangepast aan de vereisten van de hardware. 1.1.1 Industriële patronen De industriële ontwerppatronen werden door hardware verkopers ontwikkeld om de specifieke problemen van embedded systemen op de door hen verkochte hardware op te lossen. Zo biedt Intel verschillende patronen aan om te helpen bij het ontwerp op zijn processoren. Op zijn website [19] toont Intel hoe deze patronen kunnen worden toegepast op elke hardware. Later werd academisch onderzoek verricht naar ontwerppatronen op specifiek hardware. Zo beschrijft Michael Pont in zijn boek Patterns for Embedded and Time-Triggered Systems [21] en later in een artikel [17] enkele ontwerppatronen die specifiek ontworpen zijn voor de 8051 microcontrollers. Deze patronen zijn meestal gebaseerd op de theoretische patronen, die verder worden besproken, maar uitgewerkt op die specifieke hardware. De programmeur moet enkel de code toepassen in zijn systeem om het patroon te gebruiken. Tenslotte bieden ook verkopers van ontwikkelingstools ontwerppatronen aan voor de hardware die zij ondersteunen. Deze patronen zijn beschreven binnen de context van hun ontwikkelingstool. Zo biedt het bedrijf EventHelix enkele ontwerppatronen aan voor hun ontwikkelingstool EventStudio [9]. 1.1.2 Theoretische patronen Theoretische patronen zijn patronen die onafhankelijk van de hardwareconfiguratie kunnen gebruikt worden. Zij geven een algemene oplossing van het probleem, de eigenlijke implementatie op de hardware wordt aan de programmeur overgelaten. Zo zijn deze patronen op grote schaal bruikbaar. Het boek Real-Time design patterns van Bruce Powel Douglass [4] geeft een volledig overzicht van deze patronen. Patronen die door andere auteurs werden ontwikkeld, zijn steeds terug te brengen tot een patroon uit het boek van Douglass. Zo stellen Corsaro en Schmidt in hun paper Virtual Component a Design Pattern for Memory Constrained Embedded Applications [1] het Virtual Component patroon voor, een patroon waarmee het systeem wordt opgebouwd uit verschillende componenten, sommige reeds bestaand, andere nieuw. Dit patroon komt overeen met het Component-based patroon uit het boek van Douglass. Soundararajan en Brennan ontwikkelden dan weer een patroon in hun paper A Proxy Design Pattern to Support Real-Time Distributed Control System Benchmarking [22] dat beschrijft hoe client-server communicatie kan worden geregeld. Het boek van Douglass beschrijft hetzelfde patroon onder de dezelfde naam: het proxy patroon. Wanneer de patronen van naderbij worden onderzocht, blijkt dat de theoretische patronen in twee groepen

HOOFDSTUK 1. THEORETISCHE STUDIE 7 kunnen worden opgedeeld: de architecturale patronen en de gedragspatronen. De patronen die verder in deze tekst als voorbeeld worden aangehaald, komen allemaal uit het boek van Douglass. Ook de figuren zijn over genomen uit dat boek. Architecturale patronen Architecturale patronen richten zich op de structuur van het programma. Zij zorgen voor de uitbreidbaarheid en het overzicht, maar ook voor de draagbaarheid naar andere platformen. Voorbeelden van deze architecturale patronen zijn het virtual machine patroon en het recursive containment patroon. Het virtual machine patroon zorgt ervoor dat een systeem gemakkelijk kan geı mplementeerd worden op hardware. Figuur 1.1 toont de structuur van dit patroon. De applicatie wordt zo gemaakt dat ze enkel instructies van de virtuele machine gebruikt. De virtuele machine vertaalt op haar beurt die instructies naar de concrete instructies van de hardware. Wanneer er van hardware wordt gewisseld, moet enkel de virtuele machine aangepast worden. Wanneer er verschillende applicaties op dezelfde hardware gebruik maken van deze virtuele machine, kunnen ze alle op andere hardware gedraaid worden, enkel door die ene virtuele machine aan te passen. Figuur 1.1: Structuur van het Virtual Machine patroon Het recursive containment patroon is een voorbeeld van een architecturaal patroon waarbij de software wordt opgedeeld volgens functionaliteit. Op deze manier wordt het onderscheid tussen de verschillende functies van het programma behouden en kunnen later eventueel functies worden toegevoegd of verwijderd zonder de volledige code te moeten

HOOFDSTUK 1. THEORETISCHE STUDIE aanpassen. Het patroon is recursief, dit wil zeggen dat elke functionaliteit is opgedeeld in deelfunctionaliteiten die op hun beurt ook kunnen opgedeeld worden. Zo wordt elke basisfunctionaliteit apart behandeld waardoor een eventuele wijziging geen grote veranderingen teweegbrengt. Een toepassingsvoorbeeld van het recursive containment patroon is te vinden in figuur 1.2. Figuur 1.2: Toepassing van het Recursive Containment patroon De voorbeelden tonen aan dat de architecturale patronen een essentie le verbetering betekenen wanneer het programma achteraf wordt uitgebreid of gewijzigd. Ze betekenen ook een grote meerwaarde wanneer er met verschillende mensen aan een programma wordt gewerkt: het ontwerp en ook de code zijn overzichtelijker. Door eerst een model te maken van het systeem wordt een structuur vastgelegd die belangrijk is voor het verdere ontwikkelingsproces. Gedragspatronen Waar architeturale patronen een oplossing bieden voor de softwarestructuur, richten gedragspatronen zich op de specifieke implementatie van veelvoorkomende problemen, zoals bijvoorbeeld taakbeheer, geheugenbeheer en resourcebeheer binnen de vereisten en beperkingen van het systeem. Zo kan voor het taakbeheer van een systeem beroep gedaan worden op verschillende patronen, onder andere het cyclic executive patroon, het interrupt patroon en het static priority patroon. Afhankelijk van de vereisten van het programma kan dan een geschikte oplossing worden gekozen. Zo is een vereiste bij het cyclic executive patroon dat er geen taken zijn die prioriteit hebben over andere en dat alle taken telkens in dezelfde volgorde worden uitgevoerd. Wanneer taken wel prioriteiten hebben, kan het static priority patroon worden gebruikt, dat bij het plannen van de taken rekening houdt met hun prioriteit. Wanneer taken met een hogere prioriteit taken met een lagere prioriteit moeten kunnen onderbreken, wordt het interrupt patroon gebruikt. 8

HOOFDSTUK 1. THEORETISCHE STUDIE 9 Daar waar de architecturale patronen zijn ontwikkeld uit best practices, zijn de gedragspatronen meer een theoretische weergave ervan, zonder er veel aan te veranderen. De gedragspatronen geven letterlijk weer wat waar geïmplementeerd moet worden terwijl de architecturale patronen eerder een omschrijving geven van de verschillende mogelijkheden. De invulling ervan hangt voor een stuk van de interpretatie van de ontwerper af. 1.2 Onderzoek naar Model-Driven Architecture(MDA) voor embedded systemen Wanneer over ontwerppatronen wordt gesproken, heeft men het meestal ook over een ontwerpproces. Daar waar in het algemene softwareontwerp veel methodologieën de revue zijn gepasseerd, blijft het ontwerpen van embedded systemen eerder een zaak van de programmeur. Deze schrijft zo snel mogelijk werkende code, ongeacht of deze code gestructureerd of uitbreidbaar is. Het besef groeit echter dat er ook voor embedded softwareontwerp een gestructureerde ontwerpmethode moet gezocht worden. Verschillende gespecialiseerde organisaties zoals EETimes [7], embedded.com [8] en het Belgische DSP Valley [5] hebben al artikels gepubliceerd en conferenties georganiseerd omtrent model-driven ontwerp. Onderzoek wijst uit dat model-driven ontwerp een goede keuze is voor embedded systemen. Zo ontwikkelden Ito en Matsuura in hun paper Model driven development for embedded systems [12] een embedded systeem door het model-driven principe toe te passen. Wanneer men embedded systemen wil ontwerpen volgens het model-driven principe is dat het moeilijk is een platform-onafhankelijk model te maken dat ook nog rekening houdt met de hardware. Het Deense technologisch instituut ontwikkelde hiervoor een eigen ontwerptool, Rhapsody [2], die dit probleem zou moeten oplossen. Daarenboven laat de tool ook het gebruik van ontwerppatronen toe. Hoofdstuk 3 gaat verder in op het toepassen van de model-driven principes op embedded systemen. 1.3 Besluit Wanneer het gebruik van ontwerppatronen bij embedded systemen wordt bekeken, blijkt dat er reeds veel onderzoek naar werd gedaan. Er kan een onderscheid gemaakt worden tussen patronen die specifiek voor een bepaalde hardware werden ontwikkeld, de industriële patronen, en de theoretische patronen die een algemene methode voorstellen. Op de industriële patronen ga ik niet verder in. De theoretische patronen zijn op hun beurt op te delen in architecturale patronen, die de structuur van een systeem vastleggen, en de gedragspatronen, die de werking van het systeem modelleren. Aangezien dit onderzoek vooral in de academische wereld werd gevoerd, onderzoekt het volgende hoofdstuk in welke mate dit onderzoek door de industrie werd opgepikt.

Hoofdstuk 2 Patronen voor embedded systemen in een industriële omgeving 2.1 Inleiding In de academische wereld is reeds veel onderzoek naar ontwerppatronen voor embedded systemen gebeurd. In dit hoofdstuk gaan we na in welke mate dit onderzoek effect heeft gehad in de industrie. Er wordt onderzocht in welke mate ontwerppatronen worden gebruikt door programmeurs en op welk vlak ze deze gebruiken. Deze gevalstudie wordt gemaakt in samenwerking met het bedrijf E.D.&A. [6]. Dit bedrijf is gespecialiseerd in ontwerp en fabricatie van op maat gemaakte applicaties. E.D.&A. zegt geen ontwerppatronen te gebruiken. Zij maken geen ontwerp, maar programmeren rechtstreeks de gewenste functionaliteit in C. Ze zochten een betere oplossing naar uitbreidbaarheid en hergebruik van code toe en keken hiervoor richting ontwerppatronen. Bij gevolg is dit een ideale gevalstudie om te zien in hoeverre de ontwerppatronen aanleunen bij de praktijken in de professionele wereld en of toepassing ervan inderdaad leidt tot een robuustere, aanpasbare architectuur. 2.2 Voorstelling van de gevalstudie In deze gevalstudie wordt de code van twee kleinere applicaties geanalyseerd. Tijdens deze analyse wordt gekeken welke patronen reeds gebruikt worden en hoe deze toegepast worden. Er wordt ook gekeken waar nieuwe ontwerppatronen kunnen worden toegepast. Na de analyse worden, waar mogelijk, die ontwerppatronen toegepast in de code. Na de toepassing wordt geëvalueerd of deze verandering ook voordelig is. Het eerste project is een eenvoudig programma, dat slechts enkele functionaliteiten aanbiedt. Het tweede project is een groter programma. Het is geen werkend programma, maar een toepassing waarop een klant een eigen applicatie kan bouwen. Er worden verschillende functionaliteiten aangeboden. Omdat de informatie over de toepassingen vertrouwelijk is, worden geen details over de werking van het project gegeven. Wanneer toepassingen van ontwerppatronen worden geïllustreerd, wordt dit slechts voor een deel van het project gedaan. 10

HOOFDSTUK 2. INDUSTRIËLE GEVALSTUDIE 11 2.3 Het eerste project Het project is een relatief eenvoudig programma, bestaande uit een lus die een aantal threads na elkaar uitvoert. Per functionaliteit is er een managerklasse aanwezig die de instructies verdeelt en doorgeeft aan de klassen die in verbinding staan met de hardware. Er wordt eveneens een eenvoudige gebruikersinterface aangeboden. Het is een programma dat, eens opgestart, jaren moet runnen, zonder dat er geheugen gereset wordt. 2.3.1 Analyse van ontwerppatronen Uit de eerste analyse bleek dat de ontwerppatronen die in aanmerking kwamen voor het project reeds allemaal werden toegepast. Hieronder volgt een lijst van de gebruikte patronen en hoe ze werden toegepast. De beschrijving van elk patroon kan worden teruggevonden in het boek Real-time design patterns van Bruce Powel Douglass [4]. Layered patroon Beschrijving van het patroon Het programma wordt onderverdeeld in verschillende niveaus van abstractie. Zo wordt de eigenlijke implementatie van de functionaliteiten van het programma gescheiden van de delegatie van de opdrachten en verloopt de werking van het programma transparanter. In samenwerking met het recursive containment patroon (zie verder) levert dit zeer gestructureerde code die gemakkelijk uitbreidbaar is. Toepassing van het patroon Er zijn drie niveaus van abstractie in dit programma: op het hoogste niveau liggen de mainklasse en de algemene managerklasse die de ordening van de taken en de coördinatie verzorgen. Op het middelste niveau bevinden zich de managerklassen die de oproepen naar de juiste klasse in de onderste laag doorsturen. Op het laatste niveau liggen de klassen die de technische implementatie verzorgen. Conclusie De klassen zijn geïmplementeerd zoals het hoort op hun niveau van abstractie. Ook wordt op basis van de namen van de klassen een onderscheid gemaakt tussen de verschillende lagen. De klassen van de middelste laag hebben immers het suffix - Manager gekregen. Zie ook sectie 2.3.2 waarin de toegevoegde patronen worden beschreven. 5-Layered patroon Beschrijving van het patroon Wanneer een programma op basis van abstractie wordt opgedeeld, zoals in het vorige patroon, zal de onderste laag (minst abstract) groot zijn, omdat een embedded systeem vooral is afgestemd op de hardware. Met dit patroon wordt er een onderscheid gemaakt binnen deze laag, die het gemakkelijker maakt componenten te herkennen, met het oog op eventuele latere uitbreiding. De klassen worden opgedeeld in volgende categorieën: Application: De klassen die typisch zijn voor deze applicatie en dus, in tegenstelling tot klassen in de andere categorieën, niet in andere programma s zullen voorkomen. User interface: Bevat alle elementen die nodig zijn voor de user interface. Communication: Alle klassen die communicatie met andere systemen regelen.

HOOFDSTUK 2. INDUSTRIËLE GEVALSTUDIE 12 Abstract OS: Zorgt voor een laag tussen het programma en het onderliggende OS, zodat enkel deze instructies moeten worden aangepast bij verandering van OS. Abstract Hardware: In deze laag bevinden zich de klassen die de randapparaten voorstellen, zoals sensors, interfaces en drivers. Toepassing van het patroon De functionaliteit van de 5 verschillende lagen wordt door verschillende klassen geïmplementeerd. Er is geen klasse die functies van twee lagen combineert. Conclusie Weerom wordt de functionaliteit verdeeld en wordt dit patroon in principe toegepast, maar dit is niet duidelijk wanneer je de code bekijkt. Een onderverdeling zou hier het verschil kunnen maken. Zie ook sectie 2.3.2 waarin de toegevoegde patronen worden beschreven. Recursive containment patroon Scheidt de verschillende functionaliteiten van het pro- Beschrijving van het patroon gramma op verschillende niveaus. Toepassing van het patroon Op het hoogste niveau wordt het programma als geheel aangeboden. Op een lager niveau zijn er per functionaliteit manager-klassen (bv. TODO). Elk van deze manager-klassen is een interface waarlangs die bepaalde functionaliteit wordt opgeroepen. De oproep wordt dan doorgegeven door de manager naar de klasse die die bepaalde functionaliteit zal uitvoeren. Op het laagste niveau bevinden zich de afzonderlijke klassen. Deze bieden elk een eigen deel van de functionaliteit van hun manager-klasse aan. Interactie die de functionaliteit van de manager overschrijdt loopt via de manager. Andere interacties tussen klassen verlopen zonder tussenkomst van de manager. Conclusie Dit patroon is zeer nuttig wanneer men verschillende functionaliteiten wil aanbieden. Wanneer later de code wordt uitgebreid met een nieuwe functionaliteit, volstaat het om (in dit geval) een nieuwe manager-klasse te maken die met de andere managerklassen communiceert. De implementaties op lager niveau moeten niet worden aangepast. Ook hier is een indeling van de klassen gewenst (zie ook conclusie van het gelaagd patroon). Zij het op basis van de naam, of door indeling in folders. Dit komt de leesbaarheid van het programma ten goede en zal bij eventuele uitbreiding van pas komen. Zie ook sectie 2.3.2 waarin de toegevoegde patronen worden beschreven. Static allocation patroon Beschrijving van het patroon Omdat allocatie van dynamisch geheugen voorzichtig moet worden aangepakt (met gevaar voor geheugenfragmentatie en het niet vrijgeven van geheugen), wordt dit vermeden waar mogelijk. Alle variabelen die nodig zijn om het programma te runnen, worden bij de start aangemaakt en niet meer verwijderd. Dit wordt typisch gebruikt in systemen waarbij de geheugencapaciteit in het slechtste geval niet veel verschilt van de gemiddelde geheugencapaciteit en waar het dus geen overhead geeft om geheugen te alloceren voor geheugengebruik in het slechtste geval.

HOOFDSTUK 2. INDUSTRIËLE GEVALSTUDIE 13 Toepassing van het patroon Alle variabelen die nodig zijn, worden bij initialisatie van alle managerklassen gealloceerd. Zo worden in de mainmethode, voordat de lus begint (zie volgend patroon), de initmethode van alle managerklassen opgeroepen. Deze methoden zorgen voor de initialisatie van alle nodige variabelen. Ook worden de variabelen niet verwijderd. Conclusie In dit programma is het een goede keuze om dit patroon te gebruiken. Dynamische geheugenallocatie is hier niet nodig. Aangezien het programma moet blijven runnen gedurende verschillende jaren, is het ook niet wenselijk dat er zich geheugenfragmentatie voordoet. Cyclic executive patroon Beschrijving van het patroon Dit is een eenvoudig taakbeheerpatroon, dat een set onafhankelijke taken na elkaar uitvoert en dan van voorafaan begint. Toepassing van het patroon De mainklasse bestaat uit een oneindige lus die achtereenvolgens de managers hun taken laat uitvoeren. Bij elke taak wordt gekeken naar de parameters die gezet zijn. Indien deze aanduiden dat een bepaalde actie moet worden gedaan, wordt deze uitgevoerd, anders wordt deze actie overgeslagen. Taken worden dus niet onderbroken. De enige reden waardoor de acties zouden moeten onderbroken worden, is wanneer er een fout zou optreden. Echter, de lus is zo kort dat de fout wellicht meteen wordt afgehandeld als deze zich voordoet. Conclusie Deze manier van taakbeheer is ideaal voor een programma als dit. Met weinig geheugen ter beschikking, is een real-time besturingssysteem (RTOS) niet mogelijk. De functionaliteit van het programma is ook zo klein dat een RTOS overbodig is. In het boek van Douglass staan enkele vereisten waaraan een programma moet voldoen, zodat het cyclic executive patroon de efficiëntste oplossing is. Dit programma voldoet aan al deze vereisten: het aantal taken dat wordt uitgevoerd is constant gedurende de hele run-time, de tijd dat een taak nodig heeft om uitgevoerd te worden is constant, de taken zijn onafhankelijk van elkaar, de taken hebben het gebruik van eventuele resources afgerond wanneer ze de controle terug geven aan de mainklasse en de volgorde waarin de taken worden uitgevoerd voldoet in alle situaties. 2.3.2 Toegevoegde ontwerppatronen In de vorige sectie werdt het project geanalyseerd en werden de verschillende ontwerppatronen geïdentificeerd. In dit deel, bekijken we welke patronen nog kunnen toegevoegd worden om de applicatie beter te maken. Ook de patronen die slechts gedeeltelijk werden toegepast, worden hier verder geïmplementeerd. Layered patroon Toepassing van het patroon Om dit patroon toe te passen, moeten er geen codeveranderingen gebeuren. Wel heb ik een klassendiagram gemaakt dat de verschillende interacties tussen de klassen duidelijk maakt. Door het klassendiagram te structureren, worden de niveaus van abstractie meteen duidelijk (zie figuur 2.1).

HOOFDSTUK 2. INDUSTRIËLE GEVALSTUDIE 14 Figuur 2.1: Klassendiagram met verduidelijking van de lagen 5-Layered patroon Toepassing van het patroon De toepassing van dit patroon gebeurde ook reeds in de code (zie sectie 2.3.1) maar is niet meteen duidelijk te zien in de code. In onderstaand diagram wordt aangetoond hoe de verschillende klassen in het 5-gelaagd patroon passen. In dit geval wordt er geen real-time besturingssysteem gebruikt. De klassen in de abstract- OS laag zijn hier klassen die ondersteuning bieden die normaal door het besturingssysteem zou worden gegeven. Figuur 2.2 toont de toepassing van dit patroon. Er worden enkel de klassen weergegeven die het voorbeeld illustreren. Het overzicht van de klassen is niet volledig. Figuur 2.2: Toepassing van het 5-layered patroon Wanneer het recursive contaiment patroon ook wordt toegepast (zie volgende sectie), zal een deel van deze klassen reeds per functionaliteit worden ingedeeld (onder andere de abstract hardware-laag). Deze hoeven dus niet onmiddellijk volgens deze indeling worden weergegeven. Wel is het praktisch om de user interfacelaag en OS-laag apart weer te geven. Recursive containment patroon Toepassing van het patroon Wanneer we het recursive containment patroon volledig willen toepassen, delen we de klassen in volgens functionaliteit. Omdat eveneens het gelaagd patroon wordt gebruikt, heeft elke functionaliteit een managerklasse die delegeert naar de onderliggende klassen. Dit wordt weergegeven in figuur 2.3, gebaseerd op het klassendiagram. Conform het recursive containment patroon, kan een functionaliteit (licht grijze vakken) verder onderverdeeld worden in subfunctionaliteiten (donker grijze vakken). Dit gebeurt hier

HOOFDSTUK 2. INDUSTRIËLE GEVALSTUDIE 15 Figuur 2.3: Klassendiagram met verduidelijking van het recursive containment patroon ook, de klassen implementeren elk een deel van de functionaliteit die op zichzelf staat. Omdat deze subfunctionaliteit per klasse wordt geïmplementeerd, is het onderscheid op dat niveau duidelijk. Ik heb enkel de klassen onderverdeeld op basis van de hoofdfunctionaliteit waartoe ze behoren. Conclusie Wanneer ik de klassen onderverdeel volgens functionaliteit, verandert dit niets aan de code. Het programma blijft even efficiënt en gebruikt evenveel geheugen. Het is echter veel duidelijker welke klassen welke functionaliteit hebben en dit maakt het programma gemakkelijker aanpasbaar en uitbreidbaar. 2.4 Het tweede project Dit project is geen afgewerkte applicatie, maar een ondersteunende structuur waarop de klant een applicatie kan bouwen. Er wordt onder meer een embedded besturingssysteem aangeboden om het taakbeheer en geheugenallocatie te doen. Dit real-time besturingssysteem bestaat reeds, de overige functies werden door E.D.&A. toegevoegd. 2.4.1 Analyse van ontwerppatronen Er werden reeds een aantal patronen gebruikt, zowel in het RTOS als in de rest van de applicatie. De volledige beschrijving van de patronen kan weer gevonden worden in het boek van Bruce Powel Douglass [4]. Enkel de patronen nuttig voor de code van E.D&A. worden beschreven, patronen gebruikt in het besturingssysteem niet. Layered patroon Beschrijving van het patroon Het programma wordt onderverdeeld in verschillende niveaus van abstractie. Zo wordt de eigenlijke implementatie van de functionaliteiten van het programma gescheiden van de delegatie van de opdrachten en verloopt de werking van het programma transparanter. Toepassing van het patroon Dit programma is een ondersteunende structuur waarop applicaties worden gebouwd. Het gehele programma is dus de onderste laag uit het gelaagd patroon. Meer abstracte lagen worden door de bovenliggende applicatie geïmplementeerd.

HOOFDSTUK 2. INDUSTRIËLE GEVALSTUDIE 16 5-layered patroon Beschrijving van het patroon Wanneer een programma op basis van abstractie wordt opgedeeld, zoals in het gelaagd patroon, zal de onderste (minst abstracte) laag groot zijn, omdat een embedded systeem vooral is afgestemd op de hardware. Met dit patroon wordt er een onderscheid gemaakt binnen deze laag die het gemakkelijker maakt componenten te herkennen, met het oog op eventuele latere uitbreiding. De klassen worden opgedeeld in volgende categorieën: Application: De klassen die typisch zijn voor deze applicatie en dus, in tegenstelling tot klassen in de andere categorieën, niet in andere programma s zullen voorkomen. User interface: Bevat alle elementen die nodig zijn voor de user interface. Communication: Alle klassen die communicatie met andere systemen regelen. Abstract OS: Zorgt voor een laag tussen het programma en het onderliggende OS, zodat enkel deze instructies moeten worden aangepast bij verandering van OS. Abstract Hardware: In deze laag bevinden zich de klassen die de randapparaten voorstellen, zoals sensors, interfaces en drivers. Toepassing van het patroon Hier is de onderste laag het volledige programma. Dit programma kan worden opgedeeld in de bovenstaande vijf categorieën of lagen. Enkel de application-laag is nog niet aanwezig omdat de specifieke applicatie niet aanwezig is. Net zoals in het eerste project is de functionaliteit goed verdeeld, maar ontbreekt de zichtbare verdeling (bv door gebruik van mappen of naamgeving). Een gedeelte van de code is wel onderverdeeld, de code voor het OS staat in een aparte map en de klassen die de drivers voor in- en output bevatten, kregen het prefix Io -. Conclusie Net zoals in het eerste project is het belangrijk om de onderverdeling duidelijk weer te geven. Een consistente weergave is ook gewenst (mappen of naamgeving). Dit komt de uitbreidbaarheid en leesbaarheid ten goede. Recursive contaiment patroon Scheidt de verschillende functionaliteiten van het pro- Beschrijving van het patroon gramma op verschillende niveau s. Toepassing van het patroon Omdat het programma slechts één laag van abstractie weergeeft, is de indeling volgens functionaliteit al deels gegeven door het 5-gelaagd patroon. Deze indeling is niet recursief. In het besturingssysteem zien we wel een weergave van het recursive containment patroon: als we het besturingssysteem zien als de hoofdfunctionaliteit, dan wordt deze op een lager niveau opgedeeld in de enkele deelfunctionaliteiten zoals geheugenbeheer, taakbeheer, etc. De onderverdeling in deelfunctionaliteiten wordt hier duidelijk gemaakt door de naamgeving. Conclusie Het recursive containment patroon wordt gebruikt in het besturingssysteem, maar niet in het programma omdat dit slechts een deel van de uiteindelijke applicatie zal zijn. Toepassing van dit patroon op de code geschreven door E.D.&A. is niet nuttig.

HOOFDSTUK 2. INDUSTRIËLE GEVALSTUDIE 17 Watchdog patroon Beschrijving van het patroon Om corruptie van de gegevens tegen te gaan, wordt bij gebruik ervan de waakhond (watchdog) ingeschakeld die een check doet van de gebruikte gegevens. Toepassing van het patroon Volledig conform het patroon wordt een bericht naar de waakhond gestuurd. De waakhond gaat dan na of er een fout is gebeurd. In dit systeem wordt niet gekeken naar het moment waarop het bericht naar de waakhond wordt gestuurd. Conclusie Het waakhondpatroon is een eenvoudig, lichtgewicht patroon dat een eenvoudige controle uitvoert op berekende gegevens. Het patroon werd hier toegepast, zoals beschreven in het boek. 2.4.2 Toegevoegde patronen In de vorige sectie werdt het project geanalyseerd en werden de verschillende ontwerppatronen geïdentificeerd. In dit deel, bekijken we welke patronen nog kunnen toegevoegd worden om de applicatie beter te maken. Ook de patronen die slechts gedeeltelijk werden toegepast, worden hier verder geïmplementeerd. Guarded call patroon Beschrijving van het patroon Om ervoor te zorgen dat resources door verschillende taken kunnen worden gebruikt, wordt met behulp van dit patroon een interface voor deze resource voorzien. Elke methode die de resource gebruikt, doet dit via deze interface. Zo kan de toegang tot de resource gecontroleerd worden en wordt een deadlock vermeden. Toepassing van het patroon Het patroon wordt toegepast op de Spi1-resource. Deze resource wordt gebruikt door een Display-klasse en een Flash-klasse. Eerst wordt een test geschreven die de oproepen naar de Display-klasse test. Dan wordt de interface voor de Spi1-resource gemaakt. In deze interface komen alle methoden die gebruik maken van de Spi1-resource. Dit blijken enkel methoden uit de Display- en de Flash-klasse te zijn. Alle betreffende omroepen worden langs de interface omgeleid. Tenslotte wordt de bovenstaande test opnieuw uitgevoerd om eventuele veranderingen te meten. Een grafisch overzicht van de veranderingen is te vinden in figuren 2.4 en 2.5. Hier is telkens een eenvoudig klassendiagram te zien en een interactiediagram dat de oproepen illustreert. Figuur 2.4 toont de situatie voor de veranderingen, figuur 2.5 toont welke veranderingen werden gedaan. Conclusie De applicatie loopt niet efficiënter, oproepen naar de resource worden immers omgeleid via de interface. Wel zal het gebruik van resources in principe veiliger gebeuren. Alle toegang vanuit andere threads tot de resource verloopt via de interface en verloopt dus gecontroleerd. In dit geval heeft het gebruik van dit patroon weinig meerwaarde voor de applicatie. De applicatie werd in de programmeertaal C geschreven. Deze taal is procedure-gericht en er is dus geen verschil tussen de oproep naar de methode van de interface of wanneer de

HOOFDSTUK 2. INDUSTRIËLE GEVALSTUDIE 18 (a) Klassendiagram (b) Interactiediagram Figuur 2.4: Klassendiagram en interactiediagram voor de veranderingen methode in de server rechtstreeks wordt opgeroepen. Wanneer de taal C++ zou gebruikt worden, zou dit patroon wel nut hebben, omdat dan de methoden van de server kunnen worden afgeschermd van andere threads, wat de veiligheid van de applicatie bevorderdt. Component based architecture Beschrijving van het patroon Door een onderscheid te maken tussen de verschillende functionaliteiten van de applicatie en deze los van elkaar te ontwerpen, kunnen een aantal herbruikbare componenten worden gemaakt. Deze kunnen dan later in andere applicaties die dezelfde functionaliteit vereisen gebruikt worden. Toepassing van het patroon Door de verschillende klassen die de functionaliteit implementeren te verschuilen achter een publieke interface, kan deze groep klassen als een component worden beschouwd. De component kan dan gecompileerd worden bijgehouden en gebruikt wanneer nodig. Zo kan een applicatie worden opgebouwd uit verschillende componenten, waarbij enkel de tussenlaag nog geïmplementeerd moet worden. De applicatie is reeds opgedeeld in verschillende functionaliteiten (zie ook het recursive containment patroon). Omdat de applicatie is geschreven in C, is de interfacelaag niet nodig zolang de aangeboden methoden publiek zijn. De hardwarelaag kan nog verder worden opgedeeld in componenten. Het is echter moeilijk om in bestaande code dit patroon toe te passen. Alle code moet immers herschreven worden. Alle oproepen tussen componenten moeten veranderd worden naar een oproep naar de interface van een component. Omdat het moeilijk te traceren is waar een methode wordt opgeroepen en omdat het moeilijk is de volledige applicatie te herschrijven, werd enkel een virtuele wijziging gemaakt in de diagrammen. Enkel de componenten OS, HAL en Modbus bestonden voordien.