2 E STADO DEL ARTE Modelado Lenguajes Formales UML XML Herramientas Específicas de Dominio Aproximaciones a la Integración de Herramientas
|
|
- Enrique Luna Escobar
- hace 8 años
- Vistas:
Transcripción
1 2 ESTADO S DEL ARTE Este capítulo se concibe como una exposición sobre la situación actual en cuanto al empleo de entornos multidisciplinares en el desarrollo de SW para SCDTR. Esta exposición se hace de forma progresiva. Se inicia con una descripción de la ciencia básica sobre dos conceptos abstractos identificados como necesarios para el entorno en el primer capítulo: el Modelado y el empleo de Lenguajes Formales como mecanismo de expresión de instancias de modelos. Se repasarán, entre otras, nociones como vista, abstracción o instancia, por un lado, y léxico, sintaxis o semántica por el otro. Así mismo, se introducirán los fundamentos de dos tecnologías estándar aplicables en cada uno de estos dos campos: el lenguaje de modelado UML y el lenguaje formal XML, respectivamente. El interés en este punto no va más allá de conocer las ventajas que estas tecnologías pueden aportar para ubicarlas con criterio en el entorno, pero será en otros capítulos donde se profundice sobre las características más específicas de las técnicas seleccionadas. Posteriormente, el estudio se centra en las Herramientas Específicas de Dominio, es decir, en las herramientas más utilizadas en cada una de las disciplinas mencionadas en el primer capítulo. Este recorrido permitirá recoger similitudes y diferencias entre herramientas, que conducirán al enunciado de las necesidades que se le imponen al entorno que las integre. También se describirán algunas Aproximaciones a la Integración de Herramientas o soluciones ofrecidas por otros grupos de investigación que también persiguen la colaboración y comunicación entre herramientas.
2 2.1 Modelado Niveles de Abstracción Modelo de 4+1 vistas UML (Unified Modeling Language) Diagramas utilizados en UML Proceso de Desarrollo Carencias de UML Estándares OMG Model Driven Architecture (MDA) Meta Object Facility (MOF) XML Metadata Interchange (XMI) UML Lenguajes Formales Algunas Definiciones EBNF XML Generación de Gramáticas a partir de Modelos UML 2.3 Herramientas Específicas de Dominio Ingeniería de Control Sistemas Distribuidos Sistemas de Tiempo Real UML para Sistemas de Tiempo Real Ingeniería del SW Modelo de Madurez de Capacidad Software (CMM) El Proceso de Desarrollo del SW Estructura de las Herramientas CASE Lenguajes de Descripción de Arquitecturas 2.4 Aproximaciones a la Integración de Herramientas Soluciones particulares de dominio NetBeans Ptolemy Soluciones genéricas (METAframework) Generic Modelling Environment (GME) Eclipse
3 2..1 MODELADO Sobre la construcción de un modelo como abstracción de la realidad y sobre la jerarquía de las abstracciones. Descripción de las características de UML y otros estándares OMG relacionados con el modelado NIVELES DE ABSTRACCIÓN El modelado es necesariamente un ejercicio de abstracción, entendida ésta como una simplificación y generalización de la realidad. Abstraer significa ignorar, excluir o esconder ciertos detalles de un conjunto de elementos con el objetivo de capturar y resaltar las características comunes a todos esos elementos. Una abstracción es hija y madre a la vez porque primeramente es concebida a partir del análisis de ciertos elementos, pero después sirve como origen para la instanciación o concreción de nuevos elementos que se derivan de ella. Ejemplos típicos de abstracción son los tipos de datos que se usan en programación para agrupar datos con características comunes. El uso de la abstracción permite describir, representar, manejar y resolver problemas complejos, pudiendo después aplicar los resultados a casos concretos (instancias). Normalmente, se construyen jerarquías de abstracción, en las que cada nivel de abstracción se apoya en los inferiores. Cada nivel de abstracción esconde ciertos detalles a los niveles superiores de forma que se simplifica el tratamiento de problemas más complicados. Se dice que la construcción de los niveles de abstracción se hace de abajo hacia arriba (bottom-up), puesto que se parte de lo más concreto y se van agrupando y generalizando características comunes para subir un peldaño más en la pirámide de niveles. Por el contrario, la implementación o puesta en práctica de resultados genéricos se hace de arriba hacia abajo (top-down) porque a partir de una solución genérica deducida desde un nivel de abstracción alto se va descendiendo para poder instanciar esa solución y aplicarla a una realidad concreta. En general, pueden definirse tantos niveles de abstracción como se precise para gestionar adecuadamente un determinado problema. Incluso para un mismo problema pueden existir diferentes aproximaciones de abstracción, por ejemplo los marcos de referencia OSI y TCP/IP emplean respectivamente siete y cuatro niveles de abstracción para representar las capas involucradas en la comunicación de información. La representación abstracta de la información es la base en la que se fundamenta la evolución del conocimiento humano en cualquier área. Concretamente, en el caso de la informática los ejemplos son múltiples: codificación de la información, Pág. 2-1
4 programación en lenguajes de alto nivel, generación de compiladores, modularidad del software, etc. En este ámbito de la informática se definen típicamente cuatro niveles de abstracción para el modelado: Tabla 2-1. Niveles de abstracción en el modelado. NIVELES DE ABSTRACCIÓN ENTIDADES MANEJADAS LENGUAJES DEFINIDOS Meta-metamodelo Meta-modelos Lenguaje para la descripción de diferentes tipos de modelos. Lenguaje de modelado Meta-modelo Meta-metadatos ó Modelos Lenguaje para la descripción de diferentes tipos de datos (meta-datos) Modelo Meta-datos Lenguaje para la descripción de datos concretos Información Datos Nivel de Información. Agregación informal de datos a manejar en un entorno concreto (aplicación). Se separa un subconjunto de datos con características comunes o interesantes desde un determinado punto de vista. Nivel de Modelo. Agregación informal de meta-datos (datos sobre los datos) que describen una información concreta. Se describen las características comunes de los datos dando lugar a meta-datos que se agrupan, describiéndose las relaciones entre ellos, para formar un modelo. Nivel de Meta-modelo. Agregación informal de modelos o metametadatos (descripción de meta-datos). Descripciones que definen la estructura y la semántica de los metadatos. Se describen las características comunes de subconjuntos de meta-datos dando lugar a meta-metadatos o modelos que se agrupan, describiéndose las relaciones entre ellos, para formar un meta-modelo. Nivel de Meta-metamodelo. Definición de la estructura y la semántica de los meta-metadatos. Se capturan las características comunes de subconjuntos de modelos dando lugar a meta-modelos que se agrupan, describiéndose las relaciones entre ellos, para formar un meta-metamodelo. Tal y como muestra la Tabla 2-1, en cada nivel de define una nueva entidad (metadato, modelo, meta-modelo, ) que es empleada en el nivel superior para generar otra entidad más abstracta (modelo agrupando meta-datos, meta-modelo agrupando modelos, ). Además, la adecuada expresión de esta jerarquía de abstracciones está directamente relacionada con el uso de lenguajes formales. En cada nivel de abstracción se genera el lenguaje que sirve para describir los elementos del nivel inmediatamente inferior. Por esa razón, un modelo no pasará a constituirse en agregación formal de meta-datos hasta que no exista un meta- Pág. 2-2
5 modelo que defina el lenguaje con el que describir formalmente al modelo, de forma que la especificación de cualquier modelo (instancia del meta-modelo) pueda ser validada. De una manera burda, se pueden asemejar estos niveles de abstracción con los empleados en la definición de los lenguajes de programación de alto nivel, tal y como muestra la Tabla 2-2: Tabla 2-2. Ejemplo de abstracción jerárquica: lenguajes de programación. NIVELES Meta-lenguaje programación ENTIDADES MANEJADAS Lenguajes de programación LENGUAJES Lenguaje para la descripción de diferentes lenguajes de programación Lenguaje programación Sentencias control flujo, variables, tipos, Lenguaje para la descripción de programas como modelos de ejecuciones Tipos de datos Variables TYPE tnombre = string [20]; tcuenta = RECORD... Nombre, Número cuenta,... Lenguaje para la descripción de tipos de datos como modelos de variables Lenguaje para la descripción de variables (y relaciones entre ellas) como modelos de los datos Información bancaria Aitor Pérez, ,... En el caso particular de la programación orientada a objetos se puede decir que los niveles de abstracción más significativos serían: dato, objeto, clase y modelo. En general, se puede aplicar el modelado jerárquico en cualquier ámbito, teniendo claro cuál es el nivel inferior o qué tipo de información se va a modelar y con qué propósito y cuántos niveles de abstracción (por encima del inicial) se van a necesitar. Habitualmente se emplea el término alinear para denotar la acción de definir o fijar la información a modelar, los datos que van a constituir el primer escalón de la jerarquía. A partir de ese punto de denotan los niveles superiores como modelo, metamodelo, meta-metamodelo, etc respecto al más inferior. Pág. 2-3
6 Figura 2-1. Arquitectura de metamodelado de UML en 4 niveles. La Figura 2-1 representa la arquitectura de UML (lenguaje de modelado que se describirá en el apartado 2.1.3) tal y como es definida por Medvidovic y Taylor (2000) y basada en cuatro niveles. El nivel de meta-metamodelo define un lenguaje para la especificación de notaciones de modelado, y una de sus instancias es UML. El nivel de metamodelo define las especificaciones legales para un determinado lenguaje de modelado, por ejemplo el metamodelo UML define la notación legal y la semántica de las especificaciones UML. El nivel de modelo se usa para representar sistemas específicos, un modelo será así una instancia del metamodelo que describe un producto específico. Finalmente, se encuentra el nivel de los objetos de usuario. Pág. 2-4
7 2.1.2 MODELO DE 4+1 VISTAS En lo concerniente al modelado de sistemas software desde varios puntos de vista, es obligada la referencia al modelo 4+1 de Kruchten (1995). Este modelo permite describir la arquitectura de grandes sistemas SW desde múltiples vistas para tratar separadamente los requisitos de usuarios finales, desarrolladores, ingenieros de sistemas, gestores de proyecto, etc. Por lo tanto, son diferentes y complementarias las capacidades de cada vista porque detrás de ellas hay perfiles de usuario diferentes. El modelo describe vistas (arquitecturas) a través de elementos (componentes, conectores) y notaciones gráficas específicas para cada vista. Las vistas que se definen son: Vista Lógica. Está pensada para que el usuario final pueda describir la funcionalidad deseada. Se realiza una descomposición del sistema siguiendo la filosofía de Orientación a Objetos (abstracción, encapsulado y herencia). La notación gráfica empleada se compone de diagramas de clases y patrones para la descripción estática y máquinas de estados finitos para describir el comportamiento dinámico. Los elementos de su notación son: o o Componentes: clase, clase parametrizada, categoría de clases Conectores: asociación, agregación, uso, herencia, instancia Vista de Proceso. Los integradores del sistema la emplean para expresar requisitos no funcionales como integridad, rendimiento o escalabilidad. Se realiza la distribución de los objetos diseñados en la vista lógica en procesos (conjunto de tareas concurrentes) en función de los requisitos no funcionales. Se deben reflejar aspectos de concurrencia, sincronización y comunicación entre procesos. Los elementos de su notación son: o Componentes: proceso, proceso simple, periodicidad o Conectores: mensaje, RPC (Remote Procedure Call), mensaje bidireccional, difusión de evento Vista de Desarrollo. Los programadores la emplean para describir la organización estática del SW en el entorno de desarrollo (gestión del SW, descomposición en subsistemas a desarrollar por gente diferente, descripción de interfaces, relaciones de importación y exportación, reutilización, requisitos del lenguaje de programación o herramientas de desarrollo, evaluación de costes, planificación, portabilidad, seguridad). Los elementos de su notación son: o o Componentes: módulo, subsistema, nivel Conectores: referencia, dependencia de compilación Pág. 2-5
8 Vista Física. Los ingenieros de sistema definen aquí el mapeo del SW en el HW aplicando requisitos como disponibilidad, tolerancia a fallos, rendimiento o escalabilidad. Si existen varios nodos es aquí donde se define la topología del sistema y las comunicaciones y se mapean en diferentes nodos los procesos, tareas y objetos. Pueden existir diferentes configuraciones físicas de un mismo sistema para las fases de pruebas y desarrollo. Se intenta realizar un mapeo flexible y con mínimo impacto en el SW. Los elementos de su notación son: o o Componentes: procesadores, otros dispositivos Conectores: línea de comunicación permanente o no, bidireccional o unidireccional Escenarios ó casos de uso. Ilustran el uso y las relaciones entre el resto de las vistas y permiten abstraer los requisitos más generales. El nombre de 4+1 proviene del uso que se le da a esta quinta vista como vista integradora de las demás, en la que se expresan las relaciones cruzadas. Los elementos de su notación son: o o Componentes: actores, casos de uso Conectores: relaciones Tal y como resume la Figura 2-2, cada vista tiene un perfil de usuario y una notación gráfica especializada (formada siempre por un conjunto de componentes y conectores) para resolver sus necesidades expresivas. Además, se establece un proceso de desarrollo porque está predefinido el orden en el cual se deben utilizar cada una de las vistas para modelar el sistema; se comienza siempre por la vista lógica y se termina en la física, pero se tiene en cuenta en cada vista lo que se haya generado en las anteriores. En definitiva, se avanza hacia una descripción completa del sistema aportando detalles al todo desde perspectivas particulares. Pág. 2-6
9 Cada vista posee diferentes: Usuarios / Objetivos Notación (componentes y conectores) Figura 2-2. Vistas del Modelo 4+1 Pág. 2-7
10 2.1.3 UML (UNIFIED MODELING LANGUAGE) Originalmente, UML fue concebido por Grady Booch, James Rumbaugh e Ivar Jacobson de Rational Software. Posteriormente obtuvo el apoyo de la industria vía el consorcio de socios de UML, y fue presentado al Object Management Group (OMG) y aprobado por éste como estándar (17 de noviembre de 1997). Debido a que UML evolucionó a partir de varios métodos orientados a objeto de segunda generación (en cuanto a nivel de notación), mayoritariamente se cree que sólo es aplicable a sistemas de software orientados a objeto cuando, realmente, UML no es simplemente un lenguaje para modelado orientado a objeto de tercera generación, sino un "lenguaje para modelado unificado" relativo a sistemas en general (ver Figura 2-3). Al ser un lenguaje de modelado y no un método, consiste en una notación principalmente gráfica, que cualquier método puede emplear para expresar su diseño. Booch Rumbaugh Jacobson Odell Shlaer-Mellor Object life cycles UML Meyer Pre- and Post-conditions Harel State Charts Gamma et. al. Frameworks, patterns, notes Wirfs-Brock Embly Responsabilities Singleton classes Fusion Operation descriptions, message numbering Figura 2-3. UML como fusión de varios lenguajes de modelado. UML es un lenguaje de modelado para la especificación, visualización, construcción y documentación de sistemas: Como lenguaje, se emplea para la comunicación, es decir, como medio para capturar el conocimiento (semántica) y expresar el conocimiento (sintaxis) del sistema en estudio. Proporciona un vocabulario y las reglas para combinar las palabras de ese vocabulario con objeto de posibilitar la comunicación, de manera que un desarrollador puede escribir un modelo en UML, y otro desarrollador, que incluso utilice otra herramienta de programación, puede interpretar ese modelo sin ambigüedad. Como lenguaje de modelado, se centra en la comprensión del sistema a través de la formulación de un modelo del mismo (y su contexto respectivo). Se trata de un lenguaje estándar para trazar los planos del sistema, cuyo Pág. 2-8
11 vocabulario y reglas se centran en la representación conceptual y física de un sistema. En cuanto a cómo se aplica para especificar sistemas, se puede utilizar para comunicar "qué" se requiere de un sistema y "cómo" puede ser construido. Dado que especificar significa construir modelos precisos, UML cubre la especificación de todas las decisiones de análisis, diseño e implementación que deben realizarse al desarrollar e implementar un sistema. En cuanto a cómo se aplica para visualizar sistemas, se puede usar para describir visualmente un sistema antes de ser construido. Un modelo explícito facilita la comunicación. En cuanto a cómo se aplica para construir sistemas, se puede emplear para guiar la construcción de un sistema (similar a los "planos"). Además, UML es lo suficientemente expresivo y no ambiguo como para permitir, a través de herramientas que lo integran, la ejecución directa de modelos, la simulación de sistemas y la instrumentación de sistemas en ejecución. En cuanto a cómo se aplica para documentar sistemas, se puede utilizar para capturar conocimiento de un sistema a lo largo de todo el proceso de su ciclo de vida. UML cubre la documentación de la arquitectura de un sistema y todos sus detalles, también proporciona un lenguaje para modelar las actividades de planificación de proyectos y gestión de versiones. Además, cuidando la unificación, integra las mejores prácticas de la ingeniería de la industria tecnológica y de sistemas de información pasando por todos los tipos de sistemas (software y no software), dominios (negocios versus software) y procesos de ciclo de vida. También es importante destacar que UML NO es: Un lenguaje de programación visual, sino un lenguaje de modelado visual. No obstante, existen herramientas CASE que conectan de forma directa los modelos UML a una gran variedad de lenguajes de programación. Una herramienta de especificación, sino un lenguaje para modelado de especificación. Un proceso, sino que habilita procesos. En resumen, UML posibilita la captura y comunicación del conocimiento y facilita la adaptación al posible aumento de complejidad o cambio. Este lenguaje para modelado (estandarizado en ciertas industrias), no es un lenguaje cerrado, sino más bien, un lenguaje abierto y totalmente extensible. Pág. 2-9
12 Diagramas utilizados en UML UML describe cualquier tipo de sistema en términos de diagramas orientados a objetos. Un diagrama es la representación gráfica de un conjunto de elementos, normalmente mostrado como un grafo conexo de nodos (elementos) y arcos (relaciones). UML permite representar un sistema desde diferentes perspectivas, obteniendo diferentes modelos en forma de diagramas. Por tanto, un diagrama es tan sólo una proyección gráfica de los elementos que configuran un sistema. UML incluye los siguientes diagramas: Diagrama de Casos de Uso Diagrama de Clases (incluyendo Diagrama de Objetos) Diagramas de Comportamiento: o o o Estados Actividad Interacción (Diagramas de Secuencia y de Colaboración) Diagramas de Implementación: o o Componentes Despliegue La Figura 2-4 muestra las relaciones que se establecen entre estos tipos de diagramas. Otra posible clasificación de los diagramas UML los divide en: Estructurales: de clases, objetos, componentes y despliegue. De comportamiento: de casos de uso, estados, actividad, secuencia y colaboración De gestión de modelos: de paquetes, de modelos y de subsistemas Pág. 2-10
13 Casos de Uso Diagramas de Secuencia Diagramas de Clases Diagramas de Distribución Diagramas de Componentes C Ó D I G O Diagramas de Colaboración Diagramas de Estados Diagramas de Actividad Diagrama de Casos de Uso Figura 2-4. Relación entre diagramas. Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación.esta técnica permite capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que trabaje. No pertenece realmente al enfoque orientado a objeto, más bien es una técnica para el modelado de escenarios (un escenario es una instancia de un Caso de Uso) en los cuales el sistema debe operar. El modelo de los Casos de Uso comprende los actores (agente, persona o cosa que solicita un servicio al sistema o actúa como catalizador para que ocurra algo), el sistema y los propios Casos de Uso. Un Caso de Uso describe una situación de uso del sistema interactuando con actores. Se determinan observando y precisando, actor por actor, las secuencias de interacción desde el punto de vista del usuario. Examinando estas secuencias de interacción, que expresan las necesidades funcionales de los actores, se determina el conjunto de funcionalidades del sistema. La Figura 2-5 ilustra un ejemplo de diagrama de casos de uso. La descripción del Caso de Uso incluye: El inicio: cuándo y qué actor lo produce? El fin: cuándo se produce y qué valor devuelve? La interacción actor-caso de uso: qué mensajes intercambian ambos? Objetivo del caso de uso: qué lleva a cabo o intenta? Cronología y origen de las informaciones Repeticiones de comportamiento: qué operaciones son iteradas? Pág. 2-11
14 Situaciones opcionales: qué ejecuciones alternativas se presentan en el caso de uso? Caso de uso Actor Caso de uso Actor Actor Caso de uso Caso de uso Actor Figura 2-5. Diagrama de casos de uso. La realización de los Casos de Uso es la transformación de los distintos pasos y acciones que lo describen en clases, operaciones y relaciones entre clases.en resumen, los Casos de Uso describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario, permitiendo definir los límites del sistema y las relaciones del sistema con el entorno Diagrama de Clases Un Diagrama de Clases presenta las clases y objetos del sistema con sus relaciones estructurales y de herencia. El Diagrama de Clases (ver Figura 2-6) es el diagrama principal para el análisis y diseño, aunque el trabajo realizado en los Diagramas de Casos de Uso, de Secuencia y de Colaboración aporta información para establecer las clases, objetos, atributos y métodos. Pág. 2-12
15 Clase Clase Clase 1 1 Clase 1 * * Clase 1 * * Clase {disjunta, completa} * 1 Clase Clase Clase Figura 2-6. Diagrama de Clases. Los Diagramas de Clases y los Diagramas de Objetos pertenecen a dos vistas complementarias del modelo. Un Diagrama de Clases muestra la abstracción de una parte del dominio, mientras que un Diagrama de Objetos representa una situación concreta del dominio, dado que cada objeto es una instancia de una clase y cada enlace es una instancia de una relación (los enlaces vinculan objetos, las asociaciones vinculan clases). Los Diagramas de objetos que contienen objetos y enlaces son instancias de los Diagramas de Clases que contienen clases y asociaciones. Por lo tanto, debe existir coherencia entre ambos Diagramas de Interacción Los Diagramas de Interacción muestran cómo se comunican los objetos en una interacción. Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones. De ahí que se modelen las interacciones. Existen dos tipos de Diagramas de Interacción: los Diagramas de Secuencia y los Diagramas de Colaboración. Los Diagramas de Secuencia están bien adaptados para representar interacciones, mientras que los Diagramas de Colaboración se prestan más al descubrimiento de abstracciones pues permiten representar los objetos en una disposición próxima a la realidad. Es frecuente empezar por uno de Colaboración y pasar después a Secuencia Diagrama de Secuencia El Diagrama de Secuencia muestra el orden cronológico de mensajes entre objetos durante un escenario concreto.el Diagrama de Secuencia se emplea para establecer un escenario del sistema, determinando los objetos y mensajes involucrados. Presenta los objetos de un escenario mediante líneas verticales y los Pág. 2-13
16 mensajes entre objetos como flechas conectando objetos. Además, refleja de manera indirecta las opciones de control. :Actor Mensaje :Actor :Objeto :Objeto :Objeto :Objeto Mensaje Mensaje Mensaje Mensaje Mensaje Mensaje Mensaje Figura 2-7. Diagrama de Secuencia. Son de gran utilidad para: La documentación de un Caso de Uso: en términos próximos al usuario y sin detallar la sincronización existente. La representación precisa de las interacciones entre objetos.diagrama de Colaboración El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso. La colaboración es mediante el intercambio de mensajes.el Diagrama de Colaboración se emplea para establecer un escenario del sistema, determinando los objetos y mensajes involucrados. Los objetos están conectados por enlaces (links) en los cuales se representan los mensajes enviados acompañados de una flecha que indica su dirección. Así, la estructura estática viene dada por los enlaces, mientras que la estructura dinámica está representada mediante el envío de mensajes por los enlaces. Además, la distribución de los objetos en el diagrama permite representar una disposición espacial. Son útiles en la fase exploratoria para identificar objetos. En realidad, el Diagrama de Colaboración (ver Figura 2-8) ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema. Pág. 2-14
17 N: mensaje :Objeto Actor N: mensaje :Objeto N: mensaje N: mensaje N: mensaje Actor N: mensaje N: mensaje N: mensaje :Objeto :Objeto Diagrama de Estados Figura 2-8. Diagrama de Colaboración. El Diagrama de Estados modela el comportamiento de una parte del sistema a través del tiempo. Típicamente se elabora un Diagrama de Estados para cada clase que tenga un comportamiento significativo; para el resto se puede considerar que tienen un único estado. El comportamiento es modelado en términos del estado en el cual se encuentra el objeto, qué acciones se ejecutan en cada estado y cuál es el estado al que transita después de un determinado evento. Los Diagramas de Estados representan autómatas de estados finitos desde el punto de vista de los estados y las transiciones. El formalismo es el de los Statecharts (Harel et al 1990). Los Statecharts son autómatas jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos. Cada objeto sigue el comportamiento descrito en el Statechart asociado a su clase, y el estado en el que se encuentran caracterizas sus condiciones dinámicas. El estado está caracterizado parcialmente por los valores de los atributos del objeto. Cada objeto está en un estado en cierto instante y la transición entre estados, que es instantánea, se debe a la ocurrencia de eventos. Los estados inicial y final están diferenciados del resto. Los Statecharts de UML son deterministas y son complementarios a los escenarios (ver Figura 2-9). Pág. 2-15
18 Estado Transición Transición Estado Transición Transición Estado Diagrama de Actividad Figura 2-9. Diagrama de Estados. El Diagrama de Actividad es una variante de los Diagramas de Estados, organizado respecto a las acciones. Caso especial de Diagrama de Estados donde: Todos (o la mayoría de) los estados son estados de acción. Todas (o la mayoría de) las transiciones son disparadas como consecuencia de la finalización de la acción. El Diagrama de Actividad (Figura 2-10) puede estar asociado a una clase, a la implementación de una operación (representación del comportamiento interno de un método) o a un Caso de Uso. Las actividades se enlazan por transiciones automáticas, es decir, cuando una actividad termina se desencadena el paso a la siguiente actividad. Las actividades no poseen transiciones internas ni transiciones desencadenadas por eventos. Actor Actor Actor Actividad Actividad Actividad Actividad Actividad Actividad Actividad Actividad Actividad Actividad Figura Diagrama de Actividad. Pág. 2-16
19 Diagrama de Componentes Los Diagramas de Componentes describen los elementos físicos y sus realizaciones en el entorno de realización. Un Diagrama de Componentes permite modelar la estructura del software y la dependencia entre componentes. Normalmente, un componente es un grupo de clases que trabajan estrechamente, pudiendo corresponder a código fuente, binario o ejecutable. Pero en general, los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas; pueden ser: simples archivos, paquetes de Ada, bibliotecas cargadas dinámicamente, etc. Por ejemplo: cada clase del modelo lógico se realiza en dos componentes: la especificación y el cuerpo.la especificación contiene el interfaz de la clase, mientras que el cuerpo contiene la realización de dicha clase. Las relaciones de dependencia se utilizan en los Diagramas de Componentes para indicar que un componente se refiere a los servicios ofrecidos por otro componente (ver Figura 2-11). Por otra parte, los distintos componentes pueden agruparse en paquetes, según un criterio lógico, para simplificar la implementación. Son paquetes estereotipados en <<subsistemas>> para incorporar la noción de biblioteca de compilación y de gestión de configuración. Los subsistemas organizan la vista de realización de un sistema. Cada subsistema puede contener componentes y otros subsistemas (la descomposición en subsistemas no es una descomposición funcional). La relación entre paquetes y clases en el nivel lógico es la correspondiente entre subsistemas y componentes en el nivel Componente Componente Componente Componente Componente físico. Figura Diagrama de Componentes. Pág. 2-17
20 Diagrama de Distribución Los Diagramas de Distribución muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. El Diagrama de Distribución modela la distribución en tiempo de ejecución de los elementos de procesamiento y componentes de software, con los procesos y objetos asociados. Modelan los nodos y la comunicación entre ellos. Nodo Componente Componente Componente Nodo Componente Componente Nodo Componente Componente Componente Proceso de Desarrollo Figura Diagrama de Distribución. UML no es una metodología. Dentro del proceso de solución de un problema, es el método subyacente el que sugiere cómo se utiliza el conocimiento para construir una solución. Esto incluye el sugerir qué diagramas se deben usar, y la perspectiva y el nivel de abstracción a emplear para trazar e interpretar dichos diagramas. Los métodos deberían considerarse como sugerencias y recomendaciones que organizan y facilitan el proceso de solución de un problema, más que ser considerados como reglas rígidas e inflexibles que restringen al arte de resolver problemas. UML no prescribe ningún enfoque en particular para resolver un problema, es muy flexible y personalizable para adaptarse a cualquier enfoque. Permite y promociona (pero no requiere ni ordena) un proceso conducido por casos de uso, centrado en la arquitectura, reiterativo, e incremental que sea orientado al objeto y basado en componentes: Los Casos de Uso se emplean para administrar y proveer de un enfoque a un problema. Expresan interacciones entre los roles de los usuarios del sistema (actores) y los subconjuntos de funcionalidad (casos de uso). Pág. 2-18
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 detallesPROGRAMACIÓ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 detalles3.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 detallesUNIDAD 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 detallesElementos 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 detalles1 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 detallesFigure 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 detallesProceso 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 detallesPatrones 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 detallesLa 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 detallesOMG 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 detallesIngenierí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 detallesEl proceso unificado en pocas palabras
El Proceso Unificado de Desarrollo de Software Ivar Jacobson Grady Booch James Rumbaugh Addison Wesley Resumen Capítulo 1. El proceso unificado: dirigido por casos de uso, centrado en la arquitectura,
Más detallesPROCESOS 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 detallesUML. Lenguaje de Modelado Unificado
Lenguaje de Modelado Unificado Concepto de Reseña Histórica Características Estándares que conforman Modelo Relacional con Ventajas Críticas Concepto de (Unified( Modeling language) Es un lenguaje usado
Más detallesMetodologí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 detallesPROGRAMACIÓ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 detallesIntroducció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 detallesCapitulo 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 detallesIngeniería de Software en SOA
Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia
Más detallesEstas visiones de la información, denominadas vistas, se pueden identificar de varias formas.
El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los
Más detallesApp 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 detallesPRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE
PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,
Más detallesTransformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN
Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Fernández Taurant, Juan Pablo Marciszack, Marcelo Martín Universidad Tecnológica Nacional, Facultad Regional
Más detallesService Oriented Architecture: Con Biztalk?
Service Oriented Architecture: Con Biztalk? Pablo Abbate Servicios Profesionales Danysoft SOA supone una nueva forma de pensar acerca de la arquitectura IT para las empresas. De hecho, es una asociación
Más detallesUniversidad 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 detallesCICLO DE VIDA DEL SOFTWARE
CICLO DE VIDA DEL SOFTWARE 1. Concepto de Ciclo de Vida 2. Procesos del Ciclo de Vida del Software 3. Modelo en cascada 4. Modelo incremental 5. Modelo en espiral 6. Prototipado 7. La reutilización en
Más detallesIWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1
IWG-101: Introducción a la Ingeniería Departamento de Informática, UTFSM 1 Introducción a UML Historia Potencialidades Diagramas soportados UML en el proceso de desarrollo de SW. Introducción a UML Necesidad
Más detallesSERVICE 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 detallesGestió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 detallesPrimer avance de proyecto de software para la gestión de inscripciones en cursos
Primer avance de proyecto de software para la gestión de inscripciones en cursos 1. Introducción Andrés Felipe Bustamante García, Carolina Sarmiento González En este documento se presentan los resultados
Más detallesEnterprise Analyst: Taller de Bautizo
Enterprise Analyst: Taller de Bautizo Metas Entender la Necesidad de Ejecutar los Modelos Desarrollar un caso usando UML tradicional Identificar los problemas de UML Conocer la Herramienta Enterprise Analyst
Más detalleshttp://www.informatizate.net
http://www.informatizate.net Metodologías De Desarrollo De Software María A. Mendoza Sanchez Ing. Informático - UNT Microsoft Certified Professional - MCP Analísta y Desarrolladora - TeamSoft Perú S.A.C.
Más detallesIntroducció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 detallesCapí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 detallesFundamentos 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 detallesTó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 detallesArquitectura 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 detallesModelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre
Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Cenditel, Mayo 2011 Licencia de Uso Copyright (c) 2010, Alvarez J., Solé S., Briceño R., Fundación CENDITEL. La Fundación CENDITEL
Más detallesCapítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente
Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.
Más detallesGuía Metodológica para el diseño de procesos de negocio
Guía Metodológica para el diseño de procesos de negocio La guía desarrollada para apoyar TBA, se diseñó con base en las metodologías existentes para el desarrollo BPM, principalmente en aquellas que soportan
Más detallesEnginyeria del Software III
Enginyeria del Software III Sessió 3. L estàndard ISO/IEC 15504 Antònia Mas Pichaco 1 Introducción El proyecto SPICE representa el mayor marco de colaboración internacional establecido con la finalidad
Más detallesTeCS. Sistema de ayuda a la gestión del desarrollo de producto cerámico
TeCS Sistema de ayuda a la gestión del desarrollo de producto cerámico En el origen de todo proyecto de éxito se halla la capacidad de encauzar y estructurar la creatividad TeCS ofrece un entorno de fácil
Más detallesM III ABSTRACCIÓN Y CLASIFICACIÓN
M III ABSTRACCIÓN Y CLASIFICACIÓN COMPLEJIDAD Y ABSTRACCIÓN La abstracción en el desarrollo del programario En todo el proceso de abstracción siempre hay una parte de la situación o del problema que se
Más detallesMetodologí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 detallesMetodologí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 detallesServidores Donantonio
Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3
Más detalles"Módulo OOWS para StarUML" INTRODUCCIÓN
UNA HERRAMIENTA PARA DIAGRAMAS OOWS: "Módulo OOWS para StarUML" Richard Medina Z. Universidad de Concepción, Chile INTRODUCCIÓN Una herramienta CASE (Computer Aided Software Engineering,
Más detallesInteracción Persona - Ordenador
Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición
Más detallesDIAGRAMA DE CLASES EN UML
DIAGRAMA DE CLASES EN UML Mg. Juan José Flores Cueto jflores@usmp.edu.pe Ing. Carmen Bertolotti Zuñiga cbertolotti@usmp.edu.pe INTRODUCCIÓN UML (Unified Modeling Language) es un lenguaje que permite modelar,
Más detallesLINEAMIENTOS 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 detallesIngenierí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 detallesObjetos educativos y estandarización en e-learning: Experiencias en el sistema <e-aula>
Objetos educativos y estandarización en e-learning: Experiencias en el sistema Fernández-Manjón, B.1, López Moratalla, J.2 Martínez Ortiz, I. 2, Moreno Ger, P. 2 Universidad Complutense de Madrid,
Más detallesM.T.I. Arturo López Saldiña
M.T.I. Arturo López Saldiña Hoy en día, existen diversas aproximaciones al tema de cómo hacer que las personas trabajen dentro de una organización de manera colaborativa. El problema se vuelve más difícil
Más detallesDiseñ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 detallesTutorial de UML. Introducción: Objetivos: Audiencia: Contenidos:
Tutorial de UML Introducción: El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende
Más detallesCAPÍTULO 5. DESARROLLO Y PRUEBAS
CAPÍTULO 5. DESARROLLO Y PRUEBAS 5.1 Introducción a las Tecnologías 5.1.1 Herramientas 5.1.1.1 SQL Server Es un sistema que sirve para la gestión de base de datos basado en un modelo relacional. Así mismo
Más detallesGeneXus BPM Suite X. Última actualización: 01 de Setiembre de 2008
Última actualización: 01 de Setiembre de 2008 Copyright Artech Consultores S. R. L. 1988-2008. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento
Más detallesIngeniería del Software I
- 1 - Ingeniería del Software I Introducción al Modelo Conceptual 2do. Cuatrimestre 2005 INTRODUCCIÓN... 2 CLASES CONCEPTUALES... 3 ESTRATEGIAS PARA IDENTIFICAR CLASES CONCEPTUALES... 3 Utilizar lista
Más detallesVisión General de GXportal. Ú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 detallesCapas del Modelo ISO/OSI
Modelo ISO/OSI Fue desarrollado en 1984 por la Organización Internacional de Estándares (ISO), una federación global de organizaciones que representa aproximadamente a 130 países. El núcleo de este estándar
Más detallesANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN
ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini
Más detallesDISEÑO DE FUNCIONES (TRATAMIENTOS)
DISEÑO DE FUNCIONES (TRATAMIENTOS) Diseño Estructurado. Estrategias para Derivar el Diagrama de Estructura. Diseño de Módulos Programables. 1. DISEÑO ESTRUCTURADO El Diseño es el proceso por el cual se
Más detallesQué 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 detallesGLOSARIO. 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 detallesEntidad 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 detallesUna base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa.
BASES DE DATOS Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. La creación de una base de datos debe ser realizada cuidadosamente procurando
Más detallesCiclo 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 detallesEl Proceso Unificado Rational para el Desarrollo de Software.
Instituto de Electrónica y Computación El Proceso Unificado Rational para el Desarrollo de Software. Carlos Alberto Fernández y Fernández Huajuapan de León, Oaxaca 26 de octubre de 2000 Objetivo Proporcionar
Más detallesARQUITECTURA 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 detallesPatrones 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 detallesCAPÍ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 detallesDiagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases
El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los
Más detallesUnidad 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 detallesTEMA 3. EL PROCESO DE COMPILACIÓN, DEL CÓDIGO FUENTE AL CÓDIGO MÁQUINA
TEMA 3. EL PROCESO DE COMPILACIÓN, DEL CÓDIGO FUENTE AL CÓDIGO MÁQUINA Programa: Algoritmo (secuencia no ambigua, finita y ordenada de instrucciones para la resolución de un determinado problema) traducido
Más detalles3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE
3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar
Más detallesCURSO COORDINADOR INNOVADOR
CURSO COORDINADOR INNOVADOR PRESENTACIÓN La tarea que el Ministerio de Educación se propone a través de Enlaces, en relación al aseguramiento del adecuado uso de los recursos, con el fin de lograr un impacto
Más detallesCAPÍ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 detallesPlanificación en Team Foundation Server 2010
Planificación en Team Foundation Server 2010 Planificación y Seguimientos en Proyectos Agile con Microsoft Visual Studio Team Foundation Server 2010 Dirigido a: Todos los roles implicados en un proyecto
Más detallesCorrespondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech
Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech Resumen Todo documento XBRL contiene cierta información semántica que se representa
Más detallesCMMI (Capability Maturity Model Integrated)
CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla
Más detallesService 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 detallesEmpresa Financiera Herramientas de SW Servicios
Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través
Más detallesGerencia 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 detallesGestió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 detallesCurso: Arquitectura Empresarial basado en TOGAF
Metodología para desarrollo de Arquitecturas (ADM) El ADM TOGAF es el resultado de las contribuciones continuas de un gran número de practicantes de arquitectura. Este describe un método para el desarrollo
Más detallesEn un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuando y Como hacerlo. 6
2. MÉTODO, METODOLOGÍA Y MÉTRICA 2.1 MÉTODO Un método de ingeniería del software es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de alta
Más detallesUnidad III. Software para la administración de proyectos.
Unidad III Software para la administración de proyectos. 3.1 Herramientas de software para administrar proyectos. El software de administración de proyectos es un concepto que describe varios tipos de
Más detallesIBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos
ZP09-0207, con fecha 2 de junio de 2009 IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos Índice 1 Resumen de características
Más detallesGestión de Configuración del Software
Gestión de Configuración del Software Facultad de Informática, ciencias de la Comunicación y Técnicas Especiales Herramientas y Procesos de Software Gestión de Configuración de SW Cuando se construye software
Más detallescomunidades de práctica
1. Introducción CoSpace es una plataforma web diseñada para proporcionar un espacio virtual de interacción y colaboración entre formadores en comunidades virtuales. Se originó como resultado de las necesidades
Más detallesGLOSARIO. Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de
GLOSARIO Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de una descripción de bajo nivel (código fuente) para generar descripciones con un mayor grado de abstracción.
Más detallesFormularios. Formularios Diapositiva 1
Formularios Crear un formulario utilizando el Asistente para formularios Modificación en vista Diseño Adición de Controles a un Formulario Adición de un Subformulario a un formulario Formularios Diapositiva
Más detallesBPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola
BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del
Más detallesIntroducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com
Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad.
Más detallesDecisión: Indican puntos en que se toman decisiones: sí o no, o se verifica una actividad del flujo grama.
Diagrama de Flujo La presentación gráfica de un sistema es una forma ampliamente utilizada como herramienta de análisis, ya que permite identificar aspectos relevantes de una manera rápida y simple. El
Más detallesEl modelo de ciclo de vida cascada, captura algunos principios básicos:
Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada",
Más detallesMetodologí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 detallesIntroducció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