Design

1. Design

2. Software Design • Design activity begins with a set of requirements, and maybe an architecture • Design done before the system is implemented • Design focuses on module view – i.e. what modules should be in the system • Module view may have easy or complex relationship with the C&C view • Design of a system is a blue print for implementation • Often has two levels – high level (modules are defined), and detailed design (logic specified)

3. Software Design • Often has two levels • high level: • define needed modules. • specifications of modules. • how the modules should be interconnected. • detailed design: (logic specified): • internal design of the modules. • how the specifications of module can be satisfied.

4. Design… • Design is a creative activity • Goal: to create a plan to satisfy requirements • Perhaps the most critical activity during system development • Design determines the major characteristics of a system • Has great impact on testing and maintenance • Design document forms reference for later phases • Design methodology – systematic approach for creating a design(applying a set of techniques and guidelines).

5. Design Concepts • Design is correct, if it will satisfy all the requirements and is consistent with architecture. • Of the correct designs, we want best design. • Design evaluation criteria: • We focus on modularity as the main criteria (besides correctness) • Modular system: 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.

6. Modularity • desirable property. • Modularity supports independence of modules • Modularity enhances design clarity, eases implementation • Reduces cost of testing, debugging and maintenance • isolating the system problem to a module is easier if the system is modular; • in system repair—changing a part of the system is easy as it affects few other parts; • in system building—a modular system can be easily built by “putting its modules together.”

7. Modularity • Cannot simply chop a program into modules to get modularly • module needs to support a well-defined abstraction and have a clear interface through which it can interact with other modules. • Need some criteria for decomposition – coupling and cohesion are such criteria

8. Coupling • Independent modules: if one can function completely without the presence of other • Independence between modules is desirable • Modules can be modified separately • Can be implemented and tested separately • Programming cost decreases • In a system all modules cannot be independent • Modules must cooperate with each other • More connections between modules • More dependent they are • More knowledge about one module is required to understand the other module. • Coupling captures the notion of dependence • how strongly” different modules are interconnected.

10. Coupling… • Coupling between modules is the strength of interconnections between modules • In general, the more we must know about module A in order to understand module B the more closely connected is A to B • "Highly coupled" modules are joined by strong interconnection • "Loosely coupled" modules have weak interconnections • To solve and modify a module separately, we would like the module to be loosely coupled with other modules.

11. Coupling… • Goal: modules as loosely coupled as possible • Where possible, have independent modules • Coupling is decided during high level design • Cannot be reduced during implementation • Coupling is inter-module concept • Major factors influencing coupling • number of interfaces (Type of connection between modules) • Complexity of the interface • Type of information flow between modules • An interface of a module is used to pass information to and from other modules.

12. Coupling: Type of connection • Complexity and obscurity of interfaces increase coupling. • Minimize the number of interfaces per module. • Minimize the complexity of each interface. • Coupling is minimized if: • Only defined entry of a module is used by others. • Information is passed exclusively through parameters • Coupling increases if • Indirect and obscure interface are used • Internals of a module are directly used • Shared variables employed for communication

13. CouplingShared variable example

14. Coupling: interface complexity • Coupling increases with complexity of each interface, eg. number and complexity of parameters. • Interfaces are needed to support required communication. • Often more than needed is used, eg. passing entire record when only a field is needed. • passing all the record increasing the coupling unnecessarily • Keep the interface of a module as simple as possible

15. Coupling:Type of Info flow • Coupling depends on type of information flow • Two kinds of information: data or control. • Transfer of control information • Action of module depends on this control information. • Makes modules more difficult to understand • Transfer of data information • Module can be treated as input-output function • Lowest coupling: interfaces with only data communication • Highest: hybrid interfaces

16. Type of Info flow :Control coupling • Occurs when one procedure calls another using a ‘flag’ or ‘command’ that explicitly controls what the second procedure does • To make a change you have to change both the calling and called method

17. Control coupling- Example

18. Type of Info flow :Data coupling • Occurs whenever the types of method arguments are either primitive • The more arguments a method has, the higher the coupling • All methods that use the method must pass all the arguments • You should reduce coupling by not giving methods unnecessary arguments

19. Data coupling-Example

20. hybrid coupling

21. Coupling - Summary Coupling Interface Type of Type of complexity connections communication Low Simple to module data obvious by name Control High complicated to internal Hybrid obscure elements Increase

22. Cohesion • Coupling characterized the inter-module bond. • Reduced by minimizing relationship between elements of different modules. • Another method of achieving this is by maximizing relationship between elements of same module. • Cohesion considers this relationship • Interested in determining how closely the elements of a module are related to each other

23. Cohesion… • Cohesion of a module represents how tightly bound are the elements of the module • Gives a handle about whether the different elements of a module belong together • High cohesion is the goal • Cohesion and coupling are interrelated • Greater cohesion of modules, lower coupling between module • Correlation is not perfect, In practice has been observed.

24. Levels of Cohesion • There are many levels of cohesion. • Coincidental • Logical • Temporal • Communicational • Sequential • Functional • Coincidental is lowest, functional is highest • Scale is not linear • Functional is considered very strong

25. Coincidental cohesion • occurs when there is no meaningful relationship among the elements of a module. • Coincidental cohesion can occur if an existing program is “modularized” by chopping it into pieces and making different pieces modules. • If a module is created to save duplicate code by combining some part of code that occurs at many different places.

26. logical cohesion • if there is some logical relationship between the elements of a module, and the elements perform functions that fall in the same logical class. • Example: module that performs all the inputs or all the outputs. if we want to input or output a particular record. • In general, logically cohesive modules should be avoided, if possible.

27. Temporal cohesion • the same as logical cohesion, except, the elements are also related in time and are executed together. • Modules that perform activities like “initialization,” “cleanup,” and “termination” . • temporal cohesion is higher than logical cohesion, because the elements are all executed together.

28. procedurally cohesive • contains elements that belong to a common procedural unit. • Example, a loop or a sequence of decision statements in a module may be combined to form a separate module. • often occur when modular structure is determined from some form of flowchart.

29. communicational cohesion • has elements that are related by a reference to the same input or output data. • Communicationally cohesive modules may perform more than one function.

30. sequential cohesion • When the elements are together in a module because the output of one forms the input to another. • If we have a sequence of elements in which the output of one forms the input to another, sequential cohesion does not provide any guidelines on how to combine them into modules.

31. Functional cohesion • is the strongest cohesion. • all the elements of the module are related to performing a single function. • modules accomplishing a single goal are also included. • Functions like “compute square root” and “sort the array” are clear examples of functionally cohesive modules.

32. Determining Cohesion • Describe the purpose of a module in a sentence • Perform the following tests: 1. If the sentence has to be a compound sentence, contains more than one verbs, the module is probably performing more than one function. Probably has sequential or communicational cohesion. 2. If the sentence contains words relating to time, like "first", "next", "after", "start" etc., the module probably has sequential or temporal cohesion.

33. Determining Cohesion 3. If the predicate of the sentence does not contain a single specific object following the verb, the module is probably logically cohesive. Eg "edit all data", while "edit source data" may have functional cohesion. 4. Words like "initialize", "clean-up" often imply temporal cohesion. • Functionally cohesive module can always be described by a simple statement

34. Open-closed Principle • Besides cohesion and coupling, open closed principle also helps in achieving modularity • Principle: A module should be open for extension but closed for modification • Behavior can be extended to accommodate new requirements, but existing code is not modified • I.e. allows addition of code, but not modification of existing code • Minimizes risk of having existing functionality stop working due to changes – a very important consideration while changing code • Good for programmers as they like writing new code

35. Summary • Goal of designing is to find the best possible correct design • Modularity is the criteria for deciding quality of the design • Modularity enhanced by low coupling, high cohesion, and following open-closed principle

36. Function Oriented Design and Structured Design Methodology

37. Function-Oriented Design • Creating the software system design is the major concern of the design phase. • The aim of design methodologies is to provide guidelines to aid the designer during the design process. • We will discuss the structured design methodology. • The methodology employs the structure chart notation for creating the design.

38. Program Structureand Structure Charts • Every program has a structure. • Structure Chart - graphic representation of structure • SC represents modules and interconnections. • Each module is represented by a box with the module name written in the box. • If A invokes B, an arrow is drawn from A to B: • B is called the subordinate of A, and A is called the super-ordinate of B. • Arrows are labeled by data items: • 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.

39. Program Structureand Structure Charts • parameters can be shown to be data (unfilled circle at the tail of the label) or control (filled circle at the tail). • Different types of modules in a SC. • Input, output, transform and coordinate modules. • A module may be a composite.

40. Structure charts… • Different from flow charts. • Major decisions and loops can be shown • Structure is decided during design • Implementation does not change structure • Structure effects maintainability. • SDM aims to control the structure

41. Types of modules • Input module: modules that 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 module: modules that exist only for transforming data into some other form.(Most of the computational modules typically fall in this category). • Coordinate modules: modules whose primary concern is managing the flow of data to and from different subordinates. • module can perform functions of more than one type of module.

42. Example

43. SC of a Sort Program

44. Structure charts… • procedural information is not represented in a structure chart. • Focus is on representing the hierarchy of modules. • There are situations where major loops and decisions must be represented.

45. Iteration representation • consider module A has subordinates B, C, and D • 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, • All subordinate modules activated within a common loop are enclosed in the same looping arrow.

46. Decision representation • Major decisions can be represented similarly. • 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.

47. STRUCTURED DESIGN METHODOLOGY • SDM views software as a transformation function that converts given inputs to desired outputs • The focus of SD is the transformation function • Uses functional abstraction • Goal of SDM: Specify functional modules and connections • Low coupling and high cohesion is the objective Transformation functions Output Input

48. Steps in SD • Draw a DFD of the system • Identify most abstract inputs and most abstract outputs. • First level factoring. • Factoring of input, output, transform modules. • Improving the structure.

49. Step1:Data Flow Diagram • a fundamental difference between the DFDs drawn during requirements analysis and those drawn during structured design: • In requirements analysis, a DFD is drawn to model the problem domain. • During design , DFD dealing with the solution domain and developing a model for the eventual system. • SD starts with a DFD to capture flow of data in the proposed system • DFD is an important representation; provides a high level view of the system • Show the flow of data through the system • Ignores procedural aspects.

50. Drawing a DFG • Start with identifying the inputs and outputs • Work your way from inputs to outputs, or vice versa • If stuck, reverse direction • Ask: "What transformations will convert the inputs to outputs" • Never try to show control logic. • If thinking about loops, if-then-else, start again • Label each arrow carefully • Make use of * and +, and show sufficient detail • Ignore minor functions in the start • For complex systems, make dfg hierarchical • Never settle for the 1st dfg