Use case

Uit Wikipedia, de vrije encyclopedie
Ga naar: navigatie, zoeken

Een use case in software engineering en systems engineering is een beschrijving van een gedrag van een systeem, dat reageert op een verzoek dat stamt van buiten het systeem. Met andere woorden, de use case beschrijft "wie" met het betreffende systeem "wat" kan doen. De usecasetechniek wordt gebruikt bij de bepaling van de requirements van het gedrag van een bepaald systeem.

Overzicht[bewerken]

Een use case beschrijft een systeem vanuit het gebruikersperspectief. Het beschrijft de actor, de initiator van de interactie, en het systeem zelf als een opeenvolging van eenvoudige stappen. Actoren kunnen iets of iemand zijn, die bestaat buiten het te bestuderen systeem, en die deelneemt in de opeenvolgende activiteiten in een dialoog met het systeem om een bepaald doel te bereiken. Actoren kunnen eindgebruikers, andere systemen of hardware (apparatuur) zijn. Elke use case is een complete serie van zogenaamde "events", beschreven vanuit het standpunt van de actor.[1]

Volgens Bittner en Spence (2002) zijn use cases eenvoudigweg een beschrijving van een reeks gebeurtenissen, die met elkaar het systeem in staat stellen iets bruikbaars te doen.[2] Elke use case beschrijft, hoe de actor zich zal gedragen ten opzichte van het systeem om een doel te bereiken. Van een enkele use case kunnen meerdere scenarios worden gegenereerd, corresponderend met elke weg om een doel te bereiken. Bij het opstellen van use cases wordt doorgaans technisch jargon gemeden, en wordt aangesloten bij de taal van de eindgebruiker. Ze worden vaak opgesteld in samenwerking tussen een systeemanalist en de eindgebruiker. In de Unified Modeling Language kunnen use case-diagrammen gebruikt worden om de use cases van een gegeven systeem grafisch weer te geven.

In systems engineering worden use cases veelal op een hoger abstractieniveau gedefinieerd dan binnen software engineering, om de missies van een systeem of de doelen van een stakeholder weer te geven. Gedetailleerde requirements kunnen hierbij worden weergegeven in SysML requirement-diagrammen of vergelijkbare schematechnieken.

Ontstaan[bewerken]

Het begrip "use case" werd halverwege de jaren 1980 bedacht door Ivar Jacobson en stamt af van het oudere begrip "usage scenario", ofwel gebruiksscenario. Jacobson begon in 1967 bij Ericsson met het schrijven van gebruiksscenario's bij de beschrijving van de architectuur van Ericssons AXE-systeem. In de jaren 1980 ging Jacobson nadenken over zijn werkwijze en kwam met het Zweedse begrip "anvendningsfall", wat ongeveer staat voor "situatie van gebruik". Direct vertaald naar het Engels zou dit "usage case" worden, maar hij vond dat deze beide termen niet natuurlijk klonken. Uiteindelijk was hij wel tevreden met het begrip "use case". In 1986 formuleerde Jacobson ook de eerste visuele modelleertechniek voor de specificatie van use cases.[3]

Sinds Jacobson het use case model ontwikkelde hebben velen bijgedragen aan de verbetering van deze techniek, waaronder Kurt Bittner, Alistair Cockburn, Gunnar Overgaard, en Geri Schneider. Tijdens de jaren 1990 werd de use case een van de gebruikelijke methoden om functionele requirements vast te leggen. Dit was vooral het geval in de objectgeoriënteerde gemeenschap, maar de toepasbaarheid van de methode is niet beperkt tot objectgeoriënteerde systemen, daar use cases zelf niet objectgeoriënteerd van aard zijn.

Use case onderwerpen[bewerken]

Use case focus[bewerken]

Elke use case focust op de beschrijving hoe een doel of taak kan worden bereikt. Voor de meeste software projecten betekent dit dat verschillende, soms tientallen, use cases benodigd zijn voor de definitie van de scope van een nieuw systeem. De mate van formalisering van een bepaald software project en het stadium van ontwikkeling is bepalend voor de vereiste gedetailleerdheid van elke use case. Use cases moeten niet worden verward met de eigenschappen van het te ontwikkelen systeem. Een use case als gebruikt scenario kan gerelateerd zijn aan een of meerdere eigenschappen, en een eigenschap aan een of meerdere use cases.

Een use case definieert de interactie tussen externe actoren en een bepaald systeem om een doel te bereiken. Een actor specificeert een rol, die gespeeld wordt door een persoon of ding, in wisselwerking met het systeem.[4] Dezelfde persoon, die het systeem gebruikt, kan worden weergegeven met verschillende actoren indien de persoon meerdere rollen vervult. Bijvoorbeeld, een persoon "Jan" kan de rol spelen van klant als hij geld aan een geldautomaat onttrekt, en kan de rol vervullen van bankmedewerker, die de geldautomaat bijvult.

Use cases behandelen het systeem als een black box, en interacties met het systeem inclusief de systeem respons, worden opgevat als komende van buiten het systeem. Dit is een bewuste keuze, om de analist te laten focussen op wat het systeem moet doen, en niet hoe het gedaan wordt. Hiermee kan men voorkomen, dat men aannames gaat maken over de functionaliteit van het systeem om zijn taken te vervullen. Use cases kunnen beschreven worden op een abstract niveau, ook wel een "business use case" of een "essential use case" genoemd, en op een systeem level, een "systeem use case". Het verschil zit hierbij in de scope:

  • De business use case wordt beschreven in een niet-technische terminologie, waarbij systemen worden beschouwd als black boxes, en beschrijft het bedrijfsproces dat gebruikt wordt door zijn bedrijfsactoren (mensen of systemen buiten het proces) om hun doel te bereiken (bijvoorbeeld handmatige betaling bewerking, uitgave rapportage goedkeuring, beheer van onroerend goed van het bedrijf). De business use case beschrijft een proces dat waarde toevoegt aan de bedrijfsactor, en beschrijft wat het proces doet. Een andere methode van bedrijfsbeschrijving op dit niveau is bijvoorbeeld Business Process Modeling Notation (BPMN)
  • De systeem use case beschrijft een systeem dat een business use case of proces automatiseert op een niveau van systeemfunctionaliteit (bijvoorbeeld creëer toegangskaart) en specificeert de functie of dienst, die het systeem biedt voor de eindgebruiker. Een systeem use case beschrijft wat het systeem doet als reactie op de actor. Om deze reden wordt aanbevolen om de specificatie van deze use case met een werkwoord te beginnen (bijvoorbeeld creëer toegangskaart, selecteer betaling, voer betaling uit, blokkeer toegangskaart).

In het algemeen moet een use case:

  • beschrijven wat een systeem moet doen voor een actor om een bepaald doel te bereiken.
  • opgesteld zijn in een implementatie onafhankelijke specificatie taal
  • een toepasselijke mate van gedetailleerdheid hebben
  • Geen details bevatten omtrent user interfaces of beeldopbouw. Dit gebeurt pas bij het user interface ontwerp.

Mate van gedetailleerdheid[bewerken]

Cockburn (2001) heeft drie niveaus geïdentificeerd voor de mate van gedetailleerdheid in het schrijven van use cases:[5]

  • Korte use case (Brief use case) : bestaat uit een paar zinnen, die de use case samenvatten. Dit zou in een spreadsheet cel passen, waarbij in de andere kolommen zaken worden aangegeven als prioriteit, technische complexiteit, nummer, en zo voort.
  • Gewone use case (Casual use case) : bestaat uit enige paragrafen tekst, die de use case samenvatten.
  • Volledig ingevulde use case (Fully dressed use case) : dit is een formeel document gebaseerd op een gedetailleerd model met velden voor verschillende secties. Dit is de meest gebruikelijke betekenis van het use case idee.

Toepasselijke gedetailleerdheid[bewerken]

Sommige softwareontwikkelingsprocessen behoeven niet meer dan enkele eenvoudige use cases om de requirements te definiëren. Echter, andere ontwikkelingsprocessen vereisen gedetailleerde use cases om deze requirements te definiëren. Hoe groter en complexer het project, hoe aannemelijker dat hier gedetailleerde use cases benodigd zijn.

De mate van details in een use case zal vaak veranderen met de voortgang van het project. De initiële use cases kunnen kort zijn, maar worden gedetailleerder naarmate het ontwikkelingsproces verder uitpakt. Dit weerspiegelt zich ook in de veranderende requirements van de use case. In het begin hoeven zij alleen kort te zijn om de bedrijfs requirements vanuit het gebruikersperspectief samen te vatten. Verderop in het proces hebben ontwikkelaars meer specifieke en gedetailleerde richtlijnen nodig.

In het Rational Unified Process worden ontwikkelaars uitgenodigd om korte use cases in use case diagrammen te beschrijven, met een gewone beschrijving als commentaar, en een gedetailleerde beschrijving van de stroom van events in een tekstuele analyse. Dit alles kan meestal ingevoerd worden in een use case tool (bijvoorbeeld een UML Tool of SysML tool), of kan uitgewerkt worden op een aparte tekstverwerker.

Use case notatie[bewerken]

In de Unified Modeling Language wordt de relatie tussen alle use cases en actoren weergegeven in use case diagrammen, of in diagrammen die zijn gebaseerd op Ivar Jacobson's Objectory notatie. SysML, een UML profiel, gebruikt dezelfde notatie op het systeem use case niveau.

Use cases en het ontwikkelingsproces[bewerken]

De specifieke wijze waarop use cases in een ontwikkelingsproces gebruikt worden, hangt ook af van de gebruikte ontwikkelingsmethodologie. In bepaalde methodieken is alleen een korte use case verkenning voorgeschreven. In andere methodieken veranderen use cases mee met het karakter van het ontwikkelingstraject. En in weer andere methodieken kan de use case beschrijving eenvoudig beginnen en uitmonden in een zeer gedetailleerde beschrijving van de benodigde testprocedures.

Use case sjablonen[bewerken]

Er zijn geen standaard sjablonen voor de documentatie van gedetailleerde use cases. Er zijn een aantal concurrerende schema's, en individuen worden aangemoedigd om use case sjablonen te gebruiken, die voor hen zelf of het project goed werken. Standaardisatie binnen een project is belangrijker dan de details van een specifiek sjabloon. Er is echter wel aanzienlijke overeenstemming over de centrale secties. Naast de uiteenlopende terminologie en ordeningsprincipes zijn er basale overeenkomsten tussen de meeste use cases. Verschillende sjablonen gebruiken vaak toegevoegde secties, bijvoorbeeld aannamen, uitzonderingen, aanbevelingen, technische requirements. Er zijn ook vaak industrie specifieke secties. Gemeenschappelijke bouwstenen in use cases zijn:

  • Use case naam : Een use case naam levert een unieke identificatie voor de use case.
  • Versie : Een versie is van belang om de lezer inzicht te geven in het stadium dat de use case heeft bereikt.
  • Doel : Een doel beschrijft in het kort, wat de gebruiker met de use case wenst te bereiken
  • Samenvatting : Deze sectie bevat de essentie van de use case, en geeft een overzicht.
  • Actoren : Een actor is iemand of iets buiten het systeem, dat een interactie aangaat met het systeem.
  • Precondities : Een sectie die alle condities definieert, die waar dienen te zijn.
  • Triggers : Een sectie beschrijft de gebeurtenissen (events), waardoor de use case geïnitieerd wordt
  • Basis verloop van de events : een primair scenario, of verloop van de gebeurtenissen
  • Alternatieve wegen : Secundaire wegen of alternatieve scenario's
  • Post condities : Beschrijving van de eindtoestand van het systeem na het verloop van de use case.
  • Business rules : Geschreven of ongeschreven regels of beleid, die bepalen hoe een organisatie dient te reageren op een bepaalde use case.
  • Notes : Belangrijke aantekeningen, die niet in de vooropgezette format passen.
  • Auteur en datum

Zie ook[bewerken]

Externe links[bewerken]

Bronnen, noten en/of referenties
  1. Ivar Jacobson, Object-Oriented Software Engineering, Addison Wesley Professional, 1992 ISBN 0201544350.
  2. Kurt Bittner, Ian Spence, Use Case Modeling, Addison Wesley Professional, 2002, p. 2–3 ISBN 0-201-70913-9.
  3. Alistair Cockburn (2002). "Use cases, ten years later". Oorspronkelijk gepubliceerd in STQE Magazine, Mar/Apr 2002.
  4. §16.3.1 omg.org 07-02-03.
  5. Alistair Cockburn (2001). Writing Effective Use Cases. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc. ISBN 0-201-70225-8.