UserManagement subsystem

ManagementSubsystem and HotspotManagementSubsystem have been designed with the same reas- oning. The first thing to discuss is the partitioning of the subsystem in packages. The subsystem has been partitioned in three packages: Controllers, GUI and Models. The Model-View-Controller ar- chitecture forms the basis for this partitioning. For this project this architecture has been slightly modified. One of the reasons for this is the fact that the application is not a normal GUI application. Instead it is a web application which is initiated upon an incoming request from a web browser. After this sole request is handled, the instance of the application is terminated and the application server will wait for new requests. This means that no event handling takes place and that a sequence of interactions with the user is handled by as many instances of the application. For the MVC archi- tecture this means that there's no subscribe/notify protocol. Further, since there's no active instance of the application, each request is initiated by a Dispatcher class, which in turn calls the GUI. This GUI in turn calls the Controller. From this point on the MVC is the same as usual. For the sake of simplicity, the View is implemented by the GUI also, which actually means that when the GUI calls the controller it waits for the output as delivered by the controller. When the GUI receives this out- put, it sends it to the user.

3.4.1.1. UserManagementModels package

The models have been designed with especially one goal in mind: easy expandability. It is preferred that models are as autonomous as possible. One well known way of abstracting the internals of a model is by the use of get/set methods (in the diagram above denoted by the general names getAT- TRIBUTE() and setATTRIBUTE(), as there are quite a few attributes to get and set). In addition to this, check methods have been created. These methods perform various checks on the contents of a particular attribute, perhaps to check whether it has a valid value, whether the value is within a cer- tain range or whether it contains valid characters. Each model has a global check() method, which in turn calls all defined check methods of the model. When, for example, the data of the model has to be stored in a database, this method can be called first to check upon validity of the data.

Furthermore, each model has an update() method and a toDataArray() method. The update method updates several attributes of the model at once. It accepts a well-formed associative array (array in- dexed by strings), of which the indexes are taken to be the attribute names, and the values are taken to be the new contents of the attributes. This method actually calls the set method for each named at- tribute. The toDataArray() method acts like the toString() method which is regularly used in Java. But instead of creating a string representation of the object, it creates the well-formed associative ar- ray that is needed by update(). All this has been done to ease the handling of the models and the storage of the data of the models. This is because the database functions of PHP in fact accept well- formed associative arrays when doing an insert or update query. Furthermore, doing a select query returns a well-formed associative array. In other words, when we want to store a model, we only have to call the toDataArray of a method, and pass the resulting array to the respective database function. When we retrieve data from the database, we can just create a new model and pass the re- turned array to the constructor (which in turn calls update).

Besides the models themselves, collection classes are contained within the Models packages. Basic- ally the collections provide methods in order to keep the collections current: add, set (used to update an already existing instance of an item in the collection), get and delete. Besides the basic function- ality, a collection can expose more methods for extra functionality. For example methods which can get an item based on different criteria (getAccountByName), or methods which can set a particular attribute of the models contained in the collection which are not supposed to be manipulated directly (storeNetworkAnnouncement).

Figure 3.4. UserManagementGUI class diagram

As discussed above, the GUI classes perform two functions: getting input from the user, passing it on to the controllers and showing the data of a model to the user. For these purposes the GUI classes expose basically two types of methods: process- and show-methods. For simple use cases a GUI only contains one show and one process method. For management use cases, a GUI contains process and show methods for each basic operation (add, view, edit, delete) if applicable. Furthermore, each GUI contains an init() method which is always called in order to do some preprocessing of the en- vironment as offered by the application server. Based on the situation either only the GUI is shown (when the respective GUI wasn't loaded yet) by init(), or init() first calls the respective process method, followed by a call to the respective show method. When init() finishes, it returns control and its output to the Dispatcher that called him. The Dispatcher then sends the output to the user.

Figure 3.5. UserManagementControllers class diagram

The controllers are the classes which instantiate changes in the state of models. They keep instances of the collections which they maintain, and perform manipulations on the methods contained within these collections.