Alfredo Juarez

La usabilidad es un tema que no muchas empresas en México toman en cuenta a la hora de diseñar/desarrollar una aplicación o un sitio Web. El Centro de Estudios de Usabilidad A.C nos presenta este Slide que habla acerca de los beneficios de la usabilidad, su lectura es altamente recomendable.

Se trata de improvisar el diseño de un código existente. No estás agregando nuevas características, solo estás moviendo, separando, combinando, eliminando y renombrando. Es una manera de mantener el código flexible para que éste siempre sea sencillo de mantener y agregar nuevas características, aún y cuando crezca en complejidad.
La refactorización reestructura la parte interna del código fuente sin alterar su comportamiento externo. Mejor conocido como el proceso de limpiar el código, en ingeniería de software se usa a menudo como parte del desarrollo de software, de esta manera los desarrolladores alternan la inserción de nuevas funcionalidades y casos de prueba con la refactorización del código para mejorar su consistencia interna y su claridad.
La refactorización es la parte del mantenimiento del código donde no se arregla errores ni se añade funcionalidad. El objetivo, por el contrario, es mejorar la facilidad de comprensión del código o cambiar su estructura y diseño, así como eliminar código muerto, para facilitar el mantenimiento en el futuro.
Sin la refactorización, es fácil de entrar en una vía de un solo camino que guía directamente a la muerte del programa. Entre más pobre sea la estructura del código, más tendencias tienes a llegar a lo que se le llama “programación aproximada”, es decir, se refiere al hecho que si no entiendes tu propio código, puedes seguir metiéndole cosas y moviéndole hasta que encuentres algo que funcione. Desafortunadamente, programación aproximada embrolla el código aún más y hace el trabajo más duras la próxima vez. Frecuentemente, terminarás con la necesidad de re-implementarlo todo.
Hay muchas maneras conocidas y desconocidas de refactorización. Martin Fowler y otros nos han hecho el favor de catalogar un numero de técnicas de refactorización. El libro de Fowler Refactoring tiene instrucciones específicas, paso a paso de cómo hacer cada uno de ellos.
Pruebas automáticas son la clave de la refactorización. Ellos hacen posible probar el código entre cada paso pequeño en la refactorización. Hacer este tipo de pruebas repetidas manualmente puede ser por mucho una tarea que consume mucho tiempo. Así que, si no tienes pruebas automáticas, tu probarás el código hasta el final de la refactorización. Cuando finalmente empieces a probar, pudieras encontrar muchos bugs.

La mayoría de aplicaciones requieren de interacción con una base de datos, ya sea del tipo relacional u orientada a objetos y en la mayoría de los casos la persistencia de datos está mezclada con la lógica del negocio. Lo que supone un problema a la hora de querer cambiar el motor de base de datos.

Para entenderlo mejor formularemos un ejemplo de la vida real.

Imaginemos que estamos desarrollando una aplicación en la empresa donde trabajamos y estamos utilizando MySQL como motor de base de datos. Estamos en la fase de pruebas (ya a punto de publicar el producto final), y por alguna extraña razón a tu jefe se le ocurre que mejor deberíamos usar Oracle, por que se lo recomendaron, piensa que es mejor, etc.

Que pasa si tenemos todo mezclado (lógica del negocio, métodos de acceso a datos, etc), se convierte en una tremenda pesadilla.

Para nuestra suerte existe el patrón de diseño Data Access Object (DAO), que se encarga de encapsular la interacción de una aplicación con la base de datos.

¿Como funciona?

DAO encapsula el acceso a la base de datos, de esta manera cuando la capa de lógica de negocio necesite interactuar con la base de datos, ésta utilizará los métodos ofrecidos por DAO. Generalmente la clase de operaciones que ofrece la capa de datos se le conoce como CRUD (Create, Read, Update y Delete).

Cuando la capa de negocios necesite almacenar datos (por ejemplo) solo tendrá que hacer referencia al método correspondiente para insertar los datos de la clase DAO, de esta manera si en algún momento se llegara a optar por usar otro motor de búsquedas, la capa del negocio no se debe preocupar ya que sólo bastará con actualizar la capa de datos. Si hablamos de patrones algunos detectarán por aquí que se están delegando responsabilidades, una buena práctica de la orientación a objetos.

De hecho el método de persistencia no debe de interesarle a la capa de negocios, es decir, a él no le importa si los datos se guardan en una tabla MySQL, XML, Texto plano o se imprime, de esto se encarga DAO.

Por cada tabla de una base de datos relacional existirá un DAO. Esto consiste básicamente en una clase que es la que interactúa con la base de datos. Los métodos de esta clase dependen de la aplicación y de lo que queramos hacer. Pero generalmente se implementan las 4 funciones básicas (también conocidas como métodos CRUD).

Una vez entendido el funcionamiento de DAO, es conveniente explicar un nuevo término que nos será de ayuda para completar la implementación de nuestra capa de persistencia. Se trata de los DTO’s (Data Transfer IObject), los cuáles son utilizados por DAO para transportar los datos desde la base de datos hasta la capa de lógica de negocio o vice versa.

En pocas palabras un DTO es un objeto que en su interior tiene como atributos los mismos atributos del modelo, con sus correspondientes accessors (Setters y Getters).

Diagrama DAO

Ahora veamos un ejemplo

Tenemos una aplicación que entre una de sus tantas funciones es controlar los datos de clientes, y queremos usar DAO para el manejo de la persistencia de dicha aplicación.
Primero que nada de define el modelo 8en este caso de clientes), para después partir con la codificación de los respectivos DTO y DAO.

DTO

Class ClientesDTO
{
      private $id;
      prívate $nombre;
      prívate $direccion;

      public static function getID( )
      {
          return $this->id;
      }

      public static function getName( )
      {
          return $this->nombre;
      }

      public static function getAddress( )
      {
          return $this->direccion;
      }

      /* Setters */
      Public static function setID( $id )
      {
          $this->id = $id;
      }
      Public static function setName( $name )
      {
          $this->nombre = $name;
      }
      Public static function setAddress( $address )
      {
          $this->direccion = $address;
      }
}

DAO

class clientesDAO
{
     public static function create( $dto )
     {
          /* implementación para la creación de un nuevo registro */
     }

      /* aqui van los demás metodos CRUD */
}

Por obvias razones no escribí todo el código necesario ya que este artículo es meramente informativo, pero pienso que es explicito el ejemplo para comprender el uso del patrón DAO.
En la próxima entrega les mostraré un ejemplo más real, utilizando una mezcla de patrones, como el DAO, Singleton, Factory y Façade.

¿De que se compone el desarrollo de software? Hay un numero de fases comunes a cada desarrollo, sin importar la metodología, empezando por la captura de requisitos y terminando por el mantenimiento. Con los nuevos paradigmas, en la otra mano, puedes realizar cada una de las fases mas de una vez en cualquier momento.

• Requisitos
• Análisis
• Diseño
• Especificación
• Implementación
• Pruebas
• Despliegue
• Mantenimiento

Preguntas claves

Requisitos
¿Cual es nuestro contexto?
¿Qué tratamos de adquirir?

Análisis
¿Con que entidades estamos tratando?
¿Cómo podemos estar seguros que hacemos lo correcto?

Diseño

¿Cómo vamos a resolver el problema?
¿Qué hardware y/o software se necesitará para el sistema final?

Diseño del subsistema

¿Cómo vamos a implementar la solución?

Especificación

¿Qué reglas gobiernan entre las interfaces y los componentes del sistema?
¿Podemos eliminar ambigüedades y asegurar lo correcto?

Implementación

¿Cómo programaremos las los componentes para completar los requisitos?
¿Cómo escribimos código estilizado?

Pruebas

¿Satisface los requisitos?
¿Podemos quebrar el sistema?

Despliegue

¿Qué tienen que hacer los administradores del sistema?
¿Cómo podemos educar a los usuarios finales?

Mantenimiento

¿Podemos encontrar y resolver errores?
¿Podemos mejorar el sistema?

Jon wiley es un diseñador de experiencia al usuario en Google, el cuál ha mencionado 10 lineamientos que rigen el diseño de aplicaciones dentro de Google. Creo conveniente publicarlas por que así como le han servido de gran ayuda a Google, son lineamientos que todos deberíamos seguir.

1. Useful: focus on people – their lives, their work, their dreams.
2. Fast: every millisecond counts.
3. Simple: simplicity is powerful.
4. Engaging: engage beginners and attract experts.
5. Innovative: dare to be innovative.
6. Universal: design for the world.
7. Profitable: plan for today’s and tomorrow’s business.
8. Beautiful: delight the eye without distracting the mind.
9. Trustworthy: be worthy of people’s trust.
10. Personable: add a human touch.

No se si tengan algún problema por dejarlos en inglés, pero para los que prefieran aqui les va en español:

Usable: Enfócate en las personas – sus vidas, su trabajo, sus sueños.

Rápido: cada milisegundo cuenta.

Simple: simplicidad es poder.

Acoplamiento: acopla a principiantes y atrae a los expertos.

Inovador: Atrévete a ser inovador.

Universal: diseña para el mundo.

Provechoso: planea para el negocio de hoy y mañana.

Hermoso: deleita al ojo sin distraer a la mente.

Digno de confianza: sé digno con la confianza de la gente.

Personal: agrega un toque humano.