Architecture, Design Patterns and Faithful Implementation

David WoollardUniversity of Southern California

Software Architecture GroupNASA Jet Propulsion Laboratory

Data Management Group

Faithful Implementation, Architecture and Design Patterns

(and Frameworks)

Lessons Moving Forward (Recap)• Patterns are helpful at the developer level• Styles are good sources of inspiration, but one size

does not fit all– Complex software systems often exhibit multiple styles– Breaking style rules can be OK, but know why you are doing it and

make sure its for a good reason.

• Requirements drive design and vice versa• How to move forward?– Faithful Implementation... But that’s for the next lecture.this lecture.

Goals of This Lecture• In this lecture, we will cover:– Faithful Implementation– Mapping the Architecture– The Role of Middleware/Frameworks– In Depth: How To Build A GUI– A Technologist’s Perspective: Building a Better

Web Application– Lessons Moving Forward

Faithful Implementation• All of the structural elements found in the

architecture are implemented in the source code• Source code must not utilize major new

computational elements that have no corresponding elements in the architecture

• Source code must not contain new connections between architectural elements that are not found in the architecture

• What if we deviate from this?

Unfaithful Implementation• The implementation does have an architecture– It is latent, as opposed to what is documented

• Failure to recognize the distinction between planned and implemented architecture– Robs one of the ability to reason about the

application’s architecture in the future– Misleads stakeholders regarding what they believe

they have as opposed to what they really have– Makes any development or evolution strategy that is

based on the documented (but inaccurate) architecture doomed to failure

Implementation Strategies• Generative techniques– e.g. parser generators

• Frameworks– collections of source code with identified places where the

engineer must “fill in the blanks”• Middleware– CORBA, DCOM, RPC, …

• Reuse-based techniques– COTS, open-source, in-house

• Writing all code manually

The Mapping Problem• Architecture-based development provides a unique twist

on the classic problem– It becomes, in large measure, a mapping activity

• Maintaining mapping means ensuring that our architectural intent is reflected in our constructed systems

DesignDecisions

ImplementationArtifacts

What Are We Mapping?• Components and Connectors– Partitions of application computation and

communication functionality– Modules, packages, libraries, classes, explicit

components/connectors in middleware• Interfaces– Programming-language level interfaces (e.g.,

APIs/function or method signatures) are common– State machines or protocols are harder to map

What Are We Mapping?• Configurations– Interconnections, references, or dependencies between

functional partitions– May be implicit in the implementation– May be externally specified and enabled through

middleware– May involve use of reflection

• Design rationale– Often does not appear directly in implementation– Retained in comments and other documentation

What Are We Mapping?• Dynamic Properties (e.g., behavior):– Usually translate to algorithms of some sort– Mapping strategy depends on how the behaviors are

specified and what translations are available– Some behavioral specifications are more useful for

generating analyses or testing plans• Non-Functional Properties– Extremely difficult to do since non-functional properties

are abstract and implementations are concrete– Achieved through a combination of human-centric

strategies like inspections, reviews, focus groups, user studies, beta testing, and so on

Risking Drift: One-Way Mapping• Your understanding of the architecture will

change as you develop an implementation– You will know more– Your stakeholders will know more– Time/Budget/Personnel/Etc. changes

• Keeping the implementation faithful is a challenge– If the implementation and architecture are not in

sync, you’ve drifted

A Better Way: Two-Way Mapping• Both a technical and a managerial problem– Must understand how a change in the

implementation impacts architecture-level design decisions

• Two strategies:– Limit changes– Change either, but require round-trip mappings and

maintenance strategies• Tools can help• Peer reviews are better

Implementation Strategies Revisited• Generative techniques• Frameworks• Middleware• Reuse-based techniques• Writing all code manually

- Normally impractical

-Probably not looking hard enough

Reused-based Techniques• Out of the scope of this lecture• Probably only a partial solution• Beware architectural assumptions:– David Garlan, Robert Allen and John Ockerbloom.

Architectural Mismatch: Why Reuse is so Hard. In IEEE Software, Vol. 12(6):17-26, 1995.

Middleware vs. Frameworks• Implementation frameworks are forms of

middleware– There’s a subtle difference in how they emerge and

develop– Middleware generally evolves based on a set of

services that the developers want to have available• E.g., CORBA: Support for language heterogeneity, network

transparency, portability– Frameworks generally evolve based on a particular

architectural style that developers want to use• Why is this important?

Middleware vs. Frameworks• By focusing on services, middleware developers often make

other decisions that substantially impact architecture• E.g., in supporting network transparency and language

heterogeneity, CORBA uses RPC– But is RPC necessary for these services or is it just an enabling

technique?• In a very real way, middleware induces an architectural style

– CORBA induces the ‘distributed objects’ style– JMS induces a distributed implicit invocation style

• Understanding these implications is essential

More On Frameworks• Frameworks are meant to assist developers in

following a style– But generally do not constrain developers from violating a style if they

really want to

• Developing applications in a target style does not require a framework– But if you follow good software engineering practices, you’ll probably

end up developing one anyway

• Frameworks are generally considered as underlying infrastructure or substrates from an architectural perspective– You won’t usually see the framework show up in an architectural

model, e.g., as a component

In Depth: How to Build A GUI• Lots of choices in frameworks– Some are language-dependent– Some are application-dependent– Some are platform-dependent

• Let the architecture drive implementation– At least initially

Architecture of GUIs• Popular Architectures:

– Forms and Controls– Model-View-Controller– C2 (i.e., Event-Based)

• Forms and Controls:– Form is application-specific, but

it uses controls that are generic– Data-binding between session

state and underlying records (DB

– Common architecture to applications developed in builders and web frameworks (Visual Basic, VC .Net, Xcode, etc.)

Controls have program functionality embedded in them.

Form provides application specific layout.

Architecture of GUIs• Popular Architectures:

– Forms and Controls– Model-View-Controller– C2 (i.e., Event-Based)

• Model-View-Controller:– Specialization of the layered

architecture– Often implemented with call-backs– Model: underlying object

representation– View: presentation of object to the

user– Controller: responds to events from

view and changes model– Architecture of Java Swing, web

frameworks like Ruby on Rails, Trails

ViewModel

Controller

Observers are registered to handle events (i.e., MouseListener)

*

2. MouseListener eventHandler is triggered via function call-back

3. Underlying model is changed

1. User clicks on a GUI element

Architecture of GUIs• Popular Architectures:

– Forms and Controls– Model-View-Controller– C2 (i.e., Event-Based)

• C2:– Event-based architecture developed

by Richard Taylor, Neno Medvidovic, et. al. at UC Irvine

– A hierarchical network of concurrent components

– Communication is by event on ports

– Components request services “above,” reply to components “below.”

Component A Component B

Component C

Component D

View One View Two

Mediator

Repository

Request

RequestReply

Reply

Components only have one request port and one reply port

Platform Independent GUIs• Flash/Flex (Macromedia/Adobe)

– Requires a browser plug-in– Supports vector graphics,

animations, video– Scriptable (ActionScript,

PHP compatible)– Basically a front-end

Platform Independent GUIs

• AJAX*– Agglomeration of readily

-supported technologies(Javascript & XML)

– Dynamic Content (Allows callbacks and updates)

– Supports similar interaction as Flash without plug-in or expensive developer tools

* Yes, I know I am using framework loosely

Platform Independent GUIs• Plone

– Content Management System– Developers supply object description,

basic functionality comes for free– Zope - Object DB (Model)– No plug-in,

browser-based (View)– Python scripting

(Controller)

Platform Independent GUIs• Ruby on Rails

– Convention over Configuration– Reflection & discovery, not XML– VERY little coding– MySQL DB (Model)– No plug-in, browser-based (View)– Ruby (Controller)

Platform Independent GUIs

• Java Swing Application– Java - OS independent– Follows model-view-controller– Base classes for:

• GUI elements• event-listening• Developer inherits from base

classes to provide applicationspecific functionality

Non-Web Based

Platform Dependent GUIs• Cocoa GUI Builder

– Mac OS-X GUI builder– Xcode & Interface Builder tools– Form-Control pattern– Element drag-and-drop– Support for Objective C

& Java

Platform Dependent GUIs• .Net Framework

– Windows GUI builder– Visual Studio tools– Form-Control pattern– Element drag-and-drop– Support for C#

A Technologist’s Perspective• Movie Time!• http://oodt.jpl.nasa.gov/better-web-app.mov

• Sean Kelly, a JPL Technologist, discusses different web application development frameworks.

Lessons Moving Forward• Faithful implementation is essential to the

development phase– Mapping can be one-way or round trip– Round trip mappings are a challenge, but ultimately less

risky - avoid architecture drift• Middleware and Frameworks imply an architecture– Choose your architecture first

• Not all frameworks are created equal– Look for compliant architecture, ease of use, fun– Avoid unnecessary sit-ups