Evaluando el diseño

Antes de empezar a desarrollar una aplicación, es conveniente revisar el diseño lógico para asegurar que es esta completo y correcto. Esto viene a ser evaluar el diseño en los siguientes terminos:

• Evaluación de ejecución:
  • Rendimiento.
  • Escalabilidad.
  • Disponibilidad.
  • Recuperación.
  • Seguridad.
• Evaluación de la arquitectura:
  • Mantenibilidad.
  • Extensibilidad.
• Evaluación de los requerimientos:
  • Casos de uso.

La evaluación del rendimiento determina la velocidad de ejecución de la aplicación. Desde el diseño lógico, tiene dos puntos fundamentales:

• Las capas: Asegurar que no se ha dividido en demasiadas capas. Normalmente 3 son suficientes, aunque puede necesitarse más si existen motivos razonables.
• Los niveles de abstracción: Hay que evitar niveles de abstracción innecesarios en las clases. Un abuso podría producir una perdida de rendimiento al forzar al flujo de ejecución a pasar por demasiados objetos.

A nivel de diseño lógico, evaluar el rendimiento queda limitado a la búsqueda y supresión de redundancias.

La evaluación de la escalabilidad determina la capacidad de la aplicación para adaptarse al aumento de carga y/ó número de usuarios. Es importante asegurar que dispone de una ó varias capas intermedias separadas, de forma que dichas capas puedan ser puestas en otras máquinas, como por ejemplo en un servidor de gran capacidad mediante Remoting.

La evaluación de la disponibilidad y recuperación determina la capacidad de la aplicación para recuperarse y tomar contramedidas en situaciones catastróficas. Es importante asegurar que las clases pueden:

• Usar transacciones fiables, ya sean de base de datos, MSMQ, System.EnterpriseServices, DTC, ...etc... De forma que en caso de falla no quede una operación colgada a mitad de realizarse.
• Reconstruir archivos de datos y configuración corruptos por un fallo de continuidad en el hardware, como una perdida de alimentación.
• Tomar fuentes de datos ó servicios redundantes en caso de perdidas de conectividad ó fallos del hardware remoto.

La evaluación de la seguridad determina la capacidad de la aplicación para proteger "sus secretos" (contraseñas, cadenas de conexión, datos sensibles, ..etc..). Los pilares fundamentales son:

• Autenticación: Solicitar que el usuario se autentique para poder usar la aplicación, por ejemplo a través de 'Active Directory' ó un sistema propio de contrastar usuarios/contraseñas. Es importante que si se usa un sistema propio, no se almacenen las contraseñas si no sus Hash.
• Cifrado: Asegurar que los datos sensibles que necesariamente se han de guardar en disco, solo puedan ser usados por el usuario que los creo. Por ejemplo, usando la DPAPI. Se debe reducir al máximo el guardado de archivos temporales con datos sensibles. Crear un almacenamiento aislado es una buena opción para ello.
• SQL-Injections: Asegurar que desde ningún formulario de la aplicación ó punto visible se puede realizar una injección de código SQL. La mejor forma de evitar esto es usando parámetros para construir las sentencias SQL.
• Auditoria: Se debe auditar los procesos de autenticación y autorización, de forma que podamos comprobar si hay usuarios intentando acceder a datos protegidos ó intentando autenticarse por fuerza bruta.
• Firmar los ensamblados con nombres seguros para que solo el autor original de la aplicación pueda substituirlos.

La evaluación de la mantenibilidad determina la facilidad con la que la aplicación podrá se mantenida una vez puesta en producción. Siguiendo un diseño en capas y modular se asegura que los cambios podrán realizarse substituyendo piezas de la aplicación y no la aplicación entera.

La evaluación de la extensibilidad determina si el código de la aplicación es rehusable ó si se puede implementar con soluciones ya hechas, bien en el .NET Framework ó de nuestra propia empresa. Usando código ya existente aseguramos que utilizamos cosas ya probadas y ahorramos costes de desarrollo.

La evaluación de la integridad de los datos determina dos cosas:

• La capacidad de la aplicación para mantener los datos acorde al esquema de la fuente, de forma que se respeten resticiones, tipos y contratos, asegurando así que la fuente no rechazará los datos cuando le sean enviados.
• La capacidad de la aplicación para lidiar con la concurrencia de los datos. Existen dos tipos de concurrencia:
  • Optimista: Los datos no se bloquean mientras estan siendo leidos por otro usuario. Mejor rendimiento pero se tiene el riesgo de que los datos cambien mientras están siendo leidos, y podrían tomarse decisiones erróneas.
  • Pesimista: Los datos se bloquean mientras están siendo leidos por otro usuario. Peor rendimiento pero asegura que cuando un usuario lee un dato, ese dato no cambiará hasta que termine de trabajar con él.

La evaluación de los casos de uso determina si la aplicación sigue cumpliendo con los requerimientos. Se intenta buscar inconsistencias ó ambiguedades en el diseño lógico.

Resumen de la lección 3.1 del libro oficial de Microsoft para obtener el MCPD:WinApps.