Homework 4
CAP314: Software engineering concepts and tools
Topics: Designing, Testing
PART A
Q.1. Explain the difference between a database that services one
or more conventional business applications and a data
warehouse.
Ans:- Basically database & data warehouse both are databases,
and both have some tables containing data. But Still there are
few differences in both which are:-
Databases store detailed data about the operations of an
organization. They are typically organized by subject matter,
process relatively high volumes of updates using transactions.
Essentially every major organization on earth uses such
databases. We can have an example of database, include
customer databases that record contact, credit, and demographic
information about a business customers, personnel databases
that hold information such as salary, benefits, skills data about
employees.
Whereas a Data Warehouse is a database which is being designed
for facilitating querying and analysis. Often designed as OLAP
(On-Line Analytical Processing) systems, these databases contain
read-only data that can be queried and analyzed far more
efficiently as compared to your regular OLTP application
databases. In this sense an OLAP system is designed to be read-
optimized.
The primary difference between you application database and a
data warehouse is that while the former is designed (and
optimized) to record, the latter has to be designed (and
optimized) to respond to analysis questions that are critical for
your business.
We can consider the following characteristics of the data
warehouse differentiate it from the database:-
1. Subject Orientation:- A data warehouse is organized by
major business subjects, rather than by business process. As a
result there is exclusion of data that may be necessary for a
particular business function but is generally not necessary for
data mining.
2. Integration:- Regardless of the source the data exhibit
consistent naming conventions, units & measures, encoding
structures & physical attributes, even when inconsistency exists
across different application-oriented databases.
3. Time Variancy:- For transaction oriented application
environment data is accurate at the moment of access & for a
relatively short time span before access. For a data warehouse,
data can be accessed at a specific moment in time. We can have
an example of the customers who contacted on the date that a
new product was announced to the trade press.
4. Non-volatility:- Unlike typical business application databases
that undergo a continuing stream of changes i.e. insert, delete,
update etc, data are loaded into the warehouse but after the
original transfer, the data do not change.
Other Differentiations:-
• Workload:- Ad Hoc queries are accommodated by data
warehouse. Sometimes the workload of your data warehouse
is not known to you in advance, so a data warehouse should
be optimized to perform well for a wide variety of possible
query operations.
Whereas in Databases, end users routinely issue individual
data modification statements to the database. The OLTP
database is always up to date, and reflects the current state
of each business transaction.
Schema Design:- Data warehouses uses partially denormalized
schemas (such as a star schema) to optimize query
performance.
OLTP systems i.e. databases often use fully normalized
schemas to optimize update/insert/delete performance, and
to guarantee data consistency.
• Historical Data:-Data warehouses usually store many
months or years of data. This is to support historical
analysis.
Database systems usually store data from only a few weeks or
months. The OLTP system stores only historical data as needed to
successfully meet the requirements of the current transaction.
Q.2. Provide a few examples that illustrate why response time
variability can be an issue.
Ans:- . Response time variability is a new optimization problem
with a broad range of applications and a distinctive number of
theoretic flavours. The problem occurs whenever events, jobs,
clients or products need to be sequenced so as to minimize the
variability of time for which they wait for the next turn in
obtaining the resources necessary for their advance. The problem
has numerous real-life applications. We study its computational
complexity, present efficiency, polynomial time algorithms for
some cases, and the NP-hardness proof for a general problem. We
propose a position exchange heuristic and apply it to improve the
total response time variability of an initial sequence. The latter is
the optimum bottleneck sequence, Webster or Jefferson sequence
of the apportionment, or a random sequence.
Q.3. Develop a procedural design for an encryption/decryption
algorithm of your choosing.
Ans:-
Many times when data is exchanged electronically the privacy of
the data is a requirement. The use of encryption restricts
unintended recipients from viewing the data, which are deemed
confidential and potentially dangerous if made known to
irresponsible parties. Today, encryption is the procedure of
transforming plain text, data that can be read by anyone, to
ciphertext, data that can only be read by someone with a secret
decryption key. A message before being changed in any way is
called plain text. Plain text messages are converted to ciphertext
via some encryption method. A particular such method is called a
cryptosystem.
The procedural design converts structural components into a
procedural description of the software
Structured programming
- Structured Control Flow Chart
Flow charts do not guide the designer towards a structured design
the way box diagrams do. To enable the flow chart to be applied
to achieve a structured procedural design, we limit ourselves to
creating flow charts using only the structured chart constructs
(i.e., sequence, selection, repetition up to).
We have three constructs in structured programming:
-Sequence
-Selection
-Repetition.
The flow of control is always from top to bottom only. Each
construct has a predictable logical structure, and is entered at the
top and exited at the bottom.
Arbitrarily long text as input
PROCESS
Input – Text Process- Two arrays out of which one contains words
by splitting whole text and at the end of the text another loop
goes to make another array which indicates frequency of
occurrence as output.
Frequency of Occurrence
Program design language (PDL)
The Graphical Notation:
The appropriate development of a knowledge representation
(based on the cognitive processing of experts) that can deal with
concepts and facts relating to the represented diagram, the
graphical notation of the diagram, emergent properties arising
from the construction of the global units, the relationships
between the perceived concept of the diagram and the facts
inferred from the graphical notation.
For software following notations are used to represent the
program/logic.
• Assignment of variable
• Condition Operator:
• Socket Operator
• Connector Operator
• The annotation Operator
• The sequential operator
• The parallel operator
PART B
Q.4. How can project scheduling affect integration testing?
Ans:- Integration Testing:- It is the phase in software testing
in which individual software modules are combined and tested as
a group. It occurs after unit testing and before system testing.
Integration testing takes as its input modules that have been unit
tested, groups them in larger aggregates, applies tests defined in
an integration test plan to those aggregates, and delivers as its
output the integrated system ready for system testing. There is
one main head & there is a procedure explained to that head or
module. We can divide integration testing in five steps:-
1. Top down integration
2. Bottom-up integration
3. Regression Testing
4. Alpha Testing
5. Beta Testing
Project Scheduling:- Scheduling is an inexact process in that it
tries to predict the future. While it is not possible to know with
certainty how long a project will take, there are techniques that
can increase your likelihood of being close. If you are close in your
planning and estimating, you can manage the project to achieve
the schedule by accelerating some efforts or modifying
approaches to meet required deadlines.
Project Scheduling affect integration testing as follows:-
1. Design
2. Requirement elicitation
3. Unit testing
4. Integration testing
5. System testing
6. Acceptance testing
As we have seem above that project scheduling play an important
role in integration testing. Tests are conducted that each
component is integrated that means that its being checked
whether every module is performing its correspondent task. Test
case is performed for each test stub that means that it is checked
if the output of one module is affecting the other ones. If there
occurs a delay in completing any of the previous phases e.g.
design or construction and unit testing, this could delay the
beginning of the integration testing phase. Now, due to business
requirements, it is possible for the project end date to be fixed. In
such a case, project managers sometimes take the decision to
reduce the duration of the integration testing.
Q.5. Is unit testing possible or even desirable in all
circumstances? Provide examples to justify your answer.
Ans:- Unit testing focuses verification effort on the smallest unit of
software design the software component or module. Using the
component-level design description as a guide, important control
paths are tested to uncover errors within the boundary of the
module. The relative complexity of tests and uncovered errors is
limited by the constrained scope established for unit testing. The
unit test is white-box oriented, and the step can be conducted in
parallel for multiple components.
Each test case is independent from the others: substitutes like
method stubs, mock objects, fakes and test harnesses can be
used to assist testing a module in isolation. Unit tests are typically
written and run by software developers to ensure that code meets
its design and behaves as intended. Its implementation can vary
from being very manual to being formalized as part of build
automation.
Therefore we Can say that unit testing is possible and very
desirable in every case because for the development and the
implementation of a software it is required to test each and every
module individually. It is essential to measure the functionality
and failure of them. Only then a software is implemented and it is
not measured by unit testing leads to lots of harms and nobody
would like such a software because it is not being ensured how
safe is it.
For Example:-
The module interface is tested to ensure that information properly
flows into and out of the program unit under test. The local data
structure is examined to ensure that data stored temporarily
maintains its integrity during all steps in an algorithm's execution.
Boundary conditions are tested to ensure that the module
operates properly at boundaries established to limit or restrict
processing. All independent paths (basis paths) through the
control structure are exercised to ensure that all statements in a
module have been executed at least once. And finally, all error
handling paths are tested. Tests of data flow across a module
interface are required before any other test is initiated. If data do
not enter and exit properly, all other tests are moot. In addition,
local data structures should be exercised and the local impact on
global data should be ascertained (if possible) during unit testing.
Interface
Local data
structures
Boundary
conditions
Independent
Module paths
Error handling
paths
-----------
--
Test
Cases
Q.6. Provide an example of a composite object.
Ans:- Compose objects into tree structures to represent whole-part
hierarchies. Composite lets clients treat individual objects and
compositions of objects uniformly. He Composite composes objects
into tree structures and lets clients treat individual objects and
compositions uniformly. Although the example is abstract,
arithmetic expressions are Composites. An arithmetic expression
consists of an operand, an operator (+ - * /), and another
operand. The operand can be a number, or another arithmetic
expression. Thus, 2 + 3 and (2 + 3) + (4 * 6) are both
valid expressions.
Important Points:-
1. Hierarchical relationships
2. All container and containee classes declare an “is a”
relationship to the interface.
3. All container classes declare a one-to-many “has a”
relationship to the interface.
4. Container classes leverage polymorphism to delegate
to their containee objects.
