Booch Method

Chapter 1. Complexity

Katsuya Amako (KEK)
Version : Jan. 9, 1994

Questions List

Click HERE to go back to the "Main Contents".

1. What are properties of simple and complex software systems?
   
2. Why is software inherently complex?
   
3. What are common to all complex systems?
   
4. How to bring an order to a complex system?
   
5. How to construct a complex software system?
   
6. What is object-oriented analysis and design?
   

• The numbers in the parenthesis found in each question are sections referred to make the answer.
  
• You can go back to the top of the page (Questions List) by clicking each question below.

Q1: What are properties of simple and complex software systems? (Ref: 1.1, p.4)

What the author is interested in is how to develop complex software systems, and not to simple ones. Here simple and complex systems are:

Simple software system

An application that is specified, constructed, maintained, and used by the same person, usually the amateur programmer or the professional developer working in isolation.

Complex software system

An application that is intensely difficult, if not impossible, for the individual developer to comprehend all the subtleties of its design. Stated in blunt terms, the complexity of such systems exceeds the human intellectual capacity.

Q2: Why is software inherently complex? (Ref: 1.1, p.5)

The complexity seems to be an essential property of all large software system. This inherent complexity derives from four elements:

1. The Complexity of the Problem Domain
   
   • The problems we try to solve in software often have myriad of competing, perhaps even contradictory, requirements.
   • A further complication is that the requirements often change during its development, largely because the very existence of a software development project alters the rules of the problem.
2. The Difficulty of Managing the Development Process
   
   • The large amount of work for developing a large software demands that we use a team of developers, and ideally we use as small a team as possible. However, no matter what its size, there are always significant challenges associated with team development.
   • More developers means more complex communication and hence more difficult coordination, particularly if the team is geographically dispersed, as is often the case in very large projects.
   • With a team of developers, the key management challenge is always to maintain a unity and integrity of design.
3. THe Flexibility Possible through Software
   
   • Software offers the ultimate flexibility, so it is possible for a developer to express almost any kind of abstraction. This flexibility turn out to be an incredibly seductive properties. However, it also forces the developers to craft virtually all the primitive building blocks upon which these high-level abstraction stand.
   • As a result, software development remains a labor-intensive business.
4. The Problems of Characterizing the Behavior of Discrete Systems
   
   • Software is in its nature a discrete system, because the state of an application is described by discrete variables and thread of controls. In large system, there is combinatorial explosion that makes the number of states very large.
   • This makes exhaustive testing of the system impossible. Since we have neither the mathematical tools nor the intellectual capacity to model the complete behavior of large discrete systems, we must be content with acceptable levels of confidence regarding their correctness.

Q3: What are common to all complex systems? (Ref: 1.2, p.12)

There are five attributes common to all complex systems:

1. Frequently, complexity takes the form of a hierarchy, whereby a complex system is composed of interrelated subsystems that have in turn their own subsystems, and so on, until lowest of elementary components is reached.
2. The choice of what components in a system are primitive is relatively arbitrary and is largely up to the discretion of the observer of the system.
3. Intracomponet linkages are generally stronger that intercomponent linkages. This fact has the effect of separating the high-frequency dynamics of the components - involving the internal structure of the components - from the low-frequency dynamics - involving interactions among components. This difference between intra- and intercomponent interactions provides a clear separation of concerns among the various parts of a system, making it possible to study each part in relative isolation.
4. Hierarchic systems are usually composed of only a few different kinds of subsystems in various combinations and arrangements. In other words, complex systems have common patterns.
5. A complex system that works in invariably found to have evolved from a simple system that worked.... A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

   Q4: How to bring an order to a complex system? (Ref: 1.3, p.16)

   There are following three ways to dealing with complexity. You can bring an order to complexity by using these.

   1. Decomposition
      When designing a complex system, it is essential to decompose it into smaller and smaller part, each of which we may then refine independently. There is a decomposition which decomposes the system according to the key abstractions (objects) in the problem domain. This is called object-oriented decomposition.
   2. Abstraction
      Unable to master the entirety of a complex object, we choose to ignore its inessential details, dealing instead with the generalized, idealized model of the object.
   3. Hierarchy
      Complexity often takes the form of a hierarchy. It is important to recognize explicitly its hierarchy. There are two kinds of hierarchy.
      1. "part of" ("has a") hierarchy
         An example of this is "an air craft may be studied by decomposing it into its propulsion system, flight-control system, and so on."
         Booch calls this hierarchy "object structure". The reason of this can be found here.
      2. "is a" hierarchy
         An example of this is "a turbofan engine is a specific kind of jet engine, and a Pratt and Whitney TF30 is a specific kind of turbofan engine."
         Booch calls this hierarchy "class structure". The reason of this can be found here.
      The object structure is important because it illustrates how different objects collaborate with one another through patterns of interaction that is called mechanisms. The class structure is equally important , because it highlights common structure and behavior within a system.

   Combining the concept of the class and object structure together with the five attributes of a complex system, Booch says that virtually all complex systems take the same canonical form like this.

   Q5: How to construct a complex software system? (Ref: 1.4, p.23)

   There is no magic, no "silver bullet", that can unfailingly lead the software engineer down the path from requirements to the implementation of a complex software system. In fact, the design of complex software systems does not lend itself at all to cookbook approaches. Rather, the design of such systems involves an incremental and iterative process.

   In every engineering discipline, design encompasses the disciplined approach we use to invent a solution for some problem, thus providing a path from requirements to implementation.

   The products of design are models that enable us to reason about our structures, make trade-offs when requirements conflict, and in general, provide a blueprint for implementation.

   The building of models has a broad acceptance among all engineering disciplines, largely because model building appeals to the principles of decomposition, abstraction, and hierarchy. In order to express all the subtleties of complex system, we must use more than one kind of model.

   Q6: What is object-oriented analysis and design? (Ref: 1.4, p.24)

   Object-oriented analysis and design is the method that leads us to an object-oriented decomposition; object-oriented design defines a notation and process for constructing complex software system, and offers a rich set of logical and physical models with which we may reason about different aspects of the system under consideration.