Agil arkitekturmodellering med UML: principlösningar går före detaljer.

Mitt arkitekturinlägg i mars påpekade att dataskiktet ofta förenklar beteendemodellen, och att färdig beprövad SQL (eller OLAP) i databaser, som kan servera svar (cursors/views) på komplexa men vanliga anrop, kan krympa många Sekvensdiagram i UML. Där en lång kedja av interaktioner kommer av långa komplexa sökningar (ofta navigering mellan många tabeller) kan ett antal tabeller kapslas in i 1 komponent (t ex som en SQL procedur).    

Jag nämnde även att datamodellers fokus på data är en begränsning: de lämpar sig inte för att modellera beteenden som t ex tjänster/operationer, livscykler, scenarion, affärsprocesser, eller MMI.

Men å andra sidan räcker de långt för komplexa läsningar/sökningar (”Q:et” i CQRS). Med tonvikt på inkapsling snarare än notation kan ett minimalistiskt Sekvensdiagram i arkitektvyn se ut så här, uttryckt i UML men bortsett från aktiveringar (activation bars) och eventuella säkerhetsskikt:

Dvs färdig och testad funktionalitet krymper SQL-sökningen 1 komponent (och i Sekvensdiagram 1 lifeline), i stället för att visa ett antal tabeller i interna loopar (”under huven” av SQL-motorn eller OLAP-paketet). Enkelt, deklarativt (tänk SQL, OCL, Linq, Hibernate, eller ErLang, snarare än procedurellt/imperativt), oberoende av olika accesshjälpmedel (SQL index, Peter Coad’s extra associationer för Status Collections som t ex alla fullbokade avgångar kontra de med platser kvar, osv), bortser för tillfället både från NIH-syndromet (Not Invented Here) och önskelistan ”Bättre testhjälpmedel för deklarativa språk”, men visar ändå sådant som intresserar arkitekten.

Trots att exemplet är förenklat (en resa är bara 1 flightsegment, andra bolag i samma allians utelämnas, osv) så behövs alltså ingen UML-expertis för att inse att minimalistalternativet med inkapsling enligt ovan har sina fördelar jämfört med det utförliga ”procedurella” alternativet nedan:

Förutom att mer detaljer inte automatiskt medför mer förståelse och samsyn, så stämmer den här sortens explicita sökkedjor sällan med verkligheten i deklarativa miljöer, i synnerhet SQL, av främst två skäl:

- I större datamängder använder SQL motorn ofta accessoptimering, som medför att först läses de tabeller som effektivt krymper den återstående accessvägen/sökrymden, detta även när accesskedjan kommer att kännas ”ologisk” för kravanalytiker.

- Vilka tabeller som läses först kan variera över tiden beroende på nya index, aktuellt antal rader, och aktuell access-statistik.

Även i plattformsoberoende UML-diagram brukar det löna sig att börja med ”inkapslingsnivån” (subsystem, eller komponenter som PriserPåTillgängliga i den övre bilden), och därifrån ta sig ner till detaljnivån (med UML 2 Lifeline decomposition), eftersom nivåerna brukar gå hem hos helt olika roller. 

I all agil modellering är det viktigt att först fråga sig vilka roller och situationer modellen är till för och vad de får ut av att läsa den, detta innan man drar på med detaljerad notation. T ex tittar arkitekten och applikationsutvecklaren sällan genom samma glasögon. Men istället för det där med valuta för modelleringspengarna så avslutar jag med en quiz-fråga på temat ”bok kontra kurs", och en känga till de förlag som föredragit annat framför praktisk substans medan kurser prioriterat substans:

Gissa vilket av följande två citat kommer ur en i övrigt mycket bra arkitekturbok, och vilket ur en arkitekturkurs på Informator. Båda går ut på att förklara A:et i CAP inom distribuerat data (CAP = Consistency, Availability, Partition tolerance).

Citat 1.  Availability: The data will be available.

Citat 2.  Availability: Node failures do not prevent survivors from continuing to operate and being visible.

Att rangordna de två efter praktisk användbarhet (eller kanske efter graden av ”tårta-på-tårta tautologi”...) överlåter vi till läsarna.

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

samt Growing Modular:Mass Customization of Complex Products, Services and Software

Milan 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 i februari 2013 höll han också Informators fullsatta Frukostseminarium om användningsfall.