SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Subject Name: Software Engineering and Testing

Subject Code: U20CST512
Prepared by:
Dr.M.GANESAN /ASSOCIATE PROFESSOR /CSE
Ms. V. SWATHILAKSHMI / AP /CSE
Mrs.R.DEEPA/ AP /CSE

Verified by: Approved by:

UNIT II
Characteristics of a Good Software Design - Coupling and Cohesion – Structured Analysis – Data Flow
Diagrams - Structured and Detailed Design – Object oriented concepts - UML Diagrams - Use case model –
Class diagrams – Interaction diagrams – Activity diagrams – state chart diagrams - Object Oriented Analysis
and Design methodology – Characteristics of a good User Interface – Types – A User Interface Design
methodology.
2 Marks
1. State Software Design.
The software design simply means the idea or principle behind the design. It describes how you plan to
solve the problem of designing software, the logic, or thinking behind how you will design software.
2. Define Coupling and Cohesion.
• “Coupling” describes the relationships between modules, and “cohesion " describes the relationships
within them.
• This means that in a good design, the elements within a module (or class) should have internal cohesion.
3. State DFD and UML.
• Data Flow Diagram (DFD) is a graphical representation of data flow in any system. It can illustrate
incoming data flow, outgoing data flow and store data.
• Data flow diagram describes anything about how data flows through the system. ... Data flow
diagrams illustrate flow of data in the system at various levels.
• Unified Modeling Language (UML) is a general-purpose modelling language. ..... UML is not a
programming language; it is rather a visual language.
• We use UML diagrams to portray the behavior and structure of a system. UML helps software
engineers, businessmen and system architects with modelling, design and analysis.

P a g e |1 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

4. What is meant by Class and Interaction Diagrams?

• Interaction diagrams are models that describe how a group of objects collaborate in some behavior
- typically a single use-case.
• The diagrams show a number of example objects and the messages that are passed between these
objects within the use-case.
• Class diagrams are the main building block in object-oriented modeling. They are used to show the
different objects in a system, their attributes, their operations and the relationships among them. In
the example, a class called “loan account” is depicted.
5. Name the types of User Interface in Software Engineering.
• command line (cli)
• graphical user interface (GUI)
• menu driven (mdi)
• form based (fbi)
• natural language (nli)
6. Write the characteristics of User Interface.
• Simplicity: User Interface design should be simple.
• Consistency: The user interface should have more consistency.
• Intuitiveness: The most important quality of good user interface design is intuitive
• Prevention
• Forgiveness
• Graphical User Interface Design
7. Write a note on Structured Analysis.
• Structural analysis is the process of breaking words down into their basic parts to determine word
meaning.
• When using structural analysis, the reader breaks words down into their basic parts: Prefixes –
word parts located at the beginning of a word to change meaning.
8. What are the characteristics of a Good Software Design?
• Six characteristics of good software design—simplicity, coupling, cohesion, information hiding,
performance, and security—are described.
• This is followed by a description of abstraction as the art of software design.
9. What is coupling?
Coupling is the measure of the degree of interdependence between the modules. Good software
have low coupling.

P a g e |2 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

10. What is cohesion?

Cohesion is a measure of the degree to which the elements of the module are functionally related. It is
the degree to which all elements directed towards performing a single task are contained in the
component.
Basically, cohesion is the internal glue that keeps the module together. A good software design will
have high cohesion.
11. What is structured analysis?
In software engineering, structured analysis and structured design are methods for analyzing business
requirements and developing specifications for converting practices into computer programs, hardware
configurations, and related manual procedures.
12. Define data flow diagram.
A data-flow diagram is a way of representing a flow of data through a process or a system. The DFD also
provides information about the outputs and inputs of each entity and the process itself. A data-flow
diagram has no control flow; there are no decision rules and no loops.
13. What is structured design?
Structured Design is a systematic methodology to determine design specification of software It
covers the four components of software design, namely, architectural design, detail design, data design
and interface design.
14. What is detailed design?
Detailed design deals with the implementation part of what is seen as a system and its sub-systems in
the previous two designs. It is more detailed towards modules and their implementations. It defines
logical structure of each module and their interfaces to communicate with other modules.
15. What is object-oriented concept?
Object-oriented programming is a model that provides different types of concepts, such as
inheritance, abstraction, polymorphism, etc. These concepts aim to implement real-world entities in
programs. They create working methods and variables to reuse them without compromising security.
16. Define UML diagram.
A UML diagram is a diagram based on the UML (Unified Modeling Language) with the purpose of
visually representing a system along with its main actors, roles, actions, artifacts or classes, in order
to better understand, alter, maintain, or document information about the system.
17. Define use case model.
A use-case model is a model of how different types of users interact with the system to solve a
problem. As such, it describes the goals of the users, the interactions between the users and the system,
and the required behavior of the system in satisfying these goals.

P a g e |3 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

18. Define class diagram.

The class diagram is the main building block of object-oriented modeling.
Class diagrams can also be used for data modeling. The classes in a class diagram represent both the main
elements, interactions in the application, and the classes to be programmed.
19. Define interaction diagram. (Feb 2023)
Interaction diagrams are models that describe how a group of objects collaborate in some behavior -
typically a single use-case.
The diagrams show a number of example objects and the messages that are passed between these objects
within the use-case. Interaction diagrams come in two forms, both present in the UML.
20. What is the purpose of an activity diagram?
An activity diagram shows business and software processes as a progression of actions. These actions
can be carried out by people, software components or computers. Activity diagrams are used to describe
business processes and use cases as well as to document the implementation of system processes.
21. Define state chart diagram.
State chart diagram is one of the five UML diagrams used to model the dynamic nature of a system. They
define different states of an object during its lifetime and these states are changed by events. State chart
diagrams are useful to model the reactive systems. Reactive systems can be defined as a system that
responds to external or internal events.
22. What is object-oriented analysis and design?
Object-oriented analysis and design (OOAD) are a software engineering approach that models a
system as a group of interacting objects. Each object represents some entity of interest in the system
being modeled, and is characterized by its class, its state (data elements), and its behavior.
23. What are the characteristics of a good user interface`?
• Simplicity
• Consistency
• Intuitiveness
• Prevention
• Forgiveness
24. Define user interface design technique.

User Interface (UI) Design focuses on anticipating what users might need to do and ensuring that the
interface has elements that are easy to access, understand, and use to facilitate those actions. UI brings
together concepts from interaction design, visual design, and information architecture.

P a g e |4 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

25. What are the elements of Analysis model?

i. Data Dictionary
ii. Entity Relationship Diagram
iii. Data Flow Diagram
iv. State Transition Diagram v. Control Specification
vi. Process specification
26. What is DFD?
Data Flow Diagram depicts the information flow and the transforms that are applied on the data as it
moves from input to output.
27. What is a state transition diagram?
• State transition diagram is basically a collection of states and events. The events cause the system to
change its state.
• It also represents what actions are to be taken on the Occurrence of event.
28. What is a cohesive module?
A cohesive module performs only “one task” in software procedure with little interaction with other
modules. In other words, cohesive module performs only one thing.
29. What are the different types of Cohesion?
i. Coincidentally cohesive –The modules in which the set I\of tasks are related with each other loosely
then such modules are called coincidentally cohesive.
ii. Logically cohesive – A module that performs the tasks that are logically related with each other is
called logically cohesive.
iii. Temporal cohesion – The module in which the tasks need to be executed in some specific time span is
called temporal cohesive.
iv. Procedural cohesion – When processing elements of a module are related with one another and must
be executed in some specific order then such module is called procedural cohesive.
v. Communicational cohesion – When the processing elements of a module share the data then such
module is called communicational cohesive.
23. What is coupling? (Dec 2021)
Coupling is the measure of interconnection among modules in a program structure. It depends on the
interface complexity between modules.
24. What are the various types of coupling? (Dec 2021)
i. Data coupling – The data coupling is possible by parameter passing or data interaction.
ii. Control coupling – The modules share related control data in control coupling.

P a g e |5 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

iii. Common coupling – The common data or a global data is shared among modules. iv. Content
coupling – Content coupling occurs when one module makes use of data or control information
maintained in another module.
25. What is data modeling?
Data modeling is the basic step in the analysis modeling. In data modeling the data objects are examined
independently of processing. The data model represents how data are related with one another.
26. What are the objectives of Analysis modeling?
i. To describe what the customer requires.
ii. To establish a basis for the creation of software design.
iii. To devise a set of valid requirements after which the software can be built.
27. What are the components of class diagram?
Upper section: Contains the name of the class. This section is always required, whether you are talking
about the classifier or an object.
Middle section: Contains the attributes of the class. ...
Bottom section: Includes class operations (methods).
28. What are the components of activity diagram?
Action: A step in the activity wherein the users or software perform a given task. ...
Decision node: A conditional branch in the flow that is represented by a diamond. ...
Control flows: Another name for the connectors that show the flow between steps in the diagram.
29. What are the components of state chart diagram?
Choice pseudo state. A diamond symbol that indicates a dynamic condition with branched potential
results.
• Event. An instance that triggers a transition, labelled above the applicable transition arrow.
• Exit point.
• First state.
• State.
• Terminator.
• Transition.
• Trigger.
30. What are the types of user interface?
• Command Line Interface.
• Menu-driven Interface.
• Graphical User Interface.

P a g e |6 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

• Touchscreen Graphical User Interface.

31. What are user interface and its types?

User Interface Design
The visual part of a computer application or operating system through which a client interacts with
computer or software. It determines how commands are given to the computer or the program and how
data is displayed on the screen.
Types of User Interface
There are two main types of User Interface:
• Text-Based User Interface or Command Line Interface
• Graphical User Interface (GUI)
32. What is Object Oriented Methodology?
• It is a new system development approach, encouraging and facilitating re-use of software components.
• It employs the international standard Unified Modeling Language (UML) from the Object Management
Group (OMG).
• Using this methodology, a system can be developed on a component basis, which enables the effective
re-use of existing components, and facilitates the sharing of its other system components.
• Object Oriented Methodology asks the analyst to determine what the objects of the system are?, What
responsibilities and relationships an object has to do with the other objects? and How do they behave
over time?
33. What are three types of Object-Oriented Methodologies?
• Object Modeling Techniques (OMT)
• Object Process Methodology (OPM)
• Rational Unified Process (RUP)
34. Difference between State Machine and Flowchart

State Machine Flowchart

It portrays several states of a system. It demonstrates the execution flow of a

program.

It encompasses the concept of WAIT, i.e., wait for an It does not constitute the concept of WAIT.
event or an action.

P a g e |7 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

It is for real-world modeling systems. It envisions the branching sequence of a

system.

It is a modeling diagram. It is a data flow diagram (DFD)

It is concerned with several states of a system. It focuses on control flow and path.

35. what are the Characteristics of user interface.

• Simplicity: User Interface design should be simple.
• Consistency: The user interface should have more consistency.
• Intuitiveness: The most important quality of good user interface design is intuitive.
• Prevention
• Forgiveness
• Graphical User Interface Design
36. Define Modularity. (Dec 2021)
• Modularity refers to the compartmentalization and interrelation of the parts of a software package.
• In software design, modularity refers to a logical partitioning of the "software design" that allows
complex software to be manageable for the purpose of implementation and maintenance.
30. What are the characteristics of a good software design. (Feb 2023)
Six characteristics of good software design:
simplicity, coupling, cohesion, information hiding, performance, and security.

P a g e |8 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

5 Marks
1. Describe in detail about coupling and its types.
Coupling: -
Module Coupling

In software engineering, the coupling is the degree of interdependence between software modules. Two
modules that are tightly coupled are strongly dependent on each other. However, two modules that are
loosely coupled are not dependent on each other. Uncoupled modules have no interdependence at all
within them.

The various types of coupling techniques are shown in fig:

Figure: Types of coupling techniques

A good design is the one that has low coupling. Coupling is measured by the number of relations
between the modules. That is, the coupling increases as the number of calls between modules increase
or the amount of shared data is large. Thus, it can be said that a design with high coupling will have more
errors.

Types of Module Coupling

P a g e |9 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Figure: Types of Module Coupling

1. No Direct Coupling: There is no direct coupling between M1 and M2.

In this case, modules are subordinates to different modules. Therefore, no direct coupling.
2. Data Coupling: When data of one module is passed to another module, this is called data coupling.

3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite data items
such as structure, objects, etc. When the module passes non-global data structure or entire structure to

P a g e | 10 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

another module, they are said to be stamp coupled. For example, passing structure variables in C or
objects in C++ language to a module.
4. Control Coupling: Control Coupling exists among two modules if data from one module is used to
direct the structure of instruction execution in another.
5. External Coupling: External Coupling arises when two modules share an externally imposed data
format, communication protocols, or device interface. This is related to communication to external tools
and devices.
6. Common Coupling: Two modules are commonly coupled if they share information through some
global data items.

7. Content Coupling: Content Coupling exists among two modules if they share code, e.g., a branch from
one module into another module.
2. Discuss in detail about Cohesion.
Module Cohesion
In computer programming, cohesion defines the degree to which the elements of a module belong
together. Thus, cohesion measures the strength of relationships between pieces of functionality within a
given module. For example, in highly cohesive systems, functionality is strongly related.
Cohesion is an ordinal type of measurement and is generally described as "high cohesion" or "low
cohesion."

P a g e | 11 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Types of Modules Cohesion

Figure:Types of Modules Cohesion

1) Functional Cohesion: Functional Cohesion is said to exist if the different elements of a module
cooperate to achieve a single function.
2) Sequential Cohesion: A module is said to possess sequential cohesion if the element of a module forms
the components of the sequence, where the output from one component of the sequence is input to the
next.
3) Communicational Cohesion: A module is said to have communicational cohesion, if all tasks of the
module refer to or update the same data structure, e.g., the set of functions defined on an array or a
stack.

P a g e | 12 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

4) Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of the module
are all parts of a procedure in which a particular sequence of steps has to be carried out for achieving a
goal, e.g., the algorithm for decoding a message.
5) Temporal Cohesion: When a module includes functions that are associated by the fact that all the
methods must be executed at the same time, the module is said to exhibit temporal cohesion.
6) Logical Cohesion: A module is said to be logically cohesive if all the elements of the module perform a
similar operation. For example, Error handling, data input and data output, etc.
7) Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a set of tasks that
are associated with each other very loosely, if at all.
3. Describe in detail about Use-Case Model.
The Use-case model is defined as a model which is used to show how users interact with the system to
solve a problem. As such, the use case model defines the user's objective, the interactions between the
system and the user, and the system's behavior required to meet these objectives.
Various model elements are contained in the use-case model, such as actors, use cases, and the
association between them.
We use a use-case diagram to graphically portray a subset of the model in order to make the
communication simpler. There will regularly be a numerous use-case diagram which is related to the
given model, each demonstrating a subset of the model components related to a specific purpose. A similar
model component might be appearing on a few use-case diagrams; however, each use-case should be
consistent. If, in order to handle the use-case model, tools are used then this consistency restriction is
automated so that any variations to the component of the model (changing the name, for instance) will be
reflected automatically on each use-case diagram, which shows that component.
Packages may include a use-case model, which is used to organize the model to simplify the analysis,
planning, navigation, communication, development, and maintenance.
Various use-case models are textual, and the text captured in the use-case specifications, which are linked
with the element of every use-case model. The flow of events of the use case is described with the help of
these specifications.
The use-case model acts as an integrated thread in the development of the entire system. The use-case
model is used like the main specification of the system functional requirements as the basis for design and
analysis, as the basis for user documentation, as the basis of defining test cases, and as an input to
iteration planning.

P a g e | 13 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Basic Use-Case Diagram Symbols and Notations

There are following use-case diagram symbols and notations:
System
With the help of the rectangle, we can draw the boundaries of the system, which includes use-cases. We
need to put the actors outside the system's boundaries.

Use-Case
With the help of the Ovals, we can draw the use-cases. With the verb we have to label the ovals in order
to represent the functions of the system.

Actors
Actors mean the system's users. If one system is the actor of the other system, then with the actor
stereotype, we must tag the actor system.

Relationships
With the simple line we can represent relationships between an actor and use cases. For relationships
between use-case, we use arrows which are labeled either "extends" or "uses". The "extends"
relationship shows the alternative options under the specific use case. The "uses" relationship shows
that single use-case is required to accomplish a job.

P a g e | 14 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Use-Case Example-Association Link

In this use-case diagram, we show a group of use cases for a system which means the relationship
among the use-cases and the actor.

Use-Case Example-Include Relationship

To add additional functionality that is not specified in the base use-case, we use to include relationships.
We use it to comprise the general behavior from an included use case into a base case so that we can
support the reuse general behavior.

Use-Case Example-Extend Relationship

With the help of the extend relationship, we can show the system behavior or optional functionality. We
use <<extend>> relationship in order to comprise optional behavior from an extending use-case in an
extended use-case. For example, the below diagram of the use-case displays an extend connector and an
extension point "Search".

P a g e | 15 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Use-Case Example-Generalization Relationship

In the generalization relationship, the child use-case can inherit the meaning and behavior of the parent
use-case. The child use-case is able to override and add the parent's behavior. The below diagram is an
example of a generalization relationship in which two generalization connectors are connected among
three use-cases.

Use-Case Diagram-Vehicle Sales Systems

The below diagram displays an instance of a use-case diagram for a vehicle system. As we can also see, a
system as much as one vehicle sales system contains not in excess of 10 use-cases, and it is the delicacy of
use-case modeling.

P a g e | 16 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

The use of include and extend is also displayed by the use-case model. In addition, there are associations
that link between the use-case and actors.
4. Explain in details about Class diagram.
Class diagram is a static diagram. It represents the static view of an application. Class diagram is not only
used for visualizing, describing, and documenting different aspects of a system but also for constructing
executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints imposed on the
system. The class diagrams are widely used in the modeling of object oriented systems because they are
the only UML diagrams, which can be mapped directly with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and constraints. It is
also known as a structural diagram.
Purpose of Class Diagrams
The purpose of the class diagram is to model the static view of an application. Class diagrams are the
only diagrams which can be directly mapped with object-oriented languages and thus widely used at the
time of construction.
UML diagrams like activity diagram, sequence diagrams can only give the sequence flow of the
application, and however the class diagram is a bit different. It is the most popular UML diagram in the
coder community.
The purpose of the class diagram can be summarized as −
• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.
How to Draw a Class Diagram?
Class diagrams are the most popular UML diagrams used for construction of software applications. It is
very important to learn the drawing procedure of class diagram.
Class diagrams have a lot of properties to consider while drawing but here the diagram will be
considered from a top-level view.
Class diagram is basically a graphical representation of the static view of the system and represents
different aspects of the application. A collection of class diagrams represents the whole system.
The following points should be remembered while drawing a class diagram −
• The name of the class diagram should be meaningful to describe the aspect of the system.

P a g e | 17 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

• Each element and their relationships should be identified in advance.

• Responsibility (attributes and methods) of each class should be clearly identified
• For each class, a minimum number of properties should be specified, as unnecessary properties
will make the diagram complicated.
• Use notes whenever required to describe some aspect of the diagram. At the end of the drawing it
should be understandable to the developer/coder.
• Finally, before making the final version, the diagram should be drawn on plain paper and reworked
as many times as possible to make it correct.
The following diagram is an example of an Order System of an application. It describes a particular
aspect of the entire application.
• First, Order and Customer are identified as the two elements of the system. They have a one-to-
many relationship because a customer can have multiple orders.
• Order class is an abstract class and it has two concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.
• The two inherited classes have all the properties as the Order class. In addition, they have
additional functions like dispatch () and receive ().
The following class diagram has been drawn considering all the points mentioned above.

Figure: Class diagram

In a nutshell it can be said, class diagrams are used for −
• Describing the static view of the system.
• Showing the collaboration among the elements of the static view.
• Describing the functionalities performed by the system.

P a g e | 18 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

• Construction of software applications using object-oriented languages.

5. Describe in detail about Interaction Diagrams.
Interaction Diagrams
From the term Interaction, the diagram is used to describe some type of interactions among the different
elements in the model. This interaction is a part of dynamic behavior of the system.
This interactive behavior is represented in UML by two diagrams known as Sequence diagram and
Collaboration diagram. The basic purpose of both the diagrams are similar.
Sequence diagram emphasizes on time sequence of messages and collaboration diagram emphasizes on
the structural organization of the objects that send and receive messages.

Purpose of Interaction Diagrams

The purpose of interaction diagrams is to visualize the interactive behavior of the system. Visualizing the
interaction is a difficult task. Hence, the solution is to use different types of models to capture the different
aspects of the interaction.
Sequence and collaboration diagrams are used to capture the dynamic nature but from a different angle.
The purpose of interaction diagram is −
• To capture the dynamic behaviour of a system.
• To describe the message flow in the system.
• To describe the structural organization of the objects.
• To describe the interaction among objects.

How to Draw an Interaction Diagram?

As we have already discussed, the purpose of interaction diagrams is to capture the dynamic aspect of a
system. So, to capture the dynamic aspect, we need to understand what a dynamic aspect is and how it is
visualized. Dynamic aspect can be defined as the snapshot of the running system at a particular moment
We have two types of interaction diagrams in UML. One is the sequence diagram and the other is the
collaboration diagram. The sequence diagram captures the time sequence of the message flow from one
object to another and the collaboration diagram describes the organization of objects in a system taking
part in the message flow.
Following things are to be identified clearly before drawing the interaction diagram
• Objects taking part in the interaction.
• Message flows among the objects.
• The sequence in which the messages are flowing.

P a g e | 19 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

• Object organization.
Following are two interaction diagrams modeling the order management system. The first diagram is a
sequence diagram and the second is a collaboration diagram
The Sequence Diagram
The sequence diagram has four objects (Customer, Order, SpecialOrder and NormalOrder).
The following diagram shows the message sequence for the SpecialOrder object and the same can be used
in the case of the NormalOrder object. It is important to understand the time sequence of message flows.
The message flow is nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call is confirm () which is a
method of the SpecialOrder object and the last call is Dispatch () which is a method of the SpecialOrder
object. The following diagram mainly describes the method calls from one object to another, and this is
also the actual scenario when the system is running.

Figure: Sequence Diagram

The Collaboration Diagram
The second interaction diagram is the collaboration diagram. It shows the object organization as seen in
the following diagram. In the collaboration diagram, the method call sequence is indicated by some
numbering technique. The number indicates how the methods are called one after another. We have
taken the same order management system to describe the collaboration diagram.
Method calls are like that of a sequence diagram. However, the difference being the sequence diagram
does not describe the object organization, whereas the collaboration diagram shows the object
organization.

P a g e | 20 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

To choose between these two diagrams, emphasis is placed on the type of requirement. If the time
sequence is important, then the sequence diagram is used. If organization is required, then a
collaboration diagram is used.

Figure: Collaboration Diagram

6. Explain in detail about Activity diagram.

Activity diagram
Activity diagram is another important diagram in UML to describe the dynamic aspects of the system.
Activity diagram is basically a flowchart to represent the flow from one activity to another activity. The
activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be sequential, branched, or
concurrent. Activity diagrams deal with all type of flow control by using different elements such as fork,
join, etc
Purpose of Activity Diagrams
The basic purpose of activity diagrams is similar to the other four diagrams. It captures the dynamic
behavior of the system. Other four diagrams are used to show the message flow from one object to
another, but the activity diagram is used to show message flow from one activity to another.
Activity is a particular operation of the system. Activity diagrams are not only used for visualizing the
dynamic nature of a system, but they are also used to construct the executable system by using forward
and reverse engineering techniques.
The only missing thing in the activity diagram is the message part. It does not show any message flow
from one activity to another. Activity diagram is sometimesconsidered as the flowchart. Although the
diagrams look like a flowchart, they are not. It shows differentflows such as parallel, branched,
concurrent, and single.
The purpose of an activity diagram can be described as −

P a g e | 21 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

• Draw the activity flow of a system.

• Describe the sequence from one activity to another.
• Describe the parallel, branched and concurrent flow of the system.
How to Draw an Activity Diagram?
Activity diagrams are mainly used as a flowchart that consists of activities performed by the system.
Activity diagrams are not exactly flowcharts as they have some additional capabilities. These additional
capabilities include branching, parallel flow, swimlane, etc.
Before drawing an activity diagram, we must have a clear understanding about the elements used in the
activity diagram. The main element of an activity diagram is the activity itself. An activity is a function
performed by the system. After identifying the activities, we need to understand how they are
associated with constraints and conditions.
Before drawing an activity diagram, we should identify the following elements −
• Activities
• Association
• Conditions
• Constraints
Once the above-mentioned parameters are identified, we need to make a mental layout of the entire
flow. This mental layout is then transformed into an activity diagram.
Following is an example of an activity diagram for an order management system. In the diagram, four
activities are identified which are associated with conditions. One important point should be clearly
understood that an activity diagram cannot be exactly matched with the code. The activity diagram is
made to understand the flow of activities and is mainly used by the business users
Following diagram is drawn with the four main activities −
• Send order by the customer
• Receipt of the order
• Confirm the order
• Dispatch the order
After receiving the order request, condition checks are performed to check if it is normal or special
order. After the type of order is identified, dispatch activity is performed and that is marked as the
termination of the process.

P a g e | 22 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Figure: Activity Diagram

Where to Use Activity Diagrams?
The basic usage of the activity diagram is similar to the other four UML diagrams. The specific usage is to
model the control flow from one activity to another. This control flow does not include messages.
Activity diagram is suitable for modeling the activity flow of the system. An application can have multiple
systems. Activity diagram also captures these systems and describes the flow from one system to another.
This specific usage is not available in other diagrams. These systems can be databases, external queues, or
any other system.
We will now look into the practical applications of the activity diagram. From the above discussion, an
activity diagram is drawn from a very high level. So it gives a high level view of a system. This high-level
view is mainly for business users or any other person who is not a technical person.
This diagram is used to model the activities which are nothing but business requirements. The diagram
has more impact on business understanding rather than on implementation details.
Activity diagram can be used for −
• Modeling workflow by using activities.
• Modeling business requirements.
• High level understanding of the system's functionalities.
• Investigating business requirements at a later stage.
7. Describe in detail about State Chart Diagrams.
State Chart Diagrams: -
The name of the diagram itself clarifies the purpose of the diagram and other details. It describes different
states of a component in a system. The states are specific to a component/object of a system.

P a g e | 23 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

A State chart diagram describes a state machine. State machine can be defined as a machine which defines
different states of an object and these states are controlled by external or internal events.
Activity diagram explained in the next chapter, is a special kind of a state chart diagram. As the State chart
diagram defines the states, it is used to model the lifetime of an object.
Purpose of State chart Diagrams
State chart diagram is one of the five UML diagrams used to model the dynamic nature of a system. They
define different states of an object during its lifetime and these states are changed by events. State chart
diagrams are useful to model the reactive systems. Reactive systems can be defined as a system that
responds to external or internal events.
State chart diagram describes the flow of control from one state to another state. States are defined as a
condition in which an object exists and it changes when some event is triggered. The most important
purpose of a State chart diagram is to model the lifetime of an object from creation to termination.
State chart diagrams are also used for forward and reverse engineering of a system. However, the main
purpose is to model the reactive system.
Following are the main purposes of using State chart diagrams −
• To model the dynamic aspect of a system.
• To model the lifetime of a reactive system.
• To describe different states of an object during its lifetime.
• Define a state machine to model the states of an object.

How to Draw a State chart Diagram?

State chart diagram is used to describe the states of different objects in its life cycle. Emphasis is placed on
the state changes upon some internal or external events. These states of objects are important to analyze
and implement them accurately.
State chart diagrams are very important for describing the states. States can be identified as the condition
of objects when a particular event occurs.
Before drawing a state chart diagram, we should clarify the following points −
• Identify the important objects to be analyzed.
• Identify the states.
• Identify the events.
Following is an example of a state chart diagram where the state of Order object is analyzed

P a g e | 24 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

The first state is an idle state from where the process starts. The next states are arrived for events like
send request, confirm request, and dispatch order. These events are responsible for the state changes of
order objects.
During the life cycle of an object (here order object) it goes through the following states and there may be
some abnormal exits. This abnormal exit may occur due to some problem in the system. When the entire
life cycle is complete, it is considered as a complete transaction as shown in the following figure. The
initial and final state of an object is also shown in the following figure.

Figure: State chart Diagram

Where to Use State chart Diagrams?

State chart diagrams are used to model the states and also the events operating on the system. When
implementing a system, it is very important to clarify different states of an object during its lifetime and
State chart diagrams are used for this purpose. When these states and events are identified, they are used
to model it and these models are used during the implementation of the system.
If we look into the practical implementation of the State chart diagram, then it is mainly used to analyze
the object states influenced by events. This analysis is helpful to understand the system behavior during
its execution.
The main usage can be described as −
• To model the object states of a system.
• To model the reactive system. Reactive system consists of reactive objects.
• To identify the events responsible for state changes.
• Forward and reverse engineering.

P a g e | 25 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

8.Explain in detail about Data Flow Diagrams

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within a
system. A neat and clear DFD can depict the right amount of the system requirement graphically. It can be
manual, automated, or a combination of both.
The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be used as a
communication tool between a system analyst and any person who plays a part in the order that acts as a
starting point for redesigning a system. The DFD is also called as a data flow graph or bubble chart.
The following observations about DFDs are essential:
1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the order of events;
arrows in DFD represents flowing data. A DFD does not involve any order of events.
3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in a DFD, suppress
that urge! A diamond-shaped box is used in flow charts to represents decision points with multiple
exists paths of which the only one is taken. This implies an ordering of events, which makes no sense in
a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling until the end of
the analysis.
Standard symbols for DFDs are derived from the electric circuit diagram analysis and are shown in fig:

P a g e | 26 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.
Data Flow: A curved line shows the flow of data into or out of a process or data store.
Data Store: A set of parallel lines shows a place for the collection of data items. A data store indicates that
the data is stored which can be used at a later stage or by the other processes in a different order. The
data store can have an element or group of elements.
Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or sink of
system outputs.
Levels in Data Flow Diagrams (DFD)
The DFD may be used to perform a system or software at any level of abstraction. Infact, DFDs may be
partitioned into levels that represent increasing information flow and functional detail. Levels in DFD are
numbered 0, 1, 2 or beyond. Here, we will see primarily three levels in the data flow diagram, which are:
0-level DFD, 1-level DFD, and 2-level DFD.
0- level DFDM

It is also known as fundamental system model, or context diagram represents the entire software
requirement as a single bubble with input and output data denoted by incoming and outgoing arrows.
Then the system is decomposed and described as a DFD with multiple bubbles. Parts of the system
represented by each of these bubbles are then decomposed and documented as more and more detailed
DFDs. This process may be repeated at as many levels as necessary until the program at hand is well
understood. It is essential to preserve the number of inputs and outputs between levels, this concept is
called leveling by DeMacro. Thus, if bubble "A" has two inputs x1 and x2 and one output y, then the
expanded DFD, that represents "A" should have exactly two external inputs and one external output as
shown in fig:

The Level-0 DFD, also called context diagram of the result management system is shown in fig. As the
bubbles are decomposed into less and less abstract bubbles, the corresponding data flow may also be
needed to be decomposed.

P a g e | 27 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

1- level DFD

In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this level, we
highlight the main objectives of the system and breakdown the high-level process of 0-level DFD into
subprocesses.

P a g e | 28 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

2- Level DFD

2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project or record the
specific/necessary detail about the system's functioning.

P a g e | 29 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

P a g e | 30 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

P a g e | 31 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

P a g e | 32 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

9.Define the concepts of cohesion and coupling. State the difference. (Feb 2023)
Cohesion:
Cohesion is the indication of the relationship within the module. It is the concept of intra-module.
Cohesion has many types but usually, high cohesion is good for software.
Coupling:
Coupling is also the indication of the relationships between modules. It is the concept of the Inter-module.
The coupling has also many types but usually, the low coupling is good for software.

Cohesion coupling
Cohesion is the concept of intra-module. Coupling is the concept of inter-
module.
Cohesion represents the relationship within Coupling represents the relationships
a module. between modules.
Increasing cohesion is good for software. Increasing coupling is avoided for
software.
Cohesion represents the functional strength Coupling represents the
of modules. independence among modules.
Highly cohesive gives the best software. Whereas loosely coupling gives the
best software.

P a g e | 33 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

10 Marks
1. EXPLAIN IN DETAIL ABOUT SOFTWARE DESIGN CONCEPTS.
What is Software Design?
Software design is a process to transform user requirements into some suitable form, which helps the
programmer in software coding and implementation.
For assessing user requirements, an SRS (Software Requirement Specification) document is created
whereas for coding and implementation, there is a need for more specific and detailed requirements in
software terms. The output of this process can directly be used in implementation in programming
languages.
Software design is the first step in SDLC (Software Design Life Cycle), which moves the concentration from
problem domain to solution domain. It tries to specify how to fulfill the requirements mentioned in SRS.
Software Design Levels: -
Software design yields three levels of results:

• Architectural Design - The architectural design is the highest abstract version of the system. It identifies
the software as a system with many components interacting with each other. At this level, the designers
get the idea of the proposed solution domain.
• High-level Design- The high-level design breaks the ‘single entity-multiple component’ concept of
architectural design into a less-abstracted view of subsystems and modules.
and depicts their interaction with each other. High-level design focuses on how the system along with all
of its components can be implemented in forms of modules. It recognizes the modular structure of each
sub-system and their relation and interaction among each other.
• Detailed Design- Detailed design deals with the implementation part of what is seen as a system and its
sub-systems in the previous two designs. It is more detailed towards modules and their
implementations. It defines the logical structure of each module and their interfaces to communicate
with other modules.
Characteristics of Good Software Design:-
For good quality software to be produced, the software design must also be of good quality. Now, the
matter of concern is how the quality of good software design is measured? This is done by observing
certain factors in software design. These factors are:

1) Correctness
2) Understandability
3) Efficiency
4) Maintainability

P a g e | 34 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Now, let us define each of them in detail,

1) Correctness
First of all, the design of any software is evaluated for its correctness. The evaluators check the software
for every kind of input and action and observe the results that the software will produce according to the
proposed design. If the results are correct for every input, the design is accepted and is considered that
the software produced according to this design will function correctly.

2) Understandability
The software design should be understandable so that the developers do not find any difficulty to
understand it. Good software design should be self- explanatory. This is because there are hundreds and
thousands of developers that develop different modules of the software, and it would be very time
consuming to explain each design to each developer. So, if the design is easy and self- explanatory, it
would be easy for the developers to implement it and build the same software that is represented in the
design.

3) Efficiency
The software design must be efficient. The efficiency of the software can be estimated from the design
phase itself, because if the design is describing software that is not efficient and useful, then the
developed software would also stand on the same level of efficiency. Hence, for efficient and good quality
software to be developed, care must be taken in the designing phase itself.

4) Maintainability
The software design must be in such a way that modifications can be easily made in it. This is because
every software needs time to time modifications and maintenance. So, the design of the software must
also be able to bear such changes. It should not be the case that after making some modifications the
other features of the software start misbehaving. Any change made in the software design must not
affect the other available features, and if the features are getting affected, then they must be handled
properly.

2) DESCRIBE IN DETAIL ABOUT COUPLING AND COHESION.

Coupling: -
Module Coupling

In software engineering, the coupling is the degree of interdependence between software modules. Two
modules that are tightly coupled are strongly dependent on each other. However, two modules that are

P a g e | 35 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

loosely coupled are not dependent on each other. Uncoupled modules have no interdependence at all
within them.

The various types of coupling techniques are shown in fig:

Figure: types of coupling techniques

A good design is the one that has low coupling. Coupling is measured by the number of relations
between the modules. That is, the coupling increases as the number of calls between modules increase
or the amount of shared data is large. Thus, it can be said that a design with high coupling will have more
errors.

Types of Module Coupling

P a g e | 36 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

1. No Direct Coupling: There is no direct coupling between M1 and M2.

In this case, modules are subordinates to different modules. Therefore, no direct coupling.

2. Data Coupling: When data of one module is passed to another module, this is called data coupling.

3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite data items
such as structure, objects, etc. When the module passes non-global data structure or entire structure to
another module, they are said to be stamp coupled. For example, passing structure variables in C or
objects in C++ language to a module.
4. Control Coupling: Control Coupling exists among two modules if data from one module is used to
direct the structure of instruction execution in another.
5. External Coupling: External Coupling arises when two modules share an externally imposed data
format, communication protocols, or device interface. This is related to communication to external tools
and devices.
6. Common Coupling: Two modules are commonly coupled if they share information through some
global data items.

P a g e | 37 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

7. Content Coupling: Content Coupling exists among two modules if they share code, e.g., a branch from
one module into another module.
Cohesion
Module Cohesion
In computer programming, cohesion defines the degree to which the elements of a module belong
together. Thus, cohesion measures the strength of relationships between pieces of functionality within a
given module. For example, in highly cohesive systems, functionality is strongly related.
Cohesion is an ordinal type of measurement and is generally described as "high cohesion" or "low
cohesion."

P a g e | 38 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Types of Modules Cohesion

8) Functional Cohesion: Functional Cohesion is said to exist if the different elements of a module
cooperate to achieve a single function.
9) Sequential Cohesion: A module is said to possess sequential cohesion if the element of a module forms
the components of the sequence, where the output from one component of the sequence is input to the
next.
10)Communicational Cohesion: A module is said to have communicational cohesion, if all tasks of the
module refer to or update the same data structure, e.g., the set of functions defined on an array or a
stack.
11)Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of the module
are all parts of a procedure in which a particular sequence of steps has to be carried out for achieving a
goal, e.g., the algorithm for decoding a message.
12)Temporal Cohesion: When a module includes functions that are associated by the fact that all the
methods must be executed at the same time, the module is said to exhibit temporal cohesion.
13)Logical Cohesion: A module is said to be logically cohesive if all the elements of the module perform a
similar operation. For example, Error handling, data input and data output, etc.

P a g e | 39 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

14)Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a set of tasks that
are associated with each other very loosely, if at all.
3. DISCUSS IN DETAILS ABOUT STRUCTURED ANALYSIS?
What is Structured Analysis?
Structured Analysis is a development method that allows the analyst to understand the system and its
activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an
existing system and develop a new system specification which can be easily understandable by the user.
It has following attributes −
• It is a graphic which specifies the presentation of the application.
• It divides the processes so that it gives a clear picture of system flow.
• It is logical rather than physical i.e The elements of a system do not depend on the vendor or hardware.
• It is an approach that works from high-level overviews to lower-level details.
Structured Analysis Tools
During Structured Analysis, various tools and techniques are used for system development. They are −
• Data Flow Diagrams
• Data Dictionary
• Decision Trees
• Decision Tables
• Structured English
Pseudocode

P a g e | 40 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Data Flow Diagrams (DFD) or Bubble Chart

It is a technique developed by Larry Constantine to express the requirements of a system in a graphical

form.
• It shows the flow of data between various functions of the system and specifies how the current
system is implemented.
• It is an initial design phase that functionally divides the requirement specifications down to the
lowest level of detail.
• Its graphical nature makes it a good communication tool between user and analyst or analyst and
system designer.
• It gives an overview of what data a system processes, what transformations are performed, what data
are stored, what results are produced and where they flow.
Basic Elements of DFD

DFD is easy to understand and quite effective when the required design is not clear and the user wants a
notational language for communication. However, it requires a large number of iterations for obtaining
the most accurate and complete solution.

The following table shows the symbols used in designing a DFD and their significance −

Symbol Name Symbol Meaning

Squaíe Souíce oí Destination of Data

Aííow Data flow

Ciícle Píocess tíansfoíming data flow

P a g e | 41 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Open Rectangle Data Stoíe

Types of DFD

DFDs are of two types: Physical DFD and Logical DFD. The following table lists the points that
differentiate a physical DFD from a logical DFD.

Physical DÏD Logical DÏD

It is implementation dependent. It It is implementation independent. It

shows which functions are performed. focuses only on the flow of data between
processes.

It provides low level details of It explains events of systems and data

hardware, software, files, and people. required by each event.

It depicts how the current system It shows how business operates; not how
operates and how a system will be the system can be implemented.
implemented.

Structured Design

Structured design is a conceptualization of a problem into several well-organized elements of solution. It

is basically concerned with the solution design. Benefit of structured design is, it gives a better
understanding of how the problem is being solved. Structured design also makes it simpler for designers
to concentrate on the problem more accurately.

Structured design is mostly based on the ‘divide and conquer’ strategy where a problem is broken into
several small problems and each small problem is individually solved until the whole problem is solved.

P a g e | 42 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

The small pieces of the problem are solved by means of solution modules. Structured design emphasis
that these modules be well organized to achieve precise solutions.

These modules are arranged in hierarchy. They communicate with each other. A good, structured design
always follows some rules for communication among multiple modules, namely -

Cohesion - grouping of all functionally related elements.

Coupling - communication between different modules.

A good, structured design has high cohesion and low coupling arrangements.

Object Oriented Design

Object oriented design works around the entities and their characteristics instead of functions involved
in the software system. This design strategy focuses on entities and its characteristics. The whole
concept of software solution revolves around the engaged entities.

Let us see the important concepts of Object Oriented Design:

● Objects - All entities involved in the solution design are known as objects. For example, people,
banks, companies and customers are treated as objects. Every entity has some attributes associated
with it and has some methods to perform on the attributes.
● Classes - A class is a generalized description of an object. An object is an instance of a class. Class
defines all the attributes, which an object can have and methods, which defines the functionality of
the object.
In the solution design, attributes are stored as variables and functionalities are defined by means of
methods or procedures.
● Encapsulation - In OOD, the attributes (data variables) and methods (operation on the data) are
bundled together is called encapsulation. Encapsulation not only bundles important information of
an object together, but also restricts access of the data and methods from the outside world. This is
called information hiding.
● Inheritance - OOP allows similar classes to stack up in hierarchical manner where the lower or sub-
classes can import, implement and re-use allowed variables and methods from their immediate
super classes. This property of WOOD is known as inheritance. This makes it easier to define specific
classes and to create generalized classes from specific ones.
● Polymorphism - OOP languages provide a mechanism where methods performing similar tasks but
vary in arguments, can be assigned the same name. This is called polymorphism, which allows a

P a g e | 43 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

single interface performing tasks for different types. Depending upon how the function is invoked,
each portion of the code gets executed.

4. EXPLAIN IN DETAILS ABOUT UNIFIED MODELING LANGUAGE?

Or
EXPLAIN IN DETAIL ABOUT UML DIAGRAMS WITH APPROPRIATE DIAGRAMS. (Dec 2021)

UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of
software systems.

UML was created by the Object Management Group (OMG) and UML 1.0 specification draft was
proposed to the OMG in January 1997.

OMG is continuously making efforts to create a truly industry standard.

• UML stands for Unified Modeling Language.

• UML is different from the other common programming languages such as C++, Java, COBOL, etc.

• UML is a pictorial language used to make software blueprints.

• UML can be described as a general-purpose visual modeling language to visualize, specify,

construct, and document software systems.

• Although UML is generally used to model software systems, it is not limited within this boundary. It
is also used to model non-software systems as well. For example, the process flow in a
manufacturing unit, etc.

UML is not a programming language, but tools can be used to generate code in various languages using
UML diagrams. UML has a direct relation with object-oriented analysis and design. After some
standardization, UML has become an OMG standard.

As UML describes the real-time systems, it is very important to make a conceptual model and then
proceed gradually. The conceptual model of UML can be mastered by learning the following three major
elements −

• UML building blocks

• Rules to connect the building blocks

• Common mechanisms of UML

This chapter describes all the UML building blocks. The building blocks of UML can be defined as −
• Things
• Relationships
• Diagrams
P a g e | 44 Software Engineering and Testing DEPARTMENT OF CSE
 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Things
Things are the most important building blocks of UML. Things can be −
• Structural
• Behavioral
• Grouping
• Annotational
Structural Things
Structural things define the static part of the model. They represent the physical and conceptual
elements. Following are the brief descriptions of the structural things.
Class − Class represents a set of objects having similar responsibilities.

Interface − Interface defines a set of operations, which specify the responsibility of a class.

Collaboration −Collaboration defines an interaction between elements.

Use case −Use case represents a set of actions performed by a system for a specific goal.

Component −Component describes the physical part of a system.

Node − A node can be defined as a physical element that exists at run time.

Behavioral Things
A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things −

P a g e | 45 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Interaction − Interaction is defined as a behavior that consists of a group of messages exchanged

among elements to accomplish a specific task.

State machine − State machine is useful when the state of an object in its life cycle is important. It
defines the sequence of states an object goes through in response to events. Events are external factors
responsible for state change

Grouping Things
Grouping things can be defined as a mechanism to group elements of a UML model together. There is
only one grouping thing available −
Package − Package is the only one grouping thing available for gathering structural and behavioral
things.

Annotational Things
Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of
UML model elements. Note - It is the only one Annotational thing available. A note is used to render
comments, constraints, etc. of an UML element.

Relationship
Relationship is another most important building block of UML. It shows how the elements are associated
with each other and this association describes the functionality of an application.
There are four kinds of relationships available.
Dependency

Dependency is a relationship between two things in which change in one element also affects the other.

Association

P a g e | 46 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Association is basically a set of links that connects the elements of a UML model. It also describes how
many objects are taking part in that relationship.

Generalization

Generalization can be defined as a relationship which connects a specialized element with a generalized
element. It basically describes the inheritance relationship in the world of objects.

Realization

Realization can be defined as a relationship in which two elements are connected. One element
describes some responsibility, which is not implemented and the other one implements them. This
relationship exists in case of interfaces.

UML Diagrams

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are used
to make a complete UML diagram and the diagram represents a system.

The visual effect of the UML diagram is the most important part of the entire process. All the other
elements are used to make it complete.

UML includes the following nine diagrams, the details of which are described in the subsequent
chapters.

• Class diagram
• Object diagram
• Use case diagram
• Sequence diagram
• Collaboration diagram
• Activity diagram

P a g e | 47 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

• State chart diagram

• Deployment diagram
• Component diagram

Any real-world system is used by different users. The users can be developers, testers, business people,
analysts, and many more. Hence, before designing a system, the architecture is made with different
perspectives in mind. The most important part is to visualize the system from the perspective of
different viewers. The better we understand the better we can build the system.

UML plays an important role in defining different perspectives of a system. These perspectives are −

• Design
• Implementation
• Process
• Deployment

The center is the Use Case view which connects all these four. A Use Case represents the functionality of
the system. Hence, other perspectives are connected with use cases.

Design of a system consists of classes, interfaces, and collaboration. UML provides class diagram, object
diagrams to support this.

Implementation defines the components assembled together to make a complete physical system. UML
component diagram is used to support the implementation perspective.

Process defines the flow of the system. Hence, the same elements as used in Design are also used to
support this perspective.

Deployment represents the physical nodes of the system that forms the hardware. UML deployment
diagram is used to support this perspective.

5. DESCRIBE IN DETAIL ABOUT USE-CASE MODEL. (Feb 2023)

The Use-case model is defined as a model which is used to show how users interact with the system in
order to solve a problem. As such, the use case model defines the user's objective, the interactions
between the system and the user, and the system's behavior required to meet these objectives.

Various model elements are contained in the use-case model, such as actors, use cases, and the
association between them.

P a g e | 48 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

We use a use-case diagram to graphically portray a subset of the model in order to make the
communication simpler. There will regularly be a numerous use-case diagram which is related to the
given model, each demonstrating a subset of the model components related to a specific purpose. A
similar model component might be appearing on a few use-case diagrams; however, each use-case
should be consistent. If, in order to handle the use-case model, tools are used then this consistency
restriction is automated so that any variations to the component of the model (changing the name, for
instance) will be reflected automatically on each use-case diagram, which shows that component.

Packages may include a use-case model, which is used to organize the model to simplify the analysis,
planning, navigation, communication, development and maintenance.

Various use-case models are textual and the text captured in the use-case specifications, which are
linked with the element of every use-case model. The flow of events of the use case is described with the
help of these specifications.

The use-case model acts as an integrated thread in the development of the entire system. The use-case
model is used like the main specification of the system functional requirements as the basis for design
and analysis, as the basis for user documentation, as the basis of defining test cases, and as an input to
iteration planning.

Origin of Use-Case

Nowadays, use case modeling is frequently connected with UML, in spite of the fact that it has been
presented before UML existed. Its short history is:

Ivar Jacobson, in the year 1986, originally formulated textual and visual modeling methods to specify
use cases.

And in the year 1992, his co-authored book named Object-Oriented Software Engineering - A Use Case
Driven Approach, assisted with promoting the strategy for catching functional requirements,
particularly in software development.

Components of Basic Model

There are various components of the basic model:

1) Actor
2) Use Case
3) Associations

P a g e | 49 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Actor

Usually, actors are people involved with the system defined on the basis of their roles. An actor can be
anything such as a human or another external system.

Use Case

The use case defines how actors use a system to accomplish a specific objective. The use cases are
generally introduced by the user to meet the objectives of the activities and variants involved in the
achievement of the goal.

Associations

Associations are another component of the basic model. It is used to define the associations among
actors and use cases they contribute to. This association is called communicates-association.

Advanced Model Components

There are various components of the advanced model:

1) Subject
2) Use-Case Package
3) Generalizations
4) Generalizations
5) Dependencies

Subject

The subject component is used to represent the boundary of the system of interest.

Use-Case Package

We use the model component in order to structure the use case model to make the analysis, planning,
navigation, and communication simpler. Suppose there are various actors or use cases. In that case, we
can also use use-case packages in order to further structure the use-case model in much the same way
we use directories or folders to organize the information on our hard-disk.

For various reasons, we divide the use-case model into the use-case packages, containing:

To help parallel development by partitioning the problem into bite-sized parts.

To improve communication with various stakeholders by making packaging containing actors, use cases
and related to the specific stakeholder.

P a g e | 50 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Generalizations

Generalizations mean the association between the actors in order to help re-use of common properties.

Dependencies

In UML, various types of dependencies are defined between use cases. In particular, <<include>> and
<<extend>>.

We use <<include>> dependency to comprise shared behavior from an included use case into a base use
case to use common behavior.

We use <<extend>> dependency to include optional behavior from an extended use-case into an
extended use case.

How to Draw a Use-Case Diagram?

If we want to draw a use case diagram in UML first, we must study the complete system appropriately.
We need to find out every function which is offered by the system. When we find out all the system's
functionalities then we convert these functionalities into a number of use cases, and we use these use-
cases in the use case diagram.

A use case means essential functionality of any working system. When we organize the use cases, then
next we need to enlist the numerous actors or things that will collaborate with the system. These actors
are used to implement the functionality of a system. Actors can be someone or something. It can
likewise be a private system's entity. The actors should be pertinent to the functionality or a system in
which the actors are interacting.

When we enlist the use cases and actors, then next, we need to find the relationship of a specific actor
with the system or a use case. An actor should find the total number of ways in order to cooperate with
the system. One actor can interact with the numerous use cases simultaneously, or it may interact with
the multiple-use cases concurrently.

We must follow the following rules while drawing use-case for any framework:

• The use case name and actor name should be meaningful and related to the system.
• The actor's interaction with the use case should be well-described and in a comprehensible
manner.
• Use annotations wherever they are essential.
• If the actor or use case has many relationships, then display only important interactions.

P a g e | 51 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

When to Use a Use-Case Diagram?

The use-case diagram is an extraordinary system's functionality that is accomplished by a client. The
objective of a use-case diagram is to capture the system's key functionalities and visualize the
interactions of different thinking’s known as actors with the use case. It is the basic use of a use-case
diagram.
With the help of the use-case diagram, we can characterize the system's main part and flow of work
among them. In the use-case, the implementation of details is hidden from external use, and only the
flow of the event is represented.
Using use-case diagrams, we can detect the pre-and post-conditions after communication with the actor.
We can determine these conditions using several test cases.
Generally, the use-cases diagram is used for:
• Examining the system's requirements.
• Capturing the system's Functionalities.
• We use a use-case diagram in order to model the general idea behind the system.
• System's forward and reverse engineering using several test cases.
• Complex visual designing of software.
Use cases are planned to convey wanted functionality so that the exact scope of use case can differ based
on the system and the purpose of making the UML model.
Tips for Drawing a Use-Case Diagram
There are various tips for drawing a use-case diagram:
• It must be complete.
• It must be simple.
• The use-case diagram must show each interaction with the use case.
• It is necessary that the use-case should be generalized if it is large.
• At least one system module must be defined in the use case diagram.
• When there are number of actors or use-cases in the use-case diagram, only the significant use-
cases must be represented.
• The use-case diagrams must be clear and easy so that anyone can understand them easily.
Importance of Use-Case Diagram
Use Cases have been broadly used over the last few years. There are various benefits of the use-case
diagram:

P a g e | 52 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

• Use-case diagram provides an outline related to all components in the system. Use-case diagrams help
to define the role of administrators, users, etc.
• The use-Case diagram helps to provide solutions and answers to various questions that may pop up if
you begin a project unplanned.
• It helps us to define the needs of the users extensively and explore how it will work.
Basic Use-Case Diagram Symbols and Notations
There are following use-case diagram symbols and notations:
System
With the help of the rectangle, we can draw the boundaries of the system, which includes use-cases. We
need to put the actors outside the system's boundaries.

Use-Case
With the help of the Ovals, we can draw the use-cases. With the verb we have to label the ovals in order
to represent the functions of the system.

Actors
Actors mean the system's users. If one system is the actor of the other system, then with the actor
stereotype, we must tag the actor system.

P a g e | 53 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Relationships
With the simple line we can represent relationships between an actor and use cases. For relationships
between use-case, we use arrows which are labeled either "extends" or "uses". The "extends"
relationship shows the alternative options under the specific use case. The "uses" relationship shows
that single use-case is required to accomplish a job.

Guidelines for Better Use-Cases

With regards to examining the system's requirements, use-case diagrams are another one to one. Use-
cases are simple to understand and visual. The following are some guidelines that help you to make
better use cases that are appreciated by your customers and peers the same.
Generally, the use-case diagram contains use-cases, relationships, and actors. Systems and boundaries
may be included in the complex larger diagrams. We'll talk about the guidelines of the use-case diagram
based on the objects.
Do not forget that these are the use case diagram's guidelines, not rules of the use-case diagram.
Actors
● The actor's name should be meaningful and relevant to the business
If the use-case involves interacting with the outside organization, then we have to give the actor's name with
the function instead of the organization name, such as Airline company is better than the PanAir).

● Place inheriting actors below the parent actor

We must place the inheriting actors below the parent actor because it makes the actors more readable and
easily highlights the use-cases, which are exact for that actor.

P a g e | 54 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

● External Systems are actors

If send-email is our use-case and when the use-case interrelates with the email management software, then in
this case, the software is an actor to that specific user-case.

Use-Cases
● The name of the use-case begins with a verb
The use-case models action, so the name of the use-case must start with a verb.

● The name of the use-case must be descriptive

The use-case is created to provide more information to others who are looking at a diagram, such as instead of
"Print," "print Invoice is good.

● Put the use-cases to the right of the included use-cases.

To add clarity and enhance readability, we have to place the included use-cases to the right of the invoking
use-cases.

● Place inheriting use-case below the parent use-case

In order to enhance the diagram's readability, we have to place the inheriting use-case below the parent use-
case.

Systems/Packages
● Give descriptive and meaningful names to these objects.

● Use them carefully and only if needed.

Relationships
● When we are using <<extend>> arrow, it points to the base use-case.

● When we are using <<include>> then the arrow points to the compromised use-case.

● Actor and use-case relationships do not display arrows.

● <<extend>> may have an optional extension condition.

● <<include>> and <<extend>> both are shown as dashed arrows.

Use-Case Examples
Use-Case Example-Association Link
In this use-case diagram, we show a group of use cases for a system which means the relationship
among the use-cases and the actor.

P a g e | 55 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Use-Case Example-Include Relationship

To add additional functionality that is not specified in the base use-case, we use to include relationships.
We use it to comprise the general behavior from an included use case into a base case so that we can
support the reuse general behavior.

Use-Case Example-Extend Relationship

With the help of the extend relationship, we can show the system behavior or optional functionality. We
use <<extend>> relationship in order to comprise optional behavior from an extending use-case in an
extended use-case. For example, the below diagram of the use-case displays an extend connector and an
extension point "Search".

P a g e | 56 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Use-Case Example-Generalization Relationship

In the generalization relationship, the child use-case can inherit the meaning and behavior of the parent
use-case. The child use-case is able to override and add the parent's behavior. The below diagram is an
example of a generalization relationship in which two generalization connectors are connected among
three use-cases.

Use-Case Diagram-Vehicle Sales Systems

The below diagram displays an instance of a use-case diagram for a vehicle system. As we can also see, a
system as much as one vehicle sales system contains not in excess of 10 use-cases, and it is the delicacy
of use-case modeling.

The use of include and extend is also displayed by the use-case model. In addition, there are associations
that link between the use-case and actors.
Use-Case Diagram-Student Management System
The below figure shows the working of the student management system:

P a g e | 57 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

In the above use-case diagram of the student management system, we have two actors and five use-
cases. The name of the actors is Student and Teacher. The use-cases represent the definite functionality
of the student management system. Every actor interacts with a specific use-case. The student actor is
able to check the test marks, time-table and attendance. These are only 3 interactions that can be
performed by the student actor; however various use-cases are also remaining in the system.
It is not necessary that every actor has to interact with each and every use-case, but it can happen.
In the diagram, the name of the second actor is a Teacher. Teacher is an actor that is able to interact with
all the system's functionalities. The teacher actor is also able to update the student's marks as well as
attendance. These interactions of student as well as teacher actors together summarize the whole
student management application.
6. EXPLAIN IN DETAIL ABOUT CLASS DIAGRAM?
Class diagram is a static diagram. It represents the static view of an application. Class diagram is not
only used for visualizing, describing, and documenting different aspects of a system but also for
constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints imposed on the
system. The class diagrams are widely used in the modeling of object-oriented systems because they are
the only UML diagrams, which can be mapped directly with object-oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and constraints. It is
also known as a structural diagram.

P a g e | 58 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Purpose of Class Diagrams

The purpose of the class diagram is to model the static view of an application. Class diagrams are the
only diagrams which can be directly mapped with object-oriented languages and thus widely used at the
time of construction.
UML diagrams like activity diagram, sequence diagrams can only give the sequence flow of the
application, however the class diagram is a bit different. It is the most popular UML diagram in the coder
community.
The purpose of the class diagram can be summarized as −
• Analysis and design of the static view of an application.
• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.
Vital components of a Class Diagram
The class diagram is made up of three sections:
Upper Section: The upper section encompasses the name of the class. A class is a representation of
similar objects that shares the same relationships, attributes, operations, and semantics.
Middle Section: The middle section constitutes the attributes, which describe the quality of the class.
Lower Section: The lower section contain methods or operations. The methods are represented in the
form of a list, where each method is written in a single line. It demonstrates how a class interacts with
data.

Relationships
In UML, relationships are of three types:
Dependency: A dependency is a semantic relationship between two or more classes where a change in
one class cause changes in another class. It forms a weaker relationship.
In the following example, Student_Name is dependent on the Student_Id.

P a g e | 59 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Generalization: A generalization is a relationship between a parent class (superclass) and a child class
(subclass). In this, the child class is inherited from the parent class.
For example, The Current Account, Saving Account, and Credit Account are the generalized form of Bank
Account.

Association: It describes a static or physical connection between two or more objects. It depicts how
many objects are there in the relationship.
For example, a department is associated with the college.

Multiplicity: It defines a specific range of allowable instances of attributes. In case if a range is not
specified, one is considered as a default multiplicity.
For example, multiple patients are admitted to one hospital.

P a g e | 60 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Aggregation: An aggregation is a subset of association, which represents has a relationship. It is more

specific then association. It defines a part-whole or part-of relationship. In this kind of relationship, the
child class can exist independently of its parent class.
The company encompasses a number of employees, and even if one employee resigns, the company still
exists.
Composition: The composition is a subset of aggregation. It portrays the dependency between the
parent and its child, which means if one part is deleted, then the other part also gets discarded. It
represents a whole-part relationship.

A contact book consists of multiple contacts, and if you delete the contact book, all the contacts will be
lost.

Benefits of Class Diagrams

1. It can represent the object model for complex systems.
2. It reduces the maintenance time by providing an overview of how an application is structured before
coding.
3. It provides a general schematic of an application for better understanding.
4. It represents a detailed chart by highlighting the desired code, which is to be programmed.

P a g e | 61 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

5. It is helpful for the stakeholders and the developers.

How to Draw a Class Diagram?
Class diagrams are the most popular UML diagrams used for construction of software applications. It is
very important to learn the drawing procedure of class diagram.
Class diagrams have a lot of properties to consider while drawing but here the diagram will be
considered from a top-level view.
Class diagram is basically a graphical representation of the static view of the system and represents
different aspects of the application. A collection of class diagrams represents the whole system.
The following points should be remembered while drawing a class diagram −
• The name of the class diagram should be meaningful to describe the aspect of the system.
• Each element and their relationships should be identified in advance.
• Responsibility (attributes and methods) of each class should be clearly identified
• For each class, a minimum number of properties should be specified, as unnecessary properties
will make the diagram complicated.
• Use notes whenever required to describe some aspect of the diagram. At the end of the drawing it
should be understandable to the developer/coder.
• Finally, before making the final version, the diagram should be drawn on plain paper and reworked
as many times as possible to make it correct.
The following diagram is an example of an Order System of an application. It describes a particular
aspect of the entire application.
• First of all, Order and Customer are identified as the two elements of the system. They have a one-
to-many relationship because a customer can have multiple orders.
• Order class is an abstract class and it has two concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.
• The two inherited classes have all the properties as the Order class. In addition, they have
additional functions like dispatch () and receive ().
The following class diagram has been drawn considering all the points mentioned above.

P a g e | 62 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Figure: Class Diagrams

A class diagram describing the sales order system is given below.

Where to Use Class Diagrams?

Class diagram is a static diagram and it is used to model the static view of a system. The static view
describes the vocabulary of the system.

P a g e | 63 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Class diagrams are also considered as the foundation for component and deployment diagrams. Class
diagrams are not only used to visualize the static view of the system but they are also used to construct
the executable code for forward and reverse engineering of any system.
Generally, UML diagrams are not directly mapped with any object-oriented programming languages but
the class diagram is an exception.
Class diagram clearly shows the mapping with object-oriented languages such as Java, C++, etc. From
practical experience, class diagrams are generally used for construction purposes.
In a nutshell it can be said, class diagrams are used for −
• Describing the static view of the system.
• Showing the collaboration among the elements of the static view.
• Describing the functionalities performed by the system.
• Construction of software applications using object-oriented languages.
7. DESCRIBE IN DETAIL ABOUT INTERACTION DIAGRAMS.
Interaction Diagrams
From the term Interaction, it is clear that the diagram is used to describe some type of interactions
among the different elements in the model. This interaction is a part of dynamic behavior of the system.
This interactive behavior is represented in UML by two diagrams known as Sequence diagram and
Collaboration diagram. The basic purpose of both the diagrams are similar.
Sequence diagram emphasizes on time sequence of messages and collaboration diagram emphasizes on
the structural organization of the objects that send and receive messages.
Purpose of Interaction Diagrams
The purpose of interaction diagrams is to visualize the interactive behavior of the system. Visualizing
the interaction is a difficult task. Hence, the solution is to use different types of models to capture the
different aspects of the interaction.
Sequence and collaboration diagrams are used to capture the dynamic nature but from a different angle.
The purpose of interaction diagram is −
• To capture the dynamic behaviour of a system.
• To describe the message flow in the system.
• To describe the structural organization of the objects.
• To describe the interaction among objects.

How to Draw an Interaction Diagram?

P a g e | 64 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

As we have already discussed, the purpose of interaction diagrams is to capture the dynamic aspect of a
system. So, to capture the dynamic aspect, we need to understand what a dynamic aspect is and how it is
visualized. Dynamic aspect can be defined as the snapshot of the running system at a particular moment
We have two types of interaction diagrams in UML. One is the sequence diagram and the other is the
collaboration diagram. The sequence diagram captures the time sequence of the message flow from one
object to another and the collaboration diagram describes the organization of objects in a system taking
part in the message flow.
Following things are to be identified clearly before drawing the interaction diagram
• Objects taking part in the interaction.
• Message flows among the objects.
• The sequence in which the messages are flowing.
• Object organization.
Following are two interaction diagrams modeling the order management system. The first diagram is a
sequence diagram and the second is a collaboration diagram

Use of an Interaction Diagram

The interaction diagram can be used for:
1. The sequence diagram is employed to investigate a new application.
2. The interaction diagram explores and compares the use of the collaboration diagram sequence
diagram and the timing diagram.
3. The interaction diagram represents the interactive (dynamic) behavior of the system.
4. The sequence diagram portrays the order of control flow from one element to the other elements
inside the system, whereas the collaboration diagrams are employed to get an overview of the object
architecture of the system.

P a g e | 65 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

5. The interaction diagram models the system as a time-ordered sequence of a system.

6. The interaction diagram models the system as a time-ordered sequence of a system.
7. The interaction diagram systemizes the structure of the interactive elements.
The Sequence Diagram
The sequence diagram has four objects (Customer, Order, SpecialOrder and NormalOrder).
The following diagram shows the message sequence for the SpecialOrder object and the same can be
used in the case of the NormalOrder object. It is important to understand the time sequence of message
flows. The message flow is nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call is confirm () which is a
method of the SpecialOrder object and the last call is Dispatch () which is a method of the SpecialOrder
object. The following diagram mainly describes the method calls from one object to another, and this is
also the actual scenario when the system is running.

Figure: Sequence Diagram

The Collaboration Diagram
The second interaction diagram is the collaboration diagram. It shows the object organization as seen in
the following diagram. In the collaboration diagram, the method call sequence is indicated by some
numbering technique. The number indicates how the methods are called one after another. We have
taken the same order management system to describe the collaboration diagram.
Method calls are like that of a sequence diagram. However, the difference being the sequence diagram
does not describe the object organization, whereas the collaboration diagram shows the object
organization.

P a g e | 66 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

To choose between these two diagrams, emphasis is placed on the type of requirement. If the time
sequence is important, then the sequence diagram is used. If organization is required, then a
collaboration diagram is used.

Figure: Collaboration Diagram

Where to Use Interaction Diagrams?

We have already discussed that interaction diagrams are used to describe the dynamic nature of a
system. Now, we will look into the practical scenarios where these diagrams are used. To understand
the practical application, we need to understand the basic nature of sequence and collaboration
diagrams.
The main purposes of both the diagrams are similar as they are used to capture the dynamic behavior of
a system. However, the specific purpose is more important to clarify and understand.
Sequence diagrams are used to capture the order of messages flowing from one object to another.
Collaboration diagrams are used to describe the structural organization of the objects taking part in the
interaction. A single diagram is not sufficient to describe the dynamic aspect of an entire system, so a set
of diagrams are used to capture it as a whole.
Interaction diagrams are used when we want to understand the message flow and the structural
organization. Message flow means the sequence of control flow from one object to another. Structural
organization means the visual organization of the elements in a system.
Interaction diagrams can be used −
• To model the flow of control by time sequence.
• To model the flow of control by structural organizations.
• For forward engineering.
• For reverse engineering.
P a g e | 67 Software Engineering and Testing DEPARTMENT OF CSE
 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

8. EXPLAIN IN DETAIL ABOUT ACTIVITY DIAGRAM.

Activity diagram
Activity diagram is another important diagram in UML to describe the dynamic aspects of the system.
Activity diagram is basically a flowchart to represent the flow from one activity to another activity. The
activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be sequential, branched, or
concurrent. Activity diagrams deal with all type of flow control by using different elements such as fork,
join, etc
Purpose of Activity Diagrams
The basic purpose of activity diagrams is similar to the other four diagrams. It captures the dynamic
behavior of the system. Other four diagrams are used to show the message flow from one object to
another, but the activity diagram is used to show message flow from one activity to another.
Activity is a particular operation of the system. Activity diagrams are not only used for visualizing the
dynamic nature of a system, but they are also used to construct the executable system by using forward
and reverse engineering techniques. The only missing thing in the activity diagram is the message part.
It does not show any message flow from one activity to another. Activity diagram is sometimes
considered as the flowchart. Although the diagrams look like a flowchart, they are not. It shows different
flows such as parallel, branched, concurrent, and single.
The purpose of an activity diagram can be described as −
• Draw the activity flow of a system.
• Describe the sequence from one activity to another.
• Describe the parallel, branched and concurrent flow of the system.
Notation of an Activity diagram
Activity diagram constitutes following notations:
Initial State: It depicts the initial stage or beginning of the set of actions.
Final State: It is the stage where all the control flows and object flows end.
Decision Box: It makes sure that the control flow or object flow will follow only one path.
Action Box: It represents the set of actions that are to be performed.
How to Draw an Activity Diagram?
Activity diagrams are mainly used as a flowchart that consists of activities performed by the system.
Activity diagrams are not exactly flowcharts as they have some additional capabilities. These additional
capabilities include branching, parallel flow, swimlane, etc.

P a g e | 68 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Before drawing an activity diagram, we must have a clear understanding about the elements used in the
activity diagram. The main element of an activity diagram is the activity itself. An activity is a function
performed by the system. After identifying the activities, we need to understand how they are
associated with constraints and conditions.
Before drawing an activity diagram, we should identify the following elements −
• Activities
• Association
• Conditions
• Constraints
Once the above-mentioned parameters are identified, we need to make a mental layout of the entire
flow. This mental layout is then transformed into an activity diagram.
Following is an example of an activity diagram for an order management system. In the diagram, four
activities are identified which are associated with conditions. One important point should be clearly
understood that an activity diagram cannot be exactly matched with the code. The activity diagram is
made to understand the flow of activities and is mainly used by the business users
Following diagram is drawn with the four main activities −
• Send order by the customer
• Receipt of the order
• Confirm the order
• Dispatch the order
After receiving the order request, condition checks are performed to check if it is normal or special
order. After the type of order is identified, dispatch activity is performed and that is marked as the
termination of the process.

P a g e | 69 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Figure: Activity Diagrams

Where to Use Activity Diagrams?

The basic usage of the activity diagram is similar to the other four UML diagrams. The specific usage is
to model the control flow from one activity to another. This control flow does not include messages.
Activity diagram is suitable for modeling the activity flow of the system. An application can have
multiple systems. Activity diagram also captures these systems and describes the flow from one system
to another. This specific usage is not available in other diagrams. These systems can be databases,
external queues, or any other system.
We will now look into the practical applications of the activity diagram. From the above discussion, it is
clear that an activity diagram is drawn from a very high level. So it gives a high level view of a system.
This high level view is mainly for business users or any other person who is not a technical person.
This diagram is used to model the activities which are nothing but business requirements. The diagram
has more impact on business understanding rather than on implementation details.
Activity diagram can be used for −
• Modeling workflow by using activities.
• Modeling business requirements.
• High level understanding of the system's functionalities.
• Investigating business requirements at a later stage.
9. DESCRIBE IN DETAIL ABOUT STATE CHART DIAGRAMS.

P a g e | 70 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

State Chart Diagrams: -

The name of the diagram itself clarifies the purpose of the diagram and other details. It describes
different states of a component in a system. The states are specific to a component/object of a system.
A State chart diagram describes a state machine. State machine can be defined as a machine which
defines different states of an object and these states are controlled by external or internal events.
Activity diagram explained in the next chapter, is a special kind of a State chart diagram. As the State
chart diagram defines the states, it is used to model the lifetime of an object.
Purpose of State chart Diagrams
State chart diagram is one of the five UML diagrams used to model the dynamic nature of a system. They
define different states of an object during its lifetime and these states are changed by events. State chart
diagrams are useful to model the reactive systems. Reactive systems can be defined as a system that
responds to external or internal events.
State chart diagram describes the flow of control from one state to another state. States are defined as a
condition in which an object exists and it changes when some event is triggered. The most important
purpose of a State chart diagram is to model the lifetime of an object from creation to termination.
State chart diagrams are also used for forward and reverse engineering of a system. However, the main
purpose is to model the reactive system.
Following are the main purposes of using State chart diagrams −
• To model the dynamic aspect of a system.
• To model the lifetime of a reactive system.
• To describe different states of an object during its lifetime.
• Define a state machine to model the states of an object.

How to Díaw a State chaít Diagíam?

State chart diagram is used to describe the states of different objects in its life cycle. Emphasis is placed
on the state changes upon some internal or external events. These states of objects are important to
analyze and implement them accurately.
State chart diagrams are very important for describing the states. States can be identified as the
condition of objects when a particular event occurs.
Before drawing a state chart diagram, we should clarify the following points −
• Identify the important objects to be analyzed.
• Identify the states.
• Identify the events.

P a g e | 71 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Following is an example of a state chart diagram where the state of Order object is analyzed
The first state is an idle state from where the process starts. The next states are arrived for events like
send request, confirm request, and dispatch order. These events are responsible for the state changes of
order objects.
During the life cycle of an object (here order object) it goes through the following states and there may
be some abnormal exits. This abnormal exit may occur due to some problem in the system. When the
entire life cycle is complete, it is considered as a complete transaction as shown in the following figure.
Notation of a State Machine Diagram
Following are the notations of a state machine diagram enlisted below:
The initial and final state of an object is also shown in the following figure.

Initial state: It defines the initial state (beginning) of a system, and it is represented by a black filled
circle.
Final state: It represents the final state (end) of a system. It is denoted by a filled circle present within a
circle.
Decision box: It is of diamond shape that represents the decisions to be made on the basis of an
evaluated guard.
Transition: A change of control from one state to another due to the occurrence of some event is
termed as a transition. It is represented by an arrow labeled with an event due to which the change has
ensued.
State box: It depicts the conditions or circumstances of a particular object of a class at a specific point of
time. A rectangle with round corners is used to represent the state box.

P a g e | 72 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Figure: State chart Diagrams

Where to Use State chart Diagrams?
From the above discussion, we can define the practical applications of a state chart diagram. State chart
diagrams are used to model the dynamic aspect of a system like other four diagrams discussed in this
tutorial. However, it has some distinguishing characteristics for modeling the dynamic nature.
State chart diagrams define the states of a component, and these state changes are dynamic in nature. Its
specific purpose is to define the state changes triggered by events. Events are internal or external
factors influencing the system.
State chart diagrams are used to model the states and the events operating on the system. When
implementing a system, it is very important to clarify different states of an object during its lifetime and
State chart diagrams are used for this purpose. When these states and events are identified, they are
used to model it and these models are used during the implementation of the system.
If we look into the practical implementation of the State chart diagram, then it is mainly used to analyze
the object states influenced by events. This analysis is helpful to understand the system behavior during
its execution.
The main usage can be described as −
• To model the object states of a system.
• To model the reactive system. Reactive system consists of reactive objects.
• To identify the events responsible for state changes.
• Forward and reverse engineering.

P a g e | 73 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

10. EXPLAIN OBJECT ORIENTED ANALYSIS AND DESIGN METHODOLOGY.

What is Object Oriented Methodology?
• It is a new system development approach, encouraging and facilitating re-use of software
components.
• It employs the international standard Unified Modeling Language (UML) from the Object
Management Group (OMG).
• Using this methodology, a system can be developed on a component basis, which enables the
effective re-use of existing components, and facilitates the sharing of its other system components.
• Object Oriented Methodology asks the analyst to determine what the objects of the system are?,
What responsibilities and relationships an object has to do with the other objects? and How do
they behave over time?
There are three types of Object-Oriented Methodologies
• Object Modeling Techniques (OMT)
• Object Process Methodology (OPM)
• Rational Unified Process (RUP)
1. Object Modeling Techniques (OMT)
• It was one of the first object oriented methodologies and was introduced by Rumbaugh in 1991.
• OMT uses three different models that are combined in a way that is analogous to the older
structured methodologies.

a. Analysis
• The main goal of the analysis is to build models of the world.
• The requirements of the users, developers and managers provide the information needed to
develop the initial problem statement.
b. OMT Models
I. Object Model

P a g e | 74 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

• It depicts the object classes and their relationships as a class diagram, which represents the static
structure of the system.
• It observes all the objects as static and does not pay any attention to their dynamic nature.
II. Dynamic Model
• It captures the behavior of the system over time and the flow control and events in the Event-Trace
Diagrams and State Transition Diagrams.
• It portrays the changes occurring in the states of various objects with the events that might occur
in the system.
III. Functional Model
• It describes the data transformations of the system.
• It describes the flow of data and the changes that occur to the data throughout the system.
c. Design
• It specifies all of the details needed to describe how the system will be implemented.
• In this phase, the details of the system analysis and system design are implemented.
• The objects identified in the system design phase are designed.
2. Object Process Methodology (OPM)
• It is also called a second generation methodology.
• It was first introduced in 1995.
• It has only one diagram that is the Object Process Diagram (OPD) which is used for modeling the
structure, function and behavior of the system.
• It has a strong emphasis on modeling but has a weaker emphasis on process.
• It consists of three main processes:
I. Initiating: It determines high level requirements, the scope of the system and the resources that will
be required.
II. Developing: It involves the detailed analysis, design and implementation of the system.
III. Deploying: It introduces the system to the user and subsequent maintenance of the system.
3. Rational Unified Process (RUP)
● It was developed by Rational Corporation in 1998.
● It consists of four phases which can be broken down into iterations.
I. Inception
II. Elaboration

P a g e | 75 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

III. Construction
IV. Transition
● Each iteration consists of nine work areas called disciplines.
● A discipline depends on the phase in which the iteration is taking place.
● For each discipline, RUP defines a set of artefacts (work products), activities (work undertaken on
the artefacts) and roles (the responsibilities of the members of the development team).
Objectives of Object Oriented Methodologies
● To encourage greater re-use.
● To produce a more detailed specification of system constraints.
● To have fewer problems with validation (Are we building the right product?).
Benefits of Object Oriented Methodologies
1. It represents the problem domain, because it is easier to produce and understand designs.
2. It allows changes more easily.
3. It provides nice structures for thinking, abstracting and leads to modular design.
4. Simplicity:
● The software object's model complexity is reduced and the program structure is very clear.
5. Reusability:
● It is a desired goal of all development processes.
● It contains both data and functions which act on data.
● It makes it easy to reuse the code in a new system.
● Messages provide a predefined interface to an object's data and functionality.
6. Increased Quality:
● This feature increase in quality is largely a by-product of this program reuse.

7. Maintainable:
● The OOP method makes code more maintainable.
● The objects can be maintained separately, making locating and fixing problems easier.
8. Scalable:
● The object oriented applications are more scalable than structured approaches.
● It makes it easy to replace the old and aging code with faster algorithms and newer technology.
9. Modularity:
● The OOD systems are easier to modify.

P a g e | 76 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE
● It can be altered in fundamental ways without ever breaking up since changes are neatly
encapsulated.
10. Modifiability:
● It is easy to make minor changes in the data representation or the procedures in an object oriented
program.
11. Client/Server Architecture:
● It involves the transmission of messages back and forth over a network.
11. DISCUSS IN DETAIL ABOUT USER INTERFACE.
Or
DISCUSS IN DETAIL ABOUT THE CHARACTERISTICS OF A GOOD USER INTERFACE. (Dec 2021)
User Interface Design
The visual part of a computer application or operating system through which a client interacts with a
computer or software. It determines how commands are given to the computer or the program and how
data is displayed on the screen.
Types of User Interface
There are two main types of User Interface:
● Text-Based User Interface or Command Line Interface
● Graphical User Interface (GUI)
Text-Based User Interface: This method relies primarily on the keyboard. A typical example of this is
UNIX.
Advantages
● Many and easier customizations options.
● Typically capable of more important tasks.
Disadvantages
● Relies heavily on recall rather than recognition.
● Navigation is often more difficult.
Graphical User Interface (GUI): GUI relies much more heavily on the mouse. A typical example of this
type of interface is any versions of the Windows operating systems.
Hello Java Program for Beginners
GUI Characteristics

Characteristics Descriptions

P a g e | 77 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Windows Multiple windows allow different information to be displayed

simultaneously on the user's screen.

Icons Icons different types of information. On some systems, icons

represent files. Other icons describe processes.

Menus Commands are selected from a menu rather than typed in a

command language.

Pointing A pointing device such as a mouse is used for selecting choices from
a menu or indicating items of interest in a window.

Graphics Graphics elements can be mixed with text or the same display.

Advantages
• Less expert knowledge is required to use it.
• Easier to Navigate and can look through folders quickly in a guess and check manner.
• The user may switch quickly from one task to another and can interact with several different
applications.
Disadvantages
• Typically decreased options.
• Usually less customizable. Not easy to use one button for tons of different variations.
UI Design Principles

P a g e | 78 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

Structure: Design should organize the user interface purposefully, in the meaningful and usual way
based on precise, consistent models that are apparent and recognizable to users, putting related things
together and separating unrelated things, differentiating dissimilar things and making similar things
resemble one another. The structure principle is concerned with overall user interface architecture.
Simplicity: The design should make the simple, common task easy, communicating clearly and directly
in the user's language, and providing good shortcuts that are meaningfully related to longer procedures.
Visibility: The design should make all required options and materials for a given function visible without
distracting the user with extraneous or redundant data.
Feedback: The design should keep users informed of actions or interpretation, changes of state or
condition, and bugs or exceptions that are relevant and of interest to the user through clear, concise, and
unambiguous language familiar to users.
Tolerance: The design should be flexible and tolerant, decreasing the cost of errors and misuse by
allowing undoing and redoing while also preventing bugs wherever possible by tolerating varied inputs
and sequences and by interpreting all reasonable actions.
Characteristics
• Simplicity: User Interface design should be simple.
• Consistency: The user interface should have more consistency.
• Intuitiveness: The most important quality of good user interface design is intuitive.
• Prevention

P a g e | 79 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

• Forgiveness
• Graphical User Interface Design

P a g e | 80 Software Engineering and Testing DEPARTMENT OF CSE

 SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

UNIT-II

PART-A
1. State Software Design.
2. Define Coupling and Cohesion.
3. What is meant by Class and Interaction Diagrams?
4. Name the types of User Interface in SOftware Engineering.
5. Write the characteristics of User Interface.
6. Write a note on Structured Analysis. List out the types of system testing.
7. Point out the five stages in a test plan process.
8. What is software process? List its activities.
9. List the task regions in the spiral model.
10.List the characteristics of good software design. (Feb 2023)
11. Define interaction diagram. (Feb 2023)

PART-B
1. Explain in detail about Software Design with a neat sketch.
2. Write a note on Coupling and Cohesion in detail.
3. Explain Structured and Detailed Design.
4. Describe in detail about OOAD Methodology.
5. What is User Interface? Explain the types and methodology of user interfaces.
6. Write a short note about Activity Diagrams.
7. Discuss in detail about the characteristics of a good user interface.
8. Define the concept of cohesion and coupling. State the difference. (Feb 2023)

PART-C
1. Enumerate UML Diagrams with their concepts in neat script.
2. Elaborate about Structured Analysis and Data Flow Diagrams.
3. Write a note on Object Oriented Concepts.
4. Explain in detail about use case diagram and activity diagram with example. (Feb 2023)

P a g e | 81 Software Engineering and Testing DEPARTMENT OF CSE