The History Of Operational Specification

Published Date: 02 Nov 2017

Introduction

In this lecture we present operational specification and the tools used in operational specification including data flow diagrams and state transition diagrams. The lecture is organized as follows: section 2 presents operational specification. Section 3 presents data flow diagrams and finally, section 4 presents state transition diagrams.

Learning Outcomes

Be familiar with Data Flow and State Transition Diagrams

16.1 Operational Specification

In operational specification intended systems specification is formalized by describing the system’s desired behavior which provides a model implementation of the system. Operational specification focuses on control aspects of the systems. The designer chooses to look at control issues of the systems rather than data issues. Of course, there are data aspects to these systems. However the designer views these data aspects more as parameters that influence the actions of the system.

Tools used in operational specification include:

Data flow diagrams.

State transition diagram

Finite state machines.

Petri nets.

(Some) UML diagrams

Operational methods build a model of the system from a set of basic objects such as numbers, sequences, and operations on these objects. Examples of operations include addition and concatenation. The semantics of an operation is then specified by its effects on the model. Since these methods essentially define states and transitions, they naturally produce executable specifications.

Example 1 of operational specification:

An operational specification of the integer stack might for example model it by a sequence of integers. It would also contain definitions of the operations in terms of well-defined operations on sequences (e.g. cons and first), such as the following:

pop(stack) : st’ = rest(stack)

push(stack, element) : st’ = cons(element, stack) ^ e’ = e

top(st, e) : e0 = first(st) ^ st’ = st

The postfix accent (‘) is used to refer to the variable value after the operation is carried out.

Example 2 of operational specification:

Let A be an array of n elements. The result of its sorting is an array B of n elements that may be built as follows:

Find the smallest element in A, and assign it as the first element in B

Remove the element you find in step 1 from A, and find the smallest of the remaining elements. Assign this element as the second element in B

Repeat steps 1 and 2 until all elements have been removed from A

Example 3 of operational specification:

Operational specification of a geometric figure E:E can be drawn as follows:

Select two points P1 and P2 on a plane

Get a string of a certain length and fix its ends to P1 and P2

Position a pencil as shown in next figure

Move the pen clockwise, keeping the string tightly stretched, until you reach the point where you started drawing

The originated geometric figure is shown in Figure 1.

Figure 1: Operational specification of a geometric figure E

16.2 Data Flow Diagrams (DFDs)

DFDs are tools used in structured analysis and design of systems. DFDs are semi-formal operational specification. They present the data flow inside a system as well as the data flow entering the system from the external environment. Data-flow diagrams (DFDs) were introduced in late 1970s and became popular for structured analysis and design.  Data Flow Diagrams are important techniques for modeling a system as it illustrates how data that is inputted is changed into output data by going through the internal processes of the system.

DFDs make up one of the three elements of the Structured Systems Analysis and Design Method (SSADM).

DFDs can be described as an illustration of the data flow inside a system, highlighting its processes. They help in developing a general ideal or an outline of the system which is later used for implementation purposes. DFDs can also be used as structured design for the visualization of data processing. DFDs show the data that is inputted into the system, the data that is outputted, the source of data, and the destination of data, and data storage.

DFDs show the interaction that occurs between a system’s components. These components can be divided into four categories; entities, processes, data stores, and data flows.

Figure 2 presents an example of a DFD that computes (a + b) * (c + a * d).  There are different symbols used in DFDs.

Figure 2: an example of a DFD that computes (a + b) * (c + a * d)

These symbols are listed in Table 1.

Table 1: Symbols used in DFDs

Symbol

Meaning

Squares/ Rectangular box

Represent the external environment. These can be the source of data (which enter the system) or the destination (data exiting the system reaches this point).

Rounded rectangles/ Bubble (Circle or round corner square)

Represent processes, which receive data (input), manipulate it, and output it.

The top area is occupied by a identification number assigned by the system indicating the order of the process in the system

The middle area is occupied by the process name

The bottom area is occupied by the description related who has done the work or what work has been done.

Arrows

Represent the data flows between entities which can either be electric data or physical items. The contents of the data are described by some simple phrases and listed close to the arrow

Open-ended rectangles

Represent data storage (electronic or physical) such as databases or filing cabinets/stacks of paper.

The identification number of the data store is listed at the left hand side area, i.e. square area

The contents of data store is listed at the right hand area, i.e. open area

DFDs are very good tool for representing how information flows through a system and how that data is transformed in the system processes. They have become a popular tool that has replaced older methods such as flowcharts and pseudo code.

Advantages of using DFDs include the following:

DFDs are easier to understand by technical and non-technical users.

DFDs provide a high-level illustration of the system, showing its boundaries and interactions with the external environment.

DFDs illustrate the system’s components.

DFDs use graphic techniques which are superb and simple.

System boundaries in DFDs are well described.

Each part of data can be represented by different level of details.

Drawbacks of DFDs include the following:

They cannot give a precise and detailed definition of the system being modeled.

Developers cannot simulate the system with DFDs.

Firstly, the context-level DFD is drawn by the developers. This shows the communication between the system and the surrounding, external environment, which in turn, shows the data sources and data sinks. The focus of context diagrams is to illustrate the interaction that occurs between the system and the outside world, in the form of data flow. The system is illustrated as one single entity or process, providing no details about its internal organization.

Secondly, the context-level DFD is further developed into a level 0 DFD. Level 0 DFDs compensate for the lack of internal processes shown in context-level DFDs as they illustrate the internal processes of the system in question. Level 0 DFDs shows how the data flows (either entering or exiting the system) through these internal processes. As well as the data flows, level 0 DFDs show the internal storage that is needed for the system to fully function.

16.3 State Transition Diagrams (STDs)

An STD is a tool used to describe the time-dependent behavior of a system. In STD the system's behavior in any state must be the same no matter by which path the state is arrived at. The basic idea of the design of systems using STDs is to define the number of states of the system. The system moves from one state to another state when it receives events from the outside world.

STDs give an explicit and formal definition of the behavior of the system.

A disadvantage STDs is that developers have to define all the possible states of a system. While this is fine for small systems, it is impractical in larger systems as there is an exponential growth in the number of states as the system grows in complexity. This exponential growth in the number of states leads to state transition diagrams becoming far too complex for practical use.

Transitions from one state to another can have a condition attached to them, i.e., the transition only occurs if the condition is true.

The major components of the diagram are:

States: A state is an observable mode of behavior of the system. A state is represented by a rectangular box in the STD.

Arrows: Arrows connect states. Arrows represent state changes.

At any time a particular STD can only be in one state. But a system's behavior could be described by more than one state transition diagram. Transition conditions from one state to another occur when internal events or events external to the system take place. Transition actions are actions in response to the events that trigger actions. These actions produce control outputs.

16.4 Drawing STDs

The following steps are used to draw a STD of a system:

Identify observable states of the system.

Select the states with normal behavior.

Specify the conditions that mark a transition between states.

Specify the actions to produce the observable behavior in the destination state for each transition.

If the system is complex, partition the diagram into several smaller STDs.

A typical state-transition diagram is shown in Figure 3. This diagram shows the behavior of a typical telephone answering machine.

Figure 3: A typical state-transition diagram

The initial state of the STD is typically the arrow drawn at the top of the diagram. Likewise, the final state, in most cases, is drawn at the bottom of the diagram. The final state (s) is identified by the lack of arrows representing the output of a state. A system can only have one initial state but may have many final states. Figure 4 shows an example of a system with two final states: state 4 and state 6.

Figure 4: Multiple final states of a system

Summary

In this lecture we present operational specification and the tools used in operational specification including data flow diagrams and state transition diagrams. The lecture is organized as follows: section 2 presents operational specification. Section 3 presents data flow diagrams and finally, section 4 presents state transition diagrams.

Exercises

A DFD is a tool used in operational specification. (TRUE)

DFDs present the data flow inside a system. (TRUE)

DFDs provide a low-level illustration of the system, not showing its boundaries and interactions with the external environment. (FALSE)

The basic idea of the design of systems using STDs is to define the number of states of the system. (TRUE)

A system can only have more than one initial state but only one final state. (FALSE.