Category: Arquitectura

HTML, Javascript, CSS, ASP.NET, WCF, WPF, C#, PL/SQL…
Una multitud de herramientas a las que se enfrentan ya con soltura desarrolladores web (especialmente sobre plataforma Microsoft) y para las que nadie cae ya en la dificultad inicial y conceptual que representa la pregunta: ¿dónde se ejecutan las cosas?
Pregunta que sin lugar a dudas es fundamental resolver al inicio, para formaciones orientadas a nuevos profesionales del desarrollo web, especialmente para aclarar muchos conceptos derivados del funcionamiento de ASP.NET, y su transformación/creación al vuelo de HTML, CSS y Javascript… por no hablar de temas especí­ficos de comunicación cliente-servidor y mantenimiento del estado de la página mediante uso del ViewState, Session, etc.
Un concepto tan básico para desarrolladores ya iniciados, como que cuando entramos en una web esta no se visualiza en el “limbo”, si no que es descargada una copia en local (seguramente después de un procesado de página en el servidor web) y que lo íºnico que hace el navegador es abrir dicha copia en local y renderizarla, no es algo que tengan tan claro los recién iniciados en este mundillo. Hay que saber contarlo y empezar por ahí­, ya que con esto comenzaremos a asentar conocimientos básicos de arquitectura, del mismo modo que empezaremos a dar margen a pensar en la usabilidad y tiempos de respuesta de la página al usuario (no es lo mismo ejecutar arriba que ejecutar abajo, ni resolver problemas mediante una llamada a servidor o mediante n, ni de forma sí­ncrona o así­ncrona).
Este punto deberí­a ser pieza clave, a la hora de comenzar el: Capí­tulo IV. Replicando en Web. El cual describí­amos en el artí­culo Metodologí­a de Formación para Nuevos Profesionales del Software
Saludos.
Miguel.

A continuación, basado en su uso y experiencia, traslado la metodologí­a que mejor resultado viene dando en la transmisión de conceptos de arquitectura y desarrollo de software a perfiles de profesionales recién licenciados sin experiencia, con experiencia leve, o experiencia focalizada en desarrollos especí­ficos web, escritorio o dispositivos móviles.
Puntualizar que la experiencia ha sido siempre lanzada utilizando como base tecnologí­a Microsoft.NET, la cual dispone de herramientas que dan cobertura completa a los conceptos de arquitectura a trasladar, pero esto no quiere decir que este método no pueda ser aplicado utilizando otras tecnologí­as de cobertura completa (Java por ejemplo) o incluso en combinación de varias (bajo mi punto de vista serí­a el objetivo a cumplir tras la primera fase del “curso” que hoy os vamos a trasladar).
Objetivos
En el momento de finalizar el curso el alumno debe haber asentado su conocimiento sobre los siguientes conceptos
1) Entorno de desarrollo tipo
2) Desarrollo de arquitecturas orientadas a n-capas
3) Desarrollo de aplicaciones SOA
4) Buenas y malas prácticas de programación
5) Diferencias fundamentales en el desarrollo de aplicaciones web y escritorio
6) Trabajo colaborativo y en equipo
7) Importancia de las pruebas en el proceso de desarrollo
8) Despliegue de aplicaciones en entornos no accesibles
9) Dinámica de proyecto
Mientras que los objetivos del instructor son
1) Adaptar la formación a un escenario tipo de proyecto, el alumno desde el primer dí­a debe entrar en la dinámica del dí­a a dí­a de un proyecto real
2) Identificar áreas de mejora de los alumnos, tanto técnicas como no técnicas
3) Identificar puntos fuertes y puntos de mejora del alumno
4) Identificar puntos de mejora del propio método de formación
Requerimientos Previos
Referidos a los alumnos (en orden de importancia):
1) Programación orientada a objetos
2) Definición de modelos entidad-relación
3) HTML básico
La falta de conocimiento de alguno de estos puntos, requerirá que el instructor incorpore a la formación módulos adicionales que cubran la visión necesaria al respecto.
Otros valores deseables ajenos a las capacidades técnicas
1) Pro actividad
2) Eficacia
3) Eficiencia
4) Trabajo en equipo
5) Liderazgo
6) Confianza
7) Capacidad de trabajo
8) Nivel de interlocución
Es labor del instructor identificar puntos de mejora también en estos aspectos, potenciándolos durante el proceso formativo. No solo estamos formando a nivel técnico, también estamos formando profesionales que van a ser parte fundamental de proyectos de desarrollo que requerirán de aptitudes no solo técnicas para lograr el éxito del proyecto.
Referidos al instructor:
1) Profesional consolidado en conocimientos de arquitectura y en la tecnologí­a/tecnologí­as de desarrollo que se desarrollan en el curso.
2) Experiencia de trabajo en proyectos, habiendo participado/liderado procesos de captura de requerimientos, definición de arquitecturas y procesos de implantación/despliegue, gestión de equipos, diseños funcionales, diseños técnicos, supervisión del trabajo de otros programadores y construcción.
3) Nivel de interlocución medio-alto
4) Experiencia en sesiones formativas
En resumen y por poner un sí­mil en consultorí­a, las habilidades esperadas de un Jefe de Equipo.
Bases Fundamentales de la Metodologí­a
* Dinámica de proyecto desde el primer dí­a
* Curso eminentemente práctico
* Grupos de formación pequeños (entre 5 y 10 alumnos máximo por instructor)
* No solo centrarse en las habilidades técnicas
* Que el alumno de el primer paso: resolver el problema de forma completa con el conocimiento actual del alumno, a medida que se vayan incorporando conceptos nuevos (a posteriori) el alumno deberá resolver de forma completa el problema adaptando su solución e incorporando los nuevos conceptos adquiridos.
* El instructor no es el protagonista
Capí­tulo I: Definiendo requerimientos
Todo proyecto comienza a partir de un conjunto de requerimientos, por lo que si uno de nuestros principales objetivos es introducir al alumno en la dinámica del proyecto deberemos partir de un conjunto de requerimientos base. No es objetivo de esta formación introducir al alumno en el proceso de toma de requerimientos, por lo que nos mantendremos ajenos a él. Nuestro punto de partida puede ser un pequeño documento que describa un pequeño escenario o si queremos empezar desde ya a identificar capacidades no técnicas, un pequeña conversación (poniéndose el instructor la gorra del cliente) donde se describan los requerimientos a cubrir; es aquí­ donde el alumno debe comenzar a tomar notas y hacerse un pequeño esquema mental de la solución. No es una toma de requerimientos en sí­, ya que lo que hará el instructor será recitar verbalmente los requerimientos como si los estuviera leyendo.
Dependiendo de a dónde queramos llegar elegiremos uno de los dos métodos, eso sí­, es fundamental que sea cual sea el formato seleccionado, se abra un espacio para dudas y preguntas por parte del alumno. Es así­ como comenzaremos a matizar el alcance, reglas de negocio, otros requerimientos, etc; además de comenzar a identificar habilidades no técnicas del alumno.
¿Y qué vamos a construir? Bajo mi punto de vista deberí­amos definir una herramienta que motive al alumno, pero cuyo funcionamiento a bajo nivel resulte algo ajeno. Es decir, evitarí­a temas muy comunes como el desarrollo de una aplicación de gestión para bibliotecas o temas muy complejos como el desarrollo de una herramienta de gestión de cálculo de declaraciones de renta. Como un ejemplo no muy complejo tendrí­amos una herramienta tipo Facebook o Google+.
Capí­tulo II: Plazos e hitos
La propia definición de proyecto lo lleva de serie, los plazos. No hay proyecto sin un plazo de ejecución lí­mite, por lo que el alumno debe desde el primer dí­a ser consciente de esta realidad, trasladándole la tensión (que no presión) necesaria para mantener su motivación y dedicación al proyecto.
Este es el momento de trasladar al alumno cuál es la planificación de su primer proyecto (la planificación del curso), con cada uno de sus hitos intermedios y su hito final. Tanto el instructor como el alumno son los responsables de que dicha planificación se cumpla (no solo el instructor), cumpliendo adicionalmente todos los objetivos establecidos para el curso.
Para cada tarea el instructor establecerá tiempos lí­mite. El objetivo es que el alumno empiece a jugar con el tiempo, a saber cuándo puede dilatarlo y cuándo puede (normalmente más que puede debe) contraerlo. No podemos irnos por las ramas, atascarnos de forma permanente; si no podemos tomar un camino, busquemos otra alternativa. La calidad de los resultados tiene relación también con el tiempo, hay que saber jugar con estos conceptos.
Capí­tulo III: Desarrollo de aplicación de escritorio
Fase 1 – Familiarizarse con el entorno y la tecnologí­a
Como comentábamos al inicio, las formaciones de este tipo siempre han venido de la mano de tecnologí­a Microsoft .NET, por lo que el hilo argumental se basará en la experiencia con dicha tecnologí­a. Es en este punto donde cada instructor deberá adaptar los conceptos y herramientas a la tecnologí­a seleccionada.
En nuestro caso entonces, nuestro entorno de desarrollo podrí­a ser Visual Studio 2010 y nuestro framework el .NET Framework 4.0 (adaptar también dependiendo de los objetivos a lograr).
En esta primera fase, el instructor trasladará al alumno el funcionamiento básico del entorno de desarrollo:
* Tipos de proyecto
* Meníºs
* Teclas de acceso rápido
y de la tecnologí­a
* Framework .NET 4.0 (en nuestro caso de partida)
* Orientación a eventos
Fase 2 – Solucionar el problema con lo puesto, premisa: todo va en memoria
Manos a la obra, el alumno ya dispone de una versión mí­nima de funcionamiento del entorno y del framework y conoce los requerimientos a cubrir. El primer objetivo a proponer al alumno es el de construir un aplicativo de escritorio que cubra los requerimientos demandados por el cliente, obviando una de las partes fundamentales de una herramienta de gestión, como es el almacenamiento de la información en un modelo de persistencia no volátil (una base de datos o un conjunto de ficheros).
En este punto el instructor íºnicamente marca las siguientes premisas:
1) El alumno deberá describir en un pequeño documento las principales entidades implicadas y sus relaciones (no estamos hablando de un modelo relacional formal, simplemente queremos ver que el alumno ha entendido el requerimiento y se ha construido un mapa mental con la información a gestionar y las relaciones que existen entre ella).
2) Antes de iniciar la codificación, el alumno deberá diseñar en primer lugar las interfaces de usuario a partir del entorno visual (WYSWYG) que provee el propio Visual Studio. Interfaces sin comportamiento íºnicamente descripción de las pantallas.
3) Lí­mite temporal para realizar estas actividades.
Adicionalmente, el instructor puede esperar a ver con qué herramientas soluciona el problema del almacenamiento en memoria el alumno o trasladar una pista inicial que es el uso de listas genéricas, que es donde el instructor pretende que el alumno llegue. Una u otra opción dependerá del plazo temporal que estipulemos para esta primera fase.
El objetivo de esta primera fase se considera alcanzado cuando el alumno ha sido capaz de construir un aplicativo libre de errores con las nociones básicas de programación en objetos de las que cuenta, las nociones de entorno, de framework y la formación en el uso de listas genéricas. Nuestro aplicativo es un aplicativo que cubre el requerimiento sobre una aplicación de escritorio, pero con el pequeño gran defecto de que al cerrar el aplicativo toda la información almacenada en memoria se pierde.
Fase 3 – Primeras Pruebas
En este punto el alumno cuenta con una aplicación que cubre los requerimientos descritos por el cliente (o que deberí­a cumplirlos) y que está preparado para su uso masivo por parte del mismo (esperamos).
Es este el momento para trasladar la importancia del proceso de pruebas. Lo más normal es que el instructor en menos de 5 minutos haya conseguido explotar tanto vulnerabilidades del sistema (objetos no referenciados, validaciones que fallan, problemas de seguridad de acceso, navegaciones ineficientes, etc) y requerimientos que no se cumplen parcial o totalmente. Se debe estudiar cada una de las aplicaciones y trasladar de forma global a los alumnos cuáles han sido los problemas que se han detectado. Es fundamental que el instructor traslade al alumno la importancia del proceso de pruebas y verificación; se la ha de poner en la piel del cliente. El alumno debe afianzar la visión del cliente y quedarse con la máxima “me da igual cómo esté hecho por dentro, lo que te haya costado hacerlo y lo que cueste mantenerlo (esto íºltimo no deberí­a darle igual pero ya hablaremos de ese tema otro dí­a), necesito que funcione y solucione mi problema fácil y rápidamente”. La definición técnica y de arquitectura es básica para el éxito del aplicativo y su posterior mantenimiento, pero debemos transmitir a fondo en esta fase que ésta no es la prioridad principal del cliente, por lo que el desarrollador debe darle tanta importancia a los factores técnicos como a los factores de “cliente”. Como ya muchos de vosotros sabréis, los éxitos técnicos son estupendos y maravillosos (seguramente os hayan acusado de románticos más de una vez), pero no son suficientes si el aplicativo no hace lo que tiene que hacer o falla intentándolo; si el aplicativo no es usado, no hay éxito.
Resumiendo, no es objetivo de esta fase validar técnicamente el aplicativo, íºnicamente el instructor se debe poner la gorra del cliente y revisar el aplicativo a nivel de uso, siendo muy exigente con el resultado obtenido. Es buen momento para trasladar ciertas nociones de usabilidad al alumno y de establecer los mecanismos básicos de herramientas para llevar a cabo pruebas unitarias y funcionales.
Fase 4 – Trasladando buenas prácticas
El punto de entrada de esta fase es una aplicación que representa lo que el requerimiento dictamina, de forma usable y con una tasa de errores no significativa.
Es ahora el momento en el que el instructor deberá analizar cada uno de los aplicativos desarrollados por los alumnos de forma interna, evaluando cuáles son los principales problemas detectados. El nivel de conocimiento previo del alumno es el que va a marcar el camino a seguir a partir de ahora. Resalto a continuación los principales temas identificados como puntos de mejora en desarrolladores con experiencia media-baja.
* No aplicación de patrones de diseño y otras herramientas provistas por la programación orientada a objetos
* No se encapsula
* No se orienta el código a su mantenibilidad
* No se emplean estándares de codificación
* No se comentan los métodos, ni los parámetros, ni los fragmentos de código más complejos
* No se aplican las listas genéricas (si no lo hemos trasladado en una fase anterior)
* No se usan constantes
* Se hardcodean parámetros configurables a partir de ficheros externos
* No se emplean excepciones
* No hay separación entre capas
El alumno tendrá que refactorizar su código atendiendo a todas estas clausulas, logrando disponer nuevamente de una herramienta que cubra los mismos requerimientos y que pase el proceso de pruebas nuevamente. Lo interesante serí­a que estos conceptos se vayan dando de uno en uno, para que el alumno los vaya asentando individualmente.
Fase 5 – Concepto de capa de acceso a datos
Uno de los problemas que seguramente haya surgido en la primera fase es que no haya separación entre capas, es decir, que el alumno haya construido un aplicativo en el que desde el propio interfaz se esté aplicando la lógica de negocio y accediendo a nuestro repositorio de datos (que por ahora tenemos en memoria).
En este punto es donde vamos a tener que proponer una refactorización importante de código, ya que todo lo que tenga que ver con acceso a datos el alumno deberá moverlo a un conjunto de clases independientes agrupadas por entidades de datos. La interfaz debe dejar de saber dónde estamos almacenando el dato, pudiendo en un momento dado cambiar el modelo de almacenamiento (de memoria a una base de datos fí­sica) sin necesidad de modificar una sola lí­nea de código en la capa de presentación. En este punto es interesante trasladar el funcionamiento de patrones como DAO y DTO.
Nuevamente tras el desarrollo, el alumno deberá garantizar que la aplicación cubre los requerimientos y pasa el plan de pruebas, así­ como que ante un cambio de modelo de persistencia, la capa de presentación no va a sufrir ningíºn tipo de cambio.
Fase 6 – Definiendo un modelo relacional
El alumno ya deberí­a estar en disposición en este punto de modelar relacionalmente la solución. Para ello, se le provee en este caso de un acceso a una instancia de SQL Server 2008, donde va a poder definir el modelo relacional. Es en este punto donde el instructor deja definir al alumno el modelo sin aplicar ningíºn tipo de premisa, con el objetivo de identificar necesidades formativas al respecto.
El instructor deberí­a reforzar los siguientes conceptos
* Uso de claves primarias y foráneas
* Uso de relaciones 1-N y 1-1, definición de modelos entidad-relación basados en 3FN
* Abuso de la 3FN y problemas de rendimiento asociados
* Estándar de nomenclatura para campos y tablas
* Introducir comentarios descriptivos en campos y tablas
* Importancia de los í­ndices
* Concepto y programación de procedimientos almacenados (muchos recién licenciados salen de la carrera sin que nadie les haya contado que es un procedimiento almacenado y para qué sirve).
Fase 7 – Almacenando la información de forma persistente
Ya tenemos una capa de acceso a datos que realizamos en la fase 5 y un modelo de datos desarrollado en la fase 6; ahora nos queda preparar nuestra capa de acceso a datos para cambiar el modelo de persistencia y comenzar a persistir sobre nuestra base de datos SQL Server 2008.
En este punto el instructor deberá seleccionar la tecnologí­a de acceso a datos que considere. En caso de orientar la formación a un proyecto especí­fico o tecnologí­a esto nos llevarí­a a trabajar en este punto con una tecnologí­a de acceso a datos concreta. En casos en los cuales no tengamos clara la salida del alumno, y a nivel general, recomiendo partir de las clases básicas de acceso a datos que provee el framework (ADO.NET; JDBC para formaciones Java), que accedan a los procedimientos almacenados que el alumno ha creado sobre la propia base de datos.
Esta fase va a generar una refactorización exclusivamente sobre la capa de acceso a datos (si hemos hecho bien el resto), y nuestra aplicación, sin necesidad de tocar una sola lí­nea en el interfaz, va a pasar de almacenar la información en memoria a almacenar la información en base de datos.
Como siempre, tras este cambio, la aplicación va a tener que seguir cumpliendo el requerimiento y pasando el plan de pruebas.
Tras este desarrollo, el alumno deberí­a percibir la importancia del trabajo en capas, la abstracción que supone el uso de capas separadas, reforzando el uso de clases con una alta cohesión y bajo acoplamiento.
Fase 8 – Concepto de capa de lógica de negocio
Nuestro código dispone en este punto de una capa de presentación que no conoce de dónde proviene el dato que está manejando, pero que sí­ conoce la lógica del negocio. Es decir, si para nuestro negocio dar de alta un nuevo modelo de coche en nuestro software de gestión de flotas de vehí­culos supone, además de realizar una inserción en la tabla que almacena los modelos a través de nuestra nueva y reciente capa de acceso a datos, enviar 3 e-mails a 3 destinatarios diferentes, replicar un conjunto de datos asociado al modelo en otro contexto diferente al nuestro, generar un fichero de comunicación con otros sistemas, etc; en este punto todo este código seguramente estará ubicado en el propio evento “onClick” del botón dar de alta nuevo modelo de coche.
El objetivo de esta fase es que una vez finalizada, nuestro aplicativo cuente con una capa de negocio que encapsule todo este comportamiento. Nuestro botón “onClick” deberí­a llamar a un íºnico método llamado “DarDeAltaModeloCoche” que se encargara de realizar todas las acciones pertinentes (entre otras realizar la inserción del nuevo modelo de coche a través de la capa de acceso a datos). La capa de presentación no sabe dónde se almacena el coche, y qué significa para nuestro negocio el dar de alta un modelo de coche.
Nuevamente, el aplicativo deberá respetar los requerimientos y pasar el plan de pruebas.
Fase 9 – Otras capas: Caché, Validación
Incluimos a continuación nociones de uso de otras capas como Caché, Validación, etc. Es un bueno momento para trasladar al alumno teorí­a de algunos patrones como Singleton, Strategy, Factory, etc.
El aplicativo deberí­a reflejar dichos ajustes.
Fase 10 – Librerí­as
Nuestro código, aunque separado perfectamente en diferentes capas, ha estado formando parte de la misma aplicación en todo momento. Es este el momento de incluir los conceptos de librerí­a de clase, y dividir cada una de las capas en librerí­as diferenciadas por el proyecto inicial. Acceso a Datos, Negocio, Validación, Entidades de Negocio… son librerí­as diferenciadas que podrán ser actualizadas de forma independiente y reutilizadas.
Capí­tulo IV: Replicando en Web
Es precisamente en este punto donde vamos a comenzar a reutilizar el trabajo realizado en la íºltima de las fases de desarrollo de aplicaciones de escritorio, ya que vamos a referenciar las librerí­as de negocio, acceso datos, caché, validación y otras capas que hayamos creado para la aplicación de escritorio. Todo el trabajo va a ser reutilizado a excepción de la capa de presentación que es la íºnica que va a cambiar. El alumno deberá notar la potencia de haber desarrollado su anterior trabajo con esta orientación, limitándose a realizar una nueva interfaz.
En este punto el instructor debe trasladar conocimientos avanzados al respecto de
* HTML
* Javascript
* CSS
* ASP.NET
Una vez finalizado este capí­tulo, el alumno cuenta con dos aplicativos diferentes que realizan exactamente la misma función y sobre los que íºnicamente se diferencia la interfaz (ambos referencian a los mismos proyectos de tipo librerí­a para realizar cálculos de negocio y almacenamiento de datos).
Capí­tulo V: Replicando en Dispositivos Móviles
Mismo trabajo en el punto de desarrollo de aplicaciones web, pero en este caso realizando desarrollo sobre proyecto de aplicación móvil.
Capí­tulo VI: Distribuyendo el negocio, concepto de servicio, arquitectura SOA, independencia del dispositivo
Nuestro aplicativo ha referenciado hasta ahora librerí­as locales. Ha llegado el momento de distribuir el conocimiento del negocio en un aplicativo distribuido: Windows Communication Foundation. Si todo ha ido bien, las tres capas de presentación diferenciadas con las que contamos en este momento (escritorio, web, móvil), íºnicamente deberán cambiar su referencia de las librerí­as locales a los servicios web publicados por el aplicativo WCF que también crearemos en este punto.
Hasta aquí­ la primera versión de este método, donde intento a alto nivel dar a entender el formato de formación que hasta ahora mejor resultado viene dando, permitiendo en un plazo de 3/4 semanas situar al alumno en una dinámica de proyecto lo más cercana a la realidad, habiendo repasado conceptos de arquitectura medios y avanzados que forman parte del dí­a a dí­a de los proyectos de software; todo ello en un ambiente divertido y de aprendizaje continuo.
Intentaré en próximos artí­culos bajar de nivel de abstracción alguno de los puntos, intentando dar algo más de detalle de cómo enfocarlos a más bajo nivel.
Un saludo.
Miguel.