En modell som syftar till en ändringsvänlig arkitektur tar hänsyn till dels struktur (vilka begrepp är centrala i domänen och hur de är relaterade), dels beteende (vad ska systemet/systemen göra). Det innebär väl avvägda delar ”domain driven” och ”behavior driven”
Tendensen att hålla fast vid gammalt beprövat ”såhär har vi alltid gjort” följer gärna nivån i hierarkin. Ju högre upp i en organisation man modellerar, ju äldre modelleringstekniker används. De må vara helt up to date på programnivån, men uppe i EA/EITA kan man få en och annan nostalgitrip till 70-talet, på gott och ont.
Det goda med ER-diagram, datamodeller, och så småningom CA ERwin var insikten att redundans kostar och ska förebyggas – ett angreppssätt som spreds på 70-talet av Codd & Date (relationsalgebra med normalformer, och så småningom SQL-standarden).
Det mindre goda var att insikten stannade vid strukturering av data. Företagen städade successivt upp just där, men inte på programbiblioteken och inte heller i affärsprocesserna. Där fick dubblering florera vidare – och därmed även dubbelarbetet, särskilt i samband med förändringar.
ER- och Datamodellernas naturliga begränsning är just deras fokus på data (förutom på vissa typer av regler, men inte alla). De passar inte för att modellera beteende/förlopp som t ex tjänster/operationer, livscykler, scenarion, affärsprocesser, eller människa-dator interaktion.
Ibland har man kompletterat dem med användningsfall (en bra interaktionsbeskrivning) men i övrigt ändå nöjt sig med underförstått CRUD-beteende dvs ”dum” dataskyffling där systemet inte ”ser” riktiga affärshändelser utan bara mekaniskt ”Create – Retrieve – Update – Delete” så att den egentliga verksamhetslogiken förblev utspridd i lathundar och hjärnor. Det fick återverkningar uppåt på affärsprocesserna, där man senare med BPM på 1990- och 2000-talen upptäckte åtskilliga inkonsekvenser, dubbelarbete, överlapp, och halvmanuell improvisation.
Domän- och Objektmodeller i UML ligger alltså bra till som länk för att få med beteende hela vägen i modellerna, från BPM:s affärsprocess (ett förlopp ”från ax till limpa”) via senioranvändarens användningsfall (systems beteenden mot omgivningen) till arkitektens EITA som väger ihop data ochbeteende (verksamhetsanpassade tjänster/”semantiska operationer”, tvärtemot CRUD).
Det är dessutom enklare att härleda eller generera en Datamodell ur ett Klassdiagram i UML än tvärtom, trots att det innebär mer än bara en menyrad i en UML-ritare (om man gått in för enbart Datamodellering så finns f ö inte heller någon beteendemodell att klicka på).
Växelverkan mellan struktur och beteende påverkar både modelleringsstilen och arkitekturen. Det som lutar åt en entitet i ER-modellering behöver inte bli en klass i en UML-modell. Ett exempel på tjänst/operation (dvs beteende) i affärslogikskiktet som förenklar strukturen är en webbutik där varje klick på ”Betala” bara skickar iväg ett anrop på en fristående förmedlare av säkra betalningar. I UML-modellen kan ”Betala” bli en operation i stället, givet naturligtvis transaktionslogg och bekräftelse från betalningsförmedlaren till köparen och butiken (förresten, varken Datainspektionen eller kunderna skulle bli gladare av att data om bankkort hamnade i en massa webbutikers datamodeller och databaser). Ett omvänt exempel, där dataskiktet märkbart förenklar beteendemodellen, är färdig nästlad SQL eller OLAP-hjälpmedel i databaser. Klarar de komplexa svar (views) på vanliga anrop så kan många Sekvensdiagram i UML visa dem som bara 1 komponent – i stället för kanske 10 tabeller och interna loopar som är inkapslade i dem (under ”huven”, av SQL-motorn eller OLAP-paketet).
Fler tillfällen att vrida och vända på sambandet mellan struktur och beteende får man under övningar på modelleringskurserna hos Informator. Välkommen.
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:
och även Informators fullsatta Frukostseminarium om användningsfall.
/Milan Kratochvil