Agil modellering, kravkommunikation, Påskbord, smörgåsbord... Vad är lagom?

Min gästblogg i september, om UML-standardens femtonårsdag och om att förenkla för att maximera nyttan med modellering, nämnde bl a väldefinierad syntax. Entydighet är knappast något större hinder när man använder UML-diagram som mindmap i kravkommunikation med icke-tekniker. Snarare än precision kan ”notation bloat” bli ett.

I min UML-bok (länk nedan) jämför vi det med att överäta från ett smörgåsbord: nyttan per extra tugga är nära noll, det tar dessutom extra tid, och kan straffa sig i längden. Att OMG dukat fram 14 diagramtyper i modelleringsstandarden UML (bild) betyder inte att alla projekt ska svälja allt med hår och hull. Agil modellering väljer med eftertanke bland de 14, och prioriterar tydlig kommunikation utan missförstånd. Det viktiga är att ha projektets uppdrag i fokus, att snabbt ta fram få men ”rätt” diagram (informativa, kompakta, korrekta, ändamålsenliga).

Vilka av de 14 bör alltid ingå?
Det finns lika många svar som roller, produktfamiljer, eller applikationsområden. Michael A. Jackson (min forne arbetsgivare) kategoriserade applikationsområden i ett antal Problem Frames, som t ex operatörs- och övervakningsstöd, editorer (för text, bild, presentationer), styrsystem och automation, informationssystem, fil- och dataomvandling, osv.
När det klarnat vilket/vilka ”frames” som kommer att dominera projektet är det lätt att välja bland både diagram och metoder/processer/arbetssätt. I agil modellering är det syftet som avgör. I den vanliga jämförelsen med hus (där olika ritningar visar grund, byggnad, VVS, el, tele, bredband osv) fungerar Problem Frames även som arkitekturgrund. I en blivande ishall eller gym behöver man lyfta fram andra saker än i en villa, och på samma sätt blir arkitekturen för ett processtyrningssystem olik en editor.

Lika viktig är anpassning till mottagaren och situationen. Ett litet axplock från tidigare kunder där helt olika saker hamnat i fokus: arkitektur för ärendehandläggning (med event sourcing, pga strikta myndighetskrav på diarieföring), modellering av mjukvara för bilar, och ett grafiskt UML-baserat utbildningshjälpmedel för inskolning av nyanställda tjänstemän hos en storkoncern over there (visualiserar hur olika typer av ärenden passerar genom koncernens komplexa systemportfölj – för att förankra arkitekturen i organisationen). Alla tre applikationerna var ju IT och UML, men naturligtvis blev modellerna helt olika och började med var sin (olika) diagramtyp som grund.  

”Lagom” i modellering är lätt att orda om men sådär lagom lätt att pricka in för projektet. I det ena träsket lurar skakig arkitektur och luddiga krav med stort utrymme för dyra feltolkningar. I det andra lurar TAGRI (They Aren't Gonna Read It) och en marginalkostnad som överstiger marginalnyttan. Scott Ambler (Ambysoft, tidigare IBM Canada) använder fem kriterier för lagom bra modeller: (1) verkningsfulla/anpassade till mottagaren, (2) ändamålsenliga i en given situation, (3) av tillräcklig kvalitet, (4) ändras och uppdateras när det behövs, (5) färdiga tidigare än man trott.

Oftast landar jag på 3 till 6 diagramtyper, aldrig på 14 (”you can still build significantly complex systems using only three diagrams” - som RT-UML gurun Bruce Powel Douglass uttryckt det).

Nästa gallringsomgång gäller innehållet – dels att delar som inte tas med i modellen verkligen är irrelevanta, dels att rätt saker hamnar i rätt diagram, och dels att var sak modelleras (enbart) på sin plats i modellen (”separation of concerns”). Detta för att slippa splittra fokus med ”too much to see” och för att undvika dubbelarbete – i nuet, i kommande iterationer, i nya versioner osv. Även den här gallringen kräver eftertanke. Det finns många exempel på överlapp, redundans (”var sak på sin uppsjö av platser”) och onödigt dubbelarbete som hämmar användningen av modeller.

Summan av detta leder in på strukturen för en agil modelleringskurs. Den bör använda ett smalt urval av diagram, visa var sak på sin plats, visa hur UML-diagrammen hänger ihop och kompletterar varandra i en modell, och lära ut notation (”alfabet” och ”ordförråd”) invävd i modellering (”skrivstilar”) - med andra ord, välkommen på kurs hos Informator (som tänkt på ”valuta för modelleringspengarna”, så kurserna utgår från praktisk användning och innehåller en hel del övningar).

Milan Kratochvil

konsult, Kiseldalen.com

UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)

Huvudförfattare UML Xtra Light – How to Specify Your SW Requirements

Samarbetar med Informator sedan våren 1996 inom modellering, UML, krav, analys och design. Håller f.n. kurser i Arkitektur, i modellering (T2715, T2716), och (februari 2013) även Informators fullsatta Frukostseminarium om användningsfall.