1/4/20

Object Oriented Analysis and

Design (2)

BY
DR. L. RANATHUNGA

Traditional Expressions of Functional

Requirements

— Requirements specifications
¡ Hard to read
— Context Diagram
¡ Specifies users, software, hardware that interface with system
— Data-flow Diagrams (DFD)
¡ Useful for technical people but tend to confuse users
¡ Useful in design of non-object-oriented systems
— Entity-relationship diagrams (ERD)
¡ Critical to database design but are not easily understood by users
— Prototypes
¡ Good communication tool to elicit information from user.
¡ Great for proof-of-concept tasks.
¡ Useful in developing user interface designs.

1
 1/4/20

UML Diagrams
— Instead of the Context, Data-Flow and Entity-
Relationship Diagrams used in Structured
Analysis, UML produces 9 types of diagrams
¡ Use Case Diagram
¡ Sequence Diagram
¡ Collaboration Diagram
¡ State chart Diagram
¡ Activity Diagram
¡ Class Diagram
¡ Object Diagram
¡ Component Diagram
¡ Deployment Diagram

Use Cases

§ Use cases are a means of expressing user

requirements.
§ Use cases are used extensively in the analysis
phase.
§ A use case represents how a system interacts with
its environment by illustrating the activities that
are performed by the users and the system s
responses.
§ The text-based use case is easy for the users to
understand, and also flows easily into the creation
of process models and the data model.

2
 1/4/20

Use Cases

— A use case depicts a set of activities that produce some

output result.
— Each use case describes how an external user triggers
an event to which the system must respond.
— With this type of event-driven modeling, everything
in the system can be thought of as a response to some
triggering event.
— Creation of use cases is often done as a part of interview
session with users or a part of JAD sessions.

Scenario

— A scenario is a sequence of steps describing an

interaction between a user and a system.

3
 1/4/20

Buy a Product

— The customer browses the catalog and adds desired items

to the shopping basket. When the customer wishes to pay,
the customer describes the shipping and credit card
information and confirms the sale. The system checks the
authorization on the credit card and confirms the sale both
immediately and with a follow-up email.

Use case

— A use case, then, is a set of scenarios tied together by

a common user goal.
— Jacobson is a scholar who has written about
capturing system requirements in packages of
transactions called use cases.

4
 1/4/20

What is a Use Case?

— The Use Cases describe the behavior of a system

from a user's standpoint using actions and reactions.
— The Use Case Diagram defines the system's
boundary, and the relationships between the system
and the environment:
¡ different human users roles interact with our system
¡ other software systems/applications
¡ hardware systems/devices
— Use Cases support the specification phase by
providing a means of capturing and documenting
requirements

5
 1/4/20

Use Case Deliverables

— There are two parts to document a use case:
¡ the use case diagram,
÷ provides visual overview of important interactions
÷ captures scope (identifies external entities)
¡ the use case itself
÷ documents in a textual form the details of the requirements,
what the use case must do.
÷ A use case is actually a page or two of text representing each
oval in the use case diagram
÷ A project should have a standard template for use cases.

Elements of a Use Case

Basic Information
§ Each use case has a name and number, and brief
description.
§ The priority may be assigned to indicate the relative
significance.
§ The actor refers to a person, another system, or a
hardware device that interacts with the system to
achieve a useful goal.
§ The trigger for the use case – the event that causes the
use case to begin.

6
 1/4/20

Example
4-13

Preconditions

— It is common practice to create smaller, more

focused use cases breaking the whole process down
into parts.
— It is important to define clearly what needs to be
accomplished before each use case begins.
— The preconditions define the state the system must
be in before the use case commences.

7
 1/4/20

Normal Course

§ The next part of a use case is the description of the major

steps that are performed to execute the response to the
event, the inputs used for the steps, and the outputs
produced by the steps.
§ The normal course lists the steps.

Alternative Courses

§ Alternative courses depict branches (alternative paths of

the steps) in logic that also will lead to a successful
conclusion of the use case.

8
 1/4/20

Post conditions

§ The postconditions section of defines the final product

of the use case.
§ These postconditions also serve to define the
preconditions for the next use case in the series.

Exceptions

— A use case should describe any error conditions or

exceptions that may occur as the use case steps are
performed.
— These are not normal branches in decision logic, but
are unusual occurrences or errors that could
potentially be encountered and will lead to an
unsuccessful result.

9
 1/4/20

Inputs and Outputs

§ The final section of the use case summarizes the set of

major inputs and outputs of the use case, along with their
source or destination.

Additional Use Case Issues

§ Additional sections may be included, e.g.,

- Frequency of use
- Business rules
- Special requirements
- Assumptions
- Notes and issues

10
 1/4/20

Chain of use cases – an example

Alternative Use Case Formats

§ A full-dressed use case is very thorough, detailed, and

highly structured.
§ The project team may decide that a more casual use case
format is acceptable.

11
 1/4/20

Use Cases and the Functional Requirements

§ Use cases are very useful tools to us to understand user

requirements. However, use cases only convey the
user’s point of view.
§ Transforming the user’s view into the developer’s view
by creating functional requirements is one of the
important contributions of system analyst.
§ The derived functional requirements give more
information to the developer about what the system
must do.

Actor

— An actor is someone or some thing that must interact with

the system under development

Registrar

Professor

Student

Billing System

12
 1/4/20

Use Cases

— A use case is a pattern of behavior the system exhibits

¡ Each use case is a sequence of related transactions performed
by an actor and the system in a dialogue
— Actors are examined to determine their needs
¡ Registrar -- maintain the curriculum
¡ Professor -- request roster
¡ Student -- maintain schedule
¡ Billing System -- receive billing information from registration

Maintain Curriculum Request Course Roster Maintain Schedule

Use Case Diagram

— Use case diagrams are created to visualize the
relationships between actors and use cases
— Show the interaction between use cases, which represent
system functionality, and actor, which represent the
people or system that provide or receive information
from the system.

Request Course Roster

Student
Maintain Schedule Professor

Billing System Maintain Curriculum

Registrar

13
 1/4/20

Use Case Diagram

actor system

Real Estate System

Buyer Sell Property

Seller

Advisor use case

interaction

ATM Use Cases

Deposit Funds Transfer Funds

Bank Officer

Customer
Withdraw Money

Change PIN

View Balance
External
Make Payment
system
Credit System

14
 1/4/20

Associations in Use Case Diagram

— Associations can exist

¡ between an actor and a use case,
¡ between use cases
¡ between actors
— Types of Use Case Associations
¡ Communicates between actor and use case
÷ named or unnamed relationship showing participation of actor in use
case, use a solid line connecting actor to use case
¡ Generalization between actors

Associations in Use Case Diagram

— adornments = Stereotyped Associations between use cases
¡ <<extend>>
indicates relationship between use cases in which a special use case (the non-
arrow end) extends an original use case (the arrow end)
¡ <<include>>
reuses steps in a use case instead of cut-and-pasting steps into multiple use
case documents, by pulling out common steps into a new use case and
specifying with an arrowed line the <<include>> association between this
new use case and those use cases requiring the steps
¡ <<uses>>
An instance of the source use case includes behavior described by the target,
Shows a stereotyped generalization relationship between use cases

15
 1/4/20

Use Case Relationships

— Include, when you have a chunk of behaviors that is

similar across more than one use case
— Generalization, when you have one use case that is
similar to another use case but does a bit more
— Extend, similar to generalization but with more rules
to it.

16
 1/4/20

Rules

— Use include when you are repeating yourself in two

or more separate use cases and you want to avoid
repetition.
— Use generalization when you are describing a
variation on normal behavior and you wish to
describe it casually.
— Use extend when you are describing a variation on
normal behavior and you wish to use the more
controlled form, declaring your extension points in
your base use case.

Example of Generalization between Use Case Actors

Service Representative

Customer Service Representative Field Service Representative

17
 1/4/20

Example of Communicates Use Case Relationship

Sell Property

Buyer

Triggers
Sell Property

Buyer

Example <<uses>> and <<extends>>

Use Case Relationships
Transfer by computer

Remote Customer Local Customer

<<extends>>

Transfer

<<uses>>

Identification

18
 1/4/20

Example <<include>> and

<<extends>> Use Case Relationships
Schedule Customer
Appointment

Office Administrator <<extends>>

<<includes>>

Schedule Recurring
Schedule Designer Customer Appointment

<<includes>>

Enter Customer Order

More example

19
 1/4/20

Library Case Exercise

Problem Statement:
A library contains video cassettes which can be borrowed by registered
uses. User can borrow at most four items. User can reserve a cassette
which item is on loan. User can reserve at most 2 items. User can
borrow a returned item again if it is not reserved. User can search for
a particular item in a library by a keyboard.

Exercise: Create a Use Case Diagrams and Scenarios

Class Diagram

— A class diagram shows the existence of classes and

their relationships in the logical view of a system
— UML modeling elements in class diagrams
¡ Classes and their structure and behavior
¡ Association, aggregation, dependency, and inheritance
relationships
¡ Role names

20
 1/4/20

Classes

— A class is a collection of objects with common structure,

common behavior, common relationships and common
semantics
— Classes are found by examining the objects in sequence and
collaboration diagram
— A class is drawn as a rectangle with three compartments
— Classes should be named using the vocabulary of the
domain
¡ Naming standards should be created
¡ e.g., all classes are singular nouns starting with a capital letter

Example

RegistrationManager ScheduleAlgorithm

RegistrationForm

Course
Student

Professor
CourseOffering

21
 1/4/20

More example

Relationship

— Relationships provide a pathway for communication

between objects
— Sequence and/or collaboration diagrams are
examined to determine what links between objects
need to exist to accomplish the behavior -- if two
objects need to “talk” there must be a link between
them
— Three types of relationships are:
¡ Association
¡ Aggregation
¡ Dependency

22
 1/4/20

Relationship

— An association is a bi-directional connection between classes

¡ An association is shown as a line connecting the related classes
— An aggregation is a stronger form of relationship where the
relationship is between a whole and its parts
¡ An aggregation is shown as a line connecting the related
classes with a diamond next to the class representing the
whole
— A dependency relationship is a weaker form of relationship
showing a relationship between a client and a supplier where the
client does not have semantic knowledge of the supplier
— A dependency is shown as a dashed line pointing from the client
to the supplier

Finding relationship

— Relationships are discovered by examining interaction

diagrams
¡ If two objects must “talk” there must be a pathway for
communication

RegistrationManager
Registration Maths 101:
Manager Course

3: add student(kamal)

Course

23
 1/4/20

ScheduleAlgorithm
RegistrationForm

RegistrationManager

addStudent(Course, StudentInfo)
Course
name
numberCredits

Student
open()
name addStudent(StudentInfo)
major

Professor
name CourseOffering
tenureStatus
location

open()
addStudent(StudentInfo)

Associations

24
 1/4/20

Aggregation

— Associations denote relationships between classes

— Aggregation “consists of” hierarchy.
— The aggregate is the parent class, the components are the
children class.

Exhaust System

1 0..2
Muffler Tailpipe

Composition

— A solid diamond denote composition, a strong form of

aggregation where components cannot exist without the
aggregate.

TicketMachine

3
ZoneButton

25
 1/4/20

Generalization

— Is a kind of

26
 1/4/20

More examples

More examples

27
 1/4/20

Sequence diagram

— A sequence diagram displays object interactions

arranged in a time sequence
— It is used to show the flow of functionality through a
use case

Sequence Diagrams

— Used during requirements analysis

¡ To refine use case descriptions
¡ to find additional objects (“participating objects”)
— Used during system design
¡ to refine subsystem interfaces
— Classes are represented by columns
— Messages are represented by arrows
— Activations are represented by narrow rectangles
— Lifelines are represented by dashed lines

28
 1/4/20

Nested Messages

ZoneButton TarifSchedule Display

Passenger

selectZone()
lookupPrice(selection)

price
displayPrice(price)
Dataflow

n The source of an arrow indicates the activation which

sent the message
n An activation is as long as all nested activations

TicketMachine
Passenger
selectZone()

insertCoins()

pickupChange()

pickUpTicket()

29
 1/4/20

More example

: Student registration registration math 101 math 101

form manager section 1

1: fill in info

2: submit

3: add course(Kamal, math 01)

4: are you open?
5: are you open?
6: add (joe)
7: add (joe)

Collaboration Diagrams

— Show exactly the same functions as the sequence

diagram
— But it shows in different way and different purpose

30
 1/4/20

Collaboration diagram

— A collaboration diagram displays object interactions

organized around objects and their links to one another

course form :
1: set course info CourseForm
2: process

: Registrar 3: add course

aCourse : theManager :
Course CurriculumManager

4: new course

Activity Diagrams

— An activity diagram shows flow control within a

system

31
 1/4/20

Example

State diagram

— A state transition diagram shows

¡ The life history of a given class
¡ The events that cause a transition from one state to another
¡ The actions that result from a state change
— State transition diagrams are created for objects with
significant dynamic behavior

32
 1/4/20

Example

Add student[ count < 10 ]

Add Student /
Initialization Set count = 0
Open
do: Initialize course
entry: Register student
exit: Increment count

Cancel

Cancel [ count = 10 ]

Canceled
do: Notify registered students
Closed
Cancel do: Finalize course

Object Modeling with the Unified Modeling Language

— CASE Tools
¡ Object modeling requires many types of diagrams to represent
the proposed system
¡ Creating the diagrams by hand is time-consuming and tedious,
so systems analysts rely on CASE tools to speed up the process
and provide an overall framework for documenting the system
components

33
 1/4/20

— Questions?

34