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:

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:

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:

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:

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:

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:

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:

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:

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:

THE MANAGEMENT OF THE ACS ADDONS

The principles of the AcsAddon management for the gBase package are presented hereinafter:

FOR FUTURE VERSION: The principles of the tied AcsAddons are presented hereinafter:

THE LIMITATIONS OF THE ACCESS ROAD MODEL

The limits in the version 0.7.3 are presented hereinafter:

ACCESS ROAD KNOWN BUGS

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.