Types in EVA Netmodeler
A type in EVA Netmodeler is a definition of a kind of knowledge structure or concept that you want to manage. Each type will have a unique name, set of named properties, legal relationships in which it can participate, and
images by which it will be identified in displays. Types are defined in the Type Browser.
An example of a type might be:
Type Name
|
Document
|
|
Type Documentation
|
A document in electronic form. Can be from word processor, spreadsheet, presentation package or many other sources.
|
|
Type Image
|
localhost//Archi/images/Document.gif
|
|
Large Type Image
|
localhost//Archi/images/DocumentLarge.gif
|
|
Legal Relationships
|
authored by categorised by hardcopy filed at
|
Person DocumentStatus Location
|
Named Properties
|
Title Document Path Date Received
|
String ArchiHotLink ArchiDate
|
A unique feature of EVA Netmodeler is that as soon as a type is defined, it will be accessible and usable in the system in all the item related browsers. Types can be extended after items are created.
Type Definition Elements
Type Name
|
Should be unique. Identifies the type to the system. Should be short, descriptive and easy to work with for users. Typically comprises nouns and adjectives. Do
not use a "code" - Archi will create a unique type ID for every type anyway. Examples: "Business Unit"; "Market"; "Job Category"
|
Documentation
|
A description of the type (in text or well formed HTML) to display to the user when the icon representing the type is clicked in a browser. This is normally used
to provide a definition of the type and other helpful information, such as how the designer saw it being used, related types etc. It is useful to others who will use or modify the meta model and is
displayed in the type browser when a type name is selected. It can also be output to the meta model report. Here is an example.
|
Select List Order By
|
This selects a property to display in selection lists for users to identify and select items of the type. The default is to use the item ID. You may choose
another property here, for example, the name. It is best to choose properties that are likely to be unique.
|
Type Image
|
This is a reference to a browser friendly image which will represent the type in other browsers. We recommend a 24 x 24 non-transparent GIF format image. Here is
an example:
These images are held in a directory on the server where Archi
resides. If your image is not yet there, it can be uploaded via the Upload Images utility, available to authorised users from the system menu.
|
Large Type Image
|
This is a reference to a browser friendly image which will be used to represent the type in displays where large image sizes are requested. We recommend a 64x64
GIF image. Here is an example:

These images are held in a directory on the server where Archi resides. If your image is not yet there, it can be uploaded via the Upload Image utility from the system menu.
|
Legal Relationships
|
These represent the relationships that items of this type can have with items of other (or for that matter, the same) type. For example, the type "Business
Unit" may legally have a relationship of "Markets" with the type "Product". This would mean that a business unit, say "Retail" could be related to a number of products (e.g.
Cellular Phone, Starter Pack, Accessory Kit) in the sense that it "Markets" them. All relationships within Archie are bi-directional - i.e. They have inverse relationships. In the example above, the
inverse would be that a "Product" is "Marketed by" a "Business Unit". When we associate a legal relationship type with a source and a target type, we only need specify one side of
the relationship, the other will be automatically inferred.
|
Legal Attributes
|
These are properties that we want to keep within the Archi repository for each item of this type. In system terms you could think of them as data items within a
record, or properties of an object. In relational database terms you might think of the type as representing a table and the legal attributes as being column names. In a business sense, you could think of the
attributes as properties that describe the type of object being defined, much as the items on a form would describe something. E.g. A "Customer" form might have areas to write the Name, Address,
Telephone number etc.
|
|