CSE 524 Summer 2012

CSE 524: Formal

Methods of Software
Engineering
Lec 5.0
Component Oriented Software
Engineering
Requirements Analysis:
Requirements analysis is
a software engineering
System task that bridges the
Engineering gap between system-
level software allocation
Software and software design.
requirements Requirements analysis
analysis
enables the system
Software engineer to specify
design software function and
performance, indicate
software’s interface with
other system elements,
and establish constraints
that software must
meet.
Analysis principles:
 The information domain of a problem must be represented
and understood.
 The functions that the software is to perform must be
defined.
 The behavior of the software must be represented.
 The models that depict information, function, and behavior
must be partitioned in a manner that uncovers detail in
layered fashion.
 The analysis process should move from essential
information toward implementation detail.
 Testability of each requirement should be taken into
consideration.
Software Design:
 Translate requirements into software
components and interactions among them.
 Components: Objects, functions
 Interfaces: variables, arguments, functions
 Interactions: calling sequence diagram
 Define layers of abstraction.
 Hierarchical decomposition of design complexity
 Form fabrication strategy.
 Abstractions of data, function and class
 Reusability
Design Guidelines:
 A design should exhibit a hierarchical organization that makes
intelligent use of control among elements of software
 A design should be modular; that is, the software should be
logically partitioned into elements that perform specific functions
and sub-functions.
 A design should contain both data and procedural functions.
 A design should lead to modules that exhibit independent
functional characteristics.
 A design should lead to interfaces that reduce the complexity of
connections between modules and with the external
environment.
 A design should be derived using repeatable method that is
driven by information obtained during software requirements
analysis.
Design Principles:
 The design process should not suffer from tunnel vision.
 The design should be traceable to the requirement
analysis model.
 The design should not reinvent the wheel.
 The design “minimize the intellectual distance” between
the software and the problem as it exists in the real world.
 The design should exhibit uniformity and integration.
 The design should be structured to accommodate
change.
 Design should maximize the reuse
 The design should be reviewed.
Requirements to component
mapping:
C1 C2 C3 C4 C5

R1

R2

R3

R4

R5
Requirements to component
interaction mapping:
I-1 I-2 I-3 I-4 I-5

R1

R2

R3

R4

R5
What is it?

 Software is a collection of components

 Behavior of software is defined as a
sequence of interactions between
components.
 Components are fabricated from
hierarchical class definition.
 Real life artifact ?
Modeling is the basic tool of component
oriented software engineering:
Models
Models
 Models
 Models are
are the
the language
language ofof designer,
designer, inin
many
many disciplines
disciplines
 Models
 Models are
are representations
representations of of the
the system
system
to-be-built
to-be-built or
or as-built
as-built
 Models
 Models are
are vehicle
vehicle for
for communications
communications
with
with various
various stakeholders
stakeholders
 Visual
 Visual models,
models, blueprints
blueprints
 Scale
 Scale
 Models
 Models allow
allow reasoning
reasoning about
about some
some
characteristic
characteristic of
of the
the real
real system
system
21
21
Different stakeholders require
different perspectives:
Many
Many stakeholders,
stakeholders, many
many views
views
 Architecture
 Architecture is
is many
many things
things to
to many
many different
different
interested parties
interested parties
­­ end-user
end-user
­­ customer
customer
­­ project
projectmanager
manager
­­ system
systemengineer
engineer
­­ developer
developer
­­ architect
architect
­­ maintainer
maintainer
­­ other
otherdevelopers
developers
 Multidimensional
 Multidimensional reality
reality
 Multiple
 Multiple stakeholders
stakeholders
multiple
multiple views,
views,multiple
multiple blueprints
blueprints

22
22
Unified Modeling Language (UML):
The
The Value
Value of
of the
the UML
UML
 Is
 Is an
an open
open standard
standard
 Supports
 Supports the
the entire
entire software
software development
development
lifecycle
lifecycle
 Supports
 Supports diverse
diverse applications
applications areas
areas
 Is
 Is based
based on
on experience
experience and
and needs
needs of
of the
the
user
user community
community
 Supported
 Supported by
by many
many tools
tools

29
29
 History of UML:
Creating
Creating the
the UML
UML
UML 1.5
UML
UML1.3
1.3
OMG Acceptance, Nov 1997
OMG Acceptance, Nov 1997
Final submission to OMG, Sep ‘97
Final submission to OMG, Sep ‘97 UML
UML1.1
1.1
public First submission to OMG, Jan ´97
public First submission to OMG, Jan ´97
feedback
feedback
UML partners
UML partners
UML
UML1.0
1.0

Web - June ´96

Web - June ´96 UML
UML0.9
0.9
OOPSLA ´95
OOPSLA ´95 Unified
UnifiedMethod
Method0.8
0.8

Other
Othermethods
methods Booch
Boochmethod
method OMT
OMT OOSE
OOSE

30
30
 Contributors:
Contributions
Contributions to
to the
the UML
UML
Harel
Harel
Meyer Gamma,
Meyer Gamma,etetalal
Statecharts
Statecharts
Before
Beforeand
andafter Frameworks
after Frameworksand
andpatterns,
patterns,
conditions
conditions
HP
HPFusion
Fusion
Booch
Booch Operation
Operationdescriptions
descriptionsand
and
Booch
Boochmethod
method message numbering
message numbering

Embley
Embley
Rumbaugh
Rumbaugh
Singleton
Singletonclasses
classesand
and
OMT
OMT high-level view
high-level view
Jacobson
Jacobson Wirfs-Brock
Wirfs-Brock
OOSE
OOSE Responsibilities
Responsibilities
Shlaer Odell
Shlaer- -Mellor
Mellor Odell
Object Classification
Objectlifecycles
lifecycles Classification

32
32
Modeling
Modeling Elements
Elements
 Structural
 Structural elements
elements
­­ class,
class,interface,
interface,collaboration,
collaboration,use
usecase,
case,
active
activeclass,
class,component,
component,node
node

 Behavioral
 Behavioral elements
elements
­­ interaction,
interaction,state
statemachine
machine

 Grouping
 Grouping elements
elements
­­ package,
package,subsystem
subsystem

 Other
 Other elements
elements
­­ note
note
 Models,
Models, Views,
Views, and
and Diagrams
Diagrams
AAmodel
modelisisaacomplete
complete
description
descriptionofofaasystem
system
from
fromaaparticular
particular State
State
perspective
perspective State
State
Diagrams
Class
Diagrams
Class
Diagrams
Use
Use Case
Case Diagrams
Diagrams
Use
UseCase
DiagramsCase Diagrams State
State
Use Case Use
UseCase
Diagrams
DiagramsCase State
State
Diagrams
Use
Use Case
Case Diagrams
Diagrams Object
Diagrams
Object
Use Case
Diagrams
Sequence Diagrams Diagrams
Diagrams
Diagrams
Sequence
Diagrams Diagrams
Diagrams
Diagrams
Diagrams
Diagrams

Scenario
Scenario State
State
Scenario
Scenario
Diagrams State
State
Diagrams
Collaboration
Diagrams
Collaboration
Diagrams Models Component
Diagrams
Component
Diagrams
Diagrams
Diagrams Models Diagrams
Diagrams
Diagrams Diagrams

Scenario
Scenario
Component
Component
Scenario
Scenario
Diagrams
Component
Diagrams
Component
Deployment
Diagrams
Statechart
Diagrams
Statechart
Diagrams Deployment
Diagrams
Diagrams
Diagrams
Diagrams Diagrams
Diagrams
Diagrams Activity
Activity
Diagrams
Diagrams

38
38
Diagrams
Diagrams
 AA diagram
 diagram isis aa view
view into
into aa model
model
­­ Presented
Presentedfrom
fromthethe aspect
aspectofof aaparticular
particular
stakeholder
stakeholder
­­ Provides
Providesaapartial
partialrepresentation
representationof ofthe
the system
system
­­ Is
Issemantically
semanticallyconsistent
consistentwith
withother
otherviews
views

 In
 In the
the UML,
UML, there
there are
are nine
nine standard
standard
diagrams
diagrams
­­ Static
Staticviews:
views:use
usecase,
case,class,
class,object,
object,
component,
component,deployment
deployment
­­ Dynamic
Dynamicviews:
views:sequence,
sequence,collaboration,
collaboration,
statechart,
statechart,activity
activity

39
39
Use-case diagrams:
 They offer a systematic and intuitive means
of capturing functional requirements.
 The use-case model helps the customer,
users and developers agree on how to use
system.
 An user is represented as actor.
 Actors use the system as they interact with
use cases.
 All the actors and use cases of a system
make up a use-case model.
Use
Use Case
Case Diagram
Diagram
 Captures
 Captures system
system functionality
functionality as
as seen
seen by
by
users
users

40
40
Use case for Elevator Problem:

Elevator

Press an elevator
button

Press a floor button

User
Actor
Use
Use Case
Case Diagram
Diagram
 Captures
 Captures system
system functionality
functionality as
as seen
seen by
by
users
users
 Built
 Built in
in early
early stages
stages of
of development
development
 Purpose
 Purpose
­­ Specify
Specifythe
thecontext
contextof
ofaasystem
system
­­ Capture
Capturethetherequirements
requirementsofofaa system
system
­­ Validate
Validateaasystem’s
system’sarchitecture
architecture
­­ Drive
Driveimplementation
implementationandandgenerate
generatetest
testcases
cases

 Developed
 Developed by
by analysts
analysts and
and domain
domain experts
experts

41
41
Activity
Activity Diagram
Diagram
 Captures
 Captures dynamic
dynamic behavior
behavior (activity-oriented)
(activity-oriented)

56
56
Activity
Activity Diagram
Diagram
 Captures
 Captures dynamic
dynamic behavior
behavior (activity-oriented)
(activity-oriented)
 Purpose
 Purpose
­­ Model
Modelbusiness
businessworkflows
workflows
­­ Model
Modeloperations
operations

57
57
 Further to Activity diagrams:
  [condition 1]
A c tiv ity A c tiv ity
• Dynamic aspects of a
system [condition 2]

• Describe
• parallel processing
• workflows A c tiv ity A c tiv ity
• Show flow from activity to
activity
• Activity [synchronization
condition]
conceptual: task to be done

specification/implementation: A c tiv ity

method
 Example of activity diagram:


P u t c o ffe e A d d w a te r
in filte r to r e s e r v o ir

P u t filte r
in m a c h in e

Turn on
m a c h in e
Object Oriented Analysis Phase
 Concise Problem Definition: Define each
requirement as interaction between nouns
and verbs.
 Extracts nouns, verbs and interactions
between them.
 Through use case, show interactions between
people and machines.
 Elevator Problem Definition:
 A product is to be installed to control n elevators in a
building with m floors. The problem concerns the logic
required to move elevators between floors according to the
following constraints:
 Each elevator has a set of m buttons, one for each floor.
These illuminate when pressed and cause the elevator to visit
the corresponding floor. The illumination is cancelled when
corresponding floor is visited by the elevator.
 Each floor, except the first floor and top floor, as two buttons,
one to request an up-elevator and one to request a down-
elevator. These buttons illuminate when passed. The
illumination is cancelled when an when an elevator visits the
floor and then moves in the desired direction.
 When an elevator has no requests, it remains at its current
floor with the doors closed.
Use case for Elevator Problem:

Elevator

Press an elevator button

Press a floor button

State Diagram (Example of Elevator Controller Class):
Button Waiting,
Door
Elevator Event Loop

Elevator stopped, no
Button pushed, Elevator is moving in requests pending
button unlit Elevator
direction d, floor f is next
stopped, Go into wait states
requests
Determine if stop requested Close elevator doors
Process request pending
Check requests after time out
Turn on button

Update request No request to User has requested Close elevator doors

stop at floor f stop at floor f
Close elevator doors after timeout
Continue moving Stop at Floor

Move elevator one Stop elevator Floor Floor button

floor in direction d. button lit unlit
Open doors and start time
Update requests Floor button off

Turn off floor button

Elevator button
lit Elevator button
unlit

Elevator button off

Turn off elevator Process next request
button Move elevator one floor in
direction of next request
Sequence Diagram:
 It captures dynamic behavior.
 Sequence diagram of elevator problem:
Elevator
User Floor Elevator Elevator Elevator
doors
button button controller
1. Press
floor button 2. Inform elevator controller

3. Turn button on
4. Move up one floor
5. Turn button off
6. Open doors
8. Press elevator button
9. Inform elevator 7. Start
controller timer
10. Turn
button on
11. Close doors
12. Move up
13. Turn one floor
button off 14. Open doors
15. Start
timer
16. Close doors
17. Move up one floor
Classes from sequence diagram:
CLASS
Elevator Controller
RESPONSIBILITY
1. Turn on elevator button
2. Turn off elevator button
3. Turn on elevator button
4. Turn off floor button
5. Move elevator up one floor
6. Move elevator down one floor
7. Open elevators door and start timer
8. Close elevator doors after time out
9. Check requests
10. Update requests
COLLABORATION
1. Class Elevator Button
2. Class Floor Button
3. Class Elevator
4. Class Elevator Doors
Classes from sequence diagram…:
CLASS
Elevator Controller
RESPONSIBILITY
1. Send message to Elevator Button to turn on button
2. Send message to Elevator Button to Turn off button
3. Send message to Floor Button to Turn on button
4. Send message to Floor Button to Turn off floor button
Public methods?
5. Send Message to Elevator to move up one floor
6. Send message to Elevator to move down one floor Private methods?
7. Send message to Elevator Doors to open
Private attributes?
8. Start timer
9. Send message to Elevator Doors to close after time
out
10. Check requests
11. Update requestsCOLLABORATION

1. Class Elevator Button

2. Class Floor Button
3. Class Elevator
4. Class Elevator Doors
Class hierarchy from sequence diagram:


Button
Illuminated: Boolean

Elevator Button Floor Button

Communicates Communicates
with with

Elevator
Doors open: Boolean
Collaboration Diagram:
Elevator doors

11. Close doors 16. close

doors
6.Open doors 14. open doors

4. Move up one floor.

Elevator controller elevator
12. Move up one floor.
17. Move up one floor.

7. Start timer 10. Turn button on

3. Turn button on 15. Start timer 13. Turn button off
5. Turn button off 9. Inform elevator controller
2. inform elevator button

1. Press floor 8. Press

Floor button button elevator button Elevator button
METRICS FOR OBJECT-
ORIENTED Design
 While metrics for the traditional functional
decomposition and data analysis design
approach deal with the design structure
and/or data structure independently, object-
oriented metrics must be able to focus on
the combination of function and data as an
integrated object.
 The goal of defining and using metrics is the
measurement of Product (Code) Quality.
 The metrics selected are applicable to the attributes that support
this goal. The object-oriented metric criteria, therefore, are the
evaluation of the following areas:
 Efficiency of the implementation of the design - Were the
constructs efficiently designed?
 Complexity - Could the constructs be used more effectively to
decrease the architectural complexity?
 Understandability/Usability - Does the design increase the
psychological complexity?
 Reusability/Application specific - Is the design application
specific?
 Testability/Maintenance - Does the structure enhance testing?

 Whether a metrics is “traditional” or “new”, it must be effective in

measuring on of these areas. As each metric is presented, we
will briefly discuss its applicability to these areas.
Object-Oriented Specific
Metrics:
 Class
 Weighted Methods per Class (WMC)
 Response for a Class (RFC)
 Lack of Cohesion of Methods (LCOM)
 Coupling Between Object Classes (CBO)
 Depth of Inheritance Tree (DIT)
 Number of Children (NOC)
 Metric: Weighted Methods per
Class (WMC)
 The WMC is a count of the methods implemented within a class or
the sum of the complexities of the methods (method complexity is
measured by cyclomatic complexity).
 The second measurement is difficult to implement since not all
methods are assessable within the class hierarchy due to
inheritance.
 The number of methods and the complexity of the methods involved
is a predictor of how much time and effort is required to develop and
maintain the class.
 The larger the number of methods in a class, the greater the
potential impact on children since children will inherit all the methods
defined in a class.
 Classes with large numbers of methods are likely to be more
application specific, limiting the possibility of reuse. This metric
measures usability and reusability.
 Metric: Response for a Class (RFC)
 The RFC is the cardinality of the set of all methods that can be invoked
in response to a message to an object of the class or by some method
in the class.
 This includes all methods accessible within the class hierarchy. This
metric looks at the combination of the complexity of a class through the
number of methods and the amount of communication with other
classes.
 The larger the number of methods that can be invoked from a class
through messages, the greater the complexity of the class.
 If a large number of methods can be invoked in response to a
message, the testing and debugging of the class becomes complicated
since it requires a greater level of understanding on the part of the
tester.
 A worst case value for possible responses will assist in the appropriate
allocation of testing time. This metric evaluations system design as well
as the usability and the testability.
Cohesion
 Cohesion is the degree to which methods
within a class are related to one another and
work together to provide well-bounded
behavior.
 Effective object-oriented designs maximize
cohesion since it promotes encapsulation.
Metric: Lack of Cohesion of
Methods (LCOM)
Coupling
 Coupling is a measure of the strength of
association established by a connection from
one entity to another. Classes (objects) are
coupled three ways:
 When a message is passed between objects,
the objects are said to be coupled.
 Classes are coupled when methods declared in
one class use methods or attributes of the other
classes.
 Inheritance introduces significant tight coupling
between superclasses and their subclasses
Metric: Coupling Between Object Classes (CBO)
 CBO is a count of the number of other classes to which a class is coupled.
 It is measured by counting the number of distinct non-inheritance related
class hierarchies on which a class depends.
 Excessive coupling is detrimental to modular design and prevents reuse.
 The more independent a class is, the easier it is reuse in another
application.
 The larger the number of couples, the higher the sensitivity to changes in
other parts of the design and therefore maintenance is more difficult.
 Strong coupling complicates a system since a module is harder to
understand, change or correct by itself if it is interrelated with other
modules.
 Complexity can be reduced by designing systems with the weakest
possible coupling between modules.
 This improves modularity and promotes encapsulation. CBO evaluates
design implementation and reusability.
Inheritance
 Another design abstraction in object-oriented systems is the
use of inheritance.
 Inheritance is a type of relationship among classes that
enables programmers to reuse previously defined objects
including variables and operators.
 Inheritance decreases complexity by reducing the number of
operations and operators, but this abstraction of objects can
make maintenance and design difficult.
 The two metrics used to measure the amount of inheritance
are the depth and breadth of the inheritance hierarchy.
Metric: Depth of Inheritance Tree (DIT)
 The depth of a class within the inheritance hierarchy is the
maximum length from the class node to the root of the tree and
is measured by the number of ancestor classes.
 The deeper a class is within the hierarchy, the greater the
number methods it is likely to inherit making it more complex to
predict its behavior.
 Deeper trees constitute greater design complexity, since more
methods and classes are involved, but the greater the potential
for reuse of inherited methods.
 A support metric for DIT is the number of methods inherited
(NMI).
 This metric primarily evaluates reuse but also relates to
understandability and testability.
Metric: Number of Children (NOC)

 The number of children is the number of immediate subclasses

subordinate to a class in the hierarchy.
 It is an indicator of the potential influence a class can have on
the design and on the system.
 The greater the number of children, the greater the likelihood of
improper abstraction of the parent and may be a case of misuse
of subclassing.
 But the greater the number of children, the greater the reuse
since inheritance is a form of reuse.
 If a class has a large number of children, it may require more
testing of the methods of that class, thus increase the testing
time.
 NOC, therefore, primarily