Implementing a modelling tool on a central repository has certain advantages. It allows the
modellers to share and reuse the elements used for modelling the UML diagrams. For an integrated
enterprise environment, it allows for full trace ability from business to system, system to system
and system to physical implementation.
Rolling out Enterprise Architect for a repository has taught us that some questions should be
considered before the rollout takes place. Once these questions are answered the approach is fairly
simple.
Considerations
When setting up a central repository for Enterprise Architect, the following need to be considered:
1. Are you going to provide for a playpen area?
A playpen allows users to play around and model without fear of contaminating the models. A
playpen is normally either a copy, or a subset of the master model. The playpen is also a very
effective place to test modelling hypotheses and to train new modellers.
2. What backup methods are going to be used?
In a central environment, backups are crucial. If other applications and systems are used on
database implementations the EA database backup may be included in the normal backup runs. If
the database is a standalone, procedures will need to be implemented in order to ensure continuity.
3. What profile conventions and standards are applicable?
Some conventions and standards need to be decided upon before users and profiles are going to
be created. Most organizations have naming standards and conventions around the creation of user-
id's and passwords. You need to decide if the EA user names and passwords need to comply with
this.
4. What configuration control mechanisms are going to be implemented?
The first consideration is to decide whether configuration control is going to be managed via
controlled packages or via centrally controlled packages. There are pro's and con's to both
approaches and a decision needs to be made on the most advantageous approach (See EA user
guide).
If centralized configuration control is the preferred choice, you must determine if software
configuration control application used is compatible with EA (A third-party source-code control
application which provides support the Microsoft Common Source Code Control standard, version
1.1 or higher). If it is, the nature of the configuration control mechanisms needs to be established.
Packages can be controlled at every level. Baselines may be taken at the highest level, or
organized around functional or model areas. Processes and procedures around baselining of work
need to be established and agreed upon.
5. Who is going to administer the environments?
As with any shared environment, an administrator is going to be necessary for the initial setups and
ongoing user administration. This is a fairly lightweight task but must be allocated to someone in
order to run a successful shared environment.
Creating the environment
Step 1. Database space.
It is important to get space allocated on the database of choice. As a guideline with a large
customer we chose to allocate approximately 10MB per modeller. This was based on a model that
was shared between seven modellers that rapidly grew to about 21 MB within the first weeks of
use. The model included among others:
- 360 Packages
- 3594 Elements
- 4620 Connections
- 825 Diagrams
- 3866 Diagram objects
Projections based on this sample model allowed us to calculate for a minimum of 5 MB per single
modeller and allowing another 5 MB growth per modeller over the next year.
Step 2. Create the database and tables
Create a new instance of your database of choice. Using the scripts provided by Sparx Systems,
create the database tables on your new database.
Step 3. Determine users and access roles
The use of a central repository will require the setup of groups and users. A standard profile may
be set up against a group and multiple users can then be allocated against that group. The
allocated users will then inherit the group privileges. Profiles may also be set up against the specific
users.
Compile the list of all users and create them on the repository. Set up some standard groups for a
start and allocate the users against these groups. Over time the roles allocated to the standard
groups can then be extended and changed based on usage experience.
(Note. Please note that security needs to be enabled for the setup of users)
Step 4. Set up any other software on client stations
With some of the databases supported some additional software needs to be set up before the
repository may work.
- Under Oracle, each workstation needs to install the Oracle client and OLE DB provider.
- Under MySQL the appropriate drivers need to be installed on the client machines (see
Sparx Systems installation guidelines)
Step 5. Create the repository model.
By the time that the centralized repository is created, some models already exist. A decision can be
made on whether these models are to be merged into the repository or if the shared model should
be based on a clean slate.
If separate models are to be incorporated into the repository we prefer to merge the models into a
single standalone model before transferring it to the repository. It is also relatively simple to import
and merge the different models directly into the repository.
Your repository should now be ready for shared use!
