Port of schuchert.wikispaces.com


ComponentizationExercisePrintable

ComponentizationExercisePrintable

title: Vancouver_PPP_Exercise_Ch8and9 —

Exercises for Chapters 8 and 9

This exercise is meant to give you a feel for how to organize your classes into releasable components. The end result of this exercise is a listing of classes and interfaces that should all be grouped together to be released.

You’ll work on two exercises:

  • Part 1: After reviewing the Principles of Component Cohesion, we’ll try to extract out a component from the below diagram for a new client of our system.
  • Part 2: After reviewing the Principles of Component Coupling, we’ll evaluate your results, compare them with the starting point and take another swag at componentization.

  • Part 1: Unit 8 Exercise
  • Part 2: Unit 9 Exercise
  • Part 3: Repackaging Exercise

title: PPPChapter8Exercise —

Up

Part 1: Unit 8

The diagram provided describes the dependencies between many of the classes from the project 2 solution. It also shows “components”. The larger box represents the middle-tier as it is released to the UI team. The smaller box represents the all of the UI tier, which is developed by a different team. Review this diagram and look for the following:

  • Are there any “obvious” clusters of heavily related classes?
  • Where are there cycles?

Component cohesion principles

Reuse/Release Equivalency Principle (REP)
What we release is what we reuse. What we reuse is what we release.
Common Closure Principle (CCP)
Everything in a component should be closed in a related manner.
Common Reuse Principle (CRP)
When reusing a component, all or most of the component is used by the releaser.

We have a new opportunity to reduce manual entry of book information. An outside provider has offered a service to electronically register the books it ships (this is how they get new customers). All they ask is a minimal component to allow this to happen. Part of the agreement involves providing a minimal interface to reduce their liability (e.g. if they cannot affect Patrons through the interface they receive, they won’t be liable for unexpected changes to patrons). We have a need to develop a component for this new book provider. This book provider electronically provides book information on all the books they shipped to us once they receive delivery confirmation of a shipment (outside of our concern).

We already have the ability to add books into our system, so we’d prefer to create a component by reusing our existing classes. Our solution should be used by both this new book provider as well as our existing system.

Your task is to review the existing system (represented by the diagram below) and create a component that provides the service that they need but nothing else. Additionally, you’ll need to tie that component back into the existing system. As you “pull out” your component, you might need to decouple things by introducing some form of indirection.

After you’ve had some time to work on this, we’ll discuss it as a group and then learn how to assess the design of your solution.

Up


title: PPPChapter9Exercise —

Up

Part 2: Unit 9

You have been tasked with “reusing” what’s already there. You’ve already pulled out one or more components to support that functionality – catalog maintenance – how does your component measure up?

We just discussed several component coupling principles:

  • Acyclic Dependencies Principle
  • Stable Dependencies Principle
  • Stable Abstractions Principle

We also just learned about several metrics we can use to evaluate our components:

Instability


title: InstabilityFormula —

[I = \frac{C_E}{(C_E + C_A)}]

Where:

Symbol Description Term Mnemonic
\(C_E\) Efferent Coupling Fan Out E in Efferent: Exiting
\(C_E\) Afferent Coupling Fan In A in Afferent Arriving

Abstractness


title: Abstractness —

[A = \frac{N_a}{N}]

Where

Symbol Description
\(N_a\) Number of abstract classes in component
\(N\) Number of classes in component

Distance from Main Sequence


title: DistanceFromMainSequence — (D = | A + I - 1 |)

Where:

[A = Abstractness] [I = Instability]

Original diagram

What are the values for the original diagram?

Middle Tier

\(C_E = 0\)

\[C_A = 7\] \[I = \frac{0}{0+7} = 0\] \[A = \frac{2}{14} = 0.143\] \[D = |0.143 + 0 - 1| = 0.857\]

UI Tier

\[C_E = 7\] \[C_A = 0\] \[I = \frac{7}{7+0} = 1\] \[A = \frac{1}{5} = 0.2\] \[D = |1 + .2 - 1| = 0.2\]

What to do next?

  • Now perform these calculations for your new component configuration. How do you compare?
  • What can you say about the components that have a “large” distance from the main sequence?
  • Knowing what you now know, work through a second round of componentization.

Final Observations

  • What is your experience with doing this kind of work?
  • What tool support have you used or do you see available to assist in this work?
  • Why go to all this trouble?

Up


Comments

" Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.