Introducción a UML Departamento de Informática Universidad de Rancagua

Presentación del tema: "Introducción a UML Departamento de Informática Universidad de Rancagua"— Transcripción de la presentación:

1 Introducción a UML Departamento de Informática Universidad de Rancagua
Prof:Paula Quitral

2 Contenido Modelado de Software Definición de UML ¿Qué es?.
Diagramas Utilizados en UML, estáticos y dinámicos. Ejemplos.

3 Modelado de Software Modelo Representación de SW Facilita:
Comunicación de ideas Evaluar alternativas Aproximación gradual al producto Visualizar producto Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).

4 Construcción de una casa para “fido”
Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).

5 Construcción de una casa
Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Construida eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas

6 Construcción de un rascacielos
I. Introducción: Modelado de SW Construcción de un rascacielos Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Obviamente el debe ser el contexto de desarrollo (envergadura del proyecto) el que determine la configuración adecuada del proceso y los recursos necesarios. Existen propuestas radicales que promueven un proceso/modelado más “ligth”, tales como: Extreme Programming (Kent Beck) y Agile Modeling (Scott Ambler). Sin embargo, en muchos proyectos es difícil eludir un proceso y modelado más rigurosos, debido por ejemplo a relaciones contractuales, envergadura del proyecto en tiempo y participantes, etc. Una lectura interesante: Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.‘by Alexandra Weber Morales About 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000. "What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay." In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in?“ asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP. "Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions." Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself."

7 Claves en Desarrollo de SI
I. Introducción: Modelado de SW Claves en Desarrollo de SI Notación Figura “Triangle for Success” adaptada desde “Visual Modeling with Rational Rose and UML” de Terry Quatrani Herramientas Proceso

8 Abstracción - Modelado Visual (MV)
I. Introducción: Modelado de SW Abstracción - Modelado Visual (MV) “El modelado captura las partes esenciales del sistema” Proceso de Negocios Orden Item envío Sistema Computacional

9 II. Notación (Visual) - Beneficios
I. Introducción: Modelado de SW II. Notación (Visual) - Beneficios Manejar la complejidad Interface de Usuario (Visual Basic, Java, ..) Lógica del Negocio (C++, Java, ..) Servidor de BDs (C++ & SQL, ..) Múltiples Sistemas Componentes Reutilizados “... Hay dos formas de construir software: una es hacerlo tan simple que obviamente no existan deficiencias, otra es hacerlo tan complejo que no existan deficiencias obvias” C:A.R. Hoare, Turing Award Lecture 1980. “Modelar el sistema independientemente del lenguaje de implementación” Promover la Reutilización

10 UML (Unified Modeling Language)

11 UML (Unified Modeling Language)
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. surge luego de la aparición de los lenguajes orientados a objetos, cuando se buscan nuevas metodologías que permitan el análisis y diseño de aplicaciones bajo dichos lenguajes; estas metodologías fueron los primeros lenguajes de modelado orientados a objetos.

12 UML (Unified Modeling Language)
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) UML se comenzó a gestar en la empresa Rational cuando Booch y Rumbaugh decidieron unir sus métodos para conseguir un lenguaje estándar y sólido. Luego se incorporó Jacobson, lo que dio lugar a la versión 0.9 en 1996; La versión 1.0 de UML surgió en 1997 con la contribución de IBM, HP, Oracle, Microsoft y otras organizaciones, grupos de analistas y desarrolladores

13 UML (Unified Modeling Language)
Se diseñó de manera de independizarlo del método de desarrollo, y se intenta que sea aplicable a todas las etapas del ciclo de vida del software

14 UML: “Unificado” Cruza los métodos y notaciones anteriores
Cruza los ciclos de desarrollo Cruza los dominios de aplicación Cruza las plataformas y lenguajes de implantación Cruza los procesos de desarrollo Cruza los conceptos internos En el año 1994 había más de 50 notaciones, se toma lo mejor de cada una y se tiende a un estándar. Las notaciones se mantienen (en principio) a través del ciclo del desarrollo (aunque debe variar el nivel de abstracción) Se persigue poder cubrir todos los dominios de aplicación incluidos aquellos sistemas grandes, complejos, tiempo real, distribuidos, intensivos en datos o computación, entre otros. Puede haber areas especializadas con lenguajes más adecuados, pero Uml pretende cubrir un rango muy amplio. UML es un lenguaje, no una metodología de desarrollo. Se definen las interrelaciones entre los constructores de UML. Esto conlleva a un mejor entendimiento de los conceptos y una mejor aplicabilidad de los mismos.

15 Qué hace 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.

16 Qué hace UML ? UML Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto

17 UML y el Diagrama de Clases
UML olvida el protagonismo excesivo que se le da al diagrama de clases, este representa una parte importante del sistema, pero solo representa una vista estática, es decir muestra al sistema parado. Con el diagrama de clases se sabe la estructura del sistema pero no lo que sucede a las diferentes partes cuando el sistema empieza a funcionar. UML introduce nuevos diagramas que representa una visión dinámica del sistema. Para captar problemas de la estructura al propagar errores o de las partes que necesitan ser sincronizadas, así como del estado de cada una de las instancias en cada momento

18 UML y el Diagrama de Clases
El diagrama de clases continua siendo muy importante, pero se debe tener en cuenta que su representación es limitada, y que ayuda a diseñar un sistema robusto con partes reutilizables, pero no a solucionar problemas de propagación de mensajes ni de sincronización o recuperación ante estados de error.

19 Objetivos de UML Visualizar: UML permite representar mediante su simbología el contenido y la estructura de un sistema software. La notación UML permite definir modelos que serán claramente comprensibles por otros desarrolladores facilitando así el mantenimiento del sistema que describe. Especificar: UML permite especificar los procesos de análisis, diseño y codificación de un sistema software. También permite determinar modelos precisos, sin ambigüedades, detallando las partes esenciales de los mismos.

20 Objetivos de UML Construir: Las anteriores características permiten que UML pueda generar código en distintos lenguajes de programación y tablas en una base de datos a partir de modelos UML. Además permite simular el comportamiento de sistemas software. Documentar: UML permite especificar los procesos de análisis, diseño y codificación y también permite documentar los mismos, dejando clara la arquitectura del sistema.

21 Diagramas empleados por 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

22 Diagramas empleados por UML
5.     Diagrama de Estados 6.     Diagrama de Implementación 6.1. Diagrama de Componentes 6.2 Diagrama de Despliegue