5/27/2018 Enunciado

1/11

!"#$ & !"#'

5/27/2018 Enunciado

2/11

"

!"#$%#&'(%" *& +$,'$%-%.(/0 1 !"#$2.#2$%" *& 3%#,"

!"#$% '()* + '(),

!020.(%*, *& 4% +$5.#(.%

67 80#$,*2..(/0

La empresa Alloted Parkings, Inc. (conocida como API) est dedicada a gestionar, entre otros, el

aparcamiento de un conocido centro comercial. El aparcamiento dispone de un total de 6 plantas

idnticas y cada planta est dividida en 4 secciones nombradas como A, B, C y D respectivamente

dispuestas en el sentido horario. Adems cada seccin se compone, a su vez, de 4 zonas dispuestas

de manera semejante a la anterior y numeradas como I, II, III y IV. Finalmente, dentro de cada zona,

existen un total de 6 plazas dedicadas a estacionar los vehculos de los usuarios del parking. 3 de

ellas estn pensadas para alojar tan solo coches de tamao familiar mientras que en las otras 3 se

utilizan para aparcar coches normales. La figura 1 muestra una representacin esquemtica de la

estructura de una planta cualquiera del parking segn lo descrito.

Figura 1. Disposicin organizativa de las plazas del parking.

!

!!!!#

!!$

!#

!!!!!

!%

!!

!#!

!!!

&

!!!

!!!

!#

'

$ %

& '

!"#$%& (%$)&)%#

#

*&%+,%

-.//)0+

1"+%

2+,#%3% 3.

45/.+5"#.5

5/27/2018 Enunciado

3/11

#

Adicionalmente, como se aprecia en la figura, cada planta dispone de 4 entradas de ascensores

diferentes para el acceso al centro comercial que se encuentran prximas a cada una de las 4

secciones de planta. Por su proximidad a dichas secciones identificaremos a cada una de estas

entradas tambin con los nombres A, B, C y D respectivamente. Dado que las dimensiones de la

planta son muy grandes y que cada entrada de ascensores dirige a un punto distinto del centro

comercial (pinsese en Seoras, caballeros, Jvenes, etc.) los clientes que hacen uso del parkingsiempre buscan la plaza libre ms prxima a la entrada de ascensores de su inters segn las

compras que vayan a realizar y teniendo en cuenta las dimensiones de la plaza y de su propio

vehculo (slo se distingue entre coche normal o familiar).

Tras un anlisis riguroso desarrollado por API acerca del uso del parking en das alternos se observa

una alta ineficacia en el aprovechamiento de las capacidades del parking por parte de los clientes.

En el estudio se estima que los clientes aparcan ms lejos de lo estrictamente necesario porque no

se dedican a realizar una bsqueda exhaustiva de la plaza ptima por cada una de las plantas

(tngase en cuenta que todas las plantas son idnticas y disponen de los mismos 4 tipos de

entradas). Es entonces cuando se decide instalar un sistema de asistencia automtico que ayude a

gestionar las plazas del parking. Los requisitos de dicho sistema, cuya construccin ser objeto de

estudio en esta prctica, se detallan a continuacin.

97 :42;, *& !0#$%*%

En el flujo de entrada, los clientes esperan en una cola su turno de acceso al parking controlado por

una barrera elevadiza automatizada. Las condiciones de espera tienen que ver, naturalmente, con el

estado de plazas libres que hay en el parking para el tipo de vehculo (normal o familiar) situado en

la cabeza de la cola. Es decir, el sistema de control del parking detectar automticamente las

dimensiones del vehculo en cabeza, lo clasificar como normal o familiar y mantendr bajada la

barrera mientras no existan plazas libres de dicho tamao aunque ello sea en perjuicio de otros

coches que esperando detrs de ste si tuvieran una plaza libre por tratarse de vehculos de otras

dimensiones.

Una vez que se levanta la barrera, el conductor del vehculo en cabeza accede al parking y all

indica al sistema, a travs de un interfaz de mandos, la matricula del coche, el tiempo exacto de

permanencia en el parking y la parte del centro comercial a la que se dirige (entrada A, B, C o D).

Entonces el sistema, localiza dentro del parking la mejor plaza para el vehculo, la marca como

reservada y emite un ticket para el conductor con la posicin exacta de dicha plaza. Esta posicin

tiene el siguiente formato:

{Planta} {Seccin} {Zona} {Plaza}

Donde planta se refiere al nmero de la planta y es un digito comprendido entre 1 y 6, seccin serefiere al nombre de la seccin dentro de la planta y es una letra comprendida en el rango

(A,B,C,D), zona es la indicacin de la zona dentro de la seccin y es uno de los 4 identificadores (I,

II, III, IV) y plaza es un nmero de plaza dentro de la zona comprendido entre los valores 1 y 6. Un

identificador de posicin correcto sera, por ejemplo, 5-B-IV-3.

Los criterios para seleccionar, dentro del proceso de bsqueda, la mejor plaza se establecen en

trminos de la proximidad relativa de la misma a la entrada objetivo. Dicho proceso puede

describirse de la siguiente forma:

1. Determinacin de Planta. El algoritmo debe recorrer la coleccin de plantas y encontrarpara cada una de ellas la mejor solucin entendiendo que sta es la plaza de menordistancia a la entrada objetivo dentro de dicha planta. Obtenida as una coleccin de

soluciones de tamao comprendido entre 0 (ninguna planta tiene plaza) y 6 (todas tienen

5/27/2018 Enunciado

4/11

$

una plaza libre candidata) se debe devolver aquella plaza de la coleccin de soluciones

cuya distancia a la entrada objetivo sea menor. Y ante varias plazas de igual distancia

dentro de la coleccin de soluciones aquella que se encuentre en un nmero de planta

menor.

2. Determinacin de Seccin. Para encontrar la mejor solucin dentro de una planta se debedeterminar, en primer lugar, la seccin ms prxima a la entrada objetivo con plazasdisponibles del tamao adecuado al tipo de vehculo. Los criterios de proximidad aqu se

establecen en trminos de vecindad entre secciones donde cada seccin tiene 2 secciones

vecinas a distancia 1 y una seccin a distancia 2. As, por ejemplo, si un cliente desea

acceder a la entrada A, primero debera intentar encontrarse una solucin dentro de la

seccin A. Si dicha seccin no tiene plazas libres, se buscara en las secciones vecinas a

distancia 1 de A ordenadas de acuerdo a su orden lexicogrfico. Esto es, en las secciones B

y C respectivamente. Y finalmente, si ni las secciones B y C disponen de plazas libres, se

buscara en la zona D que se ubica a distancia 2 de A. Si por el contrario, la entrada

objetivo es la D, el orden de bsqueda sobre secciones sera primero D, luego A y C y

finalmente B. Una inspeccin del esquema de planta del parking de la figura 1 hace

intuitivo este criterio.3. Determinacin de Zona. Para buscar una solucin a nivel de zona se procede de forma

similar a lo establecido en el punto anterior con respecto a los criterios de proximidad por

vecindad aplicados en esta ocasin entre zonas. En este caso, como se observa en la figura

1, las zonas de distancia menor preferente a cualquier entrada son las identificadas como I,

despus aqullas a distancia de vecindad 1, correspondientes con los identificadores II y IV.

Y finalmente, aqulla a distancia de vecindad 2 identificada como III. Es decir el orden de

bsqueda dentro de las 4 zonas que componen una seccin debera ser I, II, IV y III.

4. Determinacin de Plaza. A efectos de la determinacin del nmero de plaza, se entenderque de las 6 plazas que conforman una zona, con numeracin correlativa de 1 a 6, aquellas

con nmero par corresponden a vehculos normales mientras que las de numeracin impar

corresponden a vehculos familiares siendo totalmente incompatibles entre s. Es decir, a uncoche normal no se le puede asignar una plaza familiar y recprocamente. El criterio de

ordenacin en este ltimo paso consiste siempre en devolver el nmero de plaza menor,

par o impar segn corresponda al tipo de vehculo.

Una vez que un conductor dispone de un ticket con la informacin exacta hacia la posicin donde

debe dirigirse dentro del parking y que el sistema ha marcado como reservada dicha posicin, el

cliente se dirige a ella y hace uso de la plaza exactamente durante el tiempo que indic en la

entrada. Es decir, por simplicidad puede asumirse que no se consideran efectos de retraso

motivados por clientes que se demoran en su tiempo estimado de abandono del parking. Adems

el proceso de estacionamiento del vehculo desde que el cliente recibe el ticket hasta que aparca

se considera ajeno al sistema y por tanto su tiempo es despreciable.

5/27/2018 Enunciado

5/11

%

cola de salida. Dado que en un momento determinado se pueden detectar una coleccin de

vehculos con intencin de abandonar el parking, es preciso establecer unos criterios exactos que

indiquen el orden en que stos deben ser encolados. A continuacin describimos dichos criterios:

1. Salida de Planta. La coleccin de vehculos saliente debe ser en primer lugar ordenada enfuncin del nmero de planta que ocup el vehculo durante su estacionamiento. As porejemplo, todos los vehculos salientes con plaza en la planta 3 debern ir encolados

estrictamente antes de los vehculos con plaza en las plantas inferiores (4, 5, o 6) y

estrictamente despus de aquellos con plaza en plantas superiores (1 y 2).

2. Salida de Seccin. A igualdad del nmero de planta entre varios coches salientes seaplicar de forma prioritaria el criterio de orden de la seccin de planta donde se estacion

cada vehculo. De esta forma, los coches de una misma planta que ocuparon la seccin A

deben ir encolados estrictamente antes que los que ocuparon las secciones B, C y D

respectivamente y por este orden.

3. Salida de Zona. A igualdad del orden de seccin y planta se aplicar, en tercer lugar, elcriterio de orden de la zona donde se estacion cada vehculo. Los coches de una misma

planta y seccin que ocuparon la zona I se encolarn estrictamente antes que los queocuparon las zonas II, III y IV respectivamente.

4. Salida de Plaza. Finalmente, igualdad del orden en el nmero de planta, seccin y zona seaplicar,, el criterio de orden de la plaza ocupada. Ello indica que los vehculos de una

misma planta, seccin y zona que ocuparon plazas de numeracin inferior a otros deben

posicionarse estrictamente antes en la cola de salida.

>7 >,0#$,4 *& :42;,"

De la descripcin de los dos flujos de trabajo anteriores se desprende un necesidad de

coordinacin motivada por el hecho de que el acceso de entrada y salida es compartido (Ver figura

2). Esta coordinacin dara la oportunidad de establecer unas polticas de gestin de turnos tanto a

la entrada como a la salida potencialmente configurables y variantes en funcin de la longitud de

ambas colas de espera y del estado de llenado del parking.

Figura 2. Estructura de barreras de acceso al parking.

De acuerdo a lo anterior puede describirse el flujo completo de procesamiento de accesos de

entrada y salida al parking que debe hacer el sistema a partir de la secuencia de pasos siguiente.

Este proceso de trabajo se articula en un ciclo iterativo permanente mientras dure el tiempo de vida

del parking.

!"#$ &' '()*$&$

!"#$ &' +$#,&$

-$**'*$ &' '()*$&$

-$**'*$ &' +$#,&$

.,+/'(+$&"* &' 0,12')+

3'4516#" '()*$()'

5/27/2018 Enunciado

6/11

&

1. Gestin del flujo de entrada. En primer lugar, el sistema detecta si existen cochesesperando en la cola de entrada. Si existen, analiza el tamao del vehculo en cabeza, lo

clasifica como normal o familiar y comprueba si hay una plaza libre para l antes de

levantar la barrera. Si es as, el sistema levanta la barrera dejando pasar al coche en cabeza,

solicita al conductor los datos de entrada (matricula, tiempo exacto de permanencia y

entrada objetivo), busca a partir de ellos la mejor plaza para el vehculo, genera un ticket,reserva la plaza de acuerdo a lo descrito en el flujo del apartado A y salta al paso 2. Por

otro lado, tanto si no existen coches en la cola de entrada como si no hay plazas

disponibles para el vehculo en cabeza, el algoritmo salta al paso 2.

2. Gestin de flujo de salida. El sistema detecta los coches dentro del parking que hanagotado su tiempo de permanencia y los encola en la cola de salida de acuerdo al flujo de

trabajo descrito en el apartado B. Despus, si existen coches en la cola de salida permite la

salida del primero. Para cerrar el ciclo, se retorna al paso 1.

?7 9$@2(#&.#2$% *&4 =("#&-%

El sistema de gestin de plazas de parking que se propone desarrollar en esta prctica gira entorno a un ecosistema de artefactos que queda representado por cada una de las abstracciones

que aparecen en el diagrama de clases de la figura 3. De todas ellas, la entidad central es la

representada por la clase ParkingDispatcherque dispone del mtodo main necesario para arrancar

el sistema. Cuando se arranca, esta clase invoca a init y genera con nimo simulativo una coleccin

de vehculos aleatoria invocando iterativamente a los mtodos que a tal efecto dispone la clase

VehicleGenerator. Cada llamada invoca al constructor de la clase Vehicle con unos parmetros

reales de valor aleatorio sobre el nmero de matricula, tipo de vehculo y puerta de acceso

objetivo. La clase ParkingDispatcher recoger estos vehculos y los encolar consecutivamente en la

cola de entrada asociada a dicha clase representada por el artefacto VehicleQueue.

Figura 3. Diagrama de clases del sistema de gestin del parking.

!"#$%&"

! #$%&' () * +$%&' (,')

! #$%-./$ () * +$%-./$ (%./$)

! #$%01%$ () * +$%01%$ (#1%$)

! #$%2345 () * +$%2345 (6345)

()*+$,- .$/0)1%#"*!"#$

! 73,' ,8,% (8)

! 73,' ',+/1%96 ()

!"#$%&" 23"3"

! 73,' 1'':$6,9;$ (7)

! :$6,9;$ #$%:$6,9;$ ()

! ,8#?/19$ #$%?/19$ (%./$)

! ,8#?/19$K #$%N$O% ()

!

5/27/2018 Enunciado

7/11

'

Superado este proceso de inicializacin, la clase ParkingDispatcher pasa a ejecutar el mtodo de

dispatch (), responsable de iterar los vehculos de la cola de entrada hasta que sta quede vaca y

articulando el proceso de control de flujos que se describi en el apartado C de la introduccin.

Por su parte, se puede observar que el ParkingDispatcher est conectado con la clase Parking, que

es la responsable de mantener todas las estructuras de control que gestionan el aparcamiento. Esta

clase dispone de mtodos para encontrar una plaza para un determinado tipo de vehculo

getSpace (type) as como para averiguar gilmente si existen plazas disponibles de un

determinado tipo hasSpace (type). Para gestionar esto ltimo, la clase Parking delega en la

abstraccin ParkingState, que mantiene en todo momento el nmero de plazas libres dentro del

aparcamiento para cada tipo de vehculo getSpaces (type) as como informa de si existen plazas

libres de cada tipo hasSpaces (type).

La clase Parking tambin se conecta con una agregacin de elementos de parking que quedan, en

trminos abstractos, representados por la interfaz ParkingElement. De acuerdo a la descripcin del

enunciado, ser necesario distinguir entre plantas, secciones, zonas, y plazas del parking que se

representan respectivamente a travs de las clases ParkingFloor, ParkingSection, ParkingAreay

ParkingSpace. Como puede apreciarse, cada una de estas clases dispone de mtodos propios

que ofrecen informacin respectiva al nmero de planta, nombre de seccin, identificador de zona

y nmero de plaza respectivamente. Adems, en el caso de la plaza existen mtodos para alojar,

consultar o liberar un determinado vehculo de dicha plaza.

Si se observa la anotacin sobre el diagrama de la figura, los elementos de parking se agregan de

acuerdo a una estructura de rbol general que responde a la organizacin descrita en el enunciado.

El nodo raz de dicho rbol no tiene una semntica particular. De ste nacen 6 hijos que alojan

entidades de tipo ParkingFloor y que representan cada una de las plantas. De cada uno de estos

nodos nacen 4 nodos hijos que contienen elementos de tipo ParkingSection para representar las 4secciones que existen por planta (A,B,C y D). De cada uno de estos nodos, a su vez, salen 4 hijos

que albergan elementos de tipo ParkingArea para representar los 4 tipos de zonas por seccin (I, II,

III y IV) y finalmente de estos nodos cuelgan 6 nodos hoja que se corresponden con cada una de las

6 plazas de una zona. Esta disposicin estructural debe ser garantizada por construccin durante el

proceso de arranque del sistema que realiza el mtodo init () de la clase ParkingDispatcher.

Ntese adems que cada uno de los 4 tipos de elementos de parking que gestiona el sistema estn

obligados a implementar, por contrato, un mtodo getIterator () que devuelva un iterador propio

sobre los hijos de cada nodo. La responsabilidad de estos iteradores es encapsular la lgica de

recorrido que es necesaria sobre cada tipo de nodo para realizar el proceso de bsqueda. As el

iterador del nodo raz debe iterar linealmente sobre cada uno de los 6 nodos de planta, cadaiterador de planta sobre las secciones hijas en el orden alterno de bsqueda establecido en el

enunciado y de forma similar para los iteradores de zona. Los iteradores de plaza no tienen sentido,

en tanto que stas son nodos hojas. Por tanto puede suponerse que una implementacin adecuada

de su iterador es devolver siempre false en su mtodo hasNext ().

Finalmente, existe el artefacto representado por la clase ParkingScheduler, cuya misin es la de

gestionar gilmente el tiempo de permanencia de los vehculos dentro del parking. En concreto,

esta clase se invoca una vez en cada iteracin dentro del proceso representado por el mtodo

dispatch y le sirve al sistema para conocer la coleccin de coches que deben abandonar el parking

encolndose en la cola de salida y las plazas que de esta forma quedarn vacantes. El diseo e

implementacin de esta estructura de datos queda a la eleccin del estudiante. No obstante,

tngase en cuenta que en ningn caso se considerarn aceptables soluciones que pasen por

recorrer la estructura jerrquica del parking discutida anteriormente.

5/27/2018 Enunciado

8/11

(

A7 3&".$(B.(/0 *&4 C$%D%;,

Con el nimo de acercar al alumno al desarrollo de la prctica de forma progresiva y ordenada, a lo

largo de esta seccin se proponen una coleccin de tareas que se invita a seguir de forma

secuencial, si bien cualquier otro orden de desarrollo es igualmente satisfactorio.

1. Clase Vehicle. Implemente la clase para vehculos incluyendo un constructor de 4parmetros que representen respectivamente la matricula (id) el tipo (type), la puerta

objetivo y la cantidad exacta de horas de permanencia en el parking (hours). Defnanse

estos tres atributos como privados e implemntese mtodos de acceso y modificacin

get/set para cada uno de ellos. Incluya adems los mtodos hashcode, equals y toString

que toda clase de tipo entidad debe tener. Tenga en cuenta que de forma preliminar

necesitar declarar un par de tipos enumerado TTypey TGate para representar los tipos

de vehculos (Normal, Familiar) y puertas (A,B,C,D).

2. Clase VehicleGenerator. Implemente la clase generadora de vehculos. Esta clase debeestar formada por un constructor que reciba como nico argumento un valor entero para

utilizar como semilla en los procesos de construccin de vehculos con atributos aleatorios.Implemente tres mtodos privados nextId (), nextType () y nextGate () y nextHours () que

tomando como punto de partida el valor de seed generen valores aleatorios de matricula,

tipo y puerta respectivamente. Implemente el mtodo generate () que haciendo uso de los

tres mtodos anteriores construya un nuevo vehculo de valores aleatorio. Como nota

orientativa se informa al alumno que la clase Math.Random permite obtener nmeros

aleatorios a partir de una semilla pasada como parmetro en su constructor.

3. Clase VehicleQueue. Implemente la clase cola de vehculos. Esta clase puede serdirectamente una implementacin de la interfaz QueueIF concretada para la clase

vehculo, segn se describe en el material de la asignatura, o, preferentemente, una clase

que encapsule un atributo de tipo cola concretando el tipo paramtrico en objetos de la

clase Vehicle. En cualquiera de ambos casos este artefacto debe tener mtodos para lainsercin, borrado y consulta de elementos sobre la coleccin.

4. Clase ParkingState. Implemente la clase ParkingState incluyendo un constructor quereciba como nico parmetro el nmero total de plazas de cada tipo dentro del parking.

Incluya dos atributos privados que mantengan en cada momento el nmero de plazas de

cada tipo. Para cada atributo defina mtodos de acceso y consulta getSpaces (type) /

hasSpaces (type) y mtodos de incremento y decremento para mantener vigentes sus

valores en todo momento incSpace (type) / decSpace (type).

5. Interfaz ParkingElement. Defina la interfaz ParkingElement incluyendo como nicomtodo getIterator, encargado de devolver un artefacto de la clase

IteratorIF.

6. Clases ParkingFloor, ParkingSection, ParkingArea y ParkingSpace. Codifique cada unade las clases que implementan la interfaz ParkingElement. Para cada una de ellas incluya un

constructor que reciba como argumento el tipo de dato pertinente para representar la

informacin de dicho tipo de elemento (nmero de planta, nombre de seccin,

identificador de zona o nmero de plaza). Implemente los mtodos de acceso,

modificacin y consulta que en cada caso se incluyen en la figura. No olvide agregar

adems los mtodos hashcode, equals y toString que convenientemente incluyen todas las

clases de tipo entidad.

7. Clase Parking. Implemente la clase Parking. El constructor sin argumentos debe crear unejemplar de la clase ParkingState configurado con tantas plazas totales de cada tipo como

disponga el parking (6 x 4 x 4 x 3). Asimismo debe construir una estructura jerrquica detipo TreeIF de acuerdo a la estructuracin de plantas secciones, zonas

5/27/2018 Enunciado

9/11

)

y plazas que se describi a lo largo del texto. Ambos elementos formarn parte de la clase

como atributos privados. Haciendo uso de los iteradores definidos sobre los elementos de

tipo ParkingElement y de acuerdo a su disposicin jerrquica, implemente el mtodos de

bsqueda de la mejor plaza getSpace (type) para cada tipo de vehculo. Para ello siga

las directrices indicadas en el flujo de entrada de vehculos descrito en la seccin A de la

introduccin. Igualmente, implemente el mtodo de consulta de plazas libres hasSpace(type) que permitir a la clase ParkingDispatcher conocer en todo momento la disposicin

de plazas de parking para cada tipo de vehculo. Para su implementacin haga uso de las

facilidades proporcionadas por la clase ParkingState.

8. Clase ParkingDispatcher. Implemente la clase ParkingDispatcher. Implemente el mtodoinit (n, s). Este mtodo debe instanciar un ejemplar de la clase VehicleGenerator y utilizar

dicho objeto para generar tantos vehculos aleatorios como indique el parmetro n del

mtodo que se irn encolando en la cola de entrada. La semilla de generacin que se debe

proporcionar al generador de Vehculos en su instanciacin corresponde con el otro

parmetro, s, del mtodo init. Implemente el mtodo dispatch partiendo del estado de las

colas de entrada y salida y de acuerdo a lo descrito en el apartado C de la introduccin.

Implemente el mtodo main en esta clase. Dicho mtodo debe leer como argumentos(String args[]) de la lnea de comandos primero el nmero de vehculos a generar y despus

el valor de la semilla generadora. El mtodo main debe invocar primero a init, con los

parmetros recibidos en lnea de comandos (n y s) y despus llamar al mtodo dispatch.

9. Clase ParkingScheduler. Disee e Implemente la clase ParkingScheduler de acuerdo a lasprescripciones del enunciado e incluyendo al menos los mtodos que se prescriben en el

diagrama de la figura 3.

E7 !F%42%.(/0 *& 4% +$%.#(.%

A lo largo de esta ltima seccin se expone toda la informacin relativa al proceso de evaluacin al

que ser sometido la practica. En concreto se describe en las secciones subsiguientes lascondiciones mnimas que debe satisfacer el cdigo para poder ser evaluado, as como la forma y

fecha de entrega y los criterios de evaluacin que sers aplicados durante la correccin.

97 >,0*(.(,0&" *& !0#$&'%

Para facilitar los procesos de evaluacin de la prctica se requiere a los estudiantes que se aseguren

de forma previa a la entrega, de que su cdigo cumple con las siguientes condiciones mnimas

particulares que se exponen a continuacin:

1. Mensaje de Entrada. Cada vez que un nuevo vehculo entrante ingresa al parking, y unavez que se ha procesado dicho ingreso de acuerdo a lo establecido en el enunciado, el

sistema deber imprimir por la salida estndar (la consola) un mensaje con el siguiente

formato:

ENTRA: {Id} {Tipo} {Puerta} {Horas} {Planta} {Seccin} {Zona} {Plaza}

Donde los cuatro primeros elementos corresponden a los parmetros caractersticos del

vehculo y los cuatro segundos son los correspondientes a la plaza que ocupa dentro del

parking. Entindase que las llaves no aparecern en estos mensajes, que detrs de la

cadena ENTRA aparece el carcter dos puntos (:) seguido de un espacio en blanco, que

cada dato viene separado de un guion rodeado por delante y detrs de sendos caracteres

en blanco y tras el dato de la plaza no aparece ningn carcter ni espacio en blanco

adicional, sino tan slo el salto de lnea que, de forma automtica, genera la instruccinprintln de Java.

5/27/2018 Enunciado

10/11

*

2. Mensaje de Salida. De forma similar una vez que un coche saliente haya sidocompletamente procesado y se disponga a abandonar la cola de salida del parking el

sistema debe imprimir por la salida estndar un mensaje con formato similar al anterior. Las

explicaciones precedentes relativas al formato de mensaje entrante son tambin aplicables

a este tipo de mensajes:

SALE: {Id} {Tipo} {Puerta} {Horas}

3. Arquitectura. En trminos generales, la prctica debe respetar de manera estricta elmodelo de clases prescrito en la arquitectura del sistema. No obstante, es especialmente

importante, de cara a facilitar el proceso de automatizacin de las correcciones, garantizar

las siguientes restricciones estructurales:

a. Sobre VehicleGenerator. La clase generadora de vehculos debe ser nombradacomo VehicleGenerator y debe constar de un nico mtodo constructor pblico

con un parmetro para inyectar la semilla de aleatoriedad. Asimismo, el nico

mtodo pblico que incluya esta clase debe ser el mtodo generate () que

devolver un objeto aleatorio de la clase Vehicle.b. Sobre Vehicle. La clase vehculo debe ser nombrada con el nombre Vehicle. Su

nico constructor debe recibir, en este orden, los cuatro parmetros caractersticos

siguientes: id, type, gate y hours, que corresponden a un nmero de matricula,

tipo de vehculo, puerta de entrada y hora. Para cada uno de sus 4 parmetros

deben definirse mtodos de acceso y modificacin pblicos get/set y en particular

el tipo sobre el parmetro gate y type debe usar sendos tipos enumerados para

representar el tipo de puerta y vehculo cuyos nombres deben ser TGate (con

etiquetas A, B, C, y D) y TType (con etiquetas Normal y Familiar).

c. Sobre VehicleDispatcher. La clase VehcleDispatcher debe ser la nica quedisponga de un mtodo main de arranque y debe seguir las restricciones sobre los

parmetros de configuracin por lnea de comandos que se describieron con

anterioridad.

d. Sobre la Organizacin. Todas las clases de la prctica deben ser incluidas en elpaquete eped.parking. Adicionalmente puede incluirse un subpaquete tads para

incluir las implementaciones necesarias de los tipos abstractos de datos

implementados

5/27/2018 Enunciado

11/11

"+

4. Entrega tanto del cuadernillo del estudiante como del cdigo al Tutor, que ser elencargado de evaluar la prctica, en la forma y tiempo que ste estime oportuno segn el

calendario marcado por l mismo.

5. Entrega del cdigo al Equipo Docente mediante el entorno virtual. La tarea de entregadentro del entorno ser habilitada das prximos a la fecha final de entrega que ser el

prximo da 20 de Junio de 2014 para la convocatoria de Junio y el da 15 deSeptiembre de 2014para la correspondiente a Septiembre.

>7 >$(#&$(," *& !F%42%.(/0

Segn aparece publicado en la normativa de la asignatura la evaluacin de la prctica supone un 20

% sobre el total de la nota final. Es decir, la nota del examen se pondera en rango [0...10] al 80% y

la de esta prctica en rango [0...10] al 20% de manera que: NotaFinal = 0,8 !NotaExamen + 0,2 !

NotaPrctica

Lo que se describe a continuacin es cmo se computa el valor de NotaPrctica a partir del

resultado de los pasos de evaluacin descritos en la subseccin 5.1. Describiremos los factores que

intervienen en la calificacin de forma aislada:

1. Sesin de control [SC]. Para aprobar la sesin de control nicamente es necesario que elTutor registre la asistencia del alumno. Recomendamos que el alumno se asegure de este

hecho ya que de no figurar como presentado en la misma, la prctica estar suspensa. De

cara al cmputo numrico, considere que esta calificacin es 1 en caso de asistencia y 0 en

caso contrario. El Centro slo tiene obligacin de celebrar una sesin para cada grupo de

alumnos en los que divida sus matriculados y por cada curso acadmico.

2. Cdigo de la prctica [CP], que valorar el Tutor en un rango de 0 a 10 segn los criteriosque prescriba el Equipo Docente.

3. Cuadernillo del Estudiante [CE], que se puntuar de 0 a 10 de acuerdo a los criterios depuntuacin por pregunta establecidos dentro del propio cuadernillo.

A partir de esta informacin se pueden describir los criterios que asignan una calificacin final a la

nota de la prctica por aplicacin de la siguiente frmula, donde deben cumplirse para computar la

frmula las siguientes restricciones: SC = 1, CP "4, CE "4.

NotaPrctica = SC !( 0.6 x CP + 0.4 x CE )