Arkitekturprinciper för informationsöverlägsenhet i framtidens ...

Sett i det processtekniska perspektivet blir det viktigt att under utvecklingens gång,
och inte minst även sedan systemet tagits i drift, kunna ta tillvara nya system,
produkter och “halvfabrikat” som kommer ut på marknaden medan den egna
systemutvecklingen pågår. En grundläggande fråga blir om och i så fall hur man kan
utforma sin utvecklingsprocess och sina etappvisa system så att integration av såväl
redan existerande system, egna eller andras, som på marknaden nytillkommande
produkter underlättas väsentligt. En utvecklingslinje som är avsedd att underlätta detta
är forskningen om s k medlarsystem (se avsnitt 3.2.6), en annan framväxten av
infrastruktur för dynamiska komponentbibliotek (mäklarsystem, se avsnitt 4.5) och en
komponentmarknad för programvara (avsnitt 0).
I en artikel med titeln Reevaluating the Architectural Metaphor: Toward Piecemeal
Growth skriver J O Coplien [16] provokativt att termen Software Engineering som
myntades av Peter Naur 1968 olyckligtvis öppnade dörren för hårdvarutekniska
begrepp i samband med programvaruutveckling. Därigenom ökade programvaruarkitekternas
intresse för formalism och matematisk stringens, vilket bl a ledde till
utveckling av språk för arkitekturbeskrivning, formell konstruktionsnotation och
formell metodik. I början av 80-talet började objektorienteringsmetodiken dra till sig
intresse 3 och den erbjöd nya verktyg för att fånga abstraktioner som inte härrörde från
matematik eller logik. Objektorienteringsparadigmens största värde är att den ställde
människans vardagliga begreppsbildning i centrum för konstruktionsarbetet.
Programmerare relaterar till de resurser och apparater som de arbetar med dagligen,
och objektorientering blev en väg att beskriva och utveckla programvara som
återspeglar denna förståelse. Coplien hävdar att arkitektur inte så mycket handlar om
programvaran själv som om människorna som utvecklar denna programvara.
Programvaruarkitekturens grundbegrepp, som koppling och kohesion, handlar inte om
koden utan om dess organisation, en organisation som i mycket återspeglar
utvecklingsteamets egen.
Nästa trend inom praktisk programvaruarkitektur är enligt Coplien mönster (patterns)
[17], med vars hjälp den vanliga programmeraren återfår sin värdighet och erkänns
som källa till värdefulla arkitektoniska bidrag. Ledningsmetoder och processer drar till
sig ett snabbt ökande intresse, vilket visar sig i en explosion av processtandarder och
ett växande antal böcker om ledning av programvaruutveckling. En rörelse bort från
formalism och stringens, från centraliserad arkitektur mot gradvis tillväxt av
programsystem inom ramen för en kollektiv process är vad Coplien tycker sig se. Av
mycket att döma kommer programvaruindustrin alltmer till insikt om att dessa
fenomen är verkligheten bakom de historiska illusionerna om strikt formalism och
mästerlig planering. Programvaruutveckling sker de facto alltid genom gradvis tillväxt
och sällan på en grund av genomgripande planering. Detaljplanerad utveckling kan
leda till tekniska problem eftersom det är omöjligt att förutsäga hur ett programavsnitt
kommer att användas i framtiden, men också till samverkansproblem i
organisationen eftersom en fullständigt planerad utveckling alienerar de utvecklare
som inte också är planerare.
3
i USA; i Europa och särskilt i Skandinavien hade konceptet om än inte själva termen varit i bruk ett
helt decennium.
- 41 -