and Faithful Implementation

viraginityfumblingΛογισμικό & κατασκευή λογ/κού

2 Νοε 2013 (πριν από 3 χρόνια και 5 μήνες)

47 εμφανίσεις

Architecture, Design Patterns
and Faithful Implementation


David Woollard


University of Southern

California

Software Architecture Group


NASA 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


Design

Decisions

Implementation

Artifacts

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


View

Model

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

Request

Reply

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 application

specific 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