concepts |
DEVELOPER |
 |
|
concepts |
DEVELOPER |
|
The framework approach to the design of PROIV Developer has been provided to both ease navigation of development functions and the interaction with other developer sessions in a multi-user, multi-session environment.
All users of PROIV Developer are known as Developers with additional security options permitting the creation of Administrators. Individual developers must exist as individual users within the PROIV environment in order for the locking, booking and history facilities to function correctly.
Administrators have the ability to manage Developer access rights, project constraints and some of the more powerful tools via a dedicated interface. Security of projects and objects may be varied from a tightly controlled to a more open model.
Objects within PROIV Developer can be classed in two categories: -
Main Objects - which are managed and maintained as a whole, such as Functions, Files, Global Logics and Tasks.
Objects - referring to all components within the above, such as Editboxes, Variables and Interfaces.
When Main Objects are opened for edit they are automatically booked to a Developer and will remain so until the Developer Books the Object in. This provides a controlled blocking of access by other Developers whilst the Object is being developed. An Autobook facility has been provided that will automatically book-in an Object on closure, releasing access for other Developers. Optionally an Administrator may override the current state of an Object and book-in, providing it is not currently being edited.
Component objects have a logical hierarchy that should be natural to the PROIV developer. This is an important consideration when adding or pasting objects or fragments (collections of objects) into existing functions. File accessor objects are children of dynamic objects in Screens, and children of cycles within Updates, Documents and Reports. PROIV Developer will validate the addition of new objects at the selected point in the function based on these rules. Fig 2.0 shows the basic function object hierarchies for the standard PROIV function types.
Fig 2.0 - Function hierarchy
 |
Nested cycles are placed before or after field objects for screen, document and report function types. |
Booking of Objects must always be in the context of a Project, which is managed through the administration tools. Projects provide the development boundaries for changes to source code and assist in the identification of changes over time. It is possible to have only one project and provide open access without constraints; or to segment changes by Project, Developer, Security and Time Period.
A History log of all booking activity and events such as deletion, creation and import, is held to assist in the tracking of changes and management of Project components. Access to the history detail and housekeeping of the history is provided as an administrator’s tool.
The PROIV source code within PROIV Developer is in an abstracted form in that the developer does not directly edit the source used by the build process. When a Main Object is built from PROIV Developer the code is pre-processed before the build process is performed. Once residing within PROIV Developer the source code can be considered safe but the runtime and pre-build native may be considered vulnerable if proper control is not observed. Fig 2.1 shows the basic build process of a PROIV function from PROIV Developer.
Fig 2.1 - Basic build process
File Definitions and Global Logics are automatically pushed to Native Level on closure to reflect the changes made for all subsequent builds that reference them. Tasks are not abstracted, with all changes directly affecting the Native/System definition of a Task.
Source may be migrated into PROIV Developer by opening a native function via the open dialogue or linkage views, which results in the upload and analysis of code into the PROIV Developer repository. All referenced File Definitions and Global Logics will be migrated during a function migration if they do not currently reside in PROIV Developer.
Migration is a very intensive process and may take some time on very large functions. The resultant PROIV Developer function will be fast to navigate and structurally sound so it is worth the wait.
Topic ID: 500057