Propuesta de diseo para proyectos informticos que utilizan Symfony como Framework Design for software projects that

use Symfony as framework proposal Daira Figueroa Hidalgo, Yurisbel Vega Ortiz y Vladimir Martell Fernndez. Universidad de las Ciencias Informticas dfigueroa@uci.cu Resumen Es bien sabido que en el mundo de la Ingeniera de Software las actividades asociadas al diseo de aplicaciones son muy importantes e incluso, decisivas dentro de un proceso de desarrollo de software. Paralelo a esto, el uso de frameworks de desarrollo ha evolucionado en los ltimos aos, de manera que todas las empresas, instituciones o grupos de desarrollo independientes los utilizan en las soluciones que desarrollan. Si bien es cierto que su uso reduce el tiempo de la implementacin y utiliza las mejores prcticas de diseo, tambin es cierto el hecho de que muchos equipos de desarrollo lentifican sus actividades e incluso las detienen, debido a que no existen propuestas robustas de diseo utilizando framework de desarrollo. La presente investigacin tiene como objetivo contribuir al mejoramiento de las actividades asociadas al diseo de aplicaciones web que utilicen estos mencionados framework a travs de una propuesta de diseo sencilla, fcil de entender, dirigida y centrada en las necesidades de la implementacin como objetivo fundamental del diseo. Se presentan, adems, los principales patrones de diseo presentes en la solucin y se detallan y argumentan todas las decisiones del colectivo de autores. Palabras clave: Aplicaciones web, diseo, framework, ingeniera de software.

Abstract Is well known in the world of software engineering, the activities associated with the application design are very important and even, critical software development process. Parallel to this, the use of development framework has been more in recent years, so all the institutions or independent development groups used by companies who develop solutions. While it is true that use reduces time to deployment and uses best practices design, also is the fact that many development teams lentifican activities and even stop them, since there are no robust design using development framework proposals. This research aims to contribute to the improvement of the activities associated with web application design use these mentioned framework in a simple, easy to understand, design proposal, directed and focused on the needs of the implementation, ultimate purpose of the design. Major design patterns present in the solution are also and details and argue all decisions of the authors. Keywords: Design, software engineering, web application framework.

Introduccin

Segn Ivar Jacobson, Grady Booch y James Rumbaugh en su libro El Proceso Unificado de Desarrollo de Software: el proceso de desarrollo de software es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y certificado para su uso operativo. Concretamente define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo. (Jacobson, 2000a).
Siguiendo la lnea de pensamiento anterior, cualquier empresa, grupo o entidad acadmica, que entre sus objetivos persiga la produccin eficaz de un software que satisfaga las necesidades de un cliente traducidas stas en el grado de validacin satisfactoria de cada uno de los requerimientos del producto en desarrollo- debe organizar sus procesos, actividades y recursos en funcin de lograr efectivamente la concatenacin de las acciones descritas por los Tres Amigos.

No obstante, en la prctica, alcanzar este fin no resulta sencillo, a menudo los equipos de desarrollo de software presentan dificultades para logarlo; la poca experiencia del personal asociado al proceso, las planificaciones irreales y la falta de compromiso del equipo son algunas de las causas ms notables y comunes que se pueden presentar y de las cuales se ha reflexionado sobremanera en diferentes mbitos. Sin embargo, en la actualidad, existen otros factores importantes que vale la pena considerar. Estos factores frenan considerablemente el tiempo de desarrollo y ms que esto, suponen un esfuerzo adicional del equipo que bien pudiera minimizarse con las prcticas y tcnicas adecuadas. Uno de estos factores lo constituye la etapa del diseo de aplicaciones cuando se utilizan framework1 de desarrollo. El hecho de utilizar y extender (ampliar) las caractersticas y funcionalidades de un determinado framework, si bien agiliza la implementacin, actualmente provoca desorden y lentitud en el momento de generar la documentacin adecuada, lo cual viene dado, en la mayora de los casos, por algunas de las causas siguientes: 1. Desconocimiento del equipo del funcionamiento interno del framework. 2. Poca documentacin o experiencias confiables en modelamientos similares. 3. Inexactitud en la profundidad de la modelacin de las caractersticas del framework. 4. Variedad de propuestas de modelado para una misma situacin poco confiables.

Todo lo anterior demuestra evidentemente la importancia de establecer una propuesta de diseo estndar, robusta, basada en las necesidades de los proyectos y orientada a la prctica, con el objetivo de agilizar este importante proceso en el desarrollo de un software y hacer ms comprensible la documentacin para el resto del equipo. Uno de los framework existentes en la actualidad, que adems, est siendo muy utilizado en proyectos de desarrollo de software de altas envergaduras es Symfony, el cual forma parte de la larga lista de los desarrollados y construidos para ser utilizados teniendo como base el lenguaje de programacin PHP. La presente propuesta de diseo se realiza asumiendo la seleccin del mencionado framework para PHP debido al creciente auge del mismo, al inters de la comunidad internacional por estandarizar su uso y al inters particular del grupo de desarrollo donde se desenvuelven los autores de la investigacin. Se origina entonces el siguiente problema cientfico: Cmo perfeccionar el diseo de aplicaciones que utilicen Symfony como framework de desarrollo. De ah que el objetivo general de la presente investigacin sea: Elaborar una propuesta de diseo para proyectos informticos que utilicen symfony como framework de desarrollo. Dado lo anterior, se establece como objeto de estudio: el diseo de aplicaciones web y como campo de accin el diseo de aplicaciones web utilizando Symfony. Durante la investigacin se defiende la premisa de que: si se desarrolla una propuesta de diseo, estndar, robusta, basada en las necesidades de los proyectos de software y orientada a la prctica, se agilizar y har ms comprensible el proceso de diseo de aplicaciones web de este tipo. Finalmente, se esperan como posibles resultados, la documentacin de la propuesta de diseo argumentada hasta aqu.

Estructura de soporte definida, mediante la cual otro proyecto de software puede ser organizado y desarrollado, puede incluir soporte de programas, bibliotecas y un lenguaje interpretado entre otros software para ayudar a desarrollar y unir los diferentes componentes de un proyecto.

Desarrollo Generalidades de Symfony Symfony es un completo framework diseado para optimizar, gracias a sus caractersticas, el desarrollo de las aplicaciones web. Para empezar, separa la lgica de negocio, la lgica de servidor y la presentacin de la aplicacin web. Proporciona varias herramientas y clases encaminadas a reducir el tiempo de desarrollo de una aplicacin web compleja. Por otra parte, automatiza las tareas ms comunes, permitiendo al desarrollador dedicarse por completo a los aspectos especficos de cada aplicacin. El resultado de todas estas ventajas es que no se debe reinventar la rueda cada vez que se crea una nueva aplicacin web. Est desarrollado completamente con PHP 5. Ha sido probado en numerosos proyectos reales y se utiliza en sitios web de comercio electrnico de primer nivel a escala internacional. Es compatible con la mayora de los gestores de bases de datos, como MySQL, PostgreSQL, Oracle y SQL Server de Microsoft. Se puede ejecutar tanto en plataformas *nix (Unix, Linux, etc.) como en plataformas Windows. Todo lo anterior hace de symfony un robusto framework que cada vez es ms utilizado en el desarrollo de sistemas para la web (Fabien Potencier, 2007).

Arquitectura Modelo-Vista-Controlador desarrollada en Symfony El framework seleccionado, al igual que la mayora de los existentes para PHP est desarrollado bajo las restricciones, suposiciones y recomendaciones de la Arquitectura Modelo-Vista- Controlador (MVC). MVC sugiere la separacin del software en tres componentes: Modelo, Vista y controlador, los cuales sern explicados brevemente: Modelo: Es la representacin de la informacin que maneja la aplicacin. El modelo en s lo constituyen los datos puros y la lgica de los propios datos que puestos en el contexto del sistema proveen de informacin al usuario y en algunos casos a la propia aplicacin. Vista: Es la representacin del modelo en forma grfica disponible para la interaccin con el usuario. En el caso de una aplicacin web, la Vista sera una pgina HTML con contenido dinmico sobre la cual el usuario puede realizar sus operaciones. Controlador: Es la parte encargada de manejar y responder las solicitudes del usuario, procesando toda la informacin necesaria y modificando el Modelo en caso de ser necesario. Ciclo de vida del MVC El ciclo de vida del MVC es normalmente representado por los tres componentes presentados anteriormente y el cliente (tambin conocido como usuario o actor). El siguiente diagrama representa el ciclo de vida de manera sencilla:

Fig. 1. Ciclo de vida de Modelo-Vista-Controlador.

El primer paso en el ciclo de vida empieza cuando el usuario hace una solicitud al controlador con informacin sobre lo que l desea realizar. Entonces el controlador decide a quin debe delegar la tarea y es aqu donde el modelo empieza su trabajo. En esta etapa, el modelo se encarga de realizar operaciones sobre la informacin que maneja para cumplir con lo que le solicita el controlador. Luego de terminada su labor, le regresa al controlador la informacin resultante de sus operaciones, el cual a su vez redirige a la vista la cual se encarga de transformar los datos en informacin visualmente entendible para el usuario.

Modelos de diseo El diseo del software se encuentra en el ncleo tcnico de la ingeniera de software. Una vez que se analizan y especifican los requisitos del producto, el diseo del software es la primera de las tres actividades tcnicas -diseo, generacin de cdigo y pruebas- que se requieren para construir y verificar el software. Se encuentra muy cercano al modelo de implementacin, en l se modela el sistema y se encuentra su forma (incluida la arquitectura) para que soporte todos los requisitos, incluyendo los no funcionales y las restricciones que se suponen. El modelo de diseo es un modelo de objetos que describe la realizacin fsica de los casos de uso, centrndose en cmo los requisitos funcionales y no funcionales junto con otras restricciones relacionadas con el entorno de implementacin, tienen impacto en el sistema a considerar. Adems, el modelo sirve de abstraccin de la implementacin del sistema y es, de ese modo, utilizada como una entrada fundamental de las actividades de implementacin (Jacobson, 2000b).

Diagrama de clases del diseo Segn la definicin de los tres amigos: Una clase de diseo y sus objetos, y de ese modo tambin los subsistemas que contienen las clases de diseo, a menudo participan en varias realizaciones de casos de uso. Tambin puede darse el caso de algunas operaciones, atributos y asociaciones sobre una clase especfica que son relevantes para slo una realizacin de caso de uso. Esto es importante para coordinar todos los requisitos que diferentes realizaciones de casos de uso imponen a una clase, a sus objetos y a los subsistemas que contiene. Para manejar todo esto, utilizamos diagramas de clases conectados a una realizacin de caso de uso, mostrando sus clases participantes, subsistemas y sus relaciones. De esta forma podemos guardar la pista de los elementos participantes en una realizacin del caso de uso (Jacobson, 2000a). No obstante lo anterior, en el desarrollo de la modelacin de aplicaciones web, especficamente dentro de las actividades de diseo, se recomienda utilizar los estereotipos y las extensiones web introducidas en el mundo de la Ingeniera de software en los finales de los aos 90 por Jim Conallen el cual publica en el 1999 varios artculos donde describe cada una de las extensiones y cmo utilizarlas en este tipo de modelado. De esto se obtiene como elemento significativo 3 clases de UML estereotipadas como Server Page, Client Page, Form empleados para el cdigo servidor, cdigo cliente y formularios respectivamente. La prctica cotidiana ms comn y ms acertada segn los autores de esta investigacin- supone mezclar estas tres extensiones con las tradicionales utilizadas en el diseo de aplicaciones fuera de la web, respetando en todo caso las posibles relaciones que entre todas ellas pueden existir. Una premisa fundamental que se defiende a travs de la propuesta de diseo que se presentar a continuacin ha sido la de representar nicamente las clases y extensiones web que guarden estrecha relacin con la modelacin de una solucin en particular y ocultar el comportamiento interno del framework que en la prctica poco ayudan en el diseo, la implementacin y las pruebas; an as, se representan la mayora de las clases de symfony con las cuales el equipo de desarrollo interacta.

Propuesta de diseo segn MVC y diagrama de clases Segn el estilo MVC que implementa symfony el diseo queda estructurado de la siguiente manera:

El modelo: Constituido por dos partes fundamentales: la lgica de la aplicacin, y todo lo que se refiere al acceso y abstraccin de los datos. Symfony genera automticamente todas las clases del modelo utilizando Propel, segn el diseo de los mencionados datos implementado sobre algunos de los gestores que son compatibles con l, adems, traduce por cada tabla real de la Base de Datos (en lo adelante BD) cuatro clases: NombreTabla, NombreTablaPeer, BaseNombreTabla, BaseNombreTablaPeer las cuales se encargan en conjunto de realizar todo el acceso a los datos y la lgica de la aplicacin. NombreTabla y NombreTablaPeer: Son el corazn de la aplicacin, se encargan en conjunto de toda la lgica del negocio. BaseNombreTabla: Contiene todos los atributos definidos en la tabla y un conjunto de mtodos ya implementados que gestionan el acceso a los datos y aceleran y simplifican el trabajo del equipo. BaseNombreTablaPeer: Contiene un conjunto de mtodos estticos que complementan el acceso y la lgica de los datos. La representacin del modelo una vez que symfony genera automticamente las cuatro clases a partir de una tabla de la BD quedara como se muestra en la siguiente Figura.

Fig. 2. Modelo Genrico generado por Symfony.

Para disminuir la complejidad de los diagramas de clases del diseo- luego de acotado lo anterior con relacin a las clases generadas por symfony- se propone representar solamente en el modelo las clases BaseNombreTabla pues son realmente las que proporcionan informacin acerca de la representacin y organizacin de los datos en la BD, es a travs de ellas que se establecen las relaciones entre las tablas. Las posibles relaciones, en todos los casos, coincidirn con las establecidas para la herencia, agregacin, composicin o asociacin. El controlador: La capa del controlador se encarga de procesar las interacciones del usuario, contiene el cdigo que liga la lgica del negocio con la presentacin. Esta capa se divide en dos partes fundamentales, las acciones y el controlador frontal. Las acciones: Se encargan de obtener los resultados del modelo y definen variables para la vista. Constituyen responsabilidades con el nombre execute<NombreAccion> de la clase <NombreModulo>Action que a su vez hereda de la clase sfActions. Es importante acotar que el prefijo execute de las funcionalidades y el sufijo Action de la clase son obligatorios.

Esta clase ubicada en la capa controladora de la arquitectura MVC hereda el comportamiento y las caractersticas de la clase sfActions que forma parte del framework, la cual se encapsula en la presente propuesta dentro de un paquete denominado componentes de symfony que engloba el funcionamiento interno del framework. El controlador frontal: Es el nico punto de entrada a la aplicacin, representa un archivo .php, carga la configuracin y determina la accin a ejecutarse, adems, todas las peticiones son manejadas por l que ayudado por los dems componentes del framework realizan todo el trabajo transparente al programador. Se recomienda nombrar el archivo php como el mismo nombre de la aplicacin que se desarrolla. La vista: Se encarga de producir las pginas que se muestran como resultados de las acciones. Contiene tres partes fundamentales, el layout (conocido como plantilla global), el complemento de las acciones (llamado plantilla) y las pginas con sus formularios. El layout: Almacena el cdigo HTML que es comn a todas las pginas de la aplicacin, para no tener que repetirlo en cada una de ellas. El contenido de la plantilla se integra en el layout, o si se mira desde el otro punto de vista, el layout decora la plantilla. El complemento de las acciones o plantilla: Son las encargadas de, con los resultados de la accin, insertarse en el cuerpo del layout y generar finalmente la pgina web resultado de la peticin de un usuario. Esta plantilla tiene el mismo nombre que el sufijo de la accin correspondiente y termina con el sufijo Success. Ejemplo: para una accin executeIndex existir una plantilla indexSuccess. Pginas clientes y formularios: Son las pginas que se generan finalmente producto de la construccin del layout y la plantilla y con las que el usuario interacta. Finalmente la propuesta queda como sigue:

Fig. 3. Diagrama de clases del diseo.

De manera general, el flujo de informacin segn lo representado anteriormente funciona como se explica inmediatamente: El controlador frontal recibe una peticin (generalmente una URL), luego de recibirla, y ayudado por los denominados componentes de symfony (paquete que encapsula el resto del comportamiento interno del framework), determina el mdulo y la accin que deben invocar (a travs de un proceso llamado sistema de enrutamiento), luego de invocada, la accin utiliza el modelo (no obligatoriamente) y almacena los resultados que sern accesibles desde la vista (especficamente los archivos success). Para el modelo devolverle los resultados a las acciones utiliza un ORM (Object Relational Mapping) y una capa de abstraccin que en el caso del framework seleccionado se trata de Propel y Creole respectivamente- los cuales se encargan de todo el proceso de acceso

y abstraccin de los datos. Nuevamente, los componentes de symfony, adhieren el resultado de las acciones y las success y esto finalmente al layout y le devuelven al controlador el resultado el cual se encarga de construir la pgina cliente que es lo que finalmente es mostrado al usuario, el cual, al volver a interactuar con ella desembocara el inicio nuevamente del flujo anterior. Siendo consecuentes con la premisa de representar todos los archivos o clases relevantes para el equipo de desarrollo se considera oportuno destacar algunos que a menudo s se utilizan en el desarrollo de cualquier aplicacin y que quedan encapsulados dentro del paquete componentes de symfony mostrado en el diagrama. Validate: Se establece a nivel de mdulo, su nombre debe corresponder con la accin a validar, contiene la configuracin necesaria para realizar las validaciones del lado del servidor de una accin determinada. Databases: Se establece a nivel de proyecto, contiene la configuracin necesaria para establecer la conexin a la BD que se utilizar en la aplicacin. Security: Se establece a nivel de aplicacin, contiene la configuracin necesaria para implantarle seguridad a determinada accin. View: Se establece a nivel de aplicacin, contiene la configuracin necesaria para que determinada plantilla (success) utilice archivos javascript.

Fig. 4. Componentes que a menudo se utilizan en Symfony.

Patrones de diseo presentes en la propuesta Segn Christopher Alexander (uno de los primeros en introducir el termino patrones) "Cada patrn describe un problema que ocurre una y otra vez en nuestro medio ambiente, si a esto le agregamos la descripcin del ncleo de la solucin a ese problema, entonces, es posible utilizar esta solucin un milln de veces ms, sin tener que hacerlo del mismo modo dos veces". An cuando Alexander estaba hablando de patrones de construccin en la arquitectura civil, lo que dice es cierto acerca de los patrones de diseo orientado a objetos y su criterio fue muy bien argumentado y apoyado por la llamada Banda de los cuatro en su libro Design Patterns: Elements of Reusable Object- Oriented Software (Erich Gamma, 1994), a decir de estos ltimos: Los patrones de diseo se refieren a las descripciones de comunicacin de las clases y los objetos que pueden personalizarse para resolver un problema de diseo general en un contexto particular. Symfony, al igual que la mayora de los framework sigue las mejores prcticas y patrones de diseo para la web (Fabien Potencier, 2007). A continuacin, se exponen algunos ejemplos de patrones que fueron tenidos en cuenta en el momento de desarrollar la propuesta. Patrn alta cohesin: El uso de este patrn se evidencia en la implementacin de la clase Action, la cual tiene la responsabilidad de definir las acciones para las plantillas y, paralelo a esto colabora con otras para realizar diferentes operaciones, instanciar

objetos y acceder a las propiedades, expresado de otra manera, est formada por diferentes funcionalidades que se encuentran estrechamente relacionadas. Patrn creador: En las mencionadas clases se encuentran las acciones definidas para las operaciones lgicas del negocio en cuestin y se ejecutan cada una de ellas. En las acciones se crean los objetos de las clases que representan las entidades, esto evidencia que la clase Actions es "creadora" de dichas entidades. Patrn controlador: Todas las peticiones eb, generalmente, son manejadas por un solo controlador frontal, que segn se explic, es el punto de entrada nico de toda la aplicacin para un entorno determinado. El controlador es encargado de recibir la peticin del usuario y en funcin de ella, enva la solicitud a las distintas clases para que sea procesada. Patrn creacional Singleton: Garantiza la existencia de una nica instancia para una clase y la creacin de un mecanismo de acceso global a dicha instancia. En el controlador frontal hay una llamada a sfContext::getInstance(), la cual almacena una referencia a todos los objetos que forman el ncleo de Symfony y muy provechosamente, puede ser accedido desde cualquier punto de la aplicacin. Patrn estructural decorator (envoltorio): Aade funcionalidad a una clase, dinmicamente. El archivo layout.php, que tambin se denomina plantilla global, almacena el cdigo HTML que es comn a todas las pginas de la aplicacin, para no tener que repetirlo en cada pgina. El contenido de la plantilla se integra en el layout, o si se mira desde el otro punto de vista, el layout decora el contenido de la plantilla.

Conclusiones Una vez finalizada la investigacin y como producto de su desarrollo se considera importante resaltar una serie de conclusiones las cuales se enumeran a continuacin: 1. El proceso de desarrollo que se lleva a cabo con el objetivo de lograr un producto de software, en la actualidad, es muy engorroso, lento y a menudo se afecta debido a situaciones que pudieran tener solucin con prcticas adecuadas. 2. Una de las situaciones anteriores lo constituye el diseo de aplicaciones web utilizando framework de desarrollo, stas, retrasan e incluso detienen el proceso debido a la poca experiencia y a la inexistencia de un estndar para disear. 3. La propuesta se establece para el framework Symfony por el inters local, internacional y por el auge de ste en la implementacin de aplicaciones web modernas. 4. Si se desarrolla una propuesta de diseo, estndar, robusta, basada en las necesidades de los proyectos de software y orientada a la prctica, se agilizar y har ms comprensible el proceso de diseo de aplicaciones web de este tipo. 5. La propuesta de diseo que ha sido presentada en esta investigacin sigue la premisa de representar nicamente las clases y extensiones web propias de la solucin particular y ocultar el comportamiento del framework ajeno al equipo de desarrollo. 6. La utilizacin de la presente propuesta minimizara el tiempo y los esfuerzos que actualmente los equipos de desarrollo dedican al diseo de aplicaciones. 7. Esta propuesta representa un hito importante en aras de estandarizar el diseo de aplicaciones web debido a que, de su tipo, no se conoce ninguna otra propuesta, al menos en el rea donde se desarrollan los autores de la investigacin. 8. Finalmente, la propuesta respeta y utiliza algunos patrones de diseo que contribuyen a su robustez.

Recomendaciones Los autores de la investigacin recomiendan: 1. Aplicar la propuesta a proyectos de desarrollo de software pilotos. 2. Documentar los efectos positivos y negativos que se obtienen producto de su aplicacin. 3. Ampliar el campo de accin de esta investigacin con el objetivo de proponer un diseo de aplicaciones estndar para cualquier framework de desarrollo que utilice el lenguaje PHP y la arquitectura Modelo-Vista-Controlador.

Referencias Bibliogrficas

Erich Gamma, r. G., Ralph Johnson, john Vlissides. Design patterns: elements of reusable object-oriented software 1994. P. Hidalgo, D. F. Sistema automatizado para la gestin de los datos del balance nacional de recursos y reservas de petrleo y gas de la oficina nacional de recursos minerales. Ciudad de la habana, universidad de las ciencias informticas, 2006. P.

Ivar Jacobson, G. B. y. J. R. El proceso unificado de desarrollo de software. Madrid, 2000a. P. Ivar Jacobson, G. B. y. J. R. El lenguaje unificado de modelado., 2000b. P. Pressman, R. S. Ingeniera del software. Un enfoque prctico. 5. 2005. P. Fabien Potencier, F. Z. Symfony, la gua definitiva., 2007. 435 p.