20CB304 - SE - UNIT V - Digital Notes.pptx

Pleasereadthis disclaimer before proceeding:
This document is confidential and intended solely for the educational purpose of
RMK Group of Educational Institutions. If you have received this document
through email in error, please notify the system manager. This document
contains proprietary information and is intended only to the respective group /
learning community as intended. If you are not the addressee you should not
disseminate, distribute or copy through e-mail. Please notify the sender
immediately by e-mail if you have received this document by mistake and delete
this document from your system. If you are not the intended recipient you are
notified that disclosing, copying, distributing or taking any action in reliance on
the contentsof this information is strictlyprohibited.

Digital Notes
20CB304 Software Engineering
Department: CSBS
Batch/Year: 2021-25/II
Created by: Mr.B.Jayaram/AP
Date: 24.07.2022

COURSE OBJECTIVES
To understand the different models and milestones in a software project
To understand fundamental concepts of software project management
To understand the various software design methodologies
To learn various testing and maintenance measures
To understand knowledge driven development
PREREQUISITE
20IT101 Fundamentals of Computer Science
20IT201 Data Structures and Algorithms

20CB304
SYLLABUS
Software Engineering L T P C
3 2 2 5
UNIT I INTRODUCTION 9
Programming in the small vs. programming in the large; software project failures and
importance of software quality and timely availability; engineering approach to
software development; role of software engineering towards successful execution of
large software projects; emergence of software engineering as a discipline. Basic
concepts of life cycle models different models and milestones. Software Quality and
Reliability: Internal and external qualities; process and product quality; principles to
achieve software quality; introduction to different software quality models like McCall,
Boehm, FURPS / FURPS+, Dromey, ISO – 9126; introduction to Capability Maturity
Models (CMM and CMMI); introduction to software reliability, reliability models and
estimation
UNIT II SOFTWARE PROJECT MANAGEMENT 9
Software project planning –identification of activities and resources; concepts of
feasibility study; techniques for estimation of schedule and effort; software cost
estimation models and concepts of software engineering economics; techniques of
software project control and reporting; introduction to measurement of software size;
introduction to the concepts of risk and its mitigation; configuration management.
DESIGN AND
9
UNIT III SOFTWARE REQUIREMENTS ANALYSIS,
CONSTRUCTION
Introduction to Software Requirements Specifications (SRS) and requirement
elicitation techniques; techniques for requirement modelling – decision tables, event
tables, state transition tables, Petri nets; Requirements documentation through use
cases; Introduction to UML, introduction to software metrics and metrics based
control methods; measures of code and design quality.

SYLLABUS
20CB304 Software Engineering L
3
T P C
2 2 5
UNIT IV SOFTWARE TESTING 9
Introduction to faults and failures; basic testing concepts; concepts of verification
and validation; black box and white box tests; white box test coverage – code
coverage, condition coverage, branch coverage; basic concepts of black-box tests –
equivalence classes, boundary value tests, usage of state tables; testing use cases;
transaction-based testing; testing for non- functional requirements – volume,
performance and efficiency; concepts of inspection.
UNIT V Object Oriented Analysis, Design and Construction: 9
Concepts -- the principles of abstraction, modularity, specification, encapsulation
and information hiding; concepts of abstract data type; Class Responsibility
Collaborator (CRC) model; quality of design; design measurements; concepts of
design patterns; Refactoring; object oriented construction principles; object
oriented metrics.
TOTAL: 45 PERIODS

Course Outcomes
Course
Code Course Outcome Statement
Cognitive/
Affective
Level of
the
Course
Outcome
Expected
Level of
Attainment
Course Outcome Statements in CognitiveDomain
CO1
Identify the key activities in managing a software
project.
Understand
K2 70%
CO2
Manage project schedule, estimate project cost
and effort required.
Analyse
K4 70%
CO3
Summarize the concepts of software
requirement analysis and design .
Understand
K2 70%
CO4
Identify the need for software metrics and
measure of code and design quality.
Analyse
K4 70%
CO5
Compare and contrast various testing
methodologies.
Analyse
K4 70%
CO6
Analyze Knowledge driven development and
problem space understanding
Analyse
K4 70%

(CO
s)
Programme Outcomes (POs), Programme Specific Outcomes(PSOs)
PO
1
PO
2
PO
3
PO
4
PO
5
PO
6
PO
7
PO
8
PO
9
PO
10
PO
11
PO
12
PS
O1
PS
O2
PS
O3
CO1 3 2 1 1 3 3 3 3 3
CO2 3 3 2 2 3 3 3 3 3
CO3 2 1 2 3 3 3
CO4 3 2 1 1 3 3 3 3 3
CO5 3 3 2 2 3 3 3 3 3
CO6 3 2 1 1 3 3 2 2 2
9
Correlation Matrix of the Course Outcomes to Programme Outcomes and
Programme Specific Outcomes Including Course Enrichment Activities
CO-PO/PSO Mapping

UNIT V
Object Oriented Analysis, Design and Construction
10
Object-Oriented Programming
Object-oriented programming is a method of implementation in which programs are
organized as cooperative collections of objects, each of which represents an instance of
some class, and whose classes are all members of a hierarchy of classes united via
inheritance relationships.
There are three important parts to this definition: (1) Object-oriented programming
uses objects, not algorithms, as its fundamental logical building; (2) each object is an
instance of some class; and (3) classes may be related to one another via inheritance
relationships. A program may appear to be object-oriented, but if any of these
elements is missing, it is not an object-oriented program. Specifically, programming
without inheritance is distinctly not object oriented; that would merely be programming
with abstract data types.
A language is object-oriented if and only if it satisfies the following
requirements:
 It supports objects that are data abstractions with an interface of named operations
and a hidden local state.
 Objects have an associated type [class].
 Types [classes] may inherit attributes from supertypes [super classes].
Object-Oriented Design
Object-oriented design is a method of design encompassing the process of object-
oriented decomposition and a notation for depicting both logical and physical as well as
static and dynamic models of the system under design.
There are two important parts to this definition: object-oriented design (1) leads to an
object-oriented decomposition and (2) uses different notations to express different
models of the logical (class and object structure) and physical (module and process
architecture) design of a system, in addition to the static and dynamic aspects of the
system.

Object-Oriented Analysis
Object-oriented analysis (OOA) emphasizes the building of real-world models, using
an object-oriented view of the world: Object-oriented analysis is a method of
analysis that examines requirements from the perspective of the classes and objects
found in the vocabulary of the problem domain.
How are OOA, OOD, and OOP related?
Basically, the products of object-oriented analysis serve as the models from which
we may start an object-oriented design; the products of object-oriented design can
then be used as blueprints for completely implementing a system using object-
oriented programming methods.
Elements of the object model
Programming style
Programming style as “a way of organizing programs on the basis of some
conceptual model of programming and an appropriate language to make programs
written in the style clear”.
There are five main kinds of programming styles, listed here with the kinds of
abstractions they employ:
There is no single programming style that is best for all kinds of applications. For
example, rule-oriented programming would be best suited for the design of a
knowledge base, and procedure-oriented programming would be best for the design
of computation-intense operations. From our experience, the object-oriented style is
best suited to the broadest set of applications; indeed, this programming paradigm
often serves as the architectural framework in which we employ other paradigms.
11

Each of these styles of programming is based on its own conceptual framework.
Each requires a different mindset, a different way of thinking about the problem. For
all things object-oriented, the conceptual framework is the object model.
There are four major elements of this model:
1. Abstraction
2. Encapsulation
3. Modularity
4. Hierarchy
By major, we mean that a model without any one of these elements is not object-
oriented.
There are three minor elements of the object model:
1. Typing
2. Concurrency
3. Persistence
By minor, we mean that each of these elements is a useful, but not essential, part of
the object model.
1.Concepts -- the principles of abstraction, modularity,
specification, encapsulation and information hiding
1. The Meaning of Abstraction
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 focuses on the essential characteristics of some object, relative to the
perspective of the viewer.
12

“There is a spectrum of abstraction, from objects which closely model problem
domain entities to objects which really have no reason for existence”. From the most
to the least useful, these kinds of abstractions include the following:
Entity abstraction
An object that represents a useful model of a problem domain or solution domain
entity.
Action abstraction
An object that provides a generalized set of operations, all of which perform the
same kind of function.
Virtual machine abstraction
An object that groups operations that are all used by some superior level of control,
or operations that all use some junior-level set of operations.
Coincidental abstraction
An object that packages a set of operations that have no relation to each other.
Some more points on abstraction
A client is any object that uses the resources of another object (known as the
server). We can characterize the behavior of an object by considering the services
that it provides to other objects, as well as the operations that it may perform on
other objects.
Central to the idea of an abstraction is the concept of invariance. An invariant is
some Boolean (true or false) condition whose truth must be preserved. For each
operation associated with an object, we may define preconditions (invariants
assumed by the operation) as well as postconditions (invariants satisfied by the
operation). Violating an invariant breaks the contract associated with an abstraction.
13

If a precondition is violated, this means that a client has not satisfied its part of the
bargain, and hence the server cannot proceed reliably. Similarly, if a postcondition is
violated, this means that a server has not carried out its part of the contract, and so
its clients can no longer trust the behavior of the server. An exception is an
indication that some invariant has not been or cannot be satisfied.
All abstractions have static as well as dynamic properties. For example, a file object
takes up a certain amount of space on a particular memory device; it has a name,
and it has contents. These are all static properties. The value of each of these
properties is dynamic, relative to the lifetime of the object: A file object may grow or
shrink in size, its name may change, its contents may change.
Fig. 5.1 Abstraction of a temperature sensor
What are the responsibilities of a temperature sensor? Our design decision is that a
sensor is responsible for knowing the temperature at a given location and reporting
that temperature when asked. More concretely, what operations can a client perform
on a temperature sensor? Our design decision is that a client can calibrate it, as well
as ask what the current temperature is.
5.1.2 The Meaning of Encapsulation
The abstraction of an object should precede the decisions about its implementation.
Once an implementation is selected, it should be treated as a secret of the
abstraction and hidden from most clients.
14

Abstraction and encapsulation are complementary concepts:
Abstraction focuses on the observable behavior of an object, whereas encapsulation
focuses on the implementation that gives rise to this behavior.
Encapsulation is most often achieved through information hiding (not just data
hiding), which is the process of hiding all the secrets of an object that do not
contribute to its essential characteristics; typically, the structure of an object is
hidden, as well as the implementation of its methods. “No part of a complex system
should depend on the internal details of any other part”. Whereas abstraction “helps
people to think about what they are doing,” encapsulation “allows program changes
to be reliably made with limited effort.
“Encapsulation is the process of compartmentalizing the elements of an abstraction
that constitute its structure and behavior; encapsulation serves to separate the
contractual interface of an abstraction and its implementation”.
5.1.3 The Meaning of Modularity
The act of partitioning a program into individual components can reduce its
complexity to some degree. . . . Although partitioning a program is helpful for this
reason, a more powerful justification for partitioning a program is that it creates a
number of well-defined, documented boundaries within the program.
“Modularization consists of dividing a program into modules which can be compiled
separately, but which have connections with other modules”.
In traditional structured design, modularization is primarily concerned with the
meaningful grouping of subprograms, using the criteria of coupling and cohesion. In
object-oriented design, the problem is subtly different: The task is to decide where
to physically package the classes and objects, which are distinctly different from
subprograms.
15

The overall goal of the decomposition into modules is the reduction of software cost
by allowing modules to be designed and revised independently. . . . Each module’s
structure should be simple enough that it can be understood fully; it should be
possible to change the implementation of other modules without knowledge of the
implementation of other modules and without affecting the behavior of other
modules; [and] the ease of making a change in the design should bear a reasonable
relationship to the likelihood of the change being needed”.
We strive to build modules that are cohesive (by grouping logically related
abstractions) and loosely coupled (by minimizing the dependencies among
modules). From this perspective, we may define modularity as follows:
Modularity is the property of a system that has been decomposed into a set of
cohesive and loosely coupled modules.
5.1.4 The Meaning of Hierarchy
A set of abstractions often forms a hierarchy, and by identifying these hierarchies in
our design, simplify understanding of the problem.
We define hierarchy as follows:
Hierarchy is a ranking or ordering of abstractions.
The two most important hierarchies in a complex system are its class structure (the
“is a” hierarchy) and its object structure (the “part of” hierarchy).
Examples of Hierarchy: Single Inheritance
inheritance defines a relationship among classes, wherein one class shares the
structure or behavior defined in one or more classes (denoting single inheritance
and multiple inheritance, respectively). Inheritance thus represents a hierarchy of
abstractions, in which a subclass inherits from one or more super classes. Typically,
a subclass augments or redefines the existing structure and behavior of its super
classes.
16

Inheritance denotes an “is a” relationship. For example, a bear “is a” kind of
mammal, a house “is a” kind of tangible asset, and a quick sort “is a” particular kind
of sorting algorithm. Inheritance thus implies a generalization/ specialization
hierarchy, wherein a subclass specializes the more general structure or behavior of
its super classes. The litmus test for inheritance: If B is not a kind of A, then B
should not inherit from A.
As we evolve our inheritance hierarchy, the structure and behavior that are common
for different classes will tend to migrate to common superclasses. This is why we
often speak of inheritance as being a generalization/specialization hierarchy.
Superclasses represent generalized abstractions, and subclasses represent
specializations in which fields and methods from the superclass are added, modified,
or even hidden. In this manner, inheritance lets us state our abstractions with an
economy of expression. Indeed, neglecting the “is a” hierarchies that exist can lead
to bloated, inelegant designs. “Without inheritance, every class would be a free-
standing unit, each developed from the ground up. Different classes would bear no
relationship with one another, since the developer of each provides methods in
whatever manner he chooses.
Examples of Hierarchy: Multiple Inheritance
For certain abstractions, it is useful to provide inheritance from multiple
superclasses.
For example, we can define a Rose class (see Figure 5.2) that inherits from both
Plant and FlowerMixin. Instances of the subclass Rose thus include the structure and
behavior from the class Plant together with the structure and behavior from the
class FlowerMixin.
17

Similarly, a Carrot class could be as shown in Figure 5.3. In both cases, we form the
subclass by inheriting from two superclasses.
Figure 5.2:The Rose Class, Which Inherits from Multiple Superclasses
Figure 5.3:The Carrot Class, Which Inherits from Multiple Superclasses
Multiple inheritance is conceptually straightforward, but it does introduce some
practical complexities for programming languages. Languages must address two
issues: clashes among names from different superclasses and repeated inheritance.
Clashes will occur when two or more superclasses provide a field or operation with
the same name or signature as a peer superclass.
18

Examples of Hierarchy: Aggregation
The “is a” hierarchies denote generalization/specialization relationships, “part of”
hierarchies describe aggregation relationships. For example, consider the abstraction
of a garden. We can contend that a garden consists of a collection of plants together
with a growing plan. In other words, plants are “part of” the garden, and the
growing plan is “part of” the garden. This “part of” relationship is known as
aggregation.
Aggregation is not a concept unique to object-oriented development or object-
oriented programming languages. Indeed, any language that supports record-like
structures supports aggregation. However, the combination of inheritance with
aggregation is powerful: Aggregation permits the physical grouping of logically
related structures, and inheritance allows these common groups to be easily reused
among different abstractions.
In terms of its “is a” hierarchy, a high-level abstraction is generalized, and a low-
level abstraction is specialized. Therefore, we say that a Flower class is at a higher
level of abstraction than a Plant class. In terms of its “part of” hierarchy, a class is at
a higher level of abstraction than any of the classes that make up its
implementation. Thus, the class Garden is at a higher level of abstraction than the
type Plant, on which it builds.
Aggregation raises the issue of ownership. Our abstraction of a garden permits
different plants to be raised in a garden over time, but replacing a plant does not
change the identity of the garden as a whole, nor does removing a garden
necessarily destroy all of its plants (they are likely just transplanted). In other words,
the lifetime of a garden and its plants are independent. In contrast, we have decided
that a GrowingPlan object is intrinsically associated with a Garden object and does
not exist independently. Therefore, when we create an instance of Garden, we also
create an instance of GrowingPlan; when we destroy theGarden object, we in turn
destroy the GrowingPlan instance.
19

5.1.5 The Meaning of Typing
“A type is a precise characterization of structural or behavioral properties which a
collection of entities all share”.
Typing is the enforcement of the class of an object, such that objects of different
types may not be interchanged, or at the most, they may be interchanged only in
very restricted ways.
A given programming language may be strongly typed, weakly typed, or even
untyped, yet still be called object-oriented. For example, Eiffel is strongly typed,
meaning that type conformance is strictly enforced: Operations cannot be called on
an object unless the exact signature of that operation is defined in the object’s class
or superclasses.
Examples of Typing: Static and Dynamic Typing
The concepts of strong and weak typing and static and dynamic typing are entirely
different. Strong and weak typing refers to type consistency, whereas static and
dynamic typing refers to the time when names are bound to types. Static typing
(also known as static binding or early binding) means that the types of all variables
and expressions are fixed at the time of compilation; dynamic typing (also known as
late binding) means that the types of all variables and expressions are not known
until runtime. A language may be both strongly and statically typed (Ada), strongly
typed yet supportive of dynamic typing (C++, Java), or untyped yet supportive of
dynamic typing (Smalltalk).
Polymorphism is a condition that exists when the features of dynamic typing and
inheritance interact. Polymorphism represents a concept in type theory in which a
single name (such as a variable declaration) may denote objects of many different
classes that are related by some common superclass. Any object denoted by this
name is therefore able to respond to some common set of operations [74]. The
opposite of polymorphism is monomorphism, which is found in all languages that are
both strongly and statically typed.
Polymorphism is perhaps the most powerful feature of object-oriented programming
languages next to their support for abstraction, and it is what distinguishes object-
oriented programming from more traditional programming with abstract data types.
20

5.1.6 The Meaning of Concurrency
Systems executing across multiple CPUs allow for truly concurrent threads of control,
whereas systems running on a single CPU can only achieve the illusion of concurrent
threads of control, usually by means of some time-slicing algorithm. We also
distinguish between heavyweight and lightweight concurrency. A heavyweight
process is one that is typically independently managed by the target operating
system and so encompasses its own address space. A lightweight process usually
lives within a single operating system process along with other lightweight
processes, which share the same address space. Communication among
heavyweight processes is generally expensive, involving some form of interprocess
communication; communication among lightweight processes is less expensive and
often involves shared data.
Whereas object-oriented programming focuses on data abstraction, encapsulation,
and inheritance, concurrency focuses on process abstraction and synchronization.
Concurrency is the property that distinguishes an active object from one
that is not active.
one of the realities about concurrency is that once its introduce it into a
system, consider how active objects synchronize their activities with one
another as well as with objects that are purely sequential. For example, if two
active objects try to send messages to a third object, we must be certain to
use some means of mutual exclusion, so that the state of the object being
acted on is not corrupted when both active objects try to update its state
simultaneously. This is the point where the ideas of abstraction,
encapsulation, and concurrency interact.
In the presence of concurrency, it is not enough simply to define the methods
of an object; we must also make certain that the semantics of these methods
are preserved in the presence of multiple threads of control.
21

5.1.7 The Meaning of Persistence
An object in software takes up some amount of space and exists for a particular
amount of time. In most systems, an object, once created, consumes the same
physical memory until it ceases to exist. However, for systems that execute on a
distributed set of processors, we must sometimes be concerned with persistence
across space. In such systems, it is useful to think of objects that can move from
machine to machine and that may even have different representations on different
machines.
Persistence is the property of an object through which its existence transcends time
(i.e., the object continues to exist after its creator ceases to exist) and/or space (i.e.,
the object’s location moves from the address space in which it was created).
5.2 Concepts of Abstract Data Type
An abstract data type (ADT) is a mathematical model for data types. An abstract
data type is defined by its behavior (semantics) from the point of view of a user, of
the data, specifically in terms of possible values, possible operations on data of this
type, and the behavior of these operations. This mathematical model contrasts with
data structures, which are concrete representations of data, and are the point of
view of an implementer, not a user.
Formally, an ADT may be defined as a "class of objects whose logical behavior is
defined by a set of values and a set of operations“.
Example
A well-known and convenient example is the description of stack objects. A
stack object serves to pile up and retrieve other objects in a last-in, first-out
(“LIFO”) manner, the latest inserted element being the first one to be retrieved. The
stack is a ubiquitous structure in computing science and in many software systems;
the typical compiler or interpreter, for example, is peppered with stacks of many
kinds.
22

Stack representations
Several possible physical representations exist for stacks:
ARRAY_UP: represent a stack through an array representation and an integer
count whose value ranges from 0 (for an empty stack) to capacity, the size of the
array representation; stack elements are stored in the array at indices 1 up to count.
ARRAY_DOWN: like ARRAY_UP, but with elements stored from the end of the
array rather than from the beginning. Here the integer is called free (it is the index
of the highest free array position, or 0 if all positions are occupied) and ranges from
capacity for an empty stack down to 0. The stack elements are stored in the array at
indices capacity down to free + 1.
LINKED: a linked representation which stores each stack element in a cell with two
fields: item representing the element, and previous containing a pointer to the cell
containing the previously pushed element. The representation also needs last, a
pointer to the cell representing the top.
Fig. 5.4 Three possible
representations
for a stack
23

Next to each representation, the figure shows a program extract (in Pascal-like
notation) giving the corresponding implementation for a basic stack operation:
pushing an element x onto the top.
For the array representations, ARRAY_UP and ARRAY_DOWN, the instructions
increase or decrease the top indicator (count or free) and assign x to the
corresponding array element. Since these representations support stacks of at most
capacity elements, robust implementations should include guards of the respective
forms.
For LINKED, the linked representation, pushing an element requires four
operations: Create a new cell n (done here with Pascal’s new procedure, which
allocates space for a new object); assign x to the new cell’s item field; chain the new
cell to the earlier stack top by assigning to its previous field the current value of last;
and update last so that it will now be attached to the newly created cell.
Using the operations
The operations typically available on a stack are the following:
• A command to push an element on top of a stack. Let us call that operation put.
• A command to remove the stack’s top element, if the stack is not empty. Let us
call it remove.
• A query to find out what the top element is, if the stack is not empty. Let us call it
item.
• A query to determine whether the stack is empty. (This will enable clients to
determine beforehand if they can use remove and item.)
24

Formalizing the specification
An abstract data type specification will provide the following information.
• TYPES.
• FUNCTIONS.
• AXIOMS.
• PRECONDITIONS.
Specifying types
what is a type?
A type is a collection of objects characterized by functions, axioms and
preconditions. an abstract data type such as STACK is not an object (one particular
stack) but a collection of objects (the set of all stacks). An object belonging to the
set of objects described by an ADT specification is called an instance of the ADT. For
example, a specific stack which satisfies the properties of the STACK abstract data
type will be an instance of STACK.
Our specification is about a single abstract data type STACK, describing stacks of
objects of an arbitrary type G.
Genericity
In STACK [G], G denotes an arbitrary, unspecified type. G is called a formal generic
parameter of the abstract data type STACK, and STACK itself is said to be a generic
ADT. The mechanism permitting such parameterized specifications is known as
genericity.
Listing the functions
After the TYPES paragraph comes the FUNCTIONS paragraph, which lists the
operations applicable to instances of the ADT. As announced, these operations will
25

be the prime component of the type definition — describing its instances not by
what they are but by what they have to offer. Below is the FUNCTIONS paragraph
for the STACK abstract data type.
Each line introduces a mathematical function modeling one of the operations on
stacks. For example function put represents the operation that pushes an element
onto the top of a stack.
Operation put, for example, is specified as
which means that put will take two arguments, a STACK of instances of G and an
instance of G, and yield as a result a new STACK [G]. (More formally, the source set
of function put is the set STACK [G] X G, known as the cartesian product of STACK
[G] and G; this is the set of pairs <s, x> whose first element s is in STACK [G] and
whose second element x is in G.) Here is an informal illustration:
26

The role of the operations modeled by each of the functions in the
specification of STACK is discussed below.
•Function put yields a new stack with one extra element pushed on top. The figure
on the preceding page illustrates put (s, x) for a stack s and an element x.
•Function remove yields a new stack with the top element, if any, popped; like put,
this function should yield a command at design and implementation time. We will
see below how to take into account the case of an empty stack, which has no top to
be popped.
• Function item yields the top element, if any.
• Function empty indicates whether a stack is empty; its result is a boolean value
(true or false); the ADT BOOLEAN is assumed to have been defined separately.
• Function new yields an empty stack.
The FUNCTIONS paragraph does not fully define these functions; it only introduces
their signatures — the list of their argument and result types. The signature of put is
STACK [G] X G - STACK [G] indicating that put accepts as arguments pairs of the
form <s, x> where s is an instance of STACK [G] and x is an instance of G, and
yields as a result an instance of STACK [G]. The signature of functions remove and
item includes a crossed arrow instead of the standard arrow used by put and
empty. This notation expresses that the functions are not applicable to all members
of the source set.
The AXIOMS paragraph
The AXIOMS paragraph states the properties. For STACK it will be:
27

The first two axioms express the basic LIFO (last-in, first-out) property of stacks. T
o
understand them, assume we have a stack s and an instance x, and define s' to be
put (s, x), that is to say the result of pushing x onto s. Here axiom A1 tells us that
the top of s' is x, the last element that we pushed; and axiom A2 tells us that if we
remove the top element from s', we get back the stack s that we had before pushing
x. These two axioms provide a concise description of the fundamental property of
stacks in pure mathematical terms. Axioms A3 and A4 tell us when a stack is empty
and when it is not: a stack resulting from the creator function new is empty; any
stack resulting from pushing an element on an existing stack (empty or not) is non-
empty.
Preconditions
For STACK, the paragraph will appear as:
where, for each function, the require clause indicates what conditions the function’s
arguments must satisfy to belong to the function’s domain. The boolean expression
which defines the domain is called the precondition of the corresponding partial
function. Here the precondition of both remove and item expresses that the stack
argument must be non-empty.
The complete specification
It is given in the figure 5.5.
FROM ABSTRACT DATA TYPES TO CLASSES
In the search for a good modular structure based on object types, abstract data
types provide a high-level description mechanism, free of implementation concerns.
They will lead us to the fundamental structures of object technology.
28

Fig. 5.5 Complete ADT Specification of stacks
Classes
ADTs will serve as the direct basis for the modules, More precisely, an object-
oriented system will be built (at the level of analysis, design or implementation) as a
collection of interacting ADTs, partially or totally implemented. The basic notion here
is class:
So to obtain a class we must provide an ADT and decide on an implementation. The
ADT is a mathematical concept; the implementation is its computer-oriented version.
The definition, however, states that the implementation may be partial; the following
terminology separates this case from that of a fully implemented class:
29

To obtain an effective class, you must provide all the implementation details. For a
deferred class, you may choose a certain style of implementation but leave some
aspects of the implementation open. In the most extreme case of “partial”
implementation you may refrain from making any implementation decision at all; the
resulting class will be fully deferred, and equivalent to an ADT.
How to produce an effective class
Consider first the case of effective classes. What does it take to implement an ADT?
Three kinds of element will make up the resulting effective class:
E1 • An ADT specification (a set of functions with the associated axioms and
preconditions, describing the functions’ properties).
E2 • A choice of representation.
E3 • A mapping from the functions (E1) to the representation (E2) in the form of a
set of mechanisms, or features, each implementing one of the functions in terms of
the representation, so as to satisfy the axioms and preconditions. Many of these
features will be routines (subprograms) in the usual sense, although some may also
appear as data fields, or “attributes”.
For example, if the ADT is STACK, we may choose as representation (step E2) the
solution called ARRAY_UP above, which implements any stack by a pair
<representation, count> where representation is an array and count an integer. For
the function implementations (E3) we will have features corresponding to put,
remove, item, empty and new, which achieve the corresponding effects; for example
we may implement put by a routine of the form
30

The role of deferred classes
For an effective class, all of the implementation information (E2, E3 above) must be
present. If any of it is missing, the class is deferred. The more deferred a class, the
closer it is to an ADT.
Abstract data types and information hiding
The ADT view of a module under information hiding is shown below. If the module
is a class coming from an ADT as outlined above, the answer is clear: of the three
parts involved in the transition, E1, the ADT specification, is public; E2 and E3, the
choice of representation and the implementation of the ADT functions in terms of
this representation, should be secret.
Fig. 5. 6 ADT view of a module
31

5. 3 Class Responsibility Collaborator (CRC)
model
For completeness it is necessary to mention an idea that is sometimes quoted as a
technique to find classes.
CRC cards (Class, Responsibility, Collaboration) are paper cards, 4 inches by 6 inches
(10.16 centimeters by 15.24 centimeters), on which designers discuss potential
classes in terms of their responsibilities and how they communicate.
The idea has the advantage of being easy on the equipment budget (a box of cards
is typically cheaper than a workstation with CASE tools) and of fostering team
interaction. Its technical contribution to the design process — to helping sort out and
characterize valuable abstractions. A CRC card is a standard index card that has
been divided into three sections.
Fig. 5. 7 CRC Model
A class represents a collection of similar objects. An object is a person, place, thing,
event, concept, screen, or report that is relevant to the system at hand.
Figure 5.8 shows a shipping/inventory control system with the classes such as
Inventory Item, Order, Order Item, Customer, and Surface Address. The name of the
class appears across the top of the card. A responsibility is anything that a class
knows or does. For example, customers have names, customer numbers, and phone
numbers. These are the things that a customer knows. Customers also order
products, cancel orders, and make payments.
32

These are the things that a customer does. The things that a class knows and does
constitute its responsibilities. Responsibilities are shown on the left hand column of a
CRC card. Sometimes a class will have a responsibility to fulfill, but will not have
enough information to do it. When this happens it has to collaborate with other
classes to get the job done. For example, an Order object has the responsibility to
calculate it’s total. Although it knows about the Order Item objects that are a part of
the order, it doesn’t know how many items were ordered (Order Item knows this)
nor does it know the price of the item (Inventory Item knows this).
Fig. 5. 8 A CRC Model for a simple shipping/inventory control system
To calculate the order total, the Order object collaborates with each Order Item
object to calculate its own total, and then adds up all the totals to calculate the
overall total. For each Order Item to calculate its individual total, it has to collaborate
with Inventory Item to determine the cost of the ordered item, multiplying it by the
number ordered (which it does know). The collaborators of a class are shown in the
right-hand column of a CRC card. Cards that collaborate with one another are close
to each other, cards that don’t collaborate are not near each other.
33

5.5 Quality of design
34
Design creates a representation or model of the software, the design model provides
detail about software architecture, data structures, interfaces, and components that
are necessary to implement the system.
Software design sits at the technical kernel of software engineering and is applied
regardless of the software process model that is used. Beginning once software
requirements have been analyzed and specified, software design is the first of three
technical activities—design, code generation, and test—that are required to build
and verify the software. Each activity transforms information in a manner that
ultimately results in validated computer software.
The importance of software design can be stated with a single word—quality. Design
is the place where quality is fostered in software engineering. Design provides us
with representations of software that can be assessed for quality. Design is the only
way that we can accurately translate a customer's requirements into a finished
software product or system. Software design serves as the foundation for all the
software engineering and software support steps that follow..
THE DESIGN PROCESS
Software design is an iterative process through which requirements are translated
into a “blueprint” for constructing the software. Throughout the design process, the
quality of the evolving design is assessed with a series of formal technical
reviews or design walkthroughs.
Reviews for measuring design and associated documentation
During a review, several people examine the software and its associated
documentation, looking for potential problems and nonconformance with standards.
The review team makes informed judgments about the level of quality of the
software or project documents. Project managers may then use these assessments
to make planning decisions and allocate resources to the development process.
Quality reviews are based on documents that have been produced during the
software development process. As well as software specifications, designs, code,
process models, test plans, configuration management procedures, process
standards, and user manuals may all be reviewed.

5.5 Quality of design & design measurements
35
The review should check the consistency and completeness of the documents or
code under review and, if standards have been defined, make sure that these
quality standards have been followed.
Reviews are not just about checking conformance to standards. They are also used
to help discover problems and omissions in the software or project documentation.
The conclusions of the review should be formally recorded as part of the quality
management process. If problems have been discovered, the reviewers’ comments
should be passed to the author of the software or whoever is responsible for
correcting errors or omissions. The purpose of reviews and inspections is to improve
software quality, not to assess the performance of people in the development team.
Reviewing is a public process of error detection, compared with the more private
component-testing process. Inevitably, mistakes that are made by individuals are
revealed to the whole programming team. To ensure that all developers engage
constructively with the review process, project managers have to be sensitive to
individual concerns. They must develop a working culture that provides support
without blame when errors are discovered.
Progress reviews compare the actual progress in a software project against the
planned progress. Their prime concern is whether or not the project will deliver
useful software on time and on budget.
Design Walkthrough
A "walkthrough" is a review of a product/system by peers: the participants,
who are approximately at the same level in the organization, meet to review
and discuss systematically a piece of software. Here, we study a software
design from the perspective of the user. The "Structured Walkthrough"s
(Yourdon, 1979) have been proven to be one of the most effective methods
to obtain feedback and improve the quality of software. The rules are very
simple but very important: the groups must be small (3 to 7 persons),

group members must be of the same level, the presenter must prepare work
in advance, everyone must be on time, and the session should be limited to
one hour maximum. The purpose of the walkthrough is to identify as many
problems as possible, not to discuss possible solutions . Critiques must be as
positive as possible and should be limited to the part presented by the
presenter.
36
a specific role for each walkthrough.
be presented Presents it to the group
Roles: Each group member has
Presenter: Selects that which must
Scribe: Takes note of the comments.
Coordinator: Ensures that the discussion is concentrated on the software
Ensures that the session lasts exactly x minutes (max 1 hour).
Guardian of standards: Asks questions based on the specifications of the
project.
Preparation: Make several copies of your scenario (one for each member
of your group, plus one copy to cut if you reuse text).
Procedure: The presenter acknowledges scenario and organizes screenshots
(or videos) that are necessary for a user to perform each step of the
scenario. The scribe notes the basic information on the attached page.
Result: Move so that everyone can see images of the presenter screen.
The presenter begins by describing the scenario quickly and present the first
image that the user sees. He or she shows what the user needs to do,
step by step, to execute the script. At each step, the examiners/participants
will ask questions and make constructive criticism of each screen or the
general usability of the software. Do not criticize the authors, focus on the
prototype. The scribe should make a list of design issues that were identified
and include them in the report. At the end, the group must decide if the
software is acceptable, or if it needs minor or major revisio

5.6 Design Measurements
37
To see how these measurements reveal information about the design, design
measurements can be based on three different characteristics:
(i) Relationships between classes (e.g., friendship, inheritance),
(ii) Types of interactions between classes (e.g., class–attribute interaction, class–
method interaction, method–method interaction), and
(iii) Due to design changes (i.e., whether a change flows toward or away from a
class). For each class in a design, they defined metrics that count the
interactions between the class and other classes or methods. Then, using
empirical information about the design for a real system and the resulting
system’s faults and failures, they analyzed the relationship between the type of
coupling and the kinds of faults that were found.
For example, they report that when a class depended on a large number of
attributes that belonged to other classes that were not ancestors, descendants, or
friends of that class, then the resulting code was more fault prone than usual.
Similarly, when many methods belonging to friend classes depended on the methods
of a particular class, then that class was more fault prone. In this way, design
information can be used to predict which parts of the software are most likely to be
problematic. We can take steps during the design stage to build in fault prevention
or fault tolerance, and we can focus more of our initial testing efforts on the most
fault-prone parts of the design.

5.7 concepts of design patterns
38
The concept of a pattern was first originated in the field of Architecture, where large
buildings are designed in specific pattern solutions. This concept has now been
absorbed in the area of object-oriented design to provide a very powerful
mechanism for design reuse.
Design patterns and their role in OOAD
While working out the design solution to a problem, experienced designers
consciously or unconsciously reuse solutions that they might have worked out in the
past. Such reuse of the design solutions is systematized by the concept of patterns.
In fact, patterns allow commonly accepted solutions to be reused by everybody
familiar with the patterns.
what are design patterns?
Design patterns are commonly accepted solutions to some problems that recur
during designing different applications.
Design patterns are nowadays being used extensively and have been found to make
the design process efficient. Use of patterns reduces the number of design
iterations, and at the same time improves the quality of the final design solution.
Basic Pattern Concepts
The basic idea behind patterns is that if you can master a few important patterns,
you can easily spot them in application development problems and effortlessly use
the pattern solutions.
Patterns can be viewed as helping designers to make certain important design
decisions. At a basic level, patterns can also be viewed as well-documented and well
thought-out building blocks for software design.

A pattern documentation usually consists of four important parts:
 The problem.
 The context in which the problem occurs.
 The solution.
 The context within which the solution would work and would not work.
Patterns versus algorithms
“Are patterns and algorithms identical concepts? After all, both target to provide
reusable solutions to problems!” In fact, patterns and algorithms are in some
respects similar since both attempt to provide reusable solutions. However,
algorithms primarily focus on solving problems with reduced space and/or time
requirements, whereas patterns focus on understandability and maintainability of
design and easier development.
39
to improve
Pros and cons of design patterns
The following are the main pros strengths of design patterns:
 Design patterns provide a common vocabulary that helps
communication among the developers.
 Design patterns help to capture and disseminate expert knowledge.
 Use of design patterns help designers to produce designs that are flexible,
efficient, and easily maintainable.
 Design patterns guide developers to arrive at correct design decisions and help
them to improve the quality of their designs.
 Design patterns reduce the number of design iterations, and help improve the
designer productivity.
Important cons shortcomings of design patterns are the following:
 Design patterns do not directly lead to code reuse. Since a design pattern is
tailored for a specific circumstance of reuse, and therefore it is difficult to

associate a fixed code segment with a pattern.
At present no methodology is available that can be used to select the right design
pattern at the right point during a design exercise.
Classification of Design Patterns
Design patterns vary in their granularity and level of abstraction. Because there are
many design patterns, we need a way to organize them. This section classifies
design patterns so that we can refer to families of related patterns. The
classification helps you learn the patterns in the catalog faster, and it can direct
efforts to find new patterns as well.
Design patterns are classified by two criteria. The first criterion, called purpose,
reflects what a pattern does. Patterns can have either creational, structural, or
behavioral purpose.
 Creational patterns concern the process of object creation.
 Structural patterns deal with the composition of classes or objects.
 Behavioral patterns characterize the ways in which classes or objects interact
and distribute responsibility.
The second criterion, called scope, specifies whether the pattern applies primarily to
classes or to objects. Class patterns deal with relationships between classes and
their subclasses. These relationships are established through inheritance, so they
are static— fixed at compile-time.
Object patterns deal with object relationships, which can be changed at run-time
and are more dynamic. Almost all patterns use inheritance to some extent. So the
only patterns labeled "class patterns" are those that focus on class relationships.
Note that most patterns are in the Object scope.
40

Design Pattern Space
Example
EXPERT PATTERN
Problem: When a certain activity needs to be performed, which class should be
made responsible for doing it?
Solution: Assign responsibility to the information expert—the class that has all (or
most of) the information necessary to fulfill the required responsibility.
The expert pattern expresses the common intuition that objects should do things
related to the information they store. The class and collaboration diagrams for the
solution to a problem as to which class should compute the total cost of a sale
transaction is shown in Figure 5.9.
Explanation: In the example given in Figure 5.9, a sale transaction consists of many
sale items. Each saleItem object is associated with an itemSpecification object. The
itemSpecification object among other things indicates the unit price for the item.
41

In this situation, which object should compute the total price for a sale transaction?
Let us consider the different options that are available. Should the saleTransaction
object, the saleItem object, or the itemSpecification object be given the
responsibility to compute the price of a sale transaction? If we assign the
responsibility to the saleItem object to compute the transaction price, then it would
need several information from the saleTransaction object such as the number of
items sold for various items and could also need the prices for the other items from
the corresponding itemSpecification objects for this computation.
Figure 5.9: Expert pattern: (a) Class diagram (b) Collaboration diagram
This would require a large number of data exchanges among the objects to occur,
and lead to a poor quality solution. Similarly, itemSpecification would be a poor
choice for computing the total cost payable for a sale transaction, since the object
lacks most of the information required to compute the total cost of the transaction.
It can easily be seen that the saleTransaction object has most of the information
required for the computation, and should be assigned the responsibility to compute
the total price. It is the information expert, as far as the exact items and quantities
sold are concerned.
42

5.8 Refactoring
43
An important design activity suggested for many agile methods, refactoring is a
reorganization technique that simplifies the design (or code) of a component without
changing its function or behavior.
“Refactoring is the process of changing a software system in such a way that it
does not alter the external behavior of the code [design] yet improves its internal
structure.”
When software is refactored, the existing design is examined for redundancy, un-
used design elements, inefficient or unnecessary algorithms, poorly constructed or
inappropriate data structures or any other design failure that can be corrected to
yield a better design.
For example, a first design iteration might yield a component that exhibits low
cohesion (i.e., it performs three functions that have only limited relationship to one
another). After careful consideration, you may decide that the component should be
refactored into three separate components, each exhibiting high cohesion.
Why Should You Refactor?
Refactoring Improves the Design of Software
Refactoring Makes Software Easier to Understand
Refactoring Helps You Find Bugs
Refactoring Helps You Program Faster
When Should You Refactor?
Refactor when You add new feature/function
Refactor When You Need to Fix a Bug
Refactor As You Do a Code Review
Problems with Refactoring
Databases
One problem area for refactoring is databases. Most business applications are tightly

coupled to the database schema that supports them. That's one reason that the
database is difficult to change. Another reason is data migration. Even if you have
carefully layered your system to minimize the dependencies between the database
schema and the object model, changing the database schema forces you to migrate
the data, which can be a long and fraught task.
9. object oriented construction principles (Refer Unit 1
of Object oriented programming)
10. object oriented metrics.
object-oriented metrics is specifying ones that provide meaningful measures to
support the analysis and design of software systems.
Metrics fall into one of two categories,
 process metrics
 product metrics.
Process metrics, sometimes called project metrics, assist the management team in
assessing progress with respect to the object-oriented development process being
used. Examples of process metrics include the number of person-hours expended,
the amount of work accomplished, and the number of project dollars spent—all
compared to what was planned.
Metrics more specific to object-oriented development.
Application size
– Number of scenario scripts (NSS)
– Number of key classes (NKC)
– Number of support classes (NSC)
– Number of subsystems (NOS)
44

Staffing size
– Person-days per class (PDC)
–Classes per developer (CPD)
Scheduling
– Number of major iterations (NMI)
– Number of contracts completed (NCC)
We tend to measure development progress by counting the classes in the logical
design, or the components in the physical design, that are completed and working.
Product metrics (sometimes called design metrics)
It helps the development team assess the artifacts of their analysis and design
efforts, rather than on process metrics.
Number of language-independent design metrics that are directly applicable to
object-oriented systems are.
 Weighted methods per class (WMC)
 Depth of inheritance tree (DIT)
 Number of children (NOC)
 Coupling between object classes (CBO)
 Response for a class (RFC)
 Lack of cohesion in methods (LCOM)
Weighted methods per class gives the sum of the complexities of each of the
methods of an individual class. If all the method complexities are considered to be
equally complex, this becomes a measure of the number of methods per class. In
general, a class with significantly more methods than its peers is more complex,
tends to be more application-specific, and often hosts a greater number of defects.
45

The depth of the inheritance tree and number of children are measures of the
shape and size of the class structure. Well-structured object-oriented systems tend
to be architected as forests of classes, rather than as one very large inheritance
tree. The depth of the inheritance tree, measured from the subject class to its
highest-level parent class, gives a measure of the impact to it from inheriting
functionality. Therefore, a deeper inheritance tree increases the complexity of a
class, due to the functionality it inherits.
Looking down the inheritance tree, we see the number of children for the subject
class. The more children a class has, the greater its impact on the software system’s
design, due to the reuse it produces.
Coupling between objects is a measure of their connectedness to other objects
and thus is a measure of their class’s encumbrance. As with traditional measures of
coupling, we seek to design loosely coupled objects, which have a greater potential
for reuse.
Response for a class is a measure of the methods that its instances can execute
in response to a message call. In general, a class that has significantly more
methods that can be invoked, compared with its peers, is more complex.
Lack of cohesion in methods is a measure of the unity of the class’s abstraction. A
class with low cohesion among its methods suggests an accidental or inappropriate
abstraction; such a class should generally be re-abstracted into more than one class
or its responsibilities delegated to other existing classes.
46

Part-B Questions
Q.
No.
Questions CO
Level
K Level
1
Discuss in detail about the various elements of object
model with example.
CO6 K2
2 Discuss in detail about the concepts of Hierarchy. CO6 K2
3 Explain the following minor elements of object model in
detail with an example. (i) Typing (ii) Concurrency (iii)
Persistence
CO6
K2
4 Discuss in detail about the concepts of abstract datatype
with a programming example?
CO6 K4
5
Discuss in detail about the classes responsibility
collaborator (CRC) model with an example?
CO6 K2
6
Explain in detail about the concepts of design pattern
and its various types?
CO6 K4
7
What are the various object-oriented construction
principles? Discuss in detail?
CO6 K2
8
Explain in detail about the object-oriented metrics? CO6 K3

Part-A Questions
Q.
No.
Questions CO
Level
K Level
1
What is object-oriented programming? CO6 K2
2
Mention the requirements to be followed for a language
is to be called as an object-oriented?
CO6 K2
3 Define object-oriented design?
CO6
K2
4 What are the five main kinds of programming style?
CO6
K2
5
Mention the minor elements of the object model? CO6 K2
6
What are the various kinds of abstraction? CO6 K2
7
Define Aggregation with an example? CO6 K2
8
Define Persistence? CO6 K2
9
What is meant by refactoring? CO6 K2
10
What are the various object oriented metrics? CO6 K2

PRESCRIBED TEXT BOOKS AND REFERENCE BOOKS
TEXT BOOKS:
1.Software Engineering, Ian Sommerville
Chrome-
extension://efaidnbmnnnibpcajpcglclefindmkaj/viewer.html?pdfurl=http%3A%2F%
2Findex-
of.co.uk%2FEngineering%2FSoftware%2520Engineering%2520(9th%2520Edition).
pdf&clen=14566720&chunk=true
2.Fundamentals of Software Engineering, Carlo Ghezzi, Jazayeri Mehdi, Mandrioli
Dino.
3.Software Requirements and Specification: A Lexicon of Practice, Principles
andPrejudices, Michael Jackson
REFERENCE BOOKS:
1. Software Metrics: A Rigorous and Practical Approach, Norman E Fenton,
Shari Lawrence Pfleeger
2. Software Engineering: Theory and Practice, Shari Lawrence Pfleeger and
Joanne M. Atlee
3. UML Distilled: A Brief Guide to the Standard Object Modeling Language --
Martin Fowler
4. Object-Oriented Software Construction, Bertrand Meyer
5. The Unified Development Process, Ivar Jacobson, Grady Booch, James
Rumbaugh
6. Design Patterns: Elements of Object-Oriented Reusable Software, Erich
Gamma, Richard Helm, Ralph Johnson, John Vlissides
49

Disclaimer:
This document is confidential and intended solely for the educational purpose of RMK Group of
Educational Institutions. If you have received this document through email in error, please notify the
system manager. This document contains proprietary information and is intended only to the
respective group / learning community as intended. If you are not the addressee you should not
disseminate, distribute or copy through e-mail. Please notify the sender immediately by e-mail if you
have received this document by mistake and delete this document from your system. If you are not
the intended recipient you are notified that disclosing, copying, distributing or taking any action in
relianceon thecontentsof this informationisstrictly prohibited.
Thankyou

20CB304 - SE - UNIT V - Digital Notes.pptx

More Related Content

What's hot

Similar to 20CB304 - SE - UNIT V - Digital Notes.pptx

Recently uploaded

20CB304 - SE - UNIT V - Digital Notes.pptx