Diseño Orientado a Objetos

En esencia es una técnica de construcción y manipulación de abstracciones.
La potencia de este paradigma, reside en que se basa en un enfoque, a la hora de realizar el 
diseño y análisis de aplicaciones, muy similar a la realidad que nos rodea. 

Ofreciendo una serie de ventajas como enfoque más natural, abstracción, reutilización, mayor 
robustez, menor acoplamiento, mayor cohesión y mayor capacidad funcional.

Por el contrario tiene como inconvenientes, un mayor coste del diseño de módulos reutilizables, 
lenguajes de programación orientado a objetos son poco eficientes, y dificultad de rastreo a la hora 
de depurar programas

Clases y Objetos

Hay que distinguir entre dos conceptos similares, pilares en los que sustenta el
paradigma que estamos viendo.

• Clase: Abstracción de un concepto, (idea o realidad), del mundo dentro de la ingeniería del 
software.

• Objeto: Es una instanciación o materialización de una clase.

Para simplificar ambos conceptos, podíamos decir que la clase es un molde y los objetos el 
resultado final y palpable de dicho molde.

A modo de ejemplo, una clase sería un molde pastelero con una forma determinada, y los objetos 
cada una de las galletas con dicha forma que se realizaran con el molde.

Por tanto distintos objetos pueden pertenecer a la misma clase, y siempre clases diferentes 
generan distintos objetos.

Las clases están compuestos de dos partes, una estática que serían la compuesta por los atributos 
o propiedades que son las variables que muestran el estado del objeto, y la parte dinámica, 
compuesta por métodos que son las funciones y que pueden ser de acceso, actualización, y unos 
especiales constructores y destructores.

Los objetos se instancian o crean mediante un mensaje que no es más que la invocación del 
método constructor de la clase, de la misma manera dejan de existir por medio del mensaje 
correspondiente, al invocar al método destructor.

Por todo ello y a modo esquemático, podríamos determinar que la vida de un objeto e define en 3 
pasos

1. Instanciación, mediante la invocación del mensaje constructor.
2. intercambio de mensajes con otros objetos y/o entorno
3. Finalización, mediante la invocación del método destructor 

Visibilidad 

Según la interfaz que especifiquemos a las distintas partes de la estructura de una clase.

Tenemos 3 tipos

• Pública: Todo lo definido con este tipo de interfaz, (métodos o atributos), son accesibles por 
cualquier objeto.

• Protegida: Todo lo definido bajo esta interfaz, será accesible por objetos de la misma clase o 
subclase.

• Privada: Es la interfaz más restrictiva, todo lo definido bajo este tipo es únicamente
accesible por objetos de la misma clase.

Relaciones entre Clases 

Hay 3 tipos

• Generalización: Relación entre clase origen, (subclase), y otra más genérica (superclase), 
concepto asociado a “es un”, en donde cada objeto de la subclase es un objeto de la superclase. 
Se implementa mediante la herencia
• Agregación: Se traduce como que una clase “es parte de”, (ej asignatura es parte de un plan de 
estudios). El objeto que contiene a los otros se llama agregado y los contenidos son componentes. 
Tenemos dos tipos

• Fuerte: Componentes se crean al establecer el agregado y no tiene sentido su existencia sin este

• Débil: Componentes pueden existir sin que esté el agregado que los contiene.

• Asociación: Conexión semántica entre clases no relacionadas, (ej profesor y asignatura son 
independientes, pero puede haber una relación de asociación pues los profesores imparten 
asignaturas).

Características de la Orientación a Objetos

Por otro lado, el paradigma orientado a objetos tiene una serie de propiedades que le
identifican como son:

• Encapsulación: Los atributos de la clase/objeto son inaccesibles desde el exterior, dejando 
accesible solo lo necesario para poder interactuar, sin mostrar nada más en cuanto al detalle de su 
implementación sino por medio de su interfaz con la que nos comunicaremos por medio de 
mensajes, (invocación de métodos), que tienen la forma objeto receptor.metodo (argumento[s]) 1

• Herencia: Capacidad de una clase para utilizar estructuras y métodos de clases ascendentes o 
superclase. Una clase hija dispone de todos los métodos y estructura de la que hereda. Puede 
realizarse la Anulación o Sustitución por medio de la cual redefinimos el método heredado 
especializándolo.

Existe dos tipos que son herencia simple, (desciende de una sola clase); y herencia múltiple, 
(desciende de 2 o más clases) 

Sustentado en este concepto, tenemos el de Jerarquía de Clases por medio del cual las clases se 
estructuran definiendo relaciones entre ellas que ya hemos visto existen clases a las que se les 
denomina clase virtual o abstracta de las cuales solo interesa su papel de superclase, existiendo 
únicamente como “cabeza” de la pirámide dentro de la jerarquía, que solo contiene la definición de 
métodos sin implementar y que se desarrollarán en las clases hijas por medio de la sobrecarga.
• Polimorfismo: Capacidad de referirse a distintos objetos de distintas clases de una jerarquía con 
el mismo elemento, (necesariamente sería referencia a clase padre o a clase donde se ha 
definido). Existen distintos tipos de polimorfismo, así tenemos

• Sobrecarga: Métodos o los atributos pueden tener varias formas de invocación o uso, pueden 
existir tantas versiones de un método como diferentes parámetros pueda llevar su invocación.

Puede existir incluso la sobrecarga de operadores, (+,­,...) 2
  

1 Pudiendo provocar dos tipos de problemas.
       1. Herencia Repetida donde tomando un ejemplo la clase profesor­universitario hereda de las 
clases profesor y universitario, heredará 2 veces el atributo persona.

       2. Ambigüedad se produce al tener 2 atributos con el mismo nombre

2 Por ejemplo + puede ser el símbolo de suma entre números o la concatenación de contenidos 
entre cadenas de caracteres
  

• Genericidad o Polimorfismo Paramétrico: Forman clases que describen estructuras genéricas, 
(ej Imprime (T objeto), donde Objeto puede ser de cualquier tipo) 3

• Polimorfismo Dinámico: Se produce cuando al manipular objetos utilizamos uno de una clase 
hija como si fuera objeto de la clase padre. Hay 3 tipos 

• Dinámico Subtipado: Subclase cubre todo el comportamiento de la clase padre.

• Dinámico Normal: Clase derivada tiene un comportamiento diferente al de la clase base. 
(lenguaje C++ con punteros a objetos) 

• Enlace Dinámico: Lenguajes no soportan lo visto, los métodos van precedidos de la partícula 
virtual.
Proceso de Desarrollo Orientado a Objetos

Compuesto de 3 fases

1. Planificación y Especificación de Requisitos

2. Construcción

     a. Diseño de Alto Nivel
     b. Diseño de Bajo Nivel
     c. Implementación
     d. Pruebas

3. Instalación y Puesta en Marcha

Mediante enfoque iterativo, tomando en cada ciclo una serie de requisitos hasta que se
completan, creciendo por tanto el sistema en cada ciclo.

Planificación y Especificación de Requisitos

Tiene como objetivo determinar si es apropiado el abordar el problema desde el paradigma 
orientado a objetos, definiéndose u plan a seguir, creando lo primero un informe preliminar donde 
se definen los requisitos, registramos los términos en un glosario, (tendrá continuidad en las 
siguientes fases), opcionalmente se crea un prototipo y se define un modelo de casos de uso 4 
junto con el borrador del modelo conceptual y de la arquitectura del sistema.

De la Especificación de Requisitos resaltar que identifica aquello que es relevante teniendo una 
repercusión importante cualquier error en esta fase

Como resultado final, se obtiene un documento, (no definido en UML), habitualmente escrito en 
lenguaje natural y con el siguiente contenido

• Propósito
• Ámbito
• Funciones
• Atributos

Al definir los límites del sistema determinamos lo externo, (representado por actores) y lo interno, 
(que suele ceñirse al hardware y al software).

  

3 Java no lo soporta
4 Instrumento narrativo que nos muestra una secuencia de eventos de un actor (agente externo,), 
que utiliza el sistema para completar un proceso. Consta de Sistema (ámbito del problema), Actor 
(Agente externo que interactúa con el sistema) y Escenario (Relación de interacciones entre los dos 
anteriores).
  

Casos de uso

Instrumento narrativo que muestra la secuencia de eventos de un actor o agente externo, 
(entendiendo como tal cualquier entidad o persona), que utiliza el sistema para completar un 
proceso, denominado Caso de Uso

La identificación de los casos de uso puede ser

• Basándose en Actores: Identifica los actores, obteniendo para cada uno los procesos que inicia 
o en los que participa.

• Basándose en Eventos: Identifica los eventos a los que el sistema debe responder y se 
relacionan con actores.

Una vez identificados, conviene tratarlos con el mayor grado de abstracción posible, definiéndose 
para ello casos de uso de alto nivel, especificando nombre, actores, descripción y tipo que puede 
ser Primarios, (procesos principales), Secundarios, (uso menor) y Opcionales.

Desde el punto de vista del nivel de detalle tenemos
• Esencial: Describen el proceso a nivel abstracto, (independientemente de la tecnología de la 
implementación).

• Real: Describen el proceso en detalle, en términos de solución específica.

Los diagramas se dibujan como una caja, siendo el caso de uso lo que hay en su interior, los 
actores están fuera y ambos están relacionados por medio de líneas.

Los casos de uso más importantes, se describen con un detalle mayor mediante un formato 
expandido que contendrá aparte de lo especificado anteriormente, referencias, (a otros casos de 
uso y requisitos), curso típico de eventos, (interacción sistema – actores mediante acciones 
numeradas), curso alternativo, (puntos donde pueden existir alternativas con su descripción).

Finalmente el proceso de planificación mediante casos de uso sería

• Tras listar los requisitos, se definen los límites, se identifican los actores

• Se escriben todos los casos de uso en formato de alto nivel clasificándose en prioritarios, 
secundarios y opcionales.
• Se dibuja el diagrama

• Se detallan e ilustran las relaciones entre casos de uso

• Se ordenan según prioridad

• Los más prioritarios se describen en formato expandido, el resto se describirá de esta forma en 
sucesivas interacciones.

Fase de Construcción. ­ Diseño de Alto Nivel

Su objetivo es obtener una óptima comprensión del problema por parte del equipo de
desarrollo sin entrar en los detalles de la implementación.

Las actividades para llevar esto a cabo serían:

• Definir casos de uso esenciales en formato expandido 5
• Refinar diagrama
• Especificar el Modelo Conceptual 
  

5 Si no están hechos ya
  

• Refinar el Glosario
• Definir Diagramas de Secuencia
• Definir Contratos de operación
• Definir Diagramas de Estados 6

Modelo Conceptual: Trata de identificar los conceptos que conforman el dominio del problema, por 
medio de un diagrama de estructura estática. Busca la representación de conceptos, no la de 
componentes software. 

Tiene 3 pasos
• Identificar Conceptos: Basándonos en la especificación de requisitos. 
Un concepto se representa en UML como apreciamos en la figura de la 
derecha.

• Identificar Relaciones: Pudiendo existir 3 tipos 

      * Asociación: Relación entre conceptos indicando las conexiones con sentido de interés en el 
conjunto de casos de uso que tratamos.

Se representa media te una línea que une conceptos indicando nombre, sentido de la relación, 
(mediante punta de flecha), roles de cada concepto y multiplicidad 7 

 
      * Agregación: Donde 1 o n conceptos son “parte de” otro. Se representa mediante un rombo al 
lado del concepto que representa el agregado, siendo Fuerte si está relleno o débil caso contrario.

       * Generalización: Varios conceptos pueden actuar sustituyendo a otro más genérico, pues son 
especializaciones del concepto que descienden.
• Identificar Atributos: Tomar valores simples, (los complejos los modelamos como conceptos y 
se relacionan mediante asociaciones).

Teniendo todo esto, conseguimos el modelo conceptual que se irá refinando a lo largo del 
desarrollo como podemos apreciar en la ilustración

Glosario: Se irá generando según avanza el desarrollo y conteniendo una descripción textual de 
cualquier elemento evitando ambigüedades.

Diagramas de Secuencia: Permite investigar el 
comportamiento del sistema, mostrando la iteración 
entre actores y el sistema.

Muestra por cada caso de uso los eventos que genere 
el usuario, su orden y los eventos que se 
intercambian entre sistemas Por cada caso de uso se 
realizará un diagrama para curso típico y otro para las 
alternativas de mayor interés.

Se representa el sistema con un cuadrado y una línea 
vertical
debajo, haciendo lo mismo por cada actor identificado, partiendo
del texto del curso típico de eventos, opcionalmente es posible incluir texto al margen a modo de 
comentario.

Todos los mensajes parten del actor y llegan al sistema, careciendo de sentido lo contrario y siendo 
un error. Nunca habrá mensajes entre actores

  

6 Opcional
7 Puede ser un nº fijo, (3); rango, (1..3); asterisco, (2..*) que representa 2 o más y solo asterisco, 
(*), que representa
de 0 a n
  

Contrato de Operaciones: Documento declarativo que describe una operación sin entrar en el 
detalle del como, mediante pre y post condiciones respecto a los cambios de estado.

Tras identificar las operaciones en el diagrama de secuencia, construimos un contrato por cada 
una, especificando el propósito en el apartado de responsabilidades, rellenando las 
postcondiciones y describiendo los cambios de estado de los objetos del modelo conceptual.

Es necesario añadir las asociaciones a los objetos creados.

Diagramas de Estado: Sirven para modelar el comportamiento. Se pueden aplicar a una clase 
software, un concepto, un caso de uso, aunque en el diseño de alto nivel solo se puede aplicar a 
los dos últimos

Muestra la secuencia permitida de eventos externos reconocidos y tratados por el sistema.

El diagrama de estado del sistema, será una combinación de diagramas de estado de todos los 
casos de uso.

Se representa mediante un grafo, cuyos nodos son los estados y los arcos las transiciones con los 
nombres de los eventos. El estado será una caja 1 o 2 compartimentos, en uno aparece el nombre 
y en el otro, (opcional), las acciones de E/S y acciones internas, (ejecuta un evento que no produce 
cambio de estado), representándose como entrada/acción asociada; salida/acción asociada.

Puede representar ciclos continuos o vida finita donde hay ∙pseudoestados” iniciales de creación 8 
y final de destrucción 9. 

  

8 Representado mediante un círculo relleno o sólido
9 Representado mediante un círculo relleno o sólido, rodeado de otro círculo
  

 Fase de Construcción ­ Diseño de Bajo Nivel

El objetivo es la creación de una solución a nivel lógico basado en el conocimiento
adquirido en la etapa anterior.

Las actividades de esta fase son

• Definir Casos de Uso Reales
• Definir Informes e Interfaces de Usuario
• Refinar la Arquitectura del Sistema
• Definir Diagramas de Iteración
• Definir Diagramas de Clases de Diseño (en paralelo)

Casos de Uso Reales: Describe el diseño real del caso de uso con una tecnología concreta de 
implementación y E/S, añadiendo esbozos de la interfaz de usuario. Su formato es similar a un 
caso de uso expandido.

Diagramas de Iteración: Muestra el intercambio de mensajes entre objetos para cumplir las post­
condiciones del contrato. Existen 2 tipos

• Diagramas de Colaboración: con mayor expresividad y mejor acomodo espacial

• Diagramas de Secuencia

Es una de las actividades más importantes, pues se toman decisiones clave acerca del 
funcionamiento del sistema. Se representan, (según notación UML), de la siguiente manera.

Diagramas de Colaboración: muestra objetos entre los que hay enlaces

Clases: caja, en su interior aparecerá el nombre
Objetos: se representa como el anterior, pero el nombre se especifica subrayado precedido de : o 
subrayado como nombre objeto:clase 
Enlaces: línea que muestra la conexión entre 2 objetos por donde se intercambian

mensajes 

Mensajes: Asociado al anterior, contiene el nombre del mensaje, parámetros, dirección a la que va 
dirigida, valor de retorno y tipo. Todos tienen asociado un nº secuencia, (excepto el que representa 
la operación de sistema de inicio del diagrama)

El formato básico puede ampliarse indicando

* Alternativa: Ejecución de uno u otro va en función de una condición, que asociamos a cada 
mensaje entre corchetes a continuación del número de secuencia identificados por letra minúscula 
distinta por alternativa.

* Anidamientos: Muestra número del mensaje con el formato x.y, que indica que la secuencia X, 
no finalizará hasta que no se ejecuten todos los Y.
* Iteraciones: Antepone un asterisco al nº de secuencia, pudiendo añadirse entre corchetes la 
condición para que el bucle permanezca como vemos en la figura También es posible representar 
colecciones de objetos, Los mensajes dirigidos a colecciones de objetos, son recogidos por la 
colección y NO por los objetos que componen la estructura Lo ideal será un diagrama por cada 
operación, definida mediante contratos especificados en etapas anteriores. Las operaciones del 
sistema asociado con cada diagrama será el mensaje inicial, aún así si el mensaje se complica, lo 
mejor es dividirlo.
Partiendo del apartado de responsabilidades 10 y post­condiciones de contrato y de las 
descripciones de los casos de uso, se diseñará un sistema de objetos que interaccionan 

Diagramas de Clases de Diseño: 

Formada por todas las clases (obtenidos de diagramas de colaboración y otros con 
responsabilidades específicas), y sus relaciones. Es una especificación de clases software que 
incluye Clases, asociaciones y atributos; Interfaces con operaciones y constantes; métodos; 
navegabilidad y dependencias.

Cuando una clase conoce a otra por un medio distinto de un atributo, es necesario representarlo 
mediante dependencias, (línea discontinua).

Si un objeto debe conocer a otro para invocar a sus métodos, el primero tiene “visibilidad”sobre el 
segundo, siendo la manera más directa por medio de un atributo.

En un diagrama de clases, tenemos que representar también

• Parámetro: Cuando a un método se le pasa como parámetro un objeto de otra clase, El 1º tiene 
visibilidad de parámetro sobre el 2º, etiquetando dicha relación como <>
• Local: Cuando en un método de una clase, se define una variable local que es objeto de otra 
clase. Se etiqueta como <>

• Global: Variable global del sistema y los métodos de dicha clase utilizan dicha variable. Se 
etiqueta como <>

No es necesario representar una relación de dependencia entre clases, (están relacionadas por 
asociación). Solo se incluye para conocer los elementos a revisar cuando hay cambios en el diseño 
de elementos del sistema.

Para crear un diagrama de clases se necesitan los siguientes pasos:

• Identificar todas las clases mediante diagramas de iteración
• Representarlas en Diagramas de Clases
• Añadir atributos de los conceptos del modelo conceptual y los métodos según el diagrama de 
iteración
• Añadir información del tipo a métodos y atributos.
• Añadir asociaciones para soportar visibilidad, (líneas), añadiendo flechas orientadas
• Añadir relaciones de dependencia, (líneas discontinuas), indicando visibilidad no de atributos

Solo deben mostrarse las clases que tengan interés en cuanto que tengan algún tipo de 
responsabilidad.

No hay una transición directa del modelo conceptual al diagrama de clases de diseño, uno busca la 
comprensión del dominio y el otro la solución software, (añadiendo detalles como el lenguaje de 
programación).
  

10 Responsabilidades son obligaciones de un objeto en cuanto a su comportamiento, no es lo 
mismo que un método, pero estos se implementan para satisfacer las responsabilidades
  

Los atributos y métodos, deben llevar la visibilidad 11 asignada y se incluirán valores por defecto, 
así como detalles de implementación 
  

 Navegabilidad

Es una propiedad que nos indica la posibilidad de “navegar” unidireccionalmente de objetos de la 
clase origen a objetos de la clase destino, implicando visibilidad de atributo en clase origen.

Se implementa mediante una referencia a clase destino en la clase origen.

En los diagramas, las asociaciones deben ser necesarias, de otra manera deberán eliminarse.

Situaciones más comunes:

A envía un mensaje a B
A crea una instancia de B
A necesita una conexión con B

  
 Patrones de Diseño

Son soluciones que se pueden aplicar en un contexto particular, es recurrente, (relevante a otras 
situaciones). Son de gran ayuda pues capturan la experiencia y la hacen accesible a los no 
expertos.

El conjunto de patrones, genera un vocabulario específico, ayudando a los desarrolladores a 
comunicarse mejor, facilitando la reestructuración del sistema.

Con ellos se obtiene una grandísima rehusabilidad.

Existe la siguiente clasificación

• Patrones de Creación: Inicialización y configuración de clases y objetos
• Patrones Estructurales: Tratan de Desacoplar, interfaz e implementación de clases y objetos
• Patrones de Comportamiento: Interacciones dinámicas entre clases y objetos No es aconsejable 
la utilización de variables globales por los efecto colaterales que generan, aunque en ocasiones 
sería interesante clases que solo tuvieran una instancia, (un solo objeto), en donde varios objetos 
de otras clases pueden invocar al método del objeto mencionado siendo accesible de forma global.

Se implementa mediante métodos de clase, (estáticos) y se etiquetan con el estereotipo <>
  

11 + pública # protegida ­ privada
Diseño Orientado A Objetos José Mª Zamora Bausá

Datos del Autor

 Nombre     José Maria Zamora Bausá
 Ubicación  Toledo ­ España

1991 ­ 1994 CARRERA TÉCNICA DE INFORMÁTICA DE GESTIÓN, avalada por la University of 
Cambridge con título de Analista ­ Programador. Escuela De Sistemas Informáticos (E.S.I.)
1994 ­ 1995  MASTER EIDOS PARA DESARROLLADORES
1996 ­ 1997  NANFOR IBERICA . Master en programación C++ bajo Windows 3.x / 95 (Borland C 
++ v. 5)
1997 ­ 1998  KERNELL. Master en programación visual de entornos MS. (Visual Basic, Visual C++, 
Visual J++).
1998              AIG S.L. Formación interna en Oracle y Developer 2000.

Actualmente estoy matriculado en la carrera de ingeniería técnica en
informática de gestión de la Universidad de Educación a Distancia (U.N.E.D.)