Contains the classes of the second core of the program that processes the search of rights in the open views. It provides also « facade » classes for the ACS and the views. The ACS are built up by the AcsFactory class.

Generally speaking, the Access Road software 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, in layers of abstraction. This is an iterative structure-driven and abstraction-driven development process, rather than a test-driven process. This point is presented in the gBase package documentation.

We love the idea of a strong database model from which the software structures and the algorithms emerge, since this is the true nature of a simulation software. This is also true for the path search algorithms, which are the most complex part of the code. The concept of access path is modeled in the DisplayableLinkImpl class, and the concept of access link between two path nodes is modeled in the AccessControlLinkImpl class. In this case, the structures in the gWork package to find the paths may be see as oriented by the semantic geometry of the possible links between the path nodes. Again, the path search algorithms are the result of an iterative structure-driven and abstraction-driven development process.

The Access Road classes are first Plain-Old Java Objects (POJO), because we think that well-structured POJO is the proven way to have great software. Interfaces and methods are stable, and their genericityprovides high-level operations. Some robust coding patterns may then appear through the use of these classes in varied contexts, in an iterative process.

Several architectural patterns have emerged during the Access Road development, even if they are not always presented as pattern in the code documentation:

As a framework for simulators, Access Road needs to offer all these coding patterns. It provides powerful capacities to simulate a new software, and to integrate it into the GUI and the other simulations.

The generic gWork package contains the algorithms of the generic (or core) rights search. The first aim is to build up and update the current DisplayableLinkImpls in the views. Most of these DisplayableLinkImpls will be displayed in the view diagram, but not all. For instance, the MySQL server AcsAddon may find a 3-nodes path like GroupID/acl/Actor/run_under/GroupID, As such a path has no effect, it is not visible in a view diagram, although it is put in the 'See Why' text of the view. The only case where the 'See Why' text does not display a DisplayableLinkImpl is when too many paths contain the same 3-nodes sequence, for a couple of view objects. This gives an uselessly large list of DisplayableLinkImpls. For such a view couple, only 5 of these paths are displaying in the 'See Why' text.

The classes in a gWork package may handle any gBase entities and concepts, and the classes of the generic gWork package handle all the generic gBase entities and concepts. This includes the Account/Group rights, the ACL rights, the Privilege rights, the Bridge rights. They handle also the CNot package concepts, like the varied relations between view nodes that AccessControlLink defines. The generic gWork package proceeds searchs in the core algorithms also on the gBase entities of the AcsAddons. On the other hand, the AcsAddons gWork packages contains subclasses of some generic gWork classes. They have to handle properly the entities of their AcsAddon and any entity from a gBase package. For a given view, most of the algorithms in this package are naturally not used, since the processing is based on the true properties of each node in the view. But this package is designed, coded and tested to be used for all the possible states in the gBase package objects, including the about 100 properties of an ACS. The access paths are detected at the request of the views in the package Gui2. This set defines a set of classes and a required behavior which is called the access path pattern, that includes also the CNot package.

The interfaces in gBaseInterface are used extensively to analyze different ACSObjects from different AcsAddons in the generic algorithms. The AcsAddon pattern provides a mean to change the generic algorithms, and not simply to add new algorithms without modifying the generic ones.

This package contains some classes based on a classic object-oriented design. But the gWork packages are rather grounded, for the main classes, on functional programming. This approach allows to implement the access paths algorithms. The classes xxxRightsFactoryImpl are stateless. Their methods implement pure functions without secondary effects. The only instance variables are the instances of the other xxxRightsFactoryImpl classes which collaborate with it. Functions are without secondary effects since there is no instance property to update, and all the properties are in the method arguments. Thus, all the access path algorithms may be viewed as building up new ARoad0.CNot.DisplayableLinkImpls, as the result of the analysis of the rights and the structures. This is why the method main argument is the map of all the current DisplayableLinkImpls, usually named _m_l_DisplayableLinks (or _upd_m_l_DisplayableLinks to indicate it may be updated by the method, but this not a mandatory naming rule). At each method call, this map may be filled with new DisplayableLinkImpls, and at the end, Gui2.GraphicView reads the map to display the view diagram and the view 'See why' text. Managing the sequence of method calls in the rights search through the gWork classes is the responsibility of the class RightsFactory_Facade.

There are varied uses of the search paths methods:

The classes in the generic gWork package are designed following the design pattern Visitor, in the GoF design pattern collection. The package is organized by right type (AG, ACL, ...), and by path size. The gWork package is well structured, not only at the class level, but also in the body of the large methods it is necessary to have. Into the functional style, patterns of code are used and reused, and it is recommended to keep them in the future evolutions. The main searching pattern is to take a couple (A, B) of ACSObjects. There is a search of the paths from A to B for a given type of link. These paths are added at the end of all the current DisplayableLinkImpls having A as second node. New DisplayableLinkImpls are then build up, and they are inserted in the list of the current DisplayableLinkImpls of the view. This list is passed on from searching method to searching method. The process provides some new links. For each new relation, a new DisplayableLinkImpl is created. Its last AccessControlLink is updated for describing the nature of the new relation, while the other links are copied from the current link from which the new link has been created. The search ends when there is no more relation to discover from the second ends of all the current DisplayableLinkImpls.

The path search is always from the source to the target. For processing the large paths, the DisplayableLinkImpls list of a view grows up like a bunch of flowers, where the new stalks are longer and longer. At the end, only the 'flowers' which belong to the view remain, and the result appears like a spindle-shaped bunch. A second search in the sens target-to-source would improve the search speed, but this is not done for the moment.

The generic gWork package is associated in the GUI to the Gui2.GraphicView and its subclasses. They are responsible to display the DisplayableLinkImpls the gWork packages provide. Gui2.GraphicView and its subclasses also belong to the access path pattern.

The generic gWork classes are presented hereinafter:

There is an important rule for driving all the tests on the searching of access path. Whatever the size of an access path (2 nodes, 3 nodes or more), the result must be consistent. Typically, if there is a path A-B-C-D, then the following paths must also exist in the relevant views : A-B, B-C, C-D, A-B-C, B-C-D. On the other hand, if there are the paths A-B-C and C-D, then the path A-B-C-D may have to be found in a view which contains A and D, but only if C is such a 'proxy' node. To test the access path searching, it is recommanded to use a scale of paths from the size of 2 nodes, to paths from the size of 5 nodes. The most complex method CompoundRightsFactoryImpl.detectHiddenCompoundEpRights() has 3 parts, and a 5-nodes path requires one iteration in the central part of this method. This rule is very useful to deliver a reliable code, since the code for finding the 2-nodes paths, the 3-nodes paths and the larger paths is partially independant.

It is quite easy to add a new access path search in the generic gWork package, if the responsibility of each class and the code patterns are well understood. For instance, the VirtualFolder type EP_VFolder was, in a first non-published version, reserved for having only EligibleParties as members. It appears this was too restricted, for example to model the MySQL views where table columns (as Resources) and stored functions (as Actors) may be members. To add Resources in EP_VFolder VirtualFolder, the controls in the method addEorBaseObject() was simply changed in the class VirtualFolderImpl of gBase package. There was no change to do in the GUI packages. For the access path search, the only evolution was in the processing of a VirtualFolder member being the source of a relation, as an EligibleParty, since there is now the case where the member is not an EligibleParty. This was analyzed simply in two methods of the core algorithms: ThreeNodesRightsFactoryImpl.selectOneHiddenNodePathsForVirtualFolder(), and CompoundRightsFactoryImpl.detectHiddenCompoundEpRights(). This is why handling Resources in EP_VFolder VirtualFolders induces to add no more than 10 lines of code in these two generic gWork methods.

Even if adding a function may be very straightforward, the generic gWork package contains complex algorithms for the access path search. Typically, the processing from an intermediate node to another intermediate node, in a large path, requires many different tests. This implies to consider 19 cases, including 7 tests if the first intermediate node is an Actor, 8 tests for a GroupIDMember, 4 tests for a VirtualFolder, and 3 special tests for the AcsAddons on Actor, GroupIDMember and VirtualFolder. To have a look on the complexity of the access paths among the generic gBase objects, let's see the list of such paths in the documentation of the method detectOneHiddenNodeCompoundRights(), in the class gWork.ThreeNodesRightsFactoryImpl. This method detects about 100 different forms of paths of 3 nodes in a given view.

A more complex example of gWork evolution is for the Alias relation. Two ACSObjects may be associated by an alias relation, where the first object is called a reference and the second object is called its alias. This is used in the MySQL AcsAddon. After the adding of the CAliasImpl class in the gBase package, there are numerous new access paths to detect in the gWork package. Considering only the 3-nodes paths, many new paths become possible because alias is a very extended relation, applicable to all the ACSObjects. 41 new paths appear in the ThreeNodesRightsFactoryImpl class, like the path 'ep virtual folder/virtual member/actor/alias/reference'. Three methods are added in CompoundRightsFactoryImpl to detect the direct and indirect Alias paths. The searching for large paths has to be completed. The overall effort to handle the Alias relation in the generic gWork package has produced about 130 lines of new code in CompoundRightsFactoryImpl, and the same number of lines in ThreeNodesRightsFactoryImpl. In this specific example, the ratio 'number of new paths'/'number of new lines of code' is quite good, but there is a large number of test cases for validating the new code.

The thread management pattern and the event management pattern for the views are described in the documentation of Gui2.GraphicViewBaseListenerImpl. With the view threads, the first aim is to update quickly the access paths of a view when a property has changed in a view node. This is why it is done outside the event dispatch thread and the main thread, in a pool of worker threads managed by Gui2.ViewModel. The worker threads work also at the view creation or opening. The maximal number of worker threads for the views is set to 3 by code in Gui2.ViewModel. For the generic gWork package, the main principles are:

With the AcsAddon pattern, the path search algorithms are designed in an object-oriented structure. This pattern allows to make use of the generic nature of the gBase concepts in the algorithms. It is possible to add an additional processing, or to alter the generic algorithms, by the mean of new AcsAddons gWork packages.

A simple example of use is the simulation of high-level requirements for roles, in the Workbench software, to design the MySQL Server rights. The generic algorithms deliver an efficient simulation of roles, like for the RBAC application. But it is not suffisant to simulate the roles in the MySQL Workbench, where the ACL of the role has to be copied, in the ACS of the targetted MySQL Server, as the ACL of each user that is member of the role. The MySQL Workbench software is simulated as a subACS into the MySQL Server ACS. In the gBase package of the ACS addon for MySQL, a subclass of GroupIDMySQLImpl, called WorkbenchRoleMySQLImpl, models the Workbench role. It creates and updates each ACL of user from the role ACL. The WorkbenchRoleMySQLImpl BeanInfo displays the role ACL in the beamer as 'high-level requirements', so they cannot be seen as an effective ACL for the access paths. To get this behavior, in the gWork package of the ACS addon for MySQL, the class NodeRightsMySQLImpl has a method detectL_aclEntryRights which returns no right for all the ACL of a Workbench role. That's all! The AcsAddon pattern has allowed us, with about 100 lines of code, to define, implement and explain the concept of high-level requirements for the Workbench roles.

The use of the gWork package in the AcsAddon pattern is presented hereinafter:

This AcsAddon pattern has been described for the case where a dedicated NodeRights is associated to a view node. Since varied relations are always internal to an ACS, it is possible to use the NodeRights of another node from the same ACS. This is done for instance to find the UserID and the GroupID under which an Actor starts its running.

The main limitation of the AcsAddon pattern is to not allow any evolution of the GUI for a given ACS addon. For instance, the Sketcher is not able to display the main EligibleParties having inherited AclEntry or Privilege on a Resource, since the selection of the objects to associate to a Resource, in the Sketcher, is done in a core class, outside the AcsAddon responsibility.

The main limits in the performance of the access paths search, in the 0.7.0 version, are presented hereinafter:

Ease-of-use: medium. The core algorithms are complex, and it is necessary to well understand the CNot and gBase packages before any change. Nevertheless, the AcsAddon pattern provides powerful and simple means to add new simulations, even if all the code in this package is not well understood.

Reliability: medium. There are no known bugs.