Up Previous Next Title Page Index Contents

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.

Up Previous Next Title Page Index Contents