CS504 Final term

Lec No. 20:

1. Interaction Diagrams:
A series of diagrams can be used to describe the dynamic behavior of an object-oriented system.
The purpose of Interaction diagrams is to:
 Model interactions between objects
 Assist in understanding how a system actually works
 Verify that a use case description can be supported by the existing classes
 Identify responsibilities/operations and assign them to classes.

Unified modeling UML provides two different mechanisms to document the dynamic behavior of the system.
language These are sequence diagrams which provide a time-based view and Collaboration Diagrams
which provide an organization-based view of the system’s dynamics.

2. Sequence diagram:A sequence diagram is a visual representation showing how objects interact
with each other in a specific order over time, illustrating the sequence of messages and events.
E.g:

The boxes denote objects (or classes), the solid lines depict messages being sent from one object to the
other in the direction of the arrow, and the dotted lines are called life-lines of objects.

The syntax used for naming objects in a sequence diagram is as follows:

 Syntax: [instanceName][:className]
 Name classes consistently with your class diagram (same classes).
 Label objects in messages or when duplicates exist.

MCQs: The time required by the receiver object to process the message is denoted by an activation-
box.

Lec No. 21:

1. Message Types:
Sequence diagrams can depict many different types of messages. These are: synchronous or
simple, asynchronous, create, and destroy. The following diagram shows the notation and types
of arrows used for these different message types.
 Synchronous Messages: Synchronous messages are “call events” and are denoted by the full
arrow.In case of a synchronous message, the caller waits for the called routine to complete its
operation before moving forward.
Asynchronous messages: Asynchronous messages are “signals,” denoted by a half arrow. They
do not block the caller. That is, the caller does not wait for the called routine to finish its
operation.Asynchronous messages typically perform the following actions:
 Create a new thread.
 Create a new object.
 Communicate with a thread that is already running.

Object Creation and Destruction: An object may create another object via a <create> message.
Similarly an object may destroy another object via a <destroy> message. An object may also
destroy itself. One should avoid modeling object destruction unless memory management is
critical. The following diagrams show object creation and destruction.

2. Collaboration diagrams:
Collaboration diagrams can also be used to depict the dynamic behavior of a system. They show
how objects interact with respect to organizational units. The sequence of messages determined
by numbering such as 1, 2, 3, 4,… This shows which operation calls which other
operation.Collaboration diagrams have basically two types of components: objects and
messages.Messages are numbered and can have loops.
3. Comparing sequence & collaboration diagrams:Sequence diagrams are best to see the flow of
time. On the other hand, static object connections are best represented by collaboration
diagrams. Sequence of messages is more difficult to understand in collaboration diagrams than
in the case of sequence diagrams. On the other hand, object organization with control flow is
best seen through collaboration diagrams. It may be noted that complex control is difficult to
express anyway but collaboration diagrams can become very complex very quickly.
4. Evaluating the Quality of an Object-Oriented Design:Only Reading
Judging the quality of a design is difficult. We can however look at certain object oriented design
attributes to estimate its quality.Consider a heat regulatory system for a room as shown below:
 In this case, the room is not encapsulated as one entity and three different objects namely
Desired Temp, Actual Temp, and Occupancy maintain necessary information about a room.
If we encapsulate the three objects into one Room object as shown below, thenthe overall
coupling of the system will be reduced.

We can improve the situation even further by delegating this responsibility to the Room object
as shown below.

Suppose we have two functions defined for setting the desired temperature in the room:
 SetMinimumValue(intaValue)
 SetMaximimumValue(intaValue)
We can reduce the total number of messages in the protocol of this class by consolidation these
as shown below, hence reducing the overall complexity of the protocol.
SetLimits(intminValue, intmaxValue)

Lec No. 22:

1. Software Architecture: According to IEEE Glossary:
Architectural design: The process of defining a collection of hardware and software components
and their interfaces to establish the framework for the development of a computer system.
2. Why is architecture important?
Fundamentally, there are three reasons:
 Mutual communication:Software architecture facilitates mutual understanding and
communication among stakeholders.
 Early design decisions:Software architecture represents initial design decisions guiding
development, deployment, and maintenance.
 Reusable abstraction of a system:Software architecture provides a reusable,
transferable model for structuring and integrating system components.
3. Architectural Attributes: Following are some of the architectural design guidelines:
 Performance: Keep modules independent.
 Security: Protect critical assets with layers.
  Safety: Separate critical parts.
 Availability: Duplicate key components.
 Maintainability: Use simple, self-contained parts.
4. Architectural design process:
 System structuring:System structuring divides a system into independent parts (sub-
systems and modules) that interact with each other.
 Control modelling: Control modelling establishes a model of the control relationships
between the different parts of the system.
 Modular decomposition: During this activity, the identified sub-systems are
decomposed into modules.

Lec No. 23:

1. Architectural Views:Software architecture defines the high level structure of the software. A
software architecture is a set of elements which have a certain form.These elements are chosen
to satisfy the functional as well as non-functional requirements of the system. Perry and Wolfe
proposed the following formula for software architecture:
Software architecture = {Elements, Forms, Rationale}
These elements are further divided into three categories. These are: data elements, processing
elements, and connecting elements. The data elements contain the information that is used and
transformed in the system; the processing elements process the data elements and specify the
transformation functions, and connecting elements connect different pieces of architecture
together. These can themselves be data or processing elements. This formula was modified by
Boehm as follows:
Software architecture = {Elements, Forms, Rationale/Constraints}
Krutchen proposedarchitectural model is known as Krutchen’s 4+1 architectural view model.
This model proposes the development of 5 main views namely the logical view, the process
view, the physical view, the development view, and the use case view.
 Logical View: Visual representation of software components and relationship.
 Process View: Shows concurrency, synchronization, and interactions between components.
 Physical View: Maps software components to hardware devices and infrastructure.
 Development View: Organizes code into modules, packages, and libraries.
 Use Case View: Validates architecture against specific user scenarios and requirements.
This model is shown in the following diagram:

This model has been slightly modified by Clements et. al. and is shown in the following diagram:
 Clement’s modified version of Krutchen’s 4+1 Architectural View Model. In this model, the
architecture is again prepared and analyzed from 5 different perspectives. The 4 main views are
Functional View, the Concurrency View, the Physical View, and the Development View. Code
view is not present in the original Krutchen model and is basically an extension of the
development view.

2. What Are Views Used For? Views are an engineering tool to help achieve desired system
qualities. Each view provides an engineering handle on certain quality attributes.
3. Hierarchical Views: Every view is potentially hierarchical, e.g. functional view could contain sub-
functions. Similarly development view contains directories which contain files. Code view would
have modules and systems that contain sub-modules and sub-systems respectively. Concurrency
view contains processes that are further subdivided into threads. Architectural views are related
to each other in complicated ways.
4. Architectural styles: The architectural model of a system may conform to a generic architectural
model or style.Each style describes a system category that encompasses:
 A set of components (e.g., a database, computational modules) that perform a function
required by a system.
 A set of connectors that enable “communication, coordination and cooperation” among
components.
 Constraints that define how components can be integrated to form the system, and
semantic models that enable a designer to understand the overall properties of a
system by analyzing the known properties of its constituent parts

Lec No. 24:

1. Architectural models: Like analysis models, many different kinds of architectural models are
developed during the architectural design process. Static structural model shows the major
system components while a dynamic process model shows the process structure of the system.
Interface models are developed to define sub-system interfaces.
2. Architectural Styles: Architectural design may be based upon a certain pattern of model.Among
the many styles, the most commonly practiced are the following:
 Data-centered architectures.
 Client Server Architecture and its variations.
 Layered architectures.
 Reference Architecture.
Data-centered or the repository model:In any system, sub-systems need to exchange
information and data. This may be done in two ways:
 Shared data is held in a central database or repository and may be accessed by all sub
systems.
 Each sub-system maintains its own database and passes data explicitly to other sub
systems.
Advantages: Client Software Repository model is an efficient way to share large amounts of
data. In this case sub-systems need not be concerned with how data is produced.
Disadvantages: Data evolution is difficult and expensive.It is also difficult to distribute
efficiently.
Client-server model:The client-server model is a distributed system model which shows how
data and processing is distributed across a range of components.
Client/Server Software Components: A typical client-server architecture based system is
composed of a number of different components.
 Handles user input/output.
 Application Subsystem: Implements application logic.
 Database Management: Manages data storage/retrieval.
 Middleware: Connects clients to servers.
Representative Client/Server Systems: Following are some of the representative server types in
a client-server systems.
 File Servers: Store and transmit files to clients.
 Database Servers: Process SQL queries and return results.
 Transaction Servers: Execute remote procedures and return results.
 Groupware Servers: Facilitate client communication and collaboration.
Advantage:The main advantage of the client-server architecture is that it makes effective
use of networked systems.
Disadvantage: The main disadvantage of this model is that there is no standard way of
sharing data, so sub-systems may use different data organization.

Lec No. 25:

1. Zero Install: The idea behind zero install architecture is to develop a system where no
installation on the client side is needed. This can only be done when there is no or little
processing done at the client side.
2. N-Tier architecture:Distributes data and applications across multiple servers for scalability
and performance.
3. Three-tier Architecture: In this architecture, each application architecture layers
(presentation, application, database) may run on separate processors.N-tier architecture
generalizes the concepts of 3-tier architecture. In this case the system architecture may
have more than 3 layers.
4. Data Flow or Pipes and Filters Architecture:This architecture is very similar to data flow
diagrams. This is used when the input data is processed through a series of transformations
to yield the desired output. It is also known as pipes and filters architecture where each
processing step is called a filter and the connecting link from one process to the other is
called the pipe through which the information flows from one process to the other. An
important aspect of this model is that each filter works independently of others.
If the dataflow has only a single sequence of processes with no alternative or parallel paths,
then it is called batch sequential.

5. Layered Architecture: A layered architecture has many different layers. One typical example
of a layered architecture is an operating system where different layers are used to provide
services and functionality and the inner layers are closer to the machine hardware than the
outer layers. In this way, each layer isolates the outer layer from inner complexities. In order
to work properly, the outer layer only needs to know the interface provided by the inner
layer. If there are any changes in the inner layer, as long as the interface does not change,
the outer layer is not affected. This scheme tremendously portability of the system.

6. Reference architectures: Reference architecture is not a physical architecture. It is only a

reference for defining protocols and designing and implementing systems developed by
different parties. Reference models are derived from a study of the application domain. It
may be used as a basis for system implementation or to compare different systems.
 Example of such a reference model is the OSI model which is a layered model for
communication systems.
7. Partitioning the Architecture: Partitioning of architecture is an important concept. What we
basically want to do is distribute the responsibilities to different subsystems so that we get a
software system which is easy to maintain. Partitioning results in a system that suffers from
fewer side effects.
Horizontal Partitioning: Separates modules by function.

Vertical Partitioning: Layers decision-making (top) and worker modules (bottom).This

partitioning is also known as factoring.

8. Analyzing Architecture design:The following sequence of steps provides a guideline for

performing architectural analysis.
 Collect scenarios.
 Elicit requirements, constraints, and environment description.
 Describe the architectural styles/patterns.
 Evaluate quality attributes by considered each attribute in isolation.
 Identify the sensitivity of quality attributes to various architectural attributes for a
specific architectural style.
Critique candidate architectures (developed in step 3) using the sensitivity analysis
conducted in step 5.

Lecture 26:
1. Design Patterns:

Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our
environment, and then describes the core of the solution to that problem, in such a way that you can
use this solution a million times over, without ever doing it the same way twice."

Design Patterns definition:

"Description of communicating objects and classes that are customized to solve a general design in a
particular context."

2. GOF Design Pattern Format:

The basic template includes ten things as described below:

 Name
 Problem
 Context
 Forces
 Solution
 Resulting context
 Rationale
 Related patterns
 Known uses
3. Classifications of deerns:

Creational patterns

 How to create and instantiate

 Class creational rules
 Object creational rules
 Abstract factory and factory method
 Abstract the instantiation process
 Make a system independent to its realization
 Class Creational use inheritance to vary the instantiated classes

Structural patterns

 Deals with object's structure

 Class structural patterns concern the aggregation of classes to form the largest classes.
 Object structural patterns concerns the aggregation of objects to form the largest Classes.
 Class Structural patterns concern the aggregation of classes to form largest structures.
 Object Structural pattern concern the aggregation of objects to form largest structures.

Behavioral patterns: Describe the patterns of communication between classes and objects

How objects are communicating with each other.

 Behavioral class patterns.

 Behavioral object patterns.
 Help in distributing object's intelligence
 Describe the patterns of communication between classes or objects
 Behavioral class pattern use inheritance to distribute behavior between classes

Lec No. 27:

1. Observer Pattern:
 Name
 Basic intent
 Motivation
  Description
 Consequences
 Subject
 Structure
 Participants
2. Singleton Pattern
 Intent
 It ensures that a class only has one instance and provides a global point of access to it.
 Applicability
 Singleton pattern should be used when there must be exactly one instance of a class and it
must be accessible to clients from a well-known access point.
 Structure:

 Participants
 Singleton
3. Facade Pattern:
 Intent
 It provides a unified interface to a set of interfaces in a sub-system.
 Façade defines a higher level interface that makes a subsystem easier to use
 Applicability
 You would use façade when you want to provide a simple interface to a complex sub-
system.
 You would use façade pattern when there are many dependencies between clients and
the implementation classes of an abstraction.
 You want to layer your subsystem.
 Structure

 Participants
 Façade
 Subsystem classes

Lec No. 28:

1. Maintainable Code: Fowler says, "Any fool can write code that computers can understand, good
programmer write code that humans can understand." The three basic principles that guide
maintainability are: simplicity, clarity, and generality or flexibility.
2. Self-documenting code: A self-documenting code is a code that explains itself without the need
of comments and extraneous documentation, like flowcharts, UML diagrams, process-flow state
diagrams, etc.
3. Function Size: The size of individual functions plays a significant role in making the program easy
or difficult to understand. In general, as the function becomes longer in size, it becomes more
difficult to understand. Ideally speaking, a function should not be larger than 20 lines of code
and in any case should not exceed one page in length.
4. How can we write code that is self-documenting?
There are a number of attributes that contributes towards making the program self
documented. These include, the size of each function, choice of variable and other identifier
names, style of writing expressions, structure of programming statements, comments,
modularity, and issues relating to performance and portability.
5. General naming conventions for Java and C++:
 Names representing types must be nouns and written in mixed case starting with upper case.
 Variable names must be in mixed case starting with lower case.
 Names representing constants must be all uppercase using underscore to separate words.
E.g: COLOR_RED
 Names representing methods and functions should be verbs and written in mixed case
starting with lower case. E.g: getName()
 Names representing template types in C++ should be a single uppercase letter.
 Global variables in C++ should always be referred to by using the :: operator. E.g:
::mainWindow.open().
 Private class variables should have _ suffix.
 Abbreviations and acronyms should not be uppercase when used as name.
 Generic variables should have the same name as their type.
 All names should be written in English.
 Variables with a large scope should have long names, variables with a small scope can have
short names.
 The name of the object is implicit, and should be avoided in a method name.
6. Specific Naming Conventions for Java and C++:
 The terms get/set must be used where an attribute is accessed directly. E.g:
employee.getName();
 is prefix should be used for boolean variables and methods.
 The term compute can be used in methods where something is computed. E.G:
valueSet.computeAverage();
 The term find can be used in methods where something is looked up. E.g:
matrix.findMinElement();
 The term initialize can be used where an object or a concept is established. E.g:
printer.initializeFontSet();
 List suffix can be used on names representing a list of objects.
 n prefix should be used for variables representing a number of objects. E.g: nPoints.
  No suffix should be used for variables representing an entity number.
 Iterator variables should be called i, j, k etc.
 Complement names must be used for complement entities.
 Abbreviations in names should be avoided.
 Negated boolean variable names must be avoided.
 Functions (methods returning an object) should be named after what they return and
procedures (void methods) after what they do.

Lec No. 29: IMP FOR MCQs

1. File handling tips for Java and C++:
 C++ header files should have the extension .h. Source files can have the extension .c++
(recommended), .C, .cc or .cpp.
 Classes should be declared in individual header files with the file name matching the class
name.
 Special characters like TAB and page break must be avoided.
 The incompleteness of split lines must be made obvious. In general:
 Break after a comma.
 Break after an operator.
 Align the newline with the beginning of the expression on the previous line.

E.g: totalSum = a + b + c +

d + e);

function (param1, param2,

param3);

2. Include Files and Include Statements for Java and C++: Header files must include a construction
that prevents multiple inclusion. The convention is an all uppercase construction of the module
name, the file name and the h suffix. The construction is to avoid compilation errors.

3. Classes and Interfaces Class and Interface declarations should be organized in the following
manner:
 Class/Interface documentation.
 class or interface statement.
 Class (static) variables in the order public, protected, package (no access modifier),
private.
 Instance variables in the order public, protected, package (no access modifier), private.
 Constructors.
 Methods (no specific order).
4. Statements in Java and C++:
  Type conversions must always be done explicitly. Never rely on implicit type conversion.
floatValue = (float) intValue; // NOT: floatValue = intValue;
 Types that are local to one file only can be declared inside that file.
 The parts of a class must be sorted public, protected and private.
5. Variables:
 Variables should be initialized where they are declared and they should be declared in
the smallest scope possible.
 Variables must never have dual meaning.
 Class variables should never be declared public.
 Related variables of the same type can be declared in a common statement. float x, y,z;
 Variables should be kept alive for as short a time as possible.
 Global variables should not be used. Variables should be declared only within scope of
their use.
 Implicit test for 0 should not be used other than for boolean variables and pointers.
if (nLines != 0) // NOT: if (nLines) if (value)
6. Loop structures:
Only loop control statements must be included in the for() construction.
Loop variables should be initialized immediately before the loop.
The use of do .... while loops should be avoided.
The use of break and continue in loops should be avoided. These statements should only be
used if they prove to give higher readability.
The form for (;;) should be used for empty loops.

7. Conditionals:
 Complex conditional expressions must be avoided.
 The nominal case should be put in the if-part and the exception in the else-part of an if
statement.
 The conditional should be put on a separate line.


 Executable statements in conditionals must be avoided.
8. Miscellaneous:
 The use of magic numbers in the code should be avoided. Numbers other than 0 and 1
should be considered declared as named constants instead.
 Floating point constants should always be written with decimal point and at least one
decimal. double total = 0.0; // NOT: double total = 0;
 Floating point constants should always be written with a digit before the decimal point.
double total = 0.5; // NOT: double total = .5;
 Functions in C++ must always have the return value explicitly listed.
 goto in C++ should not be used. Goto statements violates the idea of structured code.
Lec No. 30:
1. Comments: All comments should be written in English. In an international environment
English is the preferred language.Use // for all comments, including multi-line
comments.
2. Layout: Basic indentation should be 2.
for (i = 0; i < nElements; i++)
a[i] = 0;
3. Parenthesize to remove ambiguity: Parentheses should always be used as they reduce
complexity and clarify things by specifying grouping.
4. Breakup complex expressions: Complex expressions should be broken down into
multiple statements.

Lec No. 31:

1. Switch Statement: In the switch statement, cases should always end with a break.

2. Magic Numbers:

Unexplained numbers used in code

without clear meaning or context.

Can you tell by reading the code what is meant by the numbers 20, 27, 3, 21, 22, and 23.
These are constant that mean something but they do not give any indication of their
importance or derivation, making the program hard to understand and modify. To a reader
they work like magic and hence are called magic numbers.
3. Use (or abuse) of Zero: The number 0 is the most abused symbol in programs written in C or
C++.

Lec No. 32:

1. Clarity through modularity: Abstraction and encapsulation are two important tools that can
help in managing and mastering the complexity of a program. In general, as the function
 becomes longer in size, it becomes more difficult to understand. Modularity is a tool that can
help us in reducing the size of individual functions, making them more readable. Reusability is
one of the prime reasons to make functions but is not the only reason. Modularity is of equal
concern (if not more) and a function should be broken into smaller pieces, even if those pieces
are not reused.
2. Short circuiting || and &&: The logical and operator, &&, and logical or operators, ||, are
special due to the C/C++ short circuiting rule, i.e. a || b and a && b are short circuit evaluated.
That is, logical expressions are evaluated left to right and evaluation stops as soon as the final
truth value can be determined.
Short-circuiting is a very useful tool. It can be used where one boolean expression can be placed
first to “guard” a potentially unsafe operation in a second boolean expression.
3. Operand Evaluation Order and Side Effects: A side effect of a function occurs when the
function, besides returning a value, changes either one of its parameters or a variable declared
outside the function but is accessible to it.

Lec No. 33:

1. Common Coding mistakes: Following is short list of common mistakes made due to side-effects.
 array[i++] = i;
If i is initially 3, array[3] might be set to 3 or 4.
 array[i++] = array[i++] = x;
Due to side effects, multiple assignments become very dangerous. In this example, a
whole depends upon when i is incremented.
 “,” is very dangerous as it causes side effects. Let’s look at the following statement:
int i, j = 0;
Because of the syntax, many people would assume that i is also being initialized to 0,
while it is not. Combination of , and = -- is fatal. Look at the following statement:
a = b, c = 0;
A majority of the programmers would assume that all a, b, and c are being initialized to
0 while only c is initialized and a and b have garbage values in them. This kind of
overlook causes major programming errors which are not caught easily and are caused
only because there are side effects.

2. Guidelines: If the following guidelines are observed, one can avoid hazards caused by side
effects.
 Never use “,” except for declaration
 If you are initializing a variable at the time of declaration, do not declare another
variable in the same statement
 Never use multiple assignments in the same statement
 Be very careful when you use functions with side effects – functions that change the
values of the parameters.
 Try to avoid functions that change the value of some parameters and return some value
at the same time
3. Performance: When a small set (a couple of functions) of functions which use each other is so
overwhelmingly the bottleneck, there are two alternatives:
  Use a better algorithm
 Rewrite the whole set

Lec No. 34:

1. Portability: If a major rework is required to port a program written for one environment to
another, it will be probably not come at a low cost. Following is brief guideline that can help you
in writing portable code.
 Stick to the standard:
o Use ANSI/ISO standard C++.
o Instead of using vendor specific language extensions, use STL as much as possible.
 Program in the mainstream: Although C++ standard does not require function prototypes,
one should always write them.
 Size of data types: Sizes of data types cause major portability issues as they vary from one
machine to the other so one should be careful with them.
 Order of Evaluation: Order of evaluation varies from one implementation to other. This
therefore also causes portability issues.
 Signedness of char: The language does not specify whether char is signed or unsigned.
 Arithmetic or Logical Shift: The C/C++ language has not specified whether right shift >> is
arithmetic or logical. In the arithmetic shift sign bit is copied while the logical shift fills the
vacated bits with 0. This obviously reduces portability. Java has introduced a new operator
to handle this issue. >> is used for for arithmetic shift and >>> for logical shift.
 Alignment: The C/C++ language does not define the alignment of items within structures,
classes, and unions. Data may be aligned on word or byte boundaries.
2. Bit Fields: Bit fields allow the packing of data in a structure. This is especially useful when
memory or data storage is at a premium. Typical examples:
 Packing several objects into a machine word. e.g. 1 bit flags can be compacted - Symbol
tables in compilers.
 Reading external file formats -- non-standard file formats could be read in. E.g. 9 bit
integers.

Bit fields are a convenient way to express many difficult operations. However, bit fields do
suffer from a lack of portability between platforms:

 Integers may be signed or unsigned.

 Many compilers limit the maximum number of bits in the bit field to the size of an
integer which may be either 16-bit or 32-bit varieties.
 Some bit field members are stored left to right others are stored right to left in memory.
 If bit fields too large, next bit field may be stored consecutively in memory (overlapping
the boundary between memory locations) or in the next word of memory.

Bit fields therefore should not be used.

Lec No. 35:

1. Exception handling: Exception handling is a powerful technique that separates error-handling
code from normal code. It also provides a consistent error handling mechanism. The greatest
advantage of exception handling is its ability to handle asynchronous errors.
The raising of the imaginary error flag is simply called raising or throwing an error. When an
error is thrown the overall system responds by catching the error. Surrounding a block of error-
sensitive code with exception handling is called trying to execute a block. The following code
segment illustrates the general exception handling mechanism.

A function that leaves no side effects and cleans up

resources if an exceptionoccurs.
Exception-Safety: A function is exception safe if it might throw but do not have any side effects
if it does throw and any objects being used, including temporaries, are exception safe and clean-
up there resources when destroyed.
Exception Neutral: A function is said to be exception neutral if it propagates all exceptions to
the caller.
Levels of Exception Safety:
 Basic Guarantee: Ensures that temporaries are destroyed properly and there are no
memory leaks.
 Strong Guarantee: Ensures basic guarantee as well as there is full-commit or roll back.
 No-throw Guarantee: Ensure that a function will not throw.

Exception-safety requires either no-throw guarantee or basic and strong guarantee.

Does the function satisfy basic guarantee? Yes. Since the function does not create any objects,
in the presence of an exception, it does not leak any resources.
Does the function satisfy strong guarantee? No. The strong guarantee says that if the function
fails because of an exception, the program state must not be change. This function has two
distinct side-effects:

 An overpaid message is emitted to cout.

 A name strings is returned.
Does the function satisfy no-throw guarantee? No. This is clearly not true as lots of operations
in the function might throw.
Strong Guarantee: To meet strong guarantee, either both side-effects are completed or an
exception is thrown and neither effect is performed.
2. Exception Safety and Multiple Side-effects: It is difficult and some-times impossible to provide
strong exception safety when there are two or more side-effects in one function and these side-
effects are not related with each other. When such a situation comes with two or more
unrelated side-effects which cannot be combined then the best way to handle such a situation is
break it into two separate functions.
Lec No. 36:
1. Verification
Does the product meet system specifications?
Have you built the product right?
2. Validation
Does the product meet user expectations?
Have you built the right product?
It is possible that a software application may fulfill its specifications but it may deviate from
user's expectations or their desired behavior.
3. Software Testing: Software testing is the process of examining the software product against its
requirements. Thus it is a process that involves verification of product with respect to its written
requirements and conformance of requirements with user needs.
"A test is said to be successful if it discovers an error"
4. Defect: A defect is a variance from a desired product attribute. These attributes may involve
system specifications well as user expectation.
5. Development: Development is a constructive activity. Objective of development is to show that
the program works.
6. Testing: Testing is a destructive activity. Objective of testing is to show that the program does
not work.
7. Analysis of the code: It passes all the designated tests but fails for two different strings of same
length ending with the same character. For example, “cut” and “rat” would results in true which
is not correct.

Lec No. 37:

1. Description of testing phases: V IMP
 Unit testing - testing individual components independent of other components.
 Module testing - testing a collection of dependent components - a module encapsulates
related components so it can be tested independently.
 Subsystem testing - testing of collection of modules to discover interfacing problems
among interacting modules.
 System testing - after integrating subsystems into a system - testing this system as a
whole.
 Acceptance test - validation against user expectations. Usually it is done at the client
premises.
 Alpha testing - acceptance testing for customized projects, in-house testing for
products.
 Beta testing - field testing of product with potential customers who agree to use it and
report problem before system is released for general use.
2. Black box testing: V IMP
In this type of testing, a component or system is treated as a black box and it is tested for the
required behavior. This type of testing is not concerned with how the inputs are transformed
into outputs.
As the system's internal implementation details are not visible to the tester. If the outputs
match with the expected results, system is fine otherwise a defect is found.
 3. Structural testing (white box): V IMP
As opposed to black box testing, in structural or white box testing we look inside the system and
evaluate what it consists of and how is it implemented. The inner of a system consists of design,
structure of code and its documentation etc. Therefore, in white box testing we analyze these
internal structures of the program and devise test cases that can test these structures.

Lec No. 38:

1. Equivalence Classes or Equivalence Partitioning: Two tests are considered to be equivalent if it
is believed that:
 If one discovers a defect, the other probably will too, and
 If one does not discover a defect, the other probably won't either.
2. Equivalence partitioning guidelines
 Organize your equivalence classes. Write them in some order, use some template,
sequence, or group them based on their similarities or distinctions.
 Boundary conditions: determine boundary conditions.
 You should not forget invalid inputs that a user can give to a system.
3. Basis Code Structures: For structural testing it is important to know about basic coding
structures. There are four basic coding structures sequence, if statement, case statement, and
while loop. These four basic structures can be used to express any type of code.
 Sequence: Sequence depicts programming instructions that do not have branching or any
control information.

 If: Second structural form is the If statement. In the following graph, the first node at the
left depicts the if statement and the two nodes next to the first node correspond to the
successful case (if condition is true) and unsuccessful case (if condition is false)
consecutively.

 Case: In Case statement, control can take either of several branches (as opposed to only
two in If statement.) First node represents the switch statement (C/C++) and nodes in
middle correspond to all different cases.

 While: A while loop structure consists of a loop guard instruction through which the
iteration in the loop is controlled. The control keeps iterating in the loop as long as the loop
guard condition is true.
Lec No. 39:
1. White box coverage schemes:
 Statement Coverage: In this scheme, statements of the code are tested for a successful
test that checks all the statements lying on the path of a successful scenario.
 Branch Coverage: In this scheme, all the possible branches of decision structures are
tested. Therefore, sequences of statements following a decision are tested.
 Path Coverage: In path coverage, all possible paths of a program from input instruction to
the output instruction are tested.

Lec No. 40:

1. Unit testing: A software program is made up of units that include procedures, functions, classes
etc. Unit testing is done to each module, in isolation, to verify its behavior.
2. Unit Testing Principles:
 In unit testing, developers test their own code units (modules, classes, ete.) during
implementation.
 Normal and boundary inputs against expected results are tested.
 Thus unit testing is a great way to test an API.
3. Quantitative Benefits:
 Repeatable
 Bounded
4. Cheaper
 Qualitative Benefits:
 Assessment-oriented
 Confidence-building
5. Defect Origination: Following are the points in a development life cycle where defects enter
into the program.
 Requirements
 Design
 Coding
 User documentation
 Testing itself can cause defects due to bad fixes
 Change requests at the maintenance or initial usage time

Lec No. 41:

1. Inspection versus Testing: Inspections and testing are complementary and not opposing
verification techniques.
Both should be used during the verification and validation process. Inspection does not require
execution of program and they may be used before implementation. Many different defects
may be discovered in a single inspection. In testing, one defect may mask another so several
executions are required. For inspections, checklists are prepared that contain information
regarding defects. Inspections involve people examining the source representation with the aim
of discovering anomalies and defects.
 Thus inspections are a very effective technique for discovering errors in a software program.
Inspection Checklist: Following is an example of an inspection checklist.

Static analyzers: Static analyzers are software tools for source text processing. They parse the
program text and try to discover potentially erroneous conditions and bring these to the
attention of the verification and validation team. These tools are very effective as an aid to
inspections. But these are supplement to but not a replacement for inspections.
Checklist for static analysis: Tools that analyze
source code to
identify potential
errors, aiding
inspections but
notreplacingthem.

Lec No. 42:

1. What is a Bug? We call them by many names: software defects, software bugs, software
problems, and even software "features. " Software bugs range from program crashes to
returning incorrect information to having garbled displays.
2. Debugging: Finding problems, errors, defects and correct them.

Lec No. 43:

1. Memory and resource leak: A memory leak bug is one in which memory is somehow allocated
from either the operating system or an internal memory "pool", but never deallocated when the
memory is finished being used.
Symptoms:
 System slowdowns
  Crashes that occur "randomly" over a long period of time.
2. Logical Errors: A logical error occurs when the code is syntactically correct but does not do what
you expect it to do.

Symptoms

 The code is misbehaving in a way that isn't easily explained.

 The program doesn't crash, but the flow of the program takes odd branches through the
code.
 Results are the opposite of what is expected.
 Output looks strange, but has no obvious symptoms of corruption.
3. Coding Errors: A coding error is a simple problem in writing the code. Another form of a coding
error is incorrect parameter passing and invalid return type coercion.
Symptoms
 Unexpected errors in black box testing.
 The errors that unexpectedly occur are usually caused by coding errors.
 Compiler warnings.
 Coding errors are usually caused by lack of attention to details
4. Memory Over-run: A memory overrun occurs when you use memory that does not belong to
you. This can be caused by overstepping an array boundary or by copying a string that is too big
for the block of memory it is defined to hold. Memory overruns were once extremely common
in the programming world because of the inability to tell what the actual size of something
really was.
Symptoms
 Program crashes quite regularly after a given routine is called, that routine should be
examined for a possible overrun condition.
 If the routine in question does not appear to have any such problem the most likely
cause is that another routine, called in the prior sequence, has already trashed variables
or memory blocks.
 Checking the trace log of the called routines leading up to one with the problem will
often show up the error.
5. Loop Errors: Loop errors break down into several different subtypes. They occur around a loop
construct in a program. Infinite loops, off-by-one loops, and improperly exited loops.
Symptoms:
 If your program simply locks up, repeatedly displays the same data over and over, or
infinitely displays the same message box, you should immediately suspect an infinite
loop error.
 Off-by-one loop errors are quite often seen in processes that perform calculations.
 If a hand calculation shows that the total or final sum is incorrect by the last data point,
you can quickly surmise that an off-by-one loop error is to blame.
 Likewise, if you were using graphics software and saw all of the points on the screen,
but the last two were unconnected, you would suspect an off-by-one error.
6. Pointer errors: A pointer error is any case where something is being used as an indirect pointer
to another item.
 Uninitialized pointers: These are pointers that are used to point at something, but we fail to
ever assign them something to point at.
Deleted pointers, which continue to be used.
An Invalid pointer is something that is pointing to a valid block of memory, but that memory
does not contain the data you expect it to.
Symptoms:
 The program usually crashes or behaves in an unpredictable and baffling way.
 You will generally observe stack corruptions, failure to allocate memory, and odd
changing of variable values.
 Changing a single line of code can change where the problem occurs.
 If the problem "goes away" when you place a print statement or new variable into the
code that you suspect contains the problem.
7. Boolean bugs: Boolean bugs occur because the mathematical precision of Boolean algebra has
virtually nothing to do with equivalent English words. When we say "and", we really mean the
boolean "or" and vice versa. Errors in software code caused by incorrect or misunderstood
Symptoms: Boolean logic, such as true/false values or conditionalstatements.
 When the program does exactly the opposite of what you expect it to. For example, you
might have thought you needed to select only one entry from a list
 In order to proceed. Instead, the program will not continue until you select more than
one. Worse, it keeps telling you to select only one value.

Lec no. 44:

1. Holistic approach: Holistic means
 Emphasizing the importance of the whole and the interdependence of its parts.
 Concerned with wholes rather than analysis or separation into parts.
2. Get A Stack Trace: In the debugging process a stack trace is a very useful tool. Following stack
trace information may help in debugging process.
 Source line numbers in stack trace is the single, most useful piece of debugging
information.
 After that, values of arguments are important
 Debuggers can be used to display values of local or global variables.