Foundations of ISA – Base paradigm – Scale ISA global

Iteration 2: Step into OO paradigm – State axiom – Part 4

State of Classes

Here is a list of subjects I would like to have a look in the perpective of an incorporation in ISA  :

• Life cycle
• Versionning
• Grouping

I will not speak here of the class level members (static). I have already talked of them in the previous post.

class life cycle

The life cycle of a class is specific. Typically a class may be in one of the following state: Created, Developed, Delivered, Tested, Deployed, Deprecated, Destroyed (not-exhaustive list).

In its life cycle, there are other more specific states: Editing, Not compilable, Compiling, Compiled; Grouped; Reviewed; Versionned; etc.
Except in some proprietary suites, all these states are not or poorly supported. This drives to multiples practices. An Ideal Architecture like ISA cannot miss this issue and must make a response.

The class life cycle takes place in multiple environments. Many transitions occurs when the Class goes from one to another. This transition is usually known as “Deployment”. The Deployment is therefore central to Class life cycle. It is also very often an important organisational jump. Because it relates to “Delivery” of an artifact from one team to another one (to development to integration, to test, to operations, etc.).
Therefore the notion of Deployment, of Delivery, of Artifact and of Environment have to be covered by ISA to support the Class life cycle.

This life cycle occurs in very differents organisations. From the smallest informal individual project, up to the largest inter-state agency. This constraints the solution to be all together simple, generic, flexible, sure, rigorous. It must also be ready to execute with or without customization.

ISA must provide a generalist solution to Class life cycle thru delivery and deployment of artifact over environments.

Versioning

The ascending compatibility is desirable, but is it nice to require that property?  This will limit the Class life capabilities to new features and to internal improvements. On the other hand, it allows any users to take advantages of these changes. To warranty that a new version does not break any existing software, it is a challenge because of the combinatory explosion of the cases. That said, it appears preferable:

• Being able to have several versions of a class to execute side by side.
• That forward compatibility is not required.
• That when the ascending compatibility is supported, this is done explicitly via a migration mechanism.

In this context, Class versioning managment is important to ensure runnability of Objects, in particular those belonging to a version N of a Class running in an environment relying on version N+x of that Class. This suppose that state of object related to Class version have to be incorporated to ISA.
Typical states are: To migrate, Migrating, Migrated. This also suppose that a Class in version N+x must be able to automatically shift an object in Class version N to N+x. If it is not possible to automat that process, the Class can hardly be considered to be the same.

The Class ascendant compatibility is only warranted when it is explicit, otherwise ISA supports side by side runnability.

Another dimension of the Class versioning is about its scope: major, minor, bug fix, internal build number. Experience has shown that making evolve that numbers with accuracy is difficult (think at JDK 1.* and .NET 4.5 for example). So the rule must be simple stupid. The simplest policy is to merge all these scope in a single integer. Then just increment it each time the class has changed from the previous delivery.
Since class version results from human activities, their number cannot be very very high. Having a limited number of version is not an unacceptable constraint. Delivering 3 times a day the same class during 10 years could be defined as an upper limit of 9 000 versions.

The Class version is expressed via a single small integer.

In fact, when speaking of Class life cycle, one speak often about Class Version life cycle.

ISA support Class versioning in an automated manner distinguishing Class and Class Version life cycles.

Grouping

Why grouping classes ? Why not just manipulate classes directly ?
Here are some motivations:

• The Classes in themselves do not address one major subject of software engineering: their delivery
• The class grain is too small to be the eligible to be the delivery unity.
• The OO paradigm does not provide any classes groupement mechanism.
• The reusing a class is of course important, but this grain is too fine when managing a large system with multiple dependencies.
• In the real world, this notion has reappeared several times in many different manners : Library, Application, COM/DCOM, JAR, EAR, WAR, obj, Web Methods Project and Build, Docker container, etc.
  This cannot be a coincidence
• A more general notion that the local Class member access qualifiers is desirable.  Because it depends of the use of the class, not only of the Class by itself.

In accordance with the pragmaticism principle, the need for that kind of grouping feature is obvious, but it should be consistent with the ISA theorical principles.

Therefore, we need a grouping mecanism that also provides features to support the Class life cycle. We must be vigilant that the scope of that assembly does not exceed too much the cluster notion defined by B. Meyer in Object-Oriented Software Construction, page 24:

we may find it convenient for management purposes to group classes into admintrative units, called cluters.

In order to make a trade-off with the B. Meyer unique module / class fusionned principle, the assembly could be just an object with the only supplemental capability to Deliver, with all its consequences. For instance, the (re)usage cannot be made at a finer grain that bypass the assembly notion.

Classes can be grouped in an assembly. The Assembly is the delivery unit. An Assembly is also an object.