Fundamental design concepts

fundamental design concept,structure,abstraction,verification,concurrency,module and modularization,coupling,cohesion

1. Submitted By, M. Lavanya, M.Sc.(CS&IT), P. Nithya, M.Sc.(CS&IT), N. Pandimeena, M.Sc.(CS&IT), Nadar Saraswathi College of Arts & Science, Theni. Fundamental design concepts

2. Fundamental concepts of software design includes the following techniques, 1. Abstraction 2. Structure 3. Information Hiding 4. Modularity 5. Concurrency 6. Verification 7. Design Aesthetics

3. Abstraction is the intellectual tool that allows us to deal with concepts apart from particular instances of those concepts. Three widely used abstraction mechanisms in software design are, 1. Functional Abstraction 2. Data Abstraction 3. Control Abstraction These mechanisms allow us to control the complexity of the design process by systematically proceeding from the abstract to the concrete. abstraction

4. Information hiding is a fundamental design concept for software. Each module in the system hides the internal details of its processing activities and modules communicate only through well-defined interfaces. Other candidates for information hiding include: 1. A data structure and its internal linkage 2. The format of control blocks such as those for queues in an operating system 3. Character codes 4.Shifting, masking and other machine dependent details Information hiding

5. Structure is a fundamental characteristic of computer software. The use of structuring permits decomposition of a large system into smaller, more manageable units with well-defined relationships to the other units in the system. The most general form of system structure is the network. Software System Structure Network structure Link Node

6. Node The nodes can represent processing elements that transform data and the arcs can be used to represent data links between nodes. Alternatively, the nodes can represent data stores and the arcs data transformation. Environment group templates Shared objects Processes

7. Process Each process, one might find functional abstraction groups, data abstraction groups, and control abstraction groups. Template group Processing groups Utility group

8. Group Each group might consist of a visible specification part and a hidden body. The visible portion would provide attributes such as procedure interfaces, data types, and data objects available for use by other groups. Visible part Static area Hidden part

9. The term of “module” a module is FORTRAN sub routine module ada package "to” module is a work of individual programmer Modular system is collection of abstraction D ata abstraction F unction abstraction Control abstraction The abstraction to handle problem to solved Modularity enhance design clarity Implementation Debugging Testing Document Maintenance MODULARITY

10. Modular system include : i) Well defined sub system ii) Each abstraction single iii) More than one major structure iv) Function share global data v) Function abstract data type

11. Software system can be categorized as Sequential Concurrency Sequence system can activate at any time. Concurrency system can process simutanuously using multiprocess available. The implementation of time sharing, multiprocessor, real time system and Concurrency system include: Deadlock Mutual exclusion Synchronization CONCURRENCY

12. DEADLOCK When process in computer system are waiting are other process executed MUTUAL EXCLUSION M utual exclusion multi process do not attempt ,same component at share process at a time SYNCHRONIZATION C oncurrent process at different execution speed CONCURRENCY PRINCIPLE Fundamental of software design

13. Verification is a fundamental concept in software design. The verification technique has two steps: i) verification is software requirement definition satisfied customer need ii) verification is the design satisfied requirement definition VERIFICATION

14. Aesthetics is fundamental to design, whether in art or technology. Simplicity, Clarity, Elegance Quality of product The mathematical elegance or structure beauty the properties of satisfaction of requirements AESTHETICS

15. Modules and modularization criteria

16. Characteristics A software module to be a named entity having the following characteristics: Modules contain instructions, processing logic, and data structures. Modules can be separately compiled and stored in a library. Modules can be included in a program. Module segments can be used by invoking a name and some parameters. Modules can use other modules.

17. Examples Examples of modules include procedures, subroutines, and functions; functional groups of related procedures, subroutines, and functions; data abstraction groups; utility groups and concurrent processes. Modularization allows the designer to decompose a system into functional units, to impose hierarchical ordering on function usage, to implement data abstractions, and to develop independently useful subsystems.

18. Coupling and Cohesion Coupling: The strength of coupling between two modules is influenced by the complexity of the interface, the type of connection, and the type of communication. Coupling between modules can be ranked on a scale of strongest(least desirable) to weakest(most desirable) as follows: Content coupling Common coupling Control coupling Stamp coupling Data coupling

19. Content Coupling: Content coupling occurs when one module modifies local data values or instructions in another module. Common Coupling: Modules are bound together by global data structures. Control Coupling: Control coupling involves passing control flags(as parameters or globals) between modules so that one module controls the sequence of processing steps in another module.

20. Stamp Coupling: Stamp coupling is similar to common coupling, except that global data items are shared selectively among routines that require the data. Data Coupling: Data coupling involves the use of parameter lists to pass data items between routines. The most desirable form of coupling between modules is a combination of stamp and data coupling.

21. Cohesion: The internal cohesion of a module is measured in terms of the strength of binding of elements within the module. Cohesion of elements occurs on the scale of weakest(least desirable) to strongest(most desirable) in the following order: Coincidental cohesion Logical cohesion Temporal cohesion Communication cohesion Sequential cohesion Functional cohesion Informational cohesion

22. Coincidental Cohesion: Coincidental cohesion occurs when the elements within a module have no apparent relationship to one another. Logical Cohesion: Logical cohesion implies some relationship among the elements of the module. Ex: In a module that performs all input and output operations, or in a module that edits all data.

23. Temporal Cohesion: Modules with temporal cohesion exhibit many of the same disadvantages as logically bound modules. A typical example of temporal cohesion is a module that performs program initialization. Communication Cohesion: The elements of a module possessing communicational cohesion refer to the same set of input and/or output data. Ex: “Print and Punch the Output File” is communicationally bound.

24. Sequential Cohesion: Sequential cohesion of elements occurs when the output of one element is the input for the next element. Functional Cohesion: Functional cohesion is a strong, and hence desirable, type of binding of elements in a module because all elements are related to the performance of a single function. Informational Cohesion: Informational cohesion of elements in a module occurs when the module contains a complex data structure and several routines to manipulate the data structure.

25. Other Modularization Criteria Additional criteria for deciding which functions to place in which modules of a software system include: H iding difficult and changeable design decisions L imiting the physical size of modules S tructuring the system to improve observability and testability I solating machine dependencies to a few routines E asing likely changes P roviding general purpose utility functions R educing the call return overhead of excessive subroutine calls.