Modelamiento uml
- 1. MODELAMIENTO DE SOFTWARE DOCENTE: DIEGO MAURICIO CASTRO RINCÓN
- 2. ¿Qué es UML? ElLenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.
- 3. UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.
- 4. • Diagramas de Casos de Uso para modelar los procesos ’business’. • Diagramas de Secuencia para modelar el paso de mensajes entre objetos. • Diagramas de Colaboración para modelar interacciones entre objetos. • Diagramas de Estado para modelar el comportamiento de los objetos en el sistema. • Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones
- 5. • Diagramas de Clases para modelar la estructura estática de las clases en el sistema. • Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema. • Diagramas de Componentes para modelar componentes. • Diagramas de Implementación para modelar la distribución del sistema.
- 6. INTRODUCCION Se presenta a continuación un ejemplo sencillo sobre el modelado de un proyecto, basado en la metodología UML. UML, o Lenguaje de Modelado Unificado, es una especificación de notación orientada a objetos, el cual se compone de diferentes diagramas, los cuales representan las diferentes etapas del desarrollo del proyecto.
- 7. El ejemplo de este artículo se centra en el desarrollo de un pequeño aplicativo para Administrar Proyectos de desarrollo, donde se llevará el control de los avances de sus diferentes etapas. Se han usado varios diagramas, buscando mostrar su uso, mas en la práctica la complejidad del proyecto a desarrollar nos dice cuáles diagramas usar.
- 8. OBJETIVO Es una descripción corta del proyecto, de tal manera que nos dé una idea general del mismo. Es importante su claridad, ya que su información sirve de origen para algunos de los diagramas junto a otros, más adelante.
- 9. Proyecto: Administrador de Proyectos De Desarrollo Descripción: Herramienta computacional que permite controlar el proceso de Desarrollo de Aplicaciones. El sistema permite registrar las fases y las actividades de cada fase, así como el tiempo invertido en cada una de éstas, y ofrece informes actualizados en línea sobre el estado de cada proyecto.
- 10. CONTROL DE REQUERIMIENTOS. # REQUERIMIENTO DESCRIPCIÓN Consultas/informes R1 Informe Proyectos Detallado R2 Informe Responsables R3 Informe Movimientos
- 11. CONTROL DE REQUERIMIENTOS. # REQUERIMIENTO DESCRIPCIÓN Datos por proyecto: CodProyecto,nombre, fechaInicio,fechaTerminacion ALMACENAMIENTO porcentajeAvance y R4 responsable Datos por Etapa: CodEtapa,nombre,porcentaje Avance,pesoPorcentual y R5 responsable Datos por Actividad: codActividad,nombre,porcent ajeAvance,responsable R6
- 12. CONTROL DE REQUERIMIENTOS. # REQUERIMIENTO DESCRIPCIÓN Datos por Responsables: R7 CodResponsable, nombre Datos por Reporte de Tiempos: codActividad, fecha,responsable,horas y R8 porcentajeAvance Cálculo del Porcentaje de Avance de la Etapa: PROCESAMIENTO ( suma(avanceActividades) / (NroActividades*100) ) R9
- 13. CONTROL DE REQUERIMIENTOS. # REQUERIMIENTO DESCRIPCIÓN Calcula del porcentaje de Avance del Proyecto: suma(porcentajeAvance * pesoPorcentual) R10
- 14. CASOS DE USO Este diagrama representa la funcionalidad completa de un sistema (o una clase), mostrando su interacción con los agentes externos. Esta representación se hace a través de las relaciones entre los actores (agentes externos) y los casos de uso (acciones) dentro del sistema. Los diagramas de Casos de Uso definen conjuntos de funcionalidades afines que el sistema debe cumplir para satisfacer todos los requerimientos que tiene a su cargo. Esos conjuntos de funcionalidades son representados por los casos de uso. Se pueden visualizar como las funciones más importantes que la aplicación puede realizar o como las opciones presentes en el menú de la aplicación.
- 16. SUBCASOS DE USO Hacen referencia a la descomposición de los DCU del punto anterior. Se dan cuando existe una relación entre dos casos de uso. Dicha relación puede ser de extensión, que en términos de OO, esta relación es una relación de herencia, donde el “subcaso” especializa al caso. También puede ser una relación de “uso”, donde el caso requiere que el subcaso se realice completamente para que él mismo se realice bien y completamente.
- 18. DESCRIPCIÓN CASOS DE USO Este formato muestra una descripción para ayudar a comprender los Casos y SubCasos de Uso. También hace referencia a los requerimientos consignados en el documento de requerimientos, con los cuales tiene relación. Por causa del espacio, solo se muestran algunos a continuación.
- 25. EVENTOS En este formato se establecen los eventos que pueden ser generados por el actor y van a ser atendidos por cada Caso de Uso. Por evento entendemos la interacción que tiene un actor con la aplicación a través de la interfaz gráfica, como el clic de un ratón, el ingreso de un texto a un componente, el movimiento de un elemento de la interfaz. Todos los eventos van numerados en orden secuencial de acuerdo a la secuencia lógica como ocurrirían en la aplicación (ciclo de vida del caso de uso). De este formato se obtiene la información para la creación de los diagramas de interacción, más específicamente el de secuencia. También se deben presentar los eventos alternos, los cuales permiten establecer las excepciones que se pueden presentar en la ejecución del programa.
- 29. DIAGRAMA CONCEPTUAL Antes de definir el modelo estático o de clases, es necesario definir el modelo conceptual, el cual nos muestra los conceptos presentes en el dominio del problema. Un concepto para este caso, en términos de POO, es un objeto del mundo real, es decir, es la representación de cosas del mundo real y NO de componentes de software. En él no se definen operaciones ( o métodos). En este modelo se pueden mostrar los conceptos, los atributos de los conceptos (opcionalmente) y la relación o asociación entre ellos. Informalmente podríamos decir que un concepto es una idea, cosa u objeto. Para descubrirlos debemos analizar los sustantivos en las descripciones textuales del dominio del problema, es decir, de la descripción del sistema, de los requerimientos y de los Casos de Uso.
- 31. DIAGRAMA DE ESTRUCTURA ESTATICA (DE CLASES) Nos muestra una vista de la aplicación en un determinado momento, es decir, en un instante en que el sistema está detenido. Las clases son la plantilla de los objetos, y aquí podemos ver representados estos con sus atributos o características y su comportamiento o métodos, así como la relación entre ellas.
- 33. DIAGRAMA DE INTERACCIÓN Son aquellos que muestran las interacciones de un usuario con el sistema. Interacción es una cadena de mensajes enviados entre los objetos en respuesta a un evento generado por el usuario sobre la aplicación. Los diagramas de interacción pueden ser Diagramas de Secuencia y Diagramas de Colaboración. Estos diagramas conforman la etapa del diseño de la aplicación, y se crean a partir de los diagramas de Casos de Uso y el Conceptual. Los Diagramas de Secuencia representa una interacción entre objetos de manera secuencial en el tiempo. Muestra la participación de objetos en la interacción entre sus “líneas de vida”, (desde que se instancias) y los mensajes que ellos organizadamente intercambian en el tiempo. El responsable o ACTOR es quien inicia el ciclo interactuando inicialmente con la interfaz de usuario: GUI; en seguida se inician todos los objetos que intervienen en el funcionamiento del aplicativo. En este diagrama se comienza a observar el comportamiento del sistema a partir de los eventos generados por los actores. Aquí se interactúa con instancias, no con clases.
- 35. Los De Colaboración dan toda las especificaciones de los métodos. Estos permiten describir una operación específica incluyendo sus argumentos y variables locales creadas durante su ejecución. Se muestran los objetos y mensajes que son necesarios para cumplir con un requerimiento o propósito, o con un conjunto de ellos. Se puede elaborar para una operación o para un Caso de Uso, con el fin de describir el contexto en el cual su comportamiento ocurre.
- 37. CONTRATOS Es un formato que describe lo que una operación debe satisfacer o lograr, en términos de lo qué se hace, mas no de cómo se hace, y haciendo énfasis en los cambios de estado que ocurren en las precondiciones y post condiciones de la operación.
- 39. DIAGRAMA DE ESTADO Este diagrama muestra la secuencia de los estados de un objeto durante su ciclo de vida, en respuesta a un estímulo recibido. Los estados de los objetos están dados por el valor de sus atributos (estados) lo cual cambia su comportamientos (métodos). Los estados hacen referencia a una condición durante la vida de un objeto o a una interacción durante la cual se satisface alguna condición (ejecutar alguna acción, esperar algún evento, etc), por ejemplo una validación de una captura. Un objeto permanece en un estado por un tiempo finito, hasta que se cumpla la condición de cambio. Se construyen a partir del Diagrama de Estructura Estática, identificando cuáles objetos cambian de estado, cual es le estado inicial y el final, definiendo a qué eventos puede responder el objeto, y qué transacciones ejecutará.
- 42. Se utilizan para visualizar, especificar, construir y documentar la dinámica de un conjunto de objetos o simplemente para modelar el flujo de control de una operación (método de una clase). Fundamentalmente es un Diagrama de Flujo que muestra el flujo de control entre las actividades. Dentro del flujo se pueden encontrar pasos secuenciales y/o concurrentes y/o condiciones. Permiten en un momento dado construir sistemas ejecutables a través de ingeniería directa (del modelo al .exe) o inversa (de la implementación al modelado)