Modelamiento Unificado)

Modelamiento Unificado)
Introducción al UML (Lenguaje de Modelamiento Unificado)

Agenda ¿Qué es UML? Modelado Diagramas Utilizados en UML. Ejemplos.

¿Qué es UML? UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la cual permite: especificar, construir, visualizar y documentar los objetos de un sistema programado. Este lenguaje es el resultado de la unificación de los métodos de modelado orientados a objetos de Booch, Rumbaugh (OMT: Object Modeling Technique) y Jacobson (OOSE: Object-Oriented Sotfware Engineering) .

¿Qué es UML? El UML modela sistema mediante el uso de objetos que forman parte de él así como, las relaciones estáticas o dinámicas que existen entre ellos. UML puede ser utilizado por cualquier metodología de análisis y diseño orientada por objetos para expresar los diseños.

Modelo = simplificación de la realidad:
Modelado (Objetivos) Modelo = simplificación de la realidad: Ayuda a visualizar como es o queremos que sea un sistema. Permite especificar la estructura o el comportamiento de un sistema. Proporcionan plantillas (templates) que nos guían en la construcción de un sistema. Documentan las decisiones. Modelado formal inversamente proporcional a la complejidad del mismo.  más fácil menos tiempo modelando.

Modelado (Principios Básicos)
Seleccionar el modelo adecuado para cada momento, influye en cómo se enfrentará el problema. Todos los modelos pueden ser expresados en diferentes niveles de precisión. Los mejores modelos están ligados a la realidad. Un único modelo no es suficiente

Diagramas UML 1. Diagrama de Casos de Uso 2. Diagrama de Clases
3. Diagrama de Actividades 4. Diagrama de Iteración 4.1. Diagrama de Secuencia 4.2. Diagrama de Colaboración Diagrama de Estados 6. Diagrama de Implementación 6.1. Diagrama de Componentes 6.2 Diagrama de Despliegue

Diagramas UML (Casos de Uso)
Un diagrama de Casos de Uso muestra la distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuario u otras aplicaciones). Es una herramienta esencial para la captura de requerimientos y para la planificación y control de un proyecto iterativo. Los Casos de Uso se representan en el diagrama por una elipse que denota un requerimiento solucionado por el sistema.

Relación Requerimientos / Casos de Uso Los Casos de Uso son requerimientos funcionales que describen de una manera detallada el comportamiento del sistema con los distintos Actores que interactúan con él. No definen todos los requerimientos (por ej. los tipos de datos, interfaces externas, niveles de rendimiento esperado, etc.), pero representan el hilo conductor que vincula a todos los requerimientos posibles (actuales y futuros) de una aplicación. Fuente: Vico.org

Cada caso de uso de uso es una operación completa desarrollada por los actores y por el sistema. El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema.

Diagramas UML (Diagramas de Casos de Uso)

Diagramas UML (Elementos de CU)
Actor: Es un usuario del sistema, que necesita o usa alguno de los casos de uso. Un usuario puede jugar más de un rol. Un solo actor puede actuar en muchos casos de uso; recíprocamente, un caso de uso puede tener varios actores. Los actores no necesitan ser humanos pueden ser sistemas externos que necesitan alguna información del sistema actual.

¿Cómo identificamos un actor? 1. ¿ Quien está interesado en un requerimiento concreto ? 2. ¿ En qué dominios de la organización se usará el sistema? 3. ¿ Quien será beneficiario de la nueva funcionalidad ? 4. ¿ Quien proveerá, usará y/o retirará, información ? 5. ¿ Quien dará soporte y administrará el sistema ? 6. ¿ Usará el sistema un recurso externo ? 7. ¿ Un usuario actuará con diferentes roles ? 8. ¿ Diferentes usuarios actuarán con un mismo rol ? 9. ¿ Interaccionará el nuevo sistema con un sistema antiguo? Actores • Representan a un agente que interactúa con el sistema • Entran información al sistema • Reciben información del sistema • Entran y reciben información

¿Cómo identificamos un Caso de Uso? 1. ¿ Cuales son las tareas y responsabilidades de cada actor ? 2. ¿ Algún actor creará, almacenará, cambiará, borrará o leerá información del sistema ? 3. ¿ Qué Casos de Uso crearán, almacenarán, cambiarán, borrarán o leerán esta información ? 4. ¿ Es necesario que un Actor informe al sistema sobre cambios externos ? 5. ¿ Es necesario que un Actor sea informado sobre ciertas incidencias del sistema ? 6. ¿ Qué Casos de Uso darán soporte y mantendrán el sistema ? Fuente: Vico.org

También se puede encontrar tres tipos de relaciones, como son: Comunica: (comunicates): entre un actor y un caso de uso, denota la participación del actor . En la Fig. el actor cliente se relaciona con los caso de uso “usar cajero automático”.

Usa (uses): Relación entre dos casos de uso, denota la inclusión del comportamiento de un escenario en otro. Se utiliza cuando se repite un caso de uso en dos o más casos de uso separados. Frecuentemente no hay actor asociado con el caso de uso común. En otras CASE se utiliza <<include>> en ves de <<uses>>

Extiende (extend): Relación entre dos casos, denota cuando un caso de uso es una especialización o una extensión de otro. Se usa cuando se describe una variación sobre el comportamiento normal. <<extend>>

Extiende (extend): Relación entre dos casos, denota cuando un caso de uso es una especialización o una extensión de otro. Se usa cuando se describe una variación sobre el normal comportamiento. <<extend>> En la Fig. la relación extend se utiliza para denotar que los escenarios “retirar efectivo”, “consultar movimientos” y “activar tarjetas” son especializaciones del caso de uso “realizar una transacción”.

Diagrama de Casos de Uso Actualiza Libros

Diagramas UML (Especificación de CU)
Fuente: Vico.org

Diagramas UML (Ventajas de los DCU)
1. Lenguaje de comunicación entre usuarios y desarrolladores. 2. Comprensión detallada de la funcionalidad del sistema. 3. Acotación precisa de las habilitaciones de los usuarios. 4. Gestión de riesgo más eficiente para gobernar la complejidad. 5. Estimación más exacta para determinar tiempo, recursos y prioridades en la dosificación de esfuerzo de desarrollo. 6. Fiel trazabilidad para verificar la traducción de requerimientos en código ejecutable. 7. Mayor control para mantener las sucesivas revisiones de los programas. 8. Certificación contractual Cliente- Desarrollador. 9. Documentación orientada al usuario: Helps - Manual de Procedimientos - Reglas de Negocio. 10. Documentación orientada al administrador del sistema: Soporte de Mantenimiento. Fuente: Vico.org

Diagramas UML (Expansión de un CU)
Caso de uso: Nombre del caso de uso Actores: Lista de actores (agentes externos), en la cual se indica quién inicia el caso de uso Propósito: Intención del caso de uso Resumen: Repetición del caso de uso de alto nivel o alguna síntesis similar. Tipo: Primario, secundario u opcional. Esencial o real. Referencias cruzadas: Casos relacionados de uso y funciones también relacionadas del sistema. Descripción: Descripción del caso de uso. Curso de los Eventos Acción del actor Respuesta del Sistema Ver Ejemplo Ver Template Rational

MODELADO DE OBJETOS Abstracción Encapsulado Objetos y Clases Mensajes

Paradigmas de Programación
Orientados a procedimientos: Algoritmos Orientados a Objetos: Clases y Objetos Orientados a la lógica: Objetivos Otros Cada estilo de programación se basa en su propio marco de referencia conceptual Cada uno requiere una actitud mental diferente, una forma distinta de pensar en el problema

Modelo de Objeto Es una marco de referencia, en el que se establece el conjunto básico de los conceptos. El conjunto básico de conceptos deberá considerar el SI, como un conjunto de entidades conceptuales modeladas como objetos. Abstracción Encapsulado Objetos y Clases Mensajes Elementos fundamentales

Modelo de Objeto (Abstracción)
Elemento para combatir la complejidad. Centrarse en la visión externa de un objeto sirviendo para separar el comportamiento esencial de un objeto de su implementación. La Abstracción se centra en las características esenciales de algún objeto en relación a la perspectiva de quien observa

Modelo de Objeto (Encapsulado)
Ayuda a las personas a pensar sobre lo que están haciendo. La abstracción necesita que la implementación esté encapsulada. Permite que los cambios realizados en los programas sean fiables con el menor esfuerzo Encapsulado = Ocultamiento de la información Generar una barrera conceptual sobre la información y servicios de un objeto, haciendo que estos permanezcan juntos y separados de la interfaz.

Modelo de Objeto (Encapsulado)
Definición Formal: “Técnica de modelado e implementación que separa los aspectos externos de un objeto de los internos, detalles de implementación de un objeto”. Oculta los detalles de la implementación de un objeto

Modelo de Objeto (Objetos)
Conceptos Objeto como cosa del mundo real, algo tangible, visible. Objeto como abstracción intelectualmente comprensible Definición: “Una entidad delimitada precisamente y con identidad, que encapsula estado y comportamiento. El estado es representado por sus atributos y relaciones, el comportamiento es representado por sus operaciones y método”.

Modelo de Objeto (Objetos)

Modelo de Objeto (Mensajes)
Los objetos se comunican a través del paso de mensajes. Un objeto accede a otro enviándole un mensaje y el receptor ejecuta el método correspondiente al mensaje. Se realizan mediante llamadas: nombre de un método más argumentos.

Modelo de Objeto (Mensajes)
Llamada a una operación o a un objeto, en la que se incluye el nombre de la operación y una lista de valores de argumentos [Rumbaugh, 1996] Operación que un objeto realiza sobre otro [Booch, 1996] Una comunicación entre objetos que transmite información con la expectativa de desatar una acción.

Modelo Conceptual Un modelo conceptual explica los conceptos más significativos en un dominio del problema, identificando los atributos y las asociaciones, y es la herramienta más importante del análisis orientado a objetos. Los casos de uso son una importante herramienta para el análisis de requerimientos, pero realmente no están orientados a objetos. Un modelo conceptual representa cosas del mundo real, no componentes del software. En UML se representa mediante un grupo de diagramas de estructura estática donde no se define ninguna operación. En estos diagramas se muestran conceptos (objetos), asociaciones entre conceptos (relaciones) y atributos de conceptos (atributos).

Modelo Conceptual Tienda y TPDV

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 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.

Diagramas UML (Diagramas de Clases)
Un diagrama de clases o estructura estática muestra el conjunto de clases y objeto importantes que forman parte de un sistema, junto con las relaciones existentes. Muestra de una manera estática la estructura de información del sistema y la visibilidad que tiene cada una de las clases, dada por sus relaciones con los demás en el modelo.

Diagramas UML (Elementos de Diagrama de Clases)
Clase: representa un conjunto de entidades que tienen propiedades comunes. Una clase define la estructura y comportamiento de una colección de objeto denominados instancia de la clase. En UML la clase está representada por un rectángulo con tres divisiones internas, son los elementos fundamentales del diagrama.

Nombre Clase Atributos Métodos Representación de una clase

Atributo: Representa una propiedad de una entidad. Cada atributo de un objeto tiene un valor que pertenece a un dominio de valores determinado. Las sintaxis de una atributo es: Visibilidad <nombre>: tipo = valor inicial { propiedades} Donde visibilidad es : + público. # protegido. - privado.

public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar). protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (herencia). Para métodos y atributos

Operación: El conjunto de operaciones que describen el comportamiento de los objetos de una clase. La sintaxis de una operación en UML es: Visibilidad nombre (lista de parámetros): tipo que retorna { propiedades}

Objeto: es una instancia de una clase. Se caracteriza por tener una identidad única, un estado definido por un conjunto de valores de atributos y un comportamiento representado por sus operaciones y métodos.

Generalización: es un proceso de abstracción en el cual un conjunto de clases existentes, que tienen atributos y métodos comunes, es referido por una clase genérica a un nivel mayor de abstracción. La relación de generalización denota una relación de herencia entre clases. Se representa dibujando un triángulo sin rellenar en el lado de la superclase. La subclase hereda todos los atributos y mensajes descritos en la superclase.

Diagramas UML (Diagrama de Actividades)
Un diagrama de actividades es un caso especial de un diagrama de estados en el cual casi todos los estados son estados de acción (identifican que acción se ejecuta al esta en él) y casi todas las transiciones son enviadas al terminar la acción ejecutada en el estado anterior. Generalmente modelan los pasos de un algoritmo y puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto.

Sirven para representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos Los elementos que conforman el diagrama son: acción y transición.

Diagramas UML (Elementos que forman el Diagrama de Actividades)
Estado de Acción: representa un estado con acción interna, con lo menos una transición que indica la culminación de la acción (por medio de un evento implícito). Permite modular un paso dentro del algoritmo. Se representan por un rectángulo con bordes redondeados.

Transición: Es la relación entre dos estados y se encuentran unidos por flechas; indicando que un objeto que está en el primer estado realizará una acción especificada y entrará en el segundo estado cuando un evento implícito ocurra y unas condiciones especificas sean satisfechas.

Diagramas UML (Diagrama de Interacción)
Estos son modelos que describen como los grupos de objetos que colaboran en algunos ambientes. Por lo general, un diagrama de interacción captura el comportamiento de un único caso de uso. Hay dos tipos de diagramas de interacción: diagramas de secuencia y diagramas de colaboración.

Diagramas UML (Diagrama de Secuencia)
Un diagrama de secuencia muestra la interacción de un conjunto de objetos de una aplicación a través del tiempo. Esta descripción es importante porque puede dar detalle a los casos de uso, aclarándolos al nivel de mensajes de los objetos existentes, como también muestra el uso de los mensajes de las clases diseñadas en el contexto de una operación.

Diagramas UML (Diagrama de Secuencia - Sintaxis)

Diagramas UML (Diagrama de Secuencia - Ejemplo)

Diagramas UML (Diagrama de Colaboración)
Es una forma de representar interacción entre los objetos, es decir, las relaciones entre ellos y la secuencia de los mensajes de las iteraciones que están indicadas por un número A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales,…) y ciclos en la ejecución. Muestra como varios objetos colaboran en un solo caso de uso.

Diagramas UML (Diagrama de Colaboración)
Los diagramas de colaboración explican gráficamente las interacciones entre las instancias del modelo (objetos).

Diagramas UML (Diagrama de Estados)
Muestra el conjunto de estado por los cuales pasa un objeto durante su vida en una aplicación junto con los cambios que permiten pasar de un estado a otro. Esta representado principalmente por los siguientes elementos: estado, elemento y transición. Estado: Identifica un período de tiempo del objeto (no instantáneo) en el cual el objeto esta esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos.

Diagramas UML (Diagrama de Estados - Sintaxis)

Diagramas UML (Diagrama de Estados - Ejemplo)

Diagramas UML (Diagrama de Estados)
Eventos: Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas: -Condición que toma el de verdadero o falso. -Recepción de una señal de otro objeto en el modelo. -Recepción de un mensaje. -Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular. Transición: Es una relación de tres o más estados en una transición de múltiples fuentes o múltiples destinos.

Diagramas UML (Diagrama de Implantación)
Muestran aspectos de la implementación del sistema, donde se incluyen la estructura del código fuente y su implementación en tiempo real con la estructura física del sistema. Hay dos tipos de diagramas de implementación: Diagrama de componentes Diagrama de despliegue

Diagramas UML (Diagrama de Implantación Diagrama de Componentes)
Representa las componentes físicos de la aplicación.

Diagramas UML (Diagrama de Implantación Diagrama de Despliegue)
Representa la visualización de los componentes sobre los dispositivos físicos.

Diagramas UML (Diagrama de Implantación Diagrama de Despliegue)

Modelamiento Unificado)

Presentaciones similares

Presentación del tema: "Modelamiento Unificado)"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Modelamiento Unificado)

Presentaciones similares

Presentación del tema: "Modelamiento Unificado)"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback