Software Design Design is the process of applying various techniques and principles for the purpose of defining a device, a process,, or a system in sufficient detail to permit its physical realization (from your book).

Software Design Design is a blueprint: something intended as a guide for making something else; "a blueprint for a house"; "a pattern for a skirt" www.cogsci.princeton.edu/cgi-bin/webwn

Software Design Software design is the part of the software development process whose primary purpose is to decide how the system will be implemented. During design, strategic and tactical decisions are made to meet the required functional and quality requirements of a system. www.processwave.net/Glossary/glossary.htm

Software Design The design process: Converts the “what” of requirements to the “how” of design. Converts the terminology from the problem space of requirements to the solution space of implementation.

Software Design Few rules can be written to guide design. The design process is the most “creative” portion of the software development process. Few rules can be written to guide design.

Software Design 1. Data design – designing the data structures. The design process can be broken into four phases: 1. Data design – designing the data structures. 2. Architectural design – produces the structural units (classes). 3. Interface design – specifies the interface between structural units. 4. Procedural design – specifies the algorithms for each method.

Interface Specifications An interface specification is a specification of the external behavior of a module. The specification should explain what the calling module can expect under any circumstance. The implementor should know exactly what information needs to be specified in order to use the module.

Interface Specifications Each class should have an interface specification that includes an explanation of the effects of: Any public data member or method

Interface Specifications Each method should have an interface specification that includes an explanation of the effects of: 1. All input and output parameters. 2. Any return values. 3. How a call to the method changes the state of its corresponding object

Design Methods Refinement – otherwise known as “top down design”. Refinement involves starting with a general solution and then breaking the solution into more specific steps.

Example of Refinement

Attributes of Design (Abstraction) Abstraction is the removal of unnecessary details. Abstraction allows the designer to focus on essential issues without worrying about low-level details

Attributes of Design (Coupling) Coupling is a measure of how interconnected modules are. Two modules are highly coupled if a change in a variable in one module requires many changes in the other module. Low coupling is generally desired.

Attributes of Design (Cohesion) cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. Cohesion is is usually expressed as "high cohesion" or "low cohesion”. Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability

Attributes of Design (Cohesion) Low cohesion is associated with undesirable traits such as being difficult to maintain, difficult to test, difficult to reuse, and even difficult to understand. A class is highly cohesive if every method in the class uses all the attributes of the class. A method is highly cohesive if all the statements in the method are related to the outputs.

Measuring Cohesion Some preliminary definitions: Data Definition: An executable statement where a variable is assigned a value.   Data Use: An executable statement where the value of a variable is accessed. Data Definition-use Pair: A data definition and data use, where the data use uses the value defined in the data definition.

Measuring Cohesion There are two basic dependencies that determine cohesion: Data dependencies are where the value of x affects the value of y through data definitions-use pairs.

Example of Data Dependency z = 0 while x > 0 do z = z + y x = x – 1 end while The output variable z has a data dependency on the variable y, since y is added to z and assigned back to z.

Control Dependencies A control dependency exists between a variable y and a variable x when the variable x determines whether or not code containing the definitions of y executes.

Example of Control Dependency z = 0 while x > 0 do z = z + y x = x – 1 end while The output variable z has a control dependency on the variable x, since x controls how many times y is added to z.

Program Slices Program slicing is a technique for simplifying programs by focusing on selected aspects of semantics. The process of slicing deletes those parts of the program which can be determined to have no effect upon the semantics of interest.

Program Slicing to Determine Cohesion An output slice finds every statement that affects the specified output. An input slice finds every statement that is affected by the specified input.

Program Slicing to Determine Cohesion z = 0 while x > 0 do z = z + y x = x – 1 end while This graph above shows the dependencies of the code above (filled = data dotted = control)

Program Slicing to Determine Cohesion An input slice could start with the input variable X. The statements “While X>0” and “X=X+1” are added to the slice. Since there is a control dependency between While X>0 and Z=Z+Y, “Z=Z+Y” is added.

Program Slicing to Determine Cohesion Since there is a data dependency between While X>0 and X=X-1, “X=X-1” is added.

Program Slicing to Determine Cohesion The output slice for Z includes “Z=Z+Y”, Z=0 and “While X>0”. James Bieman and Linda Ott looked at tokens in program slices as a measure of cohesion

Program Slicing to Determine Cohesion Tokens include constant references, variable definitions and variable references. For example, the statement Z=Z+Y has tokens Z, Z, Y. Bieman and Ott defined cohesion metrics using output slices An output slice finds every statement that affects the specified output.

A Cohesion Measure Using Output Slices A glue token is a token that is more than one slice. A superglue token is a token that is in all slices. The adhesiveness of a token is the percentage of all output slices that contain that token.

A Cohesion Measure Using Output Slices Weak functional cohesion is the ratio of glue tokens to total tokens. Strong functional cohesion is the ratio of superglue tokens to total tokens. Adhesiveness (of the module) is the average adhesiveness of all tokens in the module.

Example of Cohesiveness Measure cin >> a >> b int x, y, z x=0; y=1; z=1; if (a>b) { x=a*b; while (10>a) { y=y+z; a=a+5; } else x=x+b; All tokens and their immediate affects

Example of Cohesiveness Measure The diagram to the right shows each token along with the slice to which each token belongs. Try calculating the weak functional cohesion, strong functional cohesion, and overall adhesiveness. An output slice finds every statement that affects the specified output.

Measuring Coupling Many different coupling metrics have been proposed. Coupling is how closely two or more modules are tied. Many different coupling metrics have been proposed.

Measuring Coupling di = number of input data parameters Dharma’s module coupling. di = number of input data parameters dc = number of input control parameters do = number of output data parameters co = number of output control parameters gd = number of global variables used as data gc = number of global variables used as control w = number of modules called (fan-out) r = number of modules calling (fan-in) mc = K / (di + 2*ci + do + 2*co + gd + 2*gc + w +r)

Requirements Traceability Requirement traceability links each requirement with a design element that satisfies the requirement.

Requirements Traceability Requ/method Class1.m1 Class1.m2 Class2.m1 R1 X R2 R3 R4 One way to do this is with a matrix showing requirements across the rows and which method(s) satisfied the requirements across the columns.