FIRST CORE OF THE PROGRAM -
This package contains the object-oriented database management system for Access Road, and its description is recommended as the first reading for the Access Road developers. This page contains an overview of the design and test principles, the functions, the patterns and the architecture of the Access Road software. This page describes also the in-memory database management system of Access Road, since this is the responsability of this package. Another recommended reading is the description of the package ARoad0.gWork, which presents the design of the access path searches.
The generic object-oriented database management system for Access Road is fully in this gBase package, and this is its unique responsibility. The modeling of the access controls, for a given software, is provided by one or several Access Control Systems (ACS) and its inner components. One ACS is suffisant in most of the cases. The generic ACS are modeled in this package by the ACSImpl class. They may be subclassed into the AcsAddons for non-generic ACS. The power of this universal model is a long-term key factor of success.
THE ACCESS ROAD ARCHITECTURE
The layered architecture may be viewed as an extension of the MVC pattern. We use this standard to present here an overview of the software code. Some layers are dedicated to only one of the 3 responsabilites of the model-view-controller pattern. Some other layers cover several responsabilites, and sometimes, they apply the MVC pattern into themself:
The main 'model' of the MVC pattern is this gBase package. It handles all the Access Road persistent data. As a model, the package CNot contains the non-persistent access paths of the views. As a model, the packages Gui1 and Gui2 manages the graphical components like the internal frames into the Access Road desktop, and the user GraphicViews. The Gui1 property editors use the configuration data from the packages gBaseBeanInfo to display and update the persistent data from the gBase packages.
The 'view' of the MVC pattern is managed by the package Gui1 and Gui2. They displays all the graphical components. Gui1 covers the desktop, the menu, the user dialogs, the internal frames and the beamer, including its property editors. The package Gui2 covers the displaying of the trees and the GraphicViews into the internal frames.
The 'controllers' of the MVC pattern are managed by the package gDMak, only for the operations from the Access Road menu. In the Gui1 package, the beamer and its property editors are the controllers of their proper operations, mainly to call the package gBase. In the Gui2 package, the GraphicViews are their own controllers to call the package gWork for getting the access paths into dedicated threads. The hard work of finding the access paths is then delivered by the packages gWork, through the reading of the packages gBase. The generic package gWork is also the creator of the ACS and the user views into the gBase package, on the request of the gDMak package. About the access paths search, we recommend to read the documentation of the generic gWork package.
The architecture of the property change listening is introduced here. The package gDMak contains extension of the AbstractAction class to listen the events from the Access Road menu. The gBase packages are the main senders of property change events to listen. In the Gui1 package, the property editors listen these packages. In the Gui2 package, there is a dedicated listener of these events for each tree and each GraphicView. In the gWork package, there is also a listener of the packages gBase for each GraphiView, and it is able to redirect the events to the Gui2 package.
The AcsAddon packages have a name starting with 'ARoad0.AcsAddon.'. Each AcsAddon has 4 packages: gBaseInterface, gBase, gBaseBeanInfo and gWork. Each package contains mainly some subclasses of the classes from the relevant generic package, i.e. 'ARoad0.AcsAddon.Accbee.Ubuntu.gWork' contains subclasses of the generic gWork classes, and its responsability is only to extend the responsabilities of the generic package gWork. The generic package gBase provides the facilities to inform the other generic packages about the property change events an AcsAddon may send from its gBase package.
Several architectural patterns have emerged during the Access Road development. They are presented in a dedicated section of this page. There is no configuration file for Access Road. All the Access Road data is saved in one dedicated Access Road directory, plus a special directory for the exports.
THE MAIN gBase CLASSES
Before the design overview, this section provides a quick look on the main Java classes Access Road handles to model a software. These classes are all into this generic gBase package. They may be subclassed by an ACS addon, into another gBase package.
The Access Road user may define the properties of a new ACS through the GUI. If it is a generic, non-addon ACS, it uses directly the generic ACSFactoryImpl class and its BeanInfo class. An advanced user may creates through the GUI a new ACS from another one, typically by editing some limited properties like the type policies. For the Java developers, it is possible to configure extensively a new ACS, like for the RBAC application in the class gWork.AcsFactory. In all cases, it is recommanded to well understand the class ACSFactoryImpl first, before the ACS addons. The AcsAddon pattern may provide a complex simulation with a minimal effort, like for Linux Ubuntu and MySQL, when the generic features of this gBase package are too limited. The way is to subclass the generic gBase and gWork classes in dedicated packages. It represents the second mean to define a new ACS, but for the Java developpers only.
The last level of coding, of course, is to change any Java class into this generic gBase package. This is beyond the AcsAddon pattern. The main risk is to impact without control the access paths search the generic gWork package provides. This is to be reserved to the cases which cannot be managed by the AcsAddon pattern. It is recommanded to code a new version of Access Road including the new features as generic ones. This would allow any AcsAddon to use the new features.
An ACS contains a catalog of components, so-called ACSObjects, which are registered into the ACS at their creation. Each ACSObject class implements a key concept to model. The relation ACS/ACSObject is strong. Deleting an ACS deletes all its ACSObjects. The catalog of ACS components is intended to model all the software to simulate. On the other hand, one given ACS has not to handle all the kinds of ACS component. Most of the ACS use only a selected part of them. There are 8 main gBaseInterface.ACSObject instances (Resource, Directory, VirtualFolder, Actor, UserID, GroupID, ExchangePoint, ContextSwitch), and 3 rights modeled as classes (AclEntry, PrivilegeForLinks and PrivilegeForType). The other rights are modeled as ACSObject properties: Resource AG rights, Actor Bridge rights, EndPoint senders lists, ExchangePoint maximal rights of ends, and finally, the Account/Group, AclEntry and PrivilegeForLinks inherited rights. This model produces 24 main structural boolean properties for a generic ACS, with numerous secondary boolean structural properties. A generic ACS handles about 100 properties to drive the behavior of its ACSObjects. The main implementations of the interface ACSObject are the following classes:
BasicImpl is a subclass of Object which is responsible for modeling the member of a VirtualFolder and/or a ViewInBase in an ACS, and it ensures the handling of Privileges. Like a Java abstract class, an ACS does not use pure BasicImpl instances, but only some subclass instances. BasicImpl handles fully the privilege rights as source and target, but it does not implement the interfaces PrivilegeSource and PrivilegeTarget. So, its subclasses have to implements them if it is required, but they have the powerful facilities of BasicImpl to do it. A BasicImpl may be an alias or an alias reference, but not both.
EligiblePartyImpl is a subclass of BasicImpl which is responsible for modeling the simplest rights user for which an ACS grants access or denies access to some access targets, by the way of any type of rights. Only EligibleParties have effective rights. Note: on the other hand, other entities may be the source of access paths to targets, like a VirtualFolder for its members. This is an example of a structural relation rather than a rights-based relation.
GroupIDMemberImpl is a subclass of EligiblePartyImpl which is responsible for modeling the member of a GroupID.
UserIDImpl is a subclass of GroupIDMemberImpl which is responsible for modeling an account in an ACS, as a kind of GroupIDMember that may own some Resources and have a primary GroupID. It may have Account/Group rights on Resources. It may have some current actors, that are active entities like programs.
GroupIDImpl is a subclass of GroupIDMemberImpl which is responsible for modeling a set of GroupIDMembers. It has Account/Group rights on Resources. The relation GroupID/member is weak, since the deleting of the container or the member does not delete the other entity.
ResourceImpl is a subclass of BasicImpl which is responsible for modeling the simplest access target on which an ACS grants an access or denies it. A ResourceImpl may be owned by an account (as UserID). It may be the member of a main groupID. A ResourceImpl may be a Target for Account/Group rights, AclEntries and Privileges.
DirectoryImpl is a subclass of ResourceImpl which is responsible for modeling a directory which contains children, as resources and other directories. The relation directory/children is strong, since the deleting of the directory produces the deleting of all the direct and indirect children.
ActorImpl is a subclass of ResourceImpl which is also an EligibleParty. It is responsible for modeling an active entity which may have access to resources, by the way of Account/Group rights, AclEntries, Privileges or Bridges. It may be both a source and a target for the Bridge rights. It may have a current UserID and a current GroupID, and also secondary groups. This is true even if the Account/Group rights are not allowed. The Actor may run under an Account/Groups context in a given access path of a ViewInBase.
VirtualFolderImpl is a subclass of FolderAbst which is responsible for modeling a folder which contains resources as members. It is a PrivilegeTarget. It may be an alias or an alias reference, but not both. The members may be simple, like Resources or Directories, or it may be EligibleParties as Actors. The relation VirtualFolder/member is weak, since the deleting of the container or the member does not delete the other entity. The ACS sets that the VirtualFolder delivers all its rights to its members, or no right at all. As an alias reference, the VirtualFolder may run under an Account/Groups context. Then, its members may be accessible through the VirtualFolder and a GroupIDMember of this context.
ExchangePointImpl is a subclass of ActorImpl (new in 0.7.3). It is responsible for modeling (1) the data exchange point (DEP) of an ACS or of a program into an ACS, (2) for modeling the 'white'/'black' senders list of a communication end point (CEP), and (3), as an option, an ACS referral. A DEP typically models a communication socket or a pipe for a unique Actor named the master program. A CEP may have a 'black' list of forbidden ACSObjects for which any call to this end point is forbidden. It may also have a 'white' list. An ACS referral is an optional feature of an ExchangePoint. It is defined as handling one link to another ACS that models the DEP master program. The ACS referral controls the existence and the properties of this external link, while the DEP controls the maximal operational rights of its data streams.
ContextSwitchImpl is a subclass of ActorImpl (new in 0.7.3). It is responsible for modeling (1) the entry context switch (CSW) function at the entrance to an ACS, (2) the exit context switch function at the exit of an ACS, and, just like the ExchangePoint, (3) for modeling the 'white'/'black' senders list of a communication end point (CEP). It selects or complements the local context of an access path. For an entry context switch, the local context is the Account/Groups context under which this CSW has to run, giving the AG or non-AG context of the income stream from the another ACS.
OVERVIEW OF THE DESIGN PROCESS AND THE TEST STRATEGY
We provide in this section an overview of the Access Road way of design and testing. Generally speaking, Access Road is based on a solid object-oriented design. The best way to provide great software at the best cost is to concentrate the efforts on clear and structured data, clear and structured patterns, clear and structured documentation, all in layers of different abstraction levels. Like a diamond flashing under the light that goes across it, a great software is transparent to the human understanding because its internal structure is trully coherent. It is just as the diamond atoms are, after the great pressure of the design effort.
This requires an iterative structure-driven and abstraction-driven development process. Starting from the true issues, testing and improving the code is based on a solid ground. Access Road does apply the SOLID approach. SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Robert C. Martin in the early 2000s which stands for five basic principles of object-oriented programming and design. The Access Road classes are first Plain-Old Java Objects (POJO), because we think that 'well-abstracted' POJO is the proven way to get a great simulation software. Interfaces and methods are stable. Some robust architectural patterns may then appear, using the classes in varied contexts in an iterative process. The convention-over-configuration approach lets avoid needless work, providing a default semantic and behavior in the architectural patterns. Without the right property, a given feature is not delivered by the generic classes of the Access Road core. Without ACS addon to include a specific class, the core offers generic classes to provide a default behavior. This is completed by the specific ACS configurations of the software simulations, like for Linux Ubuntu or MySQL Server. These configurations may be copied and edited before the creation of a new ACS.
Software testing is always mandatory, but the need of testing may be lowered by (1) a consistent and clear design, (2) a risk analysis, and (3) the best use of structures and abstractions. Documenting the design before and after coding is much more powerful than coding the tests before the functional code. 'documentation is the sign of a weak code' is a wrong sentence, although it is popular among some developers. Structuring the code so it is able to be understood without documentation is a good way of coding. However, the limit is when the algorithms are complex and have to be fast. The number of variables and the number of lines of code are larger and larger. Documentation, that is summarizing the high-level objectives and logics in a text, is then the most powerful way to communicate the most complex ideas. The design and the documentation of Access Road represents about 50% of the overall development effort. The main design task is to model a given software with the generic features of Access Road, then to define some additional functions into an ACS addon. The general development process of Access Road is the following:
(1) to define a dedicated concept for simulating a given software, like GNU/Linux Ubuntu.
(2) to fully describe and to code some first generic features from this dedicated concept.
(3) to improve the design of the generic features for simulating other software, like the RBAC application, and so for getting effective generic concepts.
(4) to fully document and to code, if necessary, some additional features in an ACS addon, to cover all the initial dedicated concept.
(5) to test the generic concept without ACS addons.
(6) to test one more time the use of the generic concept through the test of the additional features into each ACS addon.
(7) finally, to test the dedicated concepts into each ACS addon.
If the developers are skilled, it is not efficient to test all the methods in programmed unit tests. The best way to valid the code is not to apply numerous predefined tests at the level of each method. Most of these tests are trivial, and most of the execution paths are not trully used by the higher-level code. Furthermore, the errors by omission are very difficult to detect, since they are about the semantic and the sequence of calls. This is why most of the methods produce errors which can be detected by higher-level tests, rather than by unit tests. Furthermore, usual unit testing is not complete, because it does not check the internal values of the method. This is why it is recommended to think first and foremost along the lines of what are the true risks of errors. In a complex software, the more important risks are about a failed, rigid or over-complex design. There is no magic bullet against the design errors. However, an extended design documentation is a very good practice. The full documentation of the design has to be done before the coding. It is almost mandatory to get the highest quality in the definition of the concepts, the responsabilities and the algorithms. A good indicator of the design quality is to not have any complementary design question during the coding. After the coding, it is more efficient to fully review and test the critical 30% of the code. The careful reading of the code is the best way to detect the bugs, typically to improve the code in an iterative process. However, code review is efficient but boring. Improving the code enforces to perform an implicit but careful code review. This is a strength of the agile development process, just like it is a strength for the Access Road development process in 7 steps. Including some stable integrity controls in the code is a efficient form of continuous testing. Monitoring and reading the internal data of a method is very good way to enforce the quality. This allows to check the consistency of the data from varied methods, in the flow of method calls, instead of checking the values at the interfaces of each method. This way is specially useful for the functionnal-style methods of the access paths search. Finally, the automated tests complete the testing process by covering only the most complex cases. They include the critical cases coming down from the higher levels of the layered abstraction. The most important ones are the automated non-regression tests.
For Access Road, the main non-regression automated tests are based on the software TestNG. They create several classical ACS like Ubuntu and MySQL, then create several full views to check the resulting access paths. These automated tests covers all the packages gBase and gWork, both as generic and ACS addon packages. Well-chosen automated non-regression test cases are fine, but do not hesitate to apply almost random entry data if necessary. The GUI is checked mainly by simple manual tests. They are far from complete, because the GUI is less critical and more stable. In a nutshell, this way of testing uses efficiently the skills of the developer to choose the best integrity controls, the manual tests and the automated non-regression tests, after a careful design and a risk analysis of the potential bugs.
Using good structures and abstractions is a powerful way to minimise the bugs. After the coding of a method '2+5', I has to test if the result is '7'. If I code 'x+y', I put more abstraction in the code. The first tests may be with a limited set of arguments for x and y. The next iterations will allow to write the code easilly, if I master this 'x+y' abstraction. If I find a bug in the 'x+y' computing for a new couple of argument, it will be the time to debug it. Through this process, if the developer has learned the modeled concepts, abstraction simplifies the understanding of the code, while it is possible to control the number of testing cases. Layered abstraction drives to a natural use of the code. The hidden bugs are rarely met, and they are more easy to fix. With the structure-driven and abstraction-driven development process, it is a good idea to add some integrity controls in the code. Good exemples are method entry controls and controls of the consistency. They are mainly based on the semantic of the abstractions. These controls remains generally very stable during the improvement of the software. Last but not least, an abstraction-driven code is smaller, more clear and more dense, because there is more smartness in it.
On the other hand, because we are in the real life, there are also conter-exemples. This iterative and layered abstraction process is not always the best solution. A first conter-exemple is for the type-oriented policy of the ACS. Our choice is to allow the Access Road user to define extended properties through the GUI, at the creation of an ACS. Unfortunately, this produces a code rather difficult to validate. Another conter-exemple is the properties of an access path. A simple String map is prefered to model the Account/Group context of a path. This choice ensures the best performance and extensibility.
A first way to monitor the internal data for testing a method requires simply to print them during the execution of the code. 'System.out.println()' calls are required. The Access Road code is full of such calls the code maintainer may easily enable and disable at any moment. The beauty of this manual testing approach is that no heavy development tool is needed, but a text editor, a Java compiler, and above all, the clear mind of a skilled developer. The access paths search functional-style methods are tested by this way. Reading the access paths of a view is another testing approach. The paths contain a lot of data about the applied search logic. The gWork packages use a functionnal-programming style in the access paths search. A detailled human review of the view paths is an efficient way against bugs, when the good internal data of each method is printed and studied. Some comparisons between the access paths from two successive versions of Access Road may also be powerful to help the developer, and, last but not least, to enforce his confidence into the design and the code. It is easy to convert the 'System.out.println()' calls into calls to a BaseError instance, to collect all the execution points and to use them as criteria of some automated integration tests, or, as Google says, medium-size tests. These criteria complete the classical set of input/output test data, into the automated non-regression tests.
The main Access Road structures are driven by data, rather than by algorithm. We stand for the idea of a strong database model from which the software structures and the algorithms grow up, since this is the true nature of a simulation software. This is the responsibility of this gBase package, with the secondary packages gBaseInterface, gBaseBean and CNot. The database model is also the best place for most of the data integrity controls. However, there is an exception for the type-oriented policy. It is not enforced by the gBase package, but by the GUI packages, typically in the Gui1.SimplePropertyEditor class and the gDMak.ActionNewResource class. The data-centric approach is also applied to the path search algorithms, the most complex part of the code. The concept of access path is modeled in the CNot.DisplayableLinkImpl class, and the concept of access link between two path nodes is modeled in the CNot.AccessControlLinkImpl class. In this case, the structures in the gWork package to find the paths may be seen as oriented by the semantic geometry of the possible links between the path nodes. The classes DisplayableLinkImpl and AccessControlLinkImpl contains integrity tests that help to detect the bugs. Again, the path search algorithms are the result of an iterative structure-driven and abstraction-driven development process. The intermediate-data testing is able to test efficiently large constructors and large methods, contrary to the classical way. The path search algorithms are implemented with a functional programming approach, using large static methods. Very large methods with numerous loops are sometimes mandatory for providing the fastest implementations. These methods are strongly structured. Their editing and the monitoring of the internal data become more easy.
In the code, the naming convention for the classes, the methods and the properties is clear. Its application is very consistent. Each name is chosen to describe precisely the function of the object, like 'Resource' or 'EligibleParty'. In the gBase packages, a class 'XXXImpl' implements an interface 'XXX' in the relevant gBaseInterface package. It is associated to a BeanInfo class named 'XXXImplBeanInfo'. The AcsAddon class names are derived from the generic class names. The instance-level properties have a name ending with '_'. The method-level properties have a name without '_'. The method arguments have a name starting with '_'.
THE ACCESS ROAD ARCHITECTURAL PATTERNS
Several architectural patterns have emerged during the Access Road development. They are not always fully presented as pattern in the code documentation. They are the following:
The little decision maker pattern in the gDMak package is responsible to manage the basic operations from the events of the menu.
The little internal frame pattern in the Gui1 package is responsible to handle the internal frames in the Access Road desktop.
The gBaseBeanInfo package applies an extended JavaBean pattern called the BeanInfoPattern, to set the handling of gBase objects in the GUI. This complex pattern covers the display of each property of the base object in GUI, the property change events handling and the policy to create, edit and delete the property. It is applied mainly by the gBaseBeanInfo and the Gui1 packages.
The embedded class pattern provides a form of multiple class inheritance through nested traits to which a single responsability is delegated. It is reserved to the classes in the gBase packages.
The event management pattern for the views is responsible to update a displayed view when a relevant property is changing, from a view node or an intermediate node in any access path of the view. It is described in the documentation of Gui2.GraphicViewBaseListener.
The thread management pattern for the views is responsible to provide a dedicated thread to each displayed view, for processing its own access path searches.
The access path search pattern is the most complex one. It includes mainly the generic gWork package and the AcsAddon gWork packages which contain the search algorithms. There is also the Gui2 package with the GraphicViews, and the CNot package which contains the notification interfaces and classes for the data flow between the gWork packages and the GUI-oriented packages.
The pattern for AcsAddon is well documented. It is mainly implemented in the gBase and the gWork packages. This pattern allows to add more easily some Java classes to perform specific gBase and gWork functions. More precisely, it manages the subclassing of some generic classes and the adding of fully new classes. It inserts hooks (upcalls to the AcsAddon code) at every point in the generic code where the generic concepts or algorithms would be not appropriate.
As a framework for simulators, Access Road has to offer all these architectural patterns. They provide powerful capacities to simulate a new software, to integrate it in the GUI, and to exchange properly with unknown simulations. Interface multiple inheritance, Java reflection and dependency injection are used extensively in the patterns. On the other hand, Java annotations and aspects are not used. They have not proved their usefulness. Note: the OSGi standard is much more complex than the AcsAddon pattern. Its ability to load a Java module during the program execution is not an Access Road need.
ROLE OF THIS gBASE PACKAGE
The gBase package is responsible to model simple and complex software as access control systems (ACS). It provides models for all the ACS objects and for the views that contain a set of objects for which the access paths are defined. In the spirit of the 'thick database' paradigm, this package drives the display of the base object properties in the GUI, through the BeanInfoPattern pattern, and it drives also the access path search in the gWork package, through the access path search pattern.
The gBase classes protect their internal variables from external editing outside the control of given methods. At every property change, they check in the compliance with the integrity constraints coming down from the generic ACS, then they fire a matched property change event to the external listeners. In the gBase package, the integrity constraints are managed in each Java class in a true object-oriented design. It is not in separate tables like in a relational database. By this way, the reliability, the extensibility and the performance of the database may target a very high level.
In the gBase generic package, the class BaseManagerImpl is responsible for the management of the database. BaseManagerImpl handles the storing of all the data in files, with the Java class serialization. This includes mainly the Access Control System data, the ViewInBase and the Information System data. ACS is the main structure, since it simulates a given software, or a part of software, with its structure, its behavior and its access control functions. Each ACS may be independently created, opened, saved and closed. This is also true for the ViewInBases. To open a view, since the view objects are objects from some ACS, these ACS have to be open.
The Information Systems are tree structures to handle the varied relations between the ACS. They are created, opened, saved and closed with the ACS they use. They may contain passive nodes, for example a physical component. An ACS may have a subACS which is managed as a separated set of components and rights. Among the relations from an ACS to another, there is the tied relation forcing an ACS to be open with its ACS parent. A second relation is the visible space of Information System nodes on which an ACS may be connected around it. A third relation is the alternate relation where an ACS or a subACS is replaced in its access decisions by another ACS or subACS. With the combination of ACS, subACS, tied child ACS and alternate ACS/subACS, it is possible to design powerful structures for simulating complex software. With the concept of visible space, it is possible to manage the space of an ACS network where the relations among ACS are not predefined in each ACS, but are discovered by the nodes search algorithm in each ACS.
The classes ACSFactoryImpl and ACSImpl are used respectively for the construction and the handling of the Access Control Systems. ACSFactoryImpl is the most complex class of the program. Its responsibility is to allow the setting of more than 120 ACS properties. This is the first key of the Access Road versatility, its ability to be customized. ACSFactoryImpl defines a generic ACS to simulate a given software, its structure, its behavior and its access control functions.
HOW TO CONFIGURE A NEW ACS
For simulating and understanding a given software, Access Road offers three generic tools to the user. They provide a great level of flexibility to handle high-level concepts without Java coding. The documentation of these tools is in the methods of the classes gBase.ACSFactoryImpl and gBase.ACSFactoryUtilityImpl. They are introduced hereinafter:
The first tool is a set of booleans to model the so-called 'ACS main structure'. There are 24 main booleans as properties of the ACS. One boolean tells if the ACS handles AclEntries or not. Some secondary booleans are also used to complement the first 24 ones. The ACS structure is the first mean to compare two simulations. In the class ACSImpl, the methods getManageXXX() set if a given ACS component or structural property is managed by this ACS. The main booleans are displayed by the Beamer in the tab 'Structure'. An additional tab 'Structure 2' shows the properties for the ContextSwitch and the ExchangePoint, the SubACS and the composite relations (this later relation is not used so far). It describes also what are the editor, the version, the ACS addon name and the gBase classes this ACS handles. If the privileges or the virtual folders are managed, an additional tab 'Structure 3' is used in the beamer. At the creation of an ACS, the class gBase.ACSFactoryUtilityImpl provides a complex set of 60 integrity rules to ensure the consistency of the ACS structure. Detailled error messages are provided if it is not possible to create such an ACS. A trivial message is: 'in the ACS constructor, the resources are not managed, while the privileges for resources are used'. Another exemple of error message is: 'in the ACS constructor, the external one-to-one Privileges and the external AclEntries cannot be managed together.'.
The second tool is a set of requirements for the ACS behavior, as a list of sentences the user may read. The aim is to facilitate the understanding of how a given ACS works, typically to deliver or not its rights to an object into a view. There is a structured list of sentences called the 'ACS rules'. An example is the sentence 'sens meta-rule 1: this-ACS denying rights are superior to this-ACS granting rights'. Most of the booleans in the ACS structure have an equivalent as ACS rule. There is a common catalog of generic rules for all the ACS, into which each ACS selects those to apply. An ACS addon generally adds a complementaty set of specific rules. All the ACS rules are displayed in the Beamer by the tab 'Rules'.
The third tool is a type-oriented policy for the ACS, based on the String property 'type' in each ACSObject. This is a more complex tool, because there are about 40 policies. The criterion to apply a policy is generally the class or the type of the ACS component. An ACS may handle requirements like 'list of the types to authorize to a Resource', or 'list of the AclEntry rights the ACS permits for a Resource having this given type'. Other examples are the types a group allows for its members, following the group type, or the accounts which cannot be member of more than one group, following the account type. For the GroupID and the GroupID memberships only, there are more than 12 specialized policies an ACS may use. An important feature of the type-oriented policy is to be implemented by the way of two general String maps in the ACSImpl class. It is so easy to add further policies without change in the ACSImpl class signature. The backward compatibility among the Access Road versions is kept after a change of the type-oriented policy. An item in a policy map is a couple key/value, where the key is for example 'Resource.ResourceType' and the value is the 'list of the String types to authorize to a Resource'. To go further, let's see the method getL_LimitedValuesForSpecializedTypesAndExplorer() in the class gBase.ACSFactoryUtilityImpl, as a first example, and also the documentation of ACSCatalog.getM_TypeOrientedPolicy() and ACSCatalog.getM_TypesAndGUIPolicy(). The type-oriented policy defines the detailled structure, like the kinds of ACSObject under a given Directory. It may be viewed as delivering static integrity requirements for an ACS. The two maps of the type-oriented policy are displayed in the Beamer by the tab 'Types'.
It is possible to configure the objects of a generic ACS without any coding in Java. An advanced user may use a small programming language, to create/delete some objects or to change some default properties:
Associations (called actions in the GUI) are scripts having one to more than 200 lines of command. This is a powerful tool to maintain the dynamic integrity constraints among the ACS components. The scripts may be executed by the ACS, like database triggers, for four types of events: the opening/closing of the ACS, or the creation/deletion of a component in the ACS. For the opening/closing of the ACS, the scripts generate objects called roots in the parent ACS. The component is defined there mainly by its class or its type. A first example is the operations Access Road has to perform after the creation of an object by the user or a program. A GNU/Linux Ubuntu dynamic constraint is 'each account has a dedicated directory having the same name'. This is why an association is written in the GNU/Linux Ubuntu ACS addon to create the relevant Directory for each new personal UserID, and to delete this personal Directory when the UserID is deleted. Another example is for setting the root objects, like the MySQL objects in the GNU/Linux on which MySQL Server runs. The syntax of the language is derived from Java and from the gBase classes and methods. This is reserved to advanced users, even if it is much more simple than the Java code. Most of the users have not to understand these scripts. They produce updatings the user may observe and analyze through the GUI. On the other hand, like any ACS property, the associations may be ridden through the GUI by the advanced users. They are more flexible than the Java code when an ACS is copied. When a new ACS is derived from another one, the associations are copied by Access Road, and the advanced user may change them through the GUI. The documentation of the associations is for the gBase.AssociateUtilityImpl class, where the method controlAssociations() is a good first reading.
INTRODUCING THE BASIC gBase CONCEPTS
In the gBase generic package, some basic classes are used to model the ACS main components. Some complementary but important concepts are modeled into the basic classes. They are the followings:
NameImpl is responsible for managing the names for all the database objects. Examples of real name are "http://www.accbee.com", "c:\program files\access road", "net/users/john". The separator character depends on the ACS. All the real names are converted in Access Road names implemented by NameImpl. The single separator into the Access Road names is ':: '. Of course, it cannot be used in a Name component.
StringRightImpl is a subclass of Object which is responsible for managing a right. A right is defined without connection to the user rights or the access targets. This connection is the role of the right types, like AG rights or ACL rights for instance. There are two types of rights: the canonical metarights, outside any ACS, and the ACS rights. They are managing metarights to define the management operations, like the changing of a Resource owner. Each ACS right has a metaright as a reference; it is a StringMetaRightImpl, subclass of StringRightImpl. The metaright is used to compare the strenghts of the rights, and to explain precisely the ACS right semantic. A right has a sens: it delivers a granting or a denying right. A right has a name and an acronym which are displayed by the GUI in the views. The right strenght is used to set if the NoMoreNoLess view fulfills with its right criterion.
Account/Group (or AG) rights and Bridge (BDG) rights are directly handled in the ACSObjects. They are not modeled as specific classes, but mainly into the Resource and the Actor classes. The Account/Group rights are the most complex ones, since they depend on the multiple relations between the UserIDs, the GroupIDs, the Actors and the Resources. A Resource may be owned by an UserID, and it may belong to a primary GroupID. Each Resource may deliver some Account rights on it to its UserID, and some Group rights to its primary group only. An Actor is a Resource which is also an EligibleParty, so it may be both an access source and an access target. Nested GroupIDs are possible. An Actor may have a current UserID and a current GroupID under which it runs, as a model of program. Generally speaking, the current UserID and GroupID of the Actor are not the UserID and GroupID of this Actor as Resource. The Actor belongs to all the GroupIDs which have its current UserID or its current GroupID as member. As access sources, theses GroupIDs lead to deliver new access paths to the Actor as access source. Inherited AG rights of a Resource are possible through the Directory which is the parent of the Resource. They are cascading inherited AG rights along the chain of parents. The current UserID and GroupID of an Actor are never inherited. The Bridge rights are simple executing relations between two Actors from different ACS. They are immutable after the creation of the bridge source. They are never inherited.
AclEntryImpl is a subclass of Object which is responsible for modeling an access control entry which manages some access granting or some access denying from an EligibleParty to a Resource. The set of StringRights may be changed, but not the source or the target. A conditional AclEntry had some membership conditions to group(s) for delivering its rights to its EligibleParty. The AclEntry, the EligibleParty and the Resource may belong to three different ACSs, or, in the simplest case, to only one ACS. The AclEntry ACS is responsible to deliver or not the rights to the target. An AclEntry is created and managed by its Resource, and it is deleted ar the Resource finalizing. An AclEntry is uniquely defined by the set (ACS, Resource, EligibleParty, sens of the right, first condition GroupID). It may deliver no rights, or a list of all-granting or all-denying StringRights. This rights list is often editable by the user. It may deliver the rights only if the EligibleParty is member of one or several given condition GroupIDs. An AclEntry may be inherited from the direct or indirect parent of a Resource, following the inner rules of the ACS. It is not possible to set an AclEntry immutable for the user, contrary of a Privilege.
Privilege is an interface responsible for modeling an entity which manages some immutable access rights or some access restrictions. The set of StringRights cannot be changed after the privilege creation. There are 7 main types of privilege, and two interfaces which are all implemented by the classes PrivileForTypeImpl and PrivilegeForLinksImpl, subclasses of Object. In the interface PrivilegeForType, the ACSObject basic type is the criteria to apply the privilege to a source or a target. The user cannot modify the sources or the targets, since he cannot change the object basic types. These privileges are then fully managed by the program after their creation. In the interface PrivilegeForLinks, the criteria to apply the privilege is the links stored by the privilege, to the source(s) or to the target(s). The user may change the sources and the targets, but not the StringRights. PrivileForTypeImpl is used between couples (ACSObject set, ACSObject set). PrivilegeForLinksImpl is used between (EligibleParty or EligibleParty set, Target or Target set) where the Target is a Resource or an VirtualFolder. For some privilege types, a source or a target may belong to an ACS which is different to the Privilege ACS. In the simplest case, they belong to only one ACS. The ACS of the target(s) are responsible to deliver or not the rights to the target(s). A Privilege is created and managed by its ACS, and it is not deleted if a source or a target is deleted. Only some PrivilegeForLinks may be inherited from the direct or the indirect parent of their single target, following the inner rules of the ACS. A Privilege may be set immutable for the user.
The Directory, Resource and VirtualFolder interfaces may then manage container-for-target cascading rights to their children, called inherited rights. In Directory, this cover both the AG rights, the AclEntry rights and the Privilege rights. In VirtualFolder, this covers only the Privilege rights. No or one rights inheritance among three is possible in the structure of a given ACS.
As interface, a Directory may manage container-for-target cascading rights to its Resource children, both for the Account/Group (AG), AclEntry and Privilege rights. Nonetheless, the generic packages handles only the AG inherited rights. The two other inherited rights should be managed in the AcsAddon packages. In fact, the creation/removing of an inherited Privilege or AclEntry in a child is not handled by the generic gBase package, while their right updatings are handled.
The container-for-target relation is an inner principle in VirtualFolder to deliver rights to its members as targets, and it manages also container-for-target cascading Privilege rights to the VirtualFolder children (not to the members). At the source side, the container-for-source relation is an inner function of GroupID to deliver rights to its members, and in GroupIDMember to deliver rights to its members and running Actors. On the other hand, Directory and VirtualFolder do not deliver source rights to the sources that are their children or members. The container-for-source principle is managed in DirectoryEP (in a future version) to deliver source rights to its children.
In the generic gBase package, there are several embedded classes with a name starting with 'C', like CNodeImpl. Such a class is a nested trait to provide a set of methods that implements a behaviour, modeling a simple concept like the privilege handling or the node handling. This is done simply by the way of Java interfaces and delegation to an inner private object. They are used in different ACSObject classes. Each instance creates one single dedicated instance of an embedded class, if it is necessary. This avoids for example to replicate the code for handling the node children into the classes DirectoryImpl and VirtualFolderImpl. The solution is to handle one mandatory or optional CNodeImpl instance into DirectoryImpl and VirtualFolderImpl. With an optional instance, the memory print of a VirtualFolderImpl instance is lowered when the CNodeImpl inner instance remains null. This principle defines the gBase embedded class pattern. This pattern may be useful for a new function used by several classes in an AcsAddon package. The embedded classes in the generic gBase are never directly used by the other packages, but they may be subclassed by an AcsAddon, just like the other gBase classes.
In the generic gBase package, each ACS and each view is saved independently. The references of a view to its members are converted to keep only the names, since the members are ACS objects. The external references between two ACS may be a bridge, a soft alias, an external GroupIDMember in the map of an exit ContextSwitch, an external AclEntry or an external linked privilege. For most of these cases, and to be fast, the in-memory Access Road base handles direct links between the objects. The saving of an ACS requires to cut the references to another ACS, and of course to restore them at the ACS opening if the reference points on a true object into an open ACS. The soft aliases do not use direct links, while this is the case for the other external ones. The names of the external objects are saved into dedicated properties in the ACS, or in the ACS object (e.g. a VirtualFolder). This feature is the responsability of the class BaseManagerImpl.
THE VIEWS
In the gBase generic package, ViewInBaseImpl and its subclasses manage the views. A view is a passive container on which Access Road processes an extended search to find the paths between the nodes of the view. There are several types of views:
ViewInBaseImpl is a subclass of FolderAbs, which is also the superclass of VirtualFolderImpl. The relation ViewInBase/member is weak, since the deleting of the container or the member does not delete the other entity.
ViewInBaseImpl has 3 subclasses, EPRViewInBaseImpl, NoThanViewInBaseImpl and SketchViewInBaseImpl. These classes are responsible for modeling a set of BaseObjects for which the GUI may provide an ARoad0.Gui2.GraphicView.
ARoad0.Gui2.GraphicView displays the current rights and links between any couple of view objects, or nodes. There is a 1:1 relation between an open ViewInBase and its GraphicView, if any.
The ViewInBases in the gBase package do not handle the rights and the links, but only the nodes in the view.
EPRViewInBaseImpl is a subclass of ViewInBaseImpl. As GraphicView, it uses an ARoad0.Gui2.GraphicEPRView. It is the most general view, because it provides the search of all the paths between all the nodes of the views. It stores the nodes and listens some basic property changes to inform its GraphicView. Such a view may be opened without been displayed in a GraphicView.
NoThanViewInBaseImpl is a subclass of EPRViewInBaseImpl. As GraphicView, it uses an ARoad0.Gui2.GraphicNoThanView. It checks up the compliance with the rights upon 2 optional rules : a maximum right and a minimum right. For each of these two criteria, the search of paths stops when it finds one path where the criterion is not fulfilled. This view stores the nodes and listens some basic property changes to inform its GraphicView. Such a view may be opened without been displayed in a GraphicView.
SketchViewInBaseImpl is also a subclass of EPRViewInBaseImpl. It has for GraphicView an ARoad0.Gui2.GraphicSketchView. It does not listen the property changes of the nodes. Such a view is never opened without a GraphicSketchView, and it is never saved.
The other package classes may listen the property changes in the gBase objects. The generic gBase package uses only the interfaces of the gBaseInterface package. Most of the classes in the generic gBase package are designed to be sub-classed in the AcsAddon gBase packages. There is a dedicated interface the AcsAddons use to declare the specific property changes the other packages have to listen on their AcsAddon objects (see the documentation of the Gui2 and gWork packages).
THE THREADS MANAGEMENT
The threads management and the event management for the views are described in Gui2.GraphicViewBaseListenerImpl. From the multi-threading point of view, the aim is to provide the best use of the processor capacities for searching the paths. The principles of the thread management are presented there only for the gBase package, as following:
most of the gBase classes implement the ACSObject interface. Their instances may be nodes in a view, and their 'get' methods are invoked in the search of access paths. The search is done in a worker thread, and the GUI may handle several views at the same time. An ACSObject 'get' method may then be acceded in the same instance by more than one thread at the same time, if the node belongs to several open views. Nonetheless, these methods provide copied or immutable values; they are short and not synchronized, to remain fast. The pattern 'value object', from Eric Evans Fowler, is not used there. It is used for instance in the String java class.
ACSImpl is a tricky case, since the frequency of calls from different threads should be far more greater than the same frequency for a single ACSObject. This is why there is very few direct accesses to ACS instances in the access paths algorithms. This is recommended also in the AcsAddons. For the rare ACS methods that are used or should be used by a view worker thread, the method documentation has the comment 'may be called from a view worker thread'. These methods are fast. Furthermore, all the ACS new/remove methods on Resource, EligibleParty, VirtualFolder, AclEntry and Privilege are never called by a view worker thread, and thay are synchronized.
For the rare BaseManagerImpl methods that are used or should be used by an ACS add-on, the documentation contains a comment 'may be called from a view worker thread'. These methods are fast and synchronized.
BaseUtilityImpl is not used by the view core algorithms, and it provides methods for the updating of the gBase object properties. The class UtilityImpl provides some core algorithms to the views. Each view handles an instance of this class, to perform an efficient multi-threading without thread collision. This class is stateless.
THE MANAGEMENT OF THE ACS ADDONS
The principles of the AcsAddon management for the gBase package are presented hereinafter:
The AcsAddon pattern allows a programmer to add more easily to Access Road some Java classes for implementing new gBase and/or new gWork functions. This pattern may be used when the generic packages do not provide the required functions to simulate of a new software.
The first solution to study is always to code the creation of a new type of ACS in gDMak.ActionNewACSyst and gWork.AcsFactory, using the current gBase and gWork packages. Otherwise, a first alternative is to modify directly the code of these generic packages. This is more powerful, but may be much more complex. Furthermore, the compatibility with the future Access Road versions becomes an important issue. It requires also an extended test.
On the other hand, with the AcsAddon pattern, the interfaces of the new classes with the Access Road generic packages are designed to be stable and relatively small. The AcsAddon pattern is based on the subclassing of some generic gBase and gWork classes. Only the new functions are coded, and most of the current Access Road code is reused. For these reasons, the resulting code is much more easy to test and maintain.
The user cannot derive by hand a new set of ACS generic properties from an AcsAddon. Any configuration of the generic properties is handled, controlled and applied in the generic algorithms, at and after the ACS creation. On the other hand, the specific algorithms of an AcsAddon cannot apply any combination of the ACS generic properties, but only the set its AcsFactoryForAcsAddon has build up.
Each AcsAddon has exactly 4 specific Java packages. There is a strict policy for the naming of these packages. Names are derived from the AcsAddon name, like 'ARoad0.AcsAddon.Accbee.Ubuntu.gBase' for the gBase package for the AcsAddon Ubuntu from the editor ACCBEE. The AcsAddon may include a gBase package, with its gBaseBeanInfo and its gBaseInterface packages. It always includes a gWork package, with at least an ARoad0.Pattern.AcsFactoryForAcsAddon implementation to create the ACS. In the simplest case, an AcsAddon contains only one AcsFactoryForAcsAddon and one subclass of any generic gBase or gWork class. But in all cases, the 4 directories for the 4 AcsAddon packages have to be defined. Otherwise, the program detects the issue and it does not start.
Usually, most of the classes in the gBase package of an AcsAddon are subclasses of the generic gBase classes. These classes can be visible to all the program, or they can extend an embedded generic class like CNodeImpl. In this latter case, they are used and known only by the classes of their own package, or a derived package. The AcsAddon gBase classes implement the gBaseInterface interfaces of their AcsAddon, if any. Most of the AcsAddon.gBase classes may be viewed as having a double inheritance: one from a generic gBase class, and one from a set of methods that are duplicated in each class to implements an AcsAddon interface. If the AcsAddon.gBase class simply overrides a method of a generic gBase class, there is no double inheritance. Ubuntu is an example of AcsAddon with a double inheritance for its gBase classes. It may be studied as an application of the AcsAddon pattern.
In an AcsAddon, the ACS may define new booleans in the ACS structure, and new formal rules in the ACS rules. The formal rules have to belong to a registered catalog of rules which is maintained by the ACCBEE company. The aim is to facilitate the reusing of formal rules. Like the other formal rules, the AcsAddon specific formal rules are displayed in the beamer. It is possible to complement them with informal rules to explain freely the simulation.
The generic packages handle fully the AG inherited rights, and this is not true for the ACL and LPRI inherited rights. For them, the generic gBase package provides some basic methods on Resource and VirtualFolder to set and get the inherited rights. But there is no code to update the ACL and LPRI inherited rights in the children of a node, as it is done for example in the MySQL AcsAddon. On the other hand, the generic gWork package offers a basic processing of the three inherited rights in the access path search. These generic gWork functions may also be extended in an AcsAddon.
In an AcsAddon, to process the AclEntry or PrivilegeForLinks inherited rights, it is mandatory to code how the Directory or VirtualFolder creates and removes the inherited PrivilegeForLinks or AclEntry in its direct children. This may include the choice of the objects that becomes inherited ones, and the definition of an order to select them in each target. The default behavior, in the generic gBase package, is to inherit all the applicable AclEntries or PrivilegeForLinks, and to sum up all the rights. After the creation to code, the right updating of the inherited object is handled by the generic gBase classes. It may also be necessary to code a LinkRightsImpl subclass in the gWork package. Examples are for overriding some of the five 'ThroughNodesTree' methods and the method mergeInheritedAclPriRightsThroughNodesTree which implement the rights inheritance algorithms.
The generic gBase package provides an embedded CAliasImpl class to set and get the hard alias and the soft alias of an ACSObject. There is no generic code to define when a reference object has an alias, nor to allow the user to set an alias through the GUI. The reason is the alias function is truly intrinsic to a given simulation in an ACS, as it is done for example in the MySQL AcsAddon. There are internal aliasing in an ACS, and also external aliasing. It is the responsibility of the ACS associations to set an internal alias for one of the ACS objects. AcsAddons are not required for the internal aliasing, but they may use it. On the other hand, the external Alias relation is always set by a gBase class in an AcsAddon, never by the generic gBase classes. In the two cases, each ACS is responsible to script or to code its proper use of the alias types. A typical application is to script an association for a new ACSObject, for creating the internal alias of the ACSObject. The generic gWork package offers the processing of the two types of alias in the access path search. These generic gWork functions cannot be extended in an AcsAddon.
An AcsAddon must have a 'acsaddon_guide.html' file in the AcsAddon gBase directory, as the first user guide. In this same directory, it may provide an icon for the ACS, at the format JPEG.
A typical application of the AcsAddon pattern is for adding a new search algorithm. It may be necessary to handle differently the typed privileges. In that case, a LinkRightsImpl subclass is defined to override the four 'PrivilegeForType' methods.
An AcsAddon may be based on another AcsAddon. In that case, it is recommended to not change the ACS generic properties without a thorough validation. It is better to never modify these properties. On the other hand, an AcsAddon may very simply change the displayed name of a generic property. The generic property 'SoftAlias' is a list of names in the interface ImmutableBasic, to get the soft aliases of an ACSObject. It is used by the MySQL AcsAddon which does not manage the ACS soft aliasing at all. To avoid unusuful coding, this AcsAddon renames 'Soft Alias' as 'Proxy accounts' for the beamer, through the package gBaseBeanInfo. Then, the MySQL AcsAddon handles the generic property for its proper modeling needs.
To summarize, the path search algorithms are based on a full object-oriented structure. The AcsAddon pattern is based on the gBase concepts and methods in the algorithms. It is possible to add simply any additional modeling, any additional processing of an ACSObject, and to modify the generic access path search algorithms by the mean of an AcsAddon gWork package.
FOR FUTURE VERSION: The principles of the tied AcsAddons are presented hereinafter:
The tied AcsAddons are applications of the AcsAddon pattern in the context of the general ACS handling. Without this pattern, it is possible to design an ACS manually or by code, then to copy it to create an ACS image under another ACS. But the copying function has limited capacities to adapt the resulting ACS to its new context.
The tied AcsAddon pattern allows to code a specialized ACS so that it becomes easy to install it under any parent having some known properties. The ACS of the AcsAddon 'NetworkGate' may be added as child to an ACS, for handling the IP network of the parent. The tied AcsAddon ACS offer common simulation functions to any new ACS which is its parent. A tied AcsAddon ACS cannot work without its ACS parent.
THE LIMITATIONS OF THE ACCESS ROAD MODEL
The limits in the version 0.7.3 are presented hereinafter:
The next release 0.8 will model the rights on the Ubuntu resources through the MySQL server, specially when these Ubuntu resources are MySQL roots like the files which contain a MySQL table. This will imply to break the backward compatibility with the 0.7 versions.
Into a real software, a target Data Exchange Point (DEP) is sometimes accessible from any program knowing its name, or even guessing it. To model this case, we have to consider both the DEP/DEP links and the calls from any program to any DEP. This is a major issue, because the access path search would have to detect all the possible Actor relations implying the DEP. In a common operating system modeled as an ACS, this would produce a huge amount of access paths. To get an efficient simulation, Access Road handles only the explicit DEP/DEP links and the explicit program-to-DEP links into the base. This means the Access Road user has to add such a link to simulate a given call to the DEP.
The rights simulation is static and do not include the simulation of the authorized changes among the rights, by the users of a simulated software. The managing rights, that is the rights to change the current rights, may exist in the simulation, but the rights transfering to other users is not modeled, nor their impacts on the current rights. These managing rights are not used to detect the new access paths if an user would grant its proper rights to another user.
In a conditional AclEntry, if the AclEntry source is not a member of one condition group, it is necessary to listen the changes in the membership relations to update the effective rights. Rights change when the source becomes an indirect member of the condition group. This listening along a chain of groups is applied to all the groups for which the source is indirect member. However, the distance of these listened groups to the source, that is the number of intermediate groups, has to be inferior to 5. Otherwise, a new indirect membership is not detected immediately by Access Road, and the relevant views cannot be updated. The indirect membership detection is always correct at the opening of a view, whatever the membership distance source/condition group.
In the NameISTrees, only the 'tied child' and the 'alternate' relations are currently managed fully. The 'alternate' property is used for modeling the IP address of an EndPoint. For the access path search in the gWork package, there is no handling of the complex properties like the 'alternate' link and the ACS visible space.
The DirectoryEP class is not defined, but the ACS structure includes a boolean 'manage right user directory' for further works.
The 2 Privilege implementation classes handle varied types of Privileges, but the usable types in gWork are only the simple PrivilegeForType, the simple PrivilegeForLinks and the one-to-one PrivilegeForLinks.
The copy of an ACS or an ACSObject is not workable, even if some old methods exist.
ACCESS ROAD KNOWN BUGS
In the GUI, when the number of nodes is great, the full view may deliver a wrong drawing of the links, arrows and texts, all having false locations after the adding or the removing of a node.
The saving of the node positions in a full view may be wrong.
Ease-of-use: medium. The package is well structured, but the database concepts have to be well understood. There are medium-complexity algorithms to set dynamically the references between the variables, to apply the ACS structure, to define and to apply the ACS policy.
Reliability: medium-high. The main execution paths have been well tested.