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» (
)
and «processing» (
).
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» (
)
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.
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.
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.
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.
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.
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» (
) classes. As specified in the requirements,
the terms of service and the introduction
links in the menu can be accessed by everyone.
Figure 6 shows the navigation menus of the secure address book
The «session» (
) 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» (
) 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» (
) {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» (
) 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.
Figure 7 shows the main navigation state diagram of the secure address book
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» (
) - 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» (
).
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»
(
). 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.
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.