2 varianter, 1 Design Pattern - blir fler än 3 punkter för arkitekten

I min gästblogg i oktober, om att avlasta UML från ”notation bloat”, nämnde jag behovet av abstrakt arkitekttänkande.

Designmönster lyfter i sig abstraktionsnivån (i likhet med andra mönster) utöver notationen, samtidigt som man behöver arkitekturtänkande för att välja ett passande mönstervariant, och för att göra egna anpassningar (eller låta bli).

Det första man alltid frågar sig är: hur mycket av det som mönstret löser har vi (eller plattformen) redan färdigt ”på burk”? Först sedan funderar man på möjliga varianter. Ett mönster löste ett vanligt praktiskt problem när det publicerades (och därför fick det den spridning det har), men sedan dess har ju många plattformar löst och kapslat in en hel del sådant som applikationsutvecklare kan slippa göra för hand; vilket leder in på samma spår som mitt notations-inlägg i oktober, fast nu på Pattern-nivån.

Ett välkänt mönster är State: ett vanligt objekt (”context-objekt”, i diagrammet nedan en order) kopplas ihop med 1 separat state-objekt, vilket får det att fungera utåt som om objekt kunde byta klass (oavsett plattform – det är fritt fram för den som växte upp med Smalltalk80 att kalla det ”att härma Smalltalks Tillståndsklasser för hand på andra plattformar”). Om vi inte redan har den möjligheten ”på burk” så är vi framme vid tänkbara anpassningspunkter. En sådan är multipliciteten åt andra hållet på Klassdiagrammet, dvs på Context-sidan: ska ett State-objekt vara dedicerat till exakt 1 Context-objekt (det vanliga, alltsedan Gamma & GoF.) eller ska man tillåta att flera Context-objekt servas av samma State-Objekt (dvs multiplicitet ”*” ) ?

Sett med utvecklarglasögon behöver flera villkor vara uppfyllda för att ”*” skall komma ifråga: inga attribut i State-objektet (frånsett static, som t ex text för State-specifikt felmeddelande), möjlighet att vid nästa tillståndsövergång enkelt länka om objektet till nästa State-objekt, osv. Med arkitektglasögon ser man ytterligare villkor som bör vara uppfyllda: inga stora belastningstoppar (köer) på State-objektet, fördelarna med att byta minnesbehov (då multiplicitet 1 till 1 medförde fler State-objekt i runtime) mot ev processortid ska vara större än nackdelarna, inga ”single point of failure” problem, enkelt att göra State-objekt persistenta i minnet, ”D:et” i SOLID (Dependency inversion/injection, med t ex en Callback, eller direkt mha plattformen), replikering när man skalar ut (t ex ytterligare servrar), tillräckligt förklarande dokumentation för att utvecklare skall förstå anpassningen även framöver, osv. Även om notationen skiljer ”bara” ett tecken som i exemplet ( ”*” i stället för ”1”), så är konsekvenserna av anpassningar klart större än så.

   

Som applikationsutvecklare fokuserar man oftast på design och källkod; arkitekturtänk tar även med runtime-miljö, samspel med verksamheten och produkten, risken för svaga punkter i samband med uppgraderingar, säkerhetshot, belastningstoppar, fel av användaren m m, allt i ljuset av prioriterade krav på funktionalitet resp på övrig kvalitet (jfr t ex  40 ”kvalitetskarakteristika” i ISO 25010-bilden i min gästblogg den1 september).

En annan och mer långtgående anpassning av samma Design Pattern (State) kan man ev välja i en övning på kursen T2716 Avancerad modellering med UML (sekvensdiagram, avboknings-scenario med kö/väntelista till det som bokats av), som ett möjligt designalternativ till att byta state-objekt på vanligt sätt.   

// Milan Kratochvil konsult, Kiseldalen.com och kursledare hos Informator inom IT-arkitektur.

Huvudförfattare: GrowingModular: Mass Customization of Complex Products, Services and Software samt UMLXtra Light: How to Specify Your SW Requirements

UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)

Milan samarbetar med Informator sedan våren 1996 inom modellering, UML, krav, analys, arkitektur och design. Håller f.n. kurser i grundläggande Arkitektur, Modular Product Line Architecture (T1430), i modellering (T2715, T2716), och 2013 höll han också Informators fullsatta Frukostseminarium om användningsfall.