Propuesta de diseño para proyectos informáticos que utilizan Symfony como Framework Design for software projects that

use Symfony as framework proposal Daira Figueroa Hidalgo, Yurisbel Vega Ortiz y Vladimir Martell Fernández. Universidad de las Ciencias Informáticas dfigueroa@uci.cu Resumen Es bien sabido que en el mundo de la Ingeniería de Software las actividades asociadas al diseño 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 años, 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 implementación y utiliza las mejores prácticas de diseño, también 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 diseño utilizando framework de desarrollo. La presente investigación tiene como objetivo contribuir al mejoramiento de las actividades asociadas al diseño de aplicaciones web que utilicen estos mencionados framework a través de una propuesta de diseño sencilla, fácil de entender, dirigida y centrada en las necesidades de la implementación como objetivo fundamental del diseño. Se presentan, además, los principales patrones de diseño presentes en la solución y se detallan y argumentan todas las decisiones del colectivo de autores. Palabras clave: Aplicaciones web, diseño, framework, ingeniería 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.

Introducción

Según 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 diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo. Concretamente define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo. (Jacobson, 2000a).
Siguiendo la línea de pensamiento anterior, cualquier empresa, grupo o entidad académica, que entre sus objetivos persiga la producción eficaz de un software que satisfaga las necesidades de un cliente – traducidas éstas en el grado de validación satisfactoria de cada uno de los requerimientos del producto en desarrollo- debe organizar sus procesos, actividades y recursos en función de lograr efectivamente la concatenación de las acciones descritas por los “Tres Amigos”.

alcanzar este fin no resulta sencillo. robusta. la poca experiencia del personal asociado al proceso. lo cual viene dado. se esperan como posibles resultados. Sin embargo. Desconocimiento del equipo del funcionamiento interno del framework. se establece como objeto de estudio: el diseño de aplicaciones web y como campo de acción el diseño de aplicaciones web utilizando Symfony. basada en las necesidades de los proyectos y orientada a la práctica.No obstante. Dado lo anterior. la documentación de la propuesta de diseño argumentada hasta aquí. en la práctica. mediante la cual otro proyecto de software puede ser organizado y desarrollado. Poca documentación o experiencias confiables en modelamientos similares. al interés de la comunidad internacional por estandarizar su uso y al interés particular del grupo de desarrollo donde se desenvuelven los autores de la investigación. si bien agiliza la implementación. 1 Estructura de soporte definida. se agilizará y hará más comprensible el proceso de diseño de aplicaciones web de este tipo. suponen un esfuerzo adicional del equipo que bien pudiera minimizarse con las prácticas y técnicas adecuadas. el cual forma parte de la larga lista de los desarrollados y construidos para ser utilizados teniendo como base el lenguaje de programación PHP. puede incluir soporte de programas. La presente propuesta de diseño se realiza asumiendo la selección del mencionado framework para PHP debido al creciente auge del mismo. por algunas de las causas siguientes: 1. a menudo los equipos de desarrollo de software presentan dificultades para logarlo. El hecho de utilizar y extender (ampliar) las características y funcionalidades de un determinado framework. Durante la investigación se defiende la premisa de que: si se desarrolla una propuesta de diseño. Estos factores frenan considerablemente el tiempo de desarrollo y más que esto. Uno de estos factores lo constituye la etapa del diseño de aplicaciones cuando se utilizan framework1 de desarrollo. 3. basada en las necesidades de los proyectos de software y orientada a la práctica. Todo lo anterior demuestra evidentemente la importancia de establecer una propuesta de diseño estándar. en la actualidad. Uno de los framework existentes en la actualidad. bibliotecas y un lenguaje interpretado entre otros software para ayudar a desarrollar y unir los diferentes componentes de un proyecto. Inexactitud en la profundidad de la modelación de las características del framework. actualmente provoca desorden y lentitud en el momento de generar la documentación adecuada. Variedad de propuestas de modelado para una misma situación poco confiables. . en la mayoría de los casos. que además. estándar. robusta. 2. De ahí que el objetivo general de la presente investigación sea: Elaborar una propuesta de diseño para proyectos informáticos que utilicen symfony como framework de desarrollo. Finalmente. está siendo muy utilizado en proyectos de desarrollo de software de altas envergaduras es Symfony. 4. Se origina entonces el siguiente problema científico: ¿Cómo perfeccionar el diseño de aplicaciones que utilicen Symfony como framework de desarrollo. existen otros factores importantes que vale la pena considerar. con el objetivo de agilizar este importante proceso en el desarrollo de un software y hacer más comprensible la documentación para el resto del equipo. las planificaciones irreales y la falta de compromiso del equipo son algunas de las causas más notables y comunes que se pueden presentar y de las cuales se ha reflexionado sobremanera en diferentes ámbitos.

Por otra parte. MVC sugiere la separación del software en tres componentes: Modelo. permitiendo al desarrollador dedicarse por completo a los aspectos específicos de cada aplicación. al igual que la mayoría de los existentes para PHP está desarrollado bajo las restricciones. Ciclo de vida del MVC El ciclo de vida del MVC es normalmente representado por los tres componentes presentados anteriormente y el cliente (también conocido como usuario o actor). etc. la “Vista” sería una página HTML con contenido dinámico sobre la cual el usuario puede realizar sus operaciones. procesando toda la información necesaria y modificando el Modelo en caso de ser necesario. Para empezar. 2007). Proporciona varias herramientas y clases encaminadas a reducir el tiempo de desarrollo de una aplicación web compleja. El resultado de todas estas ventajas es que no se debe reinventar la rueda cada vez que se crea una nueva aplicación web. suposiciones y recomendaciones de la Arquitectura Modelo-Vista. la lógica de servidor y la presentación de la aplicación web.Controlador (MVC). Ha sido probado en numerosos proyectos reales y se utiliza en sitios web de comercio electrónico de primer nivel a escala internacional. Se puede ejecutar tanto en plataformas *nix (Unix. Vista: Es la representación del modelo en forma gráfica disponible para la interacción con el usuario. El siguiente diagrama representa el ciclo de vida de manera sencilla: . Linux. como MySQL. PostgreSQL. Está desarrollado completamente con PHP 5. El modelo en sí lo constituyen los datos puros y la lógica de los propios datos que puestos en el contexto del sistema proveen de información al usuario y en algunos casos a la propia aplicación. Controlador: Es la parte encargada de manejar y responder las solicitudes del usuario. Arquitectura Modelo-Vista-Controlador desarrollada en Symfony El framework seleccionado.) como en plataformas Windows. los cuales serán explicados brevemente: Modelo: Es la representación de la información que maneja la aplicación. Oracle y SQL Server de Microsoft. Vista y controlador. automatiza las tareas más comunes. gracias a sus características.Desarrollo Generalidades de Symfony Symfony es un completo framework diseñado para optimizar. En el caso de una aplicación web. separa la lógica de negocio. el desarrollo de las aplicaciones web. Todo lo anterior hace de symfony un robusto framework que cada vez es más utilizado en el desarrollo de sistemas para la web (Fabien Potencier. Es compatible con la mayoría de los gestores de bases de datos.

tienen impacto en el sistema a considerar. y de ese modo también los subsistemas que contienen las clases de diseño. Ciclo de vida de Modelo-Vista-Controlador. el diseño del software es la primera de las tres actividades técnicas -diseño. De esto se obtiene como elemento significativo 3 clases de UML estereotipadas como “Server Page”. el modelo sirve de abstracción de la implementación del sistema y es. Una vez que se analizan y especifican los requisitos del producto. se recomienda utilizar los estereotipos y las extensiones web introducidas en el mundo de la Ingeniería de software en los finales de los años 90 por Jim Conallen el cual publica en el 1999 varios artículos donde describe cada una de las extensiones y cómo utilizarlas en este tipo de modelado. subsistemas y sus relaciones. en él se modela el sistema y se encuentra su forma (incluida la arquitectura) para que soporte todos los requisitos. respetando en todo caso las posibles relaciones que entre todas ellas pueden existir. incluyendo los no funcionales y las restricciones que se suponen. se representan la mayoría de las clases de symfony con las cuales el equipo de desarrollo interactúa. Una premisa fundamental que se defiende a través de la propuesta de diseño que se presentará a continuación ha sido la de representar únicamente las clases y extensiones web que guarden estrecha relación con la modelación de una solución en particular y ocultar el comportamiento interno del framework que en la práctica poco ayudan en el diseño. En esta etapa. generación de código y pruebas. También puede darse el caso de algunas operaciones. a menudo participan en varias realizaciones de casos de uso. La práctica cotidiana más común –y más acertada según los autores de esta investigación. El modelo de diseño es un modelo de objetos que describe la realización física de los casos de uso. utilizada como una entrada fundamental de las actividades de implementación (Jacobson. Se encuentra muy cercano al modelo de implementación. No obstante lo anterior. “Form” empleados para el código servidor. a sus objetos y a los subsistemas que contiene. centrándose en cómo los requisitos funcionales y no funcionales junto con otras restricciones relacionadas con el entorno de implementación. le regresa al controlador la información resultante de sus operaciones. Además. específicamente dentro de las actividades de diseño. De esta forma podemos guardar la pista de los elementos participantes en una realización del caso de uso” (Jacobson.supone mezclar estas tres extensiones con las tradicionales utilizadas en el diseño de aplicaciones fuera de la web. código cliente y formularios respectivamente. aún así. mostrando sus clases participantes. Esto es importante para coordinar todos los requisitos que diferentes realizaciones de casos de uso imponen a una clase.Fig. . Diagrama de clases del diseño Según la definición de los “tres amigos”: “Una clase de diseño y sus objetos. de ese modo.que se requieren para construir y verificar el software. Luego de terminada su labor. El primer paso en el ciclo de vida empieza cuando el usuario hace una solicitud al controlador con información sobre lo que él desea realizar. Para manejar todo esto. 2000b). 1. utilizamos diagramas de clases conectados a una realización de caso de uso. la implementación y las pruebas. 2000a). el modelo se encarga de realizar operaciones sobre la información que maneja para cumplir con lo que le solicita el controlador. Entonces el controlador decide a quién debe delegar la tarea y es aquí donde el modelo empieza su trabajo. el cual a su vez redirige a la vista la cual se encarga de transformar los datos en información visualmente entendible para el usuario. “Client Page”. atributos y asociaciones sobre una clase específica que son relevantes para sólo una realización de caso de uso. Modelos de diseño El diseño del software se encuentra en el núcleo técnico de la ingeniería de software. en el desarrollo de la modelación de aplicaciones web.

es a través de ellas que se establecen las relaciones entre las tablas. se encargan en conjunto de toda la lógica del negocio. Es importante acotar que el prefijo execute de las funcionalidades y el sufijo Action de la clase son obligatorios.Propuesta de diseño según MVC y diagrama de clases Según el estilo MVC que implementa symfony el diseño queda estructurado de la siguiente manera: El modelo: Constituido por dos partes fundamentales: la lógica de la aplicación. según el diseño de los mencionados datos implementado sobre algunos de los gestores que son compatibles con él. las acciones y el controlador frontal. coincidirán con las establecidas para la herencia. Esta capa se divide en dos partes fundamentales. contiene el código que liga la lógica del negocio con la presentación. 2. y todo lo que se refiere al acceso y abstracción de los datos.se propone representar solamente en el modelo las clases BaseNombreTabla pues son realmente las que proporcionan información acerca de la representación y organización de los datos en la BD. La representación del modelo una vez que symfony genera automáticamente las cuatro clases a partir de una tabla de la BD quedaría como se muestra en la siguiente Figura. además. agregación. NombreTabla y NombreTablaPeer: Son el corazón de la aplicación. BaseNombreTablaPeer las cuales se encargan en conjunto de realizar todo el acceso a los datos y la lógica de la aplicación. Las posibles relaciones.luego de acotado lo anterior con relación a las clases generadas por symfony. Para disminuir la complejidad de los diagramas de clases del diseño. BaseNombreTablaPeer: Contiene un conjunto de métodos estáticos que complementan el acceso y la lógica de los datos. NombreTablaPeer. BaseNombreTabla: Contiene todos los atributos definidos en la tabla y un conjunto de métodos ya implementados que gestionan el acceso a los datos y aceleran y simplifican el trabajo del equipo. Fig. traduce por cada tabla real de la Base de Datos (en lo adelante BD) cuatro clases: NombreTabla. Symfony genera automáticamente todas las clases del modelo utilizando Propel. BaseNombreTabla. Modelo Genérico generado por Symfony. en todos los casos. Constituyen responsabilidades con el nombre execute<NombreAccion> de la clase <NombreModulo>Action que a su vez hereda de la clase sfActions. . El controlador: La capa del controlador se encarga de procesar las interacciones del usuario. Las acciones: Se encargan de obtener los resultados del modelo y definen variables para la vista. composición o asociación.

php. insertarse en el cuerpo del layout y generar finalmente la página web resultado de la petición de un usuario. Esta plantilla tiene el mismo nombre que el sufijo de la acción correspondiente y termina con el sufijo Success. El contenido de la plantilla se integra en el layout. carga la configuración y determina la acción a ejecutarse. la acción utiliza el modelo (no obligatoriamente) y almacena los resultados que serán accesibles desde la vista (específicamente los archivos success). Páginas clientes y formularios: Son las páginas que se generan finalmente producto de la construcción del layout y la plantilla y con las que el usuario interactúa. Ejemplo: para una acción executeIndex existirá una plantilla indexSuccess. para no tener que repetirlo en cada una de ellas.los cuales se encargan de todo el proceso de acceso . todas las peticiones son manejadas por él que ayudado por los demás componentes del framework realizan todo el trabajo transparente al programador. representa un archivo .Esta clase ubicada en la capa controladora de la arquitectura MVC hereda el comportamiento y las características de la clase sfActions que forma parte del framework. el complemento de las acciones (llamado plantilla) y las páginas con sus formularios. Diagrama de clases del diseño. Finalmente la propuesta queda como sigue: Fig. el layout (conocido como plantilla global). El layout: Almacena el código HTML que es común a todas las páginas de la aplicación. Se recomienda nombrar el archivo php como el mismo nombre de la aplicación que se desarrolla. La vista: Se encarga de producir las páginas que se muestran como resultados de las acciones. El complemento de las acciones o plantilla: Son las encargadas de. el flujo de información según lo representado anteriormente funciona como se explica inmediatamente: El controlador frontal recibe una petición (generalmente una URL). luego de invocada. Para el modelo devolverle los resultados a las acciones utiliza un ORM (Object Relational Mapping) y una capa de abstracción –que en el caso del framework seleccionado se trata de Propel y Creole respectivamente. luego de recibirla. De manera general. El controlador frontal: Es el único punto de entrada a la aplicación. la cual se encapsula en la presente propuesta dentro de un paquete denominado componentes de symfony que engloba el funcionamiento interno del framework. Contiene tres partes fundamentales. con los resultados de la acción. 3. o si se mira desde el otro punto de vista. determina el módulo y la acción que deben invocar (a través de un proceso llamado sistema de enrutamiento). el layout decora la plantilla. además. y ayudado por los denominados “componentes de symfony” (paquete que encapsula el resto del comportamiento interno del framework).

sin tener que hacerlo del mismo modo dos veces". 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 aplicación y que quedan encapsulados dentro del paquete “componentes de symfony” mostrado en el diagrama. Patrones de diseño presentes en la propuesta Según Christopher Alexander (uno de los primeros en introducir el termino patrones) "Cada patrón describe un problema que ocurre una y otra vez en nuestro medio ambiente. entonces. 1994). Componentes que a menudo se utilizan en Symfony. Databases: Se establece a nivel de proyecto. a decir de estos últimos: Los patrones de diseño se refieren a las descripciones de comunicación de las clases y los objetos que pueden personalizarse para resolver un problema de diseño general en un contexto particular. el cual. la cual tiene la responsabilidad de definir las acciones para las plantillas y. View: Se establece a nivel de aplicación. contiene la configuración necesaria para implantarle seguridad a determinada acción. es posible utilizar esta solución un millón de veces más. Patrón alta cohesión: El uso de este patrón se evidencia en la implementación de la clase Action. contiene la configuración necesaria para que determinada plantilla (success) utilice archivos javascript. al volver a interactuar con ella desembocaría el inicio nuevamente del flujo anterior. su nombre debe corresponder con la acción a validar. 4. 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 página cliente que es lo que finalmente es mostrado al usuario. A continuación. los componentes de symfony. 2007). contiene la configuración necesaria para establecer la conexión a la BD que se utilizará en la aplicación. Aún cuando Alexander estaba hablando de patrones de construcción en la arquitectura civil. se exponen algunos ejemplos de patrones que fueron tenidos en cuenta en el momento de desarrollar la propuesta. paralelo a esto colabora con otras para realizar diferentes operaciones. instanciar . Security: Se establece a nivel de aplicación. Validate: Se establece a nivel de módulo.Oriented Software” (Erich Gamma. lo que dice es cierto acerca de los patrones de diseño 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. Symfony. si a esto le agregamos la descripción del núcleo de la solución a ese problema. Nuevamente. Fig. al igual que la mayoría de los framework sigue las mejores prácticas y patrones de diseño para la web (Fabien Potencier.y abstracción de los datos. contiene la configuración necesaria para realizar las validaciones del lado del servidor de una acción determinada.

retrasan e incluso detienen el proceso debido a la poca experiencia y a la inexistencia de un estándar para diseñar. está formada por diferentes funcionalidades que se encuentran estrechamente relacionadas. son manejadas por un solo controlador frontal. lento y a menudo se afecta debido a situaciones que pudieran tener solución con prácticas adecuadas. el layout decora el contenido de la plantilla.objetos y acceder a las propiedades. Una de las situaciones anteriores lo constituye el diseño de aplicaciones web utilizando framework de desarrollo. internacional y por el auge de éste en la implementación de aplicaciones web modernas. La propuesta se establece para el framework Symfony por el interés local. que también se denomina plantilla global. para no tener que repetirlo en cada página. dinámicamente. robusta. se agilizará y hará más comprensible el proceso de diseño de aplicaciones web de este tipo. almacena el código HTML que es común a todas las páginas de la aplicación. puede ser accedido desde cualquier punto de la aplicación. no se conoce ninguna otra propuesta. 4. Patrón creador: En las mencionadas clases se encuentran las acciones definidas para las operaciones lógicas del negocio en cuestión y se ejecutan cada una de ellas. En las acciones se crean los objetos de las clases que representan las entidades. El archivo layout. de su tipo. es muy engorroso. la propuesta respeta y utiliza algunos patrones de diseño que contribuyen a su robustez. 8. 6. 3. La utilización de la presente propuesta minimizaría el tiempo y los esfuerzos que actualmente los equipos de desarrollo dedican al diseño de aplicaciones. El proceso de desarrollo que se lleva a cabo con el objetivo de lograr un producto de software. estándar. Patrón creacional Singleton: Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia. la cual almacena una referencia a todos los objetos que forman el núcleo de Symfony y muy provechosamente. que según se explicó. En el controlador frontal hay una llamada a sfContext::getInstance().php. éstas. Conclusiones Una vez finalizada la investigación y como producto de su desarrollo se considera importante resaltar una serie de conclusiones las cuales se enumeran a continuación: 1. La propuesta de diseño que ha sido presentada en esta investigación sigue la premisa de representar únicamente las clases y extensiones web propias de la solución particular y ocultar el comportamiento del framework ajeno al equipo de desarrollo. al menos en el área donde se desarrollan los autores de la investigación. Patrón estructural decorator (envoltorio): Añade funcionalidad a una clase. El contenido de la plantilla se integra en el layout. basada en las necesidades de los proyectos de software y orientada a la práctica. Esta propuesta representa un hito importante en aras de estandarizar el diseño de aplicaciones web debido a que. El controlador es encargado de recibir la petición del usuario y en función de ella. esto evidencia que la clase Actions es "creadora" de dichas entidades. Finalmente. o si se mira desde el otro punto de vista. . Patrón controlador: Todas las peticiones eb. en la actualidad. 7. Si se desarrolla una propuesta de diseño. expresado de otra manera. 2. envía la solicitud a las distintas clases para que sea procesada. 5. es el punto de entrada único de toda la aplicación para un entorno determinado. generalmente.

435 p. - . 2000a. 3.Recomendaciones Los autores de la investigación recomiendan: 1. J. R. B. 2. y. 5. P. R. P. Documentar los efectos positivos y negativos que se obtienen producto de su aplicación. Sistema automatizado para la gestión de los datos del balance nacional de recursos y reservas de petróleo y gas de la oficina nacional de recursos minerales. Hidalgo. B. r. Ciudad de la habana. Pressman. universidad de las ciencias informáticas. Un enfoque práctico. Fabien Potencier. la guía definitiva. G. Symfony. Ingeniería del software. Ampliar el campo de acción de esta investigación con el objetivo de proponer un diseño de aplicaciones estándar para cualquier framework de desarrollo que utilice el lenguaje PHP y la arquitectura Modelo-Vista-Controlador. D. 2007. F.. El proceso unificado de desarrollo de software. R.. G. Referencias Bibliográficas - Erich Gamma. 2000b. Z. F. J. Ivar Jacobson. john Vlissides. P. P. Madrid. 2006. El lenguaje unificado de modelado. Ralph Johnson. y. G. - Ivar Jacobson. 2005. Aplicar la propuesta a proyectos de desarrollo de software pilotos.. P. S. Design patterns: elements of reusable object-oriented software 1994.

Sign up to vote on this title
UsefulNot useful