WebSA (Web Software Architecture)

Tamaño: px
Comenzar la demostración a partir de la página:

Download "WebSA (Web Software Architecture)"

Transcripción

1 WebSA (Web Software Architecture) En los últimos años, dentro del desarrollo de aplicaciones web han surgido una gran variedad de metodologías basadas en UML que abordan con éxito la especificación de la navegación y presentación que dicho tipo de aplicaciones exige. Sin embargo, obligados por un mercado cada vez más competitivo que exige una continua evolución de las aplicaciones hipermedia y el aumento en la complejidad que implica su desarrollo, se hace necesario recoger requisitos de calidad que van a darnos la posibilidad de abordar con éxito su desarrollo y posterior mantenimiento. Siguiendo una aproximación DSSA (Domain-Specific Software Architecture) para abordar la especificación de la arquitectura software de una aplicación Web, vamos definir un conjunto de modelos basándonos en el estándar MDA (Model-Driven Architecture) que nos van a proporcionar diferentes vistas y niveles de abstracción, para definir un proceso de refinamiento que va a permitirnos especificar casi por completo el código de una aplicación web requiere. 1. Introducción Actualmente en un mercado tan competitivo como es internet, nos encontramos con la necesidad de desarrollar las aplicaciones web cada vez más complejas y en el menor tiempo posible. Además dichas aplicaciones deben cumplir con una serie de requisitos de calidad como son el rendimiento, la usabilidad, la escalabilidad, el mantenimiento, etc. para poder satisfacer a unos usuarios muy exigentes. Esto conduce a que su desarrollo capture dichos requisitos y los incorpore en el resto de las fases del ciclo de vida. En los últimos años, dentro de la ingeniería del software ha nacido un nuevo paradigma como es el Web Engineering, en el cual se han definido una colección de metodologías cada una de las cuales especifica con mayor o menor acierto la problemática que un desarrollo web exige. Sin embargo, salvo excepciones como [Conallen99], [Hassan02] las metodologías se preocupan en capturar los aspectos funcionales, navegacionales y de presentación de una aplicación, y olvidan los requisitos de calidad o no funcionales, que expresados mediante la arquitectura del software [Bass00] son capaces de completar las necesidades que dicha aplicación requiere. Como indica Grady Booch [Booch01] refiriéndose a las aplicaciones web: En mi experiencia, la presencia (o ausencia) de una buena arquitectura es un elemento esencial para predecir el éxito o fracaso de un proyecto. Por otro lado, existen una gran diversidad de aplicaciones web cada una de las cuales difiere tanto en número de clientes potenciales (desde pequeñas intranets a grandes aplicaciones en internet), como en los mecanismos de seguridad que se requieren (desde aplicación bancaria a una web de humor), los cambios a los que está sujeta en un futuro (un sitio web contra una aplicación de administración), etc. Por todo ello basándonos en la experiencia en el desarrollo de aplicaciones para web, hemos planteado una aproximación que capture a través de un conjunto de modelos UML y siguiendo una aproximación compatible MDA [OMG01], las diferentes vistas en las que se compondría una aplicación web. Nuestra propuesta se basa en la definición de una arquitectura software para web, utilizando una aproximación del tipo DSSA (Domain-Specific Software Architecture), que se basa en el estudio de un dominio para restringir el espacio del problema y de la solución. 1

2 En nuestro caso, centrados en el dominio específico de las aplicaciones web a nuestra aproximación le llamamos WebSA (Web Software Architecture). Para su definición, se sigue un proceso de desarrollo que implica realizar inicialmente un proceso de recogida de requisitos de usuario, en el cual obtendremos tanto requisitos funcionales como los no funcionales. Estos últimos expresados a partir de un conjunto de atributos de calidad claramente clasificados. A partir de dichos requisitos, se efectúa la definición de un conjunto de modelos expresados mediante UML y siguiendo el estándar MDA, cada uno de los cuales se encarga de recoger una vista diferente de la aplicación. Además, cada uno de los modelos se encuentran relacionados entre sí, ya sea mediante la trazabilidad de cada una de las vistas, o mediante los procesos de mapeo de los modelos que se encuentran en diferentes niveles de abstracción. Definimos por lo tanto un perfil UML a partir de la extensión conservadora del metamodelo UML, esto nos permitirá formalizar sus relaciones y poder recoger de la forma más completa una aplicación web. Para la implementación de las diferentes vistas, WebSA ha extendido la reconocida metodología OO-H [Cachero00] definida para el desarrollo de una aplicaciones hipermedia en las fases de análisis y diseño. Incorporándole por un lado la recogida de los requisitos no funcionales, a partir de los cuales se definirán nuevas vistas a la aplicación, que van a aportar la información sobre la arquitectura software y la vinculación de los aspectos funcionales y no funcionales. Dándonos así la definición completa y necesaria de una aplicación web, que nos va a permitir obtener un entorno de compilación de modelos traslativos[bell98] y generar el código para cualquier tipo de aplicación web. En los siguientes puntos vamos a especificar inicialmente una introducción a la aproximación WebSA en la que explicaremos en que se basa una arquitectura DSSA. Entraremos en la explicación de la diferentes vistas en las que dividimos una aplicación web, para posteriormente definir el metamodelo que va a formalizar nuestra aproximación. Seguidamente vamos justificar el uso de la arquitectura del software, para entrar a explicar cada una de las fases en las que se compone las vistas de arquitectura. Para la arquitectura lógica veremos las diferentes fases en las que se compone, descomposición en subsistemas, descomposición en componentes abstractos y la integración de componentes.. 2

3 2. Introducción a WebSA Para entender que es WebSA, primero vamos a definir que significan las dos últimas siglas, SA, es decir, la Arquitectura del Software que en ocasiones sigue siendo la gran desconocida dentro de la ingeniería del software, pero que en los últimos años está tomando una gran relevancia. Existen múltiples definiciones de arquitectura del software, pero de todas ellas vamos a quedarnos con dos definiciones que considero que más han influido en este trabajo. Definición de [Bass97]: La arquitectura del software de un programa o un sistema de computación es la estructura o estructuras del sistema, las cuales comprenden componentes software, las propiedades visibles de estos componentes y las relaciones entre ellos. De esta definición lo más importante es el hecho que define claramente cuales son los elementos que ha de recoger la arquitectura. Sin embargo, otra definición que aporta más contenido al mencionar las propiedades no funcionales es la de [BMR+96]: Es la descripción de los subsistemas y componentes de un sistema software y las relaciones entre ellos, típicamente representado mediante vistas que muestran las propiedades funcionales y no funcionales más relevantes. El intento de esta definición es indicar que la arquitectura del software debe abstraerse de alguna información del sistema (de otra manera no estaríamos apuntando a la arquitectura, estaríamos viendo todo el sistema) y aun así proveer suficiente información para ser la base para el análisis, toma de decisión, y por lo tanto reducción de riesgos. Definición de WebSA: WebSA es una metodología para la definición de arquitecturas software de las aplicaciones web, la cual se basa principalmente en 2 aspectos: 1. La definición de la arquitectura a través del paradigma DSSA (Domain Specific Software Architecture),es decir, de las arquitecturas software de dominio específico, que en su caso fija el dominio en el desarrollo de aplicaciones web. 2. Dicha metodología además se basa en la definición de arquitecturas mediante múltiples vistas concurrentes, para ello se vale de la utilización del estándar MDA, que nos permite definir un conjunto de modelos UML, dándole la formalidad necesaria con la utilización de estándares como MOF para la definición de los elementos de modelado, y de OCL, para la definición de restricciones. A continuación vamos a entrar en más detalle justificando el uso de dichos paradigmas. 3

4 2.1 Una aproximación DSSA Como indica el autor [Coglianese92], una arquitectura expresada mediante una aproximación DSSA se basa en la siguiente asunción: El desarrollo de sistemas en un dominio bien conocido es un proceso de emparejamiento de los requerimientos hacia aproximaciones conocidas para aportar soluciones en ese dominio. Como hemos comentado WebSA se especializa en un dominio de aplicación específico como son las aplicaciones web, que implica restringir tanto el espacio del problema como el espacio de la solución, lo que lleva en muchos casos a que el desarrollo de diferentes sistemas software sea bastante similar. Como menciona [Nilson94], el desarrollo de una arquitectura DSSA se basa en el estudio de las propiedades comunes y diferencias entre las aplicaciones de un dominio. A este proceso se lo denomina ingeniería de dominio. Las propiedades más importantes de una arquitectura DSSA [Hoffmann96] que deseamos cumplir con WebSA son: Trabajar en un espacio del problema y de la solución restringidos. Genericidad, para poder adaptar el DSSA a un desarrollo en concreto. Un nivel de abstracción adecuado para abarcar todo el dominio. Elementos de reuso dentro del proceso de desarrollo que son típicos de cada dominio. Como veremos seguidamente, cada uno de estos puntos van a ser perseguidos, además de pretender principalmente que WebSA defina correctamente el dominio de las aplicaciones web. Entre las propiedades anteriores destacamos principalmente el hecho de que trabajar en un espacio de solución restringido nos facilitará la tarea de identificar la funcionalidad de ciertos componentes que en otras ocasiones sería imposible, por otro lado, también consideramos importante que el nivel de abstracción adecuado nos va permitir recuperar elementos de reutilización. Siguiendo la definición de una arquitectura DSSA, nuestra aproximación parte inicialmente de una fase de recogida de requisitos en la que vamos a incorporar a los tradicionales requisitos funcionales recogidos mediante casos de uso, y de los requisitos no funcionales recogido a través de escenario de calidad. Ambos conjuntos de requisitos van a ser el punto de partida para el posterior análisis y diseño, donde como veremos aparece la especificación tanto de los aspectos funcionales como los aspectos meramente arquitectónicos. Dichos ámbitos van a estar especificados a través de diferentes vistas interrelacionadas mediante relaciones de dependencia definidas en un metamodelo UML común. A continuación vamos a mostrar la otra parte principal de nuestra aproximación que es el uso de MDA para la especificación de los diferentes modelos especificados dentro de nuestra aproximación. 4

5 2.2 Definición de arquitectura web mediante MDA Utilizando la definición de arquitectura que menciona [Conallen99]: Mirar la descripción de una arquitectura es como una versión condensada de todo el conjunto de artefactos de desarrollo. Nuestra aproximación se basa en la separación en diferentes vistas concurrentes de la representación del todo el sistema web, para ello nos vamos a valer del estándar definido en la OMG llamado MDA. MDA [OMG2001] define una aproximación para la especificación de sistemas cuyo principio es la separación de la funcionalidad del sistema de los aspectos dependientes de la plataforma destino. Esto lo realiza mediante una arquitectura de modelos que provee un conjunto de guías para estructurar las especificaciones expresadas como modelos. Como vemos en la definición de MDA, existen dos aspectos diferenciados, la separación con la plataforma destino, que en nuestro caso es importante, ya que la arquitectura la vamos a definir a un nivel de abstracción donde la plataforma no se especifica, y además nos va a facilitar el hecho de que proporcionan mapeos a plataformas como J2EE,.NET y CORBA. Y el siguiente aspecto y no menos importante es la aportación de una arquitectura de modelos, la cual está definida a partir de los conceptos de vista, refinamiento y abstracción que nos van a permitir definir un conjunto de modelos interrelacionados con diferentes vistas y en diferentes niveles de abstracción que nos permitirá realizar un seguimiento durante todo el ciclo de vida. Las principales ventajas que nos aporta la aproximación MDA son: Integración con sistemas legados. Utilización de estándares como UML, XMI, CWM que nos proporcionan la posibilidad de intercambiar nuestros modelos a cualquier herramienta que sea compatible UML. La formalización a través MOF y OCL de todos los modelos definidos a partir de UML. Reducción de costes durante todo el ciclo de vida de la aplicación. Rápida inclusión de los beneficios de las tecnologías emergentes en sus sistemas existentes. Existen trabajos previos que han abordado con éxito la especificación de la arquitectura de una aplicación tratando por separado las vistas que la constituyen, los más importantes son los de [Kruchten95] el cual define 4+1 vistas concurrentes para definir un sistema, y posteriormente [Hofmeister99] que separa en 4 vistas la arquitectura software. Sin embargo, ambas aproximaciones se basan únicamente en UML, y se definen para expresar cualquier tipo de arquitectura, mientras que en nuestra aproximación se hace uso de MDA y además está fijada en el dominio de las aplicaciones web lo que nos va a permitir llegar a un nivel de detalle mucho mayor. A continuación, vamos a definir el conjunto de vistas de WebSA. Entendiendo por vista, como un conjunto de artefactos creados en el proceso del desarrollo del software. Estas vistas se definen como una extensión de las vistas definidas en la metodología OO-H. OO-H define las vistas existentes en la parte funcional de la aplicación web, y 5

6 sobre dichas vistas vamos a incorporar aquellas que tratan los aspectos no funcionales, tanto en la parte de requisitos como en la arquitectura, además de establecer la trazabilidad entre cada una de las partes lo que nos va a permitir expresar aspectos que únicamente se pueden tratar cuando la parte funcional y no funcional están juntas. Además, cada una de las vistas las vamos a agrupar dentro de lo que se denomina punto de vista (viewpoint). Un punto de vista es una colección de vistas que comparten un conjunto de asuntos. Los puntos de vista las vistas que contienen son las vistas definidas son las siguientes: Punto de Vista de Requisitos: Realizado durante la fase de requisitos, en el los analistas recogen la información necesaria a partir de la cual vamos a especificar el sistema. 1. Vista Requisitos Funcionales: En dicha vista se expresan mediante los casos de uso que recogerían los requisitos funcionales. 2. Vista Requisitos No Funcionales: En esta vista se expresan mediante escenarios de calidad los requisitos no funcionales. Punto de Vista Funcional: A partir de los requisitos de usuario especificados en la fase anterior se definen un conjunto de vistas que van a recoger la funcionalidad de un sistema web. Dichas vistas están definidas en la metodología OO-H: 3. Vista Conceptual: Expresa la funcionalidad del sistema de información sobre el que se define la aplicación. 4. Vista de Presentación: se preocupa de indicar cual va ser el aspecto de la aplicación y la funcionalidad asociada a esta. 5. Vista de Navegación: expresa cada una de las interacciones que el usuario realiza para transcurrir a través de los diferentes escenarios de la aplicación. 6. Vista Procesos: expresa cuales son las actividades de los procesos y el flujo de los procesos, estableciendo que actividades deben procesarse en secuencia o en paralelo. Punto de Vista de Arquitectura: A partir de los requisitos funcionales y no funcionales se definen las vistas que tradicionalmente se han denominado de arquitectura, y son la principal aportación del este trabajo: 7. Vista de la Arquitectura Lógica: expresa cuáles son los componentes lógicos (subsistemas, módulos o componentes software) que participan en nuestra solución, y la relación entre ellos. 8. Vista de la Arquitectura Física: expresa cuáles son los componentes físicos que participan en nuestra solución, y la relación entre ellos (clientes, servidores, redes, BD, etc). Una vez hemos enumerado las vistas que constituyen una arquitectura WebSA, necesitamos indicar cuales son las relaciones que existen entre cada una de ellas. Esto lo vamos a formalizar mediante un metamodelo UML. Por metamodelo se definimos lo siguiente: 6

7 Metamodelo: Un metamodelo es una definición precisa de los elementos de modelado, sus relaciones y de reglas bien formadas necesarias para crear modelos semánticos. En nuestra aproximación, hemos utilizado UML para definir el metamodelo, esto nos va a permitir formalizar y relacionar cada unas de las vistas de la arquitectura WebSA, además de poder establecer una trazabilidad entre los diferentes elementos de las vistas. Requirements ViewPoint Functional Requirements View Non-Functional Requirements View Functional ViewPoint Architectural ViewPoint Conceptual View Presentation View Logic Architectural View Process View Navigational View Physical Architectural View Figura 1. Modelo de dependencia entre las vistas WebSA. Como se puede apreciar en la figura 1, el sistema se define inicialmente a través de un punto de vista de requisitos que contiene las vistas de requisitos funcionales y no funcionales, que recogen la información necesaria a partir de la cual se van a constituir tanto la vista funcional, representados por las cuatro vistas de OO-H, como las vistas no funcionales que serían recogidos por las vistas de Arquitectura lógica y física. Conviene remarcar que existen dependencias a la hora de elaborar cada una de las vistas del sistema, así por ejemplo en el punto de vista funcional se hace necesario establecer las vistas de proceso y conceptual, para poder tener luego la vista navegacional y a continuación la vista de presentación. Además, en el punto de vista arquitectónico, inicialmente definimos una vista de arquitectura lógica para posteriormente tener la correspondencia a nivel físico en la vista de arquitectura física. Por otro lado existe una interdependencia mutua entre las vistas de la parte funcional y las vistas de la parte de arquitectura, es decir, ambas partes están vinculadas por relaciones de dependencia, lo que nos va a permitir en muchas ocasiones tomar decisiones en la parte funcional en función de aspectos recogidos en la arquitectura, y viceversa. A continuación vamos a entrar a describir una de las vistas descritas de la arquitectura, la arquitectura lógica, que como veremos se compone a su vez de un conjunto de modelos cada uno de los cuales va a estar localizado en diferentes niveles de abstracción. En posteriores trabajos mostraremos el modelo de arquitectura física. 7

8 3. Arquitectura Lógica Como hemos indicado anteriormente, dicha arquitectura se encarga de expresar cuáles son los componentes lógicos (subsistemas, módulos o componentes software) que participan en nuestra solución y la relación entre ellos. Dicha arquitectura va a inferirse a partir de los requisitos funcionales y no funcionales definidos en fases anteriores. Para conseguir emparejar cada uno de los requisitos no funcionales recogido en la fase de requerimientos con el diseño arquitectónico especificado en las vistas de arquitectura, vamos a utilizar por un lado los patrones, definidos a diferentes niveles de abstracción, que nos va a dar indicar cuales son los requisitos que cumplen en cada uno de los casos, y por otro, cuales son las operaciones unitarias que se están realizando al aplicarse. Por otro lado, en el caso de los requisitos funcionales como veremos estos se van a intervenir a través de un mapeo con los componentes de la arquitectura, y fijado a través de las relaciones establecidas entre las diferentes vistas en el metamodelo de WebSA. Existen muchas técnicas y lenguajes para especificar la arquitectura lógica de un sistema. Nosotros utilizaremos una nomenclatura basada en UML siguiendo otras aproximaciones como [Hofmeister99, Kruchten95] que nos aporta una serie de ventajas como la posibilidad de formalizar la aproximación mediante un metamodelo estándar UML permitiéndonos la utilización de herramientas existentes, además utilizando otros estándares OMG que nos proporciona MDA, para poder hacer mapeos entre las diferentes vistas. Nuestra aproximación divide en 3 modelos cada uno correspondiendo a 3 fases dentro del diseño de la arquitectura lógica, cada una de estas fases va a estar situada en un nivel de abstracción distinto, que nos va a permitir recoger diferentes aspectos de la arquitectura, y poder captar todos los requisitos especificados por el usuario: 1. Modelo de Subsistemas: Denominado tradicionalmente como diseño estructural, define cuales son los subsistemas que van a constituir nuestra aplicación. 2. Modelo de Configuración de Componentes Web: Consiste en refinar cada uno de los subsistemas descomponiéndolos en cada uno de los componentes abstractos propios de una aplicación web, expresándose de forma independiente de dominio y de plataforma. 3. Modelo de Integración de Componentes Web: Consiste en definir cuales son los componentes y módulos concretos una vez está apareados con el dominio del problema. Como vemos cada uno de estos modelos tiene una dependencia de forma que el modelo de configuración de componentes guarda las restricciones establecidas por el modelo de subsistemas, y de la misma manera, el modelo de integración ha de mantener las relaciones establecidas con el modelo de configuración. En los siguientes puntos vamos a definir detalladamente cada uno de estos modelos. 8

9 3.1 Modelo de Subsistemas (M.S.) El modelo de subsistemas denominado tradicionalmente diseño estructural tiene que ver con el diseño de las macrocomponentes de nuestra aplicación. Esta fase localizada en el nivel de abstracción más alto en el diseño arquitectónico, consiste en definir claramente cuales van a ser los subsistemas que van a constituir nuestra aplicación. Cada uno de los subsistemas van a estar identificados con una capa lógica de la aplicación. Dicha separación por capas es un principio que nos va a ayudar a reducir la complejidad de los sistemas, basándose en el patrón layering approach [BMR+96]. La reducción de las dependencias entre los módulos y el tratamiento local de los cambios, la portabilidad y la reutilización son aspectos bien conocidos de una aproximación estratificada por capas. Tradicionalmente se ha definido un modelo de arquitectura de 3 capas para las aplicaciones cliente/servidor [BMR+96]. Sin embargo, cada una de estas capas podrían llegarse a refinar aun más, el modelo Seeheim-model [NoSc99] distingue 6 capas diferentes una aplicación, ver Figura 2. Modelo 3 Capas Modelo 6 Capas Interfaz de Usuario Presentación Control de Usuario Lógica de Negocio Control de procesos Objetos de Negocio Persistencia Acceso a Datos Física de Datos Figura 2. Refinamiento del modelo de capas. Cada una de estas divisiones las vamos a realizar basándonos en unos patrones de arquitectura situados en este nivel de abstracción llamados patrones de distribución definidos por [ReWo97]. A continuación definimos cual es la funcionalidad de cada una de las capas, cual es el patrón que se aplica para su división, y la explicación de cada una de las capas. Seguidamente entraremos a explicar cada patrón más detalladamente. Las capas son las siguientes: 9

10 Interfaz de Usuario: Capa encargada de dotar de la funcionalidad necesaria para la interacción entre el usuario y la aplicación, el patrón distribución que divide ambas capas se denomina presentación distribuida, y divide en el refinamiento en 2 subcapas: Presentación: Se encarga de una capa distribuida que se encarga de dotar únicamente la funcionalidad de aspecto, y recibir las peticiones del usuario que en algunos casos serán validadas. Control de Usuario: Capa que se encarga de recibir las peticiones del usuario, gestionando la navegación del interfaz de usuario, y redireccionando las peticiones a la lógica de negocio, la cual procesará la petición y devolverá un resultado al control de usuario. Lógica de Negocio: Esta es la parte del sistema que resuelve las reglas de negocio especificadas para el dominio del problema. Si aplicamos el patrón de distribución Núcleo de Aplicación distribuido podemos dividirla en dos subcapas: Procesamiento de Control: Esta parte del sistema se encarga de atender las peticiones que se reciben del cliente, convirtiéndolas en procesos que se realizará de forma transaccional o no, de forma síncrona o asíncrona. Objetos de Negocio: En dicho subsistema residen los elementos que contienen la representación de los objetos definidos en el dominio del problema Persistencia: Como su nombre indica, es la parte del sistema encargada del dotarle de persistencia al sistema de información. Dada la división marcada por la aplicación del patrón Base de Datos Remota, la funcionalidad se distribuye en 2 subcapas: Acceso a Datos: Este subsistema se encarga de contener aquellos elementos que permiten el acceso a los datos físicos desde la capa de lógica de negocio Capa Física de Datos: Este subsistema determina cuales van a ser las fuentes físicas de datos que va a contener nuestro sistema. Como hemos indicado a este nivel de abstracción vamos a recoger los patrones arquitectónicos de distribución definidos por [ReWo97], cada uno de los cuales va a dividir la arquitectura en diferentes subsistemas cliente y servidor. La decisión de adoptar un estilo de distribución particular va a estar dirigida por los requerimientos no funcionales. Cada uno de los patrones va a estar influenciado por un conjunto de fuerzas, cuya intensidad viene marcada por los requerimientos del sistema, e indicarán si finalmente aplicamos o no dicho patrón. A continuación pasamos a explicar los patrones de distribución identificados, y los motivos por los cuales se aplican: 1. Presentación Distribuida: Este patrón separar el sistema de la componente de presentación. Una parte de la componente de presentación es una unidad distribuida y es procesada separadamente de la otra parte de la presentación la cual puede ser empaquetada junto con otras capas de la aplicación. Este patrón nos permite una fácil implementación y clientes muy finos. Anteriormente eran los sistemas Host con sus terminales 3270 el ejemplo clásico. Pero hoy en día son los clientes ligeros web, html y flash los que mejores ejemplos de la aplicación de este patrón. 10

11 2. Interfaz de Usuario Remoto: En lugar de distribuir cierta parte de la funcionalidad de la presentación, en este caso todo el interfaz se convierte en una unidad de distribución y actúa como cliente del núcleo de la aplicación en la parte servidora. 3. Núcleo de la Aplicación Distribuido: Este patrón divide el núcleo de la aplicación en dos partes las cuales son procesadas de forma separada. Este patrón se convierte realmente interesante cuando las transacciones expanden los límites de los procesos (procesamiento de transacciones distribuidas). 4. Base de datos remota: La base de datos es el componente más grande de un sistema de información con requerimientos especiales en la ejecución de su entorno. A veces, algunas aplicaciones funcionan como una base de datos. Este patrón localiza el componente base de datos de forma separada al sistema. 5. Base de datos distribuida: Este patrón descomponen la base de datos en componentes separados los cuales interactuan por medio de interprocesos que comunican los servicios. Con una base de datos distribuida una aplicación puede integrar los datos desde diferentes sistemas de base de datos o los datos pueden ser almacenados en una localización cercana a donde se están procesando. Cada uno de los patrones se puede aplicar de forma ortogonal, es decir, no influye el hecho de aplicar un patrón a la hora de poder aplicar el siguiente. A continuación en la figura 3 podemos ver como cada patrón de distribución va dividiendo cada una de las capas. Modelo 2 Capas Modelo 3 Capas Modelo 6 Capas Interfaz de Usuario Interfaz de Usuario Presentación Distribuida Presentación Control de Usuario Servidor Interfaz de usuario remoto Lógica de Negocio Base De Datos Remota Persistencia Núcleo Aplicación Distribuido Base de Datos Distribuidas Control de procesos Objetos de Negocio Acceso a Datos Física de Datos Figura 3. Esquema de aplicación de cada uno de los patrones de distribución sobre las capas. Una vez identificados los tipos de capas, cada uno de los cuales aporta un dominio del problema específico, vamos a definir cuales van a ser los elementos del modelo de subsistemas. 11

12 Aparecen como elementos principales: Subsistema: Elemento de mayor granularidad en el diseño arquitectónico de una aplicación. Define una agrupación de componentes desarrollados para dotarle de la funcionalidad necesaria para cumplir con la tarea propia de una capa lógica. Por ello, vamos a distinguir tantos tipos de subsistemas como capas identificadas. o Representación UML: Es un estereotipo de paquete que corresponde con el tipo de subsistema que estamos definiendo. Existen tantos tipos como capas y subcapas definidas. Es decir que definimos 9 tipos. <<Tipo de subsistema>> Nombre de subsistema Figura 4. Representación de un subsistema. Relación de dependencia: Se establece una relación de dependencia entre cada uno de los subsistemas que viene marcada por las relaciones de uso. Utilizamos la dependencia de paquetes de UML. Por otro lado, en el metamodelo de WebSA, vamos a definir mediante el lenguaje de restricción OCL [OMG] las posibles relaciones que se establecen entre los diferentes tipos de subsistemas, e indicar que elementos vamos poder descomponer según el tipo de distribuciones posibles. En la siguiente figura se muestra un ejemplo de diagrama de diseño estructural de una aplicación web de comercio electrónico llamada Telecomercio. Cabe reseñar que cuenta con dos interfaces de usuario, uno que sería el sitio web que colgaríamos de internet, y el otro es una herramienta de administración con la cual cargaríamos información sobre personalización y contenido al sitio web. 12

13 <<Presentation>> Web Site Telecomercio <<Presentation>> Administrador Web Site <<Dialog Control>> DC W eb Site <<Dialog Control>> DC A dministrador <<Business Logic>> Telecomercio <<Persistence>> BDTelecomercio Figura 5. Ejemplo de Telecomercio. Una vez hemos divido del sistema en los subsistemas que lo consituyen el siguiente paso es adentrarnos en cada uno de ellos, y ver cuales son los componentes que lo componen. Dichos componentes deben definirse en armonía respecto al esquema definido a este nivel, ya que las dependencias establecidas entre los diferentes subsistemas, nos indicarán si los componentes de estos podrán relacionarse o no. 13

14 3.2 Modelo de Configuración de Componentes la Web Una vez hemos fijado a través de los requisitos no funcionales cuales van a ser la distribución en subsistemas que va a tener nuestra aplicación, el siguiente paso consiste en descomponer cada uno de dichos subsistemas en los componentes que van a constituir la arquitectura estática de nuestra aplicación. Básicamente, el modelo de configuración de componentes de web consiste en fijar la configuración estática de los diferentes subsistemas a través de una colección de componentes del dominio web abstractos vinculados entre sí a través de diferentes tipos de relaciones de dependencia. Dentro de dicho diagrama, cada uno de dichos componentes web abstractos van a estar identificados por un tipo propio del subsistema en el que está ubicado, y además tendrá asociada una cardinalidad sobre la población de dicho componente. Por otro lado, las relaciones igualmente vendrán a fijar el tipo y las cardinalidades entre los diferentes componentes del sistema. A este nivel de abstracción, vamos a poder identificar otra serie de elementos de reutilización como son los patrones de arquitectura que nos van a permitir relacionar dicho modelo con los requisitos no funcionales. Como veremos en las fases posteriores, dichos patrones de arquitectura identificados por autores como [BMR+96] y [Conallen] serán aplicados a los componentes de las diferentes capas de la aplicación web. Por otro lado, este modelo podemos considerarlo similar al que propone [Hassan2001] en su modelo ALS [Architecture Level Schema], pero a diferencia de este además de expresar la relación existente entre los componentes y los subsistemas, se intenta fijar el tipo y la cardinalidad de los componentes con lo cual se restringe la población de los componentes concretos identificados en próximos refinamientos. Las propiedades principales de dicho diseño modular son: 1. Se define una ontología de elementos localizados en el dominio de las aplicaciones web. 2. Proporciona un nivel de abstracción que recoge los patrones arquitectónicos y frameworks, que posibilitan recoger nuevos requisitos de calidad. Eso sí siempre restringidos a lo especificado en el diseño estructural. 3. Independiente de dominio, que nos aporta la posibilidad de reutilizar dicho modelo para más de un sistema. 4. Independencia de lenguaje y de plataforma que no nos obliguen a tomar compromisos tecnológicos en una fase temprana, y de esta manera poder especificar un abanico más amplio de implementaciones. 5. Definición y formalización de los elementos a través del metamodelo WebSA en UML, lo que nos proporciona una trazabilidad de los elementos que aquí se incorporan. 6. Orientado a web, consecuencia del punto anterior, ya que los elementos que se manejan están definidos para aplicaciones hipermediales. 14

15 Un componente a este nivel de abstracción va a proporcionarnos una tarea concreta e identificada como común dentro de la arquitectura de una aplicación web. Para ello a cada uno de estos componentes vamos a dotarlos de dos propiedades comunes: 1. Un tipo: Nos va a indicar cual es la tarea a desempeñar dentro de la arquitectura de la aplicación, y cual es la disposición y relaciones que puede tener. Este tipo va a estar restringido a una aplicación web y a la capa dentro del cual se define, con lo cual vamos a conseguir reducir el número de mapeos posibles a los elementos de diseño concretos. Como veremos en el próximo modelo, dicho tipo va a marcar el mapeo que se va a realizar con los elementos de las vistas funcionales de la aplicación web. 2. Cardinalidad de despliegue: Va a definir cual es el número de elementos concretos que se van a generar en las posteriores fases de diseño Constructores del diseño modular Vamos a definir cuales van a ser los elementos y las propiedades que dichos elementos van a tener: a) Componente Abstracto Representa una abstracción de uno o más componentes software con una misma funcionalidad o tarea dentro de una aplicación web. Además, cada componente va a tener una relación de dependencia con uno o más componentes que estarán restringidas en función del tipo y del modelo de subsistemas definido en la fase anterior. Vemos la definición dentro del metamodelo de dicho artefacto. Class WebApplicationComponent Cardinality : String type : String Client Page Model Session... Figura 6. Definición de los componentes MCC dentro del metamodelo WSA. Propiedades: Cada componente va a tener un conjunto de atributos que indican su función dentro de la arquitectura de la aplicación. 15

16 a. Tipo: Indica el tipo de tarea que dicho componente software va a representar en la aplicación web. Un componente dentro del dominio de una aplicación web podría ser desde una pagina, a un componente de servidor, a un componente de control, etc. b. Cardinalidad: Indica cual va a ser el conjunto de componentes software concretos que se van a generar a partir de este. c. Interfaz: Representa las operaciones que dicho componente oferta al resto del sistema para poder ser invocado. Dicho interfaz al estar definido a un nivel de abstracción más alto que los componentes software concretos, va a contener únicamente métodos que sean comunes a todos los componentes generados posteriormente. A dicho interfaz vamos a representarlo mediante la notación lollipop de UML. Representación UML-> El componente se representa mediante un estereotipo de clase. Según el tipo que se defina podremos indicar el icono con el cual se representa, y en último caso representarlo entre llaves como cualquier estereotipo. <<Tipo de componente>> Nombre de componente Interfaz Cardinalidad b) Conector Abstracto Figura 7. Representación de un componente. Relación de dependencia establecida entre dos componentes del sistema. Además, dicha relación puede establecerse sobre el componente o sobre su interfaz, lo que indica un nivel de acoplamiento menor. Esta relación expresa una dependencia entre los dos componentes, dependencia que va a venir expresada por el tipo del conector. Además, al igual que los elementos, se va a definir una cardinalidad de despliegue que va a generar los elementos conectores que cumplan la condición de despliegue. Propiedades: a. Tipo: Indica el tipo de relación establecida entre los dos elementos arquitectónicos. Cada uno de estos tipos va a indicar si se trata de una tarea de invocación, construcción (build), si es remota o local (admite llamadas entre dos nodos diferentes de la arquitectura física), etc. b. Cardinalidades: Indica cual va a ser el número de relaciones que se van a establecer entre los componentes relacionados. Puede ser 0-1, 1, *,+. 16

17 Representación en UML: En este caso cada uno de los tipos va a venir representada por un estereotipo de la relación de dependencia. Componente A Card. A Card. B Componente B <<Tipo dependencia>> Figura 8.Representación de la relación de dependencia entre 2 componentes Clasificación de los tipos de Componentes Vamos a realizar una clasificación de los diferentes tipos de componentes que vamos a poder identificar en función del subsistema en el que nos encontremos dentro del diseño modular. Dichos tipos van a estar definidos dentro del dominio de las aplicaciones web y más concretamente en cada una de las capas que por si mismas desempeñan una función diferente. Para la definición de dichos tipos vamos a definir cual es su relación dentro del metamodelo de WebSA, y su vinculación la parte funcional de OO-H con el tipo genérico definido. Sin embargo, existen algunos componentes que son propios de las aplicaciones web y no están vinculados con la parte funcional, p.e. el componente Explorador. Para dichos componentes no tienen un mapeo con la parte funcional pero si formar parte del metamodelo de WebSA. Para hacer la clasificación de los tipos vamos a indicar cuales de ellos pueden definirse en cada una de las 10 capas identificadas en el modelo de Subsistemas. Existen tipos de elementos que por contener funcionalidad perteneciente a más de una capa solo puedan definirse en una capa compuesta, por ejemplo, un applet contiene funcionalidad de la capa de presentación y de la de control así que solo puede definirse en un subsistema de tipo interfaz de usuario Subsistemas de Interfaz de Usuario Capa encargada de dotar de la funcionalidad necesaria para la interacción entre el usuario y la aplicación. En función de la aplicación del patrón de distribución Presentación Distribuida va a estar divida a su vez por dos subcapas: Presentación y Control de Usuario. A la hora de elegir cuales son los elementos más adecuados para cada una de las capas, nos hemos basado en los trabajos como [Conallen] que define un conjunto de elementos para especificar una aplicación web en UML. Existen tipos de componentes que se solo se pueden ejecutar cuando presentación y control no están separados, son los siguientes: Objeto Web: Componente que es ejecutado en el cliente proporcionando la funcionalidad tanto de presentación como de control de diálogo. Normalmente 17

18 se ejecuta en el browser mediante plugins, los ejemplos más típicos son los Applets Java, los componentes Flash, y los Actives. A continuación indicamos los elementos que podemos identificar en cada una de las subcapas, que igualmente pueden utilizarse cuando ambas capas están unidas. a) Subsistema de Presentación. Este subsistema cuya principal función es la de mostrar e interactuar con el usuario de la aplicación. En esta capa va a aparecer los siguientes tipos elementos (Componente): Explorador: Cualquier explorador HTML estandar, con soporte o no a plugins Flash, Java. Capaz de interpretar las páginas de presentación, estilo y funcional, mostrárselas al usuario. Aparte de esto es capaz de aceptar y de devolver cookies. Pagina Cliente: Componente que contiene el contenido necesario para presentar la información al usuario, recibir la entrada de datos, validarlos si es necesario y además realizar las invocaciones al servidor. (p.e. HTML, XML, página flash). Puede contener referencias a otros componentes cliente, estilo y funcional. Pagina Estilo: Componente que únicamente mantiene información referente al aspecto del interfaz de usuario (p.e. CSS, XSL). Puede ser referenciado por un componente cliente. Pagina Funcional : Componente que mantiene funcionalidad para la interacción del usuario con el interfaz de la aplicación. Dicha funcionalidad puede ser validación, presentación, navegación, etc. (p.e. Javascript, ActionScript). Puede ser referenciado por un componente cliente. Almacén: Componente que mantiene a un mecanismo de almacenamiento localizado en la capa del cliente, que le va a permitir recuperar información entre sesiones. El ejemplo más habitual es la cookie. b) Subsistema de Control de Diálogo Este subsistema llamado Control de diálogo o capa de presentación se encarga de realizar el procesamiento de la funcionalidad de presentación, tanto en lo que se refiere a su navegación, a su presentación, y en las invocaciones que se realicen a la capa de la lógica. Basándonos en la separación funcional de procesamiento, entrada y salida que hace el patrón MVC [BMR+96], vamos a incorporar ciertos elementos comunes dentro de esta capa. Los principales tipos identificados son: Página Servidora: Componente que realiza el procesamiento de la pagina web mediante scripts ejecutados en la parte servidora, normalmente por un engine que ejecuta el código de la página y le devuelve el contenido al servidor web. Dicho componente contiene la información referente a la presentación y/o lógica en el servidor y genera uno o más componentes de la capa de interfaz de usuario. (p.e. ASP, JSP, PHP, Coldfusion, etc). 18

19 Control: Componente que se encarga de recibir las peticiones realizadas por el usuario y establece la reacción del interfaz. La funcionalidad que aporta es la de redireccionar las peticiones de servicios a la lógica de negocio o al componente modelo, y la de redireccionar las peticiones de navegación a páginas servidoras. Representación en Metamodelo: Para definir la reacción obtendremos la información del modelo de navegación (NAD). A partir del cual establecemos una relación con la clase Navigational Link, el la cual control contendrá la funcionalidad de n enlaces. Por otro lado, tendrá una relación de asociación con la clase Operación OO-H, definida a partir de la herencia de la clase Operación del UML. <<W ebapplicationcomponent>> WAC1 <<NAD class>> NAD1 <<Operation>> ConceptualC1 1 1 target 0..n sourc e 0..n 0..n 0..1 <<ControlAWD>> CAWD n <<Navigational Link>> NV1 <<OperationOOH>> op1 Figura 9. Metamodelo del componente ControlAWD Modelo: Componente que representa los datos y la funcionalidad del dominio de la aplicación en la capa de presentación. Está definido mediante el diagrama de clases de la vista conceptual. Vista: Componente obtiene la información del modelo, y muestra la información al usuario. La forma en que la muestra es independiente del dominio de la aplicación. Viene definida por el CLD o modelo de presentación. Sesión: Componente que mantiene la información durante la sesión de un determinado usuario. Aplicación: Componente que mantiene la información común para todos los usuarios. Cliente: Componente que mantiene la información para un determinado cliente. Legado: Componente que realiza una invocación a la capa de control o que es demandado por la capa de control para que haga una determinada tarea. 19

20 Almacén: Componente que va a mantener información de forma persistente localizada en la capa de presentación o control. Dicha información accesible únicamente por los componentes de esta capa almacena información referente a configuración, idioma, personalización, etc. Un ejemplo puede ser un fichero properties de java, un xml, etc Subsistemas de Lógica de Negocio Esta es la parte del sistema que resuelve las reglas de negocio especificadas para el dominio del problema. Dicha capa puede estar o no divida por dos subcapas, procesos de negocio y por los objetos de negocio. Ambas partes aparecen especificadas por la vista conceptual de sistema, y se van a distribuir en un conjunto de componentes que en función de los requisitos de calidad van a sugerir la utilización de computación distribuida, standalone, etc. Los componentes identificados en este subsistema están basados en abstracciones del estándar EDOC (Enterprise Distributed Object Computing)[OMG02], esto nos va a permitir posteriormente obtener en el refinamiento a componentes concretos definidos en el estándar EDOC, para los cuales MDA nos proporcionará los mapeos a distintas plataformas. a) Subsistema de Procesamiento de Control Esta parte del sistema se encarga de atender las peticiones que se reciben del cliente, convirtiéndolas en procesos que se realizará de forma transaccional o no, de forma síncrona o asíncrona. Aquí utilizaremos las siguientes combinaciones de componentes: Sesión Sin Estado: Componente que no mantiene estado de un determinado cliente, es decir, se crea un hilo de ejecución nuevo por cada invocación que se realice. Lo que le otorga la posibilidad de generar n hilos muy ligeros y atender a muchos clientes simultáneamente. Se utiliza cuando el número de usuarios de la aplicación es elevado. Sesión Con Estado: Componente que mantiene estado de un determinado cliente durante toda su interacción. Lo que le obliga a establecer una instancia por cada cliente. Resultando más útil cuando se exigen altas prestaciones, a un número de usuarios no muy elevado. Sesión Asíncronos: Componente que recibe invocaciones en modo asíncrono de una lista de distribución o de una pila de llamadas. Componente Por Lotes: Componente que realiza un conjunto de eventos no transaccionales. Componente Servidor Legado: Componente que realiza su tarea desde un sistema legado. Funcional: Componente que contiene una colección de funciones accesibles por el resto de elementos del subsistema. b) Subsistema de Objetos de negocio 20

21 En dicho subsistema residen los elementos que contienen la representación de los objetos definidos en el dominio del problema. En nuestra aproximación aparecen definidos en la vista conceptual. Dichos componentes pueden ser de estos tipos: Entidad Distribuida: Componente que representa una instancia de una o más clases del modelo. Además, mantiene la información del modelo en memoria de manera que previo un proceso de carga, se accede a esta información y posteriormente se actualiza dicha información en la capa de persistencia. Esto permite reducir el número de accesos a base de datos con la ventaja a nivel de rendimiento que supone. Entidad Local: Componente que representa una instancia de una o más clases del modelo, pero que necesita acceder a la persistencia para realizar cualquier operación. Es utilizada cuando no es necesario optimizar los accesos a BD. CAD (Componente de Acceso a Datos): Componente cuya funcionalidad es la de acceder a los datos independizando a las componentes del dominio del tipo de persistencia que el sistema utiliza. Está basado en el patrón de diseño DAO de Gamma. Funcional: Componente que contiene una colección de funciones accesibles por el resto de elementos del subsistema. Legado: Representa una instancia del modelo o de otro sistema que es mantenida por un sistema legado Subsistemas de Persistencia Parte del sistema encargada del dotarle de persistencia al sistema de información. Dada la división marcada por la aplicación del patrón Base de Datos Remota, los componentes en cada una de las subcapas van a estar enfocados por un lado al acceso y por el otro a la gestión de dichos datos. a) Subsistema de acceso a datos. Este subsistema se encarga de contener aquellos elementos que permiten el acceso a los datos físicos desde la capa de lógica de negocio. Además provee de la funcionalidad necesaria para poder otorgar una serie de mejoras de rendimiento y escalabilidad como son la utilización de un pool de conexiones o la de disponer de bases de datos remotas. Pool: Componente que consiste en una colección de recursos que nos permiten reutilizar dichos recursos para un conjunto de usuarios elevados, y además reducir drásticamente el tiempo necesario para crear y destruir cada conexión física. Fuente de Datos: Componente que nos proporciona la conexión lógica con la fuente de datos. Va a mantener una serie de propiedades como son la posibilidad de admitir transacciones, el usuario y password, etc. 21

22 CAD (Componente Acceso Datos): Componente que nos proporciona la posibilidad de realizar una conexión física con la fuente de datos. Dicho puente puede admitir conexiones remotas (TCP/IP...), ser estandar (JDBC,ODBC...), admitir BDOO o BDR o Legacy. b) Subsistema físico de Datos Este subsistema determina cuales van a ser las fuentes físicas de datos que va a contener nuestro sistema. Dichas fuentes son de diversa naturaleza, y pueden estar distribuidas de forma local o remota dependiendo del tipo de puente utilizado. Los elementos que nos podemos encontrar son los siguientes: Almacen: Gestor donde almacenamos la información de nuestro sistema de información. Puede ser de diferentes tipos: Relacional: Base de Datos Relacional, compuesta por un conjunto de tablas relacionadas y mediante un lenguaje de consulta SQL que nos facilita el acceso a los datos. Orientado Objetos: Base de Datos Orientada a Objetos, más sofisticada que la relacional puesto que no solo permite el tratamiento de los datos, sino que proporcionan un lenguaje propietario que posibilita la definición de lógica de negocio a este nivel. Ficheros Planos: Base de datos que gestiona ficheros fisicos, ya sea con un formato propio o estándar (XML). Legada: Sistema legado que nos proporciona datos de un sistema existente y sobre el cual vamos a acceder para el funcionamiento del sistema. Funcional: Funciones localizadas a un nivel dependiente del gestor de base de datos, pueden tratarse tanto de procedimientos almacenados en el lenguaje del propio gestor o en XML Definición de los tipos de conectores Existen diferentes 3 tipos de conectores cada uno de los cuales indica una relación diferente entre componentes o módulos: Invocación Remota: Llamada que realiza un componente a otro elemento del diagrama de forma remota, es decir, soporta una distribución en nodos físicos diferentes (HTTP,TCP/IP,SMTP). Invocación Remota Segura: Llamada que realiza un componente a otro elemento del diagrama de forma remota y además utilizando un protocolo seguro (p.e. HTTPS, IMAP/SSL, SMTP/SSL, etc.) Invocación local: Llamada que realiza un componente a otro elemento del diagrama de forma local, es decir, dichos elementos han de residir en el mismo subsistema. 22

Arquitectura. 1.- Aplicaciones Web. Definición. Arquitectura clásica. Contenidos. 1.- Aplicaciones Web

Arquitectura. 1.- Aplicaciones Web. Definición. Arquitectura clásica. Contenidos. 1.- Aplicaciones Web Arquitectura 1.- Aplicaciones Web Definición Contenidos 1.- Aplicaciones Web 2.- Arquitectura de aplicaciones Web Lo que distingue una aplicación Web de una mero sitio Web reside en la posibilidad que

Más detalles

Tema 3. 3.3 Tecnologías de Desarrollo

Tema 3. 3.3 Tecnologías de Desarrollo Tema 3 3.3 Tecnologías de Desarrollo HTML pronto pasa a ser insuficiente para todas las posibilidades de la Red No se puede interactuar con el servidor Aparecen los primeros scripts para propocionar dichar

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Anexo 4 Documento de Arquitectura

Anexo 4 Documento de Arquitectura Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de

Más detalles

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R índice Módulo A Unidad didáctica 1: Introducción a las Bases de Datos Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos 3 19 Módulo B Unidad didáctica 1: Fase de análisis de requisitos Modelo

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

Capítulo 6: Instrumentación: Diseño del Sistema de H2O

Capítulo 6: Instrumentación: Diseño del Sistema de H2O Capítulo 6: Instrumentación: Diseño del Sistema de H2O Digital Media Server El video en demanda a través del web aún está restringido a las grandes empresas que pueden pagar por contar por un servicio

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

Tema 1. Arquitectura Cliente/Servidor

Tema 1. Arquitectura Cliente/Servidor Tema 1. Arquitectura Cliente/Servidor SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs 27 de septiembre de 2009 FJRP, FMBR [sistemas cliente-servidor] CCIA 1.1 Sistemas

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

1 Índice... 1. 2 Introducción... 2. 2.1 Propósito... 2. 2.2 Alcance... 2. 3 Modelo Arquitectónico Inicial... 3

1 Índice... 1. 2 Introducción... 2. 2.1 Propósito... 2. 2.2 Alcance... 2. 3 Modelo Arquitectónico Inicial... 3 1 Índice 1 Índice... 1 2 Introducción... 2 2.1 Propósito... 2 2.2 Alcance... 2 3 Modelo Arquitectónico Inicial... 3 3.1 Diagrama de alto nivel de la arquitectura... 3 3.2 Vista de Casos de Uso... 5 3.2.1

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

Capítulo I. Marco Teórico

Capítulo I. Marco Teórico 1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende

Más detalles

Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo

Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes

Más detalles

Perfil UML para el desarrollo de aplicaciones WAP

Perfil UML para el desarrollo de aplicaciones WAP Perfil UML para el desarrollo de aplicaciones WAP Ricardo Soto D., Mauricio Camara J. Escuela de Ingeniería Informática, Pontificia Universidad Católica de Valparaíso, Chile E-mail: ricardo.soto@ucv.cl,

Más detalles

con certif icado de profesionalidad

con certif icado de profesionalidad CARACTERÍSTICAS El diseño web está cambiando en poco tiempo. Las nuevas tecnologías y estándares de programación están revolucionando tanto la forma de crear web como de interactuar con ellas. En nuestro

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

2.1 Compuertas para Bases de Datos

2.1 Compuertas para Bases de Datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Uno de los aspectos mas importantes en un sistema multibase de datos es la forma en como llevar a cabo la comunicación

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE Sistema de Gestión Presupuestaria SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009

Más detalles

Enterprise Analyst: Taller de Bautizo

Enterprise Analyst: Taller de Bautizo Enterprise Analyst: Taller de Bautizo Metas Entender la Necesidad de Ejecutar los Modelos Desarrollar un caso usando UML tradicional Identificar los problemas de UML Conocer la Herramienta Enterprise Analyst

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS

ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS INGENIERIA DE SOFTWARE Trabajo Final de Carrera ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS Jordi Cid Rodríguez - ETIG - Consultor: José Antonio Raya Martos Septiembre 2011 Objetivo El

Más detalles

Objetivo Las personas que realicen el curso aprenderán a:

Objetivo Las personas que realicen el curso aprenderán a: Objetivo Las personas que realicen el curso aprenderán a: Describir el proceso de desarrollo de software orientado a objetos, lo que incluye las metodologías y los flujos de trabajo de la programación

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

Desarrollo de Aplicaciones con Tecnologías Web

Desarrollo de Aplicaciones con Tecnologías Web Desarrollo de Aplicaciones con Tecnologías Web Código: Modalidad: Distancia Duración: 100 Horas. Objetivos: La presente formación se ajusta al itinerario formativo del Certificado de Profesionalidad IFCD0210

Más detalles

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI.

Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Ponencia para Evento de Redes. Autor: Rubén Rivera Rodríguez, Citmatel Resumen Uso de los Servicios Web en la nueva arquitectura de N-Capas del Sistema Económico Integral Rodas XXI. Las nuevas tendencias

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa.

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. BASES DE DATOS Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. La creación de una base de datos debe ser realizada cuidadosamente procurando

Más detalles

Arquitectura de Aplicaciones Empresariales. Lic. Esteban Cesar Calabria

Arquitectura de Aplicaciones Empresariales. Lic. Esteban Cesar Calabria Arquitectura de Aplicaciones Empresariales Aplicaciones empresariales Temario Aplicaciones Empresariales Arquitectura Aplicaciones Empresariales Layering Negocio Persistencia Presentación Ejemplos Aplicaciones

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV 746 Miércoles 5 octubre 2005 Suplemento del BOE núm. 238 CE2.1 Identificar los distintos sistemas de archivo utilizables en un dispositivo de almacenamiento dado para optimizar los procesos de registro

Más detalles

Tema 3: Bases de datos en Entorno Web

Tema 3: Bases de datos en Entorno Web Tema 3: Bases de datos en Entorno Web 1. Introducción. Un sistema de bases de datos proporciona un control centralizado de los datos. Esto contrasta con la situación que prevalece actualmente, donde a

Más detalles

Introducción a Javato

Introducción a Javato Introducción a Javato Fº. Javier Pereñiguez Steria Iberica 20/02/2008 Índice Introducción Arquitectura Ejemplo arquitectura Plataforma Desarrollo Ejemplo de entorno de desarrollo Vías futuras Casos de

Más detalles

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software.

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. . TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. Índice 1 INTRODUCCIÓN 2 2 CARACTERÍSTICAS 2 2.1 Características del cliente...2 2.2 Características

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Arquitectura cliente/servidor

Arquitectura cliente/servidor Departamento de Lenguajes y Sistemas Informáticos Arquitectura cliente/servidor Programación en Internet Curso 2007-2008 Índice Introducción Tipos de servidores Ventajas Desventajas Arquitectura de una

Más detalles

Diplomado Java. Descripción. Objetivo. A quien está dirigido. Requisitos. Beneficios

Diplomado Java. Descripción. Objetivo. A quien está dirigido. Requisitos. Beneficios Diplomado Java Descripción El lenguaje de programación Java es uno de los más utilizados hoy en día. Su potencia, simplicidad, funcionalidad y capacidad hacen que este lenguaje sea una de las herramientas

Más detalles

Clientes Donantonio. Especificación de requisitos software. Juan José Amor David Escorial Ismael Olea

Clientes Donantonio. Especificación de requisitos software. Juan José Amor David Escorial Ismael Olea Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3

Más detalles

Arquitectura y Diseño de la Solución

Arquitectura y Diseño de la Solución Arquitectura y Diseño de la Solución Recuento de Conceptos importantes Modelamiente / Versionamiento de trámites Vista Conceptual Subsistemas Funcionales Principales Detalle de los subsistemas Vista de

Más detalles

TEMA: DESARROLLO DE APLICACIONES WEB INTERACTIVAS UTILIZANDO LA TÉCNICA AJAX AUTOR: MERY SUSANA ZAMBONINO BAUTISTA

TEMA: DESARROLLO DE APLICACIONES WEB INTERACTIVAS UTILIZANDO LA TÉCNICA AJAX AUTOR: MERY SUSANA ZAMBONINO BAUTISTA TEMA: DESARROLLO DE APLICACIONES WEB INTERACTIVAS UTILIZANDO LA TÉCNICA AJAX AUTOR: MERY SUSANA ZAMBONINO BAUTISTA AREA DEL TEMA: INGENIERÍA DE SOFTWARE OBJETIVO GENERAL Desarrollar aplicaciones web utilizando

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

DOCUMENTACION A PRESENTAR: TRABAJADORES (RÉGIMEN GENERAL, ADMINISTRACIÓN PÚBLICA, AUTÓNOMOS) DEMANDANTES DE EMPLEO

DOCUMENTACION A PRESENTAR: TRABAJADORES (RÉGIMEN GENERAL, ADMINISTRACIÓN PÚBLICA, AUTÓNOMOS) DEMANDANTES DE EMPLEO MF0492_3 PROGRAMACION WEB EN EL ENTORNO SERVIDOR (IFCD0210: DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB) 240 HORAS PRESENCIALES Nº DE EXPEDIENTE: FC/2013/0064 ACCION 217 GRUPO 1 ACCIÓN FORMATIVA FINANCIADA

Más detalles

Arquitectura de aplicaciones

Arquitectura de aplicaciones Arquitectura de aplicaciones Arquitectura en capas API API dic-08 alb@uniovi.es 2 Layers y Tiers Layer: capa arquitectónica de la aplicación software Presentación, lógica, persistencia Tier: capa física

Más detalles

NUEVA WEB DE LA CONSEJERÍA DE INNOVACIÓN, CIENCIA Y EMPRESA: LA INNOVACIÓN COMO NEXO COMÚN DE UN DESARROLLO WEB

NUEVA WEB DE LA CONSEJERÍA DE INNOVACIÓN, CIENCIA Y EMPRESA: LA INNOVACIÓN COMO NEXO COMÚN DE UN DESARROLLO WEB NUEVA WEB DE LA CONSEJERÍA DE INNOVACIÓN, CIENCIA Y EMPRESA: LA INNOVACIÓN COMO NEXO COMÚN DE UN DESARROLLO WEB Jefe del Servicio de Informática Consejería de Innovación, Ciencia y Empresa Jefe de Proyectos

Más detalles

ARQUITECTUA DE M2M MIGUEL ÁLVAREZ Y CLARA HERRERO. Documento inicial

ARQUITECTUA DE M2M MIGUEL ÁLVAREZ Y CLARA HERRERO. Documento inicial Título ARQUITECTUA DE M2M Proyecto Monkey to Monkey ( M 2 M ) Equipo Proyectos Informáticos Versión 1.0 Código PLAN_M2M_2012_04_01 Fecha 19/04/2012 Autores MIGUEL ÁLVAREZ Y CLARA HERRERO Estado Documento

Más detalles

CURSO DE ESPECIALISTA EN DESARROLLO DE APLICACIONES WEB

CURSO DE ESPECIALISTA EN DESARROLLO DE APLICACIONES WEB CURSO DE ESPECIALISTA EN DESARROLLO DE APLICACIONES WEB Objetivos Generales: Al término de esta acción formativa los participantes alcanzarán los siguientes objetivos: Preparar profesionales para el desarrollo

Más detalles

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012 TFC J2EE Aplicación Web para la gestión de facturación de una empresa de cerrajería Sara Gutiérrez Melero ITIG Junio de 2012 Consultor: Jose Juan Rodriguez Índice 1. Introducción Objetivos Planificación

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

Arquitectura de Aplicaciones Empresariales. Lic. Esteban Cesar Calabria 2007

Arquitectura de Aplicaciones Empresariales. Lic. Esteban Cesar Calabria 2007 Arquitectura de Aplicaciones Empresariales 2007 TEMARIO Introducción Aplicaciones Empresariales Introducción a la Arquitectura de Aplicaciones empresariales Layering Patrones Arquitecturas Empresariales

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

ARC 101 Architecture Overview Diagram

ARC 101 Architecture Overview Diagram ARC 101 Architecture Overview Diagram Estudio de Arquitectura para la evolución tecnológica de los aplicativos de ATyR Banco de Previsión Social ATYR Evolución Tecnológica Pág 1 of 10 Tabla de Contenidos

Más detalles

ACCIÓN FORMATIVA FINANCIADA POR EL SERVICIO PÚBLICO DE EMPLEO ESTATAL

ACCIÓN FORMATIVA FINANCIADA POR EL SERVICIO PÚBLICO DE EMPLEO ESTATAL MF0491_3: PROGRAMACIÓN WEB EN EL ENTORNO CLIENTE. (IFCD0210: DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB) 180 HORAS PRESENCIALES Nº DE EXPEDIENTE: FC/2013/0064 ACCION 141 GRUPO 1 ACCIÓN FORMATIVA FINANCIADA

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

CONSTRUCCIÓN DE PORTALES

CONSTRUCCIÓN DE PORTALES Curso «Los portales de internet». Fac. Documentación. Universidad de Murcia. 29 CONSTRUCCIÓN DE PORTALES Juan Antonio Pastor Sánchez 1. Introducción La Gestión de los contenidos informativos de los portales

Más detalles

Historia de revisiones

Historia de revisiones Herbert Game Descripción de la Arquitectura Versión 1.8 Historia de revisiones Fecha Versión Descripción Autor 29/08/2011 1.0 Creación del documento Juan Pablo Balarini Máximo Mussini 30/08/2011 1.1 Actualización

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V Bibliografía Tema V Tecnología de objetos distribuidos y arquitectura de componentes. Szyperski, C. 1998. Component Software. Addison-Wesley. Ruiz Cortés, 1998. A. CORBA: Una visión general. http://www.lsi.us.es/~aruiz

Más detalles

Estilos de Arquitectura y. Patrones de Diseño Arquitectónico. Patrones de Arquitectura

Estilos de Arquitectura y. Patrones de Diseño Arquitectónico. Patrones de Arquitectura Estilos de Arquitectura y Patrones de Diseño Arquitectónico Gastón Mousqués - AR 1 Patrones de Arquitectura Gastón Mousqués - AR 2 Principales Categorías de Patrones (Software) Patrones de Análisis Expresan

Más detalles

Arquitectura de Proyectos de IT

Arquitectura de Proyectos de IT Arquitectura de Proyectos de IT Apunte: Comunicación de Arquitectura de Software Autores: Ing. Gustavo A. Brey (gbrey@sistemas.frba.utn.edu.ar) Santiago Blanco (santiago.blanco@gmail.com) Versión: 0.8.20081106

Más detalles

Sistemas de Información Introducción a los Sistemas de Información: El Modelo Cliente/Servidor

Sistemas de Información Introducción a los Sistemas de Información: El Modelo Cliente/Servidor Sistemas de Información Introducción a los Sistemas de Información: El Modelo Cliente/Servidor Agradecimientos: por su contribución a la realización de estas transparencias: Jesus Villamor Lugo y Simon

Más detalles

Concepto de Arquitectura en Desarrollo Software. Arquitectura física Distribución de nodos en la red. Concepto de Arquitectura software Moderno

Concepto de Arquitectura en Desarrollo Software. Arquitectura física Distribución de nodos en la red. Concepto de Arquitectura software Moderno Arquitectura Web Introducción Concepto de Arquitectura en Desarrollo Software Concepción desde RUP Arquitectura física Distribución de nodos en la red Mapeo componente software nodo computacional Concepto

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Implantación de Aplicaciones Web Fecha: 20-09-13

Implantación de Aplicaciones Web Fecha: 20-09-13 Página 1 de 24 RESUMEN DE LA PROGRAMACIÓN ADMINISTRACIÓN DE SISTEMAS INFORMÁTICOS EN RED CURSO AC. 2012 / 2013 ÁREA / MATERIA / MÓDULO PROFESIONAL Implantación de Aplicaciones Web (84 horas 4 horas semanales)

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

GESTIÓN DE UN SUPERMERCADO BAJO UN SERVIDOR DE ORACLE. Noemí Peña Portillo

GESTIÓN DE UN SUPERMERCADO BAJO UN SERVIDOR DE ORACLE. Noemí Peña Portillo GESTIÓN DE UN SUPERMERCADO BAJO UN SERVIDOR DE ORACLE Noemí Peña Portillo 1. Qué voy a explicar? Objetivos del proyecto. Oracle Developer Suite 10g y Componentes. Configuración de red. Oracle Designer

Más detalles

DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN

DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN DIPLOMADO EN TECNOLOGÍAS DE LA INFORMACIÓN MODULO I: Análisis y Diseño de Sistemas El alumno se familiarizará y describirá los conceptos y aspectos fundamentales del Análisis y Diseño Orientado a Objetos

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

PFC- Aplicaciones Web para trabajo colaborativo:

PFC- Aplicaciones Web para trabajo colaborativo: PFC- Aplicaciones Web para trabajo colaborativo: Aplicación para Control de una Integración de S.I. 2º Ciclo Ingeniería Informática Curso 2011-2012 Consultor : Fatos Xhafa Autor : Miguel Angel Pineda Cruz

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación

Más detalles

Centro de Capacitación en Tecnologías de la Información. Desarrollo de. diplomado

Centro de Capacitación en Tecnologías de la Información. Desarrollo de. diplomado Centro de Capacitación en Tecnologías de la Información Desarrollo de Objetivo Dotar al alumno de la metodología y los fundamentos de la programación en Java usando la plataforma J2SE (Java 2 Standard

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

Arquitectura Java para el Cuarto Ejercicio. José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático

Arquitectura Java para el Cuarto Ejercicio. José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático Arquitectura Java para el Cuarto Ejercicio José Antonio Ruano Ampudia Técnico Superior de Proyecto Informático Sumario Introducción Arquitectura en n-capas Arquitectura y el Cuarto Examen Java y su modelo

Más detalles

Web Forms. Para crear una aplicación Web de ASP.NET se utilizan los controles de las secciones HTML o Web Forms de la caja de herramientas.

Web Forms. Para crear una aplicación Web de ASP.NET se utilizan los controles de las secciones HTML o Web Forms de la caja de herramientas. Web Forms Web Forms es un nuevo modelo de programación para interfaces de usuario de Internet basado en ASP.NET que sustituye a WebClasses y el Diseñador de Web Forms sustituye al Diseñador de páginas

Más detalles

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m. Arquitecto de Datos 1. Línea de Negocios: Soluciones de Negocios 2. Funciones Específicas: Participar en la realización de las actividades técnicas de actualización y migraciones a versiones mejoradas

Más detalles

Trabajo de Investigación

Trabajo de Investigación Escuela Técnica Superior de Ingeniería Informática Departamento: Ingeniería de Software y Sistemas Informáticos Trabajo de Investigación Arquitecturas Software: Gestión de los atributos de calidad de un

Más detalles

Qué se entiende por diseño arquitectónico? Comprende el establecimiento de un marco de trabajo estructural básico para un sistema. Alude a la estructura general del software y el modo en que la estructura

Más detalles

El servidor Web. Arquitectura y funcionamiento

El servidor Web. Arquitectura y funcionamiento El servidor Web. Arquitectura y funcionamiento ÍNDICE INTRODUCCIÓN Qué es un servidor? Y un servidor Web? FUNCIONAMIENTO DE UN SERVIDOR WEB Arquitectura Tipos de servidores Web Servidores basados en procesos

Más detalles

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010 INTRODUCCION Los objetos usados en aplicaciones JAVA mantienen su estado y comportamiento mientras la aplicación se halle en ejecución. Generalmente se necesita mantener el estado y comportamiento de los

Más detalles

Módulo 2. Arquitectura

Módulo 2. Arquitectura Módulo 2. Arquitectura Introducción Objetivos o Analizar la arquitectura física y lógica de la plataforma Agrega. o Identificar los componentes más importantes de la arquitectura física. o Exponer las

Más detalles

Desarrollo de software

Desarrollo de software Agenda 1. Introducción 2. Aspectos Metodológicos del Desarrollo de Software 3. Aplicación Web (Modelo del Producto) 4. Modelo del proceso 5. Dos enfoques Metodológicos 6. Métodos Seleccionados 7. Evaluación

Más detalles