1. Architecture, Design Patterns and Faithful Implementation
Architecture and Design Patterns
(and Frameworks)
Architecture, Design Patterns and Faithful Implementation
David Woollard
University of Southern California
Software Architecture Group
NASA Jet Propulsion Laboratory
Data Management Group

2. 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.

3. 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

4. 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?

5. 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

6. 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

7. 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
Design
Decisions
Implementation
Artifacts

8. What Are We Mapping? Components and Connectors Interfaces
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

9. What Are We Mapping? Configurations Design rationale
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

10. 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

11. 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

12. 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

13. Implementation Strategies Revisited
Generative techniques
Frameworks
Middleware
Reuse-based techniques
Writing all code manually
- Normally impractical
Probably not looking
hard enough

14. 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.

15. 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?

16. 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

17. 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

18. 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

19. 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.)
Form provides application specific layout.
Controls have program
functionality embedded in them.

20. Architecture of GUIs Popular Architectures: Model-View-Controller:
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
Observers are registered to
handle events (i.e., MouseListener)
2. MouseListener eventHandler
is triggered via function call-back
Controller *
Model
View
3. Underlying model
is changed
1. User clicks on a
GUI element

21. Architecture of GUIs Popular Architectures: C2: 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 D
Repository
Components only have one request port and one reply port
Reply
Request
Component C
Mediator
Request
Reply
Component A
Component B
View One
View Two

22. 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

23. 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

24. 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)

25. 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)

26. Platform Independent GUIs
Non-Web Based
Java Swing Application
Java - OS independent
Follows model-view-controller
Base classes for:
GUI elements
event-listening
Developer inherits from base classes to provide application specific functionality

27. 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

28. Platform Dependent GUIs
.Net Framework
Windows GUI builder
Visual Studio tools
Form-Control pattern
Element drag-and-drop
Support for C#

29. A Technologist’s Perspective
Movie Time!
Sean Kelly, a JPL Technologist, discusses different web application development frameworks.

30. 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