Tecnologías Orientadas a Objetos (T. E.

UNIVERSIDAD DE EL SALVADOR
FACULTAD DE INGENIERIA Y ARQUITECTURA
ESCUELA DE INGENIERIA DE SISTEMAS INFORMATICOS

Tecnologías Orientadas a Objetos (T.E.)

Unidad I. Desarrollo de Sistemas Orientado a Objetos

Alcance de la Asignatura
El desarrollo de un sistema de software es normalmente sólo una parte de encontrar una solución a un problema
mayor. El problema mayor podría incluir el desarrollo de un sistema de información completo que incluye
software, hardware, procedimientos y organización. Esta asignatura, se centrará en el software. No se tomará en
cuenta los aspectos relacionados con la construcción de una plataforma de hardware adecuada o reorganizar
los procedimientos de la institución que están involucrados con el software a desarrollar.

Desarrollo de Sistemas de Información

El ciclo de vida clásico de un sistema de información incluye la forma en que se construye el sistema de
información (Desarrollo de sistemas de información) y el seguimiento durante su operación (Mantenimiento). Ya
que una tarea se vuelve más fácil de realizar una secuencia de tareas pequeñas que una tarea grande, el ciclo
de vida general se divide en una serie de pasos pequeños llamados fases. El número de fases varía de empresa
a empresa y de autor a autor. Puede haber 4 fases u 8 fases. Las más comunes son 6 fases:
1) Fase de Requisitos
2) Fase de Análisis
3) Fase de Diseño
4) Fase de Programación
5) Fase de Implementación
6) Fase de Mantenimiento

Cada una de las fases anteriores se describe a continuación.

1) Fase de Requisitos
En la fase de requisitos se extraen los requisitos del cliente. Es decir, el cliente y los futuros usuarios del sistema
de información por desarrollar interactúan con el equipo de desarrollo de sistemas de información, con el fin de
determinar las necesidades de información del cliente. Los resultados de este estudio se presentan en un
documento de requisitos.

2) Fase de Análisis
La segunda fase es la de análisis. El objetivo de ésta es preparar el documento de especificaciones. El
documento de especificaciones plantea lo que debe hacer el sistema de información. Si el sistema de

-1-
Tecnologías Orientadas a Objetos (T. E.)

información entregado satisface las especificaciones, entonces el cliente paga a los desarrolladores lo que
cuesta el sistema de información. Si no, los desarrolladores tienen que corregirlo hasta que cumpla con las
especificaciones. Éstas describen lo que el sistema de información es capaz de hacer. Una vez que el cliente
aprueba el documento de especificaciones, puede redactarse el plan de administración de proyectos. Este plan
detallado incluye un presupuesto, las necesidades de personal y una lista de qué se entregará al cliente y
cuándo.

3) Fase de Diseño
En esta fase los miembros del equipo de desarrollo describen cómo se va ha desarrollar el sistema de
información. Por lo general, el sistema se divide en piezas pequeñas llamadas módulos. Cada módulo se diseña
posteriormente con detalle; el equipo de desarrollo describe los algoritmos usados por el módulo (es decir, cómo
el módulo realiza esta tarea) y las estructuras de datos dentro del módulo (es decir, los datos con los cuales va
ha operar el módulo). El resultado se presenta en forma de un documento de diseño.

4) Fase de Programación
Los diseños de los módulos se entregan al equipo de programación para que los traduzcan en un lenguaje de
programación apropiado. COBOL es el lenguaje de programación más usado en el mundo, en tanto que los
sistemas de información modernos a menudo se implementan en C++ o Java. Los módulos se integran (se
combinan) para formar el sistema de información completo.

5) Fase de Implementación
Luego que el sistema de información está completo, éste es instalado y puesto en marcha. También incluye
otras actividades como la capacitación de usuarios y alimentación de base de datos con los datos de inicio y
datos históricos.

6) Fase de mantenimiento
Después de que se ha implantado el sistema de información, necesitará modificarse, ya sea para eliminar
cualquier falla restante o porque necesita ampliarse de alguna manera.

Fases de Planeación, Pruebas y Documentación

PLANEACION
La planeación se realiza hasta saber exactamente lo qué se va ha desarrollar, no hay manera de idear un plan
detallado preciso. Por lo tanto, hay tres tipos de actividades de planeación que ocurren cuando se desarrolla un
sistema de información:
i. Se lleva a cabo la planeación preliminar de modo que se puedan manejar las fases de análisis y
requisitos.

-2-
Tecnologías Orientadas a Objetos (T. E.)

ii. Cuando se sabe con precisión lo que se va ha desarrollar, se idea el plan de administración de
proyectos. Éste incluye el presupuesto, los requisitos de personal y un calendario detallado. Lo más
pronto que puede idearse el plan de administración de proyectos es cuando el cliente ha aprobado el
documento de especificación. Hasta ese momento la planeación tiene que ser preliminar y parcial.
iii. A lo largo de todo el proyecto la administración necesita supervisar el plan de administración y estar al
pendiente de cualquier desviación. Una desviación implica considerar algunas alternativas, tales como:
o Reducir el alcance del objetivo del sistema de información y luego diseñar e implantar uno menos
ambicioso.
o Cancelar el proyecto si todas las demás opciones se consideran imprácticas. Una cancelación
temprana permite ahorrar una suma considerable de dinero.
Resumiendo, se puede concluir que no existe una fase de planeación separada. En lugar de eso, las actividades
de planeación se realizan a lo largo de todo el ciclo de vida. No obstante, hay ocasiones en que las actividades
de planeación predominan. Éstas incluyen el inicio del proyecto (planeación preliminar) e inmediatamente
después el documento de especificaciones que ha aprobado el cliente (plan de administración de proyectos).

PRUEBAS
Es esencial verificar con mucho cuidado un sistema de información después de que se ha desarrollado.
Lamentablemente, verificar el sistema de información una vez que está listo para ser entregado al cliente es
demasiado tarde. Por ejemplo, si hay una falla en el documento de especificaciones, ésta se pasará al diseño y
a la programación. Por lo tanto, además de revisar el sistema de información como un todo cuando esté
completo (validación), el sentido común dicta que también debe revisarse al final de cada fase (verificación).
Pero incluso esto no es suficiente. La revisión continua de un sistema de información es requerida ya que se
persigue asegurar que un sistema esté lo más libre de fallas posible en cualquier momento.

DOCUMENTACIÓN
Del mismo modo que nunca debe haber una fase de planeación o una fase de pruebas separadas, nunca
debería haber una fase de documentación separada. Por el contrario, en todo momento la documentación del
sistema de información debe estar completa, ser correcta y estar actualizada. Por ejemplo, durante la fase de
análisis, el documento de especificaciones debe reflejar la versión actual de las especificaciones, lo mismo que
para otras fases.

1.1. Enfoque Orientado a Objetos usando UML

La era de las computadoras comenzó en la década de 1940, así que los sistemas de información difícilmente
tienen más de 60 años. El desarrollo de los sistemas de información se consideró inicialmente como una
habilidad creativa; la individualidad tenía un precio muy alto. No obstante, a medida que las computadoras de
mayor tamaño se volvieron accesibles, fue posible ejecutar un sistema de información que era demasiado

-3-
Tecnologías Orientadas a Objetos (T. E.)

grande para ser desarrollado sólo por una persona, si es que dicho sistema tenía que completarse en una fecha
límite especificada por el cliente. En vez de eso, los sistemas de información comenzaron a desarrollarse por
equipos. Además, la especialización de habilidades se volvió la norma de la industria. Es decir, los profesionales
de la tecnología de la información ya no participaron en todas las fases; más bien, aparecieron dos profesiones
separadas: el programador y el analista de sistemas. Los analistas de sistemas se ocupaban de las fases de
requisitos, análisis y diseño, mientras que los programadores se encargaban de la programación e
implementación.

Una vez que el desarrollo de sistemas de información se volvió una actividad en equipos, fue necesario decidir
un método común; la individualidad se había vuelto una responsabilidad. El primer método sistemático para el
desarrollo de sistemas de información se llamó método tradicional o paradigma tradicional; a veces también
llamado metodología estructurada o enfoque estructurado.

En la década de 1970 la palabra metodología comenzó a utilizarse en el sentido de “una manera de desarrollar
sistemas de información”; la palabra en realidad significa la ciencia de los métodos. Luego, en la década de
1980, la palabra paradigma se puso de moda en el mundo empresarial, como en la frase: “es un paradigma
completamente nuevo”. La industria de los sistemas de información pronto comenzó a utilizar la palabra
paradigma en las frases paradigma orientado a objetos y paradigma tradicional (o clásico) para referirse a “un
estilo de desarrollo de sistemas de información”. Ésta fue una acertada elección de terminología, porque
paradigma significa modelo o patrón.

Al principio, el paradigma tradicional era muy exitoso. Después de todo, ésta fue la primera vez que el desarrollo
de sistemas de información se trató como una disciplina metódica y no como una actividad creativa. La calidad
de los sistemas de información se mejoró y la entrega de sistemas de información a tiempo y dentro del
presupuesto comenzó a convertirse en una expectativa realista.

Durante la década de 1980, el costo del hardware continuó disminuyendo tan rápido como lo había hecho en
décadas anteriores. A medida que las computadoras grandes se volvieron más accesibles, el tamaño de los
sistemas de información también creció. Pero entre más grandes eran, el éxito del paradigma tradicional era
menor. Finalmente, la comunidad de sistema de información se dio cuenta de que el paradigma tradicional ya no
era útil y se requería algo más efectivo.

El paradigma tradicional funcionó bien para los sistemas de información a pequeña escala (5,000 líneas de
código), pero no fue así para los sistemas de información a mediana escala (50,000 líneas de código) y de gran
escala (500,000 líneas de código). Los dos bloques de construcción básicos de un sistema de información son
las operaciones realizadas por ese sistema de información y los datos con los cuales se realizan las

-4-
Tecnologías Orientadas a Objetos (T. E.)

operaciones. El paradigma tradicional ignora los datos a favor de las operaciones. Por el contrario, el paradigma
orientado a objetos presta igual atención a las operaciones que a los datos. Según la empresa Standish Group
(dedicada a la investigación del desarrollo de los sistemas de información), en el año 2000 se desarrollaron
280,000 proyectos en los Estados Unidos, de los cuales:
• 28% de los proyectos se completó con buenos resultados
• 23% de los proyectos se cancelaron antes de completarlos
• 49% de los proyectos se completó e instaló en la computadora del cliente, pero estaban por debajo del
presupuesto, retrasados o tenían menos características y funcionalidad que la especificada inicialmente.

Resumiendo, en el año 2000, sólo 1 de cada 4 proyectos de desarrollo de sistemas era exitoso. Estos proyectos
fallidos implicaron problemas financieros y legales desastrosos. Una encuesta realizada por el Cutre Consortium
en el 2002, reveló que un 78% de las empresas encuestadas había participado en disputas que terminaron en
litigio. De las empresas que participaron en litigios, estos fueron los resultados:
• 67% de las empresas, los desarrolladores no cumplieron con la funcionalidad o desempeño del sistema
de información.
• 56% de las empresas, tuvieron que postergar la fecha de entrega varias veces.
• 45% de las empresas, los sistemas de información tenían defectos tan severos que los sistemas de
información eran inutilizables.
Es por eso, que más y más empresas tienden a cambiar al paradigma Orientado a Objetos.

1.1.1 Fundamentos del Enfoque Orientado a Objetos

Objetos y Clases
Una clase es una categoría o grupo de cosas que tienen atributos y acciones similares. Un objeto es una
instancia de una clase. Un objeto, también, es una unidad que encapsula estado y comportamiento. Tanto los
objetos como las clases pueden caracterizar una entidad física (alumno, libro, etc.) o abstracta (fórmula
matemática, juego, etc.).

Por ejemplo, el rey Jorge III reinó en Gran Bretaña desde 1760 a 1820. La figura 1.1 representa al rey Jorge III.
Asimismo, el rey Luis XVI reinó en Francia de 1774 a 1792, como se muestra en la figura 1.2. Al comparar las
figuras 1.1 y 1.2 queda claro que todos los reyes tienen algo en común. Los reyes tienen nombres, gobiernan un
país específico y su reinado comienza en un año específico y termina en otro año específico. Si se estable la
Clase Rey como el conjunto todos los reyes. Clase Rey se representa en la figura 1.3. Los cuatro elementos en
el recuadro de intermedio de la figura 1.3 – nombre, país, inicioDeReinado, finDeReinado – se llaman atributos
de la Clase Rey. El recuadro inferior es para las operaciones realizadas con o por los reyes. Por ejemplo, un rey
reina y si un rey quiere suspender su reinado, abdica.

-5-
Tecnologías Orientadas a Objetos (T. E.)

Figura 1.1. Rey Jorge III de Gran Bretaña Figura 1.2. Rey Luis XVI de Francia.

Todos los objetos en una clase tienen el mismo conjunto de atributos y el mismo número de operaciones;
difieren sólo en los valores de sus atributos respectivos. Como se muestra en las figuras 1.1 y 1.2.

Figura 1.3. Representación en UML de la Clase Rey Figura 1.4. Representación en UML de la Clase Zapato.

Se dice que el rey Jorge III es una instancia de la Clase Rey y también lo es el rey Luis XVI. Es decir, una clase
es un conjunto de objetos relacionados y, a la inversa, un objeto es una instancia de una clase.

Otro ejemplo son los zapatos. Un zapato tiene un color (negro, café, etc.); viene en una talla (3, 8, 7 ½, 9, 14) y
con un ancho (AAA, C, E); tiene un estilo (zapato de aguja, sandalia, tenis, etc.), y está hecho de algún material
(piel, hule). La Clase Zapato es el conjunto de todos los zapatos. La figura 1.4 muestra la Clase Zapato. El
recuadro inferior muestra las operaciones que pueden aplicarse a un zapato. Es decir, un zapato puede ponerse,
quitarse y lustrarse. Una clase se representa en UML como se muestra en la figura 1.4. Aparecen tres
recuadros. El recuadro superior contiene el nombre de la clase, en negrita y con la letra inicial de los Nombres
en Mayúscula. El recuadro del centro contiene los nombres de los atributos de una instancia de esa clase; es
decir, de un objeto de ese tipo. El recuadro inferior contiene los nombres de las operaciones que pueden
realizarse por o con una instancia de esa clase; es decir, de un objeto de ese tipo. El recuadro inferior contiene
los nombres de las operaciones que pueden realizase por o con una instancia de esa clase; es decir, por o con
un objeto de ese tipo.

-6-
Tecnologías Orientadas a Objetos (T. E.)

Como se mencionó antes, la Clase Rey es el conjunto o la clase de todos los reyes. Por el contrario, un rey
(objeto) es un miembro o instancia de la Clase Rey. (La convención del UML es escribir el nombre de un objeto
subrayado pero todo en minúsculas). Asimismo, un zapato es una instancia de la Clase Zapato.

Se mencionó que la figura 1.4 tiene 3 recuadros. De hecho, el UML es un lenguaje de modelado sumamente
flexible. Si no son de interés los atributos y las operaciones de una clase, es posible representarla como se
muestra en la figura 1.5 (a). E incluso sino es importante el nombre de la clase, entonces es posible
representarla como se muestra en la figura 1.5 (b).

(a) (b)
Figura 1.5. Dos maneras de representar una clase en UML.

Herencia
Una propiedad importante de las clases es la herencia. Por ejemplo, a un programador de mantenimiento se le
ha asignado la tarea de modificar un sistema de información de comercio electrónico. La empresa Acme
Company actualmente permite a los individuos hacer pedidos de ropa a través de la World Wide Web y cargar la
orden de compra a una tarjeta de crédito. El sistema de información soporta una amplia variedad de tipos
distintos de funcionalidad, incluyendo la comunicación a través de la World Wide Web; las complejidades de
vender ropa, la cual por lo general viene en diferentes tallas y colores; la seguridad de la Web; varias opciones
de envío y el cargo de la compra a una tarjeta de crédito.

Figura 1.6. Representación UML de la Clase Tarjeta de Crédito

La figura 1.6 representa la Clase Tarjeta de Crédito. Tiene tres atributos (elementos de datos):
númeroDeTarjeta, nombreDeTarjetaHabiente y fechaDeExpiración. Hay cuatro operaciones que pueden
realizarse con los datos: validarTransacción, cargarTransacciónATarjeta, pagarCréditoATarjeta e

-7-
Tecnologías Orientadas a Objetos (T. E.)

imprimirEstadoMensual. Con el fin de dar claridad al ejemplo, la figura 1.6 se ha mantenido lo más simple
posible; en un sistema de información de tarjetas de crédito actual habría muchos atributos y más operaciones.

Si un cliente quiere pagar su ropa con una tarjeta de crédito, el sistema de información de Acme Company envía
un mensaje al sistema de información que corre en la computadora de la compañía de tarjetas solicitando la
aprobación de la compra y el pago a favor de Acme Company. Suponga que la compañía de tarjetas de crédito
ahora desea ampliar el sistema de información de modo que pueda manejar tanto tarjetas de débito como de
crédito. La principal diferencia entre una tarjeta de crédito y una de débito es que las primeras permiten al tarjeta
habiente gastar hasta el límite de crédito de la tarjeta, mientras que una tarjeta de débito está vinculada a una
cuenta de banco, así que el tarjeta habiente puede gastar hasta el saldo actual en su cuenta bancaria.

Por otro lado, las cuentas de tarjeta de débito y las de tarjeta de crédito tienen muchas características en común.
Por ejemplo, ambas tienen los atributos númeroDeTarjeta, nombreDeTarjetahabiente y fechaDeExpiración. En
vez de tratar a la Clase Tarjeta de Debito y la Clase Tarjeta de Crédito como independientes, tiene más
sentido tratar a cada una como un caso especial de una clase más general, la Clase Tarjeta Bancaria. Revise
la figura 1.7 que muestra que la Clase Tarjeta Bancaria es una clase y que la Clase Tarjeta de Crédito es una
subclase de aquéllas. El triángulo en blanco debajo de la Clase Tarjeta Bancaria indica que la Clase Tarjeta de
Crédito hereda de la Clase Tarjeta Bancaria. Es decir, la Clase Tarjeta de Crédito tiene todas las
características de la Clase Tarjeta Bancaria (la parte derivada) pero, además, tiene características por sí misma
que son específicas de la Clase Tarjeta de Crédito (la parte con incrementos); por ejemplo, límiteDeCrédito.

Figura 1.7. Diagrama UML que muestra que la Clase Tarjeta de Crédito es una subclase de la Clase Tarjeta
Bancaria.

Hay varias maneras de describir la relación mostrada en la figura 1.7. Algunas de ellas son:
• Clase Tarjeta de Crédito es una subclase de Clase Tarjeta Bancaria.
• Clase Tarjeta Bancaria es una superclase de Clase Tarjeta de Crédito.
• Clase Tarjeta de Crédito es una especialización de Clase Tarjeta Bancaria.

-8-
Tecnologías Orientadas a Objetos (T. E.)

• Clase Tarjeta Bancaria es una generalización de Clase Tarjeta de Crédito.

• Clase Tarjeta de Crédito es una Clase Tarjeta Bancaria.
• Clase Tarjeta Bancaria es la clase base; Clase Tarjeta de Crédito es la clase derivada.
• Clase Tarjeta Bancaria es la clase padre; Clase Tarjeta de Débito es la clase hija.
• Clase Tarjeta de Crédito hereda de Clase Tarjeta Bancaria.

Estas ideas también pueden ampliarse a la Clase Tarjeta de Débito. Considere la figura 1.8, la cual muestra que
la Clase Tarjeta de Crédito y la Clase Tarjeta de Débito son subclases de la Clase Tarjeta Bancaria. Es decir,
tanto la Clase Tarjeta de Crédito como la Clase Tarjeta de Débito heredan todos los atributos y todas las
operaciones de la Clase Tarjeta Bancaria; por ejemplo, nombreDeTarjetaHabiente y validarTransacción.
Además, la Clase Tarjeta de Crédito y la Clase Tarjeta de Débito tienen atributos y operaciones por sí mismas.
Por ejemplo, la Clase Tarjeta de Crédito tiene el atributo límiteDeCrédito y la Clase Tarjeta de Débito tiene la
operación determinarSaldoDeCuenta.

Figura 1.8. Diagrama UML que muestra que Clase Tarjeta de Crédito y Clase Tarjeta de Débito son subclases
de Clase Tarjeta Bancaria.

La herencia es una característica requerida de la orientación hacia objetos. Por consiguiete, si un lenguaje de
programación no soporta la herencia, no puede ser un lenguaje de programación orientado a objetos. Por lo
tanto, se deduce que todos los lenguajes de programación orientada a objetos, incluyendo Smalltalk, C++, Ada
95 y Java soportan la herencia.

La herencia no necesita involucrar sólo dos clases. Considere la figura 1.9, la cual muestra una jerarquía de
herencia. Un atributo u operación declarada en la clase de mayor jerarquía de la figura se heredará a todas las
demás clases de la figura. Sin embargo, un atributo u operación declarada en una de las clases en el nivel
inferior de la figura será exclusivo de esa clase; la herencia es una relación de arriba abajo.

-9-
Tecnologías Orientadas a Objetos (T. E.)

Figura 1.9. Jerarquía de la Herencia.

Generalización, Agregación y Asociación

Se ha descrito una relación entre clases, la herencia, la cual es una implementación de la relación de
generalización. Pero otros tipos de relaciones son posibles entre clases. Por ejemplo, un automóvil se
construye con un chasis, motor, llantas y asientos. Cuando los analista de sistema realizan el análisis orientado
a objetos de una planta industrial de automóviles, puede definir las clases Clase Chasis, Clase Motor, Clase
Llantas y Clase Asientos. La Clase Automóvil se define entonces como el congregado de las cuatro clases de
componentes. Esto se ilustra en la figura 1.10. La relación de agregación es apropiada cuando la clase X “se
compone de” las clases Y y Z. Como se muestra en la figura 1.10, en UML la agregación se representa con un
diamante en blanco.

- 10 -
Tecnologías Orientadas a Objetos (T. E.)

Figura 1.10. Ejemplo de Agregación

La relación más general entre las clases es la asociación (por ejemplo, la agregación es un caso especial de
asociación). La Asociación es una relación arbitraria entre dos clases. Como ejemplo, considere a un radiólogo
que puede consulta a un abogado con respecto a la interpretación de un contrato con un hospital. Este ejemplo
de asociación se representa en la figura 1.11 usando la notación UML. El triángulo negro apunta desde el
radiólogo al abogado para mostrar que el diagrama UML representa aun radiólogo que consulta a un abogado,
contrariamente a la situación donde un abogado con una pierna rota consulta a un radiólogo. Esta última
situación se representa en la figura 1.12. Aquí el triángulo negro apunta en la otra dirección. Este uso que da al
triángulo en UML se llama navegación.

Figura 1.11. Ejemplo de Asociación 1 – Un radiólogo consulta a un abogado.

Figura 1.12. Ejemplo de Asociación 2 – Un abogado consulta a un radiólogo

Ocultamiento de Información (Encapsular información)

La importancia del mantenimiento se ha recalcado varias veces. El ocultamiento de información es una manera
de mejorar la capacidad de mantenimiento al volver invisibles los detalles de la implementación (programación)
fuera de un objeto.

- 11 -
Tecnologías Orientadas a Objetos (T. E.)

Por ejemplo, suponga que saldoDeCuenta es un tributo de la Clase Cuenta Bancaria. Existen varias formas de
implementar ese atributo saldoDeCuenta; por ejemplo, como un entero (la cantidad total en centavos) o como
una cantidad en dólares con dos posiciones decimales para los centavos. Los lenguajes orientados a objetos
permiten que un atributo se describa como privado; es decir, invisible fuera del objeto. Por lo tanto, la única
manera de tener acceso a saldoDeCuenta es a través de una operación.

Suponga que las dos operaciones de la Clase Cuenta Bancaria son “depósito” y “retiro”, como se muestra en la
figura 1.13. La única manera de cambiar el atributo saldoDeCuenta de un objeto cuenta bancaria es por medio
de enviar un mensaje (que es la unidad de comunicación entre objetos) para invocar una de las dos
operaciones de cuenta bancaria.

Figura 1.13. La Clase Cuenta Bancaria con información oculta.

A primera vista este método parece ser innecesario. Después de todo, tal vez sea mejor modificar el saldo de la
cuenta directamente, en lugar de enviar un mensaje para invocar una operación para que realice la modificación.
El punto crítico es cuando al dar mantenimiento al sistema de información hay un cambio en la forma de
almacenar ese saldoDeCuenta. Si los detalles de la implementación son invisibles fuera de la Clase Cuenta
Bancaria (es decir, si hay un ocultamiento de la información), entonces hacer cambios en la implementación no
puede afectar a otra parte del sistema de ninguna manera, sea cual fuere ésta. Es importante recordar que una
falla de regresión es un error en una parte del código provocado por hacerle un cambio en una parte que
aparentemente no está relacionada. Cuando hay ocultamiento de la información no puede haber fallas de
regresión. Así que una ventaja importante de ocultar la información es que el sistema de información resultante
se compone de clases esencialmente independientes que se comunican mediante el envío de mensajes para
invocar a sus propias operaciones y a las operaciones de otras clases.

- 12 -
Tecnologías Orientadas a Objetos (T. E.)

El ocultamiento de información puede lograrse usando atributos privados. Cuando un atributo se declara privado,
puede accederse al mismo sólo desde el interior de la clase en la cual se declara. Por el contrario, si un atributo
se declara público puede accederse al mismo desde cualquier parte dentro del sistema de información. Las
mismas reglas se aplican a las operaciones. Así que al volver privado al saldoDeCuenta y público al depósito y
el retiro, las operaciones depósito y retiro pueden invocarse desde cualquier parte del sistema de información,
pero invocar a esas dos operaciones es la única manera de cambiar el valor del atributo saldoDeCuenta.

El concepto de diseño basado en la responsabilidad va más allá del ocultamiento de la información. Considera la
siguiente situación, derivada de un ejemplo. Suponga que usted vive en San Salvador, y quiere enviar un ramo
por el día de las madres a su madre que vive en Chicago. Una estrategia sería consultar la Sección Amarilla de
Chicago (en el World Wide Web), determinar cuál florista se localiza más cerca de la ciudad de su madre y
hacerle un pedido. Otra forma más conveniente es hacer un pedido de flores al 1-800-flowers.com y dejar la
responsabilidad total de la entrega de las flores a esa compañía. Es irrelevante dónde se localiza físicamente 1-
800-flowers.com o a cuál florista le darán su pedido para que haga la entrega. En cualquier caso, la compañía
no divulgará esa información, éste es un ejemplo de ocultamiento de la información.

De la misma manera, cuando un mensaje se envía a un objeto, no sólo es irrelevante cómo se procesa esa
solicitud, sino que incluso no se permite, al módulo que envía el mensaje, saber cómo se implementan los
atributos del objeto. Además, la responsabilidad total de cumplir con todos los aspectos del mensaje recae sobre
el objeto que recibe el mensaje. Este es el principio del diseño basado en la responsabilidad.

1.2 UML (Unified Modeling Language)

A mediados de los noventa existían muchos métodos de análisis y diseño orientado a objetos. Entre ellos se
puede mencionar:
• OOAD (Object Oriented Analysis and Design) de Booch
• OMT (Object Modeling Technique) de Rumbaugh
• OOSE (Object Oriented Software Engineering) de Jacobson
• OGROUP de Olivetti
• Fusion de la Hewlett-Packard
• IE\O de la Texas Instruments, etc.

Aquellos métodos presentaban los mismos conceptos con distinta notación. Surgió mucha confusión y disputas
entre los métodos. En 1994, Booch, Rumbaugh y Jacobson deciden unificar sus métodos y surge UML, que
además entró en un proceso de estandarización promovido por la OMG (Object Management Group).

- 13 -
Tecnologías Orientadas a Objetos (T. E.)

1.2.1 UML y el modelado

UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema que
involucra una gran cantidad de software, desde una perspectiva OO.

El Lenguaje Unificado de Modelado (UML) es, tal como su nombre lo indica, un lenguaje de modelado y no un
método o un proceso. El UML está compuesto por una notación muy específica y por las reglas semánticas
relacionadas para la construcción de sistemas de software. El UML en sí mismo no prescribe ni aconseja cómo
usar esta notación en el proceso de desarrollo o como parte de una metodología de diseño orientada a objetos.
El UML soporta un conjunto rico en elementos de notación gráfica. Describe la notación para clases,
componentes, nodos, actividades, flujos de trabajo, casos de uso, objetos, estados y cómo modelar la relación
entre esos elementos. El UML también soporta la idea de extensiones personalizadas a través de elementos
estereotipados.

El UML provee beneficios significativos para los ingenieros de software y las organizaciones al ayudarles a
construir modelos rigurosos, trazables y a los que se pueda dar mantenimiento; además, que soporten el ciclo
de vida de desarrollo de software completo.

Actualmente se han definido y siguen definiéndose muchos procesos de desarrollo de software para ser usados
con UML. Por ejemplo, Rational (la empresa que tiene como socios a los tres autores del UML) ha ideado RUP,
“proceso unificado” (Este proceso se estudiará con detalle en la unidad VI de la asignatura).

Al ser un lenguaje, el UML puede usarse para describir los sistemas de información desarrollados mediante el
paradigma tradicional o cualquiera de las muchas versiones del paradigma orientado a objetos, incluyendo el
proceso unificado. En otras palabras, el UML es una notación que puede usarse con cualquier metodología.

1.2.2 Conceptos de Modelo y Diagrama

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.

Un diagrama es una representación gráfica de una colección de elementos de modelado.

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto
desde cada una de las perspectivas de interés. El código fuente del sistema es el modelo más detallado del
sistema (y además es ejecutable). Sin embargo, se requieren otros modelos que apoyen las fases en el proceso
de desarrollo. Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de

- 14 -
Tecnologías Orientadas a Objetos (T. E.)

trazado entre los diferentes modelos, de tal manera que aunque los modelos sean diferentes en cada fase, el
dominio real o alcance del sistema es el mismo.

1.2.3 Diagramas del UML

Los diagramas que componen el UML (versión 1.5) son los siguientes:
• Diagrama de Casos de Uso
• Diagrama de Clases
• Diagrama de Objetos (*)
• Diagramas de Comportamiento
o Diagramas de Interacción

Diagrama de Secuencia

Diagrama de Colaboración
o Diagrama de Estados
o Diagrama de Actividad
• Diagramas de implementación
o Diagrama de Componentes
o Diagrama de Despliegue

(*) El diagrama de objetos no se describe como un tipo de diagrama particular del UML. Los diagramas de
Secuencia, de colaboración y de actividad son los que en la práctica modelan objetos en sus diagramas. La
versión más reciente del UML es la 2.1.1

Paquetes en UML
La forma de manejar un sistema de información grande, es descomponerlo en paquetes relativamente
independientes. La notación UML para un paquete es un rectángulo con una etiqueta, como se puede ver en la
figura 1.14.

Figura 1.14. La notación UML para un paquete.

Esta figura muestra que “Mi Paquete” es un paquete, pero el rectángulo está vacío. Este es un diagrama UML
válido, sólo modela el hecho de que “Mi Paquete” es un paquete. La figura 1.15 es más interesante, muestra el
contenido de “Mi Paquete”, que incluye una clase, un objeto y otro paquete.

- 15 -
Tecnologías Orientadas a Objetos (T. E.)

Figura 1.15. Un paquete que contiene una clase, un objeto y otro paquete.
Los paquetes ofrecen un mecanismo general para la organización de los sub-modelos/sub-sistemas, ya que
agrupan elementos del modelado. Cada paquete corresponde a un sub-modelo (subsistema) del modelo
(sistema). Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento pertenece
a (está definido en) sólo un paquete. Una clase de un paquete puede aparecer en otro paquete por la
importación a través de una relación de dependencia entre paquetes (ver figura 1.16). Todos los elementos no
son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa.
El operador “::” permite designar una clase definida en un contexto distinto del actual (Ver figura 1.17).

Figura 1.16. Relaciones entre paquetes dependientes

- 16 -
Tecnologías Orientadas a Objetos (T. E.)

Diagrama de Casos de Uso

El modelo de casos de uso describe la funcionalidad propuesta del sistema a desarrollar. Un Caso de Uso
representa una unidad discreta de interacción entre un usuario (humano o máquina) y el sistema. Un Caso de
Uso es una unidad de trabajo significativo; por ejemplo crear una solicitud y modificar una solicitud son Casos de
Uso.

Cada Caso de Uso tiene una descripción que especifica la funcionalidad que se incorporará al sistema
propuesto. Un Caso de Uso puede 'incluir' la funcionalidad de otro Caso de Uso o puede 'extender' otro Caso de
Uso con su propio comportamiento.

Figura 1.17. Encapsulado de la clase Libro de Mi Paquete, hasta el paquete Biblioteca.

Los casos de uso típicamente se relacionan con 'actores'. Un actor es un humano o una máquina que interactúa
con el sistema para realizar un trabajo significativo.

La Notación de Caso de Uso

Los diagramas de casos de uso están generalmente compuestos por uno o más actores vinculados con uno o
más casos de uso, como en el diagrama de la figura 1.18.

- 17 -
Tecnologías Orientadas a Objetos (T. E.)

Figura 1.18. Notación del Diagrama de casos de uso

El Caso de Uso
Un Caso de Uso es una representación de una unidad discreta de trabajo realizada por un usuario (u otro
sistema) usando el sistema en operación. Se ejecuta en su totalidad o no se ejecuta nada, devolviendo algo de
valor al usuario. Algunos ejemplos de casos de uso son Agregar Pedido, Eliminar Pedido, Modificar Pedido, etc.
Una descripción de Caso de Uso generalmente incluirá:
• Comentarios generales y notas que describen el Caso de Uso;
• Requisitos: cosas que el Caso de Uso debe permitir hacer al usuario, tales como <capacidad de
actualizar orden>, <capacidad de modificar orden>, etc.
• Restricciones: las reglas sobre qué se puede hacer y qué no se puede.
• Precondiciones, que tienen que ser verdaderas antes de que se ejecute el Caso de Uso (por ejemplo
<crear orden> debe preceder a <modificar orden>);
• Post-condiciones que tienen que ser verdaderas una vez que el Caso de Uso se ejecutó (por ejemplo <la
orden está modificada y es consistente>);
• Invariantes: son siempre verdaderos (por ejemplo, una orden debe tener siempre un número de cliente).
• Escenarios: descripciones secuenciales de los pasos que se llevan a cabo para ejecutar un Caso de
Uso. Puede incluir múltiples escenarios para abarcar las circunstancias excepcionales y los caminos de
procesamiento alternativos.
• Diagramas de escenarios: diagramas de secuencia para representar el flujo.

- 18 -
Tecnologías Orientadas a Objetos (T. E.)

Actores
Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor
usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio. El conjunto de casos de uso
al que un actor tiene acceso define su rol en el sistema y el alcance de su acción.

Incluye y Extiende (Estereotipos)

Un Caso de Uso puede incluir (<<include>>) la funcionalidad de otro como parte de su procesamiento normal
(ver figura 1.18). Generalmente se asume que los casos de uso incluidos se llamarán cada vez que se ejecute el
camino base. Un ejemplo puede ser listar un conjunto de órdenes de clientes de las cuáles poder elegir antes de
modificar una orden seleccionada; en este caso, el Caso de Uso <listar órdenes> se puede incluir en el Caso de
Uso <modificar orden> cada vez que éste se ejecute. Un Caso de Uso puede ser incluido por uno o más casos
de uso, ayudando así a reducir la duplicación de funcionalidad al factorizar el comportamiento común en los
casos de uso que se reutilizan muchas veces.

Un Caso de Uso puede extender <<extend>> el comportamiento de otro Caso de Uso (ver figura 1.18);
típicamente cuando ocurren situaciones excepcionales. Por ejemplo, si antes de modificar un tipo particular de
orden de cliente, un usuario debe obtener la aprobación de alguna autoridad superior, entonces el Caso de Uso
<obtener aprobación> puede extender opcionalmente el Caso de Uso normal <modificar orden>.

Diagrama de Clases
Un diagrama de clases representa las clases y sus interrelaciones. El diagrama de clases más simple se
muestra en la figura 1.19 y representa la Clase Cuenta Bancaria. En la figura 1.20 aparece con más detalles la
Clase Cuenta Bancaria.

Figura 1.19. Diagrama de Clases más simple. Figura 1.20. Diagrama de Clases de la figura 6 con un
atributo y dos operaciones.

Un aspecto fundamental del UML es que las figuras 1.19 y 1.20 son diagramas de clases válidos, ya que en
UML es posible agregar tantos o tan pocos detalles como se considere apropiado en un modelo.
La libertad de notación se extiende a los objetos. Por ejemplo, cuenta bancaria es una manera informal para un
objeto específico de esta clase. La notación UML completa es:
cuenta bancaria: Clase Cuenta Bancaria

- 19 -
Tecnologías Orientadas a Objetos (T. E.)

Es decir, cuenta bancaria es un objeto, una instancia de una clase llamada Clase Cuenta Bancaria. El
subrayado significa que se trata de un objeto, los dos puntos denotan “una instancia de” y el tipo en negrita y las
letras iniciales mayúsculas de Clase Cuenta Bancaria indican que se trata de una clase. Pero el UML permite
usar una notación más breve cuando no hay ambigüedad, por esa razón es válido usar la notación:
cuenta bancaria
Es decir, que en el contexto de la representación de un objeto, este debe ser representado de tal manera que no
exista confusión sobre la clase a la que corresponda ese objeto. También es posible modelar el concepto de una
cuenta bancaria arbitraria; es decir, no se desea hacer referencia un objeto específico de la Clase Cuenta
Bancaria. La notación UML para esto es:
:Clase Cuenta Bancaria
Ya que se dijo que los dos puntos significan “una instancia de”; por lo tanto, :Clase Cuenta Bancaria significa
“una instancia de la Clase Cuenta Bancaria”, que es precisamente lo que se quería modelar.

Acerca de la visibilidad o el concepto de ocultamiento de información que se mencionó en la sección 1.1.1, en el

UML el prefijo + indica que un atributo u operación es público, y de manera semejante el prefijo – significa que
el atributo de la Clase Cuenta Bancaria se declara como privado (información oculta), mientras que ambas
operaciones son públicas de modo que pueden invocarse desde cualquier parte del sistema de información. El
tercer tipo de visibilidad, protegido, se denota con el prefijo #. Si un atributo es público, es visible en todas las
clases del mismo paquete; si es privado, es visible sólo en la clase en la cual se define; y si es protegido, es
visible tanto en la clase donde fue definido como dentro de las subclases de dicha clase.

A continuación, los siguientes conceptos son necesarios para definir un diagrama de clases con muchas clases
relacionadas.

Agregación
La figura 1.21 modela la frase “Un automóvil se compone de un chasis, un motor, llantas y asientos”. Los
diamantes en blanco indican la agregación. La agregación es el término del UML para la relación parte-todo; las
partes de un automóvil son el chasis, el motor, las llantas y los asientos. El diamante se coloca en el extremo del
“todo” (el automóvil), no en el extremo de la línea que conecta una de la “partes” (chasis, motor, llantas o
asientos) con el todo.

Multiplicidad
Cuando se necesita usar el UML para modelar la frase “Un automóvil se compone de un chasis, un motor, cuatro
o cinco llantas y dos o más asientos” se dibuja el diagrama de la figura 1.22. Los números cerca del final de la
línea indican multiplicidad, o el número de veces que una clase se asocia con otra clase. Primero, observe la
línea que conecta la Clase Chasis con la Clase Automóvil. El 1 en el extremo de la “parte” de la línea denota

- 20 -
Tecnologías Orientadas a Objetos (T. E.)

que hay un chasis involucrado en esta relación, y el 1 en el extremo del “todo” indica que hay un automóvil
involucrado; es decir, cada automóvil tiene un chasis. Esta relación es similar entre la Clase Automóvil y la
Clase Motor. Sin embargo, en la línea que conecta la Clase Llanta con la Clase Automóvil, aparece el 4..5 en
el extremo de la “parte” junto con el 1 en el extremo del “todo” indica que cada automóvil tienen de cuatro a cinco
llantas (la quinta llanta es la refacción que está en la cajuela). Dado que las instancias de las clases vienen sólo
en números enteros, esto significa que el diagrama UML modela la frase de que un automóvil tiene cuatro o
cinco llantas, como se requiere. Por lo general los dos puntos “..” indican un intervalo. De esta manera 0..1
significa cero o uno, que es la forma que tiene UML de denotar la condición “opcional”. Ahora observe la línea
que conecta la Clase Asiento con la Clase Automóvil. En el extremo de la “parte”, la etiqueta es 2..*. Un
asterisco por sí mismo denota “cero o más”; un asterisco en un intervalo indica “o más”. Por lo tanto, el 2..* de la
figura 1.22 significa que un automóvil tienen dos o más asientos.

De esta manera si en el UML se conoce la multiplicidad exacta, simplemente se usa ese número. Un ejemplo es
el 1 que aparece en 6 lugares de la figura 1.22. Si se conoce el intervalo, se utiliza la notación de intervalos,
como con el 4..5 de la figura 1.22. Y si el número no está especificado, se combina la notación de intervalos con
la notación del asterisco, como el caso de 2..* de la figura 1.22.

Figura 1.21. Un ejemplo de agregación.

Figura 1.22. Un ejemplo de agregación con multiplicador.

- 21 -
Tecnologías Orientadas a Objetos (T. E.)

Composición
Otro ejemplo de agregación se muestra en la figura 1.23, la cual modela la relación entre un tablero de ajedrez y
sus casillas; cada tablero de ajedrez consta de 64 casillas. De hecho, esta relación es un ejemplo de
composición, una forma más marcada de agregación. Como se mencionó antes, la asociación modela la
relación parte-todo. Cuando hay composición, entonces es posible que cada parte pertenezca a un solo todo, y
si el todo se borra, las partes también se borran. En el ejemplo, si hay varios tableros de ajedrez diferentes, cada
casilla pertenece sólo a un tablero, si hay varios tableros de ajedrez diferentes, cada casilla pertenece sólo a un
tablero y si éste se desecha, las 64 casillas se desechan junto con él. La composición, una extensión de la
agregación, se representa con un diamante sólido, como en la figura 1.24.

Figura 1.23. Otro ejemplo de Agregación.

Figura 1.24. Ejemplo de Composición.

Clase Asociación
Ya se estudio la asociación entre clases, en el cual la dirección de la asociación tenía que aclararse por medio
de una flecha de navegación, como se muestra en la figura 1.25.

Figura 1.25. Ejemplo de Asociación

En algunos casos la asociación entre las dos clases puede por sí misma requerir que se modele como una
clase. Por ejemplo, suponga que el radiólogo de la figura 1.25 consulta al abogado en varias ocasiones, en cada
una de ellas la consulta tienen diferente duración. Para que el abogado entregue una factura correcta al
radiólogo, se necesita un diagrama de clases como el representado en la figura 1.26. Ahora consultas se ha
vuelto una clase, Clase Consultas, conocida como una clase de asociación (ya que es una asociación y
también una clase).

- 22 -
Tecnologías Orientadas a Objetos (T. E.)

Diagramas de Interacción
Los diagramas de interacción muestran la manera en que interactúan entre si los objetos del sistema de
información. Los dos tipos de diagramas de interacción respaldados por el UML son: los diagramas de
secuencia, como el que aparece en la figura 1.27, y los diagramas de colaboración. Ambos contienen
exactamente la misma información, pero la muestran de diferentes maneras. La figura 1.28 es el diagrama de
colaboración equivalente al diagrama de secuencia de la figura 1.27.

Figura 1.26. Una clase asociación

: WInP réstamos :Socio :Video : Préstamo

: Encargado

prestar(video, socio)
verificar situación socio

verificar situación video

registrar préstamo

entregar recibo

Figura 1.27. Diagrama de secuencia.

El diagrama de secuencia muestra los objetos y mensajes que se envían en un escenario específico.
En el diagrama de secuencia, un objeto se desplaza hacia abajo de modo que su línea de vida (el nombre que
reciben las líneas verticales) inicia donde se crea el objeto. El rectángulo estrecho en una línea de vida muestra
cuando el objeto relevante está activo. El diagrama de colaboración, al igual que el diagrama de secuencia,
muestra los objetos, así como los mensajes, numerados en el orden en el cual se envían en un escenario
específico.

- 23 -
Tecnologías Orientadas a Objetos (T. E.)

En los diagramas de secuencia es posible representar cuando se crea un objeto en forma dinámica. De la
misma forma en que los objetos pueden crearse, pueden ser destruidos. Por ejemplo, la figura 1.29 muestra que
un comprador hace una oferta para una obra maestra (cuadro o pintura) pero ésta se rechaza, por lo que no es
necesario mantener el objeto :Clase Obra Maestra que se creó con el propósito de realizar el cálculo del precio
máximo que el comprador debe ofrecer por la obra maestra.

:Socio

:Video

2: verificar situación socio

1: prestar(video, socio) 3: verificar situación video

:WInPréstamos

5: entregar recibo
: Encargado 4: registrar préstamo

:Préstamo

Figura 1.28. Diagrama de Colaboración

Figura 1.29. Diagrama de Secuencia que muestra la creación dinámica y la destrucción de un objeto.

- 24 -
Tecnologías Orientadas a Objetos (T. E.)

La figura 1.29 también muestra además de la creación del objeto :Clase Obra Maestra, indicado por la línea de
vida que inicia sólo en el punto de la creación dinámica, y la destrucción de ese objeto después de que recibe el
mensaje “destruir objeto”. La destrucción se indica mediante la X en negrita. En el último mensaje también hay
una alerta [oferta rechazada]. Es decir, el mensaje “destruir objeto” se envía sólo si la respuesta del comprador
es rechazada. Una alerta (condición) es algo que puede ser verdadero o falso; sólo si la alerta es verdadera el
mensaje se envía. El propósito de la alerta es asegurar que el mensaje se envía sólo si la condición relevante es
verdadera. Las alertas también se usan en los diagramas de estado. Un objeto también puede enviarse un
mensaje a sí mismo. Esto se conoce como autollamada.

Los diagramas de colaboración se dijo que son equivalentes a los diagramas de secuencia; así que todas las
funciones de los diagramas de secuencia mencionados en los párrafos anteriores, se aplican por igual a los
diagramas de colaboración.

Diagramas de Estado
El diagrama de estados muestra el comportamiento del sistema y las clases o conceptos. Este diagrama refleja
todas las operaciones realizadas por o para el sistema o la clase, indicando los eventos que provocan la
transición de estado a estado. La figura 1.30 muestra el diagrama de estados de la Clase Socio en un sistema
de préstamo de libros. El círculo sólido en la esquina superior izquierda presenta el estado inicial, el punto de
inicio del diagrama de estados.

Figura 1.30. Diagrama de Estados

- 25 -
Tecnologías Orientadas a Objetos (T. E.)

La flecha del estado inicial lleva al estado llamado sin préstamos (los estados distintos del inicial y final se
representan mediante rectángulos con esquinas redondeadas). En el estado sin préstamos pueden suceder dos
eventos. Con más detalle, un socio puede prestar un libro o cancelar su membresía. Estas posibilidades se
indican mediante los dos eventos: prestarLibro y baja. (Un evento provoca una transición de estados). El
diagrama de estados también puede contener alertas o condiciones, como el caso de la operación
devolverLibro. Cuando un socio devuelve un libro y el número de préstamos es mayor que uno, el socio
permanecerá en el estado “con préstamos”. Pero si el socio devuelve un libro, y el número de préstamos es igual
a uno, entonces pasará al estado “sin préstamos”.

En resumen, un sistema o una clase, se mueven de estado a estado. En cada estado, el sistema o la clase,
pueden realizar las operaciones soportadas por ese estado, que se indican por medio de flechas que salen de
ese estado.

Diagramas de Actividad
Los diagramas de actividad muestran cómo se coordinan los diversos elementos. Normalmente se usan cuando
se llevan a cabo actividades en paralelo. Por ejemplo, en la figura 1.31 se muestra el diagrama de actividad de
un sistema dispensador de bebidas, las cuales pueden ser café o jugo. Además, muestra que la prioridad es
ofrecer café, ya que sólo cuando no hay café se ofrece jugo. Al determinar que el sistema tiene café, debe
prepararlo.

Buscar Bebida [ no hay café ] [ no jugo ]

[ hay café ]
[ hay jugo ]

Poner café Añadir agua Tomar taza

en filtro al depósito Servir
jugo
Poner filtro
en máquina

Encender
máquina
/ cafetera.On

Café en
preparación

indicador de fin
Servir café Beber

Figura 1.31. Diagrama de Actividad

- 26 -
Tecnologías Orientadas a Objetos (T. E.)

Para preparar café es necesario realizar algunas actividades antes de encender la máquina, las cuales son:
poner café en el filtro, poner el filtro en la máquina y añadir agua al depósito. La línea gruesa horizontal en la
parte superior se llama bifurcación y la inferior se llama unión. En general, una bifurcación tiene una transición
de entrada y muchas transiciones de salida, cada una de las cuales desencadena una actividad que se ejecutará
en paralelo con las otras actividades. A la inversa, una unión tiene muchas transiciones de entrada, cada una de
las cuales vienen de una actividad ejecutada en paralelo con las otras actividades, y tienen una transición de
salida que se inicia cuando todas las actividades en paralelo han finalizado.
Los diagramas de actividad son útiles para modelar sistemas en los que una serie de actividades se realizan en
paralelo. Además de la bifurcación y la unión es posible colocar carriles (recuadros) sobre el diagrama, para
representar las clases responsables de realizar cada actividad.

Diagrama de Objetos
Un diagrama de objetos es la fotografía de un instante de ejecución del sistema, es una imagen del sistema en
un momento del tiempo. Ya que contiene objetos, se le conoce como Diagrama de Objetos. Es útil para mostrar
algún ejemplo del sistema, como para ilustrar estructuras de dato complicadas o para mostrar el comportamiento
a través de una secuencia de diagramas de objetos en el tiempo (ver figura 1.32). Todos los diagramas pueden
ser del mismo sistema aunque luzcan diferentes. Estos diagramas no son definiciones o especificaciones del
sistema. La definición de la estructura y el comportamiento del sistema se encuentran en los modelos del
dominio y de los casos de uso (como el diagrama de clases y el de casos de uso), y construir los modelos del
dominio y de casos de uso, es la meta del modelado y el diseño. El modelo del dominio (diagrama de clases)
describe los posibles objetos que pueden crearse, pero no los presenta. Los objetos presentados en el diagrama
de objetos normalmente no aparecen en el modelo del dominio.

Figura 1.32. Ejemplo de Diagrama de Objetos (Generado a partir del diagrama de clases dado)

- 27 -
Tecnologías Orientadas a Objetos (T. E.)

Diagrama de Componentes
Un diagrama de componentes muestra las dependencias entre los componentes de software, incluye el código
fuente, el código compilado y las imágenes de carga ejecutables. Por ejemplo, el diagrama de componentes de
la figura 1.33 muestra el código fuente (representado por una nota) y la imagen de carga ejecutable creada
desde el código fuente.

Figura 1.33. Diagrama de Componentes.

Los programadores escriben el código fuente en un lenguaje orientado a objetos como C++ o Java. El código
fuente luego se traduce mediante un compilador a código compilado o código binario, que es el único lenguaje
que entiende una computadora. Finalmente, el código compilado para cada módulo se combina con rutinas en
tiempo de ejecución para producir una imagen de carga ejecutable.

Diagrama de Despliegue
Un diagrama de despliegue muestra sobre cuál componente de hardware se instala (o despliega) cada
componente de software. También muestra los enlaces de comunicación entre los componentes de hardware.
Un diagrama de despliegue simple aparece en la figura 1.34.

- 28 -
Tecnologías Orientadas a Objetos (T. E.)

Figura 1.34. Diagrama de Despliegue.

1.3. Proceso de Desarrollo Orientado a Objetos usando UML.

1.3.1 Asignación de Responsabilidades

Una habilidad clave y fundamental en el análisis y diseño orientado a objetos es la asignación cuidadosa de
responsabilidades a los componentes (clases por ejemplo) de software. Ya que esta actividad debe efectuarse
mientras se dibuja un diagrama UML o programando, e influye fuertemente sobre la robustez, mantenimiento y
reutilización de los componentes de software. Además, es una habilidad que requiere esfuerzo el llegar a
dominarla y al mismo tiempo tiene una importancia vital.

1.3.2 Análisis y diseño orientado a objetos

Durante el análisis orientado a objetos, se presta especial atención a encontrar y describir los objetos – o
conceptos – en el dominio del problema. Por ejemplo, en el caso de un sistema de información para una
biblioteca, algunos de los conceptos son: Libro, Biblioteca y Usuario.

Durante el diseño orientado a objetos, se presta especial atención a la definición de los objetos software y en
cómo colaboran para satisfacer los requisitos. Por ejemplo, en el sistema de la biblioteca, un objeto software
Libro podría tener un atributo título y un método obtenerCapítulo (ver figura 1.35).

- 29 -
Tecnologías Orientadas a Objetos (T. E.)

Figura 1.35. La orientación a objetos presta especial atención a la representación de los objetos.

Por último, durante la programación orientada a objetos (o implementación según algunos autores), los objetos
de diseño se programan, como la clase Java Libro.

1.3.3. Ejemplo de Análisis y Diseño Orientado a Objetos

Antes de estudiar en forma detallada el análisis y diseño orientado a objetos (OO), esta sección de la unidad 1,
presenta un ejemplo con unos pocos pasos del proceso de desarrollo de sistemas de información y los
diagramas UML más importantes. El ejemplo trata sobre un “juego de dados” en el que un jugador lanza dos
dados. Si el total de sumar los valores de cada dado es siete, el jugador gana; en otro caso, pierde.

Los pasos que incluye el ejemplo son:

1) Definición de los Casos de Uso
2) Definición del modelo del dominio
3) Definición de los diagramas de interacción
4) Definición de los diagramas de clases de diseño

1. Definición de los casos de uso

Los casos de uso son descripciones narrativas en lenguaje natural de los procesos del dominio en un formato
estructurado de prosa. Los casos de uso no son propiamente un elemento del análisis y diseño orientado a
objetos (pueden ser utilizados en análisis no orientados a objetos), pero constituyen un paso preeliminar muy útil

- 30 -
Tecnologías Orientadas a Objetos (T. E.)

porque describen las especificaciones de un sistema. Por ejemplo, aquí esta una versión breve del caso de uso
Jugar una Partida de Dados:
Caso de uso: Jugar una partida de dados.

Participantes: Jugador.

Descripción: Este caso de uso comienza cuando el jugador recoge y lanza los dados. Si los puntos
suman siete, gana y pierde si suman cualquier otro número.

El diagrama de casos de uso del UML correspondiente sería similar al de la figura 1.36.

Figura 1.36. Diagrama de Casos de Uso del Juego de Dados.

2. Definición de un modelo del dominio

Un modelo del dominio muestra gráficamente, a través de un grupo de diagramas, los conceptos (clases de
objetos), los atributos y las asociaciones más importantes del dominio. La finalidad del análisis OO es crear una
descripción del dominio desde la perspectiva de la clasificación de objetos. Una descomposición del dominio
conlleva a una identificación de los conceptos, atributos y asociaciones que se consideran significativas. El
resultado se puede expresar en un modelo del dominio, como lo muestra la figura 1.37.

Figura 1.37. Modelo del dominio parcial del juego de dados.

- 31 -
Tecnologías Orientadas a Objetos (T. E.)

Este modelo muestra los conceptos más importantes Jugador, Dado y Juego de Dados, con sus asociaciones y
atributos. Es importante mencionar que un modelo del dominio no es una descripción de los objetos software,
más bien es una visualización de los conceptos en el dominio del mundo real.

3. Definición de los diagramas de interacción

La finalidad del diseño orientado a objetos es definir los objetos software y sus colaboraciones. Una notación
habitual para ilustrar estas colaboraciones es el diagrama de interacción. Los diagramas de interacción
representan el flujo de mensajes entre las instancias y la invocación de métodos.

Por ejemplo, suponga que se desea implementar (o programar) el juego de dados. El diagrama de interacción de
la figura 1.38 muestra los pasos esenciales del juego, enviando mensajes a las clases JuegoDados y Dado.
Aunque en el mundo real un jugador lanza los dados, en el diseño de software el objeto JuegoDados lanza los
dados (es decir, envía mensajes a los objetos Dado). Los diseños de los objetos software y los programas se
basan en los dominios del mundo real, pero no son modelos directos o simulaciones del mundo real.

Figura 1.38. Diagrama de Interacción que muestra los mensajes entre los objetos software.

4. Definición de los diagramas de clases de diseño

Además de la vista dinámica de las colaboraciones entre los objetos que se muestra mediante los diagramas de
interacción, es útil crear una vista estática de las definiciones de las clases mediante un diagrama de clases de
diseño. Para definir las clases de objetos se deben contestar dos preguntas: ¿cómo se conectan unos objetos a
otros? y ¿cuáles son los métodos de cada clase?. Un diagrama de clases de diseño contesta estas preguntas.

Por ejemplo, en el juego de dados, al analizar el diagrama de interacción, se puede deducir el diagrama de
clases de diseño parcial que se muestra en la figura 1.39. Ya que se envía el mensaje jugar al objeto
JuegoDados, JuegoDados, requiere un método jugar, mientras la clase Dado requiere los métodos lanzar y
obtenerValorCara.

- 32 -
Tecnologías Orientadas a Objetos (T. E.)

A diferencia del modelo de dominio, este diagrama no muestra conceptos del mundo real, sino clases de
software.

Figura 1.39. Diagrama de Clases de Diseño Parcial.

- 33 -