1. Object-Oriented Architecture & Design – Lecture 1 (of 3) Problem Decomposition David Woollard University of Southern California Computer Science Department Software Architecture Group California Institute of Technology NASA Jet Propulsion Laboratory Data Management Group

2. About Me Defended my dissertation this June – “Domain Specific Architecture for Scientific Software” Senior Software Engineer at NASA’s Jet Propulsion Lab. My roles have included: – Lead Developer for a leading open-source Grid technology – Cognizant Engineer, Orbiting Carbon Observatory – Cognizant Engineer, NPOESS Preparatory Project – System Engineer, Airborne Cloud Computing Environment Contributor to the Apache Software Foundation 2

3. About My Work Science Data System 3

4. Story Arc Storyline in episodic form Goal for OOA&D: Move from requirements to design, reified by a model OOA&D will be split across 3 lectures – Lecture 1: Problem Decomposition (9/15) – Lecture 2: UML in Depth (9/29) – Lecture 3: Advanced Topics – NFP, Incomplete Specification, Relationship to Frameworks, etc. (10/1) OOA&D Workshop (10/11) – Interactive session to review your designs 4

5. Outline for Today Object Oriented Design Basics The Role of Software Architecture Patterns & Styles Internet Bookstore Example 5

6. Object Oriented Design OO in the `60s & `70s – Informal notions – Simula, Smalltalk In `82, Grady Booch coined the term Object Oriented Design – The idea was to combine a design methodology with language constructs that implement design concepts – Objects in design space are classes in implementation space 6

7. What Are Objects? Three key attributes: – State The collection of information known to an object State changes are a consequence of operations performed on an object – Operations The actions that can be performed on an object Not all operations make sense for all objects – Identity Two objects with identical state as still different from one another 7 Source: Mastering Object-Oriented Design in C++ by Cay S. Horstmann

8. Design Goals for OOD Booch defined three goals – Identify the objects/classes – Identify the functionality of these objects/classes – Identify the relationship between these objects/classes This is an iterative process – Decisions in design space are complex – Identification and specification of one aspect of a class might force changes in other aspects 8 Source: Mastering Object-Oriented Design in C++ by Cay S. Horstmann

9. Simple Methodology Objects are nouns in a problem statement or requirement Operations are verbs in the problem statement or requirement – A user shall be able to delete a message from a mailbox Relationships are found by looking for use, aggregation, and inheritance – “is-a” & “has-a” statements – Basic Use: Does an operation of Object A modify, require, or produce an Object B? – Aggregation: Does Object A have a reference to Object B? – Inheritance: Does Object A contain all aspects of Object B? Are all operations on Object B therefore allowed for Object A? What relationships are implied in the statement above? 9 Source: Mastering Object-Oriented Design in C++ by Cay S. Horstmann

10. Beyond the Simple Methodology Good for very constrained problems, but not larger, more complex software systems. When developing real-world applications, we need to consider other aspects of the software system. – What are objects and what should be considered state? – How are my objects deployed? – What about non-functional properties and level of service? – How does my design interact with software frameworks & middleware? We address these and other aspects of software design via Software Architecture. 10

11. Software Architecture Principle design decisions Architecture is manifested as a system’s: – Components – Connectors – Topology/Configuration Architecture != Design Architecture is both the process of arriving at these principle decisions and the creation of artifacts reifying these decisions 11

12. Why Architecture? All software systems have an architecture – Big ball of mud counts All software systems have an architect Artifacts of design decisions persist (and are useful) throughout the software lifecycle – You might not implement the software in this class – You will need to communicate design to stakeholders – You will probably not maintain this software or add new features in 10 years 12

13. Conceptual Design Tools Abstraction and Terminology – What are the fundamental concepts in your system? Separation of Concerns – Isolate likely change – Identify commonalities Refined Experience – What have other architects found useful? 13

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

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

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

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

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

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

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

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

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

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

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

25. Design in Context Design – Requirements Interplay – Design forms the vocabulary for requirements – Requirements constrain design Existing patterns, styles and frameworks can often be leveraged An example from JPL: – An archive and metadata repository called “CAS- File Manager” 25

26. CAS-File Manager Example Requirements: – The File Manager shall persist metadata in a database – The File Manager shall be deployed without external software dependencies Note: I’ve made these up for the purposes of this class;) Note 2: Where are the nouns and verbs here? 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. 26

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

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

29. Is OO an Architecture? OO is an Abstraction OO is an Architectural Style Styles and Patterns can be composed and utilized at different architectural levels 29 GUI Controller Persistence Oracle

30. In The Next Lectures… We will cover model representations (UML) We will discuss incorporation of COTS in design We will discuss how choice of framework impacts architecture (and design) But with the rest of our time today… – An example 30

31. Example – Internet Bookstore Online retail outlet for purchasing books Provide basic user capabilities for: – Searching for books – Reviews & rating of books – Purchase of books Interfaces to shipping and inventory management 31

32. Internet Bookstore Requirements (1/2) The bookstore shall accept orders over the internet The bookstore shall maintain a list of accounts for up to 1,000,000 customers The bookstore shall provide password protection for all accounts The bookstore shall provide the ability to search the master book catalog The bookstore shall provide a number of search methods on that catalog, including search by author, search by title, search by ISBN number, and search by keyword The bookstore shall provide a secure means of allowing customers to pay by credit card 32

33. Internet Bookstore Requirements (2/2) The bookstore shall provide a secure means of allowing Customers to pay via purchase order The bookstore shall provide a special kind of account that is pre-authorized to pay via purchase order The bookstore shall provide electronic links between the Web and the book information database (BID) and the shipping fulfillment center The bookstore shall maintain reviews of books and should allow anyone to upload review comments The bookstore shall maintain ratings on books based on customer inputs 33

34. Domain Modeling Necessary to ground both requirements and design (and hopefully implementation) in terminology shared by all stakeholders A methodology for building terminology, as well as discovering and refining use-cases and requirements Many techniques exist 34

35. Domain Modeling Guidelines (1/2) Focus on real-world (problem domain) objects. Use generalization (is-a) and aggregation (has-a) relationships to show the objects relate to each other. Limit your initial domain modeling efforts to a couple of hours. Organize your classes around key abstractions in the problem domain. Don’t mistake your domain model for your data model. 35 Source: Use case driven object modeling with UML: theory and practice by Doug Rosenberg and Matt Stephens

36. Domain Modeling Guidelines (2/2) Don’t confuse an object (a single instance) with a database table (a collection of things). Use the domain model as a project glossary. Do your initial domain model before you write your use cases, to avoid name ambiguity. Don’t expect your final class diagrams to precisely match your domain model, but there should be some resemblance between them. Don’t put screens and other GUI-specific classes on your domain model. 36 Source: Use case driven object modeling with UML: theory and practice by Doug Rosenberg and Matt Stephens

37. Sounds a lot like OO, right? 37

38. Example Technique: Color Modeling First used for Java software development in 1997 Refined by Peter Coad, et. Al., in Java Modeling in Color with UML Focuses on identifying different varieties of domain classes (or ‘archetypes’): – Party/Place/Thing – Role – Activity – Description (we aren’t going to cover this one) First step in the technique to to start with enumerating the activities in the problem domain that the software should support – Identify each Party, Place or Thing who participate in the activity – Identify what Roles the Party, Place or Things play while interacting with the activity 38

39. Internet Bookstore Domain Model As an initial example let us focus on the activity of account registration Two requirements suggest that this is a domain activity: – “The bookstore shall maintain a list of accounts for up to 1,000,000 customers” – “The bookstore shall provide password protection for all accounts” Since the requirements refer to accounts with password protection, you can assume that ‘People’ in the role of ‘Customers’ will have to register with the Internet Bookstore in order to create accounts for themselves Of course, like everything else during this early phase of the development process, this assumption must be verified with the relevant critical stakeholders 39

40. Color Modeling – Acct. Registration In color modeling, each object has a stereotype (this is a UML term) in ‘<>’ and a color indicating its archetype – classes are colored pink –,, and classes are colored green – classes are colored yellow Why is there a privileged account vs. an ordinary account? – “The bookstore shall provide a special kind of account that is pre-authorized to pay via purchase order” 40 Person Customer Registration Account Privileged Account Ordinary Account Produces Performs Is A

41. Conclusions OO is a useful design construct OO has a place in Architecture, but Architecture is a lot larger than OO Design is an iterative process – Requirements imply other missing requirements – Requirements conflict with other requirements – Requirements can be non-functional and imply levels-of-service Would an Internet bookstore designed to service 100 customers have a different architecture from an Internet Bookstore designed to support 100 Million? Domain Modeling is a useful activity to flesh out requirements and design concerns as well as standardize on language 41