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

Information Systems Analysis
and Design
More Class Modeling; Patterns
INFO 620
Glenn Booker
INFO 620
Lecture #6
1
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!
INFO 620
Lecture #6
2
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)
INFO 620
Lecture #6
3
Responsibilities
• The responsibilities for an object describe
what behavior it needs to fulfill
• Doing
–
–
–
–
–
INFO 620
Create an object
Perform a calculation
Start action in another object
Control activities in other objects
“Sale is responsible for creating SalesLineItem”
Lecture #6
4
Responsibilities
• Knowing
–
–
–
–
–
INFO 620
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
5
Responsibilities
• Translating responsibilities into classes
and methods depends on how detailed
or general the responsibilities are
• Methods are often implemented to
fulfill responsibilities
INFO 620
Lecture #6
6
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)
INFO 620
Lecture #6
7
Responsibilities, Methods related
Note Payment
shifted down to
show its creation
:Sale
makePayment()
create()
:Payment
makePayment implies
Sale objects are
responsible for
creating Payments
From Fig. 16.1, p. 217
INFO 620
Lecture #6
8
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
INFO 620
Lecture #6
9
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
INFO 620
Lecture #6
10
The First Five GRASP Patterns
•
•
•
•
•
Information Expert
Creator
High Cohesion
Low Coupling
Controller
INFO 620
Lecture #6
11
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 responsibility
or Whoever has the data is responsible for
managing and sharing it!
INFO 620
Lecture #6
12
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
INFO 620
Lecture #6
13
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
INFO 620
Lecture #6
14
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
INFO 620
Lecture #6
15
Information Expert
Sale
-date
-time
1
Contains
1..*
ProductSpecification
SalesLineItem
Described-by
-quantity
*
INFO 620
1
Lecture #6
-description
-price
-itemID
16
Information Expert
• So at the highest level, we need to get the
total cost from Sale
getTotal()
: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
INFO 620
Lecture #6
17
Information Expert
• So each SalesLineItem can get the
subtotal of that line; and the Sale will
get those subtotals
getTotal()
getSubtotal()
:Sale
:SalesLineItem
But each line item needs the price of each
item; get from ProductDescription
INFO 620
Lecture #6
18
Information Expert
• Omitting variable assignments we have:
getTotal()
getSubtotal()
:Sale
getPrice()
:SalesLineItem
:ProductDescription
Where each object is responsible for
providing the data it owns
INFO 620
Lecture #6
19
Information Expert
• The class diagram becomes:
Sale
-date
-time
+getTotal()
1
Contains
1..*
ProductSpecification
SalesLineItem
Described-by
-quantity
+getSubtotal()
INFO 620
*
1
Lecture #6
-description
-price
-itemID
+getPrice()
20
Information Expert
• Information Expert is used very frequently
in object design
• May not be suitable when coupling or
cohesion dictate otherwise (see later)
INFO 620
Lecture #6
21
Creator
• Problem: Who is responsible for creating a
new instance of a class?
• Solution: Let B create instances of A if:
–
–
–
–
–
INFO 620
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
22
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
INFO 620
Lecture #6
23
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
INFO 620
Lecture #6
24
Creator
• The sequence diagram would be:
:Register
:Sale
makeLineItem()
create()
:SalesLineItem
Fig. 16.8, p. 227
INFO 620
Lecture #6
25
Creator
• If the creation of an object is very complex,
then the Factory pattern would be better
(see Ch. 23)
INFO 620
Lecture #6
26
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
INFO 620
Lecture #6
27
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?
INFO 620
Lecture #6
28
“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
INFO 620
Lecture #6
29
“Fork” Object Structure
Object1
Object2
Object3
Object4
Object5
Message1()
Message8()
Message3()
Message6()
Message4()
Message5()
Message7()
Message2()
High coupling (centralized)
Object1 must see all other objects
INFO 620
Lecture #6
30
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
INFO 620
Lecture #6
31
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”
INFO 620
Lecture #6
32
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
INFO 620
Lecture #6
33
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”
INFO 620
Lecture #6
34
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
INFO 620
Lecture #6
35
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
INFO 620
Lecture #6
36
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
INFO 620
Lecture #6
37
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
INFO 620
Lecture #6
38
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
INFO 620
Lecture #6
39
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>
INFO 620
Lecture #6
40
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
INFO 620
Lecture #6
41
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)
INFO 620
Lecture #6
42
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)
INFO 620
Lecture #6
43
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)
INFO 620
Lecture #6
44
Façade Controller
System
Object8
facade
externalSystem
Object7
Object6
Object9
INFO 620
Lecture #6
45
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
INFO 620
Lecture #6
46
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
INFO 620
Lecture #6
47
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
INFO 620
Lecture #6
48
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
INFO 620
Lecture #6
49
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
INFO 620
Lecture #6
50
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
INFO 620
Lecture #6
51
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
{s.isComplete = true}
<- Constraint
This the the body of a Note box. It also has a Name, which isn't visible.
INFO 620
Lecture #6
<- Note
52
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
INFO 620
Lecture #6
53
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)
INFO 620
Lecture #6
54
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)
INFO 620
Lecture #6
55