Naar een valide objectmodel Frank Peeters september 2011 Aanleiding Er is wetenschappelijk aangetoond dat gedurende het ontwikkelen van software het in een vroeg stadium opsporen van fouten de kwaliteit van de software zeer ten goede komt en sterk kostenbesparend werkt. Onderzoek naar methoden, technieken en tools op dit terrein heeft al decennialang de aandacht. Het langdurig onderzoeksprogramma van EQuA 1 (Early Quality Assurance in Software Production) sluit hierop aan en richt zich op uitwisseling van wetenschappelijk toegepaste kennis op het vlak van vroegtijdige foutdetectie en herstel. Eén van de vijf EQuA- deelprojecten begeeft zich op het terrein van validatie van requirements en modellen. Vrij spoedig na de start van dit deelproject werd duidelijk dat één van de meest centrale modellen, die van het objectmodel is. Hierbij rijzen allereerst twee vragen: Wat is een objectmodel? Hoe kunt u ervoor zorgen dat ook een objectmodel valide blijft? Objectmodel Een model is een vereenvoudigde voorstelling, beschrijving of nabootsing van een deel van de werkelijkheid. Bij een objectmodel richten we ons op het vastleggen van de objecten uit de relevante werkelijkheid voor de betreffende software. Het relevante deel van de werkelijkheid noemen we het domein. Gedurende het ontwerp van een objectmodel zullen een aantal vragen moeten worden beantwoord. Zoals: welke objecten zijn er binnen het domein relevant, wat zijn hun eigenschappen, welke relaties met andere objecten onderhouden ze, aan welke constraints moeten ze voldoen, welke opdrachten kunt u ze geven en hoe wordt een object tot leven gebracht? Het objectmodel, dat wij voor ogen hebben, bevat daarom in ieder geval de volgende informatie: een verzameling met objecttypen, alle onderlinge relaties tussen objecttypen of relaties met primitieve gegevens (getallen, tekst, karakters en boolean waarden), de beperkingen die er voor deze relaties gelden, overerfrelaties tussen objecttypen en constructoren en operaties per objecttype. De in het objectmodel opgenomen objecttypen refereren allemaal op de een of andere manier naar objecten uit de relevante werkelijkheid. Het zijn concepten 1 Early Quality Assurance in Software production een programmavoorstel in het kader van RAAK- PRO Hogeschool van Amsterdam, december 2009. pag 1
uit deze werkelijkheid. Het objectmodel mag daarom ook een conceptueel objectmodel mogen worden genoemd. Een objectmodel kunt u in de vorm van een UML klassendiagram visualiseren. Deze visualisatie wordt in sommige kringen met een conceptueel klassendiagram aangeduid. Men bestempelt zo n conceptueel klassendiagram soms kortweg met het conceptuele ontwerp of het domeinmodel. Het conceptuele ontwerp, het domeinmodel en het (conceptuele) objectmodel zijn binnen deze tekst elkaars synoniemen. In het vervolg zullen we ons vooral van de laatste term bedienen. Validiteit Bij validatie van een model denkt men aan de vraag: of het model voldoet aan wat de klant wil. Een klant kan evenwel doorgaans niet beoordelen of een objectmodel valide is. Daarvoor is dat model te technisch. Een klant is immers normaliter geen software engineer. Bij user requirements ligt dat anders. Die zijn, zeker in het allereerste stadium van requirements engineering, in natuurlijke taal omschreven. Dat biedt de mogelijkheid om requirements aan de diverse soorten van stakeholders voor te leggen en te laten valideren. Na een grondige validatieslag heeft men echter nog geen absolute zekerheid of de requirements compleet, eenduidig en haalbaar zijn. Daarom noemen we de verzamelde requirements tesamen een requirementsmodel. Het is een model van de werkelijke behoefte. In deze tijd van iteratieve en agile software- ontwikkeling hoeft deze onvolkomenheid geen al te groot probleem te zijn. De kortcyclische werkwijze zorgt voor een snelle feedback en biedt dus de kans om de requirements bijtijds bij te stellen, waardoor deze waarschijnlijk dichter in de buurt van werkelijke behoefte komen te liggen, of anders gezegd: meer valide worden. Ook al weet men niet met 100% zekerheid dat het requirementsmodel (voldoende) valide is, toch willen we de validiteit van het objectmodel optimaliseren. Deze ambitie wordt gerealiseerd doordat elk afzonderlijk onderdeel uit het objectmodel direct of indirect in een of meer onderdelen uit het requirementsmodel is verankerd. Veranderingen (lees: verbeteringen) in het requirementsmodel moeten dan wel tot veranderingen in het objectmodel leiden. Hoe dat precies in zijn werk gaat, wordt verderop duidelijk gemaakt. De validiteit van het objectmodel wordt dan bepaald door de validiteit van het requirementsmodel. Als de validiteit van het requirementsmodel goed is, zal die van het objectmodel ook goed zijn. De validiteit van een objectmodel is dan een maat voor de afstemming op de requirements. Hoe beter het objectmodel de kansen biedt om de requirements te realiseren hoe hoger de validiteit. Hiermee hebben overigens nog niet alle kwaliteitsaspecten van een objectmodel voldoende aandacht gekregen. U kunt hierbij denken aan de beloften die er in de jaren 80 bij de opkomst van het objectgeoriënteerde paradigma zijn gedaan zoals: a) klassen bieden de mogelijkheid tot herbruikbaarheid, b) objectgeoriënteerde software is gemakkelijker uit te breiden en c) de objectgeoriënteerde software is eenvoudiger te onderhouden. Deze beloften pag 2
worden in de praktijk vaak niet waargemaakt omdat er in de ontwerpfase wordt gezondigd tegen algemeen geaccepteerde ontwerppatronen 2. Requirements De koninklijke weg voor een kwalitatief hoogwaardige software- ontwikkeling begint eigenlijk bij een businessstudie, waarin onder meer tekortkomingen, kansen, uitdagingen, risico s en doelen in kaart zijn gebracht. Uiteindelijk zal dit tot een inventarisatie van bedrijfsrequirements leiden. Deze inventarisatie is vanuit het bedrijfsperspectief beschreven. Hierna volgt het opstellen van een user requirements specification (URS). De bedrijfsrequirements worden dan geconcretiseerd richting toekomstig gebruik van de te (her)ontwikkelen software. In een URS komt men normaliter de volgende bestanddelen tegen: 1. contextbeschrijving (domein, belanghebbenden, infrastructuur etc.); 2. terminologie; 3. opsomming van handelingen die met behulp van de nieuwe software uitvoerbaar moeten gaan worden; 4. opsomming van relevante informatie, die ten grondslag ligt aan de uit te voeren handelingen (zie 3); 5. opsomming van constraints en andere bedrijfsregels waaraan de nieuwe software gebonden is; 6. opsomming van kwaliteitsattributen met betrekking tot bovenstaande geboden functionaliteit (hoe snel, hoe veilig, hoe betrouwbaar, hoe gebruiksvriendelijk e.d.). De onder punt 3 vermelde handelingen zijn pas in redelijk globale termen beschreven. Deze handelingen zullen met meer detail moeten worden uitgewerkt. Use cases zijn tegenwoordig algemeen geaccepteerd als het gaat om het, met voldoende detail en in natuurlijke taal, vastleggen van de interactie tussen de toekomstige gebruikers met het te bouwen systeem. Zo ontstaat er een bundel use cases die in een valideerbaar use- casemodel wordt ondergebracht. Het URS (=Requirementsmodel) in combinatie met het use- casemodel vormt een prima basis om de brug naar een gedegen objectmodel te slaan. De status quo van het onderzoek In het eerste acht maanden van het onderhavige EquA- deelonderzoek zijn er doelen, ambities en ook toekomstmuziek geformuleerd: 1. Constructie van een objectmodel vanuit requirements (automatisering van de constructie waar mogelijk); 2. Het verfijnen van het objectmodel door middel van het aanbrengen van constraints, zodat visualisatie in de vorm van een klassendiagram mogelijk wordt; 3. Visualisatie van het objectmodel in de vorm van een objectroldiagram (ORD) en een klassendiagram; 2 Zie: Robert C. Martin. Agile Software Development, Principles, Patterns, and Practices. 2002 pag 3
4. Modelelementen zijn zodanig gedocumenteerd dat alle bronnen traceerbaar zijn; 5. Transformatie van een objectmodel gestuurd door meta- regels en expertise op het vlak van software- design; 6. Synchronisatie van direct afhankelijke modelelementen zodra een bron wijzigt; 7. Verfijning van het objectmodel op basis van scenario- analyse; 8. Automatische generatie van testscripts op basis van scenario s en verzamelde representatieve en kritieke feiten; 9. Genereren van programmacode behorende bij alle klassen uit het conceptuele klassendiagram. In deze eerste fase van het onderzoek zijn de eerste en tweede stap inmiddels tot in een redelijk volwassen stadium gevorderd. De komende maanden wordt er de nodige progressie op het terrein van visualiseren van het objectmodel verwacht 3. De vierde, vijfde en zesde stap rondom traceability worden langzamerhand voorbereid en in gang gezet. De zevende stap wordt in het kader van het afronden van een masterstudie aan de TU/e onderzocht. De achtste en negende stap staat vooralsnog alleen op de rol, zonder dat er op dit moment een duidelijk tijdspad en, laat staan, milestones zijn voorzien. 3 De GUI wordt dit najaar, m.b.v. een usability- analyse door een team van Fontys- studenten nader onder de loep genomen. pag 4
De grote lijn In fig 1 staat schematisch de gepropageerde werkwijze beschreven. Niet alles uit dit schema zal misschien meteen duidelijk zijn. De getoonde tussenresultaten (in de vorm van rechthoeken) en de stappen er naartoe (in de vorm van pijlen) worden aan de hand van een voorbeeldcasus besproken. changing requirements Req. model refinement fact decomposition glossary adjustment Use Case model behavioral refinement scenario s Object model facts Testmodel adjustment constraints etc show adjustment behavior Object diagram Class diagram external input manually comp. controlled contws generated restricted to the domainobjects Figuur 1: de grote lijn De casus speelt zich bij de Nederlandse voetbalbond, de K.N.V.B., af. Deze bond moet allerlei competities organiseren. Te denken valt aan de eredivisie, de eerste divisie, regionale competities en de beker. De competities met wedstrijden ondergaan wijzigingen die door diverse betrokkenen worden gevolgd of gevoed. De grote lijn schrijft voor dat je met het verzamelen van alle requirements begint (zie linksboven in fig 1). Voor het K.N.V.B.- domein wordt eerst een klein deel van het URS getoond. Daarna wordt gedemonstreerd hoe uit deze requirements een objectmodel wordt geconstrueerd. De andere onderdelen uit fig 1 krijgen verderop hun aandacht. pag 5
Het voorbeelddomein In tabel 1 kunt u de vier soorten van requirements terugvinden. Te beginnen met een opsomming van de beoogde functies voor het K.N.V.B.- systeem, weliswaar in globale termen. User Requirements Specification Terminologie Context Beschrijving KNVB Stakeholders Competitieleiders, teamsecretarissen, journalisten, voetballiefhebbers A. Functies Funct1: competieleiders kunnen een competitierooster inrichten Funct2: wedstrijden moeten kunnen worden verplaatst Funct3: voetballiefhebbers kunnen de eigenschappen van een wedstrijd via het internet inzien. B. Feiten Fact1: VVV Ajax uit ronde 6 van de eredivisie van seizoen 2011 is in 2-2 geëindigd. Fact2: Bij de wedstrijd van Heracles tegen Feyenoord uit ronde 6 van de eredivisie van seizoen 2011 waren 13450 toeschouwers aanwezig. Fact3: Heracles Feyenoord uit ronde 4 van de eredivisie van seizoen 2011 is op 7 september om 14.30 uur gepland. Fact4: Ronde 1 van de KNVB- beker van seizoen 2010 staat standaard voor 1 september gepland. Fact5: In de 14 e minuut van de wedstrijd PSV- Roda JC uit ronde 7 van de erdivisie van seizoen 2011 is er voor de thuisspelende ploeg een doelpunt gevallen. Fact6: Het doelpunt in de 14 e minuut van de wedstrijd PSV- Roda JC uit ronde 7 van de eredivisie van seizoen 2011 is door Olav Toivonen gemaakt. C. Beperkingen Constr1 : tussen twee opeenvolgende wedstrijden van een team zitten ten minste twee wedstrijdloze dagen. Constr2 : de (tussen)uitslag van een wedstrijd kan pas bekend zijn als de wedstrijd is begonnen. D. Kwaliteitsattributen QA1 : [performance] gemelde wijzigingen in de uitslagen van de wedstrijden worden binnen één minuut verwerkt. QA2 : [schaalbaarheid] wedstrijdhistorie over alle knvb- competities ligt over 30 seizoenen terug publiekelijk ter inzage. Tabel 1: een URS voor het voorbeelddomein Na de opsomming van de functies volgt de relevante informatie. Er wordt aldaar gepoogd om uit het gestelde domein voor elk soort van informatie een of meer representatieve feiten op te sommen. Er is onder meer voor dit concrete niveau gekozen omdat er dan nóg gemakkelijker kan worden geconterd of de vereiste informatie correct is geformuleerd. Elk fact- requirement staat op zich; het is uitdrukkelijk de bedoeling dat zo n requirement onafhankelijk van de andere fact- requirements kan worden geïnterpreteerd. Ook een punt van aandacht is dat aanduidingen van objecten uit het domein eenduidig zijn 4. Deze 4 Zie ook: Elton Manoku, Jan Pieter Zwart, Guido Bakema. A fact approach to automatic application development. 2006 pag 6
strikte eisen komen zo meteen van pas zodra het objectmodel wordt geconstrueerd. Deze constructie start dan met een analyse van de voornoemde feiten. De constraint- requirements vormen de derde categorie aan requirements. Dat kunnen statische of dynamische constraints. Constr1 is een voorbeeld van een statische constraint. Een statische constraint beperkt de toestandsruimte van alle objecten op enig moment. De dynamische constraints beperken de toestandsovergang. Constr2 is daar een voorbeeld van. De kwaliteitsattributen sluiten de rij der requirements af. Zij stellen kwaliteitseisen aan de andere requirements. Kwesties als veiligheid, gebruiksgemak, betrouwbaarheid en dergelijke worden aldaar vastgelegd. Deze attributen worden vaak ook als de niet- functionele requirements aangeduid. Decompositie van een feit Met de hulp van factrequirements worden de bestanddelen in het objectmodel aangewezen. Elk feit representeert een verwoording van een realistische relatie uit het gestelde domein. We nemen de analyse van fact1 als startpunt: VVV Ajax uit ronde 6 van de eredivisie van seizoen 2011 is in 2-2 geëindigd. Dit feit beschrijft een uitslag van een wedstrijd, ofwel het beschrijft de relatie tussen een wedstrijd en een uitslag. Voor de identificatie van een wedstrijd zijn er drie gegevens nodig: het thuisspelende team, het uitspelende team en de ronde waar deze wedstrijd bij hoort. Er vindt een stapsgewijze decompositie in de structuur van dit feit plaats. In fig 2 krijgt u enigszins een beeld hoe deze decompositie met behulp van de EQuA- objectmodeler in zijn werk gaat. De variabele onderdelen van het feit worden getypeerd (bijv. Team) en krijgen zo mogelijk een rolnaam (bijv. uitteam) toegewezen. De constante onderdelen reigen de variabele onderdelen als het ware aan elkaar. Na afloop van deze stapsgewijze verfijning kan het oorspronkelijke feit weer worden teruggenereerd 5. 5 De werkwijze bij feitdecompositie is in detail beschreven in: Frank Peeters, Frens Vonken. Objectgeoriënteerde domeinanalyse. Academic Service, 2001. pag 7
Figuur 2: decompositie van een feit Nadat de decompositie van fact1 is voltooid, zijn er inmiddels zeven nieuwe typen aan het objectmodel toegevoegd. Deze ziet u bovenaan in weergegeven. Merk op dat al deze typen met elkaar zijn gerelateerd; er bestaan geen solitaire typen. De werkwijze van het analyseren van feitelijke relaties komt de samenhang in het resulterende objectmodel vanaf het het allereerste begin tot aan het einde van de constructie ten goede. Figuur 3: de inmiddels gedecteerde typen Een object van een objecttype kan een rol bij een ander feit of object spelen. Een feit, dat geen object is, beschikt niet over die capaciteit. Daarom noemen we pag 8
UitslagWedstrijd een (puur) feittype. De andere zes typen uit figuur 3 zijn allemaal objecttypen 6. In fig 4 zijn de drie rollen met de bijbehorende restricties voor het geselecteerd objecttype Wedstrijd getoond. Restricties kunnen hier, weliswaar op een nogal een primitieve wijze, worden aangepast 7. Voor de vermelde feit- en objecttypen zijn de volgende restricties toegevoegd: Bij Wedstrijd zijn er twee uniciteitsconstraints over de eerste en derde rol (u7) en over de tweede en derde rol (u8) aangebracht, immers per ronde zal een team slechts één wedstrijd spelen; bij UitslagWedstrijd is aan de eerste rol een uniciteitsconstraint toegevoegd (een wedstrijd kent maar één uitslag) en is de navigatie vanuit de tweede rol vanuit Uitslag verbroken (een uitslag- object hoeft niet te weten bij welke wedstrijduitslag hij betrokken is); bij Wedstrijd is de Ronde- rol als parent- rol aangemerkt; bij Ronde worden de Wedstrijd- objecten beheerd. Dit zijn de enige aanpassingen die er voor de zeven typen hebben plaatsgevonden. Nu kan er standaardgedrag voor elk objecttype (=class) worden gegenereerd. Bij standaardgedrag denken we aan een constructor, getters en setters, zoekmethoden, methoden om objectlinks toe te voegen en te verwijderen en meer van zulks. Als voorbeeld is er aan de rechterzijde in de figuren 4 en 5 het automatisch gegenereerde standaardgedrag van achtereenvolgens de klassen Wedstrijd en Ronde af te lezen. De zes operaties (1 constructor, 4 properties met getters en/of setters en 1 methode) van Wedstrijd zullen waarschijnlijk nauwelijks een verrassing zijn. Voor Ronde zijn de tien gegenereerde operaties toch al een stuk minder triviaal (zie rechterzijde in fig 5). Dankzij deze automatiseringsslag wordt er de nodige ontwerptijd bespaard en wellicht belangrijker: de kwaliteit van het objectmodel verhoogd. 6 Harm van der Lek, Guido Bakema, Jan Piet Zwart. De Unificatie van Objecttypen en Feittypen. 1992 7 Ter zijde: de GUI wordt dit najaar, m.b.v. een usability- analyse door een team van Fontys- studenten nader onder de loep genomen en, naar het zich laat aanzien, ingrijpend verbeterd. pag 9
Figuur 4: automatisch gegenereerd standaardgedrag voor het objecttype Wedstrijd Figuur 5: automatisch gegenereerd standaardgedrag voor het objecttype Ronde pag 10
Het objectmodel visualiseren Het objectmodel bevat een collectie object- en feittypen met bijbehorende constraints. Ook zijn in het objectmodel alle ingevoerde feiten en objecten terug te vinden. Zojuist is gedemonsteerd hoe u standaardgedrag van een klasse kunt genereren. Het standaardgedrag is voor de volle 100% berekenbaar uit het objectmodel 8. Ter wille van het overzicht is het gewenst om delen van een objectmodel in de vorm van een diagram te visualiseren. Er zijn twee manieren om een objectmodel te visualiseren: Class Diagram (CD) Object Role Diagram (ORD) Het klassendiagram voldoet aan de UML- specificaties. Aspecten als attributen, associaties, multipliciteit, rolnamen, overerving en operaties kunnen zichtbaar worden gemaakt. Bij het aanmaken van een klassendiagram moet de toolgebruiker aangeven welke objecttypen er in het nieuwe klassendiagram moeten worden opgenomen. Daarna kan er worden aangegeven waar elke klasse wordt gepositioneerd. De zojuist opgesomde aspecten worden vervolgens in het klassendiagram getoond. Dat gebeurt allemaal zoals men dat in een UML- tool is gewend, zie figuur 6 9. In dit figuur zijn de operaties even buiten beeld gebleven. Uiteraard kan men ook het gegenereerde gedrag in het klassendiagram zichtbaar maken. Dit gedrag komt exact overeen met datgene er in de voorgaande figuren is getoond. Dus wat dat betreft, is er niets nieuws onder de zon. Traceability Met klem wijzen we op het feit dat niet het klassendiagram het ontwerp bevat, maar dat het klassendiagram volledig aan het onderliggende objectmodel is ontleend. Het klassendiagram is niet meer dan een grafische view gebaseerd op informatie ontleend aan het objectmodel. Het beschreven objectmodel met zes objecttypen is op zijn beurt uit één enkel feit geconstrueerd. We brengen dit feit nogmaals onder uw aandacht: VVV Ajax uit ronde 6 van de eredivisie van seizoen 2011 is in 2-2 geeindigd. Op grond van dit enkele feit en het toevoegen van welgeteld vier extra constraints, is er een klassendiagram met zes klassen met eigenschappen en zesënveertig standaardoperaties ontstaan. Het vermelde feit is een bestanddeel uit het URS. In het objectmodel is deze relatie met dit requirement terug te vinden. Mocht er in de toekomst iets aan dit requirement fact1 worden gewijzigd dan zal er dankzij het metamodel nauwkeurig worden aangegeven 8 Ook het automatisch genereren van de bijbehorende programmacode (headers met complete bodies) lijkt geen al te groot probleem te zijn. 9 Dit klassendiagram is met behulp van Visual Paradigm Professional Edition opgesteld. Binnenkort biedt de Equa- objectmodeler een vergelijkbare functionaliteit, waarbij klassen aan het onderliggende objectmodel worden ontleend. pag 11
welke onderdelen uit het objectmodel speciale aandacht vergen. Deze traceability wordt consequent voor elk modelelement doorgevoerd. Figuur 6: het klassendiagram gebaseerd op de decompositie van fact1 Er bestaan binnen het metamodel geen modelelementen die niet aan ten minste één bron hun bestaansgrond ontlenen. Bij modelelementen is men vrij om verder te kijken dan onderdelen uit het objectmodel (objecttypen, feittypen, overerfrelaties, operaties). Ook use cases, scenario s en test cases vallen hieronder. Het objectroldiagram Naast het klassendiagram kunnen er ook zogenaamde objectroldiagrammen worden gegenereerd. Het ORD biedt de mogelijkheid om het objectmodel verder te configureren. Naast het verwerken van de constraints uit het URS krijgt de ontwerper de kans om andere aspecten te verfijnen en ingewikkelde relaties verder te modelleren. We verwijzen u naar bijlage 1 om een betere indruk te krijgen hoe een objectroldiagram eruit zal gaan zien. Name TypeExpression Het tool biedt de mogelijkheid om meta- regels te laten checken en te zijner tijd aanbevolen modeltransformaties te laten uitvoeren. Overigens alleen als het objectmodel door deze metacheck heen is gekomen, kunnen er pag 12
klassendiagrammen worden gegenereerd. Als het objectmodel niet in voldoende mate is uitgewerkt of het bevat zekere tegenstrijdigheden kan er geen klassendiagram worden getoond. Wel is het mogelijk om klassendiagrammen te genereren op basis van een onvolledige verzameling van verwerkte fact- requirements. Aan het tonen van ORD s is daarentegen geen beperking verbonden. Zij kunnen ook worden getoond als het objectmodel nog niet in een, voor het metamodel, acceptabele toestand is terechtgekomen. Het ORD is daarom een uitgelezen medium om het onderliggende objectmodel verder te configureren. Use cases Aan het begin van deze notitie is in fig 1 op schematische wijze de grote lijn van de gepropageerde werkwijze weergegeven. In dit schema is ook het usecasemodel (UCM) opgenomen. Er volgt nu een korte toelichting op de rol van dit model. Use cases behoren een gedetailleerder beeld op de beschreven functionaliteit in URS te geven 10. Aldaar zijn function- requirements beschreven. Deze globale beschrijvingen verdienen een detailuitwerking zodat de mogelijke mismatch tussen behoefte vanuit de klant en realisatie door de softwareontwikkelaars verder kan worden verkleind. Use Case 1 Verfijning van : func2 Status : goedgekeurd Naam : wedstrijd verplaatsen Actor: competitieleider Pre: er is een niet- gespeelde wedstrijd gepland Normal flow: 1. Actor kiest te verplaatsen wedstrijd 2. Actor vraagt aan systeem om agenda met geplande wedstrijddatums van betrokken teams 3. Actor stelt nieuwe toekomstige datum voor wedstrijd vast 4. Systeem voert wijziging van datum voor wedstrijd uit. 5. Systeem alerteert betrokken teams. Post: datum van wedstrijd is verplaatst Alternate flow: 3. Er is geen ruimte in de twee agenda s van de twee betrokken teams 1. Actor gaat eerst een of meer andere wedstrijden verplaatsen 2. Stap 1 van normal flow Figuur 7: de use case uitwerking behorende bij funct2 uit het URS In fig 7 is het functie- requirement funct2 van het URS in de vorm van een use case uitgewerkt. De use case is een prima intermediair tussen klant en requirement engineer. Voor de requirement engineer ontstaat hier bovendien een extra kans om de requirements uit het URS aan te scherpen of uit te breiden. De use case vormt een interface tussen klant en systeemontwerper. De ene zijde van de interface tussen klant en use case is zojuist aangestipt. Nu de andere kant: 10 In SysUML (zie www.sysml.org) wordt uitgebreid aandacht gegeven aan de traceability van modellen. Daarin wordt aangegeven hoe de koppeling tussen onder meer requirements, use cases en test cases etc kan worden gerealiseerd. pag 13
welke kansen biedt een use case met het oog op het conceptuele ontwerp? De systeemontwerper zal zich een beeld willen vormen van de scenario s die bij een use case horen. In een standaard use case wordt het systeem als een black box beschouwd. De systeemontwerper zal echter bij zijn analyse naar een white box voorstelling van het systeem overstappen. In deze ontwerpfase wordt het systeem door de bril van een conceptueel klassendiagram, of zo u wilt objectmodel, bezien. Zodra de systeemontwerper aan zijn scenario- analyse begint is dat klassendiagram reeds voor het overgrote deel ingevuld met klassen, associaties, attributen, overerfrelaties en operaties. De systeemontwerper zal de stappen uit een scenario met behulp van de instrumenten in het klassendiagram in kaart proberen te brengen. Tegenstrijdigheden en onvolkomenheden in het klassendiagram kunnen op deze wijze worden rechtgezet. Deze aanpassingen resulteren in wijzigingen van het onderliggende objectmodel. Normaliter beperken deze wijzigingen zich tot verfijning van het gedrag van een of meer objecttypen. Wijzigingen in eigenschappen van een objecttype zouden daarentegen eigenlijk via het pad van wijzigen van (fact- )requirements behoren te verlopen. In geval van gewijzigde fact- requirements, zal er een hernieuwde decompositie van de gewijzigde feiten plaatsvinden, waardoor het objectmodel vanuit de URS een wijziging ondergaat. Testen Interessant is te vermelden dat het automatisch genereren van testcases geen probleem hoeft te zijn zodra ook de normal en alternate flow scenario s zijn vastgelegd. De combinatie van de geanalyseerde feiten en de scenario s biedt immers een uitgelezen kans om een complete set met testscripts te genereren. De feiten uit het URS moeten dan wel met het oog van een test engineer zijn samengesteld. Behalve dat ze representatief zijn, horen de requirements ook de grensgevallen mee te nemen. Nawoord In deze uiteenzetting is een pleidooi gehouden voor een werkwijze waarin er vanuit requirements stapsgewijs een conceptueel klassendiagram wordt geconstrueerd. De werkwijze is voorbereid op de zich onherroepelijk wijzigende requirements. Hoe blijft met zo n dynamische input het ontwerp consistent. Er is aangegeven dat een groot deel van het klassendiagram geautomatiseerd is ingevuld. Deze automatiseringsslag biedt naast tijdwinst een verhoging van de kwaliteit van het conceptuele klassendiagram. Dankzij de beschreven automatisering van het creëren van standaardgedrag lijkt het genereren van bijbehorende programmacode en testscripts geen onoplosbare problemen op te leveren. Dat klinkt allemaal veelbelovend. Eigenlijk te mooi om waar te zijn. We moeten echter met een relativering eindigen. De kwaliteit van een objectmodel wordt voor een substantieel deel bepaald door de kwaliteit van de systeemontwerper die onder meer de decompositie van de feiten uitvoert. Een goede scholing en voldoende ervaring vormen een noodzakelijke voorwaarde. Men moet in voldoende mate zicht hebben op bad smells in de decompositie en de rest van het ontwerp. Met zo n scholing ontstaat er wel een ambacht dat op gestructureerde wijze kan worden aangeleerd en onderwezen. Een pag 14
systeemontwerper hoeft dan gelukkig minder terug te vallen op de gezond verstand werkwijze. Leerboeken over objectgeoriënteerd ontwerpen hoeven zich dan niet meer te bedienen van heuristieken die hun domeinanalyse starten met het inventariseren van zelfstandige naamwoorden, waarna er meestal een nogal moeizaam proces ontstaat naar een conceptueel klassendiagram, waarbij het lang duurt voordat men er een goed gevoel bij heeft. In hun boek over objectgeoriënteerde technologie 11 vermelden de schrijvers: Helaas bestaat er geen eenvoudige of eenduidige manier om een verzameling klassen voor een probleemdomein te identificeren. De kwaliteit van de domeinanalyse is sterk afhankelijk van de kennis, intuïtie, ervaring en vaardigheden van de ontwerper van het probleemdomein. Hopelijk gaat de in deze notitie gepropageerde werkwijze in deze leemte voorzien. 11 Zie paragraaf 2.6.4 in: Curtis H.K. Tsang, Clarence S.W. Lau, Ying K.Leung. Objectgeoriënteerde Technologie, Van diagram naar code met Visual Paradigm for UML. Academic Service, 2006. pag 15
Bijlage 1: prototype of an object diagram Name FactType TypeExpression Supertype Name TypeExpression ObjectType Subtype TypeExpression constraints name type constraints name Role contains 2 or 3 departments constraints name ObjectTypey pe Role connector always ending at outside boundary of rounded box of objecttype. If name unknown, number should be shown. If type of is a basetype, connector is never shown. Width of departments depends on length of containing text? Roles and type expression may be hided. TypeExpression is filled with the object type expression, unless unknown, in that case the fact type expression should be shown. pag 16