INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker

INFO 620 Lecture #6 1

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:– Add methods to the classes and define

messaging between objects to fulfill the requirements

– But that last step isn’t trivial!


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)


Responsibilities

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


Responsibilities

• 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


Responsibilities

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

• Methods are often implemented to fulfill responsibilities


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)


Responsibilities, Methods related

:Sale

:Payment

makePayment()

create()

From Fig. 16.1, p. 217

makePayment implies Sale objects are responsible for creating Payments

Note Payment shifted down to show its creation


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


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


The First Five GRASP Patterns

• Information Expert

• Creator

• High Cohesion

• Low Coupling

• Controller


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!


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


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


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


Information Expert

-date-time

Sale

-description-price-itemID

ProductSpecification

-quantity

SalesLineItem

1

1..*

Contains

* 1

Described-by


Information Expert

• So at the highest level, we need to get the total cost from Sale

But in order to get that, we need the subtotal of each line item – so get that from the information expert for each line item

:Sale

getTotal()


Information Expert

• So each SalesLineItem can get the subtotal of that line; and the Sale will get those subtotals

But each line item needs the price of each item; get from ProductDescription

:Sale

getTotal()

:SalesLineItem

getSubtotal()


Information Expert

• Omitting variable assignments we have:

Where each object is responsible for providing the data it owns

:Sale

getTotal()

:SalesLineItem

getSubtotal()

:ProductDescription

getPrice()


Information Expert

• The class diagram becomes:

+getTotal()

-date-time

Sale

+getPrice()

-description-price-itemID

ProductSpecification

+getSubtotal()

-quantity

SalesLineItem

1

1..*

Contains

* 1

Described-by


Information Expert

• Information Expert is used very frequently in object design

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


Creator

• 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


Creator

• 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


Creator

• 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


Creator

• The sequence diagram would be:

:Register :Sale

:SalesLineItem

makeLineItem()

create()

Fig. 16.8, p. 227


Creator

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


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


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?


“Stair” Object Structure

Object1 Object2 Object3 Object4 Object5

Message1()

Message2()

Message3()

Message4()

Message5()

Message6()

Message7()

Message8()

Low coupling (decentralized)Each object sees two other objects at most


“Fork” Object Structure

Object1 Object2 Object3 Object4 Object5

Message1()

Message2()

Message3()

Message4()

Message5()

Message6()

Message7()

Message8()

High coupling (centralized)Object1 must see all other objects


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


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”


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


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”


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


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


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


Controller

• 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


Controller

• 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


Controller

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


Controller

• 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


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)


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)


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)


Façade Controller

System

facade externalSystem

Object6

Object7

Object8

Object9


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


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


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


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


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


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


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

This the the body of a Note box. It also has a Name, which isn't visible.

{s.isComplete = true} <- Constraint

<- Note


Object Constraint Language

• UML supports using a formal Object Constraint Language (OCL) to show constraints on execution of messages– http://www.omg.org/docs/ad/97-08-08.pdf – A newer version of the OCL is under

development as of July 2003

• Any notation may be used, however

http://www.omg.org/docs/ad/97-08-08.pdf


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)


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)

Documents

INFO 620Lecture #61 Information Systems Analysis and Design More Class Modeling; Patterns INFO 620 Glenn Booker