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).
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).
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.
Skicka en kommentar
Trevligt att du vill dela med dig av dina åsikter! Tänk på att hålla på "Netiketten" och använda vårdat språk.