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.
Afhængig af systemets størrelse og kompleksitet fortsættes med en af følgende aktiviteter:
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.
På basis af system sekvens diagrammer og domænemodel kan udviklerne vælge at fortsætte med en af følgende aktiviteter:
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.