Diseño orientado a objetos.

Elaboración
de diagramas estructurales.
Esta es una unidad introductoria al paradigma de orientación a objetos, en la que
conocerás cuales son las principales características de esta forma de desarrollar
software en oposición a la metodología estructurada.

1. Programación orientada a objetos.

1. Conceptos de orientación a objetos.
2. Ventajas de la orientación a objetos.
3. Clases, atributos y métodos.
4. Visibilidad.
5. Objetos. Instanciación.
2. UML.
1. Familiarizándonos con algunos conceptos UML.
1. Notación.
2. Modelos y herramientas.
3. Métodos.
2. Tipos de diagramas UML..
3. Herramientas para la elaboración de diagramas URL.
1. Generación de la documentación
2. UMLet.
4. Ingeniería inversa.
3. Diagrama de clases.
1. Creación de clases.
2. Atributos.
3. Métodos.
4. Relaciones entre clases
1. Cardinalidad o multiplicidad de la relación.
2. Relación de herencia (Generalización).
3. Agregación y composición.
4. Atributos de enlace
5. Restricciones.
5. Pautas para crear diagramas de clases.
1. Obtención de atributos y operaciones.
6. Generación de código a partir del diagrama de clases.
1. Elección del lenguaje de programación. Orientaciones para el
lenguaje java.

Anexo I.- Descarga e instalación de Visual Paradigm.

Anexo II.- Introducción a UMLet.

1. Pantalla principal.
2. Opciones.
1. Atajos de teclado.
2. Importación de diagramas.
3. Exportación de diagramas.
4. Salvar diagramas.
3. Elementos del diagrama.
4. El diagrama.
5. Edición de las propiedades.

Anexo III.- Generación del diagrama de clases de un problema dado.

1. Extracción de los sustantivos de la descripción del problema.

2. Selección de sustantivos como objetos/clases del sistema.
3. Tabla de relación de las clases u objetos con sus atributos.
4. Obtención de los métodos.
5. Obtener relaciones.
6. Documentación adicional.
7. Generación de código a partir del diagrama de clases.

Anexo IV.- Generación del diagrama de clases de otro problema dado.

1. Extracción de los sustantivos de la descripción del problema.

2. Selección de sustantivos como objetos/clases del sistema.
3. Tabla de relación de las clases u objetos con sus atributos.
4. Obtención de los métodos.
5. Obtener relaciones.
6. Documentación adicional.
7. Generación de código a partir del diagrama de clases

Anexo V.- Licencias de recursos

Diseño orientado a objetos. Elaboración de
diagramas estructurales.
conocer procedimientos de análisis y diseño de software, así como alguna
herramienta que permita generar los modelos y la documentación asociada, así que
decide reunir a su equipo para empezar a tratar este tema…
1.- Programación orientada a objetos
La construcción de software es un proceso cuyo objetivo es dar solución a
problemas utilizando una herramienta informática y tiene como resultado la
construcción de un programa informático. Como en cualquier otra disciplina en la
que se obtenga un producto final de cierta complejidad, si queremos obtener un
producto de calidad, es preciso realizar un proceso previo de análisis y
especificación del proceso que vamos a seguir, y de los resultados que
pretendemos conseguir.

El enfoque estructurado.

Sin embargo, cómo se hace es algo que ha ido evolucionando con el tiempo, en un
principio se tomaba el problema de partida y se iba sometiendo a un proceso de
división en subproblemas más pequeños reiteradas veces, hasta que se llegaba a
problemas elementales que se podía resolver utilizando una función. Luego las
funciones se hilaban y entretejían hasta formar una solución global al problema de
partida. Era, pues, un proceso centrado en los procedimientos, se codificaban
mediante funciones que actuaban sobre estructuras de datos, por eso a este tipo de
programación se le llama programación estructurada. Sigue una filosofía en la que
se intenta aproximar qué hay que hacer, para así resolver un problema.

Enfoque orientado a objetos.

La orientación a objetos ha roto con esta forma de hacer las cosas. Con este
nuevo paradigma el proceso se centra en simular los elementos de la realidad
asociada al problema de la forma más cercana posible. La abstracción que permite
representar estos elementos se denomina objeto, y tiene las siguientes
características:

● Está formado por un conjunto de atributos, que son los datos que le
caracterizan y
● Un conjunto de operaciones que definen su comportamiento. Las
operaciones asociadas a un objeto actúan sobre sus atributos para modificar
su estado. Cuando se indica a un objeto que ejecute una operación
determinada se dice que se le pasa un mensaje.

Las aplicaciones orientadas a objetos están formadas por un conjunto de

objetos que interaccionan enviándose mensajes para producir resultados.

Los objetos similares se abstraen en clases,

se dice que un objeto es una instancia de
una clase.
Cuando se ejecuta un programa orientado a objetos ocurren tres sucesos:

● Primero, los objetos se crean a medida que se necesitan.

● Segundo. Los mensajes se mueven de un objeto a otro (o del usuario a un
objeto) a medida que el programa procesa información o responde a la
entrada del usuario.
● Tercero, cuando los objetos ya no se necesitan, se borran y se libera la
memoria.
1.1.- Conceptos de orientación a objetos.
Como hemos visto la orientación a objetos trata de acercarse al contexto del
problema lo más posible por medio de la simulación de los elementos que
intervienen en su resolución y basa su desarrollo en los siguientes conceptos:

● Abstracción: Permite capturar las características y comportamientos

similares de un conjunto de objetos con el objetivo de darles una descripción
formal. La abstracción es clave en el proceso de análisis y diseño orientado a
objetos, ya que mediante ella podemos llegar a armar un conjunto de clases
que permitan modelar la realidad, o el problema que se quiere atacar.
● Encapsulación: Organiza los datos y métodos de una clase, evitando el
acceso a datos por cualquier otro medio distinto a los definidos. El estado de
los objetos sólo debería poder ser modificado desde métodos de la propia
clase Esto permite aumentar la cohesión de los componentes del sistema.
Algunos autores confunden este concepto con el principio de ocultación,
principalmente porque se suelen emplear conjuntamente.
● Modularidad: Propiedad que permite subdividir una aplicación en partes más
pequeñas (llamadas módulos), cada una de las cuales debe ser tan
independiente como sea posible de la aplicación en sí y de las restantes
partes. En orientación a objetos es algo consustancial, ya que los objetos se
pueden considerar los módulos más básicos del sistema.
● Principio de ocultación: La implementación de una clase sólo es conocida
por los responsables de su desarrollo. Gracias a la ocultación, ésta podrá ser
modificada para mejorar su algoritmo de implementación sin tener
repercusión en el resto del programa. Principalmente se oculta las
propiedades de un objeto contra su modificación por quien no tenga derecho
a acceder a ellas. Reduce la propagación de efectos colaterales cuando se
producen cambios.
● Polimorfismo: Consiste en reunir bajo el mismo nombre comportamientos
diferentes. La selección de uno u otro depende del objeto que lo ejecute.
● Herencia: Relación que se establece entre objetos en los que unos utilizan
las propiedades y comportamientos de otros formando una jerarquía. Los
 objetos heredan las propiedades y el comportamiento de todas las clases a
las que pertenecen.
● Recolección de basura: Técnica por la cual el entorno de objetos se
encarga de destruir automáticamente los objetos, y por tanto desvincular su
memoria asociada, que hayan quedado sin ninguna referencia a ellos.

1.2.- Ventajas de la orientación a objetos.

Este paradigma tiene las siguientes ventajas con respecto a otros:

1. Permite desarrollar software en mucho menos tiempo, con menos coste y de

mayor calidad gracias a la reutilización porque al ser completamente modular
facilita la creación de código reusable dando la posibilidad de reutilizar
parte del código para el desarrollo de una aplicación similar.
2. Se consigue aumentar la calidad de los sistemas, haciéndolos más
extensibles ya que es muy sencillo aumentar o modificar la funcionalidad de
la aplicación modificando las operaciones.
3. El software orientado a objetos es más fácil de modificar y mantener
porque se basa en criterios de modularidad y encapsulación en el que el
sistema se descompone en objetos con unas responsabilidades claramente
especificadas e independientes del resto.
4. La tecnología de objetos facilita la adaptación al entorno y el cambio
haciendo aplicaciones escalables. Es sencillo modificar la estructura y el
comportamiento de los objetos sin tener que cambiar la aplicación.

¿Cual es la afirmación más adecuada al paradigma de orientación a objetos?

Permite crear aplicaciones basadas en módulos que pueden reutilizarse, de fácil
modificación y que permiten su ampliación en función del crecimiento del sistema.
1.3.- Clases, atributos y métodos.
Los objetos de un sistema se abstraen, en función de sus características
comunes, en clases.

Una clase está formada por un conjunto de procedimientos y datos que resumen
características similares de un conjunto de objetos.

La clase tiene dos propósitos: definir abstracciones y favorecer la modularidad.

Una clase se describe por su nombre (identifica cada clase del programa) y
por un conjunto de elementos que se denominan miembros. Estos miembros
son:

● Atributos: conjunto de características asociadas a una clase. Pueden verse

como una relación binaria entre una clase y cierto dominio formado por todos
los posibles valores que puede tomar cada atributo. Cuando toman valores
concretos dentro de su dominio definen el estado del objeto. Se definen por
su nombre y su tipo, que puede ser simple o compuesto como otra clase.
● Protocolo: Operaciones (métodos, mensajes) que manipulan el estado. Un
método es el procedimiento o función que se invoca para actuar sobre un
objeto. Un mensaje es el resultado de cierta acción efectuada por un objeto.
Los métodos determinan como actúan los objetos cuando reciben un
mensaje, es decir, cuando se requiere que el objeto realice una acción
descrita en un método se le envía un mensaje. El conjunto de mensajes a los
cuales puede responder un objeto se le conoce como protocolo del objeto.

Por ejemplo, si consideramos un objeto icono en una aplicación gráfica; tendrá

como atributos el tamaño, o la imagen que muestra; y su protocolo puede constar de
mensajes producidos al pulsar el botón sobre el objeto. De esta forma los mensajes
son el único conducto que conectan al objeto con el mundo exterior.

Los valores asignados a los atributos de un objeto concreto hacen a ese objeto ser
único. La clase define sus características generales y su comportamiento.

Un objeto es una concreción de una clase, es decir, en un objeto se concretan

valores para los atributos definidos en la clase, y además, estos valores
podrán modificarse a través del paso de mensajes al objeto.

Así es, el objeto tiene un estado formado por los valores concretos que toman los
atributos de la clase a la que pertenece, además para modificar estos valores
tenemos que hacerlo utilizando los métodos de la clase a través del paso de
mensajes.
1.4.- Visibilidad.
El principio de ocultación es una propiedad de la orientación a objetos que
consiste en aislar el estado de manera que sólo se puede cambiar mediante
las operaciones definidas en una clase. Este aislamiento protege a los datos de
que sean modificados por alguien que no tenga derecho a acceder a ellos,
eliminando efectos secundarios e interacciones. Da lugar a que las clases se dividan
en dos partes:

1. Interfaz: captura la visión externa de una clase, abarcando la abstracción del

comportamiento común a los ejemplos de esa clase.
2. Implementación: comprende como se representa la abstracción, así como
los mecanismos que conducen al comportamiento deseado.

Existen distintos niveles de ocultación que se implementan en lo que se denomina

visibilidad. Es una característica que define el tipo de acceso que se permite a
atributos y métodos y que podemos establecer como:

● Público: Se pueden acceder desde cualquier clase y cualquier parte del

programa.
● Privado: Sólo se pueden acceder desde operaciones de la clase.
● Protegido: Sólo se pueden acceder desde operaciones de la clase o de
clases derivadas en cualquier nivel.

Como norma general a la hora de definir la visibilidad tendremos en cuenta que:

● El estado debe ser privado. Los atributos de una clase se deben modificar
mediante métodos de la clase creados a tal efecto.
● Las operaciones que definen la funcionalidad de la clase deben ser públicas.
 ● Las operaciones que ayudan a implementar parte de la funcionalidad deben
ser privadas (si no se utilizan desde clases derivadas) o protegidas (si se
utilizan desde clases derivadas).

¿Desde dónde se puede acceder al estado de una clase?

Solo desde los métodos de la clase.

1.5.- Objetos. Instanciación.

Una clase es una abstracción que define las características comunes de un conjunto
de objetos relevantes para el sistema.

Cada vez que se construye un objeto en un

programa informático a partir de una clase
se crea lo que se conoce como instancia
de esa clase. Cada instancia en el sistema
sirve como modelo de un objeto del contexto
del problema relevante para su solución, que
puede realizar un trabajo, informar y cambiar
su estado, y "comunicarse" con otros objetos
en el sistema, sin revelar cómo se
implementan estas características.

Un objeto se define por:

 ● Su estado: es la concreción de los atributos definidos en la clase a un valor
concreto.
● Su comportamiento: definido por los métodos públicos de su clase.
● Su tiempo de vida: intervalo de tiempo a lo largo del programa en el que el
objeto existe. Comienza con su creación a través del mecanismo de
instanciación y finaliza cuando el objeto se destruye.

La encapsulación y el ocultamiento aseguran que los datos de un objeto están

ocultos, con lo que no se pueden modificar accidentalmente por funciones externas
al objeto.

Existe un caso particular de clase, llamada clase abstracta, que por sus
características, no puede ser instanciada. Se suelen usar para definir métodos
genéricos relacionados con el sistema que no serán traducidos a objetos concretos,
o para definir las interfaces de métodos, cuya implementación se postpone a futuras
clases derivadas.

Ejemplo de objetos:

1. Objetos físicos: aviones en un sistema de control de tráfico aéreo, casas,

parques.
2. Elementos de interfaces gráficas de usuario: ventanas, menús, teclado,
cuadros de diálogo.
3. Animales: animales vertebrados, animales invertebrados.
4. Tipos de datos definidos por el usuario: Datos complejos, Puntos de un
sistema de coordenadas.
5. Alimentos: carnes, frutas, verduras.

Existe un caso particular de clase, llamada clase abstracta, que, por sus
características, no puede ser instanciada. Se suelen usar para definir métodos
genéricos relacionados con el sistema que no serán traducidos a objetos concretos,
o para definir métodos de base para clases derivadas.

Mientras que un objeto es una entidad que existe en el tiempo y el espacio, una
clase representa sólo una abstracción, "la esencia" del objeto, si se puede decir así.

Concepto Descripción Ejemplo

La representación concreta de los atributos

Persona con nombre, edad y
Estado definidos en la clase, que describen las
altura.
características del objeto.
 Las acciones que un objeto puede realizar o los
Persona que puede caminar,
Comportamiento servicios que puede proporcionar, definidos por
hablar, comer, etc.
los métodos públicos de su clase.

El intervalo de tiempo durante el cual el objeto Instanciación de Persona con

existe en la memoria del programa, comenzando new, destrucción cuando el

Tiempo de vida
con su creación mediante la instanciación y objeto es eliminado por el

finalizando cuando es eliminado de la memoria. recolector de basura.

2.- UML.
Las características de un
lenguaje de modelado de
sistemas orientados a objetos
llamado UML. Este lenguaje
permite construir una serie de
modelos, a través de diagramas
de diferentes visiones de un
proyecto.

—Es importante apreciar como

estos modelos, nos van a
permitir poner nuestras ideas en
común utilizando un lenguaje específico, facilitarán la comunicación, que como
sabéis, es algo esencial para que nuestro trabajo en la empresa sea de calidad.

UML (Unified Modeling Language o Lenguaje Unificado de Modelado) es un

conjunto de herramientas 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 concebido por los autores
de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar
Jacobson y Jim Rumbaugh, de hecho las raíces técnicas de UML son:

● OMT - Object Modeling Technique (Rumbaugh et al.)

● Método-Booch (G. Booch)
● OOSE - Object-Oriented Software Engineering (I. Jacobson)

UML permite a los desarrolladores y desarrolladoras visualizar el producto de

su trabajo en esquemas o diagramas estandarizados denominados modelos
que representan el sistema desde diferentes perspectivas.

¿Porqué es útil modelar?

● Porque permite utilizar un lenguaje común que facilita la comunicación entre

el equipo de desarrollo.
● Con UML podemos documentar todos los artefactos de un proceso de
desarrollo (requisitos, arquitectura, pruebas, versiones,...) por lo que se
dispone de documentación que trasciende al proyecto.
● Hay estructuras que trascienden lo representable en un lenguaje de
programación, como las que hacen referencia a la arquitectura del sistema,
utilizando estas tecnologías podemos incluso indicar qué módulos de
software vamos a desarrollar y sus relaciones, o en qué nodos hardware se
ejecutarán cuando trabajamos con sistemas distribuidos.
 ● Permite especificar todas las decisiones de análisis, diseño e
implementación, construyéndose modelos precisos, no ambiguos y
completos.

Además UML puede conectarse a lenguajes de programación mediante ingeniería

directa e inversa, como veremos.

2.1.- Familiarizándonos con algunos conceptos UML.

A continuación se describen algunos de los términos típicamente usados en UML.
Se acompaña de un ejemplo relacionado con la creación de una melodía musical.

2.1.1.- Notación.
Una notación es un conjunto de símbolos y técnicas para combinarlos, que en el
contexto UML, permiten crear diagramas normalizados. Estas representaciones
posibilitan al analista o desarrollador describir el comportamiento del sistema
(análisis) y los detalles de una arquitectura (diseño) de forma no ambigua.

Que una notación sea detallada no significa que todos sus aspectos deban ser
utilizados en todas las ocasiones. Utilizar UML debe facilitar el
desarrollo/entendimiento de todos los participantes en el proyecto y no complicarlo.
¡Si se crean todos los diagramas al máximo nivel de detalle podría liar más que
aclarar!.

Las notaciones UML deben ser independientes de los lenguajes de

programación.

Un Diagrama es una representación gráfica de una colección de elementos de

modelado (modelo), a menudo dibujada como un grafo con vértices conectados por
arcos (notación).

● Notación musical-1. La notación musical formal considera términos como

pentagrama; notas redonda, blanca, negra, corchea, semicorchea, fusa,
semifusa; clave de sol, fa, do ...

2.1.2.- Modelos y herramientas

Un modelo captura una vista de un sistema del mundo real. Es una abstracción de
dicho sistema considerando un cierto propósito. Así, el modelo describe
completamente aquellos aspectos del sistema que son relevantes al propósito del
modelo, y a un apropiado nivel de detalle.
En UML existen una serie de modelos (diagramas) que nos proporcionan vistas en
las fases de análisis y diseño.
Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen
relaciones de trazabilidad entre los diferentes modelos.

Una herramienta es el soporte automático de una notación. En nuestro ejemplo

hablaríamos de un lápiz, un cuaderno musical, un programa de ordenador, un
órgano ....

Para el desarrollo de diagramas UML en este curso se usará la

aplicación/herramienta UMLet.

2.1.3.- Métodos

Un método es un proceso disciplinado para generar uno/varios modelos que

describen aspectos de un sistema de software en desarrollo, utilizando alguna
notación bien definida.

2.2.- Tipos de diagramas UML.

UML define un sistema como una colección de modelos que describen sus
diferentes perspectivas. Los modelos se implementan en una serie de diagramas
que son representaciones gráficas de una colección de elementos de modelado, a
menudo dibujado como un grafo conexo de arcos (relaciones) y vértices (otros
elementos del modelo).

Los diagramas UML se clasifican en:

● Diagramas estructurales. Representan la visión estática del sistema.

Especifican clases y objetos y como se distribuyen físicamente en el sistema.
● Diagramas de comportamiento. Muestran la conducta en tiempo de
ejecución del sistema, tanto desde el punto de vista del sistema completo
como de las instancias u objetos que lo integran.

En la siguiente imagen aparecen todos los diagramas organizados según su

categoría:
En total se describen trece diagramas para modelar diferentes aspectos de un
sistema, sin embargo no es necesario usarlos todos, dependerá del tipo de
aplicación a generar y del sistema, es decir, se debe generar un diagrama solo
cuando sea necesario.

Diagramas estructurales.

● Diagrama de clases. Muestra los elementos del modelo estático abstracto, y

está formado por un conjunto de clases y sus relaciones.
● Diagrama de objetos. Muestra los elementos del modelo estático en un
momento concreto, habitualmente en casos especiales de un diagrama de
clases o de comunicaciones, y está formado por un conjunto de objetos y sus
relaciones.
● Diagrama de componentes. Especifica la organización lógica de la
implementación de una aplicación, indicando sus componentes, sus
interrelaciones, interacciones y sus interfaces públicas y las dependencias
entre ellos.
● Diagrama de despliegue. Representa la configuración del sistema en tiempo
de ejecución. Aparecen los nodos de procesamiento y sus componentes.
Exhibe la ejecución de la arquitectura del sistema. Incluye nodos, ambientes
operativos tanto de hardware como de software, así como las interfaces que
las conectan, es decir, muestra como los componentes de un sistema se
distribuyen entre los ordenadores que los ejecutan. Se utiliza cuando
tenemos sistemas distribuidos.
 ● Diagrama de estructuras compuestas. Muestra la estructura interna de una
clase, e incluye los puntos de interacción de esta clase con otras partes del
sistema.
● Diagrama de paquetes. Exhibe cómo los elementos del modelo se
organizan en paquetes, así como las dependencias entre esos paquetes.
Suele ser útil para la gestión de sistemas de mediano o gran tamaño.

Diagramas de comportamiento.

● Diagrama de casos de uso. Representa las acciones a realizar en el

sistema desde el punto de vista de los usuarios. En él se representan las
acciones, los usuarios y las relaciones entre ellos. Sirven para especificar la
funcionalidad y el comportamiento de un sistema mediante su interacción con
los usuarios y/u otros sistemas.
● Diagrama de estado de la máquina. Describe el comportamiento de un
sistema dirigido por eventos. En el que aparecen los estados que puede tener
un objeto o interacción, así como las transiciones entre dichos estados.
También se denomina diagrama de estado, diagrama de estados y
transiciones o diagrama de cambio de estados.
● Diagrama de actividades. Muestra el orden en el que se van realizando
tareas dentro de un sistema. En él aparecen los procesos de alto nivel de la
organización. Incluye flujo de datos, o un modelo de la lógica compleja dentro
del sistema.
● Diagramas de interacción.
○ Diagrama de secuencia. Representa la ordenación temporal en el
paso de mensajes. Modela la secuencia lógica, a través del tiempo, de
los mensajes entre las instancias.
○ Diagrama de comunicación/colaboración. Resalta la organización
estructural de los objetos que se pasan mensajes. Ofrece las
instancias de las clases, sus interrelaciones, y el flujo de mensajes
entre ellas. Comúnmente enfoca la organización estructural de los
objetos que reciben y envían mensajes.
○ Diagrama de interacción. Muestra un conjunto de objetos y sus
relaciones junto con los mensajes que se envían entre ellos. Cada
nodo de actividad dentro del diagrama puede representar otro
diagrama de interacción.
○ Diagrama de tiempos. Muestra el cambio en un estado o una
condición de una instancia o un rol a través del tiempo. Se usa
normalmente para exhibir el cambio en el estado de un objeto en el
tiempo, en respuesta a eventos externos.

En la imagen aparecen todos los diagramas organizados según su categoría. En

total se describen trece diagramas para modelar diferentes aspectos de un sistema,
sin embargo no es necesario usarlos todos, dependerá del tipo de aplicación a
generar y del sistema.

2.3.- Herramientas para la elaboración de diagramas UML.

La herramienta más simple que se puede utilizar para generar diagramas es lápiz y
papel, hoy día, sin embargo, podemos acceder a herramientas CASE que facilitan
en gran manera el desarrollo de los diagramas UML. Estas herramientas suelen
contar con un entorno de ventanas tipo wysiwyg, permiten documentar los
diagramas e integrarse con otros entornos de desarrollo incluyendo la generación
automática de código y procedimientos de ingeniería inversa.

Podemos encontrar, entre otras, las siguientes herramientas:

● Rational Systems Developer de IBM: Herramienta propietaria que permite

el desarrollo de proyectos software basados en la metodología UML.
Desarrollada en origen por los creadores de UML ha sido recientemente
absorbida por IBM. Ofrece versiones de prueba, y software libre para el
desarrollo de diagramas UML.
● Visual Paradigm for UML (VP-UML): Incluye una versión para uso no
comercial que se distribuye libremente sin más que registrarse para obtener
un archivo de licencia (bajo licencia LGPL).
○ Incluye diferentes módulos para realizar desarrollo UML, diseñar bases
de datos, realizar actividades de ingeniería inversa y diseñar con Agile.
○ Compatible con UML 2.0.
○ Admite la generación de informes en formatos PDF, HTML y otros.
○ Es compatible con los IDE de Eclipse, Visual Studio .net, IntellijDEA y
NetBeans.
○ Multiplataforma.
○ Incluye instaladores para Windows y Linux.
● ArgoUML: se distribuye bajo licencia Eclipse. Soporta los diagramas de UML
1.4, y genera código para java y C++. Para poder ejecutarlo se necesita la
plataforma java. Admite ingeniería directa e inversa.
● UMLet: herramienta UML de código abierto y libre distribución. Dispone de un
interfaz de usuario sencillo de utilizar

Las herramienta CASE para la elaboración de diagramas UML sirven solo para
la generación de los diagramas asociados al análisis y diseño de una
aplicación. ¿Verdadero o falso? FALSO
Así es, además de permitir la creación y edición de los diagramas tienen
funcionalidad para la documentación, la generación automática de código y
operaciones de ingeniería inversa, que generan diagramas a partir de código
fuente o incluso binario.
2.3.1.- Generación de la documentación.
Como en todos los diagramas UML, podemos hacer las anotaciones que
consideremos necesarias abriendo la especificación de cualquiera de los elementos,
clases o relaciones, o bien del diagrama en si mismo en la pestaña "Specification".

La ventana del editor cuenta con herramientas para formatear el texto y darle un
aspecto bastante profesional, pudiendo añadir elementos como imágenes o
hiperenlaces.

También se puede grabar un archivo de voz con la documentación del elemento

usando el icono Grabar.

Generar informes

Cuando los modelos están completos podemos generar un informe en varios

formatos diferentes (HTML, PDF o Word) con la documentación que hemos escrito.
Para generar un informe hacemos:

Desde VP-UML accedemos a Tools >> Reports >> Report writer y seleccionamos el
tipo de informe que queremos.

Desde el SDE para NetBeans seleccionamos Modelin >> Reports >> Report writer.

En ambos casos, una vez que elegimos el tipo de informe, obtendremos la siguiente
ventana en la que seleccionamos entre otros:

● Qué diagramas queremos que intervengan y donde se almacenará el

informe.
● La pestaña opciones (Options) permite configurar los elementos que se
añadirán al informe, como tablas de contenidos, títulos, etc.
● Las propiedades de la página.
● Si se va a añadir una marca de agua.

El resultado es un archivo (.html, .pdf o .doc) en el directorio de salida que hayamos

indicado con la documentación de los diagramas seleccionados.
2.3.2.- UMLet.
Para los diagramas UML que se van a realizar a lo largo del curso se va a usar la
herramienta UMLet. Algunas de sus características son:

● Es un software gratuito.
● Es multiplataforma.
● Incluye un módulo para integrarse con Eclipse.
● Dispone de la versión web UMLetino http://www.umletino.com/umletino.html,
que no precisa instalación.

La instalación de UMLet como herramienta de escritorio es muy sencilla:

● Descargar UMLet standalone del sitio oficial de descargas

https://www.umlet.com/changes.htm , actualmente se encuentra en versión
14.3. El fichero descargado es umlet-standalone-14.3.0.zip.
● Descomprimir el fichero, el paquete proporciona un conjunto de ficheros bajo
el directorio uml con ejecutables para diferentes plataformas. En particular,
usaremos el archivo comprimido Java umlet.jar para lanzarlo desde nuestro
entorno de trabajo.
● Podemos copiar la carpeta descomprimida en alguna ruta del sistema de
archivos.
Utilizando UMLet dibujaremos diferentes diagramas a lo largo de este tema y del
siguiente.

Nota: Si tienes problemas para ejecutar UMLet no dudes en utilizar UMLetino.

En el Anexo II se va hacer una breve explicación de las diversas posibilidades que

ofrece UMLet

2.4.- Ingeniería inversa.

La ingeniería inversa se define como el proceso de analizar código,

documentación y comportamiento de una aplicación para identificar sus
componentes actuales y sus dependencias y para extraer y crear una
abstracción del sistema e información del diseño. El sistema en estudio no es
alterado, sino que se produce un conocimiento adicional del mismo.

Tiene como caso particular la reingeniería que es el proceso de extraer el código

fuente de un archivo ejecutable.

La ingeniería inversa puede ser de varios tipos:

● Ingeniería inversa de datos: Se aplica sobre algún código de bases datos

(aplicación, código SQL, etc.) para obtener los modelos relacionales o sobre
el modelo relacional para obtener el diagrama entidad-relación.
● Ingeniería inversa de lógica o de proceso: Cuando la ingeniería inversa se
aplica sobre el código de un programa para averiguar su lógica (reingeniería),
o sobre cualquier documento de diseño para obtener documentos de análisis
o de requisitos.
● Ingeniería inversa de interfaces de usuario: consiste en estudiar la lógica
interna de las interfaces para obtener los modelos y especificaciones que
sirvieron para su construcción, con objeto de tomarlas como punto de partida
en procesos de ingeniería directa que permitan su actualización.
3.- Diagrama de clases
El diagrama de clases puede considerarse el más importante de todos los
existentes en UML, encuadrado dentro de los diagramas estructurales, representa
los elementos estáticos del sistema, sus atributos y comportamientos, y como se
relacionan entre ellos. Contiene las clases del dominio del problema, y a partir de
éste se obtendrán las clases que formarán después el programa informático que
dará solución al problema.

En un diagrama de clases podemos encontrar los siguientes elementos:

● Clases: agrupan conjuntos de objetos con características comunes, que

llamaremos atributos, y su comportamiento, que serán métodos. Los atributos
y métodos tendrán una visibilidad que determinará quién puede acceder al
atributo o método. Por ejemplo, una clase puede representar a un coche, sus
atributos serán la cilindrada, la potencia y la velocidad, y tendrá dos métodos,
uno para acelerar, que subirá la velocidad, y otro para frenar que la bajará.
● Relaciones: en el diagrama se representan relaciones reales entre los
elementos del sistema a los que hacen referencia las clases. Pueden ser de
asociación, agregación, composición y generalización. Por ejemplo, si
tenemos las clases persona y coche, se puede establecer la relación conduce
entre ambas. O una clase alumno puede tener una relación de generalización
respecto a la clase persona.
● Notas: se representan como un cuadro donde podemos escribir comentarios
que ayuden al entendimiento del diagrama.
● Elementos de agrupación: Se utilizan cuando hay que modelar un sistema
grande, entonces las clases y sus relaciones se agrupan en paquetes, que a
su vez se relacionan entre sí.

3.1.- Creación de clases.

Una clase se representa en el diagrama como un rectángulo divido en tres filas:
arriba aparece el nombre de la clase, a continuación los atributos con su visibilidad y
después los métodos con su visibilidad.

3.2.- Atributos.
Forman la parte estática de la clase. Son un conjunto de variables para las que es
preciso definir:
 ● Su nombre.
● Su tipo, puede ser un tipo simple, que coincidirá con el tipo de dato que se
seleccione en el lenguaje de programación final a usar, o compuesto,
pudiendo incluir otra clase.

Además se pueden indicar otros datos como un valor inicial o su visibilidad. La

visibilidad de un atributo se puede definir como:

● Público (+): Se pueden acceder desde cualquier clase y cualquier parte del
programa.
● Privado(-): Sólo se pueden acceder desde operaciones de la clase.
● Protegido(#): Sólo se pueden acceder desde operaciones de la clase o de
clases derivadas en cualquier nivel.
● Paquete(~): se puede acceder desde las operaciones de las clases que
pertenecen al mismo paquete que la clase que estamos definiendo. Se usa
cuando el lenguaje de implementación tiene esta característica como es el
caso de Java.