1 / 41

Object-Oriented Architecture & Design – Lecture 1 (of 3) Problem Decomposition

Object-Oriented Architecture & Design – Lecture 1 (of 3) Problem Decomposition. David Woollard. 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:

aurek
Télécharger la présentation

Object-Oriented Architecture & Design – Lecture 1 (of 3) Problem Decomposition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Object-Oriented Architecture &Design – Lecture 1 (of 3)Problem Decomposition David Woollard

  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

  3. About My Work Science Data System

  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

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

  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

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

  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

  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

  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?

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

  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

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

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

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

  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

  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 Component Component RPC RPC RPC Server

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

  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 Component Component Data Access Blackboard

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

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

  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”

  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.

  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.

  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.

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

  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

  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

  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

  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

  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. 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. Source: Use case driven object modeling with UML: theory and practice by Doug Rosenberg and Matt Stephens

  37. Sounds a lot like OO, right?

  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 eachParty, Place or Thing who participate in the activity • Identify whatRolesthe Party, Place or Things play while interacting with the activity

  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

  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 • <activity> classes are colored pink • <party>, <place>, and <thing> classes are colored green • <role> 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” <Party> Person Is A <Role> Customer Performs <Activity> Registration Produces <Thing> Account <Thing> Privileged Account <Thing> Ordinary Account

  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

More Related