5.1 Object repository
The heart of the MetaEdit+ environment is the Object
Repository
. It is located on a server, or in the case of
a single user version of MetaEdit+ on a local disk. Alternatively, if your
computer can access a network drive, the repository can be located there,
allowing distance work and a measure of non-simultaneous data sharing: for the
latter each user must of course have a MetaEdit+ licence.
All information in MetaEdit+ is stored in the Object
Repository, including methods, diagrams, matrices, objects, properties, and even
font selections. Hence, modification of system designs (or even methods) in one
tool or MetaEdit+ client is automatically reflected everywhere it appears,
guaranteeing consistent and up to date information. Similarly, reporting and
code generation are based directly on the information stored in the repository.
Only temporary data such as which windows are open and where, which varies
between users and platforms and thus cannot be shared, is not stored.
5.1.1 Repository operations
The Object Repository itself is designed to be mostly
invisible to users. Basically the user accesses it only through the tools of
MetaEdit+. Hence, if you create objects with any of the tools they will be
automatically stored into the repository and you do not need to consider
repository operations.
The use of the repository is visible only when MetaEdit+
is started, when you open and close projects, when you want to commit or abandon
a
set of changes to your models, and when you exit
MetaEdit+.
Opening the repository and starting MetaEdit+
When you start MetaEdit+, the first thing to do is to log in
by pressing the login button in the Startup Launcher
(
Figure 5-1).

Figure 5-1. Startup Launcher.
Select your repository from
the list (
Figure 5-2). Initially you
will probably be interested in browsing the example graphs supplied by MetaCase
Consulting with the methods, so select the ‘demo’ repository. The
‘db’ repository delivered in the installation package does not
include any example models.

Figure 5-2. Choose a repository.
Next you will be prompted
for your name and password as in
Figure 5-3. You may also need to enter
some path information: see the separate Installation Sheet for
details.

Figure 5-3. Entering user name and password.
A successful
login will automatically open the main MetaEdit+ Launcher
showing repository operations. If the login fails you probably need to change
the path information as described later on in this section.
Opening projects
You will then be asked which project you want to open: If you
logged in the ‘demo’ repository select ‘Examples’.
Opening this project may take a little while, because whilst the project itself
is small, it contains models from many methods and must read the metamodels for
each method: the background in the Launcher will be red whilst the open
operation is in progress, and turn green when you can proceed.
When the selected projects have been opened, MetaEdit+
will ask you to choose a default project. The default project defines in which
project new graphs will be stored.
A repository is composed of
projects
, each of which contains a set of graphs that
describe a particular system, and possibly some metamodels. On a lower level,
each project exists as an
area in the repository. If a project is opened
that contains models but not their metamodels, the area of those metamodels will
be opened quietly in the background, so that the metamodels from the other
project are available, but that other project is not considered as being open,
e.g. its graphs are not visible in browsers. When opening projects, such a
project is shown in the list with an asterisk ‘*’.
Example projects are called ‘Examples’ and
‘Tutorial’. You can later create your own projects via the Launcher
or the browsers.
Saving your work
The
Commit and
Abandon buttons in the launcher
(
Figure 5-4) or menu selections
Repository | Commit and
Repository | Abandon... accept or reject
the work you have done, allowing you to undo all operations back to the last
commit. Therefore, you can choose how often you want to store design
information. As these operations may taken some time for larger projects, the
Launcher will again be red until they are finished: the various stages of commit
can be followed in the Repository Transcript. The times depend on the amount of
data loaded, and the amount of new or changed data.
In the multi-user version, commit and abandon also release
any locks that are no longer needed, and retrieve the latest data from the
repository.

Figure 5-4. Commit and abandon buttons in the Launcher.
Exiting MetaEdit+
When you exit MetaEdit+ normally, it commits your current
transaction and logs you out (Repository | Exit...). This is the safest
way to exit, as all your changes are written to the repository. However, commit
and start-up after this kind of exit can take some time, thus MetaEdit+ allows
you to save the current state of your transaction to a new image without
committing it, which is much faster (Repository | Long Transaction...).
Saving the image takes around 10 seconds, and starting that image takes around
20 seconds, after which you are in exactly the same state as when you saved.
When you re-enter a saved ‘long transaction’ image, you will be
prompted for your user name and password for security.
To maintain your original ‘clean’ *.im image
file, you should not save a long transaction image over it, but rather give it a
different name. You should then bear in mind that you should supply the new
image name as a command line argument when starting MetaEdit+, in place of the
original image file. Note also that when you exit in this way with a single-user
version of MetaEdit+, nobody else can access the Object Repository, because your
transaction there is still open: you are still logged in. The repository also
remembers from which image you were logged in, thus a given user can not log in
with the original image if he also has a long transaction open in the
repository.
Each long transaction
image can
only be used once. After you have logged in with that image and committed or
abandoned a transaction, that image will no longer be usable, and should be
deleted. If you wish, you can however exit again with a ‘Long
Transaction’ exit and save the image over the previous long transaction
image. Remember, thought, that your changes are only written to the database
when you commit.
A useful technique in the single user version is to commit
your transaction, then exit with Repository | Long Transaction.... This
ensures that all your changes are safely stored in the repository, but allows
you to start up MetaEdit+ faster next time, as the saved long transaction image
already contains the data you were working with.
Emergency exit
MetaEdit+ also has an operation called emergency exit, which
exits from the Object Repository without saving the work done since the last
commit, and closes MetaEdit+. To use emergency exit keep the shift key pressed
when exiting, either with
Repository | Exit... or by closing the
Launcher.
Change of repository location
Each client knows the location of the repository from the
Roots file called
‘artbase.roo
’. This
file includes information about the available repositories: their names and
directories.
In a single user version of MetaEdit+ the Roots file is
normally located in the same directory as the executable and image files of
MetaEdit+. The production repository itself is located by default in a
sub-directory of the MetaEdit+ directory called ‘db’ and the
evaluation repository, which includes the examples, in a sub-directory called
‘demo’.
With a multi-user repository there are two options: Either
each client has its own Roots file or they use a common Roots file located in a
shared directory on the server. In the latter case, the working directory of
both client and server programs should be the directory on the server where the
common Roots file is located: the repository will then be located in a
sub-directory of that directory. Basically, if all clients use same repository
the management of repository and its location becomes easier if only one Roots
file is used. Conversely, if clients use different repositories then each client
should have his own Roots file.
The location information of the Roots file is managed from
the Startup Launcher illustrated in
Figure 5-5. The
Roots Filename
button opens a dialog (
Figure 5-6) for
entering the directory and file name information from which the Roots file will
be used. By default the Roots filename locates at the working directory.

Figure 5-5. Startup Launcher.
The first line of the dialog
contains the directory information for the Roots file.

Figure 5-6. Entering location of the Roots file.
The
Roots Browser
button opens the editing tool for the
names and directories of repositories.
Figure 5-7 below shows an example of the
editor for changing, adding and removing repositories and directory
information.

Figure 5-7. Roots browser.
Information about new
repositories can be added, renamed, and removed from the pop-up menu of the
repository list. Changes to the repository list must be explicitly saved (choose
save from the pop-up menu) to store the information into the roots file.
The Roots Browser can be closed as any other window on your platform: it will
warn you if you have made changes and not saved
them.
5.1.2 Repository tools
MetaEdit+ also includes tools for managing the repository.
Some of the tools are available only when you log in as System Administrator,
others are available to any user, and are accessed through the
Repository |
Options menu in the Launcher. For more detailed description of the
repository operations see the MetaEdit+ System Administrator’s
Guide.
5.1.3 Multi-user functions
MetaEdit+ automates all the functionality connected with
supporting multiple users: it is perfectly possible to use it without knowing
anything of the underlying principles. Users, however, are generally more
curious than that, and an understanding of a few of the basics of the multi-user
functionality will enable them to use MetaEdit+ more effectively, and give them
a better sense of being in control.
There are three basic concepts which we will use in our
explanations: session, transaction, and lock.
Sessions
In MetaEdit+ a session
is defined as
the time from when a user logs in to the repository to when he logs out. As a
rough guide, a session would normally last for a work day or some part of a day,
and is generally the same as the time for which the user is running MetaEdit+.
If a user wants, he can however exit MetaEdit+ without ending his session
— more about this later. Each session is composed of one or more
transactions.
Transactions
As a term, transaction
may be familiar
to users of older style databases, where it basically represents an atomic unit
of work. In MetaEdit+ there are some differences, but the basic understanding
remains the same. As far as other users are concerned, your transaction is an
atomic unit of work: until you end your transaction, they cannot see any of the
work you have done during that transaction. You end a transaction either
explicitly by
committing it or by logging out.
Because your changes are not visible to other users until
you commit them, transactions provide a measure of atomicity: people do not get
to see your work until you are ready for them to see it. Transactions also
provide a measure of undo functionality: if you decide that you have taken a
wrong turning in your design work during a transaction, you can abandon
that transaction. All the changes you made during that transaction will be
thrown away and not written to the repository, and you will start a new
transaction in the same way as for commit.
Locks
In the everyday world, a person locks something if he wants to
prevent others from manipulating it or removing it. A
lock
will prevent changes — your bike wheel
disappearing, or your house being damaged — but in general will not
prevent others seeing something (they can look at your bike, or peer in through
your windows). The situation is in many ways similar in MetaEdit+, but here the
main aim is to prevent two people making changes to the same information, rather
than directly destructive acts. Thus if another user has locked something, you
can still look at it, but you cannot change it.
When you change a piece of information in MetaEdit+, that
piece of information will first be locked, and only if that lock was successful
will your change be allowed. A lock is successful if nobody else has held a lock
on that piece of information in a transaction which overlaps with
yours.
 | By
keeping shift pressed while opening a graph or property dialog you can open it
without locking it. This is especially useful in a multi-user environment when
you just want to view the graph or properties and allow another user to change
them at the same time. |
Sessions in use
Above we introduced the idea of a repository session —
the time for which a user is logged in to the repository. From a user’s
point of view there is another kind of session, which we could call a MetaEdit+
session. This is the time for which a MetaEdit+ client is running on the
user’s computer. Normally these two sessions will be identical, but to
enable certain ways of working MetaEdit+ allows one exception to the rule.
A user may decide to close his MetaEdit+ client but to
save the whole current state of MetaEdit+, including all information read from
the repository, into a special
image file. He can
then later start up MetaEdit+ again with that image file, and be immediately
returned to the same state as he was when he closed MetaEdit+: the same
transaction, open windows etc. As he is still in the same transaction, this
procedure is called a long transaction
.
The operations of saving and exiting, and of restarting
the saved image, are very fast and can be used to good effect in for instance
the following situations:
 | At
the end of a day a user may have only partially completed a large piece of work,
and not want the half-finished results released to the other users
yet. |
 | A
user may want to exit MetaEdit+ quickly, and not have the time to logout in the
normal
way. |
 | A
user may have many windows open, all arranged in a way that is effective for his
current task, and may not want to have to open them all again the next time he
logs in. |
When a user saves and exits
MetaEdit+, although MetaEdit+ is closed the user is still logged in to the
repository, and his current transaction is still open in the repository, neither
committed nor abandoned. Thus when he restarts MetaEdit+ with the saved image
file, he will still be in the same transaction, with information read from the
state of the repository at the start of that transaction.
Such an image file may only be used once: after
being restarted, that particular image file must be deleted or overwritten (by
saving another image file to the same file name). This is because the image file
contains information from the repository and is logged in at a particular state
of a particular transaction. The original MetaEdit+ image file which you use in
a normal session can be started as many times as you like, because that image
does not contain information from the repository, nor is it logged in.
Transactions in use
The normal length for a transaction
will depend largely on the way of working in an organisation. If there is a need
for very fast updates of information between different designers, transactions
may last from half an hour to an hour. Where such rapid updating is not
necessary, users can reduce the overhead of ending and starting transactions by
using transactions of a day or even longer. To help decide how best to use
transactions we lay out some of the basics in the next few paragraphs.
At the start of each session, when a user logs in to the
repository, a transaction is started for that user. The repository will remember
its state at that instant, and throughout the transaction the repository will
provide information as it was at the instant the transaction was started.
Similarly, none of the changes the user makes to the information in the
repository will be visible to other users until the user ends his transaction by
committing it. At that point all his changes will be written to the
repository, and will then be available to other users, but only ready by them
when they next start a transaction (remember that their current transactions
will still be using the information available from the time they were
started).
Thus for one user’s changes to be visible to another
user, the first user must commit his transaction, and the second user must start
a new transaction after that, either by ending his transaction (and thus
starting a new transaction) or by logging in (if he is not already).
To summarise: the situation is as if you read from the
repository only at the start of a transaction, and write to the repository only
at the end of a transaction.
Locks in use
In MetaEdit+, locks
are used
differently depending on the kind of information and the current circumstances.
Here we explain the types of locks and the different locking strategies in use
in MetaEdit+.
There are two types of lock in MetaEdit+, transaction
locks and session locks. A transaction lock is released (the information is
unlocked) at the end of the current transaction, releasing it for other users. A
session lock persists over into each new transaction, until the information is
unlocked by some other action. For instance, graphs are session locked while
they are open in an editor, and the session lock is only released when the user
closes the editor.
The interval between your lock and your change varies with
different kinds of information: most often it is negligible, but with some
information, particularly graphs, locks are taken when you first open the graph,
even though you may not change it immediately, or indeed at all.
5.1.4 Locks and the user-interface
These different types of lock and locking strategies are
designed to reflect the normal pattern of CASE usage, to give the most efficient
and invisible support.
Starting and ending sessions and transactions are actions
that are explicitly carried out by the user. Locking, on the other hand, is
performed automatically by MetaEdit+ on behalf of the user, based on the
user’s actions. Why this distinction? Virtually every action in MetaEdit+
requires some kind of locking operation or check, and the burden on the user of
manually setting and releasing the locks would be huge. In addition, the safety
of the work done in a transaction depends on the correct locks being obtained at
the correct times: any mistake, and the transaction will probably be unable to
commit because of conflicting changes with another user.
Types of data
For our purposes, we can divide data in MetaEdit+ into three
kinds:
 | conceptual
graphs |
 | representational
graphs and their
elements |
 | conceptual
objects, relationships, roles and properties |
A
representational graph is a diagram, matrix or table. A conceptual graph is the
‘real’ data that underlies that representational graph: a conceptual
graph may have several different representations. Information stored by a
representational graph and its elements includes the positions of individual
symbols, the order of items on an axis in a matrix, and the widths of the
columns in a table. Correspondingly a conceptual graph stores information about
which objects belong to the graph, how they are connected together via
relationships, and what other graphs they explode to.
Locks in editors
These first two types of data are session locked in connection
with opening an editor on a representational graph. MetaEdit+ will automatically
try to obtain locks both for the representational graph, and for the underlying
conceptual graph. The success of these locks determines which actions the user
may perform in that editor: if one or both locks fail, the editor will still
open, but some of the menu items will be greyed, and other e.g. mouse operations
may have no effect. You can view lock information in editors through Info Tool
(
Graph | Graph Info).
For instance, if a diagram is opened and locked
successfully, but the conceptual graph is not able to be locked, the user will
be able to move symbols around in the diagram, but not be able to add new
objects or relationships to the graph. He will however be able to add a symbol
for an object that already exists in the conceptual graph (shift-click), or show
a relationship that already exists there (Add existing connection...). If
neither lock was obtained, the user’s actions will be restricted to
scrolling, zooming, viewing selected types, and editing the properties of the
objects etc. in the graph.
For as long as the editor remains open, the user will keep
the locks he initially obtained on opening it. If he wants to relinquish the
locks, or to try to gain more locks, he should close and reopen the editor on
that representation graph.
Short-lived locks
Whilst locks
in editors are generally
held for a while, maybe over several transactions (session locks), other locks
in MetaEdit+ are often held only for a few seconds (although their effects will
be felt by other users throughout any transaction overlapping the one where
these were locked). These are the transaction locks on individual objects,
relationships, and roles, and on their individual properties.
The most common use of such locks is in property dialogs.
When a user opens a dialog on an object’s properties, MetaEdit+ attempts
to lock all that object’s properties, so they can be changed. If one or
more of the locks fail, then no locks are taken, and the user can only view the
properties in the property dialog: the OK button will be greyed. If all
locks were obtained, the user will be able to press the OK button to
accept his changes, and the locks will be released then.
Similar short-lived locks are taken in various other
circumstances, often so that their success is not noted in any particular way,
but a failure to obtain a lock will be shown to the user as a warning dialog. In
general these warnings are no real cause for concern, and the user will be able
to continue working as normal.
Locks and creating new graphs
When a user creates a new graph, it is automatically added to
the collection of graphs owned by the current default project. This collection
is of course also used by other users, and so changes to it by two users in
overlapping transactions would normally not be possible. MetaEdit+ uses a
special locking strategy for these collections, though, which normally allows
many users to add to them simultaneously. Under certain circumstances however it
may happen that the collection is locked so that a user cannot create a new
graph in that project.
As with other locking problems, the solution is to have
the other user whose lock conflicts with yours commit their transaction, and
then for you to commit your transaction. In that way you will see the new graph
the other user created, and also be able to lock the collection to add your new
graph.