Denne artikel er bragt i Upgrade - danskIT forenings medlemsblad den 8. november 2002

På vejen mod effektiv softwareudvikling

Softwareindustrien af i dag er langt bedre til, at håndtere systemudvikling end for blot få år siden. Desværre ser vi stadig mange projekter, der enten bliver voldsomt dyrere end oprindeligt antaget eller totalt mislykkedes. Der sker et voldsomt spild af ressourcer ved at utallige algoritmer, delsystemer og komplette applikationer genskrives gang på gang. Ved at skabe mere genbrug og vidensdeling, ville mange fiaskoer kunne undgås, og potentialet i industrien kunne udnyttes langt mere effektivt end i dag.

Mange forskere og software praktikere har, gennem IT-industriens 40-50-årige historie, arbejdet hen imod mere effektive softwareudviklingsprincipper. Ivar Jacobson er en af disse bidragsydere;  han er bla. kendt for use cases, UML og RUP. Ivar kommer til København d. 18 november og i den anledning har undertegnede talt med Ivar om hans syn på softwareudvikling anno 2002 samt om hans visioner for fremtidens softwareudvikling.

Ivar Jacobsons historie

Ivar har arbejdet i branchen i mere end 35 år. Han startede hos Ericsson, med udvikling af telefoncentraler og telekommunikationsstandarder fra 60’erne til midt 80’erne. I 1967 ændrede han radikalt på måden, hvorpå telefoncentraler blev designet, og fandt her på komponentbaseret softwareudvikling. Hos Ericsson arbejdede de med ”traffic cases” og ”funktioner” til kravspecifikation af telefoncentraler. I 1986 forenede Ivar disse to begreber i ét: Use cases. Use cases fik deres endelige gennembrud på konferencen OOPSLA i 1987. Samme år stiftede Ivar egen virksomhed. Objectory var navnet på virksomheden såvel som på dens produkt. Objectory, som er et omfattende procesframework for softwareudvikling, blev videreført under navnet RUP, da virksomheden i 1995 blev en del af Rational. Hos Rational indgik Ivar i samarbejdet mellem Grady Booch og Jim Rumbaugh om at forene deres objekt notationer til én standard. I 1997 var UML 1.0 en realitet. Ivar er stadig hos Rational, og bærer i dag titlen ”Vice President Process Strategy”.

Under samtalen med Ivar kommer vi vidt omkring i emnet softwareudvikling, men da talen falder på RUP, mærkes det straks, at dette er hjertebarn nummer 1 for den kendte svensker. ”Dette er min passion!” - udbryder Ivar begejstret – ”RUP er frugten af 20 års arbejde, og jeg mener, at vi for alvor er klar til at høste!”

”RUP er først og fremmest en stor vidensbase – en vidensbase over de forskellige aktiviteter, personroller, resultater m.m. der kan indgå i et softwareprojekt. RUP er udviklet ved at benytte objektorienteret modellering på softwareudviklingsprocessen, på samme måde som vi modellerer et softwaresystem i UML.”

RUP – Rational Unified Process

RUP er en meget omfattende samling af anbefalinger – i dag mere end 5000 enkeltsider. Det ville være komplet umuligt at finde rundt i og bruge, hvis det ikke var beskrevet baseret på objektorienterede modeller. Det er ikke meningen, at man skal forstå RUP fra ende til anden. Ingen udvikler behøver at læse alt dette, og intet projekt vil nogensinde få brug for det hele. Efter som RUP i sig selv er baseret på objektorienterede principper, kan det tilpasses den enkelte organisation via specialisering og egne udvidelser.

Mange har stillet spørgsmålstegn ved det enorme omfang af RUP og hertil svarer Ivar: ”Jeg vidste allerede i 1986, da jeg gik i gang med RUP [Objectory], at hvis det skulle lykkedes at lave en tilstrækkelig vidensbase for softwareudviklingsprocessen, der kunne følge med tiden, der kunne tilpasses den enkelte organisation og som på sigt kunne gøres til en eksekverbar procesmotor, så skulle processen modelleres. Inden det ville blive muligt, at automatisere RUP vidste jeg, at der ville være megen modstand, det har jeg levet med, og nu er visionen om en eksekverbar RUP endelig ved at gå i opfyldelse”.

RUP og agile metoder

Med den omfattende vidensbase som RUP udgør in mente er det måske lidt overraskende, at Ivars grundholdning til processer er, at de skal gøres så simple som muligt. ”Lad mig først sige, at når et nyt produkt skal udvikles, så bør projektet gennemføres med en så ”light” proces som muligt, måske noget i retning af XP [eXtreme Programming]. Det skal være så ”light” som muligt, men heller ikke ”lighter”!”.

Ifølge Ivar har fortalerne for Agile metoder totalt misforstået RUP. ”Agile metoders negative holdning til modellering og arkitektur er helt forkert, og kun et udtryk for udviklingsstadiet af case-værktøjer på det tidspunkt metoderne fremkom. Det var for svært at integrere model og kode. I modeldrevet udvikling er modellen koden og omvendt, men det forudsætter en god værktøjsunderstøttelse”.

Men hvis det gælder om at benytte en ”light” proces, hvorfor så i det hele taget benytte RUP? ”RUP kan skalere op. Hele rammen er klar til, at man kan stramme op og tilføje ekstra proceselementer, så snart det bliver nødvendigt. Med RUP i ryggen kan man indfri ens proceskrav, når projektet vokser og derigennem får brug for mere metode”. En af de største problemer i softwareprojekter er – ifølge Ivar – projekter, der er startet ud med en for ”light” udviklingsproces, og som har holdt sig til den. Det er en alvorlig fejl; man skal løbende tilpasse processen til projektets krav, kompleksitet, applikationstype og alle øvrige projekt faktorer.

Ivar har respekt for mange af ideerne i de forskellige ”agile” metoder [ofte også betegnet letvægtsmetoder], og Rational har da også i dag en plug-in, hvor eXtreme Programming er beskrevet i rammerne af RUP. Ivar fremhæver også Martin Fowlers bog om refactoring (restrukturering). ”Refactoring er noget vi altid har benyttet os af, men at få beskrevet og katalogiseret dem er et vigtigt skridt fremad”.

Til gengæld tror Ivar ikke på ideen, om at lade systemarkitekturen fremkomme igennem kontinuert refactoring, som XP litteraturen foreslår det. ”Noget af det vigtigste, når et nyt projekt ser dagen lys er, som det første designarbejde, at sætte en lille gruppe af de dygtigste i virksomheden til at designe arkitekturen. Dette arbejde tager en til to uger, men hvis det så til gengæld danner grundlag for en god og stabil arkitektur mange år fremover, er arbejdet tjent hjem mangefold.”

UML - Unified Modelling Language

UML er i dag en vidt udbredt standard for beskrivelse af objektorienterede modeller. UML er defineret ud fra en formel beskrivelse af objektorienterede typer og deres sammenhæng, såsom klasser, associationer, objekter og generalisering / specialisering. Den formelle del af UML sikrer, at der er sammenhæng, i det vi som softwareudviklere laver, når vi beskriver vores analyse, arkitektur og design vha. klassediagrammer, sekvensdiagrammer, tilstandsdiagrammer eller en af de øvrige UML diagramtyper.

På spørgsmålet om hvad det er, der har gjort UML så populært og udbredt svarer Ivar: ”Software er svært at forstå kun vha. kode. Med UML kan vi udtrykke softwaresystemers design og arkitektur - UML modeller giver overblik. En anden vigtig faktor er, at UML er standardiseret, og stort set alle metodefolk slutter i dag op om den, derudover bygger UML på sunde ideer, der for de flestes vedkommende er mere end 20 år gamle. Med nutidens modelleringsværktøjer spilder vi tiden, hvis vi ikke modellerer!”.

UML 2.0 er undervejs og standarden forventes frigivet i løbet af 2003. Denne nye version sigter mod, at gøre UML endnu mere tilgængeligt end i dag. Der arbejdes hen imod at mindske kernen i UML og at gøre den mere præcis og formel. Samtidig har man tilføjet såkaldte profiler til UML. I dag findes der bl.a. profiler for real-time udvikling, forretningsmodellering, web udvikling og data modellering. Den enkelte bruger af UML skal således ikke kende den komplette UML specifikation, men kun selve kernen og de relevante profiler.

Med dagens værktøjer, f.eks. XDE fra Rational [der findes også en del andre] er model og kode tæt sammenknyttet, faktisk er model og kode en og samme ting. Som udvikler arbejder man på begge dele løbende.

På længere sigt kan den øgede formalisering samt UML 2.0 udvidelsen: ”Action Semantics UML Extension” gøre UML til et ”ægte” programmeringssprog, hvor en virtuel UML-maskine kan eksekvere modeller uafhængigt af den underliggende platform.

Agenter - udviklerens hjælpende (h)ånd

”I 1980 foreslog jeg, at når vi engang forstod, hvordan vi modellerer bedst muligt, så kunne vi benytte ekspertsystemer som støtte i udviklingen. I dag er jeg sikker på, at det er intelligente agenter, der er vejen frem”

Som softwareudvikler har vi utroligt mange trivielle opgaver. 20% af arbejdet består af rutiner, der kan udføres uden faglig indsigt. 60% kan kun udføres af fagfolk, men er rutinearbejde, hvor vi følger et mønster, vi har benyttet mange gange før. De sidste 20% er der, hvor det bliver spændende - hvor kreativiteten i arbejdet ligger.

På spørgsmålet om hvordan disse agenter fungere, kaster Ivar sig ud i en analogi: ”Når vi kører i vores bil, følger vi en proces, uden rigtigt at tænke over det, og vi behøver i hvert tilfælde slet ikke at læse en manual for at køre. Som chauffør kan vi foretage både kreative og tåbelige manøvrer.” I softwareudvikling kan vi gøre proces og værktøjer langt mere transparente, bygge processen ind i værktøjerne. Når vi styrer eller bremser bilen, sker der mange ting, som vi ikke bekymrer os om. Når en udvikler udfører en arbejdsopgave, kan mange værktøjer være involveret og mange værktøjskommandoer udføres, uden at vedkommende direkte involveres. Agenter kan også være læremestre: En slags ”learn as you drive”, hvor agenten træner udvikleren når vedkommende skal i gang med en ny arbejdsopgave. Sidst, men ikke mindst, kan agenter gøre det sjovere at udvikle, ved at fremhæve de kreative dele af udviklingsprocessen og minimere rutineopgaverne, som vi har udført mange gange før.

Ivar tror på, at agenter i fremtiden bliver vigtige for softwareudviklingen. Han tror så meget på det, at han sammen med sin datter har investeret i virksomheden Jaczone AB, der arbejder på at frembringe værktøjer baseret på agenter.

Med agenter kan den enkelte udvikler få en ”procesmotor”, der understøtter udviklerens daglige arbejde, i hånden. Agenten baserer sig på projektets proces - den valgte RUP instans, på de værktøjer udvikleren har til rådighed, samt den platform der udvikles mod. Procesmotoren skal kunne opdateres løbende, når nye værktøjer og teknikker bliver tilgængelige, uden at det griber forstyrrende ind i den enkelte udviklers daglige arbejde. På længere sigt har denne form for agenter potentialet til at kunne føre til egentlig lægmandsprogrammering.

Mod effektiv softwareudvikling

Vi bevæger os til stadighed mod højere og højere abstraktioner i softwareudviklingsprocessen. Et eksempel på dette er udviklingen fra 80’erne og begyndelsen af 90’erne, hvor man ofte udviklede egne protokoller til i dag, hvor f.eks. CORBA, Java RMI og senest XML web services er blevet standardteknologier.

Der er ikke tvivl om, at Ivar med sit engagement indenfor metoder og teknikker til softwareudvikling, vil gøre sit for at øge modenheden og produktiviteten i softwareindustrien; ”I dag har vi et enormt spild af gode menneskelige ressourcer, fordi vi i vores branche gør det samme igen og igen. Med UML, RUP, komponentbaseret udvikling, agenter osv. vil meget af dette blive overflødigt. Det vil kunne udnyttes til at komme videre”.

Af Carsten Juel Andersen, Softwarearkitekt hos Captator