Upload
vivien-murphy
View
215
Download
1
Tags:
Embed Size (px)
Citation preview
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