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
  • Presentation posted in: General

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

  • Login