Collaborative Model Development

Cradle supports the smallest to the largest of projects. Large projects have large models, and Cradle supports these with its concurrent model development aids.

Many tools are intrinsically single-user for each model. They may create an in-memory image of the entire model that is RW to just one user. Any other user wanting to work in this model, or a related model, is blocked or has to copy the model and make changes in that instance.

These multiple personal models must then be committed to the central database and the inevitable conflicts and inconsistencies can take days or weeks to resolve.

Concurrency Support

Cradle eliminates such problems by providing full concurrent access by all users to all parts of the models, requirements sets and other information. This means that each user can work RW in any part(s) of any model(s) concurrently with all other users, subject only to his/her access rights to individual model items.

So a user can access a particular diagram RW and work in it even if another user is currently editing that diagram’s:

• Parent diagram
• Equivalent specification (use case, function…)
• Child diagram(s)
• Child specifications (classes, functions, architecture components…)

This allows maximum concurrency for the modelling effort, and ensures that all parts of the models are available to all users at all times in their most current form.

Model Partitioning

There are different approaches for creating models:

• Diagrams first and specifications afterwards
• Specifications first, grouped into a hierarchy and loaded into diagrams
• Top-down
• Bottom-up
• Middle-out

For any approach, a key decision is whether the model is to be partitioned, and if so, the basis for this partitioning.

Partitioning a model is essentially dividing it into parts and assigning these parts to different users. The reason this is important is to help ensure that every user has access to all of the information that he/she needs, and that this can be accessed RW if needed.

When deciding on the basis for the partitioning, recall that:

• Every diagram has, or can have, an equivalent specification
• Nearly every diagram symbol has, or can have, a definition as one or more of:
  • A data definition
  • A child diagram
  • A specification

A typical partitioning would assign different subtrees to individual users or groups:

Alternatively, different levels could be assigned to individual users or groups:

Similar approaches can apply when there are multiple models to be considered.

Access Controls for Partitions

The users responsible for a partition need RW access to its items, and the right to create new diagrams and specifications. This can be achieved by either:

The users own the items in that partition. Each user has RW access to items owned by their colleagues. The users would be in a single team.

The users being given RW access to the items, which are owned by someone else

3SL recommends the first approach, where users own the diagrams and specifications in the partition, and have the following privileges set in their user profiles:

1. CREATE_ITEM, so they can create new model elements
2. CREATE_XREF, so they can create new cross references for new parts of the model
3. TEAM_USER_RW, so they have RW access to their colleagues’ items in the partition