INGENIERÍA DEL SOFTWARE. 4º ING. INFORMÁTICA (UPV/EHU) 3 de SEPTIEMBRE de 2003 NOMBRE:

GRUPO:

1ª pregunta) (0,5 ptos.) (Tiempo estimado: 5 minutos) ¿Qué es una aplicación Web y cuál crees que es la ventaja más destacable de este tipo de aplicacio nes? Una aplicación Web es una aplicación cuyo nivel de presentación se ejecuta en un navegador Web. La ventaja más importante es que no hay que instalar nada de dicha aplicación en el cliente (el cliente debe tener instalado un navegador Web y la conexión a internet, por supuesto). Además, cambios futuros en la aplicación que afecten al nivel de presentación se instalarán en el servidor Web y no en el cliente. 2ª pregunta) (3,5 ptos.) (Tiempo estimado: 45 minutos) A continuación se muestra el enunciado del ejercicio 4 de l examen de junio de 2003 junto con su solución, que supondremos está ya implementada, y se presentan unos cambios en los requisitos que se deben realizar.

ENUNCIADO:

La siguiente clase (Presentacion.java) implementa el caso de uso SOLICITAR COMIDA, que muestra una lista de primeros platos, otra de segundos platos y permite solicitar una comida compuesta por un primer y un segundo plato.

Los nombres de los platos se obtienen de la siguiente tabla PLATO y las solicitudes de comidas se almacenan en la tabla PEDIDO.

Se pide: Proponer una solución que utilice una arquitectura física en 3 niveles y que además sea extensible ante el siguiente “posible” nuevo requisito: los menús podrán estar formados por otros tipos de platos (como postres, entrantes , etc.) como aparece en la siguiente interfaz de usuario. Con que la solución sea extensible nos referimos en concreto a que no debería cambiar ni el nivel de presentación ni el de la lógica del negocio una vez que ese nuevo requisito fuera incor porado a la aplicación. Tan sólo el nivel de datos podría cambiar. Indicar cuáles serían esos cambios.

En la solución propuesta deben mostrarse las clases necesarias en notación UML, junto con la signatura de los métodos de las mismas. No hay que implementar la solución, pero sí se debe mostrar el uso de Java RMI, Java JDBC e interfaces Java. Esto se puede representar por medio de dependencias “usa”, generalizaciones e implementación de interfaces en UML.

SOLUCIÓN: «interface» java.rmi.Remote

Presentacion

«uses»

-logNeg : Menus

«interface» Menus +getTiposPlatos() : Enumeration +getPlatos(in tipoPlato : string) : Enumeration +solicitarMenu(in platos : Enumeration)

«uses» java.sql «datatype» java.rmi.UnicastRemoteObject

ServidorMenus

NOTA referente a ServidorMenus: =========================== Hace rebind("rmi://localhost:"+puerto+"/menus", objetoServidor) Se supone que se ejecuta en la máquina "serv" NOTA referente a Presentacion: ==========================

Abre una conexión con una BD con estas tablas

Hace lookup("rmi://serv:"+puerto+"/menus") y dejar en logNeg

PLATO(nombre,tipo) PEDIDO(num,primeros,segundos,...)

Crea tantos JLabel y JComboBox como elementos haya en logNeg.getTiposPlatos() En el JLabel i-ésimo pondremos el tipo de plato i-ésimo En el JComboBox i-ésimo se pondrán los platos devueltos por logNeg.getPlatos("tipo de plato i-ésimo")

getTipoPlatos() preguntaría "select tipo from PLATO" getPlatos(t) preguntaría "select nombre from PLATO where tipo= %t" solicitarMenu(platos) realizaría el insert: insert into PEDIDO (num,%tipoPlato[1],%tipoPlato[2],...) values (NUMNUEVO,%platos[1],%platos[2],...) con platos[i] el nombre del plato pasado en el parámetro "platos" y tipoPlato[i] es el tipo correspondiente a dicho plato NOTA: el nombre del tipo de plato en la tabla PLATO coincide con el nombre del atributo en la tabla PEDIDO

Si se añadiera un nuevo tipo de plato (pongamos “Entremeses”), sólo habría que cambiar la BD: - En la tabla PLATO añadiríamos las tuplas: , ,... - En la tabla PEDIDO añadiríamos una columna llamada “Entremeses”

Cambios en los requisitos. A partir de este momento nos indican que “existen platos incompatibles con otros, esto es, que no pueden ser solicitados en un mismo menú”. Por ejemplo: si se pide macarrones no se puede pedir filete. Cada incompatibilidad está formada por un plato de un grupo y otro plato de otro grupo distinto. Además se desea que cuando el usuario seleccione uno de los platos en la interfaz gráfica (en la lista desplegable correspondiente), automáticamente se eliminen sus platos incompatibles en las listas desplegables correspondientes a los demás tipos de platos. Se pide: 1) Indicar si dichos cambios deben afectar al nivel de presentación, al nivel de lógica del negocio o al nivel de datos, razonando la respuesta. (0,5 ptos .) ¿Afectan al nivel de presentación? Sí / No ¿Por qué? Sí, ya que el cambio indicado afecta directamente a la interfaz gráfica: al seleccionar un plato deben quitarse sus platos incompatibles de las demás listas desplegables. ¿Afectan al nivel de lógica del negocio? Sí / No ¿Por qué? Sí, ya que el cambio propuesto es una nueva regla de negocio: no se servirán platos incompatibles en un mismo menú. La lógica del negocio debe proporcionar operaciones o servicios que garanticen dicha regla de negocio. ¿Afectan al nivel de datos? Sí / No ¿Por qué? Sí, ya que se debe almacenar qué platos son incompatibles entre sí. Se supone que no serán siempre los mismos ni tendrán por qué ser conocidos desde el principio.

2) Realizar los cambios que se consideren necesarios (en el diagrama de clases UML, en la base de datos, etc.) para adaptar el caso de uso “Solicitar Menu” a los nuevos requisitos. Indicar además cómo sería la implementación (sólo en qué cambiaría la implementación actual que se supone ya tenemos) (3 ptos.)

NOTA: no se pide realizar los cambios para añadir platos incompatibles en el sistema. Sólo los necesarios para que el CU “Solicitar Menu” funcione.

«interface» java.rmi.Remote

Presentacion -logNeg : Menus

«uses»

«interface» Menus +getTiposPlatos() : Enumeration +getPlatos(in tipoPlato : string) : Enumeration +solicitarMenu(in platos : Enumeration) +getPlatosIncompatibles(in platosEscogidos : Enumeration) : Enumeration

«uses» java.sql «datatype» java.rmi.UnicastRemoteObject

ServidorMenus

NOTA referente a Presentacion: ========================== Cada vez que se cambie la selección en un JComboBox habrá que cambiar los contenidos de todos los demás JComboBoxes El contenido del JComboBox i-ésimo tendrá los platos devueltos por logNeg.getPlatos("tipo de plato i-ésimo") excepto los platos que correspondan al "tipo de plato i-ésimo" devueltos por logNeg.getPlatosIncompatibles("platos escogidos en todos los JComboBox") NOTA referente a ServidorMenus: =========================== Existirá una nueva tabla INCOMPATIBLES(plato1,tipoPlato1,plato2,tipoPlato2) La llamada a getPlatosIncompatibles(platosEscogidos) donde platosEscogidos será una Enumeration En cada par , "pei" es el plato escogido de tipo "tpei" devolverá una Enumeration donde representa a un plato pi de tipo tpi que es incompatible con alguno de los platos escogidos La implementación del método getPlatosIncompatibles se conseguirá realizar con esta pregunta: select plato2,tipoPlato2 from INCOMPATIBLES where (plato1=pe1 and tipoPlato1=tpe1) or (plato1=pe2 and tipoPlato1=tpe2) ... or (plato1=peN and tipoPlato1=tpeN) NOTA: hemos optado por esta opción para tener un único método de atención común a todos los JComboBox y para que sea más sencillo el problema de volver a añadir los platos incompatibles al plato anteriormente seleccionado en un JComboBox

3ª pregunta) (2,5 ptos.) (Tiempo: 45 minutos) En una estructura Java tenemos un conjunto de instancias de la clase Persona (int edad, String nombre, int sueldo, int primas, Container hijos). Sobre esta estructura queremos definir una aplicación que haga uso de JGL y que permita: a) Visualizar ordenados por nombre, las personas mayores de 35 años, cuyo b) c)

sueldo total sea mayor de 30.000. Visualizar las personas, cuyo sueldo familiar sea mayor que 50.000. Visualizar las personas que tengan al menos un hijo que esté trabajando (sueldo>0). ¿Sería parametrizable la solución dada al apartado c) para responder a la siguiente pregunta? Visualizar las personas que tengan al menos X hijos que estén trabajando con un sueldo>Y.

4ª pregunta) (2,5 ptos.) (Tiempo: 45 minutos) En JGL tenemos un conjunto de

algoritmos disponible para su utilización. Sin embargo el usuario debe conocer exactamente cuál es el nombre del algoritmo para utilizarlo. Por ello queremos realizar una aplicación que permita a los usuarios solicitar un algoritmo a partir de un número y a continuación ejecutar el algoritmo. En este primer prototipo los algoritmos que vamos a utilizar tienen los MISMOS parámetros de entrada pero devuelven objetos DISTINTOS: 1. Container Filtering.select(Container c, UnaryPredicate up); 2. Integer Counting.countIf(Container c, UnaryPredicate up);

3. Boolean Finding.some(Container c, UnaryPredicate up); Se pide: 1. Diseña r un modelo de clases que recoja esta especificación, indicando claramente qué patrones se han utilizado en cada caso. 2. Implementar las clases del diseño. 3. Implementar un programa que cree un contenedor de Personas (suponemos que el constructor de Personas realiza la carga de los datos ), y devuelva como resultado cuántas personas son mayores de edad. Los atributos de persona son nombre y edad.

5ª pregunta) (1 pto.) (Tiempo: 20 minutos) Implementar un EJB (únicame nte las

interfaces remotas) y el Bean que permita utilizar los algoritmos de JGL como si fuesen un componente: void sort(Container c, BinaryPredicate) int countIf(Container c, UnaryPredicate up) Container select(Container c, UnaryPredicate up) NOTA: Las interfaces javax.ejb.EJBHomeObject

extienden

de

las

clases:

javax.ejb.EJBObject

y