My Stuff

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox

EclipseCon

March 22 - 25 - Tutorial on Modular Architecture

Tweets @ Twitter

RT I'm looking for good practitioner case study on BPM, speaking opportunity for right case. Takers? Suggestions? #bpm /via @bmichelson 9 hrs ago

"AT&T ... recently notified Sling Media - as well as Apple – that the optimized app can run on its 3G network" <- http://bit.ly/byqkeM #win 3 days ago

Don't get too happy using iPhone location based service primarily for ads...Apple isn't going to let you. http://bit.ly/bFFW9y 3 days ago

RT #lambdalounge will host a great talk by @mstine on Polyglot OSGi tomorrow Thursday Feb. 4th! http://tr.im/LXMz /via @puredanger 5 days ago

The XO-3 concept. If you liked the iPad, you'll dig this. If you didn't like the iPad, you'll dig this! http://bit.ly/4SyeYL 1 week ago

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

Aug '09

13

Modularity by Example

Filed Under Agile, Architecture & Design, Java, OSGi |

There are lots of benefits to modularity, some of which I discussed when introducing modularity patterns. But here’s a simple example, which serves as a prelude to some upcoming posts explaining a few of the patterns.

In the diagram at right (click to enlarge), the top left quadrant shows a sample system with a relatively complex class structure. When change occurs within a single class, shown in red in the bottom left quadrant, understanding the impact of change is difficult. It appears possible that it can propagate to any class dependent on the class highlighted in red. Assessing the impact of change requires that we analyze the complete class structure. The ripple effect appears significant, and change instills fear.

But if the system is modular with classes allocated to these modules, as shown in the bottom right quadrant, then understanding the impact of change can be isolated to a discrete set of modules. And this makes it much easier to identify which modules contain classes that might also change, as shown in the top right quadrant. Change is isolated to classes within modules that are dependent on the module containing the class that is changing.

This is a simple example, but it serves as evidence of the need for modular architecture, and illustrates one reason why modularity is so important. Modularity makes understanding the system easier. It makes maintaining the system easier. And it makes reusing system modules much more likely. As systems grow in size and complexity, it’s imperative that we design more modular software. That means we need a module system for the Java platform. It means that module system shouldn’t be shielded from enterprise developers. And it means we need to understand the patterns that are going to provide the guidance necessary in helping us design more modular software.

Comments

9 Responses to “Modularity by Example”

Thomas Hansen on August 14th, 2009 11:14 am

Howdy, you might have some interest in looking at the Lego Software Process found at; http://legosoftwareprocess.org/ - which describes a collection of patterns and practices that tries to achieve just what your goal seems to be…
Dew Drop – August 14, 2009 | Alvin Ashcraft's Morning Dew on August 14th, 2009 1:09 pm

[...] Modularity by Example (Kirk Knoernschild) [...]
Modularity Pattern - Manage Relationships : Software & Technology @kirkk.com on September 2nd, 2009 3:32 pm

[...] to a specific set of modules, which is not something easily done at the class level. I provided an example of this in a previous post. In the example above, changes to the client module clearly indicate that the impact of change is [...]
Modularity & Architecture : Software & Technology @kirkk.com on September 16th, 2009 4:37 pm

[...] I illustrate this using the simple diagram at right, and it’s what I was referring to in the Eliminate Architecture post when I stated that modularity, in conjunction with design patterns and SOLID principles, represent our best hope to minimize the impact and cost of change. It’s easier to change a design embedded within a module than it is a design that spans modules. I provided a similar example in Modularity by Example. [...]
John O'Hanley on September 17th, 2009 10:32 am

The idea of package-by-feature is closely related to what you are discussing:

http://www.javapractices.com/topic/TopicAction.do?Id=205
Agile Architecture, Lean Principles : Software & Technology @kirkk.com on September 22nd, 2009 7:46 pm

[...] to understand where we need the flexibility. My posts titled Modularity & Architecture and Modularity by Example show visual examples comparing designs that are isolated and insulated to designs that span the [...]
The Use/Reuse Paradox : Software & Technology @kirkk.com on October 7th, 2009 5:08 pm

[...] Modularity by Example - A simple visual example illustrating the benefits of modularity. [...]
OSGi Adoption Increasing? : Software & Technology @kirkk.com on November 10th, 2009 7:32 pm

[...] of overall Java jobs, it’s refreshing to see that folks recognize the benefits of modularity (here’s an example). I can only expect that this graph will continue to trend upward over the next several [...]
Architecture All the Way Down : Software & Technology @kirkk.com on December 15th, 2009 4:42 pm

[...] the service is composed of modules, it’s going to be much easier for me to understand the structure of the service, assess the impact of what’s it’s going to cost to change the service, [...]

Leave a Reply

My Stuff

2010 Conferences