Source: http://docplayer.es/1839363-Documento-de-arquitectura-de-software.html
Timestamp: 2017-05-24 00:36:09+00:00

Document:
Documento de Arquitectura de Software - PDF
Download "Documento de Arquitectura de Software"
Miguel Ángel Juan Manuel Lagos Calderón
1 Facultad de Ingeniería - Universidad de la República Pablo Alvez, Patricia Foti, Marco Scalone Junio 2006.2 Índice 1 Introducción Propósito Alcance Definiciones, Acrónimos y Abreviaciones Organización del Documento Representación de la Arquitectura Objetivos y Restricciones Requerimientos Especiales Interoperabilidad Vista de Casos de Uso Introducción Identificación de los Casos de Uso relevantes para la arquitectura Descripción de los Casos de Uso relevantes para la arquitectura Diseño de Proceso de Negocio Transformación e Instalación de Proceso de Negocio Ejecución de Proceso de Negocio Vista Lógica Introducción Descomposición en Subsistemas Descripción de los Subsistemas Diseño de Subsistemas Definición de Procesos Ejecución de Procesos Resolución de Servicios Realización de los Casos de Uso Relevantes para la Arquitectura Diseño de Proceso de Negocio Transformación e Instalación de Proceso de Negocio Ejecución de Proceso de Negocio Vista de Deployment Introducción Distribución y Deployment Arquitectura del Sistema Batuta...21 Versión 2.3 Pág. 23 7.1 Introducción Vista Lógica Subsistema de Definición de Procesos Subsistema de Ejecución de Procesos Subsistema de Resolución de Servicios Vista de Deployment Distribución y Deployment Vista de Implementación Estructura del Framework Arquitectura de la Implementación Referencias...29 Versión 2.3 Pág. 34 1 Introducción 1.1 Propósito El Documento de Arquitectura de Software presenta la arquitectura del Framework Batuta a través de diferentes vistas, cada una de las cuales ilustra un aspecto en particular del software desarrollado. Se pretende de esta forma que el documento brinde al lector una visión global y comprensible del diseño general del framework desarrollado. Luego de describir en profundidad la arquitectura del Framework Batuta, se incluye una implementación concreta de dicho framework presentando la arquitectura del Sistema Batuta construido como prueba de concepto del modelo y framework desarrollados. 1.2 Alcance El documento se centra en el desarrollo de la vista lógica del framework. Se incluyen los aspectos fundamentales del resto de las vistas y se omiten aquellas que no se consideren pertinentes como ser el caso de la vista de procesos. En cuanto a los componentes externos que se mencionen, se incluye una descripción de los mismos en el nivel que se considere apropiado y se indican las referencias donde consultar más información sobre los mismos. 1.3 Definiciones, Acrónimos y Abreviaciones Ver Glosario [1]. 1.4 Organización del Documento El documento se desarrolla y organiza en base a la plantilla elaborada para el artefacto Software Architecture Document del proceso de desarrollo de software elaborado por RUP [2], adaptada a las características particulares del tipo de proyecto en desarrollo. La sección 2 realiza una introducción a la representación utilizada de la arquitectura de forma de asegurar una comprensión cabal del documento en tal sentido. Las siguientes secciones se abocan a la descripción de la arquitectura del Framework Batuta. Luego de una descripción inicial de los objetivos y restricciones influyentes, se desarrolla cada una de las vistas y se cierra con algunas consideraciones finales importantes. En las secciones finales, y sobre la base de lo desarrollado anteriormente, se incluye la descripción de la arquitectura del Sistema Batuta. Versión 2.3 Pág. 45 2 Representación de la Arquitectura El modelo propuesto por RUP [2] para representar la arquitectura utiliza el siguiente conjunto de vistas: Vista de Casos de Uso: lista los casos de uso o escenarios del modelo de casos de uso que representen funcionalidades centrales del sistema final, que requieran una gran cobertura arquitectónica o aquellos que impliquen algún punto especialmente delicado de la arquitectura. Vista Lógica: describe las partes arquitectónicamente significativas del modelo de diseño, como ser la descomposición en capas, subsistemas o paquetes. Una vez presentadas estas unidades lógicas principales, se profundiza en ellas hasta el nivel que se considere adecuado. Vista de Procesos: describe la descomposición del sistema en threads y procesos pesados. Indica que procesos o grupos de procesos se comunican o interactúan entres sí y los modos en que estos se comunican. Vista de Deployment: describe uno o más escenarios de distribución física del sistema sobre los cuales se ejecutará y hará el deploy del mismo. Muestra la comunicación entre los diferentes nodos que componen los escenarios antes mencionados, así como el mapeo de los elementos de la Vista de Procesos en dichos nodos. Vista de Implementación: describe la estructura general del Modelo de Implementación y el mapeo de los subsistemas, paquetes y clases de la Vista Lógica a subsistemas y componentes de implementación. Vista de Datos: describe los elementos principales del Modelo de Datos, brindando un panorama general de dicho modelo en términos de tablas, vistas, índices, etc. Versión 2.3 Pág. 56 3 Objetivos y Restricciones Framework Batuta cumple con el modelo propuesto en [3]. Dentro de esta base de desarrollo son propiedades esenciales para la arquitectura a definir: diseño basado en componentes de propósito claro y concreto y con alto grado de cohesión, desacoplamiento entre componentes que permita el fácil reemplazo de los mismos, componentes altamente reutilizables. 3.1 Requerimientos Especiales Interoperabilidad El framework debe soportar la capacidad de interoperar con sistemas externos a nivel de datos y procesos. Versión 2.3 Pág. 67 4 Vista de Casos de Uso 4.1 Introducción La Vista de Casos de Uso presenta un subconjunto del Modelo de Caos de Uso. Describe los casos de uso o escenarios que representen funcionalidades centrales del sistema final, que requieran una gran cobertura arquitectónica o aquellos que impliquen algún punto especialmente delicado de la arquitectura. Estos casos de uso, en conjunto con los requerimientos no funcionales, permiten descubrir y diseñar la arquitectura del sistema. 4.2 Identificación de los Casos de Uso relevantes para la arquitectura Para el diseño del Framework Batuta, se identifican como los casos de uso relevantes desde el punto de vista de la arquitectura, los abajo mencionados: 1. Diseño de Proceso de Negocio: Representa una de las funcionalidades más importantes en la gestión de procesos de negocio, el diseño de los mismos. Introduce la necesidad de contar con un lenguaje gráfico de representación de procesos de negocio así como un editor con el cual poder construir dichos procesos. Este componente agrega la complejidad de manejar conceptos semánticos gráficamente de forma amigable e intuitiva para el usuario. Este usuario será en general un analista de negocio que posiblemente no tenga conocimientos profundos a nivel técnico informático. 2. Transformación e Instalación de un Proceso de Negocio Esta funcionalidad es sumamente importante pues permite pasar de un nivel de abstracción a otro dentro del modelo propuesto. Tanto este caso como el anterior genera la necesidad de buscar un formato de representación intermedia para la especificación del proceso de negocio. Una vez fijado dicho formato se debe especificar un mecanismo de transformación de uno al otro. Más precisamente poder generar una representación ejecutable del proceso a partir de su representación intermedia. 3. Ejecución de Proceso de Negocio Funcionalidad básica que debe proveer el framework para posibilitar la ejecución del proceso. La ejecución de un proceso de negocio es iniciada por una aplicación cliente a través de una interfaz de servicio provista por el framework. Como parte esencial de la ejecución de un proceso se debe resolver la invocación de servicios a partir de una descripción semántica de los mismos. Versión 2.3 Pág. 78 La invocación de un servicio a partir de una descripción semántica implica tres procesos fundamentales: o o o Búsqueda de servicios que se correspondan semánticamente con la descripción del perfil de servicio requerido. Contar con un mecanismo para la selección del mejor servicio, dentro de los hallados en el proceso anterior, en base a algún criterio preestablecido. Un ejemplo de esto es seleccionar el más adecuado en base a indicadores de la calidad de servicio de los mismos. En la invocación del servicio propiamente dicha se deben manejar los parámetros teniendo en cuenta sus diferentes tipos de datos, incluyendo ontologías. Introduce además la necesidad de especificar un formato de mensaje para la invocación de servicios y para la devolución de resultados. 4.3 Descripción de los Casos de Uso relevantes para la arquitectura Figura 1 Diagrama de los Casos de Uso relevantes para la arquitectura Diseño de Proceso de Negocio Nombre Actores Diseño de Proceso de Negocio Analista de negocio Versión 2.3 Pág. 89 Sinopsis El caso de uso comienza cuando el usuario analista de negocio indica al sistema que desea definir un proceso de negocios. El sistema proporciona a tales efectos, un lenguaje de alto nivel y una interfaz gráfica acorde que permiten definir el proceso. Durante la definición del proceso, el usuario puede especificar invocaciones directas: a la descripción semántica de un servicio o indirectas: mediante la especificación de un perfil de servicio deseado Transformación e Instalación de Proceso de Negocio Nombre Actores Sinopsis Transformación e Instalación de Proceso de Negocio Analista de negocio Una vez completada la definición de un proceso de negocio y obtenida la representación intermedia del mismo, el analista de negocio procede a la transformación e instalación del proceso. Para esto el sistema recibe dicha representación intermedia y un nombre para el proceso. Posteriormente, procede a realizar las transformaciones necesarias que dejen el proceso en un formato ejecutable. Finalmente, el proceso junto con los archivos necesarios para la ejecución son empaquetados y deployados en un motor de ejecución Ejecución de Proceso de Negocio Nombre Actores Sinopsis Ejecución de Proceso de Negocio Aplicación Cliente Una aplicación cliente invoca la ejecución de un proceso de negocio a través de la interfaz de servicio expuesta para tal fin. El sistema comienza la ejecución del proceso resolviendo cada una de las invocaciones a servicios especificadas. Dependiendo del tipo de invocación a resolver, y en caso de ser necesario, el sistema busca un servicio concreto que cumpla con un perfil de servicio especificado. Versión 2.3 Pág. 910 5 Vista Lógica 5.1 Introducción Se presentan en este punto los sucesivos refinamientos que definen las diferentes unidades lógicas que componen la arquitectura del Framework Batuta. El primer refinamiento realizado consiste en la descomposición en subsistemas. Los subsistemas representan cortes verticales al diseño del sistema. Cada subsistema consiste en el agrupamiento de diferentes funcionalidades relacionadas entre sí y posee la capacidad de funcionar como un sistema en sí mismo. Posteriormente se explora la composición de cada uno de los subsistemas. Finalmente se incluye la realización de los casos de uso descriptos en la sección anterior mediante los componentes arquitectónicos definidos. 5.2 Descomposición en Subsistemas La descomposición propuesta, basada en el modelo Peer to Peer, organiza la arquitectura en un conjunto de subsistemas funcionalmente cohesivos que interactúan entre sí para cumplir sus funciones. Figura 2 Principales componentes del Framework Batuta. 5.3 Descripción de los Subsistemas Definición de Procesos: Este subsistema es el encargado de proporcionar las herramientas adecuadas que le permitan al analista de negocio, diseñar de forma amigable e intuitiva el proceso de negocio. Debe permitir manipular la semántica asociada a los servicios. Finalmente, debe ser capaz de transformar la representación gráfica del proceso a una especificación intermedia del mismo que sirva de entrada para el subsistema de ejecución de procesos de negocio. Versión 2.3 Pág. 1011 Ejecución de Procesos: Tomando como entrada la representación intermedia de un proceso de negocio, realiza una serie de transformaciones que la llevan a una representación ejecutable. Este subsistema se encarga de la transformación instalación y ejecución del proceso de negocio y utiliza los servicios del subsistema Resolución de Servicios para la invocación de los servicios requeridos por el proceso. Resolución de Servicios: Se encarga de la resolución de un servicio especificado mediante una descripción semántica. La resolución implica la búsqueda y selección del servicio concreto que mejor se adapte al perfil de servicio requerido, y la ejecución del mismo utilizando los parámetros proporcionados. 5.4 Diseño de Subsistemas Definición de Procesos El diseño de este subsistema quedó fuera del alcance del proyecto. Se prescinde del mismo recurriendo a una herramienta externa para la implementación del framework. La salida del trabajo de este subsistema es una representación intermedia del proceso de negocio como se detalla en [3]; dicha representación intermedia es entrada del subsistema Ejecución de Procesos que se describe a continuación Ejecución de Procesos El subsistema Ejecución de Procesos tiene dos grandes componentes como puede verse en la figura 3. Figura 3 Componentes del Subsistema Ejecución de Procesos. Bpm es el componente principal del subsistema. Se encarga de dos tareas fundamentales: la transformación de la entrada: una representación intermedia del proceso de negocio a una representación ejecutable del mismo, y la ejecución del proceso de negocio a partir de la representación ejecutable obtenida en el paso anterior. Durante la ejecución del proceso, el componente recurre al subsistema Resolución de Servicios para resolver las invocaciones a servicios incluidas en el proceso. El resultado de la resolución de un servicio puede ser una ontología; dentro de esta ontología pueden estar contenidos elementos a ser utilizados como resultados intermedios del proceso con los que se precise hacer algún cálculo o ser entrada de una nueva invocación a un servicio. El componente Query es utilizado por Bpm precisamente para consultar una Versión 2.3 Pág. 1112 ontología en busca de un elemento (o conjunto de elementos) en particular. Por tal motivo, debe utilizarse un lenguaje de consulta desarrollado para tales fines. En la sección se presenta un caso concreto que ejemplifica el funcionamiento y cometido del componente Diseño detallado del subsistema. Componente Bpm. Bpm está integrado por tres módulos tal cual se muestra en la figura 4. Figura 4 Diseño del componente Bpm. Transformer: recibe la representación intermedia de un proceso de negocio y genera un archivo con la representación ejecutable del mismo. Installer: se encarga de tomar la representación ejecutable de un proceso de negocio, resultado del trabajo del módulo Transformer, y dejarla disponible en un motor de ejecución de procesos de negocio de forma que pueda ser ejecutada. Execution Engine: este módulo representa el motor de ejecución de procesos de negocio; los procesos son deployados dentro de este componente y se hacen accesibles para ser ejecutados generando una interfaz para cada uno de ellos; en general son expuestos en forma de web service. La figura 5 presenta la interfaz del componente Bpm y sus subcomponentes. Figura 5 Interfaces componente Bpm. IBpm o o transformandinstall: a partir de la representación intermedia de un proceso y el nombre del mismo se encarga de dejarlo disponible para ser ejecutado; para ello utiliza las operaciones transform de ITransformer e install de IInstaller. uninstallprocess: a través de esta operación se dan de baja procesos disponibles en el motor de ejecución; utiliza la operación uninstall de IInstaller. Como se menciona anteriormente la ejecución de un proceso de negocio se realiza accediendo a la interfaz del mismo expuesta por el motor de ejecución. Por este motivo es que no se encuentra una operación de ejecución en las interfaces presentadas en la figura 5. Versión 2.3 Pág. 1213 5.4.3 Resolución de Servicios La composición del subsistema Resolución de Servicios se muestra en la figura 6. Figura 6 Componentes del Subsistema Resolución de Servicios. El componente Resolver recibe las solicitudes de resolución de servicios y utiliza los componentes Finder, Selector e Invoker para resolver dichos pedidos. Finder recibe como entrada una descripción semántica de las características del servicio buscado y se encarga de hallar servicios concretos que cumplan con tales características. Para ello debe poder acceder a un repositorio de servicios sobre los cuales consultar y contar con una herramienta que resuelva el macheo semántico deseado: especificación semántica del servicio general buscado vs. descripción semántica de las características de cada uno de los servicios concretos. El resultado del trabajo de este componente es una lista de servicios que machean la especificación semántica indicada. La determinación de si un servicio machea una determinada descripción semántica se resuelve mediante un algoritmo que evalúa de acuerdo a una serie de criterios si existe la correspondencia y en que grado. Es decir que existen diferentes grados de macheo. Por este motivo la lista antes mencionada adjunta a cada servicio hallado un indicador del grado de correspondencia obtenido. El algoritmo y los criterios de macheo dependen del lenguaje de descripción semántica de servicios y la herramienta de resolución de macheo utilizados. Un caso concreto se detalla en [5]. Selector se encarga de seleccionar uno de los servicios de la lista devuelta por el componente Finder. El servicio escogido depende de determinados criterios que puedan haberse especificado en el pedido de resolución de servicio (como ser aspectos de calidad) o definidos en el componente Selector. El criterio inmediato es el de escoger el servicio con mayor grado de macheo pero podrían utilizarse otros más complejos que implicaran una revisión más profunda de la lista de resultados; el aspecto de calidad de servicio antes mencionado es un ejemplo. Una vez seleccionado el servicio adecuado debe procederse a la invocación del mismo. El encargado de resolver dicha tarea es el componente Invoker. Para ello recibe la especificación semántica del servicio seleccionado junto con los parámetros de invocación. La especificación semántica contiene toda la Versión 2.3 Pág. 1314 información requerida para ejecutar el servicio incluyendo los parámetros de entrada que son instanciados con los valores recibidos Diseño detallado del subsistema. La presenta las interfaces del subsistema. Revisando las operaciones definidas puede verse la realización de lo descrito en la sección anterior. A continuación se repasa cada una de estas operaciones centrando la descripción en los parámetros y tipos de datos manejados. Figura 7 Interfaces Subsistema Resolución de Servicios. resolve: es la operación que dispara la resolución de un servicio. Es invocada por el subsistema Ejecución de Procesos, en particular por el componente Execution Engine según se explica en la sección Recibe como parámetro de entrada un objeto IServiceResolveRequest. La forma de este objeto podrá variar de acuerdo al lenguaje empleado para el manejo semántico de los servicios pero sustancialmente debe contener la descripción semántica del servicio a resolver y los parámetros de invocación. El resultado de esta operación se encapsula en un objeto de tipo IServiceResolveResponse el cual contiene los parámetros de retorno del servicio invocado y el objeto IServiceResolveRequest con el que se realizó la invocación. find: se encarga de hallar el conjunto de servicios que macheen el perfil de servicio deseado. A partir de un parámetro de tipo URI que indica dónde se halla la ontología que describe el tipo de servicio requerido, consulta el repositorio de servicios en busca de los que macheen el perfil y retorna en un objeto de tipo IFinderResultList la lista de servicios obtenida y el grado de macheo de cada servicio. Notar que el parámetro de entrada ServiceProfile que se emplea en esta operación es parte del contenido del objeto IServiceResolveRequest con el cual se invoca la operación resolve. select: se encarga de seleccionar el servicio a invocar de los incluidos en el objeto IFinderResultList devuelto por la función find. El criterio para seleccionar el servicio se representa mediante un objeto ISelectCriterion, el cual permite la parametrización de la selección en caso de que el componente que implemente ISelector así lo permita. El resultado de esta operación es el servicio elegido representado por un objeto IFinderResult; es decir, un elemento de la lista resultlist recibida como entrada. invoke: mediante esta operación se ejecuta el servicio seleccionado en los pasos previos. Como parámetros de entrada recibe una URI apuntando a la ontología Versión 2.3 Pág. 1415 que describe el servicio seleccionado y la lista de parámetros de invocación. La URI es parte del contenido del objeto IFinderResult devuelto por el componente Selector, mientras que la lista de parámetros es parte del contenido del objeto IServiceResolveRequest con el cual se invoca la operación resolve. El resultado de la operación se encapsula en un objeto de tipo ValueMap el cual contiene una lista de parejas que representan un parámetro de retorno del servicio y su respectivo valor. 5.5 Realización de los Casos de Uso Relevantes para la Arquitectura Diseño de Proceso de Negocio La realización del caso de uso queda a cargo del subsistema Definición de Procesos. Figura 8 Realización del caso de uso Diseño de Proceso de Negocio. Como se mencionó anteriormente el diseño de dicho subsistema no está dentro del alcance del proyecto por lo que no es posible profundizar en la realización del caso de uso Transformación e Instalación de Proceso de Negocio La realización del caso de uso queda a cargo del subsistema Ejecución de Procesos. Figura 9 Realización del caso de uso Transformación e Instalación de Proceso de Negocio. Profundizando en el diseño del subsistema Ejecución de Procesos de acuerdo a lo desarrollado en la sección , se presenta en la figura 10 la realización del caso de uso por parte del componente Bpm. Figura 10 Realización del caso de uso Transform. e Instal. de Proc. de Negocio nivel 2. Bajando un paso más en el nivel de abstracción, la presenta la realización del caso de uso por parte de los subcomponentes del componente Bpm. Versión 2.3 Pág. 1516 Figura 11 Realización del caso de uso Transform. e Instal. de Proc. de Negocio nivel 3. Finalmente, se incluye el diagrama de secuencia que describe la interacción ente los componentes para realizar el caso de uso en cuestión. La figura 12 presenta dicho diagrama. Figura 12 Diagrama de secuencia realización CU Transform. e Instal. de Proc. de Negocio. El componente Bpm recibe el pedido de transformar e instalar un proceso mediante la operación transformandinstall. A partir de ello, solicita la transformación al componente Transformer y una vez completada dicha acción solicita la instalación al componente Installer el cual deja el proceso disponible para ejecutar en el Execution Engine Ejecución de Proceso de Negocio La realización del caso de uso queda a cargo del subsistema Ejecución de Procesos el cual utiliza para cumplir tal función el subsistema Resolución de Servicios. Bajando en el nivel de abstracción, se presenta en las figuras 14 y 15 la realización del caso de uso de acuerdo a los componentes presentados en las secciones y Versión 2.3 Pág. 1617 Figura 13 Realización del caso de uso Ejecución de Proceso de Negocio. Figura 14 Realización del caso de uso Ejecución de Proceso de Negocio nivel 2. Figura 15 Realización del caso de uso Ejecución de Proceso de Negocio nivel 3. Finalmente se incluye el diagrama de secuencia que describe la interacción ente los componentes para realizar el caso de uso en cuestión. La figura 16 presenta dicho diagrama. Versión 2.3 Pág. 1718 Figura 16 Diagrama de secuencia realización CU Ejecución de Proceso de Negocio. El diagrama grafica lo explicado en la sección La interacción se presenta simplificada de forma de ganar claridad en la descripción. A través de la interfaz expuesta por el motor de ejecución para acceder a cada proceso, se invoca la ejecución de un determinado proceso. Dicha ejecución implica, en el caso general, la resolución de servicios, lo cual se solicita al componente Resolver mediante la operación resolve. Resolver utiliza IFinder para obtener la lista de servicios que machean la descripción semántica del servicio a resolver, representada por el parámetro frl en el diagrama. Con esta lista se invoca la operación select de ISelector para escoger el servicio adecuado, el cual es invocado posteriormente utilizando el componente Invoker. El resultado de la resolución del servicio es devuelto al componente Execution Engine el cual eventualmente podría requerir acceder a algún parámetro en particular del resultado para lo cual utiliza el componente Query. Versión 2.3 Pág. 1819 6 Vista de Deployment 6.1 Introducción Está sección describe una o más configuraciones físicas sobre las cuales se realiza el deploy del software y es ejecutado, así como la infraestructura necesaria para su instalación. Para el caso del Framework Batuta se describe el escenario general de distribución esperado para los componentes de software antes descritos, las características de los nodos presentados y la comunicación entre los mismos. 6.2 Distribución y Deployment La figura 17 presenta el escenario de distribución esperado para la instalación del framework. El mismo se ubica en el contexto de una organización, sobre una LAN privada y se prevé el acceso vía Internet a un repositorio de servicios. Figura 17 Escenario de distribución A continuación se describen los nodos presentes en la figura: Servidor BPM: representa el equipo donde correrá el subsistema Ejecución de Procesos. Por tanto, se ejecutan aquí las funcionalidades de transformación e instalación de procesos de negocio así como el motor de ejecución de procesos. Tales servicios son expuestos mediante respectivas interfaces web service. PC Analista de Negocios: representa la estación de trabajo de un usuario analista de negocio. En este nodo correrá el subsistema Definición de Procesos. Se comunica con el Servidor BPM para la transformación e instalación del proceso definido; la comunicación es vía SOAP a través de la interfaz web service expuesta por dicho nodo. Cliente de Proceso de Negocio: representa el equipo donde corre una aplicación cliente que desea ejecutar un proceso de negocio disponible en el Servidor BPM. No hay Versión 2.3 Pág. 1920 componentes del framework corriendo en este nodo. Los procesos son ejecutados invocando el web service publicado para cada uno de ellos. Servidor Resolución de Servicios: representa el equipo donde correrá el subsistema Resolución de Servicios. Recibe pedidos del motor de ejecución de servicios corriendo en el Servidor BPM. La comunicación es nuevamente a través de una interfaz web service. Repositorio de Servicios: representa un equipo donde se mantendrá un registro de servicios disponibles a los cuales podrá acceder el subsistema Resolución de Servicios para buscar los servicios adecuados para una determinada solicitud. Podría existir más de una instancia de este nodo a la cual acceder. Las interfaces de comunicación previstas para los nodos, basadas en web services, posibilitan plantear múltiples escenarios de distribución y permiten el planteo de una infraestructura multiplataforma. Versión 2.3 Pág. 2021 7 Arquitectura del Sistema Batuta 7.1 Introducción Sobre la base arquitectónica presentada, se describe a continuación la arquitectura del Sistema Batuta realizado como prototipo prueba de concepto del Proyecto Batuta. Dicho sistema puede verse como una realización particular del framework general desarrollado y fue construido a partir de la integración de diferentes tecnologías y herramientas presentes en el área de investigación abarcada. La descripción se organiza repasando las vistas presentadas anteriormente, detallando en cada una de ellas como se resolvió la realización de los componentes definidos, que componentes de infraestructura, tecnologías, herramientas y lenguajes se utilizaron. La vista de casos de uso claramente no aplica en esta descripción puesto que no hay nada que haya debido adaptarse respecto a los requerimientos en la solución desarrollada. El Sistema Batuta es una solución particular al problema general planteado y fue construido sobre la arquitectura del framework la cual fue guiada por los casos de uso presentados. Se considera prudente repasar los siguientes puntos para entender el resto del desarrollo de la sección: El lenguaje de modelado de procesos utilizado es BPMN. El lenguaje de ejecución de procesos utilizado es BPEL. El lenguaje de representación semántica de conceptos utilizado es OWL. El lenguaje de descripción semántica de web services utilizado es OWL-S. Los fundamentos de estas decisiones pueden hallarse en Descripción del Modelo Batuta [3] y los conceptos clave de cada lenguaje pueden consultarse en el documento Estado del Arte [4]. 7.2 Vista Lógica La figura 18 presenta una vista global de los subsistemas del framework y las herramientas externas que se utilizaron para lograr cumplir los cometidos definidos para cada subsistema Subsistema de Definición de Procesos Como se menciona en la sección el diseño de este subsistema no está dentro del alcance del proyecto. Para resolver este aspecto se recurrió a la utilización de una herramienta externa. Dada la tarea a cumplir por este subsistema se requería una herramienta que permitiera el modelado de procesos de negocios de forma clara e intuitiva y la posibilidad de manejar aspectos de semántica referidos a los servicios involucrados en el proceso. Ante la no disponibilidad de una herramienta que soportara de forma nativa el manejo de representaciones semánticas (OWL y OWL-S), se recurrió a la utilización de un producto de modelado de procesos de negocio, integrando los aspectos semánticos a través de referencias a ontologías manejadas como parámetros de invocación o retorno de los servicios invocados. Versión 2.3 Pág. 21 Mostrar más
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 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 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 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 Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta
Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración Más detalles DISEÑO DE COMPONENTES DE SOFTWARE *
DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE. Más detalles 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 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 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 Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com
EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización Más detalles SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO
SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3 Más detalles Management(BPM) Gestión de Proceso de negocio con BPM. Universidad Inca Garcilaso de la Vega
Universidad Inca Garcilaso de la Vega CURSO DE ACTUALIZACIÓN PROFESIONAL DE INGENIERÍA DE SISTEMAS Y CÓMPUTO Business Process Business Process Management(BPM) Management(BPM) MSc. Daniel Alejandro Yucra Más detalles Gestión de Procesos de Negocios BPM
GNU/LinuX Universidad Inca Garcilaso de la Vega XLIX CURSO DE ACTUALIZACIÓN PROFESIONAL DE INGENIERÍA DE SISTEMAS Y CÓMPUTO. Área: Gestión Gestión de Procesos de Negocios BPM Parte III: BPM Aspectos Técnicos Más detalles HOJA TÉCNICA. SemTalk 2
HOJA TÉCNICA SemTalk 2 SemTalk 2 - Información Técnica SemTalk 2 es una herramienta para modelamiento de procesos de negocios y conocimientos orientado a objetos 100% compatible con MS Office. REQUERIMIENTOS Más detalles DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI
DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI Informe de Práctica Profesional de 4to Año, Ingeniería Informática Autor: Manuel Alejandro Aguilar Díaz Más detalles 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 Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3. Historia de revisiones
Proyecto Help Desk en plataforma SOA Especificación de Requerimientos de Software para la Plataforma Link-All Versión 1.3 Historia de revisiones Fecha Versión Descripción Autor 17/08/2005 1.0 Se hace la Más detalles 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 SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB]
Gobierno Municipal del Cantón Bolívar. SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Visión Universidad Técnica del Norte Histórico de Revisiones Más detalles Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar
Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Caso de Desarrollo Universidad Técnica del Más detalles 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 GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.
GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio. Más detalles 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 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 COMPONENTES DE SERVICIOS WEB A PARTIR DE SERVICIOS EN UDDI: VERSIÓN EXTENDIDA. Instituto Tecnológico de Nogales (ITN)
COMPONENTES DE SERVICIOS WEB A PARTIR DE SERVICIOS EN UDDI: VERSIÓN EXTENDIDA 1 Ismael Armando Zúñiga Félix y 2 Luicyana Pérez Figueroa 1,2 División de Estudios de Posgrado e Investigación (DEPI), Instituto Más detalles Historia de revisiones Fecha Versión Descripción Autor 12/11/2011 4.0 Versión final con cambios sobre extensión de ArcGIS Viewer y recorte de alcance
EXAV Descripción de la Arquitectura Versión 4.0 Historia de revisiones Fecha Versión Descripción Autor 12/11/2011 4.0 Versión final con cambios sobre extensión de ArcGIS Viewer y recorte de alcance Enrique Más detalles Desarrollo de Software con enfoque en el Negocio
Desarrollo de Software con enfoque en el Negocio Andrea Delgado Instituto de Computación Facultad de Ingeniería Universidad de la República 11300, Montevideo, Uruguay adelgado@fing.edu.uy Resumen Las Organizaciones 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
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 5/09/2012 2.1 Agregar cambios en las alertas Matias Herrera
K2BProyectos Móvil Descripción de la Arquitectura Versión 1.5 Historia de revisiones Fecha Versión Descripción Autor 24/08/2012 1.0 Comienzo de la versión Milagros Garicoits 25/08/2012 1.0 Se corrigen Más detalles Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:
PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo 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 Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1 Más detalles Facultad de Ingeniería Informática. Informe de las Prácticas Profesionales
Facultad de Ingeniería Informática CEIS Informe de las Prácticas Profesionales Título: Informatización de los Procesos de Negocio Solicitud de Trabajo Extra laboral en el CITI, a través de la BPMS BizAgi Más detalles Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1
Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir Más detalles JAVA ENTERPRISE EDITION (J2EE) ARQUITECTURA TECNOLOGÍAS (1/2) (L1)
TECNOLOGÍAS (1/2) (L1) EJB ( Enterprise Java Beans ) JSP ( Java Server Pages ) JNDI ( Java Naming and Directory Interface ) JDBC ( Java Data Base Connectivity ) Java Mail JSF ( Java Server Faces ) TECNOLOGÍAS Más detalles Muestra de solicitud para una propuesta de un conjunto de aplicaciones de Gestión de Procesos de Negocio KIT DE HERRAMIENTAS DEL COMPRADOR DE BPMS
KIT DE HERRAMIENTAS DEL COMPRADOR DE BPMS Muestra de solicitud para una propuesta de un conjunto de aplicaciones de Gestión de Procesos de Negocio Parte 1 del kit completo de herramientas del comprador Más detalles 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 Tema 5. Plataforma Java EE
Tema 5. Plataforma Java EE SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs enero 2009 FJRP, FMBR 2008/09 ccia SCS 5.1 Introducción a Java EE Java EE (Java Enterprise Más detalles 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 Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar
Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad Más detalles Notas técnicas de JAVA Nro. 7 Tip Breve
Notas técnicas de JAVA Nro. 7 Tip Breve (Lo nuevo, lo escondido, o simplemente lo de siempre pero bien explicado) Tema: JAVA Basics: Diferencias conceptuales entre JavaBeans y Enterprise JavaBeans (EJB) 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 Í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 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 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 Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software
Desarrollo de una arquitectura orientada a servicios para un prototipo de una línea de productos de software Ramón Gómez-Romero, Karen Cortés Verdin, Juan Carlos Pérez Arriaga, Ángeles Arenas Valdés Universidad Más detalles DESCRIPCIÓN FUNCIONAL API XBRL-PGC2007
DESCRIPCIÓN FUNCIONAL API XBRL-PGC2007 ADAPTACIÓN DEL MÓDULO DE SOFTWARE DE TRATAMIENTO DE INFORMES XBRL A LA NUEVA VERSIÓN DE LA TAXONOMÍA PGC2007 (V1.4.1) Noviembre 2011 ÍNDICE 1. INTRODUCCIÓN 2. DESCRIPCIÓN Más detalles Aplicaciones web construidas a base de componentes:
Java EE Aplicaciones Web/Sistemas Web Juan Pavón Mestras Dep. Ingeniería del Software e Inteligencia Artificial Facultad de Informática Universidad Complutense Madrid Material bajo licencia Creative Commons 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 Sumario Introducción Arquitectura en n-capas Arquitectura y el Cuarto Examen Java y su modelo Más detalles JavaEE. www.javasoft.com
JavaEE Java Enterprise Edition www.javasoft.com Por qué Java en el servidor? Ventajas Independencia de la plataforma portabilidad Gran conjunto de APIs Reusabilidad y modularidad Seguro en la ejecución Más detalles Tema 5. Plataforma Java EE
Tema 5. Plataforma Java EE SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs septiembre 2011 FJRP, FMBR 2008-2011 ccia SCS 5.1 Introducción a Java EE Java EE (Java Enterprise Más detalles 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 Herramienta de Gestión Integral de E-Business
Herramienta de Gestión Integral de E-Business Ingeniería técnica de informática de sistemas Autor: David López Martín Tutor: Antoni Oller Arcas Índice Introducción Metodología Análisis Diseño Planificación Más detalles Web Service de Calidad de datos identificativos
Web Service de Calidad de datos identificativos Autor: AEAT Fecha: 27/11/2015 Versión: 1.0 Revisiones Edi. Rev. Fecha Descripción A(*) Páginas 1 0 27/11/2015 Versión inicial A Todas (*) Acción: A= Añadir; Más detalles Analista Programador Java: Business Apps Expert
Analista Programador Java: Business Apps Expert TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Analista Programador Java: Business Apps Expert Duración: Más detalles 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 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización
Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización Más detalles Taller de Sistemas de Información 3. Presentación SCA
Taller de Sistemas de Información 3 Presentación SCA Integrantes: Gustavo Fava Diego Salido Marcos Techera agosto de 2008 TSI 3 1 Introducción a SCA Aplicación: conjunto de componentes de software trabajando Más detalles Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas
Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a Más detalles BASES DE DATOS. Ivon Tarazona Oriana Gomez
BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos Más detalles Programación generativa
ujuarez@itorizaba.edu.mx Instituto Tecnológico de Orizaba 15 de octubre de 2010 Agenda 1 Introducción Panorama general Problemática 2 Implementación generativa Bibliotecas activas Bibliotecas activas: Más detalles SOR -::- Prácticas -::- Curso 06/07
SOR Introducción a Se trata de un mecanismo relativamente nuevo que nos permite llamadas remotas a métodos a través de HTTP mediante el uso de protocolos y lenguajes basados en XML. Los nos ofrecen una Más detalles Entidad Formadora: Plan Local De Formación Convocatoria 2010
Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú Más detalles TEMA 5. Otras arquitecturas distribuidas IV. Web Services
TEMA 5. Otras arquitecturas distribuidas IV. Web Services IV. Web Services 1. Qué son los Web Services? 2. Ejemplos de Web Services 3. Tecnologías y arquitectura 3.1. Arquitectura 3.2. Lenguaje de descripción: Más detalles OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento
OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje Más detalles WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8
WebRatio Otro camino para el BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 El BPM El BPM (Business Process Management) no es solo una tecnología, además a grandes rasgos es una disciplina Más detalles PROGRAMACIÓN DE SISTEMAS INFORMÁTI- COS
IFCT0609: PROGRAMACIÓN DE SISTEMAS INFORMÁTI- COS CÓDIGO ESPECIALIDAD C.P. PRESEN- CIALES TELEFORMA- CIÓN TOTALES TIPO DE FORMACIÓN IFCT0609 PROGRAMACIÓN DE SISTE- MAS INFORMÁTICOS SI 210 210 420 SEMIPRESENCIAL Más detalles Software Design Description Caracterización de la comunidad. 06/07/2012 Fabián García Ariel López
Software Design Description Caracterización de la comunidad 06/07/2012 Fabián García Ariel López PAGINA DE FIRMAS ALEX LINARES CLIENTE FABIÁN GARCÍA ARIEL LÓPEZ LESMES HISTORIAL DEL CAMBIOS Versión Fecha Más detalles 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 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 Herramientas de Software que posibilitan el BPM
Una propuesta arquitectónica para integrar una herramienta BPMS y un sistema de gestión de reglas de negocio Parra Julián Matias 1, Mg. Patricia Bazán 2, Lic. José Martinez Garro 3 1 3 Facultad de Informática Más detalles Ingeniería de Software II Segundo Cuatrimestre 2007
Ingeniería de Software II Segundo Cuatrimestre 2007 Clase 4 Parte 1: Introducción a las Arquitecturas de Software Buenos Aires, 3 de Septiembre de 2007 Diagramas de ejemplo Analizando dibujitos Banco 3 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 Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta Más detalles Servicios Web: Orquestación y coreografías
Servicios Web: Orquestación y coreografías E. U. I. T. en Informática de Oviedo Master de Ingeniería Web Servicios Web Juan Ramón Pérez Pérez (jrpp en uniovi.es) Orientación a Servicios. Principios. Los Más detalles 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 Instructivo para la elaboración de un Manual Técnico
Instructivo para la elaboración de un Manual Técnico Autora: Ing. Alena González Reyes. (agonzalez@ceis.cujae.edu.cu) Ciudad de la Habana, Cuba Marzo, 2010 Índice 1. Introducción... 3 2. Confección... Más detalles SIS TPV VIRTUAL WEBSERVICE
SIS TPV VIRTUAL WEBSERVICE Versión: 2.0 26/09/2013 Referencia RS.OP.PRO.MAN.0008 Versión: 2.0 1 Autorizaciones y control de versión La propiedad intelectual de este documento pertenece a Redsys. Queda Más detalles Especificación Técnica del WebService de Autenticación y Autorización
Especificación Técnica del WebService de Autenticación y Autorización Índice de contenido Introducción...3 Propósito...3 Descripción General del Servicio...3 Referencias...4 Invocación del WSAA...4 Sincronización Más detalles 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)
3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial. Más detalles Manual de integración con el TPV Virtual para comercios con conexión por Web Service
Manual de integración con el TPV Virtual para comercios con conexión por Web Service Versión: 1.6 Versión: 1.6 i Autorizaciones y control de versión Versión Fecha Afecta Breve descripción del cambio 1.0 Más detalles Notas técnicas de SAP / ABAP - Tip en detalle Nro. 16
Notas técnicas de SAP / ABAP - Tip en detalle Nro. 16 (Lo nuevo, lo escondido, o simplemente lo de siempre pero bien explicado) Los nuevos escenarios de programación con SAP Netweaver (serie de varios Más detalles Workflow, BPM y Java Resumen de la presentación de Tom Baeyens
Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Página 1 de 11 1. Introducción Tom Baeyens es el fundador y arquitecto del proyecto de JBoss jbpm, la máquina de workflow Más detalles SERVICIOS: EXPLORACIONES EN SOA y WEB.
SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería. Más detalles Guía de migración a firma HMAC SHA256 Conexión por Web Service
Guía de migración a firma HMAC SHA256 Conexión por Web Versión: 1.4 Versión: 1.4 i Autorizaciones y control de versión Versión Fecha Afecta Breve descripción del cambio 1.0 16/10/2015 Versión inicial del Más detalles Especificación Técnica del Web Service de Autenticación y Autorización WSAA Para el desarrollo de Clientes de Entidades Externas
Servicio Nacional de Aduanas Subdirección de Informática Departamento de Desarrollo de Sistemas Especificación Técnica del Web Service de Autenticación y Autorización WSAA Para el desarrollo de Clientes Más detalles Comparación del entorno IBM Websphere BPM y sus equivalentes funcionales en código fuente abierto.
Comparación del entorno IBM Websphere BPM y sus equivalentes funcionales en código fuente abierto. 2 José Martinez Garro 1 Patricia Bazán 2 Emilio Lorenzón 1 LINTI Facultad de Informática UNLP 2 Facultad Más detalles Curso de Java EE Todos los Derechos Reservados Global Mentoring 2012 Experiencia y Conocimiento para tu Vida 1
Todos los Derechos Reservados Global Mentoring 2012 Experiencia y Conocimiento para tu Vida 1 Vivimos en un mundo globalizado, donde la eficiencia y productividad de las empresas es un factor crucial para Más detalles Figure 7-1: Phase A: Architecture Vision
Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como Más detalles Certificaciones: Diploma de Aprobación en Desarrollo Web con Java.
DIPLOMATURA EN DESAR ROLLO DE APLICACIONE S WEB CON JAVA PARTE I: OBJETIVOS ESPECÍFICOS La Diplomatura en Desarrollo de Aplicaciones Web con Java tiene los siguientes objetivos específicos: Adquirir habilidad Más detalles Rational Unified Process (RUP)
Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP Más detalles OpenESB FEMI Sofis Solutions - PMA
OpenESB FEMI Sofis Solutions - PMA Página 1 de 22 1 BPMS... 3 1.1 Introducción... 3 1.2 Modelado de Procesos... 5 1.2.1 Editor Gráfico de Procesos... 5 1.2.2 Gestión de Tareas... 6 1.2.3 Interacción Humana... Más detalles Proyecto Help Desk en plataforma SOA Glosario Versión 1.3. Historia de revisiones
Proyecto Help Desk en plataforma SOA Glosario Versión 1.3 Historia de revisiones Fecha Versión Descripción Autor 18/08/2005 1.0 Terminología a utilizar en este proyecto. 22/08/2005 1.1 Se agregaron los Más detalles Tabla de contenido 1. OBJETIVOS... 2 2. ASIGNACION DE RESPONSABILIDADES... 2 3. ROLES Y TAREAS... 3 4. ALCANCE... 4
Tabla de contenido 1. OBJETIVOS... 2 2. ASIGNACION DE RESPONSABILIDADES... 2 3. ROLES Y TAREAS... 3 4. ALCANCE... 4 5. PROCEDIMIENTOS RELACIONADOS... 4 6. DOCUMENTOS RELACIONADOS... 4 7. PROCESO... 4 7.1. Más detalles Bienvenidos a la presentación: Introducción a conceptos básicos de programación.
Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los Más detalles Cómo lograr una implementación exitosa de SOA?
Software Huibert Aalbers Certified Executive Software IT Architect BUE Technical Sales, SW Services Manager IBM de Mexico 2007 IBM Corporation Agenda!Interoperabilidad! De dónde viene SOA?!Las distintas Más detalles 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 Manual de Desarrollador Autenticación Automática
Manual de Desarrollador Autenticación Automática OI2007_AUTAUTOM_MDE_1.9 Subdirección Informática Servicio Impuestos Internos Fecha:18/11/2007 INTRODUCCIÓN... 5 CAPÍTULO 1... 6 ANÁLISIS DEL SISTEMA...6 Más detalles DIPLOMATURA DESARROLLO DE APLICACIONES JAVA
DIPLOMATURA DESARROLLO DE APLICACIONES JAVA Contenidos MÓDULO UNO: Características del Lenguaje. OOP Reconocer las características del lenguaje Java y sus componentes. Distinguir la similitudes y diferencias Más detalles Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases
3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología Más detalles Service Oriented Architecture
Programación Concurrente y Distribuida Ingeniería en Informática Service Oriented Architecture José Carlos Cortizo Pérez josecarlos.cortizo@uem.es http://www.esp.uem.es/jccortizo D. Sistemas Informáticos Más detalles 2017 © DocPlayer.es Política de privacidad | Condiciones del servicio | Feedback

References: Resolución 
 Resolución 
 Resolución 
 Resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 Resolución 
 Resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 Resolución 
 resolución 
 Resolución 
 resolución 
 resolución 
 Resolución 
 Resolución 
 Resolución