Modellering med arkitektambitioner: men vilken?

Hos Informator hittar du dels en kurs i Agil Modellering, T2715, dels en i Avancerad Modellering, T2716, förutom att UML diagram också används i ett par arkitekturkurser. Båda kurserna lär ut och använder UML 2, och agil modellering kan ju också bli tillräckligt avancerad.

Så vilka skillnader är det då mellan dem två?  

Den agila kursen betonar modelleringssamarbete i smågrupper (oftast på 3-6 personer), fokuserad kommunikation både med intressenter och inom gruppen, tidsramar och begränsat antal diagram,  enkla designchecklistor för att bygga in modifierbarhet från början, snabbt smidigt utbyte av uppslag och idéer.

Den avancerade kursen går mer in på notation, designprinciper, mönster (designmönster m fl), affärsregler/constraints, olika lösningsalternativ och sätt att modellera dem, osv.

Om den roll du siktar på medför mycket kunskapskommunikation mellan människor, dvs rollen liknar en analytiker, agil utvecklare eller design lead, kravfångst, arkitektursamordnare, så är den agila kursen oftast mer intressant.

Bland annat tänker man först igenom vilka roller och situationer modellen är till för och vad de får ut av att läsa den (det bör gå före detaljerad notation). T ex läser arkitektroller och applikationsutvecklare genom olika”glasögon”.

Om rollen däremot medför lika mycket eller mer kommunikation med maskinen, t ex verktygs- och miljösamordnare, automationsansvar, dokumentationsgranskning med sikte på kodgenerering i närtid, så ligger den avancerade kursen närmare till hands.

Bland annat för att ha grepp om olika UML-notationens styrkor och svagheter, för att jämföra med dels ev DSL (domänspecifika modelleringsspråk) och dels specifika lösningar som bygger in högre abstraktionsnivå direkt i programspråket, t ex som deklarativa uttryck och färdiga komponenter. Även i det senare fallet är det lika viktigt att väga styrkor och svagheter (leverantörsberoende, dyrare migrering m m) mot varandra.          

Milan Kratochvil

Lärare på Informator, modellerings- och arkitekturkonsult på Kiseldalen.com,

huvudförfattare: UML Extra Light (Cambridge University Press) och Growing Modular (Springer).

Advanced UML2 Professional (OCUP cert-nivå 3 av 3).

Milan samarbetar med Informator sedan 1996 inom Arkitektur ( T1101 , T1430) och Modellering (T2715, T2716).

x

Läs mer

Agile modeling and architecture under paradigm diversity

Many expert notes here mention non-relational paradigms, and these coincide with non-procedural trends in programming — in contrast to a past of procedural/imperative languages hosting non-procedural SQL-only statements; a fine combination in theory, yet often misinterpreted by host-language programmers who habitually hand-wrote loops reading one table line at a time and thus duplicated (in the host language) the tedious work that SQL and RDBMS engines had automated in the first place.

Today, there are several programming paradigms to choose from, in both data-intensive applications and signal-intensive (e.g. the Ericsson ERlang language and its spinoffs), as well as data-architecture paradigms. Also, architects now apply several integration patterns, apart from shared data stores. These trends largely match with the Object Management Group’s initial mission from 1990: to “narrow the communication gap” between IT and business by lifting the level of abstraction. At the same time however, the diversity and rapid pace of hardly-predictable change have made it more difficult to revise the corresponding standards in time.

Given an agile approach, architects communicate via lean documents that address known roles and their expected information needs, although the ever-expanding architectural landscape makes even these needs change faster.

The detailed notation bloat within the Unified Modeling Language often gets in their way (even the slimmed, OMG UML 2.5 spec is still 800 pages), because abstraction is key in the job description of an architect.

The difference in abstraction between two sequence diagrams (architecture level versus detailed level) is visible in this note even if you don’t read a Nordic language. A flight-price calendar on an airline-booking page is put together there, day by day. The text points out that the UML lifeline decomposition (resulting in the detailed right-hand part of the second diagram) is of little importance to architects and can be misleading too, because nobody knows in design time what the actual scenario path will look like, in run time, after access optimization by the DBMS. Given a non-procedural platform, we can suppress the detail without loss of clarity in communication (with most roles).

Microsoft’s architect Steve Cook mentioned already five years ago (on his MSDN blog ) that even mainstream OO PLs are all poorly represented by “vanilla UML class diagrams”.

That’s very true in today’s multitude of paradigms, and evolution of high-level constructs within Java, Dotnet/LINQ, and more (prof. Reichenbach’s big-data article here mentions that declarative languages “can offer the quickest path from idea to implementation”). With multicore and multithread, non-procedural languages also facilitate automation by compilers, which makes them less prone to programmer error than procedural ones. To architecture, they add a reasonably restricted vocabulary (fewer ways to do one thing), improving semantic coherence and standards (and thereby maintainability and quick upgrades, to make the enterprise more responsive).

I recently re-read Steve Cook's and Ivar Jacobson's article about the “road ahead” toward a slim UML3 kernel plus an extension mechanism (2010, on Dr Dobbs), and it makes even more sense with today’s diversified architectural toolbox. They are met with sympathy — but still a way to go, down the standardization road.

Summing up, today’s diversity of integration patterns, programming paradigms, and data-architectures (including in-memory storage & computing) transfers and encapsulates a wider variety of detail into extended platforms and infrastructure. This in turn gives cause for a shift of emphasis in modeling, from “vanilla-design detail” and “vanilla-code generators” to an architect level in encapsulation (of, typically, procedural detail), matching with the Object Management Group’s initial mission.   

// by Milan Kratochvil,  Trainer at Informator, and senior modeling and architecture consultant, Kiseldalen.com, Author (w. Barry McGibbon) of UML Extra Light (Cambridge University Press). Milan and Informator collaborate since 1996 on modelling, UML, architecture, requirements, analysis and design. In June, you can meet Milan at Architecture ( T1101 , T1430 ) or Modeling courses ( T2715, T2716 , in Swedish).

Posted by courtesy of  ODBMS.ORG —The Resource Portal for Big Data, New Data Management Technologies and Data Science

Läs mer

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.

Läs mer

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.

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

Samarbetar med Informator sedan våren 1996 inom modellering, UML, krav, analys och design. Håller f.n. kurser i Arkitektur, i modellering:

T2715,  Agile Modellering med UML

T2716,  Avancerad objektorientering med UML

och även Informators fullsatta Frukostseminarium om användningsfall.

/Milan Kratochvil

Läs mer