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

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

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

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

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

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

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

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

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