Luisfer
- 1. República Bolivariana de Venezuela Ministerio del Poder Popular para la Educación Instituto Universitario Politécnico Santiago Mariño 3er semestre de Ing. Sistema escuela 47 Profesor: Miguel Mena Alumno: RENGEL LUIS C.I 27.578.330 CARACAS, 16/12/2017º
- 2. ¿QUE ES UML? El Lenguaje Unificado de Modelado (Unifield Modeling Lenguaje UML), es un lenguaje estándar para escribir planos de software, UML se puede utilizar para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software. UML prescribe 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. UML se puede usar para modelar distintos tipos de sistemas como por ejemplo: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. Es un lenguaje muy expresivo, que cubre todas las vistas necesarias para desarrollar y luego desplegar tales sistemas. UML es sólo un lenguaje y por tanto es tan solo una parte de un método de desarrollo de software, además, es independiente del proceso, aunque para utilizar óptimamente se debería usar en procesos que fuesen dirigidos por los casos de uso, centrados en la arquitectura, lo interactivo e incremental. UML es una consolidación de muchas de las notaciones y conceptos más usados orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares,en 1996, el Object Managemen Group (OMG), publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en
- 3. Noviembre de 1997. El OMG llama a este documento OMG UML versión 1.1. El OMG estaba actualmente en proceso de mejorar una edición técnica de esta especificación, prevista su finalización para el 1 de abril de 1999. EJEMPLOS DE UML: 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 (Ver Figura 1):
- 4. Subcasos de Uso Hacen referencia a la descomposición de los casos de uso 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 la Orientación a Objetos 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
- 5. DiagramaConceptual 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 la Programación Orientada a Objetos, 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
- 6. 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 FASE RUP: Fase de Inicio Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores o alumnos de un proyecto en el cual tenemos que, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Fase de Elaboración En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.
- 7. Fase de Desarrollo El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Fase de Transición El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.