PDF de programación - Desarrollo Orientado a Objetos con UML

Desarrollo Orientado a Objetos con UML

Copyright (c) 2004 Xavier Ferré Grau (Univ. Politécnica de Madrid - España) y María
Isabel Sánchez Segura (Univ. Carlos III de Madrid - España)
Permiso para copiar, distribuir y/o modificar este documento bajo los términos de la
Licencia de Documentación Libre GNU (GNU Free Documentation License), Versión 1.2
o cualquier otra versión posterior publicada por la Free Software Foundation; sin Secciones
Invariantes, Textos de la Cubierta Frontal, ni textos de la Cubierta Posterior.

I. UML
I.1 Introducción

II. NOTACIÓN BÁSICA UML
II.1 Modelos
II.2 Elementos Comunes a Todos los Diagramas
II.2.1 Notas
II.2.2 Dependencias
II.3 Diagramas de Estructura Estática
II.3.1 Clases
II.3.2 Objetos
II.3.3 Asociaciones
II.3.3.1 Nombre de la Asociación y Dirección
II.3.3.2 Multiplicidad
II.3.3.3 Roles
II.3.3.4 Agregación
II.3.3.5 Clases Asociación
II.3.3.6 Asociaciones N-Arias
II.3.3.7 Navegabilidad
II.3.4 Herencia
II.3.5 Elementos Derivados
II.4 Diagrama de Casos de Uso
II.4.1 Elementos
II.4.1.1 Actores
II.4.1.2 Casos de Uso
II.4.1.3 Relaciones entre Casos de Uso
II.5 Diagramas de Interacción
II.5.1 Diagrama de Secuencia
II.5.2 Diagrama de Colaboración
II.6 Diagrama de Estados


III NOTACIÓN AVANZADA UML
III.1 Modelado Dinámico
III.1.1 Diagramas De Actividades
III.1.2 Contenido del diagrama de actividades
III.1.2.1 Estados de actividad y estados de acción

III.1.2.2 Transiciones
III.1.2.3 Bifurcaciones
III.1.2.4 División y unión
III.1.2.5 Calles
III.2 Modelado Físico De Un Sistema OO
III.2.1 Componentes
III.2.1.1 Interfaces
III.2.1.2 Tipos de componentes
III.2.1.3 Organización de componentes
III.2.1.4 Estereotipos de componentes
III.2.2 Despliegue
III.2.2.1 Nodos
III.2.2.2 Nodos y componentes
III.2.3 Diagramas de Componentes
III.2.3.1 Algunos conceptos
III.2.3.2 Usos más comunes
III.2.4 Diagramas de Despliegue
III.2.4.1 Técnicas más comunes de modelado
III.2.5 Arquitectura del Sistema
III.2.5.1 Arquitectura de tres niveles
III.2.5.2 Arquitectura de tres niveles orientadas a objetos
III.2.5.3 Arquitectura MULTI-nivel
III.2.5.4 Paquetes
III.2.5.5 Identificación de Paquetes


IV DESARROLLO ORIENTADO A OBJETOS
IV.1 Proceso de Desarrollo
IV.1.1 Visión General
IV.2 Fase de Planificación y Especificación de Requisitos
IV.2.1 Actividades
IV.2.2 Requisitos
IV.2.3 Casos de Uso
IV.2.3.1 Casos de Uso de Alto Nivel
IV.2.3.2 Casos de Uso Expandidos
IV.2.3.3 Identificación de Casos de Uso
IV.2.3.4 Identificación de los Límites del Sistema
IV.2.3.5 Tipos de Casos de Uso
IV.2.3.6 Consejos Relativos a Casos de Uso
IV.2.4 Construcción del Modelo de Casos de Uso
IV.2.5 Planificación de Casos de Uso según Ciclos de Desarrollo
IV.2.5.1 Caso de Uso Inicialización
IV.3 Fase de Construcción: Diseño de Alto Nivel
IV.3.1 Actividades
IV.3.2 Modelo Conceptual
IV.3.2.1 Identificación de Conceptos

IV.3.2.2 Creación del Modelo Conceptual
IV.3.2.3 Identificación de Asociaciones
IV.3.2.4 Identificación de Atributos
IV.3.3 Glosario
IV.3.4 Diagramas de Secuencia del Sistema
IV.3.4.1 Construcción de un Diagrama de Secuencia del Sistema
IV.3.5 Contratos de Operaciones
IV.3.5.1 Construcción de un Contrato
IV.3.5.2 Post-condiciones
IV.3.6 Diagramas de Estados
IV.4 Fase de Construcción: Diseño de Bajo Nivel
IV.4.1 Actividades
IV.4.2 Casos de Uso Reales
IV.4.3 Diagramas de Interacción
IV.4.3.1 Creación de Diagramas de Interacción
IV.4.4 Diagrama de Clases de Diseño
IV.4.4.1 Relaciones de Dependencia para Representar Visibilidad entre
Clases
IV.4.4.2 Construcción de un Diagrama de Clases de Diseño
IV.4.4.3 Navegabilidad
IV.4.4.4 Visibilidad de Atributos y Métodos
IV.4.5 Otros Aspectos en el Diseño del Sistema
IV.5 Fases de Implementación y Pruebas


V BIBLIOGRAFÍA
VI WEBS RECOMENDADAS
 

 

 

I.1 Introducción

UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y
documentar los elementos que forman un sistema software orientado a objetos. Se ha
convertido en el estándar de facto de la industria, debido a que ha sido impulsado por los
autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar
Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa Rational
Software Co. para crear una notación unificada en la que basar la construcción de sus
herramientas CASE. En el proceso de creación de UML han participado, no obstante, otras
empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así
como grupos de analistas y desarrolladores.

Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a
que incorpora las principales ventajas de cada uno de los métodos particulares en los que se
basa (principalmente Booch, OMT y OOSE). UML ha puesto fin a las llamadas “guerras de
métodos” que se han mantenido a lo largo de los 90, en las que los principales métodos
sacaban nuevas versiones que incorporaban las técnicas de los demás. Con UML se fusiona
la notación de estas técnicas para formar una herramienta compartida entre todos los
ingenieros
objetos.

desarrollo

orientado

en

a

software

que

trabajan

el


Uno de los objetivos principales de la creación de UML era posibilitar el intercambio de
modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello
era necesario definir una notación y semántica común. En la Figura 2 se puede ver cuál ha
sido la evolución de UML hasta la creación de UML 1.3, en el que se basa este documento.
Hay que tener en cuenta que el estándar UML no define un proceso de desarrollo
específico, tan solo se trata de una notación. En este curso se sigue el método propuesto por
Craig Larman [Larman99] que se ajusta a un ciclo de vida iterativo e incremental dirigido
por casos de uso.

En la parte II de este texto se expone la notación y semántica básica de UML, en la parte III
se presentan conceptos avanzados de la notación UML, mientras que en la parte IV se
presenta el método de desarrollo orientado a objetos de Larman, que se sirve de los
modelos de UML que se han visto anteriormente.

II.1 Modelos

Un modelo representa a un sistema software desde una perspectiva específica. Al igual que
la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista
desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del
sistema.

Los modelos de UML que se tratan en esta parte son los siguientes:
• Diagrama de Estructura Estática.
• Diagrama de Casos de Uso.
• Diagrama de Secuencia.
• Diagrama de Colaboración.
• Diagrama de Estados.

II.2 Elementos Comunes a Todos los Diagramas

II.2.1 Notas
Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de
un diagrama. Es un modo de indicar información en un formato libre, cuando la notación
del diagrama en cuestión no nos permite expresar dicha información de manera adecuada.
Una nota se representa como un rectángulo con una esquina doblada con texto en su
interior. Puede aparecer en un diagrama tanto sola como unida a un elemento por medio de
una línea discontinua. Puede contener restricciones, comentarios, el cuerpo de un
procedimiento, etc.


II.2.2 Dependencias
La relación de dependencia entre dos elementos de un diagrama significa que un cambio en
el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el
elemento destino habría que revisar el elemento origen). Una dependencia se representa por
medio de una línea de trazo discontinuo entre los dos elementos con una flecha en su
extremo. El elemento dependiente es el origen de la flecha y el elemento del que depende



es el destino (junto a él está la flecha).



II.3 Diagramas de Estructura Estatica

Los Diagramas de Estructura Estática de UML se van a utilizar para representar tanto
Modelos Conceptuales (ver sección IV.3.2) como Diagramas de Clases de Diseño (ver
sección IV.4.4). Ambos usos son distintos conceptualmente, mientras los primeros modelan
elementos del dominio los segundos presentan los elementos de la solución software.
Ambos tipos de diagramas comparten una parte de la notación para los elementos que los
forman (clases y objetos) y las relaciones que existen entre los mismos (asociaciones). Sin
embargo, hay otros elementos de notación que serán exclusivos de uno u otro tipo de
diagrama.

II.3.1 Clases
Una clase se representa mediante una caja subdividida en tres partes: En la superior se
muestra el nombre de la clase,