Universidad Nacional de Ingeniería Comprendiendo los Fundamentos de

Presentación del tema: "Universidad Nacional de Ingeniería Comprendiendo los Fundamentos de"— Transcripción de la presentación:

1 Universidad Nacional de Ingeniería Comprendiendo los Fundamentos de
UML Integrantes: Karen Gutiérrez Ramos. Jessy Narváez Rivas. Daysi Ruiz Úbeda. Grupo: 5T2- co Nª 6

2 Origen de la notación de UML
Fundamentos de UML Lenguaje de Modelado Unificado (UML) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software. Es “modelado” por ser visual y “unificado” porque se fusionan diversas técnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado a objetos, con el fin de servir de apoyo en los procesos de análisis de un problema. Origen de la notación de UML La notación UML se deriva y unifica las tres metodologías de análisis y diseños más extendidas: Metodología de Grady Booch (OOD) Metodología de James Rumbaugh (OMT) . Metodología de Ivar Jacobson (OOSE) .

3 *Razones y Objetivos para crear UML:
La unificación de sus métodos eliminaría las diferencias y permitiría un lenguaje de modelado común para los usuarios. La unificación de la semántica y notación, traería estabilidad al mercado orientado a objeto, permitiendo a los programadores enfocarse en el desarrollo de características más útiles y en la evolución del lenguaje de modelado. Esperaban que su colaboración brindara mejoras a los métodos anteriores, permitiéndoles aprender y solucionar problemas que ninguno de sus métodos previamente podía manejar. Proporcionar mecanismos de extensión de forma que proyectos concretos puedan extender el meta-modelo a un coste bajo.

4 Permitir el intercambio de los modelos entre una gran variedad de herramientas.
Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir. Imponer un estándar mundial. Reducciones de tiempo en los proyectos de desarrollo. Crear un lenguaje de modelado utilizable por humanos y máquinas. Ser independiente de lenguajes de programación particulares y procesos de desarrollo. Fomentar el crecimiento del mercado de herramientas OO. Integrar mejores prácticas.

5 *Aplicaciones de UML *Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender. *Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción. *Construir: A partir de los modelos especificados se puede construir los sistemas diseñados. *Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado, sirviendo para su futura revisión.

6 Elementos de UML Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo, los símbolos utilizados en los modelos y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos.

7 *Vistas Las vistas muestran diferentes aspectos del sistema modelado. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son: *Vista Caso de Uso: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos. *Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema.

8 *Vista de Componentes: Muestra la organización de los componentes de código, es decir ilustra los componentes de software que se usarán para construir el sistema. *Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema, describe la división del sistema en procesos y procesadores. *Vista de Distribución: Muestra la distribución del sistema en la arquitectura física con computadoras, dispositivos y sus conexiones.

9 * Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución. *Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. *Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.

10 Fases del desarrollo de un sistema
Análisis de Requerimientos UML tiene casos de uso para capturar los requerimientos del cliente cada caso de uso es descrito en texto y especifica los requerimientos del cliente, lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Análisis La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Es importante notar que sólo se consideran clases que están en el dominio del problema.

11 Diseño En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación. Programación En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.

12 Pruebas * Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. * Las pruebas de integración integran componentes y clases en orden para verificar que se ejecuten tal como se especificó. *Las pruebas de sistema validan que el sistema tenga la funcionalidad que le usuario final espera. *Las pruebas de aceptación verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.

13 Metodología de Booch (OOD-Diseño Orientado a Objeto)
OOD (Diseño Orientado a Objetos) es una técnica usada en ingeniería de software, que provee una forma de desarrollar análisis y diseño de un sistema orientado a objetos. OOD se centra en el desarrollo de cuatro modelos fundamentales de un sistema: Modelo Lógico, Modelo Físico, Modelo Estático y Modelo Dinámico.

14 El Modelo Lógico detalla las características primordiales de las entidades principales (clases y objetos), así como la forma de trabajo de estos, estructurando de esta manera los límites, pros y contras del problema planteado para, de esta forma, definir o identificar la arquitectura del sistema. Para representar gráficamente al modelo lógico, existen dos diagramas, a saber: Diagrama de Clases Diagrama de Objetos

15 Diagramas de Clases: Se usa para mostrar la existencia de clases y sus relaciones en la visión lógica de un sistema. Un solo diagrama de clases representa una vista de la estructura de clases de un sistema. Durante el análisis, se utilizan diagramas de clases para indicar las misiones y responsabilidades comunes de las entidades que caracterizan el comportamiento de un sistema. Durante el diseño, se utilizan diagramas de clases para plasmar la estructura de las clases que forman la arquitectura del sistema.

16 Diagrama de Objetos: Se utilizan para mostrar la existencia de objetos y sus relaciones en el diseño lógico de un sistema, es decir, representa las interacciones o relaciones estructurales que pueden darse entre un conjunto de instancias (objetos) de clases. Un diagrama de objetos representa una vista estructurada de objetos de un sistema. Durante el análisis, se usa para indicar la semántica de escenarios primarios y secundarios que proporcionan una traza del comportamiento del sistema. Durante el diseño, se usan para ilustrar la semántica de los mecanismos en el diseño lógico de un sistema.

17 El Modelo Físico describe la estructura física y lógica o software que componen al sistema. Para representar gráficamente al modelo físico, existen dos diagramas, a saber: Diagrama de Procesos Diagrama de Módulos

18 Diagrama de Procesos: Se usan para mostrar la asignación de procesos a procesadores, y dispositivos en el diseño físico de un sistema. El diagrama de procesos representa una vista de la estructura de procesos de un sistema. Durante el desarrollo, se usan para indicar la colección física de procesadores y dispositivos que sirven como plataforma de ejecución del sistema. Diagrama de Módulos: Se utiliza para mostrar la asignación de clases y objetos a módulos en el diseño físico de un sistema. Un diagrama de módulos representa una vista de la estructura de módulos que componen un sistema. Durante el desarrollo, se usan para indicar la disposición en capas y la participación física de la arquitectura.

19 Tal como se mencionó anteriormente el modelo de desarrollo orientado a objetos está conformado por los modelos lógico y físico, así como también por los modelos estático y dinámico, estos modelos explican que, algunos diagramas son estáticos mientras que otros son de carácter dinámico. El Modelo Estático es representado por modelo de objeto, estructuras de datos del sistema. El Modelo Dinámico se usa para expresar y modelar el comportamiento del sistema a lo largo del tiempo. Para representar gráficamente al modelo dinámico, existen dos diagramas, a saber: Diagramas de Transición entre Estados Diagrama de Interacción

20 Diagramas de Transición entre Estados: Este diagrama se realiza para cada objeto cuyo ciclo de vida interese al desarrollador. Es una descripción complementaria del diagrama de objetos y del diagrama de clases.En ellos se representa el comportamiento de un objeto mediante una sucesión ordenada, en el tiempo, de eventos. Diagramas de interacción: Muestran una interacción, que consiste de un conjunto de objetos y sus relaciones, incluyendo los mensajes que puedan ser realizados entre ellos.

21 Etapas Análisis de Requerimientos: En esta etapa se define qué quiere el usuario del sistema. Es una etapa de alto nivel que identifica las funciones principales y alcance del sistema, y documenta los procesos principales del sistema. Análisis de Dominio: Es el proceso de definir de una manera concisa, precisa y OO la parte del modelo del sistema. Las siguientes actividades son parte de esta etapa: Diagrama de clases Especificación de las clases Vistas de herencia Diagramas de objetos Especificación de objetos 

22 Diseño: Es el proceso de determinar una implementación efectiva y eficiente que realice las funciones y tenga la información del análisis de dominio. Las siguientes actividades se plantean en esta etapa: Descripción de arquitectura, que describe las decisiones más importantes de diseño como son el conjunto de procesos, manejadores de bases de datos, sistemas operativos, lenguajes, etc. Descripciones de prototipo, que describen las metas y contenido de las implementaciones sucesivas de prototipos, su proceso de desarrollo y la forma de probar requerimientos. Diagramas de clases en diseño. Diagramas de objetos en diseño. Especificaciones de clases corregidas, muestra la especificación completa de los métodos con algoritmos complicados, la implementación de relaciones y el tipo de atributos.

23 Metodología de Jacobson (OOSE-Ingeniería de software orientado a objeto)
OOSE es un proceso organizado para la construcción industrial de software. Este proceso de diseño está guiado por casos de uso, una técnica que se basa en el entendimiento de un sistema en la forma en la cual es usado. Descripción La Metodología de Jacobson se basa principalmente en diagramas de casos de uso y diagramas de interacción.

24 Funcionalidad Esta metodología utiliza principalmente tres técnicas diferentes: La programación orientada al objeto: De esta técnica utiliza los conceptos de encapsulación, herencia y relaciones principalmente entre las clases y casos. El trazado conceptual: El cual se usa para crear los diferentes modelos del sistema u organización a ser analizado. Extendiéndolos con los conceptos orientados a objetos y con la posibilidad de modelar la conducta dinámica. Los mismos sirven para entender el sistema y obtener una arquitectura del sistema definida. El plan de bloque: Modela los módulos con funcionalidades propias, que se conectan con las interfaces bien definidas. Este plan implica los cambios y mantención de software.

25 Diagrama de Casos de Uso
Modela requerimientos funcionales, expresados en la interacción entre actores y módulos del sistema Los casos de uso son un medio para especificar los usos necesarios de un sistema. Normalmente, se utilizan para capturar los requisitos de un sistema, es decir, lo que un sistema se supone que debe hacer. Un caso de uso muestra qué hace el sistema, no cómo lo hace Los conceptos clave relacionados con casos de uso son los actores, casos de uso, y el sujeto. El tema es el sistema en consideración al que los casos de uso se aplican. Los usuarios y cualquier otro sistema que puedan interactuar con el tema son representados como actores.

26 Etapas Análisis de Requerimientos Especificación de requerimientos con el usuario, en términos de casos de uso. Discusión y validación de requerimientos. Identificación detallada de cada caso de uso, describiendo la funcionalidad por defecto, las posibles variantes y los posibles errores. Definición de un borrador de la interfaz al usuario del sistema, que muestre cómo se verían los distintos casos de uso.

27 Modelo de análisis Definir el modelo de análisis, identificando objetos entidad, de interfaz y de control; independientes del ambiente de implementación. Toda la funcionalidad que es dependiente del entorno del sistema se expresa en objetos de interfaz. Modelar la información y comportamiento que el usuario necesitará por largo tiempo en objetos entidad. Modelar objetos de control cuando el sistema sea lo suficientemente complicado para tener funcionalidad que no corresponde a ningún objeto de interfaz ni a ningún objeto entidad.

28 Modelo de diseño Agrupar en paquetes las clases existentes. Cada paquete debería estar relacionado a un solo actor Refinar las clases de análisis para incluir detalles de implementación. Desarrollar el código de los métodos de los objetos. Realizar diagramas de interacción que muestran como interactúan los distintos paquetes en el desarrollo de un caso de uso. Desarrollar diagramas de estado para los objetos complejos

29 Implementación Implementar las clases de diseño definidas. Una clase de diseño puede corresponder a una o más clases en implementación, dependiendo de su complejidad, de su dependencia del ambiente de desarrollo, etc. Las clases en implementación deben tener las siguientes características: Altamente reusables No deben ofrecer funcionalidad similar a menos que estén relacionadas por herencia

30 Metodología de Rumbaugh -OMT OMT (Técnica de Modelización de Objetos) es una metodología de Ingeniería del Software, que cubre todas las fases del ciclo de vida de un producto software: análisis, diseño, implementación, verificación y mantenimiento. OMT modela un sistema desde tres puntos de vista diferentes, relacionados entre sí. OMT se apoya en tres modelos: Modelo de Objetos, Modelo Dinámico y Modelo Funcional. Modelo de Objetos representa al aspecto estructural, estático de un sistema: es decir, describe la estructura de los objetos del sistema en términos de su identidad, atributos, operaciones y relaciones; el modelo se representa mediante un diagrama de objetos.

31 Los diagramas de objetos permiten representar gráficamente los objetos, las clases y sus relaciones mediante dos tipos de diagramas: Diagrama de clases. Esquema para describir las instancias de datos posibles. Diagrama de instancias. Describe la forma en que un cierto conjunto de objetos se relacionan entre sí. Modelo Dinámico describe la dinámica entre los objetos y sus cambios de estado a través del tiempo. Los cambios de estado son dados por eventos de un objeto que afectan a otro objeto al interactuar; el modelo se representa gráficamente mediante diagramas de estado que muestran la secuencia de eventos, cambios de estado y operaciones permitidas para una clase.

32 Modelo Funcional Describe las transformaciones que sufre la información que maneja el sistema; se representan mediante Diagramas de Flujo de Datos (DFDs) que describen qué hace el sistema, sin tener en cuenta quién o cuándo se realizan esas acciones. Estos tres modelos van evolucionando a medida que avanza el proceso de desarrollo a través de las siguientes cuatro fases: análisis, diseño del sistema, diseño de los objetos, implementación.

33 Estos tres modelos van evolucionando a medida que avanza el proceso de desarrollo a través de cuatro fases: Fase de Análisis El objetivo del análisis es desarrollar un modelo del funcionamiento del sistema (modelo de análisis). El modelo se expresa en términos de objetos y relaciones, el control dinámico de flujo y las transformaciones funcionales. El proceso de capturar los requerimientos y consultar con el solicitante debe ser continuo a través del análisis. Fase de Diseño de Sistemas Durante el diseño de sistemas, se selecciona la estructura de alto nivel del sistema. El sistema se organiza en subsistemas basándose tanto en la estructura del análisis como en la arquitectura propuesta. Se selecciona una estrategia para afrontar el problema

34 Fase de Diseño de objetos.
Durante el diseño de objetos se construye un modelo de diseño basándose en el modelo de análisis, pero incorporando detalles de implementación. El diseño de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. Fase de Implementación. Las clases de objetos y relaciones desarrolladas durante el diseño de objetos se traducen finalmente a una implementación concreta a través de la codificación.

35 Conclusión UML es un lenguaje para modelar sistemas y no una metodología de desarrollo, aunque esta se puede utilizar en cualquier de las metodologías existentes. Como UML es la fusión de las tres metodologías OOD, OMT y OOSE contiene diagramas que estas metodologías ofrecen.