280 likes | 298 Views
This lecture covers terminology, examples of design patterns and architectural styles, considerations on requirements and design interplay, when to break rules, and more. Discover deep domain-specific software architectures, architectural patterns, and application domain knowledge. Dive into low-level design patterns, such as Creational, Structural, and Behavioral patterns. Learn about Factory Method, Singleton, Decorator, Facade, Observer design patterns, architectural styles vs. patterns, and the Three-tier pattern. Explore Client-Server, RPC, Pipe and Filter, Blackboard, and Publish-Subscribe architectural styles with basic examples. Uncover the importance of Domain-Specific Software Architecture (DSSA) and the Lunar Lander DSSA. Understand the interplay between design and requirements and how to apply the Three-tier Pattern in a real-world Web-based File Management System example.
E N D
Architecture and Design Patterns CSCI577A Fall2015 Kan Qi, Bo Wang
Goals of This Lecture • In this lecture, we will cover: • Terminology: Architecture, Styles, Patterns, etc. • Basic Examples: typical design patterns and architectural Styles. • Considerations & Example: Requirements & Design Interplay • When To Break the Rules • Summary • Workshop
Architecture is Pervasive • Architecture is NOT a single phase • Design != Architecture • Architecture is a process and artifacts • Requirements are essentially a set of design problems, while architecture refers to the process of solving, as well as the solution to, these problems • All software systems have an architecture • All software systems have an architect
Conceptual Design Methodologies • 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 Deep Domain-Specific Software Architectures Architectural Patterns Application Domain Knowledge Styles (Program) Design Patterns Shallow Programming (language level) Scope Application Structure System Structure
Design Patterns • Low level (i.e., language level, small scope) • Developer constructs • Creational • E.g. Factory Method, Singleton • Structural • E.g. Decorator, Facade • Behavioral • E.g. Observer
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 • In the singleton method, only one object is instantiated for the whole program • Introduces global state • Easily abused! • Ownership • Lazy initialization • Global access
Design Patterns: Decorator • 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
Design Patterns: Facade • Simplify multiple disjoint interfaces into a single class • Classic use of abstraction to interface to multiple libraries, objects, etc.
Design Patterns: Observer • Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
Architectural Styles vs. Patterns • Both are a known set of design decisions • Remember that every system has an architecture • Patterns are more restrictive to a particular development context • Three-tier. • Styles are general and can be parameterized for a context • Client-Server
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 Components: clients, server Connectors: 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 Components: filters Connectors: Pipes
Styles: Blackboard • Description: Independent components communicate exclusively through a shared global data repository, or blackboard. • Basic Example: Heuristic Problem Solving in A.I. Components: Functional units & Blackboard Connectors: Data Access
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, RSS feeds Components: subscribers, publishers Connectors: Network protocols, event bus
Patterns: Three-tier • Three tier systems are very common in business applications: • Front tier is traditionally focused on user interaction • Middle tier is business logic • Back tier addresses data access and persistence
Domain-Specific Soft. Arch. • A DSSA includes: • A reference architecture known to work well in a particular domain • Reference components, which contains reusable chunks of domain expertise. • Methodologies for applying the architecture to particular problems. • Example: Lunar Lander DSSA
A DSSA for Lunar Lander • Structural viewof Lunar LanderDSSA • Invariant withexplicit pointsof variation • Satellite relay • Sensors
Design in Context • Design – Requirements Interplay • Design forms the vocabulary for requirements • Requirements constrain design • One example to apply Three-tier Pattern: • Web-based File Management System. (WFMS)
WFMS 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 • Design Solution: Application of Three-tier Pattern • Web-based GUI • File Manager provides web service interface • An underlying database to persists data and metadata.
WFMS Example View Controller Model
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 Considered an up-call in layered architectures, But allowable in favor of a single source of security information LDAP
Summary • Design 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.
Workshop • Pick one Design patternwhich can be applied to your team project • Pick one Architectural style or pattern which can be applied to your team project • Explain why you make those decisions
Reference [1] David Woollard, Architecture, Design Patterns and Faithful Implementation [2] Richard N. Taylor, NenadMedvidovic, and Eric M. Dashofy, Architecture Styles [3] http://www.tutorialspoint.com/design_pattern/index.htm [4] https://sourcemaking.com/design_patterns [5] https://en.wikipedia.org/wiki/Software_design_pattern