Access Road Architecture Access Road ArchitectureFunctional Quality Matrix | Non-Functional Quality Matrix | General Use Case | Access Control Analysis
The architecture is in accordance with the high-level technical means described in the quality matrix :
- a layered architecture
- IS and ACS modelers
- one generic ACS modeler
- a framework for new ACS modeler
It is a layered architecture (Layers architectural pattern, from A System of Patterns). All constituent components of a layer work at the same level of abstraction and change-rate. The lowest-level layer groups the data associated to the analysis of the access control concepts, and it has so a more stable structure and behaviour. The slow-changing layers constrains those that change faster. The layers are, from top to bottom :
- presentation layer, with generic and specialized GUI components
- decision maker layer, which demands some comments. Based on the Caterpillar's Fate pattern, packages in this layer is responsible to the work-flow, the control, the highest level decision making about the behavior of the application (see examples below). These decisions are important for having a user-friendly product. Isolate them make their maintenance easier. The aim is also to place reusable components in the lower layers.
- application logic layer, with generic and specialized workers
- database layer, with generic and specialized bases
The dynamic behavior is based on bottom-up communication. Higher layers active a chain of actions in sending an informational object to the lower layers. Data, called here "notification", moves up through the layers, but these informational objects don't reveal the structure of the information. It avoids to have data structure knowledge that spreads across the application. This structure is encapsulated in the GBase and ACSBase packages. Notifications are defined as interfaces, so any instance of any notification class that supports that interface can then be substituted for it at runtime. The common notification classes are in the CNot package. There are other internal notification classes in the other packages.
It is also a reflective architecture, following Bridge and Abstract Factory patterns from Mark Grand. The Bridge pattern allows a hierarchy of abstractions and a corresponding dynamic hierarchy of implementations. The generic ACS modeler represents the abstractions. Each specific ACS modeler is one hierarchy of implementations. Abstractions and implementations work as independent classes that are combined dynamically. The Abstract Factory pattern is used to decide which implementation class to instantiate for an abstraction object, and then to select the appropriate ACS class in a given context. In Access Road, the generic ACS modeler can be an autonomous component. So, the Abstract Factory pattern helps to link the GUI actions to the generic ACS modeler or to any specific ACS modeler. Specific ACS modelers are dynamically loaded by Access Road, without compilation of code.
The IS modeler and the generic ACS modeler are in the Gui2, GDMak, GWork and GBase packages. Specific ACS modelers are in the ACSGui, ACSDMask, ACSWork and ACSBase packages. There is one set of these four packages for every specific ACS modeler.
An example of decision maker is the user-role-based access control to the Access Road application (general use cases). A second example of decision maker is the abstract factory manager, that dialogs with the user to define the parameters of the ACS modeler to load, and then calls the abstract factories in each loaded ACS package (diagram).
The framework for a new specific Access Control System modeler is based on :
- the generic packages in every layer
- the example of the generic packages use in the specific ACS modelers that are implemented
UML class diagram is used, rather than package description as stated by the UML principles. It is due to the limits of the UML diagram designer that doesn't draw package diagrams.
Class diagram of the Access Road's packages (as a design description, like CRC cards) :
Comments of the non-UML diagram conventions :
- interfaces in the diagram represent PACKAGES in the implementation architecture of Access Road
- the unique variable (following UML) describes here, by his name, the responsibility of the package
- the optional methods (following UML) are here the derived responsibilities of the package
- the dependence links describe the non-transitive collaborations between packages
- the inheritance links represent numerous inheritance links between the classes of the two packages.Functional Quality Matrix | Non-Functional Quality Matrix | General Use Case | Access Control Analysis
© Copyright 2000 TPA Conseil - All Rights Reserved.
