SG #08

Entrevista con Jon "maddog" Hall

Anonymous — Mon, 24 Sep 2007 18:46:41 +0000

Entrevista con Jon "maddog" Hall

Anonymous Mon, 09/24/2007 - 13:46

Publicado en

SG #08

Entrevista

Durante LinuxWorld México tuvimos oportunidad de platicar con Jon ‘maddog’ Hall, Presidente de Linux International, una organización sin fines de lucro que promueve la adopción del software libre. Durante su carrera, maddog ha ocupado un sinfín de posiciones técnicas, ha sido maestro universitario, y actualmente forma parte del consejo de diversas organizaciones. Sin duda, es una de las personas más conocedoras, interesantes y agradables de la industria. Veamos cuales fueron sus palabras para los lectores de SG.

¿Qué te motiva a promover el Software Libre?

Soy un gran creyente de la colaboración. Creo que tres personas colaborando para resolver un problema generan una mejor solución que la persona más brillante trabajando sola.

La primera distribución de Linux que se podía instalar en el sistema de archivos FAT sin tener que reparticionar el disco, la desarrolló un niño de 14 años. La única persona que lo ayudó, fue alguien a través del Internet, a quien nunca había conocido, y que también tenía 14 años. Quiero encontrar a estas personas. Quiero encontrar al próximo Einstein de las computadoras. Y no pienso que solamente puede salir de Estados Unidos. Puede ser de México, Brasil, China o un país como Finlandia. Pero estoy seguro de que si tenemos que filtrar a estas personas a través de Redmond o Silicon Valley, nunca las vamos a encontrar.

¿Qué impacto tiene el software libre en la economía local?

Si vas a una expo de computación en México, encontrarás a muchas empresas distribuyendo productos extranjeros. El inconveniente de esto es que están enviando al extranjero dinero que se podría quedar en el país para hacer otra cosa, ya sea pagarle a un desarrollador de software, comprar comida, o simplemente bajar el costo de los servicios para otros sectores. De cualquier forma es bueno para la economía.

Imaginemos un escenario extremo en el que todo el software fuera hecho por la misma empresa, en Estados Unidos. ¿Cómo podrían los diferentes países desarrollar una economía local del software? ¿Qué caso tendría que las universidades enseñaran desarrollo de software? Yo creo que es mejor tener a 80 mil personas millonarias, que a un 80 mil millonario. Definitivamente es mejor para la economía.

¿Qué se puede hacer para mejorar la educación universitaria?

Antes que nada, creo que la gente debe darse cuenta que las personas que están enseñando a sus hijos, están construyendo su futuro. Si no tenemos a las mejores personas educándolos, entonces, vamos a perder como sociedad.

Por otro lado, es común ver que los profesores se pierdan en las actividades académicas, y pierdan contacto con el mundo real. Esto termina afectando la calidad de la enseñanza que dan. Debería haber programas para que cada cierto tiempo los profesores dejen la academia, trabajen en la industria, y posteriormente regresen con ideas renovadas.

Por último, creo que debemos entender el rol de las universidades. Mucha gente piensa que es ayudar a sus hijos a conseguir un buen trabajo. Eso no es cierto. Las universidades existen para generar gente capaz de contribuir al desarrollo de la industria, y capaz de evaluar lo que se debe hacer en la política y gobierno para mejorar la economía y la sociedad. Es erróneo creer que las universidades deben entrenar a sus alumnos para hacer un trabajo específico, o con una herramienta en particular. No, lo que las universidades deben enseñar a sus alumnos, es cómo aprender nuevas cosas; es decir, prepararlos para una vida de aprendizaje.

¿Los grandes desarrolladores aplican la ingeniería de software, o simplemente se sientan a programar?

He conocido desarrolladores que al principio de un proyecto, van a un pizarrón y sistemáticamente analizan el problema, diseñan una solución, evalúan los algoritmos posibles, y entonces generan software muy bueno. Por otro lado, he visto a quienes directamente se ponen a programar, y también generan software muy bueno. Posiblemente tengan un pizarrón mental y en 30 segundos hagan lo mismo que hicieron los otros.

Lo que hay que entender acerca de estas personas, es que no sólo son buenos programadores, sino que cuentan con otras habilidades, que son las que les permiten ser tan buenos. Por ejemplo, en el caso de Linus (Torvalds), es un excelente escuchador. Hace unos años durante una conferencia, Linus estaba dando una plática sobre lo que estaban haciendo para soportar multiprocesamiento simétrico (SMP). La persona que iba conmigo, había sido arquitecto de Digital Unix, y estaba enfurecido porque él sabía lo complicado que esto era, y que Linus no estaba considerando muchas cosas. Así que después de la plática fue a buscarlo y habló con él durante más de media hora, en la que Linus se limitó a decir “ah sí... ok, ...es cierto”. Al terminar, mi amigo regresó más contento y me dijo “ja, ya lo puse en su lugar”. A lo que le contesté “sí, supongo que le dijiste todo acerca de cómo implementamos SMP en Digital Unix y el simplemente te escuchó”, y entonces mi amigo exclamó “¡oh no, le acabo de revelar toda la propiedad intelectual!”. Así es Linus, puede sentarse y absorber todo.

¿Cuál es tu opinión sobre las patentes de software?

Antes de que se crearan las patentes, la única forma de proteger un invento, era no revelándolo. El problema con esto es que al morir el inventor, este conocimiento se perdía. Otro problema es que nadie podía decir “oye, tengo una idea que puede mejorar tu idea”, porque nadie conocía la idea original, solamente su creador.

La industria médica es una buena razón para tener patentes. A un científico le toma veinte o más años crear una medicina. Y después de crearla deben pasar otros cinco o diez para probarla, y verificar que no tenga efectos secundarios. Esto es una gran inversión, y requieres patentes para evitar que los competidores simplemente copien la fórmula.

El caso de la industria de software es diferente. He estado en ella más de 35 años, y la mayoría de las veces lo que sucede es que en cuanto un ingeniero tiene una idea para un problema particular, llega un abogado diciendo: “¿podemos patentarlo?”, “¿cuánto dinero le podremos sacar?”, “tal vez no le podamos sacar dinero, pero podemos evitar que la competencia lo use”. Lo que yo me pregunto es, ¿eso es beneficioso para la sociedad?, ¿la empresa realmente hizo una gran inversión, o la va a recuperar en las primeras veinte copias que venda?

A principios del siglo XVIII, un señor llamado Bartolomé Cristofori inventó cierto instrumento musical. Cristofori bien sabía lo que era una patente, ya que ésta había sido inventada 400 años antes en la misma ciudad donde el vivía (Florencia, Italia). Sin embargo, él pensó “no existe música escrita para este instrumento, y sin música, no habrá demanda de instrumentos. Si lo patento, nadie querrá pagar para construirlo, y entonces nadie escribirá música para él. En cambio, si publico cómo construirlo, posiblemente haya gente interesada en hacerlo, y entonces habrá gente interesada en hacer música para él, y algunos vendrán a comprar mis instrumentos.”. Así que eso es lo que hizo. El instrumento que inventó es el piano forte, que es la base del piano moderno, y si Cristofori no hubiera tenido esta visión, tal vez no conoceríamos el piano.

Si a empresas como Microsoft se les concedieran todas las patentes que están solicitando, entonces cada que escribimos una línea de código tendríamos que preguntarnos: “¿estará esto patentado?, ¿tendré que pagar regalías a alguien si lo desarrollo así?”. Es como si Miguel Ángel después de estar pintando la Capilla Sixtina durante veinte años, y justo cuando está terminando, llega Leonardo da Vinci y le dice “buen trabajo, pero tienes que hacerlo otra vez, porque la semana pasada patenté esa pincelada de allá. Y ni te molestes en taparla, porque también patenté esa de allá, y esa otra”.

Actualmente, el software está en todos lados, y toda la sociedad se beneficia de él. El software nos puede ayudar a resolver muchos de los problemas que enfrentamos, y creo que sería mejor si 6.3 billones de mentes pudieran colaborar para resolverlos. Por esto, creo que las patentes de software no tienen lugar en la sociedad moderna, y que al igual que las matemáticas y las artes, el software debería ser libre.

¿Algún mensaje para los lectores?

Sí, deben divertirse. Parece que a veces olvidamos esto. Si quieren ver a la persona más importante para el software libre, miren en un espejo.

Proceso incremental de mejora. Disciplinas y su aplicación.

Anonymous — Mon, 24 Sep 2007 18:06:43 +0000

Proceso incremental de mejora. Disciplinas y su aplicación.

Anonymous Mon, 09/24/2007 - 13:06

Publicado en

SG #08

Procesos de desarrollo de software

Autor

Angélica Su

En este artículo se describen las fases y algunos de los retos de la Mejora Iterativa del Proceso de Software (MIPS), así como la descripción de algunos de los errores comunes que se cometen en la administración de un proceso de mejora. La información que se presenta surge de experiencias en consultoría, así como reportes o historias relacionadas de nuestros colegas.

Tradicionalmente, la mejora de procesos de software se realiza en un solo ciclo. Esto es más sencillo para los administradores, pero difícil para el equipo de mejora. En cambio, la mejora incremental permite al equipo de mejora y a la gerencia identificar resultados a corto plazo, con el inconveniente de que genera mayor complejidad en la administración. Sin embargo, los beneficios bien valen la pena.

El proceso incremental
El proceso incremental de mejora tiene como objetivo asegurar la implantación de la capacidad de los modelos de software a través de ciclos de vida incrementales orientados a organizaciones y objetivos de negocio como se presenta en la figura 1. Esta figura ilustra la arquitectura del proceso, el cuál provee un acercamiento disciplinado para la asignación de tareas y responsabilidades en la organización. Como podrán apreciar, estamos tomando la misma idea del ciclo de vida del Proceso Unificado, y aplicándola a la mejora de procesos.

La gráfica muestra el esfuerzo variado a través del tiempo. Por ejemplo, en iteraciones tempranas el esfuerzo se encuentra concentrado en el desarrollo de la iniciativa y en las iteraciones tardías en la entrega. Esta contiene dos dimensiones:
• El eje horizontal representa el tiempo y muestra los aspectos del ciclo de vida del proceso claramente. La primera dimensión ilustra el aspecto dinámico del desempeño del proceso el cual está expresado en términos de fases, el ciclo de vida incremental y los entregables.
• El eje vertical representa a las disciplinas que de manera lógica agrupa las actividades por naturaleza. Esta segunda dimensión representa el aspecto estático de la descripción del proceso en términos de componentes, disciplinas, actividades, flujos de trabajo, artefactos y roles. (Ver Figura 1)

Figura 1. Modelo de ciclo de vida para la mejora de procesos incremental

Disciplinas
A continuación describo las diferentes disciplinas, y las principales actividades asociadas a cada una. Iniciativas. La gerencia debe entender el estado actual del proceso de desarrollo organizacional en términos de documentación, conocimiento, uso y comunicación, así como las herramientas que lo soportan a través de la organización. Esta información servirá para identificar problemas y áreas potenciales de mejora. También se debe complementar con información acerca del ambiente o contexto, y tendencias. Cuando esta evaluación se encuentra completa, se desarrolla el “Plan de Mejora”. Estas son las principales actividades que forman parte de esta disciplina:
• Especificar metas de negocio y objetivos que serán realizados o soportados
• Comienzo de la planeación estratégica a través de las metas y objetivos de negocio
• Diagnóstico del proceso de desarrollo organizacional para facilitar la identificación del estado actual con respecto a los estándares, métodos o modelos de referencia a implantar (estado deseado alineado al del modelo o estándar)
• Mejorar las áreas y procesos que necesitan ser mejorados en primera instancia
• Identificar el impacto en otras iniciativas y en el trabajo del día a día
• Herramientas a ser usadas por la organización
• Establecer una infraestructura para la administración específica de la implementación
• El equipo seleccionado, incluidos su nivel de competencia, habilidades y motivación, deben asegurar el soporte requerido para ejecutar el cambio razonable para el éxito

Diseño. Desarrollar la arquitectura y plantillas para el proceso de desarrollo organizacional utilizado por el grupo de procesos. La intención es evolucionar la arquitectura del proceso de forma sistemática, tomando en cuenta el ambiente organizacional.
• Desarrollar la plantilla para documentar el proceso
• Planear y establecer el ambiente organizacional con el objetivo de decidir el ambiente robusto de desarrollo con las adecuaciones necesarias
• Estructurar el comité de procesos y sus funciones
• Identificar grupos de interés afectados directa e indirectamente

Instrumentación. Identificar el tipo de entrenamiento que se necesita y las estrategias para facilitar el acercamiento del uso de los procesos y herramientas con el objetivo de implementar en proyectos piloto así como pruebas controlados para generar confianza, motivación, realización y alineación en el proceso y herramientas.
• Estudiar los niveles de competencia a través de las personas en la organización
• Desarrollar el plan de entrenamiento
• Preparar los mentores que soportarán el proyecto
• Desarrollar guías para implementar el proceso. Estas serán utilizadas para implementar tanto los procesos como herramientas
• Identificar los proyectos piloto, los cuales serán de importancia para la organización pero no de alto riesgo en su ejecución
• Definir una secuencia y decidir la ejecución del proyecto piloto

Verificación y Validación. Verificar en el ambiente piloto los procesos mejorados y validar las mejoras en el desempeño.
• Probar la solución establecida para determinar qué funciona y qué no funciona. • Revisar y modificar la solución para incorporar nuevos conocimientos y entendimientos.
• Determinar que se ha logrado hasta el momento.
• Iterar en caso de ser necesario.
Liberación. Manejar la transición/cambio en términos de la madurez de: las personas, el ambiente y la infraestructura.
• Identificar a los agentes del cambio
• Definir y comunicar las siguientes estrategias: a) Equipo, b) Liderazgo, c) Alineación, d) Comunicación, e) Incentivos, f) Entrenamiento, g) Valoración y h) Recursos

Cambios y Configuración. Es esencial para controlar los artefactos que se han generado por el proceso de mejora. Controla los cambios a los requisitos así como las versiones del proceso por lo que ayuda a evitar costosas confusiones con los artefactos y asegura la integridad de los artefactos resultantes, permitiendo establecer una línea base de conocimiento.
• Definir la estructura de la base de conocimiento
• Identificar el proceso de cambio

Administración de Proyectos. Esta disciplina se enfoca principalmente a aspectos de administración, monitoreo y control de manera iterativa a través del ciclo de vida.
• Administración de riesgos
• Planeación de todo el proyecto, y de las iteraciones individuales
• Monitoreo del progreso de un proyecto iterativo.
• Monitoreo del progreso en términos de métricas.
• Identificar barreras potenciales

Gestión de Procesos. Establece un proceso organizacional acorde a la estrategia del negocio, definiendo, planeando e implementando las actividades de mejora.
• Estructura y definición de actividades del equipo de mejora
• Ejecución y análisis controlado de la mejora a través del líder de mejora y apoyo del comité
• Análisis de las mejoras a través de la viabilidad para el negocio y el retorno de inversión (ROI) en la organización y/o áreas afectadas.

Disciplinas e iteraciones
Las diferentes disciplinas se aplican de manera cíclica en cada una de las iteraciones del proyecto de mejora. Haciendo la analogía con el ciclo de mejora Planear, Hacer, Verificar, Actuar (PHVA), quedaría de la siguiente forma ilustrada en la figura 2.

Figura 2. Ejecución dentro de una iteración

Implicaciones de la mejora incremental
A través de la aplicación de un ciclo de vida incremental para mejorar los procesos, es posible mostrar resultados rápidos a aquellas partes “afectadas”, y así obtener un mayor apoyo con convencimiento a través de resultados medibles.

Una estrategia de mejora alineada a objetivos de negocio y acotada bajo una definición del alcance nos permite contar con:
a) Metas evidentes (a corto plazo)
b) Lecciones aprendidas (reacciones) de aquellas inconsistencias que se puedan encontrar bajo el desarrollo de los requisitos, diseño e instrumentación son detectas previo a la liberación por lo que se tiene una mejora continua.
c) Verificaciones y validaciones continuas para asegurar los objetivos, integración y su estatus
d) Grupos de interés que requieren observar evidencia concreta del estatus cuantitativo del proyecto
e) Comunicación a través de resultados dirigidos a los diferentes partícipes e involucrados.

Conclusión
Aunque el modelo de mejora iterativo e incremental genera mayor complejidad en su ejecución que la forma tradicional, la inversión fuerte se realiza la primera vez que se utiliza, y los beneficios serán permanentes. Una vez que se entiende como hacerlo de manera “correcta”, el equipo de mejora comprende y piensa de manera incremental, este método es mucho mejor en el sentido que la mejora se enfoca primero a los principales problemas de la organización y esto habilitará a la gerencia a través de resultados palpables y apoya para desarrollar mejoras complejas dentro de la organización.

Bio

Angélica Su es Consultor en Procesos de Software y Administrador de Proyectos en Itera. Participó en la elaboración de MoProSoft y EvalProSoft. Ha trabajado en proyectos de mejora en la realización de diagnósticos y evaluación formal CBA-IPI y asesoría en procesos basados en SW-CMM, CMMI e ISO 9000. Heidi González es Consultor de Procesos de Software en Itera. Ha trabajado en el desarrollo de metodologías de evaluación de proveedores a través de CBA-IPI del SW-CMM.

Modelando con clase. El rey de la orientación a objetos.

Anonymous — Mon, 24 Sep 2007 17:40:39 +0000

Modelando con clase. El rey de la orientación a objetos.

Anonymous Mon, 09/24/2007 - 12:40

Publicado en

SG #08

Modelado visual

Autor

Sergio Orozco

Si alguien se lleva la corona en UML, lo más probable es que sean las clases. Finalmente, todo surgió en un principio en UML debido a la necesidad de unificar los criterios para la representación de la orientación a objetos, y las clases son un elemento básico en este paradigma. Podríamos decir que lo que hemos visto hasta el momento en ediciones anteriores de esta sección, es el preámbulo para llegar a un buen diseño de clases.

Por supuesto que cada artefacto tiene un valor importante en el ciclo de vida. Los casos de uso ayudándonos a identificar y a validar mejor con el usuario sus necesidades; el modelo conceptual (un previo del diagrama de clases) permitiéndonos comprender mejor el problema del usuario; el diagrama de interacción, mostrándonos la colaboración entre los objetos para ejecutar un proceso o un caso de uso. Pero a fin de cuentas, todos estos elementos aportan para llegar al punto que trataremos en esta ocasión: el diseño de las clases que constituirán nuestro sistema.

Efectos del Diagrama de Interacción en las Clases
Vamos a ver cómo es que las decisiones que tomamos en los diagramas de interacción se pueden ver reflejadas en el diagrama de clases. Estas decisiones pueden afectar tanto la funcionalidad de las clases, como las relaciones que debe haber entre éstas.

De acuerdo con lo trabajado previamente, hasta el momento nuestro diagrama de clases debe contar con las clases candidatas a ser de diseño, así como algunos posibles atributos y relaciones (las obtenidas en el modelo conceptual). La figura 1 ilustra una parte del modelo conceptual obtenido al analizar una terminal punto de venta (TPV).

Figura 1. Modelo conceptual del punto de venta.

El diagrama de clases de diseño al que llegaremos, por lo menos en la capa de negocio, probablemente tenga un gran parecido al modelo conceptual que mostramos. Entre los cambios más importantes está la aparición de operaciones y el refinamiento de las relaciones, que se verán reflejadas en el código, como la funcionalidad asignada en cada clase de nuestro sistema y en el mecanismo de comunicación entre ellas, respectivamente.

Las Relaciones y los Mensajes
¿Cómo nos puede ayudar el diagrama de interacción para refinar nuestras clases de diseño? En primer lugar, para identificar relaciones entre dos clases basta con observar cuáles son las que se comunican en el diagrama de interacción, y representarlas con algún tipo de relación en el diagrama de clases. ( Ver Figura 2 )

Figura 2. Diagrama de secuencia para “Realizar Venta”

Como ejemplo, en el diagrama de secuencia ilustrado en la figura 2, se ve cómo la clase TPV (en realidad las instancias de esta clase) requiere comunicarse con Venta para enviarle mensajes, y a su vez Venta requiere comunicarse con los objetos de la clase RenglonVenta. Esto significa que en el diagrama de clases tendremos que mostrar una relación con navegabilidad de TPV a Venta, y otra de Venta a RenglonVenta. (Ver Figura 3)

Figura 3. Relaciones obtenidas del diagrama de secuencia.

Las relaciones mostradas en el diagrama de clases de diseño pudieron o no haber existido durante el modelo conceptual, pero es en este momento (en el diseño) donde se toma la decisión final con respecto a las relaciones a incluir en la construcción (implementación) del sistema orientado a objetos, de conectar o no dichas clases. Recuerda que con fines de diseño, el modelo conceptual no es más que un previo o bosquejo de lo que podría ser nuestro sistema.

Cabe aclarar que el tipo específico de relación se define de una manera más elaborada, tema que será tratado en ediciones posteriores de esta sección. Sólo para no dejar un hueco en la descripción de nuestro ejemplo, hay que mencionar que las relaciones aquí mostradas corresponden a una dependencia y composición, respectivamente.

Los Mensajes y las Operaciones
Las operaciones son uno de los elementos de UML más relevantes para la implementación del sistema, pues proveen el elemento fundamental para ubicar la funcionalidad de nuestro sistema. Una identificación adecuada de las operaciones de cada clase es clave para el desarrollo de un sistema de calidad. Incluso facilitará el contar con cualidades como el “reuso” y “mantenibilidad” del mismo.

El realizar un diagrama de secuencia con una perspectiva de diseño nos puede ayudar a identificar y a ubicar de una mejor manera estas operaciones en sus correspondientes clases. Cuando existe un mensaje entre dos objetos tenemos que tomar la decisión de diseño de usar o no dicho mensaje como una llamada a operación, esto significa que la clase receptora del mensaje tendrá asignada dicha operación en el diagrama de clases de diseño.

Si volvemos al ejemplo ilustrado en la figura 2, podemos observar cómo los cuatro mensajes corresponden a llamadas a operaciones de las clases. Dos de estas operaciones corresponden a constructores de las clases y las otras dos a métodos tradicionales implementadas en las clases que reciben los mensajes.

La clase Venta recibe los mensajes agregarRenglonVenta( ) y registrarPago( ), lo cual se traduce en el diagrama de clases como dos operaciones en dicha clase, como podemos observar en el siguiente diagrama:

Conclusión
Diseñar un sistema orientado a objetos no es cosa fácil, pues requiere tomar diferentes decisiones que sólo el conocimiento de las técnicas y una apropiada experiencia nos permiten lograr. Naturalmente resulta complejo compartir, en un artículo tan breve, todo este conocimiento y experiencia. Pero, en cada uno de estos artículos esperamos poder transmitir lo más relevante para facilitarles el uso de UML como una buena herramienta de desarrollo.

Bio

Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting. Carlos Macías es arquitecto en jefe e instructor senior en Milestone Consulting. Primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en UML, CMM y orientación a objetos. info@milestone.com.mx www.milestone.com.mx

Framework aplicativo y MDA. Detonadores de calidad y productividad.

Anonymous — Mon, 24 Sep 2007 17:13:49 +0000

Framework aplicativo y MDA. Detonadores de calidad y productividad.

Anonymous Mon, 09/24/2007 - 12:13

Publicado en

SG #08

El ambiente de negocio de empresas exitosas es por definición dinámico y cambiante. Para mantener su ventaja competitiva, una compañía tiene que responder al cambio rápida y adecuadamente. Así, la capacidad de desarrollar sistemas de información cumpliendo los requerimientos del negocio, con la calidad requerida, en el tiempo que permita al negocio lograr sus objetivos, y a un costo competitivo, está directamente ligado con el éxito de la compañía.

En este artículo vamos a presentar el esquema de “Industrialización” de la fábrica de software de IIDEA Solutions basado en tres conceptos que identificamos como claves para la operación interna de la misma: los conceptos de frameworks aplicativos, EOM (Enterprise Object Model) y MDA (Model Driven Architecture).

¿Qué es un Framework Aplicativo?
Un framework aplicativo es una “aplicación semi-terminada” que está montada sobre una tecnología base como .NET o J2EE. Contiene una capa general que provee servicios comunes para todo tipo de aplicaciones tales como seguridad, acceso a datos, manejo de errores, etc., y una capa que provee servicios específicos para un cierto dominio de negocio. Este tipo de frameworks son diseñados por arquitectos experimentados; donde queda plasmado mucho de su conocimiento adquirido a través de los años y que está empaquetado y listo para ser reutilizado.

Los frameworks aplicativos son creados para ser la estructura base en la cual se montan varias aplicaciones de negocio, las cuales compartirán requerimientos similares de infraestructura, mientras otros requerimientos de negocio serán totalmente diferentes. Esta característica hace al desarrollo de un framework aplicativo particular y complejo, por lo que al momento de diseñar, se debe estar consciente de que su estructura de clases sea muy flexible en puntos donde se detecte que pueda haber requerimientos muy variables. Esto se logra siguiendo el principio “open-close” de la programación orientada a objetos (una clase debe soportar extensibilidad o modificación de su comportamiento sin la necesidad de modificar su código, la clase debe estar cerrada para su modificación de código fuente) utilizando patrones de diseño que nos apoyan en establecer “hooks” o ganchos dentro la estructura de una clase para colgar nuevos comportamientos a esta. También se debe tener la previsión para saber cuáles son los requerimientos más comunes en las aplicaciones de cierto nicho y así proveer estos mecanismos.

Un error muy común en la interpretación del concepto del framework aplicativo es confundirlo con una librería de clases o API; el framework va más allá. La diferencia primordial es que un framework controla el ciclo de vida de los componentes montados sobre éste y contiene lógica de orquestación de ciertos flujos.

Figura 1. Librerías vs Framework

En la figura de la izquierda, la aplicación usa los componentes que provee una librería y nada más. En la figura de la derecha la aplicación usa componentes que provee el framework y además éste controla el ciclo de vida de los objetos (IoC) y los flujos dentro de ciertos procesos para orquestar los componentes que fueron montados sobre éste.

Para explicar cómo está conformado un framework aplicativo en la figura tenemos una disección en capas. Existen frameworks genéricos como .NET o Java los cuales fueron hechos para uso genérico y tienen mil y una formas de realizar una misma funcionalidad. Sobre éste están los frameworks aplicativos, que son la realización de una arquitectura de software específica (componentes de software) para un cierto tipo de aplicaciones. Si hacemos un zoom de un framework aplicativo, podemos ver que existen 2 capas importantes, una dedicada a ofrecer funcionalidades comunes orientadas a servicios de infraestructura, y otra que se refiere a servicios específicos para un tipo de negocio en particular; lo cual da como resultado la capa que se llama “Domain Specific Language” (DSL). Entre más especializado sea un framework, su valor se incrementa debido a que se ve afectada positivamente la productividad del desarrollo de software y como veremos más adelante se puede generar mayor porcentaje de código automáticamente usando una herramienta de MDA.

Figura 2. Disección en capas

Enterprise Object Model
Para desarrollar la capa de DSL se debe realizar previamente un proyecto de EOM (Enterprise Object Model). El concepto de EOM está basado en la idea de crear un modelo de dominio representando los objetos de negocio para toda una organización empresarial. Para obtener este modelo se requiere realizar un análisis de procesos de la organización e identificar los objetos de negocio, así como su objetivo, propiedades, responsabilidades y variaciones que pueden tener dentro de los diferentes procesos o contextos de negocio en que son usados. Después se deben encontrar agrupaciones funcionales de objetos y englobarlos en subsistemas funcionales. En base a este modelo se pueden identificar, diseñar y construir subsistemas funcionales parametrizables según los hallazgos de variabilidad de los objetos encontrados por el EOM. Estos componentes funcionales parametrizables de negocio se integran al framework aplicativo formando la capa de DSL.

MDA
MDA son las siglas de “Model Driven Architecture”, un concepto promovido por la OMG, que propone basar el desarrollo de software en modelos de análisis y/o diseño especificados en UML, y que a partir de estos se realicen transformaciones que generen código fuente u otro modelo con características específicas para una tecnología.

Este concepto permite dos tipos de modelos de UML: Modelo PIM (independiente a la tecnología) y Modelo PSM (específico a una tecnología). Esto sucede debido a que MDA intenta separar en el desarrollo de software las preocupaciones de requerimientos del negocio y las preocupaciones tecnológicas. La ventaja que nos da este desacoplamiento es que ambos aspectos pueden evolucionar en su propio tiempo y espacio sin estar atados entre sí; la lógica de negocio responde a las necesidades del negocio —y no a las restricciones tecnológicas—, y los aspectos tecnológicos pueden tomar ventaja de los nuevos desarrollos tecnológicos.

La propuesta se basa en tener un modelo de UML que contenga el comportamiento y lógica del negocio de una aplicación neutral a la tecnología (PIM), esto quiere decir que el modelo PIM no es consciente de lenguajes de programación, restricciones tecnológicas, estilos arquitectónicos o protocolos. Ahora mediante transformaciones (punto clave del concepto MDA) del modelo PIM se generarán modelos para plataformas tecnológicas especificas (PSM ) como .NET o J2EE. Para llevar a la práctica el concepto de MDA necesitamos lo siguiente:

1) Una arquitectura de software que define los componentes claves del sistema y sus responsabilidades, la organización de los componentes del sistema y cómo se intercomunican entre sí. Esta puede estar definida en dos niveles, una arquitectura de software base que define los componentes claves y la organización de los componentes sin tener detalles de implementación; y como segundo nivel una arquitectura de software que se basa en la definición de la arquitectura base mas los detalles de implementación referentes a una plataforma o tecnología.

2) Documentar los mecanismos de diseño que son la especificación de las reglas de mapeo y transformación entre un modelo PIM y un modelo PSM.

3) Definir un perfil de UML (UML Profile) el cual es la definición de “estereotipos” y “tagged values” que es el mapeo de los tipos de componentes y roles que se definen en la arquitectura de software y los cuales serán usados para “marcar” el modelo PIM. (Cuando se tiene un Framework Aplicativo con DSL éste agrega más definiciones al perfil).

4) El Transformador es el componente que implementa las reglas de mapeo y transformación definidas en las mecánicas de diseño. En caso de existir un framework aplicativo, el Transformador será consciente de éste y generará código para ser montado sobre el framework.

Existe un quinto componente que es opcional (éste es el sello diferencial de un MDA), el cual es tener un Framework Aplicativo sobre el cual se basará el componente Transformador para la generación de código fuente y así lograr generar una mayor cantidad de código automáticamente por medio del DSL.

Ya teniendo estos componentes, el flujo del proceso sería realizar un modelo de UML PIM que especifique la lógica del negocio de manera precisa y de manera agnóstica a la tecnología de una aplicación, luego este modelo PIM se “marca” con el Perfil de UML que se tiene y que fue definido por la arquitectura de software, en este momento del proceso es cuando se le agrega al modelo el conocimiento de la arquitectura de software de manera conceptual. Después este modelo PIM “marcado” sirve como entrada para el Transformador que en base a las “marcas” que se agregaron al modelo PIM determina la transformación a realizar y genera el modelo PSM, que puede ser el código fuente de la aplicación u otro modelo UML (no necesariamente tiene que ser un modelo UML ).

Es fácil darse cuenta que el modelo PIM que sirve como entrada al proceso es el artefacto más preciado ya que detalla de manera precisa la lógica y comportamiento del negocio y el cual puede ser transformado a diferentes plataformas tecnológicas (ver figura anterior).

“El concepto de MDA es otro pequeño paso en el largo camino de transformar el actual proceso de desarrollo de software artesanal a un proceso de software que sea una disciplina de ingeniería”.

Figura 3. Flujo para aplicar MDA

Logrando los Objetivos de una Fábrica de Software
La Productividad y Calidad de Software son los objetivos primarios en una Fábrica de Software y como detonadores de estos atributos está el uso de un framework aplicativo y una herramienta de MDA.

Las características que impactan directamente a la calidad del software y que se obtienen por usar un framework aplicativo son:

Modularidad. Esta característica se refiere a la composición de una aplicación en componentes o módulos desacoplados. Como las aplicaciones están montadas sobre el framework que promueve la división de la aplicación en componentes desacoplados mejorando la modularidad de las aplicaciones y por consecuencia se incrementa la velocidad en el desarrollo en cambios de funcionalidad o extensión.

Reusabilidad. Lo más valioso de un framework aplicativo es la reutilización de la experiencia de la gente que diseñó el framework y tuvo el cuidado de tener en cuenta aspectos arquitectónicos fundamentales de una aplicación y lo cual se está reutilizando en cada aplicación que lo esté usando. En segundo término la reutilización de funcionalidad común que se encuentra encapsulada en componentes del framework.

Estandarización. El framework aplicativo forza al desarrollador a programar en un modelo determinístico lo cual estandariza la manera de desarrollar aplicaciones.

Extensibilidad. Extensibilidad es la habilidad para agregar nuevas funcionalidades a una aplicación existente. Este criterio de servicio es fundamental en un framework aplicativo debido a que éste debe ser flexible para poder cubrir las diferentes variaciones de funcionalidad que existirán en las aplicaciones que serán montadas sobre este y por ende las aplicaciones de negocio montadas sobre éste también heredarán esta característica casi “out of box”.

Simplicidad. Esta característica se refiere a que el framework aplicativo oculta muchos detalles para el programador referente a complejidad técnica y parte de la orquestación de procesos que se realizan entre componentes del framework por lo que la productividad del programador se ve incrementada.

Facilidad de Mantenimiento. Esta característica se refiere a la habilidad de realizar un cambio de una funcionalidad existente en una aplicación de manera rápida y eficiente sin afectar otra funcionalidad existente. Esta característica es uno de los criterios de servicio más complejos por cubrir y se requieren muchos años de experiencia para lograr un nivel aceptable en las aplicaciones de este criterio de servicio; el framework promueve la arquitectura en capas, composición de una aplicación en componentes desacoplados y parametrizables, manejo de errores y rastreo de errores, lo cual es un punch directo en la facilidad de mantenimiento de la aplicación. Cuando se tiene un conjunto de aplicaciones empresariales con una misma organización de componentes debido a que se montaron sobre un framework aplicativo, está comprobado por la industria de software que esto incrementa la productividad en el mantenimiento de las aplicaciones. Como siguiente paso natural de maduración en el proceso de “industrialización” está la herramienta de MDA que genera automáticamente un porcentaje de código fuente de una aplicación por lo que impacta drásticamente la productividad del desarrollo de software.

Caso Real
En la fábrica de software de IIDEA Solutions empezamos a trabajar en la visión de la “industrialización” del desarrollo de software en el año 2003.

Los primeros dos años nos dedicamos a formar una organización estable y acumular conocimiento en las plataformas estratégicas .NET y J2EE desarrollando varios proyectos para un cliente principal. Sobre todo para la parte de .NET estuvimos en una fase exploratoria durante estos años. Al principio de 2005 estuvimos en la posición de poder integrar el conocimiento tecnológico a un framework aplicativo que se estaba desarrollando durante la primer mitad del 2005. En la segunda mitad tuvimos oportunidad de usar el framework en varios proyectos dentro de la fábrica de software para optimizarlo y madurarlo lo suficiente para usarlo como base para la generación de código bajo el esquema MDA.

Todas las aplicaciones que actualmente se están desarrollando están basadas en este framework. Además estamos trabajando con nuestro cliente principal en el desarrollo de un EOM y servicios reutilizables para enriquecer al framework en la parte del DSL. En el área de MDA empezamos a finales del 2005 a desarrollar un generador de código basado en el kernel de AndroMDA que está disponible sin costo bajo licenciamiento GNU. Actualmente se está usando en un proyecto piloto para cuantificar el potencial de aumentar la productividad en el desarrollo sin disminuir la calidad.

Bio

Eduardo Macías, MSc, Chief Architect de IIDEA Solutions, es el responsable de la definición e implantación de la visión tecnológica en la Fábrica de Software. Eduardo trabajó en GE Nuclear Energy para abrir el departamento de arquitectura de software encargado de las aplicaciones de J2EE/MatrixOne, y posteriormente se dedicó a definir arquitecturas de software empresarial para diferentes empresas en USA y México.