FUNDAMENTOS DE

INFORMTICA

PRCTICA
CURSO 2016/2017
 Contenido
1 INTRODUCCIN .................................................................................................................................................... 5

2 DESCRIPCIN DE LA PRCTICA....................................................................................................................... 5

3 ETAPA 1 .................................................................................................................................................................. 6

3.1 ETAPA 1.1: ORIENTACIN A OBJETOS ...................................................................................................... 6

3.1.1 OBJETIVOS ......................................................................................................................................... 6

3.1.2 REQUISITOS PREVIOS ................................................................................................................... 6

3.1.3 ENUNCIADO: CREACIN DE UNA CLASE SENSOR ...................................................................... 6

3.2 ETAPA 1.2: EJECUCIN DE APLICACIONES.............................................................................................. 8

3.2.1 OBJETIVOS ......................................................................................................................................... 8

3.2.2 REQUISITOS PREVIOS ................................................................................................................... 9

3.2.3 ENUNCIADO: JAVA, BLUEJ Y EL MTODO MAIN ............................................................ 9

4 ETAPA 2 ................................................................................................................................................................ 10

4.1 ETAPA 2.1: USO DE LA COMPOSICIN .................................................................................................... 10

4.1.1 OBJETIVOS ....................................................................................................................................... 10

4.1.2 REQUISITOS PREVIOS ................................................................................................................. 10

4.1.3 ENUNCIADO: CREACIN DE LAS CLASES ROBOT Y PEDIDO .................................. 11

4.2 ETAPA 2.2: USO BSICO DE LA HERENCIA Y EL POLIMORFISMO ................................................... 12

4.2.1 OBJETIVOS ....................................................................................................................................... 12

4.2.2 REQUISITOS PREVIOS ................................................................................................................. 12

4.2.3 ENUNCIADO: AADIENDO NUEVOS TIPOS DE SENSORES A UN ROBOT ........... 12

5 ETAPA 3 ................................................................................................................................................................ 14

5.1 ETAPA 3.1: USO AVANZADO DE LA HERENCIA Y POLIMORFISMO ................................... 14

5.1.1 OBJETIVOS ....................................................................................................................................... 14

5.1.2 REQUISITOS PREVIOS ................................................................................................................. 14

5.1.3 ENUNCIADO: AADIENDO NUEVOS TIPOS DE SENSORES CON

RESTRICCIONES ............................................................................................................................................. 14

5.2 ETAPA 3.2: COMPLETANDO EL SISTEMA .............................................................................................. 15

5.2.1 OBJETIVOS ....................................................................................................................................... 15

5.2.2 REQUISITOS PREVIOS ................................................................................................................. 15

5.2.3 ENUNCIADO: FACTURANDO SEGN TIPO DE CLIENTE ............................................. 15

2
6 Fechas y Normas de Entrega .................................................................................................................................. 16

6.1 Fechas ............................................................................................................................................................... 16

7 Normas de Entrega ................................................................................................................................................. 16

7.1 Evaluacin de la prctica .................................................................................................................................. 17

7.2 Preguntas al Equipo Docente ............................................................................................................................ 17

4
1 INTRODUCCIN

Esta prctica la realizaremos en Java, un lenguaje orientado a objetos. El primer concepto que se debe conocer para
programar dentro del paradigma de la orientacin a objetos es el de 'objeto'. En este paradigma todo est basado en los
objetos, que toman vida cuando nuestro programa est en ejecucin; por tanto, un programa Java se organizar en
objetos que adems podrn relacionarse de diferentes maneras entre s.

Las relaciones entre objetos proporcionan al programador las funcionalidades necesarias para resolver una amplia gama
de problemas. La definicin de un objeto viene dada por lo que se conoce como 'clase', que es lo que modelaremos y
programaremos, aquello que escribiremos definiendo campos y mtodos. Estos campos y mtodos nos permitirn aadir
funcionalidad a la clase y, una vez definida, ya podremos crear objetos (o instancias de clase) que son los que existirn
cuando nuestro programa se ejecute.

Por tanto, podemos ver los objetos como los componentes que nos servirn para disear nuestro programa, y las clases
como las definiciones de dichos objetos. Una misma clase puede, por tanto, dar lugar a muchos objetos diferentes, cada
uno de ellos con caractersticas diferentes que vendrn dadas por los valores de sus campos.

2 DESCRIPCIN DE LA PRCTICA

El objetivo de esta prctica es que el alumno sea capaz de crear un sistema informtico simplificado para la
configuracin y posterior gestin de pedidos de una empresa que comercializa robots educativos. Este tipo de robots se
construye a partir de una plataforma base a la que se le pueden ir aadiendo diferente nmero y tipo de sensores. La
empresa se encarga de configurar los robots para una posterior comercializacin.

La aplicacin que desarrollaremos deber ser capaz de:

- Permitir la configuracin de un robot aadiendo diferentes tipos de sensores segn las necesidades del cliente.

- Gestionar pedidos en los que se pueda incluir ms de un robot, que podrn tener o no una misma
configuracin. Los pedidos debern tambin contener informacin del cliente que los ha solicitado.

Nuestros robots educativos estarn formados por una plataforma base a la que se le podrn ir aadiendo sensores,
aunque en algunos casos con algunas restricciones. Habr sensores que sean incompatibles entre s, es decir, que si se
incluye uno no puede incluirse otro; por ejemplo, este es el caso de los sensores de medicin de distancias. Tambin
habr tipos de sensores que puedan o no incluirse en el robot, pero que en caso de hacerlo solo podr incluirse uno; este
es el caso de, por ejemplo, los sensores que detectan si es de da o de noche. Finalmente habr sensores que podrn
incluirse conjuntamente y en el nmero que desee el cliente; este es el caso de, por ejemplo, sensores de presin para
incluir en diferentes partes del robot, etc.

Durante el proceso de configuracin de un robot, adems de permitir incluir o eliminar sensores dentro de un robot, el
sistema deber poder mostrar por pantalla los sensores instalados y los valores caractersticos de cada uno de ellos.
Permitir tambin acceder a los detalles de un pedido y del cliente para el que se realiza.

La forma de desarrollar la prctica ser partiendo de un enfoque bsico, para ir avanzando progresivamente y de forma
iterativa incluyendo nuevas caractersticas y funcionalidades. Planteamos para ello tres etapas. En cada etapa se partir
inicialmente del diseo y desarrollo de la etapa anterior, pero habr que incluir nuevas funcionalidades, poniendo en
juego los conceptos del temario que se van estudiando progresivamente. Es posible que en determinadas etapas haya
que modificar el diseo previo si ste no cubre la nueva especificacin.

RECOMENDACIN: la prctica se realiza a lo largo del cuatrimestre y forma parte del estudio de la asignatura.
Para cada etapa el tutor indicar las correspondientes fechas de entrega.

Es conveniente hacer una primera lectura completa de este documento para tener una visin global de lo que se
pide, y organizar apropiadamente el estudio de la asignatura.

5
3 ETAPA 1

3.1 ETAPA 1.1: ORIENTACIN A OBJETOS

3.1.1 OBJETIVOS

En la primera etapa de la prctica se van a afianzar los conceptos bsicos de la programacin en Java. Trabajaremos con
las caractersticas fundamentales de clase, objeto, atributos y mtodos (constructores, mtodos que ayudan a la
encapsulacin de la clase y mtodos de visualizacin).

Vemoslo con un ejemplo que nos permita comenzar esta primera etapa de la prctica. En la prctica de este ao vamos
a necesitar considerar informacin de diferentes tipos de sensores; en otras palabras, cada sensor ser un objeto de la
clase correspondiente. Estos componentes tendrn unas caractersticas comunes (atributos), pero cada uno podr ser
diferente si los valores de dichas caractersticas son diferentes.

3.1.2 REQUISITOS PREVIOS

Para la realizacin de esta primera etapa se requiere haber estudiado los temas 4, 5 y 6 del temario detallado de la
asignatura, correspondientes a los captulos 1, 2 y 3, as como los apndices B, C, D y F del libro de referencia de la
Unidad Didctica II.

3.1.3 ENUNCIADO: CREACIN DE UNA CLASE SENSOR

Se desea disear un sistema informtico cuyo fin sea permitir a los clientes elaborar un pedido consistente en un
conjunto de robots educativos, en donde se pueda configurar con diferentes sensores cada uno de los robots. Dentro de
esta primera parte se realizar una aproximacin bsica al modelado inicial de algunos de los elementos del sistema.
Los elementos bsicos de nuestro sistema en este punto del desarrollo sern los sensores con los que se dotar a los
robots. Cada sensor concreto se modela como un objeto y, por tanto, para definir un sensor necesitaremos crear una
clase. Para ello, tendremos en cuenta que un sensor tendr las siguientes caractersticas (campos o atributos):

Nombre del fabricante

Cdigo del fabricante.

Cdigo del sensor.

Descripcin de producto. Ser un texto.

Precio de fbrica.

Adems, todo objeto de la clase Sensor debe permitir consultar y modificar estos campos a travs de una serie de
mtodos creados a tal efecto; por tanto, por cada campo debe haber dos mtodos, uno para consultar su valor y otro para
modificarlo. Por ejemplo, para el campo PrecioFabrica tendramos los mtodos getPrecioFabrica() y
setPrecioFabrica().

Asimismo, deber existir un mtodo llamado printInfo() que presente por pantalla informacin del producto (el nombre
y cdigo del fabricante, el cdigo interno del sensor, la descripcin de producto y el precio de fbrica) con un formato
legible como, por ejemplo, el mostrado en la Figura 1. Se puede hacer uso del mtodo System.out.println() sobre el cul
se puede encontrar informacin en el captulo 2.9 del libro de texto.

6
 Fabricante: <Nombre del fabricante>

Cdigo del Fabricante: <Cdigo del fabricante>

Referencia del sensor: <Cdigo del sensor>

Detalles: <Descripcin de producto>

Precio: <Precio de fbrica>

Figura 1: Formato de salida por pantalla con la informacin bsica de un Sensor.

Los elementos entre '<' y '>' son los valores correspondientes a los campos referidos arriba con dicho nombre.

RECOMENDACIN: Jugar con BlueJ creando sensores, modificando sus datos, escribindolos por pantalla, etc.

Cuntos sensores puedes crear? Cmo puedes acceder a ellos en BlueJ?

7
 3.2 ETAPA 1.2: EJECUCIN DE APLICACIONES

3.2.1 OBJETIVOS

Es importante comprender que Java y BlueJ son cosas diferentes. Java es un lenguaje de programacin, mientras que
BlueJ es un entorno de programacin que nos permite programar en Java. BlueJ est pensado para el aprendizaje de
Java y proporciona distintas herramientas que permiten inspeccionar las partes de un programa, tanto en la parte de
diseo (cuando estamos escribiendo el cdigo), como en la de ejecucin (cuando el cdigo se ejecuta, se crean los
objetos en memoria, etc.)

Una de las herramientas de BlueJ que pueden resultar ms tiles, pero a la vez pueden despistar ms, es el banco de
objetos u object bench (captulo 1 del libro; se muestra un ejemplo en la Figura 2). En conjunto con otras herramientas
como el inspector de objetos, resulta muy interesante para jugar con los objetos en tiempo de ejecucin de forma
interactiva. BlueJ nos permite ejecutar nuestras aplicaciones mediante la invocacin de los mtodos de sus objetos, pero
no es esta la nica manera de hacerlo.

Figura 2: Banco de objetos (recuadrado en verde) en BlueJ

A estas alturas sabemos que cada clase dispone de una serie de mtodos y campos, que son propios de los objetos que
creamos a partir de dicha clase, es decir, que para poderlos utilizar necesitamos crear primero un objeto. Por ejemplo, la
clase Sensor que hemos creado tiene un mtodo para escribir por pantalla su informacin bsica, que slo podr ser
invocado una vez tengamos algn objeto de esta clase. Pues bien, existe otro tipo de mtodos que no son propios de los
objetos, sino de las clases. De esta forma, no necesitamos una instancia particular de la clase (objeto) para invocarlos.

Java, ms all de BlueJ, nos permite ejecutar los programas que creamos de forma independiente. La ejecucin fuera de
BlueJ comienza sin que exista ningn objeto (en BlueJ primero se crean objetos que se almacenan en el banco de
objetos para posteriormente invocar sus mtodos). Antes de tener objetos, lo nico que tenemos son las clases que los
definen, por lo que deberemos usar un mtodo de clase (de los que hablbamos en el prrafo anterior) para poder iniciar
la ejecucin.

Un caso particular de estos mtodos de clase es el mtodo main(), que es el que se utiliza como punto de partida para
iniciar la ejecucin de un programa en Java (vase el apartado 3.2.2).

8
RECOMENDACIN: Al final de este apartado se debera entender la diferencia entre ejecutar un programa en BlueJ
y hacerlo de forma independiente, esto es, por ejemplo, ejecutarlo desde la lnea de comandos (smbolo de sistema en
Windows/Linux/MacOS).

3.2.2 REQUISITOS PREVIOS

Adems de los expuestos en la seccin 3.1.2, debe consultarse el libro de texto, captulo 6.15, sobre mtodos de clase.
En el apndice E del libro de texto puede encontrar ms informacin sobre el mtodo main(), en concreto en el apartado
E1. Puede consultar tambin el captulo 3.9 (Objetos que crean objetos) del libro de texto si necesita ms informacin
acerca de la creacin de objetos desde el cdigo.

3.2.3 ENUNCIADO: JAVA, BLUEJ Y EL MTODO MAIN

Aada un mtodo main(), incluido en una nueva clase llamada Lanzador creada a tal efecto. Dentro de l pruebe a crear
varios objetos del tipo Sensor con diferentes caractersticas y pruebe a acceder a stos mediante los mtodos pertinentes.
Escriba su informacin bsica en pantalla, use los mtodos apropiados para modificar alguno de sus campos y vuelva a
escribir la informacin bsica por pantalla para ver cmo ha cambiado su estado. Ejecute el programa desde BlueJ y
desde la lnea de comandos (consola o smbolo de sistema, segn el sistema operativo que utilice).

IMPORTANTE: La presente prctica debe poderse ejecutar independientemente de BlueJ de cara a su entrega
y correccin.

9
4 ETAPA 2

4.1 ETAPA 2.1: USO DE LA COMPOSICIN

4.1.1 OBJETIVOS

Los objetos pueden contener otros objetos y utilizarlos para realizar distintas tareas. De esta forma, cuando un objeto
contiene otros, hablamos del mecanismo de Composicin. En Java existen adems estructuras de datos que nos
permiten agrupar objetos, como es el caso de las listas, los conjuntos o los mapas. De esta forma si quisiramos
representar una Universidad con personas, podramos, por ejemplo, crear una clase Universidad que tuviera un campo
de tipo de lista de objetos de la clase Persona, como se muestra en la Figura 3. Tendramos as que una Universidad se
compone de personas.

Figura 3: Diagrama de clases correspondiente al ejemplo

de la Universidad (se han omitido los constructores)

No hay que olvidar que, a medida que la aplicacin que estamos construyendo se hace ms grande y compleja, conviene
ir documentando las clases que hemos creado, no slo para que terceras personas puedan comprender su funcionalidad
sin tener que leer minuciosamente el cdigo, sino para que nosotros mismos podamos en el futuro reutilizarlas de una
forma sencilla. Para la generacin de documentacin en Java disponemos de la herramienta Javadoc, que por medio de
determinado tipo de comentarios que podemos incluir en nuestro cdigo, permite la generacin posterior de
documentacin a partir del mismo.

4.1.2 REQUISITOS PREVIOS

Esta etapa requiere haber estudiado los temas 7, 8 y 9 del temario detallado incluido en la gua de estudio de la
asignatura. Encontrar informacin ms detallada sobre el mecanismo de composicin y la generacin de
documentacin en el libro de texto de la asignatura en los captulos 4 y 5. La lectura de las secciones comprendidas
entre la 6.3 y la 6.6 del libro, ambas incluidas, sobre buenas prcticas en el diseo de aplicaciones es tambin
recomendable.

10
 4.1.3 ENUNCIADO: CREACIN DE LAS CLASES ROBOT Y PEDIDO

RECOMENDACIN: leer primero los requisitos completos antes de tomar decisiones acerca de cmo desarrollar la
solucin.

Siguiendo el modelo del ejemplo de la Universidad, en este punto se deber crear una clase Robot que deber cumplir
las siguientes condiciones:

1. Debe poder contener un conjunto de sensores.

2. Deber disponer de un identificador nico que se corresponder con el de la plataforma base sobre la que se
montan los sensores. Esta plataforma base no es necesario modelarla, es decir, asumimos que est incluida en
la propia definicin de robot.

3. Se ha de permitir aadir y eliminar sensores al robot. Se puede tomar el cdigo del sensor como parmetro
para identificarlo.

4. El Robot debe ser capaz de mostrar por pantalla su precio de venta, as como los cdigos de todos los sensores
con los que se ha configurado. El PVP de un robot se calcula aplicando un 85% de beneficio a la suma de los
precios de fbrica de los sensores que contiene.

5. Debe tambin poder mostrar la informacin bsica de los sensores que tiene instalados (para ello se debe
utilizar el mtodo correspondiente creado en la clase Sensor en el apartado 3.1.3).

6. En relacin al tratamiento de errores, se ha de contemplar que un cdigo de sensor no exista (por ejemplo,
cuando se quiera eliminar un sensor de la configuracin del robot) o que no haya sensores para listar porque la
plataforma base no contenga ninguno. Deber gestionarse este tipo de situaciones informando adecuadamente
por pantalla de lo que sucede.

A continuacin, debe crearse una nueva clase Pedido que:

1. Contenga un identificador de pedido.

2. Contenga una lista de robots (los que constituyen un pedido) con sus mtodos correspondientes de insercin y
eliminacin de robots en el pedido.

3. Contenga una direccin de envo.

4. Por simplicidad, no ser necesario modelar una clase Cliente, simplemente deber almacenarse

a. un identificador para cada cliente, as como

b. una fecha (en un formato que incluya hora, minutos y segundos) correspondiente a la de peticin del
pedido.

5. Tenga un mtodo imprimirPedido() que calcule y muestre el precio total del pedido, junto con el precio de
cada robot por separado. El precio total del pedido ser la suma de los PVP de los robots incluidos en l
(descrito anteriormente), pero aplicando una rebaja de un 10% por cada 5 robots hasta un mximo del 50% de
rebaja.

Documente las clases que ha creado hasta ahora. En el apartado 5.10.2 del libro de texto se detalla la mnima
documentacin que se debera incluir.

Escriba dentro del mtodo main() de la clase Lanzador el cdigo necesario para crear un Pedido y aadirle varios robots
(por ejemplo 5), a los que habr que configurar previamente con diferentes sensores (un mnimo de 3 por robot).
Elimine despus algn robot del pedido y presente por pantalla el listado de robots encargados. Para cada robot debe
11
mostrarse su informacin completa y su precio de venta al pblico, as como el precio total del pedido. Se deja a
eleccin del alumno la especificacin de valores para los campos.

4.2 ETAPA 2.2: USO BSICO DE LA HERENCIA Y EL POLIMORFISMO

4.2.1 OBJETIVOS

Hasta ahora hemos modelado un sensor, un robot y un pedido. El siguiente paso dentro de nuestro desarrollo es
considerar diferentes tipos de sensores, para lo que introduciremos un nuevo concepto, la herencia de clases.

Todos los sensores tendrn los campos ya definidos (Nombre del fabricante, Cdigo del fabricante, Cdigo del sensor,
Descripcin de producto y Precio de Fbrica), pero algunos tendrn ahora campos adicionales.

Para este tipo de situaciones, los lenguajes orientados a objetos como Java disponen de un mecanismo llamado
Herencia. La herencia permite construir una nueva clase que herede las caractersticas de una clase existente. Por
tanto, esta clase heredera o hija tiene toda la funcionalidad de la clase de la que hereda (clase padre, siguiendo con
la analoga), permitiendo adems la inclusin de nuevos mtodos y campos para extender dicha funcionalidad. As la
clase resultante ser una extensin de la clase que ya tenamos, que aportar las nuevas funcionalidades que la clase
extendida no tena.

Por otro lado, los sensores tenan un mtodo para mostrar por pantalla los campos y valores correspondientes. Al incluir
nuevos tipos de sensores, en cada uno de ellos deberemos volver a escribir este mtodo para que muestre adems la
informacin particular de ese tipo de componente. Con todo esto, adems de la herencia, estamos haciendo uso de un
mecanismo llamado polimorfismo para que el sistema siga funcionando sin tener que modificar el cdigo que ya
tenamos.

4.2.2 REQUISITOS PREVIOS

Esta etapa requiere haber estudiado los captulos del libro base de las etapas anteriores, as como los temas 10, 11 y 12
del temario detallado de la asignatura, correspondientes a las Secciones de la 6.3 a la 6.6, y los Captulos 7, 8 y 9 del
libro base para la Unidad Didctica II. En concreto la seccin 8.7.4 y relacionadas; y el captulo 9; particularmente el
apartado 9.6 y relacionados, resultarn tiles en la resolucin de esta etapa.

4.2.3 ENUNCIADO: AADIENDO NUEVOS TIPOS DE SENSORES A UN ROBOT

Hasta ahora en nuestro sistema slo se ha modelado un nico tipo de sensor. Ahora se desea poder incluir los siguientes
nuevos tipos con las caractersticas siguientes:

Sensores LDR, que mayoritariamente se aplican para detectar si es de da o de noche y encender el sistema de
iluminacin del robot, pudiendo tener dos niveles de sensibilidad: baja y alta.

Sensores de presin, que se utilizan como medidores de fuerza y que debern tener un valor mximo de
deteccin medido en N/mm2.

Sensores de ultrasonido, que permiten calcular la distancia entre el robot y un objeto, con una unidad de
medida de metros y con un valor de alcance mximo.

Sensores de infrarrojos, empleados tambin para el clculo de distancias pero para distancias ms cortas, con
una unidad de medida de centmetros y con un valor de alcance mnimo.

Sensores CCD, para la realizacin de capturas de imgenes y caracterizados por tener una resolucin mxima
en puntos por pulgada (ppp).

12
 Sensores de deteccin de obstculos, que podrn ser de sensibilidad baja, media o alta.

En orientacin a objetos el polimorfismo aparece en distintos contextos. Como la propia palabra indica, polimorfismo
se refiere a que un elemento concreto puede tener varias formas. En el caso de las variables, el polimorfismo permite
que una variable pueda hacer referencia a objetos de diferentes tipos o clases, ya sea el tipo declarado o cualquier
subtipo de ste.

Por ejemplo, en esta prctica, una variable declarada de la forma:

Sensor s;

puede referenciar a objetos no slo de la clase Sensor, sino tambin objetos de cualquiera de las clases que hereden de
Sensor, que en nuestra jerarqua sern clases hijas (subclases o subtipos) de Sensor.

En el caso de los mtodos, el polimorfismo nos permite reescribir mtodos definidos en una clase padre, de modo que
en cada clase hija se pueda tener un cdigo diferente dependiendo de las caractersticas diferentes de cada una de ellas.
En esta prctica todas las clases hijas de Sensor podrn tener, por ejemplo, un mismo mtodo printInfo(), donde cada
una de ellas mostrar la informacin correspondiente a su subclase, que en parte ser comn (la informacin
correspondiente a las caractersticas generales de un sensor) y en parte diferente (la correspondiente a cada subtipo
particular) .

Se pide ahora aadir al mtodo main() que se cre en el apartado 4.1 el cdigo necesario para:

1. Crear un nuevo pedido.

2. Crear sensores de diferentes tipos y, a continuacin, asociarlos a diferentes robots.

a. Un primer robot deber estar formado por un sensor LDR de sensibilidad baja (con un precio de
fbrica de 5 ), diez sensores de presin con valor mximo de 1 N/mm2 (con precio 25 /unidad) y un
sensor de deteccin de obstculos con sensibilidad media (con precio 15 ).

b. Un segundo robot deber montarse con un sensor de ultrasonido con alcance mximo de 10 m. (con
precio 30 ), un sensor de presin con valor mximo de 1,5 N/mm2 (con precio 29 ) y un sensor de
deteccin de obstculos de sensibilidad alta (con precio 15 ).

c. Un tercer robot con un sensor LDR de sensibilidad alta (con precio 7 ), cinco sensores de presin
con valor mximo de 0,8 N/mm2 (con precio 20 /unidad), un sensor de infrarrojos con alcance
mnimo de 0,1 cm. (con precio 45 ), 4 sensores CCD con resolucin 1024 ppp (con precio 75
/unidad) y un sensor de deteccin de objetos con sensibilidad baja (con precio 12 ).

NOTA: Se deja a eleccin del alumno el establecimiento del resto de los diferentes valores de los
campos de los sensores (cdigos del fabricante, del sensor y descripciones textuales).

3. Aadir los tres robots al pedido anterior.

4. Calcular y mostrar por pantalla el precio total del pedido, desglosando el PVP de cada robot por separado y
mostrando su descripcin completa.

5. Eliminar, a continuacin, el segundo robot e imprimir el pedido resultante.

13
5 ETAPA 3

5.1 ETAPA 3.1: USO AVANZADO DE LA HERENCIA Y POLIMORFISMO

5.1.1 OBJETIVOS

En esta etapa nos vamos a centrar en extender la funcionalidad de la aplicacin estableciendo restricciones a la hora de
permitir incluir sensores a un robot, de modo que no puedan incluirse simultneamente dos tipos determinados de
sensor o que, en caso de incluirse un tipo especfico, no sea posible despus incluir ms sensores de ese mismo tipo.

La solucin a este problema podra encontrarse, bien modificando el esquema de clases en la parte correspondiente a la
jerarqua de la clase Sensor, de modo que el tipo de sensores que podrn incluirse sin lmite en un robot sern slo de un
determinado subtipo, o bien manteniendo el esquema y diseo que tenemos hasta ahora, donde todos los tipos de
sensores son tratados por igual a la hora de incluirse en la clase Robot, pero modificando los mtodos de insercin de
sensores en un robot para cumplir las restricciones impuestas.

5.1.2 REQUISITOS PREVIOS

Esta etapa se basa en los mismos principios que la etapa 2.2, por lo que los temas que deben estudiarse son los mismos.
Requiere, eso s, un dominio mayor de los conceptos que se presentan, con el objetivo de profundizar en el uso del
mecanismo de composicin, herencia y polimorfismo para ampliar la aplicacin que estamos desarrollando.

5.1.3 ENUNCIADO: AADIENDO NUEVOS TIPOS DE SENSORES CON

RESTRICCIONES

Hasta ahora, en nuestra aplicacin se han usado diferentes tipos de sensores, pero han sido tratados todos por igual a la
hora de incluirse en un robot. En este punto se desea incluir los mismos tipos de sensores, pero ahora estableciendo las
siguientes limitaciones:

1. En un robot nicamente podr instalarse un sensor de tipo LDR, aunque no es obligatorio hacerlo.

2. Si se instala un sensor de ultrasonido no podr instalarse otro de infrarrojos, y viceversa.

Se pide modificar el cdigo de la aplicacin para cubrir esta nueva. Ntese que hay ms de un diseo posible; por tanto,
se deben estudiar las opciones y justificar la decisin tomada. A continuacin debe incluirse en el mtodo main() del
Lanzador el cdigo necesario para realizar lo siguiente:

1. Crear un nuevo pedido.

2. Crear sensores de diferentes tipos y, a continuacin, asociarlos a diferentes robots.

a. Un primer robot deber estar formado por un sensor LDR de sensibilidad alta (con un precio de
fbrica de 7 ), 8 sensores de presin con valor mximo de 0,9 N/mm2 (con precio 22 /unidad), un
sensor de infrarrojos con alcance mnimo de 0,1 cm. (con precio 45 ), y un sensor de deteccin de
obstculos con sensibilidad baja (con precio 12 ). Trata de incluir en el robot otro sensor LDR de
sensibilidad baja (con precio 5 ) y un sensor de ultrasonido con alcance mximo de 10 m. (con
precio 30 ). Comprueba si tu diseo lo permite.

b. Un segundo robot deber montarse con un sensor de infrarrojos con alcance mnimo de 0,1 cm. (con
precio 45 ), un sensor de presin con valor mximo de 1,5 N/mm2 (con precio 29 ) y un sensor de
deteccin de obstculos de sensibilidad alta (con precio 15 ). Trata de incluir ahora un sensor LDR
de sensibilidad alta (con precio 7 ) y un sensor de ultrasonido con alcance mximo de 10 m. (con
precio 30 ). Comprueba si tu diseo lo permite.

c. Un tercer robot con un sensor LDR de sensibilidad alta (con precio 7 ), seis sensores de presin con
valor mximo de 1 N/mm2 (con precio 25 /unidad), un sensor de infrarrojos con alcance mnimo de

14
 0,1 cm. (con precio 45 ), 2 sensores CCD con resolucin 768 ppp (con precio 55 /unidad) y un
sensor de deteccin de objetos con sensibilidad baja (con precio 12 ). Trata ahora de incluir un
sensor LDR de sensibilidad baja (con precio 5 ) y un sensor de ultrasonido con alcance mximo de
10 m. (con precio 10 ). Comprueba de nuevo si tu diseo lo permite.

NOTA: Se deja a eleccin del alumno el establecimiento del resto de los diferentes valores de los
campos de los sensores (cdigos del fabricante, del sensor y descripciones textuales).

3. Aadir los tres robots resultantes al pedido anterior.

4. Calcular y mostrar por pantalla el precio total del mismo, desglosando el precio de cada robot por separado y
mostrando su descripcin completa.

Nota: en este punto se puede comprobar si la solucin es correcta y se cumplen las restricciones establecidas
en este enunciado.

5. A continuacin, eliminar el tercer robot e imprimir el pedido resultante. Comprobar de nuevo si se cumplen las
restricciones.

5.2 ETAPA 3.2: COMPLETANDO EL SISTEMA

5.2.1 OBJETIVOS

Hasta llegar a esta ltima etapa hemos hecho un recorrido por los aspectos ms importantes de la programacin
orientada a objetos en Java. Para finalizar el diseo e implementacin de la aplicacin que tenemos entre manos, vamos
a introducir una nueva funcionalidad en la aplicacin.

Hasta ahora el precio de los pedidos se calcula aplicando un margen de beneficio fijo (en nuestro caso del 85%) sobre el
precio de fbrica de cada uno de los sensores instalados en un robot (lo que supone el PVP de cada robot) y aplicando
despus una rebaja fija de un 10% por cada 5 robots incluidos en un pedido hasta un mximo del 50% de rebaja. Ahora
nos interesara poder aplicar diferentes porcentajes de descuento en el precio final del pedido al considerar diferentes
tipos de clientes.

5.2.2 REQUISITOS PREVIOS

Para la realizacin de esta parte es necesario haber estudiado y tener claro todo lo que se ha ido proponiendo a lo largo
de la presente prctica.

5.2.3 ENUNCIADO: FACTURANDO SEGN TIPO DE CLIENTE

El objetivo de este apartado es que en el clculo del precio final de un pedido se puedan aplicar diferentes rebajas segn
el tipo de cliente considerado. Esta funcionalidad dar una mayor flexibilidad a nuestra aplicacin a la hora de ser usada
por una empresa que comercialice nuestros robots educativos.

Se considerar ahora que la empresa distingue entre dos tipos de clientes: premium y cliente estndar. A la hora de
imprimir un pedido, en caso de tratarse de un cliente premium habr que aplicar un 15% extra de descuento respecto al
precio que se le dara a un cliente estndar. Se debern introducir en el diseo previo las modificaciones necesarias para
el tratamiento de los diferentes tipos de clientes.

En esta ltima etapa se pide incluir en el mtodo main() de la clase Lanzador el cdigo necesario para comprobar el
correcto funcionamiento del sistema, de forma que se pueda imprimir el pedido del apartado 5.1.3 para un cliente
premium. Deber comprobarse que se modifica el precio total del pedido obtenido anteriormente en el apartado 5.1.3.

15
6 Fechas y Normas de Entrega

6.1 Fechas

La realizacin de la prctica se llevar a cabo en los centros asociados, siendo las sesiones organizadas y supervisadas
por el tutor de la asignatura. Habr como mnimo tres sesiones presenciales de obligatoria asistencia. En cada sesin se
abordar cada una de las partes de las que consta la prctica. Los alumnos debern ponerse en contacto con su centro
asociado para informarse acerca de cundo tendrn que asistir a las sesiones.

Las fechas orientativas para la realizacin de cada una de las etapas sern:

Finales de Marzo. Realizacin de la primera parte de la prctica.

Finales de Abril. Realizacin de la segunda parte de la prctica.

Mediados de Mayo. Realizacin de la tercera parte de la prctica.

7 Normas de Entrega

La prctica se entregar a travs de la tarea definida en el entorno virtual de la asignatura. Cada alumno crear y
comprimir una carpeta nombrada con el DNI y primer apellido separados por un guin (8345385X-gonzalez). Esta
carpeta contendr:

- Una memoria de no ms de 6 hojas donde se explique la especificacin y el diseo realizados en cada parte de la
prctica.

- Los ficheros .JAVA, sin caracteres especiales; por ejemplo o tildes.

NOTA IMPORTANTE: Los nombres de los ficheros y carpetas/paquetes que compongan la prctica entregada, deben
contener SLO caracteres correspondientes a las letras de la A a la Z, tanto maysculas como minsculas, nmeros del
0 al 9 y los caracteres especiales - y . No deben utilizarse otros, tales como tildes o smbolos.

Los tutores de la asignatura debern evaluar en el entorno virtual las prcticas antes del 23 de mayo.

NOTA IMPORTANTE: Los tutores tienen que cumplir una serie de requisitos ante los alumnos debido a que la prctica
cuenta para la calificacin de la asignatura. Por tanto, antes de entregar las calificaciones al equipo docente debern:

1. Publicar la nota de las prcticas en un lugar accesible para los alumnos (ya sea va web o mandar un fax al
centro asociado)

2. Establecer un da de revisin de prcticas (previo al perodo de entrega de las calificaciones al equipo docente),
dado que stas forman parte de la evaluacin del alumno.

Es importante que se mantengan todos los identificadores definidos en el enunciado, es decir, el nombre de las clases,
atributos y mtodos deben ser tal y como se definen en este enunciado.

16
 7.1 Evaluacin de la prctica

Las prcticas tienen carcter INDIVIDUAL, para evitar posibles copias todas las prcticas pasarn por un software
detector de ejemplares similares. La deteccin de prcticas copiadas implicar un SUSPENSO en TODO el curso, es
decir, convocatorias de Junio y Septiembre, para todos los implicados.

Es requisito indispensable para aprobar el examen, la asistencia a las 3 sesiones obligatorias de la prctica, as
como superar la propia prctica. El informe del tutor se considera a efectos de subir nota.

Las prcticas NO se guardan de un curso para otro.

7.2 Preguntas al Equipo Docente

El equipo docente atender preguntas de carcter metodolgico y de diseo, preferentemente a travs de los foros del
curso virtual de la asignatura. Las preguntas relativas a la instalacin del entorno de desarrollo, puesta en
funcionamiento y errores de compilacin deben ser remitidas a los tutores de los centros asociados.

Felisa Verdejo Mallo, Catedrtica de Universidad

Tutoras: Jueves de 11:00 a 13:00 h. y de 15,00 a 17,00 h.

Telfono: 91.398.64.84
Email: felisa@lsi.uned.es

Enrique Amig Cabrera, Profesor Contratado Doctor

Tutoras: Jueves de 15:00 a 19:00

Telfono: 91.398.86.51
Email: enrique@lsi.uned.es

Vctor Fresno Fernndez, Profesor Contratado Doctor

Tutoras: Jueves de 15:00 a 19:00

Telfono: 91.398.82.17
Email: vfresno@lsi.uned.es

Roberto Centeno Snchez, Profesor Ayudante Doctor

Tutoras: Jueves de 11:00 a 13:00 h. y de 15,00 a 17,00 h.

Telfono: 91.398.96.96
Email: rcenteno@lsi.uned.es

17