Se analysis and design

CSE3308 - Software Engineering: Analysis and Design, 2005 Lecture 5B.1

Software Engineering: Analysis and Design - CSE3308

Object-Oriented Analysis 1

CSE3308/DMS/2005/15

Monash University School of Computer Science and Software Engineering


Lecture Outline

Object-Oriented Analysis

The Unified Modeling Language

Use Cases

Class Diagrams


Object-Oriented Analysis

1989 - Object-Oriented Systems Analysis - Modeling the World in Data by Shlaer and Mellor (ER Modeling by another name)

Early 90’s 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”


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


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

Generalization

Relationship

AssociationAssociation

Role2..*

1

{ordered}

Part of the UML specification,

expressed in UML


Tools of UML

Use Cases (from Ivar Jacobson) Class Diagrams Interaction Diagrams

Sequence Diagrams Collaboration Diagrams

Package Diagrams State Diagrams Activity Diagrams Deployment Diagrams


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

Elaboration TransitionConstruction

1 2 3 ...

Inception


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


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


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 system’s 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


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


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 itemsand collects payment. On completion, the Customer leaves with the items


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


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

Essential/Abstract

Real/Concrete


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 topurchase. The Cashier records the purchase items and collects a cash payment. Oncompletion, 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 <<extends>>, <<includes>> or generalization)


Expanded Use Case (2)

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 informationto the running sales transaction. The descriptionand price of the item are presented.5. Calculates and presents the sale total.

TYPICAL COURSE OF EVENTS

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.

ACTOR ACTION SYSTEM RESPONSE

9. Show the balance due back to the Customer.Generates a receipt.

11. Logs the completed sale.



Alternative Courses Line 2: Invalid identifier entered. Indicate

error Line 7: Customer didn’t 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


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


Your turn

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


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

Icon for a use case Icon for an actor

Association between ause case and an actor


A simple use case diagram

Customer

Buy Items

Cashier

Pay for Items


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


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

Child Use Case

Parent UseCase


Example of Generalization in a Use Case Diagram

ValidateUser

RetinalScan

CheckPassword


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<<includes>>


Example of Include in a Use Case Diagram

ValidateUser

PlaceOrder

TrackOrder

<<include>>

<<include>>


Example of Include in a Track Order Use Case

1. Input order number

Actor Action System Response

2. Verify Order Number

Include (Validate User)

3. For each part in the order,query its status4. Report back to user

Note: “includes” should also be mentioned in the overview section of the Use Case, under “cross-references”


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

<<extends>>


Example of Extends in a Use Case Diagram

Place OrderPlace Rush

Order

<<extends>>(set priority)

“set priority” is the name of the extension point in the Place Order Use Case


Example of Extends in a Use Case

Actor Action System Response

1. Ask for order to be placed

2. Verify customer details.

Include (Validate User)

3. Collect the user’s order items.(set priority)4. Submit order for processing

Note: extends should also be mentioned in the cross-references section of the Use Case


Your turn

Draw a Use Case Diagram for an ATM machine


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


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


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


Classes Represented by a

rectangle 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 be

shown as navigable

Components of a Class Diagram

Customer


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

String: name;Addr: address;

Rating: creditRating();

Class Name

Attributes

Operations


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


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:

Association Multiplicity

Gift WrapPaper

OrderLine

ProductReview

Customer1

Many (zero or more)

Many (one ormore)

Exactly one

0..*

PurchaseHistory

Customer

1Exactly one

1 writes

Exactly one Order1 1..*

Optional(zero or one)Order 0..10..*Many (zero or

more)

Exactly one


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):

Order

OrderLine: myOrderLines[];

Case A

OrderLine

Order: myOrder;

Case Bor


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?)

Order OrderLine1 1..*


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


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


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


Whole/part Examples

Composition Aggregation

Glider

WingTailFuselage

2 1 1

Order

OrderLine

lineItem

{ordered}

1..*

1


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

Person Company*employer

Employment

period

0..1

Association Class

Role name


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


Generalisation example

Product

Book CD DVD

Generalization Symbol


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


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


Stereotypes Is a general extension mechanism for the UML Stereotypes are shown between << >> A stereotype outlines certain responsibilities that a

class will undertake Example: showing a class is actually an interface à

la Java

DataInput

<<interface>>


Bringing it all together: A Class DiagramIndividual CustomerBusiness Customer 1..* Division1..*

1..* Book1..*Publisher 1..*1..* publishes

Purchase record

1..*

0..*

1

1

1

Order line

1..*

1

Warehouse

0..*1

1 1Order

1..*

0..*

1fills

0..*

1

Customer<<abstract>>

0..*1places

1 1emails

Customer Database0..*0..*

Product<<abstract>>

1

1

corresponds to1..*

1

stores

0..*

1

purchases

Inventory Database 1..*1..*


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)

Date post:	08-Dec-2014
Category:	Education
Upload:	abdur-muhammadi
View:	712 times
Download:	4 times

Se analysis and design

Education