Software Engineering: Analysis and Design CSE3308

1
Software Engineering Analysis and Design -
CSE3308
CSE3308/DMS/2002/16
Monash University School of Computer Science
and Software Engineering

• Object-Oriented Analysis 2

2
Lecture Outline

• Linking Use Cases and Class Diagrams
• Interaction Diagrams
• Sequence Diagrams
• Collaboration Diagrams
• Package Diagrams
• State Diagrams
• Activity Diagrams
• A criticism of Use Cases

3
Linking Use Cases and Class Diagrams

• Use Cases are a key tool in determining the
  concepts/classes in a system
• One of the earliest methods of finding the
  classes was Noun Identification
• Noun Identification is both simple and deceptive
• Simple to apply to requirements
• Deceptive because natural language is ambiguous
• Use cases (especially expanded use cases) provide
  a more focused view of the requirements and
  therefore can act as a very good source of
  inspiration

4
Example
System Response
Actor Action
1. This use case begins when a Customer arrives
at a checkout with items to purchase. 2. The
Cashier records the Universal Product Code (UPC)
from each item. If there is more than one of the
same item, the Cashier can enter the quantity as
well.
3. Determines the item price and adds the item
information to the running sales
transaction. The description and price of the
current item are displayed.

• Identifies both concepts and attributes
• Different nouns can mean the same thing
• Often a question of experience

5
Rejecting Classes

• We will come up with many possible classes, some
  of which we will not need
• Competing priorities
• Simplest set of classes to satisfy current needs
• Set of classes which will easily accommodate
  future needs
• Need to apply criteria to possible classes

6
Rejection criteria

• Redundant classes
• e.g. User and Customer of an ATM
• retain the more descriptive name
• Irrelevant classes
• context-dependent
• e.g. Customer complaint is outside the scope of
  the ATM example
• Vague classes
• A class should be specific
• e.g. ATM Death is not clearly defined in our
  material
• Attributes
• e.g. name, age, weight, are not usually classes

7
Rejection criteria (2)

• Functions
• a behaviour of a class rather than a class in
  itself
• e.g. in a car system, acceleration is a function
  not a class
• Roles
• The name of a class should reflect its intrinsic
  nature and not a role it plays in an association
• e.g. Customer confused with Car Owner, Car Driver
  and Car Renter
• Implementation constructs
• classes which are extraneous to the real world
• e.g. CPU, subroutine, array, linked list, etc.

8
Interaction Diagrams

• Models which show how groups of objects
  collaborate in some behaviour
• Typically we describe how the behaviour of a
  single use case is implemented by a group of
  objects and the messages they pass between them
• Two types of Interaction diagrams
• Sequence
• Collaboration
• Both are useful, choice is a matter of
  personal/organisational preference

9
Filling an OrderA real use case
Name Filling an Order Actors Order Clerk
Purpose To fill an order for a
customer Overview Type Primary and real
Typical Course of Events
Actor Action
System Response
1. An order clerk enters an order in the entry
window.
2. The Order Entry Window sends a prepare message
to an Order. 3. The order then sends prepare to
each Order Line on the Order. 4. Each Order Line
checks the given Stock Item 5. Order Line removes
the appropriate quantity of Stock Item from stock
Alternative Course Quantity of Stock Item below
reorder level and that Stock Item requests a
new delivery
10
Sequence Diagram
11
Collaboration Diagram
Messages, e.g. prepare() are calls to
operations on the objects to which they are sent
12
Comparing Sequence and Collaboration Diagrams

• Sequence diagrams emphasise the sequences of
  events well
• Collaboration diagrams show the relationships
  between the classes well
• Keep both types of diagrams simple
• They are not particularly good at defining
  behaviour precisely

13
Package Diagrams

• Method to break down a large system into smaller
  systems
• Basically lets us group classes into higher-level
  units
• Group classes based upon dependencies
• Dependency means a change in one group will cause
  a change in another group
• Packages give us a way of depicting dependencies
• Reducing dependencies is the key to building
  large systems
• Can be implemented in Java directly (Packages)

14
A Package Diagram
package
dependency
15
Another package diagram
Order Capture UI
Mailing List UI
AWT
Order Capture Application
Mailing List Application
Domain
Customers
Orders
Oracle Interface
Common global
Quantity Money Date Range
Database Interface abstract
Sybase Interface
16
Package Diagrams (2)

• You need to create a package diagram, if your
  class diagram is larger than a sheet of A4 paper
• Dependencies are not transitive, they go one step
  only
• You should aim to break cycles in the
  relationships between packages where possible
  (often difficult within the domain)
• Are useful for testing, can do unit testing on a
  per package basis rather than per class

17
State Diagrams

• Very similar to those in Structured Analysis, but
  with a quite different purpose
• Describe the lifecycle of an object
• All the possible states of an object
• How the objects state changes as a result of
  events that reach the object
• Good at describing the behaviour of an object
  across several use cases
• Not good at describing behaviour where several
  objects are interacting
• Use state diagrams only for classes that exhibit
  interesting behaviour
• If too much concurrent behaviour in an objects
  state diagram, is probably more than one object

18
A Basic State Diagram for an Order
start
guard condition
/get first item
not all items checked/ get next item
all items checked all items available
Dispatching
Checking
do/initiate delivery
do/check item
action
Item Received all items available
activity
event
all items checked some items not in stock
Item received some items not in stock
cancelled
Waiting
State
transition
Delivered
Cancelled
cancelled
self-transition
19
Superstates
Active
/get first item
get next item not all items checked
all items checked all items available
Dispatching
Checking
do/initiate delivery
do/check item
Item Received all items available
all items checked some items not in stock
Item received some items not in stock
Waiting
Delivered
Cancelled
cancelled
20
Concurrent States
Cancelled
Waiting
Checking
Dispatching
Delivered
Authorised
Authorising
Rejected
21
Activity Diagrams

• In a conceptual diagram, an activity is some task
  to be done
• In a specification/implementation diagram, an
  activity is a method on a class
• Each activity can be followed by another activity
• Activities can span multiple use cases
• Show the whole picture of behaviour, just as a
  class diagram shows the whole picture of the
  static relationships

22
An Activity Diagram
23
Another Activity Diagram
24
Joining Activity Diagrams
25
Activity Diagrams (2)

• Strength is their support for parallel behaviour
• Ideal for describing workflow modelling and
  multi-threaded programming
• Disadvantage is that the link between activities
  and objects is not very clear
• Either use swimlanes or specifically indicate the
  object on the diagram
• Not used for looking at how objects collaborate
  or how an object behaves over its lifetime

26
A criticism of Use Cases

• Meyer (1997) criticises use cases as a method for
  OO Analysis and Design, especially as a tool for
  finding classes
• Use cases emphasise ordering and thus harm the
  systems reuseability and robustness
• Use cases emphasise a current view of the system
  and reduce the possibility of new and better ways
  of doing things
• Use cases favor a a functional approach based on
  processes, the reverse of OOs concentration on
  data abstraction

27
References

• Booch, Grady, Rumbaugh, James, and Jacobson,
  Ivar, The Unified Modeling Language User Guide,
  Addison-Wesley, 1998 (Chs. 12, 18, 19, 21)
• Fowler, Martin, UML Distilled, Addison-Wesley,
  1997 or 2000 (Chs. 5, 6, 7, 8, 9)
• Page-Jones, Meilir, Fundamentals of
  Object-Oriented Design in UML, Addison-Wesley,
  2000 (Ch. 5, 6, 7)