18CSE265J-SOFTWARE ENGINEERING

1. UNIT-IV
Prepared By
S.Nandhini,
Assistant Professor,
SRMIST (RMP CAMPUS).
18CSC265J/ SOFTWARE
ENGINEERING

2. OBJECT-ORIENTED ANALYSIS
AND DESIGN

3. • The Unified Modeling Language (UML) is a standard
diagramming notation; sometimes referred to as a blueprint.
• It is NOT OOA/OOD or a method
• Only a notation for capturing objects.
• UML is language-independent
• Analysis and design provide software “blueprints” captured in
UML.
• Blueprints serve as a tool for thought and as a form of
communication with others.

4. • But it is far more essential to ‘think’ in terms of objects as
providing ‘services’ and accommodating ‘responsibilities.’
• Discuss: What is meant by ‘services?’ How indicated?
– How might you think these ‘services’ impact the design of classes?
– How might a client access these services?
• Discuss: What is meant by ‘responsibilities?’
– Encapsulation of data and services?

5. • Object-Oriented Analysis (Overview)
– An investigation of the problem (rather than how a solution is defined)
– During OO analysis, there is an emphasis on finding and describing the
objects (or concepts) in the problem domain.
– For example, concepts in a Library Information System include Book,
and Library.

6. • Object-Oriented Design
– Emphasizes a conceptual solution that fulfills the requirements.
– Need to define software objects and how they collaborate to fulfill the
requirements.
– For example, in the Library Information System, a Book software object
may have a title attribute and a getChapter method.
• Designs are implemented in a programming language.
– In the example, we will have a Book class in Java.

7. From Design to Implementation
Book
title
print()
public class Book {
public void print();
private String title;
}
Book
(concept)
Analysis
investigation
of the problem
Design
logical solution
Construction
code
Domain concept Representation in
analysis of concepts
Representation in an
object-oriented
programming language.
Can you see the services / responsibilities in the Book class?

8. • Then too, there are sets of proven design solutions to problems
that are considered ‘best practices.’
– Certain ‘groupings’ of classes with specific responsibilities / interfaces.
– These provide specific solutions to specific problems.
– Called Design Patterns
• We will discuss (much later) these patterns and how to apply
them to develop solutions to problems.

9. • Of course, design, solutions to requirements, ‘assume’ a robust
requirements analysis has taken place.
• Use Cases are often used to capture stories of requirements.
• Use Cases are not specifically designed to be object-oriented,
but rather are meant to capture how an application will be used.
• While there are many methods for capturing requirements, we
will concentrate on Use Cases ahead.

10. Basic Terms: Iterative, Evolutionary, and Agile
1. Introduction
• Iterative because the entire project will be composed of min-
projects and will iterate the same activities again and again (but
on different part of the project) until completion.
• Evolutionary (or incremental) because the software grows by
increments (to be opposed to the traditional, and somewhat old-
fashioned, Waterfall model of software development).
• Agile because we will use a light approach to software
development rather than a very rigid one (which may be needed
for a safety-critical system for example)
• This kind of approach seems better at treating software
development as a problem solving activity; also the use of
objects makes it amenable.

11. • We need a Requirements Analysis approach with OOA/OOD
need to be practiced in a framework of a development process.
• We will adopt an agile approach (light weight, flexible) in the
context of the Unified Process, which can be used as a sample
iterative development process.
• Within this process, the principles can be discussed.
• Please note that there are several other contexts that may be
used, such as Scrum, Feature-Driven Development, Lean
Development, Crystal Methods and others…

12. Why the Unified Process:
• The Unified Process is a popular iterative software development
process.
• Iterative and evolutionary development involves relatively early
programming and testing of a partial system, in repeated cycles.
• It typically also means that development starts before the exact
software requirements have been specified in detail; feedback is
used to clarify, correct and improve the evolving specification:
this is in complete contrast to what we usually mean by
engineering!

13. 2. What is the Unified Process?
• The UP is very flexible and open and can include other practices
from other methods such as Extreme Programming (XP) or
Scrum for example.
– e.g. XP’s test-driven development, refactoring can fit within a UP
project; So can Scrum’s daily meeting.
– Being pragmatic in adapting a particular process to your needs is an
important skill : all projects are different.

14. We will be studying all of the topics found in Fig. 1.1
Topics and Skills
UML notation
Requirements
analysis
Principles and
guidelines
Patterns
Iterative
development with
an agile Unified
Process
OOA/D

15. The Rush to Code
• Analysis: - investigate the problem and the requirements.
– What is needed? Required functions? Investigate domain objects.
– The Whats of a system.
– Do the right thing (analysis)
• Design:
– Conceptual solution that meets requirements.
– Not an implementation
– Describe a database schema and software objects.
– Avoid the CRUD activities and commonly understood functionality.
– The ‘Hows’ of the system
– Do the thing right (design)

16. What is Object-Oriented Analysis and Design
• OOA: we find and describe objects or concepts in the problem
domain
• OOD: we define how these software objects collaborate to meet
the requirements.
– Attributes and methods.
• OOP: Implementation: we implement the design objects in,
say, Java, C++, C#, etc.

17. ABSTRACTION AND MODULARITY

18. Abstraction
1. Highlights common properties of objects
2. Distinguishes important and unimportant properties
3. Must be understood even without a concrete object
 An abstraction denotes the essential characteristics of an object
that distinguish it from all other kinds of objects and thus
provide crisply defined conceptual boundaries, relative to the
perspective of the viewer.
 Abstraction allows designers to focus on solving a problem
without being concerned about irrelevant lower level details.

19. • There are three types of abstraction available
 Procedural abstraction – a sequence of instructions that have a
specific and limited function. Eg: Word OPEN for a door.
 Data abstraction – a named collection of data that describes a
data object. Data abstraction for door would be a set of attributes
that describes the door
(e.g. door type, swing direction, weight, dimension).
 Control abstraction – a program control mechanism without
specifying internal detail. It is used to coordinate all activities in
operating system

20. Modularity
 What is the "right" number of modules for a specific software
design…???
Single attribute of software that allows a program to be intellectually
manageable.
 Software is divided into separately named and addressable
components,often called modules, that are integrated to satisfy
problem requirements.
 This leads to a "divide and conquer" conclusion—it's easier to
solve a complex problem when you break it into manageable
pieces.
 It has been stated that "modularity is the single attribute of
software that allows a program to be intellectually manageable“.

21. Modular decomposability
 A design method provides a systematic mechanism for
decomposing the problem into sub-problems reduce the
complexity and achieve the modularity
Modular composability
 A design method enables existing design components to be
assembled into a new system.
Modular understandability
 A module can be understood as a standalone unit it will be
easier to build and easier to change.

22. Modular continuity
A small changes to the system requirements result in changes to
individual modules, rather than system- wide changes.
Modular protection
An aberrant condition occurs within a module and its effects are
constrained within the module.

24. Information Hiding
 The way of hiding the unnecessary details
 Information (data and procedure) contained within a module
should be inaccessible to other modules that have no need for
such information.
 Hiding defines and enforces access constraints to both
procedural detail within a module and any local data structure
used by the module
 Modules should be specified and designed so that information
(procedure and data) contained within a module is inaccessible
to other modules that have no need for such information.

25.  Hiding implies that effective modularity can be achieved by
defining a set of independent modules that communicate with
one another only that information necessary to achieve software
function.
 Thisenforces access constraints to both procedural (i.e.,
implementation) detail and local data structures.

26. module
controlled
interface
"secret"
• algorithm
• data structure
• details of external interface
• resource allocation policy
clients
a specific design decision

27. Encapsulation
 Encapsulation is also known as information hiding concept.
 The data and operations are combined into a single unit.
 The only way to access data is through operations which are
designed to operate on the data.
 The data is not available to external world.
 This concept may make the data safe and secure from external
interventions.

28. Encapsulation

29. SRS(software requirement specification)
 SRS is the official statement of what the system developers
should implement.
 SRS is a complete description of the behavior of the system to
be developed.
 SRS should include both a definition of user requirements and a
specification of the system requirements.
 The SRS fully describes what the software will do and how it
will be expected to perform.

30. Purpose of SRS
 SRS precisely defines the software product that will be built.
 SRS used to know all the requirements for the software
development and thus that will help in designing the software.
 It provides feedback to the customer.

31. Characteristics of SRS
 Correct : Every requirement given in SRS is a requirement of
the software.
 Unambiguous: Every requirement has exactly one interpretation.
 Complete: Includes all functional, performance, design, external
interface requirements; definition of the response of the software
to all inputs
 Consistent: Internal consistency.
 Ranked importance: Essential vs. desirable.

32. DATA ABSTRACTION

33. Data Abstraction:-
• Concept of “Abstraction”
– Allows us to consider the high-level characteristics of something without
getting bogged down in the details
– For example: Process abstraction in procedural programming like C, we
can use (pre-defined) functions without concern how they really works
inside.
• Data Abstraction
– We know what a data type can do
– How it is done is hidden

34. What is an Abstract Data Type.?
 Abstract Data Type (ADT)
– Defines a particular data structure in terms of data and
operations
– Offers an interface of the objects (instances of an ADT)
 An ADT consists of
– Declaration of data
– Declaration of operations
– Encapsulation of data and operations : data is hidden from
user and can be manipulated only by means of operations

35. ADT Implementation
 Implementation of an Abstract Data Type (ADT)
– Hidden from the user
– Same ADT may be implemented in different ways in different languages
– Some languages offer built-in ADTs and/or features to be used to
implement ADTs (user-define types)
 ADTs support modular design which is very important in
software development

36. Model for an ADT
Interface - Operations
Data Structure
System design with ADTs
Problem definiton
Identification of ADTs
(identify data or attributes)
Specify ADT operations
Specify ADT interactions
Implement ADTs
Identify object hierarchy (if using OOP)

37. Benefits
 Manufacturer Benefits:
– easy to modify, maintain
– profitable
– reusable
 Client Benefits:
– simple to use, understand
– familiar
– cheap
– component–based

38. CLASS RESPONSIBILITY COLLABORATOR
(CRC) MODEL

39.  A Class Responsibility Collaborator (CRC) model (Beck &
Cunningham 1989; Wilkinson 1995; Ambler 1995) is a
collection of standard index cards that have been divided into
three sections, as depicted in Figure 1.
 A class represents a collection of similar objects, a responsibility
is something that a class knows or does, and a collaborator is
another class that a class interacts with to fulfill its
responsibilities.

40.  Although CRC cards were originally introduced as a technique
for teaching object-oriented concepts, they have also been
successfully used as a full-fledged modeling technique.
 CRC models are an incredibly effective tool for conceptual
modeling as well as for detailed design.
 CRC cards feature prominently in extreme Programming (XP)
(Beck 2000) as a design technique.

41.  A class represents a collection of similar objects. An object is a
person, place, thing, event, or concept that is relevant to the
system at hand. For example, in a university system, classes
would represent students, tenured professors, and seminars.
 The name of the class appears across the top of a CRC card and
is typically a singular noun or singular noun phrase, such
as Student, Professor, and Seminar.
 You use singular names because each class represents a
generalized version of a singular object. Although there may be
the student John O'Brien, you would model the class Student.
The information about a student describes a single person, not a
group of people.
 Therefore, it makes sense to use the name Student and
not Students. Class names should also be simple. For example,
which name is better: Student or Person who takes seminars?

42.  A responsibility is anything that a class knows or does. For
example, students have names, addresses, and phone numbers.
 These are the things a student knows. Students also enroll in
seminars, drop seminars, and request transcripts. These are the
things a student does. The things a class knows and does
constitute its responsibilities. Important: A class is able to
change the values of the things it knows, but it is unable to
change the values of what other classes know.
 Sometimes a class has a responsibility to fulfill, but not have
enough information to do it. For example, as you see
in Figure students enroll in seminars.

43.  To do this, a student needs to know if a spot is available in the
seminar and, if so, he then needs to be added to the seminar.
However, students only have information about themselves
(their names and so forth), and not about seminars.
 What the student needs to do is collaborate/interact with the card
labeled Seminar to sign up for a seminar. Therefore, Seminar is
included in the list of collaborators of Student.

44.  Collaboration takes one of two forms: A request for information
or a request to do something. For example, the
card Student requests an indication from the
card Seminar whether a space is available, a request for
information.
 Student then requests to be added to the Seminar, a request to do
something. Another way to perform this logic, however, would
have been to have Student simply request Seminar to enroll
himself into itself.
 Then have Seminar do the work of determining if a seat is
available and, if so, then enrolling the student and, if not, then
informing the student that he was not enrolled.

45.  So how do you create CRC models? Iteratively perform the
following steps:
-Find classes.
-Find responsibilities.
-Define collaborators
-Move the cards around

46. QUALITY CONCEPTS OF DESIGN

47. What is Quality Management.?
 Also called software quality assurance (SQA)
 Serves as an umbrella activity that is applied throughout the
software process
 Involves doing the software development correctly versus doing
it over again
 Reduces the amount of rework, which results in lower costs and
improved time to market

48.  Encompasses
• A software quality assurance process
• Specific quality assurance and quality control tasks
(including formal technical reviews and a multi-
tiered testing strategy)
• Effective software engineering practices (methods and tools)
• Control of all software work products and the changes made
to them
• A procedure to ensure compliance with software
development standards

49. Quality Defined
 Defined as a characteristic or attribute of something
 Refers to measurable characteristics that we can compare to
known standards
 In software it involves such measures as cyclomatic complexity,
cohesion, coupling, function points, and source lines of code
 Includes variation control
• A software development organization should strive to minimize the variation
between the predicted and the actual values for cost, schedule, and resources
• They should make sure their testing program covers a known percentage of the
software from one release to another
• One goal is to ensure that the variance in the number of bugs is
also minimized from one release to another

50.  Two kinds of quality are sought out
Quality of design
The characteristic that designers specify for an item
This encompasses requirements, specifications, and the
design of the system
Quality of conformance (i.e., implementation)
The degree to which the design specifications are
followed during manufacturing
This focuses on how well the implementation follows the
design and how well the resulting system meets its
requirements

51.  Quality also can be looked at in terms of user satisfaction
User satisfaction = compliant product
+ good quality + delivery within budget and schedule
Quality Control
Involves a series of inspections, reviews, and tests used
throughout the software process
Ensures that each work product meets
the requirements placed on it.

52.  Includes a feedback loop to the process that created the work
product
 This is essential in minimizing the errors produced
 Combines measurement and feedback in order to adjust the
process when product specifications are not met
 Requires all work products to have defined,
measurable specifications to which practitioners may compare to
the output of each process

53. SOFTWARE MEASUREMENT AND
METRICS

54.  Software measurement is concerned with deriving a numeric
value for an attribute of a software product or process
 This allows for object comparisons between techniques or
processes
 The systematic use of measurement is essential to process
improvement programs
Software measurement

55. Software Metric
• Any type of measurement that relates to a software system,
process, or document
– LOC, person-months, function points
• Metrics allow for the quantification of the software or a software
process
• May be used to predict product attributes or to control the
software process

56. Predictor and Control Metrics
Management
decisions
Control
measurements
Software
process
Predictor
measurements
Software
product

57. Metrics Assumptions
 The software property of interest can be measured
 There is a known relationship between what we want to measure
and what we want to know
 The relationship has been formalized and validated
 It may be difficult to relate what can be measured to desirable
quality attributes

58. Measurement Process
 The software measurement process may be part of a quality
control process
 Data collected during the measurement process should be
maintained as an organizational strategic resource
 Establishing a measurement database allows comparisons
between and across projects

59. Product Measurement Process
 Choose measurement to be made
 Select components to be assessed
 Measure component characteristics
 Identify anomalous measurements
 Analyze anomalous components

60. Data Collection
 A good metrics program is based on a set of identifiable
product and process data
 Data should be collected immediately (not retrospectively)
 Use automatic data collection if possible
– static product analysis
– dynamic product analysis
– process data collection

61. Automated Data Collection
 Instrumented software system
- monitors added to software to record necessary data unobtrusively
 Usage data
- capture user inputs and transactions
 Fault data
- make use of electronic media to record faults as they are uncovered

62. Data Accuracy
 Don’t collect unnecessary data
– decide the questions to be answered in advance and only
collect relevant data
 Tell people why data is being collected
– make sure people understand that the product and process are
being evaluated (not the employees)
 Don’t rely on people’s memory
– collect data as it is being generated, not after a project is
completed

63. Product Metric Classes
 Dynamic metrics
– measurements made on executing program
– help assess things like efficiency and reliability
 Static metrics
– measurements made of some system representation
– help assess things like complexity, understandability, and maintainability

64. Dynamic and Static Metrics
• Dynamic metrics
– closely related to software quality attributes
– it is fairly easy to measure response time (performance) or
number of failures (reliability)
• Static metrics
– are indirectly related to quality attributes
– you may need to use statistics to derive relationships between
static metrics and attributes like complexity or
maintainability

65. Static Metrics
 Fan-in
– number of functions that call a particular function
 Fan-out
– number of functions called by a particular function
 Length of code
– size of program (LOC or KLOC)
 Cyclomatic complexity
– measures control complexity inside program
 Fog index
– average word and sentence lengths in documents

66. Object-Oriented Static Metrics
 Depth of inheritance tree
– distance between root class and instances
 Method fan-in/fan-out
– wise to distinguish between method calls within a class
and between classes
 Weighted class methods per class
– number of methods in a class weighted by complexity of
each method
 Number of overriding operations
– superclass operations redefined in subclass

67. Customer Satisfaction
 PVM (valid problems per user month)
 How do you improve PVM?
– Reduce product defect injection rates during development
– Improve support, usability, documentation, communication,
or training
– Increase sales of installed licenses (spreads same number of
problems over more user months)

68. Maintenance Metrics
 Defect arrivals by time interval
 Customer problem calls
 Backlog management index (BMI)
- 100% * (# problems fixed this month)/(# arriving this month)
 Percent of delinquent fixes
- 100% * (# fixes by that exceed fix time standards)/(total #
fixes)

69. Measurement Analysis
 It is not always obvious what the data means
 Data analysis is difficult
 Consult professional statisticians when necessary
 Data analyses should take local circumstances into account

70. Measurement Surprise
 Reducing the number of faults in a program may lead to an
increased number of help desk class
 Program is now perceived as more reliable and may have a
wider market (a lower percentage of calls may net a larger
number of calls)
 People are less willing to work around faults in a system that has
a reputation for reliability and this may lead to more calls for
help