Unified Modeling Language UML. Ejemplo a desarrollar La Universidad XXX desea computarizar su sistema de registración – El secretario establece el plan.

Presentación del tema: "Unified Modeling Language UML. Ejemplo a desarrollar La Universidad XXX desea computarizar su sistema de registración – El secretario establece el plan."— Transcripción de la presentación:

1 Unified Modeling Language UML

2 Ejemplo a desarrollar La Universidad XXX desea computarizar su sistema de registración – El secretario establece el plan de estudio para un semestre. Un curso puede tener varias ofertas – Los estudiante seleccionan 4 cursos principales y 2 alternativos. – Cuando un estudiante se anota en un semestre, se le notifica al sistema de facturación para que pueda facturar al estudiante. – Los estudiantes pueden usar el sistema para agregar/borrar cursos por un período de tiempo después de la registración. – Los profesores usan el sistema para obtener la lista de inscriptos en sus cursos. – A los usuarios del sistema se les asignan contraseñas que se utilizarán durante la validación del ingreso al sistema de registración.

3 Actores Un actor es alguien o alguna cosa que debe interactuar con el sistema en desarrollo Es el rol que un usuario juega dentro del sistema EstudianteSecretarioProfesorSistema Facturación

4 Casos de Uso Cada caso de uso es una secuencia de transacciones relacionadas ejecutadas por un actor y el sistema en un diálogo Especifican todas las formas de interactuar con el sistema Definen qué es lo que el actor puede hacer Mantenimiento De Planes de Estudio Secretario

5 Diagrama de Casos de Uso Los diagramas de caso de uso son creados para visualizar las relaciones entre actores y casos de uso Sistema Facturación Secretario Estudiante Profesor Mantenimiento de Programa Mantenimiento de Planes de Estudio Administracion de las Solicitudes de Inscriptos

6 Documentando Casos de Uso Un flujo de eventos es creado por cada caso de uso – Escrito desde el punto de vista del actor Se detalla lo que el sistema debe proveer al actor cuando el caso de uso es ejecutado Contenido típico – Cómo el caso de uso empieza y termina – Flujo normal de eventos – Flujo alternativo de eventos – Flujo excepcional de eventos

7 Mantener Plan de Estudio Flujo de Eventos Este caso de uso comienza cuando el Secretario intenta entrar al sistema ingresando su clave. El sistema verifica que la clave se válida, si es asi, solicita al Secretario que seleccione el semestre. El Secretario entra el semestre deseado. El sistema pregunta el profesor la actividad deseada: AGREGAR, ELIMINAR, MODIFICAR, o FIN. Si la actividad seleccionada es AGREGAR, se ejecuta el subflujo Agregar Curso. Si la actividad seleccionada es ELIMINAR, se ejecuta el subflujo Eliminar Curso. Si la actividad seleccionada es MODIFICAR, se ejecuta el subflujo Modificar Curso. Si la actividad seleccionada es FIN, el caso de uso termina....

8 Relaciones entre Casos de Uso Uses y Extends Una relación “uses” muestra el comportamiento que es común entre varios casos de uso Una relación “extends” muestra el comportamiento que es opcional Registracion de cursos > Validacion de clave > Mantenimiento de Planes de Estudio

9 Realizaciones de Casos de Uso El diagrama de casos de uso presenta una vista externa del sistema Los diagramas de interacción describen cómo los objetos colaboran para realizar un casos de uso Hay dos tipos de diagramas de interacción – Diagrama de secuencia – Diagrama de colaboración

10 Diagrama de Secuencia Un diagrama de secuencia muestra las interacciones entre los objetos en orden temporal :Estudiante secretario GUI secretario mat 101 1: “carga de datos” 2: confirmate 3: agregaCurso(juan, mat 101) 4: esAbierto? 5: agrega (juan)

11 : Secretario cursoGUI : CursoGUI manager : CurriculumManager unCurso : Curso 1: “carga de datos” 2: confirmate 3: agregaCurso 4: new Diagrama de Colaboración Un diagrama de colaboración muestra las interacciones entre los objetos enfatizando las relaciones entre ellos

12 Diagrama de Clases Un diagrama de clases muestra la existencia de clases y sus relaciones en la vista lógica del sistema La naturaleza estática de un sistema es representada por una serie de diagramas de clase En diagramas de clase UML modela: – Clases: estructura y comportamiento – Relaciones: asociación, agregación, dependencia, herencia – Indicadores de multiplicidad y navegación – Nombres de roles

13 Clases Una clase es una colección de objetos con – estructura común – comportamiento común – relaciones comunes – semántica común Una clase es dibujada como un rectángulo con tres partes Clase

14 Clases SecretarioGUICurso Alumno CursoOfrecido Profesor Secretario

15 Operaciones El comportamiento de una clase es representado por sus operaciones Las operaciones pueden ser encontradas examinando los diagramas de secuencia secretario GUI secretario 3: agregaCurso(juan, math 01) Secretario agregaCurso(unAlumno,unCurso)

16 Atributos La estrucutra de una clase es representada por sus atributos Los atributos pueden ser encontrados examinando las definiciones de la clase, los requerimientos del problema, etc Cada curso ofrecido tiene un número, ubicación y duración CursoOfrecido numero ubicacion duracion

17 Clases SecretarioGUI Secretario agregaEstudiante(unCurso, unEstudiante) Curso nombre cantCreditos abrirte() agregaEstudiante(unEstudiante) Alumno nombre legajo CursoOfrecido número ubicación duración abrite() agregaEstudiante(unEstudiante) Profesor nombre titulo

18 Relaciones Las relaciones proveen el medio de comunicación entre objetos – si dos objetos necesitan “hablar”debe existir un link entre ellos UML reconoce tres tipos de relaciones: – Asociación – Agregación – Dependencia

19 Relación de Asociación Una asociación es una conección bi-direccional entre objetos de diferentes clases Una asociación es representada por una línea conectando las clases relacionadas CursoOfrecidoProfesor

20 Relación de Agregación Unaagregación es un caso especial de asociación donde la relación es entre un todo y sus partes – el tiempo de vida de las partes depende del tiempo de vida del todo Una agregación es representada como una línea conectando las clases relacionadas con un rombo cercano a la clase representando el todo CursoCursoOfrecido

21 Relación de Dependencia Una dependencia muestra la relación entre un cliente y un proveedor donde el cliente no tiene conocimiento semántico del proveedor Una dependencia es representada como una línea punteada dirigida desde el cliente al proveedor ProveedorCliente

22 Relaciones SecretarioGUI Secretario agregaEstudiante(unCurso, unEstudiante) Curso nombre cantCreditos abrite() agregaEstudiante(unEstudiante) Alumno nombre legajo Profesor nombre titulo CursoOfrecido número ubicación duración abrite() agregaEstudiante(unEstudiante)

23 Roles & Nombre de roles El rol es el propósito de una asociación El nombre del rol describe cómo una clase ve a otra CursoProfesor profesor

24 Multiplicidad La multiplicidad define cuántos objetos participan en una relación – Es el número de instancias de una clase relacionada a UNA instancia de la otra clase – Por cada asociación y agregación,hay dos decisiones de multiplicidad La multiplicidad da los límites inferior y superior – 0..1 : cero o una instancia – 1..1: una y solo una instancia – 0..*: cero o muchas instancias –...

25 Navegación Las asociaciones y agregaciones son bi-direccionales Una relación dibujada como una línea dirigida restringe la navegación a ser unidireccional

26 Multiplicidad y Navegación SecretarioGUI Secretario agregaEstudiante(unCurso, unEstudiante) Curso nombre cantCreditos Abrite() agregaEstudiante(unEstudiante) Alumno nombre legajo Profesor nombre titulo 0..*1 1 4 3..10 0..4 1 1 1..* CursoOfrecido número ubicación duración abrite() agregaEstudiante(unEstudiante)

27 Herencia Herencia es una relación entre clases – superclase – subclases Llamada también: – Generalización ó – Especialización La herencia se representa como una asociación dirigida Alumno nombre UsuarioRegistrado legajo

28 Herencia SecretarioGUI Secretario agregaEstudiante(unCurso, unEstudiante) Curso nombre cantCreditos abrite() agregaEstudiante(unEstudiante) legajo título Alumno Profesor nombre UsuarioRegistrado CursoOfrecido número ubicación duración abrite() agregaEstudiante(unEstudiante)

29 Diagrama de Transición de Estados Un diagrama de transición de estados describe la evolución temporal de un objeto en respuesta a interacciones con otros objetos Un diagrama de transición de estados muestra: – El comportamiento dinámico de una clase – Los eventos que causan una transición desde un estado a otro – Las acciones que resultan de un cambio de estado Un diagrama de transición de estados es un grafo dirigido de estados conectado por transiciones

30 Estados & Actividades Un estado es una abstracción de los valores de atributo de un objeto. Especifica la respuesta del objeto a eventos de entrada Un estado TIENE duración Una actividad es una operación dentro de un estado que toma tiempo completar Estado1 do: actividad1

31 Estados Iniciales & Finales Un estado inicial representa la creación del objeto Un estado final representa la destrucción del objeto Estado InicialEstado Final

32 Eventos & Acciones Un evento es algo que sucede en un punto del tiempo. Cada evento comunica información desde un objetos a otro Un evento NO tiene duración Una acción es una operación instantánea asociada a un evento

33 Transiciones Una transición es una relación entre dos estados indicando que un objeto en el primer estado pasará al segundo estado y ejecutará cierta acción especificada si un evento dado ocurre y se cumplen las condiciones especificadas Estado1 do: actividad1 Estado2 entry: actividad1 exit: actividad2 Evento1(atr) [condicion1] / accion1

34 Diagrama de Transición de Estados de Curso Ofrecido Inicializado Abierto entry: Registrar estudiante exit: Incrementar contador Cerrado do: Ìnit curso do: Finalizar curso Cancelado do:Notificar estudiante registrado agregar alumno / Set count = 0 Agregar alumno[ count < 10 ] [ count = 10 ] Cancelar

35 Diagrama de Componentes El diagrama de componentes – visualiza la naturaleza física del sistema – ilustra las organizaciones y dependencias entre los componentes de software Un componente puede ser – un componente de código fuente – un componente de run-time – un componente ejecutable

36 Diagrama de Componentes Curso Ofrecido Alumno Profesor Curso.dll Gente.dll Curso Usuario Registrar.exe Facturar.exe Sistema Facturación

37 Deployment Diagram El diagrama deployment muestra la configuración de los elementos de procesamiento en ejecución y de los procesos que ejecutan en ellos El diagrama deployment visualiza la distribución de componentes a través de la empresa. Registracion BaseDatos

38 Estereotipos Un estereotipo representa una clasificación de mas alto nivel del elemento modelado para indicar la clase de elemento que es. Los estereotipos pueden ser usados para clasificar y extender asociaciones, herencia, relaciones, clases y componentes Ejemplos: – de Clase: boundary, control, entidad, excepción – de Herencia: uses – de Componente : subsistema

39 Estereotipos SecretarioGUI Secretario agregaEstudiante(unCurso, unEstudiante) Curso nombre cantCreditos abrite() agregaEstudiante(unEstudiante) título Alumno Profesor > CursoOfrecido número ubicación duración abrite() agregaEstudiante(unEstudiante)

40 Paquetes (packages) Un paquete representa un agrupamiento de elementos del modelo en unidades de mas alto nivel Una dependencia existe entre dos paquetes si existen dependencias entre elementos de cada paquete