1 Nikoshicage

Function Oriented Design Case Study Ppt

Presentation on theme: "Function-oriented Design"— Presentation transcript:

1 Function-oriented Design
Andrew IrelandSchool of Mathematical & Computer SciencesHeriot-Watt UniversityEdinburgh

2 OutlineMotivationsData flowStructuringDetailed design

3 MotivationsMany significant software systems fall into this classification, e.g. transaction processingMany legacy applications were developed usingfunction-oriented design

4 Function-oriented Design
Applicability:Minimal system stateInformation is typically communicated via parameters or shared memoryNo temporal aspect to functions, i.e. the result of a function invocation is not dependent upon the function’s earlier invocationsApproach:Promotes a top-down functional decomposition style of design

5 Function-oriented Activities
Data flow design:Model data flow through the system as a set of data flow diagramsStructural decomposition:Model the functionality of the system as a hierarchy of sub-functions via the structure chart notationDetailed design:Provide detailed data and functional descriptions, typically supported by the notion of a data dictionary

6 Data Flow DiagramsData Flow Diagrams (DFDs) are used to represent the flow of information through a system, i.e. how the system outputs are derived by the functional transformation of input data sourcesDFDs are used within many design methods and are supported by numerous computer assisted software engineering (CASE) toolsNo standard notation …

7 DFD Notation User interaction with the system, i.e. input/output
Data store, e.g. database, files, etcSystem function/operation/processLabelled data flowNote: data flows can be combined logically, i.e. and/or

8 Example: Regression Testing
Testing that code modifications have not regressed thecorrectness of the system as a whole:“Also as a consequence of the introduction of new bugs, program maintenance requires far more system testing per statement written than any other programming. Theoretically, after each fix one must run the entire batch of test cases previously run against the system, to ensure that it has not been damaged in an obscure way. In practice, such regression testing must indeed approximate this theoretical idea, and it is very costly."Fred Brooks, The Mythical Man Month (p 122)

9 Example: Regression Testing
Consider the following system requirements:A user provides a name for a source code baseIf valid, then the source code base is retrieved from a database along with its associated regression test suit, which is held in a separate databaseThe source code is executed against the regression testsThe test results are compared against the expected results, which are held in another databaseIf actual and expected results differ then a report is generated for the user, else a certificate is generated for the userA log file summarizing the regression testing stored in a database

10 DFD Example and or Data flow l_file Regression test db s_file r_res
Source code dbGen Logs_filer_resreportt_filea_resTest case dbGen reportsandRun testsComparer_residr_fileidGen reportsorValidatec_filee_fileExpected results dbcertifGen certifsData flow

11 Exercise: Wanted Persons
Consider the following system requirements:A user provides facial features based upon crime reportsIf valid, then the feature list is used to retrieve a list of relevant feature templates from a database. If the feature list is not valid then an error message is sent to the userThe feature template list is used to search for matching offender imagines which are stored within an offender records databaseAny records for offenders already in prison are then prunedFrom pruned list, a suspect list is dispatched to the user, while the corresponding records are sent to a “wanted persons” databaseExercise: construct a DFD for the requirements above

12 Exercise: Wanted Persons
Consider the following system requirements:A user provides facial features based upon crime reportsIf valid, then the feature list is used to retrieve a list of relevant feature templates from a database. If the feature list is not valid then an error message is sent to the userThe feature template list is used to search for matching offender imagines which are stored within an offender records databaseAny records for offenders already in prison are then prunedFrom pruned list, a suspect list is dispatched to the user, while the corresponding records are sent to a “wanted persons” databaseExercise: construct a DFD for the requirements above

13 DFD Example or and feature list features error-msg get feature list
validate featuresorfeature listfeaturetemplatedbtemplatesfiltertemplatestemplate listoffenderimagedbimagesmatchimagessuspect listimagesandprisonrecords dbrecordsextractsuspectsrecordswantedpersons db

14 Hierarchical DFDs As system complexity grows, so will the DFDs
Hierarchical, or layered, DFDs provide a way of managing this complexity, i.e.Firstly, a Context Diagram (Level 0) is used to model the system as a single system process together with the environment in which it operates, e.g. users and external data storesThen, Level 1, 2, 3 … DFDs are developed, which model the system’s sub-processes

15 A Context Diagram (Level 0)

16 Level 1 DFD12

17 Level 2 DFD1.11.22.12.2

18 Structural Decomposition
For a given DFD there will exist choices as to how it is implementedThe structure chart notation provides a means of adding more structure to the designEach function (or procedure) is represented as a rectangleA high-level function is represented as a hierarchy of sub-functionsLinks between sub-functions are labelled with input/output data, i.e. parameters or shared data

19 Structural Decomposition
yxyyAAAAxxxxinputoutputtransformCo-ordinate

20 Structural Decomposition
Note that a structure chart shows the relationship between sub-functions, but not the order in which they are invokedTypically a series of structure charts are developed for a given DFD – incrementally expanding level by level, e.g.AAzzxxBCBCxvrtusDEF

21 Structural Decomposition
BEFGHIJKinputprocessoutput

22 Structural Decomposition
decisionmakingACDBEFGHIJKdataprocessing

23 Structure Chart: First
Regression testeridresidresInitializeTestReportSource code idSource codeTest casesExpected resultsRegression results:regression logdefect reportcertificate

24 Structure Chart: Second
Regression testeridr_residr_resInitializeTestReportidr_resr_resr_resididresa_resValidateRun testsCompareLoggerGeneratorSource codeTest casesExpected resultsRegression logDefect reportCertificate

25 Structure Chart: Third
Regression testeridr_residr_resInitializeTestReportidr_resr_resr_resididresa_resValidateRun testsCompareLoggerGeneratorl_files_filet_filee_filer_filec_fileGen reportGen certSource code dbTest case dbExpected results dbreportcertRegression test db

26 Detailed DesignDetailed design involves getting inside the functional blocks represented with the structure chart notationAt this level, Process Description Languages (PDL), i.e. pseudo codeA useful intermediate representation is a Data Dictionary (DD) – a structured, but informal, record of data items and functionalDDs are useful to designers, programmers as well as during maintenance

27 Example: Data Dictionary
EntityTypeDescriptionidstringName of the source code base under testresbooleanThe result of validating the name of the source code base provided by the user…r_resvectorThe regression test results, i.e. the actual results vs expected resultsa_resThe actual results obtained by executing the code base against the regression teststestprocedureInput: name of source code baseFunction: co-ordinates the execution of the regression tests and the comparison with the expected resultsOutput: results of regression testing

28 Sequential vs Concurrent
Note that no explicit reference has been made as to how a design is implemented, i.e. sequential vs concurrentDFDs in particular do not impose a control paradigmA DFD representation of a function could be implemented as a:sequence of sub-function invocations orset of communicating processes

29 Summary Learning outcomes: Recommended reading:
Applicability of function-oriented designData flow and DFDsStructure charts and functional hierarchyDetailed design and data dictionariesRecommended reading:D. Budgen, “Software Design”, Addison-Wesley 2003I. Sommerville, “Software Engineering”, Addison-Wesley 2007

Software Design Strategies



Previous Page

Next Page  


Software design is a process to conceptualize the software requirements into software implementation. Software design takes the user requirements as challenges and tries to find optimum solution. While the software is being conceptualized, a plan is chalked out to find the best possible design for implementing the intended solution.

There are multiple variants of software design. Let us study them briefly:

Structured Design

Structured design is a conceptualization of problem into several well-organized elements of solution. It is basically concerned with the solution design. Benefit of structured design is, it gives better understanding of how the problem is being solved. Structured design also makes it simpler for designer to concentrate on the problem more accurately.

Structured design is mostly based on ‘divide and conquer’ strategy where a problem is broken into several small problems and each small problem is individually solved until the whole problem is solved.

The small pieces of problem are solved by means of solution modules. Structured design emphasis that these modules be well organized in order to achieve precise solution.

These modules are arranged in hierarchy. They communicate with each other. A good structured design always follows some rules for communication among multiple modules, namely -

Cohesion - grouping of all functionally related elements.

Coupling - communication between different modules.

A good structured design has high cohesion and low coupling arrangements.

Function Oriented Design

In function-oriented design, the system is comprised of many smaller sub-systems known as functions. These functions are capable of performing significant task in the system. The system is considered as top view of all functions.

Function oriented design inherits some properties of structured design where divide and conquer methodology is used.

This design mechanism divides the whole system into smaller functions, which provides means of abstraction by concealing the information and their operation.. These functional modules can share information among themselves by means of information passing and using information available globally.

Another characteristic of functions is that when a program calls a function, the function changes the state of the program, which sometimes is not acceptable by other modules. Function oriented design works well where the system state does not matter and program/functions work on input rather than on a state.

Design Process

  • The whole system is seen as how data flows in the system by means of data flow diagram.
  • DFD depicts how functions changes data and state of entire system.
  • The entire system is logically broken down into smaller units known as functions on the basis of their operation in the system.
  • Each function is then described at large.

Object Oriented Design

Object oriented design works around the entities and their characteristics instead of functions involved in the software system. This design strategies focuses on entities and its characteristics. The whole concept of software solution revolves around the engaged entities.

Let us see the important concepts of Object Oriented Design:

  • Objects - All entities involved in the solution design are known as objects. For example, person, banks, company and customers are treated as objects. Every entity has some attributes associated to it and has some methods to perform on the attributes.
  • Classes - A class is a generalized description of an object. An object is an instance of a class. Class defines all the attributes, which an object can have and methods, which defines the functionality of the object.

    In the solution design, attributes are stored as variables and functionalities are defined by means of methods or procedures.

  • Encapsulation - In OOD, the attributes (data variables) and methods (operation on the data) are bundled together is called encapsulation. Encapsulation not only bundles important information of an object together, but also restricts access of the data and methods from the outside world. This is called information hiding.
  • Inheritance - OOD allows similar classes to stack up in hierarchical manner where the lower or sub-classes can import, implement and re-use allowed variables and methods from their immediate super classes. This property of OOD is known as inheritance. This makes it easier to define specific class and to create generalized classes from specific ones.
  • Polymorphism - OOD languages provide a mechanism where methods performing similar tasks but vary in arguments, can be assigned same name. This is called polymorphism, which allows a single interface performing tasks for different types. Depending upon how the function is invoked, respective portion of the code gets executed.

Design Process

Software design process can be perceived as series of well-defined steps. Though it varies according to design approach (function oriented or object oriented, yet It may have the following steps involved:

  • A solution design is created from requirement or previous used system and/or system sequence diagram.
  • Objects are identified and grouped into classes on behalf of similarity in attribute characteristics.
  • Class hierarchy and relation among them is defined.
  • Application framework is defined.

Software Design Approaches

Here are two generic approaches for software designing:

Top Down Design

We know that a system is composed of more than one sub-systems and it contains a number of components. Further, these sub-systems and components may have their on set of sub-system and components and creates hierarchical structure in the system.

Top-down design takes the whole software system as one entity and then decomposes it to achieve more than one sub-system or component based on some characteristics. Each sub-system or component is then treated as a system and decomposed further. This process keeps on running until the lowest level of system in the top-down hierarchy is achieved.

Top-down design starts with a generalized model of system and keeps on defining the more specific part of it. When all components are composed the whole system comes into existence.

Top-down design is more suitable when the software solution needs to be designed from scratch and specific details are unknown.

Bottom-up Design

The bottom up design model starts with most specific and basic components. It proceeds with composing higher level of components by using basic or lower level components. It keeps creating higher level components until the desired system is not evolved as one single component. With each higher level, the amount of abstraction is increased.

Bottom-up strategy is more suitable when a system needs to be created from some existing system, where the basic primitives can be used in the newer system.

Both, top-down and bottom-up approaches are not practical individually. Instead, a good combination of both is used.


Previous Page

Print

PDF

Next Page  


Leave a Comment

(0 Comments)

Your email address will not be published. Required fields are marked *