Methodologies and the GEANT4 Project

The 1st GEANT4 Workshop by Video Conference
Dec. 6, 1994

Katsuya Amako (KEK)

Why do we need a methodology?

Ref. : G. Booch, "Object-Oriented Analysis and Design with Application"

Software is inherently complex:
1. The Complexity of the Problem Domain
  - Users generally find it very hard to give precise expression to their needs in a form that developers can understand.
  - In our project, users are nearly equal to developers. However, still it is true that understanding ourselves clearly what we want (require) to the GEANT4 is not easy.
2. The difficulty of Managing the Development Process
  - It is not unusual to find systems whose size is measured in hundred of thousands, or even millions of lines of code. No one person can ever understand such a system completely.
  - This amount of work 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 project.
  - With a team of developers, the key management challenge is always to maintain a unity and integrity of design.
  - This is exactly the case of our GEANT4 project !!!
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 higher-level abstractions stand.
  - As a result, software development remains a labor-intensive business.
  - We also want to GEANT4 as flexible as possible, but .....
4. The Problem 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 systems, 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.
  - Testing is a serious problem in the GEANT4 project.
When designing a complex software system, it is essential to decompose it into smaller and smaller parts, each of which we may then refine independently.
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 systems, and offers a rich set of logical and physical models with which we may reason about different aspects of the system under consideration.

Is there a "best" design method ?

Ref. : G. Booch, "Object-Oriented Analysis and Design with Application"

There is no absolute answer to this question.
There is no magic, no "silver bullet", that can unfailing lead the software engineer down the path from requirements to the implementation of a complex software system.
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.

Methodologies in the World

Booch's statement is absolutely right. There are variety of OO methodologies available now.

Booch Method
Coad and Yordon Method
Jacobson (OOSE) Method
Martin and Odell (OMW) Method
Rumbaugh (OMT) Method
Shlaer and Mellor Method
Wirfs-Brock (CRC, RDD) Method
Fusion Method

and more are coming, for example,

Booch + Rumbaugh (OOPSLA Conference, Oct. 1994)

and also some of them are evolving.

Then a question is what should we do?

Should we study all of these methods before applying to our project?
Or, should we immediately pick up a particular one?

Similarity in Methods

Essential components in various methods are similar.

Major methodologies consist of the following critical components.

D. E. Monarchi and G.I Puhr: "A Research Typology for Object-Oriented Analysis and Design"
Commun. ACM 35, 9 (Sept. 1992) 35
OOA: Problem Domain Analysis Process
Identification of

semantic class
attributes
behavior
relationship (e.g., generalization, aggregation, association)

Placement of

classes
attributes
behavior
Specification of dynamic behavior
OOD: Solution Domain Design Process

The above three processes for the following kinds of classes:

Interface
Application
Base/Utility

Optimization of classes

OOA/OOD Representations

Static View:

Objects
Attributes
Behavior
Relationship
Generalization
Aggregation
Association
etc.

Dynamic View:

Communication
Control/Timing

Constraints:

On structure (attribute values, relationship cardinalities)
On dynamic behavior
Methodology Proposal for GEANT4
Because essential components in various methodologies are similar, a practical selection for our project is :

to start from a relatively familiar one - in out case, the Rumbaugh methodology,

then, to import appropriate features from other methodologies - mainly Booch and Fusion.
Does the introduction of OOA/OOD really help our project?
From our experience of the "ProdiG" project,

It helps to guide how do we proceed the program design - not straight forward of course,

it helps to identify ourselves where we are in the design process,

it helps to exchange various design ideas by many people,

it helps to summarize the software design.

However, we cannot quantify the above merits.
Do we need to introduce a CASE tool which matches the OOA/OOD?

We don't know how much a CASE tool helps.

From our experience, OMTool is just for the diagram drawing.

However, J. Rumbaugh said in his talk at OOPSLA'94 that:
"I was actually the original designer behind OMTool. I had the feeling that well, fine, other people would use it, but I didn't need it. When I finally had it operational, I find that in fact, I needed it just as much as everybody else. Not only that, but it changed the way I thought. And I think that's what people see when they work with good tools. It doesn't just bring the methodology to life; it actually changes the methodology."

We need some experience on this issue.