Onderzoek naar het specificeren van logica in een Software

Onderzoek naar het specificeren van logica in een Software

Development Tool

Auke Vleerstraat 4 7521 PG Enschede www.claves.nl info@claves.nl Tel: 053 - 436 2340 Fax: 053 - 432 9820

Auteur: Rien Heule

Opleidingsinstituut: Rijksuniversiteit Groningen Opdrachtgever: Claves B.V.

1

Begeleider: ir F.B.E. Blommestein

2

Begeleider: dr ir T.D. Meijler

Datum: Augustus 2007

Plaats: Heeten

Voorwoord

Voor u ligt het rapport van mijn afstudeeronderzoek dat ik heb uitgevoerd in het kader van mijn afstudeertraject voor de opleiding Technische Bedrijfswetenschappen, richting Informatie Technologie, aan de Rijksuniversiteit Groningen. Voor deze scriptie heb ik onderzoek gedaan naar het specificeren van logica in een ontwerp voor software in het product Novulo. Dit ten behoeve van het kunnen genereren van volledig werkende webapplicaties.

Dit onderzoek heeft plaatsgevonden bij Claves B.V. met als doel om het product Novulo naar een hoger niveau te tillen. De inhoud van deze scriptie is dan ook vooral bedoeld voor de directie van Claves en mijn begeleiders. Daarnaast kan deze scriptie interessant zijn voor een ieder die geïnteresseerd is in softwareontwikkeling of de vernieuwende methode van het ontwikkelen van software via de gebruikersinterface.

Tijdens mijn onderzoeksstage van oktober 2006 tot juni 2007 heb ik diverse stadia van ontwikkeling van het relatief jonge en snelgroeiende bedrijf Claves mogen meemaken en heb ik veel geleerd over zowel de technische als bedrijfskundige aspecten van software- ontwikkeling in de praktijk. Bij deze wil ik de directeur Frank Wille bedanken voor de mogelijkheid en de ruimte die hij mij heeft gegeven voor het doen van dit afstudeer- onderzoek. Daarnaast wil ik de medewerkers van productontwikkeling Erik-Jan, Geert, Tjitze, Vincent en Wim bedanken voor de interessante en informatieve gesprekken over de technische aspecten van Novulo.

Graag wil ik mijn begeleider Fred van Blommestein bedanken voor zijn aanwijzingen en opbouwende kritiek tijdens onze gesprekken in de stationsrestauratie te Deventer. Ook wil ik Theo Dirk Meijler, mijn tweede begeleider, bedanken voor zijn constructieve feedback.

Zonder hun begeleiding was deze scriptie niet geworden tot wat het nu is. Verder bedank ik mijn goede vrienden Emiel, Hinse, Jan-Willem en Mark voor de verhelderende gesprekken die we hebben gehad. De waardevolle betekenis van het zo simpel mogelijk uitleggen van wat je nu eigenlijk aan het onderzoeken bent is enorm. Als laatste bedank ik mijn ouders.

Zonder hun belangstelling en onvoorwaardelijke steun gedurende mijn afstudeerperiode en gehele studententijd was het me niet gelukt om te komen waar ik nu ben.

Rien Heule

Heeten, Augustus 2007

Samenvatting

De laatste decennia zijn in de Informatie en Communicatie Technologie de mogelijkheden voor de automatisering van bedrijfsprocessen enorm toegenomen. In eerste instantie waren vooral grote bedrijven in staat om de kostbare automatiseringsprojecten te financieren, maar naar mate de mogelijkheden en het aantal spelers in de ICT-markt toenamen, daalden de gemiddelde kosten voor ICT-oplossingen en werd het voor bedrijven in het MKB steeds aantrekkelijker om tot automatisering over te gaan. Het relatief jonge en snelgroeiende bedrijf Claves B.V. wist hierop in te spelen door het realiseren van betaalbare, op maat gemaakte webapplicaties voor bedrijven uit het MKB.

Het kostbare proces van het maken van een functioneel ontwerp alsmede de immer blijvende onduidelijkheid bij klanten met betrekking tot wat zij uiteindelijk krijgen voor hun geld, heeft Claves ertoe bewogen om een CASE-tool (Computer Aided Software Engineering) te ontwikkelen waarmee de requirements voor de software vastgelegd kunnen worden in een ontwerp van de grafische gebruikersinterface. Deze CASE-tool genaamd Novulo is vervolgens verder ontwikkeld zodat grote delen code van de software automatisch gegenereerd konden worden uit het ontwerp. Nu is het echter de wens van de directie om een volledig werkende webapplicatie te kunnen genereren vanuit een gespecificeerd softwareontwerp. Het probleem hierbij is dat niet alle specificaties in een softwareontwerp kunnen leiden tot gegenereerde code. Hiertoe is de volgende doelstelling voor dit onderzoek opgesteld:

“Het realiseren van metamodellen ten behoeve van de implementatie van specificatie- mechanismen voor niet-executeerbare specificaties in de Novulo Architect, opdat in de toekomst een volledig werkende webapplicatie gegenereerd kan worden uit een softwareontwerp.”

De bijbehorende hoofdvraag die voor dit onderzoek is geformuleerd, is als volgt:

“Welke niet-executeerbare specificaties veroorzaken de ongewenste gap in Novulo waardoor het niet mogelijk is om een volledig werkende webapplicatie te genereren, en hoe kunnen deze specificaties in de toekomst door een persoon zonder kennis van programmeren in de Novulo Architect vastgelegd worden zodat een volledig werkende webapplicatie direct uit het ontwerp gegenereerd kan worden?”

Het onderzoek is uitgevoerd in twee delen. Het eerste gedeelte bestaat uit een grondige analyse van het concept Novulo en een GAP-analyse met betrekking tot het specificeren van requirements. In het tweede deel wordt er gezocht naar geschikte specificatietechnieken om de GAP’s te dichten die vervolgens worden gebruikt bij het opstellen van metamodellen.

De analyse van het concept Novulo is uitgevoerd door het concept vanuit het perspectief van Software Engineering te beschrijven en te vergelijken met andere ontwikkelingsmethoden.

Daarop is Novulo geanalyseerd door het beschrijven van de voorgeschiedenis, de

samenstelling en werkwijze van het concept, het soort software dat ermee ontwikkeld kan

worden, de manier waarop een softwareontwerp wordt gemaakt en de voor- en nadelen van

Novulo. Het is gebleken dat Novulo een eigen wijze van Rapid Application Development

hanteert. Met het Novulo pakket, bestaande uit een Architect, Framework en Generator, kan

een softwareontwerp ontwikkeld worden door de grafische gebruikersinterface van de

software vorm te geven door middel van visual programming. Het specificeren van grafische

componenten – representaties van stukken gestandaardiseerde code uit het Framework – in de Architect, leidt tot een ontwerp dat alle schermen van de software omvat en kan door de Generator getransformeerd worden in code. Vooralsnog kan circa 80 procent van de code uit een softwareontwerp worden gegenereerd. De resterende code moet handmatig door programmeurs worden geïmplementeerd.

In de GAP-analyse van Novulo is de huidige situatie met de gewenste situatie vergeleken.

Het resultaat van de GAP-analyse is een lijst met niet-executeerbare specificaties. Om een volledig werkende webapplicatie te kunnen genereren zouden deze requirements als executeerbare specificaties in een softwareontwerp vastgelegd moeten kunnen worden.

Vervolgens zijn de niet-executeerbare specificaties uit deze lijst beoordeeld en gecategoriseerd naar de wijze waarop ze gespecificeerd moeten worden. Hieruit bleek dat er twee categorieën specificaties zijn, namelijk regels en transactieprocessen, waar momenteel geen specificatiemechanismen voor bestaan in de Architect. Voor beide categorieën is een lijst opgesteld met eisen aan de metamodellen.

Vervolgens is in het tweede deel van het onderzoek gezocht naar geschikte specificatietechnieken welke de basis zouden vormen voor het maken van de metamodellen.

Het resultaat van dit onderzoek is dat het Rule Wizzard model van Linehan en het UML

Activity Diagram geschikt bevonden zijn voor het specificeren van respectievelijk regels en

transactieprocessen. Tot slot zijn in hoofdstuk 7 voor beide categorieën metamodellen

opgesteld door het Rule Wizzard model en het UML Activity Diagram als uitgangspunt te

nemen en conform de gestelde eisen aan te passen. Het resultaat hiervan zijn de

metamodellen die het uitgangspunt vormen voor de implementatie van de specificatie-

mechanismen in de Architect. Het onderzoek is vervolgens afgesloten met de aanbevelingen

om deze metamodellen te gebruiken voor de implementatie in de Architct.

Inhoudsopgave

Voorwoord...2

Samenvatting ...3

Inhoudsopgave ...5

1 Inleiding ...7

1.1 Achtergrond...7

1.2 Bedrijfsbeschrijving Claves ...7

1.3 Onderzoeksopdracht...8

2 Onderzoeksopzet ...9

2.1 Inleiding...9

2.2 Probleemanalyse ...9

2.3 Probleemstelling...9

2.4 Deelvragen...10

2.5 Scope...10

2.6 Aanpak...11

3 Software ontwikkeling ...13

3.1 Inleiding...13

3.2 Software Engineering...13

3.3 Activiteiten van het software proces...13

3.3.1 Requirements analysis ...14

3.3.2 System design...15

3.3.3 Implementation...15

3.3.4 Integration & Deployment...16

3.3.5 Operation & Maintenance...16

3.4 Ontwikkelingsmethoden ...17

3.4.1 Watervalmethode ...17

3.4.2 Iteratieve ontwikkeling ...18

3.4.3 Rapid Application Development ...19

3.5 Software specificaties...21

3.5.1 Representatiewijzen ...22

3.5.2 Architectuur ...24

3.6 Conclusie ...26

4 Novulo...27

4.1 Inleiding...27

4.2 Voorgeschiedenis...27

4.3 Novulo pakket ...28

4.3.1 Het Framework...28

4.3.2 De Architect...29

4.3.3 De Generator...30

4.4 De software ...31

4.4.1 Software classificatie...31

4.4.2 Webbased software...32

4.4.3 Novulo software...33

4.5 Werkwijze...34

4.5.1 Requirements Analysis & System Design ...34

4.5.2 Implementation, Integration & Deployment...35

4.5.3 Operation & Maintenance...36

4.6 Een softwareontwerp ...36

4.6.1 Datamodel ...37

4.6.2 Functionaliteiten ...37

4.6.3 Voorwaarden en beperkingen op de functionaliteiten...38

4.7 Bedrijfsprocessen...38

4.7.1 Activiteiten ...39

4.7.2 Pre- en postcondities...40

4.7.3 Rollen ...41

4.8 Kritische reflectie op Novulo...41

4.8.1 Voordelen van Novulo ...42

4.8.2 Nadelen van Novulo ...42

4.9 Conclusie ...42

5 GAP-analyse ...44

5.1 Inleiding...44

5.2 Gewenste situatie...44

5.3 Huidige situatie...45

5.3.1 Datamodel ...46

5.3.2 Functionaliteiten ...47

5.3.3 GUI specificaties ...48

5.4 De GAP...48

5.4.1 Speciale functionaliteiten en canvassen...48

5.4.2 Regels ...49

5.4.3 Speciale transactieprocessen...50

5.5 Mogelijkheden tot specificeren ...51

5.5.1 Speciale functionaliteiten en canvassen...51

5.5.2 Regels ...52

5.5.3 Speciale transactieprocessen...52

5.5.4 Eisen aan specificatiemechanismen...52

5.6 Conclusie ...53

6 Geschikte specificatietechnieken...55

6.1 Inleiding...55

6.2 Business Rules ...55

6.2.1 Inleiding ...55

6.2.2 Business Rules Approach ...55

6.2.3 Soorten business rules...56

6.2.4 Transformatie van business rules...56

6.3 Unified Modeling Language...57

6.3.1 Inleiding ...57

6.3.2 Statische structuur...58

6.3.3 Dynamisch gedrag...58

6.4 Conclusie ...61

7 Metamodellen ...63

7.1 Inleiding...63

7.2 Regels...63

7.2.1 Analyse van eisen aan metamodellen voor regels ...63

7.2.2 Analyse van eisen aan metamodel structurele regels ...64

7.2.3 Metamodel voor structurele regels ...65

7.2.4 Analyse van eisen aan metamodel afgeleide regels ...66

7.2.5 Metamodel voor afgeleide regels ...66

7.3 Speciale transactieprocessen ...66

7.3.1 Analyse van eisen ...66

7.3.2 Metamodel...68

7.3.3 Interface ...69

7.4 Conclusie ...70

8 Conclusies en aanbevelingen...72

9 Literatuurlijst ...75 Appendices... Error! Bookmark not defined.

A. Definities en terminologie ... Error! Bookmark not defined.

B. The Business Rules Manifesto ... Error! Bookmark not defined.

C. Syntax van UML Activity Diagram ... Error! Bookmark not defined.

1 Inleiding

1.1 Achtergrond

Informatie en Communicatie Technologie (ICT) heeft de laatste decennia een dominantie positie in het bedrijfsleven ingenomen. Jarenlang hebben nieuwe ontwikkelingen in de Informatie Technologie (IT) het voor steeds meer bedrijven mogelijk gemaakt om bedrijfsprocessen gedeeltelijk dan wel geheel te automatiseren. Met de komst van het internet en mobiele communicatie werd de term IT geleidelijk vervangen door het begrip ICT en vond er een verschuiving plaats van marketingpull naar technologiepush. De internethype veroorzaakte een enorme toename aan automatisering in het bedrijfsleven, mede omdat men zich door de technologische mogelijkheden gedwongen voelde om op de golf mee te gaan.

Administraties werden geautomatiseerd en het internet werd hét nieuwe medium om met klanten en leveranciers te communiceren. In het jaar 2000 kwam de hype tot een einde, maar de behoefte aan ICT-oplossingen bleef bestaan. Automatisering is voor bedrijven namelijk een middel om veerkracht, efficiency, responsiviteit en flexibiliteit te bewerkstellingen [IBM].

De vraag naar en het aanbod van software en internetdiensten zijn sinds het begin van deze internethype enorm toegenomen. Softwarebedrijven bieden pakketsoftware of software oplossingen op maat en Internet Service Providers bieden op verschillende manieren internetverbindingen aan met diverse aanvullende services. Mede door de toename in het aanbod en daaruit volgend de toegenomen afzet van deze diensten zijn de gemiddelde kosten voor een ICT-oplossing de laatste jaren afgenomen. Daarnaast is een trend te onderscheiden van toenemend gebruik van open-source software. De broncode van open- source software kan zonder kosten gebruikt worden en draagt bij in een daling in de kosten van ICT. Als gevolg van dergelijke kostendalingen is het aanschaffen van ICT-oplossingen voor het midden- en kleine bedrijf (MKB) steeds aantrekkelijker geworden. De vraag naar bedrijfssoftware voor het MKB is de laatste jaren daarom ook flink toegenomen.

1.2 Bedrijfsbeschrijving Claves

Het bedrijf Claves B.V. is een relatief jong en snel groeiend ICT-bedrijf dat zich bezighoudt met de ontwikkeling van webbased bedrijfssoftware. Claves is ongeveer vier jaar geleden opgericht door de ambitieuze en ondernemende student Frank Wille, is gevestigd in Enschede en telt 20 medewerkers, ongeveer negen FTE. Het bedrijf levert op maat gemaakte datageoriënteerde webapplicaties aan klanten in heel Nederland en bedient voornamelijk bedrijven uit het MKB. Voorbeelden van dergelijke webapplicaties zijn urenregistratiesystemen, customer relationship managementsystemen en projectadmini- stratiesystemen. Software op maat en op basis van webpagina’s is vanaf het begin het uitgangspunt geweest van het bedrijf. De focus op webbased software is direct het gevolg van de klantgeoriënteerde focus van Claves. Het bedrijf is altijd gericht op de wensen van de klant. Dit realiseert zij in haar producten door de wensen van de klant direct te vertalen naar applicaties die met gratis opensource software worden ontwikkeld. Hierdoor krijgt de klant maatwerk voor een betaalbare prijs.

Ruim twee jaar geleden is Claves begonnen met het ontwikkelen van een tool om op een

eenvoudige wijze de specificaties van de software vast te leggen. In deze tool, bekend onder

de naam Novulo, worden de wensen en eisen van de klant gespecificeerd in een compleet

ontwerp van de gebruikersinterface. Vervolgens kan met behulp van deze tool het ontwerp

omgezet worden in code. Momenteel is Novulo in staat om circa tachtig procent van de

softwarecode te genereren. Hierdoor is het echter noodzakelijk dat de overige twintig procent handmatig geïmplementeerd wordt.

1.3 Onderzoeksopdracht

De directie van Claves heeft echter de wens om webbased software te ontwikkelen zonder dat daarvoor geprogrammeerd hoeft te worden. Anders gezegd, de directie wil dat Novulo dusdanig wordt uitgebreid zodat een gespecificeerd ontwerp in Novulo volledig kan worden omgezet naar een werkende applicatie. Hiertoe heeft de directie van Claves mij de opdracht gegeven om een onderzoek te doen naar manieren om de specificaties die vooralsnog handmatig in de code geïmplementeerd moeten worden in Novulo te kunnen specificeren, opdat ook deze specificaties in code gegenereerd kunnen worden.

Ik, Rien Heule, ben student aan faculteit Bedrijfskunde van de Rijksuniversiteit Groningen, en heb deze opdracht aangenomen voor mijn afstudeeronderzoek. In het kader van de studie Technische Bedrijfswetenschappen met als afstudeerrichting Informatie Technologie doe ik in dit rapport verslag van het onderzoek dat ik bij Claves B.V. heb gedaan. Het betreft een praktijkonderzoek naar manieren om de niet-executeerbare specificaties in een ontwerp te kunnen specificeren zodat een volledig werkende webapplicatie gegenereerd kan worden zonder tussenkomst van een programmeur.

In het volgende hoofdstuk kunt u lezen hoe het onderzoek is opgezet en vindt u een

beschrijving van de aanpak van het onderzoek. Hierin vindt u tevens een leeswijzer voor de

overige hoofdstukken van dit rapport.

2 Onderzoeksopzet 2.1 Inleiding

Voorafgaand aan een onderzoek is het noodzakelijk om in een probleemstelling vast te leggen wat onderzocht gaat worden, met welk doel dat gebeurt en onder welke randvoorwaarden het onderzoek wordt uitgevoerd. Om tot een helder en duidelijk geformuleerde probleemstelling te komen, is het nuttig om allereerst een probleemanalyse te doen. In een probleemanalyse wordt het probleemgebied onderzocht en wordt geanalyseerd wat exact het probleem is. In dit hoofdstuk wordt de probleemanalyse uitgevoerd en de probleemstelling geformuleerd. De probleemstelling bestaat uit een doelstelling, een onderzoeksvraag en randvoorwaarden [Leeuw, 2000], en voorziet het onderzoek van een leidraad. Vervolgens wordt de hoofdvraag opgesplitst in deelvragen en de scope van het onderzoek vastgelegd. Daarna volgt een beschrijving van de aanpak van het onderzoek, ondersteund door een conceptueel model.

2.2 Probleemanalyse

In de onderzoeksopdracht wordt duidelijk dat de directie van Claves in een situatie van ongenoegen verkeert. Het probleem is de discrepantie tussen het willen hebben van een software ontwikkelingstool dat volledig werkende software kan genereren zonder tussenkomst van een programmeur en het niet hebben van een dergelijke tool. Claves heeft de afgelopen jaren gewerkt aan de ontwikkeling van Novulo, een uitgebreide tool om webbased software te specificeren en vervolgens te genereren. Echter, ongeveer tachtig procent van de programmacode kan uiteindelijk uit een dergelijk ontwerp gegenereerd worden. De directie van Claves wil dat de overige twintig procent ook kan worden gegenereerd uit een softwareontwerp. Deze twintig procent code bestaat volgens de directie voornamelijk uit logica. Dit kan niet anders dan als toelichting in het ontwerp worden gespecificeerd en dus betreffen het niet-executeerbare specificaties die niet kunnen leiden tot gegenereerde code. Het probleem kan dus teruggevoerd worden op het bestaan van een gap tussen de gewenste en de huidige situatie, waarin de niet-executeerbare specificaties de hoofdrol spelen.

2.3 Probleemstelling

Dit onderzoek is gericht op het analyseren en dichten van de gap tussen de gewenste en de huidige situatie van Novulo. Hiertoe kunnen nu de doelstelling en hoofdvraag van dit onderzoek geformuleerd worden:

Doelstelling

Het realiseren van metamodellen ten behoeve van de implementatie van specificatie-

mechanismen voor niet-executeerbare specificaties in de Novulo Architect, opdat in de

toekomst een volledig werkende webapplicatie gegenereerd kan worden uit een

softwareontwerp.

Hoofdvraag

Welke niet-executeerbare specificaties veroorzaken de ongewenste gap in Novulo waardoor het niet mogelijk is om een volledig werkende webapplicatie te genereren, en hoe kunnen deze specificaties in de toekomst door een persoon zonder kennis van programmeren in de Novulo Architect vastgelegd worden zodat een volledig werkende webapplicatie direct uit het ontwerp gegenereerd kan worden?

Randvoorwaarden

• ‘Niet-executeerbare specificaties’ zijn requirements die tekstueel worden vastgelegd in een softwareontwerp maar niet leiden tot gegenereerde code en bestaan uit woordelijke omschrijvingen in een softwareontwerp.

• Een softwareontwerp is een volledige specificatie van een applicatie in de Novulo Architect, dat zowel executeerbare als niet-executeerbare specificaties omvat.

• Onder ‘volledig werkende code’ wordt een gegenereerde webapplicatie verstaan dat zonder aanvullend programmeerwerk naar behoren functioneert.

• De met Novulo te ontwikkelen software betreft relatief eenvoudige, datageörien- teerde webapplicaties, die voornamelijk gericht zijn op het vastleggen en beheren van gegevens.

2.4 Deelvragen

Nu de hoofdvraag is gedefinieerd wordt deze opgesplitst in deelvragen die het beantwoorden van de hoofdvraag vereenvoudigen.

1. Hoe wordt software ontwikkeld?

1.1. Hoe ziet het generieke ontwikkelingsproces voor software eruit?

1.2. Hoe worden specificaties voor software vastgelegd?

2. Wat houdt Novulo precies in?

2.1. Wat is Novulo?

2.2. Wat voor software wordt met Novulo ontwikkeld?

2.3. Hoe ziet het ontwikkelingsproces met Novulo eruit?

2.4. Hoe wordt een softwareontwerp gemaakt?

2.5. Wat zijn de voor- en nadelen van Novulo?

3. Welke specificaties kunnen momenteel niet als executeerbare specificaties vastgelegd worden die wel vereist zijn voor het genereren van volledig werkende code?

3.1. Welke requirements kunnen als executeerbare specificaties worden vastgelegd?

3.2. Welke requirements worden als niet-executeerbare specificaties vastgelegd?

3.3. Voor welke categorieën niet-executeerbare specificaties moeten nieuwe specificatie- mechanismen ontwikkeld worden?

4. Wat zijn de eisen aan de metamodellen voor de specificatiemechanismen die het vastleggen van de ‘niet-executeerbare specificaties’ mogelijk moeten maken?

5. Welke specificatietechnieken zijn geschikt om de ‘niet-executeerbare specificaties’ te kunnen vastleggen?

2.5 Scope

In dit onderzoek wordt gezocht naar nieuwe mechanismen om de niet-executeerbare

specificaties in de Novulo Architect te kunnen specificeren. Het onderzoek zal resulteren in

een aantal metamodellen die het uitgangspunt vormen voor de benodigde aanpassingen in

de Architect. De implementatie blijft echter buiten beschouwing, maar wel er zullen aanbevelingen omtrent de implementatie gegeven worden.

Het genereren van volledig werkende software heeft in dit onderzoek betrekking op datageoriënteerde webapplicaties met een lage complexiteit. Een verdere afbakening van de mogelijk te ontwerpen software zal besproken worden in hoofdstuk 4 waarin Novulo uitgebreid behandeld wordt.

2.6 Aanpak

De hoofdvraag bestaat uit twee delen waarbij het tweede deel niet te beantwoorden is zonder een antwoord op het eerste deel. Dit betekend dat het onderzoek in twee delen uitgevoerd moet worden. In het eerste deel zal antwoord gevonden moeten worden op de vraag welke specificaties momenteel in Novulo als niet-executeerbare specificaties worden vastgelegd.

Hiervoor moet allereerst meer duidelijkheid komen over wat Novulo precies is. Deelvragen 2.1 t/m 2.3 zullen hier antwoord op geven. Om dit te bewerkstelligen zal het concept Novulo onderzocht moeten worden. Hiervoor zal de ontwikkelingsmethode van Novulo worden gereflecteerd op het generieke softwareontwikkelingsproces. Vervolgens kan met behulp van een GAP-analyse onderzocht worden wat de verschillen zijn tussen de huidige en de gewenste situatie om te bepalen welke requirements als niet-executeerbare specificaties in een softwareontwerp van Novulo worden vastgelegd. Een beantwoording van de deelvragen 3.1 t/m 3.3 zullen uiteindelijk leiden tot afsluiting van het eerste deel van dit onderzoek.

Het tweede deel van het onderzoek omvat de beantwoording op het tweede gedeelte van de hoofdvraag: “hoe kunnen deze specificaties in de toekomst door een persoon zonder kennis van programmeren in de Novulo Architect vastgelegd worden zodat een volledig werkende webapplicatie direct uit het ontwerp gegenereerd kan worden?” De resultaten van het eerste deel van het onderzoek zullen bepalend zijn voor het beantwoorden van de vragen 4 en 5.

Als de antwoorden op deze laatste deelvragen bekend zijn kunnen metamodellen ontwikkeld worden die zullen voorzien in een raamwerk voor de implementatie van specificatie- mechanismen in de Architect om in de toekomst ook de ‘niet-executeerbare specificaties’ in een softwareontwerp vast te leggen opdat geheel werkende applicaties gegenereerd kunnen worden. Als dit is voltooid, is de hoofdvraag beantwoord en de doelstelling bereikt en zal dit onderzoek zijn afgerond.

In figuur 2.1 wordt het onderzoek in een conceptueel model weergegeven waarin de lijn van

het onderzoek duidelijk zichtbaar is. Tevens is per onderzoeksstap aangegeven in welk

hoofdstuk het behandeld zal worden.

Figuur 2-1: Onderzoeksmodel

3 Software ontwikkeling 3.1 Inleiding

In dit hoofdstuk zal ingegaan worden op het algemene softwareontwikkelingsproces volgens de theorie van Software Engineering en zullen de eerste deelvragen uit paragraaf 2.5 beantwoordt worden. Deze vragen zijn “Hoe ziet het generieke ontwikkelingsproces voor software eruit?” en “Hoe worden software specificaties vastgelegd?”.

Het doel van dit hoofdstuk is om een theoretische basis te leggen voor het verdere onderzoek. Het hoofdstuk zal beginnen met korte inleiding op het begrip Software Engineering. Daaropvolgend wordt een beschrijving gegeven van de generieke activiteiten van het ontwikkelingsproces voor het ontwikkelen van software, gevolgd door een beschrijving van een aantal ontwikkelingsmethoden. Daarna zullen een aantal representatie- wijzen besproken worden die gebruikt kunnen worden om specificaties van software te beschrijven en vast te leggen.

3.2 Software Engineering

In 1996 omschrijft Ian Sommerville het begrip software engineering als een concept dat

“theorieën, methodes en tools betreft die nodig zijn voor het ontwikkelen van software”

[Sommerville 1996]. Een aantal jaren later definieert Ghezzi software engineering als “het veld van computerwetenschappen dat gaat over het bouwen van software systemen die zo groot en complex zijn dat ze door een team of teams ontwikkelaars gebouwd worden”

[Ghezzi et al. 2002]. In beide gevallen gaat het om de discipline waarbij software wordt ontwikkeld door abstracte representaties te maken van de realiteit, ook wel modelleren genoemd. Abstractie is een krachtige techniek waarbij alleen op de relevante aspecten van het probleemgebied wordt gefocust, waardoor de complexiteit van het probleem wordt gereduceerd [Maciaszek 2005].

Software engineering staat dus voor een systematische en georganiseerde benadering om hoge kwaliteitssoftware te ontwikkelen. Om het ontwikkelen van software te bewerkstelligen wordt een software proces model doorlopen. Een software proces model is een abstracte representatie van een software proces, wat een verzameling is van de activiteiten en bijkomende resultaten welke leiden tot een software product [Sommerville 2004]. Het software proces kent een vijftal fundamentele activiteiten die in ieder software proces model terug komen. Deze activiteiten zijn 'requirements analysis', 'system design', 'implementation', 'integration & deployment' en 'operation & maintenance', en worden in de volgende paragrafen behandeld. Daarna zullen een paar bekende ontwikkelingsmethoden worden besproken. Voor het beschrijven van de theorie over de software levenscyclus en de ontwikkelingsmethoden is voornamelijk de theorie van Maciaszek en Sommerville gebruikt.

3.3 Activiteiten van het software proces

Zoals hierboven reeds is genoemd, is het software proces de verzameling activiteiten en de

bijbehorende resultaten welke leiden tot een software product. De vijf fundamentele

activiteiten die het software proces omvatten zullen in deze paragraaf een voor een

behandeld worden.

3.3.1 Requirements analysis

De Requirements Analysis is de eerste activiteit in een software ontwikkelingstraject en staat voor de verzameling van activiteiten voor het bepalen en specificeren van de requirements.

Tijdens deze activiteit worden de wensen en eisen van de gebruikers geanalyseerd en vastgelegd. Deze ‘user requirements’ zijn verklaringen in natuurlijke taal en diagrammen waarin wordt beschreven welke functionaliteiten de software zal moeten verlenen en onder welke beperkingen het zal moeten werken [Sommerville 1996]. Tijdens de requirements analysis, die overigens ook wel requirements engineering wordt genoemd, zijn er twee stappen te onderscheiden die uiteindelijk het requirements document als resultaat hebben.

Requirements Definition

De eerste stap is de requirements definition, ook wel bekend als requirements determination, waarin wordt bepaald wat precies de wensen en eisen zijn van de toekomstige gebruikers.

Het is gebleken dat het eenduidig vastleggen van de user requirements – ook wel business requirements – een van de meest uitdagende activiteiten is van het software ontwikkelings- proces, omdat gebruikers vaak onduidelijk zijn over de vereisten van de software [Maciaszek 2005]. Ook komt het voor dat verschillende gebruikers tegenstrijdige wensen of eisen aan de software stellen en zo het vastleggen van de requirements moeilijk maken. Daarnaast speelt het aspect communicatie tussen de gebruikers en de ontwikkelaars een cruciale rol. Als ontwikkelaars de requirements van de gebruikers verkeerd interpreteren, dan is het project vanaf de start al gedoemd te mislukken. Een ander probleem dat bestaat bij requirements definition is dat klanten en gebruikers bepaalde requirements vergeten aan te geven, waardoor tijdens een latere activiteit nieuwe requirements gedefinieerd moeten worden.

Een methode om dergelijke problemen te voorkomen is om de requirements analysis iteratief uit te voeren. De user requirements worden dan in natuurlijke taal en diagrammen vastgelegd in het requirements document en voor verificatie teruggespeeld naar de klant en de toekomstige gebruikers. Zij kunnen dan controleren of het document volledig is en eventueel fout geformuleerde en ontbrekende requirements ter verbetering terugkoppelen aan de ontwikkelaars.

Aanvullende methodes om de requirements volledig en ondubbelzinnig te extraheren zijn vragenlijsten aan gebruikers, gezamenlijke ontwikkelsessies tussen ontwikkelaars en klanten, en het demonstreren van prototypes om specificaties te bevestigen en om nieuwe requirements te ontdekken [Maciaszek 2005].

Requirements Specification

De tweede stap is requirements specification. Hierin worden de user requirements tot in detail uitgewerkt en omgezet in system requirements, en vastgelegd in het requirements document in zowel tekstuele beschrijvingen als in grafische modellen. Er bestaan twee soorten requirements: functionele requirements en non-functionele requirements. Functionele requirements zijn specificaties die de vereiste functionaliteiten en services van de software beschrijven, en non-functionele requirements specificeren de beperkingen op de software en op het ontwikkelingsproces [Sommerville 1996]. Non-functionele requirements hebben betrekking op het gedrag van de software in zijn geheel en hebben bijvoorbeeld betrekking op de performance en het gebruiksgemak [Dennis et al. 2005].

System requirements zijn requirements die beschrijven wat de software moet doen in plaats

van hoe het opgelost moet worden. Het vastleggen van oplossingen op een hoog

ontwerpniveau kan namelijk later in het ontwikkelingstraject voor problemen zorgen en de

speelruimte van de ontwikkelaars beperken. De system requirements vormen het hoogste ontwerpniveau en fungeren vaak als basis voor het contract met de klant.

Requirements Document

Het requirements document is het resultaat van de requirements analysis van het software ontwikkelingsproces. In het document staan alle specificaties beschreven op een manier dat leesbaar is voor alle betrokken partijen. Dat wil zeggen dat er geen formele ontwerptalen worden gebruikt om requirements te beschrijven die voor klanten en gebruikers van de software doorgaans onleesbaar zijn.

3.3.2 System design

De tweede activiteit is System Design. Tijdens deze activiteit wordt de architectuur van de software ontworpen aan de hand van het requirements document. Sommerville omschrijft een software ontwerp als “een beschrijving van de structuur van de te implementeren software, de data die deel uitmaakt van het systeem, de interfaces tussen de componenten van het systeem en, soms, de te gebruiken algoritmes” [Sommerville 2004]. Dit komt overeen met de definitie van een software systeem als een verzameling data structuren en algoritmes [Shaw et al. 1996]. Tijdens de system design activiteit wordt de analyse van de requirements voortgezet door het ontwerp van de software tot in detail uit te werken. Datastructuren worden vastgelegd in modellen, die meestal als blauwdruk gelden voor de database, en er worden algoritmes beschreven die de benodigde functionaliteiten zullen ondersteunen. De algoritmes worden niet altijd volledig beschreven om zodoende tijdens te implementatie een bepaalde mate van vrijheid aan de programmeurs over te laten.

Architectural design

Naast het gedetailleerd uitwerken van de requirements, wordt tijdens de activiteit system design de architectuur van de software vastgelegd, het architectural design. De bedoeling van het architectural design is het opzetten van een efficiënte en effectieve architectuur van de software. Volgens Maciaszek betreft de architectuur van een software ontwerp het opzetten van een framework voor het systeem, de structuur van componenten die in het detailed design naar voren komen, en de beginsels en patronen van de communicatie tussen de componenten [Maciaszek 2005]. In de architectuur wordt dus op het hoogste ontwerpniveau de structuur vastgelegd door een indeling van software modules. Hierdoor wordt inzichtelijk gemaakt wat de intermodulaire afhankelijkheden zijn en kan vervolgens de basis gelegd worden voor een efficiënte communicatie tussen de modules. In paragraaf 3.5 zal het begrip Architectuur verder uitgelicht worden.

3.3.3 Implementation

De activiteit Implementation bestaat uit het ontwikkelen van de softwarecode. Tijdens de

implementatie wordt het system design omgezet naar code en wordt de ontbrekende code

handmatig door programmeurs aangevuld. In sommige gevallen, bijvoorbeeld bij wordt voor

de transformatie van het system design naar code gebruikt men krachtige en intelligente

Computer Aided Software Engineering tools (CASE tools) en Integrated Development

Environments (IDE`s) [Maciaszek 2005]. De code die niet wordt gegenereerd moet

vervolgens handmatig door programmeurs worden toegevoegd. De specificaties die nodig

zijn voor de ontbrekende code worden uit het system design geëxtraheerd en door de

programmeur geïnterpreteerd. Echter, deze specificaties zijn veelal niet volledig, met name

op het gebied van algoritmes, waardoor de programmeur zelf eerst een ontwerp moet maken

voordat de code geproduceerd kan worden. Om inconsistentieproblemen tussen de ontwerpmodellen en de software te voorkomen, worden na dergelijke handmatige aanpassingen met behulp van reverse engineering de ontwerpmodellen geüpdate. Dergelijke cycli van forward en reverse engineering wordt roundtrip engineering genoemd.

In de meeste softwareprojecten is implementatie de activiteit die het meeste tijd kost. Dit komt doordat het handmatig omzetten van requirements naar code een activiteit is die gevoelig is voor fouten. Vaak kost het debuggen en testen van de software meer tijd dan het creatieve proces waarin de software wordt gemaakt. Debuggen is de activiteit waarin bugs, errors in software code, worden opgespoord en gerepareerd. Veel errors in de syntax van de code en sommige fouten in de logica kunnen door speciale debugging-tools gevonden worden. Overige errors worden opgespoord door het testen van de software. Het testen van software kan op twee manieren, namelijk door het inspecteren van de code of door het controleren van het gedrag van de software terwijl het wordt uitgevoerd. Op beide manieren wordt grondig bekeken of de ontwikkelde software zich gedraagt zoals het zich volgens de requirements behoort te gedragen.

3.3.4 Integration & Deployment

Integration

De vierde activiteit is Integration & Deployment. Gedurende deze activiteit worden de verschillende losse componenten die tijdens de implementatie zijn ontwikkeld samenge- voegd. Tijdens deze activiteit wordt de software dan ook voor het eerst volledig

‘geassembleerd’ en speelt de architectuur uit de system design fase een cruciale rol. In de architectuur zijn namelijk de specificaties omtrent de verschillende software modules en de afhankelijkheden ertussen vastgelegd. Als de software modules geïntegreerd worden, is het van groot belang dat de communicatie tussen de modules correct verloopt en goed getest wordt.

Het integreren van de modules vindt doorgaans niet in één keer plaats, maar gebeurt in verschillende iteraties waarbij de software wordt geproduceerd als een opeenvolging van incrementele releases (versies). In iedere iteratie wordt één of een aantal componenten geïntegreerd en getest. Doordat dit de voornaamste activiteit is van de integration en deployment, wordt het ook wel integration testing genoemd [Maciaszek 2005].

Deployment

Als de integratie van alle modules gereed is, kan de software in gebruik genomen worden.

Officieel wordt dit deployment genoemd. Net als de integratie vindt de deployment plaats in een aantal iteraties door iedere keer een nieuwere release in gebruik te nemen. Elke release bevat een aantal incrementele aanpassingen dat samenhangende en bruikbare functionaliteiten biedt aan de gebruiker. Op deze manier kan de gebruiker de software leren te gebruiken. Dit valt ongeveer samen met de training van de gebruikers en het schrijven van de gebruikershandleiding, wat tevens activiteiten van integration & deployment zijn.

3.3.5 Operation & Maintenance

Als laatste is er de activiteit waarin de software gebruikt wordt en waarin onderhoud gepleegd

moet worden: de Operation & Maintenance. Gedurende deze activiteit wordt de software

dagelijks gebruikt en wordt eventueel het voorgaande systeem uitgefaseerd. In sommige

gevallen waar het nodig en/of mogelijk is wordt de oude software nog parallel naast de

nieuwe software gebruikt als uitwijkmogelijkheid voor het geval dat de nieuwe software niet

goed aansluit bij de bedrijfsvoering. Soms zijn bepaalde onderdelen van een oud systeem van dermate groot belang dat deze door speciale ‘life support’ technologieën in ‘leven’

worden gehouden. Zulke systemen worden legacy sytemen genoemd.

Vanaf het moment dat de software in gebruik genomen wordt, begint ook de maintenance aan het software product. In de software engineering betekent dit begrip meer dan alleen

‘onderhoud’; de verdere ontwikkeling van het product valt ook onder de noemer maintenance.

Sommerville verdeelt software maintenance in drie verschillende types: corrective, adaptive en perfective [Sommerville 1996].

• Corrective maintenance betreft het repareren van gevonden errors

• Adaptive maintenance betekent het aanpassen van de software in reactie op veranderingen in de technologische of business omgeving

• Perfective maintenance heeft te maken met het toevoegen van nieuwe features Software maintenance is dus een activiteit die zolang duurt als de resterende levensduur van de software. Maintenance is overigens vaak de oorzaak van het minder onderhoudbaar worden van de software, doordat het de helderheid van de architectuur aantast. Op den duur leidt dit tot het punt dat de software niet meer supportable is.

3.4 Ontwikkelingsmethoden

Nu de fundamentele activiteiten van het software proces zijn besproken zullen een aantal verschillende ontwikkelingsmethoden uiteengezet worden. Een ontwikkelingsmethode is een gestructureerde benadering om software te ontwikkelen met een eigen invulling van het software proces. De specifieke invulling van het model en de verschillende stappen is per organisatie anders en kan zelfs per project verschillen. Hiervoor zijn een aantal redenen, waaronder de verschillen in interne processen, de kennis en ervaring van de organisatie, de omvang van het project en het soort software dat ontwikkeld wordt. Ook interne en externe veranderingen kunnen invloed hebben op de invulling van het levenscyclus model.

Over het algemeen genomen worden twee algemene proces modellen onderscheiden, namelijk de ‘watervalmethode’ en ‘iteratieve ontwikkeling’. Deze twee modellen zullen nu verder worden toegelicht.

3.4.1 Watervalmethode

De Watervalmethode is de traditionele manier van software ontwikkelen waarbij de activi- teiten – ook wel fasen – van het software proces elkaar lineair opvolgen en de voorgaande fase afgesloten moet zijn voordat begonnen mag worden met de volgende fase. Bij het afsluiten van een fase wordt een officieel projectdocument doorgegeven wat het startpunt is voor de betreffende volgende fase. Als er in een latere fase blijkt dat bepaalde specificaties niet gedocumenteerd maar wel nodig zijn, dan kan dit via een feedback lus aan een voorgaande fase teruggekoppeld worden om de documentatie aan te passen.

Een cruciaal gegeven van het watervalmodel is dat het een monolithische ontwikkelmethode is. De projecten worden in keer uitgevoerd tot de software klaar is en opgeleverd kan worden.

Het resultaat van een project is daarom ook een enkele versie van de software; dit in tegenstelling tot het iteratieve model. Bij het watervalmodel wordt de gebruiker tijdens de requirements fase bij het project betrokken en blijft vervolgens tijdens de voortgang van het project in het ‘duister’ totdat de software klaar is en opgeleverd wordt.

Het voordeel van het watervalmodel is dat de projecten heel goed te beheersen zijn doordat

het ontwikkelproces goed zichtbaar is: een project kan zich maar in één fase tegelijk

bevinden. Een groot nadeel van dit model is de inflexibiliteit. Doordat een afgesloten fase niet

opnieuw kan worden doorlopen, komt het voor dat een opgeleverd systeem niet aan de werkelijke eisen en wensen van de gebruiker voldoet.

3.4.2 Iteratieve ontwikkeling

Iteratieve ontwikkeling is in tegenstelling tot het monolithische watervalmodel een ontwikkelmethode waarbij de software incrementeel wordt ontwikkeld. Dit model staat ook wel bekend als evolutionary software development. Een iteratie is een herhaling van een bepaald proces met als doel om het software product te van fouten te ontdoen en om de requirements helderder te krijgen. Iteratieve ontwikkeling veronderstelt korte iteraties, in weken of dagen, maar niet in maanden, waardoor betere planning en management mogelijk zijn [Maciaszek 2005].

Hoewel het watervalmodel feedback en overlaps ondersteund en dus een bepaald soort iteraties kent, is het niet iteratief omdat de activiteiten van het proces slechts een keer worden uitgevoerd. In het iteratieve model kunnen activiteiten van het proces worden herhaald en heeft iedere iteratie een verbeterde of uitgebreidere versie van het product als resultaat. Tevens gaat het iteratieve model uit van de aanwezigheid van 'builds'; uitvoerbare code wat het resultaat is van een iteratie. Een build representeert een deel van het totale systeem en kan gebruikt worden om bepaalde delen van de software te demonstreren aan de klant en toekomstige gebruikers.

Het model voor iteratieve ontwikkeling is een metamodel en dient derhalve als basismodel voor iteratieve ontwikkelingsmethoden. Er bestaan vele verschillende variaties, maar er zijn vijf zeer bekende iteratieve ontwikkelingsmethoden. Vier daarvan zullen hierop volgend kort worden besproken aan de hand van hun karakteristieken. De vijfde methode, Rapid Application Development (RAD), zal vervolgens in een aparte paragraaf uitvoeriger worden behandeld omdat RAD voor dit onderzoek relevant is.

Spiral model

Het Spiral model, ook wel Boehm's spiral model genaamd, bestaat uit een matrix met een horizontale en verticale as, waarbij de vier kwadranten vier verschillende stadia van het ontwikkelproces voorstellen. Deze vier zijn planning, risk analysis, engineering en customer evaluation. Via een spiraal beweging die dichtbij het centrum start in het planning kwadrant en die steeds verder naar buiten toe buigt, worden de vier fasen doorlopen. Na de customer evaluation kan de spiraal doorgetrokken worden om een volgende iteratie te starten. Uniek aan het spiral model is de risico analyse waarbij diverse analyses worden gedaan om een 'go no-go' beslissing te kunnen doen voordat er verder gewerkt mag worden aan het project.

Overigens, het spiral model is geen standaard ontwikkelingsmethode, maar eerder een metamodel of referentiemodel voor andere modellen [Maciaszek 2005].

Rational Unified Process

Het Rational Unified Process (RUP) is een uitgebreidere versie van het generieke unified proces, en is oorspronkelijk gebaseerd op het spiral model. Het RUP is meer dan een ontwikkelingsmethode omdat het ook een support omgeving omvat. Het proces model van RUP bestaat uit een horizontale en verticale as waarop respectievelijk 4 dynamische en 9 statische perspectieven staan. De vier dynamische aspecten zijn: inception, elaboration, construction en transition. Op de verticale as staan de softwareontwikkelingsactiviteiten:

business modelling, requirements, analysis and design, implementation, test, deployment,

configuration & change management, project management en environment.

Het voordeel van het scheiden van de dynamische en statische aspecten in het RUP model is dat de fasen van het ontwikkelingsproces niet worden geassocieerd met specifieke activiteiten. In principe mag iedere activiteit worden uitgevoerd in elke fase van het proces [Sommerville 2004].

Model Driven Architecture

Een derde ontwikkelingsmethode met iteraties is Model Driven Architecture (MDA), wat is ontwikkeld door de Object Management Group (OMG). Het MDA gebruikt UML als standaard modelleringstaal en probeert het ontwikkelen van software naar een nieuw niveau te tillen door de toepassing van ‘executable specifications’. Het idee hierachter is dat de modellen waarin specificaties worden vastgelegd getransformeerd kunnen worden naar uitvoerbare code. Dit concept is op zich niet nieuw, maar door het gebruik van bestaande standaarden en nieuwe technieken wordt het idee tot uitvoer gebracht.

MDA maakt gebruik van Platform Independent Models (PIM) om op een hoog niveau van abstractie de software te beschrijven, meestal in UML. De volgende stap is dat een PIM wordt getransformeerd naar een of meer Platform Specific Models (PSM) door middel van transformation tools. Een PSM is een gedetailleerder model van de software gefocust op een bepaalde implementatie technologie. De laatste stap is de transformatie van elke PSM naar code. Een voorwaarde voor MDA is dat alle modellen (PIM en PSM) in een welomschreven taal moeten worden vastgelegd, omdat alleen dan de specificaties door computers geïnterpreteerd kunnen worden om te kunnen transformeren naar gedetailleerde modellen of uitvoerbare code [Kleppe et al. 2003].

Agile Software Development

Agile software development is een relatief nieuwe benadering van software productie, waarbij creativiteit en flexibiliteit hoog in het vaandel staan. Het model stelt dat de productie van software een creatief proces is dat veel meer afhankelijk is van mensen en samenwerking dan van processen, tools, documentatie, planning en andere formaliteiten. Zo wordt verondersteld dat de gebruikers en eigenaren van de software bij het gehele ontwikkelproces betrokken worden, en niet alleen in de beginfase zoals bij andere ontwikkelingsmethoden het geval is. Ook wordt er tijdens het proces relatief weinig gedocumenteerd omdat veel van de kennis via intensieve samenwerking wordt overgedragen.

Ondanks de vernieuwende benadering van agile software development, volgt het model de activiteiten van analyse, design, implementation en deployment, maar dan met gebruik van een andere terminologie, en worden de activiteiten iteratief uitgevoerd. Het verschil met andere iteratieve modellen is de korte doorlooptijd. Agile software development gaat uit van korte cycli – iteraties die worden gemeten in weken in plaats van maanden [Maciaszek 2005].

3.4.3 Rapid Application Development

Rapid Application Development (RAD) is een iteratieve ontwikkelingsmethode dat speciaal is

gericht op een versnelde manier van software ontwikkelen en het maximaal benutten van

krachtige ontwikkelingssoftware [Agarwal et al. 2000]. De RAD methodologie wordt daarom

ook vaak geassocieerd met de tools die de methodologie mogelijk maken. Versnelde

ontwikkeling kan gerealiseerd worden door het software proces te verkorten met behulp van

krachtige tools, zoals bijvoorbeeld code generators, grafische interface builders, debugging

en scripting tools, database management systems (DBMS) of fourth generation languages

(4GLs) [Agarwal et al. 2000] [Beynon-Davies et al. 1999].

RAD methodieken omvatten 4 stadia, requirements planning, user design, construction en cutover, waarvan de eerste twee stadia soms worden samengevoegd tot één iteratieve activiteit. Algemene componenten van RAD methodieken zijn joint application development (JAD), snelle ontwikkeling, clean rooms, time boxing, prototyping, het gebruik van ontwikkelingtools en projecten met lage complexiteit [Beynon-Davies et al. 1999]. JAD staat voor het ontwikkelen van applicaties in kleine teams bestaande uit ontwikkelaars en gebruikers, waarvan wordt verwacht dat deze meetings plaatsvinden in clean rooms. Dit zijn ontwikkelomgevingen die vrij zijn van dagelijkse werkzaamheden en onderbrekingen om volledig te kunnen focussen op het ontwikkelen van de applicatie. Time boxing is een vorm van projectbeheersing waarmee deadlines voor oplevering en user reviews worden gesteld en wat een periode van afbakent waarin zoveel mogelijk wordt ontwikkeld als de timebox toelaat. Dergelijke opleveringen zijn doorgaans prototypes van de applicatie in ontwikkeling.

Prototyping of throw-away-prototyping wordt gebruikt om te zoeken naar oplossingen en om oplossingen te bespreken met teamleden en gebruikers, waarna het prototype of de oplossing in de software wordt gebruikt.

Zoals reeds eerder is gezegd, wordt een snelle ontwikkeling van applicaties mogelijk gemaakt door intensief gebruik van ontwikkelingstools. Een ander aspect waardoor snelle ontwikkeling mogelijk is, is het gegeven dat RAD voornamelijk gericht is op het ontwikkelen van kleinschalige applicaties met een relatief lage complexiteit. Della Penna et al.

karakteriseren RAD-applicaties aan de hand van de volgende vier issues: een lage tot gemiddelde hoeveelheid code, een hoge mate van (her)gebruik van bestaande componenten, een laag niveau van formele specificaties en korte release tijden [Della Penna et al. 2001]. Ook Beynon-Davies benoemt de eigenschap van RAD dat de documentatie tijdens een RAD-project tot een minimum wordt gehouden [Beynon-Davies et al. 1999]. Voor kleinschalige projecten waarmee applicaties met een lage complexiteit of applicaties bovenop bestaande databases worden ontwikkeld in combinatie met een hoge mate van betrokkenheid van de gebruikers, is een lage mate van documentatie dan ook goed mogelijk.

Visual Programming

Een veel toegepaste techniek bij RAD is Visual Programming (VP). Visual programming is een methode om op interactieve manier, met behulp van grafisch vormgegeven componenten die speciaal voor hergebruik ontwikkelde software componenten represen- teren, relatief simpele software te ontwikkelen [Sommerville 2004]. Visual programming is met name ontwikkeld om de geestelijke inspanning van het programmeren te verminderen.

Onderzoekers beweren dat visual programming de volgende voordelen heeft ten opzichte van gebruikelijke, tekstuele programmeertalen: gemakkelijk te gebruiken, gemakkelijk te leren, een verhoogde productiviteit, een betere leesbaarheid en een betere aansluiting bij de modellen die de programmeur in gedachte heeft [Whitley & Blackwell 1997]. Hoewel deze voordelen door veel personen in de industrie worden ondersteund, bestaan er meningsverschillen tussen onderzoekers, professionele programmeurs en gebruikers van VP over de kracht en de mate van het uitdrukken van berekeningen in VP-tools en de mate van schaalbaarheid en onderhoudbaarheid van de applicaties die ermee ontwikkeld worden [Whitley & Blackwell 1997].

Desalniettemin weet het VP-paradigma in te spelen op de verbeelding van gebruikers en

ontwikkelaars en wordt VP toegepast – ook door eindgebruikers zelf – om kleinschalige

applicaties en/of user interfaces te ontwikkelen.

Nadelen en gevaren van RAD

Naast de voordelen die RAD biedt vergeleken met de meer traditionele ontwikkelings- methoden, zijn er onderzoekers en ontwikkelaars die zich zorgen maken over de waarde van RAD en RAD-tools op de lange termijn. De snelle ontwikkelingsmethode van RAD vertaalt zich met name in het minimaliseren van formele specificaties en documentatie om zo snel mogelijk te beginnen met het ontwikkelen van prototypes en code met korte iteraties en hoge een betrokkenheid van gebruikers. Agarwal et al. identificeren een aantal zorgwekkende aspecten met betrekking tot het gebruik van RAD. Zo concluderen zijn dat er met RAD een afnemende nadruk op requirements planning en modelling te onderscheiden is en dat de ontwikkelingsmethodologie mogelijk wordt ondermijnd; er wordt veel meer aandacht besteed aan de implementatie dan aan de analyse van het domein. Dit leidt er toe dat ontwikkelaars de neiging hebben om niet in een vroeg stadium te zoeken naar inconsistenties en foute specificaties, waardoor deze fouten in een later stadium moeten worden verholpen. Ook stellen ze dat de voordelen van hergebruik niet kunnen worden verworven als er minder aandacht wordt besteed aan analyses, omdat de software niet op een abstract niveau wordt geanalyseerd en ontworpen, en omdat er niet wordt onderzocht welke componenten herbruikbaar zijn. Agarwal et al. concluderen dat de ad hoc manier van ontwikkelen met RAD op lange termijn schadelijke gevolgen kan hebben voor RAD-projecten. Doordat er niet genoeg aandacht wordt besteed aan de requirements, het ontwerp en de architectuur van de applicaties, zullen de schaalbaarheid en onderhoudbaarheid van de applicaties afnemen, waardoor de winst van het snelle ontwikkelen op lange termijn zal verdampen. Een ander probleem dat zij benoemen is dat managers onrealistische verwachtingen hebben met betrekking tot de snelheid van ontwikkelen met RAD. De RAD-tools scheppen bij managers de verwachting dat een applicatie al (bijna) klaar is op het moment dat een prototype gereed is, terwijl er dan nog weken nodig is om de implementatie ervan te realiseren [Agarwal et al.

2000].

Agarwal et al. en Martin adviseren daarom ook aan bedrijven en managers die RAD toepassen om zich goed te realiseren wat de implicaties zijn van RAD en raden aan om RAD te gebruiken in combinatie met een geschikte ontwikkelingsmethodologie.

3.5 Software specificaties

In deze paragraaf wordt verder ingegaan op het vastleggen van software specificaties. Het doel van deze paragraaf is het in kaart brengen van manieren die gebruikt kunnen worden om de specificaties voor software vast te leggen, om zodoende een antwoord te verkrijgen op de onderzoeksvraag "Hoe worden de specificaties van software vastgelegd?".

Voorafgaand aan de implementatie, moeten de specificaties van de software worden vastgelegd. Dit gebeurt normaal gesproken tijdens de activiteiten requirements analysis en system design van het software proces. In overleg met de verschillende stakeholders worden de wensen en eisen geanalyseerd en in user requirements vastgelegd. User

Figuur 3-1: Van wensen en eisen naar

specificaties

requirements zijn statements in natuurlijke taal (tekst) die beschrijven wat de software moet kunnen doen. Vervolgens worden de user require-ments omgezet in system requirements.

Dit zijn ook statements in natuurlijke taal, maar dan meer technisch van aard waarin al gefocust wordt op de implementatie. System requirements beschrijven derhalve hoe de software moet gaan werken en worden geschreven voor ontwikkelaars. Daarna worden aan de hand van deze system requirements modellen gemaakt en/of specificaties opgesteld.

Modellen en specificaties kunnen op twee manieren worden vastgelegd: in executeerbare vorm of in niet-executeerbare vorm. Executeerbare modellen en specificaties worden in formele talen genoteerd die door computers of programma’s geïnterpreteerd en uitgevoerd kunnen worden [Kleppe et al. 2003] [Fuchs 1992]. Niet-executeerbare modellen en specificaties kunnen dus niet door computers geïnterpreteerd worden en moeten tijdens de implementatie handmatig in formele talen worden omgezet. Met executeerbare modellen is het mogelijk om vanuit een hoog abstractie niveau executeerbare specificaties te genereren [Kleppe et al. 2003]. Executeerbare specificaties kunnen vervolgens worden uitgevoerd om de requirements te valideren. Een groot voordeel van executeerbare specificaties is dus dat in een vroeg stadium van het software proces de requirements op juistheid en consistentie gecontroleerd kunnen worden waardoor de juistheid en betrouwbaarheid van de software toenemen [Fuchs 1992]. Het geheel van modellen en specificaties vormt het ontwerp van de software.

In figuur 3-1 is schematisch weergegeven hoe in het software proces de modellen en specificaties van het ontwerp van de software tot stand komt door wensen en eisen steeds nader te specificeren. Het is van belang dat iedere overgang naar verder uitgewerkte requirements goed wordt gedocumenteerd, zodat later in het proces de bron van de require- ments te traceren is. Dit is nuttig, bijvoorbeeld om in geval van gewijzigde requirements de implicaties ervan te onderzoeken. De mate van de traceerbaarheid van requirements wordt ook wel ‘traceability‘ genoemd [Sommerville 2004].

Software wordt gedurende het ontwikkelingsproces op verschillende manieren gerepresen- teerd. Tijdens de activiteiten requirements analysis en system design worden representaties gebruikt om de specificaties van de software vast te leggen. Tijdens requirements analysis worden representaties tevens gebruikt om de software met de klant en de toekomstige gebruikers te bespreken. Afhankelijk van de activiteit in het ontwikkelingsproces worden een of meer verschillende representatiewijzen gebruikt.

3.5.1 Representatiewijzen

Figuur 3-2 laat zien dat software met behulp van verschillende representatiewijzen kan worden gerepresenteerd. De verschillende representaties geven een bepaald aspect of onderdeel van de software weer. Zo kan een specificatie van de GUI de grafische interface van de software representeren en code representeert door de syntax van de gebruikte programmeertaal de implementatie van de software. Hieronder zullen een aantal veel voorkomende en/of relevante representatiewijzen worden behandeld.

Figuur 3-2: Verschillende representatiewijzen om software te specificeren

Tekst

Als eerste representatiewijze is er eenvoudigweg tekst. Een softwareontwerp kan in tekst worden weergegeven door een beschrijving in natuurlijke taal. Door met woorden te beschrijven wat de software moet kunnen doen, wanneer, waar, hoe en waarom, kan een functioneel ontwerp van de software worden gemaakt dat voor alle stakeholders te begrijpen is. Tijdens de requirements fase wordt tekst als representatiewijze gebruikt om de requirements in natuurlijke taal in het requirements document vast te leggen. Aangezien in het requirements document alle specificaties van de software zijn opgenomen, bedekt deze representatiewijze alle aspecten van de software.

Een voordeel van deze representatiewijze is dat het ontwerp van de software makkelijk te communiceren is met stakeholders zoals gebruikers en eigenaars, die veelal geen technische achtergrond hebben. Het nadeel van tekst als representatiewijze is dat het veel tijd kost om te maken en om aan te passen in geval van gewijzigde requirements.

Business Rules

Software kan ook worden beschreven in termen van Business Rules (BR). Business Rules is een verzamelnaam voor de regels binnen een organisatie. Door de software met regels te beschrijven, kunnen alle beperkingen, voorwaarden en relaties, en daarmee dus het gedrag van de software vastgelegd worden. Een groot voordeel van deze Business Rules Approach (BRA) is dat niet de processen van de organisatie worden beschreven, maar juist de voorwaarden en regels waarvan de processen afhankelijk zijn [Morgan 2002]. Op deze manier moet het in de toekomst mogelijk worden om software volledig te beschrijven aan de hand van Business Rules, waardoor de software door aanpassing van de regels met de organisatie mee verandert.

Business Rules kunnen op drie verschillende niveaus uitgedrukt worden, en wel op informeel niveau, technisch niveau en formeel niveau. De keuze van het niveau hangt af van het doel van de representatie. Het informele niveau wordt gebruikt op het hoogste aggregatie niveau om BR in natuurlijke taal te representeren voor gebruikers, klanten en managers. Het technische niveau wordt gebruikt om BR op een meer gedetailleerde wijze weer te geven in een gestructureerde vorm inclusief operatoren en data verwijzingen. Op het formele niveau worden BR uitgedrukt in wiskundige taal [Morgan 2002].

Business Rules zijn beperkingen en voorwaarden die de software correct moeten laten functioneren en representeren derhalve de regels op de functionaliteiten en de non- functionele requirements van de software.

Unified Modeling Language

UML staat voor Unified Modeling Language en is sinds 1997 de standaard modelleertaal voor het analyseren en ontwerpen van informatiesystemen. Deze standaard is vastgelegd door de Object Management Group (OMG). UML-modellen zijn grafische weergaven van bepaalde aspecten van een informatiesysteem en worden onder andere gebruikt voor analyse en ontwerp van software [Maciaszek 2005]. Bijzonder aan UML is dat het een heel complete modelleertaal is; met behulp van de vele verschillende modellen die UML biedt, kan bijna een geheel softwaresysteem gemodelleerd worden. Met het klassendiagram van UML kan het datamodel gemodelleerd worden en met use-cases en verscheidene flow-diagrammen die met UML gemaakt kunnen worden is het mogelijk de functionaliteiten en het gedrag van de software tot in detail uit te werken. UML dekt hiermee de aspecten van het datamodel en de functionele requirements van software specificaties.

Tevens wordt door de OMG hard gewerkt aan het automatiseren van transformaties van

UML modellen. Door transformaties tussen UML modellen is het mogelijk om gedetailleerde

modellen en uitvoerbare code te genereren vanuit de minder gedetailleerde modellen op een hoger niveau. Deze methode vormt de kern van MDA en zal naar verwachting in de toekomst een steeds belangrijker rol spelen bij het ontwikkelen van software en informatiesystemen.

Code

Software kan ook door de code worden gerepresenteerd door middel van de programmeertaal die gebruikt is om de software maken. De code, ook wel broncode of programmacode, is de implementatie van de software middels de realisatie van algoritmen en klassen in syntactische vorm waarmee de functionaliteiten en de grafische interface van de software worden gerealiseerd. Code wordt gebruikt als representatie van een volledig software systeem en beslaat alle aspecten van de software die wordt gerepresenteerd. Het ís immers de software zelf.

Code is nuttig als representatiemiddel tijdens de implementatie fase, integration &

deployment fase en operation & maintenance fase. Programmeurs gebruiken het dagelijks om te communiceren over oplossingen of om het werk van elkaar te controleren. Tijdens de implementatie fase wordt code gecreëerd door algoritmes en klassen uit te werken in de syntax van een programmeertaal. Gedurende de integration & deployment fase wordt code gebruikt om verschillende componenten van de software op elkaar af te stemmen en om fouten uit de syntax te verwijderen die tijdens verschillende testen zijn ontdekt. In de operation & maintenance fase wordt de code gebruikt tijdens het onderhoud van de software.

GUI-specificatie

Als laatste representatiewijze: een specificatie van de Grafische User Interface (GUI). Een GUI is een soort gebruikersinterface dat met behulp van labels, tekst, grafische en visuele componenten, informatie en mogelijke acties weergeeft aan de gebruiker. De gebruiker kan door manipulatie van de zichtbare elementen acties uitvoeren waardoor de informatie en/of de grafische interface verandert.

Representatie van software door middel van de specificatie van de GUI kan erg verhelderend werken omdat de grafische weergave van de software inspeelt op de verbeelding van de gebruiker. GUI`s worden vaak in de requirements analysis fase gebruikt als prototypes om de toekomstige gebruikers te laten zien hoe bepaalde oplossingen geïmplementeerd kunnen worden.

De GUI als grafische representatie van de software is in elke fase van de levenscyclus het middel bij uitstek om de toekomstige gebruikers en klanten te laten zien hoe de software eruit ziet en hoe de sofware werkt. Naast de functie als communicatiemiddel naar stakeholders wordt de GUI gebruikt om de specificaties van de grafische interface van de software vast te leggen.

Er bestaan ontwikkelingsmethoden waarbij de GUI als uitgangspunt geldt voor het ontwerpen van de software. Dergelijke methoden zijn bekend onder de naam ‘visual programming’, en bieden de mogelijkheid om applicaties te ontwikkelen door het samenstellen van software aan de hand van herbruikbare interface objecten [Sommerville 2004].

3.5.2 Architectuur

Zoals in paragraaf 3.3.2 ‘System design’ al kort behandeld is, wordt in het architectural design de structuur van de software vastgelegd. In deze paragraaf wordt nog iets dieper ingegaan op het begrip software architectuur. Shaw en Garlan definiëren het als volgt:

“Software Architectuur omvat de beschrijving van elementen waarmee systemen zijn

gebouwd, interacties tussen deze elementen, patronen die hun compositie ondersteunen, en