UNIDAD III

DISEÑO ORIENTADO A OBJETOS Y UML

MODELO DE PROCESO DE
DATOS Y ORIENTACION A
OBJETOS
Modelo y estructurado de datos
Unidad III: Diseño orientado a objetos y UML

En el Modelado Orientado a Objetos, se constituye un paradigma diferente de llevar a cabo

la representación de proyectos de software, dejando de lado la programación procedimental y lineal.
La programación orientada a objetos no representa un lenguaje de programación en sí, sino es una
forma de enfrentar la programación en base a la reutilización de código. Hoy en día existen muchos
lenguajes que soportan este tipo de programación y algunos han sido creados especialmente para ello,
es por esto que la misma se presenta como una alternativa vigente en la actualidad.

La programación orientada a objetos facilita la representación de los objetos del mundo real.
De cada entidad básica de POO, denominada como objeto, se podría mencionar a sus características
y es lo que se conoce como: propiedades o atributos, pudiendo ser: edad, velocidad, temperatura,
color, altura, entre otros.
A las acciones que pueden desencadenar los objetos es lo que se conoce como: funciones o
métodos, pudiendo ser éstas acciones las siguientes: activar, subir, acelerar…

Cada uno de los objetos podría constituirse en una estructura de clases. Una clase es una
estructura que se compone de cada objeto que forma parte del mismo tipo. Por ejemplo, se podría
mencionar que un objeto que tiene una serie de características como son: ojos, nariz, boca, brazos,
piernas, pertenece a la "clase persona". La razón de ser de una clase en POO consiste en determinar
sus características y métodos por lo que están compuestos los objetos de un mismo tipo.
A varios objetos que corresponden a la misma clase se les llama instancias de esa clase. Es así
que podríamos tener una clase de nombre vehículos, los objetos tales como automóvil, motocicleta,
bicicleta serían instancias de esa clase. La clase vehículo está constituida por características
principales que tiene cualquier medio de desplazamiento, y que compartirán todos los
objetos/instancias que pertenezcan a esa clase. Estos elementos a compartir serían por ejemplo las
ruedas – pero cada instancia tiene un número y tipo distinto de ruedas.

Los cuatro pilares de la POO son:

 Abstracción
 Encapsulamiento
 Herencia
 Polimorfismo
 Abstracción: La abstracción es la capacidad de extraer toda información y cualidad de un
determinado objeto que nos parezca relevante. Para éste propósito, nos concentramos en el
comportamiento esencial.
Gracias a esto, se puede representar las características esenciales de un objeto sin preocuparse
de los restantes. Por ejemplo, de un objeto animal como el gato, al pensar en ellos, uno se imagina en
sus propiedades o características, como ser: nombre, color, peso, edad y en sus métodos o
comportamientos, como ser: correr, maullar, saltar, comer…

Encapsulación es la capacidad de ocultar los datos relevantes que se han abstraído de un

determinado objeto, aislarlos o protegerlos de quien no se desea que se tenga acceso a ellos; que en
términos de programación, sería otro objeto. Los objetos pueden tener muchas cosas encapsuladas en
su interior: propiedades, funciones o incluso otros objetos.
Muchas veces no se necesita entender el funcionamiento interno de un objeto, sino tan solo
sus funcionalidades: para que sirve o qué puede hacerse con él, por tanto un objeto puede ser
cambiado por otro siempre y cuando cumpla con la misma función. El usuario no necesita saber cómo
funciona internamente todo el objeto, sino simplemente qué método usar, y el tipo de resultado que
el método proveerá – (por ejemplo, no hace falta saber todo el funcionamiento interno de un
automóvil, sino basta con usar el método de pisar el acelerador para desplazarse).

Herencia: Describe la situación en la que puede crearse un objeto a partir de otro objeto ya
existente, y este nuevo objeto hereda todas las cualidades del objeto del que deriva y además puede
añadir nuevas funcionalidades o modificar las ya existentes. La clase superior se denomina padre, la
cual se asocia a clases hijas.
Un ejemplo práctico sería de un computador con sus planos, y se quiere fabricar otro
computador. En vez de crear uno de cero, sería más fácil basarse en el computador ya existente y
añadirle o modificarle ciertas funcionalidades.
La clase que se crea a partir de otra clase se le conoce como subclase o clase derivada.

Polimorfismo: Es cuando varias clases u objetos derivados de otros actúan de manera

diferente ante los mismos métodos. El polimorfismo se puede aplicar tanto a objetos como a
funciones, por lo que se puede hablar de objetos polimórficos y de funciones polimórficas. Es así que,
cuando apretamos el acelerador de un automóvil, no va a responder igual el que posee un motor diesel
comparado a uno naftero.
Objeto

Un objeto es la entidad base de la POO. Puede ser tangible, una cosa palpable inerte, como
así también una persona. Asimismo, puede ser algo intangible como ‘horario’ o ‘turno’. En resumen,
un objeto representa una entidad individual e identificable.

Los objetos poseen: Estado, identidad y comportamiento.

El estado de un objeto abarca todas las propiedades del objeto en una instancia de tiempo
específica, y los valores actuales representan a sus propiedades. Los valores que toman esas
propiedades cambian con el tiempo. Los objetos ocupan espacio, ya en el mundo físico, o en la
memoria del sistema.

La identidad es la propiedad de un objeto que lo lleva a distinguirse de otros, es por ello que
a cada objeto se lo asigna un nombre.

El comportamiento es como el objeto actúa y reacciona en términos de sus cambios de estado

y de los mensajes que intercambia con otros objetos. El comportamiento de un objeto son las acciones
visibles y probables, dicho de otro modo son las operaciones que una clase realiza.
Al referirnos al término de operación se está haciendo referencia al servicio que una clase
ofrece a los que acceden a él. Un objeto puede realizar cinco tipos de operaciones sobre otro, con el
propósito de provocar una reacción:

1. Modificarse: que consiste en alterar el estado de un objeto.

2. Seleccionar que consiste en: acceder al estado de un objeto, sin alterarlo.
3. Iterar: se refiere al acceso ordenado de las partes del objeto.
4. Construir: es cuando se crea un objeto o se inicializa su estado.
5. Destruir: se refiere a la acción de liberar el estado de un objeto o eliminarlo.

Además, entre objetos existen las relaciones, que son las operaciones que un objeto realiza
sobre otros.
Clase

Una clase es un conjunto de objetos que comparten una estructura y comportamiento que son
comunes entre ellos.
Se podría referir a objetos y clases con los siguientes términos:

 Clase representa una abstracción o la esencia que comparten los objetos.

 Un objeto es una instancia de una clase (pues los objetos pasan a ser clases)
 Un objeto no es una clase, y una clase no es un objeto.

Relaciones entre clases y objetos

 Todo objeto es el ejemplo de una clase, y toda clase tiene 0 o más objetos.
 Las clases son estáticas - con semántica, relaciones y existencia fijas previamente a la
ejecución de un programa
 Los objetos sin embargo se crean y destruyen rápidamente durante la actividad de una
aplicación.

Comportamiento de un objeto

Mensajes: Los objetos se comunican e interactúan entre sí por medio de mensajes. Si un

objeto desea que otro objeto haga algo, le envía un mensaje, que puede tener información adicional
en forma de parámetros. Cuando un objeto lo recibe, ejecutará un método.

Método: Los métodos son las ‘acciones’ que puede realizar un objeto. Pueden ser métodos
sin parámetros que se ejecutan directamente, o pueden ser métodos cuya ejecución se ve alterada por
parámetros que lo definen. Además, pueden devolver o no un valor al finalizar su ejecución. A este
valor se le llama valor de retorno.

Si volvemos al ejemplo de un automóvil, ejemplos de métodos sin parámetros serían arrancar

o detener el motor, mientras ejemplos de métodos con parámetros serían el giro del volante (los
parámetros son la dirección y los grados de giro), o el pisar el acelerador (el parámetro sería el nivel
de fuerza ejercida sobre el pedal, lo que influye en el motor), o un cambio en la transmisión (el
parámetro sería la caja a la cual se cambia).
Proceso unificado vía UML

El concepto de proceso unificado se refiere a un modelo de desarrollo que define "quién"

hace "qué", "cuándo" y "cómo". Sus objetivos son:

 Representar una guía/manual de actividades de un proyecto de software, dirigido a: clientes,

usuarios, desarrolladores, directivos
 Ordenar las actividades del equipo
 Dirigir las tareas de cada desarrollador y del equipo como un todo
 Especificar los artefactos que deben desarrollarse en cada etapa
 Ofrecer criterios para el control y la medición de cada actividad y del producto resultante
 Reducir riesgos y hace el proyecto más predecible

El proceso unificado se caracteriza por:

Ser dirigido por casos de uso: Los casos de uso dirigen todo el proceso de desarrollo debido
a que las actividades o flujos de trabajo (análisis, diseño, implementación y prueba), se llevan a partir
de ellos.

Ser centrado en la arquitectura: Proporciona diferentes vistas del sistema. Como parte de
la arquitectura, se tiene la definición de: sistema operativo, sistema de gestión de base de datos, los
protocolos de red, etc. Dentro de la arquitectura se definen los requisitos:

Funcionales: Representado por cada caso de uso. Los CU representan en forma gráfica las
funcionalidades de todo el sistema.
No funcionales: Como parte de este requisito se tiene al rendimiento, fiabilidad, integridad de
datos que debería de proporcionar un software; y por otra parte también se menciona a todos los
recursos que permiten dar funcionalidad al software, como: los computadores donde estará instalada
la aplicación, el servidor donde estará instalada la BD, la topología de red, y adicionalmente la
documentación que instruye acerca del sistema.
Requisitos candidatos: Representa una lista de características que se van añadiendo en la
medida que el sistema va creciendo, estas características se establecen al momento de realizar la
planificación del proyecto, y son:

 Estado, cuyos valores podrían ser: propuesto, aprobado, incluido o validado.

 Costo,implica los tipos de recursos y horas-personas necesarios para implementar
 Nivel de riesgo, que puede ser crítico, significativo y ordinario.

Ser iterativo e incremental: Consiste en la especificación de que el proyecto se va dividiendo

en miniproyectos o secciones, y a cada nueva versión que se crea, se lo llama como iteración del
software. La iteración es la que genera un incremento de las partes de que se compone el proyecto.
Ciclo de vida del proceso unificado

Inicio: Se deben establecer las reglas, normas y condiciones de negocio, delimitar el proyecto,
identificar actores y casos de uso, y finalmente decidir si se ejecutará el proyecto.

Elaboración: Se debe establecer la arquitectura, evaluar riesgos (requerimientos,

tecnológicos, políticos), especificar en detalle los casos de uso. Al final de esta etapa, se deben
planificar las actividades y estimar los recursos.

Construcción: Iterativa e incrementalmente, se desarrolla el producto completo. El producto

contiene los casos de uso que los desarrolladores y el cliente acordaron.

Transición: Se presenta la versión beta o "de prueba" del producto, se realizan las pruebas y
se define el reporte de los defectos y deficiencias.
Flujo de trabajo del Proceso Unificado

Modelo de Negocio: Define los procesos de negocio de la organización.

Modelo de Casos de Uso: incluye a los Caso de Uso y su relación con los actores.
Modelo de Análisis: detalla los eventos que ocurren en cada Caso de Uso.
Modelo de diseño: define el Caso de Uso como colaboraciones entre subsistemas, clases e
interfaces.
Modelo de Implementación: se toman en cuenta a los componentes (código fuente), de las
clases (aspecto lógico) y componentes (aspecto físico)
Modelo de Despliegue: representa a los nodos físicos, lo cual constituye a la infraestructura
tecnológica, como así también a la ubicación de los componentes
Modelo de Prueba: se definen los casos de uso de prueba, siguiendo todas las combinaciones
posibles en busca de errores o elementos faltantes.

Todo proyecto se inicia identificando el problema, proponiendo la solución para luego realizar
el relevamiento de los datos que se requiere para el modelado del sistema, es por ello que se debe
realizar la captura de requerimientos.

Captura de requerimientos

Como parte de la captura, se consideran los siguientes aspectos:

Modelo de negocio: Consiste en entender la estructura y funcionamiento de la organización,

se analizan los problemas existentes y se identifican potenciales o posibles mejoras a ser
implementados.

Glosario de términos de negocio: Se definen los términos más importantes usados por el
negocio y que sea de fácil entendimiento para todos los involucrados en el proyecto. Los términos
corresponden a la descripción textual del planteamiento del negocio.
 Reglas de negocio: Delimitan las restricciones a tener en cuenta, como por ejemplo el número
máximo de libros que se puede prestar a un socio en una biblioteca, el máximo porcentaje de
descuento aplicable en una promoción, etc.

Modelo de casos de uso: Su objetivo es presentar funciones de las que se compone el

negocio, esto permite identificar roles y responsabilidades de los miembros del mismo. Se utiliza al
diagrama de Casos de uso para modelar a los Casos de Uso del negocio, junto con sus actores.
El diagrama de Caso de Uso representa a un componente de la herramienta del UML
(Lenguaje Unificado de Modelado). El Proceso Unificado hace uso del UML, el cual es componente
de una serie de diagramas con los cuales se logra representar a las acciones que el negocio realiza y
son los que se desea plasmar en un software en funcionamiento.

A continuación se explican los diagramas del UML:

1) Diagrama de caso de uso

Los casos de uso se definen para representar a las funciones que el sistema va a llevar a cabo,
es una secuencia de interacciones entre un sistema y una persona u objeto que envía y recibe datos
del sistema - a éstos se los conoce como actores.
En caso de que el actor no represente a una persona, el mismo podría ser un compnente del de
hardware o software. Por ejemplo, si se pretende modelar un sistema de ventas donde se debe ingresar
un nuevo pedido de un cliente, cuando el usuario realiza el pedido, lo que ocurre es que se está
“ejecutando” el caso de uso de nombre “ingresar pedido”.

Un caso de uso es una descripción de los pasos, eventos y acciones, que deberán realizarse
para llevar a cabo algún proceso. Tanto el Modelado de Sistemas como la programación, forman parte
de la ingeniería del software, en él se tiene un caso de uso, lo cual representa una secuencia de
interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia
un actor sobre el propio sistema.
Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento
de un sistema mediante su interacción con los usuarios y/u otros sistemas. Muestra la relación entre
los actores y los casos de uso en un sistema, además de los requerimientos del mismo al mostrar cómo
reacciona a eventos iniciados por un actor.

Su simbología es:

Actor: Representa a la
entidad externa que interactúa
con el sistema, en este caso con los casos de uso. La entidad externa podría estar representada por
una persona u objeto.
Caso de Uso: El nombre de un caso de uso se expresa con un verbo en infinitivo, seguido
generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente,
los casos de uso se representan con un óvalo (elipse).
Línea o asociación de comunicación: son líneas rectas sin flechas, que sirven para enlazar a
los actores con los casos de uso.
Asociación o enlace de tipo <uses> (Uso): es el enlace que se podría dar entre dos casos de
uso cuando una acción debe ejecutarse posteriormente a la ejecución de acciones o eventos de su
sucesor. Este tipo de enlace sirve para representar la secuencia de funciones que deben ejecutarse
dentro del diagrama de caso de uso.
Asociación o enlace de tipo <extends>: este enlace indica la ejecución de una acción de entre
un conjunto de alternativas, sirve para enlazar un caso de uso que va asociado a dos o más casos de
uso, de los cuales se "elige" uno. Por ejemplo podríamos tener un caso de uso de nombre pagar
cuenta, y éste se asocia a las opciones de pago que se podría tener, las cuales serían enlaces extends:
pagar en efectivo, pagar con tarjeta de débito, pagar con tarjeta de crédito, pagar con cheque.
Asociación o enlace de tipo <include>: se utiliza para representar la ejecución de un
determinado caso de uso que depende de una acción primaria como una precondición, lo cual también
está definido en otro caso de uso. Por ejemplo, con los CU “registrar venta” y “consultar catálogo
de productos”, al tener una relación de tipo <include>, se expresa que primeramente se debe
consultar el catálogo, para luego realizar la venta.
Límite de un sistema: también se lo conoce como frontera, sirve para establecer el alcance
del sistema (o una parte de él). Gráficamente se lo puede representar con un rectángulo o con dos
líneas paralelas verticales, la frontera es útil en sistemas grandes y complejos, los cuales se componen
de varios módulos - dentro de cada frontera se establece hasta dónde llega la funcionalidad de un
determinado módulo. Se puede así limitar el alcance de un diagrama de caso de uso para representar
al módulo de RR.HH, otro para el área comercial, otro para el área contable, otro para el área de
producción, etc. En casos de proyectos de software pequeños, normalmente se tiene un solo diagrama
de caso de uso para todo el proyecto.

Ejemplo de diagrama de caso de uso: Ventas vía web

La gestión de venta se efectúa con el previo registro de un usuario; una vez registrado el
usuario, el mismo procede a optar por su libro de preferencia, indicando su forma de pago que puede
ser al contado o financiado - ambas formas de pago se efectúan con tarjeta de crédito, una vez
decidido, el sistema le emitirá un mensaje de confirmación o error según el nivel de crédito disponible.
2) Descripción de casos de uso

El Proceso Unificado considera a la descripción de los casos de uso como una actividad cuyo
objetivo principal consiste en describir el flujo de sucesos de los eventos que ocurren dentro de un
caso específico del diagrama anterior.
La estructura de la descripción de un CU define los estados que las instancias pueden tener,
y la posible transición entre cada uno de esos estados. Cada transición representa a una secuencia de
acciones que se ejecuta en una instancia del CU, cuando ésta se activa o ejecuta. Se debe tener en
cuenta que la descripción debe ser precisa y fácil de leer, en ella se van desglosando las alternativa
de ejecución de acciones que se podrían tener dentro de un determinado caso de uso.
Las alternativas, desviaciones, o excepciones que se podrían presentar en la ejecución del CU,
podrían manifestarse por muchas razones:

 El actor puede elegir entre diferentes caminos en el caso de uso, es así que podríamos
tener por ejemplo, que durante la ejecución de un caso de uso de nombre “Pagar
factura”, el actor podría decidir pagar una factura o rechazarla.
 En caso de que intervenga más de un actor en el Caso de Uso, las acciones de uno de
ellos podría influenciar el camino de las acciones de los otros actores.
 El sistema puede detectar entradas que son errores producidos por los actores, e
interrumpir el proceso mostrando un error.
 Algunos recursos del sistema pueden tener un mal funcionamiento, lo cual podría traer
como consecuencia de que el sistema impida a que el CU realice de forma adecuada
su trabajo. (ej. pérdida de energía o enlace)
 El camino básico que se sigue en las secuencias de acciones representa al camino normal o
habitual, es lo que el usuario percibe como el camino que usualmente va a seguir y aquél que le
proporcionará el resultado que está esperando obtener como resultado de la ejecución del CU.
Según la figura siguiente, que corresponde a un Diagrama de CU para un “Sistema de Pagos
y Facturación”, se procederá a detallar uno de sus Casos de Uso como ejemplo:

Los

enlaces con texto iniciador indican cuál es el actor que inicia el Caso de Uso. Este texto es opcional,
en caso que para el cliente del proyecto sea relevante indicar quién inicia tal o cual acción.
(Observemos por ejemplo que no es el vendedor quien inicia "Solicitar bienes o servicios", ya que no
tiene sentido - es el comprador el que inicia este CU).
Tomando el CU "Pagar Factura", procedemos a la descripción de CU del mismo:
Nombre del Caso de Uso: Pagar Factura
Actor/es: comprador y vendedor
Precondición: el comprador ha recibido los bienes y servicios, y al menos una factura del sistema, es
por ello que el comprador planifica su correspondiente pago.
Flujo de Sucesos
Camino básico:
1. El comprador activa al caso de uso para iniciar a revisar las facturas recibidas por medio del
sistema. El sistema verifica que el contenido de la cada factura sea consistente con las
confirmaciones de pedidos que ha recibido, de tal modo a que pueda confirmar al comprador.
2. El comprador decide planificar una factura para pagarla por transacción bancaria, y el sistema
genera una petición de pago para transferir el dinero desde la cuenta del comprador a la cuenta
del vendedor.
3. Si el comprador tiene suficientes fondos en su cuenta, se realiza la transacción del pago,
durante el proceso de transacción el dinero se transfiere de la cuenta del comprador a la cuenta
del vendedor. Posterior a éste proceso, tanto el comprador como el vendedor reciben una
notificación como parte del pago realizado. El banco cobra comisión por la transacción, esto
se descuenta de la cuenta del comprador.
4. La instancia del Caso de Uso finaliza.

Caminos alternativos:
 En el paso 2, podría pedirse al sistema que genere un rechazo de factura al vendedor, por
disconformidad del producto, o porque el monto de la factura es incorrecto.
 En el paso 3, si no hay suficiente dinero en la cuenta del comprador, se generará una acción
de cancelar el pago y se le notificará al comprador que no posee fondos.

Postcondición: la instancia del Caso de Uso termina cuando la factura ha sido pagada, o cuando el
pago de la factura ha sido cancelado y no se ha realizado ninguna transferencia.

Criterios a tener en cuenta para una adecuada descripción/detalle de los Casos de Uso:

 La descripción del caso de uso debe definir el estado inicial como precondición.
 Definir cómo y cuándo comienza el CU, que sería la primera acción a ejecutarse.
 Enumerar las acciones para indicar el orden requerido para la ejecución de las mismas.
 Definir cómo y cuándo terminan los Casos de Uso.
 Se deben definir los posibles estados finales en las postcondiciones.
 Los caminos de ejecución que no están permitidos, o los caminos que no deberían de ser
posibles, como pagar por ejemplo dos veces la misma factura, son restricciones que el sistema
debería de imponer, y por lo tanto deben ser modeladas.
 Considerar la interacción del sistema con los actores y los cambios que producen.
 Considerar la utilización de objetos, valores y recursos del sistema.
 Se debe describir explícitamente lo que hace el sistema, se debe separar las responsabilidades
del sistema y la de los actores - caso contrario, la descripción del caso de uso no será
suficientemente precisa como para que el programador lo utilice en su especificación.
En la siguiente unidad se continúa con más diagramas de UML.

Bibliografía
Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El Proceso Unificado de Desarrollo de Software.
Pearson Addisson-Wesley. Año 2000.