Tutorial - Requirements Model (Spanish)

In UWE el modelado de requisitos consiste de dos partes:

Casos de uso de la aplicación 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 aplicación: el usuario debe poder realizar búsquedas 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 aplicación son modificados o no. "SearchContact" por ejemplo, modela la búsqueda 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 información, cada caso de uso puede ser descripto más 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 precisión 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 análogamente al

flujo de procesos. El estereotipo «user Action» es usado para indicar interacciones de usuario en la página web initiando un proceso o respondiendo to un explícito requisito de

información. 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 ingeniería de requisitos es usual determinar que datos son representados donde y

cuando. Para modelar grupos de presentación en UWE son usados el estereotipo «display

Action», mientras que los dos  pines de acción 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

navegación y los elementos asociados de presentación.

Como estos estereotipos se utilizan para indicar elementos de presentación durante la etapa

de ingeniería 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, unadirección de correo, dos direcciones y números de teléfono y el descargar un archivo del

tipo imagen. La dirección de correo debe ser validada durante la entrada de datos y el

nombre de la ciudad completado automáticamente en función del código postal. El formulario

completado por el usuario es finalmente salvado en la base de datos de la aplicación.

Un segundo caso de uso que refinamos es "SearchContacts". Para este caso de uso

solamente elementos de presentación son de interés, nos limitamos en el diagrama a ellos.

Inicialmente, la presentación consiste de un simple formulario usado para entrar palabras claves y un butón para el display de la lista de contactos.

La parte principal de la presentación sin embargo, consite en la lista de contactos, que es

modelada con una acción "Contacts". Los elementos de presentación pueden ser agrupados

adicionalmente creando acciones con una acción de jerarquía mayor, como puede observarse para las direcciones y los númerod de teléfono.

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

acción.

Transformaciones

Una vez que los requisitos han sido modelados, hay dos maneras de simplificar los pasos

siguientes en el modelado de contenido, navegación, presentación y procesos:

En vez de crear un modelo y el diagrama correspondiente manualmente, el mismo puede ser generado con una transformación 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 (Español)

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 dirección de correo, dos números

de teléfono y dos direcciones postales. El nombre y la dirección de correo son Strings, el

teléfono y la dirección postal son clases que representan más información, como se ilustra en

la siguiente figura: 

Por qué necesitamos el atributo "introducción" en la clase AddressBook? - Ello es porque

queremos almacenar allí el texto introductorio de la página principal de la aplicación web.

Tutorial - Navigation Model (Español)

En un sistema para la web es útil saber como están enlazadas las páginas. Ello significa que

necesitamos un diagrama conteniendo nodos (nodes) y enlaces (links).

Pero que es un nodo? Nodos son unidades de navegación y están conectados por medio de

enlaces. Nodos pueden ser presentados en diferentes páginas o en una misma página.

UWE provee diferentes estereotipos, los que presentaremos mediante nuestro ejemplo. La forma más simple de obtener un Diagrama de Navegación básico es utilzando

la Transformación Content to Navigation. En este caso obtenemos para nuestro ejemplo un

diagrama que contiene más 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 dirección o el teléfono? - No,

porque no son relevantes para la navegación. Pues borremos ambos del árbol de contenido

del modelo.

AddressBook será nuestra página principal del sitio web. Lo cuál se indica con el tagged

value {isHome}.

Es pensable un sitio web para una agenda de direcciones con la información de todos los contactos en la misma página web? - No es eso lo que queremos.

El objetivo es una aplicación en la cuál 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 página

principal del sitio web

2. (contact)Search - buscar un contacto3. 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 búsqueda debe tener un estereotipo «query». Una búsqueda implica

ejecución de código, por ello conectamos esta clase con una asociación «processLink» .

3. ContactCreation es también un proceso, pero no uno predefinido, por ello usamos el

estereotipo «processClass» (modelaremos la acción asociada más adelante).

Si un nuevo contacto es creado, es útil visualizarlo luego, y en el caso de una búsqueda, se

espera la visualización de un lista (ContactList) con los resultados. Usamos un estereotipo «processLink» para estas asociaciones salientes y dirigidas para prohibir la navegación hacia

atrás como en el caso de ContactCreation. Esto evita la creación por error de duplicados.

nombres de estereotipos y sus iconos

 clase de navegación  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 véase User Guide and Reference para el uso general de todos los estereotipos de UWE)

Para completar nuestro Mdelo de Navegación (Navigation Model), tenemos que agregar la

funcionalidad faltante de borrar y actualizar contactos (ContactDeletion y ContactUpdate)

(nuevamente véase 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 página de cada contacto):

Tutorial - Presentation Model (Español)

El Modelo de Navegación no indica cuáles son las clases de navegación y de proceso que

pertenecen a una página web. Podemos usar un Diagrama de Presentación con el fin de

proveer esta información!

Agrega una «presentationPage» class y agrega las propiedades con los estereotipos de UWE en ellos para expresar, que el elemento está ubicado en una página web. Las

propiedades pueden anidarse, por ejemplo cada contacto («presentationGroup»-property)

cubre diferentes textos y botones. Ello significa, que para cada contacto la correspondiente dirección de correo y los correspondientes campos de teléfonos y

direcciones serán visualizados en la página.

Recordemos el atributo "introduction" en nuestro Diagrama de contenido y agreguemos la páginaprincipal 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 búsqueda criterion y un botón para lanzar la búsqueda. Una

cantidad arbitraria de contactos pueden ser presentados, lo que es modelado con la

multiplicidad "*".

nombres de estereotipos y sus iconos

 grupo de presentación  página de presentación

 texto  entrada de texto

 ancla  fileUpload

 botón  imagen

 formulario  componente de cliente

 alternativas de presentación  selección

En los siguientes diagramas, los estereotipos son solamente representados por sus iconos. En

MagicDraw se puede configurar la visualización de ambos: nombres e iconos de los

estereotipos.

Mensaje, confirmación y error de validación (Message, Confirmation y ValidationError) son

modelados aquí, tan sólo para mayor claridad aunque en la visión general de

nuestro Diagrama de Navegación(Navigation Diagram) no son visibles. Ellos son páginas

simples visualizando un mensaje o una pregunta.

Creación de contacto (ContactCreation) y actualización de contacto (ContactUpdate) son

similares la una con la otra, solamente el nombre de las páginas y el botón de "ok" son

rotulados de acuerdo con la funcionalidad correspondiente. Por ello, el estereotipo

«presentationAlternatives» es usado nuevamente para evitar el múltiple 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 implementación 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 complementación y que el

formato de la dirección de correo es chequeada automáticamente.

Tutorial - Process Model (Español)

Hasta ahora podemos modelar muchos aspectos de nuestro sitio web. Pero no hemos

hablado en ningún 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 transformación de navegación a estructura de

proceso (Navigation to Process Structure Transformation). Despues de ejecutar la transformación 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 confirmación (recuerda nuestro diagrama de presentación) con

una pregunta. Esto significa que si un usuario quiere borrar un contacto, un mensaje será

mostrado, el cuál 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 válidos (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 validación (ValidationError) la página de confirmación

es presentada al usuario. Para más detalles sobre las actividades, véase el próximo párrafo!

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

 acción de usuario

 acción de sistema

Podemos seleccionar nuestro diagrama de navegación y ejecutar la transformación de

navegación 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 página

webiniciando un proceso o respondiendo a un requerimiento explícito de información. 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.

 

Véase tambíen los modelos de la sección 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 PresentationUse 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 bookContent 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 bookRole 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 bookBasic 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 bookSecureUML 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 bookNavigation 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

bookPresentation 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 SecureEsta página describe la identificación de las necesidades, la UWE contenido de modelo, el

usuario y el modelo a seguir, los modelos de los derechos básicos y su representación

alternativa en SecureUML, el modelo de navegación con máquinas de estado y el modelo de presentación de lalibreta de direcciones seguras ejemplo.Consideraciones y requisitos de diseñoLa aplicación 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 sólo

pueden leer una introducción y los términos 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 página. A la

derecha se muestran los datos de contacto de la libreta de direcciones seleccionada. Cada

libreta de direcciones puede ser borrado y además 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 dirección postal, dirección de correo electrónico o

números de teléfono. Los tres últimos elementos etiquetados, es decir, el usuario puede

especificar una etiqueta de nombre arbitrario para cada dirección de distinguir entre ellos, por ejemplo, entre la casa y la dirección de la dirección comercial.Modelos UWEEste 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 separación de intereses, es decir, el modelado de los

siguientes puntos de vista por separado:

Caso de uso Contenido Papel Derechos Básicos SecureUML  Navegación Presentación Use Case Modelo

El diagrama de casos de uso (Figura 1) muestra el diagrama de casos de uso que

corresponde a las consideraciones de diseño anteriores. Algunos estereotipos de UWE se

utilizan: «navegación» (  ) y el «proceso» (  ). Se aconseja la utilización de «proceso» en

el caso de alguna entrada directa se da (como una cadena de búsqueda) o en caso de una

modificación importante base de datos (como la creación de una nueva libreta de

direcciones). Además, los estereotipos pueden ser omitidos, si están 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 segurasModelo de contenido

El diagrama contenido en la figura 2 no sólo representa que un usuario (a partir del modelo

de usuario UWE) es el dueño de un número ilimitado de libros de direcciones, sino también

que cada libro de direcciones contiene los contactos con varios datos de contacto. El

TaggedEntry clase abstracta se asegura de que la Dirección de clases, correo electrónico y

teléfono 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 segurasModelo 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 enumeración. En este ejemplo queremos comparar nuestro

modelo de derechos básicos UWE con el modelo SecureUML. Por lo tanto, la figura 3 muestra

el modelo a seguir UWE subyacente en la parte superior y la versión 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 segurasDerechos Básicos Modelo

El derechos básicos 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 ejecución sobre los métodos. Algunos comentarios

estereotipados por «authorizationConstraint» se añaden a fin de especificar que un visitante

registrado apenas está permitido suprimir sus propios contactos y libretas de

direcciones. Además, un administrador tiene permiso para eliminar usuarios, excepto otros

administradores. Entre otras limitaciones, como por Contact.edit () o AddressBook.create ()

son fácilmente imaginables, pero en aras de la claridad que se quedan fuera en este ejemplo.

La figura 4 muestra el modelo de los derechos básicos de la libreta de direcciones segurasSecureUML Modelo

La Figura 5 muestra los mismos hechos y circunstancias con un diagrama SecureUML. Llama

la atención que incluso este sencillo diagrama parece demasiado llena, debido a las clases de

asociación. Diagramas SecureUML especifican los permisos mediante la repetición de los

(método) los nombres de las clases en las clases «Permiso» de la asociación, mientras que el

tipo de retorno define las acciones permitidas. El resultado es que - a primera vista - es

imposible ver lo que están limitados los métodos, mientras que en el diagrama de

dependencias de los derechos básicos de apuntar directamente a los métodos restringidas

en la mayoría de los casos. Si algunos de los métodos de una clase son ejecutables y no

algunos, todos los ejecutables deben ser listados por separado en SecureUML. Esta es la

razón para evitar diagramas SecureUML en el HospInfo estudio de caso.

La figura 5 muestra la representación SecureUML alternativa de la libreta de direcciones

segurasNavegación Unidos Modelo

La figura 6 representa la navegación diagrama del menú de nuestra aplicación de libreta de

direcciones. Los elementos del menú se modelan como métodos dentro de «navigationMenu»

(  clases). Como se especifica en los requisitos, las condiciones del servicio y los enlaces de

introducción en el menú se puede acceder a todo el mundo.

La figura 6 muestra los menús de navegación de la libreta de direcciones seguras

La «sesión» (  ) ExternalArea en el diagrama de estados de navegación (Figura 7) se denota

por las siguientes etiquetas:

{ISHOME} indica que este estado es el punto de partida de nuestra aplicación web.

{NavigationMenu = ExternalMainMenu} conecta la ExternalMainMenu clase menú con este

estado, es decir, los menús externos están disponibles en este nodo de navegación.

{Papeles = visitantes} define que sólo las instancias de usuario que están vinculados con la

instancia de visitantes en el modelo a seguir se les permite acceder a este estado. En este

caso, cada visitante externo automáticamente toma el papel de visitante.

Después del registro e inicio de sesión - 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 verificación de derechos de acceso. Sin

embargo, las sesiones internas están catalogadas por {} papeles etiquetas con el fin de prohibir no autorizada el acceso directo a través 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

navegación semi-independientes (libros de direcciones y contactos) correctamente. Por esa

razón el InternalArea estado ortogonal contiene tres regiones: La primera es la

DependentArea con la navegación de la zona de contacto. La segunda región comprende sólo un estado independiente para la presentación de la lista de libretas de direcciones. Se

estereotipado por «colección» (  ) con el valor etiquetado {itemType = AddressBook} que

apunta a la clase de la libreta de direcciones en nuestro modelo de contenido. La tercera

región es necesaria para la navegación hasta el nodo de navegación CreateAddressBook,

como la creación de las libretas de direcciones es autosuficiente. El cuadro de diálogo 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 diálogos están

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 navegación para la presentación de los resultados de búsqueda y las posibilidades de

navegación que están disponibles después de que el usuario ha seleccionado una libreta de

direcciones. La diferencia es que después de que se ejecuta una búsqueda de contactos no

se pueden crear y libretas de direcciones no se pueden eliminar, ya que los contactos de la

lista podrían estar ubicados en diferentes libretas de direcciones. Además, el retorno del

estado ametrallador DisplayContact es diferente, como en el estado exterior se vuelve a

ejecutar la búsqueda para actualizar la lista de contactos resultante. La «búsqueda» (  )

estereotipo permite al modelador para reemplazar ct: String con un guión 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 navegación principal de la libreta de

direcciones seguro

La figura 8 muestra el diagrama de estado de navegación para los visitantes registrados de

la libreta de direcciones segurasPresentación Modelo

Como se describió anteriormente, la página libreta de direcciones se divide en dos partes

después de que un visitante registrado ha iniciado sesión: 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. Además, hay un menú en la parte superior

de la página, que incluye enlaces a la página de introducción, de los términos de servicio de

pop-up y a una funcionalidad de cierre de sesión, denotados por el estereotipo «ancla» ( 

). El DeleteBook botón se oculta, si se muestran los contactos de varias libretas de

direcciones después de que el usuario ha ejecutado la búsqueda. A fin de mantener la

presentación simple, esto no es el modelo aquí, pero la estructura de navegación 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 Atrás. 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 presentación de la libreta de

direcciones seguras

Más información está disponible en la tesis , el apéndice A y otros esquemas se pueden

encontrar en el archivo de proyecto.