As Example 8 shows, developers need to deal with the dependencies that arise as a result of their decomposition of a problem and its solution into a number of modules. We say that a module of a system depends on another if it is possible that a change to one module requires a change to another. For example, if a business changes its production methods this may cause a consequent change in the way it calculates the payments required for the goods it produces.
A developer must not only deal with the nature of each dependency but also the number of dependencies. In software engineering, ‘coupling’ is used to refer to the degree of interdependence among the different parts of a system. It is easy to see that certain systems can have chains of interdependent modules where, for example, module A depends on module B, which depends on module C, and so on. In some cases these chains may join up and create a circular dependency, which is a particular form of strong (or high) coupling.
Developers try to construct loosely coupled systems because they are easier to understand and maintain. So a good software system has low coupling, which means that changes to one part are less likely to propagate through the rest of the system. A further benefit of low coupling is that components are easy to replace and, potentially, reuse.
Whatever the level of coupling in a software system, it is important to know which modules are coupled. If there were no records of the coupling between modules, a developer would have to spend time working through the modules to determine whether or not each was affected by a change. The result would be a lot of effort spent on checking, even if no changes were needed. Example 9 illustrates the danger of having more than one module making use of common or shared data.
Date handling has always been a problem for software developers. For applications of a certain age, the most applicable storage format for representing a year was a number between 0 and 99. It made sense because 1966 was stored as 66, 1989 as 89, and so on, therefore less space was needed to store just two digits. Furthermore, if dates were stored as numbers, tasks that involved sorting by date order were simple – 22 January 1989 stored as 890122, is after 22 December 1966 stored as 661222.
Unfortunately, a number of these applications were still in use as the year 2000 approached, so every module in every application that used the short form of year had to be investigated.
A major aspect of the problem in Example 9 was that different developers had different ways of reading and manipulating the values stored in variables that used the six-figure date format. This increased the effort required to resolve the so-called millennium bug. If developers had had a consistent way to manipulate dates that did not rely upon the storage format, the millennium bug would not have been an issue of concern.
Cohesion is a way of describing how closely the activities within a single module are related to each other. Cohesion is a general concept – for example, a department in an organisation might have a cohesive set of responsibilities (accounts, say), or not (miscellaneous services). In software systems, a highly cohesive module performs one task or achieves a single objective – ‘do one thing and do it well’ is a useful motto to apply. A module should implement a single logical task or a single logical entity.
Low coupling and high cohesion are competing goals. If every module does only one thing at a low level of abstraction, we might need a complex edifice of highly coupled modules to perform an activity at higher levels of abstraction. A developer should try to achieve the best balance between the levels of coupling and cohesion for a software system. For example, hotels generate income by letting out their rooms to guests. The concept of room is likely to be represented somewhere in the software system for reservations for a hotel. It may be convenient to use a module or class representing the concept of room to collect and store data about the income generated by letting rooms. However, a better solution is to have a separate bill or payment module, because it is more cohesive, especially when a hotel generates income in other ways, for example, from serving meals to people who are not resident guests.
Allow approximately 20 minutes.
OpenLearn - Approaches to software development Except for third party materials and otherwise, this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 Licence, full copyright detail can be found in the acknowledgements section. Please see full copyright statement for details.