Architecture, Design Patterns and Faithful Implementation

1. Architecture, Design Patterns and Faithful Implementation David Woollard

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

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

4. 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?

5. Examples of Past Experience Deep Domain-Specific Software Architectures Architectural Patterns Application Domain Knowledge Styles (Program) Design Patterns Shallow Programming (language level) Scope Application Structure System Structure

6. 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)

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

8. Design Patterns: Singleton Method • In the singleton method, only one object is instantiated for the whole program • Introduces global state • Easily abused!

9. Design Patterns: Decorator Method • Used to override the default behavior of an object/component • Steps in setting up a decorator: • Create a decorator class by sub-classing a component • Add a reference to the original component as part of the decorator • Override any custom behavior, and call the original component for default behavior

10. Design Patterns: Facade Method • Simplify multiple disjoint interfaces into a single class • Classic use of abstraction to interface to multiple libraries, objects, etc.

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

12. 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 RPC RPC Server

13. 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 Filter Filter Filter Pipe Pipe

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

15. 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 RPC RPC RPC Event Server

16. 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 Request Request Front Tier Middle Tier Back Tier Reply Reply

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

18. SWSA: A DSSA for Scientific Software

19. 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”

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

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

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

23. CAS-Curator Example

24. CAS-Curator Example View Controller Model

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

26. CAS-Curator With Roles Considered an up-call in layered architectures, But allowable in favor of a single source of security information LDAP

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