PDF de programación - Introducción a UML - Lenguaje para modelar objetos

Introducción a UML

Lenguaje para modelar objetos

Juan Manuel Cueva Lovelle

Catedrático de E.U. de Lenguajes y Sistemas Informáticos

Departamento de Informática

Universidad de Oviedo (España)

Octubre 1999

Tabla de contenidos

• 1. Modelos de desarrollo de software
• 2. Análisis y diseño Orientado a Objetos
• 3. Proceso de Análisis y Diseño preliminar
• 4. Proceso de Diseño detallado
• 5. ¿Qué es UML?
• 6. Documentos de Análisis
• 7. Especificación de Requisitos
• 8. Casos de Uso
• 9. Escenarios
• 10. Diagramas de Secuencia
• 11. Diagramas de Colaboración
• 12. Diagramas Estáticos
• 13. Diagramas de Actividad
• 14. Diagramas de Estados
• 15. Diagramas de Implementación

Bibliografía

•

•

•

•

•

•

•

•

•

•

[Bock/Odell 94] C. Bock and J. Odell, “A Foundation For Composition,” Journal of
Object-oriented Programming, October 1994.

[Booch 94] G.Booch. Object-oriented analysis and design with applications.
Benjamin Cummings (1994). Versión castellana: Análisis y diseño orientado a objetos
con aplicaciones. 2ª Edición. Addison-Wesley/ Díaz de Santos (1996).

[Booch 99] G.Booch., J. Rumbaugh, I. Jacobson The unified modeling language. User
guide. Addison-Wesley (1999). Versión castellana: El lenguaje Unificado de
Modelado.Addison-Wesley (1999).

[Cook 94] S. Cook and J. Daniels, Designing Object Systems: Object-oriented
Modelling with Syntropy, Prentice-Hall Object-Oriented Series, 1994.

[Eriksson 98] H-E Eriksson & M. Penker. UML Toolkit. Wiley, 1998.

[Fowler 97] M. Fowler with K. Scott, UML Distilled: Applying the Standard Object
Modeling Language, ISBN 0-201-32563-2, Addison-Wesely, 1997.

[Jacobson 92] I. Jacobson, M. Christerson, P. Jonsson, G. Övergaard. Object-Oriented
Software Enginneering. A use Case Driven Approach., ISBN 0-201-54435-0,
Addison-Wesely, 1992.

[Lee 97] R. C.Lee & W. M. Tepfenhart. UML and C++, Prentice-Hall, 1997

[Rumbaught 91] Rumbaught J., Blaha M., Premerlani W., Wddy F., Lorensen W.
Object-oriented modeling and design. Prentice-Hall (1991). Versión castellana:
Modelado y diseño orientado a objetos. Metodología OMT. Prentice-Hall (1996)

[UML] UML Notation Guide, Version 1.1, Sep-97, www.rational.com/uml

Método y metodologías

• Un método es un proceso disciplinado para generar un

conjunto de modelos que describen varios aspectos de un
sistema de software en desarrollo, utilizando alguna
notación bien definida

• Una metodología es una colección de métodos aplicados

a lo largo del ciclo de vida del desarrollo de software y
unificados por alguna aproximación general o filosófica

– La mayor parte de las metodologías puede catalogarse en

uno de los grupos siguientes:

• Diseño estructurado descendente

– Yourdon y Constantine
– Wirth
– Dahl, Dijkstra y Hoare
• Diseño dirigido por datos

Jackson

–
– Warnier y Orr

• Diseño orientado a objetos son las que siguen el modelo de

objetos

– Booch
– OMT (Rumbaugh et al.)
– Objectory (Jacobson et al.)
– Schlaer-Mellor
– Coad/Yourdon
– Fusion (Coleman et al.)

Juan Manuel Cueva Lovelle

6-1

Notación

• Una notación es un conjunto de diagramas normalizados

que posibilita al analista o desarrollador el describir el
comportamiento del sistema (análisis) y los detalles de
una arquitectura (diseño) de forma no ambigua

– La acción de dibujar un diagrama no constituye ni análisis

ni diseño

– Una notación no es un fin por si misma
– El hecho de que una notación sea detallada no significa
que todos sus aspectos deban ser utilizados en todas las
ocasiones

– La notación son como los planos para un arquitecto o un

ingeniero

– Una notación no es más que un vehículo para capturar los
razonamientos acerca del comportamiento y la arquitectura
de un sistema

– Las notaciones deben ser lo más independientes posibles de

los lenguajes de programación, sin embargo facilita el
proceso de desarrollo que exista una equivalencia entre la
notación y los lenguajes de programación

– El propósito de este tema es describir la sintaxis y

semántica de la notación que se utiliza para el análisis y
diseño orientado a objetos

Juan Manuel Cueva Lovelle

6-2

Modelos, metamodelos y

herramientas

• Un metamodelo es la descripción de un modelo
• Un modelo es el resultado del análisis y diseño
• Una herramienta es el soporte automático de una notación

Herramientas

Notación

Metamodelo

Juan Manuel Cueva Lovelle

6-3

Comparación de metodologías

•

•

•

Con el paso del tiempo las metodologías de análisis y diseño
orientado a objetos han ido convergiendo en

– Conceptos de modelado similares
– Procesos similares

Las principales diferencias están en la notación

– Diferentes iconos para la representación de los artefactos del diseño
– Diferentes diagramas para expresar las relaciones entre clases y

objetos

La experiencia indicará que es lo que se debe utilizar y lo que se
debe dejar de lado

Juan Manuel Cueva Lovelle

6-4

Desarrollo de software

Modelo en cascada

Requisitos

Análisis

Diseño preliminar y detallado

Implementación & prueba unitaria

Integración

Mantenimiento

Juan Manuel Cueva Lovelle

5-1

Desarrollo de software

Modelo en espiral

Esfuerzo

Diseño

Implementación

Prueba

Análisis

Juan Manuel Cueva Lovelle

Tiempo

5-2

Análisis y diseño orientado a objetos

Requisitos

Implementación

Juan Manuel Cueva Lovelle

5-3

Análisis Orientado a Objetos

Preguntas que se deben plantear

• ¿Cuál es el comportamiento que se desea en el sistema?
• ¿Qué objetos existen en el sistema?
•¿Cuáles son las misiones de los objetos para llevar a cabo
el comportamiento deseado del sistema?

Diseño Orientado a Objetos

Preguntas que se deben plantear

Modelo lógico
• ¿Qué clases existen y como se relacionan estas clases?
• ¿Qué mecanismos se utilizan para regular la forma en
que los objetos colaboran?
Modelo físico
• ¿Dónde debería declararse y construirse cada clase y
objeto?
• ¿A qué procesador debería asignarse un proceso, y para
un procesador dado, cómo deberían planificarse sus
múltiples procesos?

Juan Manuel Cueva Lovelle

5-4

El modelo del desarrollo orientado a objetos

•

Se definen distintas dimensiones del modelo

– El modelo estático describe la estructura estática del sistema

• El modelo lógico define la arquitectura del sistema desde el punto de

vista de las abstracciones principales y mecanismos

– Diagramas de clases
– Diagramas de objetos

• El modelo físico define la arquitectura del sistema desde el punto de

vista de la composición concreta hardware y software

– Diagrama de módulos
– Diagrama de procesos

– Modelo dinámico describe la evolución dinámica y las

interacciones entre objetos

• Diagramas de transición de estados
• Diagramas de interacción o de seguimiento de sucesos

– OMT añade el modelo funcional (eliminado posteriormente)

• Diagrama de flujo de datos

•
•

Por cada dimensión se define una serie de diagramas que denotan una vista de los modelos del sistema
Cuando el modelo es estable cada uno de los diagramas permanece semánticamente consistente con el
resto de los diagramas

Juan Manuel Cueva Lovelle

6-5

Proceso de Análisis y Diseño Preliminar

Aunque el proceso es iterativo los pasos fundamentales son los siguientes:

1. Título de la aplicación

El título de una aplicación debe reflejar de la mejor forma posible sus fines y su funcionalidad

2. Documentos de análisis

–
–

Son la documentación que aporta el cliente que encarga la aplicación
También es la documentación elaborada de forma informal en reuniones de trabajo para
entender las solicitudes del cliente

3. Especificación de Requisitos o Requerimientos

–
–

Es la especificación más técnica y elaborada de los documentos de análisis
Es importante codificar los requisitos para poder seguirlos a lo largo del proceso de
construcción del software

4. Diagramas de Casos de Uso

–
–
–
–

Es un diagrama que muestra sistemas, casos de uso y actores
Es una documentación que describe cada caso de uso, cada sistema y cada actor
Es importante codificar cada caso de uso
Los casos de uso sólo muestran aspectos muy generales

5. Escenarios y sub-escenarios

–
–
–

A cada caso de uso le corresponden varios escenarios donde se pueden mostrar los detalles
Cada escenario puede dividirse en sub-escenarios para bajar más el nivel de detalle
Los escenarios se codifican siguiendo los valores de los casos de uso

6. Diagramas de Secuencia

–
–
–

Se corresponden con los escenarios y sub-escenarios pero con mucho más detalle
Siguen la misma codificación que los escenarios y sub-escenarios
Algunos diagramas de secuencia pueden refinarse más en la fase de diseño detallado

7. Diccionario de datos

–
–
–
–
–

Contiene todas las clases
Se pueden ir definiendo los miembros de las clases (datos y métodos)
Se iré refinando paso a paso en cada iteración
Las herramientas lo van construyendo automáticamente

También se pueden utilizar fichas CRC para obtener el diccionario de datos

Juan Manuel Cueva Lovelle

5-5

Proceso de Diseño Detallado

Es continuación del análisis y diseño preliminar, pero como es un proceso iterativo en

muchos casos será necesario volver al análisis y diseño preliminar

8. Diagramas de Colaboración

9. Diagramas Estáticos

10. Diagramas de Actividad

11. Diagramas de Estados

12. Diagramas de implementación

• En algunos casos en el diseño preliminar es necesario hacer algunos
diagramas del diseño detallado pero de forma sencilla
• El diseño preliminar puede ser interesante para poder dar una idea de los
costes y de los tiempos de desarrollo de una aplicación

Especificaciones del dominio
del problema a resolver

AOO

DOO

Metodologías de descomposición en objetos

y notaciones para expresar los modelos lógico y físico

POO

Características de los lenguajes, marcos de

aplicación y entornos de desarrollo

Juan Manuel Cueva Lovelle

5-6

Unified Modeling Language (UML)

[UML]

• UML es el sucesor de la ola de métodos de A y DOO que

aparecieron a finales de los 80 y principios de los 90

• UML unifica principalmente los métodos de Booch, Rum