tutorial magic draw uwe
TRANSCRIPT
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.