 Ganapayawalika works in the Department of Computer Science and Engineering, Vulture Institute of Technology, Sholapo. Today I am going to deliver a lecture on Introduction to Software Design. As part of the learning outcome, at the end of this session, students will be able to explain how software design may be represented as a set of functional modules and also they will be able to illustrate the concept of cohesion and coupling with example. These are the content of my presentation, Introduction to Software Design, Design Principles, Modularization, Cohesion and Coupling. Let us we will discuss one by one. So before discussing different aspects of design, let we will overview of the software design. In software requirements engineering, wherein the requirement analyst have gathered the requirements of a software from the stakeholders and specified them in a software requirement specification. And usually in a requirement analysis, they will gather the requirement of a software and they understand the requirements and then specify those into SRS. So once SRS is ready, so now design engineers needs to plot the requirements from the end user in terms of very good design. As I said, usually design begins after requirement analysis process. Now software design process concentrates more on how to find the solution to the problem identified in the requirement analysis phase of the software development lifecycle. Usually requirement analysis try to understand the problem of the system in the requirement analysis phase. So in the design, so they try to find a solution to the problem identified in the requirement analysis phase and hence the software design transforms what to and how that is it converts SRS to a design document. However we are talking in terms of analysis, it is all in terms of words written context. So now the design process converts these textual formats into a design format which will be legible and be clear to all the developers and customers. Design is a blueprint or a solution to the problem of the system. So the first point here more effectively required is that the design has to be more creative than in terms of analysis. Usually there are two level of people are there who are going to use this design document. One is customer and another one is a designer. In order to satisfy both customer and developers, the design should be complete, correct, verifiable, traceable, understandable, simple, efficient and maintainable. To convince these customers, first concepts of design being built before building technical design. The concepts of design highlights what to implement and technical design focuses on how to implement the specification. So, commercial design convince the customer and technical design convince a developer how to proceed with a development process. So now we will move from introduction part to the functional oriented software design. Functional or function oriented design is a method for software design where the module is decomposed into a set of interacting units or a modules where each unit or a module has a clearly defined functions. So here this is a pictorial representation of how each module is decomposed into a different fine track to modules or interactive functions. These are the different functions derived from the single module and all these functions are interacting each other and having a well defined services or well defined functions. So now these are the design principle to proceed with the design phase, right. Every design engineers have to follow some set of the principles or some set of the guidelines and these are the guidelines or these are the principles for the design engineer to proceed with the design work. So one first one is problem partitioning and hierarchy, abstractions, fidelity, top down and bottom up strategy. In the problem partitioning and hierarchy thus the large and complex problem is divided into a independent or independently manageable parts and then conquer these parts and then assemble these parts to find a solution to the entire software or entire system. And after applying the problem partitioning we have left with n number of parts and these parts will be organized in a well manner or well system hierarchy so that everyone can understand each part of the system. So next one is abstraction. The abstraction is a concept so that will allow them a designer or allow the designer to view the modules in a abstraction manner not in a details. Abstraction can be achieved in terms of functions and in terms of data. So first one is functional abstractions and second one is data abstraction. The functional abstraction enables designer to view the module as in a functions which is responsible for a performing that particular module and in data abstractions the designers are focusing only on type of data and its associated operations irrespective of how that data being implemented and where it is or where form it is derived. Next one is modularity. So this helps a designer to decompose a complex and large system into different or individual manageable modules and each module can be compiled and executed separately. And in the top-down and bottom-up strategies the user will adapt top-down approach for the design where the requirements are not in detail and bottom-up strategies are applied for the system where the requirements are in detail. So there are two main properties need to be understand or need to be used in selecting the good design or to develop a good design. One is coupling and second one is co-agent and both these properties are used in identifying the modules in a design. The coupling is the measure of the degree of interdependency between the modules that is it defines strength of interconnection between the modules in a system. So once the system is decomposed or partitioned into different modules, so these modules are either to be dependent or are independent. Usually 99% is modules are dependent each other, if the modules are not dependent then there is no coupling that is what uncoupling or no dependency. And if the modules are joined by low coupling, so that is what a loosely coupled. And if the modules are coupled strongly then we can say it is highly or tightly coupled. And these coupling is mainly dependent on three things. One is the number of interfaces and its complexity that is the complexity of the interfaces and third one is type of data being exchanged between these two modules. Here there is no interface, so hence there is no coupling and here the modules are having less interfaces and also they are exchanging only simple data. So that is why, so these modules are coupled by a loosely coupling. And here too many interfaces are exist between these two modules that indicate that these two modules are highly dependent and also they are exchanging data as well as control information. So that is why, so here there is highly or tightly coupled or else you may say that these modules are interconnected with strong coupling. These are the types of coupling that is content coupling, common coupling, external coupling, control coupling, message coupling, data coupling and stamp coupling. The content coupling means the one module is directly accessing or directly modifying content of the another module. The common coupling means that two modules of any system they are referring to the common data. External coupling means the modules or multiple modules or two modules are referring to the external formats and they are referring to the protocols or communication protocols. The control coupling can be achieved if the one module totally controls functions of the another module and even the one module can change the sequence of the or flow control of the another module and then message coupling. So message coupling can be achieved if that multiple or two modules are communicating each other by means of a message passing mechanism. The data coupling means the multiple modules they are referring to the single data structure and not only referring to the single data structure but they are trying to update that particular data structure. The stamp coupling means the multiple modules they are referring to the common data structure but they are using that data structure in their internal operations. So now we will move to the cohesion. As I said this is also one of the selection criteria of design. The cohesion measures of the degree to which the elements of the modules are functionally related that is the strength of the relations within the module. So now we will discuss types of the cohesion there are several types of cohesions are there coincidental cohesion, logical cohesion, temporal cohesion, procedural cohesion, sequential cohesion and functional cohesion. The worst cohesion is coincidental cohesion. So coincidental cohesion means here the elements of the module are coincidentally related each other. They are not related by means of the functions they are not related by means of functions or services but coincidentally they are interrelated. Logical cohesion means the two elements are more than two elements they are referring to the common logic and they are using in their operation. And temporal cohesion means here also the more than two elements they are referring to the common logic and they are using in their internal the difference between logical cohesion temporal cohesion is in the temporal cohesion all the elements they are using that common logic at the same time. Next one is the procedural cohesion here the multiple elements they are referring to the common procedure to perform their operations. The sequential cohesion the element one element output of the one element is going to be act as a input to the another element. In functional cohesion the multiple elements of a module are using single function modularity. The modularity is the process in which the system is divided into modules and managed and executed them separately. The module in different programming language context the subroutine in case of fortune packages in case of ADA procedure and functions in case of Pascal and C and the modules may be classes in case of C++ and Java but in case of software engineering context the module is in an assignment for an individual programmer think and write what is the difference between coupling and cohesion. Over the video now and answer the questions. The coupling is a degree of dependency between the modules and the cohesion is the strength of functionality within the modules and coupling is inter modular properties and cohesion is a intra modular property. Cohesion defines a strength of modules the cohesion defines the strength of elements in a module. These are the references I used to prepare my presentation thank you.