Architecture, Design Patterns and Faithful Implementation

David WoollardUniversity of Southern California

Software Architecture GroupNASA Jet Propulsion Laboratory

Data Management Group

Goals of This Lecture• In this lecture, we will cover:– Terminology: Architecture, Styles, Patterns, etc.– Basic Examples: Gang of Four, Canonical Styles– Considerations: Requirements & Design Interplay – Rich Examples: Metadata Repository & Data

Curation Application– When To Break the Rules– Lessons Moving Forward

Architecture is Pervasive• All software systems have an architecture• All software systems have an architect• Architecture is NOT a single phase– Design != Architecture

• Architecture is a process and artifacts

Conceptual Design Tools• Abstraction and Terminology– What are the fundamental concepts in your

system?• Separation of Concerns– Isolate likely change– e.g., components & connectors, object orientation

• Refined Experience– What have other architects found useful?

Examples of Past Experience

(Program)Design

Patterns

Styles

ArchitecturalPatterns

Domain-Specific Software Architectures

Appl

icati

on D

omai

nKn

owle

dge

Scope

Shallow

Deep

Prog

ram

min

g(la

ngua

ge

leve

l)

Appl

icati

onSt

ruct

ure

Syst

emSt

ruct

ure

Design Patterns• Low level (i.e., language level, small scope)• Developer constructs• Well documented in:

Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (Gang of 4 Book)

Design Patterns: Factory Method• The factory method allows

the developer to specify an interface but to defer that actual instantiation to subclasses

• Often used in Framework development

Design Patterns: Singleton Method• In the singleton method,

only one object is instantiated for the whole program

• Introduces global state• Easily abused!

Design Patterns: Decorator Method• Used to override the default

behavior of an object/component

• Steps in setting up a decorator:

1. Create a decorator class by sub-classing a component

2. Add a reference to the original component as part of the decorator

3. Override any custom behavior, and call the original component for default behavior

Design Patterns: Facade Method• Simplify multiple disjoint

interfaces into a single class• Classic use of abstraction to

interface to multiple libraries, objects, etc.

Styles vs. Patterns• Both are a known set of design decisions– Remember that every system has an architecture

• Styles are more restrictive to a particular development context– REST, Client-Server

• Patterns are general and are parameterized for a context – Three-tier systems

Styles: Client-Server

• Description: Clients send requests to servers, which perform the required function and replies as with requested information. Clients initiate interaction

• Basic Example: Web Browser

Component Component Component

RPC

Server

RPC RPC

Styles: Pipe and Filter

• Description: Separate programs, or filters, are executed, potentially concurrently with data streams connecting the output of one filter to the input of the next.

• Basic Example: The Unix Pipe

PipeFilter PipeFilter Filter

Styles: Blackboard

• Description: Independent components communicate exclusively through a shared global data repository, or blackboard.

• Basic Example: Heuristic Problem Solving in A.I.

Component Component Component

Data Access

Blackboard

Styles: Publish-Subscribe

• Description: Subscribers register/deregister for specific messages or content. Publishers maintain a list of subscribers. Content-based routing is possible.

• Basic Example: Multiplayer networked games, news

Subscriber Subscriber Subscriber

Event Distributor

Event ServerRPC

RPCRPC

Patterns: Three-tier

• Three tier systems are very common in business applications:– Front tier is traditionally focused on user interaction– Middle tier is business or application logic– Back tier addresses data access and persistence

Front Tier Middle Tier Back TierRequest Request

ReplyReply

Domain-Specific Soft. Arch.• A DSSA includes:– An architecture known to work well in a particular

domain– Reference components– Methodologies for applying the architecture to

particular problems.• Example: Scientific Software

SWSA: A DSSA for Scientific Software

Design in Context• Design – Requirements Interplay– Design forms the vocabulary for requirements– Requirements constrain design

• Two Examples for JPL:– A metadata repository called “CAS-File Manager”– A web-based data curation system called “CAS-

Curator”

CAS-File Manager Example• Requirements:

– The File Manager shall persist metadata in a database– The File Manager shall be runnable “out of the box”

• Note: I’ve made these up for the purposes of this class;)

• Design Solution:– Factory pattern & Abstract Factory pattern used to create multiple

persistence interfaces implementations specified at runtime– Two implementations were created:

• Database implementation that connected to an external database that would need to be configured separately

• Apache Lucene implementation that uses a flat-file indexing engine to build a local store of metadata documents.

CAS-File Manager Example

• The AbstractCatalogFactory in an interface that defines the factory creation methods for any Catalog Factory.

• The CatalogFactory is an interface class that defines the methods of any catalog implementation.

• The DataStoreCatalogFactory class defines the concrete construction methods for creating a catalog that persists metadata to a database.

• The DataStoreCatalog class defined the implementation of the catalog that persists metadata to a database.

CAS-Curator Example• Project Goals:– Develop a web-based application that allows a user to

manage data and associated metadata, including:• extracting metadata from existing products• changing metadata for previously stored products

– Language agnostic (front-end could be PHP, Javascript, etc.)

• Design Solution: Application of Three-tier Pattern– Web-based GUI – File Manager provides web service interface – File Manager persists metadata to an underlying database

CAS-Curator Example

CAS-Curator Example

ModelView Controller

When To Break The Rules• Remember - patterns and styles are abstractions– Design guides from past experience

• OK to deviate, but you should do so for a reason• Example: An existing layered architecture must add role-

based security.– LDAP is chosen as both the authentication and

authorization tool (single, gold standard).– All front-ends must support user authentication– Before any action is performed, the system must validate

that the user is authorized to perform the action.

CAS-Curator With Roles

LDAPConsidered an up-call in layered architectures,But allowable in favor of a single source of security information

Lessons Moving Forward• 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.