Arkitektur, UML, och 3 varianter av ett vanligt Designmönster: Proxy

I min gästblogg i september nämnde jag i förbigående att några få mönster kvalar in som både design och arkitektur. Proxy (beskriven redan i boken Design Patterns av Gamma & GoF) är ett enkelt exempel på det. Skillnaderna mellan dess tre vanligaste varianter är små. Ändå prioriterar de var sina kvalitetsegenskaper (QA) och därmed också arkitekttaktiker.

Bild: Klassdiagram i UML för Proxy Design Pattern (strukturen liknar Decorator, men syftet är något helt annat).  

Man börjar med frågan: hur mycket av det här har vi redan i  plattformen, ”på burk”? Först sedan kan det bli aktuellt att välja variant och att ev anpassa den vidare. Arkitekten tar även hänsyn till runtime, möjliga svagheter i samband med uppgraderingar, säkerhetshot, belastningstoppar, fel i handhavande osv.

Variant 1: Remote Proxy

Klassikern i distribuerade system, där den ofta tillhör ”rördragningen” i plattformen/mellanvaran, så att applikationsutvecklare slipper göra den för hand. Ett lokalt objekt (av klassen Proxy i diagrammet) företräder ett avlägset (av VerkligOrder), som kan ligga i en annan komponent, namespace, server, osv. Ett anrop på Proxyn vidarebefordras av den till rätt ställe, utan att avsändaren behöver känna till hur (det är Proxyns ansvar). De som gått kursen Agil Modellering med UML kommer nog ihåg sekvensdiagramsövningen, där bankomaten ”pratar” med sin bank-proxy, och slipper ”se” ”verkliga banken” (kommunikationen är inkapslad i proxyn).

Kvalitetsegenskaper: interoperabilitet (taktik: skräddarsy gränssnitt), modifierbarhet (kapsla in, använd mellanhand, begränsa beroenden, senarelägg bindningstid), testbarhet (begränsa komplexitet, abstrahera datakällor, förenkla sandboxing och fakes på delsystem- eller komponentnivå).        

Variant 2: Virtual Proxy

En mer kompetent ställföreträdare, för ett resurskrävande objekt. Minimerar antalet (resurskrävande) instansieringar, och undviker dem helt i enklare fall, genom att utföra ofta anropade operationer själv lokalt (i proxyn, i stället för att skicka vidare).

Anta i diagramexemplet att orderobjekten ligger i sina respektive län (t ex 1 server per län, alternativt index i cache per län). Om aktuellt värde i parametern(typ) till operationen extraRabatt betyder ”kampanj: efterskänk frakt på alla order i Norrbotten” så slipper Proxyn instansiera objekt från andra län. Proxyn kan alltså (i förbehandlingssteget i metoden) filtrera bort onödiga instansieringar. Om varje proxyobjekt dessutom byggs på med ofta efterfrågat orderspecifikt data (som tex orderdatum och summa) kan proxyn avlasta ordern från alla enkla anrop, och instansiera den bara i mer sällsynta komplicerade fall. Dvs dels liknande fördelar som med typen Lazy i dotnet, dels anpassningar från fall till fall.

Kvalitetsegenskaper: tillgänglighet (taktik: redundans), prestanda (minska resursbehov i enkla anrop, öka resurseffektivitet), modifierbarhet (kapsla in, begränsa beroenden, senarelägg bindningstid), testbarhet (abstrahera datakällor, förenkla sandboxing och fakes på delsystem- eller komponentnivå).       

Variant 3: Protection Proxy

Surrogat för eller säkerhetshölje för ett annat objekt. I likhet med Virtual kan den besvara en del (mindre känsliga) anrop själv. Dessutom styr den åtkomst till objektet (tex till verkligOrder) baserat på accessrättigheter. I exemplet skulle det kunna vara fritt fram att tex se orderdatum givet ett ordernr (proxyn kan verkställa själv mha ett index), men för att visa mer (dvs att få ”titta in i ordern”) skulle proxyn först göra en behörighetskontroll.

Kvalitetsegenskaper: säkerhet (taktiker: upptäck intrång, verifiera aktörer, begränsa åtkomst, begränsa exponeringsytan utåt), prestanda i mindre känsliga anrop (minska resursbehov, öka resurseffektivitet).      

Ett helt kapitel om Design Patterns finns bl a i kursen T2716 Avancerad modellering med UML. Kvalitetsegenskaper (QA) går man igenom i kursen T1101 Architecture Fundamentals. 

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

Huvudförfattare: Growing Modular: Mass Customization of Complex Products, Services and Software samt UML Xtra 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 modellering, grundläggande arkitektur, Modular Product Line Architecture (T1430), och 2013 höll han också Informators fullsatta Frukostseminarium om användningsfall.