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).
<\/div>![](\"http:\/\/1.bp.blogspot.com\/-2T1oBy46NHM\/UUgOajwttII\/AAAAAAAAAZU\/8eF5lo70FSI\/s640\/milan.png\")
<\/a><\/div>
<\/span><\/div>
<\/div>
<\/div>Vilka av de 14 b\u00f6r alltid ing\u00e5?
Det finns lika m\u00e5nga svar som roller, produktfamiljer, eller applikationsomr\u00e5den. Michael A. Jackson (min forne arbetsgivare) kategoriserade applikationsomr\u00e5den i ett antal Problem Frames, som t ex operat\u00f6rs- och \u00f6vervakningsst\u00f6d, editorer (f\u00f6r text, bild, presentationer), styrsystem och automation, informationssystem, fil- och dataomvandling, osv.
N\u00e4r det klarnat vilket\/vilka \u201dframes\u201d som kommer att dominera projektet \u00e4r det l\u00e4tt att v\u00e4lja bland b\u00e5de diagram och metoder\/processer\/arbetss\u00e4tt. I agil modellering \u00e4r det syftet som avg\u00f6r. I den vanliga j\u00e4mf\u00f6relsen med hus (d\u00e4r olika ritningar visar grund, byggnad, VVS, el, tele, bredband osv) fungerar Problem Frames \u00e4ven som arkitekturgrund. I en blivande ishall eller gym beh\u00f6ver man lyfta fram andra saker \u00e4n i en villa, och p\u00e5 samma s\u00e4tt blir arkitekturen f\u00f6r ett processtyrningssystem olik en editor.
<\/div>
![](\"http:\/\/1.bp.blogspot.com\/-2T1oBy46NHM\/UUgOajwttII\/AAAAAAAAAZU\/8eF5lo70FSI\/s1600\/milan.png\")
<\/a><\/div><\/span><\/div>
<\/div>
<\/div>Vilka av de 14 b\u00f6r alltid ing\u00e5?
Det finns lika m\u00e5nga svar som roller, produktfamiljer, eller applikationsomr\u00e5den. Michael A. Jackson (min forne arbetsgivare) kategoriserade applikationsomr\u00e5den i ett antal Problem Frames, som t ex operat\u00f6rs- och \u00f6vervakningsst\u00f6d, editorer (f\u00f6r text, bild, presentationer), styrsystem och automation, informationssystem, fil- och dataomvandling, osv.
N\u00e4r det klarnat vilket\/vilka \u201dframes\u201d som kommer att dominera projektet \u00e4r det l\u00e4tt att v\u00e4lja bland b\u00e5de diagram och metoder\/processer\/arbetss\u00e4tt. I agil modellering \u00e4r det syftet som avg\u00f6r. I den vanliga j\u00e4mf\u00f6relsen med hus (d\u00e4r olika ritningar visar grund, byggnad, VVS, el, tele, bredband osv) fungerar Problem Frames \u00e4ven som arkitekturgrund. I en blivande ishall eller gym beh\u00f6ver man lyfta fram andra saker \u00e4n i en villa, och p\u00e5 samma s\u00e4tt blir arkitekturen f\u00f6r ett processtyrningssystem olik en editor.
<\/div>
Lika viktig \u00e4r anpassning till mottagaren och situationen. Ett litet axplock fr\u00e5n tidigare kunder d\u00e4r helt olika saker hamnat i fokus: arkitektur f\u00f6r \u00e4rendehandl\u00e4ggning (med event sourcing, pga strikta myndighetskrav p\u00e5 diarief\u00f6ring), modellering av mjukvara f\u00f6r bilar, och ett grafiskt UML-baserat utbildningshj\u00e4lpmedel f\u00f6r inskolning av nyanst\u00e4llda tj\u00e4nstem\u00e4n hos en storkoncern over there (visualiserar hur olika typer av \u00e4renden passerar genom koncernens komplexa systemportf\u00f6lj \u2013 f\u00f6r att f\u00f6rankra arkitekturen i organisationen). Alla tre applikationerna var ju IT och UML, men naturligtvis blev modellerna helt olika och b\u00f6rjade med var sin (olika) diagramtyp som grund. <\/span><\/div>
<\/div>
<\/div>
\u201dLagom\u201d i modellering \u00e4r l\u00e4tt att orda om men s\u00e5d\u00e4r lagom l\u00e4tt att pricka in f\u00f6r projektet. I det ena tr\u00e4sket lurar skakig arkitektur och luddiga krav med stort utrymme f\u00f6r dyra feltolkningar. I det andra lurar TAGRI (They Aren't Gonna Read It) och en marginalkostnad som \u00f6verstiger marginalnyttan. Scott Ambler (Ambysoft, tidigare IBM Canada) anv\u00e4nder fem kriterier f\u00f6r lagom bra modeller: (1) verkningsfulla\/anpassade till mottagaren, (2) \u00e4ndam\u00e5lsenliga i en given situation, (3) av tillr\u00e4cklig kvalitet, (4) \u00e4ndras och uppdateras n\u00e4r det beh\u00f6vs, (5) f\u00e4rdiga tidigare \u00e4n man trott.<\/div>
<\/div>
<\/div>
Oftast landar jag p\u00e5 3 till 6 diagramtyper, aldrig p\u00e5 14 (\u201dyou can still build significantly complex systems using only three diagrams\u201d - som RT-UML gurun Bruce Powel Douglass uttryckt det).<\/div>
<\/div>
<\/div>
N\u00e4sta gallringsomg\u00e5ng g\u00e4ller inneh\u00e5llet \u2013 dels att delar som inte tas med i modellen verkligen \u00e4r irrelevanta, dels att r\u00e4tt saker hamnar i r\u00e4tt diagram, och dels att var sak modelleras (enbart) p\u00e5 sin plats i modellen (\u201dseparation of concerns\u201d). Detta f\u00f6r att slippa splittra fokus med \u201dtoo much to see\u201d och f\u00f6r att undvika dubbelarbete \u2013 i nuet, i kommande iterationer, i nya versioner osv. \u00c4ven den h\u00e4r gallringen kr\u00e4ver eftertanke. Det finns m\u00e5nga exempel p\u00e5 \u00f6verlapp, redundans (\u201dvar sak p\u00e5 sin uppsj\u00f6 av platser\u201d) och on\u00f6digt dubbelarbete som h\u00e4mmar anv\u00e4ndningen av modeller.<\/div>
<\/div>
<\/div>
Summan av detta leder in p\u00e5 strukturen f\u00f6r en agil modelleringskurs. Den b\u00f6r anv\u00e4nda ett smalt urval av diagram, visa var sak p\u00e5 sin plats, visa hur UML-diagrammen h\u00e4nger ihop och kompletterar varandra i en modell, och l\u00e4ra ut notation (\u201dalfabet\u201d och \u201dordf\u00f6rr\u00e5d\u201d) inv\u00e4vd i modellering (\u201dskrivstilar\u201d) - med andra ord, v\u00e4lkommen p\u00e5 kurs hos Informator (som t\u00e4nkt p\u00e5 \u201dvaluta f\u00f6r modelleringspengarna\u201d, s\u00e5 kurserna utg\u00e5r fr\u00e5n praktisk anv\u00e4ndning och inneh\u00e5ller en hel del \u00f6vningar).<\/div>
<\/div>
<\/div>
Milan Kratochvil<\/span><\/span><\/a><\/div>
konsult, Kiseldalen.com<\/span><\/span><\/a><\/div>
UML 2 Professional, OCUP<\/span><\/span><\/a> Advanced Level (certifikatniv\u00e5 3 av 3)<\/div>
Huvudf\u00f6rfattare UML Xtra Light \u2013 How to Specify Your SW Requirements<\/span><\/span><\/span><\/a><\/span><\/div>
<\/div>
<\/div>
Samarbetar med Informator sedan v\u00e5ren 1996 inom modellering, UML, krav, analys och design. H\u00e5ller f.n. kurser i Arkitektur, i modellering (T2715<\/span><\/span>,<\/b><\/a> T2716<\/span><\/span><\/b>)<\/a>, och (februari 2013) \u00e4ven Informators fullsatta Frukostseminarium<\/span><\/span><\/a> om anv\u00e4ndningsfall.<\/div>","featuredImage":false}};