Presentación ¿Cómo Aprender UML - CIMATcimat.mx/Eventos/seminariodetecnologias/uml.pdf · – Modelado de Comportamiento: • Diagramas de Secuencia, de Colaboración, de Estado,

Grupo de Ingeniería de Software / CIMAT

© 2007 by ESF Pres. ¿Cómo Aprender UML? / 1

Presentación

¿Cómo Aprender UML?

Grupo de Ingeniería de SoftwareCentro de Investigación en MatemáticasGuanajuato, México 2007

Desarrollada por: Efraín Salomón Flores

Correo electrónico: [email protected]



Objetivos de la Presentación• Describir las semejanzas entre el UML y el Lenguaje

Escrito.

• Mostrar la representación de los conceptos de la orientación a objetos en UML.

• Presentar un subconjunto de los diagramas de UML aplicados a un caso de estudio.



Puntos a Tratar1. Introducción2. Caso de Estudio3. Alfabeto, Palabras y Sentencias4. Modelado Orientado a Objetos5. Párrafos6. Secciones7. Documentos



1. Introducción1.1 ¿Qué es UML?1.2 UML vs Lenguaje Escrito1.3 Los Tres Aspectos de UML1.4 Historia1.5 UML y los Procesos



• Definición:– UML es un lenguaje para modelar y comunicar información

sobre sistemas, para lo cual se usan diagramas y texto.

1.1 ¿Qué es UML?

EquipoDescripción

ProyectoNombreFechaDeInicioFechaDeFin

AdministradorNombre

IniciarProyecto()TerminarProyecto()

Dirige Administra



– Un administrador dirige un equipo que trabaja en un proyecto.

– Cada administrador tiene un nombre y un número de teléfono, además puede iniciar o terminar un proyecto.

– Cada proyecto tiene un nombre, una fecha de inicio y una fecha de fin.

– Cada equipo tiene una descripción, y eso es todo lo que nos interesa con respecto al equipo.

1.2 UML vs Lenguaje Escrito

ProyectoNombreFerchaDeInicioFichaDeFin

AdministradorNombreTelefono


EquipoDescripcion

Dirige

Ejecuta

Administra



• Lenguaje– Nos permite la comunicación sobre un tema o concepto

determinado.

• Modelo– Es una representación de un tema.

• Unificado– Habla de los diferentes esfuerzos para tener un lenguaje

común.

1.3 Los Tres Aspectos de UML



• El Período de Fragmentación, entre la mitad de 1970 y la mitad de 1990.– El Método Booch `93.– La Técnica de Modelado de Objetos de James Rumbaugh.– El método de Ingeniería de Software Orientado a Objetos de

Ivar Jacobson.

• El Período de Unificación, entre la mitad de 1990 y la mitad de 1997.– James Rumbaugh y posteriormente Ivar Jacobson, se unieron

a Grady Booch para unificar sus métodos.– Inicios 1997 UML 1.0.

1.4 Historia



• El Período de Estandarización:– La OMG adopto UML y asumió la responsabilidad de su

desarrollo.– Hacia finales 1997 se libero la versión 1.1 de UML.

• El Período de Revisión:– Varios vendedores empezaron a dar soporte y promoción.– Surgieron varias versiones de UML.– Octubre 2004 y Noviembre 2005 UML 2.0

• El Período de Industrialización.– La OMG esta proponiendo que UML se convierta en un

estándar internacional a través de la ISO.

1.4 Historia



• UML es independiente de los procesos.

• Sus creadores promueven un proceso que es:– Dirigido por casos de uso (use-case driven).

– Iterativo

– Incremental

• Sin embargo UML puede ser utilizado en cualquier proceso.

1.5 UML y los Procesos



2.1 Caso de Estudio• Un sistema de administración de proyectos provee

funcionalidad para manejar proyectos, recursos y administrar el sistema.

• El administrador del proyecto: – Utiliza el sistema para administrar proyectos.

– Dirige al equipo para que lleve a cabo el proyecto dentro de las fechas de inicio y fin.

– Una vez que el proyecto es creado el administrador puede iniciarlo, y posteriormente terminarlo.



• Define las partes más simples de un lenguaje: – Letras, caracteres, signos y etiquetas.

• El lenguaje escrito esta conformado por 27 Letras.

• El lenguaje UML esta conformado por fragmentos de símbolos (rectángulos, líneas y otros elementos gráficos) y cadenas de caracteres.

3.1 Alfabeto



• Son una agrupación de elementos del alfabeto del lenguaje que definen una unidad con significado.

• Las palabras en UML son los conceptos y las relaciones.

3.2 Palabras

Proyecto

ProductoDeTrabajo

Sistema

Equipo Administrador

Requerimiento



• Son una agrupación de palabras que definen una unidad gramatical que contiene significado y una expresión sobre un tema.

• Las sentencias en UML son fragmentos de diagramas o diagramas muy simples.

3.3 Sentencias

Equipo

Proyecto

Ejecuta



• La gramática de un lenguaje especifica las reglas para poder combinar las palabras y formar sentencias.

3.3 Sentencias

Equipo

Administrador

Proyecto

Dirige Administra

ProyectoEquipo Administrador AdministraDirige



4. Modelado Orientado a Objetos4.1 Conceptos Generales y Específicos4.2 Clases, Asociaciones, Objetos y Ligas4.3 Atributos y Valores4.4 Operaciones y Métodos4.5 Mensajes y Estímulos4.6 Generalización4.7 Polimorfismo



4.1 Conceptos Generales y Específicos• Conceptos Específicos:

– Objetos.

– Ligas.

– Valores.

– Métodos.

– Estímulos.

• Conceptos Generales:– Clases.

– Asociaciones.

– Atributos.

– Operaciones.

– Mensajes.



4.2 Clases, Asociaciones, Objetos y Ligas

Equipo

Administrador

Proyecto

Dirige Administra

Juan : Administrador

: Equipo Águila : Proyecto

Dirige Administra



4.3 Atributos y Valores

EquipoDescripción


AdministradorNombre

Dirige Administra

Juan : Administrador- Nombre = "Juan Castillo Salómon"

: Equipo- Descripción

Águila : Proyecto- FechaDeFin = Enero 1, 2003- FechaDeInicio = Enero 1, 2002- Nombre = "Eagle"

= "Equipo que incluye análistas, usuarios finales, arquitectos, diseñadores, desarrolladores y examinadores"

Dirige Administra



4.4 Operaciones y Métodosclass Administrador {

String Nombre;

void IniciarProyecto (){...

}

void IniciarProyecto (Date fecha){...

}

void TerminarProyecto (){...

}}

EquipoDescripción


AdministradorNombre


Dirige Administra



Juan : Administrador

: Equipo Águila : Proyecto

1: obtenerRequerimientos2: asignarActividades

3: asignarTareas

4.5 Mensajes y EstímulosAdministrador

Equipo Proyecto

2: asignarActividades

3: asignarTareas

1: obtenerRequerimientos



• Indica que una clase específica recibe los atributos, relaciones, operaciones y métodos de una clase general.

SistemaPorcentajeCompletadoDescripciónPlataforma

Validar()Deploy()

RequerimientoPorcentajeCompletadoDescripciónMedia

Validar()Publicar()

ProductoDeTrabajoPorcentajeCompletadoDescripción

Validar()

4.6 Generalización



• Es la habilidad de tener varios métodos para una sola operación.

4.7 Polimorfismo


Validar()Deploy()


Validar()Publicar()

ProductoDeTrabajoPorcentajeCompletadoDescripción

Validar()



5. Párrafos5.1 Diagramas de Clases5.2 Diagramas de Objetos5.3 Diagramas de Casos de Uso5.4 Diagramas de Secuencia5.5 Diagramas de Colaboración



• Un párrafo es un grupo de sentencias con un tema en común.

• Los párrafos en UML son los diagramas:– Modelado de Estructura:

• Diagramas de Clases, de Objetos, de Casos de Uso, de Componentes, de Deployment, de Paquetes y Subsistemas.

– Modelado de Comportamiento:• Diagramas de Secuencia, de Colaboración, de Estado, y

de Actividad.

5. Párrafos



5.1 Diagramas de ClasesProductoDeTrabajo

PorcentajeCompletadoDescripción

Validar()

AdministradorNombreTelefono


EquipoDescripción


Validar()Deploy()



Validar()Publicar()

Entrada Salida

Administrar

Dirige

Ejecuta

EntradaSalida



5.1 Diagramas de Clases• El administrador del proyecto utiliza el sistema de administración

de proyectos para manejar un proyecto. El administrador del proyecto dirige al equipo para que lleve a cabo el proyecto dentro de las fechas de inicio y fin de dicho proyecto, una vez que el proyecto es creado en el sistema de administración de proyectos, el administrador puede iniciarlo, y posteriormente terminarlo, una vez que se haya completado o por cualquier otra razón.

• Como entrada un proyecto recibe requerimientos, y como salida, un proyecto produce un sistema. Tanto los requerimientos como el sistema son productos de trabajo, es decir productos que son creados, usados, optimizados y elaborados durante el proyecto. Cada uno de estos productos tienen una descripción, un porcentaje de completado (que se mide a través de un esfuerzo) y pueden ser validados. Sin embargo la validación depende del tipo de producto de trabajo. Por ejemplo los requerimientos son validados por los usuarios en juntas de trabajo y el sistema es validado a través de pruebas que comparan el sistema versus los requerimientos. Adicionalmente, los requerimientos pueden ser publicados utilizando diferentes tipos de medios, por ejemplo a través de una intranet o en papel; los sistemas pueden ser colocados en plataformas específicas.



5.2 Diagramas de ObjetosReq-Cliente :

RequerimientoCondor : Proyecto Solución en .Net :

Sistema

: Equipo

: Equipo

Requerimientos Comunes :Requerimiento

Halcón : ProyectoSolución en Java :

Sistema

Nombre = "Juan Pérez"Juan : Administrador

Descripción = "Este es el equipo del Proyecto Águila" : Equipo

Nombre = "Águila"Fecha de Inicio = Enero 1, 2002Fecha de Fin = Enero 1, 2003

Águila : Proyecto

Porcentaje Completado = 50%Descripción = "Este es el requerimiento para el Sistema de Administración de Proyectos"

: Requerimiento

Porcentaje Completado = 50%Descripción = "Este es el Sistema de Administración de Proyectos"

: Sistema

SalidaEntrada

Administra

Dirige

Dirige

Administra

Entrada

Administra

Dirige

Entrada

Salida

Entrada

Salida

Ejecuta

Ejecuta

Ejecuta



5.2 Diagramas de Objetos• El sistema de administración de proyectos debe manejar el

siguiente escenario:– Juan quien es un administrador de proyectos, maneja tres proyectos,

que se llaman, Águila, Halcón, y Cóndor.

– Todos los proyectos involucran equipos anónimos o sin nombre.

– El proyecto Águila esta desarrollando un sistema de administración de proyectos, similar al que se esta utilizando de ejemplo.

– El proyecto Halcón esta utilizando la plataforma Java para producir otro tipo de sistema, que esta dirigido hacia un amplio mercado.

– El proyecto Cóndor esta utilizando la plataforma Microsoft .Net para producir un sistema similar al del proyecto Halcón, pero este tiene requerimientos específicos de organización adicionales. Por consiguiente los proyectos Halcón y Cóndor comparten requerimientos comunes.



5.3 Diagramas de Casos de Uso

• Descripción General.

• Actores.

• Precondiciones.

• Flujo Principal de Eventos.

• Flujo Alternativo (Excepciones).

• Poscondiciones.

• Escenarios.

AdministradorDelProyecto

AdministrarProAdministrarProyecto




Administracion del proyecto y Actividad del RegistroAdministrador de Proyecto

Administracion de Recursos y Actividad del Registro

Adminstrador de recursos

Administrador de Sistema

Administrador del Sistema y Actividad del Registro

Sistema de Respaldo<<Actor>>




Actividad de Registro

Administracion de RecursosAdministrador de Recursos

Administrador de SistemasAdministrador de Projecto

Administracion de Proyecto

<<include>>

<<include>>

Administrador de Sistemas

<<include>>

Sistema de Respaldo

<<Actor>>



5.3 Diagramas de Casos de UsoAdministracion del Proyecto

por si mismo

Administracion del Proyectopor ActividadAdministrador de Proyecto

Administrar Proyecto por Tarea

Mantener Proyecto

Mantener Actividad

Mantener Tarea

Administrador de ProyectoAdministacion de Proyecto

<<extender>>

<<extender>>

<<extender>>



5.3 Diagramas de Casos de Uso• Actores del sistema de administración de proyecto son:

– Administrador de proyecto• Responsable de asegurarse de que un proyecto entregue un

producto de calidad dentro de un tiempo y costo especificado, y adentrado a una limitación de recursos específicos.

– Administrador de recursos• Responsable de asegurar que se entrene y especialice a los

recursos humanos para que estos estén disponibles para los proyectos

– Recursos humanos• Responsable de asegurarse de que las habilidades del trabajador

estén mantenidas, y de que el trabajo de la calidad sea completado para un proyecto

– Administrador de sistema• Responsable de asegurarse que un proyecto de sistema de

administración este disponible para un proyecto– Sistema de reserva

• Responsable de la cubierta de datos de reserva para el proyecto de sistema administrativo



5.3 Diagramas de Casos de Uso• Un administrador del proyecto utiliza el sistema de administración

de proyectos para administrar un proyecto.

• Los requisitos funcionales para el proyecto de sistema administrativo incluyen: funcionalidad de la seguridad (tal comopermitir que los usuarios abran una sesión y fuera del sistema), entrada de datos, proceso de datos, generación de informes.

• La actividad del registro de casos de uso es común al manejo del proyecto, se maneja el recurso, y se administran los casos de uso del sistema.

• Los proyectos se conforman de actividades, y las actividades se conforman de tareas, así que un administrador de proyecto puede manejar los proyectos, sus actividades, o sus tareas.



5.4 Diagramas de Secuencia

• Manejo de Roles:– Boundary– Control– Entity



5.5 Diagramas de ColaboraciónAdministrador DelProyecto

InterfazDe Usuario Equipo

Manejador AdministradorDelProyecto

Administrador Proyecto

Sistema

Requerimiento

1: IngresarNombre2: IngresarTelefono3: IngresarNomAdministrador4: IngresarFechaInicio5: IngresarFechaFin6: IngresaDscReq7: IngresarDscSistema8: IngresarDscEquipo9: Enviar

10: PeticiónDel Proceso

19: Confirmar ParaTerminar

18: asignar DscEquipo

17: asignar DscSistema

11: asignarNom Administrador

12: asignar Telefono

13: asinar NomProyecto

14: asignar FechaInicio

15: asignar FechaFin

16: asignar DscReq



5.5 Diagramas de Colaboración• Cuando se crea un proyecto, el administrador de proyectos utiliza

un interfaz de usuario para ingresar:– Sus datos para poder ser contactado (como mínimo su nombre y tu

número de teléfono), – El nombre del proyecto, la fecha de inicio y de fin, – Y una descripción de los requerimientos y del sistema, así como una

descripción del equipo.

• Una vez que la información requerida es ingresada, el sistema procesa adecuadamente la solicitud guardando la información y confirmando la operación.



• Una sección es un grupo de párrafos con un tema en común.

• Las secciones de UML son las vistas arquitectónicas que agrupan un conjunto específico de conceptos.

6. Secciones

Design View Implementation View

Process View Deployment View

Use Case View

System assemblyConfiguration management

System topologyDistributionDeliveryInstallation

PerformanceScalabilityThroughput

VocabularyFunctionability

Behavior



• Un documento es un grupo de secciones sobre un tema común.

• Los documentos de UML son los modelos.

7. Documentos



Resumen• Recordar que UML es un Lenguaje que sirve para Modelar, y se

pretende sea ampliamente utilizado.

• Al aprender UML es importante concentrarse en lo esencial y entender cómo aplicarlo de manera efectiva.

• Trabajar en los elementos básicos de los siguientes diagramas:– Diagramas de Clases– Diagramas de Objetos– Diagramas de Casos de Uso– Diagramas de Secuencia– Diagramas de Colaboración

• Al trabajar con UML se necesita diferenciar los Conceptos Generales de los Conceptos Específicos.



Bibliografía:• Learning UML

– Sinan Si Alhir– 0-596-00344-7– 2003– O'Reilly



¿Preguntas?

Fin

Documents

Presentación ¿Cómo Aprender UML - CIMATcimat.mx/Eventos/seminariodetecnologias/uml.pdf · – Modelado de Comportamiento: • Diagramas de Secuencia, de Colaboración, de Estado,