Datamatikeruddannelsen - Softwaredesign

Systemudvikling - tutorial 1

Systemudviklingsprocessen

Dette er en gennemgang af en mulig strategi for løsning af en opgave i systemudvikling baseret på Larmans version af RUP. Det er værd at bemærke, at denne fremstilling primært forholder sig til udviklingsprocessen, hvorfor der kan forekomme andre anbefalinger for brug af diagrammer og værktøjer, end man oplever, hvis de samme diagrammer og værktøjer anvendes som dokumentation.

Dette har i praksis den konsekvens, at jeg ikke vil anbefale computertegnede diagrammer brugt i udviklingsprocessen - disse hører efter min mening alene hjemme i en dokumentationsproces, som med stor fordel kan udskydes til programkoden er færdig. Det er så ofte muligt at anvende refactoring værktøjer i programudviklingsmiljøet til fremstilling af den ønskede dokumentation.

I udviklingsprocessen fremstilles de diagrammer, som man anser for nødvendige for at løse opgaven på den optimale måde. Det har i praksis vist sig at være meget effektivt at fremstille diagrammer på tavler og white-boards. Her er der mulighed for at diskutere designforslag og komme med ændringsforslag i en kreativ proces.

Som dokumentation af denne udviklingsproces kan et digitalt fotografi af tavlen være mindst lige så meget værd som et rentegnet diagram i et computerprogram - og det er væsentligt hurtigere at fremstille.

Det er i øvrigt en god ide at fotografere sine tavler med jævne mellemrum, og ikke mindst hvis man skal til at diskutere større ændringsforslag - det er ofte set, at man efter en større diskussion af ændringsforslag ønsker at vende tilbage til det oprindelige design, og så er det ærgerligt, hvis man ikke kan huske detaljerne i det. Tavlen kan jo være blevet ændret i forbindelse med ændringsforslagene.

Nedenstående figur viser, hvordan forskellige produkter (UML artefacts) kan relatere sig til og supplere hinanden i en udviklingsproces.

Udgangspunktet er altid brugernes krav og ønsker, som beskrives i et antal use cases. Disse use-cases udgør den vigtigste del af systemets kravspecifikation. Som udgangspunkt skal man udarbejde use cases i brief format.

Når man har defineret use-cases

Afhængig af systemets størrelse og kompleksitet fortsættes med en af følgende aktiviteter:

  1. Hvis systemet er meget simpelt, kan udviklerne i mange tilfælde fortsætte direkte til programmering af koden.
  2. Hvis systemet er mere komplekst, kan udviklerne fortsætte med at omdanne use cases til system sekvens diagrammer.
  3. Hvis man har svært ved at komme i gang med denne proces, kan det være en hjælp at omdanne sine use cases til casual format eller fully dressed format, inden man laver system sekvens diagram. Nogle vil, efter at have omdannet use cases til casual eller fully dressed format, kunne fortsætte til programmering af koden.
  4. I de fleste tilfælde vil udviklerne på baggrund af de fundne use cases lave en skitse til en domænemodel for systemet.

Det er altid en god ide at lave systemet i små og mere overskuelige dele. Selvom projektet allerede er opdelt i iterationer af 2 til 3 ugers varighed, kan det altså være fordelagtigt med en endnu større nedbrydning - gerne helt ned til en enkelt dags arbejde. Man kan således starte dagen med at udvælge de use cases man vil arbejde med denne dag - herefter udvikler man kun den del af diagrammerne som er nødvendige for den aktuelle dags arbejde. Dog gælder det for domænemodellen, at man her ofte har ideer til flere klasser, end der umiddelbart er brug for til dagens arbejde, og så tegner man naturligvis de klasser, man har fundet frem til. Man bør i øvrigt altid kradse en skitse ned, hvis man får en god ide til et eller andet - uanset hvor man i øvrigt befinder sig på det tidspunkt, hvor man får ideen. Der er ingen der ved, om de kan genkalde sig ideen senere, hvis de får brug for det.

Når man har defineret Systemsekvensdiagrammer

På basis af system sekvens diagrammer og domænemodel kan udviklerne vælge at fortsætte med en af følgende aktiviteter:

  1. Hvis udviklerne kan overskue situationen og ved, hvad der skal laves, fortsætter de ofte direkte med programmering af koden.
  2. Alternativt kan udviklerne vælge at starte med at tegne sekvens diagrammer for udvalgte system operationer i system sekvens diagrammet.
  3. Hvis man har svært ved at komme i gang med at programmere eller tegne sekvensdiagrammer, kan det være en idé at overveje at lave operationskontrakter for systemoperationerne.

Der må meget gerne opstå en kreativ vekselvirkning mellem programmering og tegning af sekvens diagrammer - programmet og sekvens diagrammet udgør nemlig to sider af samme sag. Kan man fremstille det ene, kan man som regel også fremstille det andet. Dog kan det være en stor fordel at kunne skifte perspektiv undervejs. Mange foretrækker således at begynde med en skitse til et sekvensdiagram. Efter at have arbejdet med diagrammet i et stykke tid får man måske lyst til at programmere, fordi man enten mener at vide, hvordan det skal kodes, eller blot fordi man er kørt fast og har lyst til at lave noget andet.

Næste tutorial: Eksempel på anvendelse af Larmans metode - realisering af de to første systemoperationer.


Oprettet: 6. december 2007
Sidst opdateret: 14. december 2007