The objective is to develop a discovery-oriented network robot that is useful for maintaining a web site and testing a network. The source code will be freely distributed to encourage further development via the Internet.

We also use this project to customize Fusion, an object-oriented development method. We begin with the text then add both our experience in using it and our exposure to other OOD methods. Eventually, we will integrate it with our overall process of creating a customer.

We refer to three versions of the method: Fusion (from the classic text), Fusion++ (H-P's latest version; a book is still forthcoming), and eFusion (our extended version -- and a homophonous description of this text).

Unfortunately, the analysis phase did not show this project to be object-oriented enough to justify further OOD. We have abandoned it and will apply eFusion elsewhere.

The objective is to develop a discovery-oriented network robot that is useful in the process of maintaining a web site. The initial requirements are:

• a network robot that explores a URL:
  • verifying links
  • copying pages (locally or remotely)
  • stress testing the server
  • stress testing the network (SNMP?)

Development Methodology

Our approach to satisfying the Customer's requirements -- as well as the end-user's -- is eFusion. All of eFusion is divided into three parts: analysis, design, and implementation. There is no formal requirements phase. The initial requirements are submitted as a natural language document emphasizing what the system does. They do not have to be complete since our development process is customer-driven throughout. Therefore, we have:

1. Analysis
   1. a specification of what the system does
   2. result: formalized requirements, verified to avoid errors (especially crucial at the early stage of development); delivered as part of an "initial study"
2. Design
   1. choosing how the system operations are performed by interacting objects (to satisfy the analysis)
   2. result: an object-oriented architecture of the system
3. Implementation
   1. coding, profiling, review (inspection and testing)
   2. result: a coded solution that satisfies the requirements

Fusion draws upon "formal methods" to check for completeness and consistency at the end of each phase: testing is built in. We also conduct an Extended Review that results in a deliverable system, but that is outside the scope of this text. (Fusion++ has a Requirements phase involving "use cases" and inserts an Architecture phase between Analysis and Design, which seems intended for large, complex systems.) We observe that eFusion provides a direct route from a requirements definition through to a programming language implementation. Its systematic approach not only provides the traditional benefits of a method but also enhances the strengths and shores up the weaknesses of object-oriented programming.

Study Case

To better illustrate eFusion, we will use it in Project SLAMbot. We have already gathered the initial requirements from the Customer (i.e, us) in a "what list". Our initial development will concentrate on the first two aspects since the notion of "stress testing" is not very clear. This will still give us a useful robot, and we can add "stress testing" in the next iteration. (We hope to gain a better understanding of how to facilitate iterative development; ironically, we cannot stress this enough.)

Thus, the Customer has a process need, and we have a problem to solve. Now the challenge is to propose a solution in terms of an object-based model: develop a model of the problem and find a solution using a computer.

Brainstorming

The first step towards developing the model is to identify candidates for classes and relationships from the requirements. Class candidates are important nouns, and sources of relationships include verbs of communication, association, containment, and action. These are recorded in a project dictionary, a central repository of terms, concepts, and their definitions. The dictionary plays a central role in cross-checking the model for completeness and consistency, and it is updated throughout the process.

During this "brainstorming", it helps to consider the user interface and ask, What other requirements are needed to achieve the Customer's goals? A simple sketch and some user feedback should prove enlightening. We pattern the robot's initial GUI after the "what list".

In all this, we discover that the robot has some implied requirements:

• report the status of the URL
• filter a page to get more URLs
• fetch/copy a page
• recurse according to "exploration options" set by user
• label new URLs as descendant, family, neighbor, or outsider

and add these to the project dictionary.

Now we are ready to develop the object-based model. Just as an object has data and behavior, the system has structure and behavior; and this step in the Analysis phase reflects that:

1. brainstorming:
   1. begin project dictionary
   2. sketch GUI
2. develop the object-based model:
   1. describe system structure
   2. describe system behavior
3. check all models according to exit criteria

System Structure

To describe system structure, we diagram object models, graphical representations of the classes and their relationships. Presently, this project has only one. It also shows cardinalities (the numbers involved; "one" is assumed if none given), conditions (invariants and predicates), and attributes. However, it does not show temporal order or data flow: the model is not procedural; instead, it reflects the static structure of the information in the system.

(The object models should be inspected for mutual consistency and completeness against the requirements, but do not try to get them perfect now: they will change as the analysis progresses. While there are definite steps, analysis is iterative and incremental because decisions are continually subject to review and revision as all the implications of the requirements become clear.)

System Behavior

With a working description of the system structure behind us, we are ready to describe its behavior. The system interface model defines the input and output communication of the system. This is not the internal messaging between objects; the focus here is on agents, active entities that communicate via events. (Note that agents should not be confused with objects, nor events with relationships.) The system itself is an agent, and the events it receives are system operations, which can change its state and cause the output of other events.

The system operations (input) and their events (output) comprise the interface of the system. The other agents comprise its environment; if these agents are not truly outside the system, the system does not interact with its environment and is a simulation. The system interface is also useful for dealing with concurrency, in which the agents are concurrent processes that need to have compatible interfaces.

To develop the system interface model, identify agents from the requirements, and then collect what events (typically phrases describing what_action_is_desired) are involved and identify those which are system operations. All are entered in the project dictionary and shown in an agent collaboration model.

These findings are then used in the two parts of the system interface model: the operation model and the life-cycle model. The operation model characterizes the effect of each system operation: the state changes it causes and the output events it sends. It is expressed as a series of schemata, with each schema of the form:

Operation:	(name)
Description:	(text)
-------------------------------------------------
Reads:		(items)
Changes:	(items)
Sends:		(agents & events)
Assumes:	(pre-conditions)
Result:		(post-conditions)

The operation model uses the object model as a visual aid to its development. The emphasis is still on what the system operations do to the system. Therefore, the model does not specify the intermediate states of the system during the operation, for such states are dependent on the implementation details. There is no flow control.

The second part of the system interface model is the life-cycle model. Its pseudocode groups the system operations and events and proposes a sequence for each "scenario" of agent collaboration. This will make it useful as a guide for implementation, which is more convenient when it is event-driven.

Checks

The final step in the Analysis phase is checking the models. They must be complete and consistent in order to be good enough for the Design phase. The text lists three sets of exit criteria on p. 60:

1. completeness against requirements
2. simple consistency
3. semantic consistency

In summary, the Analysis phase of eFusion follows:

1. brainstorming:
   1. begin project dictionary
   2. sketch GUI
2. develop the object-based model:
   1. describe system structure:
      • object model(s)
   2. describe system behavior:
      • agent collaboration model
      • system interface models: operation model and life-cycle model
3. check all models according to exit criteria

This outline clarifies Fusion's approach and simplifies its steps toward describing system behavior. The work products of the phase formalize the requirements and specify what the system does. With the exit criteria met, the Design phase can begin.

Unfortunately, this particular project does not seem object-oriented enough to justify further OOD.

Object-Oriented Development, The Fusion Method, Derek Coleman et al. (1994; ISBN: 0-13-338823-9)

other methods: limited to "Java as a Second Language" notes, the 1994 NEXTSTEP East Coast Developer Conference tutorials (which contain some useful suggestions for requirements gathering), and various texts browsed at random

Last modified: 7/11/98