software design 1. software design is a creative process, just like designing anything else to see...

1

Software Design

2

Software Design

Software design is a creative process, just like designing anything else

To see a wrong design, we can check with the requirements in the analysis model

To see a bad design, we need to assess the design model and analyse the components, whether the performance can be improved by changing the modules or the interfaces

In Analysing the software Design many factors are used, such as Coupling, Cohesion, Factoring, System Shape, etc.

Desired Class/Object Interaction

Maximize internal interaction (cohesion) easier to understand easier to test

Minimize external interaction (coupling) can be used independently easier to test easier to replace easier to understand

Characteristics of Good Design

Component independence High cohesion Low coupling

Exception identification and handling Fault prevention and fault tolerance

5

Coupling

The degree of interdependence between two modules. we aim to minimize coupling - to make modules as

independent as possible Low coupling can be achieve by:

eliminating unnecessary relationships reducing the number of necessary relationships easing the ‘tightness’ of necessary relationships

6

Types of Coupling

Data coupling (Most Required)

Stamp coupling

Control coupling

Hybrid coupling

Common coupling

Content coupling (Least Required)

7

Data Coupling

Modules communicate by parameters.

Each parameter is an elementary piece of data.

Each parameter is necessary to the communication.

Nothing extra is needed.

8

Stamp coupling

A composite data is passed between modules . Internal structure contains data not used . Bundling - grouping of unrelated data into an artificial

structure.

9

Control coupling

A module controls the logic of another module through the parameter .

Controlling module needs to know how the other module works - not flexible!

Hybrid coupling. A subset of data used as control . Example: account numbers 00001 to 99999 If 90000 - 90999, send mail to area code of last 3 digit

(000 - 999)

10

Common coupling

Use of global data as communication between modules.

Dangers of ripple effect

inflexibility

difficult to understand the use of data

11

Content coupling

A module refers to the inside of another module. .

Branch into another module.

Refers to data within another module.

Changes the internal workings of another module.

Mostly by low-level languages .

12

Cohesion

“The measure of the strength of functional relatedness of elements within a module” Elements: instructions, groups of instructions, data definition, call of

another module

We aim for strongly cohesive modules Everything in module should be related to one another -

focus on the task. Strong cohesion will reduce relations between modules -

minimise coupling.

13

Types of Cohesion

Functional cohesion (Most Required) Sequential cohesion Communicational cohesion Procedural cohesion Temporal cohesion Logical cohesion Coincidental cohesion (Least Required)

14

Functional cohesion

All elements contribute to the execution of one and only one problem-related task

Focussed - strong, single-minded purpose No elements doing unrelated activities Examples of functional cohesive modules:

Compute cosine of angle Read transaction record Assign seat to airline passenger

15

Sequential cohesion

Elements are involved in activities such that output data from one activity becomes input data to the next

Usually has good coupling and is easily maintained Not so readily reusable because activities that will not in

general be useful together Example of Sequential Cohesion

module format and cross-validate record • use raw record • format raw record • cross-validate fields in raw record • return formatted cross-validated record

end module

16

Communicational Cohesion

Elements contribute to activities that use the same input or output data

Not flexible, for example, if we need to focus on some activities and not the others

Possible links that cause activities to affect each other Better to split to functional cohesive ones Example of Communicational Cohesion

module determine customer details • use customer account no • find customer name • find customer loan balance • return customer name, loan balance

end module

17

Procedural cohesion

Elements are related only by sequence, otherwise the activities are unrelated .

Similar to sequential cohesion, except for the fact that elements are unrelated

Commonly found at the top of hierarchy, such as the main program module

Example of Procedural Cohesion module write read and edit something

• use out record • write out record • read in record • pad numeric fields with zeros • return in record

end module

18

Temporal cohesion

Elements are involved in activities that are related in time . Commonly found in initialisation and termination modules Elements are basically unrelated, so the module will be

difficult to reuse. Good practice is to initialise as late as possible and terminate

as early as possible Example of Temporal Cohesion

module initialise• set counter to 0 • open student file • clear error message variable• initialise array

end module

19

Logical cohesion

Elements contribute to activities of the same general category (type) .

For example, a report module, display module or I/O module Usually have control coupling, since one of the activities will be selected

Example of Logical Cohesion

20

Example of Logical Cohesion

module display record use record-type, record if record-type is student then display student record else if record-type is staff then display staff record

end module

21

Coincidental cohesion

Elements contribute to activities with no meaningful relationship to one another .

Similar to logical cohesion, except the activities may not even be the same type .

Difficult to understand and maintain, with strong possibilities of causing ‘side effects’ every time the module is modified.

Example of Coincidental Cohesion

22

Example of Coincidental Cohesion

module miscellaneous functions

use customer record

display customer record

calculate total sales

read transaction record

return transaction record end module

23

The Open-Closed Principle

It’s a principle for object oriented design first described by Bertrand Meyer that says that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”.

The Open Close Principle encourages software developers to design and write code in a fashion that adding new functionality would involve minimal changes to existing code. Most changes will be handled as new methods and new classes

Like cohesion and coupling, the basic goal here is again to promote building of systems that are easily modifiable.


A module being “open for extension” means that its behavior can be extended to accommodate new demands placed on this module due to changes in requirements and system functionality.

The module being “closed for modification” means that the existing source code of the module is not changed when making enhancements.

This principle restricts the changes to modules to extension only, i.e. it allows addition of code, but disallows changing of existing code.

Code changes involve heavy risk

25


But if changes are not made, how will enhancements be made? This principle says that enhancements should be made by adding new code, rather than altering old code.

There is another side benefit of this. Programmers typically prefer writing new code rather than modifying old code.

If this principle is satisfied, then we can expand existing systems by mostly adding new code to old systems, and minimizing the need for changing code

26


This principle can be satisfied in OO designs by properly using inheritance and polymorphism.

Inheritance allows creating new classes that will extend the behavior of existing classes without changing the original class. And it is this property that can be used to support this principle.

Example, consider an application in which a client object (of type Client) interacts with a printer object (of class Printer1) and invokes the necessary methods for completing its printing needs. The class diagram for this will be as shown in Figure

27

Example

28


In this design, the client directly calls the methods on the printer object for printing something.

Now suppose the system has to be enhanced to allow another printer to be used by the client.

To implement this change, a new class Printer2 will have to be created and the code of the client class will have to be changed to allow using object of Printer2 type .

This design does not support the open-closed principle as the Client class is not closed against change.


In this design, instead of directly implementing the Printer1 class, we create an abstract class Printer that defines the interface of a printer and specifies all the methods a printer object should support.

Printer1 is implemented as a specialization of this class. In this design, when Printer2 is to be added, it is added as another subclass of type Printer.

The client only deals with a generic Printer. The class diagram for this is shown in the following

Figure


The basic idea is to have a class encapsulate the abstraction of some concept.

If this abstraction is to be extended, the extension is done by creating new subclasses of the abstraction, thereby keeping all the existing code unchanged.

Function oriented design

Here we discuss the structured design methodology for developing function-oriented system designs. The methodology employs the structure chart notation for creating the design.

For a function-oriented design, the design can be represented graphically by structure charts.

The structure of a program is made up of the modules of that program together with 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.

Structure chart

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, and 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). As an example, consider the structure of the following program, whose structure is shown in following Figure

main ()

{

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

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

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

}

readnums (a, N)

int a[], *N;

{

:

}

Example

sort (a, N)

int a[], N;

{

}

:

if (a[i] > a[t]) switch (a[i], a[t ]);

:

/* Add the first n numbers of a */

add_n (a, n)

int a[], n;

{

:

}

Structure chart

where module A has subordinates B, C, and D, and A repeatedly calls the modules C and D.

This can be represented by a looping arrow around the arrows joining the subordinates C and D to A, as shown in Figure

Structure chart

if the invocation of modules C and D in module A depends on the outcome of some decision, that is represented by a small diamond in the box for A, with the arrows joining C and D coming out of this diamond, as shown in Figure

38

Module --Categories

Modules that obtain information from their subordinates and then pass it to their superordinate. This kind of module is called input module.

Output Modules, which take information from their superordinate and pass it on to its subordinates.

There are modules that exist solely for the sake of transforming data into some other form. Such a module is called a transform module. (ex: computational modules )

39

Module --Categories

There are modules whose primary concern is managing the flow of data to and from di erent subordinates. Such ffmodules are called coordinate modules.

For a software system, once its structure is decided, the modules and their interfaces and dependencies get fixed.

Structured Design Methodology

The basic principle behind the 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.

The modules performing the transformation deal with data at an abstract level, and hence can focus on the conceptual problem of how to perform the transformation without bothering with how to obtain clean inputs or how to present the output


Inputs have to deal with issues of screens, reading data, formats, errors, exceptions, completeness of information, structure of the information, etc.

The modules dealing with output have to prepare the output in presentation formats, make charts, produce reports, etc.

Transformation in the system is 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.


This partitioning is at the heart of the structured design methodology. There are four major steps in the methodology:

1. Restate the problem as a data flow diagram.

2. Identify the input and output data elements.

3. First-level factoring.

4. Factoring of input, output, and transform branches.

1.Restate the Problem as a Data Flow Diagram

The first step is to construct the data flow diagram for the problem.

In the requirements analysis, a DFD is drawn to model the problem domain.

During design activity, we are dealing with the solution domain and developing a model for the eventual system.

That is, the DFD during design 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 di erent transforms. ff

Example--ATM

There are two major streams of input data in this diagram. The first is the account number and the code, and the second is the amount to be debited.

The transform debit account has two outputs, one used for recording the transaction and the other to update the account.

2. Identify the Most Abstract Input and Output Data Elements

The goal of this second step is to separate the transforms in the data flow diagram that convert the input or output to the desired format from the ones that perform the actual transformations.

For this separation, once the data flow diagram is ready, the next step is to identify the highest abstract level of input and output.


The most abstract input data elements are those data elements in the data flow diagram that are farthest removed from the physical inputs but can still be considered inputs to the system.

The most abstract input data elements 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 by starting From the outputs in the data flow diagram and traveling toward the inputs.

These are the data elements that are most removed from the actual outputs but can still be considered outgoing.

central transforms perform the basic transformation for the system, taking the most abstract input and transforming it into the most abstract output.


The purpose of having central transforms deal with the most abstract data items is that the 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.

In Figure 6.5. The two most abstract inputs are the dollar amount and the validated account number.

The validated account number is the most abstract input, rather than the account number read in, as it is still the input—but with a guarantee that the account number is valid. The two abstract outputs are obvious.

3. First-Level Factoring

Having identified the central transforms and the most abstract input and output data items, we are ready to identify some modules for the system.

We first specify a main module, whose purpose is to invoke the subordinates. The main module is therefore a coordinate module.

For each of the most abstract input data items, an immediate subordinate module to the main module is specified.


For each most abstract output data item, a subordinate module that is an output module that accepts data from the main module is specified.

ATM, this has two most abstract inputs, two most abstract outputs, and two central transforms.

Drawing a module for each of these, we get the structure chart shown in Figure 6.6.


The first-level factoring is straightforward, after the most abstract input and output data items are identified in the data flow diagram.

The main module is the overall control module, which will form the main program or procedure in the implementation of the design.

It is a coordinate module that invokes the input modules to get the most abstract data items, passes these to the appropriate transform modules, and delivers the results of the transform modules to other transform modules until the most abstract data items are obtained. These are then passed to the output modules.

4. 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 processing to do.

To simplify these modules, they must be factored into subordinate modules that will distribute the work of a module.

Each of the input, output, and transformation modules must be considered for factoring.


To factor an input module, the transform in the data flow diagram 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. The new input modules now created can then be

factored again, until the physical inputs are reached.


The factoring of the output modules is symmetrical to the factoring of the input modules.

An output module we look at the next transform to be applied to the output to bring it closer to the ultimate desired output.

The goal is to determine subtransforms that will together compose the overall transform and then repeat the process for the newly found transforms, until we reach the atomic modules.


Factoring the central transform is essentially an exercise in functional decomposition and will depend on the designers’ experience and judgment.

The central transform can be factored by creating a subordinate transform module for each of the transforms in this data flow diagram.

This process can be repeated for the new transform modules that are created, until we reach atomic modules.

Example:

Consider the problem of determining the number of di erent words in an input file..ff

First –level factoring

The structure chart after the first-level factoring of the word counting problem is shown in Figure 6.8.

Factoring the input module

Factoring the central transform

software design 1. software design is a creative process, just like designing anything else to see...

Documents