UNIT 3
Software Design strategies & methodologies
Software design is a process where software requirements are analysed in order to produce a description of the internal structure and organization of the system that serves as a basis for its construction (coding).
IEEE defines software design as “both a process of defining the architecture, components, interfaces, and other characteristics of a system or component and the result of that process”. During software design phase, many critical and strategic decisions are implemented to meet the required functional and quality requirements of a system. These decisions are taken into account to successfully develop the software.
Objectives of Software Design:
Principles of Software Design
Data oriented software design
A data-centered architecture has two distinct components:
The client software accesses the data independent of any changes to the data or the actions of other client software. In this architectural style, existing components can be deleted and new clients can be added to the architecture without affecting the overall architecture. This is because client components operate independently.
Structured Design
Structured design is an approach based on ‘divide and conquer’ strategy where a problem is divided into several sub problems and each small problem is individually solved until the whole problem is solved. The small parts of problem are solved by means of different solution modules. Structured design emphasis on modular programming to achieve a precise ordered solution.
Structure chart represents hierarchical structure of modular programming. At each layer a specific task is performed. In figure below symbols are given which are used in construction of structure charts.
These modules are arranged in hierarchy as communicate with each other. A structured design can further be explored as namely -
Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.
Module - It represents process or subroutine or sub-task. A control module branches to more than one sub-module. Library Modules are re-usable and invokable from any module.
In modular design when modules can function completely without the interaction of another module, they are called independent. As they are separable and modifiable individually. Though, all modules in a system cannot be independent of each other.
Coupling is measure of strength of interconnections between modules or a measure of interdependence between the modules. When modules are strongly connected, they are called highly coupled. On the other hand when modules have weak interconnections, they are "loosely coupled".
Figure 3: Factors affecting coupling
The more complex each interface is, the higher will be the degree of coupling.
Example: complexity of the entry interface of a procedure depends on the number of items being passed as parameters and on the complexity of the items.
Module coupling is categorized into the following types.
• No direct coupling: Two modules are no direct coupled when they are independent of each other. In Figure below, Module 1 and Module 2 are no directly coupled.
• Data coupling: Two modules are data coupled if they communicate by passing parameters. In Figure below, Module 1 and Module 3 are data coupled.
Stamp coupling: Two modules are stamp coupled if they communicate through a passed data structure that contains more information than necessary for them to perform their functions. In Figure below data structure is passed between modules 1 and 4.Therefore, Module 1 and Module 4 are stamp coupled.
Control coupling: Two modules are control coupled if they communicate (passes a piece of information intended to control the internal logic) using at least one ‘control flag’. The control flag is a variable that controls decisions in subordinate or superior modules. In Figure 4.12, when Module 1 passes control flag to Module 2, Module 1 and Module 2 are said to be control coupled. Control coupling is shown below.
Content coupling: Two modules are content coupled if one module changes a statement in another module, one module references or alters data contained inside another module, or one-module branches into another module. In Figure 4.13, Modules B and Module D are content coupled.
Common coupling: Two modules are common coupled if they both share the same global data area. In Figure below Modules C and Module N are common coupled.
Cohesion of a module is how strongly the internal components of a module are bounded to each other. Relation between cohesion and coupling is like this greater the cohesion of each module, lower the coupling between modules.
Coupling is inter modules (between the modules) and cohesion is intra modules (within a module).
Several levels of cohesion:
• Coincidental (lowest)
• Logical
• Temporal
• Procedural
• Communicational
• Sequential
• Functional
Structured analysis uses DFD which is “a diagram that depicts data sources, data sinks, data storage, and processes performed on data as nodes, and logical flow of data as links between the nodes”. DFD depicts flow of data from one or more processes to another and some other objectives are:
• Represents system data in hierarchical manner and with required level of detail.
• Depicts processes according to defined user requirements and software scope.
DFD depicts the flow of data within a system and considers a system that transforms inputs into the required outputs. When there is complexity in a system, data needs to be transformed by using various steps to produce an output. These steps are required to refine the information.
The objective of DFD is to provide an overview of the transformations that occur to the input data within the system in order to produce an output.
DFD are not same as flowchart. A DFD represents the flow of data whereas flowchart depicts the flow of control. Also, a DFD does not depict the information about the procedure to be used for accomplishing the task. Hence, while making DFD, procedural details about the processes should not be shown. DFD helps a software designer to describe the transformations taking place in the path of data from input to output
DFD comprises of four basic notations (symbols), listed in Table below:
These levels are listed below:
• Level 0 DFD (also known as context diagram): Shows an overall view of the system.
• Level 1 DFD: Elaborates level 0 DFD and splits the process into a detailed form.
• Level 2 DFD: Elaborates level 1 DFD and displays the process(s) in a more detailed form.
• Level 3 DFD: Elaborates level 2 DFD and displays the process(s) in a detailed form.
Design notations are used to express process of design and are used to represent design or design decisions for a function-oriented design, the design can be represented graphically or mathematically by the following:
Structure Chart
It breaks down a system into block boxes. A black box means that functionality is known to the user without the knowledge of internal design.
To design a system in structured way, there are two possible approaches:
a) Top-down Approach
b) Bottom-up Approach
Top-down Approach: this approach begins with identification of the main components and then decomposing them into their more detailed sub-components.
Figure: Top down
Bottom-up Approach: bottom-up approach starts with the lower details and moves towards up the hierarchy, as shown in fig. This approach is suitable in case of an existing system.
Figure: bottom up
Object-oriented design
In the object-oriented design consider system as a collection of objects (i.e., entities -real world object). Class is made which is a prototype of an object. Objects belonging to same class have same data and functions.
Elements of object oriented design
a) Objects: real world entities are object having attributes associated with it and has some methods to be perform on the attributes.
b) Classes: A class is a generalized blue print of an object. An object is an instance of a class.
c) Messages: Objects communicate by message passing.
d) Abstraction: To reduce complexity abstraction is used. it is the removal of irrelevant and the amplification of the essentials.
e) Encapsulation: Encapsulation is also called an information hiding concept. The data and operations are linked to a single unit.
f) Inheritance: inheritance is a process of reusing old data by using concept of inheritance through which an object acquires the property of another object.
g) Polymorphism: it enables using of similar function and methods name to be used with a small distinction in argument passing.
UML (Unified Modeling Language) is a general-purpose graphical modeling language used of Software Engineering. It is used to specify, visualize, construct, and document the artifacts (major elements) of the software system.
The UML helps in designing and characterizing the concept of Object orientation to develop a software systems. It explains the working of both the software and hardware systems.
Features of UML
UML diagrams are classified into three categories that are given below:
Structural Diagram
It represents the static view of a system by portraying the structure of a system. It shows several objects residing in the system. Following are the structural diagrams given below:
Behavioural Diagram
It depicts the behavioural features of a system. It deals with dynamic parts of the system. It encompasses the following diagrams:
Interaction diagram: It is a subset of behavioural diagrams. It depicts the interaction between two objects and the data flow between them. Following are the several interaction diagrams in UML:
