Unidad 2

UNIDAD
2
CURSO DE UML Y PATRONES DE DISEÑO DE SOFTWARE
Diseño Orientado a Objetos

Web: www.redtecnologica.org
E-mail: info@redtecnologica.org
Curso de UML y Patrones de Diseño de

Software
1. Introducción
Dentro de los ciclos de vida de desarrollo de software suele haber etapas o instancias
(normalmente al inicio del proyecto, si se sigue un modelo en cascada, o al inicio de
cada ciclo nuevo, si se sigue un modelo iterativo) donde se desarrollan actividades que
sirve de base para el desarrollo propiamente dicho y las etapas posteriores de pruebas,
despliegue y mantenimiento.
Son referimos a las actividades que podemos sintetizar en análisis de distintos tipos
(económico-financieros, funcionales, técnicos, etc.). Cada una de estas instancias, desde
el comienzo hasta el producto de análisis final va incrementando su nivel de detalle,
desde un bosquejo hasta un documento concreto que es tomado e interpretado por un
programador.
Estas actividades están enmarcadas dentro de distintos modelos. Enfocándonos en

aquellos que nos resultan de interés, nos encontramos con el Modelo de Casos de Uso,
que precede al Modelo de Análisis y al Modelo de Diseño. Sobre el Modelo de Casos
de Uso no profundizaremos en este curso, dado que se encuentra fuera del alcance de
lo que se pretende desarrollar (aunque se presenta una serie de características en esta
misma Unidad). No así los Modelos de Análisis y Diseño, que integran las actividades
de Análisis y Diseño Orientado a Objetos (ADOO), donde resulta importante generar
documentación clara, completa, robusta y portable.
Aquí es donde entra en juego UML, justamente como herramienta para concretizar
estos Modelos. Para conocer sobre estos modelos y su implementación con UML, se
desarrollan a continuación ambos tópicos.
1
2. El Modelo de Análisis
Este Modelo se utiliza para lograr una mejor compresión de los requerimientos expresados
en casos de uso (y que fueran definidos durante el análisis funcional) y para refinarlos
enunciándolos como colaboraciones entre objetos conceptuales que describen características
estructurales y de comportamiento del sistema. Resulta de utilidad como una primera
acercamiento al diseño del sistema.
En esta etapa se toma cada caso de uso y se efectúa la realización del mismo. Esta realización
contiene las descripciones de las interacciones entre los objetos que se llevan a cabo durante
la ejecución de ese objeto a la vez que se mantiene una trazabilidad con el propio caso de
uso.
Notaremos lo importante de algunos conceptos que irán surgiendo,

como el caso de la trazabilidad, siendo este un elemento
importante y característico de UML. A través de la trazabilidad es
que lograremos conectar clases, componentes y hasta diagramas
con los elementos que los preceden. De esta forma podríamos "navegar" desde los
requerimientos, pasando por los casos de uso, hasta llegar a un diagrama de de clases
que muestre como se van a desarrollar esos requerimientos, e incluso sería posible
continuar hasta el mismo diagrama de despliegue para ver cómo se van a empaquetar
y desplegar en un servidor los componentes involucrados. Las herramientas actuales
de modelado de UML presentan características que realizan la gestión de esta
trazabilidad en forma transparente para el usuario.
El tipo, representado por la clase a que la pertenecen los objetos que posee estas
interacciones, se analiza a través de tres representaciones diferentes del sistema que está
siendo analizado:
• La interfaz entre el sistema y sus actores
• La información utilizada en el sistema
• La lógica de control del sistema
Estas representaciones se definen a través de una serie de estereotipos que se les dan a las
clases de análisis:
• Clases de Interfaz (“boundary”, en inglés )
2
• Clases de Entidad ("entity”, en inglés)
• Clases de Control (“control”, en inglés
Más adelante, en esta misma Unidad profundizaremos sobre estos estereotipos.
Los estereotipos son uno de los mecanismos que se utilizan para

extender el lenguaje que nos provee por defecto UML y es,
probablemente, el más utilizado y difundido, por su simpleza de
uso y claridad que aporta. Básicamente se trata de etiquetas que se
aplican a elementos (componentes, clases, objetos) y relaciones (asociaciones,
invocaciones) y que aportan un significado especial y adicional la originalmente
proporcionado.
En resumen, el Modelo de análisis brinda la posibilidad de efectuar una

primera aproximación a la estructura del sistema, expresándola en
términos de objetos conceptuales de tipo Interfaz, Entidad y Control; y al
comportamiento del mismo, describiendo la forma en que interactúan
esos objetos conceptuales por medio de “realizaciones” de los casos de uso.
3
2.1 Aplicación del Modelo de Análisis
Es utilizado como un instrumento para documentar el análisis de los requerimientos

(obtenidos en el Modelo de Casos de Uso), y resulta de gran importancia dado que:
• Permite obtener mayor nivel de detalle de los requerimientos.
• Permite la utilización de UML, a la vez que se razona sobre los aspectos internos del
funcionamiento del sistema que está siendo analizado.
• Provee una forma de organizar los requerimientos de manera de facilitar su

comprensión y posterior mantenimiento de los mismos, por ejemplo, ante cambios
de requerimientos.
• Brinda una visión incremental del problema analizado, desde un nivel de detalle alto
hasta el nivel de detalle buscado.
Estos factores hacen que el Modelo de Análisis actúe como un puente que permite una
transición suave entre los requerimientos (Modelo de Casos de Uso) y el diseño (Modelo de
Diseño) del sistema.
A continuación enumeramos algunas características para contrastar el Modelo de Análisis con

el Modelo de Casos de Usos:
Modelo de casos de uso Modelo de análisis

Descripto en el lenguaje del cliente/usuario Descripto en el lenguaje técnico
Vista externa del sistema Vista interna del sistema
Estructurado en casos de uso. Estructurado con clases estereotipadas
(clases de análisis).
Usado como un “contrato” entre el cliente y Usado por los desarrolladores para entender
el equipo de desarrollo sobre lo que el cómo el sistema debería ser diseñado e
sistema debe y no debe hacer (alcance). implementado.
Puede haber redundancias e inconsistencias No debería haber redundancias e
entre requerimientos. inconsistencias entre requerimientos.
Captura la funcionalidad del sistema. Define cómo realizar la funcionalidad
dentro del sistema.
Define casos de uso para que sean Define realizaciones de casos de uso, cada
analizados en el Modelo de Análisis. una de ellas representa el análisis de un caso
de uso del modelo de casos de uso
4
2.2 Componentes del Modelo de Análisis
Los principales elementos que componen este Modelo son:

• Los Paquetes de Análisis
• Las Clases de Análisis
• Las Realizaciones de los Casos de Uso
• Descripción de Arquitectura
2.2.1 Paquetes de análisis
Los Paquetes de Análisis son un artefacto utilizado para agrupar Clases de Análisis y
realizaciones de casos de uso, buscando obtener paquetes con cohesión (fuerte relación a
nivel funcional) y débilmente acoplamiento (mínima dependencia entre paquetes).
El principal objetivo es separar funcionalmente el problema a analizado para poder ser
tratado en forma paralela.
Un ejemplo de Paquete de Análisis podría ser:
2.2.2 Clases de análisis
Las Clases de Análisis se ocupan de la gestión de los requerimientos funcionales,

describiéndolos en forma narrativa, sin dar mayores detalles sobre las operaciones o
métodos, aunque pueden contener atributos y propiedades de alto nivel, los cuales pueden
5
ser mantenidos en el Modelo de Diseño o transformados, por ejemplo, en clase concretas del
sistema.
Estas clases pueden tener relaciones, aunque de algún tipo simple como, por ejemplo, de
herencia y suelen estar estereotipadas, como se dijo anteriormente, como:
• Clases de Interfaz: Las clases de interfaz se utilizan para modelar la interacción entre
el sistema y sus actores, representando normalmente ventanas, formularios, API de
comunicación, periféricos, etc. Suele utilizarse para mostrar cómo se verá presentada
la información del sistema, manteniendo un nivel alto de abstracción.
Como regla general, cada clase de interfaz debería estar relacionada con al menos un
Actor del sistema.
Los actores son elementos que provee UML para

describir a un usuario de un sistema (sea una
persona u otro sistema externo) que se relaciona
con este por diferentes motivos (por ejemplo,
utilizar una funcionalidad determinada). Son fácilmente reconocibles
por su forma de “persona de palitos” (“stickman”, en inglés).
Las Clases de Interfaz se representan con el símbolo de clase UML, estereotipada

como “interface” o “interfaz” (dependiendo de la herramienta de modelado), siendo
común encontrarlas con alguno de los dos estereotipos:
6
• Clases de Control: Estas clases modelan el manejo y coordinación de las acciones

principales y los flujos de control, así como la secuencia, las transacciones y el control
en general de otros objetos.
Las Clases de Control se representan con el símbolo de clase UML, estereotipada

como “control”, siendo común encontrarlas con alguno de los dos estereotipos:
• Clases de Entidad: Las clases de entidad se utilizan para modelar los datos que se
maneja en el dominio del sistema, los cuales suelen ser persistentes (son almacenados
en distintos medios). Además, es posible que contengan comportamiento, relacionada
7
con la manipulación de datos.
Las Clases de Entidad se representan con el símbolo de clase UML, estereotipada

como “entity” o “entidad” (dependiendo de la herramienta de modelado), siendo
común encontrarlas con alguno de los dos estereotipos:
2.2.3 Realizaciones de caso de uso
Los casos de uso realizados suelen nombrarse con el mismo nombre que caso de uso que
realizan, y se representan con el símbolo de caso de uso estándar de UML, siendo posible
estereotiparlas como “realización” (dependiendo de la herramienta de modelado utilizada).
Su principal uso suele estar dado para describir la forma en que un caso de uso en particular
se lleva a cabo en términos de clases de análisis y sus correspondientes objetos. De esta
manera, las realizaciones permiten trazar en forma directa los componentes de análisis con
los casos de uso del modelo de casos de uso.
Pueden estar compuestas por descripciones narrativas del flujo de eventos (similares a las
descripciones de los casos de uso, pero describiendo el comportamiento interno del sistema
en lugar del comportamiento externo), diagramas de clases que muestran la estructura y
relaciones de las clases de análisis, y diagramas de interacción que muestran las
colaboraciones entre objetos de análisis que se dan para llevar a cabo un flujo de eventos o
un escenario particular de un caso de uso.
2.2.4 Descripción de arquitectura
8
El modelo de análisis también puede hacer su aporte al “Documento de arquitectura del

software”, complementándolo con la siguiente información:
• Los paquetes de análisis y sus dependencias. Esta descomposición suele influir en los
subsistemas que se identifican en el posterior diseño e implementación.
• Las clases de análisis consideradas de mayor relevancia (clases de entidad que se

corresponden con información fundamental del sistema bajo análisis, clases de
interfaz que se corresponden con interfaces de comunicación importantes con otros
sistemas o mecanismos especiales de interfaz de usuario y clases de control que se
corresponden con secuencias importantes).
• Las realizaciones de los casos de uso.
Los conceptos relacionados a los casos de uso y al Modelo de Análisis

podrán ser apreciados con mayor nivel de detalle en las próximas dos
Unidades cuando sean analizados los diagramas estructurales y los
diagramas de comportamiento que involucran el modelado de clases y
casos de uso.
9
3. El Modelo de Diseño
Este Modelo toma la visión abstracta aportada por el Modelo de Análisis, a partir del
cual se obtiene un enfoque concreto de los componentes del sistema, llegando a un
nivel de detalle mayor, en el cual se hace mención a conceptos concretos como lenguaje
de programación, bases de datos, sistemas operativos, software de base, entre otros. Es
posible concebir este Modelo como un paso adelante en cuanto al análisis y su
refinamiento, en el cual se pasa de componentes conceptuales a componentes reales del
sistema en estudio, los cuales, idealmente, deberían convertirse en código fuente, ya sea
manualmente o a través de generadores de código.
Una de las principales responsabilidades de este Modelo es definir los componentes y la

arquitectura del sistema, a la vez que se mantiene una completa trazabilidad con los
requerimientos funcionales y no funcionales.
Otros objetivos buscados en el diseño son:

• Aportar claridad a los requerimientos no funcionales
• Lograr un nivel de detalle amplio sobre los lenguajes de programación, tecnologías,

sistemas operativos, etc. a utilizar y sus restricciones asociadas.
• Descomponer el sistema en partes más manejables que permitan una mejor

comprensión del mismo.
• Identificar subsistemas y las interfaces que deban existir entre ellos.
A continuación enumeramos algunas características para contrastar el Modelo de

Análisis con el Modelo de Diseño:
10
Modelo de análisis Modelo de diseño

Modelo conceptual, es una abstracción del Modelo físico, refleja de la implementación.
sistema.
Genérico, aplicable a varios diseños No genérico, aplicable a una única
implementación.
Tiene 3 estereotipos conceptuales: Interfaz, Puede tener cualquier número de
Control y Entidad estereotipos, dependiendo del lenguaje y las
tecnologías de implementación.
Menos formal. Más formal.
Menos caro de desarrollar. Más caro de desarrollar.
Menos capas. Más capas.
Brinda un bosquejo del sistema, pudiendo Es un detalle real del sistema, definiendo
incluir algo de su arquitectura conceptual completamente su arquitectura.
Se crea principalmente como resultado de Se crea principalmente como “programación
reuniones y relevamientos. visual”.
Puede no mantenerse durante todo el ciclo de Debe mantenerse durante todo el ciclo de
vida del software. vida.
3.1 Componentes del Modelo de Diseño

Está constituido por clases de diseño, realizaciones de casos de uso, paquetes,
subsistemas e interfaces, y modelo de despliegue. Otro elemento que forma parte del
modelo de diseño es la descripción de la arquitectura, presentada en los modelos
anteriores (Modelo de casos de uso, Modelo de análisis).
A continuación se detallan los elementos más destacados, además de loa antes

nombrados
3.1.1 Clases de diseño
Una clase de diseño es una descripción de un conjunto de elementos que comparten las
mismas responsabilidades, relaciones, operaciones, atributos y semántica.
11
Se encuentran definidas por los siguientes elementos:

• Atributos: Los atributos definen las propiedades o estado de la clase. Están
compuestos por: un nombre y un tipo, que se corresponde con el tipo de datos
(o clase) al que pertenece el atributo.
• Operaciones: Las operaciones definen los métodos que, a su vez, detallan el

comportamiento de la clase y constituyen la forma en las que estas interactuar
entre sí. Cada operación puede tener como entrada argumentos o parámetros,
efectúa un procesamiento y pueden retornar un único resultado.
Tanto las clases, como las operaciones y los atributos de una clase cuentan con un nivel
de visibilidad definido. Dicha visibilidad define desde qué lugar es posible ver o acceder
a cada uno de estos elementos.
Las visibilidades más comunes son:
• Pública: pueden ser vistos o accedidos desde cualquier otra clase.
• Protegida: pueden ser vistos o accedidos solamente dentro de la clase y de sus

clases derivadas.
• Privada: pueden ser vistos o accedidos solamente dentro de la misma clase.
En posible encontrar pequeñas diferencias entre estos conceptos y las

implementaciones de los distintos lenguajes de programación.
3.1.2 Relaciones
Las clases del Modelo de Diseño pueden estar relacionadas entre sí de diversas
maneras. A continuación un detalle de los tipos principales y más comúnmente usados
12
de relaciones que encontramos:
3.1.2.1 Asociaciones
Se utilizan para indicar que un objeto que es instancia de una clase conoce a otros
objetos que son instancias de otras clases.
Se utiliza el siguiente símbolo:
Ejemplo: en la figura siguiente, existe una asociación entre los objetos de la clase
Empleado y los de la clase Empresa. Esto significa que una instancia de Empleado
conocerá a una instancia de Empresa.
Componentes de las Asociaciones

• Roles: se compone por un nombre, el cual debe ser un sustantivo que indica el
papel que cumple la clase con respecto a la asociación con la otra clase.
Ejemplo: ampliando el ejemplo anterior, se asigna un nombre al rol que cumple el

Empleado y la Empresa en la asociación entre ambas clases.
13
• Nombres: es posible agregar un nombre para calificar a la asociación.
Ejemplo: la asociación entre Empleado y Empresa puede calificarse con el

nombre “es empleado de” o “trabaja en”.
Como buena práctica se recomienda utilizar role en lugares de nombres, ya que

aporta más información sobre la asociación.
• Multiplicidad: indica cuántos objetos de una clase pueden asociarse con cuántos
objetos de la otra, ya sea por valor (número entero o “*” para indicar
“muchos”) o rango (por ejemplo, “1..*” significa que puede haber entre “1” y
“n” objetos). En caso de omisión se interpreta una relación 1 a 1.
Ejemplo: se muestra que en la asociación una empresa siempre tiene uno o más
empleados.
• Navegabilidad: se utiliza en los extremos de una asociación para indicar que

desde las instancias de los objetos de uno de los extremos se puede llegar a las
instancias de los objetos del otro extremo. El sentido de la navegabilidad se
indica con una “punta” en la flecha orientada hacia al extremo de destino de la
asociación. En caso de ausencias de “puntas” de flecha en ninguno de los
14
extremos de una asociación, se asume que la misma tiene una navegación

bidireccional.
Ejemplo: en el siguiente ejemplo, la asociación entre Empleado y Empresa es

navegable en ambos sentidos, por lo que ambos elementos se conocen,
mientras que la asociación entre Empleado y Legajo no lo es. Esto significa que
un objeto Empleado conoce su Legajo, pero el objeto Legajo no conoce al
objeto Empleado.
• Clases de Asociación: es una asociación que a su vez contiene atributos y

operaciones. Su utilización más común es en asociaciones con multiplicidad del
tipo “muchos a muchos”.
Ejemplo: continuando con el ejemplo, se puede pensar que en cada una de las
empresas en las que trabaja, una persona tiene un contrato por el cual se
especifica el sueldo y el tiempo que va a trabajar.
15
3.1.2.2 Agregaciones
Son un tipo especial de asociación que se utilizan para definir relaciones del tipo
“composición” entre clases, como por ejemplo: Auto está compuesto por una
Carrocería, un Motor, Ruedas, etc.
A continuación, se muestra que una Factura contiene un conjunto de Items utilizando

una relación de agregación. El extremo con forma de rombo debe ir del lado del
contenedor.
16
3.1.2.3 Composición
Es otro tipo de agregación que se utiliza cuando los objetos componentes de un

agregado no pueden existir sin mismo. En este caso el contenedor no tiene sentido sin
que existan sus contenidos.
Ejemplo: una Factura está formada por Items, que serían los artículos o líneas de la
misma. Un Item no tiene existencia fuera del contexto de una Factura y una Factura
siempre está compuesta por Items, ya que no tiene sentido que exista Factura vacía.
3.1.2.4 Generalizaciones
Define una relación entre una clase más general (clase padre) y una más específica
(clase hija), representando el concepto de Herencia de la programación orientada a
17
objetos. La clase hija hereda de la madre todas sus propiedades (atributos), su

comportamiento (operaciones o métodos) y sus relaciones, y adicionalmente puede
definir nuevas propiedades, comportamientos o relaciones.
Ejemplo: a continuación se muestra un ejemplo simple de una relación de herencia, con

una clase padre Vehiculo, de la cual heredan sus propiedades y operaciones las
clases hijas Auto, Camion, y Bus, en los cuales se incorporan atributos propios
que no tiene la clase padre.
UML permite calificar una clase como abstracta, lo que significa que la clase define
atributos y operaciones, pero que no existirán instancias de la misma.
Ejemplo: siguiendo con el caso de los vehículos, en el siguiente ejemplo la clase padre
“Vehiculo” se define como abstracta, con lo cual no se podrá instanciar objetos de la
misma.
18
3.1.2.5 Dependencias
Las dependencias entre clases permiten detallar asociaciones temporales (ya que no
existe una asociación permanente entre estas) y sirven, principalmente, para indicar que
los objetos de una clase tendrán conocimiento sobre los objetos de otra (y por ende
podrán enviarles mensajes) de alguna de las siguientes formas:
• Instanciando el objeto destino dentro de alguna operación del objeto fuente
• Recibiendo el objeto destino como argumento de alguna operación del objeto

fuente
• El objeto destino tiene alcance global, con lo cual el objeto fuente puede
accederlo en cualquier momento
19

Unidad 2

Cargado por

Copyright:

Formatos disponibles

Unidad 2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 2

Cargado por

Copyright:

Formatos disponibles

UNIDAD

Diseño Orientado a Objetos

Curso de UML y Patrones de Diseño de

Estas actividades están enmarcadas dentro de distintos modelos. Enfocándonos en

Notaremos lo importante de algunos conceptos que irán surgiendo,

• La información utilizada en el sistema

• La lógica de control del sistema

• Clases de Entidad ("entity”, en inglés)

• Clases de Control (“control”, en inglés

Más adelante, en esta misma Unidad profundizaremos sobre estos estereotipos.

Los estereotipos son uno de los mecanismos que se utilizan para

En resumen, el Modelo de análisis brinda la posibilidad de efectuar una

2.1 Aplicación del Modelo de Análisis

Es utilizado como un instrumento para documentar el análisis de los requerimientos

• Provee una forma de organizar los requerimientos de manera de facilitar su

A continuación enumeramos algunas características para contrastar el Modelo de Análisis con

Modelo de casos de uso Modelo de análisis

2.2 Componentes del Modelo de Análisis

Los principales elementos que componen este Modelo son:

• Las Clases de Análisis

• Las Realizaciones de los Casos de Uso

2.2.1 Paquetes de análisis

Un ejemplo de Paquete de Análisis podría ser:

2.2.2 Clases de análisis

Las Clases de Análisis se ocupan de la gestión de los requerimientos funcionales,

Los actores son elementos que provee UML para

Las Clases de Interfaz se representan con el símbolo de clase UML, estereotipada

• Clases de Control: Estas clases modelan el manejo y coordinación de las acciones

Las Clases de Control se representan con el símbolo de clase UML, estereotipada

con la manipulación de datos.

Las Clases de Entidad se representan con el símbolo de clase UML, estereotipada

2.2.3 Realizaciones de caso de uso

2.2.4 Descripción de arquitectura

El modelo de análisis también puede hacer su aporte al “Documento de arquitectura del

• Las clases de análisis consideradas de mayor relevancia (clases de entidad que se

• Las realizaciones de los casos de uso.

Los conceptos relacionados a los casos de uso y al Modelo de Análisis

Una de las principales responsabilidades de este Modelo es definir los componentes y la

Otros objetivos buscados en el diseño son:

• Lograr un nivel de detalle amplio sobre los lenguajes de programación, tecnologías,

• Descomponer el sistema en partes más manejables que permitan una mejor

• Identificar subsistemas y las interfaces que deban existir entre ellos.

A continuación enumeramos algunas características para contrastar el Modelo de

Modelo de análisis Modelo de diseño

3.1 Componentes del Modelo de Diseño

A continuación se detallan los elementos más destacados, además de loa antes

3.1.1 Clases de diseño

Se encuentran definidas por los siguientes elementos:

• Operaciones: Las operaciones definen los métodos que, a su vez, detallan el

• Protegida: pueden ser vistos o accedidos solamente dentro de la clase y de sus

• Privada: pueden ser vistos o accedidos solamente dentro de la misma clase.

En posible encontrar pequeñas diferencias entre estos conceptos y las

de relaciones que encontramos:

Componentes de las Asociaciones

Ejemplo: ampliando el ejemplo anterior, se asigna un nombre al rol que cumple el

• Nombres: es posible agregar un nombre para calificar a la asociación.

Ejemplo: la asociación entre Empleado y Empresa puede calificarse con el

Como buena práctica se recomienda utilizar role en lugares de nombres, ya que

• Navegabilidad: se utiliza en los extremos de una asociación para indicar que