Práctica #2. Patrón de diseño Factory Method. 2.1 Objetivos. 2.2 Práctica a realizar

Transcripción

1 Práctica #2 Patrón de diseño Factory Method 2.1 Objetivos El objetivo de esta práctica es consolidar los conceptos vistos en teoría sobre el PD Factory Method. Para ello es aconsejable que haya asistido a las clases previas de teoría y haya repasado los apuntes de las mismas. Vamos a utilizar este patrón para crear un framework de autenticación de aplicaciones genérico, de forma que las aplicaciones objeto de autenticación puedan decidir (en tiempo de compilación) con qué tipo de autenticación concreta van a trabajar. 2.2 Práctica a realizar Esta práctica es una extensión de la práctica sobre el PD Singleton. En ella vamos a proporcionar a nuestro paquete de autenticación (isw2.lab3.loginv0) de una política de rechazo genérica, de forma que la nueva versión (isw2.lab4.loginv1) puede ser utilizada desde una aplicación con una política de rechazo concreta. El siguiente requisito funcional recoge el nuevo aspecto a tener en cuenta:

2 12 Práctica #2. Patrón de diseño Factory Method FRQ 002 Versión Autores Descripción Estabilidad Comentarios Política de rechazos 1.0 (Abril/2005) ffl David Ruiz (Universidad de Sevilla) El sistema deberá tener en cuenta los intentos de acceso erróneos, añadiendo en el registro de actividad el evento correspondiente. Alta En la primera versión de la aplicación, cuando se produzca un fallo en la autenticación no se hará nada pero se impedirá el acceso a la aplicación. En sucesivas versiones, esta política de rechazo puede cambiar, pero nunca será opcional en tiempo de ejecución. Con este requisito, se puede utilizar el PD Factory Method para poder crear en tiempo de compilación distintas políticas de rechazos. 2.3 Desarrollo de la práctica El diagrama de clases de la práctica es el que se muestra en el Figura 2.1. El primer paso que daremos será crear un nuevo proyecto Lab 4. Factory Method y dentro del mismo el paquete isw2.lab4.loginv1. Dentro de este paquete copiaremos todas las clases del paquete de la practica anterior (isw2.lab3.loginv0. Además generaremos una biblioteca Java traverv0.jar a partir del paquete isw2.lab3.tracerv0, también de la práctica anterior. Por último, crearemos un paquete isw2.lab4.application en el copiaremos la clase visual ApplicationFrm de la práctica anterior. Ya estamos en disposición de empezar con la nueva versión del framework y1. Para ello, lo primero que vamos a hacer es añadir los nuevos interfaces IRefusePolicy e IRefusePolicyFactory, que contendrán las definiciones de los métodos fault(int) y IRefusePolicy create(int), respectivamente. La distintas implementaciones que se proporcionen de IRefusePolicy serán las que lleven a cabo la política de rechazo concreta en función al número de errores consecutivos a través de la implementación concreta que se se haga del método fault(int). Por otro lado, las posibles implementaciones de IRefusePolicyFactory llevarán a cabo la instanciación de los objetos con los políticas concretas en tiempo de ejecución. Fíjese que la responsabilidad de crear estos objetos no puede recaer en la clase Login ya que ésta es un singleton y no puede contener métodos abstractos. y1 Aclarar aquí por qué empezamos a hablar de frameworks

3 2.3. Desarrollo de la práctica 13 isw2.lab4.loginv1 <<Interface>> IResource +run() LoginFrm -dologin() -doexit() <<singleton>> Login +Login getinstance() +getusername(): string +setusername(string) +setpassword(string) +getresource(): IResource +setresource(iresource) +authenticate() +setrefusepolicy(irefusepolicy) +fault(int) <<Interface>> IRefusePolicyFactory +IRefusePolicy create(int) <<Interface>> IRefusePolicy isw2.lab4.application Isw2.lab4.refusepolicies uses ApplicationFrm RefusePolicyFactory +IRefusePolicy create(int) StrictPolicy WaitPolicy uses Test WarningPolicy NaivePolicy +test(string policy) isw2.lab3.tracerv0 <<singleton>> Tracer Figura 2.1: Vista lógica de las capas de la aplicación.

4 14 Práctica #2. Patrón de diseño Factory Method En la clase Login tendrá una propiedad RefusePolicy en la que se almacenará la referencia a la política de rechazos. De esta forma, el método validate() queda ahora de la siguiente forma: boolean validate() { boolean result = false; if (password.compareto(masterpassword) == 0) { Tracer.getInstance().addLine(getUsername() + " logged"); result = true; else { Tracer.getInstance().addLine(getUsername() + " refused"); if (refusepolicy!= null) { nfallos++; refusepolicy.fault(nfallos); return result; Las implementaciones de las distintas políticas de rechazo las vamos a crear en el paquete isw2.lab4.refusepolicies. En el caso de una política de rechazo estricta que lo que haga sea abortar la ejecución en caso de error en la autenticación tendríamos: public class StrictPolicy implements IRefusePolicy { public void fault(int i) { System.exit(1); Para hacer que nuestra aplicación use esta política de rechazos lo que tenemos que hacer es escribir el código de RefusePolicyFactory, por ejemplo: public class RefusePolicyFactory implements IRefusePolicyFactory { public static final int STRICT_POLICY = 1;... public IRefusePolicy create(int p) { IRefusePolicy result = null; switch (p) { case STRICT_POLICY : result = new StrictPolicy(); break;...

5 2.4. Cuestiones 15 return result; Para hacer un test con esta política: public void teststrict() { Login.getInstance().setResource(new ApplicationFrm()); Login.getInstance().setRefusePolicy( (new RefusePolicyFactory()).create(RefusePolicyFactory.STRICT_POLICY)); Login.getInstance().authenticate(); 2.4 Cuestiones I CUESTIÓN 2.1: Añada las siguientes políticas de rechazos: Naive: No hace nada. Warning: Muestra por la consola el número de fallos y continua con la ejecución. Wait: Introduce un tiempo de espera en segundos igual al número de fallos. Se recomienda que use el paquete ActiveDelayer proporcionado. I CUESTIÓN 2.2: abstracta. Diserte sobre si es posible o no que la clase Login sea I CUESTIÓN 2.3: Plantee otra solución (modificando todo lo necesario tanto en el framework como en la aplicación) para hacer recaer la responsabilidad de crear las distintas políticas de rechazo en la clase Login. I CUESTIÓN 2.4: Es correcto utilizar el término framework de autenticación en lugar de biblioteca de autenticación? En este sentido, qué diferencias existen entre el sistema de autenticación de la primera práctica con respecto a esta? I CUESTIÓN 2.5: Qué repercusiones tiene añadir el método constructor create() al interfaz IRefusePolicy?

6 16 Práctica #2. Patrón de diseño Factory Method I CUESTIÓN 2.6: Plantee otra solución (modificando todo lo necesario tanto en el framework como en la aplicación) en la que el interfaz IRefusePolicyFactory pase a ser una clase abstracta y que el framework incorpore las políticas de rechazos implementadas en la primera cuestión. De esta forma, cómo se crearía desde la aplicación una nueva política de rechazos?