3.1 Why is Software Complex?

   

. . . software seems like malleable stuff, most programs are actually intricate plexuses of brittle logic through which data of only the right kind may pass. [1]

W. Waytt Gibbs, "Software's Chronic Crisis"

[1] From "Software's Chronic Crisis," by W. Wyatt Gibbs, Scientific American , September 1994.

Software can be thought of as a machine that has many states, with these states being linked to or triggered by other states. Consider that even the most basic application consisting of a user interface, a bit of hardware, and maybe some data that needs filing can have more possible states than we would care to list. This is why it is possible, even inevitable, to be overrun by our software. Added to this inherent complexity is the perception that creating software is easy, and changing someone else's even easier.

It has been proven that software maintenance is a significant proportion of the total cost of the software. Most programmers hate picking up other people's software more than being asked to do paperwork. The reasons for this are relatively easy to define.

Other peoples software is often:

  • Overly complex.

  • Badly tested .

  • Written in a peculiar style.

  • Poorly documented.

  • Too clever.

On top of that are the reasons we dare not discuss:

  • Changing other people's software is always more problematic than we anticipated

  • It always takes too long

  • We always end up owning the entire application afterward

  • A small change can ripple through the application causing death and destruction in its wake

The last point is interesting and is related to how the many states of the application interact. If our software has many states that are dependent on other states, small changes will propagate themselves throughout the application. This interaction of states is called coupling, a fundamental part of software design, which will be discussed more thoroughly later.

As software engineers we are in the business of managing complexity. So let's all agree on the following:

  • Simplicity is good . . . complexity is bad.

  • Good design simplifies complex problems.

  • Decomposing large complex systems into manageable chunks is an effective method of complexity management. The interfaces to these chunks should be understandable enough to allow them to be used without referring to their implementation.

What weapons can we employ in our battle against complexity?

  • Coupling

  • Cohesion

  • Information hiding

  • Abstraction

The following analogy serves two purposes: it introduces you to the ACME Widget Company and illustrates coupling and cohesion in an example that the majority of the readers will be familiar with.

There are four products made at the ACME widget factory, the ubiquitous Widget, its successor the SuperWidget, the top of the line MegaWidget 2000, and the all new method of measuring widgets, the Widgetometer.

Regarding the factory layout (as seen in Figure 3.1), it can be seen that a product's journey through the shop floor is complex, and the distance traveled by the subassemblies and parts is long. Managing a factory such as this one is complicated because any product, part, or subassembly could be anywhere in the factory.

Figure 3.1. Disorganized factory.

graphics/03fig01.gif

You can think of the factory as a software application, parts going into stores would be input data and shipped products would be output data. The production lines would be top-level components .

Before we improve matters let's define cohesion and coupling and then apply them to the factory layout.


   
Top


A Software Engineering Approach to LabVIEW
A Software Engineering Approach to LabVIEW
ISBN: 0130093653
EAN: 2147483647
Year: 2003
Pages: 66

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net