As lead analyst on a new system development project, you have been hard at work
ID: 3573511 • Letter: A
Question
As lead analyst on a new system development project, you have been hard at work developing the program designs for the new system. Much of your time over the last three weeks has been devoted to this task, and you are nearing your target deadline. You have been so immersed in this work that you have decided to ask a team member to spend some time reviewing the structure charts that you have prepared. Although you have tried to be very careful in your work, you know that it is easy to overlook some design problems, and you want to avoid as many nasty surprises later as you can. The team member you want to help you has had quite a bit of experience reading and implementing systems from structure charts, but she has not been responsible for their development yet in her career. a. Describe what your team member should look for with regard to cohesion. What will signify good cohesion in the design? What should she look for that might signify poor cohesion in the design? b. Describe what your team member should look for with regard to coupling. What will signify good coupling in the design? What should she look for that might signify poor coupling in the design? c. Describe what your team member should look for with regard to fan-in and fan-out. What will signify high fan-in in the design? What should she look for that might signify low fan-in in the design? What will signify low fan-out in the design? What should she look for that might signify high fan-out in the design?
Explanation / Answer
Cohesion measures the extent to which all elements of a module belong together. (The term element refers to any piece of code that performs some work or defines some data.) In other words, cohesion examines how the activities within a module are related to one another. The cohesion of a module may determine how tightly it will be coupled to other modules
Designing Highly Cohesive Modules
The objective of designers is to create highly cohesive modules where all the elements of a module are closely related. However, the elements of one module should not be closely related to the elements of another module. Such a relationship leads to tight coupling between modules. Ensuring high cohesion within modules is one way of reducing tight coupling between modules.
Together with coupling, cohesion is one of the best measures of the quality of a desig
Cohesion and Coupling deal with the quality of an OO design. Generally, good OO design should be loosely coupled and highly cohesive. Lot of the design principles, design patterns which have been created are based on the idea of “Loose coupling and high cohesion”.
The aim of the design should be to make the application:
easier to develop
easier to maintain
easier to add new features
less Fragile.
Coupling:
Coupling is the degree to which one class knows about another class. Let us consider two classes class A and class B. If class A knows class B through its interface only i.e it interacts with class B through its API then class A and class B are said to be loosely coupled.
If on the other hand class A apart from interacting class B by means of its interface also interacts through the non-interface stuff of class B then they are said to be tightly coupled. Suppose the developer changes the class B‘s non-interface part i.e non API stuff then in case of loose coupling class A does not breakdown but tight coupling causes the class A to break.
So its always a good OO design principle to use loose coupling between the classes i.e all interactions between the objects in OO system should use the APIs. An aspect of good class and API design is that classes should be well encapsulated.
Cohesion:
Cohesion is used to indicate the degree to which a class has a single, well-focused purpose. Coupling is all about how classes interact with each other, on the other hand cohesion focuses on how single class is designed. Higher the cohesiveness of the class, better is the OO design.
Benefits of Higher Cohesion:
Highly cohesive classes are much easier to maintain and less frequently changed.
Such classes are more usable than others as they are designed with a well-focused purpose.
Single Responsibility principle aims at creating highly cohesive classes.
FAN IN and FAN OUT
The fan-out of a module is the number of its immediately subordinate modules. As a rule of thumb, the optimum fan-out is seven, plus or minus 2. This rule of thumb is based on the psychological study conducted by George Miller during which he determined that the human mind has difficulty dealing with more than seven things at once.
The fan-in of a module is the number of its immediately superordinate (i.e., parent or boss) modules. The designer should strive for high fan-in at the lower levels of the hierarchy. This simply means that normally there are common low-level functions that exist that should be identified and made into common modules to reduce redundant code and increase maintainability. High fan-in can also increase portability if, for example, all I/O handling is done in common modules.
Object-Oriented Considerations
In object-oriented systems, fan-in and fan-out relate to interactions between objects. In object-oriented design, high fan-in generally contributes to a better design of the overall system. High fan-in shows that an object is being used extensively by other objects, and is indicative of re-use.
High fan-out in object-oriented design is indicated when an object must deal directly with a large number of other objects. This is indicative of a high degree of class interdependency. In general, the higher the fan-out of an object, the poorer is the overall system design.
Strengths of Fan-In
High fan-in reduces redundancy in coding. It also makes maintenance easier. Modules developed for fan-in must have good cohesion, preferably functional. Each interface to a fan-in module must have the same number and types of parameters.
Designing Modules That Consider Fan-In/Fan-Out
The designer should strive for software structure with moderate fan-out in the upper levels of the hierarchy and high fan-in in the lower levels of the hierarchy. Some examples of common modules which result in high fan-in are: I/O modules, edit modules, modules simulating a high level command (such as calculating the number of days between two dates)
Use factoring to solve the problem of excessive fan-out. Create an intermediate module to factor out modules with strong cohesion and loose coupling
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.