|
absolute identifier
|
An absolute identifier is a string of characters associated with each object in the repository. This string is computed using the date and time the session was opened, the number of objects created since the session started, and the object creation date (in milliseconds). An absolute identifier provides a unique way to identify an object in the repository, so that even if the object is renamed, all the links to it are retained.
|
|
access area member
|
Access area member groups all persons and person groups belonging to an access area. This area defines objects that can be accessed by the person or person group.
|
|
access path
|
An access path indicates which folder you can use when creating a reference for an environment database or a site environment. When all repositories are created in the same location as the environment, the path created at installation (the DB folder under the environment root) is sufficient and is given as the default. When you want to save a repository in a folder other than that of the environment, you must declare a new access path.
|
|
access rights
|
User access rights are the rules that manage access to software functions and databases. You can restrict the access rights of a user to the different repositories defined in his/her work environment. You can also restrict what software features a given user can run, such as the descriptor editor, modifying queries, designing report templates (MS Word), deleting objects, dispatching private workspaces, importing command files, managing environments, repositories, users, writing access, etc.
|
|
administration
|
Administration consists of managing the work environment of repository users. This function is usually the responsibility of the administrator. Administration tasks include making backups of repositories, managing conflicts in data shared by several users and providing users with queries, descriptors, report templates (MS Word), etc. common to several projects.
|
|
Administration desktop
|
The HOPEX Administration desktop (Web Front-End) is the Web version of the Administration (Windows Front-End) application accessible via an internet browser. It enables to manage HOPEX users and permissions.
|
|
administrator
|
The administrator is a person who has administration rights to manage sites, environments, repositories and users. In addition to Administrator (who cannot be deleted) and MEGA users, created at installation, you can grant administration rights to other users.
|
|
attribute
|
See Characteristic.
|
|
business role
|
A business role defines a function of a person in a business sense. A person can have several business roles. A business role is specific to a repository.
|
|
characteristic
|
A characteristic is an attribute that describes an object or a link. Example: the Flow-Type characteristic of a message allows you to specify if this message is information, or a material or financial flow. A characteristic can also be called an Attribute.
|
|
command file
|
A command file is a file containing repository update commands. It can be generated by backup or object export (.MGR extension) or by logfile export (.MGL extension).
|
|
comparison
|
You can compare objects in two repositories, creating a file that will modify objects in one repository to make these equivalent to objects in the other repository. This comparison also allows you to list the differences between the contents of the two different objects.
|
|
compilation
|
Compilation is carried out after migration or customization. Compilation checks configuration of the environment concerned. When completed, processing for all users of this environment is speeded up. Metamodel compilation includes in parallel translation in the current language. You can also translate the metamodel into another language.
|
|
consolidation
|
Consolidation groups the updates from stand-alone workstations or remote sites (with Lan) and merges them in a reference site. After dispatch of the private workspaces of each of the users, the repository log is exported and reinitialized. The logfiles are imported into the reference repository, then this is recopied on each of the user sites.
|
|
database
|
See repository.
|
|
description
|
Descriptors allow you to create reports (MS Word) containing part of the contents of the repository. Descriptor for an object includes the object characteristics, to which can be added the characteristics of objects directly or indirectly linked to it. The readable format for each of the objects encountered is entered as text in Word for Windows. You can insert descriptors into reports (MS Word) or report templates (MS Word) or use them to produce reports. Descriptors can be created or modified using the HOPEX Power Studio technical module.
|
|
desktop
|
The desktop specific to each user contains projects, diagrams, reports (MS Word), etc. handled by this user. The user has a different workspace in each of the repositories he/she accesses.
|
|
discard
|
Discarding the work performed in a private workspace cancels all modifications made since the last dispatch. All the work you have done since the beginning of the private workspace is lost. A warning message reminds the user of this. The user can request the discard of his/her private workspace from the File > Discard menu or at disconnection.
|
|
environment
|
An environment groups a set of users, the repositories on which they can work, and the system repository. It is where user private workspaces, users, system data, etc. are managed.
|
|
external reference
|
An external reference enables association of an object with a document from a source outside HOPEX. This can relate to regulations concerning safety or the environment, legal text, etc. Location of this document can be indicated as a file path or Web page address via its URL (Universal Resource Locator).
|
|
functionality
|
A functionality is a means proposed by the software to execute certain actions (for example: the shapes editor and the descriptor editor are functionalities proposed as standard).
|
|
general UI access
|
General UI access defines if tools are available or not. By default, general UI accesses have value *A (A: Available, *: default value)
|
|
importing
|
Importing a command file, a backup file, or a logfile consists of applying the commands in the file to this new repository.
|
|
link
|
A link is an association between two types of object. There can be several possible links between two object types, for example: Source and Target between Org-Unit and Message.
|
|
link orientation
|
The two objects connected by a link do not normally have symmetrical roles. For example, to connect an operation to an organizational process with the HOPEX Power Supervisor technical module, you must be authorized to modify the organizational process, since this action will modify its behavior. This action will not however modify the operation. You do not need authorization to modify the operation to create this link. The organizational process is said to be major for this link, the operation is minor. This characteristic is used by administration tools for object export, protection, object comparison and querying isolated objects.
|
|
lock
|
A lock is a logical tag assigned to an object to indicate that it is currently being modified by a user. Simultaneous access to an object by several users can also be checked. Locks apply to all types of object. When a user accesses an object to modify it, a lock is placed on the object.
When a lock is placed on an object, another user is only able to view the object. This second user will not be able to modify the object until the first user dispatches his/her work, and the second user refreshes. This is done to avoid conflicts between the state of the object in the repository, and the obsolete view of the second user.
|
|
logfile
|
Logfiles contain all the actions performed by one or more users over a given period. The private workspace log contains all the changes made by a user in his/her private workspace. This logfile is used to update the repository when the user dispatches his work.
|
|
logfile export
|
Export of a logfile creates a command file from the logfile of user actions in a repository. You can keep this file and import it later into a repository. You can selectively export modifications made in the work repository, or those made to technical data (descriptors, queries, etc.) in the system repository.
|
|
login
|
A Login uniquely defines a user or user group. It can be assigned to only one Person or Person Group.
|
|
major
|
The major object in the link is the one whose nature changes with the presence or absence of the link. For example a process, defined as a succession of operations, is modified if you remove an operation. The process is then major for the link. If the objects are protected, you must have the correct authorization for modifying the major object in order to create or delete the link.
|
|
matrix
|
A matrix is a table comprising rows and columns containing objects from the repository. Matrices show the relationships between two sets of objects and allow you to create or delete links without having to open the diagrams themselves. For example, you can build a matrix showing the messages sent by the different org-units in a project.
|
|
MetaAssociation
|
see "link".
|
|
Metaclass
|
see object type
|
|
Metamodel
|
The metamodel defines the language used for describing a model. It defines the structure used to store the data managed in a repository The metamodel contains all the MetaClasses used to model a system, as well as their MetaAttributes and the MetaAssociations available between these MetaClasses. The metamodel is saved in the system repository of the environment. You can extend the metamodel to manage new MetaClasses. Repositories that exchange data (export, import, etc.) must have the same metamodel, otherwise certain data will be rejected or inaccessible.
|
|
minor
|
The minor object in a link is the one whose nature is not modified or only slightly modified by presence or absence of this link. For example, removing an operation from a process does not change characteristics of this operation. Therefore the process is minor in the link.
|
|
model
|
A model is a formal structure which represents the organization of a company, or its information system. In another sense, a model can be a template for reproducing objects with similar characteristics. This is the case for report templates (MS Word) and matrix models.
|
|
object
|
An object is an entity with an identity and clearly defined boundaries, of which status and behavior are encapsulated. In a HOPEX repository, an object is often examined along with the elements composing it. For example, a Diagram contains Org-Units or Messages. A Project contains Diagrams, themselves containing Org-Units, Messages etc. Repository administration frequently requires consideration of consistent sets of objects. This is the case for object export, protection and object comparison.
|
|
object export
|
The export of one or several objects enables transfer of a consistent data set from a study to another repository. For example, export of objects from a project includes the project diagrams, together with the objects these diagrams contain, such as messages and org-units, as well as dependent objects. All the links between objects in this set are also exported.
|
|
Object type
|
An object type (or MetaClass) is that part of the database containing objects of a given type. The objects created are stored in the repository according to their type. Segments are used when searching for objects in the repository and when the metamodel is extended to include a new type of object. Example: message, org-unit, etc.
|
|
object UI access
|
Object UI access defines user rights on creation, reading, update, and deletion on these objects and their tools. By default, object UI accesses have value *CRUD (C: create, R: read, U: update, D: delete, *: default value).
|
|
person
|
A person is defined by his/her name and electronic mail address.
A person can access HOPEX once the administrator assigns him/her a login and a profile.
|
|
Person group
|
(Web Front-End specific) A person group groups persons in a group. These persons share the same connection characteristics.
|
|
private workspace
|
A private workspace is a temporary view of the repository in which the user is working before dispatching his/her work. This view of the repository is only impacted by the changes of the user, and does not include concurrent modifications made by other users. This private workspace exists until it is refreshed, dispatched or discarded. Note that a private workspace is kept when the user disconnects from the repository, unless the user indicates otherwise. A user can see modifications dispatched by other users of this repository without dispatching his/her own modifications. To do this, the user refreshes his/her private workspace. The system then creates a new private workspace, and imports the logfile of his/her previous modifications into it.
|
|
private workspace log
|
The private workspace log contains all modifications made by a user in his/her private workspace. It is applied to the repository at dispatch, then automatically reinitialized. This log is stored in the EMB private workspace file.
|
|
profile
|
A profile defines what a person can see or not see and do or not do in tools, and how he/she sees and can do it. The profile defines options, access rights to repositories and products, read/write and read-only rights on objects.
All users with the same profile share these same options and rights. A user can have several profiles. A profile is available for all repositories in a single environment.
|
|
profile assignment
|
The profile assignment defines the following for each person: the repository concerned by the assignment, access rights to the repository, the validity period of the assignment, (optional, with access to the repository in read only) connection repository snapshot
|
|
protection
|
When several users work on the same project, it is important to provide them with the means to work on a new part of the project without inadvertently interfering with previous work. To do this, you can protect the objects concerned by assigning to them a writing access area (HOPEX Power Supervisor technical module). It is then possible to connect these objects to others, if the link does not modify the nature of the object. The link orientation determines whether or not the nature of the object is affected.
|
|
publish
|
Dispatching your work allows the other users to see the changes you have made to the repository. They will see these when they open a new workspace, either by dispatching, refreshing or discarding their work in progress
|
|
query
|
A query allows you to select a set of objects of a given type using one or more query criteria. Most of the MEGA software functions can handle these sets. For example, you can use a query to find all enterprise org-units involved in a project.
|
|
see "reading access area".
|
|
|
reading access area
|
The user reading access area corresponds to the view the person or person group has of the repository: it defines objects that can be accessed by the person or person group.
|
|
reading access diagram
|
The reading access diagram enables definition of reading access areas and their hierarchical organization. This diagram also enables creation of users and their association with reading access areas.
|
|
reflexive link
|
A reflexive link is a link between two objects of the same type, for example: the link between projects that allows you to define sub-projects.
|
|
refresh
|
Refreshing his/her private workspace allows the user to benefit from changes dispatched by other users since creation of his/her workspace. In this case, it keeps repository modifications carried out by the user without making these available to other users. The system creates a new private workspace and the logfile of previous changes is imported into it.
|
|
reject file
|
When updating a repository (importing, restoring, dispatching), a reject file is created in order to store rejected commands. Rejected commands are stored with the reason for which they were rejected. These are found in the "MegaCrd.txt" file located in the environment folder.
|
|
reorganization
|
Reorganizing a repository consists of executing a logical backup of the repository, reinitializing it and reimporting the logical backup (without log).
|
|
report (MS Word)
|
Reports (MS Word) managed by HOPEX are objects allowing you to transfer written knowledge extracted from the data managed by the software.
|
|
report (MS Word) element
|
A report (MS Word) element is the instancing of a report template (MS Word) element. It is the result, formatted in the word processing software, of execution of the query defined in the report template (MS Word) element.
|
|
report file
|
The environment report file, MegaCrdYYYYmm.txt (where YYYY and mm represent year and month of creation) indicates all administration operations (backup, export, restore, controls, etc.) carried out in the environment. The report file is stored in the user work folder associated with the environment system repository: SYSDB\USER\XXX\XXX.WRI where XXX is the user code.
|
|
report template (MS Word)
|
A report template (MS Word) is a structure with characteristics that may be reproduced when producing reports (MS Word). A report (MS Word) can be created and modified as many times as necessary; however to produce several reports (MS Word) of the same type, use of a report template (MS Word) is recommended.
A report template (MS Word) provides the framework for the report (MS Word), which is completed with data from the repository when the report (MS Word) is created. A template contains the formatting, footers, headers and text entered in MS Word. It also contains report template (MS Word) elements that allow you to format data from the repository. It allows you to produce reports (MS Word) associated with main objects of the repository.
|
|
report template (MS Word) element
|
A report template (MS Word) element is the basic element of a report template (MS Word). It comprises a query which enables specification of objects to be described and a descriptor for their formatting. When creating a report (MS Word) from a report template (MS Word), each report template (MS Word) element is instanced by a report (MS Word) element.
|
|
Reporting Datamart
|
A Reporting Datamart is a replicated RDBMS Database from an HOPEX repository content.
The Reporting Datamart is made up of data selected at creation and synchronized on regular basis, to keep the Reporting Datamart updated according to the HOPEX repository content.
The Reporting Datamart feature is to be used as a source for any usage that needs HOPEX data (for example: reporting).
|
|
repository
|
A repository is a storage location where HOPEX manages objects, links, and inter-repository links.
The main part is managed by a database system (SQL Server). The remainder is in a directory tree (content of Business Document versions, locks.
The different users in the environment can access the repositories connected to it.
|
|
repository log
|
The repository log stores all the updates of users working in a repository. It is reinitialized at repository reorganization , or by selecting Repository Log > Manage Repository and Object Log in the repository pop-up menu. This logfile is stored in the .EMB file of the repository.
|
|
repository snapshot
|
A repository snapshot identifies an archived state of the repository.
Creating a repository snapshot allows you to label important states in the repository life cycle.
The repository archived states for which a snapshot exists are not deleted by repository cleanup mechanisms (Repository history data deletion).
|
|
restore
|
A physical restore consists of copying previously saved repository files.
|
|
saving
|
The work done in a session is saved when you request it, or when you exit. By default, the software executes an automatic save (the time interval between two saves is specified in the options: Options > Repository > Data Saving > Background automatic save). Messages appear asking you to confirm saving the changes you made in each open report template (MS Word) or report (MS Word) (except during the automatic save). It is recommended that you regularly save your work to avoid losing your work if your computer locks up or loses power.
|
|
session
|
A session is the period during which a user is connected to a repository. A session begins when the user authenticates and ends when he/she exits HOPEX. Sessions and private workspaces can overlap. When you dispatch, refresh or discard a private workspace, a new private workspace is created in the same session. Conversely, a user can keep his/her private workspace when exiting a session.
|
|
set
|
A set is a collection of objects with common characteristics. For example, you can build a set of messages sent or received by a certain org-unit in the enterprise. These sets are usually built using queries, and can be handled by most functions of the software.
|
|
setting
|
A setting is a parameter of which value is only determined when the function with which it is associated is executed. You can use variables to condition a query (HOPEX Power Studio technical module). When you execute this query, a dialog box asks you to enter these settings, with a box for each setting defined in the query.
|
|
site
|
A site groups together everything that is shared by all HOPEX users on the same local network: the programs, standard configuration files, online help files, standard shapes, workstation installation programs, and version upgrade programs. The site is installed on a local network resource or on each workstation if you are working without a network connection.
|
|
snapshot
|
|
|
style
|
A style is a particular format applied to a paragraph of text in a word processor. Styles allow you to systematically apply formats such as fonts, margins, indents, etc. Several styles are available for report (MS Word) configuration. These styles have the M- prefix and are based on the M-Normal style that is similar to the Word Normal style. Note that the M-Normal style text is in blue. All these styles are contained in the Megastyl.dot style sheet.
|
|
SystDb
|
SystDb is a particular repository containing the metamodel and technical data (descriptors, Web site templates, queries, etc.). The metamodel and technical data are common to all repositories in the same environment. Definition of users and their rights are stored in this repository, essential for operation of the software.
|
|
system repository
|
See SystDb.
|
|
text
|
You can associate text with each object found when browsing object descriptors (HOPEX Power Studio technical module). This text is formatted for MS Word. It presents what will be displayed for each of the objects in the generated report (MS Word). In the text you can insert the object name, its characteristics, and its comment. You can also insert the characteristics of other objects linked to it.
|
|
trace file
|
The trace file (Megaerr*.txt) is accessible via menu Help or from the HOPEX Server Supervisor tool (available in the C:\ProgramData\MEGA\Hopex Application Server\ <name of the HAS instance> folder). It traces all problems and errors encountered on the workstation. Technical support may ask you to check this file.
|
|
user
|
A user is a person with a login and at least one profile assigned.
The code associated with the user is used to generate file names as well as a specific work folder for the user.
By default at installation, Administrator (Login: System) and Mega (Login: Mega) persons enable administration of repositories and creation of new users.
|
|
work folder
|
Each user has a work directory in each repository that he/she uses. This directory is located in sub-directory User\XXX of the repository (XXX represents the user code).
|
|
workstation
|
A workstation is defined for each computer connected to the environment. A workstation contains programs and a configuration file that allow you to use HOPEX on that machine.
|
|
see "writing access area".
|
|
|
Writing access area
|
A writing access area is a tag attached to an object to protect it from unwanted modifications. Each user is assigned a writing access area. There is a hierarchical link between writing access areas. A user can therefore only modify objects with the same or lower authorization level. The structure of writing access areas is defined in the writing access diagram. By default there is only one writing access area, "Administrator", to which all objects and users are connected. Writing access management is available with the HOPEX Power Supervisor technical module.
|
|
writing access diagram
|
The writing access diagram is available if you have the HOPEX Power Supervisor technical module. With this diagram, you can create users and manage their writing access rights for repositories and product functions. By default only one writing access area is defined, named "Administrator". Attached to it are the "Administrator" and "Mega" persons. This is the highest writing access level and it should normally be reserved for repository management. You cannot delete this writing access area.
|