Examples - Secure Address Book

This page describes the identification of requirements, the UWE content model, the user and role model, the basic rights models and its alternative representation in SecureUML, the navigation model with state machines and the presentation model for the secure address book example.

Design considerations and requirements

The web application should allow registered users to create several address books and to add new contacts to one of them. Non-registered visitors can only read an introduction and the terms of service until they register or authenticate themselves, as depicted in Figure 1. Administrators cannot use the address book functionality, but they are allowed to search for users and to delete their accounts including all address books and contacts. For registered visitors the address books are shown in a column on the left of the page. On the right the contact details of the currently selected address book are displayed. Every address book can be deleted and besides it is possible to create additional ones. The contacts can be created/removed and the user may read or update the contact details, e.g. the name, picture, postal addresses, email address or phone numbers. The latter three elements are tagged, i.e. the user can specify an arbitrary named tag for each address to distinguish between them, for example between home address and business address.

UWE models

This example was modelled with UWE Profile - v2.1 defined in the Magic Draw 16.8 CASE tool and is available as mdzip and emf.

UWE specifies Web applications following the separation of concerns, i.e. modelling the following views separately:

Use Case Model

The use case diagram (Figure 1) depicts the use case diagram that corresponds to the design considerations above. Some UWE stereotypes are used: «browsing» (StereotypeImage) and «processing» (StereotypeImage). We suggest to use «processing» in case some direct input is given (like a search string) or in case of a significant database modification (like creating a new address book). Additionally, stereotypes can be omitted, if they are assigned to a parental package, which in this case is used for the UserManagement package.

The stereotype «webUseCase» (StereotypeImage) with the tagged value {transferType="cif"} is used to annotate that the data transfer of the whole system has to be secure; "cif" stands for confidentiality, integrity and freshness.

UWE solution modelled with MagicDraw

Figure 1 shows the use case diagram of the secure address book

Content Model

The content diagram in Figure 2 not only depicts that a user (from the UWE user model) is the owner of an unlimited number of address books, but also that each address book contains contacts with several contact details. The abstract class TaggedEntry makes sure that the classes Address, EMail and Phone provide a tagName label for every object which is created by a user.

UWE solution modelled with MagicDraw

Figure 2 shows the content model of the secure address book

Role Model

In contrast to our HospInfo case study, a User is associated with exactly one role. That Role is modelled as a class, as introduced in the previous section, and not as an enumeration. In this example we want to compare our UWE basic rights model with the SecureUML model. Therefore Figure 3 shows the underlying UWE role model in the upper and the SecureUML version in the lower half of the diagram. The two versions differ in the use of linked instances versus stereotyped classes with inheritance.

UWE solution modelled with MagicDraw

Figure 3 shows the role model of the secure address book

Basic Rights Model

The basic rights model (Figure 4) comprises access rules for contacts, users and address books. In this example we do not model the CRUD access, but instead the execution rights on methods. Some comments stereotyped by «authorizationConstraint» are added in order to specify that a registered visitor is just allowed to delete his own contacts and address books. Furthermore, an administrator has the permission to delete users, except other administrators. Other constraints, as for Contact.edit() or AddressBook.create() are easily conceivable, but for the sake of clarity they are left out in this example.

UWE solution modelled with MagicDraw

Figure 4 shows the basic rights model of the secure address book

SecureUML Model

Figure 5 shows the same facts and circumstances with a SecureUML diagram. It is noticeable that even this simple diagram looks overfilled, because of the association classes. SecureUML diagrams specify the permissions by repeating the (method) names of the classes in the «Permission» association classes, while the return type defines the allowed actions. The result is that - at the first glance - it is impossible to see which methods are constrained, whereas in the basic rights diagram dependencies directly point to the restricted methods in the majority of cases. If some methods of a class are executable and some not, all executable ones have to be listed separately in SecureUML. This is the reason for avoiding SecureUML diagrams in the HospInfo case study.

UWE solution modelled with MagicDraw

Figure 5 shows the alternative SecureUML representation of the secure address book

Navigation States Model

Figure 6 depicts the navigation menu diagram of our address book application. The menu items are modelled as methods within «navigationMenu» (StereotypeImage) classes. As specified in the requirements, the terms of service and the introduction links in the menu can be accessed by everyone.

UWE solution modelled with MagicDraw

Figure 6 shows the navigation menus of the secure address book

The «session» (StereotypeImage) ExternalArea in the navigation states diagram (Figure 7) is denoted by the following tags:

  • {isHome} indicates that this state is the starting point of our web application.
  • {navigationMenu=ExternalMainMenu} connects the menu class ExternalMainMenu with this state, i.e. the external menus are available in this navigational node.
  • {roles=visitors} defines that only user instances which are linked with the visitors instance in the role model are allowed to access this state. In this case every external visitor automatically takes on the visitor role.

After the registration and login - that are both modelled with UWE patterns - two types of internal areas can be reached: One for the administrators and a separated one for the registered users that want to manage their contacts. Therefore guards on transitions targeting the internal areas check the access rights. Nevertheless, the internal sessions are also labeled with {roles} tags in order to prohibit unauthorized direct access via URL. In Figure 8 the internal area for registered visitors is depicted. The challenge is to model our two semi-independent navigation areas (address books and contacts) correctly. For that reason the orthogonal state InternalArea contains three regions: The first is the DependentArea with the navigation for the contact area. The second region comprises only one state for the independent presentation of the list of address books. It is stereotyped by «collection» (StereotypeImage) with the tagged value {itemType=AddressBook} that points to the AddressBook class in our content model. The third region is required for the navigation to the CreateAddressBook navigational node, as the creation of address books is self-sufficient. The modal dialog for the TermsOfService is modelled equally (with «navigationalNode» (StereotypeImage) {isModal}) as in the external area. Even though it has to be kept in mind that both dialogs are represented by two different states, even if they have the same name.

InnerContactArea is a state that is nested in the DependentArea in order to separate the navigation for the presentation of search results and the navigation possibilities that are available after the user has selected an address book. The difference is that after a search was executed no contacts can be created and address books cannot be deleted, because the listed contacts could be located in different address books. Furthermore, the return from the DisplayContact submachine state is different, as in the outer state the search is executed again to update the resulting contact list. The «search» (StereotypeImage) stereotype allows the modeller to replace ct:String with an underscore (_), but for the sake of clarity this abbreviation is not used in Figure 8.

UWE solution modelled with MagicDraw

Figure 7 shows the main navigation state diagram of the secure address book

UWE solution modelled with MagicDraw

Figure 8 shows the navigation state diagram for registered visitors of the secure address book

Presentation Model

As described above, the address book homepage is divided into two parts after a registered visitor has logged in: The address books are shown on the left - AddressBooksArea, stereotyped by «presentationGroup» (StereotypeImage) - and if an address book is selected, the contacts are presented on the right (ContactsArea), as depicted in Figure 9. Furthermore there is a menu on top of the page, which includes links to the introduction page, to the terms of service pop-up and to a logout functionality, denoted by the stereotype «anchor» (StereotypeImage). The button DeleteBook is hidden if contacts from several address books are displayed after the user has executed the search. In order to keep the presentation simple, this is not modelled here, but the related navigation structure is depicted in Figure 8. On the right, a list of contact names (ContactListEntry [*]), or the contact details of exactly one selected contact are shown. This exclusiveness is specified by the stereotype «presentationAlternatives» (StereotypeImage). To change between both views, the anchors ContactListEntry and Back are used. Contact details that can be tagged consist of a TagName and a TaggedEntry, in which the actual contact data is shown.

UWE solution modelled with MagicDraw

Figure 9 shows an example diagram of the presentation model of the secure address book

More information is available in thesis, appendix A and further diagrams can be found in the project file.