cse3308 - software engineering: analysis and design, 2004lecture 6a.1 software engineering: analysis...

CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.1

Software Engineering: Analysis and Design - CSE3308

Object-Oriented Analysis 2

CSE3308/DMS/2004/18

Monash University School of Computer Science and Software Engineering


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


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


Example

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

Actor Action System Response

1. This use case begins when a Customerarrives at a checkout with items to purchase.

2. The Cashier records the UniversalProduct 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 andadds the item information to the running sales transaction.

The description and price of the current item are displayed.


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


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


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.


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


Filling an OrderA real use case

Name: Filling an OrderActors: Order Clerk Purpose: To fill an order for a customerOverview: Type: Primary and real

Actor Action System Response

1. An order clerk enters an order in the entry window.

2. The Order Entry Window sends a preparemessage to an Order.3. The order then sends “prepare” to eachOrder Line on the Order.4. Each Order Line checks the given StockItem5. Order Line removes the appropriate quantityof Stock Item from stock

Typical Course of Events

Alternative Course: Quantity of Stock Item below reorder level and that Stock Item requests a new delivery


Sequence Diagram : orderEntry

Window : order : orderLine : stockItem : reorderItem : deliveryItem

prepare ( )

prepare ( )

check ( )

needToReorder ( )

remove ( )[check == true]

new ( )[needToReorder == true]

new ( )

[check == true]

*

Message

Iterated message Condition

Return

Creation


Collaboration Diagram

: orderEntryWindow

: order

: orderLine : stockItem

: reorderItem

: deliveryItem

5: needToReorder ( )

[check == true]

[check == true]

[needToReorder == true]

Sequence Number

Self-Delegation

Object

Message

1: prepare ( )

2: prepare ( ) 3: check ( )4: remove ( )

7:

8: new ( )6: new ( )

Messages, e.g. “prepare()” are calls to operations on the objects to which they are sent


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


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)


A Package Diagram

Order Capture UI AWT

MailingList UI

Mailing ListApplication

CustomersOrders

Order Capture

Application

dependency

package


Another package diagramOrder

Capture UI AWT MailingList UI

Mailing ListApplication

CustomersOrders

Order Capture

Application

Domain

QuantityMoneyDate Range

Common{global}

DatabaseInterface{abstract}

OracleInterface

SybaseInterface


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


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 object’s 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 object’s state diagram, is probably more than one object


A Basic State Diagram for an Order

Item Received

[all items availa

ble]

Waiting

Delivered

Cancelled

Checking Dispatching

cancelled

[all items checked &&all items available]

[all items checked&& some items not in stock]

Item received [some items not in stock]

cancelled

do/initiatedelivery

do/checkitem

start

self-transition

Statetransition

/get first item

activity

guard condition

[not all items checked]/ get next item

action

event


Superstates

Item Received

[all items availa

ble]

Waiting

DeliveredCancelled

Checking Dispatching[all items checked &&all items available]

[all items checked&& some items not in stock]

Item received [some items not in stock]

cancelled

do/initiatedelivery

do/checkitem

get next item[not all items checked]

/get first item

Active


Concurrent States

Checking Dispatching

Waiting

AuthorisedAuthorising

Rejected

Delivered

Cancelled


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


An Activity Diagram


Another Activity Diagram


Joining Activity Diagrams


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


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 system’s 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 OO’s concentration on data abstraction


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)

cse3308 - software engineering: analysis and design, 2004lecture 6a.1 software engineering: analysis...

Documents