Aplicando Uwe - Un ejemplo didactico

Aplicando UWE Un proyecto de ejemplo

Problema Hacer un sistema web en el cual podamos cargar los distintos clubes de fútbol del país, con su información particular. Cargar diferentes ciudades del país. Asociar clubes con ciudades. Obtener el informe de los campeonatos logrados por cada club. Registro de usuario y login al sistema. (Similar a la B.D. usada en el tallercito 3)

Tareas a realizar Definir actores Definir relaciones entre actores Definir Casos de Uso para cada actor Definir capa de contenido Definir capa de navegación Definir capa de presentación Todo esto igual que lo que se debe presentar en el T.P. Recordar presentar un diagrama por página, lo más legible posible. Agrupar los diagramas en páginas contiguas para facilitar la búsqueda y corrección de los mismos.

1. Actores Definiremos dos tipos de actores: Usuario no registrado Usuario registrado El no registrado podrá leer información. El registrado podrá hacer lo mismo que el no registrado, más cargar información al sistema. Entregar una página con todos los actores del sistema y una breve descripción de los mismos en formato tabular.

1. Actores Esta sería la primera página de los diagramas. NO la primera página del documento. Este actor representa a los usuarios que no .. y tampoco .. Etc. etc. Usuario registrado El usuario no registrado representa al usuario que no posee login, que no… etc. Usuario no registrado Descripción Actores

2. Relaciones entre actores El usuario registrado puede hacer todo lo que hace el no registrado, además de sus propias funcionalidades. Debe haber un diagrama exclusivamente para denotar esto. Este diagrama, por sí solo, ocuparía la segunda página.

3. Casos de Uso por actor Hacer un diagrama por actor. En cada diagrama colocar el actor y todos los casos de uso asociados al mismo. No hace falta repetir los Casos de Uso de un actor, si la generalización ya indica que un actor está heredando los mismos de otro actor.

3. Casos de Uso por actor Un diagrama por actor. El nombre del diagrama igual al del actor donde modelaremos sus Casos de Uso. Entregar un diagrama por página. Siempre se coloca primero el diagrama del actor más sencillo (con menos funcionalidades). Todos los diagramas en formato dibujo, insertados en una página del documento en formato Word, OO, u otro. Además entregar el proyecto entero en el formato de la herramienta CASE utilizada (MD, PW, etc.)

3. Casos de Uso por actor Diagrama de un actor en particular. Notar el diagrama comprende solo los Casos de Uso particulares a este actor.

3. Casos de Uso por actor Diagrama del actor registrado. Notar es un diagrama separado del anterior. Solo comprende sus casos de uso. No es necesario repetir los casos de uso que “recibe” por herencia. Estos se denotan en la segunda página del documento. Y en el diagrama “generalización de actores”.

3. Casos de uso por actor Una vez definidos esto, pasamos agregar los esterotipos para casos de uso definidos por UWE (Navegación, Proceso, Personalización). Estos se agregan en los diagramas de Casos de Uso. No hace falta crear nuevos diagramas para esto. Si no tienen los esterotipos o no saben como crearlos, denotar que estereotipos tiene cada CU mediante notas uml sobre los mismos.

3. Casos de uso por actor Luego de esto los diagramas quedarían de la siguiente manera:

4. Capa de contenido La capa de contenido la consideramos el diagrama presentado por cada grupo de la Base de Datos. Diagrama Entidad/Relación (Tablas, campos con tipos de datos, asociaciones entre tablas, etc.). Diagrama físico (generado automáticamente por su herramienta a partir del anterior, el cual ya incluye claves foráneas, tablas intermedias, etc).

4. Capa de contenido De nuevo, presentar el diagrama en formato imagen en el documento de texto. Entregar el proyecto que contiene los diagramas en el formato de su herramienta CASE. Entregar los diagramas, exportados en formato grafico (.jpg,.png,otro) en una carpeta dentro del disco entregado.

4. Capa de contenido Para nuestro ejemplo usaremos como diagrama E/R (no olvidar el físico y script de la BD)

5. Capa de navegación Ahora pasaremos a ver un procedimiento básico para la capa de navegación. Magic Draw, utilizando el perfil UWE, nos proporciona todos los esterotipos necesarios. En nuestro ejemplo, de los requerimientos y funcionalidades de UC sabemos que tenemos que buscar clubes, cargar clubes nuevos, cargar ciudades, cargar campeonatos, etc. Nos basaremos en todas las funcionalidades para obtener la navegación.

5. Capa de navegación Conceptualmente, partiremos que el usuario se logueará primero. Posteriormente podrá buscar un club, ver los campeonatos de un club, ver los equipos en cada ciudad. Además, si es usuario registrado, podrá cargar un club nuevo, cargar un campeonato nuevo, o cargar una ciudad. A ejemplos demostrativos se omitió el login y registro de nuevo usuario en los CU.

5. Capa de navegación En algún momento tendremos que poder llegar (navegar) hasta una página de un club. O una página con los campeonatos de un club. O una página con los clubes de una ciudad. Basar en esto para saber las páginas (nodos) a los cuales se llegará y refinaremos hacia atrás. Todos estos serán nodos navegacionales. Son los casos de uso que definimos con el estereotipo <<navegacional>>

5. Capa de navegaci ón Además tendremos nodos de proceso. Los casos de uso que definimos como <<proceso>> derivarán en algún momento en un nodo de proceso. Es decir donde hay algún tipo de lógica de programación, que terminará en algún tipo de modificación de datos. En otras palabras, los casos de uso cargar club implica en algún momento poder navegar hasta una página donde cargaremos un nuevo club. Cargar ciudad, igual al punto anterior. Etcetera. Notar que un CU de <<proceso>> eventualmente implicará dos nodos. Uno de navegación (la página de carga), y el otro un nodo de proceso (la lógica de negocio donde se realiza el proceso de carga y los controles necesarios para esto). Y debe haber una asociación de proceso entre estos.

5. Capa de navegación Partimos de nuestra capa de contenido (diagrama BD)

5. Capa de navegación Vemos cuales de las tablas son importantes para nuestra navegación y las colocamos en el diagrama de navegación, junto con sus asociaciones. Los links de navegación son dirigidos. Si consideramos es necesario un link de ida y vuelta entre dos nodos, se deben colocar dos links de asociación.

5. Capa de navegación Ahora debemos eliminar las multiplicidades. Donde desde un nodo haya más de un link de navegación de salida se utiliza un menú . Si la multiplicidad del lado final del link de navegación es mayor a uno se utiliza: Index Guided tour Querie

5. Capa de navegación En la imagen anterior reemplazamos asociaciones con multiplicidad por nodos con primitivas de acceso. En la imagen vemos de color grises las clases con el estereotipo index . Ahora debemos agregar la dirección en las asociaciones. En el ejemplo anterior desde un nodo de navegación Ciudad general, pasamos a un Indice de Ciudades, de donde elegimos una y vemos los clubes de dicha Ciudad. Lo mismo de un nodo Clubes, vamos a un nodo Indice de campeonatos de Club, de donde podemos elegir uno en particular. Normalmente querríamos buscar una ciudad primero, o un club, o grupos de los mismos. Desde los resultados de la búsqueda, tener una o varias opciones de elección para ver la información de los mismo. Ahí utilizaremos queries .

5. Capa de navegación Ahora en verde tenemos las clases con estereotipo query . Las clases verdes indican un nodo donde se realiza una búsqueda (query). La misma puede tener desde cero a varios resultados. Por lo tanto se utiliza un menú (nodos con links de salida con multiplicidad mayor a uno). Desde la lista de Ciudades, podemos elegir cualquiera, para ver los clubes en dicha ciudad. Desde la lista de clubes, podemos elegir cualquiera para ver sus campeonatos. Tanto la lista de clubes, como la lista de ClubCiudad tienen el mismo contenido (un grupo de clubes) Por lo tanto en ClubCiudad podemos también elegir cualquier Club y ver sus campeonatos, lo que nos crea un link de navegación hacia CampeonatosIndex. CampeonatosIndex es un indice porque puede tener multiplicidad mayor a uno en el lado final o de salida (un club con varios campeonatos).

5. Capa de navegación También debemos ver información de usuarios, buscar usuarios, elegir un usuario de una lista, etc. De esta manera seguimos refinando el diagrama de navegación.

5. Capa de navegación Podemos ver la información general de un club desde el indice de clubes. Sin embargo ahora tendremos dos links de navegación de salida de un mismo nodo.

5. Capa de navegación De nuevo, nodos con más de un link de navegación se deben transformar en menues.

5. Capa de navegación Seguimos refinando la navegación de esta manera. Luego agregamos los nodos de proceso. Estos salen de los Casos de Uso de proceso. Los mismos implican situaciones donde haya lógica de negocio, transacciones con los datos subyacentes, etc.

5. Capa de navegación De nuevo, refinar los nodos con más de un link de salida. Y luego, definir un punto de entrada a la aplicación que será simbolizado como el home . No dejar nodos sin conección, ya que implicaría que no se puede navegar hasta ellos.

5. Capa de navegación Debemos asi refinar el diagrama hasta cubrir todas las funcionalidades, items en los requerimientos, etc. Evidentemente el diagrama puede crecer demasiado, debemos separarlo en diferentes sub-diagramas. Otra opción por navegación de cada actor. Ver también hay tres nodos de proceso, uno por cada CU de proceso (ver página 13 de este diagrama).

6. Capa de presentación Provee una visión abstracta de la interfaz del usuario. Esta basada en el modelo de navegación. No tener en cuenta temas como colores, letras, posicionamiento de los elementos dentro de la página, etc. Las clases de presentación se basan los nodos del diagrama de navegación. Es decir, tendremos una clase de presentación por cada menú, clase de navegación, primitivas de acceso ( query , guided tour , index ), y clases de proceso. Para facilitar la ubicación de la clase de presentación de un nodo de navegación se recomienda utilizar los mismos nombres para los mismos. Tomemos como ejemplo el nodo de navegación “InformaciónClub” del diagrama de Navegación. A continuación, vemos la clase de representación que corresponde a este nodo.

6. Capa de presentación Clase de presentación del nodo de navegación del mismo nombre.

6. Capa de presentación Ya tenemos una clase de presentación vacía. Para llenarla, partimos de nuestra Base de Datos. ¿Qué atributos tiene, en la BD, la tabla que produce el nodo de navegación InformacionClub, y posteriormente la clase de presentación InformacionClub?

6. Capa de presentación Vemos de nuevo nuestro diagrama de BD.

6. Capa de presentación En el nodo de presentación veremos la información relacionada a un club. De la tabla tenemos los atributos: Id Nombre Apodo Principal Apodo Secundario Estadio Año de fundación Id de la ciudad a la que pertenece (esta es una clave foranea que viaja desde la tabla ciudad)

6. Capa de presentación Cada atributo de la clase será representado con un elemento de UI. El MD y el plug-in UWE proporciona todos los esterotipos y elementos visuales e iconos necesarios para la clase de presentación. Así como un diagrama para crear los mismos. Entonces nuestra clase de presentación InformaciónClub se verá como en la siguiente página. Notar que un elemento, el nombre de la ciudad, viene de otra tabla (Ciudad), mediante un Join, con la información que se tiene con el id de Ciudad. El MD permite dibujar los elementos dentro de la clase que lo contiene, facilitando la visualización y entendimiento de los mismos.

6. Capa de presentación Notamos ahora que un club, muestra en su presentación, el nombre de la ciudad a la que pertenece. Quizás sería conveniente que del nombre de la ciudad podamos llegar a la lista de clubes de dicha ciudad. Deberíamos modificar nuestro diagrama navegacional permitiendo un link de salida desde InformacionClub hacia ClubesCiudad. Hecho esto, “ciudad” en nuestra clase de presentación ya no sería solo texto, sino un link.

6. Capa de presentación De esta manera, vamos tomando los diferentes nodos de navegación, y construyendo su correspondiente clase de presentación. Usualmente, en una misma página se presentará información de varios nodos de navegación. Para esto usamos el estereotipo page . Una página puede contener varias clases de presentación, así como grupos de presentación. Los grupos de presentación son contenedores que pueden tener grupos de presentación y clases de presentación. A continuación veremos un ejemplo de la página de ClubesMenu.

6. Capa de presentación En esta página queremos ver: El menú principal El menú de clubes Información relacionada al club (información propia, campeonatos, etc). Por lo tanto, agregamos las clases de presentación de dichos elementos a la clase (queda a cargo del alumno hacer los mismos).

6. Capa de presentación Como en los pasos previos ya deberíamos de haber creado todas las clases de presentación individuales, simplemente completamos las páginas con las clases que la componen. Recordar que los atributos salen de la BD. Y además, la navegación se hace en base a los links de navegación entre los nodos en el diagrama de navegación. También quizás necesitemos modificar nuestra navegación y tener un link a crear un nuevo club. Por lo tanto necesitamos añadir esto también a nuestros Casos de Uso, etc. Así de informacionClub puedo llegar a informacionClub y también a campeonatosIndex (diagrama de navegacion). Por lo tanto:

6. Capa de presentación Como se ve, normalmente, los query se ven en una clase con un formulario dentro. Un atributo que lleva a otro nodo, un anchor o ancla (link). Debemos realizar las clases de presentación individuales. Y posteriormente, agrupar las necesarias para ir presentando las páginas. ¿Cuántas páginas hacer? Las que representen los UC más importantes para nuestro sistema.

Conclusión Presentar todos estos diagramas. Entregar en formato electrónico en un CD/DVD correctamente identificado, en caja. El CD/DVD debe contener un archivo de texto (Word, OpenOffice, otro) con el documento completo, incluyendo los gráficos dentro del mismo. Además en carpetas ( folders ) separadas, todos los diagramas correctamente identificados en formato gráfico (.jpg,.png,otro) para poder abrirlos rápidamente. Además, en otra carpeta, el o los archivos que componen el proyecto de la herramienta CASE utilizada para modelar los diagramas. Un archivo README o LEEME en formato texto explicando que hay en cada carpeta, integrantes, breve descripción del sistema que están presentando, y cualquier otra información relevante (que herramienta CASE utilizaron, consideraciones varias, o lo que fuese necesario).

Conclusión Solo se deben entregar los diagramas solicitados. Diagramas de secuencia, actividades, escenarios, diagramas de estado, etc. NO son requeridos, y si fuesen entregados no ocasionarán pérdida ni ganancia de puntos. La fecha de entrega definitiva es el viernes 25 de septiembre de 2009, en horario de clase. Grupos que no cumplan con esta fecha de entrega, tendrán un porcentaje de penalización respecto a su nota, por día de atraso. No es necesaria una defensa del trabajo práctico en esta oportunidad.

Lic. Omar Esgaib - omar_esgaib @uca.edu.py Lic. Mauricio Merín - [email_address]

Aplicando Uwe - Un ejemplo didactico

Más contenido relacionado

La actualidad más candente (20)

Similar a Aplicando Uwe - Un ejemplo didactico (20)

Último (20)

Aplicando Uwe - Un ejemplo didactico