Information systems analysis and design more class modeling patterns
1 / 55

Information Systems Analysis and Design More Class Modeling; Patterns - PowerPoint PPT Presentation

  • Uploaded on

Information Systems Analysis and Design More Class Modeling; Patterns. INFO 620 Glenn Booker. Object Design. The rough steps followed so far include: Define requirements and model with use cases Create domain model (conceptual class diag.) Now to design objects we need to:

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Information Systems Analysis and Design More Class Modeling; Patterns' - leonard-hopper

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Information systems analysis and design more class modeling patterns

Information Systems Analysis and DesignMore Class Modeling; Patterns

INFO 620

Glenn Booker

Lecture #6

Object design
Object Design

  • The rough steps followed so far include:

    • Define requirements and model with use cases

    • Create domain model (conceptual class diag.)

  • Now to design objects we need to:

    • Add methods to the classes and define messaging between objects to fulfill the requirements

    • But that last step isn’t trivial!

Lecture #6

Grasp patterns
GRASP Patterns

  • GRASP patterns help define normal ways that objects interact with each other

    • GRASP is Larman’s term; “General Responsibility Assignment Software Patterns”

    • We’ll cover five of the patterns in the text

    • For all 23 standard patterns, see Erich Gamma’s classic Design Patterns(ISBN 0201633612 or 0201634988)

Lecture #6


  • The responsibilities for an object describe what behavior it needs to fulfill

  • Doing

    • Create an object

    • Perform a calculation

    • Start action in another object

    • Control activities in other objects

    • “Sale is responsible for creating SalesLineItem”

Lecture #6


  • Knowing

    • About private encapsulated data

    • About related objects

    • About things it can calculate or derive

    • “Sale is responsible for knowing its total”

    • Most ‘knowing’ responsibilities are apparent from the attributes and associations of the object

Lecture #6


  • Translating responsibilities into classes and methods depends on how detailed or general the responsibilities are

  • Methods are often implemented to fulfill responsibilities

Lecture #6

Getters and setters
Getters and Setters

  • Detailed object methods often include a lot of getters and setters

    • Getters ‘get’ some value for the outside world, e.g. getTotal (a ‘knowing’ responsibility)

    • Setters ‘set’ some value – like assignment statements, e.g. setSecurityLevel(a ‘doing’ responsibility)

Lecture #6

Responsibilities methods related

Note Payment shifted down to show its creation

makePayment implies Sale objects are responsible for creating Payments

Responsibilities, Methods related

Lecture #6

Defining patterns
Defining Patterns

  • Patterns capture well established “best practices” for design

  • Some are very low level; others are architectural

  • Each Pattern is defined by its Name, a summary of the Pattern’s Solution, and a description of the Problem it solves

Lecture #6

Defining patterns1
Defining Patterns

  • Patterns are not always the best solution

  • Good pattern descriptions include when the pattern may not apply, or the pros and cons of the pattern

Lecture #6

The first five grasp patterns
The First Five GRASP Patterns

  • Information Expert

  • Creator

  • High Cohesion

  • Low Coupling

  • Controller

Lecture #6

Information expert
Information Expert

  • Problem: what is the general principle of assigning responsibilities to objects?

  • Solution: assign responsibility to the Information Expert – the class which has the information needed to fulfill the responsibilityor Whoever has the data is responsible for managing and sharing it!

Lecture #6

Information expert1
Information Expert

  • The domain model should inspire expansion into design classes which will handle all of the data and use it to meet requirements

  • A key step is that we have to make up the classes we think we’ll need, based on the system characteristics, and see if they can work correctly

Lecture #6

Information expert2
Information Expert

  • So if we have a class called Sale (like Shipment in the homework assignments), one responsibility might be to provide the total cost of the Sale

  • We know from a typical invoice that a Sale might consists of a bunch of line items, so we might call their class SalesLineItem

Lecture #6

Information expert3
Information Expert

  • Each SalesLineItem may have a quantity

  • And each SalesLineItem needs someplace safe to store its description and price, so we’ll put that in a ProductSpecification

  • After defining the associations and multiplicity, we get Figure 16.3 (p. 222), shown on the next slide

Lecture #6

Information expert4
Information Expert

Lecture #6

Information expert5
Information Expert

  • So at the highest level, we need to get the total cost from SaleBut in order to get that, we need the subtotal of each line item – so get that from the information expert for each line item

Lecture #6

Information expert6
Information Expert

  • So each SalesLineItem can get the subtotal of that line; and the Sale will get those subtotalsBut each line item needs the price of each item; get from ProductDescription

Lecture #6

Information expert7
Information Expert

  • Omitting variable assignments we have:Where each object is responsible for providing the data it owns

Lecture #6

Information expert8
Information Expert

  • The class diagram becomes:

Lecture #6

Information expert9
Information Expert

  • Information Expert is used very frequently in object design

  • May not be suitable when coupling or cohesion dictate otherwise (see later)

Lecture #6


  • Problem: Who is responsible for creating a new instance of a class?

  • Solution: Let B create instances of A if:

    • B aggregates (is made up of) A

    • B contains (holds) A objects

    • B records instance of A objects

    • B closely uses A objects

    • B has data needed when A is created

Lecture #6


  • Creation of objects is also a very common activity

  • In the previous example, Sale aggregates (contains) many SalesLineItem objects (one object per line in the Sale), hence is makes sense for Sale to be a Creator of SalesLineItem instances

Lecture #6


  • Hence a responsibility of the system is that a Sale needs a method to makeLineItem

  • If you want add X (quantity) widgets to a shopping cart, then Sale adds them to the cart

Lecture #6


  • The sequence diagram would be:

Lecture #6


  • If the creation of an object is very complex, then the Factory pattern would be better (see Ch. 23)

Lecture #6

Low coupling
Low Coupling

  • Problem: How can we support low dependency among classes, low impact of changes, and increase reuse of classes?

  • Solution: Assign responsibilities so that coupling remains low

  • Coupling describes the extent of interconnection among classes

Lecture #6

Low coupling1
Low Coupling

  • Notice that some coupling is needed – otherwise the classes don’t interact

  • Too much coupling means that changes to one class might have unexpected changes elsewhere

  • Related to “visibility” – how many other objects does each one need to see?

Lecture #6

Low coupling2
Low Coupling

  • The Stair structure is generally preferred where possible

  • Might have to use Fork structure if

    • The sequence of operations may change, and/or

    • New operations may be needed frequently

  • Subclasses are, by definition, high levels of coupling between objects

Lecture #6

Low coupling3
Low Coupling

  • Particularly avoid high coupling for objects which may change interface, implementation, or existence frequently

  • Desire for low coupling may conflict with Expert or High Cohesion patterns

  • No firm measure of what level of coupling is “good”

Lecture #6

High cohesion
High Cohesion

  • Problem: how do you keep complexity manageable?

  • Solution: Assign responsibilities so that cohesion remains high

  • Cohesion is a measure of how closely related an object’s responsibilities are

  • High cohesion means a closely related set of narrowly defined responsibilities

Lecture #6

High cohesion1
High Cohesion

  • In other words, don’t make an object do too much work!

  • Low cohesion generally results from remaining too abstract when defining responsibilities

  • Per Booch, high cohesion is when the elements of a class “all work together to produce some well-bounded behavior”

Lecture #6

High cohesion2
High Cohesion

  • An object which has a kitchen-sink function (it catches all the functions except the kitchen sink) generally has very low cohesion

  • A single complex function can result in low cohesion

  • Moderate cohesion would have similar, but not closely related, functions together

Lecture #6

High cohesion3
High Cohesion

  • High cohesion classes have some responsibilities in one set of functions, and use other objects to accomplish them

  • Modular design is a similar concept as ‘low coupling and high cohesion’

  • Conversely, high coupling and low cohesion often appear together

Lecture #6

High cohesion4
High Cohesion

  • Deliberately violating high cohesion is rare

  • Might have to do it:

    • To isolate related functions (rare)

    • To distribute object to different servers

    • To manage an external interface

Lecture #6


  • Problem: who is responsible for handling external input system events?

  • Solution: assign the responsibility to a Controller object

    • Façade controller represents the entire subsystem or interface

    • Session controller handles an entire use case where some events may occur

Lecture #6


  • An ‘input system event’ is some event from an external actor (human or not)

  • The Controller object is responsible for deciding what to do with the input system event

Lecture #6


  • So the Controller pattern applies to both management of external system interfaces (capture the entire interface in a single controller class), and managing inputs from user interfaces

  • User interface controllers generally end with <>Handler, <>Coordinator, or <>Session, where <> = <Use Case Name>

Lecture #6


  • Note that user interfaces (e.g. windows, views, or documents) are NOT part of the Controller’s job – those belong to an object at the Interface (or Presentation) Layer

  • Controller acts as a façade between interface and the application

  • Controllers DELEGATE work to other objects – they don’t do it themselves

Lecture #6

Bce objects
BCE Objects

  • We can break objects into three major types for many purposes

    • Boundary objects (user interface window, buttons, etc.)

    • Control objects (controllers who make decisions, here also called ‘use case handlers’)

    • Entity objects (persistent objects which contain data)

Lecture #6

Bce objects1
BCE Objects

  • These might be correlated to the kinds of computers involved in processing them

    • User interface might be at a PC level (e.g. web browser)

    • Controller objects might run on an application server (captures logic, e.g. web server)

    • Entity objects might run on a database server (stores data)

Lecture #6

Fa ade controller
Façade Controller

  • Façade controllers hide an entire system or subsystem under one class, such as Register or System

    • Avoid except for simple external systems

  • Works well if only a few events to manage; otherwise may need use case controllers to break down system functions into smaller sets (p. 241)

Lecture #6

Fa ade controller1
Façade Controller

Lecture #6

Avoiding bloated controllers
Avoiding Bloated Controllers

  • Even a façade controller should generally have more than one class

  • Beware of controllers which perform work without calling another class

  • Controllers should have few or no attributes

  • Fix bloat by adding more controller classes, and/or redesign to delegate more work

Lecture #6

Use case realization
Use Case Realization

  • Every scenario in a use case can become a ‘use case realization,’ which shows how the design model meets the requirements for that use case

  • Use Case Realization is UP term, not UML

  • Interaction diagrams help express Use Case Realization

Lecture #6

Use case realization1
Use Case Realization

  • Use case suggests system events shown in system sequence diagram

  • Effect of operations may be documented in operation contracts

  • Events represent messages which initiate interaction diagrams

  • Interaction diagrams describe communication between classes

Lecture #6

Interaction diagrams
Interaction Diagrams

  • Recall the collaboration diagrams are specific to one use case

  • Sequence diagrams generally show one scenario for one use case; might show extensions

  • Operations contracts describe the conditions for one event in one use case

Lecture #6

Models don t start perfect
Models Don’t Start Perfect

  • Expect that early requirements, and the initial domain model (conceptual class diagram) will not be perfect

    • But that doesn’t mean do them poorly!

    • Maintain contact with customer and subject experts to keep improving models

  • Conceptual classes inspire design classes

    • But many additional classes likely needed

Lecture #6

Model view separation
Model-View Separation

  • Non-GUI objects should not be involved in output tasks

  • This reinforces the Boundary/Control/Entity object distinction earlier

  • Controllers should know the information to be displayed in output, but actual output is a boundary object’s purpose

Lecture #6

More uml notation
More UML Notation

  • Constraints are tagged with curly brackets {}. An algorithm may be shown if needed.

  • Notes are in text boxes which also have the upper right corner dog-eared

<- Constraint

<- Note

Lecture #6

Object constraint language
Object Constraint Language

  • UML supports using a formal Object Constraint Language (OCL) to show constraints on execution of messages


    • A newer version of the OCL is under development as of July 2003

  • Any notation may be used, however

Lecture #6

Iteration 2
Iteration 2

  • The text’s second iteration assumes that in iteration 1 everything was done through development of the design class diagram, and major architecturally important parts of the system have been coded and tested

  • Iteration 2 is refining the design through additional patterns (which we aren’t covering)

Lecture #6

Iteration 21
Iteration 2

  • Iteration 2 also adds more scenarios to the foundation already established

  • Additional lower priority use cases may be fully defined

  • The system sequence diagram may be expanded to include external systems (p. 324)

Lecture #6