DT Consulting Newsletter; Issue 6

This edition of the newsletter discusses the issues to be considered when structuring projects in Enterprise Architect.

Approaches to Structuring Enterprise Architect Projects
All projects in Enterprise Architect must have a root and at least one view and there are two main options available for creating a suitable structure which extends this minimal structure.
1) Use the select model(s)s dialog as displayed when creating a new project.
2) Creating a structure by adding views and packages to the root node created for a new project.
The Select Model(s) DialogThe dialog is shown below:
A different set of options is displayed according to the technologies installed. By checking a number of checkboxes and clicking OK a project structure is then created accordingly. For example if “Business Process”, “Requirements”, “Use Case” and “Domain Model” are chosen, then the result project structure is as shown below:
The structure that has been formed is based upon “common practice” and the example above does indeed give a reasonable starting position for modelling.

However, upon closer inspection we find that diagrams and “dummy elements” have also been added to the model, generally these have to be deleted before modelling begins. Some renaming of views/packages is also often necessary.

For small “ad-hoc” projects this approach may work well, but for projects that have to follow a more rigorous structure a different approach is required.

Adding views and packages to the root node
This is achieved by not selecting any checkboxes in the Select Model(s) dialog and adding views to project root, and then adding package structures to each of these views.

This can lead to an inconsistent approach to projects and this method of project structure is usually associated with a framework.

A framework is a prescribe structure for a project, where views/packages have standard consistent names and contain the same specified diagrams/elements for all projects.

Common Frameworks are:

  • Krutchen’s 4 + 1 view (plus the addition of requirements)
  • Zachmann

The last 4 listed above are provided in Enterprise Architect by the addition of MDG Add-Ins, for the moment we will consider Krutchen’s 4+1 view.

Krutchen’s 4+1 View
This is a re-usable framework which is designed for any project for any problem domain. The framework is illustrated below:

As this view does not address requirements specifically, an extra view for this can be added as shown below:

The above gives a consistent, but flexible structure which can be applied to any project.

The Logical View (which addresses structural models), the Process View (which addresses processes such as Business Flows, Transactions and Threads), the Implementation View (which addresses the software solution) and the Deployment View (which address the project deployment variations) can be structured with addition of packages as each project design demands.

The use of formalised frameworks such as TOGAF, Zachmann and MoDAF/DODAF results in more rigid complex project structures as specified by these frameworks. In Enterprise Architect the use of the MDG technology Add-In for these frameworks results in a navigation diagram for easy access to project artefacts.

The MoDAF/DODAF framework in Enterprise Architect is illustrated below:

When a suitable project structure has been created, whether it is based upon a formalised framework or not, it can be applied to all projects in an organisation be the use of an Enterprise Architect Base project.

This Base Project can be used for new projects, or applied retrospectively to restructure existing projects.

The use of Base Projects, Private Models, SharedModels and Design Master Replicas will be the subject of a future Newsletter.

Project Structure and Version Control
Version control is an important issue in modelling systems and how to set up version control (using Subversion) was covered in Newsletter 2.

Enterprise Architect allows version control to be applied at the Project Root/View/Package Level and works by exporting the contents to XMI and adding to the version control repository. When a check-out is requested, the XMI file is imported in the Enterprise Architect project.

Irrespective of the Version Control system in use, Enterprise Architect by default, uses exclusive lock check-out so only the user who has checked out has write access to the items in that section of the project.Because of the exclusive lock check-out, view/package structure becomes very important in Enterprise Architect projects.

The best general advice is:

a) Use a package per diagram and place all elements for the that diagram in this package
b) Use version control at each level of the project hierarchy. This is so structural changes can be made by only one user at a time.

Of course this is not always possible, since elements (particularly classes are re-usable across multiple diagrams). However by judicious use of packages the need to check-out multiple packages to work on a single diagram can be kept to a minimum.

An example of a project structure which illustrates the above is shown below:

In the above, a package per Use Case diagram has been created and this package contains the Use Case diagram and its associated Use Cases. Note also, that the Actors package has itself been subdivided into logical groups.

Organising an Enterprise Architect project is just like organising a hard drive into folders. In a hard drive you would not place all files and applications into one folder; similarly it would be foolish to place all diagrams and elements in a single View in an Enterprise Architect project.

In this newsletter we have discussed the methods available to structure Enterprise Architect projects effectively and also to make those structures reusable across multiple projects.

Previous Next