|
Main Index
PREV
NEXT
|
As computer application systems can be comprised of a large number of separate modules, virtually every application requires some sort of menu system. This will present the user with a list of available options so that one may be easily selected for processing. In its simplest form a menu can be a single list, but in a large system the list is usually broken down into a series of separate pages, with the various pages presented in some sort of logical hierarchy.
It is not usual to allow absolutely anyone to gain access to the application, therefore some sort of security mechanism is required. The simplest method is to force each user to pass through some sort of verification process before being allowed access to the system. This verification process may be in the form of a logon screen that requires the user to input a valid combination of user identity and password. Only after these details have been successfully validated will the user be allowed to continue.
Static menus have fixed, pre-defined contents, and can be loaded very quickly with almost no overhead, but they do not offer any degree of flexibility. Dynamic menus are constructed as and when required using current information obtained from an amendable data source (ie: the menu database), but they require more processing effort. The ever-increasing speed of modern PC's makes this extra effort virtually unnoticeable; therefore dynamic menus are more readily acceptable. This allows the number of menu screens, and their content, to be altered at will simply by making changes to the data source rather than by making changes to any program code.
Although several users may be authorised to access a particular application, it may be necessary to restrict different users to different sets of functions, rather than having every user being able to access the entire set of available functions. The most common example is where User 'A' may create and update a piece of data, but User 'B' can only read it. This will require some sort of security matrix that acts as a cross-reference between users and functions.
Rather than having several functions (eg: create, read, update and delete) combined into a single module, it is the usual practice nowadays to create a separate module for each individual function. The security matrix will then be a simple cross-reference between users and modules, rather than users, modules, and functions-within-modules.
This list of modules which be accessed by a user can be referenced when constructing menu screens for that user so that only those modules which are currently accessible are actually loaded into the menu screens. This prevents the user from seeing and selecting an option on his menu only to be told that "access is denied".
This is discussed more in Appendix J: Transaction Access Profiles
An additional level of security may be required where a user has access to a particular module, but not all the items (fields) within that module. One method would be to create a different version of the module containing a different combination of items. Another would be to have a single module, but with the ability to turn off access to particular items at runtime. The latter option is more dynamic as it does not require any changes to the source code, thus new combinations of inaccessible items could be implemented at will.
This is discussed more in Appendix K: Transaction Item Access Profiles
 |
http://www.tonymarston.net |