Management Information System Ch-6

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.

It shows how data enters and leaves the system, what changes the information, and where data is
stored.

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.

0-level DFD: 
It is also known as a context diagram. It’s designed to be an abstraction view, showing the
system as a single process with its relationship to external entities. It represents the entire
system as a single bubble with input and output data indicated by incoming/outgoing arrows.  

1-level DFD: 
In 1-level DFD, the context diagram is decomposed into multiple bubbles/processes. In this
level, we highlight the main functions of the system and breakdown the high-level process of
0-level DFD into subprocesses. 
2-level DFD: 
2-level DFD goes one step deeper into parts of 1-level DFD. It can be used to plan or record
the specific/necessary detail about the system’s functioning. 
Data Dictionaries

A data dictionary is a file or a set of files that includes a database's metadata. The data dictionary
hold records about other objects in the database, such as data ownership, data relationships to
other objects, and other data. The data dictionary is an essential component of any relational
database. Ironically, because of its importance, it is invisible to most database users. Typically,
only database administrators interact with the data dictionary.

The data dictionary, in general, includes information about the following:

o Name of the data item

Aliases include other names by which this data item is called DEO for Data Entry Operator and
DR for Deputy Registrar.

Decision Table
A Decision Table is a tabular representation of inputs versus rules/cases/test conditions. It is a
very effective tool used for both complex software testing and requirements management.
Decision table helps to check all possible combinations of conditions for testing and testers can
also identify missed conditions easily. The conditions are indicated as True(T) and False(F)
values.

What is Decision Table Testing?

What is a decision tree?

A decision tree is a map of the possible outcomes of a series of related choices. It allows an
individual or organization to weigh possible actions against one another based on their costs,
probabilities, and benefits. They can be used either to drive informal discussion or to map out an
algorithm that predicts the best choice mathematically.

A decision tree typically starts with a single node, which branches into possible outcomes. Each
of those outcomes leads to additional nodes, which branch off into other possibilities. This gives
it a treelike shape.

Use-case diagrams
In UML, use-case diagrams model the behavior of a system and help to capture the requirements of the
system.

Use-case diagrams describe the high-level functions and scope of a system. These diagrams also
identify the interactions between the system and its actors. The use cases and actors in use-case
diagrams describe what the system does and how the actors use it, but not how the system
operates internally.

The following topics describe model elements in use-case diagrams:

 Use cases
A use case describes a function that a system performs to achieve the user’s goal. A use case must
yield an observable result that is of value to the user of the system.
  Actors
An actor represents a role of a user that interacts with the system that you are modeling. The user
can be a human user, an organization, a machine, or another external system.
 Subsystems
In UML models, subsystems are a type of stereotyped component that represent independent,
behavioral units in a system. Subsystems are used in class, component, and use-case diagrams to
represent large-scale components in the system that you are modeling.
 Relationships in use-case diagrams
In UML, a relationship is a connection between model elements. A UML relationship is a type of
model element that adds semantics to a model by defining the structure and behavior between the
model elements.

Use case diagrams are used to gather the requirements of a system including internal
and external influences. These requirements are mostly design requirements. Hence,
when a system is analyzed to gather its functionalities, use cases are prepared and
actors are identified.
When the initial task is complete, use case diagrams are modelled to present the
outside view.
In brief, the purposes of use case diagrams can be said to be as follows −
 Used to gather the requirements of a system.
 Used to get an outside view of a system.
 Identify the external and internal factors influencing the system.
 Show the interaction among the requirements are actors.

Example of a Use Case Diagram

Here the Web Customer actor makes use of any online shopping website to purchase
online. The top-level uses are as follows; View Items, Make Purchase, Checkout, Client
Register. The View Items use case is utilized by the customer who searches and view
products. The Client Register use case allows the customer to register itself with the
website for availing gift vouchers, coupons, or getting a private sale invitation. It is to be
noted that the Checkout is an included use case, which is part of Making
Purchase, and it is not available by itself.