Software Design. Software design is a blueprint or a plan for a computerbased solution for system

Transcription

1 Software Design

2 Software Design Software design is a blueprint or a plan for a computerbased solution for system Software design deals with transforming the customer requirements, as described by the SRS into a form that is implementable using a programming language According to the IEEE definition [IEEE ], design is both "the process of defining the architecture, components, interfaces, and other characteristics of a system or component" and "the result of that process.

3 Software Design (Contd..) The design process for software systems often has two levels : Top-level Design Detailed Design

4 Four Components of a Design Procedural Design Interface Design Architectural Design Data Design The Design Model

5 Design Objectives/Properties Correctness Verifiability Completeness Traceability Efficiency Simplicity

6 Design Principles Partitioning Abstraction Modularity Top-down and Bottom-up approach

7 Partitioning Basic principle "divide and conquer" Divide the problem into manageably small pieces Ideally,each piece can be solved separately Ideally, each piece can be modified separately Pieces cannot be independent; they must communicate Communication adds complexity As number of components increases, this cost increases Stop partitioning when cost is more than benefit Results in hierarchies in the design

8 Abstraction Abstraction is a view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information An abstraction of a component describes the external behaviour of the system without bothering with the internal details that produce the behaviour To allow the designer to concentrate on one component at a time, abstraction of other component is used

9 Abstraction (Contd..) Functional Abstraction Data abstraction

10 Top- Down and Bottom up strategies A top-down approach starts by identifying the major component of the system, decompose them into lower level components and iterating until the desired level of detail is achieved. Stepwise refinement

11 Top- Down and Bottom up strategies (contd ) A bottom-up approach starts with designing most basic or primitive components and proceeds to higher level components that uses these lower-level components Work with layers of abstraction

12 Modularity Modularity refers to the degree to which software can be understood by examining its components independent of one another A system is considered modular if it consist of discrete components so that each component can be implemented separately and a change to one component has minimal impact on other components

13 Functional Independence A module having high cohesion and low coupling is said to be functionally independent of other module Error Isolation Scope of reuse Understandability

14 Cohesion The measure of strength of the association of elements within a module is known as cohesion Degree of interaction within a module

15 Types of Cohesion Functional Cohesion Sequential Cohesion Communicational Cohesion Procedural Cohesion Temporal Cohesion Logical Cohesion Coincidental Cohesion

16 Functional Cohesion A module exhibits ``functional cohesion'' if it supports activities needed for the execution for one and only one problemrelated task. Example Compute cosine of angle Calculate net employee salary Sort the array

17 Sequential Cohesion A sequentially cohesive module is one whose elements are involved in activities such that output data from one activity serves as input data to the next. Example

18 Communicational Cohesion Communicational cohesion occurs when the elements of a module are grouped together because they operate on same input or output data Example

19 Procedural Cohesion Procedural cohesion occurs when the elements of a module are related because they operate according to a particular procedure Elements are related only by sequence, otherwise the activities are unrelated Example

20 Temporal Cohesion A temporarily cohesive module is one whose elements are functions that are related in time. Example module initialise set counter to 0 open student file clear error message variable initialise array

21 Logical Cohesion A logically cohesive module is one whose elements performs activities of the same general category. For example, a report module, display module or I/O module

22 Coincidental Cohesion Coincidental cohesion occurs when elements contribute to activities that have no meaningful relationship to one another. Module performs multiple, completely unrelated actions. Example print next line, reverse string of characters comprising second parameter, add 7 to fifth parameter, convert fourth parameter to floating point

23 Classification of Cohesion

24 Determining Module Cohesion Functional Yes Doing one function only? Coincidental Sequential Yes No No Sequence important? Data Module related by? None Activities same category? Yes Communicational Procedural No Sequence important? Yes Control Flow No Logical Temporal

25 Coupling The degree of interdependence between two modules. Highly coupled modules great deal of dependence between components Loosely coupled modules some dependence but interconnections are weak Uncoupled modules no interconnections at all

26 Goal is to Minimize Coupling Enable us to change the portion of the system while disrupting the rest of the system as little as possible

27 Types of Coupling Data Coupling Stamp Coupling Control Coupling Common Coupling Content Coupling

28 Data Coupling Modules communicate by passing simple data parameters Process Results Each parameter is an elementary piece of data mark grade Calculate Grade

29 Stamp Coupling A composite data is passed between modules Not all of the individual components of the data may not be used record Process Results updated record Update Grade

30 Control Coupling One module passes an element of control to another. Check record One module directs the order of instruction execution of another module by passing necessary control information Error code Display error

31 Common Coupling When two modules refer to the same global data area Process Results Global data updated record Update Grade

32 Content Coupling Two modules are content coupled if one directly references the contents of another. One module branches into another module. One module references or alters data contained inside another module Module A modifies the statement of module B.

33 Range of Coupling Content High Coupling Common Control Stamp Loose Data Uncoupled Low

34 General Design Approaches Function Oriented Design Structured Design by Constantine and Yourdon Jackon s structured design Warnier-Orr Methodology Step-wise refinement by Writh Object Oriented Design

35 Structured Design Structured Design is a process-oriented technique to divide a system into a hierarchy of modules leading to programs that are easy to develop and maintain The basic approach in system design is systematic conversation o data flow diagrams into structure chart

36 Structure Chart Notation

37 Structure Chart Notation (contd )

38 Example Modules on level 2 can be decomposed further

39 Repetition

40 Structure Chart - Module Rectangle represents a module (program or subroutine) Control Modules (mainline) branch to sub-modules Library modules are reusable and can be invoked from more than one Control Module elsewhere in the system

41 Selection

42 Physical Physical to to Logical Logical DFDs DFDs AZ104 form AZ104 form Bill checks Bill form checks form checked AZ104 form checked AZ104 form Master File Master File sales order sales order Validate Validate sales order sales order valid sales order valid sales order Sales orders Sales orders

43 Physical DFD

44 Logica l DFD

45 Structured Analysis Study existing system: What is done and how Prepare physical current DFD Convert this DFD to logical DFD Remove physical implementation-specific details Prepare DFD for proposed system - requires innovation, experience, vision Incorporate new needs Improve work flows (BPR: business process re-engg) Introduce efficiency/effectiveness Define boundary for automation (scope)

46 Automation Boundary on a System-Level DFD

47 SSA/SD process 1. Construct an initial DFD for each major component to provide a top level description of the problem. context diagram) 2. Review and refine DFDs for the major components until a sufficient degree of cohesion is achieved for processes; one elaborates the context diagram into a layered hierarchy of DFDs, supported by a data dictionary. 3. Determine whether each DFD has a transformational or transactional flow characteristics. The remaining steps depend on the outcome of step 3

48 Transformational Flow Data continuously moves through a collection of incoming flow processes transform center processes and finally outgoing flow processes

49 Transform Analysis (contd..) Input portion in the DFD: processes which convert input data from physical to logical form. Each input portion is called an afferent branch. Possible to have more than one afferent branch in a DFD. Output portion of a DFD: transforms output data from logical form to physical form. Each output portion is called an efferent branch. The remaining portions of a DFD called central transform

50 Transform Analysis 4.Isolate the transform center by specifying incoming and outgoing flow boundaries. Determine most abstract data input and most abstract data output (Identify the transform center by specifying Most Abstract Input and Output Data Elements)

51 Transform Analysis (contd..) Divide the DFD into 3 types of parts: Afferent stream, Central transform, Efferent stream

52 Transform Analysis 5. Perform first level factoring

53 First- Cut Structure Chart for word count Problem

54 Transform Analysis (contd..) 6. Perform second level factoring

55 Transform Analysis (contd..) 7.Refine the first iteration program structure using design heuristics for improved software quality

56 Design heuristics for effective modularity Reduce coupling and increase cohesion Explode complicated modules into multiple modules Implode related modules Minimize structures with high fan-out Strive for fan-in as depth increased Keep scope of effect within in the scope of control Tune module interfaces to reduce complexity

57 Transform Mapping

58 Level 3 DFD for Monitor Sensors with flow boundaries

59 First level factoring for monitor sensors

60 Second Level Factoring

61 First-Iteration program structure for monitor sensors

62 Refined program structure for monitor sensors

63 Transactional Flow Data continuously moves through a collection of incoming flow processes reaches a particular transaction centre processes and then follows one of a number of actions paths. Each actions path is again a collection of processes

64 Example of Transaction Flow user commands action paths read user command command type invoke command processing

65 Railway reservation transaction stimuli

66 Transaction Flow Transaction: Information flow is often characterized by a single data item, that triggers other data flow along one of many paths Action Paths :The transaction is evaluated and based on its value flow along one of many action paths ; implements different types of functionalities Transaction center :The hub of info flow from which many action paths originate, evaluates transaction and initialize the correct action path Transact ion Transaction center T Action paths

67 Transaction Analysis 4.Identify the transaction center and the flow characteristics along each of the action paths. isolate incoming path and all action paths each action path evaluated for its flow characteristic.

68 5. Perform first level factoring for a transactional flow; map the DFD to a program structure amenable to transaction processing

69 5.Factor and refine the transaction structure and the structure of each action path. 6. Refine the first iteration program structure using design heuristics for improved software quality.

70 Transaction Mapping

71 Level 2 DFD for user transaction subsystem with flow boundaries

72 First level factoring for user interaction subsystem

73 Transaction mapping (contd..) Factor and refine the transaction structure and the structure of each action path Refine the first iteration program structure using design heuristics for improved software quality

74 First-iteration architecture for user interaction subsystem

75

76 Stock New Stock Level Warehouse Stock Levels Delivery Notes Item No 1 Validate Orders Valid Orders 2 Check Stock Available Orders 3 Write Del.Notes Orders Partially Available Orders Available Part Orders Customer 3 Split Order Non-available Part Orders Back Orders

77 New Stock Level Stock Levels Delivery Notes Item No 1 Validate Orders Valid Orders 2 Check Stock Available Orders 3 Write Del.Notes Orders Partially Available Orders 3 Split Order Available Part Orders Non-available Part Orders

78 2 Check Stock Available Orders Valid Orders Stock Levels 1 Validate Orders New Stock Level Partially Available Orders Delivery Notes 3 Write Del.Notes Orders Item No 3 Split Order Available Part Orders Non-available Part Orders

79 5 Process Orders Partially Available Orders 2 Check Stock Partially Available Orders 3 Split Order Non-available Part Orders Valid Orders Available Orders Available Part Orders New Stock Level 1 Validate Orders Stock Levels 3 Write Del.Notes Delivery Notes Item No Orders

80 2 Check Stock 5 Process Orders Partially Available Orders Partially Available Orders 3 Split Order Non-available Part Orders Orders Available Orders Available Part Orders Item No 1 Validat e Orders Stock Levels Orders New Stock Level 3 Write Del.Note s Delivery Notes

81 Check Stock Valid Orders Orders Stock Levels Available Orders New Stock Level Partially Available Orders Validate Orders Orders Item No Split Order End of Orders Available Part Orders Non-available Part Orders Write Delivery Notes Delivery Notes

82 Check Stock Valid Orders Orders Stock Levels Available Orders New Stock Level Partially Available Orders Validate Orders Split Order Orders End of Orders Item No Non-available Part Orders Available Part Orders Read Orders Read Stock Write Stock Write Back Stock Write Delivery Notes

83 Verification Review Review process involves a group of people get together to discuss the design with the aim of revealing design errors or undesirable properties Errors include omissions, misinterpretation of requirements, weak modularity etc.

84 Detailed Design A processing narrative must be developed for each module. Using process design language An interface description is provided for each module. Local and global data structures are refined or designed. A design review is conducted. Optimization is considered (if required and justified).

85 Process Design Language Mimax(file) Array a Do Until end of input Read an item into a Enddo max,min:=first item of a DO FOR each item in a IF max<item THEN set max to item IF min >item THEN set min to item ENDDO END