SOLUTION of RTU PAPER 3CS4-07 Software Engineering

II B.Tech. III Sem. (Main/Back) Exam., Dec. 2019

Computer Science & Engineering
3CS4-07 Software Engineering
Common For CS, IT Maximum Marks: 120
PART — A (Answer should be given up to 25 words only)
Q. 1 Define system engineering?
Q.2 Mention the three key elements of software engineering.
Q.3 What is the objective of various model in software engineering?
Q.4 Define the merits of the various model in software engineering.
Q.5 Why accuracy is important in the data dictionary?
Q.6 What is behavior modeling>
Q.7 What is a finite state machine model?
Q. 8 Why design documentation is important in software engineering?
Q.9 Write the objective of software project planning.
Q.10 What is sequence diagram in the context of UML
PART — B (Analytical/Problem solving questions)
Attempt any five questions
Q.1 Describe the Computer Based system as an organizational information system with an example.
Q.2 Explain the software development life cycle with a diagram.
Q.3 What do you understand by data dictionary where and how it is used?
Q.4 Explain the object modular radiation with example.
Q.5 What is SDLC? Explain the MIS oriented SDLC model?
Q.6 Explain COCOMO estimation model in software project management.
Q.7 What is UML? Explain how it is useful in object — oriented modeling.
PART - C (Descriptive/Analytical/Problem Solving/Design Questions)
Attempt any four questions
Q. 1 Discuss merits and demerits of various models of software development.
Q.2 Write a short not on a Finite State Machine (FSM).
Q.3 Explain object - oriented analysis and its approach and explain classes and object relationship model.
Q.4 Explain major elements of DFD & CFD.
Q.5 Explain the use case diagram and state diagram in the context of UML.
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

SOLUTION
PART — A (Answer should be given up to 25 words only)
Q. 1 Define system engineering?
Answer: System Engineering is the systematic approach to the development, operation and maintenance of
Computer System. System Engineering is concerned with development and maintenance of combination of
software and hardware products.

Q.2 Mention the three key elements of software engineering.

Answer: 1. Requirement Analysis.
2. Code Quality and Architecture
3.Version Control and Deliverables

Q.3 What is the objective of various model in software engineering?

Answer: A software process model represents the order in which the activities of software development will
be undertaken. It describes the sequence in which the phases of the software lifecycle will be performed.

Q.4 Define the merits of the various model in software engineering.

Answer: Models are forms of description often adopted in software development. They are abstractions used
to represent and communicate what is important, devoid of unnecessary detail, and to help developers deal
with the complexity of the problem being investigated or the solution being developed.

Q.5 Why accuracy is important in the data dictionary?

Answer: data is used to provide insight. Businesses, when armed with this, are able to improve the everyday
decisions they make. If data accuracy levels are low at the start of this process, the insight will be lacking and
the decisions it influences are likely to be poor as a result.

Q.6 What is behavior modeling?

Answer: Modeling is one way in which behavior is learned. When a person observes the behavior of another
and then imitates that behavior, he or she is modeling the behavior. ... Modeling may teach a new behavior,
influence the frequency of a previously learned behavior, or increase the frequency of a similar behavior.

Q.7 What is a finite state machine model?

Answer: A finite-state machine (FSM) or finite-state automaton (FSA, plural: automata), finite automaton, or
simply a state machine, is a mathematical model of computation. ... The FSM can change from one state to
another in response to some inputs; the change from one state to another is called a transition.

Q. 8 Why design documentation is important in software engineering?

 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

Answer: Design Documentation help ensure consent and expectations. It helps to tell the narrative for
decisions made, and how yourself or the client responded to different situations. In this same manor, it is
important to record information that can help support the proper treatment plan and the reasoning for such
services.

Q.9 Write the objective of software project planning.

Answer: he objective of software project planning is to provide a framework that enables the manager to
make reasonable estimates of resources, cost, and schedule. These estimates are made within a limited time at
the beginning of a software project and should be updated regularly as the project progresses.

Q.10 What is sequence diagram in the context of UML

Answer: A sequence diagram is a type of interaction diagram because it describes how—and in what
order—a group of objects works together. These diagrams are used by software developers and business
professionals to understand requirements for a new system or to document an existing process.

PART — B (Analytical/Problem solving questions)

Attempt any five questions
Q.1 Describe the Computer Based system as an organizational information system with an example.
Answer: Computer Based Information System:
This relies on the computer for handling business applications. The business requires computer heavily to
solve their business problems. There are different levels of information required by people at different level.
People at Lower Level needs detailed information which would allow them to carry out with their tasks.
People at Higher Level needs summarized information which would allow them to assess the overall
progress, goals etc. This system should ensure that people at lower level are not given access to all the data
shown at the higher level. However, people at the higher level can drill down to the data at the lower when
required.
Component of Computer based information System
A Computer-Based Information System (CBIS) is an information system in which the computer plays a
major role. Such a system consists of the following elements:
Hardware: The term hardware refers to machinery. This category includes the computer itself, which is
often referred to as the central processing unit (CPU), and all of its support equipment. Among the support
equipment are input and output devices, storage devices and communications devices.
Software: The term software refers to computer programs and the manuals (if any) that support them.
Computer programs are machine-readable instructions that direct the circuitry within the hardware parts of
the CBIS to function in ways that produce useful information from data. Programs are generally stored on
some input / output medium-often a disk or tape.
Data: Data are facts that are used by program to produce useful information. Like programs, data are
generally stored in machine-readable from on disk or tape until the computer needs them.
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

Procedures: procedures are the policies that govern the operation of a computer system. ―Procedures are to
people what software is to hardware‖ is a common analogy that is used to illustrate the role of procedures in a
CBIS.
People: Every CBIS needs people if it is to be useful. Often the most over-looked element of the CBIS is the
people: probably the components that most influence the success or failure of information system.
The major Information Systems are
1. Formal Information System
2. Informal Information System
3. Computer Based Information System

This is based on the organization represented by the Organization Chart. The Organization char clearly lays
down the position and the personnel associated to those positions and their authority relationship.

Q.2 Explain the software development life cycle with a diagram.

Answer: SOFTWARE DEVELOPMENT LIFE CYCLE :

The Systems Development Life Cycle (SDLC) is a conceptual model used in project
management that describes the stages involved in an information system development project
from an initial feasibility study through maintenance of the completed application. Various
SDLC methodologies have been developed to guide the processes involved including the
waterfall model (the original SDLC method), rapid application development (RAD), joint
application development (JAD), the fountain model and the spiral model. Mostly, several
models are combined into some sort of hybrid methodology. Documentation is crucial
regardless of the type of model chosen or devised for any application, and is usually done in
parallel with the development process. Some methods work better for specific types of
projects, but in the final analysis, the most important factor for the success of a project may
be how closely particular plan was followed.
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

The image above is the classic Waterfall model methodology, which is the first SDLC
method and it describes the various phases involved in development.

Q.3 What do you understand by data dictionary where and how it is used?

Answer: DATA DICTIONARY: The analysis model encompasses representations of data

objects, function, and control. In each representation data objects and/or control items play a
role. Therefore, it is necessary to provide an organized approach for representing the
characteristics of each data object and control item. This is accomplished with the data
dictionary.

The data dictionary has been proposed as a quasi-formal grammar for describing

the content of objects defined during structured analysis. This important modeling

notation has been defined in the following manner :

― The data dictionary is an organized listing of all data elements that are pertinent to the
system, with precise, rigorous definitions so that both user and system analyst will have a
common understanding of inputs, outputs, components of stores and [even] intermediate
calculations ―.

Today, the data dictionary is always implemented as part of a CASE "structured analysis and
design tool." Although the format of dictionaries varies from tool to tool, most contain the
following information:

• Name—the primary name of the data or control item, the data store or an external entity.

• Alias—other names used for the first entry.

• Where-used/how-used—a listing of the processes that use the data or controlitem and how it
is used (e.g., input to the process, output from the process, as a store, as an external entity.

• Content description—a notation for representing content.

• Supplementary information—other information about data types, preset values (if known),
restrictions or limitations, and so forth.

Once a data object or control item name and its aliases are entered into the data dictionary,
consistency in naming can be enforced. That is, if an analysis team member decides to name a
newly derived data item xyz, but xyz is already in the dictionary, the CASE tool supporting
the dictionary posts a warning to indicate duplicate names. This improves the consistency of
the analysis model and helps to reduce errors.

―Where-used/how-used‖ information is recorded automatically from the flow models. When

a dictionary entry is created, the CASE tool scans DFDs and CFDs to determine which
processes use the data or control information and how it is used. Although this may appear
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

unimportant, it is actually one of the most important benefits of the dictionary. During
analysis there is an almost continuous stream of changes. For large projects, it is often quite
difficult to determine the impact of a change. Many a software engineer has asked, "Where is
this data object used? What else will have to change if we modify it? What will the overall
impact of the change be?" Because the data dictionary can be treated as a database, the
analyst can ask "where used/how used" questions, and get answers to these queries.

Q.4 Explain the object modular radiation with example.

Answer: In the object-oriented design method, the system is viewed as a collection of objects (i.e., entities).
The state is distributed among the objects, and each object handles its state data. For example, in a Library
Automation Software, each library representative may be a separate object with its data and functions to
operate on these data. The tasks defined for one purpose cannot refer or change data of other objects. Objects
have their internal data which represent their state. Similar objects create a class. In other words, each object is
a member of some class. Classes may inherit features from the superclass.
1. Objects: All entities involved in the solution design are known as objects. For
example, person, banks, company, and users are considered as objects. Every entity
has some attributes associated with it and has some methods to perform on the
attributes.
2. Classes: A class is a generalized description of an object. An object is an instance of a
class. A class defines all the attributes, which an object can have and methods, which
represents the functionality of the object.
3. Messages: Objects communicate by message passing. Messages consist of the
integrity of the target object, the name of the requested operation, and any other action
needed to perform the function. Messages are often implemented as procedure or
function calls.
4. Abstraction In object-oriented design, complexity is handled using abstraction.
Abstraction is the removal of the irrelevant and the amplification of the essentials.
5. Encapsulation: Encapsulation is also called an information hiding concept. The data
and operations are linked to a single unit. Encapsulation not only bundles essential
information of an object together but also restricts access to the data and methods
from the outside world.
6. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where
the lower or sub-classes can import, implement, and re-use allowed variables and
functions from their immediate superclasses.This property of OOD is called an
inheritance. This makes it easier to define a specific class and to create generalized
classes from specific ones.
7. Polymorphism: OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned the same name. This is known as
polymorphism, which allows a single interface is performing functions for different
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

types. Depending upon how the service is invoked, the respective portion of the code
gets executed.

For example if you want to design an object- for the registry system of your school the

following are candidate objects:

 The school itself

 Departments
 Students
 Faculties
 Staffs
 Courses

Q.5 What is SDLC? Explain the MIS oriented SDLC model?

Answer: The system development life cycle is a project management model that defines the stages involved
in bringing a project from inception to completion. Software development teams, for example, deploy a
variety of systems development life cycle models that include waterfall, spiral and agile processes.
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

MIS Systems Development Life Cycle (SDLC): The system development life cycle refers to the processing of
planning, creating, testing, and deploying an information system. The main objective of system development life
cycle is to produce high-quality information systems that meet or exceed the expectations of the users within the
stipulated budget and time frame. SDLC uses a number of development methodologies to achieve this objective.

Q.6 Explain COCOMO estimation model in software project management.

Answer: COCOMO (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines
of Code. It is a procedural cost estimate model for software projects and often used as a process of reliably
predicting the various parameters associated with making a project such as size, effort, cost, time and quality.
It was proposed by Barry Boehm in 1970 and is based on the study of 63 projects, which make it one of the
best-documented models.
The key parameters which define the quality of any software products, which are also an outcome of the
COCOMO are primarily Effort & Schedule:
 Effort: Amount of labor that will be required to complete a task. It is measured in person-months
units.
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

 Schedule: Simply means the amount of time required for the completion of the job, which is, of
course, proportional to the effort put. It is measured in the units of time such as weeks, months.
Different models of COCOMO have been proposed to predict the cost estimation at different levels, based on
the amount of accuracy and correctness required. All of these models can be applied to a variety of projects,
whose characteristics determine the value of constant to be used in subsequent calculations. These
characteristics pertaining to different system types are mentioned below.
Boehm‘s definition of organic, semidetached, and embedded systems:
1. Organic – A software project is said to be an organic type if the team size required is adequately
small, the problem is well understood and has been solved in the past and also the team members
have a nominal experience regarding the problem.
2. Semi-detached – A software project is said to be a Semi-detached type if the vital characteristics
such as team-size, experience, knowledge of the various programming environment lie in between
that of organic and Embedded. The projects classified as Semi-Detached are comparatively less
familiar and difficult to develop compared to the organic ones and require more experience and
better guidance and creativity. Eg: Compilers or different Embedded Systems can be considered of
Semi-Detached type.
3. Embedded – A software project with requiring the highest level of complexity, creativity, and
experience requirement fall under this category. Such software requires a larger team size than the
other two models and also the developers need to be sufficiently experienced and creative to develop
such complex models.
All the above system types utilize different values of the constants used in Effort Calculations.
Types of Models: COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. Any
of the three forms can be adopted according to our requirements. These are types of COCOMO model:
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
The first level, Basic COCOMO can be used for quick and slightly rough calculations of Software Costs. Its
accuracy is somewhat restricted due to the absence of sufficient factor considerations.
Intermediate COCOMO takes these Cost Drivers into account and Detailed COCOMO additionally
accounts for the influence of individual project phases, i.e in case of Detailed it accounts for both these cost
drivers and also calculations are performed phase wise henceforth producing a more accurate result. These
two models are further discussed below.
Estimation of Effort: Calculations –
1. Basic Model –
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

The above formula is used for the cost estimation of for the basic COCOMO model, and also is used in the
subsequent models. The constant values a,b,c and d for the Basic Model for the different categories of
system:

SOFTWARE PROJECTS a b c d

Organic 2.4 1.05 2.5 0.38

Semi Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

The effort is measured in Person-Months and as evident from the formula is dependent on Kilo-Lines of
code.
The development time is measured in Months.
These formulas are used as such in the Basic Model calculations, as not much consideration of different
factors such as reliability, expertise is taken into account, henceforth the estimate is rough.

Q.7 What is UML? Explain how it is useful in object oriented modeling.

Answer: 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.

 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

 UML can be described as a general purpose visual modeling language to visualize,

specify, construct, and document software system.

 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.

Goals of UML

A picture is worth a thousand words, this idiom absolutely fits describing UML. Object-
oriented concepts were introduced much earlier than UML. At that point of time, there were
no standard methodologies to organize and consolidate the object-oriented development. It
was then that UML came into picture.

There are a number of goals for developing UML but the most important is to define some
general purpose modeling language, which all modelers can use and it also needs to be made
simple to understand and use.

UML diagrams are not only made for developers but also for business users, common people,
and anybody interested to understand the system. The system can be a software or non-
software system. Thus it must be clear that UML is not a development method rather it
accompanies with processes to make it a successful system.

In conclusion, the goal of UML can be defined as a simple modeling mechanism to model all
possible practical systems in today‘s complex environment.

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
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

 Collaboration diagram

 Activity diagram

 Statechart diagram

 Deployment diagram

 Component diagram

PART - C (Descriptive/Analytical/Problem Solving/Design Questions)

Attempt any four questions
Q.1 Describe the Computer Based system as an organizational information system with an example.
Answer: Computer-Based Information Systems: All large organizations have computer-based information
systems:
 Some systems record routine activities called transactions.
 Employees hired
 Materials purchased
 Products produced
 Some systems also use these recorded events to help managerial planning and control.
 Systems can be supportive of one another through input and output of information.

Types of Computer Information Systems

There are four basic types of computer-based information Systems:
a. Transaction Processing Systems (TPS)
1. Record day-to-day transactions such as customer orders, bills, inventory.
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

2. Helps supervisors by generating databases needed for other information Systems.

3. Examples: recording customer orders, bills, inventory levels, and production output.
b. Management Information Systems (MIS)
1. Summarizes the detailed data of the transaction processing system.
2. Produces standard reports for middle-level managers.
3. Examples: Production schedule and budget summaries.
c. Decision Support Systems (DSS)
1. Draws on the detailed data of the transaction processing system.
2. Provides a flexible tool for middle-level managers for analysis.
3. Examples: Analyzing the effects of events such as strikes, rising interest rates, etc.
d. Executive Support Systems (ESS)
1. Presents information in a very highly summarized form.
2. Combines the internal data from TPS and MIS with external data.
3. Helps top-level managers oversee operations and develop strategic plans.
4. Examples: Introducing new products, starting a company wide cost control program, etc.

Q.2 Write a short not on a Finite State Machine (FSM).

Answer: The finite state machine (FSM) is a software design pattern where a given model transitions to other
behavioral states through external input. It is also known as state transition diagram (STD).
The state transition diagram (STD) indicates how the system behaves as a consequence of external events. To
accomplish this, the STD represents the various modes of behavior (called states) of the system and the manner in
which transitions are made from state to state. The STD serves as the basis for behavioral modeling. Additional
information about the control aspects of the software is contained in the control specification (CSPEC).
A FSM is defined by its states, its initial state and the transitions.
The power of FSM comes from the ability to clearly define different behaviors in different conditions. Usually FSM is
used with looping behavioral scripts which constantly evaluate the current situation in a loop or with events.
To help form an image of how this might be applied, a coffee machine will be used as an example of a finite state
machine. We will also cover a state diagram to visualise the FSM and provide coding examples.
State Diagram
This diagram shows three possible states for the coffee machine:
Open
ReadyToBuy
PoweredOff
The lines between these states show which transitions are possible between states and in which direction. These
transitions have conditions for when the FSM needs to change between states.
A FSM is defined by its states, its initial state and the transitions.
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

The power of FSM comes from the ability to clearly define different behaviors in different conditions. Usually FSM
is used with looping behavioral scripts which constantly evaluate the current situation in a loop or with events.
To help form an image of how this might be applied, a coffee machine will be used as an example of a finite state
machine. We will also cover a state diagram to visualise the FSM and provide coding examples.
State Diagram

This diagram shows the possible states for the coffee machine:
 Open (BUSY)
 ReadyToBuy(IDLE)
 PoweredOff
The lines between these states show which transitions are possible between states and in which direction. These
transitions have conditions for when the FSM needs to change between states.
 StartUpMachine From the PoweredOff state to the Open state the machine has to start up. This is done
manually in this case.
 deposit >= cost of coffee The FSM evaluates the amount of deposited cash either in a loop or when the
amount changes (recommended in this case) If you deposit enough cash into the coffee machine, the FSM
will go from ‗Open‘ to ‗ReadyToBuy‘.
 ShutdownMachine The machine will automatically go from Open to PoweredOff through the
ShutDownMachine method if the condition ‗no more coffees left‘ is met.
 DispenseCoffee In the ReadyToBuy state the user can buy a coffee whereafter it will be brewed and
dispensed. The condition is when the BuyCoffee event (!Link to observer pattern!) fires. (not shown in
diagram)
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

 CancelCoffee If the user opts to cancel, the machine will go from ReadyToBuy to Open.
 ShutDownMachine The machine will go to PoweredOff state
States
In every state there is defined behavior which will only be executed when the object is in that state. For instance,
during PoweredOff the coffee machine won‘t brew coffee before it‘s powered on, during the Open state it will wait
either until there‘s enough cash inserted, until the power down command is given, or until it runs out of coffee. During
this Open state it can do routines such as cleaning which won‘t happen in other states.
Initial State
Every FSM has an initial state, this means which state it starts in when it is created and has to be defined when
constructed or instantiated. Of course it‘s possible to directly change state if conditions are met.
Transitions
Every state either constantly evaluates if it should transition to another state or will transition to another state based on a
triggered event.
StartUpMachine From the PoweredOff state to the Open state the machine has to start up. This is done manually in
this case.
deposit >= cost of coffee The FSM evaluates the amount of deposited cash either in a loop or when the amount
changes (recommended in this case) If you deposit enough cash into the coffee machine, the FSM will go from
‗Open‘ to ‗ReadyToBuy‘.
ShutdownMachine The machine will automatically go from Open to PoweredOff through the ShutDownMachine
method if the condition ‗no more coffees left‘ is met.
DispenseCoffee In the ReadyToBuy state the user can buy a coffee whereafter it will be brewed and dispensed. The
condition is when the BuyCoffee event (!Link to observer pattern!) fires. (not shown in diagram)
CancelCoffee If the user opts to cancel, the machine will go from ReadyToBuy to Open.
ShutDownMachine The machine will go to PoweredOff state
States
In every state there is defined behavior which will only be executed when the object is in that state. For instance,
during PoweredOff the coffee machine won‘t brew coffee before it‘s powered on, during the Open state it will wait
either until there‘s enough cash inserted, until the power down command is given, or until it runs out of coffee. During
this Open state it can do routines such as cleaning which won‘t happen in other states.
Initial State
Every FSM has an initial state, this means which state it starts in when it is created and has to be defined when
constructed or instantiated. Of course it‘s possible to directly change state if conditions are met.
Transitions
Every state either constantly evaluates if it should transition to another state or will transition to another state based on a
triggered event.
Q.3 Explain object - oriented analysis and its approach and explain classes and object relationship model.
Answer:
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

Q.4 Explain major elements of DFD & CFD.

Answer: Elements of data-flow diagrams: Four basic elements are used to construct data-flow diagrams:
processes
data-flows
data stores
external entities
The rest of this section describes each of the four elements of DFDs, in terms of their purpose, how the
element is notated and the rules associated with how the element relates to others in a diagram.
Notation and software: A number of different notations exist for depicting these elements, although it is
only the shape of the symbols which vary in each case, not the underlying logic. This unit uses the Select
SSADM notation in the description and construction of data-flow diagrams.
As data-flow diagrams are not a part of the UML specification, ArgoUML and Umbrello do not support their
creation. However, Dia is free software available for both Windows and Ubuntu which does support data-
flow diagrams.
Processes: Processes are the essential activities, carried out within the system boundary, that use information.
A process is represented in the model only where the information which provides the input into the activity is
manipulated or transformed in some way, so that the data-flowing out of the process is changed compared to
that which flowed in.
The activity may involve capturing information about something that the organisation is interested in, such as
a customer or a customer's maintenance call. It may be concerned with recording changes to this information,
a change in a customer's address for example. It may require calculations to be carried out, such as the
quantity left in stock following the allocation of stock items to a customer's job; or it may involve validating
information, such as checking that faulty equipment is covered by a maintenance contract.
Notation: Processes are depicted with a box, divided into three parts.

Data-flows: A data-flow represents a package of information flowing between two objects in the data-flow
diagram. Data-flows are used to model the flow of information into the system, out of the system, and
between elements within the system.
Occasionally, a data-flow is used to illustrate information flows between two external entities, which is,
strictly speaking, outside of the system boundaries. However, knowledge of the transfer of information
between external entities can sometimes aid understanding of the system under investigation, in which case it
should be depicted on the diagram.
Notation: A data-flow is depicted on the diagram as a directed line drawn between the source and recipient
of the data-flow, with the arrow depicting the direction of flow.
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

Data stores: A data store is a place where data is stored and retrieved within the system. This may be a
file, Customer Contracts file for example, a catalogue or reference list, Options Lists for example, a log book
such as the Job Book, and so on.
Notation: A data store is represented in the data-flow diagram by a long rectangle, containing two locations.

External entities: External entities are entities outside of the system boundary which interact with the
system, in that they send information into the system or receive information from it. External entities may be
external to the whole organisation — as in Customer and Supplier in our running example; or just external to
the application area where users' activities are not directly supported by the system under
investigation. Accounts and Engineering are shown as external entities as they are recipients of information
from the system. Sales also provide input to the system.
External entities are often referred to as sources and sinks. All information represented within the system is
sourced initially from an external entity. Data can leave the system only via an external entity.
Notation: External entities are represented on the diagram as ovals drawn outside of the system boundary,
containing the entity name and an identifier.

A control-flow diagram can consist of a subdivision to show sequential steps, with if-then-else conditions, repetition,
and/or case conditions. Suitably annotated geometrical figures are used to represent operations, data, or equipment,
and arrows are used to indicate the sequential flow from one to another.
There are several types of control-flow diagrams, for example:
 Change-control-flow diagram, used in project management
 Configuration-decision control-flow diagram, used in configuration management
 Process-control-flow diagram, used in process management
 Quality-control-flow diagram, used in quality control.
In software and systems development, control-flow diagrams can be used in control-flow analysis, data-flow analysis,
algorithm analysis, and simulation. Control and data are most applicable for real time and data-driven systems. These
flow analyses transform logic and data requirements text into graphic flows which are easier to analyze than the text.
PERT, state transition, and transaction diagrams are examples of control-flow diagrams.
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

Elements of CFD are :

1. The Oval
An End or a Beginning

The oval, or terminator, is used to represent the start and end of a process. Use the Gliffy flowchart tool to drag and
drop one of these bad boys and you've got yourself the beginning of a flowchart. Remember to use the same symbol
again to show that your flowchart is complete.
2. The Rectangle
A Step in the Flowcharting Process

The rectangle is your go-to symbol once you've started flowcharting. It represents any step in the process you‘re
diagramming and is the workhorse of the flowchart diagram. Use rectangles to capture process steps like basic tasks
or actions in your process.
3. The Arrow
Indicate Directional Flow

The arrow is used to guide the viewer along their flowcharting path. And while there are many different types of
arrow tips to choose from, we recommend sticking with one or two for your entire flowchart. This keeps your
diagram looking clean, but also allows you to emphasize certain steps in your process.
4. The Diamond
Indicate a Decision
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

The diamond symbolizes that a decision is required to move forward. This could be a binary, this-or-that choice or a
more complex decision with multiple choices. Make sure that you capture each possible choice within your diagram.

Q.5 Explain the use case diagram and state diagram in the context of UML.
Answer: UML Use Case Diagrams: Use case diagrams are usually referred to as behavior diagrams used to
describe a set of actions (use cases) that some system or systems (subject) should or can perform in
collaboration with one or more external users of the system (actors). Each use case should provide some
observable and valuable result to the actors or other stakeholders of the system.
UML specifications also described use case diagram as a specialization of a class diagram, and class diagram
is a structure diagram.
Use case diagrams are in fact twofold - they are both behavior diagrams, because they describe behavior of
the system, and they are also structure diagrams - as a special case of class diagrams where classifiers are
restricted to be either actors or use cases related to each other with associations.

Use case diagrams are considered for high level requirement analysis of a system. When the
requirements of a system are analyzed, the functionalities are captured in use cases.

We can say that use cases are nothing but the system functionalities written in an organized
manner. The second thing which is relevant to use cases are the actors. Actors can be defined
as something that interacts with the system.

Actors can be a human user, some internal applications, or may be some external
applications. When we are planning to draw a use case diagram, we should have the
following items identified.

 Functionalities to be represented as use case

 Actors

 Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system. After
identifying the above items, we have to use the following guidelines to draw an efficient use
case diagram
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

 The name of a use case is very important. The name should be chosen in such a way
so that it can identify the functionalities performed.

 Give a suitable name for actors.

 Show relationships and dependencies clearly in the diagram.

 Do not try to include all types of relationships, as the main purpose of the diagram is
to identify the requirements.

 Use notes whenever required to clarify some important points.

Following is a sample use case diagram representing the order management system. Hence, if
we look into the diagram then we will find three use cases (Order, SpecialOrder, and
NormalOrder) and one actor which is the customer.

The SpecialOrder and NormalOrder use cases are extended from Order use case. Hence, they
have extended relationship. Another important point is to identify the system boundary,
which is shown in the picture. The actor Customer lies outside the system as it is an external
user of the system.

A state diagram is used to represent the condition of the system or part of the system at finite instances of time. It‘s
a behavioral diagram and it represents the behavior using finite state transitions. State diagrams are also referred to
as State machines and State-chart Diagrams. These terms are often used interchangeably. So simply, a state
diagram is used to model the dynamic behavior of a class in response to time and changing external stimuli. We can
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

say that each and every class has a state but we don‘t model every class using State diagrams. We prefer to model the
states with three or more states.
Uses of statechart diagram –
 We use it to state the events responsible for change in state (we do not show what processes cause those
events).
 We use it to model the dynamic behavior of the system .
 To understand the reaction of objects/classes to internal or external stimuli.
Basic components of a statechart diagram –
1. Initial state – We use a black filled circle represent the initial state of a System or a class.

Figure – initial state notation

2. Transition – We use a solid arrow to represent the transition or change of control from one state to another.
The arrow is labelled with the event which causes the change in state.

Figure – transition
3. State – We use a rounded rectangle to represent a state. A state represents the conditions or circumstances of
an object of a class at an instant of time.

Figure – state notation

4. Fork – We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow from the
parent state and outgoing arrows towards the newly created states. We use the fork notation to represent a
state splitting into two or more concurrent states.
 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

Figure – a diagram using the fork notation

5. Join – We use a rounded solid rectangular bar to represent a Join notation with incoming arrows from the
joining states and outgoing arrow towards the common goal state. We use the join notation when two or
more states concurrently converge into one on the occurrence of an event or events.

Figure – a diagram using join notation

6. Self transition – We use a solid arrow pointing back to the state itself to represent a self transition. There
might be scenarios when the state of the object does not change upon the occurrence of an event. We use self
transitions to represent such cases.

Figure – self transition notation

7. Composite state – We use a rounded rectangle to represent a composite state also.We represent a state with
internal activities using a composite state.

Figure – a state with internal activities

8. Final state – We use a filled circle within a circle notation to represent the final state in a state machine
diagram.

Figure – final state notation

 SOLUTION of RTU PAPER 3CS4-07 Software Engineering

Steps to draw a state diagram –

1. Identify the initial state and the final terminating states.
2. Identify the possible states in which the object can exist (boundary values corresponding to different
attributes guide us in identifying different states).
3. Label the events which trigger these transitions.
Example – state diagram for an online order –

Figure – state diagram for an online order