Architecture, Design Patterns and Faithful Implementation David Woollard University of Southern California Software Architecture Group NASA 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 Architectural Patterns Domain-Specific Software Architectures Application Domain Knowledge Scope Shallow Deep Programming (language level) Application Structure System Structure

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 RPC Server 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 Pipe Filter Pipe 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 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 Event Distributor Event Server RPC

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 TierMiddle TierBack Tier Request Reply

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

Model View 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 LDAP Considered 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.