Using Lava for object-oriented analysis and design

Lava supports a highly incremental programming style with successive completion and modification of initially very coarse and preliminary declarations that may require major revisions and restructuring later:

• You can start by defining just a few object classes (= Lava classes) having a few primary methods.
• You need not yet assign attributes (= member variables) to the object classes,
• and you need not (but may) declare formal parameters for the methods.

For instance, the object-oriented essence of a UML "use case" like "bank customer opens new account", which would typically be established in the requirements analysis phase of a new project, can be imitated quite easily and naturally in Lava by declaring three classes "Bank", "Customer" and "Account" and a "CreateAccount" method of "Bank".

You can successively add details (member variables, formal parameters, further classes, partial implementations of functions) just as they come into your head.

You need not interrupt your flow of thoughts and switch to a completely different representation (from "use cases" to "class diagrams", say) just because you want to keep your idea that the CreateAccount method should have an input parameter of type "Customer" and an output parameter of type "Account". You may stay within the same language all the time and add, remove, and change details just as they cross your mind.

Lava provides automatic updates of all existing references if you change the arrangement of declarations in the Lava declaration tree, if you assign a new name to any Lava entity, or if you change the order or number of formal parameters of a function. Therefore it is very inexpensive to make such changes, and this makes it very attractive to use Lava already in the still very instable analysis and design phases of software projects.

It is expensive, however, to move member variables or functions from one class to another one, since they must then be referenced through other (containing) variables, and the parameters of the functions will have to be adapted to the new environment. This cannot easily be performed by an automatic update of references but will require manual changes at all affected places.

Therefore it is very important to arrive at a stable assignment of member variables and functions to containing classes as early as possible. In our opinion this is a strong argument in favor of using an incremental single-language approach like Lava in OO analysis, design and implementation.

Lava provides particular support for the design phase by providing a specialization/override notion for families of related classes that refer to each other and that have overridable type parameters (patterns / virtual types ). They are particularly suited to represent reusable and adaptable design patterns and frameworks on which you may want to build during the design phase.

Additionally we could imagine that the nested tree structure of Lava declarations may be well suited for specifying entire "pattern languages" as tree structures consisting of primary and subordinate ("auxiliary" / "successor") patterns.