Modellering i enterprise-IT arkitektur: mer än datamodell och flöde


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 och beteende (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)

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

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.