Software Design doc

Structured Design Methodology …• modules dealing with inputs have to deal with issues of screens, reading data, formats, errors, exceptions, completeness of information, structure of the

Software Design

Software Design

• Introduction to Software Design

• Design Concepts

• Function-Oriented Design

Introduction to Software Design

• Design is module view The system

viewed as a collection of code units Each module implements some part of the

system functionality.

• Determine what modules the system

should have and which have to developed

• Modules can be packages, a class, a

procedure, a method, a collection of

functions, and a collection of classes

Introduction to…

• Relationships between modules are code-based and depend how code of a module interacts with another module

– “is a part of” (module B is a part of module A)

– “user depends on” (module A uses services of

module B to perform its own functions and

correctness of model A depends on correctness of

module B)

– “generalization or specialization” (module B is a

generalization of module A E.g B is superclass, A is subclass)

• Detailed design (logic design): Decide

internal design of modules, how the

specifications of module can be satisfied

- Detailed description of the processing

logic and data structures

Design Methodology

• A systematic approach of creating a

design by applying of a set of techniques and guidelines.

• A system is considered modular if it

consists of discrete modules so that each module can be implemented separately, and a change to one module has minimal impact on other modules.

• Independence: one module can function without presence of the other The more independent the connection between modules, the easier to solve and modify modules

• Coupling: the strength of interconnections

between modules The more we must know

about module A to understand module B, the

more closely connected A is to B

• Cohesion of a module represents how tightly

bond the internal elements of the module are to one another

• Usually, the greater the cohesion of each

module in the system, the lower the coupling

between modules is

Open-Closed Principle

• Goal: also to promote building of easily modified systems: A design that not easy to accommodate change will result in fast died system

• Basic principle: “Software entities should be open for extension, but closed for modification”

A module being “open for extension” means that its behavior can be extended to accommodate new demands placed on this module The module being “closed for modification” means that the existing source code of the module is not changed when making enhancements

Function-Oriented Design

• Structure charts

• Structured Design Methodology

• An Example

Structure Charts

• The structure of a program is made up of the

modules and the interconnections between

modules

• Every computer program has a structure, and given a program its structure can be determined

• The structure chart of a program is a graphic

representation of its structure

• A function-oriented design can be represented graphically by structure charts

Structure Charts…

• In a structure chart:

- A module is represented by a box with the module

name written in the box

- An arrow from module A to module B represents that module A invokes module B

- B is called the subordinate of A,

- A is called the superordinate of B

- The arrow is labeled by the parameters received by B

as input and the parameters returned by B as output,

with the direction of flow of the input and output

parameters represented by small arrows.

- The parameters can be shown to be data (unfilled circle

at the tail of the label) or control (filled circle at the tail)

Structure Charts - Example

main ()

{

int sum , n, N, a[MAX ];

readnums (a, &N); sort (a, N); scanf (&n);

sum = add_n (a, n); printf ( sum );

The structure chart of the sort program:

Structure Charts…

• The designer may wish to communicate certain procedural information explicitly, like major loops and decisions.

A repeatedly calls the

modules C and D

the invocation of modules C and D

in module A depends on the outcome of some decision

Structure Charts - Module

Categories

• input modules: obtain information from their

subordinates and then pass it to their

superordinate

• output modules: take information from their

superordinate and pass it on to its subordinates

• transform modules: for the sake of transforming data into some other form

• coordinate modules: manage the flow of data to and from different subordinates

Structure Charts

• A structure chart is a nice (succinct)

representation for a design that uses functional abstraction

• It shows the modules and their call hierarchy, the interfaces between the modules, and what information passes between modules

– Through the interface one module can interact with other modules An interface of a module is used to pass information to and from other modules.

• So, for a software system, once its structure is decided, the modules and their interfaces and dependencies get fixed

Structured Design Methodology

(SDM)

• The objective of the structured design

methodology is to control the eventual structure

of the system by fixing the structure during

Structured Design Methodology …

• No design methodology reduces design to a

series of steps that can be mechanically

executed All design methodologies are, at best,

a set of guidelines that, if applied, will most likely produce a design that is modular and simple

• The basic principle behind the structured design methodology is problem partitioning

• Structured design methodology partitions the

system at the very top level into various

subsystems, one for managing each major input, one for managing each major output, and one

for each major transformation

Structured Design Methodology …

• modules dealing with inputs have to deal with

issues of screens, reading data, formats, errors, exceptions, completeness of information,

structure of the information, etc

• modules dealing with output have to prepare the output in presentation formats, make charts,

produce reports, etc

• Transformation dealing with data and getting it in proper form for performing the transformation or producing the output in the desired form that

requires considerable processing

Restate the Problem as a Data

Flow Diagram (DFD)

• During requirements analysis: a DFD is drawn to model the problem domain The analyst has little control over the problem, and hence his task is to extract from the

problem all the information and then represent it as a

DFD

• During design activity: dealing with the solution domain and developing a model for the eventual system DFD represents how the data will flow in the system when it is built In this modeling, the major transforms or functions

in the software are decided, and the DFD shows the

major transforms that the software will have and how the data will flow through different transforms.

Data flow diagram of an ATM

Identify the Most Abstract Input and

Output Data Elements

• This second step is to separate the

transforms in the DFD that convert the

input or output to the desired format from the ones that perform the actual

transformations.

The most abstract input data elements

• Data elements in the data flow diagram

that are farthest removed from the

physical inputs but can still be considered inputs to the system

• They often have little resemblance to the actual physical data These are often the data elements obtained after operations like error checking, data validation, proper formatting, and conversion are complete.

The most abstract output data

elements

• The data elements that are most removed from the actual outputs but can still be considered

outgoing

• The most abstract output data elements are

identified by starting from the outputs in the DFD and traveling toward the inputs

• These data elements may also be considered

the logical output data items, and the transforms

in the data flow diagram after these data items are basically to convert the logical output into a form in which the system is required to produce the output

Central transforms

• Central transforms perform the basic

transformation for the system, taking the most abstract input and transforming it into the most abstract output

• Purpose: Modules implementing these

transforms can concentrate on performing the

transformation without being concerned with

converting the data into proper format, validating the data, and so forth

SDM… First-Level Factoring

• Specify a main (coordinate) module, whose purpose is to invoke the subordinates

• For each of the most abstract input data items, an

immediate subordinate (input) module to the main

module is specified to deliver to the main module the

most abstract data item.

• for each most abstract output data item, a subordinate (output) module that accepts data from the main module

is specified

• Each of the arrows connecting these input and output

subordinate modules is labeled with the respective

abstract data item flowing in the proper direction.

First-Level Factoring…

• For each central transform, a (transform) module

subordinate to the main one is specified to accept data from the main module, and then return the appropriate data back to the main module

• The data items coming to a transform module from the main module are on the incoming arcs of the

corresponding transform in the data flow diagram The data items returned are on the outgoing arcs of that

transform

• Note that here a module is created for a transform, while input/output modules are created for data items.

Example

SDM - Factoring the Input, Output,

and Transform Branches

• The first-level factoring results in a very

high level structure, where each

subordinate module has a lot of

Factoring input module

• The purpose of an input module, as viewed by the main program, is to produce some data To factor an input

module, the transform in the DFD that produced the data item is now treated as a central transform

• The process performed for the first-level factoring is

repeated here with this new central transform, with the input module being considered the main module.

• A subordinate input module is created for each input

data stream coming into this new central transform, and

a subordinate transform module is created for the new central transform The new input modules now created can then be factored again, until the physical inputs are reached Factoring of input modules will usually not yield any output subordinate modules.

Factoring output module

• The factoring of the output modules is

symmetrical to the factoring of the input

modules

• For an output module we look at the next

transform to be applied to the output to bring it closer to the ultimate desired output This now becomes the central transform, and an output

module is created for each data stream going

out of this transform

• During the factoring of output modules, there will usually be no input modules

Factoring transform module

• Method: Treat a transform module as a problem and

start with a DFD for it

• The inputs to the DFD are the data coming into the

module and the outputs are the data being returned by the module

• Each transform in this DFD represents a subtransform of this transform The central transform can be factored by creating a subordinate transform module for each of the transforms in this DFD

• This process can be repeated for the new transform

modules that are created, until reaching atomic modules

• Problem: determining the number of different words in an input file This problem has only one input data stream, the input file, while the desired output is the count of different words in the file.

DFD for the word-counting problem (mai/o - most abstract input/output)

• To transform the input to the desired

output

– form a list of all the words in the file

– sort the list, as this will make identifying

different words easier

– count the number of different words, and the output of this transform is the desired count– print

• The arcs in the data flow diagram are the most abstract input and most abstract output

• The choice of the most abstract input is obvious

– Start following the input First, the input file is converted into a word list, which is essentially the input in a different form

– The sorted word list is still basically the input, as it is still the same list,

in a different order This appears to be the most abstract input because the next data (i.e., count) is not just another form of the input data

• The choice of the most abstract output is even more obvious

– count is the natural choice (a data that is a form of input will not usually

be a candidate for the most abstract output)

• Thus, we have one central transform, words, which has one input and one output data item.

count-number-of-different-Example-First Level Factoring

Example - Factoring the input

module

The factoring of the input module get-sorted-list

Example-Factoring the central

transform

Factoring of the central transform count-the-number-of-different-words

• P Jalote A Concise Introduction to

Software Engineering Springer, 2008.