Curso Práctico de ADOO con UML y Enterprise Architect.

Presentación del tema: "Curso Práctico de ADOO con UML y Enterprise Architect."— Transcripción de la presentación:

1 Curso Práctico de ADOO con UML y Enterprise Architect

2 Qué Necesita el Usuario

3 Qué Pidió el Usuario

4 Cómo lo Vio el Analista

5 Cómo se Diseñó

6 Cómo lo Escribió el Programador

7 Cómo Funciona el Sistema (en ocasiones...)

8 La Moraleja La moraleja de la historia Comunicación Efectiva comunicación multi- disciplinaria La Torre de Babel Cada participante maneja su propio lenguaje

9 El Proceso de Desarrollo “Escribir código es sólo una parte del total de esfuerzo de desarrollo”

10 El Análisis y Diseño Orientado a Objetos

11 El Diagrama de Casos de Uso El Eje de la Calidad

12 Objetivos Aprender a describir el comportamiento general de un sistema por medio de casos de uso Entender qué es un actor y cómo representar su interacción con el sistema Comprender las relaciones entre casos de uso Conocer los mecanismos de extensión de UML en los diagramas de casos de uso

13 Diagrama de casos de uso Muestra el Comportamiento del Sistema Muestra el Alcance del Sistema Interacciones con entidades externas

14 Elementos del diagrama de casos de uso Asociación Actor Caso de Uso

15 Actor Representa el rol que juega una entidad externa que interactúa con el sistema. Intercambia información con el sistema Puede ser un recipiente pasivo de información Puede representar el rol que juega un humano, una máquina u otro sistema Se nombran generalmente con sustantivos en singular Cliente, Vendedor, Administrador, Alumno, Sistema de Nómina, etc.

16 Carlos imparte un curso y estudia un postgrado Carlos como Profesor Carlos como Alumno Una entidad, varios actores

17 Carmen estudia administración y Claudia diseño gráfico Carmen como Alumno Varias entidades, un actor Claudia como Alumno

18 Caso de Uso Caso de uso Es la especificación de un conjunto de acciones que ejecuta el sistema Genera un resultado observable con valor real para el actor Describe un flujo de eventos completo Describe las interacciones entre el actor y el sistema El actor inicia un caso de uso cuando invoca cierta funcionalidad del sistema Al unir todos los casos de uso se tienen todas las formas posibles de usar el sistema Se nombran generalmente con un verbo en infinitivo: Realizar Venta, Cotizar Seguro, Generar Nómina, etc.

19 Diagrama de casos de uso

20 Relaciones entre casos de uso (1/2) En ocasiones hay fragmentos de funcionalidad que varios casos de uso comparten Para evitar la repetición, esta funcionalidad común la podemos factorizar en un caso de uso nuevo Los casos de uso que lo requieren, invocan al caso de uso factorizado

21 Relaciones entre casos de uso (2/2) Entre los casos de uso pueden darse dos tipos de relaciones: Dependencia Implica que la funcionalidad englobada en un caso de uso depende de otro ya sea por que el primero (dependiente) incluye o extiende la funcionalidad definida por el segundo Generalización Implica que un caso de uso especializado reutiliza tanto el comportamiento como las relaciones que posee otro caso de uso más general Además, el caso de uso especializado puede redefinir ciertas actividades definidas por el padre

22 Relación de dependencia entre casos de uso UML define dos formas de dependencia entre casos de uso: Includes Extends Para representarlos necesitamos utilizar el mecanismo de extensión de UML: Estereotipos Los estereotipos extienden el significado de los elementos de UML Se escriben entre “«” y “»” y se coloca junto al elemento que deseamos extender «includes» «extends» «estereotipo»

23 Relación Include > Las relaciones “include” se usa … Para extraer parte del flujo que comparten más de un caso de uso Cuando se quiere visualizar parte del detalle de un proceso El “casos de uso base” incluye al “caso de uso incluido”

24 Relación Extend La relación “extend” añade un flujo de trabajo a un caso de uso de negocio que ya se ha descrito completamente La mayoría de los casos de uso de extensión no se pueden ejecutar solos. Las relaciones extend se pueden usar para … Modelar un flujo que rara vez ocurre Modelar un flujo que solo ocurre bajo circunstancias especiales. >

25 Puntos de extensión Identifica un punto en la funcionalidad de un caso de uso donde esta se puede extender por la funcionalidad de otro caso de uso (indicado en una relación «extends» )

26 Relación de Generalización La generalización del caso de uso de negocio es usada para mostrar que dos flujos de trabajo comparten estructura, propósito y medio. Llamada LocalLarga distancia 1 Levantar Auricular 2 Esperar tono 3 Marcar numero 4 el sistema conecta con el numero marcado 4 el sistema conecta con otro sistema B 5 Colgar5 Sistema B conecta con numero marcado 6 Sistema desconecta6 Colgar 7 Sistemas desconectan

27 Paquetes Los paquetes sirven para agrupar de una manera lógica elementos de UML y reducir la complejidad Casos de uso Clases Componentes Paquetes

28 Paquetes de casos de uso Un paquete de casos de uso representa agrupación lógica de funcionalidad. Ejemplo: módulos, subsistemas, sistemas.

29 Conclusiones El diagrama de casos de uso muestra el alcance, el comportamiento del sistema y su interacción con entidades externas Un actor es una entidad externa que interactúa con el sistema Un caso de uso es un conjunto de interacciones entre el sistema y uno o más actores Los casos de uso pueden relacionarse mediante dependencias o generalizaciones Las relaciones de dependencia entre casos de uso pueden estereotiparse con «extend» o «include» Los casos de uso se pueden agrupar en paquetes para reducir la complejidad y organizarlos en subsistemas y módulos

30 Documentación de casos de uso Especificación de Casos de Uso y Escenarios

31 Objetivos Aprender a documentar los requerimientos del sistema mediante el uso de flujos de eventos y escenarios Entender la estructura de un flujo de eventos Comprender la ventaja de los flujos de eventos sobre el enfoque basado en listas de requerimientos Comprender el uso que tiene este artefacto para mejorar la comunicación entre las partes involucradas en el proyecto

32 Documentación de los casos de uso Los casos de uso se documentan con: Una breve descripción El propósito del caso de uso en unas cuantas líneas El flujo detallado de los eventos Descripción detallada de eventos Terminología y redacción simple orientada al negocio/usuario

33 Caso de uso de alto nivel Las descripciones breves de los casos de uso se pueden realizar al principio del proyecto Nombre del Caso de Uso: Registrar Calificaciones Descripción Breve: Este caso de uso tiene como propósito permitir al Catedrático registra las calificaciones que obtuvieron sus alumnos tras la aplicación de un examen. Las calificaciones registradas ya no pueden modificarse una vez generada el acta correspondiente.

34 Especificación del caso de uso La especificación de un caso de uso debe incluir: Precondiciones Flujos de eventos Flujo Principal Flujos Alternos Flujos Excepcionales Post-condiciones

35 Precondiciones Es el estado en que se encuentra el sistema antes de iniciar el caso de uso, y que es necesario para poder llevarlo a cabo exitosamente Generalmente son aspectos que no van a ser validados durante el caso de uso, sino que se dan por ciertos

36 Precondiciones (Ejemplo) CU: Registrar Calificaciones Precondiciones: El catedrático debe haber iniciado una sesión en el sistema El examen a calificar debe estar registrado como un examen programado El examen a calificar no debe tener un acta asociada Los alumnos a los que se les asentarán las calificaciones deben estar registrados como alumnos inscritos en el grupo al que se aplicó el examen Los alumnos a los que se les asentará la calificación debe contar con derecho a presentar dicho examen. A los alumnos sin derecho a examen se les asienta una calificación de NA

37 Flujos de eventos Describe sólo los eventos que ocurren dentro del caso de uso y no lo que pasa en otros casos de uso Evita terminología vaga como por ejemplo, “información” y “etc.” Un flujo de eventos debe describir: Cómo y cuándo inicia y termina el caso de uso Cuándo interactúa el sistema con el actor en el caso de uso Qué información es intercambiada entre un actor y el sistema No describir los detalles de la interfase de usuario El flujo básico de eventos Cualquier flujo alterno

38 Tipos de flujos de eventos Cada caso de uso Debe tener un flujo principal (o básico). Este flujo muestra los pasos o transacciones que normalmente ocurren en el caso de uso Puede tener uno o varios flujos alternos Normalmente tiene flujos excepcionales, que indican los pasos a seguir en caso de error Flujo principal Flujos excepcionales Flujos alternos

39 CU: Registrar Calificaciones Flujo principal 1.El caso de uso inicia cuando el Catedrático le indica al sistema que desea registrar las calificaciones resultantes de la aplicación de un examen. 2.El sistema le pide al Catedrático que le indique el examen que desea calificar. 3.El Catedrático le indica al sistema el examen programado que desea calificar. 4.El sistema le indica al catedrático que asiente las calificaciones obtenidas por los alumnos en el examen. 5.El Catedrático asienta las calificaciones obtenidas por los alumnos y al concluir le indica al sistema que las registre. El catedrático sólo podrá registrar las calificaciones para aquellos alumnos con derecho a examen.

40 CU: Registrar Calificaciones (cont.) Flujo principal 6.El caso de uso termina cuando el sistema registra las calificaciones asentadas para los alumnos. A los alumnos sin derecho a examen se les asienta una calificación de NA.

41 CU: Registrar Calificaciones (cont.) Flujos alternos 5a.Identificar a los alumnos sin derecho a examen 1.El Catedrático le indica al sistema que identifique a los alumnos sin derecho a examen. 2.El sistema el sistema identifica a los alumnos sin derecho a examen y el flujo de eventos continúa en el paso 4 del flujo principal.

42 CU: Registrar Calificaciones (cont.) Flujos excepcionales Cancelar el registro de las calificaciones 1.En cualquier momento, el Catedrático le puede indicar al sistema que desea cancelar el registro de calificaciones. 2.El sistema le indica al Catedrático que confirme la cancelación del registro. 3.El Catedrático confirma la cancelación del proceso. 4.El caso de uso termina con la cancelación del proceso de registro. En este caso cualquier calificación asentada por el catedrático no se registrará en el sistema.

43 Post-condiciones Es el estado en el que debe quedar el sistema despu é s de haber llevado a cabo exitosamente un caso de uso CU: Registrar Calificaciones Post-condiciones: Las calificaciones obtenidas por los alumnos en el examen deben estar registradas en el sistema. Los alumnos con derecho a examen tendrán registrada la calificación asignada por el catedrático mientras que a los alumnos sin derecho a examen se les registrará una calificación de NA

44 Usuarios de los casos de uso Clientes – validan que los desarrolladores comprendieron el problema Usuarios – clarifican sus ideas respecto al problema Desarrolladores – comprenden lo que el usuario espera del sistema a desarrollar Revisores – verifican la calidad de los requerimientos Analistas y diseñadores – base para el análisis y el diseño Tester – a partir de estos validan que el sistema hace lo que el cliente/usuario pidió Líder de proyecto – es la base para el plan de trabajo Documentador – lo usan como base aproximada de un manual de usuario

45 Prototipo GUI Facilita el levantamiento de requerimientos Al usuario y a los desarrolladores les ayuda a aterrizar y esclarecer ideas Reduce riesgos de requerimientos mal entendidos Se deben realizar en paralelo con los casos de uso

46 El Prototipo y los casos de uso Caso de Uso: Cotizar Seguro de Vida Descripción: El caso de uso comienza cuando el ejecutivo registra los datos del asegurado, el sistema utiliza los parámetros de cotización para indicar el monto...

47 Ejemplo de flujo de eventos Especifique el Caso de Uso indicado

48 Ejercicio Desarrollar para el caso de uso especificado: Las precondiciones El flujo de eventos principal Los flujos de eventos alternos Un flujo excepcional Las post-condiciones

49 Escenarios Un escenario es al caso de uso, lo que el objeto es a las clases Es una instancia espec í fica de un caso de uso, al llevar a cabo uno de los flujos del caso de uso (ya sea primario, alterno o excepcional) Los escenarios son utilizados para comprender mejor alg ú n caso de uso y para realizar las pruebas funcionales del sistema

50 Posibles Escenarios Para cada uno de los flujos de un caso de uso existe por lo menos un escenario Para el caso de uso “Registrar Calificaciones” existen los siguientes flujos posibles: Cuando el registro de calificaciones sigue la secuencia de eventos típica Cuando se desea identificar a los alumnos sin derecho a examen Cuando se cancela el registro de las calificaciones Y los siguientes ejemplos de escenario para cada flujo: Registrar las calificaciones del examen final para el ciclo 2006 obtenidas por los alumnos inscritos en el curso de Comunicación Oral y Escrita impartido por Marco Aurelio Torres H. los martes y jueves de 14:00 a 16:00 hrs. Identificar a los alumnos sin derecho al examen final para el ciclo 2006 inscritos en el curso de Comunicación Oral y Escrita impartido por Marco Aurelio Torres H. los martes y jueves de 14:00 a 16:00 hrs. Cancelar el registro de las calificaciones del examen final para el ciclo 2006 obtenidas por los alumnos inscritos en el curso de Comunicación Oral y Escrita impartido por Marco Aurelio Torres H. los martes y jueves de 14:00 a 16:00 hrs.

51 Escenario: Registro de Calificaciones Exitoso Escenario: Registrar las calificaciones del examen final para el ciclo 2006 obtenidas por los alumnos inscritos en el curso de Comunicación Oral y Escrita impartido por Marco Aurelio Torres H. los martes y jueves de 14:00 a 16:00 hrs. 1. Marco Aurelio Torres H. le indica al sistema que desea registrar las calificaciones resultantes de un examen 2. El sistema le pide a Marco Aurelio Torres H. que le indique el examen que desea calificar. 3.Marco Aurelio Torres H. le indica al sistema que desea registrar las calificaciones del examen final para el ciclo 2006 obtenidas por Juan de la Barrera, Agustín Melgar y Francisco Márquez, inscritos en el curso de Comunicación Oral y Escrita impartido los martes y jueves de 14:00 a 16:00 hrs. 4.El sistema le indica a Marco Aurelio Torres H. que asiente las calificaciones obtenidas por los alumnos en el examen indicado. 5.Marco Aurelio Torres H. asienta las calificaciones obtenidas por Juan de la Barrera, Agustín Melgar y Francisco Márquez y al concluir le indica al sistema que las registre. 6.El sistema registra las calificaciones obtenidas por Juan de la Barrera, Agustín Melgar y Francisco Márquez

52 Ejercicio Enlistar los posibles flujos Enlistar un escenario para cada flujo Describir a detalle uno de los escenarios

53 Conclusiones Los flujos de eventos son la forma en que se describen textualmente y a detalle los casos de uso Los flujos de eventos permiten especificar el funcionamiento del sistema Es uno de los principales artefactos de entrada utilizados por los diferentes stakeholders Los prototipos GUI facilitan la identificaci ó n de requerimientos y casos de uso, y ayudan a eliminar riesgos tempranamente Los escenarios son instancias espec í ficas para cada flujo del caso de uso Los escenarios son los guiones utilizados para realizar las pruebas al sistema y validar la implementaci ó n de los requerimientos

54 El Diagrama de Clases La Estructura Estática del Sistema

55 Objetivos Conocer los elementos de UML para modelar un diagrama de clases El alumno podrá desarrollar un diagrama de clases con base en los artefactos generados durante el análisis El alumno conocerá los elementos de un diagrama de clases

56 Diagrama de Clases Es el artefacto principal en el desarrollo orientado a objetos Muestra las clases en las que se implementará el sistema, sus relaciones, atributos y operaciones

57 Elementos en un Diagrama de Clases (1/2) Clases Atributos Operaciones Scope o alcance de atributos y operaciones

58 Elementos en un Diagrama de Clases (2/2) Relaciones Elementos de las Asociaciones y Agregaciones Navegabilidad Roles Multiplicidad Visibilidad entre clases

59 Atributos Descripción de un dato que define a una clase El atributo debe tener especificado un nombre, tipo de dato y scope Cada objeto instanciado de una clase tiene su propio valor para el atributo

60 Operaciones Especificación de una transformación o query que puede ser solicitado a un objeto Consta de un nombre y una serie de parámetros (firma de la operación) Un método es la implementación de una operación

61 Scope de Atributos y Operaciones Es la visibilidad que tienen las clases hacia los atributos y operaciones de una clase con la cual están relacionadas. Existen 4 tipos de scope: Público Privado Protegido Friendly

62 Control de Acceso y Encapsulamiento El control de acceso se emplea para reforzar el encapsulamiento Operaciones públicas Operaciones protegidas y privadas Atributos Privados

63 Especificación del Control de Acceso Se pueden usar símbolos de acceso en una clase para indicar la accesibilidad a sus atributos y operaciones + Acceso Público # Acceso Protegido - Acceso Privado ~ Acceso Friendly El acceso es concedido, de manera explícita, por la misma clase y no forzado por el cliente

64 Especificación del Control de Acceso + agregarAlumno () + estaLleno () # determinarTamañoCurso () - maxAlumnos - Nombre Curso

65 Tipos de Relaciones entre Clases Asociación Agregación y Composición Generalización Dependencia Curso Diplomado Modulo Alumno

66 Asociación Es la relación más simple entre dos clases Indica que 2 clases pueden verse o solicitar sus servicios

67 Clases Asociación Una clase asociación contiene información perteneciente a un vínculo entre objetos AlumnoCurso 3..10 4 Promedio Calificación

68 Roles En términos de análisis indica el rol que toma una clase con respecto a otra en una relación de asociación En términos de implementación es el nombre de la instancia u objeto que se utilizará para solicitar los servicios de la clase y para asignarle valores a sus atributos

69 Navegabilidad La asociación sin flechas indica que ambas clases pueden verse y comunicarse entre sí Pero, en ocasiones no es necesario eso, sino que una sola clase es la que requiere comunicarse con la otra, en este caso indicamos que existe navegabilidad hacia un solo lado por medio de una punta de flecha al final de la asociación

70 Agregación Es una clase especial de asociación donde una clase “contiene” a otra clase, o donde una clase “es parte de” otra clase Un Motor “contiene” Válvulas (o las válvulas son parte del motor)

71 Composición Es un tipo de agregación más sólido donde las partes sólo existen cuando existe el contenedor Una mano está compuesta de dedos Si la mano desaparece los dedos no sirven de nada La parte sólo puede ser parte de un contenedor al mismo tiempo

72 Generalización (Herencia) Es una relación donde una clase es un tipo especial de otra clase. Es decir, tiene todas las características (atributos, operaciones y relaciones) de la súperclase más otras especiales Un carro es un tipo especial de transporte Existen dos formas de identificar la herencia: Generalización Especialización

73 Generalización Cuando obtenemos características comunes de varias clases para crear una súperclase de la cual van a heredar todas las subclases las características comunes Carro Motor Llantas Barco Motor Aspas

74 Generalización Transporte Motor Carro Llantas Barco Aspas

75 Especialización Es la técnica mediante la cual se identifica que una clase puede comportarse o tener características diferentes dependiendo de cierta situación o condición Identificamos cuáles son las características que nunca cambian y las dejamos en una súperclase, y las características especiales las ponemos en nuevas clases llamadas subclases Transporte Motor Llantas Aspas Transporte Motor Carro Llantas Barco Aspas

76 Dependencia Es un tipo de relación menos duradera que una asociación o una agregación La comunicación sólo es posible en momentos específicos de la clase dependiente (p.ej. cuando instancía o recibe como parámetro a la 2a clase)

77 Visibilidad Existen cuatro opciones de visibilidad Global El objeto servidor es un objeto global Parámetro El objeto servidor es un parámetro de una operación del objeto cliente Local El objeto servidor se declara localmente dentro de uno de los métodos del objeto cliente Campo El objeto servidor es un campo contenido en el objeto cliente

78 Visibilidad Indica cómo y bajo que circunstancias pueden comunicarse dos clases relacionadas asociación, agregación o composición Por campo dependenciaLocal dependenciaPor parámetro dependenciaGlobal Tipo de Relación Visibilidad

79 Elaboración del Diagrama de Clases Identificar operaciones y su scope (usar d. de interacción) Identificar atributos con su tipo de dato y scope Identificar relaciones entre clases (usar d. de interacción) Organizar clases en paquetes lógicos

80 Información en Diagrama de Interacción El diagrama de interacción es uno de los productos de entrada más importantes para elaborar el de clases Pasos para Refinar el Diagrama de Clases a partir del de interacción Convertir mensajes en operaciones Definir scope de las operaciones Decidir visibilidad requerida entre 2 clases comunicándose en el d. De interacción Si es global, local o por parámetro mostrar una dependencia en el d. De clases Si es por campo Identificar si es una relación de un todo con sus partes Si la parte, sólo es “parte” en una relación de composición, marcarla como composión Si no marcarla como agregación Si no, marcarla como asociación Mostrar la multiplicidad, navegabilidad y rol

81 Paquetes de Clases Las clases se pueden agrupar lógicamente en paquetes Las clases que se agrupan son las que guardan una relación cercana entre sí, ya sea de funcionalidad o de datos Estos grupos o paquetes lógicos de clases son los que suelen convertirse en componentes

82 VentasEmpresaNómina Paquete de Clases EmpleadoEmpresa Dirección Venta Nómina Producto Cliente Impuestos Factura

83 Ejercicio Desarrolle el Diagrama de Clases de Diseño con base en los artefactos antes generados

84 Conclusiones El diagrama de clases muestra la estructura estática del sistema Un diagrama de clases muestra las clases y sus relaciones Existen diferentes tipos de relaciones y visibilidad entre las clases Las clases se pueden agrupar lógicamente en paquetes para reducir la complejidad