Xavier S. Medianero P.

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

Download "Xavier S. Medianero P. xavier.medianero@utp.ac.pa"

Transcripción

1 Metodología para el Soporte del Diseño de Framework Basados en Programación Orientada a Aspectos Methodology to Support the Design of Framework based on Aspect Oriented Programming. Xavier S. Medianero P. Universidad Tecnológica de Panamá Facultad de Ingeniería de Sistemas Computacionales xavier.medianero@utp.ac.pa RESUMEN Este trabajo presenta una propuesta sobre una metodología para el soporte del proceso de generación de frameworks basado en programación orientada a aspectos y una herramienta de apoyo para diagramar, interrelacionar, analizar y diseñar el sistema de clases y aspectos del framework para su posterior migración a código Java. La metodología incluye elementos que minimizan inconvenientes de la Programación orientada a aspectos como los estructurales, de comportamiento, por multifuncionalidad y de dinamismo. La metodología pretende minimizar los esfuerzos en la determinación de Puntos de Corte o Puntos de Unión de aspectos, al igual que incrementar la cohesión de las clases, componentes y aspectos, en conjunto con la implementación de una capa semántica superior para una mayor abstracción de concepto en el desarrollo de frameworks basados en Aspectos. ABSTRACT This paper is an approach about a methodology to support the process of generation of framework based on aspect oriented programming and a support tool for diagramming, interrelate, analize and design the classes and aspects sets of the framework for future migration to Java code. The methodology includes elements that minimize the disadvantages of aspect-oriented programming such a structural, behavior, dynamism and multifunctionality. The methodology seeks to minimize the efforts in determining the cut-point and join-point issues, as well as increasing the cohesion of classes, component and aspects together with the implementation of a superior semantic layer to greater abstraction of concept in the development of framework based on aspects. Categories and Subject Descriptors D.2.1 (Software Engineering): Requirements/Specifications Methodologies & Tools. General Terms Design, Management, Documentation, Performance. Keywords Framework, Aspect Oriented Programming, AspectJ, Join-Point Model, Weaving Model. Palabras Claves Framework, Programación Orientada a Aspectos, AspectJ, Modelo Join-Point, Modelo Weaving. 1. INTRODUCCIÓN Los Frameworks son generadores de aplicación hacia un dominio específico [1]. Los framework contienen módulos, métodos y características de software cuya función es ser un molde para aplicaciones que se deriven del mismo, es decir, que utilicen el mismo núcleo y estén cubiertas por un área específica. Los frameworks están compuestos por dos secciones: el núcleo conocido como los puntos congelados, que representan las clases, librerías, métodos y módulos que son iguales y que sirven como base para todas las aplicaciones, es decir la parte inmutable e invariable del framework, en otras palabras, todas las aplicaciones generadas por este framework tendrán las mismas características base guardadas en esta capa. La segunda sección son las ranuras conocidas como los puntos calientes, que representan los elementos que pueden adaptarse, agregarse o simplemente prescindir de ellos en la aplicación, puede imaginarse como un checklist donde se eligen los métodos extras que debe tener la aplicación, los elementos en las ranuras no deben ser obligatorios para el funcionamiento del framework [1]. Existen varios paradigmas utilizados en la elaboración de estos frameworks, dentro de los cuales se encuentra la orientación a objetos, a aspectos, a servicios, entre otros. El modelado de aspectos toma en consideración dos aspectos según [2]: modelos dinámicos que tratan los eventos y la traza de eventos y los modelos estáticos que ocupa los puertos de aspectos y el tipo de mensaje. La utilización de frameworks basados en orientación a aspectos (Fb-AOP) presenta ventajas sobre las otras arquitecturas debido a que permite: Encapsular la abstracción de los aspectos Incnrementa la reusabilidad logrando mayor separación de conceptos. Integra los elementos del núcleo con las propiedades y métodos de las ranuras que están en función de los aspectos.

2 Mejora el diseño del framework del software. Maximiza la flexibilidad del prototipo. Facilita la configuración de los puntos calientes en base a aspectos que son generalmente módulos que contienen las reglas del negocio. La AOP presenta algunos problemas prácticos [3] como lo son los conflictos estructurales debidos a un frágil Punto de Corte (normas que regulan los Join-Point), en otras palabras, el modelo basado en Join-Point tiene ligeros problemas al momento de definir los Puntos de Corte cuando el código se ha expandido, ya que este depende de la estructura base de cómo fue programado el software causando que la evolución y expansibilidad del código sea dificultoso; conflictos de comportamiento que radican en la determinación exacta del lugar en donde deben ser ubicados los Join-Point, este problema fue tratado por el Modelo Conceptual [3]. Otros inconvenientes de la AOP radican en el posible mal funcionamiento de la aplicación con referencia al framework original causado por la adición de nuevos aspectos en el mismo, además de agregar otros comportamientos diferentes a los esperados en el flujo de instrucciones del framework [4]. Conflictos multifuncionales, presentes cuando un módulo presenta diferentes funcionalidades y es difícil de conceptualizar. La flexibilidad de los frameworks radica en que la estructura de la AOP permite interferir en las llamadas de los métodos tanto antes de su ejecución, durante el proceso o después del mismo, esta flexibilidad es proporcionada por los Join-Point (puntos de función: lugar donde los aspectos pueden ser colocados) puesto el Fb-AOP está diseñado enfocado hacia el control y manejo de estos Join-Point. El proyecto permitirá recopilar las ventajas de los Fb-AOP en una metodología que suprimirá mediante la aplicación de adaptaciones de estas técnicas, las principales desventajas del enfoque a AOP. Dentro de las mayores limitaciones del enfoque AOP tenemos que la selección de aspectos está basada en el código, es decir, depende de las características del lenguaje de programación: llamada de métodos, acceso a datos, etc. No hay un Fb-AOP, inclusive en la dimensión basada en código, que se haya acercado a apoyar a todos, ni siquiera la mayoría, de las construcciones en cualquier lenguaje de programación determinado [5]. La programación orientada a aspectos permite la modularidad de conceptos y bloque de instrucciones que no pueden ser estructurados con los paradigmas de la programación orientada a objetos o a módulos [6]. La tecnología actual en la AOP permite varias alternativas para la abstracción y separación de conceptos, las cuales involucran la definición de aspectos del lenguaje, weaving process y la modelación de conceptos como aspectos [7]. Los modelos y framework existentes se especializan en solucionar y corregir un inconveniente en particular: ubicación de Join-point, mantenimiento al expandir el código, pérdida de la compactación de aspectos, entre otros. No se han unificado los conceptos para encontrar la solución de todas las desventajas en un solo esquema. Además, una metodología permitirá establecer normas y procedimientos que permitirá identificar y ubicar elementos de los aspectos dentro del software. Aunado a esto, es común el problema del mantenimiento del software frente a los cambios de las reglas de negocios, porque un si los Join-point y los cut-points se encuentran seleccionados de forma errada, se complicará aún más la adaptación del código. La incorporación de los modelos como Join-point, weaving [8], abstracción de aspectos por técnicas de separación horizontal y vertical de conceptos [9], en una metodología permite la compactación de las propuestas que reducen la desventajas de la AOP sirviendo como base a modelos futuros. Además de incorporar estos modelos, Se presente realizar un caso de estudio enfocado a determinar un mecanismo para dar seguimiento a las decisiones de negocio, permitiendo identificar la ubicación para los Join-point y los point-cut, para la ubicación correcta de los aspectos y los advice. En este caso se evaluará la metodología y la herramienta aplicada. Uno de los principales objetivos de los Fb-AOP es separar las clases, métodos, procedimientos y funciones de las reglas del negocio, es decir, moldear un enfoque de programación de tal forma que el framework en sí, no este dependiendo de métodos sino que sea una representación del flujo de las reglas de negocio, facilitando el mantenimiento del mismo, ya sea en procedimientos de eliminación y adición de códigos, o en la adaptación del código para la modificación de una nueva regla. En conjunto a la metodología propuesta, la incorporación de una herramienta servirá como apoyo para aplicar la metodología, además, esta herramienta proporcionará los elementos base del framework de forma automática una vez ingresado ciertos parámetros de entrada se generará los principales métodos y estructuras base del framework. En fin, esta metodología, la herramienta conjunta de diseño y generación del Fb-AOP recopila los más valiosos aportes de diferentes modelos (explicados posteriormente) a la vez que proporciona un procedimiento de cómo realizar un framework para cualquier dominio específico 2. TRABAJOS RELACIONADOS Existen trabajos similares que tratan sobre la elaboración, medición y motivación de porqué utilizar esta estructura frente al enfoque de programación orientada a objetos (OOP). AOP presenta grandes ventajas sobre la OOP [10], entre las cuales se pueden destacar que el primero es más flexible que el segundo siendo AOP considerada como una extensión de las características de OOP, permite la creación de ambientes más robustos y pueden adaptarse más fácilmente al seguimiento de las reglas del negocio de un determinado lugar o compañía, además de segmentar un problema en pequeños conceptos dependiendo a aplicaciones y usos en lugar de funciones y objetivos, además de permitir las invocaciones a cualquier método con un Punto de Corte lo cual facilita la modificación del mismo. Una variedad de trabajos similares sobre Fb-Frameworks como los siguientes:

3 2.1 Framework basado en Componentes y Aspectos [2] Tiene como propósito es de diseñar un modelo de framework que combine los elementos: componentes y aspectos en un mismo modelo. Su arquitectura está dividida en tres capas: componentes-aspectos (los módulos funcionales son trabajados como componentes y los no funcionales como aspectos), interfaz e información (las interfaces son divididas en entrada y salida) y conexión (es la forma para interconectar a los aspectos y a los componentes). Los componentes se encuentran a través de la red, mientras que los aspectos están desarrollados en el servidor. Como todo framework el área de aplicabilidad está limitada a los ambientes que soporten su estructura, cuya implementación, según el autor, resulta práctica para su implementación. La metodología a desarrollar incorpora mecanismos de construcción dinámica en tiempo de ejecución de los aspectos y métodos a invocar y ejecutar. También se aplica el modelo conceptual para evitar los errores comunes de los AOP Frameworks al momento de la expansión del código con la implementación de una vista lógica y física de las relaciones. 2.2 Framework basado en Modelo Conceptual Su propósito consistía en formar un grupo de clases, métodos de clases, paquetes y métodos particulares (información física), metadatos para la expresión de conceptos y funciones lógicas del software (información lógica). Su arquitectura utiliza un modelo basado en sintaxis XML para conectar la información física y la información lógica; resultando fácil aplicar ontología para lograr encontrar mediante instrucciones (querys) la información física mediante la referencia a la información lógica y viceversa Tiene como aplicabilidad solucionar el problema de los débiles Puntos de Corte mediante la utilización de meta niveles, metaclases que están vinculadas con las clases y que son generadas por la reflexión de la clase la cual es un aspecto. 2.3 Dynamic Weaver Framework The Dynamic Weaver Framework (DWF) es un framework orientado a aspectos independiente de lenguaje. El cuál separa propiedades del sistema como autenticación, seguridad, calendarización, entre otras funcionalidad [11]. Propósito: Este framework incorpora el mecanismo dinámico, es decir, los aspectos pueden ser agregados y removidos en tiempo de ejecución sin la necesidad de reconfigurar, bajar el sistema o detener la actividad del mismo. Su arquitectura consta de los siguientes componentes: Aspectos Weaver: intercepta la invocación de cada método y redirige el control hacia el Repositorio de Aspectos. Además este componente se encarga de entrelazar los aspectos en tiempo de ejecución. Repositorio de Aspectos: Evalúa las condiciones en que se ejecutan los Puntos de Cortes, evalúa todos los aspectos requeridos en la invocación de un método. Tabla de Aspectos: Contiene todos los aspectos implementados cuya ubicación es determinada por una llave hash. Esta tabla se crea en tiempo de ejecución. Aspectos: Conceptos y Abstracciones de reglas de negocio, cada uno de ellos pueden tener varios Puntos de Corte. Puntos de Corte: Determina el lugar donde puede ocurrir una invocación e intervenir el Aspectos Weaver, puede contener muchos Advices. Advices: Define el comportamiento de un objeto frente a un determinado evento o trigger. Aplicabilidad: Permite aplicar la reusabilidad, puesto que el acoplamiento entre los aspectos es mínimo; existe un alto nivel de abstracción de conceptos a aspectos y en la codificación no existen restricciones, su arquitectura es independiente del lenguaje. Permite separar el código completamente de los aspectos. 2.4 THAOP [12] THAOP es un framework liviano orientado a aspectos que utiliza una dinámica tecnología de tejido. Propósito: La creación de un nuevo framework basado en aspectos utilizando un componente TH_CORE, el cual se ejecuta en tiempo de ejecución como una serie de herramientas, incluyendo un compilador. Arquitectura: THAOP consiste principalmente de Librerías AOP, Especificación de Lenguaje de Definición de Aspectos ADLS Está basado en Join-Point, Puntos de Corte, Advice, Interceptores (similares a los advice). Estos modelos tiene funcionalidad es similar a AspectJ. Aplicabilidad: Es un framework liviano lo que lo hace mucho más flexible que Fb-AOP más complejos, y facilita la forma de describir aspectos, está basado en XML. 2.5 TITAN TITAN es un framework que permite el modelado de sistemas y la integración de aspectos. Está enfocado a tareas de modelado UML utilizando IPS (Interaction Patterns Specifications) para describir la conducta de los aspectos [4]. El procedimiento de trabajo de TITAN consiste en una vez determinado un aspecto dentro de la lógica del negocio de la aplicación, como por ejemplo la dispensación de bebidas embotelladas [4], al aspecto original del suministro debe agregarse varios requerimientos, por ejemplo cuando ya no existan bebidas; si este aspecto no se contemplo originalmente, mediante el enfoque AOP, es posible adicionar el nuevo aspecto aplicándolo sobre el mismo Join-point, de tal forma que en su ejecución mediante un advice es posible intervenir en el procedimiento original. La arquitectura de TITAN sigue un procedimiento basado en los siguientes elementos [4]: 1) Descripción del sistema (IPS) y especificaciones UML. 2) Instancias de Patrones. 3) Validación de especificaciones UML

4 4) Revisión y validación del modelo. 5) Simulación, verificación y prueba. 6) Verificación del comportamiento del sistema frente a nuevos aspectos. Propósito: permite modelar a través de aspectos procedimientos y diseños UML. 2.6 Otros Proyectos Otros proyectos se han enfocado en la solución de proyectos de cross-cutting (cuando una sección del código se repite muchas veces a lo largo del framework, en especial en las ranuras) y dependencia y cohesión de aspectos. Los dos problemas expresados anteriormente [13] radican en los siguientes conceptos: Al momento de generar la codificación y los métodos del software, en muchas ocasiones se utilizan las mismas funcionalidades, un ejemplo clásico es la autenticación (login), por lo cual al momento de prestar mantenimiento es necesario la modificación de cada uno de los conceptos; para el segundo punto, la cohesión y dependencia de aspectos radica en que es posible que varios aspectos estén involucrados entre sí, lo cual dificulta la arquitectura del framework, ya que como se presento al inicio del documento, el mismo debe ser independientes de las ranuras y métodos parametrizables, por lo que una ranura de un aspecto no debe estar estructuralmente dependiendo de otro que no esté completamente asociado al mismo. Las soluciones a los mismos fueron proporcionadas en el Trabajo [13] mediante la separación de conceptos bajo una estructura denominada Universal. 3. TECNOLOGÍAS UTILIZADAS Las tecnologías involucradas para el desarrollo del proyecto que serán utilizadas son las siguientes: 3.1 AspectJ [13] Son librerías, extensiones de código del lenguaje Java que están orientadas a aspectos. Estos módulos captan la esencia de los Join-point, Cut-Point, código adicional (Advice), weaving process (Objetos creados en el point-cut al aplicar instanciación de clases). AspectJ es uno de los modelos de AOP más populares en la actualidad, permite la ejecución de programas bien definidos en concepto de organización de programación y ejecución de aspectos [6]. AspectJ implementa una serie de complementos Java para trabajar los Join-Point, descripción de los Cut-Point, implementa el uso de advice, introduction y aspectos [6]. AspectJ trabaja de la siguiente forma: Join-Point: El mecanismo de invocación de métodos, ejecución, constructores y manejadores de excepción orientados a aspectos forman parte del Join Point. Cut-Point: Maneja operaciones booleanas para determinar y marcar los puntos para activar los Join Point, estas llaves se encuentran colocadas antes, durante y después de una llamada a un Join Point, de tal forma que son un punto importante en la flexibilidad y para controlar el flujo de un módulo o método. Los Cross-Cutting: permiten agregar conceptos y módulos de seguridad en los mismos, puesto que estos son los puntos de acceso y de vínculo para la ejecución de las demás funciones del framework [14]. Advice: Son las instrucciones de programación que se ejecuta antes, durante y después la intervención de un Joinpoint [6]. Se ejecuta cuando un Join-point es alcanzado, de esta forma es capaz de agregar un comportamiento extra a la funcionalidad. Los advice se definen para cada Cut-Point. Introduction: permite a los aspectos modificar la estructura estática de un programa. La introduction permite la adición de variables, clases, métodos, declaraciones y el control de excepciones dentro mientras se ejecuta un advice [6]. El principal objetivo de la AspectJ es proporcionar que mediante las librerías, los métodos e instrucciones orientadas a objetos y a aspectos, tanto como los bloques secuenciales de código trabajen acopladamente a la par sin problemas al momento de la ejecución del software. El uso de AspectJ puede crear sistemas imprevisibles [4], efectos secundarios no deseados provocados por la incorporación de aspectos, weaving parcial, alteración semántica de los advice, conflictos con los estados invariantes del sistema al adicionar un nuevo aspecto. La aplicabilidad de ApectJ permitirá la incorporación de la AOP dentro del Framework mediante la utilización de la herramienta que se pretende diseñar, permitiendo el uso de cada uno de los elementos de este paradigma de programación. 3.2 Procedimiento Hashing Es un algoritmo de programación que permite determinar la ubicación de elementos en una tabla lógica o física, este procedimiento utiliza una llave hash para determinar la posición del elemento. En este caso, determina la ubicación de los aspectos dentro del directorio de aspecto, en tiempo de ejecución. La llave Hash es determinada generalmente por una función matemática, es posible que se ejecute colisiones, las cuales son tratadas con un procedimiento determinado. Aplicabilidad: Las técnicas de Hashing en conjunto con los Aspectos Repository, permiten la asignación dinámica de los aspectos en tiempo de ejecución dentro del framework. 3.3 IDE Java: Netbeans / Eclipse Son IDE (Plataforma de Desarrollos) para el desarrollo de aplicaciones con el lenguaje de Java, sobre los cuales existen módulos y librerías de desarrollo como AspectJ, los cuales incluyen métodos que controlan las características y los eventos de los aspectos. 3.4 Modelo Joint-Point Este modelo se basa en la utilización de Join-Point, Puntos de Cortes y Advice en la AOP. Los Join-Point deben estar localizados en una posición coherente del flujo del proceso y sus procedimientos deben ser entendibles por el programador.

5 Los Puntos de Cortes son los que determinan en qué lugar pueden ser invocados los Join-Point. Los Advice, son procedimientos que se ejecutan antes, durante o después del Join-Point Es posible notar que es muy importante para este modelo la localización correcta de los Puntos de Corte, ya que estos determinan los Join-Point que ejecutan el código referente a los conceptos y aspectos. Este modelo es comúnmente utilizado para el diseño de las aplicaciones y frameworks basados en aspectos. 3.5 Weaving Model Model-Driven base Aspect-Oriented Model Weaving (MAMW) es un nuevo modelo de concepción que transforma el modelo de la Programación orientada a aspectos. El MAMW es utilizado para la transformación en meta-modelos que implementará el nivel de abstracción. Utiliza un modelo de vínculos para contener los Join Points y elementos de información de la sintaxis. MAMW mejora el nivel de abstracción y unifica el modelo de la Programación AOP. El procedimiento de Tejido (Weaving Model) es un modelo que modifica el programa original con el fin de tejer los aspectos y asociarlos con los Join-point correspondientes [15]. Weaving no es más que el procedimiento de integración de advices a sus correspondientes Join-points del código principal. Los aspectos son conformados por los Join-points, point-cuts y los advices. El procedimiento de weaving consta de las siguientes características: El proceso de Weaving teje varios segmentos de código antes de la compilación, no permite la modificación dinámica del núcleo, ni de los módulos si contiene aspectos. Entre sus desventajas está la reutilización de código para el conjunto de aspectos ya que están separados a los Join-point del programa principal [15]. 3.6 Aspect Dynamic Weaving Model El método de Tejido dinámico presenta los siguientes elementos característicos [16]: Modelado Base y de Aspectos: Se basa en un meta-modelo, no incluye los aspectos (separación de conceptos y reglas), mientras que la otra sección incluye todas las descripciones de los aspectos. Capa de vínculos que permite la interacción entre las dos capas de modelado superiores. La capa de Weaver ejecuta los advice de cada Join-point interceptando las instrucciones en la capa de vínculos. Buffer de Solicitudes: Permite guardar en una lista de todos los aspectos enlazados, estos son vinculados con la capa de Modelo. Todas las solicitudes nuevas también son respaldadas de tal forma que se utilizan y se cargan dinámicamente. Gestor de Estados: que maneja y controla los estados de las otras capas. 4. PROPUESTA La propuesta presentada consta de tres partes: La metodología para el soporte en el desarrollo de frameworks basado en aspectos, una herramienta plug-in de Eclipse para la representación y tratamiento de aspectos, al igual que la generación de código y la aplicación en un caso de estudio que involucra la generación del framework para el seguimiento de las reglas de negocio a partir de la implementación de la metodología. 4.1 Elementos de la Propuesta: Metodología La metodología consta de los siguientes pasos, en los cuales se creará una serie de reglas y procedimientos de apoyo: (Paso1) Identificación de clases: mediante los procedimientos usuales del paradigma orientado a objeto, se abstraen y separan conceptos en base a la identificación de objetos y propiedades en común. (Paso2) Determinar funciones y métodos: procedimiento usual en el procedo de Ingeniería de Requerimientos que busca asignar y determinar a cada clase identificada que atributos, funciones y métodos contendrá. (Paso3) Clasificación por funcionalidades: consiste en la agrupación de clases según los métodos definidos que juntos tratan un requerimiento funcional o no funcional del sistema. Este punto permitirá tener una visión superior de las clases, objetos y métodos analizados. (Paso4) Identificar métodos y clases multifuncionales: del paso anterior es posible encontrar clases y métodos que no se puedan encapsular fácilmente bajo una funcionalidad específica debido a su carácter multifuncional. Mediante reglas de apoyo que se diseñaran, facilitará este procedimiento. (Paso5) Determinar los posibles aspectos en cada bloque de funcionalidad: Identificados los elementos y métodos, se analizan bajo el paradigma de abstracción a aspectos y se eligen candidatos para convertirse en aspectos y cuáles de ellos tendrán comportamiento dinámico. (Paso6) Seleccionar los Join-Point y las normas que rigen los Cut-Point: Para cada aspecto candidato se seleccionan cuáles serán sus Join-Point dependiendo al impacto, estableciendo normas para determinar la ubicación correcta de estos puntos con el fin de que los aspectos cumplan el propósito deseado. (Paso7) Determinar los Advice y crear los cross-cutting: identificando los advice dentro del código del framework concatenando la funcionalidad transversal deseada. (Paso8) Determinar los aspectos candidatos para ser tratados como aspectos dinámicos: este paso consiste en la creación de normas que permitan identificar qué aspectos pueden ser tratados como dinámicos dentro del framework, es decir, que tengan la versatilidad de poder modificarse, omitirse o agregarse en tiempo de ejecución. (Paso9) Aplicar la capa superior de metadatos y metaclases: guía para la creación de una capa superior que permita la definición ontológica de los aspectos según su comportamiento para referencias futuras.

6 4.2 Diseño de la Herramienta de Apoyo Representación de Aspectos: Utilizando y adaptando modelos se representarán los diferentes elementos de los aspectos, basados en [17] como los presentados en la Tabla1: Autor Elemento Representación Zakaria, et al 2003 M. Bash, A. Sanchez 2003 Zakaria, et al, 2002 Steinmacher 2003 Aldawud, et al 2003 Aspecto Join-Point Cut-Point Advice Cross-Cutting Tabla1. Representación de elementos de los aspectos. Representación en código: Codificar cada elemento dentro de la herramienta en formato UML / XMI, para la representación en código de los elementos y su posterior manipulación en la migración de data. Reglas de Validación para la interrelación de los elementos de los aspectos: Normas para relacionar los elementos de forma coherente y lógica no permitiendo asociaciones no válidas. Establecer funcionalidades de la Herramienta: diseñar las funciones básicas como copiar, pegar, nuevo documento, nuevo diagrama, etc. Determinar elementos funcionales indispensables: Son propiedades que determinarán que elementos serán considerados como hot-spots y frozen-spots del framework, lo cual impactará al momento de la migración del código. Diseñar los módulos para migración y generación del código base del Framework: funcionalidad que permitirá trasladar el diseño planteando y diagramado en la herramienta a código Java. Este proceso replicará las clases, aspectos, métodos y atributos como elementos base en el código de framework Caso de Estudio Como forma de evaluación de los pasos de la metodología y de su integración dentro de la herramienta de apoyo. Se desarrollará un caso de estudio en donde se desarrollará un Framework basado en aspectos para el seguimiento de las reglas y decisiones de negocio aplicando estos elementos y evaluando los resultados. 4.4 Características Al aplicar la metodología, los frameworks desarrollados tendrán las siguientes características: Segmentación de Aspectos: Los aspectos son definidos como propiedades de cortes de componentes funcionales, es decir, las áreas de los puntos calientes son analizadas de forma independiente según sus funcionalidades. Después la identificación, todos los aspectos son reunidos e indexados en el contenedor de aspectos. Este proceso se logra en el Paso3. Separación de Cross-Cutting: El Framework incluye la separación de componentes funcionales de los componentes no funcionales, lo cual mejora la reutilización del código de aspectos, puesto que esta clasificación permite organizar las clases y aspectos dependiendo de las funcionalidades siendo posible establecer los componentes de una determina función y encapsularlas en aspectos, de esta manera cuando se necesite utilizar sólo se hace referencia a estos componentes. La separación por cross-cutting se aplica definitivamente en el Paso7. Dinamismo: en tiempo de ejecución el Framework permite la selección dinámica de los aspectos que se ejecutarán. Esto es posible debido al contenedor de aspectos, que permite listar estos elementos; esta indexación se cargará también en tiempo de ejecución. El procedimiento que apoya este beneficio es el Paso8; a su vez trata un problema de la Orientación a Aspectos, que es la reducción de la complejidad al momento de determinar qué aspectos serán dinámicos y como se manejarán los mismos en tiempo de ejecución. Cohesión: es un Framework AOP, utilizando conceptos clásicos de OOP y COP como bases. Aplicado la mezcla de los pasos de la metodología. Conceptualización: se conceptualizan los métodos y funciones evitando inconvenientes al momento de la expansión del código, aplicando clases superiores: meta-data y meta-clases para evitar la redundancia cuando el código empieza a expandirse durante procesos de mantenimiento por ejemplo. A su vez, la conceptualización minimiza el inconveniente de expansión mediante el uso de metadatos y metaclases, pues le dan significado semántico a los aspectos y métodos, aplicado en el Paso9. Intercepción de Invocaciones: es el conjunto de advice de aspectos que se ejecutaran antes, durante o después de una determinada intervención. Esto es un propiedad natural de la AOP, está aplicado en el Paso7. Basado en Join-Point Model: basado en este modelo, el Framework permite reducir el conflicto de los puntos de fusión débiles. La metodología disminuye la dificultad innata que radica en la ubicación de los Join-point y Cut-point mediante las reglas del Paso6. Abstracción de Elementos Multifuncionales: Mediante las reglas del Paso4 y Paso5 se determinan y clasifican los aspectos cuya dificultad de abstracción es elevada debido a que su función se refleja en varios bloques y clasificaciones, a su vez se trata el problema de multifuncionalidad de la AOP. 4.5 Arquitectura La herramienta de apoyo para la generación del framework que utiliza la metodología presenta la arquitectura de la Figura2. El

7 usuario implementa la herramienta y diagrama los elementos del modelo que desea diseñar, en conjunto con la determinación de los atributos y métodos de las clases y elementos de los aspectos; de tal forma que se ve gráficamente en una interfaz de usuario y 4.7 Herramientas y Metodología de la Investigación Se utilizará el IDE de Eclipse para el desarrollo de la investigación, utilizando como soporte y librerías de apoyo de forma paralela se elabora la codificación correspondiente. Una vez terminado se generará en código Java los elementos identificados en los diagramas que serán la estructura base del framework. Además, se genera una capa semántica superior de metadatos y metaclases que identificará las funcionalidad de los métodos, clases y elementos; estos valores se extraerán de la información colocada en los respectivos elementos y se creará de forma paralela al proceso anterior, con independencia al usuario. 4.6 Componentes Los framework tendrán los siguientes elementos: Núcleo: son las instrucciones, clases, funciones y métodos del Framework que no podrán ser modificables (kernel). Estos elementos deben ser notificados en la herramienta como Indispensables para que sean encapsulados dentro del núcleo en la migración del software. Repositorio de Aspectos: es el lugar donde se almacena la representación de los conceptos y funcionalidades del Framework (aspectos); los mismos deben seleccionados y ubicados en un cross-cutting de impacto, de tal forma que mantenga la separación de las funciones. Controlador Dinámico de Aspectos: mantiene todos los aspectos organizados e indexados. El uso de un contenedor paralelo permite la organización en tiempo de ejecución según las prioridades y las invocaciones de cada aspecto o intercepción (llamadas antes, durante o después del aspecto). Ranunas Modificables: son los bloques de abstracciones que fueron catalogados como no requerido dentro de la generación del software. Y que podrán ser modificados o hasta prescindir de ellos. Meta Nivel: nivel superior que contiene el significado semántico de las clases, componentes y aspectos; de tal forma de poder identificar su funcionalidad rápidamente. (middleware) AspectJ que incorpora la segmentación de los Cut- Point, Join-Point, Advice a través de extensiones de código del lenguaje Java. Para el desarrollo de la metodología se utilizarán esquemas de trabajos relacionados donde se implementan el paradigma AOP analizando las variantes de aplicabilidad, además de visualizar el comportamiento de los elementos de los aspectos, a través de ellas se crearan las reglas y normas que denotarán la metodología. En la herramienta se adaptaran los diseños de representación de aspectos, se establecerán los elementos de cada uno de ellos relevante en el proceso de generación del código y la migración se llevará a cabo a través de transformaciones de XML y XMI a código Java. 5. CONCLUSIONES El propósito de la metodología es la de servir de apoyo para el diseño de Fb- AOP en conjunto con la herramienta que es la de diseñar y representar los aspectos para la migración de código. Los beneficios de esta investigación radican en proporcionar una metodología de soporte para el diseño de frameworks basados en programación orientada a aspectos, la cual minimiza los inconvenientes del paradigma de la programación orientada a aspectos, a la vez de proporcionar una nueva visión para el diseño, análisis y desarrollo de Fb AOP. Se tendrá con una herramienta en la cual es posible aplicar la metodología creada, esta herramienta proporcionará los elementos base del framework d3e forma automática una vez ingresado ciertos parámetros de entrada. La herramienta servirá como soporte para la representación y el tratamiento de los aspectos. 6. REFERENCIAS [1] M. E. Markiewicz and C. J. P. d. Lucena, 2001, "El Desarrollo del Framework Orientado al Objeto." Software Engineer Summer. [2] Y. Z. a. J.Zhang, 2005, "Interactive Framework and its Supported Environment between Component and Aspect,. [3] H. Hu, C. He, and Z. Li, 2009, "An AOP Framework and Its Implementation Based on Conceptual Model,"

8 ISECS International Colloquium on Computing, Communication, Control and Management. [4] M. Perez-Toledano and C. Canal, 2007, "TITAN: a Framework for Aspect Oriented System Evolution," in International Conference on Software Engineering Advances, Cap Esterel. [5] A. Nusayr, 2008, "AOP as Formal Framewok for Runtime Monitoring," in FSE-16 Doctoral Symposium, Atlanta, Georigia, USA. [6] A. Kumar, R. Kumar, and P. S. Grover, 2008, "Toward a Unified Framework for Cohesion Measurement in Aspect-Oriented Systems," in 19th Australian Conference on Software Enginnering. [7] M. Díaz, S. Romero, B. Rubio, E. Soler, and J. M. Troya, 2005, "An Aspect Oriented Framework for Scientific Component Development," in 13th Euromicro Conference on Parallel, Distributed and Network-Based Processing. [8] X. Wang, S. Liu, and S. Li, 2007, "A Model Driven based Aspect Oriented Model Weaving Framework for Distributed System," in 11th International Conference on Computer Supported Cooperative Work in Design. [9] A. Solberg, D. Simmonds, R. Reddy, S. Ghosh, and R. France, 2005, "Using Aspect Oriented Techniques to Support Separation of Concerns in Model Driven Development," in 29th Annual International Computer Software and Applications Conference. [10] Z. Hua, Z.-C. Wang, J. Hua, G.-X. Yang, and Y.-W. Liu, 2005, "The Framework of Agent-Oriented Programming," IEEE. [11] D. P. Fletcher, F. Akkawi, R. L. Alena, and D. P. Duncavage, 2004, "From Research to Operations: Integrating Components with an Aspect-Oriented Framework and Ontology," IEEE Aerospace Conference Proceedings. [12] H. J. Hwang and J. T. Choi, 2007, "Design of an Aspect-Based Framework to Improve the Dynamic Management of MFID middleware,". [13] L. Zhou, Q. Wang, Y. Zhang, and C. Xing, 2008, "Solving AOP Problems with Universal Framework," International Symposium on Information Science and Engineering. [14] V. Shah and F. Hill, 2003, "An Aspect-Oriented Security Framework," in DARPA Information Survivability Conference and Exposition (DISCEX'03). [15] D. Majumdar and S. Bhattacharya, 2009, "A Design Model Based Exceution Framework for Aspect Oriented Systems," in International Conference on Methods and Models in Computer Science. [16] G. Jun-Wei, T. Rong, and Y.-Q. Fang, 2008, "A MDA based Aspect-Oriented Model Dynamic Weaving Framework," International Conference on Computer Science and Software Engineering. [17] F. Losavio, A. Matteo and P. Morantes, 2009, "UML Extensions for Aspect Oriented Software Development," Journal of Object Technology Vol. 8, No 5.

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

CAPÍTULO 3 Servidor de Modelo de Usuario

CAPÍTULO 3 Servidor de Modelo de Usuario CAPÍTULO 3 Servidor de Modelo de Usuario Para el desarrollo del modelado del estudiante se utilizó el servidor de modelo de usuario desarrollado en la Universidad de las Américas Puebla por Rosa G. Paredes

Más detalles

Introducción a la Firma Electrónica en MIDAS

Introducción a la Firma Electrónica en MIDAS Introducción a la Firma Electrónica en MIDAS Firma Digital Introducción. El Módulo para la Integración de Documentos y Acceso a los Sistemas(MIDAS) emplea la firma digital como método de aseguramiento

Más detalles

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

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

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Metodología Evolutiva Incremental Mediante Prototipo y Técnicas Orientada a Objeto (MEI/P-OO)

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

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

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

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

INGENIERÍA DEL SOFTWARE

INGENIERÍA DEL SOFTWARE INGENIERÍA DEL SOFTWARE Sesión No. 2 Nombre: Procesos de ingeniería del software INGENIERÍA DEL SOFTWARE 1 Contextualización La ingeniería de software actualmente es muy importante, pues con los avances

Más detalles

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web J.Corral-García, D.Cortés-Polo, C.Gómez-Martín, J.L.González-Sánchez

Más detalles

MANUAL DE USUARIO APLICACIÓN SYSACTIVOS

MANUAL DE USUARIO APLICACIÓN SYSACTIVOS MANUAL DE USUARIO APLICACIÓN SYSACTIVOS Autor Edwar Orlando Amaya Diaz Analista de Desarrollo y Soporte Produce Sistemas y Soluciones Integradas S.A.S Versión 1.0 Fecha de Publicación 19 Diciembre 2014

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

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

Diseño orientado al flujo de datos

Diseño orientado al flujo de datos Diseño orientado al flujo de datos Recordemos que el diseño es una actividad que consta de una serie de pasos, en los que partiendo de la especificación del sistema (de los propios requerimientos), obtenemos

Más detalles

Patrones de software y refactorización de código

Patrones de software y refactorización de código Patrones de software y refactorización de código Introducción y antecedentes de los patrones de software Los patrones permiten construir sobre la experiencia colectiva de ingenieros de software habilidosos.

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

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

Más detalles

Análisis y diseño del sistema CAPÍTULO 3

Análisis y diseño del sistema CAPÍTULO 3 Análisis y diseño del sistema CAPÍTULO 3 36 CAPÍTULO 3 Análisis y diseño del sistema En este capítulo se pretende realizar un análisis detallado de los requerimientos del software a desarrollar para la

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

Ingeniería de Software. Pruebas

Ingeniería de Software. Pruebas Ingeniería de Software Pruebas Niveles de prueba Pruebas unitarias Niveles Pruebas de integración Pruebas de sistema Pruebas de aceptación Alpha Beta Niveles de pruebas Pruebas unitarias Se enfocan en

Más detalles

Unidad 1. Fundamentos en Gestión de Riesgos

Unidad 1. Fundamentos en Gestión de Riesgos 1.1 Gestión de Proyectos Unidad 1. Fundamentos en Gestión de Riesgos La gestión de proyectos es una disciplina con la cual se integran los procesos propios de la gerencia o administración de proyectos.

Más detalles

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com

Más detalles

Gestión de la Configuración

Gestión de la Configuración Gestión de la ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ESTUDIO DE VIABILIDAD DEL SISTEMA... 2 ACTIVIDAD EVS-GC 1: DEFINICIÓN DE LOS REQUISITOS DE GESTIÓN DE CONFIGURACIÓN... 2 Tarea EVS-GC 1.1: Definición de

Más detalles

ARQUITECTURA DE DISTRIBUCIÓN DE DATOS

ARQUITECTURA DE DISTRIBUCIÓN DE DATOS 4 ARQUITECTURA DE DISTRIBUCIÓN DE DATOS Contenido: Arquitectura de Distribución de Datos 4.1. Transparencia 4.1.1 Transparencia de Localización 4.1.2 Transparencia de Fragmentación 4.1.3 Transparencia

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

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

Un primer acercamiento a la CMDB.

Un primer acercamiento a la CMDB. Un Versión primer 1.2 acercamiento a la CMDB. 20/07/2005 Un primer acercamiento a la CMDB. Versión 1.1 1.2 18/02/05 20/02/05 Fecha Jose Autores Carlos Manuel García Viejo García Lobato http://ars.viejolobato.com

Más detalles

"Diseño, construcción e implementación de modelos matemáticos para el control automatizado de inventarios

Diseño, construcción e implementación de modelos matemáticos para el control automatizado de inventarios "Diseño, construcción e implementación de modelos matemáticos para el control automatizado de inventarios Miguel Alfonso Flores Sánchez 1, Fernando Sandoya Sanchez 2 Resumen En el presente artículo se

Más detalles

Workflows? Sí, cuántos quiere?

Workflows? Sí, cuántos quiere? Workflows? Sí, cuántos quiere? 12.11.2006 Servicios Profesionales Danysoft Son notables los beneficios que una organización puede obtener gracias al soporte de procesos de negocios que requieran la intervención

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

O jeto de apre r ndizaje

O jeto de apre r ndizaje Herramientas de Gestión para Objetos de Aprendizaje. Plataforma AGORA Victor Hugo Menéndez Domínguez Universidad Autónoma de Yucatán, México :: mdoming@uady.mx Manuel Emilio Prieto Méndez Universidad de

Más detalles

Programación generativa

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

Metodología centrada en la Experiencia del Usuario

Metodología centrada en la Experiencia del Usuario Metodología centrada en la Experiencia del Usuario Esta metodología fue creada por Jesse James Garrett, se describe a detalle en su libro The Elements of User Experience, consiste en asegurarse que ningún

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

Introducción. Componentes de un SI. Sistema de Información:

Introducción. Componentes de un SI. Sistema de Información: Introducción. Sistema de Información: Conjunto de elementos relacionados entre sí de acuerdo a ciertas reglas, que aporta a la organización la información necesaria para el cumplimiento de sus fines, para

Más detalles

Curso de Spring Framework

Curso de Spring Framework Todos los Derechos Reservados Global Mentoring 2012 Experiencia y Conocimiento para tu Vida 1 Spring es un proyecto de código abierto (open source), originalmente creado por Rod Johnson y descrito en su

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

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 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

Capítulo VI. Conclusiones. En este capítulo abordaremos la comparación de las características principales y

Capítulo VI. Conclusiones. En este capítulo abordaremos la comparación de las características principales y Capítulo VI Conclusiones En este capítulo abordaremos la comparación de las características principales y de las ventajas cada tecnología Web nos ofrece para el desarrollo de ciertas aplicaciones. También

Más detalles

Creación y administración de grupos de dominio

Creación y administración de grupos de dominio Creación y administración de grupos de dominio Contenido Descripción general 1 a los grupos de Windows 2000 2 Tipos y ámbitos de los grupos 5 Grupos integrados y predefinidos en un dominio 7 Estrategia

Más detalles

CONSTRUCCIÓN DEL PROCESO ADMINISTRADOR DE PROYECTOS SEIS SIGMA Bizagi Process Modeler

CONSTRUCCIÓN DEL PROCESO ADMINISTRADOR DE PROYECTOS SEIS SIGMA Bizagi Process Modeler ADMINISTRADOR DE PROYECTOS SEIS Bizagi Process Modeler Copyright 2011 - bizagi Contenido CONSTRUCCIÓN DEL PROCESO... 1 1. DIAGRAMA DEL PROCESO... 3 Sub proceso Fase... 4 Sub proceso Crear Entregable...

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

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

App para realizar consultas al Sistema de Información Estadística de Castilla y León

App para realizar consultas al Sistema de Información Estadística de Castilla y León App para realizar consultas al Sistema de Información Estadística de Castilla y León Jesús M. Rodríguez Rodríguez rodrodje@jcyl.es Dirección General de Presupuestos y Estadística Consejería de Hacienda

Más detalles

Introducción. Metadatos

Introducción. Metadatos Introducción La red crece por momentos las necesidades que parecían cubiertas hace relativamente poco tiempo empiezan a quedarse obsoletas. Deben buscarse nuevas soluciones que dinamicen los sistemas de

Más detalles

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

2 EL DOCUMENTO DE ESPECIFICACIONES

2 EL DOCUMENTO DE ESPECIFICACIONES Ingeniería Informática Tecnología de la Programación TEMA 1 Documentación de programas. 1 LA DOCUMENTACIÓN DE PROGRAMAS En la ejecución de un proyecto informático o un programa software se deben de seguir

Más detalles

Capítulo 2. Planteamiento del problema. Capítulo 2 Planteamiento del problema

Capítulo 2. Planteamiento del problema. Capítulo 2 Planteamiento del problema Capítulo2 Planteamientodelproblema 38 2.1Antecedentesycontextodelproyecto En lo que respecta a los antecedentes del proyecto, se describe inicialmente el contexto donde se utiliza el producto de software.

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

Metodologías de diseño de hardware

Metodologías de diseño de hardware Capítulo 2 Metodologías de diseño de hardware Las metodologías de diseño de hardware denominadas Top-Down, basadas en la utilización de lenguajes de descripción de hardware, han posibilitado la reducción

Más detalles

Gestión de la configuración en el software (SCM) Ingeniería de software Eduardo Ferreira, Martín Solari

Gestión de la configuración en el software (SCM) Ingeniería de software Eduardo Ferreira, Martín Solari Gestión de la configuración en el software (SCM) Ingeniería de software Eduardo Ferreira, Martín Solari 1 Temario Definiciones Problemas del cambio Elementos de la configuración Actividades de SCM Identificación

Más detalles

Visión General GXflow. Última actualización: 2009

Visión General GXflow. Última actualización: 2009 Última actualización: 2009 Copyright Artech Consultores S. R. L. 1988-2009. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento explícito de

Más detalles

Microsoft SQL Server Conceptos.

Microsoft SQL Server Conceptos. Microsoft Conceptos. Microsoft 2005 es una plataforma de base de datos a gran escala de procesamiento de transacciones en línea (OLTP) y de procesamiento analítico en línea (OLAP). La siguiente tabla muestra

Más detalles

Figura 4.1 Clasificación de los lenguajes de bases de datos

Figura 4.1 Clasificación de los lenguajes de bases de datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Este capítulo describen los distintos lenguajes para bases de datos, la forma en que se puede escribir un lenguaje

Más detalles

Metodología básica de gestión de proyectos. Octubre de 2003

Metodología básica de gestión de proyectos. Octubre de 2003 Metodología básica de gestión de proyectos Octubre de 2003 Dentro de la metodología utilizada en la gestión de proyectos el desarrollo de éstos se estructura en tres fases diferenciadas: Fase de Éjecució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

CAPÍTULO 1 Instrumentación Virtual

CAPÍTULO 1 Instrumentación Virtual CAPÍTULO 1 Instrumentación Virtual 1.1 Qué es Instrumentación Virtual? En las últimas décadas se han incrementado de manera considerable las aplicaciones que corren a través de redes debido al surgimiento

Más detalles

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto

Más detalles

UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERÍA. Documentación de Motivación del Proyecto. JMit. Java Monitoring by Introspection Tool

UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERÍA. Documentación de Motivación del Proyecto. JMit. Java Monitoring by Introspection Tool UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERÍA Documentación de Motivación del Proyecto JMit Java Monitoring by Introspection Tool Alumnos: 84.264 86.097 Tutor: Wachenchauzer, Rosa Graciela Indice

Más detalles

I INTRODUCCIÓN. 1.1 Objetivos

I INTRODUCCIÓN. 1.1 Objetivos I INTRODUCCIÓN 1.1 Objetivos En el mundo de la informática, la auditoría no siempre es aplicada en todos las empresas, en algunos de los casos son aplicadas por ser impuestas por alguna entidad reguladora,

Más detalles

UNIVERSIDAD DE SALAMANCA

UNIVERSIDAD DE SALAMANCA UNIVERSIDAD DE SALAMANCA FACULTAD DE CIENCIAS INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS Resumen del trabajo práctico realizado para la superación de la asignatura Proyecto Fin de Carrera. TÍTULO SISTEMA

Más detalles

1.1.- Objetivos de los sistemas de bases de datos 1.2.- Administración de los datos y administración de bases de datos 1.3.- Niveles de Arquitectura

1.1.- Objetivos de los sistemas de bases de datos 1.2.- Administración de los datos y administración de bases de datos 1.3.- Niveles de Arquitectura 1. Conceptos Generales 2. Modelo Entidad / Relación 3. Modelo Relacional 4. Integridad de datos relacional 5. Diseño de bases de datos relacionales 6. Lenguaje de consulta estructurado (SQL) 1.1.- Objetivos

Más detalles

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él.

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él. PROCESOS SOFTWARE MOTIVACIÓN? Con independencia de la metodología o modelo implementado, es común la estrategia para la mejora continua de la calidad, basada en el Círculo de Deming o Plan, Do, Check,

Más detalles

SCT3000 95. Software para la calibración de transductores de fuerza. Versión 3.5. Microtest S.A. microtes@arrakis.es

SCT3000 95. Software para la calibración de transductores de fuerza. Versión 3.5. Microtest S.A. microtes@arrakis.es SCT3000 95 Versión 3.5 Software para la calibración de transductores de fuerza. Microtest S.A. microtes@arrakis.es Introducción El programa SCT3000 95, es un sistema diseñado para la calibración automática

Más detalles

INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS

INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS AUTORÍA JOSEFA PÉREZ DOMÍNGUEZ TEMÁTICA NUEVAS TECNOLOGIAS ETAPA CICLOS FORMATIVOS DE GRADO SUPERIOR DE INFORMÁTICA Resumen En esta publicación se

Más detalles

Unidad II. - Las técnicas en las que se basó, las categorías de análisis o ejes centrales que permiten guiar el proceso de investigación.

Unidad II. - Las técnicas en las que se basó, las categorías de análisis o ejes centrales que permiten guiar el proceso de investigación. Unidad II Metodología de Solución de Problemas 2.1 Descripción del problema (enunciado). Este aspecto nos indica describir de manera objetiva la realidad del problema que se esta investigando. En la descripción

Más detalles

BASE DE DATOS RELACIONALES

BASE DE DATOS RELACIONALES BASE DE DATOS RELACIONALES Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para implementar bases de datos ya

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 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

ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN ARQUITECTURAS DE PROCESOS DE NEGOCIOS INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN ARQUITECTURA SOA Services Oriented Arquitecture SOA como arquitectura para BPM Las organizaciones deben

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

SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0

SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0 SPEM 2.0 SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0 Metamodelo para modelos de procesos de ingeniería de software y de ingeniería de sistemas. La idea central de SPEM

Más detalles

Capitulo I. Introducción

Capitulo I. Introducción Capitulo I. Introducción 1.1 Descripción del trabajo El ser humano, como todos sabemos tiene la necesidad de comunicarse, de ser escuchado y sobretodo interactuar con los demás seres vivos que lo rodean.

Más detalles

Infraestructura Tecnológica. Sesión 5: Arquitectura cliente-servidor

Infraestructura Tecnológica. Sesión 5: Arquitectura cliente-servidor Infraestructura Tecnológica Sesión 5: Arquitectura cliente-servidor Contextualización Dentro de los sistemas de comunicación que funcionan por medio de Internet podemos contemplar la arquitectura cliente-servidor.

Más detalles

Describir una metodología sistemática de análisis de los procesos organizacionales y cómo estos pueden ser apoyados por las TI.

Describir una metodología sistemática de análisis de los procesos organizacionales y cómo estos pueden ser apoyados por las TI. Procesos de Negocio Objetivos Describir una metodología sistemática de análisis de los procesos organizacionales y cómo estos pueden ser apoyados por las TI. Identificar y analizar los procesos de negocios,

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

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: EL PROCESO DE DISEÑO DE SISTEMAS DISTRIBUIDOS MANEJANDO LOS DATOS EN LOS SISTEMAS DISTRIBUIDOS DISEÑANDO SISTEMAS PARA REDES DE ÁREA LOCAL DISEÑANDO SISTEMAS PARA ARQUITECTURAS CLIENTE/SERVIDOR

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

Capítulo I. Definición del problema y objetivos de la tesis. En la actualidad Internet se ha convertido en una herramienta necesaria para todas

Capítulo I. Definición del problema y objetivos de la tesis. En la actualidad Internet se ha convertido en una herramienta necesaria para todas Capítulo I Definición del problema y objetivos de la tesis 1.1 Introducción En la actualidad Internet se ha convertido en una herramienta necesaria para todas las personas ya que nos permite realizar diferentes

Más detalles

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO)

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO) Diseño Orientado a Objetos. Metodología enfocada a la solución de problemas complejos. Complejidad del software. Problemas difíciles de precisar. Definición de requerimientos vago y cambio en el desarrollo

Más detalles

COPIAS DE SEGURIDAD AUTOMÁTICAS DE DIRECCIONES CALLEÇPAÑA

COPIAS DE SEGURIDAD AUTOMÁTICAS DE DIRECCIONES CALLEÇPAÑA COPIAS DE SEGURIDAD AUTOMÁTICAS DE DIRECCIONES CALLEÇPAÑA Autor: Carlos Javier Martín González. Licenciado en Física Teórica por la Universidad Autónoma de Madrid. Analista programador y funcional. Desarrollador

Más detalles

No se requiere que los discos sean del mismo tamaño ya que el objetivo es solamente adjuntar discos.

No se requiere que los discos sean del mismo tamaño ya que el objetivo es solamente adjuntar discos. RAIDS MODO LINEAL Es un tipo de raid que muestra lógicamente un disco pero se compone de 2 o más discos. Solamente llena el disco 0 y cuando este está lleno sigue con el disco 1 y así sucesivamente. Este

Más detalles

Creación y administración de grupos locales

Creación y administración de grupos locales Creación y administración de grupos locales Contenido Descripción general 1 Introducción a los grupos de Windows 2000 2 Grupos locales 5 Grupos locales integrados 7 Estrategia para utilizar grupos locales

Más detalles

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles

Alumna: Adriana Elizabeth Mendoza Martínez. Grupo: 303. P.S.P. Miriam De La Rosa Díaz. Carrera: PTB. en Informática 3er Semestre.

Alumna: Adriana Elizabeth Mendoza Martínez. Grupo: 303. P.S.P. Miriam De La Rosa Díaz. Carrera: PTB. en Informática 3er Semestre. Alumna: Adriana Elizabeth Mendoza Martínez. Grupo: 303. P.S.P. Miriam De La Rosa Díaz. Carrera: PTB. en Informática 3er Semestre. Tema: Sistemas Subtema: Base de Datos. Materia: Manejo de aplicaciones

Más detalles

1. Resumen.. 3. 2. Objetivos.. 3. 3. Introducción. 3

1. Resumen.. 3. 2. Objetivos.. 3. 3. Introducción. 3 1 Índice 1. Resumen.. 3 2. Objetivos.. 3 3. Introducción. 3 4. Aplicación web para la gestión de una memoria corporativa: reportes de actividades (proyectos) 4.1 Metodología... 4 4.2 Lenguajes y herramientas

Más detalles

Guías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online

Guías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online Guías _SGO Gestione administradores, usuarios y grupos de su empresa Sistema de Gestión Online Índice General 1. Parámetros Generales... 4 1.1 Qué es?... 4 1.2 Consumo por Cuentas... 6 1.3 Días Feriados...

Más detalles

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS CURSO: JAVA BASICO PROFESOR: EMERSON CASTAÑEDA SANABRIA TEMA: Programación Orientada a Objetos OBJETIVOS: Familiarizarse con la Programación

Más detalles

LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN

LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN Tabla de Contenidos LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN... 1 Tabla de Contenidos... 1 General... 2 Uso de los Lineamientos Estándares...

Más detalles

Capítulo II. Arquitectura del Software

Capítulo II. Arquitectura del Software Capítulo II. Arquitectura del Software Después de un cuidadoso análisis de los objetivos del proyecto, se determinó que la mejor manera de estructurar el sistema era haciendo uso del muy famoso patrón

Más detalles

CAPITULO 4. Requerimientos, Análisis y Diseño. El presente capítulo explica los pasos que se realizaron antes de implementar

CAPITULO 4. Requerimientos, Análisis y Diseño. El presente capítulo explica los pasos que se realizaron antes de implementar CAPITULO 4 Requerimientos, Análisis y Diseño El presente capítulo explica los pasos que se realizaron antes de implementar el sistema. Para esto, primero se explicarán los requerimientos que fueron solicitados

Más detalles

Software de Simulación aplicado a entornos de e-learning

Software de Simulación aplicado a entornos de e-learning Software de Simulación aplicado a entornos de e-learning 2009 Laboratorio de Investigación de Software Universidad Tecnológica Nacional Facultad Regional Córdoba Titulo del Proyecto Software de Simulació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] 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

Gestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi

Gestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi Gestión de Permisos Bizagi Suite Gestión de Permisos 1 Tabla de Contenido Gestión de Permisos... 3 Definiciones... 3 Rol... 3 Perfil... 3 Permiso... 3 Módulo... 3 Privilegio... 3 Elementos del Proceso...

Más detalles

Presentación y Planificación del Proyecto: Administración de Calzado

Presentación y Planificación del Proyecto: Administración de Calzado 1 Presentación y Planificación del Proyecto: Administración de Calzado Integrantes Manuel Cubillos manuel.cubillosv@usach.cl Juan Díaz juan.diazc@usach.cl Felipe Llancaleo felipe.llancaleo@usach.cl Alberto

Más detalles

F A B R I C I O M U Ñ O Z S. T E N I E N T E T É C N I C O D E A V I A C I Ó N

F A B R I C I O M U Ñ O Z S. T E N I E N T E T É C N I C O D E A V I A C I Ó N PROPUESTA DE IMPLEMENTACIÓN DE UNA METODOLOGÍA PARA EL DESARROLLO DE SISTEMAS ORIENTADOS A SERVICIOS EN EL DEPARTAMENTO DE DESARROLLO DE SISTEMAS DE LA DIRECCIÓN DE SISTEMAS DE INFORMACIÓN Y COMUNICACIONES

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

Anteproyecto Fin de Carrera

Anteproyecto Fin de Carrera Universidad de Castilla-La Mancha Escuela Superior de Informática Anteproyecto Fin de Carrera DIMITRI (Desarrollo e Implantación de Metodologías y Tecnologías de Testing) Dirige: Macario Polo Usaola Presenta:

Más detalles

Capitulo 3. Desarrollo del Software

Capitulo 3. Desarrollo del Software Capitulo 3 Desarrollo del Software 3.1 Análisis del sistema 3.1.1 Organización de la autopista virtual Para el presente proyecto se requiere de simular una autopista para que sirva de prueba. Dicha autopista

Más detalles

MODELADO DE OBJETOS DE DATOS

MODELADO DE OBJETOS DE DATOS Manual Página Web MODELADO DE OBJETOS DE DATOS MANUALES ESPECIALES Documento: Manual Páginas Web (SemanticWebBuilder). Fecha de Elaboración: Marzo de 2009. INFOTEC CONACYT FIDEICOMISO. Página i Glosario

Más detalles