Cohesion & Coupling. 1. Presentation OfSoftware engineering Topic: Cohesion & Coupling Jagnesh Chawla([email protected]).
Discuss in Detail Coupling and Cohesion. By Dinesh Thakur Category: Software Engineering. Coupling: Two modules are considered independent if one can function completely without the presence of other. Obviously, if two modules are independent, they are solvable and modifiable separately.
Contents: Coupling Highly Coupled Loosely Coupled Uncoupled Types Of Coupling Cohesion Types Of Cohesion Jagnesh Chawla([email protected]). Coupling Coupling is measure of the independence of components. Coupling is related to cohesion. It is an indication the strength of inter connections between the components in a design.
Jagnesh Chawla([email protected]). Highly coupled These types of systems have interconnections, with program units dependent on each other. Jagnesh Chawla([email protected]). Highly coupled: Jagnesh Chawla([email protected]). Loosely coupled Loosely coupled systems are made up of components which are independent or almost independent. In this less dependences are available. Jagnesh Chawla([email protected]).
Loosely coupled: Jagnesh Chawla([email protected]). Uncoupled Uncoupled components have interconnections at all. No Dependencies Jagnesh Chawla([email protected]). Uncoupled: Jagnesh Chawla([email protected]). The range of couplingmeasures: Content coupling High coupling Common coupling Loose Control coupling Stamp coupling Data coupling Low Uncoupled Jagnesh Chawla([email protected]). Content coupling: When one component actually modifies another. Then the modified component is completely dependent on the modifying one.
Jagnesh Chawla([email protected]). JagneshChawla([email protected]). Common coupling: We can reduce the amount of coupling somewhat by organizing our design so that data are accessible from a common data store. Global: A1 A2 A3 Variables: V1 V2 Component Component Component X Y Z Change V1 Increment T T V =V2+A To zero V1 Jagnesh Chawla([email protected]). Control coupling: When one component passes parameters to control the activity of another component. We say that there is control coupling between the two. Jagnesh Chawla([email protected]). Stamp coupling: When data structure is used to pass information from one component to another.
Jagnesh Chawla([email protected]). Data coupling: If only data are passed, the components are connected by data coupling. Jagnesh Chawla([email protected]).
Cohesion: The cohesion of a component is a measure of the closeness of the relationship between its components. Jagnesh Chawla([email protected]). Coincidental: The worst degree of cohesion, coincidental is found in a component whose parts are unrelated to one another. Jagnesh Chawla([email protected]). Logical cohesion: It is the next higher level of cohesion, where several logically related functions or data elements are placed in same component. Jagnesh Chawla([email protected]). Temporal cohesion: Sometime a component is used to initialize a system or a set variables. Such a component performs several functions in sequence,but the functions are related by the timing involved, so its cohesion is temporal.
Jagnesh Chawla([email protected]). Procedurally cohesion: When function are grouped together in a component just to ensure this order the component is procedurally cohesive.
Jagnesh Chawla([email protected]). Communicationally: Communicationally cohesion often destroys the modularity and functional independence of the design.
Notice the main difference between this and previous diagram? Approach to design are complementary; Good software engineers should select the. High Cohesion ensures each unit provides a set of related capabilities and makes the tests of those capabilities easier to maintain; Low Coupling allows each unit to be.
There is an interaction between requirements engineering, architecting, and design. SE, Design, Hans. Abstraction; Modularity, coupling and cohesion; Information hiding; Limit complexity; Hierarchical structure. Differences in verbosity; differences between programming languages; a:= b versus while p^ nil do p:= p^. Jagnesh Chawla([email protected]).
Sequential cohesion: If the output from one part of a component is input to the next part the component has sequential cohesion. Jagnesh Chawla([email protected]). Thank you Jagnesh Chawla([email protected]). Software development is time-consuming and expensive.
Under the best circumstances, one goes from an idea to requirements, design, coding, testing, deployment, and then a maintenance phase. This is, more or less, the classic software development model. Of course, changing requirements can throw off this entire process.
EHR vendors are experiencing this first-hand due to changing MU requirements. The threat of obsolescence due to changes in computing technology may also result in new requirements that alter software development cycles.
Consider how much computing has changed since 2000. In 2000, the Internet was just beginning to come into its own, and LAN-based client/server was still the next big thing.
Creating a complex web application such as a content management system was expensive, and the tools to do so were not that great. Java was five years old, Rails was four years in the future, and.Net was still two years away. Look at how much things have changed in just 12 years.
Mobile computing is a fact of life; anybody with a web hosting account can launch a content management system-based website; and the cloud and multi-processing are coming to the forefront of software development. In previous posts, I have discussed basic software design principles that help to address the problem of change. Concepts such as essentially acknowledge change as a constant that must be addressed via development practices and software architecture/design choices. Happily, developing a web application while studying object-oriented analysis and design (OOA&D) has allowed me to see the practical value of these design principles.
Cohesion and coupling are my latest discoveries. Coupling is defined as the degree of interdependence between two or more classes, modules, or components.
Tight coupling is bad, and loose coupling is good. This will make more sense with an example. Let’s say we have a clinical research application that contains a patient information collection form. On this form is a field for the SSN.
Whenever a patient enrolls in a study, the form checks the SNN to see whether: 1) it is a valid SSN (i.e., fits the pattern 0), and 2) the patient has been a subject in prior studies. In the current version of the application, when the cursor leaves the SSN field, the following procedure runs. Procedure SSN Check Begin If isNumber(LeftThreeChars) Then Result=0 Else Result =1 If isNumber(MiddleTwoChars) Then Result=0 Else Result =1 If isNumber(RightThreeChars) Then Result=0 Else Result =1 If Result=0 Then Count = “SELECT SSN FROM patients WHERE SocNum=SSN” Else Print “This is not a valid SSN” End This procedure checks whether each part of the SSN is a number, and if everything is okay, it searches for the SNN in the patients table and returns 1 if the patient has been in a prior study.
This type of code is easy (and tempting) to write in form-based development environments. Why is it bad? The Count query makes a direct call to the database. As a result, the SSN text field is tied directly to the database, exhibiting tight coupling. With one form, this is not a huge problem.
However, if the application has multiple forms and more than one requires SSN verification, it might become a headache if the form changes, the database changes, or the query is altered. Any of these situations could prove to be costly and messy because developers would have to find every place in the application where a SSN check occurred, change the programming code, and test the final application. Cohesion is defined as the degree to which all elements of a module, class, or component work together as a functional unit. High cohesion is good, and low cohesion is bad. The ideal situation is one where a module, class, or component provides only one function or, at most, a very closely related set of functions.
Looking at the above procedure, we see that it performs two functions. It validates SSNs, and it performs a database query.
These are completely unrelated actions and, thus, the procedure exhibits low cohesion. Improving the Design Moving unrelated functions into their own units (i.e., module, class, or component) would be a good first-step in improving the design.
One solution would be creating a data access module then placing all database queries for the entire application in one location. Consequently, forms would no longer have to know anything about the database–or even that it exists.
Next, we could do the same with validation. Since any real-world application is likely to require validation for a range of form fields (e.g., birthdates, duplicate names, vital signs, etc.) it makes sense to have one component that handles validation as well.
Here is the SSN Check procedure after Validation and Data Access modules have been created. Procedure SSN Check Begin Result =Validate (SSN) If Result=0 Then Count=Databaselookup(SSN) Else Print “This is not a valid SSN” End The new version of the SSN Check procedure merely passes information to functions in the Validation and Data Access modules. This procedure is now oblivious as to how validation is performed as well as how SSN numbers are stored. Further, new functions can be added to either module without affecting the SSN Check procedure. The form is now loosely coupled to the database, and the two new components are highly cohesive, each providing a single or closely-related set of functions. Post navigation.