Object Oriented software

Engineering
(CoSc3092)

Sem. II – 2020
Department of Computer Science
 Introduction
software engineering

The
Theterm
term software
softwareengineering
engineeringwas was coined
coinedin in1968
1968asasaa
response
response to to the
the desolate
desolate state
state of
of the
the art
art of
of developing
developing
quality
quality software
softwareon on time
timeand andwithin
withinbudget.
budget.
Software
Software developers
developers were were not
not able
able to
to set
set concrete
concrete
objectives,
objectives, predict
predict the the resources
resources necessary
necessary to to attain
attain
those
those objectives,
objectives, and and manage
manage the the customers’
customers’
expectations.
expectations...
More
More often
often than
than not,
not, the
the moon
moon waswas promised,
promised, aa lunar
lunar
rover
roverbuilt,and
built,andaapair
pair ofofsquare
squarewheels
wheelsdelivered.
delivered.
The
The emphasis
emphasis in in software
software engineering
engineering isis on on both
both
words,
words, software
softwareandandengineering.
engineering.
 Introduction
Software engineering

An
Anengineer
engineerisisable
abletotobuild
buildaahigh-quality
high-qualityproduct
productusing
using
off-the-shelf
off-the-shelf components
components and and integrating
integrating them
them under
under
time
timeand
and budget
budget constraints.
constraints.
The
The engineer
engineer isis often
often faced
faced with
with ill-defined
ill-defined problems,
problems,
partial
partial solutions,
solutions, and
and has
has to
to rely
rely on
on empirical
empirical methods
methods to
to
evaluate
evaluatesolutions.
solutions.
Useful
Usefulsoftware
softwaresystems
systemsare arecomplex
complexand andchange.
change.
 Introduction
what is software engineering? SW eng. is
aa modeling
modeling activity:
activity: deal
deal with
with complexity
complexity through
through
modeling,
modeling, by by focusing
focusing at at any
any one
one time
time onon only
only the
the
relevant
relevantdetails
detailsand
andignoring
ignoringeverything
everythingelse.
else...
aa problem-solving
problem-solving activity:
activity: Models
Models are are used
used to to
search
search forfor an
an acceptable
acceptable solution.
solution. This
This search
search isis
driven
drivenby byexperimentation
experimentation
aa knowledge
knowledge acquisition
acquisition activity:
activity: In
In modeling
modeling the the
application
application and
and solution
solution domain
domain ,, software
software engineers
engineers
collect
collect data,
data, organize
organize itit into
into information,
information, andand formalize
formalize
ititinto
intoknowledge.
knowledge.
aa rationale-driven
rationale-driven activity:
activity: WhenWhen acquiring
acquiring
knowledge
knowledge and and making
making decisions
decisions about
about thethe system
system or or
its
its application
application domain,
domain, software
software engineers
engineers alsoalso need
need
toto capture
capture the
the context
context in in which
which decisions
decisions werewere made
made
 Introduction
System Development (SD)
SD
SD refers
refers toto all
all activities
activities that
that go
go into
into producing
producing an an
information
information systems
systems solution.
solution. These
These activities
activities consist
consist ofof
systems
systems analysis,
analysis, modeling,
modeling, design,
design, implementation,
implementation,
testing
testingandandmaintenance.
maintenance.
AA software
software development
development methodology
methodology isis aa seriesseries of of
processes
processes thatthat ifif followed
followed can
can lead
lead to
to the
the development
development of of
an
anapplication.
application.
There
There areare two
two orthogonal
orthogonal views views of
of the
the software
software differs
differs in
in
their
their primary
primaryfocus.
focus.
 1.
 1. The
Thetraditional
traditionalapproach
approachfocuses
focuseson onthe
thefunctions
functionsof ofthe
the
system
system andandsays
sayssoftware
softwareas asaacollection
collectionof ofprograms
programs(or (or
functions)
functions)and andisolated
isolateddata.data.
2.
2.Object
Objectoriented
orientedsystems
systemsdevelopment
development centers
centerson onthethe
object,
object, which
whichcombines
combinesdata dataand
andfunctionality
functionalityi.e.,
i.e.,
 Introduction
Object Oriented System Development Methodology

isis aa way
way to
to develop
develop software
software byby building
building self
self –– contained
contained
modules
modules or or objects
objects that
that can
can be
be easily
easily replaced,
replaced, modified
modified
and
andreused.
reused.
InIn an an object–oriented
object–oriented environment,
environment, software
software isis aa
collection
collection ofof discrete
discrete objects
objects that
that encapsulate
encapsulate their their data
data
asas well
well as
as the
the functionality
functionality of
of model
model real–world
real–world events
events
“objects”.
“objects”.
 Introduction
Why Object Oriented?
An
An object
object orientation
orientation produces
produces systems
systems thatthat are
are easier
easier toto
evolve,
evolve, more
more flexible,
flexible, more
more robust,
robust, and
and more
more reusable
reusable than
than aa
top
top––down
downapproach,
approach,
Allows
Allows higher
higher levellevel of of abstraction:
abstraction: SinceSince objects
objects
encapsulate
encapsulate bothboth data
data (attributes)
(attributes) && functions
functions (methods),
(methods),
they
theywork
workatataahigher
higherlevel
levelofof abstraction.
abstraction.
Provides
Provides Seamless
Seamless transition
transition among
among different
different phases
phases of of
software
software development:
development: uses uses the
the same
same language
language toto talk
talk
about
aboutanalysis,
analysis, design,
design,programming
programmingand anddatabase
database design.
design.
Encourage
Encourage good good development
development techniques:
techniques: the the classes
classes
will
will be
be grouped
grouped intointo subsystems
subsystems but but remain
remain independently
independently
and
and therefore,
therefore, changing
changing one one class
class has
has nono impact
impact on
on other
other
classes
classesand
andso,so, the
theimpact
impactisisminimized.
minimized.
Promotes of reusability: Objects are reusable because
 An Overview of UML
What is modeling?

Modeling
Modelingconsists
consistsofofbuilding
buildingan
anabstraction
abstractionofofreality.
reality.
Abstractions
Abstractionsare aresimplifications
simplificationsbecause:
because:
They
They ignore
ignore irrelevant
irrelevantdetails
detailsand
and
They
They only
onlyrepresent
representthe therelevant
relevantdetails.
details.
What
What isis relevant
relevant oror irrelevant
irrelevant depends
depends on
on the
the purpose
purpose
of
of the
themodel.
model.
 An Overview of UML
Why model software?

Software
Softwareisisgetting
gettingincreasingly
increasinglymore
morecomplex
complex

Windows
WindowsXP XP>> 40
40mio
miolines
linesof
of code
code

AAsingle
singleprogrammer
programmer cannot
cannotmanage
managethisthisamount
amount
of
of code
codeinin its
itsentirety.
entirety.
Code
Code isis not
not easily
easily understandable
understandable by by developers
developers who
who
did
didnot
notwrite
writeitit
We
Weneed
needsimpler
simpler representations
representationsforfor complex
complexsystems
systems

Modeling
Modelingisisaamean
meanforfordealing
dealingwith
withcomplexity
complexity
 An Overview of UML
Why model software?

Once
Once models
models of of aa system
system havehave been
been constructed,
constructed,
these
these can
can bebe used
used for
for aa variety
variety of
of purposes
purposes during
during
software
softwaredevelopment,
development, including
including ::
••Analysis
Analysis ••Specification
Specification ••Code
Codegeneration
generation ••Design
Design ••
Visualize
Visualizeand
and understand
understand the the problem
problemandandthe
theworking
working
of
of aasystem
system ••Testing,
Testing, etc.
etc.
The
The UML
UML models
models cancan not
not only
only be
be used
used to
to document
document
the
theresults
resultsbut
but also
alsototoarrive
arriveat
at the
theresults
resultsthemselves
themselves
 An Overview of UML
What is UML?
UML (Unified Modeling Language)
An emerging standard for modeling object-oriented software.
Resulted from the convergence of notations from three leading
object-oriented methods:
OMT (Object Management Technology James Rumbaugh)
OOSE (Ivar Jacobson)
Booch (Grady Booch)

It has successfully been used to model both large

and small problems
Supported by several CASE tools
Rational ROSE
Microsoft viso
TogetherJ
 Building Blocks of the UML

UML
UML maymay be be used
used to
to visualize,
visualize, specify,
specify, construct,
construct, and
and
document
documentthe theartifacts
artifactsofofaasoftware
softwaresystem
system
ItIt provides
provides aa set set of
of notations
notations (e.g.
(e.g. rectangles,
rectangles, lines,
lines,
ellipses,
ellipses,etc.)
etc.)to
tocreate
createaavisual
visualmodel
modelof ofthe
thesystem
system
Like
Like any
any other
other language,
language, UMLUML has has its
its own
own syntax
syntax
(symbols
(symbols andand sentence
sentence formation
formation rules)
rules) and
and semantics
semantics
(meanings
(meaningsof ofsymbols
symbolsand andsentences)
sentences)
UML
UML isis not not aa system
system design
design or or development
development
methodology,
methodology, but but can
can bebe used
used toto document
document object-
object-
oriented
oriented andand analysis
analysis results
results obtained
obtained usingusing some
some
methodology..
methodology
 Building Blocks of the UML
UML Core Conventions
Rectangles are classes or instances
Ovals are functions or use cases
Instances are denoted with an underlined names
myWatch:SimpleWatch
Joe:Firefighter

Types are denoted with non underlined names

SimpleWatch
Firefighter

Diagrams are graphs

Nodes are entities
Arcs are relationships between entities
 Diagrams in the UML

UML
UML can
canbebeused
usedtoto construct
constructnine
nine different
differenttypes
typesofofdiagrams
diagramsto to
capture
capturefive
fivedifferent
differentviews
viewsofofaasystem
system
The
The UML
UML diagrams
diagrams can can capture
capture the
the following
following five
five views
views of
of aa
system:
system:
User’s
User’sview
view
Structural
Structuralview
view
Behavioral
Behavioralviewview
Implementation
Implementationview view
Environmental
Environmentalview view
 Diagrams in the UML
Use case Diagrams
Describe the functional behavior of the system as seen by the user.
Class diagrams
Describe the static structure of the system: Objects, Attributes,
Associations
Sequence diagrams
Describe the dynamic behavior between actors and the system and
between objects of the system
Statechart diagrams
Describe the dynamic behavior of an individual object (essentially
a finite state automaton)
Activity Diagrams
Model the dynamic behavior of a system, in particular the
workflow (essentially a flowchart)
Implementation diagrams
Component diagrams
Deployment diagrams
 Use Case Diagrams
Use
Use cases
cases are are used
used during
during requirements
requirements
elicitation
elicitation and
and analysis
analysis to to represent
represent the
the
functionality
functionality of
of the
the system
system
use
use cases
cases represent
represent thethe different
different ways
ways in
in which
which aa
system
system cancan be
be used
used by
by the
the users
users
AA simple
simple way
way to to find
find all
all the
the use
use cases
cases of
of aa
system
system is is to
to ask
ask the the question:
question: “What
“What the
the
users
users can
can do
do using
using the the system?”
system?”
It represent
It represent the
the functionality
functionality of of the
the system
system
from
from aa user’s
user’s point
point of of view.
view. They
They define
define the
the
boundaries
boundaries of of the
the system
system
 Use Case Diagrams

Used during requirements

elicitation to represent external
behavior

Actors represent roles, that is, a

Passenger type of user of the system
Use cases represent a sequence
of interaction for a type of
functionality
The use case model is the set of
PurchaseTicket all use cases. It is a complete
description of the functionality
of the system and its
environment
 Use Case diagrams/Actors

An actor models an external entity

which communicates with the system:
User
External system
Physical environment
Passenger
An actor has a unique name and an
optional description.
Examples:
Passenger: A person in the train
GPS satellite: Provides the system with
GPS coordinates
 Use case Diagrams/ Use Case
A use case represents a class of functionality provided
by the system as an event flow.
A use case consists of six fields:
• Unique name:
PurchaseTicket
The name of the use case is unique across the system so that
developers (and project participants) can unambiguously refer to the use case

• Participating actors: are actors interacting with the use case.

• Entry conditions: describe the conditions that need to be satisfied before the
use case is initiated.
• Flow of events: describes the sequence of actions of the use case, which are
be numbered for reference
• Exit conditions: describe the conditions that are satisfied after the
completion of the use case
• Special requirements: are requirements that are not related to the
functionality of the system
 Use Case Diagram: Example
Name: Purchase ticket
Participating actor: Passenger
Entry condition:
• Passenger standing in front of
ticket distributor.
• Passenger has sufficient
money to purchase ticket.
Exit condition:
• Passenger has ticket.
Event flow:
1. Passenger selects the number
of zones to be traveled.
2. Distributor displays the amount
due.
3. Passenger inserts money, of at
least the amount due.
4. Distributor returns change.
5. Distributor issues ticket.
Anything missing?
Exceptional cases!
 Use Case Diagrams: relationship
Use case diagrams can include four types of relationships:
Communication : Actors and use cases communicate when information is
exchanged between them. Communication relationships are depicted by a solid line
between the actor and use case symbol
 Inclusion :We reduce the complexity of the model by identifying commonalities in
different use cases.
 Extension : A use case can extend another use case by adding events , it allows
you to show optional system behavior
Generalization: are a third mechanism for reducing the complexity of a
model. A use case can specialize a more general one by adding more detail.
 The <<extends>> Relationship
<<extends>> relationships
represent exceptional or seldom
invoked cases.
Passenger The exceptional event flows are
factored out of the main event
flow for clarity.
Use cases representing
PurchaseTicket exceptional flows can extend
more than one use case.
<<extends>> The direction of a <<extends>>
relationship is to the extended
<<extends>> use case
<<extends>>

OutOfOrder <<extends>> TimeOut

Cancel NoChange
 The <<includes>> Relationship

<<includes>> relationship
represents behavior that is
Passenger factored out of the use case.
identifying commonalities in
different use cases
PurchaseMultiCard
<<includes>> behavior is
PurchaseSingleTicket factored out for reuse, not
<<includes>> because it is an exception.
<<includes>> The direction of a
<<includes>> relationship is to
the using use case (unlike
CollectMoney <<extends>> relationships).
<<extends>> <<extends>>

NoChange Cancel
 Use Case Diagrams: Summary
Use case diagrams represent external behavior
Use case diagrams are useful as an index into the use cases
Use case descriptions provide meat of model, not the use
case diagrams.
All use cases need to be described for the model to be
useful.
 Class Diagrams
Class diagrams describe the structure of the
system in terms of classes and objects
A class is a definition of objects that share the
same properties, relationships and behavior.
An object is an instance of a class.
The properties of a class are called
attributes and the behavior is expressed
in operations.
 Class Diagrams
Classes are the most important building block of any
object-oriented system ClassName
attributes
operations
Classes are used to: -
 capture the vocabulary of the system you are developing
 represent software things, hardware things, and even things that
are purely conceptual
Well-structured classes have crisp/distinct
boundaries and form a part of a balanced
distribution of responsibilities across the system
 Class Diagrams
TarifSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)

TarifSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations TarifSchedule

A class represent a concept

A class encapsulates state (attributes) and behavior (operations).
Each attribute has a type.
Each operation has a signature.
The class name is the only mandatory information.
 Class Diagrams/Instance

tarif_1974:TarifSchedule
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}

An instance represents a phenomenon.

The name of an instance is underlined and can contain the class of the
instance.
The attributes are represented with their values.
 Class Diagrams/ Relationships
Association
Association
Associations are needed to enable objects to communicate with each
other .
An association describes a connection between classes.
The association relation between two objects is called object connection
or link .
Association between two classes is represented by drawing a straight
line between the concerned classes.
The name of the association is written alongside the association line.
An arrowhead may be placed on the association line to indicate the
reading direction of the association.
 Class Diagrams/ Relationships
Association/
Association/ multiplicity
multiplicity
On each side of the association relation, the multiplicity is noted as an
individual number or as a value range.
The multiplicity indicates how many instances of one class are
associated with each other.
Value ranges of multiplicity are noted by specifying the minimum and
maximum value, separated by two dots.
 Class Diagrams/ Relationships
Association/
Association/ multiplicity
multiplicity
1-to-1 and 1-to-many Associations

Country Has-capital City

name:String name:String

One-to-one association

Point
Polygon
* x: Integer

y: Integer
draw()

One-to-many association
 Class Diagrams/ Relationships
Association/
Association/ multiplicity
multiplicity
Many-to-Many Associations

Lists

StockExchange * * Company

tickerSymbol
 Class Diagrams/ Relationships
Generalization

A generalization is a relationship
between a general thing (superclass
or parent) and a more specific kind of
that thing (subclass or child)
Generalization means that objects of
the child may be used anywhere the
parent may appear, but not the reverse
the child is substitutable for the parent

33
 Class Diagrams/ Relationships
Cont…
Graphically, a generalization is rendered as a
solid directed line with a large open arrowhead,
pointing to the parent

ParentClass

ChildClass
attributes
operations
34
 Class Diagrams/ Relationships
Example: - The Rectangle, Circle and Polygon
classes inherits the attributes and operations of
the Shape class
Shape
origin
move()
resize()
display()

Rectangle Circle Polygon

corner : Point radius : Float

points : List
duplicate()
3
5
 Class Diagrams/ Relationships
Aggregation
is a “whole-part” relationship within which one or
more smaller class are “part” of a larger “whole”
represents a “has-a” relationship, whereby an
object of the whole class has objects of the part

Company
whole 1
aggregation

part *
Department
36
 A simple example
On-line Bookstore Review
a web application that can be accessed by the store’s
registered customer, whereby each customer can review
one or more books sold in the book store
The process given: -
Each registered CUSTOMER has an ACCOUNT that is used to
verify his/her ID and password
Each PASSWORD entered must be more than 8 characters and
consists of a combination of text and numbers
Each registered CUSTOMER, upon ACCOUNT verification, can
REVIEW one or more BOOKs based on its title
A REVIEW can either be a customer’s review and editor’s review

3
7
 Things that are found in the problem: -
 Account
 Password
 Customer
 Book
 Review
 can be divided into CustomerReview and
EditorialReview

3
8
 Cont…
Each of these things can form individual
classes with responsibilities (attributes and operation)
 Account
 Used to keep the customer’s ID and password
for verifying that the customer is a registered
customer
 Also keeps additional information, i.e. e-mail
address
 The password is of the type PASSWORD

3
9
  Password
 Used to check that the password entered is valid (more
than 8 characters and consists of combination of text and
numbers)
 Customer
 Used to keep information about the customer, such as
customer’s name, ID, address etc
 Book
 Used to keep the relevant information on the book that is
crucial to customer’s review, i.e. book title, author, rating

4
0
 Cont…

 Review
 Divided into sub-classes: CustomerReview and
EditorialReview
 CustomerReview
Used to assign ratings to book reviewed (with 1
being the lowest and 5 the highest) by customer
Used to compute the average rating for each book
that has been reviewed by customer
 EditorialReview
Used to store editor’s review
4
1
 Translate the responsibilities for each class into attributes and
operations needed to perform those responsibilities (relevant to the
given problem)
 Account
 Attributes:emailAddress(string),
ID(string), passwd(Password)
 Operations: verifyPassword(p: Password)
 Password
 Attributes:passwd(string)
 Operations: checkPassword()
 Customer
 Attributes:CustName, CustAddress, CustID etc
 Operations: NONE
Can choose not to show the attributes when modeling the class
as they are not relevant to the given problem (put NONE for
both)
 Book
 Attributes:title, author, rating
4  Operations : NONE
2
  Review
 Attributes: NONE
 Operations: NONE

 CustomerReview
 Attributes: NONE

 Operations: assignRatings(rating : Int),

computeAvgRating() : double
 EditorialReview
 Attributes: NONE

 Operations: NONE

4
3
 The relationship between classes: -
 Dependency
 The operation verifyPassword in Account class
has as parameter a Password class
 Therefore, Account depends on Password
 Generalization
 Review can be divided into customer’s review
and editor’s review
 Therefore, CustomerReview and
EditorialReview is the subclass of Review

4
4
  Association
A customer can open 1 account and an
account can be opened by 1 customer
 A customer writes a review and a review
can be written by a customer
 1 customer can write 1 or many reviews,
but 1 review can only come form 1 customer
 A book can have many reviews but a review
is for one book

4
5
 Modelling the classes and relationships: - EditorialReview
Book
title : String has
Review
1 *

writes is written by CustomerReview

Customer
1 1..*
1
opens assignRating(rating : Int)
computeAvgRating() : Double
1
Account
emailAddress : string
ID : string Password
passwd : Password
pass : String
verifyPassword(p :
checkPassword()
4 Password)
6
 Summary

basic, simple dependencies,

generalizations and associations with
names, multiplicities and roles are the
most common features needed in
creating abstractions (classes)
 For most of the models that we will build,
the basic form of these three relationships
will be all that is needed to convey the most
important semantics of a relationship

4
7
 Sequence Diagrams

In every system, objects do not just sit idle;

they interact with one another by passing
messages.
In the UML, the dynamic aspects of a system
is modelled using interactions
An interaction sets the stage for its behaviour by
introducing
all the objects that work together to carry out some
action,
the messages that are dispatched from object to object
 Sequence Diagrams
A sequence diagram is an interaction diagram
that emphasizes the time ordering of messages
A sequence diagram is formed by: -
 Placing the objects that participate in the interaction at
the top of the diagram, along the X-axis
 The object that initiates the interaction is placed on the left
most, and the other subordinate objects are placed to the right
Placing the messages that these objects send and receive
along the Y-axis, in order of increasing time from top to
bottom
 Sequence Diagrams

A sequence diagram has four key elements:

Object, Lifeline, Focus of Control and
Message
Objects appear along the top margin
Each object has a lifeline, which is a
dashed line that represent the life
and perhaps death of the object
Most objects will be in existence for the
duration of the interaction
Objects may also be created or destroyed
 Sequence Diagrams

A focus of control, which is a tall thin

rectangle that sits on top of an object’s
lifeline
 Itshows the period of time during which an
object is performing an action, either directly or
through subordinate procedure
 The bottom part of a focus of control can be
marked by a return message
 Messages show the actions that objects
perform on each other and on themselves
 Sequence Diagrams
Example: - Modelling a sequence diagram for the log-in
use case from the on-line Bookstore Case Study.
The main-flow of events that are involved is: -

1. The CUSTOMER clicks the Log-in button on the Home

Page.
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and password.
The CUSTOMER clicks the OK button.
4. The system validates the log-in information against the
ACCOUNT table in the database.
5. CUSTOMER is an authorised user; the system displays
the Personal Home Page to the CUSTOMER
 Sequence Diagrams

Actors: Customer
Messages and Objects
1. The CUSTOMER clicks the Log-in button on the
Home Page.
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and
password. The CUSTOMER clicks the OK button.
5. The system validates the log-in information against the
ACCOUNT table in the database.
6. CUSTOMER is an authorised user; the system displays
the Personal Home Page to the CUSTOMER
 :Customer :HomePage :LoginPage :Account
The Customer clicks
the Login button on clickLogin( )
the Home Page

The system displays

display( )
the Login Page

The Customer enters

his or her user ID
and password, and enter userID and password
then clicks the OK
button. clickOK( )
validateLogin(userID
The system validates , password)
the login information
against the persistent login OK
Account data
display( PersonalPage)
The system then
returns the Customer
to the Home Page.

54 Login Sequence Diagram

 Robustness Analysis
Sometimes when drawing an interaction
diagram, we may be confused about the
objects that are involved.
Because each object that we use in an
interaction diagram MUST have its
corresponding classes in the class diagram, we
may find ourselves in a situation where we
have already determined the objects that are
needed in an interaction diagram but the
objects do not have their corresponding
classes in our class diagram.
55
Robustness analysis involves analysing the text of
a use case and identifying a first-guess set of
objects that will participate in the use case, and
then classifying these objects based on their
characteristics.
 It involves defining analysis classes

There are 3 types of analysis classes:

 boundary classes
 entity classes
 control classes
Instances of each of these analysis classes are called
objects.

56
Boundary Objects
is an object with which an actor
associated with a use case interacts. (More
of Interfacing)
if the actor is human, the boundary object
may be a window, screen, dialog box, or menu
if the actor is non-human, the boundary
object may be application program interfaces
(APIs)
boundary object

57
Entity Objects
is an object that contains long-lived
information, such as that associated with
databases.
will be mapped to a table (part of the
database) in the design phase
It can also contain temporary objects, i.e.
contents of lists in windows, or search
results. entity object

58
Control Objects
 is an object that embodies application logic
 correspond with system actions (not actions taken by
actors)
 are often used to handle things such as coordination and
sequencing
 are also useful for calculations involving multiple entity
objects
 will be mapped to codes during implementation phase
 used as a connecting tissue between boundary objects
and entity objects.

control object
59
Using the previous example (the log-in
use case of the Online Bookstore), we
can identify that
the HomePage and Log-in Page objects
are boundary objects,
whereas the Account object is an entity
object.
Therefore, taking this into account, we
can draw a new interaction diagram.

60
 :Customer :HomePage :LoginPage :Account

The Customer clicks clickLogin( )

the Login button on
the Home Page display( )
The system displays
the Login Page

The Customer enters

enter userID
his or her user ID and password
and password, and
then clicks the OK clickOK( )
button. validateLogin(userID
, password)
The system validates
the login information login OK
against the persistent
Account data
display( )

The system then

returns the Customer
to the Home Page.

61 Login Sequence Diagram

 Summary
No single interaction diagram can capture
everything about a system’s dynamic aspect
may need to use many interaction
diagrams to model the dynamic aspects of a
system as a whole, as well as its subsystem,
operations, classes, use cases and
collaborations.

62
On-line Bookstore is a web application that can be
accessed by the store’s registered customer,
whereby each customer can order books, review
one or more books sold in the book store, and sell
used books to other customers. Before performing
any one of these transactions, the customer must
first log-in into the system using their user id and
password kept in their account.
Problem: Draw the sequence diagram for the
above system

63
From previous discussions, we know that the
functional requirements for the Online
Bookstore can be seen from the use case
diagram (as shown in the next slide)
Each of the use cases in the use case diagram
must have its corresponding interaction diagram
We will use the scenarios in the ‘Main flow of
events’ for each use case to model the interaction
diagram

64
 On-line Bookstore System

Register

<<extend>>
(CustID) Check out

Order books
<<include>>

Customer
<<include>>
Sell used Log-in
books

<<include>>

Review books

65 Use Case Functional Requirements Diagram

 Log-in

:Customer :HomePage :LoginPage :Account

The Customer clicks clickLogin( )

the Login button on
the Home Page display( )
The system displays
the Login Page

The Customer enters

enter userID
his or her user ID and password
and password, and
then clicks the OK clickOK( )
button. validateLogin(userID
The system validates , password)
the login information
against the persistent login OK
Account data …
display( )
… and then returns the
Customer to the Home
Page.
66
Use Case: Register
 Main flow of events:

1. The CUSTOMER clicks the REGISTER button on the Home Page.

2. The system displays the Register Page.
3. The CUSTOMER enters all of the required information.
4. The CUSTOMER clicks the SEND button.
5. The system checks that all of the required information were entered. If
yes, the system update the CUSTOMER’s record in the CUSTOMER
and ACCOUNT tables in the database. System displays OK message.
 Objects:-
 CUSTOMER: actor
 CUSTOMER and ACCOUNT: entity objects
 Home Page and Register Page: boundary objects

67
 Register

:Customer :HomePage :RegisterPage

The customer clicks
the REGISTER button clickRegister( )
on the Home Page
The system displays
the Register Page display( )

The Customer enters

the required
information and enter information
then clicks the
SEND button.
clickSEND( ) verify info
The system checks
that all of the required
information were
entered. If yes, the <<create>>
system updates the :Account
CUSTOMER’s record
in the CUSTOMER <<create>>
and ACCOUNT tables display( ) :Customer
in the database. The
68
system displays OK
message
Case Study: Order Books
 Main Flow of events: -
1. The CUSTOMER enters the keyword for a book and clicks the
SEARCH button on the personal Home Page.
2. The system displays the matching books on the web Page.
3. The CUSTOMER chooses the desired book and clicks the ADD TO
SHOPPING CART button on the web page.
4. The system adds the book into the CUSTOMER’s Order table in the
database.
 Objects:
 Customer: actor
 Home Page: boundary object
 Book and Order: entity object

69
 Order
books

:Customer :HomePage :Book :Order

The CUSTOMER
enters the keyword for
a book and clicks the enters keyword
SEARCH button on the
personal Home Page
clickSearch( )
search( )
The system displays
the matching books on displayMatch( )
the web Page
The CUSTOMER
chooses the desired
book and clicks the
ADD TO choose books
SHOPPING CART
button on the web clickAdd()
page.
<<create>>)
The system adds the
book into the
CUSTOMER’s Order
addBook( )
table in the database.
70
Use Case: Check-out
Main flow of events
1. The CUSTOMER clicks the Check out button on the Home Page
2. The system displays the books in the ORDER table of the
CUSTOMER on the web Page.
3. The CUSTOMER checks the order list for any inconsistency. If
nothing was found, CUSTOMER clicks the PROCEED button.
4. The system displays the Invoice page.
5. The Customer enters the relevant credit card information and clicks OK.
6. The system checks that the credit card is valid. Then, the system displays
the Delivery Details page.
7. The CUSTOMER chooses destination for delivery, along with delivery
options. Then, he/she clicks the PROCEED button.
8. The system will display the check-out information for confirmation.
7. The CUSTOMER checks that all information is correct and then clicks the
OK button.
8. The system sends a confirmation via CUSTOMER’s e-mail.
Objects: -
Home Page, Invoice Page and Delivery Page: boundary objects
Customer and Order: entity objects
71
:Customer :HomePage :Order :InvoicePage :Customer :DeliveryPage
clickCheckOut( )
retrieve()
display( )

verify info
clickProceed( )
display( )

enter credit card info

clickOK()
validate( )

display( )

choose destination
clickOK()
display()
confirm and clickOK ()
Use case: Sell used books
Main flow of events: -
1. The CUSTOMER clicks the Sell Used Books button on the Home
Page.
2. The system displays the sell used books web page.
3. The CUSTOMER enters the required information on the used
books that he/she wants to sell.
4. The CUSTOMER clicks the SEND button on the webpage.
5. The system displays a confirmation page listing the information
that the CUSTOMER has entered.
6. The CUSTOMER checks that the information displayed are
accurate. If yes, the CUSTOMER clicks the OK button on the web
page.
7. The system updates the USED BOOKS table in the database.
Objects:
HomePage, UsedBooksPage and ConfirmationPage: boundary objects
Customer and Used Books: entity objects

73
:Customer :HomePage :UsedBooksPage :ConfPage :Customer :UsedBook

clickUsedBooks( )

display( )

enter book info

clickSend( )
display( )

verify info
clickOK( )
add( )

add( )
74
Use case: Review
 Main flow of events: -
1. The CUSTOMER enters the keyword to search for a book and
then clicks the SEARCH button on the Personal Web Page.
2. The system displays the matching books on the web Page.
3. The CUSTOMER checks for the desired book and clicks on the
chosen book icon.
4. The system displays the book’s detail in the Book Detail web page.
5. The CUSTOMER clicks the REVIEW button on the web page.
6. The system displays the Review Book web page.
7. The CUSTOMER clicks on the desired star button and the click
the OK button on the web page.
8. The system calculates the overall rating of the book and updates
the Book table in the database.
9. The system displays the Book Detail web pages that have been
updated.
 Objects?
 Diagram?

75
 State chart Diagrams
A state chart diagram is normally used to model
how the state of an object changes in its lifetime
State chart diagrams are good at describing how
the behavior of an object changes across several
use case executions
A state chart is a hierarchical model of a system
and introduces the concept of a composite state
(also called nested state).
The basic elements of the state chart diagram
are as follows:
Initial state- This is represented as a filled circle.
Final state- This is represented by a filled circle inside a larger circle
State- These are represented by rectangles with rounded corners.
 Transition- A transition is shown as an arrow between two states.
 State chart Diagrams
An example state chart for the order object of the Trade House Automation
software
 Activity Diagrams

Activity diagrams describe the workflow behavior

of a system.
They are typically used for business process
modeling, for modeling the logic captured by a
single use case or usage scenario, or for modeling
the detailed logic of a business rule.
UML activity diagrams could potentially model the
internal logic of a complex operation.
In many ways UML activity diagrams are the
object-oriented equivalent of flow charts.
Activity Diagrams
 Cont…
The diagram on previous slide above
shows a fork after activity1. 
This indicates that both activity2 and
activity3 are occurring at the same time. 
After activity2 there is a branch.  The
branch describes what activities will take
place based on a set of conditions. 

8
0
 Example to illustrate the activity of performing selling an
item to a customer.

8
1
 Component Diagram
A component diagram describes the organization of the physical components
in a system.
Basic Component Diagram Symbols and Notations

Component
A component is a physical building block of
the system. It is represented as a rectangle
with tabs.

Interface
An interface describes a group of operations
used or created by components.

Dependencies
Draw dependencies among components
using dashed arrows.
 Component Diagram
Component Diagram For Library Management System

Component diagram is essentially class diagram that focus on a system’s component.

 Deployment Diagram
Deployment diagrams depict the physical resources in a system including
nodes, components, and connections.

Basic Deployment Diagram Symbols and Notations

Node
A node is a physical resource that
executes code components

Association
Association refers to a physical connection
between nodes, such as
Ethernet.

Components and Nodes

Place components inside the node that
deploys them.
 Deployment Diagram
Deployment Diagram For Library Management System

The deployment diagram captures the configuration of the run time

element of the application
 UML Summary

UML provides a wide variety of notations for

representing many aspects of software development
Powerful, but complex language
Can be misused to generate unreadable models
Can be misunderstood when using too many exotic features

For now we concentrate on a few notations:

Functional model: Use case diagram
Object model: class diagram
Dynamic model: sequence diagrams, statechart and activity
diagrams
Object-Oriented Software engineering

Requirement Elicitation
Collecting and organizing users requirement- WHAT-
User needs

87
Basic objectives of the chapter
Define requirement and related concepts?
Requirement Elicitation concepts
Requirement elicitation activities
Managing requirements elicitation

88

88
Requirement and related concepts
What is requirement?
◦ Definition
◦ Types
 Functional, non-functional, pseudo- requirement
Requirement engineering – includes
◦ Elicitation –system specification of the system
that the client understands,
◦ Analysis – system(structured analysis) models
that the developers can unambiguously
interpret
89

07/20/21 89
 What is a Requirement ?
It is a statement describing either
◦ 1) an aspect of what the proposed system must do,
◦ or 2) a constraint on the system’s development.
◦ In either case it must contribute in some way towards
adequately solving the customer’s problem;
◦ the set of requirements as a whole represents a
negotiated agreement among the stakeholders.
A collection of requirements is a requirements
document.

90

07/20/21 90
 An overview of requirements
elicitation
 Is about a communication b/n developers , clients and user
in defining a new system define a system that addresses
the problem.
 Such a definition is called a system specification and
serves as a contract between the client and the
developers
 The system specification is structured and formalized
during analysis to produce an analysis model.
 Both system specification and analysis model represent the
same information. They differ only in the language and
notation they use.

91

91
Cont..
System specification Vs Analysis model
◦ Represent same information
◦ Difference only on the language and notation
they use
 system specification – natural languages
 Analysis model is usually expressed in a formal or
semiformal notation
◦ Both- more of external aspect of the system
visible to users (users' view)
◦ They occur concurrently and iteratively
92

07/20/21 92
Requirements elicitation concepts
Types of Requirements
 Functional requirements
◦ Describe what the system should do
◦ the interactions between the system and its environment
independent of its implementation.
 Non-functional requirements
◦ describe user-visible aspects of the system that are not directly
related with the functional behavior of the system
◦ Quality requirements
 Constraints on the design to meet specified levels of quality
 Pseudo requirements
◦ requirements imposed by the client that restrict the
implementation of the system
◦ Platform requirements
 Constraints on the environment and technology of the system
◦ Process requirements
 Constraints on the project plan and development methods

93

07/20/21 93
Requirements elicitation concepts
Correctness, completeness, consistency, clarity, and
realism
 Requirements are continuously validated with the client and the
user
 Validation is a critical step in the development process, given that
both the client and the developer are dependent on the system
specification.
 Requirement validation involves checking if the specification is
correct, complete, consistent, unambiguous, and realistic.
 A specification is
◦ correct if it represents the client’s view of the system (i.e., everything in the
requirements model accurately represents an aspect of the system)
◦ complete if all possible scenarios through the system are described, including
exceptional behavior (i.e., all aspects of the system are represented in the
requirements model)
◦ consistent if it does not contradict itself
◦ unambiguous if exactly one system is defined (i.e., it is not possible to interpret
the specification two or more different ways).
◦ Realistic if the system can be implemented within constraints. The model
describes a reality that can exist.

94

07/20/21
 Requirements elicitation concepts
Verifiability and traceability
 The specification is verifiable if, once the system is built, a
repeatable test can be designed to demonstrate that the system
fulfills the requirement
 The following requirements are examples of non verifiable requirements:
◦ The product shall have a good user interface (good is not defined).
◦ The product shall be error free (requires large amount of resources to
establish).
◦ The product shall respond to the user with 1 second for most cases
(“most cases” is not defined).
 A system specification is traceable if each system
function can be traced to its corresponding set of
requirements
 Traceability facilitates the development of tests and the
systematic validation of the design against the
requirements
95

07/20/21
Object-Oriented Software
Enginnering

Object Oriented Analysis

Object Oriented Analysis
Motivation
Although our requirement elicitation
model are effective in understanding
what our users want to have built, it is
not effective in understanding what
will be built.
Needs formalization and structuring
 WHAT IS ANALYSIS?
Analysis focuses on producing a model of the system, called the
analysis model, which is correct, complete, consistent, and verifiable.
Analysis is different from requirements elicitation in that developers
focus on structuring and formalizing the requirements elicited from
users
Translating a system specification into a formal or semiformal model
forces developers to identify and resolve difficult issues early in the
development.
The analysis model is composed of three individual models: the
functional model , represented by use cases and scenarios, the
analysis object model , represented by class and object diagrams,
and the dynamic model, represented by statechart and sequence
diagrams

98
Object Oriented Analysis Concepts
The main difference is that
The requirement gathering phase tries to understand
what the user needs and their usage of the system.
The analysis phase will be used to understand the
system itself in addition to the user usage.
Analysis Concepts
entity, boundary, and control objects
association multiplicity
qualified associations
generalization
Analysis Summary Basic Tasks
The requirements activity is highly iterative
and incremental
Developing and validating
(System) Use case model
Sequence Diagram
Conceptual Class Model (analysis level)
State chart/Activity Diagram
UI prototyping
 Documenting Analysis
the requirements elicitation and analysis activities are
documented in the Requirements Analysis Document
(RAD).
We have already been written during requirements
elicitation. During analysis, we revise these sections as
ambiguities and new functionality is discovered.
Object Oriented Design
How to Construct?
 Introduction
The object oriented analysis part does not
do well on how the system should be build.
This gap is filled by the design phase that
provides such details for the
implementation.
There are various artifacts that would be
used to model the design of the system that
evolve from the analysis phase.

103
 Thus
Design is defined as
a meaningful engineering representation of something that is
to be built.
both “the process of defining the architecture, components,
interfaces, and other characteristics of a system or
component” and “the result of that process.”
As a process, software design is the software engineering
life cycle activity in which software requirements are
analyzed in order to produce a description of the
software’s internal structure that will serve as the basis
for its construction.

104
 Why is it important?

Would you try to build a house without a blueprint? You’d

risk confusion, errors, a floor plan that didn’t make sense,
windows and doors in the wrong place . . . a mess.
Computer software is considerably more complex than a
house; hence, we need a blueprint  the design.
It can be traced to a customer’s requirements and at the
same time assessed for quality against a set of predefined
criteria for “good” design.

105
 The software design process
Software design is
an iterative process through which requirements are translated
into a “blueprint” for constructing the software.
is generally considered a two-step process:
Architectural design  describes how software is decomposed
and organized into components (the software architecture)
Class type architecture, Component, Deployment, persistent
diagrams
Detailed design  describes the specific behavior of these
components.
Refined class model ,Statechart, collaboration

106
 Describing an architecture using UML
All UML diagrams can be useful to describe aspects
of the architectural model
Some UML diagrams are particularly suitable for
architecture modelling and for implementation issues:
Class Type architecture (not in UML)
Component diagrams
Deployment diagrams
Persistent diagram
Package/subsystem diagram

107
 Class Type Architecture (not in UML)
A common architectural strategy, some might call it a
pattern, is to layer the architecture of a system into
several layers/strata. 
Some strategies simply define N layers stacked on top
of each other where layer J interacts only with layers J-
1 and J+1. 
The various layers are represented by the rectangles
and collaboration between layers by the arrows. 
The primary name of a layer is indicated first, and
other common names in parenthesis.

108
 Layered class type architecture

109
 Class Modeling
The class model at the design level will add some
additional details than that of the analysis level
class model.
Here the focus will be the solution domain rather
than the problem domain.
In practice, the analysis level class model will
evolve into a design level class model.
There will be changes to be introduced to the
analysis class model based on implementation
technologies.
110
 Cont…
The design level class model will concentrate on
how to implement attributes methods, inheritance,
association, aggregation, composition and the
likes.
Modeling Methods
Methods, also called operations or member functions,
are the object-oriented equivalent of functions and
procedures.
The design level will model more information about
methods than the analysis.

111
 Cont…
The design level may include:
Visibility: the level of access that external
objects have to a method.
To reduce the effect of coupling within a system,
more restrictions on access of methods should be
set.
In other words, if a method does not have to be
public then make it protected and if it does not
have to be protected then make it private.

112
 Cont…
Visibility Symbol Description Proper Usage
Public + A public method can be When the method must be
invoked by any other accessible by objects and classes
method in any other object outside of the class hierarchy in
or class. which the method is defined.
Protected # A protected method can be When the method provides behavior
invoked by any method in needed internally within the class
the class in which it is hierarchy, but not externally.
defined or any subclasses
of that class.
Private - A private method can only When the method provides behavior
be invoked by other specific to the class. Private
methods in the class in methods are often the result of
which it is defined, but not refactoring.
in the subclasses.
113
 Cont…
Name: Descriptive name for the method. A good
name is the one that is capable of explaining the
purpose of the methods just by looking at its name.
In giving a name to methods the designer needs to know
what programming language will be used for the
development so that the naming convention of that language
will be used here.
Parameters: The names of parameters, and
optionally their types and default values (if any);
Return value type: The data type of the return value
(if available)
114
 Cont…
Modeling Attributes
Attributes are the data aspects of objects.
The design level will model more
information about methods than the
analysis.
The design level may include:
Visibility: This is the level of access
external objects have to an attribute.(public ,
protected or privitae)
115
 Cont…
Name: descriptive name to attributes.
A good attribute name is the one that is capable
of explaining the purpose of the attribute just by
looking at its name.
Type: The data type of an attribute should be
determined (could be a primitive type, such as
string or int, or a class such as Address.)
Initial value: The initial value for an attribute
should also be indicated (if available).

116
 Cont…
Modeling Association
Objects in any system cannot exist and work alone. For
this reason they need to depend one another or collaborate
with each other.
The dependency and collaboration will help the development
team to define how they interact with each other.
The collaboration is important as an object needs to know
about another object to work with it.
For each association multiplicity should be modeled, one
on each end of the association line

117
 Following is an example to compare
Analysis and design versions of a class
Analysis Level Design Level

118
 Deployment Diagram
Shows the physical relationships among software and
hardware components in the delivered system.
is a good place to show how components and objects are
routed and move around a distributed system.
Each node on a deployment diagram represents some kind of
computational unit—in most cases, a piece of hardware.
The hardware may be a simple device or sensor, or it could
be a mainframe.
It shows where components will be located, on what servers,
machines or hardware.

119
 Coding and Testing

120
 Coding
Translating the design specification in to a working
system (a reality)
Two important issues
Coding style
To make readable and maintainable
Adding as much comments as possible, use combination
of uppercase and lower case in naming …
Programming language selection
A language that supports features required
For a web based applications vs window based

121
 Software Testing
Testing is the process of exercising a
A software/program with the specific intent
of finding errors prior to delivery to the end
user.
Fault Detection: is a planned process identifying erroneous states
and finding the underlying faults before releasing the system.
Testing is Verification and Validation
“Are we building the right system?”
“Are we building the system right ?”
Software Testing

white-box black-box
methods methods

Methods

Strategies
 White-Box Testing

... our goal is to ensure that all

statements and conditions have
been executed at least once ...
 Cont…
Also called ‘Glass-box testing’ or ‘structural’ testing
Testers have access to the system design
They can
 Examine the design documents
 View the code
 Observe at run time the steps taken by algorithms and their
internal data
Individual programmers often informally employ glass-
box testing to verify their own code

125
Black-Box Testing

requirements

output

input events
 Cont…
Testers provide the system with inputs and observe the
outputs
They can see none of:
 The source code
 The internal data
 Any of the design documentation describing the system’s
internals

127
 Testing performed by users and clients
Alpha testing
 Performed by the user or client, but under the supervision of the
software development team.
Beta testing
 Performed by the user or client in a normal work environment.
 Recruited from the potential user population.
 An open beta release is the release of low-quality software to the
general population.
Acceptance testing
 Performed by users and customers.
 However, the customers do it on their own initiative.

128
Finally
Software testing is four steps procedure
Initially, unit tests focus on each component
individually, ensuring that it functions properly as a unit.
makes heavy use of white-box testing techniques,
exercising specific paths in a module's control
structure to ensure complete coverage and maximum
error detection.
Cont…
Next, Integration test : components must be assembled
or integrated to form the complete software package.
Integration testing addresses the issues associated with the
dual problems of verification and program construction.
Black-box test case design techniques are the most prevalent
during integration, although a limited amount of white-box
testing may be used to ensure coverage of major control
paths.
Cont…
After the software has been integrated (constructed), a
set of high-order tests are conducted. Validation
criteria (established during requirements analysis)
must be tested.
Validation testing provides final assurance that software
meets all functional, behavioral, and performance
requirements.
 Black-box testing techniques are used exclusively during
validation.
Cont….
The last high-order testing step falls outside the
boundary of software engineering and into the broader
context of computer system engineering. Software,
once validated, must be combined with other system
elements (e.g., hardware, people, databases).
System testing verifies that all elements mesh properly
and that overall system function/performance is
achieved.
 Others
Installation
Putting the system in to work
Direct/phased/parallel/ one site
Training
Enabling end users and technical personals to work and
mange the system/software
For whom and how much?
Maintenance
Providing continuous support as long as the
software/system is alive.
Adaptive/perfective/corrective

133
 Summary
Introduction
Understanding motivations and basic concepts
 Terminologies , concepts, processes, approaches

Modeling using UML

Understanding modeling tools in software development
 Types, categories and structure

Requirement elicitation
Collecting and organizing users requirement- WHAT- User
needs
 From function, class, and interface points of view

134
 Cont…
Requirement Analysis
Analyzing and modeling requirements-WHAT System
 In terms of Function, Logic and Objects (classes)

System and object design

Specifying the new system-HOW
 At an architecture level and detail design level

Implementation, testing and Pragmatic

Making it a reality
 Coding, testing and documentation

135
 End of the Course

136