Tutorial Magic Draw Uwe 4g6l2p

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 debe poder realizar búsquedas en la libreta de direcciones y borrar os. Adicionalmente, os 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. "Search" por ejemplo, modela la búsqueda de os y por ello lleva el esterotipo «browsing» pues los datos son solamente leidos y presentados al . 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 y aquellos requeridos como entrada de datospueden ser modelados con precisión como actividades. nombres de estereotipos y los iconos correspondientes

Action

systemAction

displayAction

navigationAction

displayPin

interactionPin

Los dos esterotipos « Action» y «system Action» pueden ser usados análogamente al flujo de procesos. El estereotipo « Action» es usado para indicar interacciones de 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 "Create". El mismo muestra un formulario que permite al 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 es finalmente salvado en la base de datos de la aplicación.

Un segundo caso de uso que refinamos es "Searchs". 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 os. La parte principal de la presentación sin embargo, consite en la lista de os, que es modelada con una acción "s". 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 os. Cada o 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 o 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 os 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. List - cada o debe ser alcanzable usando un enlace desde la página principal del sitio web 2. ()Search - buscar un o 3. Creation - crear un nuevo o 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 os(List) 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 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. Creation 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 o es creado, es útil visualizarlo luego, y en el caso de una búsqueda, se espera la visualización de un lista (List) 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 Creation. 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 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 os (Deletion y Update) (nuevamente véase diagrama de casos de uso). Estas dos clases son ambas accedidas desde el o concreto, por ello necesitamos nuevamente un menú ( y lo nombramos Menu indicando que está ubicado en la página de cada o):

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 o («presentationGroup»-property) cubre diferentes textos y botones. Ello significa, que para cada o 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 os 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

file

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 o (Creation) y actualización de o (Update) 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 Creation, 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 quiere borrar un o, un mensaje será mostrado, el cuál deberá ser confirmado con un ok para que el o sea borrado. Creation and Update funcionan en forma similar, ambos heredan de la clase abstracta Processing, asegurando que los campos de texto, que son atributos de DataInput 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 . 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 navega a una clase de proceso (por ejemplo Creation en nuestro ejemplo). nombres de estereotipos y sus iconos acción de

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:

  

Creation Deletion Update

El estereotipo « Action» es usado para indicar interaciones de 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 age 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 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 s. Each 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 s 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, , 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 . Address and Phone are not included as they are not relevant for the navigation. Address and phone information is included in the 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 s. For each 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 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 ed s to create several address books and to add new s to one of them. Non-ed visitors can only read an introduction and the of service until they or authenticate themselves, as depicted in Figure 1. s cannot use the address book functionality, but they are allowed to search for s and to delete their s including all address books and s. For ed visitors the address books are shown in a column on the left of the page. On the right the 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 s can be created/removed and the may read or update the details, e.g. the name, picture, postal addresses, email address or phone numbers. The latter three elements are tagged, i.e. the 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 Management 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 (from the UWE model) is the owner of an unlimited number of address books, but also that each address book contains s with several 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 .

Figure 2 shows the content model of the secure address book Role Model

In contrast to our HospInfo case study, a 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 s, s 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 ed visitor is just allowed to delete his own s and address books. Furthermore, an has the permission to delete s, except other s. Other constraints, as for .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 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 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 - that are both modelled with UWE patterns - two types of internal areas can be reached: One for the s and a separated one for the ed s that want to manage their s. 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 ed visitors is depicted. The challenge is to model our two semi-independent navigation areas (address books and s) correctly. For that reason the orthogonal state InternalArea contains three regions: The first is the DependentArea with the navigation for the 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 OfService 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. InnerArea 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 has selected an address book. The difference is that after a search was executed no s can be created and address books cannot be deleted, because the listed s could be located in different address books. Furthermore, the return from the Display submachine state is different, as in the outer state the search is executed again to update the resulting 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 ed visitors of the secure address book Presentation Model

As described above, the address book homepage is divided into two parts after a ed visitor has logged in: The address books are shown on the left - AddressBooksArea, stereotyped by «presentationGroup» (

) - and if an address book is selected, the s

are presented on the right (sArea), as depicted in Figure 9. Furthermore there is a menu on top of the page, which includes links to the introduction page, to the of service pop-up and to a functionality, denoted by the stereotype «anchor» (

). The

button DeleteBook is hidden if s from several address books are displayed after the 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 names (ListEntry [*]), or the details of exactly one selected are shown. This exclusiveness is specified by the stereotype «presentationAlternatives» (

).

To change between both views, the anchors ListEntry and Back are used. details that can be tagged consist of a TagName and a TaggedEntry, in which the actual 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 página describe la identificación de las necesidades, la UWE contenido de modelo, el 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ño La aplicación web debe permitir que los s registrados puedan crear varias direcciones delibros y para agregar nuevos os 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 es no pueden utilizar la funcionalidad de libreta de direcciones, pero se les permite buscar s y eliminar sus cuentas incluyendo todos libretas de direcciones y os. 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 o de la libreta de direcciones seleccionada. Cada libreta de direcciones puede ser borrado y además es posible crear otros adicionales. Los os se pueden crear / eliminados y el puede leer o actualizar los datos de o, 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 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 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 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ónPresentació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 ManagemeNT. 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 sólo representa que un (a partir del modelo de UWE) es el dueño de un número ilimitado de libros de direcciones, sino también que cada libro de direcciones contiene los os con varios datos de o. 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 .

La figura 2 muestra el modelo de contenido de la libreta de direcciones seguras Modelo de conduct a

En contraste con nuestro HospInfo estudio de caso, un 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 seguras Derechos Básicos Modelo

El derechos básicos del modelo (Figura 4) comprende las reglas de para los os, los s y las libretas de direcciones. En este ejemplo no modelamos el 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 os y libretas de direcciones. Además, un tiene permiso para eliminar s, excepto otros es. Entre otras limitaciones, como por .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 seguras SecureUML 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 seguras Navegació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 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 es y una separada para los s registrados que deseen istrar sus os. Por lo tanto los guardias en las transiciones dirigidas a las áreas internas de verificación de derechos de . Sin embargo, las sesiones internas están catalogadas por {} papeles etiquetas con el fin de prohibir no autorizada el 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 os) 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 o. 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 ofservice 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. InnerArea 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 ha seleccionado una libreta de direcciones. La diferencia es que después de que se ejecuta una búsqueda de os no se pueden crear y libretas de direcciones no se pueden eliminar, ya que los os de la lista podrían estar ubicados en diferentes libretas de direcciones. Además, el retorno del estado ametrallador Display es diferente, como en el estado exterior se vuelve a ejecutar la búsqueda para actualizar la lista de os 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 seguras Presentació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 os se presentan a la derecha (sArea), 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 os de varias libretas de direcciones después de que el 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 o (ListEntry

[*]), o los datos de o de exactamente un o seleccionado se muestran. Esta exclusividad se especifica por el estereotipo «presentationAlternatives» (

). Para cambiar

entre ambas vistas, se utilizan los anclajes ListEntry y Atrás. Los datos de o que pueden ser etiquetados consisten en una TagName y una TaggedEntry, en el que se muestran los datos de o 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.