Programación Orientada a

Objetos (POO)
1.1. Complejidad del software :
origen y tratamiento

¿qué hacemos mal?, ¿por qué es tan

complejo este sistema o este desarrollo?
la complejidad es una propiedad inherente
al software y no un accidente debido a
una mala gestión o a un mal diseño.
Según Grady Booch, la complejidad en el
software y en su desarrollo se deriva
fundamentalmente de los siguientes
cuatro elementos:
• La complejidad del dominio del problema.
Un proyecto software siempre está salpicado
por la complejidad propia del problema que
pretende resolver. Por ejemplo, el desarrollo de
un software de contabilidad tiene la
complejidad propia del desarrollo, más la
complejidad de las normas y del proceso de
contabilidad.
• La dificultad de gestionar el proceso de
desarrollo. Cuando el desarrollo software que
se realiza tiene miles de líneas de código,
cientos de ficheros, muchos desarrolladores...
el proceso que gestiona todos estos elementos
no es trivial.
• La flexibilidad de las herramientas de
software. Esta flexibilidad es un
obstáculo, ya que permite a los
desarrolladores usar elementos muy
básicos para construir el software desde
cero en vez de usar elementos más
elaborados y probados construidos por
otros. Este hecho se deriva de la poca
confianza que existe en los desarrollos de
otras personas, y de los problemas de
comunicación relativos al traspaso de
software.
• Comportamiento impredecible del
software. El software puede verse como
un sistema discreto, con multitud de
variables que definen su estado en cada
momento. Un pequeño cambio en una de
esas variables puede llevar al sistema a un
estado totalmente diferente. Esto puede
verse como una alta sensibilidad al ruido,
es decir, que un pequeño error (ruido)
puede provocar un comportamiento
totalmente erróneo.
1.1.1 Herramientas para tratar la
complejidad
Descomponer. La descomposición
orientada a algoritmos y la
descomposición orientada a objetos.
• Descomposición algorítmica .El
problema se descompone en tareas más
simples. Luego, cada tarea se
descompone a su vez otras más simples y
así sucesivamente. Por ejemplo, es el
enfoque utilizado al hacer la comida
Básicamente un autómata de estados.
• Descomposición orientada a objetos .

El problema se descompone en objetos de

cuya interacción surge la solución. Cada
objeto a su vez se descompone en más
objetos. Por ejemplo, es el enfoque
utilizado al construir un coche (un coche
funciona como resultado de la interacción
del motor, las ruedas y el chasis; el motor
funciona como resultado de la interacción
de la batería, el carburador y los cilindros;
la batería...).
La descomposición orientada a objetos
tiene varias ventajas cuando se aplica a
proyectos grandes. Para empezar, facilita
una mayor reusabilidad de mecanismos
comunes. Además, al permitir construir
objetos que a su vez agrupan a otros
objetos provee de una mayor economía de
expresión. Se adapta mejor al cambio
porque se basa en formas intermedias
estables que se pueden utilizar de
múltiples maneras.
Por otro lado la descomposición
algorítmica aporta ventajas cuando los
problemas a resolver son pequeños, ya
que es muy sencillo el desarrollo de tareas
concretas.
Abstraer
Para comprender un sistema muy
complejo las personas solemos ignorar los
detalles que nos parecen poco
significativos y solemos concentrarnos en
otros que consideramos esenciales,
construyendo un modelo simplificado del
sistema que se conoce como abstracción.
Por ejemplo, cuando se desea representar
en un mapa los accidentes geográficos de
un país se ignora la división en provincias
o regiones de ese país.
Jerarquizar
Esta técnica de análisis nos permite
ordenar los elementos presentes en un
sistema complejo. Ordenar los elementos
en grupos nos permite descubrir
semejanzas y diferencias que nos guían
luego para comprender la complejidad del
sistema. Por ejemplo, si nos piden
enumerar las provincias Españolas las
citaremos agrupándolas previamente por
comunidades autónomas.
1.1.2 Evolución de los lenguajes de
programación
La primera generación de lenguajes de
programación aparece entre los años 1954
y 1958. En aquella época aparecieron
Fortran (Formula Translator de la mano
de J. W. Backus), ALGOL, FlowMatic e
IPL V. Esta primera etapa se caracteriza
por programas muy lineales, con una sola
línea principal de ejecución, y por una
clara orientación hacia ingenieros y
científicos.
En la segunda generación (1959 – 1961)
aparecen Fortran II y Cobol (Common
Business Oriented Language ). Este
último tuvo un alto arraigo en el mundo
empresarial al que iba dirigido. Además,
aparece Lisp (List Processing creado en el
MIT por J. McCarthy y otros) orientado a
los problemas de inteligencia artificial y
que tuvo un gran impacto en multitud de
lenguajes posteriores. En todos estos
lenguajes, ya existe separación entre
datos y programa.
La tercera generación (1962 – 1975) es
muy prolífica. Entre la multitud de
lenguajes que aparecen podemos destacar
Pascal, C y Simula. En esta etapa
aparecen conceptos como el de
programación estructurada y el de
abstracción de datos. La programación
estructurada se basa en un teorema de
Dijkstra que demuestra que cualquier
programa de ordenador puede escribirse
con un lenguaje que permita la ejecución
secuencial de instrucciones, la instrucción
condicional y la realización de bucles de
instrucciones. Las abstracciones de datos
consisten en la definición de tipos complejos
de datos y su asociación a operadores para
tratarlos. Estas abstracciones permiten que se
puedan abordar programas más complejos. Sin
embargo, estos lenguajes aún no formalizan
mecanismos de protección adecuados para
evitar violaciones en los protocolos de acceso a
los datos. Tampoco añaden ningún mecanismo
de reutilización de código distinto a las
bibliotecas de funciones.
En la etapa que comprende desde el año
1976 hasta 1980 los lenguajes de la etapa
anterior evolucionan y se estandarizan.

Aparecen además lenguajes funcionales

como los de la familia ML, y lenguajes
lógicos como Prolog.
En las décadas de 1980 y 1990 aparecen
los lenguajes orientados a objetos como
SmallTalk, C++ y Java. Estos lenguajes
están especialmente diseñados para
adaptarse a la descomposición orientada a
objetos. Para ello, existen mecanismos
que permiten restringir el acceso a los
datos que forman parte de los objetos. Es
responsabilidad de cada objeto el
mantenimiento de sus datos, y el resto de
objetos que interaccionan con él lo hace a
través de una interfaz bien definida.
También aparece en estos lenguajes el
mecanismo de herencia que permite la
reutilización de código de una manera
controlada.
Casi todos los lenguajes evolucionan
desde sus orígenes. Por ejemplo, las
versiones más actuales de Cobol, Fortran
y Pascal incorporan características de
orientación a objetos.
1.1.3 Paradigmas de programación

Un paradigma de programación es un
modelo conceptual para desarrollar
programas. El uso de un paradigma se
refuerza por el lenguaje que se escoja
para realizar un programa concreto,
aunque en general, con mayor o menor
dificultad, se puede usar cualquier
lenguaje de programación para seguir
cualquier paradigma. Grady Booch cita
diferentes paradigmas:
• Orientado al procedimiento. Que se expresa
de manera imperativa en forma de algoritmos.
Por ejemplo C y Fortran.
• Orientado a funciones. Se basa en el
concepto matemático de función y se expresa
de manera declarativa. Por ejemplo Lisp, SML,
Hope, Hasckel.
• Orientado a la lógica. Que se expresa por
metas en forma de cálculo de predicados.
Utilizan reglas e inferencia lógica. Por ejemplo
Prolog.
• Orientado a objetos. Se expresa en forma de
relaciones entre objetos y responsabilidades de
cada uno. Por ejemplo SmallTalk o Java.
Cada uno de estos paradigmas tiene
ciertas ventajas. Así, el paradigma
procedimental aporta ventajas cuando son
tareas sencillas que se pueden describir
con unos pocos pasos, o cuando es
importante optimizar la velocidad de
ejecución. El uso del paradigma orientado
a la lógica facilita la implementación de
sistemas expertos en los que se deba
manejar una base de conocimiento. El
paradigma funcional permite construir
programas concisos, fáciles de probar y
paralelizar, lo cual es muy adecuado para
la prueba matemática de algoritmos y para
programas en los que se requiera un alto
grado de fiabilidad. El paradigma de
Programación Orientada a Objetos está
demostrando su utilidad en una amplia
variedad de problemas (interfaces gráficas,
simuladores, aplicaciones ofimáticas,
juegos...). Además, está demostrando que
puede ser un marco de alto nivel ideal para
integrar sistemas desarrollados siguiendo
diferentes paradigmas.
1.2. Programación orientada a objetos
Objeto. Un objeto es algo a lo que se le
puede enviar mensajes y que puede
responder a los mismos y que tiene un
estado, un comportamiento bien
definido y una identidad. El estado de
un objeto está definido por el valor de
ciertas variables internas al objeto. Este
estado puede cambiar dependiendo de los
mensajes que reciba desde el exterior o de
un cambio interno al propio objeto. El
comportamiento de un objeto varía en
función del estado en el que se encuentra,
y se percibe por los valores que devuelve
ante los mensajes que recibe y por los
cambios que produce en los objetos con
los que se relaciona. Finalmente, la
identidad de un objeto es aquello que lo
hace distinguible de otros objetos.
La Programación Orientada a Objetos: es
un método de desarrollo en el cual los
programas se organizan como colecciones de
objetos que cooperan para resolver un
problema. En general los objetos pueden
corresponderse a entidades del mundo real
(como un coche o un gato), a acciones (como
saltar o realizar una transacción bancaria) o a
procesos (como el vuelo o el aprendizaje).
La Programación Orientada a Objetos se basa
en el Modelo de Objetos. Este modelo se
fundamenta en el uso de 7 capacidades, 4 de
las cuales que se consideran principales y 3
secundarias. Los lenguajes de programación
orientados a objetos se caracterizan
porque proporcionan mecanismos que
dan soporte a estas capacidades.
Las capacidades principales son:
• Abstraer.
• Encapsular.
• Modularizar.
• Jerarquizar.
Las capacidades secundarias son:
• Tipo.
• Concurrencia y persistencia.
Lenguaje Unificado de Modelado
(Unified Modeling Language - UML )
UML es un lenguaje gráfico para
visualizar, especificar, construir y
documentar los artefactos de un sistema
software orientado a objetos.
1.2.1 Abstraer
Abstraer es la capacidad que permite distinguir
aquellas características fundamentales de un
objeto que lo hacen diferente del resto, y que
proporcionan límites conceptuales bien
definidos relativos a la perspectiva del que lo
visualiza. La abstracción surge de reconocer
las similitudes entre objetos, situaciones o
procesos en el mundo real, y la decisión de
concentrarse en esas similitudes e ignorar las
diferencias. Así, una abstracción se focaliza
sobre una posible vista, ayudando a separar el
comportamiento esencial de un objeto de su
implementación.
Los lenguajes de programación
orientados a objetos facilitan abstraer
gracias a que permiten definir interfaces
comunes para comunicarse con clases de
objetos. Estas interfaces están
compuestas por los métodos, que son
funciones que pueden aplicarse sobre el
objeto y que pueden verse como los
mensajes que es posible enviar al objeto.
Normalmente un objeto puede tener
varias interfaces, permiten concentrarnos
en ciertos aspectos y obviar el resto.
En algunos lenguajes de programación
orientados a objetos (como C++ o Java)
aparece el concepto de clase de objetos o
simplemente clase que une las interfaces
definidas en el proceso de abstracción con
la implementación del comportamiento
deseado. Otros lenguajes (como
SmallTalk o JavaScript) no permiten
definir clases de objetos, sino que se
basan en el concepto de prototipos (todo
objeto es un prototipo a partir del cual se
puede crear otro).
Las clases añaden a la definición de
métodos la implementación de los
mismos. También añaden las
propiedades, que son variables internas
al objeto o a la clase que definen el estado
del objeto. Así, los objetos que hay en un
sistema siempre pertenecen a una
determinada clase, la cual define su
comportamiento, la forma de
interaccionar con él y sus posibles
estados. Métodos y propiedades también
se conocen como miembros.
Entre los objetos se crea un
comportamiento cliente/servidor, de
forma que el cliente conoce el
comportamiento de una abstracción
servidora analizando los servicios que
presta. Estos servicios forman un
contrato que establece las
responsabilidades de un objeto respecto a
las operaciones que puede realizar. El
orden en que se deben aplicar las
operaciones se conoce como protocolo, y
pueden implicar precondiciones
y poscondiciones que deben ser
satisfechas. Cuando al enviar un mensaje
a un objeto se cumplen las precondiciones
pero el objeto no puede cumplir las
poscondiciones se produce una
excepción. Los lenguajes orientados a
objetos también suelen dar soporte al
manejo de excepciones.
 Definición

La Programación Orientada a Objetos (Object Oriented

Programming) es una técnica de programación que establece
una unión muy estrecha entre algoritmos y datos.

Algoritmos + Datos = Objetos

 Características
Las características principales de los objetos son:
Encapsulación: combinación en una sola estructura los
datos, procedimientos y funciones que los manipulan para
formar un nuevo tipo - el objeto.
Herencia: Definición de un objeto y luego uso del mismo
para construir una jerarquía de objetos descendientes, con
cada descendiente heredando acceso a todo el código y datos
del ancestro.
Polimorfismo: Dada una acción un nombre que es
compartido hacia arriba y abajo en una jerarquía de objetos,
con cada objeto en la jerarquía implementando la acción de
una manera apropiada a sí mismo.
 Mensajes y métodos
•En la programación orientada a objetos, la acción se indica
mediante la transmisión de un mensaje a un agente (un
objeto) responsable de la acción.
•El mensaje tiene codificada la petición de una acción y se
acompaña de cualquier información adicional (argumentos)
necesaria para llevar a cabo la petición.
•El receptor es el agente al cual se envía el mensaje.
•Si el receptor acepta el mensaje, acepta la responsabilidad de
llevar a cabo la acción indicada.
•En respuesta a un mensaje, el receptor ejecutará algún
método para satisfacer la petición.
 Diferencia entre mensajes y
procedimientos
La distinción entre el paso de mensajes y la llamada a
procedimiento es que, en el paso de mensaje, hay un receptor
designado, y la interpretación – es decir, la selección del método
que se ejecutará como respuesta al mensaje – puede diferir con
receptores diferentes.
Por lo general, el receptor específico para cualquier mensaje no
se conoce sino hasta el tiempo de ejecución, por lo que la
determinación del método que se debe invocar no puede hacerse
sino hasta entonces.
 Clases y ejemplares

•Todos los objetos son ejemplares de una clase.

•El método invocado por un objeto en respuesta a un mensaje
queda determinado por la clase del receptor.
•Todos los objetos de una clase dada usan el mismo método
en respuesta a mensajes similares.
 Herencia

•Las clases se pueden organizar en una estructura de herencia

jerárquica.
•Una subclase heredará atributos de una superclase que esté
más arriba en el árbol.
•Una superclase abstracta es una clase (como mamífero) que
se usa sólo para crear subclases y para la cual no hay
ejemplares directos.
 Ejemplo de herencia
Objeto material

Animal Planta

Mamífero Flor

Perro Humano Ornitorrinco

Comerciante Artista Dentista

Florista

Relámpago Flo Beth Ken Pepe flores de la abuela

 Enlace de métodos
•La búsqueda para encontrar un método que pueda invocarse
en respuesta a un mensaje dado empieza con la clase del
receptor.
•Si no se encuentra un método apropiado, se lleva la
búsqueda a la superclase de dicha clase.
•La búsqueda continúa hacia arriba de la cadena de la
superclase hasta que se encuentra un método o se agota la
cadena de la superclase.
•En el primer caso el método se ejecuta; en el último caso, se
emite un mensaje de error.
Encapsular
Encapsular es la capacidad que
permite mantener oculta la
implementación de una abstracción
para los usuarios de la misma. El
objetivo de encapsular es la de ocultar la
implementación, para que ninguna parte
de un sistema complejo dependa de
cómo se ha implementado otra parte. La
abstracción y la encapsulación son
complementarias.
Mientras que la primera se centra en el
comportamiento observable, la segunda
lo hace en cómo se construye ese
comportamiento. Así, la abstracción
define la interfaz y la encapsulación se
encarga de los detalles de la
implementación. Para forzar esta útil
separación entre abstracción e
implementación, entre la definición de la
interfaz y la implementación de una
abstracción se dice que existe la barrera
de la abstracción.
La principal ventaja de la encapsulación
está en que facilita que al cambiar el
funcionamiento interno de una
abstracción, los clientes de la misma no
lo noten. Para facilitar la ocultación los
lenguajes orientados a objetos ofrecen
ciertos mecanismos, como los
modificadores de visibilidad public,
private y protected de C++ y Java.
Estos modificadores permiten que se
pueda acceder libremente a unas partes
de la interfaz (que son públicas), acceder
con restricciones a otras partes (que son
protegidas), y que se prohíba el acceso a
otras partes (que son privadas).
Notación UML(Diagramas Estáticos
Clases) modificadores de visibilidad.
Éstos se disponen precediendo a los
métodos y a las propiedades, mediante
los caracteres + , - y # para público,
privado y protegido respectivamente.
Jerarquizar
En cualquier problema simple se
encuentran más abstracciones de las que
una persona puede usar a la vez en un
razonamiento. Los conjuntos de
abstracciones a menudo forman
jerarquías y su identificación permite
simplificar la comprensión del problema.
Jerarquizar es una capacidad que
permite ordenar abstracciones.
Su principal ventaja consiste en que la
organización de las abstracciones de un
sistema en una jerarquía permite detectar
estructuras y comportamientos comunes
y con ello simplificar el desarrollo.
En el esquema de Programación
Orientada a Objetos se definen dos
formas básicas de jerarquías:
• Jerarquías entre clases e interfaces.
• Jerarquías entre objetos.
Jerarquía entre clases e interfaces
Definen relaciones que se denominan
relaciones de herencia y cumplen que
los elementos de los que se hereda son
más generales, mientras que los que
elementos que heredan están más
especializados.
Un ejemplo lo podríamos encontrar en la
clase Coche y en una clase derivada
Deportivo. Los objetos de la clase
Deportivo compartirían el
comportamiento de los de la clase
Coche, pero además los objetos de la
clase Deportivo añadirían ciertas
interfaces y comportamientos nuevos. La
clase Deportivo sería una especialización
de la clase Coche.
Por ejemplo, los objetos de la clase
Deportivo podrían tener la propiedad
turbo, pero un Coche en general no
tendría por qué tener turbo. Además, la
clase Deportivo podría redefinir el
método acelerar, para dotarlo de
diferentes características mediante una
implementación diferente. Obsérvese
que todo Deportivo sería un Coche, pero
no todo Coche sería un Deportivo.
Herencia entre interfaces. Ya se ha
dicho que las interfaces no contienen
implementación ni propiedades, sólo
definen métodos. Por eso, cuando una
interfaz hereda de otra lo que obtiene es
precisamente la declaración de sus
métodos.
Herencia entre clase e interfaz. Cuando
una clase hereda de una interfaz se dice
que tal clase implementa o que cumple
tal interfaz.
Nuevamente, como las interfaces no
contienen implementación sólo se hereda
la definición de métodos, siendo
responsabilidad de la clase que hereda
implementar el comportamiento.
Herencia entre clases. La herencia de
clases se produce cuando una clase
hereda tanto la interfaz como el
comportamiento de otra clase. Por
ejemplo, cuando en Java se define una
clase B que hereda de otra A, la clase B
tiene todos los métodos y todas las
propiedades que en A se definieron como
públicas o protegidas. Además, cualquier
llamada a un método M de la clase B se
comportará exactamente como lo haría sobre un
objeto de la clase A, salvo que explícitamente se
modifique su comportamiento en B. Tras
heredar siempre se pueden añadir nuevos
métodos a la interfaz que hereda para
especializarla en algún aspecto. Además, en el
caso de que la que hereda sea una clase, y no
una interfaz, también se pueden añadir nuevas
propiedades.
Por otro lado, la herencia puede clasificarse en
dos grupos atendiendo a la forma de las
jerarquías: herencia simple y herencia
múltiple.
Herencia simple. Cuando un elemento sólo
hereda de una jerarquía. En la práctica esto
ocurre cuando una clase o interfaz hereda sólo
de otra y no lo hace de varias simultáneamente.
Herencia múltiple. Cuando una clase o
interfaz hereda simultáneamente de varias
jerarquías diferentes. La herencia múltiple de
clases da lugar a lo que se conoce como el
problema de la ambigüedad. Este problema
aparece cuando una clase hereda de varias
que tienen un método de idéntico nombre y
parámetros pero que tiene definidos
comportamientos diferentes en cada clase.
Jerarquía entre objetos
Las jerarquías entre objetos se pueden
clasificar en 2 tipos de relaciones: relaciones
de asociación y relaciones de
dependencia.
Las relaciones de asociación. Establecen
relaciones estructurales entre objetos de
forma que se establece una conexión entre
ellos. Fundamentalmente, este tipo de
relaciones permite construir objetos
mediante la asociación de otros objetos
menores.
Un ejemplo lo podemos encontrar en la
relación entre los objetos de la clase Coche y
los objetos de la clase Rueda, si definimos
que un objeto de la clase Coche posee cuatro
objetos de la clase Rueda. Los lenguajes
orientados a objetos facilitan las relaciones de
asociación permitiendo que cualquier clase se
pueda utilizar para definir una propiedad
dentro otra clase.
Las relaciones de dependencia. Dan lugar a
relaciones del tipo “tal objeto usa tal otro
objeto” por lo que también se conocen como
Estas relaciones se distinguen de las de
asociación porque el ámbito y el tiempo de
uso de un objeto desde otro es más limitado.
Los lenguajes orientados a objetos facilitan
las relaciones de dependencia permitiendo
que un método pueda utilizar un objeto de
manera local.
Por otro lado, las relaciones de asociación
entre objetos se representan mediante líneas
simples que unen las cajas de las clases.
Sobre estas líneas se pueden indicar las
cardinalidades, es decir, las proporciones en
las que intervienen los elementos de la
asociación. Un ejemplo puede ser:
Obsérvese que las relaciones de asociación
también se pueden representar como
propiedades. Suele hacerse así cuando el
diseño de una de las clases de la asociación
no tiene importancia en ese contexto. En
estos casos, el nombre del objeto menor se
añade como una propiedad de la clase que se
está explicando. Por ejemplo, en la clase
Coche, existe una asociación entre la clase
Coche y la clase Texto, pero se considera de
menos importancia que la asociación entre
Coche y Rueda,
quizás porque la clase Texto es muy común,
y por ello se presenta de manera abreviada.
Finalmente, las relaciones de uso se
representan mediante líneas punteadas con
punta de flecha, indicando el sentido de la
dependencia.
También se suelen utilizar diagramas que
presentan instancias de objetos mediante
cajas y las relaciones que hay entre ellos en
un momento de la ejecución mediante líneas.
Estos diagramas se denominan Diagramas
de Instancias . En el interior de las cajas se
presenta el nombre de la clase precedida por
el carácter dos puntos. Opcionalmente se
puede presentar el nombre de la instancia, en
cuyo caso debe aparecer subrayado y antes
del nombre de la clase. Finalmente, bajo el
nombre de la clase puede presentarse el valor
de la propiedades de la clase para esa
instancia.
Modularizar
Modularizar es la capacidad que permite
dividir un programa en agrupaciones
lógicas de sentencias. A estas agrupaciones
se les llama módulos.
Las ventajas que ofrece la modularidad son:
• Facilidad de mantenimiento, diseño y
revisión. Al dividir el programa se facilita
que varias personas pueden desarrollar de
manera simultánea e independiente
conjuntos de módulos.
• Aumento de la velocidad de compilación.
Los compiladores suelen compilar por
módulos. Esto significa que el cambio de un
módulo sólo implica la recompilación del
módulo y de los que dependan de él, pero no
la del total de módulos.
• Mejora en la organización y en la
reusabilidad, ya que es más fácil localizar
las abstracciones similares si se encuentran
agrupadas de una manera lógica.
A la hora de diseñar los módulos debe tenerse en
cuenta:
•Maximizar la coherencia, es decir, se deben
agrupar en un mismo módulo las abstracciones
relacionadas lógicamente.
•Minimizar las dependencias entre módulos, es
decir, que para compilar un módulo no se necesite
compilar muchos otros.
•Controlar el tamaño de los módulos. Módulos
pequeños aumentan la desorganización, módulos
muy grandes son menos manejables y aumentan
los tiempos de compilación.
En C++ y en Java el concepto de módulo
encuentra soporte a varios niveles. Al menor
nivel cada módulo corresponde a un archivo.
Así, los archivos se pueden escribir y compilar
de manera separada. Las bibliotecas aportan un
segundo nivel de modularidad a C++. Mientras,
en lenguajes como Java, se ha creado el
concepto de paquete que permite un número
ilimitado de niveles de modularidad. También
suele utilizarse el concepto de componente y de
programa como módulos que tienen una
funcionalidad completa e independiente.
Notación UML
En UML los paquetes se representan en los
Diagramas de Paquetes mediante unos
rectángulos que se asemejan a carpetas. Estas
carpetas se etiquetan con el nombre del paquete.
Los componentes y los programas se
representan utilizando unas cajas con dos cajas
en su interior. Ejemplo: Obsérvese que entre
paquetes se pueden dar relaciones de
asociación y dependencia.
Ejercicio 1
Supónga que un banco desea instalar cajeros
automáticos para que sus clientes puedan sacar e
ingresar dinero mediante una tarjeta de débito.
Cada cliente podrá tener más de una cuenta en el
Banco, y por cada cuenta se podrá tener como
máximo una tarjeta; de cada cuenta sólo
interesan los datos del titular de la misma,
estando las tarjetas, en caso de que existan, a
nombre del titular de la cuenta.
Para evitar que las tarjetas extraviadas o robadas
se usen, se decide que antes de entregar el
dinero del cajero debe verificar mediante una
contraseña la identidad del propietario de la
cuenta. Sólo se permiten tres intentos para
introducir la clave correcta, si no se consigue se
invalida la tarjeta.
Para aumentar la seguridad, el Banco propone
que se fije una cantidad máxima de dinero que
pueda sacarse cada día.
El banco desea que más tarde sea posible añadir
nuevas operaciones al cajero como: consultar el
saldo, comprar entradas de teatro, etc.
Usando el paradigma de orientación a objetos y
el lenguaje UML se pide construir un Diagrama
Estático de Clases que pueda representar una
solución al enunciado. Además se pide realizar
una aplicación en lenguaje Java que implemente
dicha solución.
Tipo
Un tipo es una caracterización precisa asociada a
un conjunto de objetos. “El concepto de tipo
proviene directamente de la Teoría de Tipos
Abstractos. Según ésta un Tipo Abstracto de Datos
es la estructura resultante de la unión de un
dominio para ciertos datos y de una colección de
operaciones que actúan sobre esos datos”.
En Programación Orientada a Objetos, los objetos que
comparten una misma interfaz se dice que tienen el
mismo tipo. También se dice que el tipo de un objeto
B deriva del de otro A cuando la interfaz de B es un
superconjunto de la de A. La asociación del tipo a un
objeto se conoce como tipado.
Los lenguajes pueden clasificarse en dos
grupos respecto a las restricciones que
impone el tipo:
• Lenguajes con tipado fuerte, en los que
no es posible mezclar variables de tipos
diferentes.
• Lenguajes con tipado débil, en los que es
posible mezclar variables de diferentes tipos.
Esta mezcla puede realizarse de manera
implícita o explícita mediante coerción. La
coerción fuerza al compilador a tratar un
dato de un tipo como si fuese de otro tipo.
El tipado fuerte evita los errores que se
pueden cometer al mezclar abstracciones de
una manera no prevista en el diseño.
Por ejemplo, puede evitar que se comparen
directamente dos precios si están en
monedas diferentes (como dólares y euros).
También acelera los intérpretes y los
compiladores, pues al ser más estricta la
sintaxis el número de posibilidades a
analizar es menor.
Además, Java impide violar el tipo de un
objeto enviándole mensajes para los que no
está preparado.
Por otro lado, dependiendo de la forma en
que se declaran las variables se puede hablar
de:
• Tipado explicito, cuando antes de utilizar
una variable debe declararse el tipo al que
pertenece.
• Tipado implícito, cuando las variables no
se les indica el tipo, sino que éste se deduce
del código.
Por último, en cuanto al momento en que se
comprueba el tipo de una variable, los
lenguajes de programación se pueden
clasificar en:
• Lenguajes con tipado estático, en los que
el tipo se comprueba en compilación.
• Lenguajes con tipado dinámico, en los
que el tipo se comprueba en ejecución. En
los lenguajes de programación orientados a
objetos existe una característica derivada de
la herencia que impide el enlace temprano
en algunas ocasiones.
Esta característica se denomina polimorfismo
y consiste en permitir utilizar una misma
variable para designar objetos de clases
diferentes pero que cumplan la misma
interfaz. El polimorfismo puede impedir que
se sepa en compilación a qué método de qué
clase se debe llamar. Por lo que se debe realizar
la comprobación de tipo en ejecución y realizar
un enlace tardío. Cuando en compilación se
puede determinar la dirección del método se
habla de polimorfismo estático, y cuando sólo
es posible determinarla en ejecución se habla
de polimorfismo dinámico.
Notación UML
En UML el tipo aparece como nombre de
cada clase o interfaz. También suele seguir a
cualquier identificador que aparezca en un
diagrama, separado del mismo por el
símbolo de dos puntos.
Concurrencia
La concurrencia es la capacidad que
permite la ejecución paralela de varias
secuencias de instrucciones. Hay
problemas que se resuelven más fácilmente
si se dispone de esta capacidad. Por ejemplo,
hay ocasiones en las que se dispone de
múltiples procesadores y se desea
aprovecharlos a todos a la vez para resolver
un mismo problema. Otros problemas
requieren que se puedan tratar diversos
eventos simultáneamente.
Clásicamente los lenguajes de programación
no han dado ningún soporte a la
concurrencia. Generalmente, esta facilidad
es proporcionada por los sistemas
operativos. Por ejemplo, en Unix la
concurrencia se consigue con la invocación
de una función del sistema operativo
llamada fork que divide la línea de
ejecución, creando múltiples líneas de
ejecución (también conocidas como hilos o
threads ).
Los lenguajes orientados a objetos pueden
dar soporte a la concurrencia de una manera
natural haciendo que un objeto se pueda
ejecutar en un thread separado. A tales
objetos se les llama objetos activos frente a
los pasivos que no se ejecutan en threads
separados. Esta forma de tratamiento ayuda
a ocultar la concurrencia a altos niveles de
abstracción. Sin embargo, los problemas
clásicos de la concurrencia persisten.
Java es un ejemplo de lenguaje que da
soporte a la concurrencia creando hilos al
crear ciertos objetos, aunque en el caso de
Java el hilo puede ejecutar luego código que
esté en otros objetos.
Persistencia
La persistencia es la capacidad que
permite que la existencia de los datos
trascienda en el tiempo y en el espacio.
Podemos clasificar los datos en relación a su
vida según los siguientes 6 tipos:
•Expresiones. Cuya vida no supera el
ámbito de una línea de código.
•Variables locales. Cuya vida se
circunscribe a la vida de una función.
•Variables globales. Que existen mientras
se ejecuta un programa.
•Datos que persisten de una ejecución a
otra.
•Datos que sobreviven a una versión de
un programa.
•Datos que sobreviven cuando ya no
existen los programas, los sistemas
operativos e incluso los ordenadores en los
que fueron creados. Los tres primeros
puntos entran dentro del soporte dado
clásicamente por los lenguajes de
programación.
Los tres últimos puntos no suelen estar soportados
por los lenguajes de programación, entrando en el
ámbito de las bases de datos. Un lenguaje
orientado a objetos que dé soporte para la
persistencia debería permitir grabar los objetos
que existan, así como la definición de sus clases,
de manera que puedan cargarse más adelante sin
ambigüedad, incluso en otro programa distinto al
que lo ha creado. Java da cierto nivel de soporte a
la persistencia de una clase si ésta cumple la
interfaz predefinida Serializable. Esta interfaz
define métodos que permiten almacenar los
Las clases en Java
Las clases son el mecanismo básico que
proporciona Java para manejar el concepto
de abstracción y de tipado. Java permite
construir clases que definan la interfaz y la
implementación de los objetos que
posteriormente se podrán crear. Así, cada clase
define una interfaz y un tipo (o varios tipos en el
caso de las clases parametrizadas). Las clases en
Java están constituidas por:
•Identificación. La primera línea de una clase
identifica el nombre de la clase, las clases de las
que hereda, las interfaces que implementa, las
excepciones que puede lanzar y los parámetros
utilizados para referir tipos.
•Miembros. Se pueden clasificar en datos miembros y
funciones miembros, también conocidos como
propiedades y métodos, Cabe decir que en Java tanto
las propiedades como los métodos pueden
corresponder a instancias de la clase (objetos) o a la
propia clase (con valores y comportamientos comunes
para todos los objetos de la clase).
•Clases internas. Clases que se definen dentro de
otras clases. Normalmente se utilizan para crear clases
fuertemente ligadas con la clase huésped.
Estas clases internas pueden incluso ser anónimas,
derivando de otra que le proporciona una interfaz con
el resto del código.
•Bloques de inicialización. Conjuntos de
instrucciones encargadas de iniciar las propiedades de
la clase. Java se encarga de que estos bloques se
ejecuten convenientemente antes de crear los objetos
de la clase.
Los siguientes ejemplos definen la clase Automóvil y
la clase Coche. Ambos tienen definidas algunas
propiedades y métodos. Obsérvese que la clase Coche
hereda de Automóvil, y por lo tanto, aunque no los
declara explícitamente, tiene los miembros definidos
en Automóvil más los que ella misma define.
/**
* Ejemplo de implementación de una clase
* @version 1.0
*/
class Automóvil {
int velocidad; //Declaración de una propiedad
// Ejemplo de declaración e implementación de un método
/** Método que permite conocer la velocidad actual
* @return Entero con la velocidad
*/
int velocidad() {
//Implementación del método
return velocidad;
}
}
/**
* Declaración de una clase que hereda de la clase Automovil
* @version 1.0
*/
class Coche extends Automóvil {
boolean enMarcha; //Indica si el coche está en marcha
int numRuedas = 4; //Cuenta las ruedas del coche
/** Método que permite aumentar la velocidad
* @param incremento Valor entero que se sumará a la
*velocidad
*/
void acelerar(int incremento) {
velocidad += incremento;
enMarcha = true;
}
/**
* Permite reducir la velocidad
*/
void frenar() {
if (enMarcha)
velocidad --;
if (velocidad == 0)
enMarcha = false;
}
}