Conclusiones y recomendaciones

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.
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.
•
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.
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?
-
¿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
Delete
Insert
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.
-
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 lógica
Capa idioma
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