Conclusiones y recomendaciones

Transcripción

1 Conclusiones y recomendaciones El MD5C otorga, al grupo de desarrollo, 3 vistas claramente definidas en base a: a. Los tipos de presentación y subpresentación que tiene la aplicación. b. Las 5 capas que plantea el modelo. c. Los niveles y componentes que existen en la aplicación a. Los tipos de presentación y subpresentaciones proporcionan los límites de las áreas que existen en el diseño de las distintas interfaces de nuestra aplicación. b. Diferenciación a alto nivel de los alcances que tiene cada capa en el sistema o en alguna área específica dentro de él. c. Los niveles de la aplicación otorgan las distintas escalas de modularidad que posee nuestra aplicación y las componentes abstraen el concepto de un objeto para un determinado nivel. Su combinación otorga un desarrollo en base a una jerarquía o herencia. Proceso de desarrollo Permite el trabajo en conjunto entre los analistas, diseñadores, programadores, etc. otorgándole a cada uno de ellos cierta independencia de avance. Minimiza el tiempo de desarrollo al permitir el trabajo en paralelo de diferentes niveles y distintos componentes para un nivel específico Cualquier agregación, modificación o eliminación de cualquier funcionalidad en un componente se realiza de manera sencilla, rápida y transparente. El MD5C facilita la creación de versiones ya sea para un nivel o componente siempre y cuando se mantenga el mismo kernel de la aplicación, en caso contrario también da la posibilidad de la creación de otro kernel que pueda interactuar con el anterior. Se puede identificar errores en el sistema por medio de las 3 vistas que otorga el MD5C, las cuales permiten aislarlos y detectarlos de manera rápida. La capa plantilla permite la existencia de diferentes plantillas para la misma plataforma del cliente otorgando la posibilidad de escoger uno u otro diseño.

2 También permite tener diferentes plantillas por cada plataforma del cliente a la que se quiera dar soporte: navegadores web, navegadores WAP, etc. El MD5C soporta múltiples idiomas. Integrar otro idioma es sencillo y transparente de cara al resto de capas. El MD5C no forma parte del análisis requisitos. Su utilización se realiza desde las primeras fases del diseño de la aplicación. Permite una mejor administración y control de variables utilizadas para la interacción con el usuario en cada una de las componentes. Permite la construcción de procesos en donde no interviene el usuario: la capa de presentación no participa del resultado puesto que no existe el requerimiento que el usuario perciba determinado resultado. Estos procesos ocultan al usuario las capas de presentación y de idioma. Calidad de la aplicación resultante El MD5C garantiza código legible debido a la diferenciación de las capas y ordenamiento en base a los niveles y componentes que tenga la aplicación. El trabajo a través de presentaciones y subpresentaciones beneficia enormemente en la especialización y optimización de procesos que se realizan en cada uno de ellos debido a que son independientes y autónomos. El MD5C brinda las herramientas para conseguir el aseguramiento de la calidad del software: Corrección, a través de la capa lógica; Fiabilidad, por las claridad de los límites de las componentes; Eficiencia: ayuda a minimizar procesos duplicados; Integridad, por la sinergia que proporciona las componentes y niveles del sistema y Facilidad de uso, a través de la capa plantilla. Alta capacidad para soportar cambios proporcionando: alta facilidad de mantenimiento por la claridad de los límites en las 3 vistas que permite el modelo, alta flexibilidad en la agregación de componentes del sistema para un cierto nivel y alta facilidad de pruebas a través de las 3 vistas. Garantiza la adaptabilidad a nuevos entornos (transportabilidad) para cambio de servidores el cual depende de la implementación de las capas y permite la Reusabilidad de las componentes del sistema dado que estos son autónomos en los distintos niveles de la aplicación o con otras aplicaciones externas a ella. Permite una abstracción conceptual del sistema a través de las vistas del modelo. Esfuerzo y nivel de reuso El MD5C es aplicable a cualquier sistema de información en donde se pueda diferenciar las cinco capas que plantea el modelo. Su aplicación es absolutamente independiente a las reglas del negocio para las que se desea desarrollar el sistema. El MD5C garantiza un alto nivel de reuso a través de la tres vistas que otorga, es decir diseños completos o parciales, ya sea por presentaciones o subpresentación, las cinco capas y, los niveles y componentes de la aplicación.

3 Los procesos que tenga la aplicación puede estar asociado a una o varias de las capas del modelo. Curva de aprendizaje El aprendizaje y entendimiento de las características del modelo requiere de una inversion de tiempo por parte del grupo de desarrollo. Para obtener los beneficios que otorga una buena implementación del MD5C el grupo de desarrollo debe: 1. Tener claro las diferencias en las capas y los límites que existen entre ellas. 2. Poder abstraer las presentaciones y las subpresentación que se van a utilizar en la aplicación. 3. Aprender a definir los niveles y componentes que se van a tener en la aplicación. 4. Saber dividir un evento en la aplicación en las capas. El tiempo invertido por el grupo de desarrollo otorga la capacidad de minimizar en grandes proporciones el desarrollo de la aplicación: rapidez de desarrollo y facilidad de mantenimiento. Minimiza el tiempo en la lectura de los códigos de la aplicación así como el tiempo para detección y corrección de errores. Tecnologías y alcance i. Metodologías de desarrollo El MD5C es independiente a cualquier metodología de desarrollo por lo que puede ser utilizado con las distintas metodologías que existen o que más adelante aparezcan. Debido a la gran facilidad de mantenimiento y la rapidez en la creación de nuevas funcionalidades tiene un alto desempeño en aquellas aplicaciones donde se utiliza la metodología de desarrollo en espiral. ii. Lenguajes de programación El MD5C es independiente a cualquier lenguaje de programación. Este fue ideado inicialmente para la creación de software Web lo que acotaba a aquellos lenguajes de programación relacionados a dichos entornos: PHP, JSP, ASP, etc. Pero debido a que es un modelo que puede ser aplicado en cualquier otro escenario, el MD5C necesita que el lenguaje a utilizar permita la diferenciación de las 5 capas que corresponden al modelo. iii. Paradigma de desarrollo El MD5C es independiente cualquier paradigma de desarrollo (estructurado u Orientado a objetos). iv. Tipos de aplicaciones El MD5C está dirigido a cualquier aplicación más o menos compleja, desde páginas web estáticas, utilizándola como soporte para un CMS, hasta aplicaciones complejas relacionadas directamente con el negocio de la empresa.

4 Recomendaciones en la implementación Se recomienda que antes de la utilización del MD5C y después de conocer como trabaja el mismo y se haya decidido aplicar el modelo se tenga al menos un bosquejo o una noción básica del sistema que se va a desarrollar en base a las siguientes perspectivas: - De Negocio: cómo opera, procesos y flujos de tareas principales para definir las reglas de negocio y la secuencia de operaciones que se realizan. - De la aplicación: conociendo las componentes que son comunes para cualquier evento que se realiza dentro de la aplicación,. - De Información: manejo del flujo de información para diagramar las presentaciones y subpresentación que necesita la aplicación así como el diseño de la forma de almacenamiento tanto de los datos como los idiomas. - Tecnología: estándares que se va a utilizar, plataformas que va soportar, etc. La parte más importante de la aplicación es el kernel del mismo. Es por esto que para el diseño del kernel se recomiendo especial cuidado en la definición de: - Variables de control del kernel - Variables y constantes de entorno del kernel - Variables de sesión de la aplicación - Verificación de autentificación del punto de interacción (Ej: index.phtml) - Incluir los archivos necesarios para la existencia de la aplicación - Variables y constantes globales de la aplicación En el caso que se utilice un único punto de entrada (index.phtml) en la aplicación para distintos tipos de presentaciones se recomienda crear la lógica de decisión la cual debe ser llamada desde el punto de entrada para que éste decida, en base a ciertos atributos, qué tipo de presentación se va a utilizar. Se recomienda que el objeto utilizado para la creación de la página permita la flexibilidad de los siguientes atributos: - Plantilla de la presentación - Agregar lógica global - Agregar hojas de estilo (CSS) - Javascript (JS) - Cambiar al menos una subpresentación en un tipo de presentación flexible - Atributos que pertenecen a las subpresentaciones - Llenado de la plantilla. Para la creación de las subpresentaciones que conforman una presentación se recomienda crear la lógica de administración en base a las acciones que se pueden realizar en la subpresentación teniendo en consideración los siguientes puntos: - Cuáles son las acciones que puede realizar el usuario en la subpresentación? - Qué acciones se van controlar desde la misma lógica de la aplicación?

5 - Va a utilizar otras subpresentaciones para su creación? - Qué contenido se obtendrá de las otras subpresentaciones? - Qué condiciones se van a considerar para realizar las acciones? - Cuáles son las partes de las plantilla para el proceso de llenado? La creación de librerías en nuestra aplicación debe realizarse en lo posible para cada nivel relevante. A continuación se definen algunos tipos de librerías que se pueden considerar: - Capa presentación: a través de funciones que tengan variables de entrada o Lógica subpresentación o Lógica idioma o Lógica plantilla - Capa lógica: a través de funciones que tengan variables de entrada o Lógica Consulta o Lógica Proceso - Capa Plantilla - Capa Idioma (Sólo cuando es almacenado en archivos) - Capa Datos (Sólo cuando es almacenado en archivos) Para la creación de la lógica de consulta (capa lógica) por ser independiente a la presentación y las subpresentaciones, se recomienda la estructura mostrada en la Figura 6.1 para el almacenamiento ordenado de los archivos utilizados para este propósito. Carpeta para Lógica Consulta Insert Delete Select Update Figura 6.1: Distribución de carpetas de la lógica de consulta En la Figura 6.1 muestra la distribución de la consultas a través de las carpetas: _del, _ins, _sel, _upd para los DELETE, INSERT, SELECT y UPDATE respectivamente. La carpeta _ins/_sel son para las consultas INSERT SELECT y la carpeta _sel/_join para SELECT con JOIN, es decir de varias tablas ya sea con INNER JOIN o LEFT JOIN. Para la administración de estás lógicas de consulta se recomienda crear un administrador de la lógica de consulta, el cual debe contemplar los siguientes puntos: - Que permita agregar un PATH correspondiente a la estructura antes mencionada (nivel) donde se van a encontrar las categorías posibles para este nivel.

6 - Que incluya el archivo donde se encuentra la consulta una sola vez. - Obtención de los archivos incluidos para un tiempo t. - Obtención de los niveles existentes y sus categorías posibles por nivel. - Obtención de errores posibles por que no se ha encontrado el archivo de la consulta para la categoría escogida en un determinado nivel. Para la creación modular se otorga la siguiente distribución que puede ser utilizada también para las librerías donde: _core/ utilizado para almacenar la lógica de proceso en ella se puedo invocar a la lógica de consulta (capa lógica), _lang/ en donde se almacena las traducciones de ciertas constantes a través de un archivo por idioma (capa idioma), _lead/ para la lógica de subpresentación, _out en donde se realiza la lógica de plantilla (capa presentación) y por último _tpl/ para almacenar las plantillas (capa plantilla). Ver Figura 6.2. Capa idioma Capa lógica Capa presentación Capa plantilla Figura 6.2: Distribución de carpetas para las capas Se debe tener en cuenta que el idioma puede variar la forma de presentar la página, los resultados, etc. es decir que lo que corresponde a la lógica de plantilla es posible que cambie en dependencia del idioma seleccionado. También puede darse el caso de que el capa idioma tenga relación directa con la capa de datos, por ejemplo las traducciones para los menús del sistema; para estos casos la lógica consulta con la lógica idioma trabajan conjuntamente para obtener un resultado en el cual ya existe el código (capa datos) y el nombre (capa idioma) para que el usuario interprete de manera fácil el resultado. Aunque existe esta relación tan estrecha no significa que no se puedan mantener las diferencias respectivas en cada capa. Queda totalmente implícito que las recomendaciones que se presentan en este documento tienen como objetivo mantener las diferencias entre las 5 capas que plantea el modelo. Por tanto cualquier alteración o modificación del desarrollador o del grupo de desarrollo en el sistema para la implementación del MD5C es viable siempre y cuando mantenga claramente las diferencias entre las capas.

7 7