Home · Fasen · Rollen · Producten · Best practices · Referenties · Nieuws & release notes · Begrippen

Smart
Verklarende begrippenlijst

Actor

De actor is de rol die een gebruiker heeft ten opzichte van de te ontwikkelen applicatie. Deze actor fungeert als startpunt voor het beschrijven van de bedrijfsprocessen.

Agile manifesto

Uit onvrede met de lineaire systeemontwikkelmethoden schrijft een groep industrie-experts begin 2001 het agile manifesto. Dit manifest beschrijft kenmerken van een nieuwe generatie systeemontwikkelmethoden, waaronder extreme programming, DSDM en Smart. Het inspirerende manifest beschrijft de volgende principes.

Individuals and interactions over processes and tools. Projecten draaien om mensen. De projectomgeving wordt zo ingericht dat projectmedewerkers optimaal functioneren, in een acceptabel tempo.

Working software over comprehensive documentation. Het opleveren van de software is de driver van projecten. Alhoewel documenteren van belang blijft, is dit ondergeschikt aan het opleveren van het systeem. Face-to-face communicatie is nu eenmaal effectiever dan het over de muur gooien van mijlpaalproducten.

Customer collaboration over contract negotiation. In projecten wordt de hoogste prioriteit gegeven aan het tijdig en frequent opleveren van voor de klant waardevolle software, dit in korte iteraties. Samenwerking tussen klant en ontwikkelaars is essentieel.

Responding to change over following a plan. Last but not least, agile methoden faciliteren het omgaan met veranderingen en proberen niet deze planmatig te dwarsbomen.

Alternate course (use case)

Een use case kent in het algemeen een aantal scenario's. Eén daarvan is het gewenste scenario. In de stappen van dit scenario wordt de "normale" gang van zaken beschreven.

Afwijkingen van dit gewenste scenario kunnen leiden tot ofwel faalscenario's waar de doelen van de use case, gedefinieerd in de postcondities van de use cases worden niet bereikt. Ook kunnen ze leiden tot herstelscenario's, waarbij de doelen eveneens niet bereikt lijken te worden, maar door een aanvullende acties alsnog worden gehaald.

Deze scenario's worden gemodelleerd in de alternate courses van de use case. Hierin worden - voor ieder afwijkend scenario - slechts de afwijkende stappen ten opzichte van het stappenplan van het gewenste scenario beschreven. Stappen die hetzelfde zijn als in het stappenplan van het gewenste scenario worden altijd weggelaten.

Application services

In de applicatiearchitectuur van Smart spelen de application services een belangrijke rol. De application services zijn verantwoordelijk voor het implementeren van de applicatiespecifieke bedrijfslogica. Alle verzoeken die vanuit de user interface (via de tasks) worden gedaan, worden afgehandeld door de application services.

In een omgeving waar component based development een grote rol speelt fungeren de application services bovendien als doorgeefluik en facade naar de interfaces van de componenten.

Bedrijfsproces

Het bedrijfsproces is het werkproces van de gebruikers van de nieuwe applicatie. Het bedrijfsproces staat altijd centraal in een Smart project.

Business class

Een business class is een klasse die een deel van de bedrijfslogica van het domein bevat. De business class vertegenwoordigt in het algemeen een "ding" of concept uit het dagelijks leven van de gebruikersvertegenwoordigers, zoals klant, hypotheek of contract.

Alle business classes zijn onderdeel van de application services.

Component

Een component is een zelfstandige verzameling bij elkaar horende functionaliteit. Een component implementeert één of meerdere interfaces. Iedere interface levert één of meerdere services.

Domein

Een domein bestaat uit een verzameling aan elkaar gerelateerde services en applicaties die te maken heb met een deelgebied van de organisatie. Voorbeelden zijn domeinen als kredieten, hypotheken, leven, schade.

Een domein kan ook een algemener karakter hebben, zoals relaties of abonnementen.

In het algemeen zijn de domeinen van een organisatie gedefinieerd in de informatie- of in de bedrijfsarchitectuur.

DSDM

De methode Smart leunt voor een groot deel op de marktstandaard Dynamic Systems Development Method (DSDM). Dit iteratieve en incrementele raamwerk voor systeemontwikkeling is ontwikkeld door een consortium van bedrijven, waar ook Ordina actief deel van uit maakt. Smart biedt voor veel aspecten van DSDM een praktische invulling

Eindproduct

Eindproducten wordt opgeleverd aan het eind van het project. Dit in tegenstelling tot werkproducten, die dienen voor communicatie tijdens het project. Voorbeelden van eindproducten zijn de use case diagrammen, de testscenario's en de user interface diagrammen.

Extreme programming

Systeemontwikkelmethode die is ontwikkeld door Kent Beck. Extreme programming is evenals Smart een agile systeemontwikkelmethode en kent zeer interessante best practices zoals pair programming en test first design.

Facade task

Tasks zijn in de applicatiearchitectuur van Smart verantwoordelijk voor de afhandeling van het proces dat beschreven is in het stappenplan van een use case. Iedere task voert dit proces voor precies één use case uit. In die zin implementeert de task de use case.

Daarbij is de task onder andere verantwoordelijk voor de coordinatie van de afhandeling van verzoeken aan de application services, en voor het tonen van de informatie in de user interface. Daarbij maakt de task vaak gebruik van andere tasks (denk maar aan en ).

Probleem hierbij is dat de aan te roepen task niet altijd is gerealiseerd op het moment dat deze nodig is. Nu wordt een lege task geconstrueerd, zodat de aanroep normaal kan worden uitgevoerd. Deze lege task wordt in de applicatiearchitectuur van Smart een facade task genoemd. De enige functionaliteit die de facade task implementeert is het waar maken van de postcondities van de aan te roepen use case. De realisatie van de aanroepende use kan derhalve normaal plaatsvinden. De facade task wordt uiteindelijk vervangen door de werkelijke implementatie van de functionaliteit van de desbetreffende use case.

Zo zal een use case 'Onderhouden Medewerker' gebruik willen maken van de use case 'Selecteren Medewerker'. Voor deze laatste kan nu een facade task worden ontwikkeld die niets meer doet dan een van te voren bepaald ID van een medewerker retourneren.

Factory class

Omdat het in objectorientatie geen usance is om een instantie van een klasse verantwoordelijk te maken voor het benaderen van een tweede instantie van dezelfde klasse, wordt hiervoor vaak een factory class gebruikt. Dit probleem doet zich vooral voor bij business classes.

Een factory class is een klasse die verantwoordelijk is voor de toegang van individuele instanties van een klasse. Factory classes krijgen als naam de meervoudsvorm van de te benaderen klasse. Zo biedt de factory class Rekeningen toegang tot individuen van de business class Rekening. Vaak is de factory class zelf ook weer een business class, die hierarchisch gezien "een laag hoger" ligt dan de desbetreffende klasse. Als voorbeeld hiervoor geldt dat een Order iedere individuele Orderregel van deze Order kan benaderen.

Er zijn echter klassen die - aan de top van de hierarchie - niet automatisch een factory class hebben. Een nieuwe factory class wordt ook aangemaakt, als de instanties niet via de klasse die zich "een laag hoger" bevindt, benaderd kunnen worden. Bijvoorbeeld in het voorbeeld van Order en Orderregel, als er Orderregels van verschillende Orders moeten worden benaderd. Nu wordt toch een factory class Orderregels gecreeerd.

Form

De term form wordt in Smart gehanteerd om een willekeurige vorm van user interface aan te geven. Meestal is een form een webpagina of een scherm in een applicatie in Windows.

Integratie-testgeval

Een integratie-testscenario is een verzameling van (integratie-)testgevallen voor een use case model. Hierbij geldt dat iedere link in het bijbehorende user interface model wel of niet kan worden uitgevoerd, resulterend in een groot aantal testgevallen. In een integratie-testgeval wordt veelvuldig gebruik gemaakt van de reguliere individuele testgevallen.

Een integratie-testgeval bestaat derhalve uit een reeks van handelingen - het volgen van een link in het user interface model - gevolgd door het uitvoeren van een testgeval voor de aan te roepen use case.

Integratie-testscenario

Een integratie-testscenario is een verzameling van (integratie-)testgevallen behorend bij een use case model. Iedere link in het user interface model dat bij het use case model is opgesteld kan worden uitgevoerd. Dit leidt tot een groot aantal van deze testgevallen.

In een integratie-testgeval wordt veelvuldig gebruik gemaakt van de reguliere individuele testgevallen.

Interactiepatroon

Een interactiepatroon beschrijft een oplossing voor vaak voorkomende functionaliteit, meestal technisch van aard. Interactiepatronen worden bijvoorbeeld opgesteld voor het vastleggen van de wijze van het benaderen van data in de database, of voor het wegschrijven van data. Ook zijn er bij het ontwikkelen van webapplicaties vaak interactiepatronen voor het omgaan met state en caching.

Een interactiepatroon wordt meestal vormgegeven als een sequence diagram en wordt vastgelegd in de applicatiearchitectuur.

List (user interface diagram)

List is een term die wordt gebruikt bij het modelleren van de user interface. Een list is een verzameling van objecten van eenzelfde klasse die op een scherm of webpagina worden gerepresenteerd.

Model

Een model is een verzameling diagrammen (meestal in verschillende modelleertechnieken) die tezamen de status van een applicatie weergeven.

MoSCoW

Het acroniem MoSCoW identificeert een viertal regels voor het vaststellen van prioriteiten. Deze regels zijn vastgelegd in het handboek van DSDM.

De vier categorieën zijn must have, should have, could have en would have (but won't have this time around).

Opvallend bij het toepassen van MoSCoW is dat meestal zeer veel aspecten het label must have krijgen, vaak veel meer dan realiseerbaar. In dergelijke gevallen is een tweede procedure gebruikelijk, waarbij alle aspecten met dit label op volgorde van importantie wordt geplaatst. Zo kan alsnog een subselectie worden gemaakt uit alle must haves.

Object-Relational Mismatch

Het object paradigma is gebaseerd op bouwen van applicaties vanuit objecten met data en gedrag, dit terwijl het relationele paradigma is gebaseerd op opslaan van data. De “mismatch” komt naar voren zodra we kijken naar de gewenste wijze om data te benaderen: met het object paradigma in het hoofd springen we tussen objecten via hun onderlinge relaties, terwijl we middels het relationele paradigma in het achterhoofd de data dupliceren om de rijen in de tabellen te joinen. Dit fundamentele verschil resulteert in een non-ideale combinatie van de twee paradigma's. Maar ja, wanneer heb je wel ooit twee verschillende dingen in samenspraak gebruikt zonder dat er een aantal kleine mankementen waren? Een van de geheimen voor het succesvol mappen van objecten naar relationele databases is om beide paradigma's te begrijpen, hun verschillen te zien, en dan pragmatische tradeoffs te maken gebaseerd op die kennis en begrip.

OTOPOP

OTOPOP is een vuistregel die vooral wordt toegepast om de scope van use cases in te perken. Er geldt one time, one place, one person.

Package

Een package is een tekentechniek uit UML, die meestal wordt gebruikt om een logische service of component aan te duiden.

Een package in UML is niet hetzelfde als een package in Java, alhoewel de laatste vaak wordt gebruikt om de eerste in te implementeren.

Pair programming

Pair programming is een techniek waarbij twee ontwikkelaars samen aan een stuk code werken, met één beeldscherm en één computer. Alhoewel deze techniek op het eerste gezicht tamelijk inefficient lijkt te zijn, is het tegendeel waar.

Twee ontwikkelaars weten bijvoorbeeld meer dan één, en problemen lossen zich sneller op. Eenzelfde effect heeft pair programming op het brainstormen dat vaak vooraf gaat aan het daadwerkelijk coderen.

Tijdens het coderen worden fouten in code sneller ontdekt en hersteld met behulp van pair programming. Zeker bij complexe stukken code, als in de business classes, biedt de techniek de hierboven genoemde grote voordelen.

Parkeerpunt

Een parkeerpunt is een aspect, waarvan wordt onderkend dat het op een bepaalde moment in het project voor gaat komen, maar waarvan de precieze details nog onbekend zijn.

Er wordt nu besloten om het bestaan van het aspect te registreren, maar de werkelijk details nog niet uit te zoeken. Dit gebeurt op een later tijdstip, veelal tijdens volgende iteraties. Meestal is de kennis rond het aspect dan groter, door voortschrijdend inzicht, en kunnen de details makkelijker, correcter en sneller worden uitgezocht. Dit bespaart tijd en effort.

Een goed voorbeeld vormen validaties die moeten worden uitgevoerd als de gebruiker van de applicatie een veld op het scherm verlaat of een knop indrukt. Er is bekend dat de validaties moeten afgaan, maar het uitzoeken van de precieze werking van de validaties wordt geparkeerd.

Scenario (use case)

Een use case kent in het algemeen een aantal scenario's. Een scenario beschrijft een aantal stappen (in het stappenplan van het scenario), die moeten leiden tot het verwezenlijken van de doelen van de use case.

Eén van deze scenario's is het zogenaamde gewenste scenario. In de stappen van dit scenario wordt de "normale" gang van zaken binnen de use cases beschreven. Afwijkingen van dit gewenste scenario kunnen leiden tot faalscenario's waar de doelen van de use case, gedefinieerd in de postcondities van de use cases worden niet bereikt. Ook kunnen ze leiden tot herstelscenario's, waarbij de doelen eveneens niet bereikt lijken te worden, maar door een aanvullende actie alsnog worden gehaald.

Utility class

Een utility class is een realisatie van een verzameling diensten. Utility classes zijn er in twee categorieën: business classes en algemene services. Business classes verzorgen de business requirements. Algemene services zijn er in vele soorten. Een factory is een utility class.

Alle utility classes zijn onderdeel van de application services, zeg maar de middle-tier van de applicatiearchitectuur van Smart.

Service of component

Een service is een component dat bepaalde diensten kan verlenen aan applicaties die deze wensen te gebruiken. Deze diensten worden beschreven in de interface van de service.

Singleton (user interface diagram)

Singleton is een term die wordt gebruikt bij het modelleren van de user interface. Een singleton is een object dat op een scherm of webpagina wordt gerepresenteerd zonder dat er meerdere instanties van dezelfde klasse worden getoond.

Spike

In vrijwel ieder project wordt nieuwe technische functionaliteit gerealiseerd. Zeker wanneer dit een voor de organisatie relatief nieuwe ontwikkelomgeving en bijbehorende architectuur betreft. Om dergelijke nieuwe functionaliteit snel uit te kunnen proberen wordt een spike uitgevoerd.

Tijdens een spike worden de verschillende alternatieven voor realisatie van de nieuwe functionaliteit uitgeprobeerd en wordt advies uitgebracht over het te kiezen alternatief. Een spike wordt derhalve uitgevoerd met een zeer specifieke doelstelling, vaak een vraag, door een beperkte samenstelling van specialisten. Een spike kent een korte timebox, vaak enkele dagen tot een week, en dient niet om de daadwerkelijk oplossing ook volledig te implementeren. Dit gebeurt tijdens het project, op het moment dat de functionaliteit echt nodig is.

Een spike levert naast het gevraagde advies wel vaak de interactiepatronen op voor de geadviseerde oplossing en eventueel de aanzet van de benodigde utility classes.

Stakeholder

Een stakeholder is iemand die belang heeft bij het al dan niet slagen van het project. Alle verschillende typen stakeholders dienen vroeg in een project te worden geïdentificeerd, om zo de verschillende belangen te kunnen onderscheiden en te beheren.

Het succes van een project is voor een groot deel afhankelijk van de communicatie met de verschillende groepen stakeholders.

Stand-up meeting

Een stand-up meeting is een kortlopende dagelijks overleg waarin de status van de huidige iteratie wordt besproken. Een stand-up meeting duurt ongeveer 10 a 15 minuten, afhankelijk van de grootte van het projectteam en wordt gehouden bij de start van iedere werkdag.

Tijdens een stand-up meeting krijgt iedere medewerker uit het projectteam circa 45 seconden spreektijd. De eerste 15 seconden worden gebruikt om te vertellen waar de medewerker de dag ervoor aan heeft gewerkt. De volgende 15 seconden worden gebruikt om aan te geven waar de medewerker nu aan gaat werken, en tenslotte worden 15 seconden gebruikt om aan te geven waar de medewerker voor zijn taken ondersteuning nodig heeft.

Stappenplan (use case)

Het stappenplan van een use case beschrijft - genummerd - de acties die tezamen het scenario vormen van de uitvoering van de use case.

Task

Klassen van het type task zijn in de applicatiearchitectuur van Smart verantwoordelijk voor de afhandeling van het proces dat beschreven is in het stappenplan van een use case. Iedere task voert dit proces voor precies één use case uit. In die zin implementeert de task de use case.

Daarbij is de task onder andere verantwoordelijk voor de coordinatie van de afhandeling van verzoeken aan de application services, en voor het tonen van de informatie in de user interface.

Testactie

Een testgeval beschrijft de verschillende handelingen die worden uitgevoerd om de functionaliteit van een use case te verifiëren. Ieder testgeval bestaat uit een aantal testacties. Een testactie beschrijft de handeling die moet worden uitgevoerd. En beschrijft de daarbij behorende in te voeren attributen of de attributen die worden verwacht als uitvoer van het uitvoeren van de testactie.

Belangrijke beslismomenten in het stappenplan van een use case dienen in elk geval op basis van een testactie te zijn opgenomen in het testgeval.

Testgeval

Een testgeval beschrijft de verschillende handelingen - die testacties worden genoemd - die worden uitgevoerd om de functionaliteit van een use case te verifiëren. Ieder testgeval bestaat uit een aantal van deze testacties. De testacties van een testgeval zijn gebaseerd op het stappenplan van de use case, en komen nagenoeg overeen met de in het bijbehorende interactiemodel - het sequence diagram - vastgelegde proces. Bij iedere testactie is de handeling beschreven die moet worden uitgevoerd, en de daarbij behorende in te voeren attributen of de attributen die worden verwacht als uitvoer van het uitvoeren van de testactie. Belangrijk hierbij zijn de testacties die beslissingen in het stappenplan van de use case simuleren.

De verzameling van testgevallen die bij een use case worden opgesteld wordt het testscenario voor de use case genoemd.

Testscenario

Een testscenario bevat een verzameling van individuele testgevallen die bij dezelfde use case horen. Deze testgevallen zijn tezamen uitputtend om alle verschillende scenario's te doorlopen die kunnen voorkomen bij het uitvoeren van de use case.

Unified Modeling Language (UML)

De Unified Modeling Language (UML) is een algemene visuele modelleertaal waarmee de verschillende producten in een systeemontwikkelproject, vooral gericht op analyse en ontwerp, kunnen worden gespecificeerd, ontwikkeld en gedocumenteerd. De ontwerpers van UML hebben de objectgeoriënteerde modelleertechnieken uit het verleden gecombineerd met de heden ten dage geldende best practices in een standaard aanpak. UML is dan ook bedoeld om onafhankelijk gebruikt te kunnen worden van systeemontwikkelmethoden, faseringen, probleemdomeinen of zelfs typen projecten.

De specificatie van de modelleertaal kent notaties voor het dynamische gedrag en de statische structuren van applicaties en is zo opgesteld dat het mogelijk is om te worden geïmplementeerd in visuele ontwerpgereedschappen. Met behulp van UML worden applicaties gemodelleerd als een verzameling van objecten die samenwerken om de functionaliteit te beschrijven. De statische structuren beschrijven de typen objecten, zoals use cases en klassen, die voorkomen in de applicatie en de onderlinge relaties van deze objecten. Het dynamische gedrag van de objecten verwoordt de samenwerking van de objecten, meestal in de tijd, en de communicatie die de objecten voeren om de functionaliteit van de applicatie te realiseren. Daarnaast kent de Unified Modeling Language organisatorische eenheden, zoals packages, waarmee de objecten kunnen worden gegroepeerd. Hiermee kunnen de objecten in grote applicaties worden geordend in logische componenten.

Use case

Een use case vertegenwoordigt een deel van de functionaliteit van een business process. Een use case wordt in een use case model altijd gevisualiseerd door een ovaal, met daarin (of erbij) de naam van de use case. Een use case wordt daarnaast beschreven als een opeenvolging van stappen die leidt tot een observeerbaar resultaat voor de actor.

Dit stappenplan dient in Smart vervolgens als input voor het opstellen van een interactiemodel voor de use case.

Use case iteratie

In de fasen ontwerp en bouw wordt gewerkt aan de realisatie van use cases. Een typisch dagindeling wordt opgehangen aan de activiteiten uit fasen ontwerp en bouw ten aanzien van één of enkele use cases. Elke dag bestaat dus uit mini-iteraties, zogeheten 'use case iteraties' omdat de gekozen activiteiten van dag tot dag ophangen aan één of enkele use cases.

Werkproduct

Werkproducten worden niet opgeleverd aan het eind van het project maar dienen voor communicatie tijdens het project. Voorbeelden van werkproducten zijn de incrementplannen, de haalbaarheidsstudie en het projectplan.

Workshop

Een workshop is een sessie die - in het algemeen - wordt geleid door de facilitator. Er worden twee soorten workshops onderscheiden in Smart. Productgerichte workshops hebben de realisatie van een concreet product tot doel, zoals een use case diagram, een componentendiagram of een interactiediagram.

Daarnaast zijn er brown paper workshops, die veel meer het karakter van een brainstormsessie vertonen. Hierbij wordt het onderwerp van de workshop behandeld door de deelnemers (simultaan) alle aspecten van het onderwerp te laten noteren (bij voorkeur op Post-Its). De facilitator verzorgt vervolgens de groepering hiervan. Aan de hand van deze groepering worden de overige facetten van het onderwerp nader - in discussies - belicht.

[GLOSSARY] Versie 2003Q2 Basic - ©1999-2006 Sander Hoogendoorn (aahoogendoorn@gmail.com), 1 juli 2003