Objektorienteret modellering er en metode til at organisere komplekse systemer.
En use case er en tekst, der beskriver systemets opførsel i en bestemt situation uden at fortælle hvordan (blackbox). Den beskriver, hvordan systemet er i brug af en aktør. Ind- og output for operationerne beskrives. Use cases udarbejdes tidligt i processen for at identificere funktioner.
Hvem er brugeren?
Hvad er deres interesser?
Hvordan bruger de systemet?
Scenarier er konkrete eksempler på brug.
Aktør-perspektivet: First person repræsenterer en bruger, mens scenariet er en specifik, fiktiv person.
Scenariet beskrives i brødtekst, mens use casen beskrives generelt for at dække flere scenarier.
Use casen indeholder det forretningsmæssige formål:
Titel på use casen
Valg og navngivning af aktøren
Tekstbeskrivelse
Der er tre typer aktører:
Primary actor: Bruger systemet til et givet formål (f.eks. kunde).
Supporting actor: Yder en service til systemet (f.eks. betalingsløsninger).
Offstage actors: Interesserede i use casen, men ikke direkte involveret (f.eks. skattemyndigheder, investorer).
Tekstbeskrivelse skal afspejle forretningsmæssige formål og beskrive både brugen og konteksten.
Brief: Enkelt afsnit om ideel adfærd.
Casual: Flere afsnit, beskriver alternative adfærdsmuligheder.
Fully dressed: Detaljeret beskrivelse af alle trin, variationer, krav, samt pre- og post-conditions. Overvej detaljegraden; "brief" er ofte tilstrækkeligt.
Visuel beskrivelse af informationer, der behandles i systemet og deres sammenhænge. Fokus på systemets afspejling af virkeligheden, ikke programobjekter.
Identificér og visualisér stamdata.
Identificér og visualisér samlende objekter og deres relationer til stamdata.
Langlivede data, sjældent skiftende. Systemets funktion er bygget på disse data.
Binder stamdata sammen og har ofte kortere levetid. Eksempel:
System: Visning af fag- og holdfordeling for lærere.
Identificering af stamdata:
Undervisere.
Fag på første år.
Hold.
Samlende objekter: Undersøg systemets prompt: forbindelser mellem underviserne og fag gennem lektionsobjektet, som angiver antal lektioner pr. uge.
Klasser repræsenterer objekter med samme attributter (f.eks. Underviser, Fagfordeling, osv.). Tag højde for virksomhedens sprog ved navngivning.
Giver overblik over objekterne i systemet og opdeles i konceptuelle klasser. Associationen mellem klasserne vises med linjer, hvor multipliciteten noteres.
Domænemodellen starter som en kopi af objektmodellen. Attributter tilføjes for at beskrive data. Klasser kan have flere attributter og skal være konceptuelle.
Definerer hvor mange objekter af en klasse der kan være associerede med et objekt af en anden klasse. Tag højde for potentielle objekter.
Objektmodellen skal altid opdateres for at afspejle ændringer i domænemodellen. Opdater for at imødekomme ønsker fra kunden som f.eks. antal studerende.
Artefakter der viser input og output fra et system. Historik over interaktioner mellem aktører og system.
Operationskontrakter definerer aftaler mellem aktører og systemet om, hvordan operationer udføres. De beskriver specifikt forventninger til input, proces og output for en given operation. OC'er er vigtige for at sikre, at aktører og systemet er enige om kravene til funktionalitet og ydeevne i systemet.
Formål: At fastlægge klare rammer for, hvordan systemet skal reagere i forskellige scenarier.
Elementer:
Ind-data: Hvilke oplysninger der skal gives til systemet.
Procedurer: Hvad systemet skal gøre med dataene.
Ud-data: Hvilke resultater der forventes fra operationen.
Forhold til use cases: OC'er komplimenterer use cases ved at give detaljerede beskrivelser for de specifikke operationer, der er nævnt i use cases.