1. SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well planed manner from the information collected in requirement analysis.

2. SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design activities start after the software requirements have been analyzed and specified correctly. These activities are: Design Code generation Testing

3. The Data Design In data design, the information collected during analysis are transformed into data structure that are used in the system (or software) implementation. The data objects and their relationship are defined in the ERD and the data contents into Data Dictionary of analysis model.

4. The Architectural Design The large systems are decomposed into sub-systems. The design process of identifying the sub-systems and establishing the relationship between sub-systems of a system is called Architectural Design. The primary objective of the Architectural design is to develop a modular program structure and represent the control relationships between modules. Architectural Design joins the program structure & data structure, defines the interfaces of modules and how the modules share the data or data flow through the modules.

5. What is Architecture? It is the overall shape of the physical structure of the software. It is also regarded as a manner by which various components of the system are integrated to form a concrete model. It is the viewpoint on which the customer feels satisfaction from its needs. It is also like an art to cover sharp details.

6. What is Software Architecture? The software architecture of a program or computer based system is the structure of the system, which consists of: Software Components Properties of Software Components The Relationship among them

7. The Interface Design This activity defines or describes the interfaces of each sub-system of a system with other sub-system as well as with users. An interface indicates flow of information. Therefore data and control flow diagrams provide the information that are required for the interface design.

8. The Procedural Design In this activity, structural elements of program architecture are transformed into procedural description of software components. Services are allocated to different components and interface of these components is designed. This activity is performed with the help of information obtained from the PSpec, CSpec and STD (State-Transition Diagram).

9. THE DESIGN PROCESS The Design process is a set of activities through which the customer ’ s requirements are transformed into a blueprint for constructing the software. The design is represented at a high level of abstraction. It is level that can be directly traced to specify data, functional and behavioral requirements.

10. DESIGN & SOFTWARE QUALITY The quality control activities must be performed throughout the design process. The software quality is assessed with a series of formal technical reviews and using other technical methods. There are three characteristics (given by McGlaughlin) that help in the evaluation of a good design.

11. CHARACTERISTICS OF A GOOD SOFTWARE DESIGN The design must implement all the explicit requirements contained in the analysis model as well as it must accommodate all the implicit requirements designed by customer. The design should display uniformity and integration. It means that rules and format should be defined for a design team before design work begins. The design should be structured to accommodate new changes. The design should be structured to be acceptable, even when varying data, events or operating conditions are encountered.

12. CHARACTERISTICS OF A GOOD SOFTWARE DESIGN The design is not coding and coding is not design. The design should be assessed for quality, as it is being created. For this purpose, various design concepts and design measures are available for he help of designer in assessing quality. The design should be reviewed to minimize the conceptual errors.

13. DESIGN CONCEPTS There are many fundamental concepts that help the software designer to apply the most suitable design methods. Each fundamentals design concepts helps the software designer or engineer to give the answer of the following questions. What criteria can be used to partition software into individual components? How is the detail of function or data structure separated from a conceptual representation of the software? Are there uniform criteria that define the technical quality of a design?

14. ABSTRACTION The abstraction is a very powerful concept that is used in all engineering disciplines. It is a tool that allows a designer to consider a component at an abstract level without knowing the detail of the implementation of the component into the system. An abstraction of the component describes the external behavior of that component but not describes the internal details of the component that produce the behavior.

15. ABSTRACTION MECHANISM Procedural Abstraction Data Abstraction Control Abstraction

16. Procedural Abstraction It is also referred as functional abstraction. It is a module or a set of instructions that have a specific and limited function. For example a module to compute the sine of value can be abstractly represented by the function “ Sine ” :

17. Data Abstraction It is a second unit of abstraction. There are certain operations that are required from a data object. The predefined operations can be performed on the data object. The operations defined on the data object are the only operations that can be performed on those objects. From outside an object, the internals of the objects are hidden and only the operations on the object are visible. The programming languages ADA and Modula etc provide the mechanisms for creating abstract data types.

18. Control Abstraction It is the third unit or form of abstraction used in software design. It indicates a program control mechanism without specifying the internal details.

19. EFECTIVE MODULAR DESIGN In fact modularity has become an acceptable approach in all engineering discipline. A modular design reduces complexity, facilities changes, and results in easier implementation by encouraging parallel development of different parts of a system.

20. FUNCTIONAL INDEPENDENCE A module is a logically separate part of a program. A system is considered to be modular if it consists of components (or modules) such that each component supports a well-defined abstraction and if one component is modified then minimum affect is occurred on other components. Some criteria must be used to select modules so that the modules support well-defined abstractions and are solvable and modifiable separately.

21. MODULIZATION CRITERIA The independence is measured by using two modularization criteria; these are Coupling Cohesion

22. COUPLING The coupling is a measure of interconnection between modules in a program structure (or system). Highly coupled modules are joined by strong interconnection and the modules are dependent on each other. The loosely coupled modules have weak interconnection and the modules are independent.

23. COUPLING MODULE AMODULE B MODULE CMODULE D Fig (a) Highly Coupled Modules

24. COUPLING Loosely Coupled Modules Module A Module BModule c Module D

25. COUPLING Content/Pathological Coupling : (worst) When a module uses/alters data in another Control Coupling : 2 modules communicating with a control flag (first tells second what to do via flag) Common/Global-data Coupling : 2 modules communicating via global data Stamp/Data-structure Coupling : Communicating via a data structure passed as a parameter. The data structure holds more information than the recipient needs. Data Coupling : (best) Communicating via parameter passing. The parameters passed are only those that the recipient needs. No data coupling : independent modules.

26. COHESION Cohesion of a module represents how tightly bound the internal elements of modules are to one another. The cohesion of a module is a measure of the closeness of the relationships between the components. A module should perform a single task and all elements of the module should contribute to this task. If some elements of the module are not directly related to perform task, it has low cohesion.

27. LEVELS OF COHESION There are seven levels of cohesion: Coincidental Cohesion It is the lowest level and functional is the highest. It occurs when there is no meaningful relationship between the elements of a module. Elements of the module are not related, but simply bundled into a single component. An example of a module using coincidental cohesion is one which performs various functions such as computing net pay, calculating inventory reorder amount or generating an invoice depending on the value of the parameters passed to the module.

28. LEVELS OF COHESION Logical Cohesion A module has logical cohesion if there is some logical relationship between elements of a module, and the elements perform functions that fall in the same logical class. The components that perform similar functions such as inputs outputs error handling and so on are put together in a single component. An example of a logically cohesive module is a general I/O routine which reads, writes, or deletes various combinations of records, depending on the value of a control flag. Control flags are often an indication that a module is logically cohesive.

29. LEVELS OF COHESION Temporal Cohesion The temporal cohesion is same as the logical cohesion except that the relationship between the elements is temporarily bond and these are execute together at the same time. The modules that perform activities like start-up shutdown etc. are usually temporally bound. The temporal cohesion is higher than logical cohesion since the elements are all executed together. Temporally cohesive modules typically consist of partial activities whose only relationship to one another is that they are all carried out at a specific time. E.g. FatalErrorShutdown

30. LEVELS OF COHESION Procedural Cohesion In procedural cohesion elements in a component make up a single control sequence. For example a loop or a sequence of decision in a module may be combined to form a separate module. A module with only procedural cohesion may contain a part of a functions, or parts of several functions. For example, a procedurally cohesive module may:  write record B,  read record A,  format A for printing.

31. LEVELS OF COHESION Communication Cohesion In communication cohesion elements are related by a reference to the same input or output data. It means that the elements of the module operate on the same input or produce the same output data. Unrelated operations except need same data or input For example, obtain author, title, or price of book from bibliographic record, based on a passed flag.

32. LEVELS OF COHESION Sequential Cohesion In sequential cohesion elements in a component are related so that the output from one element in the component or module serves as input for the next element in a sequence. Examples of activities in a sequentially cohesive module are:  Retrieve customer, retrieve customer order, and generate invoice,  Get and edit input data.

33. LEVELS OF COHESION Functional Cohesion The functional cohesion is that strongest cohesion. Ina functionally bound module all elements of the module are related to perform a single function. Each part of the component is necessary for the execution of a single function. Functionally cohesive modules may be simple and perform one task, such as Read Customer Record. Calculate net Pay

34. COHESION AND COUPLING Most researchers and engineers agree that a good software design implies clean decomposition of the problem into modules and thereafter the neat arrangement of these modules. The primary characteristics of neat module decomposition are high cohesion and low coupling.