CSC/ECE 517 Fall 2009/wiki3 18 301: Difference between revisions
m (→Links) |
No edit summary |
||
(15 intermediate revisions by 2 users not shown) | |||
Line 3: | Line 3: | ||
== Introduction == | == Introduction == | ||
Package Design is a challenging area of Software Engineering. An inefficiently designed system can be a root cause of many problems, thus, it is vital to have a solid understanding of various design approaches. This article discusses Stable Dependencies Principle, one of a few key package design principles that software engineers should be aware of. | Package Design is a challenging area of Object Oriented Programming (OOP), an important part of Software Engineering. An inefficiently designed system can be a root cause of many problems, thus, it is vital to have a solid understanding of various design approaches. This article discusses Stable Dependencies Principle, one of a few key package design principles that software engineers should be aware of. | ||
== Definition of Package== | |||
In OOP, a package is one or more classes logically grouped into a single unit. According to [4], "classes often have dependencies on other classes, creating package dependencies relationships." The below principle can interchangeably be applied to small packages of just one class, and to larger ones consisting of multiple classes. | |||
== Definition of Instability == | == Definition of Instability == | ||
First, let's discuss why certain packages are considered stable, and others are not. | First, let's discuss why certain packages are considered stable, and others are not. According to [2], the instability of any package can be calculated using the following formula: | ||
I (instability) = Ce / ( Ca + Ce ) | I (instability) = Ce / ( Ca + Ce ) | ||
Line 15: | Line 19: | ||
Ce – the number of other modules that our package requires in order to operate correctly. In other words, this is an indicator of package ''independence''. | Ce – the number of other modules that our package requires in order to operate correctly. In other words, this is an indicator of package ''independence''. | ||
Ca – the number of packages that can be viewed as “dependents“, i.e., “depend upon classes within the package”. This is an indicator of package '' | Ca – the number of packages that can be viewed as “dependents“, i.e., “depend upon classes within the package”. This is an indicator of package ''responsibility''. | ||
Therefore, in order for a package to be completely independent and also stable, it should not be dependent upon other packages. | Therefore, in order for a package to be completely independent and also stable, it should not be dependent upon other packages. | ||
Line 23: | Line 27: | ||
[[Image:fig1.png]] | [[Image:fig1.png]] | ||
The ''Wheel'' class in this example is shown | The ''Wheel'' class in this example is shown to be not dependent on any other module. | ||
Using the above formula: | Using the above formula: | ||
Line 37: | Line 41: | ||
In this case, the ''Car'' class does not have any dependent classes (Ca = 0), yet itself depends upon three classes – ''Wheel'', ''Engine'', and ''Suspension'' (Ce = 3). | In this case, the ''Car'' class does not have any dependent classes (Ca = 0), yet itself depends upon three classes – ''Wheel'', ''Engine'', and ''Suspension'' (Ce = 3). | ||
Let’s calculate the instability of the ''Car'' package: | |||
I(C) = 3 / ( 0 + 3 ) = 3 / 3 = 1 | I(C) = 3 / ( 0 + 3 ) = 3 / 3 = 1 | ||
Line 63: | Line 67: | ||
I(St) = 0 / (1 + 0) = 0 | I(St) = 0 / (1 + 0) = 0 | ||
After replacing each class with its corresponding instability value, the diagram would look as | After replacing each class with its corresponding instability value, the diagram would look as shown below: | ||
[[Image:fig4.png]] | [[Image:fig4.png]] | ||
In general, lower values result in more stable packages. In our case, all dependencies progress in the direction of stability, thus, according to the SDP, our design is proven to be effective. | |||
Another important consideration when it comes to stability is that more stable packages should not be changed often. On the other hand, a highly volatile class can be changed easily, without affecting other packages in the system. | Another important consideration when it comes to stability is that more stable packages should not be changed often. On the other hand, a highly volatile class can be changed easily, without affecting other packages in the system. | ||
== Conclusion == | |||
To summarize, the SDP is one of several package design principles. It helps design "systems with a high degree of reusability and testability" [1]. The principle states that "a package should always depend upon packages that are more stable than it is," and this article demonstrates methods to identify which packages are more stable than others. | |||
== Links == | == Links == |
Latest revision as of 05:24, 25 November 2009
Topic: Stable Dependencies Principle
Introduction
Package Design is a challenging area of Object Oriented Programming (OOP), an important part of Software Engineering. An inefficiently designed system can be a root cause of many problems, thus, it is vital to have a solid understanding of various design approaches. This article discusses Stable Dependencies Principle, one of a few key package design principles that software engineers should be aware of.
Definition of Package
In OOP, a package is one or more classes logically grouped into a single unit. According to [4], "classes often have dependencies on other classes, creating package dependencies relationships." The below principle can interchangeably be applied to small packages of just one class, and to larger ones consisting of multiple classes.
Definition of Instability
First, let's discuss why certain packages are considered stable, and others are not. According to [2], the instability of any package can be calculated using the following formula:
I (instability) = Ce / ( Ca + Ce )
In this formula:
Ce – the number of other modules that our package requires in order to operate correctly. In other words, this is an indicator of package independence.
Ca – the number of packages that can be viewed as “dependents“, i.e., “depend upon classes within the package”. This is an indicator of package responsibility.
Therefore, in order for a package to be completely independent and also stable, it should not be dependent upon other packages.
For example, let’s look at the following component diagram:
The Wheel class in this example is shown to be not dependent on any other module.
Using the above formula:
I(W) = 0 / ( 3 + 0 ) = 0
I(W) has the instability of zero. In other words, even though the Wheel class is “responsible” for three classes (Ca=3), it is not dependent upon any of them (Ce = 0), thus resulting in a stable package.
Respectively, instable or irresponsible packages would have the instability of 1, as shown below:
In this case, the Car class does not have any dependent classes (Ca = 0), yet itself depends upon three classes – Wheel, Engine, and Suspension (Ce = 3).
Let’s calculate the instability of the Car package:
I(C) = 3 / ( 0 + 3 ) = 3 / 3 = 1
The instability of 1 indicates a high level of volatility of the Car module.
Stable Dependencies Principle
The Stable Dependencies Principle (SDP) states that “a package should always depend upon packages that are more stable than it is.” Ideally, the direction of dependencies should go from high volatile to more stable packages.
So how do we know whether a certain component design follows the SDP? Let's look at another example. The following is a more complex diagram outlining several Car components and their sub-components:
The instability of each of the modules would be calculated as follows:
I(C) = 3 / (0 + 3) = 1 (the least stable) I(W) = 2 / (1 + 2) = 0.66 I(E) = 2 / (1 + 2) = 0.66 I(Su) = 1 / (1 + 1) = 0.5 I(T) = 0 / (1 + 0) = 0 (the most stable) I(R) = 0 / (1 + 0) = 0 I(Cyl) = 0 / (1 + 0) = 0 I(O) = 0 / (1 + 0) = 0 I(St) = 0 / (1 + 0) = 0
After replacing each class with its corresponding instability value, the diagram would look as shown below:
In general, lower values result in more stable packages. In our case, all dependencies progress in the direction of stability, thus, according to the SDP, our design is proven to be effective.
Another important consideration when it comes to stability is that more stable packages should not be changed often. On the other hand, a highly volatile class can be changed easily, without affecting other packages in the system.
Conclusion
To summarize, the SDP is one of several package design principles. It helps design "systems with a high degree of reusability and testability" [1]. The principle states that "a package should always depend upon packages that are more stable than it is," and this article demonstrates methods to identify which packages are more stable than others.
Links
[1] The Tipping Point: Stability and Instability in OO Design, http://www.ddj.com/architect/184415285
[2] On Package Design, https://prof.hti.bfh.ch/fileadmin/home/due1/uml_dp/udp_package_design_200906.pdf
[3] What Makes A Good Object-Oriented Design?, http://ootips.org/ood-principles.html
[4] Principles of Package Design, http://nandokakimoto.wordpress.com/2009/05/15/principles-of-package-design/
[5] Stability, http://www.objectmentor.com/resources/articles/stability.pdf