FINALTERM EXAMINATION
Spring 2009
CS504- Software Engineering _ I
Spring 2009
CS504- Software Engineering _ I
Question No: 31 ( Marks: 1 )
Write the procedure how names representing Abbreviations and acronyms should be describe in
coding style guide.
Abbreviations and acronyms should not be uppercase when used as name.
Write the procedure how names representing Abbreviations and acronyms should be describe in
coding style guide.
Abbreviations and acronyms should not be uppercase when used as name.
exportHtmlSource(); // NOT: xportHTMLSource();
openDvdPlayer(); // NOT: openDVDPlayer();
Question No: 32 ( Marks: 1 )
Define a system downtime.A system downtime is the period in which tremendous pressure is on developers end to fix the problem and make the system running again.
Question No: 33 ( Marks: 2 )
What is layered architectureAs 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.
Question No: 34 ( Marks: 2 )
What is Infeasible path?Infeasible path is a path through a program which is never traversed for any input data.
Question No: 35 ( Marks: 3 )
List three guidelines that can help you in writing portable code.
http://www.allvupastpapers.blogspot.com/
Question No: 36 ( Marks: 3 )
Describe three coverage schemes related to white box testing.
Question No: 37 ( Marks: 3 )
Wrtie the General Form for documenting pattrens.The motivation or context that this pattern applies to.
Prerequisites that should be satisfied before deciding to use a pattern.
A description of the program structure that the pattern will define.
A list of the participants needed to complete a pattern.
Consequences of using the pattern...both positive and negative.
Examples!
Question No: 38 ( Marks: 5 )
Discuss any five the General naming conventions for an object oriented language
General naming conventions for Java and C++
1. Names representing types must be nouns and written in mixed case starting with
upper case.
Line, FilePrefix
2. Variable names must be in mixed case starting with lower case.
line, filePrefix
This makes variables easy to distinguish from types, and effectively resolves potential
naming collision as in the declaration Line line;
3. Names representing constants must be all uppercase using underscore to separate
words.
MAX_ITERATIONS, COLOR_RED
In general, the use of such constants should be minimized. In many cases
implementing the value as a method is a better choice. This form is both easier to
read, and it ensures a uniform interface towards class values.
int getMaxIterations()// NOT: MAX_ITERATIONS = 25
{
return 25;
}
4. Names representing methods and functions should be verbs and written in mixed case
starting with lower case.
getName(), computeTotalWidth()
5. Names representing template types in C++ should be a single uppercase letter.
template<class T> ...
template<class C, class D> ...
6. Global variables in C++ should always be referred to by using the :: operator.
::mainWindow.open() , ::applicationContext.getName()
7. Private class variables should have _ suffix.
class SomeClass
{
private int length_;
...
}
Apart from its name and its type, the scope of a variable is its most important feature.
Indicating class scope by using _ makes it easy to distinguish class variables from local
scratch variables.
8. Abbreviations and acronyms should not be uppercase when used as name.
exportHtmlSource(); // NOT: xportHTMLSource();
openDvdPlayer(); // NOT: openDVDPlayer();
Using all uppercase for the base name will give conflicts with the naming conventions
given above. A variable of this type would have to be named dVD, hTML etc. which
obviously is not very readable.
9. Generic variables should have the same name as their type.
void setTopic (Topic topic) // NOT: void setTopic (Topic value)
// NOT: void setTopic (Topic aTopic)
// NOT: void setTopic (Topic x)
void connect (Database database) // NOT: void connect (Database db)
// NOT: void connect (Database oracleDB)
Non-generic variables have a role. These variables can often be named by combining role
and type:
Point startingPoint, centerPoint;
Name loginName;
10. All names should be written in English.
fileName; // NOT: filNavn
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.
Question No: 39 ( Marks: 5 )
What are the Software testing objective? Also define a successful test.
Software testing objective
What are the Software testing objective? Also define a successful test.
Software testing objective
„h 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)
„h The goal of testing is to expose latent defects in a software system before it is put
to use.
„h A software tester tries to break the system. The objective is to show the presence
of a defect not the absence of it.
„h Testing cannot show the absence of a defect. It only increases your confidence in
the software.
„h 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.
“A test is said to be successful if it discovers an error” – doctor’s analogy.
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.
Question No: 40 ( Marks: 10 )
What should be the sets of inputs that should be used to test the system effectively and efficiently? Give an example.To answer these questions, we divide a problem domain in different classes. These are
called Equivalence Classes.
Question No: 41 ( Marks: 10 )
Discuss Art and Science of Debugging.
Debugging is taken as an art but in fact it is a scientific process. As people learn about
different defect types and come across situations in which they have to debug the code,
they develop certain heuristics. Next time they come across a similar situation, they apply
those heuristics and solve the problem in lesser time and with a lesser effort. While
discussing the debugging process we discuss the phenomenon of “you miss the obvious”.
When a person writes a code, he develops certain impression about that code. One can
term this impression as a personal bias that the developer builds towards his creation the
“code” and when he has to check this code, he can potentially miss out obvious mistakes
due to this impression or bias. Therefore, it is strongly recommended that in order to
reach to a defect in the code, one needs “another pair of eyes”. That is, start discovering
the defect by applying your own heuristics and if you could reach to the problem, fine,
otherwise ask a companion to help you in this process. We shall further elaborate this
idea based on the following example.
Final Term Examination - February 2005
Time Allowed: 150 Minutes
Question No. 1 Marks : 6
What are Loop Errors? Describe briefly. What are symptoms of Loop Errors?
Question No. 2 Marks : 15
„h Loop errors break down into several different subtypes.
„h They occur around a loop construct in a program.
„h Infinite loops, off-by-one loops, and improperly exited loops.
Symptoms
„h If your program simply locks up, repeatedly displays the same data over and over,
or infinitely displays the same message box, you should immediately suspect an
infinite loop error.
„h Off-by-one loop errors are quite often seen in processes that perform calculations.
„h If a hand calculation shows that the total or final sum is incorrect by the last data
point, you can quickly surmise that an off-by-one loop error is to blame.
„h Likewise, if you were using graphics software and saw all of the points on the
screen, but the last two were unconnected, you would suspect an off-by-one error.
Watching for a process that terminates unexpectedly when it should have
continued.
Q- 4 Marks: 6
What are Boolean Bugs? Describe briefly.What are symptoms of Boolean Bugs?
Boolean bugs
Boolean bugs occur because the mathematical precision of Boolean algebra has virtually
nothing to do with equivalent English words.
When we say "and", we really mean the boolean "or" and vice versa.
Symptoms
„h When the program does exactly the opposite of what you expect it to. For
example, you might have thought you needed to select only one entry from a list
in order to proceed. Instead, the program will not continue until you select more
than one. Worse, it keeps telling you to select only one value.
„h For true/false problems, you will usually see some sort of debug output indicating
an error in a function, only to see the calling function proceed as though the
problem had not occurred.
2. Write a short note on Data Flow or Pipes and Filter Architecture Configuration.(3 Pts)
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.
3. How do you differentiate between the responsibilities of Developer and Tester? (3 Pts)
Development is a creative activity Testing is a destructive activity
Objective of development is to show that the program works. Objective of testing is to show that the program does not work
QuestionNo.3 Marks:6
What are the symptoms of pointer errors?
Pointer errors
„h A pointer error is any case where something is being used as an indirect pointer to
another item.
„h Uninitialized pointers: These are pointers that are used to point at something, but
we fail to ever assign them something to point at.
„h Deleted pointers, which continue to be used.
„h An Invalid pointer is something that is pointing to a valid block of memory, but
that memory does not contain the data you expect it to.
Symptoms
„h The program usually crashes or behaves in an unpredictable and baffling way.
„h You will generally observe stack corruptions, failure to allocate memory, and odd
changing of variable values.
„h Changing a single line of code can change where the problem occurs.
„h If the problem "goes away" when you place a print statement or new variable into
the code that you suspect contains the problem.
What are the differences between Thin Client and Fat Client architecture?
(Q 9)
Thin Client Model
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.
Fat Client Model
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.
Following is the list of bugs’ symptoms; identify the bug classes in each case.
a) System slowdowns. Memory Leakage
b) The program doesn't crash, but the flow of the program takes odd branches
through the code. Logical Error
c) If your program simply locks up, repeatedly displays the same data over and over,
or infinitely displays the same message box. Loop Error
No comments:
Post a Comment
PLEASE COMMENT ABOUT YOUR VISIT AND MY SITE
Note: Only a member of this blog may post a comment.