MODELANDO EL DOMINIO Capítulo 2 del libro guía Gloria Lucía Giraldo G. UNIVERSIDAD NACIONAL DE COLOMIBIA 2014-2 DISEÑO Y CONSTRUCCIÓN DE PRODUCTOS DE SOFTWARE.

Slides:



Advertisements
Presentaciones similares
Escribir aquí el título de la WQ
Advertisements

Compiladores e intérpretes
UML DCU -DS Alvaro Garrido V..
Evaluación de Aprendizajes
TECNICATURA UNIVERSITARIA EN INFORMATICA
MAPAS CONCEPTUALES.
Curso de Microsoft® Access® 2010
COLEGIO DE BACHILLERES PLANTEL 13 XOCHIMILCO-TEPEPAN MATERIA:TIC EQUIPO:23 PRESENTACION: BASE DE DATOS ALUMNAS: Velazquez Corona Elsa Ponciano Antonio.

DSOO - María Eugenia Valencia
“ no existe en el mundo algo mas difícil de establecer, que un nuevo orden de cosas” Maquiavelo “ el príncipe” Lo anterior se refiere al hecho de lo importante.
Arquitectura CLARO-TECNOTREE
MODELO RELACIONAL.
CÓMO HACER UN AFICHE.
Modelo de Datos Unidad II.
DIAGRAMAS DE FLUJO Y PSEUDOCÓDIGO
Fundamentos de Ingeniería de Software
DIAGRAMAS DE FLUJO Y PSEUDOCÓDIGO
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno.
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
DIAGRAMAS DE CLASES Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando.
DIAGRAMAS ENTIDAD RELACIÓN
DESCRIPCION DEL PROBLEMA
Aspectos Avanzados de la Tecnología de Objetos
UNIDAD 2 CONJUNTOS.
Modelo Entidad-Relación
INGENIERÍA DE REQUERIMIENTOS
Actividad 6. Requisitos del software, referente a la estructura y base de datos. M.C. Juan Carlos Olivares Rojas Syllabus May,
DISEÑO DE SOFTWARE 1ª. Parte
Traducción de Juan Antonio del Valle Flores
Seminario-Taller Como escribir, presentar y publicar resultados científicos 07, 08 y 09 de Febrero, 2011.
(Organización y Manejo de Archivos)
Fundamentos de Ingeniería de Software Facultad de Ingenieria Universidad Distrital Francisco José de Caldas ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS.
5.3 APROXIMACIONES AL DISEÑO
Métrica v2.1 Técnicas: Modelado de datos (Parte 2)
MODELADO DE DATOS (PARTE 2) Viviana Poblete L. Modelo de Datos I.
Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II.
METODOLOGÍA OMT Diseño de sistemas.
Modelos de desarrollo de Software
Análisis de Sistemas.
Organización y Estructuración de Datos
DIAGRAMAS ENTIDAD RELACIÓN
Importancia en la efectividad del:
El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema. Dependiendo del.
DEFINICIÓN DE OBJETO Un objeto es aquello que puede ser observado, estudiado y aprendido CARACTERÍSTICAS nos permiten conocerlos mediante la observación,
COLEGIO DE BACHILLERES PLANTEL 13 XOCHIMILCO-TEPEPAN MATERIA:TIC EQUIPO:21 PRESENTACION: BASE DE DATOS ALUMNAS: Adán Millán Sánchez.
Christian Monrreal Gonzalez Daryl Silverman Aguilar Gone
1.Función y ecuación polinomial
1-1 Capítulo dos Descripción de los datos: distribuciones de frecuencias y representaciones gráficas OBJETIVOS Al terminar este capítulo podrá: UNO Organizar.
TORMENTA DE IDEAS BRAINSTORMING
Alexander Aristizabal Ángelo flores herrera
Diseño de Sistemas.
Ingeniería de Requisitos
DIAGRAMA DE CLASES.
UML.
Ilustra: E L M ODELO C ONCEPTUAL Conceptos (Objetos) en el dominio del problema. Es el instrumento (artefacto) más importante de crear en el AOO. Es la.
Cuatro pasos para hacer un cartel
UNIDAD 2: “Características del Modelado UML” CONTENDIDO Elaborado por: Ingeniero Harold Cabrera Meza Actualizado por: Ingeniero Nilson Albeiro Ferreira.
@josedlujan. Director de Desarrollo M.T.I. José Dimas Luján Castillo
Resolución de problemas
Acceso a Datos Erick López Ovando Licenciado en Informática.
Hablar en Publico Lección 10. Haciendo Transiciones I. ¿Qué queremos decir cuando hablamos de transiciones? Una transición podría ser definida como un.
La Programación Orientado a Objetos
VALOR ACTUAL NETO (VAN)
Mini-video 2 de 5 Materia: Límites de funciones Continuidad de funciones Prácticas con Introducción a Funciones de una variable.
COMO INCIDE EL MANEJO ADECUADO DE LA INFORMACION EN LA COMUNICACIÓN DE IDEAS Básicamente incide bastante ya que debemos tener claro que es lo que deseamos.
Presentación De UML Lenguaje estándar para escribir planos de software Se usa para visualizar, especificar, construir y documentar los artefactos de un.
LAS METAS EN LA ELECCIÓN PROFESIONAL EJERCICIO DE REFLEXIÓN Y ACCIÓN En términos de la elección profesional es indispensable ampliar la información que.
Entregables del Proyecto
13/11/14. UNIDADES DEL SEMESTRE Este trabajo esta diseñado para saber los propósitos de los sistemas de información, así como el buen desempeño que le.
Transcripción de la presentación:

MODELANDO EL DOMINIO Capítulo 2 del libro guía Gloria Lucía Giraldo G. UNIVERSIDAD NACIONAL DE COLOMIBIA DISEÑO Y CONSTRUCCIÓN DE PRODUCTOS DE SOFTWARE

CONTEXTO GENERAL

MOTIVACIÓN Cómo te llamas? Comment tu t'appel ? What's your name? ¿? Imagine que en un grupo de trabajo, todos los integrantes hablan idiomas diferentes. La mayoría de los proyectos de IT adolecen de falta de buena comunicación entre sus integrantes

¿Cómo subsanar ese problema de falta de comunicación? Una buena idea sería poner a disposición de todos los integrantes del equipo un vocabulario común !!! EL MODELO DEL DOMINIO Muestra de forma gráfica cómo se relacionan todos esos términos entre sí. provee un vocabulario común (diccionario de términos) que posibilita una comunicación clara entre los miembros de un proyecto. Sirve de base para los casos de uso.

¿Qué pretendemos? Hacer un diseño dirigido por los casos de uso Por lo tanto los casos de uso NO pueden ser ni vagos, ni ambiguos. Esto se logra teniendo como base el modelo del domino bien definido Hay que re escribir las especificaciones de los casos de uso, en el contexto del dominio referenciando los objetos del dominio, por su nombre en la especificación de los casos de uso. EJEMPLOEJEMPLO ¿Cómo?

¿Qué pretendemos hacer ? Un diseño dirigido por casos de uso.

Los Top 10 del modelo del dominio 10.Enfocarse en los objetos del mundo real (dominio del problema). Cuando se está creando el modelo del dominio uno se debe asegurar que se está enfocando en los objetos de mundo real del problema, pues estos objetos tienden a cambiar más lentamente que los requisitos del software. La notación de las clases del modelo del dominio debe ser la notación simple, es decir aquella que es solo una caja con el nombre de la clase, ya que en esta fase puede que todavía no tengamos atributos y operaciones.

Los Top 10 del modelo del dominio 9. Use las relaciones de generalización y agregación para mostrar como los objetos se relacionan entre si. : Por ejemplo una revisión de un libro (Book Review) pertenece a un libro (Book) entonces se representa como una relación de agregación. Las ordenes de compra y las tarjetas de crédito son tipos de pago, entonces se representan como relaciones de generalización.

Ejemplo

Los Top 10 del modelo del dominio 8. No invierta más de un par de horas para realizar el modelo de dominio inicial. No se trata de hacer el modelo del dominio perfectamente desde la primera vez. La idea es ir mejorándolo y completándolo cuando sea necesario. A medida que se va trabajando con los casos de uso y con el diagrama de robustez, se van descubriendo objetos perdidos. Las dos horas que se invierten en el modelo del dominio inicial, son probablemente las dos horas más importantes del proyecto. Si se descubre el 80% de las clases del dominio en esas 2 horas, entonces serán dos horas muy bien invertidas.

Los Top 10 del modelo del dominio 7. Organice sus clases alrededor de abstracciones “clave” en el dominio del problema. Recuerde que el modelo del dominio es una primera aproximación al diagrama de clases que será finalmente la base de la arquitectura del software. Organizar la arquitectura alrededor de abstracciones del mundo real, hace el modelo más resistente a los cambios en los requisitos del software.

Los Top 10 del modelo del dominio 6. No confunda el modelo del dominio con el modelo de datos. Aunque estos modelos pueden parecer similares, recuerde que no siempre lo que es una buena práctica para uno, lo es para el otro. Generalmente una tabla de la BD es más grande y relaciona y almacena un número grande de cosas, mientras que una clase se considera mejor diseñada si son pequeños paquetes de datos y de comportamiento.

Los Top 10 del modelo del dominio 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. Por ejemplo, si usted llama Book a una clase del dominio, no quiere eso decir que deba tener una tabla Book en la BD. Lo que se quiere describir con esa clase son las características de UN SOLO LIBRO. Las columnas en una tabla mapean a atributos de una clase. Sin embargo, las tablas de la BD tienen otras columnas adicionales como por ejemplo aquellas correspondientes a las claves foráneas. Asi, que NO hay un mapeo 1:1 entre filas de una tabla con un objeto.

Los Top 10 del modelo del dominio 4. Use el modelo del dominio como un glosario del proyecto. Si los requisitos ambiguos son nuestro principal enemigo, el modelo del dominio es nuestra primera línea de defensa. El modelo del dominio debe ayudar a asegurar el uso consistente de los términos, cuando se está describiendo el espacio del problema. Usar el modelo del dominio como un glosario del proyecto es el primer paso hacia la desambiguación del modelo.

Los Top 10 del modelo del dominio 3. Haga el modelo del dominio antes de hacer los casos de uso, para evitar ambigüedades en los nombres. Si lo que se pretende con el modelo del dominio es desambiguar el problema, no es inteligente construir primero los casos de uso y luego hacer el modelo. Esto sería aplazar gran cantidad de problemas para más tarde.

Los Top 10 del modelo del dominio 2. No espere que su diagrama de clases final corresponda exactamente con el modelo del dominio. Aunque debería existir cierta semejanza entre ellos, no quiere decir que sean iguales. Los diagramas de clases son más detallados, el Modelo de dominio se hace deliberadamente más simple.

Los Top 10 del modelo del dominio 1.No coloque las clases relativas a las GUI en el modelo del dominio. L as clases del modelo del dominio deben ser solamente aquellas clases relativas al dominio del problema, no se deben incluir clases relativas al diseño, ni a la implementación.

Ejercicio I Decir cuáles son los problemas de los siguientes extractos de un modelo del dominio

Solución: quitar cardinalidades Muestra multiplicidad demasiado pronto. En el modelo del dominio todavía no vamos a mostrar esos detalles

Encuentra el problema !!!

Solución

Solución: colocar los atributos en las clases correctas

Encuentra el problema !!! Véase en cursiva

Solución !!! Demasiado pronto para estar pensando si la clase es abstracta Asignación de operaciones en el espacio del problema

Ejercicio II A partir del modelo verbal que se entrega en clase: 1.Leerlo. 2.Analizar la lista de clases del dominio que se da al final de la segunda hoja y eliminar las ambigüedades. 3.Actualizar la lista. 4.Realizar un modelo del dominio, utilizando solo relaciones de agregación y de Generalización/Especialización.