CS504 Quiz 3 2022 and One
CS504 Quiz 3 2022 and One
MOAZ,JUNAID FILES
Final term preparation 2022
ORANGE MONKEY TEAM
Structure….confirm
3. A self documenting code is a code that explains itself without the need of comments
and extraneous documentation like _____.
Software Engineering – 1
(CS504)
Lecture Notes
Delivered by
Dr. Fakhar Lodhi
Lecture 29: File Handling Tips for C++ and Java ......................................................... 155
Lecture 30: Layouts and Comments in Java and C++… ............................................... 162
2
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 23
8.6 Architectural Views
Software architecture defines the high level structure of the software by putting together a
number of architectural elements in an organized fashion. 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:
That is, a software architecture is a set of elements which have a certain form. 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.
Krutchen proposed that the software architecture model should be composed of multiple
views as a software architecture deals with abstraction, with decomposition and
composition, with style and esthetics as well as requirements from different stake holders.
His architectural model is known as Krutchen’s 4+1 architectural view model. As
evident, 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. The
logical view is the object model of the design, the process view captures the concurrency
and synchronization aspects of the design, the physical view documents the mapping(s)
of the software onto the hardware and reflects its distributed aspect, the development
view describes the static organization of the software in its development environment,
and the use case view uses selected use cases or scenarios to validate that the architecture
supports the required functionality.
This model is shown in the following diagram.
Logical Implementation
View View
End-user
End- Programmers
user
Functionali
Functional Software
ity
ty Use e management
Cas View
Throughput
Process View
System
integrators
Performan
Performance
ce
Scalability
Throughp
ut
122
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Deployment View
S
y
s
t
e
m
e
n
g
i
n
e
e
r
i
n
g
S
y
s
t
e
m
t
o
p
o
l
o
g
y
D
e
l
i
v
e
r
y
,
i
n
s
t
a
l
l
a
t
i
o
n
C
o
m
m
u
n
i
c
a
t
i
o
n
123
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
This model has been slightly modified by Clements et. al. and is shown in the following
diagram.
Functional Develop-
Code
ment
Scenarios
Concurrency Physical
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.
The Functional View comprises of various different functions provided by the system,
key system abstraction, and the domain elements. It connects different dependencies and
data flows into a single view. This view can be used by the domain engineers, product-
line engineers, as well as the end users of the system. It can be used for understanding the
functionality provided by the system, modifiability of the system, reusability, tool
support, and allocation of work.
The Development View documents the different files and directories in the system and
users of this view include the development and the configuration management staff as
well as the project managers. The major uses of this view include maintenance, testing,
configuration management, and version control.
The components of the Code View include classes, objects, procedures, functions,
subsystems, layers, and modules. It documents the calling as well as the containing
hierarchy of different components of the system. Its primary users are the programmers
and designers of the system. The primary intent of developing this view is to use it for
maintenance and portability.
124
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Concurrency View intends to document different parallel processes and threads in the
system. Its main focus is on event synchronization and parallel data flows. It is used
primarily by integrators, performance engineers, and testers. The main purpose of
building this view is to identify ways and means to improve performance by highlighting
possible opportunities for parallelism.
The Physical View depicts the physical organization of this system and how this system
will be physically deployed. This includes different processors, sensors, and storage
devices used by the system. This view connects various network elements and
communication devices. The primary users of this system include hardware and system
engineers. The view is developed with an intention to document and analyze system
delivery and installation mechanism. The view is also used in understanding and
analyzing issues pertaining to system performance, availability, scalability, and security.
Finally, there are Scenarios. Scenarios are basically use cases which describe the
sequences of responsibilities and change cases which are changes to the system. As stated
earlier, the first objective of developing a system is to fulfill the functional requirements
setout for the system. These functional requirements are written in the form of use cases.
Therefore, scenarios are used to understand and validate the system. Their secondary
purpose is to communicate the design to the other users of the system. Scenarios tie all
the view together into an integrated system. They are also used to understand the
dynamic behavior of the system and understand the limits of design.
125
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Views are an engineering tool to help achieve desired system qualities. Each view
provides an engineering handle on certain quality attributes. In some systems, distinct
views collapse into one (e.g., the concurrency and physical views may be the same for
small systems.). Views are also used as documentation vehicle for current development
and future development. Users of views include both managers and customers. For these
reasons views must be annotated to support analysis. This annotation can be achieved
with the help of scenarios and design rationale.
Structures can also be used to document how the current system was developed and how
future development should occur. This information is needed by managers and
customers.
Although one often thinks about a system’s structure in terms of functionality, there are
other system properties in addition to functionality (such as physical distribution, process
communication, and synchronization) that must be reasoned about at an architectural
level. Each structure provides a method for reasoning about some of the relevant quality
attributes. The uses structure, for instance, must be engineered (not merely recorded) to
build a system that can easily be extended or contracted. The calls structure is engineered
to reduce bottlenecks. The module structure is engineered to produce modifiable systems,
and so on. Each structure provides a different view into the system and a different
leverage point for design to achieve desired qualities in the system.
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. Finally,
physical view clusters contain computers which contain processors.
Architectural views are related to each other in complicated ways. One has to choose the
views that are useful to the system being built and to the achievement of qualities that are
important for that particular application. The architectural views should be hierarchical
(where needed) and should contain enough annotated information to support desired
analyses.
Architectural styles
126
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
(1) a set of components (e.g., a database, computational modules) that perform a function
required by a system,
(2) a set of connectors that enable “communication, coordination and cooperation”
among components,
(3) 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.
Lecture No. 24
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.
Architectural Styles
Architectural design may be based upon a certain pattern of model. These different
patterns are also called architectural styles. These styles have different characteristics and
attributes and can be useful to solve problems related to a particular situation of
requirement. Among the many styles, the most commonly practiced are the following:
⚫ Data-centered architectures
⚫ Client Server Architecture and its variations
⚫ Layered architectures
⚫ Reference Architecture
In any system, sub-systems need to exchange information and data. This may be done in
two ways:
1. Shared data is held in a central database or repository and may be accessed by all sub-
systems
2. Each sub-system maintains its own database and passes data explicitly to other sub-
systems
127
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
When large amounts of data are to be shared, the repository model of sharing is most
commonly used. This model has been extensively used in the main-frame based
Client Client
Software Software
Client Client
Software Software
⚫ Advantages
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 Centralised
management e.g. backup, security, etc. This model also provides a global view of
the system and the sharing model is published as the repository schema.
⚫ Disadvantages
Client-server model
Client server model tries to distribute data and processing. This is a shift from main-
frame based applications where both the data management and the processing of data
used to be typically carried out by the same main-frame computer. In those applications,
the user interface used to be a provided through a “dumb” terminal which did not have
much processing power. With the availability of the cheaper but power machines, it was
possible to shift some load from the back-end computer to other smaller machines.
The client-server model is a distributed system model which shows how data and
processing is distributed across a range of components. In this model, the application is
modeled as a set of services that are provided by servers and a set of clients that use these
services. The system is organized as a set of stand-alone servers which provide specific
services such as printing, data management, etc. and a set of clients which call on these
128
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
services. These clients and servers are connected through a network which allows clients
to access servers. Clients and servers are logical processes (not always physical
machines). Clients know the servers but the servers do not need to know all the clients
and the mapping of processes to processors is not always 1:1.
C1 C2 Server
Client
C7 S1 S2 C3
S3 S4 C4
C6 C5
129
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Client-server characteristics
⚫ Advantages
The main advantage of the client-server architecture is that it makes effective
use of networked systems. Instead of building the system with very expensive
large computers and hardware devices, cheaper hardware may be used to gain
performance and scalability. In addition, adding new servers or upgrading
existing servers becomes easier. Finally, distribution of data is straightforward
in this case.
⚫ Disadvantages
The main disadvantage of this model is that there is no standard way of
sharing data, so sub-systems may use different data organisation. Hence data
interchange may be inefficient. From a management point of view, each
server needs attention and hence there is redundant management in each
server. Finally there is no central register of names and services - it may be
hard to find out what servers and services are available.
130
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
The client-server model can have many different configurations. In the following
sections, we look at some of these configurations.
This model was initially used to migrate legacy systems to client server architectures.
In this case the legacy system may act as a server in its own right and the GUI may be
implemented on a client. It chief disadvantage is that it places a heavy processing
load on both the server and the network.
With advent of cheaper and more powerful hardware, people thought of using the
processing power of client side machines. So the fat client model came into being. In
this model, more processing is delegated to the client as the application processing is
locally extended. It is suitable for new client/server systems when the client system
capabilities are known in advance. It however is more complex than thin client model
with respect to management issues. Since the client machine now also has a
significant part of the application resident on it, new versions of each application need
to be installed on every client .
Lecture No. 25
Zero Install
As discussed earlier, fat-client architecture posed major challenges in terms of
installation and maintenance of the client side of the application, especially when
there are large number of client machines. So 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. This is basically a
trade-off between using the computing power available at the client machine versus
maintenance overhead. This in essence takes us back to an architecture which is
similar to thin-client architecture. There is little difference though. In the classical
thin-client architecture, the entire processing is carried-out by a single server, in the
case of zero-install, the network environment is used to distribute server side
processing by adding a number of servers which share processing load. Web-based
application where the web-pages are put on a web-server is an example of this type of
architecture. In this case, whenever there is a change, the web page is updated
accordingly. Now when the user logs in, he gets to use the modified version of the
application without any changes or updates at the client side.
131
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
N-Tier architecture
N-tier architecture stems from the struggle to find a middle ground between the fat-
client architecture and the thin-client architecture. In this case the idea is to enhance
scalability and performance by distributing both the data and the application using
multiple server machines. This could involve different types of servers such as
application server, web server, and DB server. Three-tier architecture which is
explained below is a specialized form of this architecture.
Three-tier Architecture
Client
Client
N-tier architecture generalizes the concepts of 3-tier architecture. In this case the system
architecture may have more than 3 layers. That is, in n-tier architecture, in order to
increase performance, we may distribute the application over different servers by putting
different subsystems on different servers.
132
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
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 and does not require knowledge of the working
of any of the other filters including its neighbours.
If the dataflow has only a single sequence of processes with no alternative or parallel
paths, then it is called batch sequential. These models are depicted in the following
diagrams.
pipes
Filter2 Filter4 Filter5
Filter1
Batch Sequential
133
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Layered Architecture
As the name suggests, 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. The basic layered architecture is depicted in the following
diagram.
Application Layer
Utility Layer
Core Layer
134
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Reference architectures
7 Ap pl icat io n Ap pl icat io n
5 Ses si on Ses si on
4 Trans po rt Trans po rt
C o m mu nica t io ns m edium
135
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
In the horizontal partitioning we define separate branches of the module hierarchy for
each major function and control modules are used to coordinate communication
between functions. This concept is depicted in the following diagram.
Vertical partitioning divides the application from a decision making perspective. The
architecture is partitioned in horizontal layers so that decision making and work are
stratified with the decision making modules residing at the top of the hierarchy and
worker coming at the bottom. This partitioning is also known as factoring and the
general model is depicted in the following diagram.
136
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Top Partition
Decision Makers
Bottom Partition
Workers
In a given system, the required characteristics may conflict. Trade-offs seek optimal
combinations of properties based on cost/benefit analysis. So the analysis requires an
understanding of what is required and the relative priority of the attributes has to be
established. The following sequence of steps provides a guideline for performing
architectural analysis.
1. Collect scenarios.
2. Elicit requirements, constraints, and environment description.
3. Describe the architectural styles/patterns that have been chosen to address the
scenarios and requirements. These views include module view, process view, and
data flow view.
4. Evaluate quality attributes by considered each attribute in isolation.
5. Identify the sensitivity of quality attributes to various architectural attributes for a
specific architectural style.
137
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 26
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.” A Pattern Language: Towns/Buildings/Construction, 1977
Even though Alexander was talking about patterns in buildings and towns, what he says
is true about object-oriented design patterns. Our solutions are expressed in terms of
objects and interfaces instead of walls and doors, but the core of both kinds of patterns is
a solution to a problem in a context.
Patterns are devices that allow programs to share knowledge about their design. In our
daily programming, we encounter many problems that have occurred, and will occur
again. The question we must ask our self is how we are going to solve it this time.
Documenting patterns is one way that you can reuse and possibly share the information
that you have learned about how it is best to solve a specific program design problem.
Essay writing is usually done in a fairly well defined form, and so is documenting design
patterns. The general form for documenting patterns is to define items such as:
138
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
The pattern movement became very quiet until 1987 when patterns appeared again at an
OOPSLA conference. Since then, many papers and presentations have appeared,
authored by people such as Grady Booch, Richard Helm, and Erich Gamma, and Kent
Beck. From then until 1995, many periodicals, featured articles directly or indirectly
relating to patterns. In 1995, Erich Gamma, Richard Helm, Ralph Johnson, and John
Vlissides published Design Patterns: Elements of Reusable Object-Oriented Software
[Gamma95], which has been followed by more articles in trade journals.
The concept of design patterns is not new as we can find a number of similar pursuits in
the history of program designing and writing. For instance, Standard Template Library
(STL) is a library of reusable components provided by C++ compilers. Likewise, we use
algorithms in data structures that implement typical operations of manipulating data in
data structures. Another, similar effort was from Peter Coad whose patterns are known
for object-oriented analysis and design.
Anti-patterns is another concept that corresponds to common mistakes in analysis and
design. These are identified in order to prevent potential design and analysis defects from
entering into the design. Another, similar concept is object-oriented framework that is a
set of cooperative classes that make up reusable design of a system. Framework dictates
the architecture of the software and describes the limitations and boundaries of
architecture.
With this introduction, we now describe the format that has been adopted in GoF book
for describing various design patterns.
GOF Design Pattern Format
The basic template includes ten things as described below
Name
• Works as idiom
• Name has to be meaningful
Problem
• A statement of the problem which describes its intent
• The goals and objectives it wants to reach within the given context
Context
• Preconditions under which the problem and its solutions seem to occur
• Result or consequence
• State or configuration after the pattern has been applied
Forces
• Relevant forces and constraints and their interactions and conflicts.
• motivational scenario for the pattern.
Solution
• Static and dynamic relationships describing how to realize the pattern.
• Instructions on how to construct the work products.
139
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
• Pictures, diagrams, prose which highlight the pattern’s structure, participants, and
collaborations.
Examples
• One or more sample applications to illustrate
o a specific context
o how the pattern is applied
•
Resulting context
• the state or configuration after the pattern has been applied
• consequences (good and bad) of applying the pattern
Rationale
• justification of the steps or rules in the pattern
• how and why it resolves the forces to achieve the desired goals, principles, and
philosophies
• how are the forces orchestrated to achieve harmony
• how does the pattern actually work
Related patterns
• the static and dynamic relationships between this pattern and other patterns
Known uses
• to demonstrate that this is a proven solution to a recurring problem
Classifications of deerns
Creational patterns
• How to create and instantiate
• Abstract the instantiation process and make the system independent of its creational
process.
• 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
• Object Creational delegate instantiation to an another object
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
140
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 27
Observer Pattern
Name
• Observer
Basic intent
• It is intended to define a many to many relationship between objects so that when
one object changes state all its dependants are notified and updated automatically.
• Dependence/publish-subscribe mechanism in programming language
o Smalltalk being the first pure Object Oriented language in which observer
pattern was used in implementing its Model View Controller (MVC)
pattern. It was a publish-subscribe mechanism in which views (GUIs)
were linked with their models (containers of information) through
controller objects. Therefore, whenever underlying data changes in the
model objects, the controller would notify the view objects to refresh
themselves and vice versa.
o MVC pattern was based on the observer pattern.
Motivation
• It provides a common side effect of partitioning a system into a collection of
cooperating classes that are in the need to maintain consistency between related
objects.
Description
• This can be used when multiple displays of state are needed.
Consequences
Optimizations to enhance display performance are impractical.
141
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
D 50
A 25
C ABC D
B 0
Subject
A: 40
B: 25
Observer 1 C: 15 Observer 2
D: 20
Structure
Subject Observer
Attach(Observer)
Update()
Detach(Observer)
Notify() for all o in observers
o -> Update()
ConcreteSubject ConcreteObserver
observerState =
GetState() return SubjectState Update()
subject -> GetState()
SubjectState ObserverState
Participants
142
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Subject
• Knows its observers. Any number of Observer objects may observe a subject.
• Provides an interface for attaching and detaching Observer objects.
Observer
• Defines an updating interface for objects that should be notified of changes in a
subject.
ConcreteSubject
• Stores state of interest to concreteObserver objects.
• Sends a notification to its observers when its state changes.
ConcreteObserver
• Maintains a reference to a ConcreteSubject object.
• Stores state state that should stay consistent with the subject’s.
• Implements the Observer updating interface to keep its state consistent with the
subject’s.
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.
• Singleton pattern should be used when controlling the total number of instances
that would be created for a particular class.
• Singleton pattern should be used when the sole instance should be extensible by
sub classing and clients should be able to use an extended instance without
modifying their code.
Structure
Singleton
static instance() return uniqueInstance
SingletonOperation()
GetSingletonData()
static uniqueInstance
singletonData
Participants
Singleton
143
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
• Defines an instance operation that lets clients access its unique instance. Instance
is a class operation (that is, a class method in Smalltalk and a static member
function in C++).
• May be responsible for creating its own unique instance.
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
};
Singleton* Singleton::_instance = 0;
Singleton* Singleton::Instance(){
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
Clients access the singleton exclusively through the Instance member function. The
variable _instance is initialized to 0, and the static member function Instance returns its
value, initializing it with the unique instance if it is 0.
Façade 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 should introduce a façade to decouple the system from clients and other
subsystems.
• You want to layer your subsystem.
• You would use façade when you want to provide a simple interface to a complex
sub-system
144
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
• You would use façade pattern when there are many dependencies between clients
and the implementation classes of an abstraction
• You should introduce a façade to decouple the system from clients and other
subsystems
• You want to layer the subsystem
client classes
Facade
subsystem classes
Structure
145
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Facade
Participants
Façade
• Knows which subsystem classes are responsible for a request.
• Delegates client requests to appropriate subsystem objects.
Subsystem classes
• Implement subsystem functionality.
• Handle work assigned by the Façade object.
• Have no knowledge of the façade, that is, they keep no references to it.
146
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 28
Good Programming Practices and Guidelines
Maintainable Code
As we have discussed earlier, in most cases, maintainability is the most desirable quality
of a software artifact. Code is no exception. Good software ought to have code that is
easy to maintain. Fowler says, “Any fool can write code that computers can understand,
good programmers write code that humans can understand.” That is, it is not important
to write code that works, it is important to write code that works and is easy to understand
so that it can be maintained. The three basic principles that guide maintainability are:
simplicity, clarity, and generality or flexibility. The software will be easy to maintain if it
is easy to understand and easy to enhance. Simplicity and clarity help in making the code
easier to understand while flexibility facilitates easy enhancement to the software.
147
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
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.
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. From where did I get
this number 20 and one page? The number 20 is approximately the lines of code that fit
on a computer screen and one page of course refers to one printed page. The idea behind
these heuristics is that when one is reading a function, one should not need to go back and
forth from one screen to the other or from one page to the other and the entire context
should be present on one page or on one screen.
148
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Identifier Names
Identifier names also play a significant role in enhancing the readability of a program.
The names should be chosen in order to make them meaningful to the reader. In order to
understand the concept, let us look at the following statement.
In this particular case, the meanings of the condition in the if-statement are not clear and
we had to write a comment to explain it. This can be improved if, instead of using x, we
use a more meaningful name. Our new code becomes:
if (AllocFlag == 0)
The situation has improved a little bit but the semantics of the condition are still not very
clear as the meaning of 0 is not very clear. Now consider the following statement:
If (AllocFlag == NEW_NUMBER)
We have improved the quality of the code by replacing the number 0 with a named
constant NEW_NUMBER. Now, the semantics are clear and do not need any extra
comments, hence this piece of code is self-documenting.
149
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
This coding style guide emphasizes on C++ and Java but the concepts are applicable to
other languages as well.
Naming Conventions
Hungarian Notation was first discussed by Charles Simonyi of Microsoft. It is a variable
naming convention that includes information about the variable in its name (such as data
type, whether it is a reference variable or a constant variable, etc). Every company and
programmer seems to have their own flavor of Hungarian Notation. The advantage of
Hungarian notation is that by just looking at the variable name, one gets all the
information needed about that variable.
In our style guide, we will be using a naming convention where Hungarian Notation is
mixed with CamelCase.
150
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
1. Names representing types must be nouns and written in mixed case starting with
upper case.
Line, FilePrefix
151
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
11. Variables with a large scope should have long names, variables with a small scope
can have short names. Scratch variables used for temporary storage or indices are best
kept short. A programmer reading such variables should be able to assume that its
value is not used outside a few lines of code. Common scratch variables for integers
are i, j, k, m, n and for characters c and d.
12. The name of the object is implicit, and should be avoided in a method name.
line.getLength(); // NOT: line.getLineLength();
The latter seems natural in the class declaration, but proves superfluous in use.
152
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Using the is prefix solves a common problem of choosing bad boolean names like status
or flag. isStatus or isFlag simply doesn't fit, and the programmer is forced to chose more
meaningful names.
There are a few alternatives to the is prefix that fits better in some situations. These are
has, can and should prefixes:
boolean hasLicense();
boolean canEvaluate();
boolean shouldAbort = false;
Using this term will give the reader the immediate clue that this is a potential time
consuming operation, and if used repeatedly, he might consider caching the result.
4. The term find can be used in methods where something is looked up.
vertex.findNearestVertex(); matrix.findMinElement();
This gives the reader the immediate clue that this is a simple look up method with a
minimum of computations involved.
Simply using the plural form of the base class name for a list (matrixElement (one
matrix element), matrixElements (list of matrix elements)) should be avoided since the
two only differ in a single character and are thereby difficult to distinguish.
A list in this context is the compound data type that can be traversed backwards,
forwards, etc. (typically a Vector). A plain array is simpler. The suffix Array can be used
to denote an array of objects.
153
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
There are two types of words to consider. First are the common words listed in a
language dictionary. These must never be abbreviated. Never write:
cmd instead of command
cp instead of copy
pt instead of point
comp instead of compute
init instead of initialize
etc.
Then there are domain specific phrases that are more naturally known through their
acronym or abbreviations. These phrases should be kept abbreviated. Never write:
HypertextMarkupLanguage instead of html
CentralProcessingUnit instead of cpu
PriceEarningRatio instead of pe
etc.
154
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
The problem arise when the logical NOT operator is used and double negative arises. It is
not immediately apparent what !isNotError means.
13. Functions (methods returning an object) should be named after what they return and
procedures (void methods) after what they do. This increases readability. Makes it clear
what the unit should do and especially all the things it is not supposed to do. This again
makes it easier to keep the code clean of side effects. Naming pointers in C++
specifically should be clear and should represent the pointer type distinctly.
155
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 29
File handling tips for Java and C++
1. C++ header files should have the extension .h. Source files can have the extension
.c++ (recommended), .C, .cc or .cpp.
MyClass.c++, MyClass.h
2. Classes should be declared in individual header files with the file name matching the
class name. Secondary private classes can be declared as inner classes and reside in the
file of the class they belong to. All definitions should reside in source files.
class MyClass
{
public:
int getValue () {return value_;} // NO!
...
private:
int value_;
}
The header files should declare an interface, the source file should implement it. When
looking for an implementation, the programmer should always know that it is found in
the source file. The obvious exception to this rule is of course inline functions that must
be defined in the header file.
3. Special characters like TAB and page break must be avoided. These characters are
bound to cause problem for editors, printers, terminal emulators or debuggers when used
in a multi-programmer, multi-platform environment.
156
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
157
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
The construction is to avoid compilation errors. The construction should appear in the top
of the file (before the file header) so file parsing is aborted immediately and compilation
time is reduced.
158
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
1. Type conversions must always be done explicitly. Never rely on implicit type
conversion.
By this, the programmer indicates that he is aware of the different types involved and that
the mix is intentional.
2. Types that are local to one file only can be declared inside that file.
3. The parts of a class must be sorted public, protected and private. All sections must be
identified explicitly. Not applicable sections should be left out. The ordering is "most
public first" so people who only wish to use the class can stop reading when they
reach the protected/private sections.
Variables
1. Variables should be initialized where they are declared and they should be declared in
the smallest scope possible.
2. Variables must never have dual meaning. This enhances readability by ensuring all
concepts are represented uniquely. Reduce chance of error by side effects.
3. Class variables should never be declared public. The concept of information hiding
and encapsulation is violated by public variables. Use private variables and access
functions instead. One exception to this rule is when the class is essentially a data
structure, with no behavior (equivalent to a C++ struct). In this case it is appropriate
to make the class' instance variables public.
The common requirement of having declarations on separate lines is not useful in the
situations like the ones above. It enhances readability to group variables.
5. Variables should be kept alive for as short a time as possible. Keeping the operations
on a variable within a small scope, it is easier to control the effects and side effects of
the variable.
159
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
6. Global variables should not be used. Variables should be declared only within scope
of their use. Same is recommended for global functions or file scope variables. It is
easier to control the effects and side effects of the variables if used in limited scope.
7. Implicit test for 0 should not be used other than for boolean variables and pointers.
if (nLines != 0) // NOT: if (nLines)
if (value != 0.0) // NOT: if (value)
It is not necessarily defined by the compiler that ints and floats 0 are implemented as
binary 0. Also, by using explicit test the statement give immediate clue of the type being
tested. It is common also to suggest that pointers shouldn't test implicit for 0 either, i.e. if
(line == 0) instead of if (line). The latter is regarded as such a common practice in
C/C++ however that it can be used.
Loop structures
3. The use of do while loops should be avoided. There are two reasons for this. First
is that the construct is superflous; Any statement that can be written as a do while
loop can equally well be written as a while lopp or a for loop. Complexity is reduced
by minimizing the number of constructs being used. The other reason is of
readability. A loop with the conditional part at the end is more difficult to read than
one with the conditional at the top.
4. The use of break and continue in loops should be avoided. These statements should
only be used if they prove to give higher readability than their structured counterparts.
In general break should only be used in case statements and continue should be
avoided alltogether.
160
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
This form is better than the functionally equivalent while (true) since this implies a test
against true, which is neither necessary nor meaningful. The form while(true) should be
used for infinite loops.
Conditionals
2. The nominal case should be put in the if-part and the exception in the else-part of an
if statement.
boolean isError = readFile (fileName);
if (!isError) {
:
}
else {
:
}
161
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Miscellaneous
1. 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.
2. Floating point constants should always be written with decimal point and at least one
decimal.
double total = 0.0; // NOT: double total = 0;
double speed = 3.0e8; // NOT: double speed = 3e8;
double sum;
:
sum = (a + b) * 10.0;
This emphasizes the different nature of integer and floating point numbers even if their
values might happen to be the same in a specific case. Also, as in the last example above,
it emphasize the type of the assigned variable (sum) at a point in the code where this
might not be evident.
3. Floating point constants should always be written with a digit before the decimal
point.
double total = 0.5; // NOT: double total = .5;
The number and expression system in Java is borrowed from mathematics and one should
adhere to mathematical conventions for syntax wherever possible. Also, 0.5 is a lot more
readable than .5; There is no way it can be mixed with the integer 5.
4. Functions in C++ must always have the return value explicitly listed.
int getValue() // NOT: getValue()
{
:
}
If not explicitly listed, C++ implies int return value for functions.
5. goto in C++ should not be used. Goto statements violates the idea of structured code.
Only in some very few cases (for instance breaking out of deeply nested structures)
should goto be considered, and only if the alternative structured counterpart is proven
to be less readable .
162
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 30
Layout and Comments in Java and C++
Comments
The problem with comments is that they lie. Comments are not syntax checked, there is
nothing forcing them to be accurate. And so, as the code undergoes change during
schedule crunches, the comments become less and less accurate.
As Fowler puts it, comments should not be used as deodorants. Tricky code should not be
commented but rewritten. In general, the use of comments should be minimized by
making the code self-documenting by appropriate name choices and an explicit logical
structure.
If, however, there is a need to write comments for whatever reason, the following
guidelines should be observed.
Since multilevel commenting is not supported in C++ and Java, using // comments ensure
that it is always possible to comment out entire sections of a file using /* */ for
debugging purposes etc.
163
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Indentation of 1 is to small to emphasize the logical layout of the code. Indentation larger
than 4 makes deeply nested code difficult to read and increase the chance that the lines
must be split. Choosing between indentation of 2, 3 and 4, 2 and 4 are the more common,
and 2 chosen to reduce the chance of splitting code lines.
Expression should be written as if they are written as comments or spoken out aloud.
Conditional expression with negation are always difficult to understand. As an example
consider the following code:
The logic becomes much easier to follow if the code is written in the natural form as
shown below:
Parentheses should always be used as they reduce complexity and clarify things by
specifying grouping. It is especially important to use parentheses when different
unrelated operators are used in the same expression as the precedence rules are often
assumed by the programmers, resulting in logical errors that are very difficult to spot. As
an example consider the following statement:
This causes problems because == operator has higher precedence than & operator.
Hence, MASK and BITS are first compared for equality and then the result, which is 0 or
1, is andded with x. This kind of error will be extremely hard to catch. If, however,
parentheses are used, there will be no ambiguity as shown below.
164
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Following is another example of the use of parentheses which makes the code easier to
understand and hence easier to maintain.
In this case parentheses have not been used and therefore the definition of a leap year is
not very clear for the code. The code becomes self explanatory with the help of proper
use of parentheses as shown below:
leapYear = ((year % 4 == 0) && (year % 100 != 0)) ||
(year % 400 == 0);
This statement liberally uses a number of operators and hence is very difficult to follow
and understand. If it is broken down into simple set of statements, the logic becomes
easier to follow as shown below:
Sometimes the programmers, in their creative excitement, try to write very concise code
by using shortcuts and playing certain kinds of tricks. This results in a code which is
cryptic in nature and hence is difficult to follow. Maintenance of such code therefore
becomes a nightmare. Following are some examples of such code.
1. Let us start with a very simple shortcut, often used by programmers. Assume that we
have the following statement.
x *= a;
165
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
x *= a + b;
This seemingly harmless change is actually a little cryptic and causes confusion. The
problem lies with the semantics of this statement. Does it mean x = x*a+b or x =
x*(a+b)? The second one is the right answer but is not obvious from the syntax and
hence causes problems.
2. Let us now look at a more complex example. What is the following code doing?
As can be seen, it is pretty hard to understand and therefore difficult to debug in case
there is any problem. What this code is actually doing is masking bitoff with octal 7
and then use the result to shift subkey those many time. This can be written as
follows:
It is quite evident that the second piece of code is much follow to read than the first
one.
a = a >> 2;
It is easy to see that a is shifted right two times. However, the real semantics of this
code are hidden – the real intent here is to divide a by 4. No doubt that the code above
achieves this objective but it is hard for the reader to understand the intent as to why a
is being shifted right twice. It would have been much better had the code been written
as follows:
a = a/4;
4. A piece of code similar to the following can be found in many data structures books
and is part of circular implementation of queues using arrays.
bool Queue::add(int n)
{
int k = (rear+1) % MAX_SIZE;
if (front == k)
return false;
else {
rear = k;
queue[rear] = n;
return true;
}
}
166
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
bool Queue::isFull()
{
if (front == (rear+1 % MAX_SIZE))
return true;
else
return false;
}
This code uses the % operator to set the rear pointer to 0 once it has reached
MAX_SIZE. This is not obvious immediately. Similarly, the check for queue full is
also not trivial.
It is always much better to state the logic explicitly. Also, counting is also much
easier to understand and code as compared to some tricky comparisons (e.g. check for
isFull in this case). Application of both these principles resulted in the following
code. It is easy to see that this code is easier to understand. It is interesting to note that
when another group of students were asked to do implement double-ended queue
after showing them this code, almost everyone did it without any problems.
bool Queue::add()
{
if (! isFull() ) {
rear++;
if (rear == MAX_SIZE) rear = 0;
QueueArray[rear] = n;
size++;
return true;
}
else return false;
}
bool Queue::isFull(int n)
{
if (size == MAX_SIZE)
return true;
else
return false;
}
167
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 31
Coding Style Guidelines (Continued)
Switch Statement
In the switch statement, cases should always end with a break. A tricky sequence of fall-
through code like the one below causes more trouble than being helpful.
switch(c) {
case ‘-’ : sign = -1;
case ‘+’ : c = getchar();
case ‘.’ : break;
default : if (! isdigit(c))
return 0;
}
This code is cryptic and difficult to read. It is much better to explicitly write what is
happening, even at the cost of duplication.
switch(c) {
case ‘-’: sign = -1;
c = getchar();
break;
case ‘+’: c = getchar();
break;
case ‘.’: break;
default: if (! isdigit(c))
return 0;
break;
}
It would even be better if such code is written using the if statement as shown below.
if (c == ‘-’) {
sign = -1;
c = getchar();
}
else if (c == ‘+’) {
c = getchar();
}
else if (c != ‘.’ && !isdigit(c)) {
return 0;
}
168
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Magic Numbers
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. Any number (even 0 or
1) used in the code is a magic number. It should rather have a name of its own that can be
used in the program instead of the number.
The difference would be evident if we look at the code segment below that achieves the
same purpose as the code above.
enum {
MINROW = 1,
MINCOL = 1,
MAXROW = 24,
MAXCOL = 80,
LABELROW = 1,
NLET = 26,
HEIGHT = MAXROW –4,
WIDTH = (MAXCOL-1) / NLET
};
169
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
This is a legacy of old style C programming. It is much better to use symbols to explicitly
indicate the intent of the statement. It is easy to see that the following code is more in line
with the self-documentation philosophy than the code above.
flag = false;
str = NULL;
name[i] = ‘\0’;
x = 0.0;
i = 0;
170
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 32
Although it is not very long but we can still improve its readability by breaking it into
small functions to perform the logical steps. The modified code is written below:
171
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
It is easy to see that the new selectionSort function is much more readable. The logical
steps have been abstracted out into the two functions namely, minimum and swap. This
code is not only shorter but also as a by product we now have two functions (minimum
and swap) that can be reused.
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. As an example, let us consider the quickSort
algorithm below.
172
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
This is actually a very simple algorithm but students find it very difficult to remember. If
is broken in logical steps as shown below, it becomes trivial.
173
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
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.
Also, time is saved in evaluation of complex expressions using operators || and &&.
However, a number of issues arise if proper attention is not paid.
Let us look at the following code segment taken from a commercially developed software
for a large international bank:
struct Node {
int data;
Node * next;
};
Node *ptr;
...
The second part of condition, ptr != NULL, is supposed to be the guard. That is, if the
value of the pointer is NULL, then the control should not enter the body of the while loop
otherwise, it should check whether ptr->data < myData or not and then proceed
accordingly. When the guard is misplaced, if the pointer is NULL then the program will
crash because it is illegal to access a component of a non-existent object. This code is
rewritten as follows. This time the short-circuiting helps in achieving the desired
objective which would have been a little difficult to code without such help.
while (ptr != NULL && ptr->data < myData){
// do something here
}
174
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
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. That is, a side effect is caused by an operation that may return an explicit result but it
may also modify the values stored in other data objects. Side effects are a major source of
programming errors and they make things difficult during maintenance or debugging
activities. Many languages do not specify the function evaluation order in a single
statement. This combined with side effects causes major problems. As an example,
consider the following statement:
c = f1(a) + f2(b);
The question is, which function (f1 or f2) will be evaluated first as the C/C++ language
does not specify the evaluation order and the implementer (compiler writer) is free to
choose one order or the other. The question is: does it matter?
In this case both f1 and f2 have side effects as they both are doing two things - changing
the value of the parameter and changing the value at the caller side. Now if we have the
following code segment,
a = 3;
b = 4;
c = f1(a) + f2(b);
a=6
b=2
c=8
175
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
So far there seem to be any problem. But let us now consider the following statement:
c = f1(a) + f2(a);
a=3
c = 9 // 7 + 2
On the other hand, if f2 is evaluated before f1 then, we get totally different results.
a=2
c = 3 // 3 + 0
176
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 33
Common Coding mistakes
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.
Guidelines
If the following guidelines are observed, one can avoid hazards caused by side effects.
177
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Performance
In many cases, performance and maintainability are at odds with one another. When
planning for performance, one should always remember the 80/20 rule - you spend 80
percent of your time in 20 percent of the code. That is, we should not try to optimize
everything. The proper approach is to profile the program and then identify bottlenecks to
be optimized. This is similar to what we do in databases – we usually normalize the
database to remove redundancies but then partially de-normalize if there are performance
issues.
The profiling revealed that most of time was spent in strchr and strncmp and both of these
were called from strstr.
When a small set (a couple of functions) of functions which use each other is so
overwhelmingly the bottleneck, there are two alternatives:
In this particular case strstr was rewritten and profiled again. It was and found out that
although it was much faster but now 99.8% of the time was spent in strstr.
The algorithm was rewritten and restructured again by eliminating strstr, strchr, and
strncmp and used memcmp. Now memcmp was much more complex than strstr but it
gained efficiency by eliminating a number of loops and the new results are as shown:
178
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Many details of the execution can be discovered by examining the numbers. The trick is
to concentrate on hot spots by first identifying them and then cooling them. As mentioned
earlier, most of the time is spent in loops. Therefore we need to concentrate on loops.
This loop clears field before each new input is read. It was observed that it was taking
almost 50% of the total time. On further investigation it was found out that MAX_FIELD
was 200 but the actual fields that needed to be cleared were 2 or 3 in most cases. The
code was subsequently modified as shown below:
179
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 34
Portability
Although C++ standard does not require function prototypes, one should always write
them.
Sizes of data types cause major portability issues as they vary from one machine to the
other so one should be careful with them.
int i, j, k;
…
j = 20000;
k = 30000;
i = j + k;
180
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
181
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Order of Evaluation
As mentioned earlier during the discussion of side effects, order of evaluation varies from
one implementation to other. This therefore also causes portability issues. We should
therefore follow guidelines mentioned in the side effect discussion.
Signedness of char
char c;
// between 0 and 255 if unsigned
// -128 to 127 if signed
c = getchar();
if (c == EOF) ??
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.
Interestingly, Java has introduced a new operator to handle this issue. >> is used for for
arithmetic shift and >>> for logical shift.
The order in which bytes of one word are stored is hardware dependent. For example in
Intel architecture the lowest byte is the most significant byte while in Motorola
architecture the highest byte of a word is the most significant one. This causes problem
when dealing with binary data and we need to be careful while exchanging data between
to heterogeneous machines. One should therefore only use text for data exchange. One
should also be aware of the internationalization issues and hence should not assume
ASCII as well as English.
182
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Alignment
The C/C++ language does not define the alignment of items within structures, classes, an
unions. data may be aligned on word or byte boundaries. For example:
struct X {
char c;
int i;
};
183
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
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.
C lets us do this in a structure definition by putting :bit length after the variable. i.e.
struct packed_struct {
unsigned int f1:1;
unsigned int f2:1;
unsigned int f3:1;
unsigned int f4:1;
unsigned int type:4;
unsigned int funny_int:9;
} pack;
Here the packed_struct contains 6 members: Four 1 bit flags f1..f3, a 4 bit
type and a 9 bit funny_int.
C automatically packs the above bit fields as compactly as possible, provided that the
maximum length of the field is less than or equal to the integer word length of the
computer. If this is not the case then some compilers may allow memory overlap for the
fields whilst other would store the next field in the next word.
Bit fields are a convenient way to express many difficult operations. However, bit fields
do suffer from a lack of portability between platforms:
184
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 35
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 idea is to raise some error flag every time something goes wrong. There is a system
that is always on the lookout for this error flag. Third, the previous system calls the error
handling code if the error flag has been spotted. 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.
try {
...
...
throw Exception()
...
...
} catch( Exception e )
{
...
...
}
One of the most powerful features of exception handling is that an error can be thrown
over function boundaries. This allows programmers to put the error handling code in one
place, such as the main-function of your program.
185
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
186
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
The argument is passed by value, which invokes the copy constructor. This copy
e.Title() might itself throw, or it might return an object of class type by value, and
Same as above.
To match a valid ==() operator, the string literal may need to be converted to a
temporary object of class type and that construction of the temporary might throw.
Same as above.
Same as above.
187
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Same as above.
9-13 cout << e.First() << “ “ << e.Last() << “ is overpaid” << endl;
As per C++ standard, any of the five calls to << operator might throw.
14-15 cout << e.First() << “ “ << e.Last() << “ is overpaid” << endl
similar to 2 and 3.
similar to 14-15.
similar to 4.
Summary:
188
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
The Challenge:
Can we make this code exception safe and exception neutral? That is, rewrite it (if
needed) so that it works properly in the presence of an exception and propagates all
exceptions to the caller?
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.
As far as the second side-effect is concerned, the function meets the strong
guarantee because if an exception occurs the value will never be returned.
As far as the first side-effect is concerned, the function is not exception safe for
two reasons:
• if exception is thrown after the first part of the message has been emitted
to cout but before the message has been completed (for example if the
fourth << operator throws), then a partial message was emitted to cout.
• If the message emitted successfully but an exception occurs in later in the
function (for example during the assembly of the return value), then a
189
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
message was emitted to cout even though the function failed because of an
exception. It should be complete commit or complete roll-back.
Strong Guarantee
To meet strong guarantee, either both side-effects are completed or an exception is
// First attempt:
}
return result;
}
String theName;
theName = evaluateSalarayAndReturnName(someEmplyee);
190
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Can we do better and perhaps avoid the problem by avoiding the copy?
// Second attempt:
}
r = result;
}
Looks better but assignment to r might still fail which leaves us with one side-effect
completed and other incomplete.
// Third attempt:
}
return result;(); // rely on transfer of ownership
// this can’t throw
}
We have effectively hidden all the work to construct the second side-effect (the return
value), while we ensured that it can be safely returned to the caller using only non-
throwing operation after the first side-effect has completed the printing of the
message. In this case we know that once the function is complete, the return value
will make successfully into the hands of the caller and be correctly cleaned-up in all
cases. This is because the aut_ptr semantics guarantee that If the caller accepts the
returned value, the act of accepting a copy of the auto_ptr causes the caller to take the
ownership and if the caller does not accept the returned value, say by ignoring the
191
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
return value, the allocated string will automatically be destroyed with proper clean-
up.
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. That way, at least, the caller would know that these are two separate atomic
steps.
Summary
1. Providing the strong exception-safety guarantee often requires you to trade-off
performance.
2. If a function has multiple un-related side-effects, it cannot always be made
strongly exception safe. If not, it can be done only by splitting the function
into several functions, each of whose side-effects can be performed
atomically.
3. Not all functions need to be strongly exception-safe. Both the original code
and attempt#1 satisfy the basic guarantee. For many clients, attempt # 1 is
sufficient and minimizes the opportunity for side-effects to occur in the
exceptional situation, without requiring the performance trade-off of attempt
#3.
192
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
Lecture No. 36
Software Verification and Validation
Software Testing
To understand the concept of software testing correctly, we need to understand a few
related concepts.
Software verification and validation
Verification and validation are the processes in which we check a product against its
specifications and the expectations of the users who will be using it. According to a
known software engineering expert Berry Boehm, verification and validation are
Verification
• Does the product meet system specifications?
• Have you built the product right?
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 users expectations or their desired behavior. That means, software is verified but not
validated. How is it possible? It is possible because during the requirements engineering
phase, user needs might not have been captured precisely or the analyst might have
missed a major stakeholder in the analysis. Therefore, it is important to verify as well as
validate the software product.
Defect
The second major and a very important concept is Defect. A defect is a variance from a
desired product attribute. These attributes may involve system specifications well as user
expectation. Anything that may cause customer dissatisfaction, is a defect. Whether these
defects are in system specifications or in the software products, it is essential to point
these out and fix.
Therefore software defect is that phenomenon in which software deviates from its
expected behavior. This is non-compliance from the expected behavior with respect to
written specifications or the stakeholder needs.
Software and Defect
Software and defects go side by side in the software development life cycle. According to
a famous saying by Haliburton, Death and taxes are inevitable. According to Kernighan:
Death, taxes, and bugs are the only certainties in the life of a programmer. Software and
defects cannot be separated, however, it is important to learn how discovering defects at
an appropriate stage improves the software quality. Therefore, software application needs
to be verified as well as validated for a successful deployment.
Software Testing
With these concepts, we are in a position to define 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. From another perspective, software testing
193
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
is the process of executing software product on test data and examining its output vis-à-
vis the documented behavior.
Software testing objective
• The correct approach to testing a scientific theory is not to try to verify it, but to
seek to refute the theory. That is to prove that it has errors. (Popper 1965)
• The goal of testing is to expose latent defects in a software system before it is put
to use.
• A software tester tries to break the system. The objective is to show the presence
of a defect not the absence of it.
• Testing cannot show the absence of a defect. It only increases your confidence in
the software.
• This is because exhaustive testing of software is not possible – it is simply too
expansive and needs virtually infinite resources.
Successful Test
From the following sayings, a successful test can be defined
“If you think your task is to find problems then you will look harder for them than if you
think your task is to verify that the program has none” – Myers 1979.
The success of a test depends upon the ability to discover a bug not in the ability to prove
that the software does not have one. As, it is impossible to check all the different
scenarios of a software application, however, we can apply techniques that can discover
potential bugs from the application. Thus a test that helps in discovering a bug is a
successful test. In software testing phase, our emphasis is on discovering all the major
bugs that can be identified by running certain test scenarios. However it is important to
keep in mind that testing activity has certain limitations.
Limitations of testing
With the help of the following example, we shall see how difficult it may become to
discover a defect from a software application.
Example (adapted from Backhouse)
This is a function that compares two strings of characters stored in an array for equality.
The tester who has to test this function has devised the following test cases in which
different combinations of inputs are tried and their expected behavior is documented.
From the look of this table, it seems that almost all major combinations of inputs have
been documented.
Inputs and Expected Outputs
A b Expected result
“cat” “dog” False
“” “” True
“hen” “hen” True
“hen” “heN” False
“” “” False
194
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
“” “ball” False
“cat” “” False
“HEN” “hen” False
“rat” “door” False
“” “” True
Results of testing
The tester runs all the above-mentioned test cases and function returns the same results as
expected. But it is still not correct. What can be a problem To analyze the problem, lets
look at the code of this string equal routine
Code of the Function
bool isStringsEqual(char a[], char b[])
{
bool result;
if (strlen(a) != strlen(b))
result = false;
else {
for (int i =0; i < strlen(a); i++)
if (a[i] == b[i])
result = true;
else result = false;
}
return result;
}
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.
The above-mentioned defect signifies a clear limitation of the testing process in
discovering a defect which is not very frequent. However, it should be noted from this
example that a tester cannot generate all possible combinations of test cases to test
an application as the number of scenarios may become exhaustive.
Testing limitations
• In order to prove that a formula or hypothesis is incorrect all you have to do to
show only one example in which you prove that the formula or theorem is not
working.
• On the other hand, million of examples can be developed to support the
hypothesis but this will not prove that it is correct.
• These examples only help you in coming up with a hypothesis but they are not
proves by themselves and they only enhance your comfort level in that particular
hypothesis or in this particular case, in your piece of software.
• You cannot test a program completely because:
o the domain of the possible inputs is too large to test.
o there are too many possible paths through the program to test.
• According to Discrete Mathematics
195
© Copyright Virtual University of Pakistan
CS504-Software Engineering – I VU
196
© Copyright Virtual University of Pakistan
AL-JUNAID INSTITUTE GROUP
134. In system development life cycle, defects cannot enter into the program
during _____ phase.
a. Requirement
b. Design
c. Coding
d. Implementation page 209
135. _____and _____ are important short circuiting logical operators.
a. AND b. OR c. NOTd. NOR
a. a & b pae 173
b. b&c
c. c&d
d. a & c.
136. _________ testing isolates every part of the program and shows that
the individual parts are correct.
a. White Box
b. Black Box
c. Unit Google
d. System
137. _______is not a white box testing technique.
a. Statement Coverage
b. Branch Coverage
c. Path Coverage
d. State Transition Coverage page 202
138. Chip level testing for hardware is equivalent to _______
a. White Box
b. Black Box
c. Unit testing page 207
AL-JUNAID INSTITUTE GROUP
d. System testing
139. For equivalence partitions, we divide the problem in _____ obvious categories.
a. Two
b. Four
c. Five
d. Six
140. Which rewritten form of above line of code is more in line with the
self-documentation philosophy than the code above?
a. x = false
b. x = NULL
c. X = 0.0; page 169
d. x = '\0`
141. One of the main reasons to make functions is _____
a. Reliability
b. Reusability page171
c. Maintainability
d. Efficiency
142. 80/20 rule states that:
a. you spend 80 percent of your time in 20 percent of the
code page 177
b. you spend 20 percent of your time in 80 percent of the code
c. We should try to optimized 80 percent or at least 20 percent of the
code
d. We should try to optimized 20 percent or at least 80 percent of the
code
143. ______identifies which statements in a method or class have been executed.
a. Method Coverage
b. Statement Coverage
c. Class Coverage
d. Branch Coverage
144. In ______ system's internal implementation details are not visible to
the tester.
a. White Box Testing
b. Gray Box Testing
c. Black Box Testing page 198
d. Both White Box Testing & Gray Box Testing
AL-JUNAID INSTITUTE GROUP
145. Verification and validation are the processes in which we check a
product against its ___________ and the ________ of the users who will be
using it
a. specifications arguments
b. statements, expectations
c. specifications, expectations page 192
d. statements, arguments
146. Objective of _____ is to show that the program does not work
a. Requirements
b. Design
c. Coding
d. testing page 196
147. The raising of the imaginary error flag is simply called raising or ___ an error
a. Catching
b. Casting
c. Throwing page 184
d. Repress
148. Be very careful when you use functions with side effects - functions
that change the values of the ________
a. Objects
b. Classes
c. Structures
d. Variables
Be very careful when you use functions with side effects – functions that
change the values of the parameters. Page 176
149. The number _________ is the most abused symbol in programs written in C or
C++.
a. 1
b. 0 page169
c. 2
d. 3
150. _______ is a creative activity while____________ is a destructive activity.
a. Development, Testing
b. Testing, Development
c. Validation, Verification
d. Verification, Validation
151. Testing individual components independent of other components is called:
AL-JUNAID INSTITUTE GROUP
a. Unit testing page 189
b. Module testing
c. Subsystem testing
d. System testing
152. The expressions with logical operators can be evaluated only from______
a. Right to left
b. Left to right page173
c. Top to bottom
d. Bottom to top
153. The complexity of a program may ______if there are exceptional paths in it
a. Decrease
b. Increase page 185
c. Remain same
d. Cutback
154. In the switch statement, cases should always end with a _________ statement.
a. Switch
b. Go
c. Break page 167
d. Stop
155. Cyclomatic complexity measures the logical complexity____
a. Quantitatively page 205
b. Qualitatively
c. Creditably
d. Worthily
156. The size of ______________ plays a significant role in making the
program easy or difficult to understand
a. Function page 170
b. Object
c. data type
d. none of the above
157. ______________depicts programming instructions that do not have branching
or any control information
a. Sequence page 200
b. IF
c. While
d. Case
158. for (i =0, col = 0; i < 27; i++.j++)
AL-JUNAID INSTITUTE GROUP
In the above line of the code 27 is representing ________.
a. Real Numbers
b. Magic Numbers page 167
c. Constant Numbers
d. Positive Numbers
159. The process that involves verification of product with respect to its written
requirements is called ________
a. Maintenance
b. Debugging
c. Development
d. Testing page 192
160. If an application fulfills its specifications but deviates from users expectations
or their desired behavior. This means, software is verified but not _______
a. Validated page 192
b. Corrected
c. Checked
d. Traced
161. If a function changes the value of some other accessible data object along
with returning its value after execution is called ______
a. Short Circuiting
b. Modularity
c. Side Effects page 174
d. Abstraction
162. if (e.Title() == "CEO" || e. Salary() > 10000)
in the above statement if (e.Title()=="CEO") is TRUE then
a. Second part is not evaluated page 185
b. Second part is always evaluated
c. Second part must also be TRUE
d. Second part is not evaluated but e.Salary ()is called
163. When an error is thrown the overall system (on the lookout for this error
flag) responds by ____the error
a. Ignoring
b. Casting
c. Catching page 184
d. Pass over
164. Testing of collection of modules to discover interfacing problems
among interacting modules is called
AL-JUNAID INSTITUTE GROUP
a. Unit testing
b. Module testing
c. Subsystem testing page 198
d. System testing
165. Constant values used in the program are
called
a. Real Numbers
b. Magic Numbers page 168
c. Constant Numbers
d. Positive Numbers
166. Bit fields are a convenient way to express many difficult operations.
However, bit fields suffer from one problem
a. Lack of usability
b. Lack of security
c. Lack of performance
d. Lack of portability page 183
167. Comma ( ,) is very dangerous because _____
a. Compiler does not recognize this symbol
b. It creates linkage problem
c. It causes side effects page 176
d. It does not causes side effects
168. Function testing falls under ______________testing technique
a. White Box
b. Black Box
c. Unit page 207
d. System
169. The greatest advantage of exception handling is its ability to handle:
a. Asynchronous errors page 184
b. Syntax errors
c. Memory errors
d. Control Structure errors
170. After integrating subsystems into a system, and then testing this system as a
whole is called
a. Unit testing
b. Component testing
c. Subsystem testing
d. System testing
AL-JUNAID INSTITUTE GROUP
171. struct packed_struct{
unsigned int
f1:1; } pack;
Here in "packed_struct":
a. value of f1 = 1
b. size of f1 = 1 bit page 183
c. value of f1 should not exceede 1
d. None of given options
172. The C/C++ language has not specified whether _______ is arithmetic or
logical.
a. Right shift >> page 181
b. Right shift <<
c. &&
d. ||
173. There are______ basic coding structures.
a.
One
b.
Two
c.
Three
d.
Four page 200
174. In _______ control can take either of several branches.
a. IF
b. While
c. Case statement page 201
d. Sequence
175. __________ cause major portability issues
a. Loops
b. Bugs in code
c. Sizes of data types page 179
d. Conditional Structures
176. A good program must contain _________ infeasible paths.
a. 0 page 206
b. 1
c. N
d. Infinite
177. We do not use flow graphs to ___________.
a. Show flow of data
AL-JUNAID INSTITUTE GROUP
b. Describe decisions
c. Show Control in an application
d. Describe different coding structures
178. The order in which bytes of one word are stored is _______ dependent
a. Hardware page 181
b. Software
c. Language
d. syntax
179. _________ is the starting point, base document for both testing and the
development
a. Software code
b. Test case document
c. Software architecture document
d. Functional specification document page196
193. When a small set of functions (which use each other) is so overwhelmingly
the bottleneck, there are two alternatives:
a. use a better algorithm OR re-write the code page 177
b. debug the code OR place assertions in code
c. remove the functions OR add more functions
d. changed programming language OR compiler at least
194. The first step in any OOA process model is to____________________
a. build an object-relationship model
b. define collaborations between objects
c. elicit customer requirements Page603
d. select a representation language
AL-JUNAID INSTITUTE GROUP
195. A necessary supplement to transform or transaction mapping needed to
create a complete architectural design is ________.
a. entity relationship diagrams
b. the data dictionary
c. processing narratives for each module Page422
d. test cases for each module
196. All comments should be written in---------
a. English (Page 162)
b. French
c. C++
d. JAVA
197. Which test criteria should be applied in a phase of testing?
a. functional validity
b. interface integrity
c. correctness
d. all of the given Page522
198. The hardest single part of building a software system is deciding
precisely ----------- to build.
a. what (Page 17)
b. How
c. When
d. Why
199. In sequence Diagrams objects are organized in a ----------line
a. horizontal (Page 106)
b. vertical
c. horizontal and vertical
d. none of the above
200. Every view is potentially Hierarchical in this regard which of the view
are Hierarchical?
a. Functional View
b. Development View
c. Concurrency view
d. All of given (Page 125)
201. Like analysis models, many different kinds of -----------models are
developed
a. Architectural (Page 126)
b. System
c. Design
d. Logical
AL-JUNAID INSTITUTE GROUP
202. Idea behind zero install architecture is to develop a system where no
installation on the ---------- is needed.
a. Client side (Page 130)
b. Server Side
c. Client & Server Side
d. None of the all
203. The construction is used to avoid ---------------- errors.
a. compilation (Page 157)
b. runtime
c. design time
d. none of them
204. 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, --------------------
a. the other probably may
b. none of them
c. the other probably won’t either Page 199
d. the other probably will
205. It was lady named ----------------- who actually coin the term “bug" for
the fiest time.
a. Elisay Chistopher
b. Admiral Grace Hopper Page 213
c. Ana Nicholson
d. Jane Hopper
206. Symptoms of logical errors are ------------------------------
a. code is misbehaving
b. Program doesn't crash, but the flow of program takes odd branches through
the code.
c. Results are the opposite
d. Output looks strange,
e. all of the given Page 218
207. First-hand accounts of the problem are always useful in Debugging
process.
a. True Page 225
b. False
208. architecture elements are further divided into categories which in total
are -----------
a. 2
b. 3 Page 122
c. 4
AL-JUNAID INSTITUTE GROUP
d. 5
209. Establishing responsibilities for objects includes
a. Generalization Relationships
b. Specialization Relationships
c. all of the above
d. identifying Association relationships Page 101
210. Source files can have the extension ---------------------
a. .c++
b. .C
c. .cpp
d. all of the given Page 155
213. The statements given below are associated with system development,
testing and maintenance. Identify the correct statement from among
them:
a. Some of the activities in the implementation phase are building individual
system components, writing of programs and development of user
interfaces.
b. The post implementation review is performed to see that the computer
system is working.
c. None of Given
d. System development phase consists of a development phase and an
implementation phase.
214. Quantitative methods for assessing the quality of proposed architectural
designs are readily available.
AL-JUNAID INSTITUTE GROUP
a. True
b. False
215. A decision table should be used_______________________
a. to document all conditional statements
b. to guide the development of the project management plan
c. only when building an expert system
d. when a complex set of conditions and actions appears in a component
216. Test cases should be designed long before testing begins.
a. True Page 467
b. False
217. Which of the following are characteristics of testable software?
a. observability
b. simplicity
c. stability
d. all of the given Page 469
218. Comparison testing is typically done to test two competing products as
part of customer market analysis prior to product release.
a. True
b. False
FINALTERM EXAMINATION
Spring 2010
CS504- Software Engineering - I (Session - 2)
► behavioral errors
► subtle logic errors Click here for detail
► performance errors
► input error
► functional validity
► interface integrity
► correctness
► all of the given (A P R A C T I T I O N E R ’ S A P P R O A C H Page522)
Question No: 5 ( Marks: 1 ) - Please choose one
The hardest single part of building a software system is deciding precisely ----------- to build.
► Functioanl View
► Development View
► Concurrency view
► All of given (Page 125)
►, (Page 176)
►;
►=
► ||
► Elisay Chistopher
► Admiral Grace Hopper (Page 213)
► Ana Nicholson
► Jane Hopper
► II (Page 213)
►I
► III
► IV
► code is misbehaving
► The program doesn't crash, but the flow of program takes odd branches through the code.
► Results are the opposite
► Output looks strange,
► all of the given (Page 218)
►2
►3 (Page 122)
►4
►5
► c++ .
► .C
► .cpp
► all of the given (Page 155)
► Software is tangible
► A change to a piece of code may implicitly affect the functions of the rest of the code.
► Software is configurable.
► Software does not wear and tear.
► Site visits
► Prototyping
► Study of similar systems
► All of given
Seven common fact-finding methods (Sampling, Research, Observation, Questionnaires, Interviews,
Prototyping, Joint Requirements Planning) are introduced as a means to discover requirements.
► Some of the activities in the implementation phase are building individual system components, writing of
programs and development of user interfaces.
► The post implementation review is performed to see that the computer system is working.
► None of Given
► System development phase consists of a development phase and an implementation phase.
FINALTERM EXAMINATION
Spring 2010
► True
► False http://highered.mcgraw-hill.com/sites/0072853182/student_view0/chapter10/multiple_choice_quiz.html
► observability
► simplicity
► stability
► all of the given (A P R A C T I T I O N E R ’ S A P P R O A C H Page 469)
► True
► False Click here for detail
► True
► False Click here for detail
► Circuit level
► Chip Level (Page 207)
► component level
► system level
► freely
► independently (Page 207)
► dependtly
► completely
► Uptime
► Downtime (Page 214)
► Currentime
► futuretimr
► 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.
► Compiler warnings. (Page 220)
Question No: 18 ( Marks: 1 ) - Please choose one
Software architecture elements are further divided into categories which in total are -----------
►2
►3 (Page 122) rep
►4
►5
► Presentation
► Application
► Database
► All of the above (Page 131)
► Flow Graphs
► Data Flow Diagrams (not sure)
► Activity Networks
► Module Dependency Diagrams
Question No: 23 ( Marks: 1 ) - Please choose one
Consider the following comment. “The software which I bought won’t run on windows and when it runs
I can’t use WORD at the same time”. Which of the following do you think are violated by the newly
bought software?
► dependability, interchangeability
► platform independence, interoperability
► reliability, dependency
► interoperability, reliability
► Class Diagram
► Document flow diagrams
► Data flow diagrams
► Flow charts
FINALTERM EXAMINATION
Spring 2010
► creation of a CFD
► derivation of the control hierarchy Click here for detail
► distribution of worker modules
► refinement of the module view
► performance
► reliability
► security
► time (Page 498)
Question No: 9 ( Marks: 1 ) - Please choose one
Top-down integration testing has as it's major advantage(s) that
► True
► False Click here for detail
► code is misbehaving
► The program doesn't crash, but akes odd branches through the code.
► Results are the opposite
► Output looks strange,
► all of the given (Page 218)
► Flow Graphs
► Data Flow Diagrams (not sure)
► Activity Networks
► Module Dependency Diagrams
► True
► False (Page 150)
►Creat
►Update
►Read
►All of above (Page 53)
Question No: 12 ( Marks: 1 ) - Please choose one
Bugs Finding is done by which of the teams in Software Development lifecycle?
► Development Team
► Testing Team (Page 196)
► Analysis & Design Team
► Process Team
FINALTERM EXAMINATION
Spring 2010
► bounding scope
► understanding user needs
► requirements volatility
► all of the above (A P R A C T I T I O N E R ’ S A P P R O A C H Page 285)
► True
► False (Page 150)
► True
► False Click here for detail
► True
► False Click here for detail
► Vertical
► Horizontal (Page 106)
► Vertical & Horizontal
► Non of the above
Question No: 14 ( Marks: 1 ) - Please choose one
the development view describes the -----------organization of the software in its development
environment,
► Functioanl View
► Development View
► Concurrency view
► All of given (Page 125)
► Code
► Design (Page 138)
► Analysis
► non of the all
► analysis text
► source text (Page 211)
► design text
► non of the given
► 20 % (Page 214)
► 25 %
► 30%
► 35%
FINALTERM EXAMINATION
Fall 2008
True
False Click here for detail
True
False Click he re for Detail
analysis text
source text (Page 211)
design text
non of the given
II (Page 213)
I
III
IV
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.
Compiler warnings. (Page 220)
reason
disease (Page 224)
source
non of the given
Question No: 30 ( Marks: 1 ) - Please choose one
Bugs that won't "stand still" (almost random) are the ---------- to deal with.
least difficult
most difficult (Page 226)
very easy
easy