TOPIC: FUNCTION ORIENTED DESIGN IN SOFTWARE ENGINEERING

TABLE OF CONTENTS
Points affecting selection of design approach Introduction to Function Oriented Design Approach Advantages of Function Oriented Design over Object Oriented Design

 Processes in Function Oriented Design:

Data Flow Design Structural Decomposition Detailed Design Description

Function Orinted Design Object Oriented Design Basic Terms Associated Function Oriented Design Conclusion

V/S with

Selection approach

of

design

The goal of software design is to find the best possible design that meets your needs You may have to explore different designs Unfortunately, evaluation criteria for a design are often subjective and non-quantifiable Major criteria to evaluate a design : o Correctness

A software design is correct if a system built precisely according to the design satisfies the requirements of the system A design should be verifiable (does an implementation match the design), complete (does the design address its specified requirements) and traceable (all design elements can be traced back to specific requirements) Efficiency Does the design efficiently make use of scarce resources: such as memory on a wireless sensor Maintainability How easy is it for the design of a system to be understood? Simpler designs make it easy for a developer to understand and then maintain the system Cost Does the design help to reduce costs in later phases of software development? Can one design achieve the same quality as another design while reducing costs

 Introduction to Function Oriented Design Approach

Function-oriented design is an approach to software design where the design is decomposed into a set of interacting units where each unit has a clearly defined function. A function oriented design strategy relies on decomposing the system into a set of interacting functions with a centralized system state shared by these functions. Function-oriented design has been practiced informally since programming began. Programs were decomposed into subroutines which were functional in nature. A functional approach to design is therefore most likely to be successful when the amount of system state information is minimized and information sharing is explicit.

Advantages of Function Oriented Design over Object Oriented Design:

1. As discussed above, there are classes of system, particularly business systems, where objectoriented design does not offer significant advantages in terms of system maintainability or reliability. In these cases, an object oriented approach may result in a less efficient system implementation. 2. Many organizations have developed standards and methods based on functional decomposition. They are understandably reluctant to discard these in favors of object-oriented design. Many design methods and associated CASE tools are functionally oriented. A large capital and training investment in these systems has been made. 3. An enormous number of systems have been developed using a functional approach. These legacy systems will have to be maintained for the foreseeable future. Unless they are radically reengineered, their design structure will remain functional.

 Following are the processes involved in function oriented design:

Data-flow design Data-flow design is concerned with designing a sequence of functional transformations that convert system inputs into the required outputs. The design is represented as data-flow diagrams. These diagrams illustrate how data flows through a system and how the output is derived from the input through a sequence of functional transformations. Data-flow diagrams. This model may be derived from data-flow models developed during the analysis process. Following are some of the symbols used in data flow diagram:
1.

Rounded rectangles represent functions which transform inputs to outputs. The transformation name indicates its function. Rectangles represent data stores. Again, they should be given a descriptive name. Circles represent user interactions with the system that provide input or receive output.

2.

3.

4.

Arrows show the direction of data flow. Their name describes the data flowing along that path. The keywords and and or. These have their usual meanings as in boolean expressions. They are used to link data flows when more than one data flow may be input or output from a transformation.

5.

 Structural decomposition
This structural model shows how a function is realized by a number of other functions which it calls. They show how one function calls others. They do not show the static block structure of a function or procedure .These are dynamic like data flow diagrams. Following are some useful rules to convert the data flow diagram into structural chart:

Identify system processing transformations These are the transformations in the diagram which are responsible for central processing functions. They are not concerned with any input or output functions such as reading or writing data, data validation or filtering or output formatting. Group these transformations under a single function at the first-level in the structure chart. Identify input transformations These are concerned with reading data, checking it, removing duplicates, etc. These should also be grouped under a single function at the first-level in the structure chart. Identify output transformations These are transformations which prepare and format output or write it to the users screen or other device.

 Detailed design description

At this stage in the design process, the designer should know the organization of the design and what each function should do. Design entity description is concerned with producing a short design
specification (sometimes called a minispec) of each function. This requires describing the function, its inputs and its outputs.

The data-flow diagrams and structure charts must be revisited and modified to incorporate the improved understanding of the design. The best way to manage these functional descriptions is to maintain them in a data dictionary.

Function Oriented Design V/S Object Oriented Design

S. No.
1)

Functionaloriented Approach
In the functionaloriented design approach, the basic abstractions, which are given to the user, are real-world

Objectoriented Approach
In the objectoriented design approach, the basic abstractions are not the real-world functions, but are the data abstraction where the real-

functions, such as sort, merge, track, display, etc. 2)

3)

world entities are represented, such as picture, machine, radar system, customer, student, employee, etc. In functionIn this design, the oriented design, functions are functions are grouped together grouped together on the basis of the by which a data they operate higher-level on, such as in class function is person, function obtained. An displays are made example of this member functions technique is to operate on its SA/SD. data members such as the person name, age, etc. in this approach, In this approach, the state the state information is information is not often represented in a represented in a centralized shared centralized memory but is shared memory. implemented/distrib uted among the objects of the system.

Some basic terms :

External Entity

An external entity is a source or destination of a data flow which is outside the area of study. Only those entities which originate or receive data are represented on a business process diagram. The symbol used is an oval containing a meaningful and unique identifier. Process A process shows a transformation or manipulation of data flows within the system. The symbol used is a rectangular box which contains 3 descriptive elements: Firstly an identification number appears in the upper left hand corner. This is allocated arbitrarily at the top level and serves as a unique reference.

Secondly, a location appears to the right of the identifier and describes where in the system the process takes place. This may, for example, be a department or a piece of hardware. Finally, a descriptive title is placed in the centre of the box. This should be a simple imperative sentence with a specific verb, for example 'maintain customer records' or 'find driver'. Data Flow A data flow shows the flow of information from its source to its destination. A data flow is represented by a line, with arrowheads showing the direction of flow. Information always flows to or from a process and may be written, verbal or electronic. Each data flow may be referenced by the processes or data stores at its head and tail, or by a description of its contents. Data Store A data store is a holding place for information within the system: It is represented by an open ended narrow rectangle. Data stores may be long-term files such as sales ledgers, or may be short-term accumulations: for example batches of documents that are waiting to be processed. Each data store should be given a reference followed by an arbitrary number. Resource Flow

A resource flow shows the flow of any physical material from its source to its destination. For this reason they are sometimes referred to as physical flows. The physical material in question should be given a meaningful name. Resource flows are usually restricted to early, high-level diagrams and are used when a description of the physical flow of materials is considered to be important to help the analysis. External Entities It is normal for all the information represented within a system to have been obtained from, and/or to be passed onto, an external source or recipient. These external entities may be duplicated on a diagram, to avoid crossing data flow lines. Where they are duplicated a stripe is drawn across the left hand corner, like this. The addition of a lowercase letter to each entity on the diagram is a good way to uniquely identify them. Processes When naming processes, avoid glossing over them, without really understanding their role. Indications that this has been done are the use of vague terms in the descriptive title area - like 'process' or 'update'.

The most important thing to remember is that the description must be meaningful to whoever will be using the diagram. Data Flows Double headed arrows can be used (to show twoway flows) on all but bottom level diagrams. Furthermore, in common with most of the other symbols used, a data flow at a particular level of a diagram may be decomposed to multiple data flows at lower levels. Data Stores Each store should be given a reference letter, followed by an arbitrary number. These reference letters are allocated as follows: 'D' - indicates a permanent computer file 'M' - indicates a manual file 'T' - indicates a transient store, one that is deleted after processing. In order to avoid complex flows, the same data store may be drawn several times on a diagram. Multiple instances of the same data store are indicated by a double vertical bar on their left hand edge.

CONCLUSION
Functional and object-oriented design result in different system decompositions. However, a heterogeneous approach to design is often necessary. Thus, the object oriented approach is better than functional oriented approach but there are some places in software engineering where there is need of functional oriented approach.