SOFTWARE ENGINEERING

Lecture 3
 2

Analysis & Design

• Analysis
• Investigation of problem and requirements, rather than a solution
• E.g. Requirements analysis and OO analysis
• Design
• It emphasizes a conceptual solution that fulfills the requirements.
• E.g. Database design or OO design
• Implementation expresses the true and complete realized design
 3

Object Oriented Analysis (OOA)

• OOA is “a method of analysis that examines
requirements from the perspectives of the classes and
objects” (Booch 1995)

• Emphasis is on finding and describing conceptual

objects in the problem domain
 4

Object Oriented Design (OOD)

• OOD is “a method of design encompassing the process of
OO decomposition and a notation for depicting both
logical and physical as well as static and dynamic
models of the system” (Booch 1995)
• Emphasis is on defining software objects, and how they
collaborate to fulfill system requirements
 5

What is OO analysis and design?

• Essence of OO analysis
• consider a problem domain from the perspective of objects (real
world things, concepts)

• Essence of OO design
• define the solution as a collection of software objects (allocating
responsibilities to objects)
 6

Examples- Library Information System

• OO Analysis - in the case of the library information
systems, one would find concepts like book, author,
publisher

• OO Design - emphasis on defining the software objects;

ultimately these objects are implemented in some
programming language; Book may have a method named
print.
(Objects with functionalities)
 7

Examples- Library Information System

Book visualization of
domain concept
domain concept
title

public class Book

{
representation in an
private String title;
object-oriented
programming language
public Chapter getChapter(int) {...}
}
 8

Flight Information System

Plane
visualization of
domain concept
domain concept tailNumber

public class Plane

{
representation in an private String tailNumber;
object oriented
programming language public List getFlightHistory() { …}
}
What is UML and Why we use UML?
 UML → “Unified Modeling Language”
Language: express idea, not a methodology

Modeling: Describing a software system at a high level of

abstraction

Unified: UML has become a world standard

Object Management Group (OMG): www.omg.org
What is UML and Why we use UML?
 More description about UML:
 It is a industry-standard graphical language for specifying, visualizing,
constructing, and documenting the artifacts of software systems

 The UML uses mostly graphical notations to express the OO analysis and
design of software projects. 

 Simplifies the complex process of software design

What is UML and Why we use UML?
 Why we use UML?
 Use graphical notation: more clearly than natural language
(imprecise) and code (too detailed).

 Help acquire an overall view of a system.

 UML is not dependent on any one language or technology.

 UML moves us from fragmentation to standardization.

 12

UML Diagrams
• UML defines 13 basic diagram types, divided
into two general sets:
• Structural Modeling Diagrams
• Structure diagrams define the static architecture of a model
1. Package diagrams are used to divide the model into logical
containers or 'packages' and describe the interactions
between them at a high level
2. Class or Structural diagrams define the basic building
blocks of a model: the types, classes and general materials
that are used to construct a full mode.
3. Object diagrams show how instances of structural elements
are related and used at run-time.
4. Composite Structure diagrams provide a means of layering
an element's structure and focusing on inner detail,
construction and relationships
 13

UML Diagrams
5. Component diagrams are used to model higher level or more
complex structures, usually built up from one or more classes,
and providing a well defined interface
6. Deployment diagrams show the physical disposition of significant
artifacts within a real-world setting.
Profile
• Profile diagrams are those created in a «profile» Package, to
extend UML elements, connectors and components.
 15

UML Diagrams
• Behavioral Modeling Diagrams
Behavior diagrams capture the varieties of
interaction and instantaneous state within a model
as it 'executes' over time.
1. Use Case diagrams  are used to model user/system interactions.
They define behavior, requirements and constraints in the form of
scripts or scenarios
2. Activity diagrams  have a wide number of uses, from defining
basic program flow, to capturing the decision points and actions
within any generalized process
3. State Machine diagrams  are essential to understanding the
instant to instant  condition or "run state" of a model when it
executes
 16

UML Diagrams
4. Communication diagrams show the network and sequence of
messages or communications between objects at run-time during
a collaboration instance
5. Sequence diagrams  are closely related to Communication
diagrams and show the sequence of messages passed between
objects using a vertical timeline
6. Timing diagrams fuse Sequence and State diagrams to provide a
view of an object's state over time and messages which modify
that state
Interaction Overview Diagrams
• Interaction Overview diagrams visualize the cooperation
between Interaction diagrams (Timing, Sequence,
Communication and other Interaction Overview diagrams) to
illustrate a control flow serving an encompassing purpose.
 18

What is a Use Case?

The indispensable first step to getting the
things you want out of life:

decide what you want.

(Ben Stein)
 19

What is a Use Case?

• Narrative descriptions of domain processes in a
structured prose format

• They are stories or scenarios of how people use the

system
Use-Case Diagrams
• A use-case diagram is a set of use cases
• A use case is a model of the interaction between
 External users of a software product (actors) and
 The software product itself
 More precisely, an actor is a user playing a specific role

• describing a set of user scenarios

• capturing user requirements
• contract between end user and software developers
 21

Example: Dice Game

• Problem Statement
• A software simulates a player rolling two dice. If the total
is seven, they win; otherwise, they lose.

• Use Case
Use Case Name: Play a Dice Game
Actor: Player
Description: Player requests to roll the dice. System
presents results: If the dice face value totals seven,
player wins; otherwise, player loses.
 22

Use Case, Actor, and Scenario

• Actors
• Something with behavior such as person, computer system, or
organization
• Scenario
• It is a specific sequence of actions and interactions between
actors and the system
• It is also called use case instance
• It is one particular story of using a system
• Example: scenario of successfully purchasing items with cash or
scenario of failing to purchase items because of credit payment
denial
• Use case then is a collection of success and failure scenarios
• Use cases are requirements, primarily functional
 23

Use Case, Actor, and Scenario

• A UC is a dialogue between an actor and a system
that accomplishes a task
• The dialogue is presented as a sequence of steps
• A complete sequence of steps is a use case
scenario
• A scenario (UC instance) forms a complete path
through the UC
• A UC can contain multiple scenarios/paths
• UCs are not object-oriented artifacts! They feed
into other OO models
 24

Kinds of Actors
• Primary actor
• has user goals fulfilled through using services of the SuD
(single user device)
• why identify? To find user goals, which drive use cases

• Supporting/Secondary actor
• provides a service (for example, information) to the SuD
• why identify? To clarify external interfaces and protocols
 25

Guidelines: How to Find Use Cases?

• Four Steps

1. Choose the system boundary

2. Find primary actors

3. Identify goals for each primary actor

4. Define use cases that satisfy user goals

i. Draw Use Case Diagram
ii. Write Use Case Text
 26

1. Choose the System Boundary

 27

2 and 3. Primary Actors and their Goals

• Brainstorm (pooling of spontaneous ideas about a
problem) the primary actors first
• Questions to help identify actors and goals
• Who starts and stops the system?
• Who does user and security management?
• Who does system administration?
• Is “Time” an actor because the system does something in
response to a time event?
• Are there any external software system that call upon the
services of the system?
• Organize the actors and goals in an Actor Goal List
 28

Actor Goal List

Use-Case Diagrams

Boundary Use Case

Actor Library System

Borrow Employee
Client

Order Title

Fine Remittance

Supervisor
 30

4. Define Use Cases that Satisfy User Goals

(i. Use Case Diagram)
Use Case Associations
• Use case association = relationship between use cases
• Important types:
• Include
• A use case uses another use case (functional
decomposition and reuse of existing functionality)
• Extends
• A use case extends another use case
• Generalization
• A use case has different specializations
Use-Case Diagrams
• Association:
communication between an actor and a use case; Represented by a solid line.

• Generalization: relationship between one general use case and a special use case
(used for defining special alternatives) Represented by a line with a triangular arrow
head toward the parent use case.
Use-Case Diagrams
Include: a dotted line labeled <<include>> beginning at base
use case and ending with an arrows pointing to the include use
case. The include relationship occurs when a chunk of
behavior is similar across more than one use case. Use
“include” in stead of copying the description of that behavior.
<<include>>

Extend: a dotted line labeled <<extend>> with an arrow toward

the base case. The extending use case may add behavior to the
base use case. The base class declares “extension points”.

<<extend>>
≪include≫: Functional Decomposition
• Problem:
• A function in the original problem statement is too complex to be
solvable immediately
• Solution:
• Describe the function as the aggregation of a set of simpler
functions. The associated use case is decomposed into smaller
use cases
CreateDocument

≪include≫
≪include≫
≪include≫

OCR (Optical
Scan Check
Character
Recognition )
≪include≫: Reuse of Existing Functionality
• Problem:
• There are already existing functions. How can we reuse them?
• Solution:
• The include association from Use Case A to Use Case B indicates
that an instance of A performs all the behavior described in B (“A
delegates to B”)
• Example:
• The use case “ViewMap” describes behavior that can be used by
the use case “OpenIncident” (“ViewMap” is factored out)
• Note: The base use case cannot exist alone. It is always called with
the supplier use case

≪include≫

OpenIncident
ViewMap
Base Use ≪include≫
Case Supplier
AllocateResources Use Case
When to Use Include Relationship?

• Use include when you are repeating yourself in

two or more separate use cases and you want to

avoid repetition.

• A use case is very complex and long, and

separating it into subunits aids comprehension.

≪extend≫ Association for Use Cases
• Problem:
• The functionality in the original problem statement needs to be
extended.
• Solution:
• An extend association from Use Case B to Use Case A indicates
that B is an extension of A.
• Example:
• The use case “ReportEmergency” is complete by itself , but can be
extended by the use case “Help” for a specific scenario in which
the user requires help
• Note: In an extend association, the base use case can be executed
without the use case extension
Base Use
Case B
Help
FieldOfficer
A ≪extend≫

ReportEmergency
≪ extend≫ Association for Use Cases
• The idea is to create an extending or addition use

case, and within it, describe where and under

what condition it extends the behavior of some
base use case.
Generalization Association in Use Cases
• Problem
• You have common behavior among use cases and want to factor
this out.
• Solution
• The generalization association among use cases factors out
common behavior. The child use cases inherit the behavior and
meaning of the parent use case and add or override some
behavior.
• Example
• Consider the use case “ValidateUser”, responsible for verifying the
identity of the user. The customer might require two realizations:
“CheckPassword” and “CheckFingerprint”

CheckPassword

Parent ValidateUser
Child
Case
CheckFingerprint Use Case
 40

Use-Case Experts advise to Keep Things Simple

and Prefer the include Relationship
NextGen POS

Process Sale

Cashier
«include» «include» «actor»
Accounting
«include» System

Handle Check Handle Cash Handle Credit

Payment Payment Payment
Customer «actor»
«include» Credit
«include» «include» Authorization
Service
UML notation:
the base use
Process Rental
case points to
the included use
case

Handle Returns

Manage Users

...
Other Requirements
• Important to know that use cases are not suitable
for all requirements
• Because, not all requirements are determined by
user-system dialogue
• Supplementary Specification (SS) captures non-
functional requirements (URPS+)
• Glossary, Vision, Business Rule docs can also
contain requirements
 42

4. Define Use Cases that Satisfy User Goals

(ii. Writing Use Case Text)
• Use Case Formats
• Brief, Casual, and Fully Dressed

• Brief Format
 43

4. Define Use Cases that Satisfy User Goals

(ii. Writing Use Case Text)
• Causal Format
 44

4. Define Use Cases that Satisfy User Goals

(ii. Writing Use Case Text)Fully Dressed Format
Use Case Sections Comments
Use case name Start with a verb
Scope The system under design
Level “User goal” or “Sub function”
Primary Actor Calls on system to deliver its services
Stakeholders and interests Who cares about the system and what do
they want
Preconditions What must be true on start
Success Guarantee What must be true on successful completion

Main Success Scenario Unconditional happy path scenario of

success
Extensions Alternate scenario of success or failure
Special Requirements Related NFRs
Technology and Data variation list Varying I/O methods
Frequency of occurrence Influences investigation, testing
Miscellaneous Open issues
 45

Process Sale Use Case from The NextGen POS

System
• Main Success Scenario
1. User selects new sale option
2. System requests item identifier
3. User enters item identifier
4. System records sale of item, and
5. System displays item description, price, current total
Steps 2-5 repeated until user finished
6. User selects sale finished option
7. System displays total and taxes due
8. User selects payment option
9. System requests payment information
10. User enters payment information
11. System handles payment
12. System logs completed sale and sends sale information to Accounting
System and Inventory System
13. System generates receipt
Case Study (A Library Information System)

Library Information System (LIS) for the benefit of students and

employees of the institute. LIS will enable the members to
borrow a book (or return it) with ease while sitting at his
desk/chamber. The system also enables a member to extend
the date of his borrowing if no other booking for that particular
book has been made. For the library staff, this system aids them
to easily handle day-to-day book transactions. The librarian,
who has administrative privileges and complete control over the
system, can enter a new record into the system when a new
book has been purchased, or remove a record in case any book
is taken off the shelf. Any non-member is free to use this
system to browse/search books online. However, issuing or
returning books is restricted to valid users (members) of LIS
only.
List of actors
Actor Description

Can avail LIS facilities; could be

Member
student, professor, researcher

Non-member Need to register to avail LIS facilities

Update inventory and other

Librarian
administrative tasks

Handle day-to-day activities with the

Library staff
LIS
Table 2: List of use cases
# Use Case Description

Allows to register with the LIS and create an

UC1 Register
account for all transactions

LIS authenticates a member to let him avail

UC2 User login
the facilities

UC3 Search book A member can search for a book

Allows a member to issue a specified book

UC4 Issue book
against his account

To return a book, which has been issued

UC5 Return book
earlier by a member

UC6 Reissue book To reissue a book

UC7 User logout User logs out from the system
Partial Use-case diagram
Home Assignment
Draw complete use-case diagram for
the given case study and also write
major use cases in fully dressed
format.