SlideShare una empresa de Scribd logo
© 2008 Telmex S.A.
Arquitectura de Aplicaciones
Gerencia de Analisis y Desarrollo de Sistemas
All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or
mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the
written permission of the publisher.
Products that are referred to in this document may be either trademarks and/or registered trademarks of the
respective owners. The publisher and the author make no claim to these trademarks.
While every precaution has been taken in the preparation of this document, the publisher and the author assume no
responsibility for errors or omissions, or for damages resulting from the use of information contained in this
document or from the use of programs and source code that may accompany it. In no event shall the publisher and
the author be liable for any loss of profit or any other commercial damage caused or alleged to have been caused
directly or indirectly by this document.
Printed: Octubre 2008 in (whereever you are located)
Arquitectura de Aplicaciones
© 2008 Telmex S.A.
Arquitectura de Aplicaciones4
© 2008 Telmex S.A.
Lista de contenidos
Foreword 6
Apéndice A - Objetivos 8
................................................................................................................................... 81 Contexto
................................................................................................................................... 82 Del presente documento
................................................................................................................................... 83 Del código fuente
................................................................................................................................... 84 De la arquitectura
................................................................................................................................... 85 Historia de Revisiones
Apéndice B - Arquitectura interna 11
................................................................................................................................... 111 Orientación a Objetos
................................................................................................................................... 112 Lógica distribuida en capas
..........................................................................................................................................................12Capa de Persistencia
..........................................................................................................................................................13Capa de Acceso a datos
..........................................................................................................................................................13Capa Tipos Comunes
..........................................................................................................................................................14Capa de Servicios
..........................................................................................................................................................14Capa Presenter de interfaz
..........................................................................................................................................................14Capa de interfaz de usuario
................................................................................................................................... 143 Del mantenimiento de la vista
................................................................................................................................... 144 Patron MVP
................................................................................................................................... 155 Mínimo acoplamiento
................................................................................................................................... 156 Abstraccion del modelo de persistencia
................................................................................................................................... 167 Simplicidad del código
Apéndice C - Arquitectura externa 18
................................................................................................................................... 181 De la división estructural de las aplicaciones
..........................................................................................................................................................18Vantive
..........................................................................................................................................................18Desarrollos adicionales al estándar
..........................................................................................................................................................18Herramientas CORE
..........................................................................................................................................................19Grafica de división
................................................................................................................................... 192 De los componentes estándar
................................................................................................................................... 193 De los requerimientos técnicos
................................................................................................................................... 204 De los puntos críticos a considerar
Apéndice D - De la metodología de instalación 22
................................................................................................................................... 221 De la escalabilidad y estabilidad en la instalación
................................................................................................................................... 222 Del proceso de deployment
................................................................................................................................... 223 Del control de versiones
................................................................................................................................... 224 De las estrategias de migración
5Contents
5
© 2008 Telmex S.A.
Foreword6
© 2008 Telmex S.A.
Apéndice A
Arquitectura de Aplicaciones8
© 2008 Telmex S.A.
1 Objetivos
1.1 Contexto
El área de sistemas de TELMEX se dispone a ofrecer servicios de desarrollos a la misma
empresa productos para facilitar diversos procesos, bajo los siguientes objetivos
· Rápida velocidad de respuesta en la solución
· Aprovechar el acceso y la existencia de información transversal de VANTIVE
para agilizar diversos procesos, y ofreciendo soluciones especificas.
· Generar un ahorro en los presupuestos de migración reutilizando módulos
desarrollados o a desarrollarse.
· Alineación con normas de desarrollo de TELMEX.
1.2 Del presente documento
Documentar la arquitectura general de toda aplicación .NET para los presentes y futuros
desarrollos.
Identificar los posibles puntos débiles a mejorar en próximas etapas de desarrollo.
Documentar las estrategias de migración progresiva y convivencia con las actuales
aplicaciones ASP/PHP.
1.3 Del código fuente
Buen nivel de reutilización, código simple y de fácil mantenimiento. Clara identificación del
negocio que desea resolver. Desarrollo progresivo. Patrones de desarrollo y applications
blocks. Abstracción completa de la persistencia.
Asi mismo, se generó un documento de buenas practicas para inducir al desarrollador a
mejorar sus habitos.
1.4 De la arquitectura
Escalable, estructura de aplicaciones empresariales, con capacidad para implementación
en diferentes ambientes con ciclos de desarrollo de diferentes tiempos. Uso de
componentes de arquitectura SOA controlado.
Puntos críticos identificables. Uso de componentes homologados.
Flexibilidad para implementación en diferentes infraestructuras.
Optimización y control del uso de memoria y ancho de banda, capacidad para soportar
gran nivel de concurrencia.
1.5 Historia de Revisiones
Fecha Versión Descripción Autor
Objetivos
© 2008 Telmex S.A.
9
13/10/2008 1.0 Creación del Documento José Franco
Apéndice B
Arquitectura interna
© 2008 Telmex S.A.
11
2 Arquitectura interna
2.1 Orientación a Objetos
En el código resultante se aplicarán los principios de la POO haciendo especial énfasis en
los siguientes ítems:
· Abstracción completa del modelo de persistencia: Esto se logra con objetos en la
capa de negocios que provean métodos para recuperar los datos y modificarlos.
· Objetos de bajo de acoplamiento
2.2 Lógica distribuida en capas
Se identifican las siguientes capas con sus límites claramente definidos
La ubicación de lógica aplicada en la capa incorrecta esta prohibida.
Arquitectura de Aplicaciones12
© 2008 Telmex S.A.
La interoperabilidad con los Servicios Web, se muestra a continuación.
2.2.1 Capa de Persistencia
Se refiere a la base de datos, bajo las siguientes premisas:
· Acceso a los datos sólo por SP.
· No puede existir lógica del negocio en el Store Procedure, la complejidad sólo será
admitida para optimizar el resultado de la consulta.
Arquitectura interna
© 2008 Telmex S.A.
13
· Se priorizará restringir los paquetes a un set de 4 métodos.
· GetList: selección de todos los campos, descripciones de claves foraneas incluidas,
ordenamiento por parámetro de los campos, busqueda por like en campos de texto,
paginación de resultado. En el Anexo I, template de selección.
· GetByPk: selección por clave primaria.
· Insert.
· Delete.
· Update: Con control de concurrencia.
· No utilización de SQL dinámico: a fin de permitir el uso de un plan de ejecución.
· Funciones: Restringidas a auxiliar consultas de selección para optimizar resultado,
no se admite otra lógica aplicada.
· Triggers: No, restringidas a los estandares de VANTIVE.
· Seguridad: Autenticación de usuario único con acceso al esquema particular del
negocio, acceso a los datos a través de vistas, seguridad de acceso a los datos
controlada por la aplicación.
· Paginación: No pueden existir Store Procedures de busqueda de datos sin limitar el
resultado y ofrecerlo por páginas.
· Tracking: Para lógica compleja necesaria para interactuar con VANTIVE, se usará
un SP para abrirse de la arquitectura de las aplicaciones.
2.2.2 Capa de Acceso a datos
Provee el acceso a los datos, dividida en tres secciones, esta capa no puede contener
ninguna referencia de lógica de negocio.
· Componente de Acceso a Datos: DataAccess homologado por TELMEX y otros
componentes de acceso a datos (VANTIVE, SAP, driver nativos).
· Interfase de comunicación con los componentes: Basada sus métodos en MS
DataAccess Application Block, principalmente hace de un wrapper con los
diferentes componetes de acceso a datos
· Clases de comunicación con el componente: Implica la declaración de los
parámetros, en una forma independiente al componente de acceso a datos, a esta
llegan tipos de datos abstractos propios del lenguaje (Dataset, tipos nativos)
2.2.3 Capa Tipos Comunes
Capa de tipo colaboradora, se hace hincapié en que la comunicación entre capa debe
efectuarse con tipos de datos abstractos. Esta capa posee acoplamiento con el negocio
de la aplicación, su existencia y separación es para simplificar la estructura del código.
Entre las características de la misma encontramos
· Tipos abstractos de datos: Sin lógica de negocio asociada, generalmente
derivaciones de tipos provistos del framework con mayores funcionalidades o
clases contenedoras de datos asociados a circuitos de negocio para comunicarse
entre capas.
Arquitectura de Aplicaciones14
© 2008 Telmex S.A.
2.2.4 Capa de Servicios
Contiene un proveedor de servicio, pudiendo acceder a cada servicio de cada entidad
existente en nuestro proyecto.
· Objetos de lógica: Clases instanciables que permiten resolver problemáticas
concretas del negocio, por lo general tendrán una correspondencia con lo requerido
por el objeto visual. Concentra la totalidad de la funcionalidad del negocio
(validaciones, campos calculados, etc). Los objetos de negocio son serializables
para poder ser persistidos en caso de que sea necesario.
2.2.5 Capa Presenter de interfaz
Por aplicación del patrón MVP, se encargará de transformar la información entre la capa
de servicio y la interfaz de usuario, dominará la traducción de los contenidos, la
transformación de datos para proveerla a la interfaz.
Actúa como controlador de interfaz de usuario, de fuerte acoplamiento con las páginas a
las que asiste. Cada página obligatoriamente contendrá una interfaz.
La pagina hablara exclusivamente con su controlador, salvo que la funcionalidad requerida
no implique presentación o envio de datos.
2.2.6 Capa de interfaz de usuario
Compuestas por los paginas aspx que conformarán el sitio web, el código del codebehind
se restringirá al consumo de las funcionalidades y los datos provistos por la capa
controladora
El flujo de ejecución de la aplicación es dominado por la interfaz pero regla de negocios
tendrá la decisión final acerca de si se provee funcionalidades y datos para la
funcionalidad solicitada.
El control del flujo será monitoreado desde funciones core invocadas desde el global.asax
antes de resolverse cada petición de datos. En ella se llevará registro de la navegación
del usuario.
2.3 Del mantenimiento de la vista
El presenter será instanciado en cada petición, no siendo guardado ni serializado en
ningún componente, para guardar estados.
2.4 Patron MVP
La implementación de este patrón se debe principalmente a los siguientes aspectos:
· Reducir al mínimo el código alojado en el aspx y restringirlo simplemente a código
de presentación y de configuración de los componentes visuales.
· Prever modificaciones en la visualización que tengan mínimo impacto en el resto del
código.
· Evitar toda lógica no propia de la vista en los aspx para poder efectuar soluciones
con capas de presentación en otras tecnologías (flash, winform)
Arquitectura interna
© 2008 Telmex S.A.
15
MVP Pattern:
2.5 Mínimo acoplamiento
Dentro del código que se va desarrollando se obtienen un conjunto de clases de alta
reutilización asociadas al manejo de datos tales como buscadores y objetos de alta, baja,
modificación y consulta de datos, los cuales se corresponden con una o varias entidades
existentes en el modelo de datos.
Estas clases desarrolladas en forma independiente a la especificación puntual de negocio
son utilizadas en varios subproyectos del sitio, razón por la cual, son alojadas en un
ensamblado diferente al de cada aplicación.
2.6 Abstraccion del modelo de persistencia
El objetivo de esta implementación es independizarse del medio de almacenamiento.
Se logra accediendo a las entidades del modelo de datos a través de las clases
representativas en regla de negocio.
Cada entidad podría estar almacenada en diferentes modelos de persistencia (SAP, Oracle,
SQL Server, PeopleNet (m4objects), VANTIVE ).
Al obligar acceder exclusivamente a través de las clases de servicio para recuperar los
datos, nos independizamos completamente del medio y hasta podríamos controlar
procesos transaccionales entre diferentes plataformas.
Ademas de la inclusión de conceptos de AOP. Como IoC, y Service Factory.
Arquitectura de Aplicaciones16
© 2008 Telmex S.A.
2.7 Simplicidad del código
Se logra a través de la utilización de clases instanciables.
Se evita la utilización de métodos estáticos con una gran cantidad de parámetros para
lograr establecer el contexto antes de resolver el negocio.
Al utilizarse variables de instancia, los métodos se simplifican, el objeto tiene mayor
control del negocio y se logran encapsular muchas funcionalidades
La desventaja de esta implementación es el uso que hacen estos objetos de la memoria,
es por ello que se aplican reglas en todas las capas para evitar saturaciones de la misma.
Asimismo, con el fin de lograr mayor simplicidad, existen normas específicas de
nomenclatura, longitud de los métodos, nombre de métodos, templates de clases, etc.
Apéndice C
Arquitectura de Aplicaciones18
© 2008 Telmex S.A.
3 Arquitectura externa
De la división estructural de las aplicaciones
Se detecta tres bloques principales de funcionalidades los cuales tienen ciclos de
desarrollo diferentes, medios de persistencia separados, y que pueden ser afectados por
migraciones en momentos distintos.
3.1 De la división estructural de las aplicaciones
3.1.1 Vantive
<<pendiente>>
3.1.2 Desarrollos adicionales al estándar
Contempla todos aquellos desarrollos que no estén dentro del estándar del sistema de
gestión de TELMEX.
3.1.3 Herramientas CORE
Se refiere al conjunto de clases que proveen funcionalidades para la ejecución del sitio,
resuelve los aspectos de seguridad (autorización y autenticación), navegación (control del
flujo de ejecución), espacios de memoria compartida (objeto SessionManager),
regionalización (traducción de contenidos y presentación), etc.
Estas herramientas requieren acceder a un repositorio de datos especial donde guardar
información de configuración el cual es completamente independiente de los anteriormente
descriptos.
Asimismo, dentro de las herramientas CORE, encontraremos los módulos (controles y
páginas) que dominan el flujo de ejecución de las subaplicaciones de TELMEX y proveen
funcionalidades para comunicarse entre ellos.
El ciclo de desarrollo de las herramientas CORE es mas lento, con ciclos de versiones
amplios, de gran estabilidad.
Estos módulos (ensamblados) deben poder ser accedidos desde cualquier subaplicacion,
razón por la cual deben estar instalados en la GAC del servidor de web.
Arquitectura externa
© 2008 Telmex S.A.
19
3.1.4 Grafica de división
<<pendiente>>
La grafica divide los servidores como repositorios de datos distintos, no necesariamente
representan una arquitectura física de esta distribución, aunque al menos si marca
diferentes esquemas de base de datos para cada uno de los grupos.
En el caso de los desarrollos especiales, estos a su vez pueden dividirse en múltiples
esquemas que encierren las entidades particulares de cada negocio.
3.2 De los componentes estándar
No se tiene previsto utilizar componentes de terceras partes, en caso de que así sea se
evaluará conveniencia y se elevará a consideración de responsables de Tecnología.
Se procura utilizar la paleta de componentes estandar incluida en el framework .Net
2.0.50727.
3.3 De los requerimientos técnicos
Conforme a los puntos anteriormente detallado se desprenden los siguientes
requerimientos técnicos
· Servidor IIS con las siguientes caracteristicas:
· Framework .NET v2.0.50727
· .NET Framework 2.0 Software Development Kit (SDK)
Ambientes de Desarrollo, Test, Pre-Producción y Producción para cada paquete.
Arquitectura de Aplicaciones20
© 2008 Telmex S.A.
3.4 De los puntos críticos a considerar
<<pendiente>>
Apéndice D
Arquitectura de Aplicaciones22
© 2008 Telmex S.A.
4 De la metodología de instalación
4.1 De la escalabilidad y estabilidad en la instalación
La separación indicada en 4.1 garantiza líneas de desarrollo separadas con ciclos de
estabilización diferentes.
La estructuración de subproyectos bajo el esquema ejemplificado en 4.1.5.1 garantiza
procesos de instalación independientes y permitirían usar las funcionalidades de rollback
en instalaciones fallidas.
4.2 Del proceso de deployment
Si bien cada desarrollo puede requerir programación en paralelo para abarcar la totalidad
de las funciones solicitadas en el requerimiento, los proyectos pueden tratarse como
líneas de desarrollo independientes las cuales inclusive, pueden tener instalaciones en
distintas etapas, con diferentes requerimientos y con diferentes niveles de testing.
Si, es recomendable, que primero se incorporen las funciones transversales al proyecto
para que al momento de culminar la especificación puntual pueda testearse el desarrollo
en su totalidad.
Las modificaciones a las herramientas CORE son independientes a los módulos a desarrollar
aunque puede resolverse en el mismo proyecto incorporarse funcionalidades nuevas para
mejorar las capacidades de todo el sitio, es por ello que se puede adelantar el proceso de
instalación para testear su funcionamiento con los módulos existentes.
El testing de desarrollos CORE posee niveles más estrictos ya que afectan a todos los
subproyectos.
Los desarrollos sobre proyectos deberían tener test de integración, aunque si las
funcionalidades son genéricas y afectan otros desarrollos puede adelantarse su testing e
instalación en producción.
4.3 Del control de versiones
Los ensamblados se versionarán, se llevará un registro de las funciones incorporadas en
cada versión, los bugs detectados y el estado de los mismos.
Se planificará la incorporación de funcionalidades necesarias para los ensamblados CORE
en versiones posteriores.
La incorporación de nuevas funcionalidades sobre estos ensamblados permitirá un
desarrollo progresivo del sitio.
En caso de que se cuente con software de apoyo a estas metodologías de trabajo se
incorporarán caso contrario se llevarán registros con otros software existente y
disponibles.
4.4 De las estrategias de migración
<<pendiente>>
23
© 2008 Telmex S.A.
Arquitectura de Aplicaciones Web ASP.NET/MVP

Más contenido relacionado

La actualidad más candente

Trabajar con bases de datos desde ASP.NET
Trabajar con bases de datos desde ASP.NETTrabajar con bases de datos desde ASP.NET
Trabajar con bases de datos desde ASP.NETJavier Roig
 
5. Curso Java Struts I (Framework para Java) - Curso 2005-2006
5. Curso Java Struts I (Framework para Java) - Curso 2005-20065. Curso Java Struts I (Framework para Java) - Curso 2005-2006
5. Curso Java Struts I (Framework para Java) - Curso 2005-2006Samuel Marrero
 
Bd T1 Eq7 Caracteristicas Sql Server 2008 Todos
Bd T1 Eq7 Caracteristicas Sql Server 2008 TodosBd T1 Eq7 Caracteristicas Sql Server 2008 Todos
Bd T1 Eq7 Caracteristicas Sql Server 2008 TodosArmando
 
Buenas prácticas de codificación para capas de acceso a datos de aplicaciones...
Buenas prácticas de codificación para capas de acceso a datos de aplicaciones...Buenas prácticas de codificación para capas de acceso a datos de aplicaciones...
Buenas prácticas de codificación para capas de acceso a datos de aplicaciones...SolidQ
 
Aplicaciones en capas1
Aplicaciones en capas1Aplicaciones en capas1
Aplicaciones en capas1mariana
 
UDA-Guia de desarrollo
UDA-Guia de desarrolloUDA-Guia de desarrollo
UDA-Guia de desarrolloAnder Martinez
 
Programacion de aplicaciones Web con ASP.NET
Programacion de aplicaciones Web con ASP.NETProgramacion de aplicaciones Web con ASP.NET
Programacion de aplicaciones Web con ASP.NETJavier Roig
 
Intro a ASP.NET
Intro a ASP.NETIntro a ASP.NET
Intro a ASP.NETwilliamsm
 
Ingenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de softwareIngenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de softwareJosé Antonio Sandoval Acosta
 
5to ciclo desarrollo de aplicaciones web i
5to ciclo   desarrollo de aplicaciones web i5to ciclo   desarrollo de aplicaciones web i
5to ciclo desarrollo de aplicaciones web iJulio Pari
 
Asp.net conceptos
Asp.net conceptosAsp.net conceptos
Asp.net conceptosXstremsX
 
Manual 2014 i 04 lenguaje de programación ii (0870)
Manual 2014 i 04 lenguaje de programación ii (0870)Manual 2014 i 04 lenguaje de programación ii (0870)
Manual 2014 i 04 lenguaje de programación ii (0870)Robert Rayco Quiroz
 
Diapositivas Web Util
Diapositivas Web UtilDiapositivas Web Util
Diapositivas Web Utilsudamericano
 

La actualidad más candente (20)

Trabajar con bases de datos desde ASP.NET
Trabajar con bases de datos desde ASP.NETTrabajar con bases de datos desde ASP.NET
Trabajar con bases de datos desde ASP.NET
 
5. Curso Java Struts I (Framework para Java) - Curso 2005-2006
5. Curso Java Struts I (Framework para Java) - Curso 2005-20065. Curso Java Struts I (Framework para Java) - Curso 2005-2006
5. Curso Java Struts I (Framework para Java) - Curso 2005-2006
 
Bd T1 Eq7 Caracteristicas Sql Server 2008 Todos
Bd T1 Eq7 Caracteristicas Sql Server 2008 TodosBd T1 Eq7 Caracteristicas Sql Server 2008 Todos
Bd T1 Eq7 Caracteristicas Sql Server 2008 Todos
 
Buenas prácticas de codificación para capas de acceso a datos de aplicaciones...
Buenas prácticas de codificación para capas de acceso a datos de aplicaciones...Buenas prácticas de codificación para capas de acceso a datos de aplicaciones...
Buenas prácticas de codificación para capas de acceso a datos de aplicaciones...
 
Aplicaciones en capas1
Aplicaciones en capas1Aplicaciones en capas1
Aplicaciones en capas1
 
Manual Basico De Struts
Manual Basico De StrutsManual Basico De Struts
Manual Basico De Struts
 
Asp.net
Asp.netAsp.net
Asp.net
 
UDA-Guia de desarrollo
UDA-Guia de desarrolloUDA-Guia de desarrollo
UDA-Guia de desarrollo
 
Programacion de aplicaciones Web con ASP.NET
Programacion de aplicaciones Web con ASP.NETProgramacion de aplicaciones Web con ASP.NET
Programacion de aplicaciones Web con ASP.NET
 
MVC
MVCMVC
MVC
 
Dce2 ejercicios asp.net
Dce2 ejercicios asp.netDce2 ejercicios asp.net
Dce2 ejercicios asp.net
 
DocOpenERP - Open erp tutorial_basico
DocOpenERP - Open erp tutorial_basicoDocOpenERP - Open erp tutorial_basico
DocOpenERP - Open erp tutorial_basico
 
Intro a ASP.NET
Intro a ASP.NETIntro a ASP.NET
Intro a ASP.NET
 
Ingenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de softwareIngenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de software
 
5-Unidad 2: Diseño de Vista-2.2 Para Web
5-Unidad 2: Diseño de Vista-2.2 Para Web5-Unidad 2: Diseño de Vista-2.2 Para Web
5-Unidad 2: Diseño de Vista-2.2 Para Web
 
5to ciclo desarrollo de aplicaciones web i
5to ciclo   desarrollo de aplicaciones web i5to ciclo   desarrollo de aplicaciones web i
5to ciclo desarrollo de aplicaciones web i
 
Arquitectura proyecto fam
Arquitectura proyecto famArquitectura proyecto fam
Arquitectura proyecto fam
 
Asp.net conceptos
Asp.net conceptosAsp.net conceptos
Asp.net conceptos
 
Manual 2014 i 04 lenguaje de programación ii (0870)
Manual 2014 i 04 lenguaje de programación ii (0870)Manual 2014 i 04 lenguaje de programación ii (0870)
Manual 2014 i 04 lenguaje de programación ii (0870)
 
Diapositivas Web Util
Diapositivas Web UtilDiapositivas Web Util
Diapositivas Web Util
 

Similar a Arquitectura de Aplicaciones Web ASP.NET/MVP

UDA-Componentes RUP. Tabla.v2.4.6
UDA-Componentes RUP. Tabla.v2.4.6UDA-Componentes RUP. Tabla.v2.4.6
UDA-Componentes RUP. Tabla.v2.4.6Ander Martinez
 
Arquitectura aplicaciones .net
Arquitectura aplicaciones .netArquitectura aplicaciones .net
Arquitectura aplicaciones .netEdwin Benavente O.
 
Estructura organizacional
Estructura organizacionalEstructura organizacional
Estructura organizacionalyoltsi
 
Proyecto softpyme informe analisis
Proyecto softpyme informe analisisProyecto softpyme informe analisis
Proyecto softpyme informe analisisYeison Smith
 
Estrategia para la Implementación y Administración Inteligente de DataWarehouse
Estrategia para la Implementación y Administración Inteligente de DataWarehouseEstrategia para la Implementación y Administración Inteligente de DataWarehouse
Estrategia para la Implementación y Administración Inteligente de DataWarehouseSebastian Rodriguez Robotham
 
Aplicacion mvc entity_framework_login_membership
Aplicacion mvc entity_framework_login_membershipAplicacion mvc entity_framework_login_membership
Aplicacion mvc entity_framework_login_membershipJose B Flores P
 
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTAPROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTARoyer Tuesta Salas
 
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptx
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptxM.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptx
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptxHawkMartnez
 
Ingeniería de Sistemas - Trabajo colaborativo 2
Ingeniería de Sistemas - Trabajo colaborativo 2Ingeniería de Sistemas - Trabajo colaborativo 2
Ingeniería de Sistemas - Trabajo colaborativo 2Yenny Caterine
 
Modelo de prototipo
Modelo de prototipoModelo de prototipo
Modelo de prototipoyanezcabrera
 
Metodologia Estructurada - Análisis -
Metodologia Estructurada - Análisis -Metodologia Estructurada - Análisis -
Metodologia Estructurada - Análisis -Susana Daldin
 
Guide liferay themestraining_lr6.2_v1
Guide liferay themestraining_lr6.2_v1Guide liferay themestraining_lr6.2_v1
Guide liferay themestraining_lr6.2_v1Juan Gallardo Ortiz
 
Parcial2
Parcial2Parcial2
Parcial2fredmoa
 
Carreras vinculadas-programacion-informatica-consultoria-de-informatica
Carreras vinculadas-programacion-informatica-consultoria-de-informaticaCarreras vinculadas-programacion-informatica-consultoria-de-informatica
Carreras vinculadas-programacion-informatica-consultoria-de-informaticaEtsonCelisMartinez1
 

Similar a Arquitectura de Aplicaciones Web ASP.NET/MVP (20)

UDA-Componentes RUP. Tabla.v2.4.6
UDA-Componentes RUP. Tabla.v2.4.6UDA-Componentes RUP. Tabla.v2.4.6
UDA-Componentes RUP. Tabla.v2.4.6
 
Arquitectura aplicaciones .net
Arquitectura aplicaciones .netArquitectura aplicaciones .net
Arquitectura aplicaciones .net
 
Estructura organizacional
Estructura organizacionalEstructura organizacional
Estructura organizacional
 
Proyecto softpyme informe analisis
Proyecto softpyme informe analisisProyecto softpyme informe analisis
Proyecto softpyme informe analisis
 
Estrategia para la Implementación y Administración Inteligente de DataWarehouse
Estrategia para la Implementación y Administración Inteligente de DataWarehouseEstrategia para la Implementación y Administración Inteligente de DataWarehouse
Estrategia para la Implementación y Administración Inteligente de DataWarehouse
 
Aplicacion mvc entity_framework_login_membership
Aplicacion mvc entity_framework_login_membershipAplicacion mvc entity_framework_login_membership
Aplicacion mvc entity_framework_login_membership
 
Tema 3
Tema 3Tema 3
Tema 3
 
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTAPROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
PROYECTO DE TESIS SISTEMA INTEGRAL DE COMPRA Y VENTA
 
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptx
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptxM.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptx
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptx
 
Ingeniería de Sistemas - Trabajo colaborativo 2
Ingeniería de Sistemas - Trabajo colaborativo 2Ingeniería de Sistemas - Trabajo colaborativo 2
Ingeniería de Sistemas - Trabajo colaborativo 2
 
DAS+Plantilla
DAS+PlantillaDAS+Plantilla
DAS+Plantilla
 
Modelo de prototipo
Modelo de prototipoModelo de prototipo
Modelo de prototipo
 
Informe practicas
Informe practicasInforme practicas
Informe practicas
 
GraphQL Reactivo
GraphQL ReactivoGraphQL Reactivo
GraphQL Reactivo
 
Metodologia Estructurada - Análisis -
Metodologia Estructurada - Análisis -Metodologia Estructurada - Análisis -
Metodologia Estructurada - Análisis -
 
Guide liferay themestraining_lr6.2_v1
Guide liferay themestraining_lr6.2_v1Guide liferay themestraining_lr6.2_v1
Guide liferay themestraining_lr6.2_v1
 
Parcial2
Parcial2Parcial2
Parcial2
 
Carreras vinculadas-programacion-informatica-consultoria-de-informatica
Carreras vinculadas-programacion-informatica-consultoria-de-informaticaCarreras vinculadas-programacion-informatica-consultoria-de-informatica
Carreras vinculadas-programacion-informatica-consultoria-de-informatica
 
documento arquitectura
documento arquitecturadocumento arquitectura
documento arquitectura
 
Scrum en el proyecto
Scrum en el proyectoScrum en el proyecto
Scrum en el proyecto
 

Último

experiencia de aprendizaje sobre lectura y escritura como herramientas de ap...
experiencia de aprendizaje sobre lectura y escritura como  herramientas de ap...experiencia de aprendizaje sobre lectura y escritura como  herramientas de ap...
experiencia de aprendizaje sobre lectura y escritura como herramientas de ap...cuentauniversidad34
 
Los desafíos de calidad de software que nos trae la IA y los LLMs
Los desafíos de calidad de software que nos trae la IA y los LLMsLos desafíos de calidad de software que nos trae la IA y los LLMs
Los desafíos de calidad de software que nos trae la IA y los LLMsFederico Toledo
 
trabajo integrador final sofi y vane.docx
trabajo integrador final sofi y vane.docxtrabajo integrador final sofi y vane.docx
trabajo integrador final sofi y vane.docxlasocharfuelan123
 
Maquina de Dibujo y Escritura Automática.pdf
Maquina de Dibujo y Escritura Automática.pdfMaquina de Dibujo y Escritura Automática.pdf
Maquina de Dibujo y Escritura Automática.pdfjuanjosebarreiro704
 
FICHA DE TRABAJO DE CREACION DE TABLAS EN WORD
FICHA  DE TRABAJO DE CREACION DE TABLAS EN WORDFICHA  DE TRABAJO DE CREACION DE TABLAS EN WORD
FICHA DE TRABAJO DE CREACION DE TABLAS EN WORDRobertSotilLujn
 
Virus informático (tipos y opciones para prevenir)
Virus informático (tipos y opciones para prevenir)Virus informático (tipos y opciones para prevenir)
Virus informático (tipos y opciones para prevenir)edisonquispecalderon
 
MODULO BASICO DE WORD - I CICLO.DOC.DOC.
MODULO BASICO DE WORD - I CICLO.DOC.DOC.MODULO BASICO DE WORD - I CICLO.DOC.DOC.
MODULO BASICO DE WORD - I CICLO.DOC.DOC.CarmenFlores88207
 
LA CALIDAD DE LA INFORMACION EN LA NUEVA ERA DEL INTERNET
LA CALIDAD DE LA INFORMACION  EN LA NUEVA ERA DEL INTERNETLA CALIDAD DE LA INFORMACION  EN LA NUEVA ERA DEL INTERNET
LA CALIDAD DE LA INFORMACION EN LA NUEVA ERA DEL INTERNETCasa
 

Último (8)

experiencia de aprendizaje sobre lectura y escritura como herramientas de ap...
experiencia de aprendizaje sobre lectura y escritura como  herramientas de ap...experiencia de aprendizaje sobre lectura y escritura como  herramientas de ap...
experiencia de aprendizaje sobre lectura y escritura como herramientas de ap...
 
Los desafíos de calidad de software que nos trae la IA y los LLMs
Los desafíos de calidad de software que nos trae la IA y los LLMsLos desafíos de calidad de software que nos trae la IA y los LLMs
Los desafíos de calidad de software que nos trae la IA y los LLMs
 
trabajo integrador final sofi y vane.docx
trabajo integrador final sofi y vane.docxtrabajo integrador final sofi y vane.docx
trabajo integrador final sofi y vane.docx
 
Maquina de Dibujo y Escritura Automática.pdf
Maquina de Dibujo y Escritura Automática.pdfMaquina de Dibujo y Escritura Automática.pdf
Maquina de Dibujo y Escritura Automática.pdf
 
FICHA DE TRABAJO DE CREACION DE TABLAS EN WORD
FICHA  DE TRABAJO DE CREACION DE TABLAS EN WORDFICHA  DE TRABAJO DE CREACION DE TABLAS EN WORD
FICHA DE TRABAJO DE CREACION DE TABLAS EN WORD
 
Virus informático (tipos y opciones para prevenir)
Virus informático (tipos y opciones para prevenir)Virus informático (tipos y opciones para prevenir)
Virus informático (tipos y opciones para prevenir)
 
MODULO BASICO DE WORD - I CICLO.DOC.DOC.
MODULO BASICO DE WORD - I CICLO.DOC.DOC.MODULO BASICO DE WORD - I CICLO.DOC.DOC.
MODULO BASICO DE WORD - I CICLO.DOC.DOC.
 
LA CALIDAD DE LA INFORMACION EN LA NUEVA ERA DEL INTERNET
LA CALIDAD DE LA INFORMACION  EN LA NUEVA ERA DEL INTERNETLA CALIDAD DE LA INFORMACION  EN LA NUEVA ERA DEL INTERNET
LA CALIDAD DE LA INFORMACION EN LA NUEVA ERA DEL INTERNET
 

Arquitectura de Aplicaciones Web ASP.NET/MVP

  • 1. © 2008 Telmex S.A. Arquitectura de Aplicaciones Gerencia de Analisis y Desarrollo de Sistemas
  • 2.
  • 3. All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the written permission of the publisher. Products that are referred to in this document may be either trademarks and/or registered trademarks of the respective owners. The publisher and the author make no claim to these trademarks. While every precaution has been taken in the preparation of this document, the publisher and the author assume no responsibility for errors or omissions, or for damages resulting from the use of information contained in this document or from the use of programs and source code that may accompany it. In no event shall the publisher and the author be liable for any loss of profit or any other commercial damage caused or alleged to have been caused directly or indirectly by this document. Printed: Octubre 2008 in (whereever you are located) Arquitectura de Aplicaciones © 2008 Telmex S.A.
  • 4. Arquitectura de Aplicaciones4 © 2008 Telmex S.A. Lista de contenidos Foreword 6 Apéndice A - Objetivos 8 ................................................................................................................................... 81 Contexto ................................................................................................................................... 82 Del presente documento ................................................................................................................................... 83 Del código fuente ................................................................................................................................... 84 De la arquitectura ................................................................................................................................... 85 Historia de Revisiones Apéndice B - Arquitectura interna 11 ................................................................................................................................... 111 Orientación a Objetos ................................................................................................................................... 112 Lógica distribuida en capas ..........................................................................................................................................................12Capa de Persistencia ..........................................................................................................................................................13Capa de Acceso a datos ..........................................................................................................................................................13Capa Tipos Comunes ..........................................................................................................................................................14Capa de Servicios ..........................................................................................................................................................14Capa Presenter de interfaz ..........................................................................................................................................................14Capa de interfaz de usuario ................................................................................................................................... 143 Del mantenimiento de la vista ................................................................................................................................... 144 Patron MVP ................................................................................................................................... 155 Mínimo acoplamiento ................................................................................................................................... 156 Abstraccion del modelo de persistencia ................................................................................................................................... 167 Simplicidad del código Apéndice C - Arquitectura externa 18 ................................................................................................................................... 181 De la división estructural de las aplicaciones ..........................................................................................................................................................18Vantive ..........................................................................................................................................................18Desarrollos adicionales al estándar ..........................................................................................................................................................18Herramientas CORE ..........................................................................................................................................................19Grafica de división ................................................................................................................................... 192 De los componentes estándar ................................................................................................................................... 193 De los requerimientos técnicos ................................................................................................................................... 204 De los puntos críticos a considerar Apéndice D - De la metodología de instalación 22 ................................................................................................................................... 221 De la escalabilidad y estabilidad en la instalación ................................................................................................................................... 222 Del proceso de deployment ................................................................................................................................... 223 Del control de versiones ................................................................................................................................... 224 De las estrategias de migración
  • 8. Arquitectura de Aplicaciones8 © 2008 Telmex S.A. 1 Objetivos 1.1 Contexto El área de sistemas de TELMEX se dispone a ofrecer servicios de desarrollos a la misma empresa productos para facilitar diversos procesos, bajo los siguientes objetivos · Rápida velocidad de respuesta en la solución · Aprovechar el acceso y la existencia de información transversal de VANTIVE para agilizar diversos procesos, y ofreciendo soluciones especificas. · Generar un ahorro en los presupuestos de migración reutilizando módulos desarrollados o a desarrollarse. · Alineación con normas de desarrollo de TELMEX. 1.2 Del presente documento Documentar la arquitectura general de toda aplicación .NET para los presentes y futuros desarrollos. Identificar los posibles puntos débiles a mejorar en próximas etapas de desarrollo. Documentar las estrategias de migración progresiva y convivencia con las actuales aplicaciones ASP/PHP. 1.3 Del código fuente Buen nivel de reutilización, código simple y de fácil mantenimiento. Clara identificación del negocio que desea resolver. Desarrollo progresivo. Patrones de desarrollo y applications blocks. Abstracción completa de la persistencia. Asi mismo, se generó un documento de buenas practicas para inducir al desarrollador a mejorar sus habitos. 1.4 De la arquitectura Escalable, estructura de aplicaciones empresariales, con capacidad para implementación en diferentes ambientes con ciclos de desarrollo de diferentes tiempos. Uso de componentes de arquitectura SOA controlado. Puntos críticos identificables. Uso de componentes homologados. Flexibilidad para implementación en diferentes infraestructuras. Optimización y control del uso de memoria y ancho de banda, capacidad para soportar gran nivel de concurrencia. 1.5 Historia de Revisiones Fecha Versión Descripción Autor
  • 9. Objetivos © 2008 Telmex S.A. 9 13/10/2008 1.0 Creación del Documento José Franco
  • 11. Arquitectura interna © 2008 Telmex S.A. 11 2 Arquitectura interna 2.1 Orientación a Objetos En el código resultante se aplicarán los principios de la POO haciendo especial énfasis en los siguientes ítems: · Abstracción completa del modelo de persistencia: Esto se logra con objetos en la capa de negocios que provean métodos para recuperar los datos y modificarlos. · Objetos de bajo de acoplamiento 2.2 Lógica distribuida en capas Se identifican las siguientes capas con sus límites claramente definidos La ubicación de lógica aplicada en la capa incorrecta esta prohibida.
  • 12. Arquitectura de Aplicaciones12 © 2008 Telmex S.A. La interoperabilidad con los Servicios Web, se muestra a continuación. 2.2.1 Capa de Persistencia Se refiere a la base de datos, bajo las siguientes premisas: · Acceso a los datos sólo por SP. · No puede existir lógica del negocio en el Store Procedure, la complejidad sólo será admitida para optimizar el resultado de la consulta.
  • 13. Arquitectura interna © 2008 Telmex S.A. 13 · Se priorizará restringir los paquetes a un set de 4 métodos. · GetList: selección de todos los campos, descripciones de claves foraneas incluidas, ordenamiento por parámetro de los campos, busqueda por like en campos de texto, paginación de resultado. En el Anexo I, template de selección. · GetByPk: selección por clave primaria. · Insert. · Delete. · Update: Con control de concurrencia. · No utilización de SQL dinámico: a fin de permitir el uso de un plan de ejecución. · Funciones: Restringidas a auxiliar consultas de selección para optimizar resultado, no se admite otra lógica aplicada. · Triggers: No, restringidas a los estandares de VANTIVE. · Seguridad: Autenticación de usuario único con acceso al esquema particular del negocio, acceso a los datos a través de vistas, seguridad de acceso a los datos controlada por la aplicación. · Paginación: No pueden existir Store Procedures de busqueda de datos sin limitar el resultado y ofrecerlo por páginas. · Tracking: Para lógica compleja necesaria para interactuar con VANTIVE, se usará un SP para abrirse de la arquitectura de las aplicaciones. 2.2.2 Capa de Acceso a datos Provee el acceso a los datos, dividida en tres secciones, esta capa no puede contener ninguna referencia de lógica de negocio. · Componente de Acceso a Datos: DataAccess homologado por TELMEX y otros componentes de acceso a datos (VANTIVE, SAP, driver nativos). · Interfase de comunicación con los componentes: Basada sus métodos en MS DataAccess Application Block, principalmente hace de un wrapper con los diferentes componetes de acceso a datos · Clases de comunicación con el componente: Implica la declaración de los parámetros, en una forma independiente al componente de acceso a datos, a esta llegan tipos de datos abstractos propios del lenguaje (Dataset, tipos nativos) 2.2.3 Capa Tipos Comunes Capa de tipo colaboradora, se hace hincapié en que la comunicación entre capa debe efectuarse con tipos de datos abstractos. Esta capa posee acoplamiento con el negocio de la aplicación, su existencia y separación es para simplificar la estructura del código. Entre las características de la misma encontramos · Tipos abstractos de datos: Sin lógica de negocio asociada, generalmente derivaciones de tipos provistos del framework con mayores funcionalidades o clases contenedoras de datos asociados a circuitos de negocio para comunicarse entre capas.
  • 14. Arquitectura de Aplicaciones14 © 2008 Telmex S.A. 2.2.4 Capa de Servicios Contiene un proveedor de servicio, pudiendo acceder a cada servicio de cada entidad existente en nuestro proyecto. · Objetos de lógica: Clases instanciables que permiten resolver problemáticas concretas del negocio, por lo general tendrán una correspondencia con lo requerido por el objeto visual. Concentra la totalidad de la funcionalidad del negocio (validaciones, campos calculados, etc). Los objetos de negocio son serializables para poder ser persistidos en caso de que sea necesario. 2.2.5 Capa Presenter de interfaz Por aplicación del patrón MVP, se encargará de transformar la información entre la capa de servicio y la interfaz de usuario, dominará la traducción de los contenidos, la transformación de datos para proveerla a la interfaz. Actúa como controlador de interfaz de usuario, de fuerte acoplamiento con las páginas a las que asiste. Cada página obligatoriamente contendrá una interfaz. La pagina hablara exclusivamente con su controlador, salvo que la funcionalidad requerida no implique presentación o envio de datos. 2.2.6 Capa de interfaz de usuario Compuestas por los paginas aspx que conformarán el sitio web, el código del codebehind se restringirá al consumo de las funcionalidades y los datos provistos por la capa controladora El flujo de ejecución de la aplicación es dominado por la interfaz pero regla de negocios tendrá la decisión final acerca de si se provee funcionalidades y datos para la funcionalidad solicitada. El control del flujo será monitoreado desde funciones core invocadas desde el global.asax antes de resolverse cada petición de datos. En ella se llevará registro de la navegación del usuario. 2.3 Del mantenimiento de la vista El presenter será instanciado en cada petición, no siendo guardado ni serializado en ningún componente, para guardar estados. 2.4 Patron MVP La implementación de este patrón se debe principalmente a los siguientes aspectos: · Reducir al mínimo el código alojado en el aspx y restringirlo simplemente a código de presentación y de configuración de los componentes visuales. · Prever modificaciones en la visualización que tengan mínimo impacto en el resto del código. · Evitar toda lógica no propia de la vista en los aspx para poder efectuar soluciones con capas de presentación en otras tecnologías (flash, winform)
  • 15. Arquitectura interna © 2008 Telmex S.A. 15 MVP Pattern: 2.5 Mínimo acoplamiento Dentro del código que se va desarrollando se obtienen un conjunto de clases de alta reutilización asociadas al manejo de datos tales como buscadores y objetos de alta, baja, modificación y consulta de datos, los cuales se corresponden con una o varias entidades existentes en el modelo de datos. Estas clases desarrolladas en forma independiente a la especificación puntual de negocio son utilizadas en varios subproyectos del sitio, razón por la cual, son alojadas en un ensamblado diferente al de cada aplicación. 2.6 Abstraccion del modelo de persistencia El objetivo de esta implementación es independizarse del medio de almacenamiento. Se logra accediendo a las entidades del modelo de datos a través de las clases representativas en regla de negocio. Cada entidad podría estar almacenada en diferentes modelos de persistencia (SAP, Oracle, SQL Server, PeopleNet (m4objects), VANTIVE ). Al obligar acceder exclusivamente a través de las clases de servicio para recuperar los datos, nos independizamos completamente del medio y hasta podríamos controlar procesos transaccionales entre diferentes plataformas. Ademas de la inclusión de conceptos de AOP. Como IoC, y Service Factory.
  • 16. Arquitectura de Aplicaciones16 © 2008 Telmex S.A. 2.7 Simplicidad del código Se logra a través de la utilización de clases instanciables. Se evita la utilización de métodos estáticos con una gran cantidad de parámetros para lograr establecer el contexto antes de resolver el negocio. Al utilizarse variables de instancia, los métodos se simplifican, el objeto tiene mayor control del negocio y se logran encapsular muchas funcionalidades La desventaja de esta implementación es el uso que hacen estos objetos de la memoria, es por ello que se aplican reglas en todas las capas para evitar saturaciones de la misma. Asimismo, con el fin de lograr mayor simplicidad, existen normas específicas de nomenclatura, longitud de los métodos, nombre de métodos, templates de clases, etc.
  • 18. Arquitectura de Aplicaciones18 © 2008 Telmex S.A. 3 Arquitectura externa De la división estructural de las aplicaciones Se detecta tres bloques principales de funcionalidades los cuales tienen ciclos de desarrollo diferentes, medios de persistencia separados, y que pueden ser afectados por migraciones en momentos distintos. 3.1 De la división estructural de las aplicaciones 3.1.1 Vantive <<pendiente>> 3.1.2 Desarrollos adicionales al estándar Contempla todos aquellos desarrollos que no estén dentro del estándar del sistema de gestión de TELMEX. 3.1.3 Herramientas CORE Se refiere al conjunto de clases que proveen funcionalidades para la ejecución del sitio, resuelve los aspectos de seguridad (autorización y autenticación), navegación (control del flujo de ejecución), espacios de memoria compartida (objeto SessionManager), regionalización (traducción de contenidos y presentación), etc. Estas herramientas requieren acceder a un repositorio de datos especial donde guardar información de configuración el cual es completamente independiente de los anteriormente descriptos. Asimismo, dentro de las herramientas CORE, encontraremos los módulos (controles y páginas) que dominan el flujo de ejecución de las subaplicaciones de TELMEX y proveen funcionalidades para comunicarse entre ellos. El ciclo de desarrollo de las herramientas CORE es mas lento, con ciclos de versiones amplios, de gran estabilidad. Estos módulos (ensamblados) deben poder ser accedidos desde cualquier subaplicacion, razón por la cual deben estar instalados en la GAC del servidor de web.
  • 19. Arquitectura externa © 2008 Telmex S.A. 19 3.1.4 Grafica de división <<pendiente>> La grafica divide los servidores como repositorios de datos distintos, no necesariamente representan una arquitectura física de esta distribución, aunque al menos si marca diferentes esquemas de base de datos para cada uno de los grupos. En el caso de los desarrollos especiales, estos a su vez pueden dividirse en múltiples esquemas que encierren las entidades particulares de cada negocio. 3.2 De los componentes estándar No se tiene previsto utilizar componentes de terceras partes, en caso de que así sea se evaluará conveniencia y se elevará a consideración de responsables de Tecnología. Se procura utilizar la paleta de componentes estandar incluida en el framework .Net 2.0.50727. 3.3 De los requerimientos técnicos Conforme a los puntos anteriormente detallado se desprenden los siguientes requerimientos técnicos · Servidor IIS con las siguientes caracteristicas: · Framework .NET v2.0.50727 · .NET Framework 2.0 Software Development Kit (SDK) Ambientes de Desarrollo, Test, Pre-Producción y Producción para cada paquete.
  • 20. Arquitectura de Aplicaciones20 © 2008 Telmex S.A. 3.4 De los puntos críticos a considerar <<pendiente>>
  • 22. Arquitectura de Aplicaciones22 © 2008 Telmex S.A. 4 De la metodología de instalación 4.1 De la escalabilidad y estabilidad en la instalación La separación indicada en 4.1 garantiza líneas de desarrollo separadas con ciclos de estabilización diferentes. La estructuración de subproyectos bajo el esquema ejemplificado en 4.1.5.1 garantiza procesos de instalación independientes y permitirían usar las funcionalidades de rollback en instalaciones fallidas. 4.2 Del proceso de deployment Si bien cada desarrollo puede requerir programación en paralelo para abarcar la totalidad de las funciones solicitadas en el requerimiento, los proyectos pueden tratarse como líneas de desarrollo independientes las cuales inclusive, pueden tener instalaciones en distintas etapas, con diferentes requerimientos y con diferentes niveles de testing. Si, es recomendable, que primero se incorporen las funciones transversales al proyecto para que al momento de culminar la especificación puntual pueda testearse el desarrollo en su totalidad. Las modificaciones a las herramientas CORE son independientes a los módulos a desarrollar aunque puede resolverse en el mismo proyecto incorporarse funcionalidades nuevas para mejorar las capacidades de todo el sitio, es por ello que se puede adelantar el proceso de instalación para testear su funcionamiento con los módulos existentes. El testing de desarrollos CORE posee niveles más estrictos ya que afectan a todos los subproyectos. Los desarrollos sobre proyectos deberían tener test de integración, aunque si las funcionalidades son genéricas y afectan otros desarrollos puede adelantarse su testing e instalación en producción. 4.3 Del control de versiones Los ensamblados se versionarán, se llevará un registro de las funciones incorporadas en cada versión, los bugs detectados y el estado de los mismos. Se planificará la incorporación de funcionalidades necesarias para los ensamblados CORE en versiones posteriores. La incorporación de nuevas funcionalidades sobre estos ensamblados permitirá un desarrollo progresivo del sitio. En caso de que se cuente con software de apoyo a estas metodologías de trabajo se incorporarán caso contrario se llevarán registros con otros software existente y disponibles. 4.4 De las estrategias de migración <<pendiente>>