Course Title: Introduction to Software Engineering

Semester: Spring 2018

Awais Umar
1421-315171

Q 1: What is the fundamental difference between structured analysis

and objected-oriented strategies for requirements analysis?
Ans:
In structured analysis, data objects are modeled in a way that defines their
attributes and relationships. An object-oriented analysis focuses on the definition
of classes and manner in which they collaborate with one another to effect
customer requirements.
Structured Analysis: -
In Structured Analysis, the focus is only on process and procedures. Modeling
techniques used in it are DFD (Data Flow Diagram), Flowcharts etc. This approach
is old and is not preferred.
Object Oriented Analysis: -
Whereas in Object Oriented Analysis, the focus is more on capturing the real
world objects in the current scenario that are of importance to the system. It
stresses more on data structure and less on procedural structure. Without
actually identifying objects, what are you going to interact with, and whose state
will you change. In this approach, objects are identified, their relationships among
each other, possible states that each object can be in, and finally how all objects
collaborate with each other to achieve a broader system goal are identified.

Q 2: What is Data Flow Diagramming? Give Guidelines on Constructing

a DFD-l and II.
Ans:
What are data-flow diagrams?
Data-flow diagrams (DFDs) model a perspective of the system that is most readily
understood by users – the flow of information through the system and the
activities that process this information.
Data-flow diagrams provide a graphical representation of the system that aims to
be accessible to computer specialist and non-specialist users alike. The models
enable software engineers, customers and users to work together effectively
during the analysis and specification of requirements. Although this means that
our customers are required to understand the modeling techniques and
constructs, in data-flow modeling only a limited set of constructs are used, and
the rules applied are designed to be simple and easy to follow. These same rules
and constructs apply to all data-flow diagrams (i.e., for each of the different
software process activities in which DFDs can be used).
A few simple guidelines can aid immeasurably during the derivation of a data
flow diagram: (1) the level 0 data flow diagram should depict the software/system
as a single bubble; (2) primary input and output should be carefully noted; (3)
refinement should begin by isolating candidate processes, data objects, and data
stores to be represented at the next level; (4) all arrows and bubbles should be
labeled with meaningful names; (5) information flow continuity must be
maintained from level to level,2 and (6) one bubble at a time should be refined.
There is a natural tendency to overcomplicate the data flow diagram. This occurs
when you attempt to show too much detail too early or represent procedural
aspects of the software in lieu of information flow.
Q 3: What are coupling and Cohesion? How can coupling and cohesion
lead to either good or poor software component design? Give
examples for each case.
Ans:
Cohesion:
Cohesion is a measure that defines the degree of intra-dependability within
elements of a module. The greater the cohesion, the better is the program design.
Coupling:
Coupling is a measure that defines the level of inter-dependability among
modules of a program. It tells at what level the modules interfere and interact
with each other. The lower the coupling, the better the program.

Cohesion:
Cohesion is the indication of the relationship within module.
Cohesion shows the module’s relative functional strength.
Cohesion is a degree (quality) to which a component / module focuses on the
single thing.
While designing you should strive for high cohesion i.e. a cohesive component/
module focus on a single task (i.e., single-mindedness) with little interaction with
other modules of the system.
Cohesion is the kind of natural extension of data hiding for example, class having
all members visible with a package having default visibility. Cohesion is Intra –
Module Concept.

Coupling:
Coupling is the indication of the relationships between modules.
Coupling shows the relative independence among the modules.
Coupling is a degree to which a component / module is connected to the other
modules.
While designing you should strive for low coupling i.e. dependency between
modules should be less
Making private fields, private methods and nonpublic classes provides loose
coupling.
Coupling is Inter -Module Concept.

Q 4: Describe the four elements of Requirements Analysis models. Is it

possible to develop an effective analysis model without developing all
the four elements? Explain briefly.
Ans:
One view of requirements modeling, called structured analysis, considers data
and the processes that transform the data as separate entities. Data objects are
modeled in a way that defines their attributes and relationships. Processes that
manipulate data objects are modeled in a manner that shows how they transform
data as data objects flow through the system. A second approach to analysis
modeling, called object-oriented analysis, focuses on the definition of classes and
the manner in which they collaborate with one another to effect customer
requirements. UML and the Unified Process (Chapter 2) are predominantly object
oriented. Although the requirements model proposed in this book combines
features of both approaches, software teams often choose one approach and
exclude all representations from the other. The question is not which is best, but
rather, what
combination of representations will provide stakeholders with the best model of
software requirements and the most effective bridge to software design. Each
element of the requirements model (Figure 6.3) presents the problem from a
different point of view. Scenario-based elements depict how the user interacts
with the system and the specific sequence of activities that occur as the software
is used. Class-based elements model the objects that the system will manipulate,
the operations that will be applied to the objects to effect the manipulation,
relationships (some hierarchical) between the objects, and the collaborations that
occur between the classes that are defined. Behavioral elements depict how
external events change the state of the system or the classes that reside within it.
Finally, flow-oriented elements represent the system as an information
transform, depicting how data objects are transformed as they flow through
various system functions.

Q 5: What is Transaction flow and Transform flow? How is a

Transaction center different from a Transform center in a data flow
diagram? Give an example in support of your answer.
Ans:
Transaction flow modeling:
The nodes represent steps in some transaction (e.g., the steps required to make
an airline reservation using an online service), and the links represent the logical
connection between steps (e.g., flightInformationInput is followed by
validationAvailabilityProcessing). The data flow diagram can be used to assist in
creating graphs of this type.
Transform flow
I present a step-by-step “transform” mapping for a small part of the SafeHome
security function.8 In order to perform the mapping, the type of information flow
must be determined. One type of information flow is called transform flow and
exhibits a linear quality

Q 6: Discuss the role of Activity Modeling in Software Engineering.

Draw the activity diagram for an ATM Machine system.
Ans:

Q 7: Describe how to apply Use Cases during the analysis of a system.

Give an example to support your answer.
Ans:
As requirements are gathered, an overall vision of system functions and features
beings to materialize. However, it is difficult to move into more technical software
engineering activates until you understand how these functions and features will
be used by different classes of end users.
Developers and users can create a set of scenarios that identify a thread of usage
for the system to be constructed. The scenarios often called use cases, proved a
description of how the system will be used.
In essence, a use case tells a stylized story about how an end user interacts with
the system under a specific set of circumstances.
The story can be a narrative text, an outline of tasks or interactions, a template-
based description, or a diagrammatic representation.

UML Use Case Diagram

 Arms/ disarms
syst em

Accesses syst em sensors

via Int ernet

homeow ner

Responds t o
alarm event

Encount ers an
error condit ion

syst em Reconf igures sensors

administ rat or and relat ed
syst em f eat ures

A collection of user scenarios that describe the thread of usage of a system

Each scenario is described from the point-of-view of an “actor”—a person or
device that interacts with the software in some way (not necessarily users).
External entities. For example, a machine in four different modes of
programming, test, monitoring and troubleshooting modes. Four actors can be
defined. Programmer, tester, monitor, and troubleshooter. In some cases, the
machine operator can play all of these roles. Or different people can play
different roles.

Q 8: Give comments on the statement given by the Software Engineer

Pressman R. “Software quality is no longer the sole responsibility of
the programmer. It extends to software engineers, project managers,
customers, salespeople, and the SQA group”. '
Ans:
Q 9: What is the difference between a scenario and a use case? When
do you use each construct?
Ans:
A use case represents the actions that are required to enable or abandon a goal.
A use case has multiple “paths” that can be taken by any user at any one time. A
use case scenario is a single path through the use case.
It is difficult to move into more technical software engineering activities until you
understand how these functions and features will be used by different classes of
end users. To accomplish this, developers and users can create a set of scenarios
that identify a thread of usage for the system to be constructed. The scenarios,
often called use cases [Jac92], provide a description of how the system will be
used.

Q 10: Describe four interface design issues present in the

development of most user interfaces.
Ans:

User interface design issues

The user interface design consist of following four issues:

1. Response time of the system

Length and variability are the two important characteristic of the system response
time.

2. User help facilities

The user of each software system needs the help facility or the user manual for
the smooth use of the software.

3. Error information handling

Many error messages and warnings are created which irritate the users as they
are not meaningful. Only the critical problems should be handled.

Error message guidelines are as follows:

The language of error message should be described in plain language i.e. easily
understandable for the users.
For recovering the error, useful advice should be provided.
The error message must have an audible or visual indications like beep, short
flashing or the special error color.
The error messages must indicate any negative result so that the user verifies it.
The wordings of message should not be blamed on the user.
4. Command labeling
The commands and menu labeling must be consistent, easy to understand and
learn.

Q 11: How software testing process a software tester can do by

computing cyclomatic complexity?
Ans:
Cyclomatic complexity is a software metric, used to indicate the complexity of a
program. It is a quantitative measure of the number of linearly independent paths
through a program's source code.
Cyclomatic complexity is a software metric that provides a quantitative measure
of the logical complexity of a program. When used in the context of the basis path
testing method, the value computed for cyclomatic complexity defines the
number of independent paths in the basis set of a program and provides you with
an upper bound for the number of tests that must be conducted to ensure that all
statements have been executed at least once. Cyclomatic complexity has a
foundation in graph theory and provides you with an extremely useful software
metric. Complexity is computed in one of three ways:
1. The number of regions of the flow graph corresponds to the cyclomatic
complexity.
2. Cyclomatic complexity V(G) for a flow graph G is defined as V(G) E
N
2 where E is the number of flow graph edges and N is the number of flow graph
nodes.
3. Cyclomatic complexity V(G) for a flow graph G is also defined as V(G) P

1 where P is the number of predicate nodes contained in the flow graph G.