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!
