Software Engineering: Analysis and Design CSE3308

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

• Object-Oriented Analysis 1

2
Lecture Outline

• Object-Oriented Analysis
• The Unified Modeling Language
• Use Cases
• Class Diagrams

3
Object-Oriented Analysis

• 1989 - Object-Oriented Systems Analysis -
  Modeling the World in Data by Shlaer and Mellor
  (ER Modeling by another name)
• Early 90s a host of books appeared
• Coad and Yourdon Object-Oriented Analysis
• Jacobson Object-Oriented Software Engineering
• Rumbaugh et al. Object-Oriented Modeling and
  Design
• Booch Object-Oriented Analysis and Design with
  Applications
• Shlaer and Mellor Object Lifecycles Modeling
  the World in States

4
Unified Modeling Language

• 1994 - Grady Booch and Rational Software hire Jim
  Rumbaugh away from General Electric
• 1995 Version 0.8 of the Unified Method released
• Late 1995 - Ivar Jacobson joins Rational from
  Ericsson, become the Three Amigos
• Jan 1997 - Version 1.0 of the Unified Modeling
  Language is released
• Current version is 1.5, released March 1st, 2003
• UML 2.0 is nearing finalization (expected mid
  2005)
• August 1997 - The Object Management Group (CORBA
  people) select UML to be the standard OO modeling
  notation
• Backed by Microsoft, HP, DEC, etc.
• February 2002 IBM acquires Rational Software
• Rational tools are to be integrated with the
  Eclipse framework

5
Unified Modeling Language

• Is a notation
• Is not a software process or method
• Is a meta-model
• A meta-model is a rigorous definition of the
  notation and the rules governing relationships
  between its components

Part of the UML specification, expressed in UML
Relationship
1
Generalization
Association Role
Association
2..
ordered
6
Tools of UML

• Use Cases (from Ivar Jacobson)
• Class Diagrams
• Interaction Diagrams
• Sequence Diagrams
• Collaboration Diagrams
• Package Diagrams
• State Diagrams
• Activity Diagrams
• Deployment Diagrams

7
The Rational Unified ProcessAn Outline Process
suitable for using UML

• The Rational Unified Process (RUP) is a Software
  Development Process (or lifecycle) suitable for
  users of UML. It belongs to the iterative family
  of processes.
• It has four main phases
• Note the RUP is not the same thing as UML
• You do no need to use UML to use the RUP
• You do not need to use the RUP to use UML

8
Process Stages

• Inception
• Establish the business rationale and scope of the
  project, obtain commitment of the sponsor
• Elaboration
• Detailed requirements, high-level analysis and
  design to establish a baseline architecture and
  create the construction plan
• Construction
• many iterations of producing production-quality
  software, tested and integrated, that satisfies a
  subset of the requirements. Each iteration
  contains analysis, design, implementation and
  testing
• Transition
• beta testing, performance training and user
  training

9
Elaboration elaborated

• In this phase you look closely at
• What is it you are actually going to build?
• How are you going to build it?
• What technology are you going to use?
• The riskier an aspect, the closer you should
  examine it
• Requirements risks
• Technological risks
• Skills risk
• Political risks
• UML best handles requirements risks

10
The process begins

• We need to develop two main models in this phase
• A Use Case Model
• details the interactions between the system and
  the outside world
• A Domain Model
• provides a conceptual model of the environment
  the system is working in
• Captures the most important types of objects in
  the context of the system
• Represents the things that exist, or events
  that transpire, in the systems environment
• Described in UML diagrams typically class
  diagrams
• Not treated in detail in this unit (see Jacobson,
  Booch, Rumbaugh, 1998 (Ch. 6))
• These two models are analogous to the Event List,
  Context Diagram and the Figure 0 DFD

11
Use Cases

• A Use Case is a narrative document that describes
  the interaction between actor(s) and the system
  during a usage scenario
• Properties A Use Case
• captures some user-visible function
• is a relatively large end-to-end process
• achieves some discrete goal for the user
• You need some understanding of the requirements
  before starting to develop your use cases
• Use cases are not really OO
• but are often associated with OO because they are
  part of UML

12
Cash Register ExampleHigh-level Use Case
Use Case Buy items Actors Customer,
Cashier Type Primary Description
A Customer arrives at a checkout with items to
purchase. The Cashier records the purchase
items and collects payment. On completion, the
Customer leaves with the items
13
Components of a High-LevelUse Case

• NAME - start with a verb to emphasise that it is
  a process
• ACTOR - is a role that a user plays in respect
  to the system. Actors are generally shown when
  they are the ones who need the use case.
• The system is never an actor
• TYPE
• Primary - represent major common processes
• Secondary - represent minor or rare processes
• Optional - processes that may not be implemented
  in the system depending upon resources
• DESCRIPTION - short and essential

14
Use Case Level of Detail

• High-level
• terse description of the activities without going
  into details of how activities are performed
• Expanded
• shows more detail than a high-level one, details
  the sequence of events in the process
• generally done in a conversational style
• show alternative courses
• shows the initiator of the use case
• Real
• details concretely the process in terms of its
  real current design, input and output technologies

15
Expanded Use Case Example
Use Case Buy Items with Cash Actors Customer
(initiator), Cashier Purpose Capture a sale and
its cash payment Overview A Customer arrives
at a checkout with items to purchase. The
Cashier records the purchase items and
collects a cash payment. On completion, the
Customer leaves with the items. Type primary
(essential level) Cross-references none
The cross-references line lists the IDs of any
other Use Cases to which this one refers (via
ltltextendsgtgt, ltltincludesgtgt or generalization)
16
Expanded Use Case (2)
TYPICAL COURSE OF EVENTS
ACTOR ACTION
SYSTEM RESPONSE

• 1. This use case begins when a Customer arrives
  at the register with items to purchase.
• 2. The cashier records the identifier from each
  item. If more than one of the same item, the
  Cashier can enter the quantity as well.
• 4. Cashier indicates completion of item entry.
• 6. Cashier tells the Customer the total.

3. Determines the item price and adds the item
information to the running sales transaction.
The description and price of the item are
presented.
5. Calculates and presents the sale total.
17
Expanded Use Case (3)
ACTOR ACTION
SYSTEM RESPONSE

• 7. The Customer gives a cash payment - possibly
  greater than the sale total.
• 8. The Cashier records the cash received amount.
• 10. The Cashier deposits the cash received and
  extracts the balance owing. Cashier gives balance
  and receipt to Customer.
• 12. Customer leaves with items purchased.

9. Show the balance due back to the
Customer. Generates a receipt.
11. Logs the completed sale.
18
Expanded Use Case (4)

• Alternative Courses
• Line 2 Invalid identifier entered. Indicate
  error
• Line 7 Customer didnt have enough cash. Cancel
  sales transaction
• If a Typical Course of Events has multiple
  equally likely courses of action
• indicate branches in Use case
• write a subsection for each branch indicating the
  typical course of events
• have alternatives for each subsection if necessary

19
Identifying Use Cases

• Using the actors
• Identify the actors related to a system or
  organisation
• For each actor, identify the processes they
  initiate or participate in
• Using events
• Identify the external events that a system must
  respond to
• Relate the events to actors and use cases
• Examples
• Withdraw cash from ATM
• Order a product
• Enrol for a subject
• Check the spelling of a document
• Handle a telephone call

20
Your turn

• Automated Teller Machine (ATM) at Bank
• Who are the Actors?
• Name four use cases that could be developed

21
Use Case Diagrams

• Illustrates a set of use cases for a system, the
  actors and the relationships between actors and
  use cases.
• Each use case diagram is for a particular subject
  area

Association between a use case and an actor
Icon for a use case
Icon for an actor
22
A simple use case diagram
Buy Items
Cashier
Customer
Pay for Items
23
Organizing Use Cases

• In many situations we find that use cases are
  very similar
• We need mechanisms to handle these similarities
• Three mechanisms in the UML
• Generalization
• Includes
• Extends

24
Generalization

• This means that a child use case inherits the
  behaviour and meaning of the parent use case
• The child may add or override the behaviour of
  the parent
• The child may be substituted in any place the
  parent may appear in the system
• Generalization appears as

Parent Use Case
Child Use Case
25
Example of Generalization in a Use Case Diagram
Check Password
Validate User
Retinal Scan
26
Includes

• This means that a particular use case explicitly
  incorporates the behaviour of another use case at
  a location specified in that use case it is
  included
• An including use case never stands alone
• The included use case, however, can
• An include relationship is used to avoid
  describing the same flow of events several times,
  by putting the common behaviour in a use case of
  its own
• include appears as

ltltincludesgtgt
27
Example of Include in a Use Case Diagram
Place Order
ltltincludegtgt
Track Order
Validate User
ltltincludegtgt
28
Example of Include in a Track Order Use Case
Actor Action
System Response
1. Input order number
2. Verify Order Number
Include (Validate User)
3. For each part in the order, query its
status 4. Report back to user
Note includes should also be mentioned in the
overview section of the Use Case, under
cross-references
29
Extends

• Extends is used to separate optional behaviour
  from mandatory behaviour
• The base use case optionally incorporates the
  behaviour of another use case at a location
  specified indirectly by the extending use case
• The base use case may stand alone, but under
  certain conditions, it may be extended by another
  use case.
• It may be extended only at certain points known
  as extension points
• Extends appears

ltltextendsgtgt
30
Example of Extends in a Use Case Diagram
ltltextendsgtgt (set priority)
Place Order
Place Rush Order
set priority is the name of the extension point
in the Place Order Use Case
31
Example of Extends in a Use Case
System Response
Actor Action
1. Ask for order to be placed
2. Verify customer details.
Include (Validate User)
3. Collect the users order items. (set
priority) 4. Submit order for processing
Note extends should also be mentioned in the
cross-references section of the Use Case
32
Your turn

• Draw a Use Case Diagram for an ATM machine

33
Class Diagrams

• Initial use is to provide a conceptual model of
  the system
• A class diagram shows
• Concepts
• Associations between concepts
• Attributes and methods
• Initially (conceptual level)
• Not a model of the software design
• Shows real world concepts
• Better to over-specify than to under-specify

34
Three perspectives

• Conceptual
• used in initial analysis
• described previous slide
• Specification
• does describe software
• describes the interfaces of your software, not
  the implementation
• types rather than classes
• Implementation
• describes the actual software in the system
• classes

35
Identifying Concepts

• Physical objects Aeroplane
• Specifications Product Specification
• Places Shop
• Transactions Sale
• Transaction Line Items Sale Line Item
• Roles of people Cashier
• Containers Bin
• Things in a container Item
• Other computer systems Credit card authorisation
  system

• Abstract Nouns Hunger
• Organisations - Sales Department
• Events Meeting, Flight
• Rules and policies Refund policy
• Catalogues Product Catalogue
• Records Receipt, Ledger
• Financial instruments Line of credit
• Manuals Repair manual

36
Components of a Class Diagram

• Classes
• Represented by arectangle containingthe class
  name (andoptionally with sectionsshowing
  attributes andoperations)
• Associations
• Indicate the existence of a relationship between
  two classes. Basic representation is a straight
  line
• Special kinds of associations exist, e.g.
• Aggregation
• Generalization
• Associations can beshown as navigable

Customer
37
Attributes and Operations

• We can choose to show various aspects of the
  classes
• At a conceptual level we have
• Attributes which indicate which data a class is
  going to keep conceptually
• Operations which indicate the responsibilities of
  a class

Customer
Class Name
String name Addr address
Attributes
Rating creditRating()
Operations
38
Associations

• Represent conceptual relationships between
  classes
• and existence of attributes at specification and
  implementation levels
• Associations should be named if it adds to
  understanding
• Each association has two roles
• A role has a direction on the association, e.g.
• Customer to Order role
• Order to Customer role
• Each role can be explicitly named, if not named,
  then the role is called after the target class,
  i.e. the role from Order to Customer is called
  Customer

39
Association Multiplicity

• Each end of an association can have its
  multiplicity shown. This indicates how many
  objects of each class are involved in the
  association. For example

PurchaseHistory
Customer
1
1
Exactly one
Exactly one
Many (zero or more)
writes
ProductReview
1
Customer
0..
Exactly one
Many (one ormore)
OrderLine
1
Order
1..
Exactly one
Optional(zero or one)
Order
Gift WrapPaper
Many (zero or more)
0..
0..1
40
Association Navigability (1)

• When implementing associations, classes need to
  be given attributes to manage the association
• For example, if an Order can consist of one or
  more OrderLines (each corresponding to a single
  product), either the Order class must have a list
  of its OrderLines (case A), or each OrderLine
  must have a reference to the Order to which it
  belongs (case B)

Case A
Case B
or
41
Association Navigability (2)

• At the conceptual level, names and types of
  attributes are typically not yet known
• The directions in which associations could and
  should be navigated, however, often are
• This is shown on a class diagram by placing an
  arrow on the association
• i.e. an Order knows how to find its OrderLines
  (Case A on previous slide)
• Associations can be navigable in both directions
• Though this can lead to maintenance problems (Can
  you think why?)

1
1..
42
Whole/Part Associations

• UML has special notation for two whole/part
  associations composition and aggregation
• There is disagreement about the exact meanings of
  these terms
• Coad and Yourdon - an organisation is an
  aggregation of its employees
• Rumbaugh - an organisation is not an aggregation
  of its employees
• Some say that the important issue is cascading
  delete
• If you destroy an object that is a composite, you
  must destroy all its component objects too
• When you destroy an object representing an
  aggregation, you do not destroy the members of
  the aggregate
• The important thing is to choose a convention and
  then to stick to it

43
Composition

• Composition is a common structure in software
  systems, because many composite objects appear in
  real life
• a dog is a composite of a head, a body, a tail
  and 4 legs
• an email is composed of a header and a text
  message the header is composed of a From line a
  To line, etc.
• Three most important characteristics
• The composite object does not exists without its
  components
• At any time, each component may be part of only
  one composite
• Component objects are likely to be of mixed types

44
Aggregation

• Aggregation is also a familiar concept from real
  life
• a forest is an aggregate of trees
• a flock is an aggregate of sheep
• Aggregation is a group/member association
• Three most important characteristics
• The aggregate object may potentially exist
  without its constituent objects (not always
  useful though)
• At any time, each object may be a constituent of
  more than one aggregate (e.g. a person may belong
  to several clubs)
• Constituent objects are typically of the same
  class

45
Whole/part Examples
Aggregation
Composition
Glider
Order
1
ordered
2
1
1
lineItem
1..
Wing
Tail
Fuselage
OrderLine
46
Association Classes

• Allow you to add attributes, operations and other
  features to associations
• Can only be one instance of the association
  between any two participating objects

Company
Person
0..1

employer
Role name
Employment
Association Class
period
47
Generalisation

• At the conceptual level, we can say that a
  particular class is a subtype of another class if
  all instances of the first class are also
  instances of the second class.
• For example, in an on-line store such as Amazon,
  Book is a sub-class of Product
• All the associations, attributes and operations
  of Product (e.g. price, addToShoppingBasket())
  are true for Book
• At the implementation level, generalization is
  usually delivered using inheritance, but other
  mechanisms are possible, e.g. delegation

48
Generalisation example
Product
Generalization Symbol
Book
CD
DVD
49
Dependency

• A dependency is a relationship which indicates
  that a change in specification of one thing may
  affect another thing that uses it, but not
  necessarily the reverse
• Use dependency when you want to show one thing
  using another
• Often used to show that one class uses another as
  an argument to one of its operations

Event
Window
50
Constraints

• The elements of a class diagram (associations,
  attributes and generalization, etc.) are
  effectively placing constraints on the system
• e.g. an order must have a customer
• Other constraints are often necessary
• Place these constraints inside
• At the conceptual level, use simple statements
• Constraints are ideally implemented as assertions
• ordered and abstract are common constraints

51
Stereotypes

• Is a general extension mechanism for the UML
• Stereotypes are shown between ltlt gtgt
• A stereotype outlines certain responsibilities
  that a class will undertake
• Example showing a class is actually an interface
  à la Java

DataInput
ltltinterfacegtgt
52
Bringing it all together A Class Diagram
1..
1..
Individual Customer
Business Customer
Division
emails
1
1
1
ltltabstractgtgt
1
0..
0..
Order
Customer Database
Customer
1
1
0..
0..
places
0..
0..
1
1
fills
1
1
purchases
Warehouse
1..
1..
1
1
Purchase record
Order line
stores
0..
0..
1
1
1..
1..
corresponds to
ltltabstractgtgt
1..
1..
Inventory Database
1
1
Product
publishes
1..
1..
1..
1..
Book
Publisher
53
References

• Booch, Grady, Rumbaugh, James, and Jacobson,
  Ivar, The Unified Modeling Language User Guide,
  Addison-Wesley, 1998 (Chs. 4, 5, 8, 16, 17)
• Fowler, Martin, UML Distilled, Addison-Wesley,
  1997 or 2000 (Chs. 2, 3, 4)
• Jacobson, Ivar, Booch, Grady, and Rumbaugh,
  James, The Unified Software Development Process,
  Addison-Wesley, 1998 (Ch. 6)
• Page-Jones, Meilir, Fundamentals of
  Object-Oriented Design in UML, Addison-Wesley,
  2000 (Ch. 4)