1. University of Southern California Center for Systems and Software Engineering Architecture and Design Patterns CSCI577A Fall2015 Kan Qi, Bo Wang

2. University of Southern California Center for Systems and Software Engineering 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

3. University of Southern California Center for Systems and Software Engineering 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

4. University of Southern California Center for Systems and Software Engineering 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?

5. University of Southern California Center for Systems and Software Engineering 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

6. University of Southern California Center for Systems and Software Engineering 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

7. University of Southern California Center for Systems and Software Engineering 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. University of Southern California Center for Systems and Software Engineering 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

9. University of Southern California Center for Systems and Software Engineering Design Patterns: Decorator 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

10. University of Southern California Center for Systems and Software Engineering Design Patterns: Facade Simplify multiple disjoint interfaces into a single class Classic use of abstraction to interface to multiple libraries, objects, etc.

11. University of Southern California Center for Systems and Software Engineering 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.

12. University of Southern California Center for Systems and Software Engineering 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

13. University of Southern California Center for Systems and Software Engineering 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

14. University of Southern California Center for Systems and Software Engineering 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

15. University of Southern California Center for Systems and Software Engineering 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

16. University of Southern California Center for Systems and Software Engineering 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

17. University of Southern California Center for Systems and Software Engineering 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

18. University of Southern California Center for Systems and Software Engineering 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

19. University of Southern California Center for Systems and Software Engineering A DSSA for Lunar Lander Structural view of Lunar Lander DSSA Invariant with explicit points of variation – Satellite relay – Sensors

20. University of Southern California Center for Systems and Software Engineering 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)

21. University of Southern California Center for Systems and Software Engineering 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.

22. University of Southern California Center for Systems and Software Engineering WFMS Example

23. University of Southern California Center for Systems and Software Engineering WFMS Example Model View Controller

24. University of Southern California Center for Systems and Software Engineering 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.

25. University of Southern California Center for Systems and Software Engineering CAS-Curator With Roles LDAP Considered an up-call in layered architectures, But allowable in favor of a single source of security information

26. University of Southern California Center for Systems and Software Engineering 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.

27. University of Southern California Center for Systems and Software Engineering Workshop Pick one Design pattern which 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

28. University of Southern California Center for Systems and Software Engineering Reference [1] David Woollard, Architecture, Design Patterns and Faithful Implementation [2] Richard N. Taylor, Nenad Medvidovic, 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