UNIVERSIDAD LIBRE DE COLOMBIAPROGRAMA PROFESIONAL DE INGENIERIA DE SISTEMAS

INGENIERIA DE SOFTWAARE I

Fundamentos de UML

Método: proceso disciplinado y rígido con el cual se generan modelos que describen aspectos propios de de un sistema o software en desarrollo, a través de una notación claramente definida.

Metodología: colección de métodos generalmente aceptados, que se aplican obedientemente en la transformación de una idea, o proyecto a producto terminado.

Notación: conjunto de diagramas normalizados que posibilitan al analista o desarrollador, describir el comportamiento del sistema (análisis) y sus detalles de arquitectura (diseño) de una forma no ambigua.

“La acción de representar un diagrama no constituye ni análisis ni diseño”

Modelos, metamodelos y herramientas

Metamodelo: descripción clara y precisa de un modelo

Modelo: resultado del análisis y del diseño

Herramienta: soporte automático de una notación

UML es el último representante de la ola MOO de los años 80 – 90, UML unifica los métodos de Booch, Rumbaught (OMT) y Jacobson, hoy en día es un estándar del OMG (Object Management Group).

UML hace uso y combina eficientemente notaciones tales como:

Modelado Orientado a Objetos

Modelado de Datos

Modelado de Componentes

Modelado de Flujos de Trabajo (Workflows)

WbH-2010

UNIVERSIDAD LIBRE DE COLOMBIAPROGRAMA PROFESIONAL DE INGENIERIA DE SISTEMAS

INGENIERIA DE SOFTWAARE I

Propósitos del lenguaje

El objetivo de UML es describir cualquier tipo de sistema en términos de diagramas orientados a objetos, ejemplos:

Sistemas de Información de uso general

Sistemas de Tiempo Real

Sistemas Embebidos

Sistemas Distribuidos

Software de Sistemas

Sistemas de Negocios

El Modelo

Elementos de UML

UML es un lenguaje estándar para escribir proyectos de software, puede ser usado para visualizar, especificar, construir, y documentar los elementos de un sistema. Constituye una forma estandarizada de documentación (conceptos, procesos de negocio, funciones del sistema, clases, objetos, Bases de datos y componentes de software reutilizables).

Los diagramas de casos de uso: describen la forma como el analista ven los requerimientos explícitos del usuario, teniendo en cuenta eventos (casos de uso), y los actores que participan en la dinámica (relaciones y dependencias) de representación, para traducir los requerimientos en un modelo efectivo de sistema. No están pensados como herramienta de diseño y no puede describir los elementos internos de un sistema, solo se usan para la comunicación con el usuario o cliente, y resultan útiles para determinar las características funcionales que deberá tener el sistema. En otras palabras, los diagramas de casos de uso modelan requerimientos explícitos del software (describen qué es lo que debe hacer el sistema, y no cómo lo debe hacer).

WbH-2010

UNIVERSIDAD LIBRE DE COLOMBIAPROGRAMA PROFESIONAL DE INGENIERIA DE SISTEMAS

INGENIERIA DE SOFTWAARE I

Caso de Uso: describen de forma concreta un grupo de actividades propias de un sistema, que produce un resultado concreto. Son descriptores de las interacciones típicas entre los usuarios y el sistema, están asociados con la funcionalidad del sistema, la interfaz externa y las relaciones con los usuarios.

Principios: Cada caso de uso se relaciona con otro caso de uso o con un actor

Cada caso de uso es por sí mismo iniciador

Cada caso de uso lleva a un resultado relevante

Actor: entidad externa (de fuera del sistema) que interactúa con el sistema, siendo normalmente activador o iniciador del caso de uso. Los actores pueden denominar personal (pe. usuarios del sistema), eventos externos al sistema o equipos de computo. Los actores no son las personas o los sistemas físicamente, son la función, el rol que desempeñan, esto significa que en una aplicación una persona física puede interactuar de diferentes formas, asumiendo diferentes roles. pe., un empleado que ofrece servicios de atención al cliente telefónicamente, toma y realiza pedidos, y elabora cuentas de cobro estaría representada en la aplicación por varios actores.

Relaciones:

Asociación: relación básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso).

Dependencia o instancia: forma particular de relación entre casos de uso, en la cual un caso de uso depende de otro, es decir, se requiere para complementar o extender la acción del caso base.

WbH-2010

UNIVERSIDAD LIBRE DE COLOMBIAPROGRAMA PROFESIONAL DE INGENIERIA DE SISTEMAS

INGENIERIA DE SOFTWAARE I

Generalización: especifica que un caso de uso hereda las características del “super” caso de uso base, y especificar además las suyas. Expresan relaciones entre elementos generales y ocurrencias de dicho elemento. Permite la reutilización de casos de uso.

Estereotipos:

<<include>>: que especifica una situación en la que un caso de uso tiene lugar dentro de otro caso de uso.

<<extends>>: que especifica que en ciertas situaciones, o en algún punto (llamado punto de extensión) un caso de uso será extendido por otro.

Taller de práctica:

Ejecute la herramienta e identifique el explorador de vistas.

En el menú Tools, seleccione Options y luego Notation, para establecer notación por defecto Unified y lenguaje por defecto Analysis.

Un modelo de proyecto en rational Rose, se almacena en un archivo con extensión .mdl.

Interface de presentación

En esta ventana destaca el explorador (browser) en la parte izquierda, desde donde se puede crear y acceder a toda la información del modelo actual, con una pequeña ventana de documentación debajo de ella, donde aparece la documentación textual asociada al elemento seleccionado en el explorador.

En la parte derecha se abren las ventanas de edición grafica que sirven para representar gráficamente un modelo; en esta área se destaca la de log, que contiene información administrativa de los modelos (fechas de creación, actualización.) junto con los errores de consistencia que se vayan produciendo (por ejemplo, durante la generación de código).

Vistas de trabajo

En el explorador de la herramienta, encontramos cuatro carpetas que representan las vistas de la arquitectura del sistema. Cada vista muestra una proyección de la arquitectura y usa un conjunto de diagramas. Por defecto, cada una de estas vistas tiene un diagrama especial, denominado Main (icono que cambia en cada vista), y una carpeta especial Associations. Cada vista se puede estructurar en paquetes, de manera tal que el diagrama Main esté formado por paquetes y sus relaciones.

Las vistas de Rose son las siguientes:

WbH-2010

UNIVERSIDAD LIBRE DE COLOMBIAPROGRAMA PROFESIONAL DE INGENIERIA DE SISTEMAS

INGENIERIA DE SOFTWAARE I

a) La Vista de Casos de Uso, Use Case View, que es la vista en la que se presenta el comportamiento deseado del sistema: en ella se encontrarían los modelos relacionados con la captura de requisitos, en esta vista se ubicarían el modelo del negocio, el modelo conceptual, el modelo de casos de uso del sistema y los diagramas de secuencia del sistema.

b) La Vista Lógica, Logical View, en la que encontraremos los modelos que muestran el vocabulario y la funcionalidad (estructura y comportamiento) del sistema, a través de un conjunto de colaboraciones que realizan los casos de uso de la vista de casos de uso (colaboraciones que se modelan mediante diagramas de clases y diagramas de interacción: secuencia y colaboración).

c) La Vista de Componentes, Component View, en la que se representa la implementación del sistema mediante componentes, la organización modular del software. Esta vista está relacionada con la gestión de la configuración del software. Los paquetes en esta vista se organizan en niveles. Un componente está relacionado con un archivo de software y un lenguaje de programación. Las clases de la vista lógica se asignarían a los componentes de la vista de componentes.

d) La Vista de Despliegue, Deployment View, en la que se modela la distribución o despliegue de los componentes a los nodos de procesamiento del sistema. Muestra la topología, distribución e instalación del sistema.

En el explorador tenemos también en una carpeta especial la opción Model Properties, que coincide con Tools/Options..., y que contiene la información de configuración del proyecto actual, incluyendo la apariencia de los elementos y las opciones de generación de código.

Para modelar un sistema, trabajamos en la vista de casos de uso.

Para crear un paquete a través del navegador:

1. Con el botón derecho del ratón y estando en el navegador sobre la Vista de Casos de Uso, haz new-package y asígnale el nombre Actividad1

Estando dentro del paquete “Actividad1”, hacemos uso del explorador, para modelar los casos de uso del sistema de prueba. Primero crearemos los actores y los casos de uso, y después crearemos el diagrama que representara el modelo.

Creando Actores:

Para crear un actor a través del explorador:

1. Haz clic con el botón derecho del ratón sobre la carpeta “Actividad1”.

2. Selecciona New Actor + Clic, en el explorador aparece un nuevo componente <<Actor>> NewClass.

3. Selecciónalo y cámbiale el nombre por el nombre “Rol1”.

WbH-2010

UNIVERSIDAD LIBRE DE COLOMBIAPROGRAMA PROFESIONAL DE INGENIERIA DE SISTEMAS

INGENIERIA DE SOFTWAARE I

4. Haz doble clic sobre el actor, que acabas de crear y observa que se edita con el estereotipo <<actor>>, si el área de documentación no es visible, actívala seleccionando del menú “View” la opción “Documentation”.

5. Pon el cursor en el área de documentación y describe el comportamiento del actor.

Creando Casos de uso:

Para crear un caso de uso a través del explorador:

1. Procedemos de la misma manera que en el caso anterior, solo que en el momento de seleccionar New, nos vamos por “Use Case”, así: “New Use case + clic”.

2. Seleccionamos el objeto que acabamos de crear y le cambiamos el nombre por “Caso1”.

3. Por documentación le agregamos una descripción que indique la función que va a realizar.

4. Repita lo mismo tres veces. Obviamente cambiando el nombre de cada caso de uso y de descripción.

Creando un diagrama:

Para crear un diagrama de casos de uso:

1. Con botón derecho del ratón, sobre el paquete “Actividad1”, crea un diagrama de casos de uso, y denomínalo “Diagrama-CU1”.

2. Arrastra sobre él los actores y casos de uso que creaste en los pasos anteriores.

3. Establece las relaciones, teniendo en cuenta que debes combinar asociación, herencia, dependencia y generalización.

Creando relaciones:

Para crear relaciones entre casos de uso:

1. Haz clic sobre el icono “Dependency or instantiates”

2. Traza la línea en el sentido correcto

3. Haz doble clic sobre la línea para hacer visible “Specification”

4. Selecciona el valor adecuado en el campo Stereotype

5. Si así lo deseas, puedes ponerle o quitarle la flecha de la relación con botón derecho/Navigable sobre la relación, cerca del extremo deseado.

WbH-2010

UNIVERSIDAD LIBRE DE COLOMBIAPROGRAMA PROFESIONAL DE INGENIERIA DE SISTEMAS

INGENIERIA DE SOFTWAARE I

Borrando elementos del diagrama:

Para borrar elementos del diagrama o del modelo:

Con la tecla Supr (botón derecho/Edit/Delete) se borra un elemento del diagrama actual, pero no del modelo. (Recuerda que el diagrama no es más que una “vista” o proyección del modelo.) Para borrar dicho elemento del modelo, se usa botón derecho/Edit/Delete from model.

Taller #1: Ejercicio propuesto

La institución educativa “Los gansitos”, promueve cursos de capacitación a los miembros de la comunidad para promover el emprendimiento y la integración social, la institución ofrece un variado catalogo de cursos, diseñados estratégicamente para soportar varias áreas de interés social. Los aspirantes solo se pueden inscribir en un curso a la vez, cuando se completa el cupo, se le asigna un docente quien debe desarrollar las temáticas ofrecidas y complementarla con los talleres aprobados por el coordinador de área, al final del curso el docente emite y registra una nota a cada estudiante según su rendimiento académico, la certificación de terminación a satisfacción se elabora si la nota obtenida por el estudiante es superior a 4,0.

El director de la academia interesado en mejorar la gestión y atención prestada a la comunidad, solicita el servicio de modelamiento de una solución a través de un diagrama de casos de uso, en donde el factor diferenciador deberá ser la documentación, indicando con precisión el comportamiento de cada componente en el sistema.

Nota: realiza el diagrama, salva el trabajo y envíalo al docente, al buzón wbh.dus@gmail.com. Solamente el archivo .mdl.

PD: solo se reciben y califican los trabajos de quienes asisten a la sesión.

WbH-2010