UML DCU -DS Alvaro Garrido V.

Agenda Diagrama de Secuencia Modelo de Dominio (conceptual).

Diagrama de Secuencia Artefacto UML, muestra los eventos de entrada y salida relacionados con el sistema en estudio. Notación UML para representar los eventos que comienzan de los actores hacia el sistema.

Comportamiento del Sistema Descripción del ¿QUE? hace el sistema, no ¿CÓMO? lo hace. A partir de un CU, donde comienza una interacción o solicitud de alguna operación. Incluirlo como notación para representar las interacciones de los actores y las operaciones que inician. Muestra un escenario específico de un CU

Importante UML no define “DS del Sistema” sólo “DS”. Representa una caja negra. Para representar la interacción. Los eventos podrían tener parámetros. Nombres de eventos, expresado a nivel de “intenciones”. Ej.: Ingresar Articulo es mejor que “escanear articulo” o “pistolear articulo”. Permanece la “abstracción” y no hay compromiso con la elección de interfaz para la captura de dicho evento.

Diagrama de Secuencia Mejor nombre Peor nombre

Diagrama de Secuencia Apoyar con Expansión del CU

Diagrama de Secuencia Debería hacerse un Diagrama de secuencia por cada caso de éxito de un CU y los flujos alternativos. Se puede apoyar su creación con la expansión del CU. En el proceso unificado (UP) el diagrama de secuencia, es una visualización de las interacciones que están implicadas en los casos de uso.

Diagramas de secuencia No se incentiva “normalmente” su uso en las fases iniciales. Larman recomienda no “tomar” mucho tiempo para la creación de los diagramas de secuencia. Las operaciones, parámetros y valores de retorno (en los mensajes) deben ser precisos y concisos, de lo contrario, será importante la creación de un glosario para una explicación más apropiada, para que en diseño esté claro lo que entra o sale en el sistema.

Modelo de Dominio ¿Qué se entiende por dominio? Modelo de dominio Principalmente se refiere al problema en cuestión. Modelo de dominio Divide los conceptos que son importantes y que están relacionados con el dominio. NO son objetos de software, podríamos catalogarlo como un “diccionario” visual de los conceptos del dominio. NO representa conceptos de software, solo de dominio.

Modelo Conceptual Un modelo conceptual es una descripción del dominio de un problema real, NO es una descripción del diseño del software. Una forma simple de obtener conceptos, es identificarlos de un análisis de las descripciones textuales referentes al dominio del problema. Para hacer esto, los casos de uso expandidos proveen una buena fuente de conceptos.

Modelo de Dominio Algunos tips para la identificación de clases conceptuales. Listado de clases, sin cuestionar. Listado de categorías de clases. Utilización de frases (extraídas principalmente de la expansión del caso de uso). La expansión de una fuente importante de clases conceptuales. Una vez analizado lo anterior, se realiza un listado de clases conceptuales de dominio. Recuerden, No Silver Bullet.

Modelo Conceptual Acción de los actores Respuesta del sistema 1. Este caso de uso comienza cuando un Cliente llega a una caja de TPV con los productos que desea comprar. 2. El Cajero registra el código de barras de cada producto. Si hay más de un producto, el Cajero puede introducir también la cantidad. 3. Determina el precio del producto y a la transacción de venta le agrega la información sobre el producto. Se muestra la descripción y el precio del producto actual.

Modelo Conceptual (Atributos) Un atributo es un valor lógico de un dato de un objeto. Es preferible que los atributos sean simples. Entre los tipos de atributos más comunes se encuentran: booleanos (o lógicos), fechas, números, texto y horas. Algunos tipos comunes son: dirección, color, teléfono, RUT, código de barras, código postal. Los atributos no deberían usarse para relacionar conceptos en el modelo conceptual, solamente para describir estos conceptos.

Modelo Conceptual (Atributos) Errores al representar modelos conceptuales: Es representar algo como un atributo, cuando debería haber sido un concepto aparte. Una regla práctica para evitar esto es: si en el mundo real no consideramos algún concepto X como número o texto, probablemente X sea un concepto y no un atributo.

Modelo de Dominio En UML podemos utilizar un diagrama de estructura estática para su representación.

Modelo de Dominio Es más fácil representar de esta forma, permite una ignorancia de los detalles sin interés (para el modelador de software).

Modelo de Dominio Recomendación: evitar mostrar este tipo de conceptos en un modelo de dominio. Esto es un artefacto de Software Muestra responsabilidades ó Métodos

Modelo de Dominio Mostrar solo tipos primitivos, simples como atributos (ej. Fecha, hora). Importante será realizar alguna documentación de apoyo, como está en la siguiente figura.

Modelo de Dominio Muestra a los modeladores de software posibles clases candidatos a ser clase (clases conceptuales), es el artefacto importante en el análisis OO. Una clase conceptual es una idea, cosa u objeto. La diferencia de hacer este tipo de análisis (OO) y el estructurado, que acá se piensa a nivel de objetos y no a nivel de funciones.

Recomendaciones para el Modelo de Dominio

Recomendación de Apoyo para Prueba. Capitulo 10 del Libro de Craig Larman “UML y Patrones”. Modelo de dominio: visualización de conceptos.

Conclusiones Cómo regla empírica, el modelo de dominio no es absolutamente correcto o equivocado, sino más o menos útil. Es una herramienta de comunicación.