cse3308 - software engineering: analysis and design, 2004lecture 6a.1 software engineering: analysis...
Post on 22-Dec-2015
223 views
TRANSCRIPT
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.4
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.
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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.
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.9
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.10
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.11
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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)
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.14
A Package Diagram
Order Capture UI AWT
MailingList UI
Mailing ListApplication
CustomersOrders
Order Capture
Application
dependency
package
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.15
Another package diagramOrder
Capture UI AWT MailingList UI
Mailing ListApplication
CustomersOrders
Order Capture
Application
Domain
QuantityMoneyDate Range
Common{global}
DatabaseInterface{abstract}
OracleInterface
SybaseInterface
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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 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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.18
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.19
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.20
Concurrent States
Checking Dispatching
Waiting
AuthorisedAuthorising
Rejected
Delivered
Cancelled
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.22
An Activity Diagram
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.23
Another Activity Diagram
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.24
Joining Activity Diagrams
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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 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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 6A.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)