http://www.isr.uci.edu/

The Golden Spike: Finding Common Ground between

Software Architecture Research and Practice

Eric M. DashofyJune 8, 2004

http://www.isr.uci.edu/

Outline

What are the advantages of working to bring together research and practice?

What have the difficulties been in bridging the gap?

What can we do to improve collaborations?

What research directions can we pursue that will satisfy the goals of both researchers and practitioners?

http://www.isr.uci.edu/

A History Refresher The golden spike joined

the two halves of thetranscontinentalrailroad in Promontory, Utah in 1869

http://www.isr.uci.edu/

The Advantages of Collaboration Researchers are assisted in evaluating

and validating their research Find out what works Find areas for improvement

Practitioners get to evaluate new methods and techniques Improve processes Improve products

http://www.isr.uci.edu/

The Difficulties (Some) different goals

Researchers need to create and publish research results Practitioners need to create and ship products Researchers need to do something new Practitioners need to do something that works

(Some) different constraints Researchers desire

openness forpublication, widedissemination

Practitioners oftenneed exclusivity,e.g. for gov’trequirements

Artist’s Rendering of the Chunnel Effort

http://www.isr.uci.edu/

How can researchers and practitioners find common ground? Start small

Look for small opportunities to make a connection Researchers: Shouldn’t expect practitioners to

reorient their entire operation around the latest ideas Practitioners: Shouldn’t expect research ideas to be

fully formed and productized

Prepare for growth Both parties should prepare to capitalize on successful

efforts and be thinking of longer-term collaborations Be proactive in looking for win-win funding

opportunities

http://www.isr.uci.edu/

How can researchers and practitioners find common ground? Balance the use of well-worn/adopted

technologies with novel research approaches

Perpetually look for research areas that satisfy common and disparate goals Areas where there are important, open research

questions Areas where (incremental) improvements will make

an immediate difference Areas where there’s a lot of future potential

http://www.isr.uci.edu/

From a Software Architecture Perspective Design above the level of modules and

classes occurs But is not principled or adequately supported

Moving toward principled, supported design at this level has potential benefits: Better management of software evolution Better management of run-time changes

Potential for self-governed run-time changes Better ability to monitor, understand, analyze software Better ability to understand and explore tradeoffs

http://www.isr.uci.edu/

Key #1: Start Small with Incrementality All-or-nothing solutions are hard to justify

adopting For any complex

technology, anincrementaladoptionplan iscritical tosuccessfuladoption. XML

Structural Schemas

Type System

CM Schemas

ImplementationSchemas Syntax-based

Tools

(Apigen, Data BindingLibrary, ArchEdit)

Semantics-based Tools(Critics, Ménage, Archipelago, MAE, etc.)

Incr

ease

d A

dopti

on

http://www.isr.uci.edu/

Incrementality in ISR Architecture Technologies xADL 2.0

Adopt structural modeling Adopt our type system Adopt implementation mappings Adopt product variations (options and variants) Adopt product evolution (versioning)

Our tools Adopt tools for supporting the syntax of the notation Adopt tools for supporting the semantics of the

notation

http://www.isr.uci.edu/

Key #1: Start Small with Incrementality All-or-nothing problem domains are hard to

work on Applying new technologies or techniques to

complete, huge systems over multiple dimensions is infeasible

The full details of huge systems are often classified or proprietary

http://www.isr.uci.edu/

Key #2: Grow Big with Extensibility

Many research projectshave viewed extensibility as an afterthought

We have found that whenextensibility is a primary (or the first) concern, our ownlong-term research goalsmysteriously becomeeasier to achieve

Spending time developingthe extension mechanismsfirst pays dividends xArch – Run-time

(Architectural Instances Core)

Types & Instances -Design-time

CM/Product Families(Versions, Options,

Variants)

ImplementationMappings

(Future Expansions)

http://www.isr.uci.edu/

Extensibility in ISR Architecture Technologies xADL 2.0

Chose and designed the extension mechanisms first Leveraged off-the-shelf technology (XML schemas) Language constructs designed to be extended

ArchStudio 3 Designed the framework first Chose a loosely-coupled architectural style for easy

extensibility

Archipelago Designed the plugin mechanism first Applied well-known design patterns pervasively

http://www.isr.uci.edu/

Key #2: Grow Big with Extensibility

Practitioners can look to open up areas of their development processes, particularly in the design phase

Prioritize extensibility in tool choices Look for and choose off-the-shelf tools that have

some open mechanisms and let researchers know these tools are important

http://www.isr.uci.edu/

Key #3: Play nice with other kids

As researchers, it’s our job to find deficiencies in existing technologies and techniques And remedy them

Compromise betweenbuilding a bettermousetrap and adaptingan existing one

http://www.isr.uci.edu/

Key #3: Play nice with other kids

Practitioners will continue using off-the-shelf technologies, but should be open to replacing or augmenting them with research technologies With the understanding that research techniques

and tools (especially) will not have evolved to the point of some of these well-seated standards

http://www.isr.uci.edu/

Key #4: Find a Common Area

The “holy grail” of research-practice collaborations in architecture has been a research area that Contains lots of interesting, “big” research questions Is valuable to practitioners in the short-term Is important to practitioners in the long-term Provides incremental opportunities for success

I believe such a research area is emerging and will fundamentally change the direction of architecture research

http://www.isr.uci.edu/

Systems Architecture Application of architecture techniques

to software systems in context Models aspects of the hardware that affect system

qualities Models quantifiable, analyzable aspects of software

components and connectors Provides strong traceability to implementation Facilitates powerful tradeoff analysis Facilitates multi-level understanding of complex

systems

http://www.isr.uci.edu/

Systems Architecture

PhysicalElements

SoftwareElements

ImplementationMappings

ImplementedElements

Requirements

Systems Architecture

http://www.isr.uci.edu/

Systems Architecture

PhysicalElements

SoftwareElements

ImplementationMappings

ImplementedElements

Requirements

SingleBoard

Computer

LegacySystem DBMS

NIC

(offboard)

http://www.isr.uci.edu/

Systems Architecture

PhysicalElements

SoftwareElements

ImplementationMappings

ImplementedElements

Requirements

SingleBoard

Computer

LegacySystem DBMS

NIC

(offboard)

TPS = 200MaxTables = 255MaxRecords = 64K

OS = VMSProcessor = 68KMhz = 40RAM = 4M

OS = QNXProcessor = PPCMhz = 500RAM = 256M

Media = EthernetBandwidth = 10Mbps

Link = PCIBusSpeed = 100Mhz

http://www.isr.uci.edu/

Systems Architecture

PhysicalElements

SoftwareElements

ImplementationMappings

ImplementedElements

Requirements

http://www.isr.uci.edu/

Systems Architecture

PhysicalElements

SoftwareElements

ImplementationMappings

ImplementedElements

Requirements

Footprint = 256KPeriod = 1.0 secPowerUse = .02W

Type = BusFootprint = 4KPeriod = 0.2 secPowerUse = .01W

http://www.isr.uci.edu/

Systems Architecture

PhysicalElements

SoftwareElements

ImplementationMappings

ImplementedElements

Requirements

Footprint = 256KPeriod = 1.0 secPowerUse = .02W

-OR-

FootPrint = 512KPeriod = 0.5 secPowerUse = .03W

http://www.isr.uci.edu/

Systems Architecture

PhysicalElements

SoftwareElements

ImplementationMappings

ImplementedElements

Requirements UML?

Mapped to components?

Generated? Extended

with propertiesgarnered from the architecture?

http://www.isr.uci.edu/

ISR Technologies and Systems Architecture ISR technologies map well onto needs

of systems engineering Extensible notations

Allow the addition of new views Allow the modeling of new types of properties

Adaptable environments and editors Allow for addition of new semantics and diagrams

Strong focus on product-line modeling and sculpting Required for expressing and managing tradeoffs

Leverage off-the-shelf technologies Needed to integrate in larger processes

http://www.isr.uci.edu/

Summing Up

Start out small Incrementality

Grow big Extensibility

Play nice Open technologies, tools, and processes Integrate where possible

Look for opportunities Systems architecture will provide a plethora of

mutually beneficial research endeavors