Systems design tools/ techniques

Structured Analysis and Design Technique (SADT) is a diagrammatic notation designed

specifically to help people describe and understand systems

There are five design tools to system development and analysis

Control Flow diagrams (Flowcharts), Data Flow Diagram, Use Case Diagram, Entity-Relationship
Diagram, and State-Transition Diagram

Flowchart

Flowchart is the schematic representation of a process. It is the earliest and best known diagramming
tools. It is also known as Control flow diagram. Flowchart allows users to graphically view the process
and also helps them including audiences easily understand the content and easily find flows in the
process. It breaks a process down to a finite number of steps that get executed one at a time. Thus, if
the flowcharts accurately describe the content carried out within them in the diagram, they can be used
for analysis.

Why flowchart is not popular in system analysis

However, there are several reasons that most system analysts actually do not use detailed flowcharts for
process specifications
• Flowcharts can be difficult to read and complicated. Using flowcharts required users to deeply
understand the systems and frequently modified the flowcharts to the simpler way.
• Flowcharts will be the time consuming and tedious to redraw the flowchart each time because
it requires system analysts to redraw it whenever the detailed policy changes.
• New diagramming method such as Data Flow Diagrams are more effective way to illustrate a
multidimensional reality.

Flowchart components

Flowcharts are composed of many symbols but the common flowcharts are composed of three basic
symbols: Arrows, Diamonds and Rectangles.
• Arrows represent flow of control. It must be draw from one symbol and end at another symbol.
• Diamonds represent decision points. Typically, it contains a Yes/No or True/False question
and requires two Arrows coming out of it to support the decision. Nevertheless, it is possible
that there are more than two Arrows coming out of it. In that case, it will be the clear indicator
of the complex decision and it is usually required to be broken down.
• Rectangles represent tasks or activities that occur in the processes.
Flowcharts may also contain other symbols such as page connectors when your diagram is too big to fit
in one page, input/output which is represented by parallelogram and etc.

Unlike Data Flow Diagrams which are used to describe data flow within the system, flow charts are
typically used to describe the detailed logic of a business process or business rule.
Example 2. Pseudocode

DO Fill_Water_Can
IF Plant_Soil_Moist THEN
IF Plant_Type = Succulent THEN
DO Add_Some_Water
ELSE
Do Add_Lots_of_Water
ENDIF
ENDIF

Data Flow Diagrams (DFDs)

Data flow diagrams (DFDs) reveal relationships among and between the various components in a program or
system. DFDs are an important technique for modeling a system’s high-level detail by showing how input data
is
transformed to output results through a sequence of functional transformations. DFDs consist of four major
components: entities, processes, data stores, and data flows.
A data flow diagram illustrates the processes, data stores, and external entities in a business or other
system and the connecting data flows. There are only four symbols for a data flow diagram: Squares or
Ovals, Circle or Rounded Rectangles, Arrows, and Open-ended Rectangles.
• Squares or Ovals represent external entities, terminators, sources, or sinks. Typically, a
terminator is a person or a group of people outside the control of the system being modeled. It
represents where information comes from and where it goes. There are three important things
that we must remember about terminators:
o They must be outside the system we are being modeled.
o As a result, neither the system analysts nor system designers are able to change the
contents, organization and the internal process within the terminators.
o Any relationship between each terminator is not a part of the system we are considering,
so the system analysts and designers can not include any relationship that exists
between terminators. Thus, in case there are relationships occur between terminators
and those relationships are important for system analysts to model a proper system, the
terminators are actually part of the system and system analysts should include it as
processes in data flow diagram, not terminators.
• Circles or Rounded Rectangles represent processes within the system. It shows a part of the
system that transforms inputs into outputs. The name of the process in the symbols usually
explains what the process does so that it is generally used with verb-object phase. In some cases,
however, the process may contain the name of the person or group of people, or a mechanical
device. So, it sometimes tells us who or what is carrying out the process, rather than describing
what the process is.
• Arrows represent the data flows. It can be either be electronic data or physical items or both.
The name of the arrows represents the meaning of the packet (data or items) that flow along. In
addition, like Arrows in flow charts, Arrows in data flow diagrams show direction to indicate
whether data or items are moving out or into a process.
• Open-ended Rectangles represent data stores, including both electronic stores and physical
stores. Data stores might be used for accumulating data for a long or short period of times.

Nonetheless, the data flow diagram doesn’t answer a lot of procedural questions that you might have
when looking at the DFD. All the questions related to procedural details are normally modeled within
Flowcharts or other procedural modeling tools. Some examples of the procedural questions are what
the criteria for moving data from one process to another process and what the order in which the
processes are performed.
Rules of Drawing Data Flow Diagram
Furthermore, there are several common modeling rules that you need to follow when creating Data
Flow Diagrams.
• At least one data flow in and one data flow out is required to each process in the system.
• The data output for each process should be modified from the data input. So, the outgoing data
should be in the new forms.
• Each data store must be involved with at least one data flow.
• Each external entity must be involved with at least one data flow.
 • A data flow must be attached to at least one process.
• A data flow can be moved in one direction only.
• A data flow can not be returned to the process from which it originated.
• Both branches of a joined data flow must have the same data type.
Data Flow Diagram Levels
In the real projects, data flow diagrams are considerably large and complex. So we need to avoid
drawing the whole system in only one diagram. System analysts organize the overall DFD in a series
of levels so that each level provides successively more detail about a portion of the level above it. The
top-level DFD is called a context diagram which represents the system as a single process. It consists
of only one circle representing the entire system, the data flows showing the interaction between the
system and the external terminators. There is no data stores appear on a context diagram because the
data stores of the systems are conceptually inside the one process. The context diagrams are useful for
showing how a proposed system may behave for a specific example or scenario. The next level DFD
are called Level-0 DFD, Level-1 DFD, and so on. Level-0 diagram is the decomposition of the one
process from the context diagram into two to nine high-level processes. Then, each process in the Level-
0 diagram can be decomposed into the next level.

In order to properly create many levels of data flow diagram, you must understand two concepts:
decomposition and balancing.
• Decomposition is the iterative process by which system description has been broken down into
deeper detail. One process on a given diagram is then explained in greater detail on a lower-
level diagram.
• Balancing is the conservation of inputs and outputs to a data flow diagram process when that
process is decomposed into a lower level.

Example: university system student registration, exams etc:- to be drawn In class

Use Case Diagram

In the Unified Modeling Language (UML), a use case diagram is a sub class of behavioral diagrams.
Use Case Diagram is one of the Object Oriented Diagrams. It shows how a system interacts with the
external entities. So, it is relatively sparse about the details of how the system behaves internally and
how the external environment is configured. Indeed, Use Case Diagram shows what we want the system
to do rather than describe how it can be accomplished. One of the major benefits of this diagram is
communication.
Use Case Diagram Components
There are four major symbols in the Use Case Diagrams: Use cases, Actors, and Associations and
System boundary.
Use Cases describe a sequence of actions. Those actions must provide the measurable value to an
actor. It is represented by horizontal ellipse.
 Actors are a person, group of people, organization, or external system the plays a role in one or
more interactions with your system. Furthermore, it can be networks, communication devices,
computers, or other programs on the same computer. It is represented by stick figure.
Associations or Communications indicate the interaction described by a use case. It is
represented by lines connecting between use cases and actors with an optional arrowhead on
one end of the line. Notice that the arrowheads in Use Case diagram is used for indicating the
direction of the initial invocation of the relationship or to indicate the primary actor, while the
arrowheads of Data Flow Diagram is used for showing the flow of data in the system.
System boundary is the rectangle around the use cases. Anything within this boundary is the
functionality in scope of the system.
System analysts and designers must remember that interaction among actors is not shown in the Use
Case Diagrams. Thus, the system boundary should reexamine if the interaction between actors is
essential to a coherent description of the desired behavior. Furthermore, Actors are formed based on the
role we set. So, the different actors may actually be the same person.
Use Case Relationships
There are three major types of Use Case Relationships: Include Extend, and Generalization or
Inheritance.
• Include relationship occurs when the first use case depends on the outcome of the included
use case. It is helpful when the same use case can be factored out of two different use cases.
For example, when patient (actor) wants to make appointment (use case). It is required that
make appointment depends on check patient record (included use case). You may refer Include
relationships as the equivalent of a procedure call.
• Extend relationship indicates that the behavior of extension use case may be inserted in the
extended use case under some conditions. For instance, patient (actor) is linked to Pay Bill
(extension use case). Whenever the patient is required more treatment, the extend relationship
emerges between Pay Bill (extension use case) and Defer Payment (extended use case). You
may refer Extend relationships as the equivalent of a “hardware interrupt”.
• Generalization or Inheritance indicates that a given use case may be a specialized form of an
existing use case. For example, Pay Bill (parent use case) can be substituted by the Bill
Insurance (child use case) whenever necessary.
Entity-Relationship Diagrams
Entity-Relationship Diagrams is a network model that describes the stored data layout of a system
at a high level of abstraction. For the system analyst, the benefit of using Entity-Relationship Diagram
is that it concentrates on the relationships between data stores on the Data Flow Diagram that can be
seen only in the process specification. Since Data Flow Diagram mainly focuses on the function that
the system perform not the data that the system need, using Entity-Relationship Diagram is important
to capture another part of system analysis which concentrates mainly on the data in the system.
Entity-Relationship Components
There are four major components of an Entity-Relationship Diagram: Objects or Entities, Relationships,
Associative object type indicators, and Supertype/Subtype indicators.
Entities represent set of objects in the real world. Entities are represented by rectangles. It has
three main characteristics. First, each entity can be identified uniquely in some way. Student,
for example, must be able to distinguish from one another by student identities, or name
because if students are the same, then Student is meaningless in Entity-Relationship Diagram.
Second, each entity must play a necessary role in the system. In other words, objects which
have no role in the system can not put into the system. Third, each entity can be described by
one or more data elements. For instance, Textbook can be described by one attribute or one
data element, ISBN. Also, it can be described by combined attributes (Title, Author, Published
Date, and Edition).
Relationships represent set of connections between entities. It captures how two or more entities
are related to one another. Diamond symbols are used for identify relationships. We must keep
in mind that the relationship represents something that must not be calculated or derived
mechanically by the system. Also, more than one relationship can occur between objects.
Associative object type indicator represents something that functions both as an object and a
relationship.
Subtype/Supertype indicators represent objects and one or more subcategories connected by a
relationship. For example, Student can be connected with Part-time Student and Full-time
Student via unnamed relationship. So in this case, Student is Supertype and Part-time Student
and Full-time Student are subtypes. Also, all data elements in supertype can be applied to
subtypes and subtype have additional data elements to identify themselves.