Software Complexities

Leave a comment

June 1, 2010 by huionn

A work on software engineering by Ivar Jacobson et al. describes software entropy as follows:

“The second law of thermodynamics, in principle, states that a closed system’s disorder cannot be reduced, it can only remain unchanged or increase. A measure of this disorder is entropy. This law also seems plausible for software systems; as a system is modified, its disorder, or entropy, always increases. This is known as software entropy.”

source: http://en.wikipedia.org/wiki/Software_entropy

 

Any intelligent idiot can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.

~ Albert Einstein

Last few weeks, I was reading application codes written with EJB 2 architecture. I read plenty of books criticizing EJB 2 before, but until now only I truly understand one of the key reasons – EJB component model encourages procedural code and discourage good Object-Oriented Design. Inheritance in EJB is either cumbersome (session beans, MDB) or impossible (entity beans). As a result, many powerful techniques of OO are less applicable in EJB 2. As the requirements grow over time, so as the lines of code in the classes…


From a books I read many years ago, there are 4 approaches to manage software complexity (it says 5, but I think the last one is less significant). I summarize them with my experience and other books I read.

LAYER – either architecture-driven layer (presentation, business and persistence layers) or domain-driven layer (decision support, operation and capability layers). Communication between layers is one direction only (presentation can access business layer, but not adverse).

MODULE – either architecture-driven deployable packaged modules or domain-driven package structure. Dependency between modules is kept to minimum explicitly (no hidden coupling and strictly no cyclic coupling).

ENCAPSULATION – the internal states are hidden from client and this facilitates bundling of data with behaviors. Client is insulated from any internal implementation changes.

ABSTRACTION – the client only need to know WHAT will be done which are the essential characteristics of a type. Client is also insulated from different implementations.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: