Descargar la presentación
La descarga está en progreso. Por favor, espere
1
Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II
2
Enumerar los requisitos. (SRS) Comprender el contexto del sistema. (Modelo del dominio). Capturar requisitos funcionales. (Casos de uso). Capturar requisitos no funcionales. (Información adicional en los casos de uso).
4
Provee un vocabulario común (diccionario de términos) que posibilita una comunicación clara entre los miembros de un proyecto. Muestra de forma gráfica cómo se relacionan todos esos términos entre sí. Es una actividad clásica del análisis orientado a objetos. Sirve de base para los casos de uso. Nota: no son objetos software, sino un “diccionario visual” de conceptos del dominio.
5
Los casos de uso no deben ser vagos ni ambiguos. Para lograr esto se toma como base el modelo del dominio.
6
Clases (conceptos) Arriba se muestran dos tipos de notación de clase. En un diagrama de clases detallado se tendrá que utilizar la versión de la izquierda, con los atributos y operaciones. Sin embargo, durante el esfuerzo inicial de modelado de dominio, es demasiado pronto para atribuir esas partes a una clase. Es mejor utilizar la notación más simple, la cual se muestra a la derecha. Esta versión sólo se muestra el nombre del dominio de clase. Nota: un dato primitivo (entero, flotante, texto, booleano, no se considera una clase, es un atributo).
7
Generalización o herencia (es un) Agregación (tiene un)
8
9. Enfóquese en los objetos del mundo real (dominio del problema). 8. Use las relaciones de generalización y agregación para mostrar como se relacionan los objetos entre si. 7. No invierta más de un par de horas para realizar el modelo de dominio inicial. 6. No confunda el modelo del dominio con el modelo de datos.
9
5. No confunda un objeto, el cual representa una instancia simple de algo, con una tabla de la base de datos, la cual representa una colección de cosas. 4. Use el modelo del dominio como un glosario del proyecto. 3. Haga el modelo del dominio antes de hacer los casos de uso, para evitar ambigüedades en los nombres. 2. No espere que su diagrama de clases final corresponda exactamente con el modelo del dominio. 1. No coloque las clases relativas a las GUI en el modelo del dominio.
10
Modela los conceptos del dominio de la aplicación. Permite visualizar las relaciones entre las clases que involucran el sistema. Clase: una unidad que encapsula información de un tipo de objeto (sirve para agrupar características comunes). Objeto: es la instanciación de una clase.
11
Una clase se representa como un rectángulo dividido en 3 compartimientos. En el primero va el nombre de la clase (centrado y singular). En el segundo van los atributos de la forma: visibilidad nombreAtributo: tipo En el tercero van las operaciones visibilidad nombreMétodo(parámetros): tipoRetorno
13
Se representa con una flecha que va desde la clase hija a la clase padre. En este caso Cuadrado hereda todos los atributos y métodos de FiguraGeometrica, si se desea se pueden sobrescribir los atributos y métodos.
14
Se representa como una línea continua entre 2 clases (puede contener el nombre de la relación encima de la línea). 0..* (cero o muchos) 1..* (1 o muchos) 0..1 (cero o uno) 1 (uno) Estas relaciones terminarán traducidas en atributos de las clases, pero en el diagrama de clases no se deben mostrar.
15
La agregación es un tipo de asociación que indica que una clase es parte de otra clase (composición débil). La destrucción del compuesto no conlleva la destrucción de los componentes.
16
Existe una forma especial de agregación, conocida como composición. Ésta se usa cuando se tiene una situación en la que un objeto contiene un número de otros objetos, y cuando el objeto contenedor se elimina todas las instancias de los objetos que están contenidos desaparecen. Por ejemplo, una clase Cliente que representa clientes en un banco tendrá una relación de composición con las cuentas que el cliente posee; porque si el cliente se elimina, por ejemplo, se mueve a otro banco, todas sus cuentas son eliminadas
17
Del documento entregado de la tienda de libros, realizar el diagrama de clases y enviarlo a udea@danielgara.comudea@danielgara.com Plazo hasta el viernes 4 de octubre a las 11.59 pm NO SE DAN PLAZOS ADICIONALES.
18
Software Modeling & desing. UML, use cases, patterns, & software architectures. Hassan Gomma. 2011. UML y patrones. Craig Larman. 1999. Learning UML 2.0 O’Reilly. 2006. Ingeniería del software. Un enfoque practico 5ta edición. Roger S. Pressman. 2002. Use Case Driven Object Modeling with UML, Theory and Practice. Doug Rosenberg. 2007.
Presentaciones similares
