![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
This glossary is applicable to all of Apex.
Apex access control provides methods for controlling access to the objects in subsystems and views. Apex access control also provides management of UNIX permissions and groups for subsystems, views and the files within them.
Access control point directories (also known as "access control points" or just "control points") provide central management of all access control properties for the directory and its children. In particular, each access control point has an owner, an associated group and an access category. The owner is the user who created the control point. The associated group is the UNIX group associated with the control point. The access category specifies the kind of access that is available to different users of the control point and determines the UNIX permissions for the control point directory and its children.
The access categories and their characteristics are defined below:
- User_Only or Private
Specifies that the owner has full access to the control point while other users are to have no access.
- User_Group
Specifies that the owner of the control point is to have full access while the group associated with the control point is to have read-only access. Users who are not the owner and who are not in the associated group have no access.
- User_Public
Specifies that the owner of the control point is to have full access while all other users are to have read-only access.
- Group_Only
Specifies that the owner and users in the associated group are to have full access while other users are to have no access.
- Group_Public
Specifies that the owner and users in the associated group are to have full access while other users are to have read-only access.
- Public
Specifies that all users are to have full access.
- Unmanaged
Specifies that access to the control point is not managed by Apex.
The API providing a common set of services to support the Ada tasking layer using the disparate services provided by a Target Kernel Interface.
An implementation of the Ada Kernel Interface.
Application Program Interface (API) of various runtime services designed to aid in the implementation of Ada language features. The Apex compiler translates Ada source constructs into subprogram calls to this API.
That part of the runtime system implementing Ada Tasking and VADS Exec interfaces using the services of the Ada Kernel.
Request that Apex perform semantic analysis on your Ada code.
An Apex product for which the target and host are the same type of computer system, and which may in fact be the same computer system.
An Apex product for which the target and host are of distinct, incompatible types; applications cannot run on the host nor can they be created on the target.
Application program interface —— In Apex, a UNIX object library and a set of Ada specifications that define an interface to it. The API-related functionality of Apex includes using existing APIs and building new APIs.
All APIs are uniquely identified by a simple name (Ada identifier syntax). The API concept absolutely depends on the fact that API names are universally unique.
A set of files (named libapi_name.*) representing the implementation part of the API that is not visible to API clients. The API body consists of three files:
- The API (object) library archive file (libapi_name.a)
- The API-dependency file (libapi_name.dependency)
- The API-attribute file (libapi_name.attribute)
A program or another API that uses the API.
If an API interface unit or an API implementation unit of a first API mentions a unit (of the API interface) of a second API in a with clause, the first API is said to depend on the second API, or to have an API dependency. The first API then also depends on all the APIs the second API depends on, and so on, in a transitive manner.
API dependency (implicit/explicit)
A first API is said to explicitly depend on a second API if an API interface declaration of the second API appears in the compilation closure of the API interface of the first API. The first API is then said to have an explicit API dependency.
An API implicitly depends on an API it depends on but does not explicitly depend on. An API is said to have an implicit API dependency on a second API if it implicitly depends on the second API.
A subsystem that contains API implementation units of an API but is not the API interface subsystem. A given subsystem can be an API implementation subsystem of several different APIs.
An Ada compilation unit belonging to the API body, excluding the API interface units and units belonging to object libraries. Note that this excludes compilation units belonging to other APIs, because an API is an object library.
A set of Ada library unit declarations (the API interface declarations). As the API interface is shipped to API clients as part of a release view (of the API subsystem), the term API interface can also designate the entire release view.
A secondary unit belonging to an API interface declaration.
An Ada library unit declaration, which is member of the API interface (of some given API). The API interface of an API is exactly the set of its API interface declarations.
APIs are implemented by subsystems and their subcomponents. The API interface subsystem is the subsystem that contains the API interface (the Ada library unit declarations called API interface declarations). The API interface subsystem can contain other compilation units, it will in particular contain all the API interface bodies.
Either an API interface declaration or an API interface body. The term API interface units is used to designate the complete set of all API interface declarations and API interface bodies of a given API.
An Ada main procedure body, located in the API interface subsystem. The API main procedure of a given API mentions all API interface declarations of its API in with clauses, has no declarations and only executes a null statement.
An unambiguously named version of both the API interface and the API body. An API release can also include other items such as API skin units or documentation items. An API can have any number of releases.
The name of an API release. Each API release name must be unique with respect to other releases of the same API. Different APIs may, however, have releases with the same API release name. Identically named releases of different APIs need not have any relation to each other.
A release view of the API interface subsystem is shipped to API clients in the form of a release view, which is thus called API release view. The simple name of an API release view is the API release name of the API release.
An Ada compilation unit that implements a layered interface on top of the API interface. API skin units are shipped as part of an API release and belong to the API interface subsystem. However, API skin units are not part of the API proper because their implementation is visible to API clients.
Contains the API release views of all API releases installed at the API client site an API client, APIs are implemented by a single subsystem (the API interface subsystem). In client context the API interface subsystem is thus simply called the API subsystem.
The architecture of a software system defines how the system will do the things it is required to do by:
- Decomposing the system into components
- Defining the relationship between the components
Large systems can be organized into cohesive components with controlled interfaces between them. Each component exports only those portions of the interface that must to be visible to other components. Apex is like an extension of the class/package model. Imports are similar to withs or includes. Exports are similar to specifications defining which objects are visible outside the package in Ada or public in C/C++.
The architecture is the top- or macro-level design. It is the logical framework that allocates capabilities and requirements of a system via high-level components —— such as layers, subsystems, Ada packages or C/C++ files —— plus the interfaces between those components. But it also is the ongoing evolution and enforcement of that design.
Effective architecture involves understanding the problem domain and customer requirements, dissecting those requirements, and then planning and controlling the production of a software system to meet those requirements.
A check out with reservation obtains an exclusive reservation on the version history of the file, thereby preventing any other files with the same version history from also being checked out with a reservation. Checking out a file with a reservation starts a new version in the version history of the file. The version is completed and the reservation on the history is relinquished when the file is checked in.
Check Out, Private (Apex/Summit)
A private check out does not obtain an exclusive reservation of the version history of the file. A private check out allows modification of the file in the current view; however, a private check out may not be checked in unless the private check out is upgraded to a check out with a reservation. A file may be privately checked out even if its history is already reserved. A private check out is one way in which Apex supports simultaneous development by multiple users.
Request that Apex compile your program.
(Ada Only) Compilation units contain programming language source code. Compilation units have special semantics associated with them in order to support compilation.
Compilation Units are defined in Section 10 of the Ada LRMs and discussed in detail in the Ada Compiler Reference Guide.
Configuration Management and Version Control (Apex/Summit)
Configuration Management and Version Control (Summit/CM) provides:
Version control: Changes to individual objects in each subsystem can be controlled, and what changes were made, when, why, and by whom. can be tracked.
Configuration management: Multiple consistent sets of versions in each subsystem can be constructed, released, and maintained. Each alternative set constitutes a view of the subsystem. At a higher level, a configuration of views from each subsystem to create a complete system may be specified. What units or files are available to other subsystems and what units or files can be used by other subsystems can be controlled using exports and imports.
Configuration Files (Apex/Summit)
Configuration files provide a way to group together views from different subsystems. For example, a system release is often constructed by creating a configuration that includes release views from each of the component subsystems. Configurations are also used to specify the closure when main programs are to be linked. The contents of a configuration are either the fully qualified names of views or the fully qualified names of other configurations.
Configuration files and issues are discussed in detail in the Concepts Guide.
Context switches apply to commands that are executed in, and objects that reside in, a specific subsystem or view (Apex/Summit). Each subsystem and view (Apex/Summit) contains a switch file —— Policy/Switches —— and that file contains switches that apply only to the library context.
(Apex/Summit Only) The switch file in a subsystem is used only to initialize the switch file in a newly created working view when no model is specified as part of view creation. The switch file in a view is used when placing objects under Summit/CM control, compiling and debugging source code, spawning new released views, and so on. Context switches are discussed in detail in the Programmer's Guide.
In a switch file, switches are listed one per line and formatted as follows:
OPTIMIZATION_LEVEL: 2
REPLACE_TABS_WITH_BLANKS: FalseContext switch names are not case-sensitive, but by convention they are written in all uppercase.
Corresponding Files (Apex/Summit)
A subsystem usually contains at least one working view in which files can be checked out, modified, checked in, compiled, and tested. At any given time, each working view contains exactly one version of each file, usually (but not always) the latest version.
Files are corresponding if they exist in different views of the same subsystem and have the same view-relative name. Corresponding files may or may not share the same version history.
When corresponding files do share the same version history, only one file, in one view, can be checked out for editing at any given time. Thus, if a file is checked out in one view, the corresponding file in another view cannot be checked out until the file in the first view is checked in.
Even after the object is checked in, the corresponding files in other views are unaffected until you explicitly update using the Control > Update Objects or Control > Update Views command from the first view.
When corresponding objects do not share the same version history, they can be checked out in different views at the same time, and changes made in one view will never affect other views.
A deleted version is created when a controlled file is deleted. A deleted version has the same properties as any other version. A controlled file is removed from the file system if its associated version is changed to a deleted version.
Version control operations are discussed in detail in the Command Reference.
Development Releases (Apex/Summit)
Development releases can be used to represent releases at an early stage when limited changes are still allowed. Source changes in development releases are limited to accepting changes from other views, which allows development releases to be constructed incrementally, but also promotes stability by prohibiting in-place editing of units or files. Import changes and recompilation are not restricted. Development releases are primarily used as integration areas.
Release management is discussed in detail in the Concepts Guide.
For compilation units or files in a supplier library context to be visible to a unit or file in a client view, the client must import the supplier and the supplier must export the compilation unit or file. Compilation units or files that are not exported are not visible to the client.
An export set is a set of units and files that are exported from a particular library context. Compilation units and files are always exported into a particular export set. Different export sets may contain different units or files. When a client library context imports a supplier, the client specifies an export set in the supplier that will be used. The client will have visibility only to the units or files included in the export set that is being used.
Exporting is discussed in detail in the Concepts Guide and the Summit/CM Command Reference.
In frozen releases, all characteristics are frozen. All files and directories in a frozen release are read-only. In particular, no source changes, import changes, or recompilation are allowed.
Release management is discussed in detail in the Concepts Guide.
The computer system used to create an Ada application executable.
Import operations are used to manage the inter-subsystem compilation relationships of views. A client library context may only compile against the interfaces of a supplier library context if the client library context imports the supplier library context. To establish the import relationships, users specify a set of explicit imports for a client library context. The explicit imports can be specified as parameters to the Import command or by editing the import description file in the Imports directory.
Once the explicit imports have been specified, the import process conceptually proceeds in two stages. First, a set of implicit imports are computed. The implicit imports are library context that are in the import closure of the explicit imports. The client library context will have indirect compilation dependencies on the implicit imports. The full set of imports is the union of the explicit and implicit imports.
The second stage of the import process performs various checks on the consistency and compatibility of the full import set. The checks are listed below:
- There may be no circularities in the import relationships.
- Imports must be consistent.
- Release views may only import other release views (Apex/Summit)
- Frozen release views may only import other frozen release views (Apex/Summit).
- The compiler keys of the imports must be compatible.
Importing is discussed in detail in the Concepts Guide. and the Summit/CM Command Reference.
Any view (working or release) may be designated as an interface view. Interface views contain interface units or files, such as Ada specifications or C/C++ files, but no implementation units or files. For example, accepting changes from a non-interface view into an interface view will move interface units or files but will not transfer any implementation.
Interface views are discussed in detail in the Concepts Guide.
A target kernel layer with the corresponding Ada kernel layer. As such it implements the Ada Kernel API over the hardware of the target.
Keyword replacement provides a way in which strings containing special tokens called keywords are evaluated in order to produce result strings in which the keywords have been replaced by the names or attributes of Apex objects. For example, the keyword <subsystem> is always replaced by the name of the current subsystem.
An Apex view (Apex/Summit) or a Rational subsystem (Apex/ClearCase).
You can use one library context as a model for creation of another library context. The library context that is being cloned —— the model library context —— provides a base structure of subdirectories, policies (compiler options, target keys, etc., by way of switches), and a base set of Imports.
The rules concerning model library context are:
- Any library context can be used as a model.
- Subdirectories within the model are copied into the target.
- Imports within the model are imported into the target.
- Compiler options and other "switches" are copied from the model library context into the target.
Models are discussed in the Concepts Guide and the Summit/CM Command Reference.
Hierarchical importing may be relaxed by grouping views into mutual importing sets. The members of a mutual importing set have the following characteristics:
- Each member of a mutual importing set has a circular import relationship with all the other members of the set.
- Each member of a mutual importing set has the same set of explicit hierarchical imports.
- Each member of a mutual importing set has the same set of implicit imports.
- Each member of a mutual importing set has the same compiler key.
- A view may be a member of at most one mutual import set.
A mutual importing set is formed when each library context in the set declares itself to have a mutual import relationship with the other members of the set. This is accomplished through the Control > Show > Imports command or by editing a text file in each library context of the set.
When a mutual importing set is formed, an import change to any member of the set results in a change to all members.
One way to think of a mutual importing set is to regard it as a single compilation context that is distributed across multiple library contexts.
Mutual importing is also discussed in the Concepts Guide.
A standard API for multiprocess operating systems. Unless otherwise noted, this will mean ISO/IEC 9945-1 (ANSI/IEEE Std 1003.1, second edition, 1196-07-12), otherwise referred to as P1003.1c. Implementations of this API serves as part or all of the target kernel layer for Rational Apex to all target architectures for POSIX threads.
Apex is delivered with a set of POSIX Ada Language Interfaces. To find the POSIX 1003.5 bindings and the README file, look in the appropriate view:
A "thin" interface layer between the Ada kernel for Apex native systems and the POSIX API presented by the OS. Some OS implementations leave out optional parts of the standard, or for historical reasons implement a draft version of P1003.1c. This layer implements the standard calls required by the Ada kernel using non-standard OS services.
That extension of P1003.1 in P1003.1c intended to address real time programming requirements, as described in the Introduction of P1003.1c. These include semaphores, process memory locking, memory mapped files and shared memory, priority process scheduling, realtime signals, timers, interprocess communication, synchronized I/O, and asynchronous I/O.
That extension of P1003.1 in P1003.1c intended to address the need for multiple threads of control within a single process, ad described in the Introduction of P1003.1c. These include thread management and synchronization primitives, as well as harmonization of P1003.1 services to multiple threads of control.
Private Check Out (Apex/Summit)
See Check Out, Private (Apex/Summit).
A project allows access of files, directories, and resources named in the project by clicking special icons instead of typing pathnames. Apex provides the ability to create an object called a project that contains this kind of information and makes it available at various points in the Apex user interface. Projects can be on a per-user basis or shared among groups.
Creating and using projects are discussed in detail in the Programmer's Guide.
Switches that describe properties.
The general term for the target kernel layer provided by Rational.
Rational Exec Microkernel for Embedded
The version of the microkernel implementing all target kernel services, both tasking and otherwise, by accessing the hardware directly.
Rational Exec Microkernel for POSIX
The version of the microkernel implementing tasking support directly, but implementing other runtime services (e.g. signals, time, delay) using the POSIX API.
Release views represent the products of the development process that occurs in a subsystem. To provide flexibility for different methodologies, three different kinds of release views are provided:
- Development Releases
- Stable Releases
- Frozen Releases
Release views and release operations are discussed in detail in the Concepts Guide.
Release Kinds, Changing (Apex/Summit)
The kind of an existing release view may always be changed to a more restricted kind. In particular, the unfrozen kinds (development and stable) may always be frozen in-place after all import and compilation characteristics have been established.
Release management is discussed in detail in the Concepts Guide.
No source changes are allowed in stable releases (source stability is guaranteed). Import changes and recompilation are not restricted. Stable releases are particularly useful when the source is frozen but import changes might still be required in order to get an import network of release views into its final form. Also a stable release may be transformed into a development release.
Release management is discussed in detail in the Concepts Guide.
A declaration or pragma that is not inside a subprogram, task, generic unit, or block statement.
An Ada function or procedure (Ada 83 LRM 6, Ada 95 LRM 6).
Subsystems are the fundamental units of organization for software systems in Rational Apex. Each subsystem represents a component of a larger software system that can be developed, tested, and released independently.
Subsystems are composed of logical entities called objects that represent the source files that are being developed within the subsystem.
The objects in a subsystem typically have multiple versions that represent states of the objects at different points in their development history.
(Apex/Summit) Each subsystem maintains a version control database that is used to manage the versions of the objects. The version control database also provides facilities to coordinate multiple developers working in the subsystem to avoid conflicts.
(Apex/ClearCase) Each subsystem selects elements from a VOB. See the ClearCase User's Guide for more information.
Subsystems are discussed in detail in the Concepts Guide.
An API is called a supporter API of a second API, if the second API has an API dependency on the first API. The API dependency can be explicit or implicit.
You can control many characteristics of Apex's behavior through switches.
There is a switch that corresponds to each option of every Apex command line commands. These commands are described in the online document, Command Reference which can be displayed by executing the Help > Manuals command from the GUI. When you invoke an Apex command, the precedence for each option is:
- If you specified the option on the command line, use it.
- Otherwise, if the corresponding switch is defined, use it.
- Otherwise, use the default value.
Some switches do not correspond to command options because it would not be useful to be able to specify them on a command line.
The two kinds of switches are session switches and context switches. You can display either or both kinds with the Control > Reports > Switches command.
Session switches are UNIX environment variables whose names begin with APEX_. You set them the same way you set any UNIX environment variables.
Session switch names are case-sensitive. Use all uppercase.
Session switches are discussed in detail in the Programmer's Guide.
See Architecture.
The computer system on which an Ada application executes.
An API for runtime services which drive the hardware of the computer and its peripherals, either directly, by calling the OS, or a mixture of both.
An implementation of a Target Kernel Interface.
Templates provide initial values for various files that are created by Apex.
Update Objects, Update Views (Apex/Summit)
The Control > Update Objects command updates a set of destination objects. In many ways this operation is similar to File > Copy; however, it is customized to support integration and baselining for subsystems that are being developed in multiple views.
Each destination argument may name a file, a directory, or a view. When a file is specified, the file is updated to a later version. When a view or directory is specified, the operation is applied recursively to update all nested files and to create any files that are present in the source but not in the destination (subject to the options).
For a destination file to be updated from a corresponding source file the following conditions must be met:
- The source and destination must name objects in views of the same subsystem. When the source and destination name multiple objects in different subsystems, they are grouped together based on the associated subsystems and changes are accepted on a subsystem-by-subsystem basis.
- Both the source and destination files must have the same version history. Furthermore, the destination will be updated only if the history matches that specified by the
-history option.- The version associated with the source file must be more recent than that associated with the destination file.
When a new file is created, its history is that of the source file. When a destination file is updated to a deleted version, the destination file is removed from the file system.
Update operations are discussed in detail in the Command Reference.
Various runtime services providing extensions to Ada. The Apex compiler does not automatically generate calls to VADS Exec; applications must access them by making explicit subprogram calls.
A version is a snapshot of the state of a file at some point in time.
You can control individual objects in a subsystem. Controlled objects must be checked out to be modified. Checking out an object reserves it for editing. When ready, the modified object is checked in, making it available to other users.
You can also abandon your reservation without checking an object back in (Apex/Summit) or you can uncheckout your checkout (Apex/ClearCase). You can also (more rarely) make an object uncontrolled.
- For Apex/Summit
In every subsystem, Apex maintains a Summit/CM database that records the changes made to each controlled object. Each time an object is checked in, a new version of the object is created in the Summit/CM database. The resulting time-ordered, numbered sequence of versions is called a version history.
Each file in a view may be placed under version control. When a file is placed under version control the file is associated with a version history and the contents of the file reflect a particular version of that history.
When a file is under version control, the file may only be modified if it has been checked out. Checking out a file starts a new version in the version history of the file. The version is completed when the file is checked in.
When a controlled file is deleted, a deleted version is created. A deleted version has the same properties as any other version. A controlled file is removed from the file system if its associated version is changed to a deleted version.
Version control and version operations are discussed in detail in the Command Reference and the Concepts Guide.
- For Apex/ClearCase
A version history is a time-ordered sequence of versions that represents the history of a file. The versions in a version history are numbered from 1 to 65535.
A version history family is a set of version histories. A version history family includes at most one version history for each element in the subsystem. Version history families can be used to group together version histories that are related in some way.
Multiple version history families are often used in multitarget development. For example, there might be version history families for Common, Sun4 and RS/6000 development. The Common history family would group together the history for files that are target independent while the Sun4 and Rs6000 families would be used to group together the history of all the files that are being developed for those particular targets.
Version control and version operations are discussed in detail in the Command Reference and the Concepts Guide.
Each subsystem contains a set of views. Each view is an alternative specification or implementation of the subsystem. A view contains actual files that represent the logical elements in the subsystem. Files in different views are associated with the same element if the files have the same view-relative name. Files that are associated with the same element are said to be corresponding.
Each view provides both a version control context and a compilation context to support the development and compilation activities involving the files in the view.
In its role as a version control context, a view provides:
- A way to specify the desired version for each of the elements in the subsystem
- A way to generate new versions
- Methods to interchange versions with developers working in other views, and ways to limit the interchange when the work of different developers should not be mixed
To provide a compilation context, a view manages the following:
- The compiler that will be used to compile compilation units or files in the view
- Switches that are used by the compiler
- The visibility to compilation units or files in other subsystems (i.e., the imports of the view)
- The visibility that the view itself will provide to clients in other subsystems (i.e., the exports of the view)
- Management of all compiler generated files (e.g., object files)
Apex also integrates the management of version control and compilation information in a view in order to maintain consistency and to reduce the recompilation affects of version control operations.
- Providing a team development environment for managing multiple developers and simultaneous change
- Supporting testing and iterative development
- Making releases
- Compilation issues
Each view of a subsystem is either a working view or a release view.
A proprietary OS by WindRiver Systems Inc. for embedded computer systems which serves as the target kernel layer for Rational Apex Embedded to all target architectures for Tornado.
Working views provide areas for development and integration. Typically, each developer has a personal working view that provides insulation from other developers working simultaneously in the same subsystem. Working views are also used to provide integration areas when the work of multiple developers needs to be merged.
Views are discussed in detail in the Command Reference.
A proprietary Microsoft Corp. OS for desktop computers. It serves as the target kernel layer for Rational Apex to Intel Architecture for Windows NT.
Glossary
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |