Software Engineering Chapter 6 Software Design Eng Sultan

Software Engineering Chapter 6: Software Design Eng. Sultan M. Al-Rushdan 1

Introduction • Design activity begins when requirement document is available. • Design is the first step moving from problem domain to solution domain. • Design of a system is a blue print or plan for a solution. • The goal of design is to produce a model or representation of a system which can be used later to build that system. 2

Introduction • Design have two levels – System design or Top-level design, which focus on deciding which modules are needed for the system. – Detailed design or Logic design, focus on the internal design of the model or how the specification of the modules can be satisfied. 3

What is Software Design Software design is the process of inventing and selecting program that meet the objectives for a software system. Input include understanding the followings: 1. Requirements. 2. Environmental Constraints. 3. Design Criteria. The output of design are: 1. Architectural design which shows how pieces are interrelated. 2. Specifications for any new pieces. 3. Definition for any new data 4

Why Design is Important? A good design is the key to a successful product. The meaning of ‘Good design’ is very depending on application. Researchers agree on desirable characteristics that every good design should have: • Correctness: correct implementation of system functionality. • Understandability: should be easily understandable. • Efficiency: it should be efficient. • Maintainability: it should be easily maintained. 5

Why Design is Important? Without design we risk building an unstable system that: • Will fail when small change are made. • Will be difficult to maintain. • Quality cannot be assessed until late in software process. 6

Why Design is Important? Good Design Vs. Bad Design. Good Design Characteristics Bad Design Change in one part of the system does not always require change in other parts Change in one part require change in many other parts Logic Every piece of logic has one and only one home Logic has to be duplicated Cost small High Nature simple complex Extension System can be extended System cannot be with change in one extended aesily. place 7

Objectives of Design • Software design objective is to transform customer requirements in SRS to a form that is implementable using programming language. • Design fills the gap between specifications and coding. 8

Design Framework 9

Analysis and Design Model After analyzing the requirements the process of design begins. Elements of analysis model are used to create a design model those elements are: 1. Data Dictionary. 2. Entity Relationship Diagram. 3. Data Flow Diagram. 4. State Transition Diagram. 5. Control Specification. 6. Process Specification. 10

Analysis and Design Model The elements of design model are 1. Data Design. 2. Architectural Design. 3. Interface Design. 4. Component level Design. 11

Analysis and Design Model 12

Analysis and Design Model Data Design: transform information domain model data structures. Architectural Design: defines the relationships between major structural elements of software. Interface Design: describe how the software communicate within itself, with systems that interoperate with and with users. Component level Design: transform the structural elements of software architecture in to procedural description of software components. 13

Software Design Model • Static Models: represent aspects of software that do not change during execution. Usually software components, their characteristics and relationships between them(e. g object and class diagram, use case diagram etc. ) • Dynamic Models: show what happens during software execution (e. g. data flow diagram, state-charts, decision trees etc. ) 14

Design Process Design process is a sequence of steps carried through which the requirement translated into a system or software model. Design Process can be decomposed into the following three levels: 1. Interface design. 2. Architectural design. 3. Detailed design. 15

Design Process 16

Interface Design Interface design is the specification of interaction between the system and its environment. It usually include: 1. Precise description of events in the environment or messages to which system should respond. 2. Precise description of events or messages that system must produce. 3. Specification of data and its format that are coming into and going out of the system. 4. Specification of the ordering and timing relationships between incoming events or messages and outgoing events or outputs. 17

Architectural Design • Is the specification of the major components of the system and their responsibilities, properties, interfaces and relationship and interaction between them. • The overall structure of the system is chosen but the internal details of major components are ignored. 18

Architectural Design Architectural design should include: 1. Gross decomposition of the system into major components. 2. Allocation of functional responsibilities to components. 3. Component interfaces. 4. Component scaling and performance properties, resource consumption properties, reliability properties etc. 5. Communication and interaction between components. 19

Detailed Design Is the specifications of internal elements of all major system components, their structures, properties, relationships, processing and often their algorithms. It includes: 1. Decomposition of major system components into program units. 2. Allocation of functional responsibilities to units. 3. Unit interface. 4. Data and control interaction between units. 5. Unit state and state changes. 6. Unit packaging and implementations. 7. Algorithms and data structures. 20

Properties of Good Software Design The desirable properties of software design are: 1. Correctness: the design is correct if it is build precisely according to requirements of the system. 2. Verifiability: how easily the correctness of the design can be checked. 3. Completeness: all different components of design should be verified including all data structures, modules, external interfaces, etc. 4. Traceability: all design elements must be traceable to the requirements. 5. Efficiency: proper use of scare resources (e. g memory, processors) 6. Simplicity: maintenance of computer system is expensive and simple system can reduce the maintenance costs. 21

Design Principles The three design principles are: 1. Problem Partitioning. 2. Abstraction. 3. Top-down and Bottom-up design. 22

Design Principles 1. Problem Partitioning: divide the problem into manageable small pieces that can be solved separately. Problem partitioning can be divided into two categories: a. Horizontal partitioning. b. Vertical partitioning. 23

Design Principles a. Horizontal partitioning: defines separated branches of modular hierarchy for each major function, the simplest is (data input , data transformation or processing, output), benefits are: • Software that is easier to test • Software that is easier to maintain • Software that is easier to extend • Propagation of fewer side effects The disadvantage that horizontal partitioning cause more data to be passed across modules interfae and can complicate the overall control of program flow. 24

Design Principles b. Vertical partitioning: called factoring suggest that control and work should be distributed from top down in the program structure, top level modules should perform control and lower level modules do the actual processing work. 25

Design Principles 26

Design Principles 27

Design Principles 2. Abstraction: describes the behavior of component without bothering with the internal details. During design the designer specifies only abstract specifications the on detailed design the designer can concentrate on what component should do. Two common abstraction mechanisms: 1. Functional Abstraction. 2. Data Abstraction. 28

Design Principles 1. Functional Abstraction: module is specified by the function it performs, it is used in functional oriented approach where the problem is being partitioned the overall function is partitioned to smaller functions. 2. Data Abstraction: data object are expected to perform certain operations depending on the object and the environment, and these operations are the only operation that data object can do. Form outside data object data are hidden only operations are visible. 29

Design Principles 3. Top-down and Bottom-up Design: a system consists of components which have components of it own and so on. To define this hierarchy two approaches: 1. Top–down approach. 2. Bottom-up approach. 30

Design Principles 1. Top–down approach: start by identify major components then decompose them into lower level components until the desired level of detailed achieved, it start from abstract design then move to a more concrete level in each step until reach a design that can be implemented. 2. Bottom-up approach: begins with concrete machine and successively develops one abstract machine after the other by adding needed attributed at each level 31

Design Principles • Top–down approach is suitable only if the specifications of the system are clearly known and the system development is from scratch • Bottom-up approach is suitable when if the developers start from existing components, or if iterative life cycle model is used to develop a system. 32

Architectural Design The initial design process which includes identifying subsystems and establish a framework for subsystem control and communications. Architectural design represents the structure of data and program components that are required to build a computer based system and their relationships and communications between system components. 33

Architectural Design There are various alternatives of architectural styles which are: • Data centric architecture: approach involves the use of central database operations such as insertion, deletion and update. • Data flow architecture: is center around the pipe and filter mechanism, where input data are subject to series of transformations to become outputs. • Object oriented architecture: the design uses classes and objects to encapsulate data and operations associated with these data. • Layered architecture: define a number of layers and each layer perform some tasks, the outer most layer handle user interface and the inner most layer handle the interaction with hardware. 34

Objectives of Architectural Design • Develop a model of software which gives an overall organization of program module in the software product. • Define the organization of program components but it does not provide the details of each components and implementations. • Control the relationships between modules, one module may control one or more modules or one modules can be controlled by one or more modules. 35

Low-Level Design Modularization A system is considered modular if it consists of discrete components so that each component can be implemented separately and changing one component have minimal impact on other components. At the highest level of abstraction, the entire system is a module whose immediate parts are the subsystems of which it is composed. 36

Low-Level Design Modularization Desirable properties of modular system includes: • Each function in each abstraction has a single, well-defined purpose. • Each function manipulates no more than one major data structure. • Functions share global data selectively, it is easy to identify all function that share a major data structure. • Functions that manipulate instances of abstract data type are encapsulated with the data structure being manipulated. 37

Low-Level Design Modularization Advantages of Modular Systems: • Modular system are easier to understand explain. • Modular systems are easier to document. • Modular systems are easier to program. • Testing and debugging of modular system is easier. • Bugs are easier to isolate and understand. • Well composed modules are more reusable. 38

Low-Level Design Modularity separation principle Can be applied in two phases: 1. Dealing with the details of each in isolation( ignoring the details of other modules) 2. Dealing with overall characteristics of all modules and their relationships. If the two phases were executed in order (1 then 2) then the system is designed buttonup if they executed in converse (2 then 1) then the system is designed top-down. 39

Low-Level Design Modularity Modules created during modularization phase are: • Process Support Modules: in it all the functions and data items that are required to support a particular business process are grouped together. • Data Abstraction: these are abstract types that are created by associating data with processing components. • Functional Modules: in it all the function that carried out similar or closely related task is grouped together. • Hardware Modules: it it all the functions, which controls on a particular hardware grouped together. 40

Low-Level Design Modularity A model can be classified into three types depending on activation mechanism. • An Incremental Module: is activated by an interruption and can be interrupted by another interrupt during the execution. • A Sequential Module: a model that is referenced by another model and without interruption of any external software. • A Parallel Module: is executed in parallel with another module. 41

Low-Level Design Modularity If the software system was subdivided indefinitely the effort required to develop it become negligibly small. But however in such case the effort or cost of integration become greater. 42

Design Structure Chart is a principle tool of structure design. The aim is transfer the results of structure analysis to structure chart. Structure chart represent the software architecture(the modules making up the system, module dependency and parameter passed). 43

Design Structure Chart The basic element of structure chart is module which is defined as a collection of program statements with four attributes: 1. Inputs and Outputs. 2. Function(transfer inputs to outputs) 3. Mechanics(the code or logic by which the function is carried out). 4. Internal Data. 44

Design Structure Chart • Module are represented as rectangle box. • The module at top level calls the module at lower level. • The connection between modules represented by arrows which represent the control flow during execution. • Arrows represent the direction of data movement. • The hierarchy is red from top to bottom and form left to write. • There is only one module at the top level called root. • Modules uses data and flag. 45

Design Structure Chart Basic building blocks of Structure Chart. 1. Rectangle Box: which represent a modules which contain a name. 2. Arrows: indicate that during execution control is passes from one module to another 46

Design Structure Chart Basic building blocks of Structure Chart. 3. Data flow Arrows: represent the named data passed from one module to anther 4. Library module: a frequently called module by anther module 47

Design Structure Chart Basic building blocks of Structure Chart. 5. Selection: means that one module out of several is invoked 6. Repetitions: represent that the respective modules are invoked repeatedly. 48

Design Structure Chart 49

Pseudo-Code • Pseudo-Code is a combination of algorithm written in simple language and programming language statements. • Using Pseudo-Code the designer describes the system characteristics using keyword such as IF-THEN-ELSE and WHILE-DO and END. 50

Pseudo-Code Example of Pseudo-Code 1. Read value of a, b and c 2. If(a<b) { if(a<c) print “a is the smallest” Else print “c is the smallest } Else if(b<c) print “b is the smallest” Else print “c is the smallest” 51

Pseudo-Code Advantages of Pseudo-Code • Converting Pseudo-code to program is much easier than converting flowchart or decision table. • Compared to flowchart it is easier to modify pseudo-code of program logic whenever program modifications are necessary. • Writing pseudo-code involves much less time and effort than equivalent flowchart. • Pseudo-code is easier to write than writing a program is programming language. 52

Pseudo-Code disadvantages of Pseudo-Code • Graphical representation of program logic is not available. • There are no standard rules to follow in using pseudo code, different programmer use their own rules od pseudo-code. • For beginner it is more difficult to follow the logic or write pseudo -code compared to flowchart. 53

Flow Chart • Is a techniques to represent the control flow in the program. • It is a pictorial representation of an algorithm that uses symbols to show the operation and decision to be followed. 54

Flow Chart Symbols used in flowchart 1. Terminal symbol 2. Input/output symbol 3. Processing Symbol 55

Flow Chart Symbols used in flowchart 4. Decision symbol 5. Flow Lines 6. Connector symbol 7. Loop symbol 56

Flow Chart 57

Flow Chart Rules and guidelines for drawing flowcharts • Only conventional chart symbols should be used. • Flow lines should not cross each other. • Processing logic should flow from top to bottom and from left to right. • Words in flowchart should be common statement and easy to understand. • Consistency in using names and variables in flowcharts. • If flowchart becomes large and complex then connector symbol should be used to avoid crossing flow lines. • Flowchart should have start and stop points. 58

Flow Chart Advantages of flowcharts. • flowchart is used as working model in designing of new programs and software systems. • Guide the programmer in writing the actual code which suppose to give error free program. • Flow chart act as an important tool in detecting, locating, and removing bugs. • It is excellent communication technique to explain the logic of program. • Can help in effective analysis of logical problem. • Help design test and test data. 59

Flow Chart Disadvantages of flowcharts. • Drawing of flowcharts is very time and laborious consuming process specially for complex systems. • Redrawing flowchart is more complex, it is very difficult to include any new steps in existing flowchart. • There are no standard. • Complex problem with many branches and loops are difficult to draw. 60

Coupling • coupling is the measure of the degree of interdependence between the modules. • If two modules interchange large amount of data then they are highly interdependent. • The degree of coupling depend on the complexity of interface(the number and type of parameters interchanged). • When there is a little interaction between two modules then the modules are loosely coupled, when there is high interaction the modules are strongly coupled. 61

Coupling Three degrees of coupling: • Highly Coupled: when modules are highly dependent on each other. • Loosely Coupled: when the modules are dependent on each other but the interaction between them is weak. • Uncoupled: when the different modules have no interaction among them. 62

Coupling Types of coupling: 1. Data Coupling: If the dependency between the modules is based on the fact that they communicate by passing only data, then the modules are said to be data coupled. 2. Stamp Coupling: In stamp coupling, the complete data structure is passed from one module to another module. 3. Control Coupling: If the modules communicate by passing control information. 63

Coupling Types of coupling: 4. External Coupling: In external coupling, the modules depend on other modules, external to the software being developed or to a particular type of hardware. 5. Common Coupling: The modules have shared data such as global data structures. The changes in global data mean tracing back to all modules which access that data to evaluate the effect of the change. 6. Content Coupling: In a content coupling, one module can modify the data of another module or control flow is passed from one module to the other module. 64

Coupling High coupling between modules make the design difficult to understand maintain and increase the development effort as the modules have a higher coupling they cannot be delivered independently. 65

Cohesion • Cohesion is a measure of the degree to which the elements of the module are functionally related. • It is the degree to which all elements directed towards performing a single task are contained in the component. • Basically, cohesion is the internal glue that keeps the module together. • A good software design will have high cohesion. • A high cohesion system is loosely coupled system. 66

Cohesion Types of Cohesion 1. Functional Cohesion: all activities in the module are functionally related or they are performing a similar function. 2. Sequential Cohesion: An element outputs some data that becomes the input for other element. 3. Communicational Cohesion: all function in the module refer to or update the same data structure. 67

Cohesion Types of Cohesion 4. Procedural Cohesion: activities share the same procedural implementation. Ex- calculate student GPA, print student record, calculate cumulative GPA, print cumulative GPA. 5. Temporal Cohesion: The elements are related by their timing involved. A module connected with temporal cohesion all the tasks must be executed in the same time-span. 68

Cohesion Types of Cohesion 6. Logical Cohesion: The elements are logically related and not functionally. Ex- A component reads inputs from tape, disk, and network. 7. Coincidental Cohesion: The elements are not related. The elements have no conceptual relationship other than location in source code. 69

Cohesion 70

Software Design Strategies There are mainly two strategies used for software design: • Top-Down Design Strategy • Bottom-Up Design Strategy 71

Top-Down Design Strategy • Breaking the problem into smaller problems. • Design activity begin with requirement analysis and should not consider implementation detail at first. • The specification is viewed as black box, then the designer decide how the internal of black box is constructed from smaller black boxes. • The process is repeated for those black boxes until these black boxes can be coded directly. 72

Bottom-Up Design Strategy • When specifications are complex or open ended, traditional top-down method become unsuitable. • In bottom-up design first modules that are required by many programmer are identified. • Those modules collected together in library. • Now those libraries combines together to form larger one and so on. 73

Function Oriented Design • Is a Top-down approach where the decomposition of system is performed into units where each unit has clearly defined function. • For function oriented design the design can be graphically or mathematically represented by the followings: 1. 2. 3. 4. Data flow diagram. Data Dictionary. Structure charts Pseudo-code 74

Object Oriented Design • Object Oriented implies that the system consists of a collection of objects that include both data and methods. • Object have four characteristics: identity, encapsulation, inheritance and polymorphism. • Focusing in OOD is on data that are to be manipulated not on functions performed by the system. 75

Steps to Analyze and Design Object Oriented System 1. Create a use-case model: use-case is description of sequence of events. Each use-case provide one or more scenarios that describe how system should interact with users calls. 2. Draw activity diagram: shows the dynamic nature of system by modeling the flow of control, the purposes are: 1. Draw the activity flow of the system. 2. Describe the sequence from one activity to another. 3. Describe the parallel, branched and concurrent flow of the system. 76

Steps to Analyze and Design Object Oriented System 77

Steps to Analyze and Design Object Oriented System 3. Draw the interaction diagram: model the behavior of use cases by describing the way group of object interact to complete the task, two kinds of interaction are: 1. Sequence diagram: show the sequence of events occur. 2. Collaboration diagram: demonstrate how object statically connected. 78

Steps to Analyze and Design Object Oriented System 4. Draw class diagram: static diagram that represent the static view of the system, it describe the types of objects and the various king of static relationships exist between them, class diagram contains: 1 - Classes 2 - Interfaces 3 - Collaborations 4 - Dependency 5 - Generalization and association relationships 79

Steps to Analyze and Design Object Oriented System 80

Steps to Analyze and Design Object Oriented System 5. Design state chart diagram: used to show state transition of a given class and the event cause the transition from one state to another. The purposes of state chart are: 1. To model dynamic aspect of system 2. To model life time of reactive system. 3. To describe different states of object during its life time. 4. Define a state machine to model state of an object. 81

Steps to Analyze and Design Object Oriented System 82

Steps to Analyze and Design Object Oriented System 6. Draw components and development diagram: component diagram address the static implementation view of a system, they are related to class diagrams in that component maps to one or more classes, interface or colaboration. 83

Functional Oriented Vs. Object Oriented approach Functional Oriented Object Oriented The basic abstractions are real The basic abstractions are world functions such as sort, the real world entities are merge, track, etc. represented Such as picture, machine, etc. In this approach the state information is often represented in a centralized shared memory. In this approach the state information is implemented or distributed among the objects of the system. Functions are grouped together by which a higher level function is obtained. Functions are grouped together on the basis of the data they operate. we decompose in function/procedure level we decompose in class level Functions gets some data, process it and then return the result. Objects is data with methods. 84

Chapter 6: END OF CHAPTER 85