Tutorial - Requirements Model (Spanish)

In UWE el modelado de requisitos consiste de dos partes:

Casos de uso de la aplicacin y sus relaciones
Actividades describiendo los casos de uso en detalle
Casos de Uso
Nuestro ejemplo es simple, por ello no es absolutamente necesario comenzar modelando los
casos de uso, pero sirve para ilustrar las funcionalidades de nuestra aplicacin: el usuario
debe poder realizar bsquedas en la libreta de direcciones y borrar contactos.
Adicionalmente, contactos pueden ser creados y actualizados, cambios deben ser archivados
o pueden ser cancelados. En este ejemplo con fines de claridad, nos limitamos a las
funcionalidades descriptas, pero aconsejamos modelar tantas como se deseen.
En UWE se distinguen casos de uso estereotipados con browsing y con processing para
ilustrar si los datos persistentes de la aplicacin son modificados o no. "SearchContact" por
ejemplo, modela la bsqueda de contactos y por ello lleva el esterotipo browsing pues los
datos son solamente leidos y presentados al usuario. Los otros casos de uso por el contrario
modelan cambios, lo que se especifica con el estereotipo processing.
stereotype-names and their icons
browsing processing
webUseCase


Actividades
Como con casos de uso solamente es posible capturar poca informacin, cada caso de
uso puede ser descripto ms detalladamente mediante un proceso. Es decir, las acciones
que son parte de un caso de uso asi como los datos presentados al usuario y aquellos
requeridos como entrada de datospueden ser modelados con precisin como actividades.
nombres de estereotipos y los iconos
correspondientes
userAction systemAction
displayAction navigationAction
displayPin interactionPin
Los dos esterotipos user Action y system Action pueden ser usados anlogamente al
flujo de procesos. El estereotipo user Action es usado para indicar interacciones de usuario
en la pgina web initiando un proceso o respondiendo to un explcito requisito de
informacin. Por lo contrario, system Action describe acciones que son ejecutados por el
sistema. Ambos tipos de accionespueden ser insertados usando la toolbar.
Detalles de las estructuras de datos usadas pueden ser representadas por objetos de nodos
y pins de acciones. El objeto de nodo es usado para modelar clases de contenido y los pines
sus atributos.
Durante ingeniera de requisitos es usual determinar que datos son representados donde y
cuando. Para modelar grupos de presentacin en UWE son usados el estereotipo display
Action, mientras que los dos pines de accin estereotipados interaction Pin y display
Pin son usados para modelar la entrada y la salida de datos.
Finalmente el estereotipo navigationAction, puede ser usado para modelar opciones de
navegacin y los elementos asociados de presentacin.
Como estos estereotipos se utilizan para indicar elementos de presentacin durante la etapa
de ingeniera de requisitos, aspectos que caracterizan a RIAs pueden ser especificadas
mediante valores etiquetados para estos mismos elementos./p>
Para ejemplificar modelamos dos actividades. Primero, una actividad para el caso de uso
"CreateContact". El mismo muestra un formulario que permite al usuario entrar su nombre,
unadireccin de correo, dos direcciones y nmeros de telfono y el descargar un archivo del
tipo imagen. La direccin de correo debe ser validada durante la entrada de datos y el
nombre de la ciudad completado automticamente en funcin del cdigo postal. El formulario
completado por el usuario es finalmente salvado en la base de datos de la aplicacin.

Un segundo caso de uso que refinamos es "SearchContacts". Para este caso de uso
solamente elementos de presentacin son de inters, nos limitamos en el diagrama a ellos.
Inicialmente, la presentacin consiste de un simple formulario usado para entrar palabras
claves y un butn para el display de la lista de contactos.
La parte principal de la presentacin sin embargo, consite en la lista de contactos, que es
modelada con una accin "Contacts". Los elementos de presentacin pueden ser agrupados
adicionalmente creando acciones con una accin de jerarqua mayor, como puede
observarse para las direcciones y los nmerod de telfono.
Las dos acciones del estereotipo navigationAction modelan transiciones a otros casos de
uso. Esto es modelado la actividad del caso de uso destino como comportamiento de la
accin.

Transformaciones
Una vez que los requisitos han sido modelados, hay dos maneras de simplificar los pasos
siguientes en el modelado de contenido, navegacin, presentacin y procesos:
En vez de crear un modelo y el diagrama correspondiente manualmente, el mismo puede ser
generado con una transformacin de los datos del modelo de requisitos.
Adicionalmente, un modelo previamente generado puiede ser extendido por nuevas
clasestransformando desde el modelo de requisitos o agregando a las clases
existentes nuevos datosque son dependientes del modelo.
Tutorial - Content Model (Espaol)
Crea un nuevo diagrama de contenido. Este es un diagrama UML normal de clases, por ello
debemos pensar en las clases que son necesarias para nuestro ejemplo. Primero queremos
disponer de una clase agenda ("AddressBook") conteniendo un conjunto de contactos. Cada
contacto debe contener un nombre, y puede contener una direccin de correo, dos nmeros
de telfono y dos direcciones postales. El nombre y la direccin de correo son Strings, el
telfono y la direccin postal son clases que representan ms informacin, como se ilustra en
la siguiente figura:

Por qu necesitamos el atributo "introduccin" en la clase AddressBook? - Ello es porque
queremos almacenar all el texto introductorio de la pgina principal de la aplicacin web.
Tutorial - Navigation Model (Espaol)
En un sistema para la web es til saber como estn enlazadas las pginas. Ello significa que
necesitamos un diagrama conteniendo nodos (nodes) y enlaces (links).
Pero que es un nodo? Nodos son unidades de navegacin y estn conectados por medio de
enlaces. Nodos pueden ser presentados en diferentes pginas o en una misma pgina.
UWE provee diferentes estereotipos, los que presentaremos mediante nuestro ejemplo.
La forma ms simple de obtener un Diagrama de Navegacin bsico es utilzando
la Transformacin Content to Navigation. En este caso obtenemos para nuestro ejemplo un
diagrama que contiene ms nodos de los necesarios. Para los nodos y enlaces son usados los
estereotipos navigationClass and navigationLink:

Queremos realmente modelar el enlace desde el contacto a la direccin o el telfono? - No,
porque no son relevantes para la navegacin. Pues borremos ambos del rbol de contenido
del modelo.

AddressBook ser nuestra pgina principal del sitio web. Lo cul se indica con el tagged
value {isHome}.
Es pensable un sitio web para una agenda de direcciones con la informacin de todos los
contactos en la misma pgina web? - No es eso lo que queremos.
El objetivo es una aplicacin en la cul se puede acceder a las operaciones de
nuestro diagrama de casos de uso. Por este motivo necesitamos un sitio que provee
conexiones a diferentes nodos:


1. ContactList - cada contacto debe ser alcanzable usando un enlace desde la pgina
principal del sitio web
2. (contact)Search - buscar un contacto
3. ContactCreation - crear un nuevo contacto y visualizarlo
En UWE, puede usarse un menu, para navegar a diferentes clases. Insertar uno y
asignarle el nombre "MainMenu":

1. Podemos insertar la lista de contactos(ContactList) casi del mismo modo. El estereotipo
index es usado para listar una cantidad de objetos del mismo tipo.
Agrega las otras dos clases usando el panel de MagicUWE:
2. La clase para la bsqueda debe tener un estereotipo query. Una bsqueda implica
ejecucin de cdigo, por ello conectamos esta clase con una asociacin processLink .
3. ContactCreation es tambin un proceso, pero no uno predefinido, por ello usamos el
estereotipo processClass (modelaremos la accin asociada ms adelante).
Si un nuevo contacto es creado, es til visualizarlo luego, y en el caso de una bsqueda, se
espera la visualizacin de un lista (ContactList) con los resultados. Usamos un estereotipo
processLink para estas asociaciones salientes y dirigidas para prohibir la navegacin hacia
atrs como en el caso de ContactCreation. Esto evita la creacin por error de duplicados.

nombres de estereotipos y sus iconos
clase de navegacin men
ndice pregunta
visita guiada clase de proceso
nodo externo

(En este tutorial solamente algunos aspectos de los estereotipos de UWE son presentados.
Por favor vase User Guide and Reference para el uso general de todos los estereotipos de
UWE)
Para completar nuestro Mdelo de Navegacin (Navigation Model), tenemos que agregar la
funcionalidad faltante de borrar y actualizar contactos (ContactDeletion y ContactUpdate)
(nuevamente vase diagrama de casos de uso). Estas dos clases son ambas accedidas desde
el contacto concreto, por ello necesitamos nuevamente un men ( y lo nombramos
ContactMenu indicando que est ubicado en la pgina de cada contacto):

Tutorial - Presentation Model (Espaol)
El Modelo de Navegacin no indica cules son las clases de navegacin y de proceso que
pertenecen a una pgina web. Podemos usar un Diagrama de Presentacin con el fin de
proveer esta informacin!
Agrega una presentationPage class y agrega las propiedades con los estereotipos de
UWE en ellos para expresar, que el elemento est ubicado en una pgina web. Las
propiedades pueden anidarse, por ejemplo cada contacto (presentationGroup-property)
cubre diferentes textos y botones. Ello significa, que para cada contacto la
correspondiente direccin de correo y los correspondientes campos de telfonos y
direcciones sern visualizados en la pgina.
Recordemos el atributo "introduction" en nuestro Diagrama de contenido y agreguemos la
pginaprincipal del sitio web AddressBook conteniendo el texto introductorio (estereotipo
text). Entonces son necesarios un formulario con un campo para entrada de datos
(textInput) para el criterio de bsqueda criterion y un botn para lanzar la bsqueda. Una
cantidad arbitraria de contactos pueden ser presentados, lo que es modelado con la
multiplicidad "*".
nombres de estereotipos y sus iconos
grupo de presentacin pgina de presentacin
texto entrada de texto
ancla fileUpload
botn imagen
formulario componente de cliente
alternativas de presentacin seleccin
En los siguientes diagramas, los estereotipos son solamente representados por sus iconos.
En MagicDraw se puede configurar la visualizacin de ambos: nombres e iconos de los
estereotipos.

Mensaje, confirmacin y error de validacin (Message, Confirmation y ValidationError) son
modelados aqu, tan slo para mayor claridad aunque en la visin general de
nuestro Diagrama de Navegacin(Navigation Diagram) no son visibles. Ellos son pginas
simples visualizando un mensaje o una pregunta.

Creacin de contacto (ContactCreation) y actualizacin de contacto (ContactUpdate) son
similares la una con la otra, solamente el nombre de las pginas y el botn de "ok" son
rotulados de acuerdo con la funcionalidad correspondiente. Por ello, el estereotipo
presentationAlternatives es usado nuevamente para evitar el mltiple modelado de todo el
contenido de ambos formularios de ingreso de datos. Parece que una imagen en el caso de
ContactCreation, antes de que la imagen es subida, no tenga sentido. Sin embargo, puede
ser que en la implementacin se desee incluir una imagen por defecto...
Los atributos etiquetados {autoCompletion} y {liveValidation} son usados para especificar
que los campos de direcciones proveen funcionalidad de auto complementacin y que el
formato de la direccin de correo es chequeada automticamente.
Tutorial - Process Model (Espaol)
Hasta ahora podemos modelar muchos aspectos de nuestro sitio web. Pero no hemos
hablado en ningn momento de que aspecto tienen las acciones de nuestras clases de
proceso. El Modelo de Proceso comprende:
el Modelo de Estructura del Proceso que describe las relaciones entre las diferentes clases de
proceso y
el Modelo de Flujo del Proceso que especifica las actividades conectadas con cada
processClass.
Modelo de Estructura del Proceso
Con el fin de describir las relaciones entre las diferentes clases de proceso, creamos un
diagrama de clases, usando la transformacin de navegacin a estructura de
proceso (Navigation to Process Structure Transformation). Despues de ejecutar la
transformacin tenemos un diagrama de clases con tres clases enmarcadas con un borde
rojo:

Como puede observarse, hemos agregado otras clases para expresar, que las tres
operaciones requieren una confirmacin (recuerda nuestro diagrama de presentacin) con
una pregunta. Esto significa que si un usuario quiere borrar un contacto, un mensaje ser
mostrado, el cul deber ser confirmado con un ok para que el contacto sea borrado.
ContactCreation and ContactUpdate funcionan en forma similar, ambos heredan de la clase
abstracta ContactProcessing, asegurando que los campos de texto, que son atributos de
ContactDataInput contienen valores vlidos (por ejemplo podemos pensar en prohibir un
nombre en blanco para prevenir entradas inservibles en la base de datos). No bien los datos
han sido validados y no hay errores de validacin (ValidationError) la pgina de confirmacin
es presentada al usuario. Para ms detalles sobre las actividades, vase el prximo prrafo!
Modelo de flujo del proceso
Un flujo del proceso (flujo de trabajo) es representado como un diagrama de actividades,
describiendo el comportamiento de una clase de proceso, por ejemplo que sucede en detalle,
cuando el usuario navega a una clase de proceso (por ejemplo ContactCreation en nuestro
ejemplo).
nombres de estereotipos y sus
iconos
accin de
usuario
accin de
sistema
Podemos seleccionar nuestro diagrama de navegacin y ejecutar la transformacin de
navegacin a flujo del proceso (Navigation to Process Flows Transformation). Se han
generado tres diagramas de actividades vacios:
ContactCreation
ContactDeletion
ContactUpdate
El estereotipo user Action es usado para indicar interaciones de usuario con la pgina
webiniciando un proceso o respondiendo a un requerimiento explcito de informacin. Por el
contrario, system Action describe acciones, que son ejecutadas por el sistema. Ambos
tipos de acciones pueden ser agregadas usando la barra de herramientas (toolbar).
Felicitaciones! :-)
Este es el fin del tutorial, porque solamente se necesita UML standard para expresar lo to
express loque ocurre en estos tres procesos del diagrama de flujo del proceso.


Vase tamben los modelos de la seccin de ejemplos (example section).

Examples - Simple (static) Website
The purpose of this system is to express the requirements for Web applications that allow
navigation between static hypertext pages. This is a simple example that shows how to
express the modularization of the hypertext into pages and the elementary navigation step.
Design considerations and requirements
The system will offer an initial (home) page with an introductory text, a index to a set of
pages, and a link to an "Acknowledgement" page. The index will consist of a set of entries,
each one composed of a name and a brief description. The Acknowledgement section will
contain just text.
Each of the Web pages that can be accessed from the home page will consist of
an introductory text, an index to its sections, and a fixed set of sections ("design
considerations and requirements", "Solutions", "Discussion and comparison", "Contributors"
and "Bibliography and references"). Each of these sections will contain text, and possibly
references to external pages.
It will be possible to navigate from the home page to the rest of the pages, and from them
back to the home page (inter-page navigation). Within a Web page, it will be possible to
navigate from the index of its sections to each one of the these sections, and from them
back to the top of the page (intra-page navigation).
No passage of information from the source to the destination page occurs.
UWE models
This example was modelled with UWE Profile - v1.9 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 content,
navigation structure and presentation separately. Content elements are specified using a
plain UML class diagram, which contains classes, attributes, associations, inheritance
relationships, association classes, and further UML model elements. Figure 1 shows the
content model of the running example, with the classes defined for Project, Article, Section
and Acknowledgement.

Figure 1. The content model of the running example
The hypertext structure is described using a navigation diagram, which consists of a set of
nodes and links. UWE distinguishes among different types of nodes, such as navigation class,
menu, index and query. Figure 2 shows the navigation model of the running example. It
includes several navigation classes as Project, Article, sections such as SectionRequirements,
one index (ArticleIndex), one menu (SectionMenu), Navigation class Project is identified
as entry point of the Web application with the tagged value {isHome}.

Figure 2. The navigation structure of the Simple Web Site
Figure 3 shows the presentation model of the running example. UWE uses a class diagram
for the representation of presentation models. The container form is selected in order to
provide a more intuitive representation of pages.

Figure 3. The presentation model of the Simple Web Site

Examples - Simple Address Book
The purpose of this system is to express the extraction of object content from the domain
objects and the selection of the attributes to be published. The user shall access one page,
which publishes a list of objects. For each object a set of attributes values are displayed.
In this case the example is an address book of contacts. Each contact will contain a name,
twophone numbers (main and alternative), two postal addresses (main and alternative), and
one e-mail address.
Design considerations and requirements
The system will offer a page with an introductory text, and the list of contacts in the
agenda, which is stored in a database. For each object the set of its non-empty attributes
values will be displayed.
UWE models
This example was modelled with UWE Profile - v1.9 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 content,
navigation structure and presentation separately.
Figure 1 shows the content model of the simple address book example, with the classes
defined for AddressBook, Contact, Address and Phone. The content model is represented as a
plain UML class diagram.

Figure 1. UWE content model of the running example
The hypertext structure is described using a navigation diagram, which consists of a set of
nodes and links. UWE distinguishes among different types of nodes, such as navigation class,
menu, index and query. Figure 2 shows the navigation model of the running example. It
includes two navigation classes AddressBook and Contact. Address and Phone are not
included as they are not relevant for the navigation. Address and phone information is
included in the Contact list. Navigation class AddressBook is identified as entry point of
the Web application with the tagged value {isHome}.

Figure 2. UWE navigation structure of a simple Address Book
Figure 3 shows the presentation model of the running example. UWE uses a class diagram
for the representation of presentation models. The container form is selected in order to
provide a more intuitive representation of pages. The address book page contains an
Introduction and a list of Contacts. For each contact the corresponding email, phones and
addresses fields are displayed.

Figure 3. UWE presentation model of a simple Address Book

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 Content Role Basic Rights SecureUML Navigation Presentation
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
Rol e 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
Presentati on 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.

Ejemplos - Libreta de direcciones de Secure
Esta pgina describe la identificacin de las necesidades, la UWE contenido de modelo, el
usuario y el modelo a seguir, los modelos de los derechos bsicos y su representacin
alternativa en SecureUML, el modelo de navegacin con mquinas de estado y el modelo de
presentacin de lalibreta de direcciones seguras ejemplo.
Consideraciones y requisitos de diseo
La aplicacin web debe permitir que los usuarios registrados puedan crear varias direcciones
delibros y para agregar nuevos contactos a uno de ellos. Los visitantes no registrados slo
pueden leer una introduccin y los trminos de servicio hasta que se registren o
autenticarse, como se muestra en la Figura 1. Los administradores no pueden utilizar la
funcionalidad de libreta de direcciones, pero se les permite buscar usuarios y eliminar sus
cuentas incluyendo todos libretas de direcciones y contactos. Para los visitantes registrados
las libretas de direcciones se muestran en una columna a la izquierda de la pgina. A la
derecha se muestran los datos de contacto de la libreta de direcciones seleccionada. Cada
libreta de direcciones puede ser borrado y adems es posible crear otros adicionales. Los
contactos se pueden crear / eliminados y el usuario puede leer o actualizar los datos de
contacto, como el nombre, la imagen, la direccin postal, direccin de correo electrnico o
nmeros de telfono. Los tres ltimos elementos etiquetados, es decir, el usuario puede
especificar una etiqueta de nombre arbitrario para cada direccin de distinguir entre ellos,
por ejemplo, entre la casa y la direccin de la direccin comercial.
Modelos UWE
Este ejemplo fue modelado con UWE Perfil - v2.1 definido en el Magic Draw
16,8 CASOherramienta y est disponible como mdzip y fem .
UWE especifica aplicaciones Web tras la separacin de intereses, es decir, el modelado de los
siguientes puntos de vista por separado:
Caso de uso Contenido Papel Derechos Bsicos SecureUML NavegacinPresentacin
Use Case Modelo
El diagrama de casos de uso (Figura 1) muestra el diagrama de casos de uso que
corresponde a las consideraciones de diseo anteriores. Algunos estereotipos de UWE se
utilizan: navegacin ( ) y el proceso ( ). Se aconseja la utilizacin de proceso en
el caso de alguna entrada directa se da (como una cadena de bsqueda) o en caso de una
modificacin importante base de datos (como la creacin de una nueva libreta de
direcciones). Adems, los estereotipos pueden ser omitidos, si estn asignados a un paquete
de los padres, que en este caso se utiliza para el paquete UserManagemeNT.
El estereotipo webUseCase ( ) con el valor etiquetado {TransferType = "cif"} se utiliza
para anotar que la transferencia de datos de todo el sistema tiene que estar seguro; "Cif"
significa la confidencialidad, la integridad y la frescura.

La figura 1 muestra el diagrama de casos de uso de la libreta de direcciones seguras
Modelo de contenido
El diagrama contenido en la figura 2 no slo representa que un usuario (a partir del modelo
de usuario UWE) es el dueo de un nmero ilimitado de libros de direcciones, sino tambin
que cada libro de direcciones contiene los contactos con varios datos de contacto. El
TaggedEntry clase abstracta se asegura de que la Direccin de clases, correo electrnico y
telfono proporcionan una etiqueta tagName para cada objeto que es creado por un usuario.

La figura 2 muestra el modelo de contenido de la libreta de direcciones seguras
Modelo de conducta
En contraste con nuestro HospInfo estudio de caso, un usuario est asociado con
exactamente unpapel . Ese papel se modela como una clase, como se introdujo en el
apartado anterior, y no como una enumeracin. En este ejemplo queremos comparar nuestro
modelo de derechos bsicos UWE con el modelo SecureUML. Por lo tanto, la figura 3 muestra
el modelo a seguir UWE subyacente en la parte superior y la versin SecureUML en la mitad
inferior del diagrama. Las dos versiones difieren en el uso de instancias vinculadas frente a
clases estereotipadas con herencia.

La Figura 3 muestra el modelo de papel de la libreta de direcciones seguras
Derechos Bsi cos Model o
El derechos bsicos del modelo (Figura 4) comprende las reglas de acceso para los
contactos, los usuarios y las libretas de direcciones. En este ejemplo no modelamos el acceso
CRUD, pero en cambio los derechos de ejecucin sobre los mtodos. Algunos comentarios
estereotipados por authorizationConstraint se aaden a fin de especificar que un visitante
registrado apenas est permitido suprimir sus propios contactos y libretas de
direcciones. Adems, un administrador tiene permiso para eliminar usuarios, excepto otros
administradores. Entre otras limitaciones, como por Contact.edit () o AddressBook.create ()
son fcilmente imaginables, pero en aras de la claridad que se quedan fuera en este
ejemplo.

La figura 4 muestra el modelo de los derechos bsicos de la libreta de direcciones seguras
SecureUML Modelo
La Figura 5 muestra los mismos hechos y circunstancias con un diagrama SecureUML. Llama
la atencin que incluso este sencillo diagrama parece demasiado llena, debido a las clases de
asociacin. Diagramas SecureUML especifican los permisos mediante la repeticin de los
(mtodo) los nombres de las clases en las clases Permiso de la asociacin, mientras que el
tipo de retorno define las acciones permitidas. El resultado es que - a primera vista - es
imposible ver lo que estn limitados los mtodos, mientras que en el diagrama de
dependencias de los derechos bsicos de apuntar directamente a los mtodos restringidas en
la mayora de los casos. Si algunos de los mtodos de una clase son ejecutables y no
algunos, todos los ejecutables deben ser listados por separado en SecureUML. Esta es la
razn para evitar diagramas SecureUML en el HospInfo estudio de caso.

La figura 5 muestra la representacin SecureUML alternativa de la libreta de direcciones
seguras
Navegacin Unidos Modelo
La figura 6 representa la navegacin diagrama del men de nuestra aplicacin de libreta de
direcciones. Los elementos del men se modelan como mtodos dentro de navigationMenu
( clases). Como se especifica en los requisitos, las condiciones del servicio y los enlaces de
introduccin en el men se puede acceder a todo el mundo.

La figura 6 muestra los mens de navegacin de la libreta de direcciones seguras
La sesin ( ) ExternalArea en el diagrama de estados de navegacin (Figura 7) se
denota por las siguientes etiquetas:
{ISHOME} indica que este estado es el punto de partida de nuestra aplicacin web.
{NavigationMenu = ExternalMainMenu} conecta la ExternalMainMenu clase men con este
estado, es decir, los mens externos estn disponibles en este nodo de navegacin.
{Papeles = visitantes} define que slo las instancias de usuario que estn vinculados con la
instancia de visitantes en el modelo a seguir se les permite acceder a este estado. En este
caso, cada visitante externo automticamente toma el papel de visitante.
Despus del registro e inicio de sesin - que tanto se modela con patrones UWE - dos tipos
de reas internas se puede llegar: Una para los administradores y una separada para los
usuarios registrados que deseen administrar sus contactos. Por lo tanto los guardias en las
transiciones dirigidas a las reas internas de verificacin de derechos de acceso. Sin
embargo, las sesiones internas estn catalogadas por {} papeles etiquetas con el fin de
prohibir no autorizada el acceso directo a travs de la URL. En la figura 8 se representa el
rea interna a las personas registradas. El reto consiste en modelar nuestras dos reas de
navegacin semi-independientes (libros de direcciones y contactos) correctamente. Por esa
razn el InternalArea estado ortogonal contiene tres regiones: La primera es la
DependentArea con la navegacin de la zona de contacto. La segunda regin comprende slo
un estado independiente para la presentacin de la lista de libretas de direcciones. Se
estereotipado por coleccin ( ) con el valor etiquetado {itemType = AddressBook} que
apunta a la clase de la libreta de direcciones en nuestro modelo de contenido. La tercera
regin es necesaria para la navegacin hasta el nodo de navegacin CreateAddressBook,
como la creacin de las libretas de direcciones es autosuficiente. El cuadro de dilogo modal
para el termsofservice se modela por igual (con navigationalNode ( ) {} IsModal) como
en el mbito externo. A pesar de que tiene que tener en cuenta que tanto los dilogos estn
representados por dos estados diferentes, incluso si tienen el mismo nombre.
InnerContactArea es un estado que est anidado en el DependentArea con el fin de separar
la navegacin para la presentacin de los resultados de bsqueda y las posibilidades de
navegacin que estn disponibles despus de que el usuario ha seleccionado una libreta de
direcciones. La diferencia es que despus de que se ejecuta una bsqueda de contactos no
se pueden crear y libretas de direcciones no se pueden eliminar, ya que los contactos de la
lista podran estar ubicados en diferentes libretas de direcciones. Adems, el retorno del
estado ametrallador DisplayContact es diferente, como en el estado exterior se vuelve a
ejecutar la bsqueda para actualizar la lista de contactos resultante. La bsqueda ( )
estereotipo permite al modelador para reemplazar ct: String con un guin bajo (_), pero en
aras de la claridad, esta abreviatura no se utiliza en la Figura 8.

La figura 7 muestra el diagrama de estado de navegacin principal de la libreta de
direcciones seguro

La figura 8 muestra el diagrama de estado de navegacin para los visitantes registrados de
la libreta de direcciones seguras
Presentaci n Modelo
Como se describi anteriormente, la pgina libreta de direcciones se divide en dos partes
despus de que un visitante registrado ha iniciado sesin: Las libretas de direcciones se
muestran a la izquierda - AddressBooksArea, estereotipado por presentationGroup ( ) -
y si se ha seleccionado una libreta de direcciones, los contactos se presentan a la derecha
(ContactsArea), como se muestra en la Figura 9. Adems, hay un men en la parte superior
de la pgina, que incluye enlaces a la pgina de introduccin, de los trminos de servicio de
pop-up y a una funcionalidad de cierre de sesin, denotados por el estereotipo ancla (
). El DeleteBook botn se oculta, si se muestran los contactos de varias libretas de
direcciones despus de que el usuario ha ejecutado la bsqueda. A fin de mantener la
presentacin simple, esto no es el modelo aqu, pero la estructura de navegacin relacionado
se muestra en la Figura 8. A la derecha, una lista de nombres de contacto (ContactListEntry
[*]), o los datos de contacto de exactamente un contacto seleccionado se muestran. Esta
exclusividad se especifica por el estereotipo presentationAlternatives ( ). Para cambiar
entre ambas vistas, se utilizan los anclajes ContactListEntry y Atrs. Los datos de contacto
que pueden ser etiquetados consisten en una TagName y una TaggedEntry, en el que se
muestran los datos de contacto real.

La Figura 9 muestra un diagrama de ejemplo del modelo de presentacin de la libreta de
direcciones seguras
Ms informacin est disponible en la tesis , el apndice A y otros esquemas se pueden
encontrar en el archivo de proyecto.