OBJECT ORIENTED SOFTWARE ENGINEERING
Q1. What are the types of integration testing?
There are some different types of integration testing that can be conducted, below is a list
of the different integration testing types;

Big Bang
The way this integration testing type works is, most or all of the modules are integrated
together to form nearly a complete system. This is very similar to system testing as this
basically has a whole system before starting the testing.
There are not many advantages of the big bang integration; the only advantage is that for a
smaller system this will be the ideal integration testing technique.
The disadvantages is that you would have to wait for all the modules to be integrated in
order to do big-bang testing so there will be quite a lot of delay. Any errors are identified at
a very late stage and it is very hard to indentify the fault. It is very difficult to be sure that
all testing has been done before product release.
Bottom Up Testing is an approach to integrated testing where the lowest level components
are tested first, then used to facilitate the testing of higher level components. The process is
repeated until the component at the top of the hierarchy is tested.
All the bottom or low-level modules, procedures or functions are integrated and then tested.
After the integration testing of lower level integrated modules, the next level of modules
will be formed and can be used for integration testing. This approach is helpful only when
all or most of the modules of the same development level are ready. This method also helps
to determine the levels of software developed and makes it easier to report testing progress
in the form of a percentage.
Top Down Testing is an approach to integrated testing where the top integrated modules
are tested and the branch of the module is tested step by step until the end of the related
module.
Sandwich Testing is an approach to combine top down testing with bottom up testing.
Q2. What are the Techniques for requirements elicitation?
Sol: Some techniques for requirement elicitation are:
Interview(Question Answers)
Used for eliciting detailed information from an individual
• For the small projects – may be used as the only requirement elicitation technique
• For large projects – usually a part of some high-level elicitation technique
• Interviewing is not simply a matter of asking questions; it requires development of some
general social skills, the ability to listen, and knowledge of a variety of interviewing tactics
• Overcomes articulation problems and communication barriers
Four phases of interview are:
• Identifying candidates
• Preparing for an interview
• Conducting the interview
• Following up
Brainstorming
Brainstorming is a group or individual creativity technique by which efforts are made to find a
conclusion for a specific problem by gathering a list of ideas spontaneously contributed by its
member(s)
Following these two principles were his four general rules of brainstorming, established with
intention to :

reduce social inhibitions among group members,

stimulate idea generation

increase overall creativity of the group.
FAST(Facilitated Application Specification Technique)
The objective is to close the gap between what the developers intend and what users expect. It is
a team-oriented approach for gathering requirements. This encourages creation of joint team of
customers and developers who work together to identify the problem, purpose elements of
solution, negotiate different approaches and specify a preliminary set of solution.
Basic Guidelines of FAST Meeting are:
o
o
o
A meeting is conducted at a neutral site.
Rules for preparation and participation are established.
An agenda is suggested that is formal enough to cover all important points but informal
enough to encourage free flow of ideas.
o
o
o
A “Facilitator” controls the meeting
A ‘Definition mechanism’ ( like work sheets, wall stickers etc..) is used.
The goal is to identify the problem, purpose elements of the solution, negotiate different
approaches and specify a preliminary set of solution in an atmosphere conducive to
accomplishment of the goal.
QFD (Quality Function deployment)
Quality function deployment (QFD) is a “method to transform qualitative user demands into
quantitative parameters, to deploy the functions forming quality, and to deploy methods for
achieving the design quality into subsystems and component parts Software requirements can be
classified into three categories: Normal, exciting and expected .
1.Normal Requirements are what the stakeholders communicate during traditional facilitated
sessions or in interviews. They cover the base functionality of the application. These requirement
contribute proportionally to customer satisfaction and expectations.
2. Expected requirements: These are implicit to the product or system and may be so fundamental
that the customer may not explicitly state them. Their absence will cause significant dissatisfaction.
3.Exciting Requirements: are aspects which the users do not expect. Often exciting requirements
involve innovation of the business process or new ways of handling functionality.
Use Cases
In software and systems engineering, a use case is a list of steps, typically defining interactions
between a role (known in Unified Modeling Language (UML) as an "actor") and a system, to
achieve a goal. The actor can be a human or an external system.
A use case defines the interactions between external actors and the system under consideration
to accomplish a goal. Actors must be able to make decisions, but need not be human: "An actor
might be a person, a company or organization, a computer program, or a computer system —
hardware, software, or both.
Q3. Explain the requirement elicitation activities.
Requirements Elicitation Activities are
o
o
o
o
o
Identifying Actors
Identifying Use Cases
Identifying Relationships among Actors and Use Cases
Identifying Initial Analysis Objects
Identifying Nonfunctional Requirements
o
o
Identifying Scenarios
Refining Use Cases
Identifying Actors
Actors represent roles
One person can have several roles
Many persons can have the same role
In companies, roles usually exist before system is built.
Identifying Scenarios:
A scenario is a narrative description of what people do and experience as they try to make
computer systems and applications.
Types of scenarios:
o Visionary scenario :Used to describe a future system .
o As- is scenario: Describes current situation
o Evaluation Scenario: describes task against which system is to be evaluated
o Training scenarios: step by step instructions desgined to hand-hold the user through
common tasks.
Identifying Use Cases
o Scenarios are generalized to high-level use cases
o Name
- A verb describing what the actor wants to accomplish
o Initiating actor
- Helps to clarify roles
- Helps identifying previously overlooked actors
o High-level description
- Entry and exit conditions (identify missing cases)
- Event flow (define system boundary)
- Quality requirements (elicit nonfunctional requirements)
Refining Use Cases
Many use cases are rewritten several times
Focus: completeness and correctness
o
o
o
o
o
o
Activities during refinement
Add details to use cases
Specify low-level sequences of interactions
Specify access rights (which actor can invoke which use case)
Identify missing exceptions and specify handling
Factor out common functionality
Identifying Relationships among Actors and Use Cases
Relationships among actors and use cases reduce systems complexity. An association
relationship may exist between actor and use case
Use include relationships to factor out commonly occurring normal activities that are common
to multiple use-cases. Included use-cases are often capable of standing alone as use-cases, and
are usually invoked from other use-cases at predictable points. Example: Printing.
Use extend relationships to document unusual, exceptional, error, and rarely occurring usecases. Extend use-cases generally cannot stand alone, and in general could be invoked from any
point in a number of use cases. Example: Power failure.
Identifying Nonfunctional Requirements
Nonfunctional requirements are defined together with functional requirements because of
dependencies Basic non functional requirement deal with issues like:
o
o
o
o
o
o
o
Quality attributes
Constraints
Usability
Reliability
Performance
Portability
Maintainability
Identifying initial analysis objects
We need to establish a clear terminology to be used by the developer and users. So, developers
identify the participating objects for each use case. The identification of participating objects
results in an initial analysis object model.
Q4. What are Structural things in UML.
Things in the UML
There are four kinds of things in the UML:
1.
2.
3.
4.
Structural things
Behavioral things
Grouping things
Annotational things
These things are the basic object-oriented building blocks of the UML. You use them
to write well-formed models.
Structural Things
Structural things are the nouns of UML models. These are the mostly static parts of a
model, representing elements that are either conceptual or physical. Collectively, the
structural things are called classifiers.
A class is a description of a set of objects that share the same attributes, operations,
relationships, and semantics. A class implements one or more interfaces. Graphically,
a class is rendered as a rectangle, usually including its name, attributes, and
operations,
Class
An interface is a collection of operations that specify a service of a class or
component. An interface therefore describes the externally visible behavior of that
element. An interface might represent the complete behavior of a class or
component or only a part of that behavior. An interface defines a set of operation
specifications (that is, their signatures) but never a set of operation
implementations. The declaration of an interface looks like a class with the keyword
«interface» above the name; attributes are not relevant, except sometimes to show
constants. An interface rarely stands alone, however. An interface provided by a
class to the outside world is shown as a small circle attached to the class box by a
line. An interface required by a class from some other class is shown as a small
semicircle attached to the class box by a line,
Collaboration defines an interaction and is a society of roles and other elements that
work together to provide some cooperative behavior that's bigger than the sum of all
the elements. Collaborations have structural, as well as behavioral, dimensions. A
given class or object might participate in several collaborations. These collaborations
therefore represent the implementation of patterns that make up a system.
Graphically, a collaboration is rendered as an ellipse with dashed lines, sometimes
including only its name
A use case is a description of sequences of actions that a system performs that yield
observable results of value to a particular actor. A use case is used to structure the
behavioral things in a model. A use case is realized by a collaboration. Graphically, a
use case is rendered as an ellipse with solid lines, usually including only its name.
Use case
An active class is a class whose objects own one or more processes or threads and
therefore can initiate control activity. An active class is just like a class except that
its objects represent elements whose behavior is concurrent with other elements.
Graphically, an active class is rendered as a class with double lines on the left and
right; it usually includes its name, attributes, and operations
Active Class
A component is a modular part of the system design that hides its implementation
behind a set of external interfaces. Within a system, components sharing the same
interfaces can be substituted while preserving the same logical behavior. The
implementation of a component can be expressed by wiring together parts and
connectors; the parts can include smaller components. Graphically, a component is
rendered like a class with a special icon in the upper right corner
Component
An artifact is a physical and replaceable part of a system that contains physical
information ("bits"). In a system, you'll encounter different kinds of deployment
artifacts, such as source code files, executables, and scripts. An artifact typically
represents the physical packaging of source or run-time information. Graphically, an
artifact is rendered as a rectangle with the keyword «artifact» above the name,
Artifact
A node is a physical element that exists at run time and represents a computational
resource, generally having at least some memory and, often, processing capability. A
set of components may reside on a node and may also migrate from node to node.
Graphically, a node is rendered as a cube, usually including only its name
Node
Q5. What are Behavioral things in UML?
Behavioral things are the dynamic parts of UML models. These are the verbs of a
model, representing behavior over time and space. In all, there are three primary
kinds of behavioral things.
First, an interaction is a behavior that comprises a set of messages exchanged
among a set of objects or roles within a particular context to accomplish a specific
purpose. The behavior of a society of objects or of an individual operation may be
specified with an interaction. An interaction involves a number of other elements,
including messages, actions, and connectors (the connection between objects).
Graphically, a message is rendered as a directed line, almost always including the
name of its operation
Interaction
Second, a state machine is a behavior that specifies the sequences of states an
object or an interaction goes through during its lifetime in response to events,
together with its responses to those events. The behavior of an individual class or a
collaboration of classes may be specified with a state machine. A state machine
involves a number of other elements, including states, transitions (the flow from
state to state), events (things that trigger a transition), and activities (the response
to a transition). Graphically, a state is rendered as a rounded rectangle, usually
including its name and its substates, if any,
State machine
Third, an activity is a behavior that specifies the sequence of steps a computational
process performs. In an interaction, the focus is on the set of objects that interact.
In a state machine, the focus is on the life cycle of one object at a time. In an
activity, the focus is on the flows among steps without regard to which object
performs each step. A step of an activity is called an action. Graphically, an action is
rendered as a rounded rectangle with a name indicating its purpose. States and
actions are distinguished by their different contexts.
Actions
Q6. What are Different relationships in UML?
There are four kinds of relationships in the UML:
1.
2.
3.
4.
Dependency
Association
Generalization
Realization
These relationships are the basic relational building blocks of the UML. You use them to
write well-formed models.
First, a dependency is a semantic relationship between two model elements in which a
change to one element (the independent one) may affect the semantics of the other
element (the dependent one). Graphically, a dependency is rendered as a dashed line,
possibly directed, and occasionally including a label.
Dependencies
Second, an association is a structural relationship among classes that describes a set of
links, a link being a connection among objects that are instances of the classes.
Aggregation is a special kind of association, representing a structural relationship
between a whole and its parts. Graphically, an association is rendered as a solid line,
possibly directed, occasionally including a label, and often containing other adornments,
such as multiplicity and end names..
Associations
Third, a generalization is a specialization/generalization relationship in which the
specialized element (the child) builds on the specification of the generalized element
(the parent). The child shares the structure and the behavior of the parent. Graphically,
a generalization relationship is rendered as a solid line with a hollow arrowhead pointing
to the parent.
Generalizations
Fourth, a realization is a semantic relationship between classifiers, wherein one classifier
specifies a contract that another classifier guarantees to carry out. You'll encounter
realization relationships in two places: between interfaces and the classes or
components that realize them, and between use cases and the collaborations that realize
them. Graphically, a realization relationship is rendered as a cross between a
generalization and a dependency relationship..
Realizations
Q7. What are different diagrams in UML?
A diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and paths (relationships). You draw diagrams to
visualize a system from different perspectives, so a diagram is a projection into a
system. For all but the most trivial systems, a diagram represents an elided view of the
elements that make up a system. The same element may appear in all diagrams, only a
few diagrams (the most common case), or in no diagrams at all (a very rare case). In
theory, a diagram may contain any combination of things and relationships. In practice,
however, a small number of common combinations arise, which are consistent with the
five most useful views that comprise the architecture of a software-intensive system. For
this reason, the UML includes thirteen kinds of diagrams:
1.
2.
3.
4.
5.
6.
Class diagram
Object diagram
Component diagram
Composite structure diagram
Use case diagram
Sequence diagram
7. Communication diagram
8. State diagram
9. Activity diagram
10. Deployment diagram
11. Package diagram
12. Timing diagram
13. Interaction overview diagram
A class diagram shows a set of classes, interfaces, and collaborations and their
relationships. These diagrams are the most common diagram found in modeling
object-oriented systems. Class diagrams address the static design view of a system.
Class diagrams that include active classes address the static process view of a system.
Component diagrams are variants of class diagrams.
An object diagram shows a set of objects and their relationships. Object diagrams
represent static snapshots of instances of the things found in class diagrams. These
diagrams address the static design view or static process view of a system as do class
diagrams, but from the perspective of real or prototypical cases.
component diagram is shows an encapsulated class and its interfaces, ports, and
internal structure consisting of nested components and connectors. Component
diagrams address the static design implementation view of a system. They are
important for building large systems from smaller parts. (UML distinguishes a composite
structure diagram, applicable to any class, from a component diagram, but we combine
the discussion because the distinction between a component and a structured class is
unnecessarily subtle.)
A use case diagram shows a set of use cases and actors (a special kind of class) and
their relationships. Use case diagrams address the static use case view of a system.
These diagrams are especially important in organizing and modeling the behaviors of a
system.
Both sequence diagrams and communication diagrams are kinds of interaction
diagrams. An interaction diagram shows an interaction, consisting of a set of objects or
roles, including the messages that may be dispatched among them. Interaction
diagrams address the dynamic view of a system. A sequence diagram is an interaction
diagram that emphasizes the time-ordering of messages; a communication diagram is
an interaction diagram that emphasizes the structural organization of the objects or
roles that send and receive messages. Sequence diagrams and communication
diagrams represent similar basic concepts, but each diagram emphasizes a different
view of the concepts. Sequence diagrams emphasize temporal ordering, and
communication diagrams emphasize the data structure through which messages flow.
A timing diagram (not covered in this book) shows the actual times at which messages
are exchanged.
A state diagram shows a state machine, consisting of states, transitions, events, and
activities. A state diagrams shows the dynamic view of an object. They are especially
important in modeling the behavior of an interface, class, or collaboration and
emphasize the event-ordered behavior of an object, which is especially useful in
modeling reactive systems
An activity diagram shows the structure of a process or other computation as the flow
of control and data from step to step within the computation. Activity diagrams address
the dynamic view of a system. They are especially important in modeling the function
of a system and emphasize the flow of control among objects.
A deployment diagram shows the configuration of run-time processing nodes and the
components that live on them. Deployment diagrams address the static deployment
view of architecture. A node typically hosts one or more artifacts.
Q8. What are the various development processes?
Analysis Process
o
o
Creates conceptual picture
Output are requirement model and Analysis model
Requirement Model
o
o
o
Done by use cases in the use case model
Form the basis of construction and testing process
Forms the basis of analysis Model
Requirement model Consist of
o
o
o
A use case model
Interface description
Problem domain model
Analysis Model
o
o
o
o
o
o
o
Basis of system structure
Specify all the logical objects to be included in the system and how
these are related and grouped
Provide input for the construction process
Development of actual system starts with analysis model
Focus on the logical structure
Define the stable, robust and maintainable structure that is also
extensible
Creating analysis model corresponding to assigning functionality of
use cases to objects
Objects in analysis model.
Entity object
Information about an entity object is stored even after a use case
is completed.
Control object
A control object illustrates functionality that is not contained in
any other object in the system
Interface object
Interface objects interact directly with the environment
Dimensions of analysis model
Construction Process
o
o
Develops design model and implementation model
Includes the implementation and results in complete system
Design Model
o
o
o
o
o
Each object will be fully specified
Consider the implementation constraints
More closer to the the Actual source code
Use block term in place of object
Stimuli is sent from one block to another to trigger an execution
Dimensions of Design model
Implementation model
o
o
Consist of annotated source code
Object oriented programming language is desirable since all fundamentals
concepts can easily be mapped onto language constructs
Testing Process
Integrates the system, verifies it and decides whether it should be delivered.
Q9 What is centralized(Fork) and decentralized(Stair) structure for interaction diagram?
Which is better?
Fork: Much of the dynamic behavior is placed in a single object, ususally the control
object. It knows all the other objects and often uses them for direct questions and
commands.
Stair: The dynamic behavior is distributed. Each object delegates some responsibility
to other objects. Each object knows only a few of the other objects and knows which
objects can hepl with a specific behavior.
Object-oriented fans claim that the stair structure is better
the more the responsibility is spread out, the better.
However, this is not always true.
In decentralized control structure the operations have a strong connection. The
operations will always be performed in the same order
Centralized control structure (better support of change)
The operations can change order
New operations can be inserted as a result of new requirements
Fork: Much of the dynamic behavior is placed in a single object, ususally the control
object. It knows all the other objects and often uses them for direct questions and
commands.
Stair: The dynamic behavior is distributed. Each object delegates some responsibility
to other objects. Each object knows only a few of the other objects and knows which
objects can help with a specific behavior.