7.1 Arquitectura de clases

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "7.1 Arquitectura de clases"

Transcripción

1 7.1 Arquitectura de clases El modelo de analisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diserio del sistema. Como se discutio en el capitulo 3, dependiendo del tipo de aplicacion existen cliversas arquitecturas que se pueden utilizar, en este libro nos centraremos en aquellas arquitecturas especialmente disenaclas para el mane jo de los sistemas de information, las cuales involucran la manipulacion de la informacion guardada en bases de datos a partir de interfaces de usuario. Las arquitecturas se distinguen segun la organizacion de los objetos de acuerdo a su funcionalidad. Esto es tambien conocido como la dimension de la arquitectura. For ejemplo, si existe un grupo de objetos para el manejo de la funcinalidad cle la aplicacion y otro para interactuar con las entidades externas de la aplicacion, como el usuario y las bases de datos, entonces se considera que la arquitectura es de dos dimensiones. For el contrario, si existe un solo grupo de objetos que maneja de manera inclistinta la funcionalidad junto con la interaccion externa, entonces se considera que la arquitectura es de una sola dimension. En general, una arquitectura puecle incluir cualquier numero de dimensiones, algo que depencle del tipo de aplicacion que se desee desarrollar. En general, el planteamiento es: si se diseria un sistema con cierto ncimero de dimensiones, ^;se obtendna un sistema mas estable y facil de extender que con un numero menor o mayor? La respuesta clepende de que tan indepencliente sean los objetos de un eje de funcionalidad con los demas. Si se cuenta con ejes de funcionalidad completamente ortogonales, algo que es dificil de lograr, el efecto de cambios en una dimension no deberia afectar a las demas dimensiones. Sin embargo, si los grupos de objetos no son lo suficientemente independientes, aun se puede limitar el efecto de los posibles cambios. En el caso de los sistemas de informacion, una cle las arquitecturas mas utilizadas es la de Modelo, Vista, Control (MVC - Model, View, Control)? popularizada por los ambientes de desarrollo para los lenguajes de programacion de Smalltalk (ver capitulo 2). Esta arquitectura se basa en tres dimensiones principales: Modelo correspondiente a la informacion, Vista correspondiente a la presentation o interaccion con el usuario y Control correspondiente al comportamiento, como se ilustra en la figura 7.2. Figura 7.2 Diagrama de tres dimensiones correspondiente a la arquitectura Modelo, Vista, Control (MVC). 254 CAP. 7 MODELO DE ANALISIS

2 La vista o presentacion de la informacion corresponde a las interfaces que se le presentan at^usuario para el manejo de la informacion, donde por lo general pueden existir multiples vistas sobre un mismo moclelo. Tipicamente la informacion representa el dominio del problema y se almacena en una base cte clatos. Por otro lado, el control corresponde a la manipulacion cle la informacion a traves de sus cliversas presentaciones. Aunque existe cierta depenclencia entre estas tres dimensiones, se considera que la manera de presentar la informacion es independiente de la propia informacion y de como se controla esta. Sin embargo, cacla una de ellas probablemente experimente cambios a lo largo del ciclo cle vida del sistema, donde el control es el mas propenso a ser modificado, seguido cie la vista y, finalmente, del moclelo. En el moclelo de analisis descrito aqui utilizaremos como base la arquitectura MVC para capturar estos tres aspectos cle la funcionaliclad, como se muestra en la figura 7.3. Figura 7.3 Diagrama de tres dimensiones correspondiente a la arquitectura del modelo de analisis, basado en el modelo de casos de uso. En correspondencia con el modelo MVC, la arquitectura para el modelo de analisis se basara en tres tipos o estereotipos de objetos corresponclientes a las tres dimensiones anteriores. Es importante notar la correspondencia con las tres dimensiones utilizadas durante el modelo cle requisites (ver figura 6.2) Clases con estereotipos El tipo cle funcionalidad o "la razon cle ser" cle un objeto clentro de una arquitectura se conoce como su estereotipo. Siguienclo la metodologia de casos de uso, la arquitectura del sistema para el modelo de analisis se basara en tres estereotipos: El estereotipo entidad (entity) para los objetos que guardan informacion sobre el estado interno del sistema a corto y largo plazo. Estos objetos corresponden al clominio del problema. Un ejemplo de objeto entidad es un registro de usuario con sus clatos y comportamiento asociados. El estereotipo horde (boundary) para objetos que implementan las interfaces del sistema con el munclo externo, correspondientes a todos los actores, incluyendo a aquellos que no son humanos. Un ejemplo de objeto borde es una interface cle usuario o pantalla para insertar o modificar informacion en el registro de usuario. Otro ejemplo es un objeto que se comunica con una base cle clatos externa al sistema. ARQUITECTURA DE CLASES 255

3 El estereotipo control (control) para objetos que implementan el comportamiento o control de la logica de los casos de uso, especificando cuando y como el sistema cambia de estado. Los objetos control modelan la funcionalidad que no se asocia naturalmente con un solo objeto. Un ejemplo tipico de objeto control es validar un usuario existente o insertar uno nuevo. Este comportamiento requiere la interaccion de multiples objetos y actores. La notacion de UML para un estereotipo se muestra en la figura 7.4. Figura 7.4 Diagrama de clase con estereotipo utilizando la notacion de UML. Los tres estereotipos, Entidad, Borde y Control, correspondientes a las tres dimensiones de la arquitectura de analisis, se ilustran en la figura 7.5. Figura 7.5 Diagrama de clase para los tres estereotipos. Los tres estereotipos de la arquitectura de analisis se pueden describir a traves de diagramas de iconos en lugar de rectangulos, se muestran como iconos en la figura 7.6. Figura 7.6 Diagrama de clases mostrando los tres estereotipos como iconos: entidad, borde y control, respectivamente. Es dificil lograr una ortogonalidad completa de estereotipos en los objetos. En general, es comun que un objeto tenga cierta inclinacion hacia una de las dimensiones, como se muestra en la figura CAP. 7 MODELO DE ANALISIS

4 Figura 7.7 Diagrama que ilustra el traslape en las dimensiones de los objetos correspondientes a sus estereotipos Clases para casos de uso Cuando se desarrolla el modelo de analisis, normalmente se trabaja con un caso de uso a la vez. En cada caso de uso se identifican los objetos necesarios para su implementacion. Los objetos se identifican segun sus estereotipos de manera que correspondan con la funcionalidad ofrecida en cada uno. Se define explicitamente que objeto es responsable de cual comportamiento dentro del caso de uso. Se comienza identificando los objetos borde necesarios, continuando con los objetos entidad y, finalmente, los objetos control. Este proceso se continua a los demas casos de uso. Dado que los mismos objetos pueden participar en varios casos de uso, durante este proceso es necesario identificar aquellos objetos comunes. Esto significa que cuando un conjunto de objetos ya existe, estos pueden modificarse para ajustarlos al nuevo caso de uso. La meta es formar una arquitectura que reutilice el mayor numero de objetos posible. De tal manera, la descripcion original de los casos de uso se transforma en una descripcion con base en los tres tipos de objetos, como se muestra en la figura 7.8. Figura 7.8 La funcionalidad de cada caso de uso se asigna a objetos distintos y de acuerdo con sus estereotipos. ARQUITECTURA DE CLASES 257

5 La asignacion de objetos a cada caso de uso se hace de acuerdo con los siguientes principios: La funcionalidad de los casos de uso que depende directamente de la interaccion del sisterna con el mundo externo se asigna a los objetos borde. La funcionalidad relacionada con el almacenamiento y manejo de informacion del dominio del problema se asigna a los objetos entidad. La funcionalidad especifica a uno o varios casos de uso y que afecta a multiples objetos a la vez, o que no se relaciona naturalmente con ningun objeto borde o entidad, se asigna a los objetos control. En general, se asigna un solo objeto control por caso de uso. Si el caso de uso es muy complejo, se pueden asignar objetos control adicionales. 7.2 Identification de clases segun estereotipos Para llevar a cabo la transicion del modelo de requisites al modelo de analisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos como se discutio anteriormente. Para ello, se deben identificar primero las clases borde, luego las clases entidad y, finalmente, las de control. En general, se desea asignar la funcionalidad general del caso de uso, correspondiente a la "politica" de la aplicacion, a los objetos control. Esta funcionalidad depende y afecta al resto de los objetos dentro del caso de uso. Por otro lado, los objetos entidad y borde deben contener funcionalidad local, limitando su efecto en los demas objetos. El trabajo del analista consiste en distribuir de la mejor manera posible el comportamiento especificado en el modelo de requisites entre los diferentes tipos de objetos de la arquitectura de analisis. La asignacion de funcionalidad es bastante dificil en la practica, y afecta en gran medida la calidad y mantenimiento del sistema. Los buenos analistas consideran desde un principio los posibles cambios futuros al sistema. En general, los cambios mas comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo a los objetos borde. Los cambios a la funcionalidad son mas dificiles de administrar, ya que esta puede abarcar todos los tipos de objetos. En las siguientes secciones se describira con mayor detalle el proceso de identificacion de los tres tipos de objetos, identificando las clases para cada caso de uso segun sus estereotipos. El desafio principal en dicho proceso, es decidir cuantas y cuales clases deben asignarse por caso de uso Borde Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a traves de ellos se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una 258 CAP. 7 MODELO DE ANALISIS

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

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

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

Casos de uso UML. Miguel Vega mvega@ugr.es. Granada, octubre de 2010 LSI - UGR

Casos de uso UML. Miguel Vega mvega@ugr.es. Granada, octubre de 2010 LSI - UGR Especificación de UML Miguel Vega mvega@ugr.es LSI - UGR Granada, octubre de 2010 Especificación de Contenido 1 Introducción 2 3 Especificación de Contenido Plantilla de especificación Un ejemplo 4 5 Especificación

Más detalles

ESTÁNDAR DIAGRAMA DE SECUENCIA

ESTÁNDAR DIAGRAMA DE SECUENCIA ESTÁNDAR DIAGRAMA DE SECUENCIA Un diagrama de secuencia muestra las interacciones entre objetos ordenadas en secuencia temporal. Muestra los objetos que se encuentran en el escenario y la secuencia de

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

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

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

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

Patrones de Diseño Orientados a Objetos 2 Parte

Patrones de Diseño Orientados a Objetos 2 Parte Patrones de Diseño Orientados a Objetos 2 Parte Patrón Observador Observer (Patrón de Comportamiento) Patrón Observador Observer Observador (en inglés: Observer) es un patrón de diseño que define una dependencia

Más detalles

Historia de revisiones

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

Más detalles

CAPITULO V. HERRAMIENTA CASE (Rational Rose, C++)

CAPITULO V. HERRAMIENTA CASE (Rational Rose, C++) CAPITULO V HERRAMIENTA CASE (Rational Rose, C++) 5.1 HERRAMIENTA CASE La documentación del UML ha propiciado el desarrollo de herramientas CASE, las cuales cubren el ciclo de vida del software y además

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

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

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

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

INGENIERÍA DEL SOFTWARE I. Univ. Cantabria Fac. de Ciencias. Especificación de Requisitos. Práctica 2

INGENIERÍA DEL SOFTWARE I. Univ. Cantabria Fac. de Ciencias. Especificación de Requisitos. Práctica 2 INGENIERÍA DEL SOFTWARE I Práctica 2 Especificación de Requisitos Univ. Cantabria Fac. de Ciencias María Sierra y Patricia López Nociones de UML para Requisitos: Casos de Uso Caso de Uso Una descripción

Más detalles

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

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

Más detalles

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

Anexo 4 Documento de Arquitectura

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

Más detalles

TECNOLOGÍA DE LA SÍNTESIS DE PROCESOS

TECNOLOGÍA DE LA SÍNTESIS DE PROCESOS TECNOLOGÍA DE LA SÍNTESIS DE PROCESOS La tecnología de procesos juega un papel importante en la industria química y de hidrocarburos, mejora la utilidad económica de un proceso, una vez puesto en operación.

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática Modelado Avanzado con Casos de Uso Especificación Gráfica de Casos de Uso Una simple secuencia de acciones no puede describir adecuadamente la riqueza de situaciones que se pueden presentar en un caso

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

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

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

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

Casos de Uso Diagramas de Casos de Uso. Universidad de los Andes Demián Gutierrez Abril 2011 1

Casos de Uso Diagramas de Casos de Uso. Universidad de los Andes Demián Gutierrez Abril 2011 1 Casos de Uso Diagramas de Casos de Uso Universidad de los Andes Demián Gutierrez Abril 2011 1 Casos de Uso ( Qué es un caso de uso?) Caso de Uso? 2 Casos de Uso ( Qué es un caso de uso?) Un caso de uso

Más detalles

Guía para la elaboración de Proyectos de Formación Sindical Ambiental e Investigación en Trabajo y Desarrollo Sustentable

Guía para la elaboración de Proyectos de Formación Sindical Ambiental e Investigación en Trabajo y Desarrollo Sustentable Guía para la elaboración de Proyectos de Formación Sindical Ambiental e Investigación en Trabajo y Desarrollo Sustentable 1- Denominación del Proyecto Esto se hace indicando, de manera sintética y mediante

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

Modulo I. Introducción a la Programación Web. 1.1 Servidor Web.

Modulo I. Introducción a la Programación Web. 1.1 Servidor Web. Modulo I. Introducción a la Programación Web. 1.1 Servidor Web. Antes de analizar lo que es un servidor Web y llevara a cabo su instalación, es muy importante identificar diferentes elementos involucrados

Más detalles

Instructivo para la elaboración de un Manual Técnico

Instructivo para la elaboración de un Manual Técnico Instructivo para la elaboración de un Manual Técnico Autora: Ing. Alena González Reyes. (agonzalez@ceis.cujae.edu.cu) Ciudad de la Habana, Cuba Marzo, 2010 Índice 1. Introducción... 3 2. Confección...

Más detalles

Tabla de contenido 1. OBJETIVOS... 2 2. ASIGNACION DE RESPONSABILIDADES... 2 3. ROLES Y TAREAS... 3 4. ALCANCE... 4

Tabla de contenido 1. OBJETIVOS... 2 2. ASIGNACION DE RESPONSABILIDADES... 2 3. ROLES Y TAREAS... 3 4. ALCANCE... 4 Tabla de contenido 1. OBJETIVOS... 2 2. ASIGNACION DE RESPONSABILIDADES... 2 3. ROLES Y TAREAS... 3 4. ALCANCE... 4 5. PROCEDIMIENTOS RELACIONADOS... 4 6. DOCUMENTOS RELACIONADOS... 4 7. PROCESO... 4 7.1.

Más detalles

ANOTACIONES PARA LA PRESENTACIÓN

ANOTACIONES PARA LA PRESENTACIÓN DIAPOSITIVA Nº2 Cada vez más gente tiene horario de oficinas y necesitan comer en el trabajo, o bien porque no les da tiempo de ir a casa o bien porque no tienen tiempo o habilidades para gestionar su

Más detalles

UML, ejemplo sencillo sobre Modelado de un Proyecto

UML, ejemplo sencillo sobre Modelado de un Proyecto UML, ejemplo sencillo sobre Modelado de un Proyecto Normal &DOLILFDU 0L3DQRUDPD 626 (VFULEHSDUD1RVRWURV Por Armando Canchala Contenido Introducción Objetivo Requerimientos Casos de Uso Subcasos de Uso

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

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

CAPÍTULO 3 DISEÑO DE LA ARQUITECTURA

CAPÍTULO 3 DISEÑO DE LA ARQUITECTURA CAPÍTULO 3 DISEÑO DE LA ARQUITECTURA Para el desarrollo de la arquitectura interna del subsistema de programación de actividades se utilizó como referencia la Arquitectura de Aplicaciones.NET 105 de Microsoft

Más detalles

Manual de usuario Software PC Editor de Rutas. inled

Manual de usuario Software PC Editor de Rutas. inled Manual de usuario Software PC Editor de Rutas. Manual de usuario Software PC Editor de Rutas. Agregar una Ruta 01 Texto Fijo e Icono 04 Guardar Archivo Creado 06 Modelo de Itinerario 07 Edición de Icono

Más detalles

Capítulo 4. Implementación del lenguaje multitáctil

Capítulo 4. Implementación del lenguaje multitáctil Capítulo 4. Implementación del lenguaje multitáctil En este capítulo se presenta como fue diseñado y desarrollado el servicio de ademanes multitáctiles. Se presentan la arquitectura general del sistema,

Más detalles

DCU Diagramas de casos de uso

DCU Diagramas de casos de uso DCU Diagramas de casos de uso Universidad de Oviedo Departamento de Informática Contenidos Introducción Elementos básicos Más sobre los actores Más sobre los casos de uso Más sobre las asociaciones Otros

Más detalles

ENCUENTA - CONTABILIDAD Net. Definiciones generales

ENCUENTA - CONTABILIDAD Net. Definiciones generales ENCUENTA - CONTABILIDAD Net Definiciones generales 2013 ENCUENTA - CONTABILIDAD Net Definiciones generales Contenido 1 GENERALIDADES... 3 2 DISTRIBUCIÓN GENERAL DE LOS ELEMENTOS DEL SISTEMA... 3 3 REQUERIMIENTOS...

Más detalles

1. I N T R O D U C C I Ó N 2 2. O B J E T I V O S 9 3. C O M P E T E N C I A S B Á S I C A S 1 1 4. C O N T E N I D O S 1 2

1. I N T R O D U C C I Ó N 2 2. O B J E T I V O S 9 3. C O M P E T E N C I A S B Á S I C A S 1 1 4. C O N T E N I D O S 1 2 Í N D I C E 1. I N T R O D U C C I Ó N 2 1. 1. J u s t i f i c a c i ó n 2 1. 2. E n t o r n o e d u c a t i v o 6 2. O B J E T I V O S 9 3. C O M P E T E N C I A S B Á S I C A S 1 1 4. C O N T E N I D

Más detalles

Documento de Arquitectura de Software. KunaySoft. Autores: Juan Camilo González Vargas. Javier Leonardo Parra Laguna

Documento de Arquitectura de Software. KunaySoft. Autores: Juan Camilo González Vargas. Javier Leonardo Parra Laguna Documento de Arquitectura de Software KunaySoft Autores: Juan Camilo González Vargas Javier Leonardo Parra Laguna Pontificia Universidad Javeriana Bogotá, Colombia Noviembre 2014 Tabla de contenido 1.

Más detalles

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes Capítulo 4 Arquitectura para análisis de información propuesta 4.1 Arquitectura Zombi es una arquitectura que proporciona de manera integrada los componentes necesarios para el análisis de información

Más detalles

Arquitectura de Proyectos de IT

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

Más detalles

Interacción Persona - Ordenador

Interacció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 detalles

1. Cuál es el objetivo del proceso de Análisis del Sistema de Información? del sistema. a. 10. b. 12. c. 9. d. 11. Análisis

1. Cuál es el objetivo del proceso de Análisis del Sistema de Información? del sistema. a. 10. b. 12. c. 9. d. 11. Análisis 1. Cuál es el objetivo del proceso de del Sistema de Información? a. La obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios

Más detalles

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases

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

Caso empresa ELÉCTRICA S.A.

Caso empresa ELÉCTRICA S.A. 1 Caso empresa ELÉCTRICA S.A. Eléctrica es una empresa dedicada a la venta de artículos Esta empresa cuenta con diferentes puntos de venta. Cada punto de venta cuenta con cajeros, vendedores y su propio

Más detalles

MANUAL DE REGISTRO DE TALLER DE HABILIDADES LINGÜISTICAS 1 MANUAL DE INSCRIPCION AL TALLER DE HABILIDADES LINGÜISTICAS

MANUAL DE REGISTRO DE TALLER DE HABILIDADES LINGÜISTICAS 1 MANUAL DE INSCRIPCION AL TALLER DE HABILIDADES LINGÜISTICAS MANUAL DE REGISTRO DE TALLER DE HABILIDADES LINGÜISTICAS 1 MANUAL DE INSCRIPCION AL TALLER DE HABILIDADES LINGÜISTICAS MANUAL DE REGISTRO DE TALLER DE HABILIDADES LINGÜISTICAS 2 INDICE 1.- INGRESO EL SISTEMA....

Más detalles

6.6 DISEÑO. [Proceso]

6.6 DISEÑO. [Proceso] 6.6 DISEÑO. [Proceso] Durante un Ciclo de Desarrollo iterativo es posible pasar a la Fase de Diseño una vez completada la documentación de la fase de Análisis. Durante esta etapa se desarrolla una solución

Más detalles

ZCBC. ECBTI. Programa Ingeniería de Sistemas. Curso Académico de Programación Orientada a Objetos. Código José Acevedo y Gómez

ZCBC. ECBTI. Programa Ingeniería de Sistemas. Curso Académico de Programación Orientada a Objetos. Código José Acevedo y Gómez ZCBC. ECBTI. Programa Ingeniería de Sistemas Curso Académico de Programación Orientada a Objetos Código 301403 José Acevedo y Gómez Programación Orientada a Objetos Unidad II Requisitos y Análisis Unidad

Más detalles

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

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

Documento de Arquitectura de Software

Documento de Arquitectura de Software Documento de Arquitectura de Software Anexo 9 2014 - I Pontificia Universidad Javeriana - Bogotá Alex Arias 1. Introducción El presente documento describe la arquitectura utilizada para la implementación

Más detalles

Capítulo 4. Prueba de Adaptabilidad

Capítulo 4. Prueba de Adaptabilidad Capítulo 4 Prueba de Adaptabilidad Capítulo 4. Prueba de Adaptabilidad Como se mencionó en el capítulo 2 actualmente no es válido que el software únicamente funcione bien y resuelva el problema que le

Más detalles

Capítulo V. Implementación

Capítulo V. Implementación Capítulo V Implementación En este capítulo se especifican los recursos utilizados en la implementación de la interfaz, así como se describe su arquitectura funcional y las características principales.

Más detalles

El Software. Es lo que se conoce como el ciclo de vida del software.

El Software. Es lo que se conoce como el ciclo de vida del software. El Software Hace referencia a los programas y toda la información asociada y materiales necesarios para soportar su instalación, operación, reparación, y mejora. Para construir un nuevo elemento software

Más detalles

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

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

Más detalles

ASI. Análisis del Sistema de Información

ASI. Análisis del Sistema de Información ASI Análisis del Sistema de Información 1 ASI Análisis del Sistema de Información Introducción Objetivo Obtención de una especificación detallada del Sistema Información a través de: Catálogo de Requisitos

Más detalles

Modelo de Proceso: Ciclo de Vida Estructurado

Modelo de Proceso: Ciclo de Vida Estructurado Modelo de Proceso: Ciclo de Vida Estructurado Edward Yourdon (1999) Análisis Estructurado Moderno EL CICLO DE VIDA ESTRUCTURADO DEL PROYECTO Es importante verlo como un diagrama de flujo de datos. No es

Más detalles

Ingeniería de Software

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

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Fundamentos de Ingeniería del Software Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Cap 3. Análisis de Requisitos Estructura 1. Actividades iniciales. 2. Técnicas de recogida de la

Más detalles

V. CAPÍTULO: CONTRIBUCIÓN

V. CAPÍTULO: CONTRIBUCIÓN V. CAPÍTULO: CONTRIBUCIÓN Requerimientos del Sistema Para llevar a cabo el desarrollo de nuestro sistema se establecieron tanto los actores como los requerimientos funcionales y no funcionales del sistema.

Más detalles

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño El proceso de diseño para una base de datos consta básicamente de 7 pasos, los cuáles se describen en la siguiente imagen.

Más detalles

UNIDAD DIDACTICA 2 Lenguaje Unificado de Modelado(UML) 1. INTRODUCCIÓN Y TIPOS DE DIAGRAMAS

UNIDAD DIDACTICA 2 Lenguaje Unificado de Modelado(UML) 1. INTRODUCCIÓN Y TIPOS DE DIAGRAMAS UNIDAD DIDACTICA 2 Lenguaje Unificado de Modelado(UML) 1. INTRODUCCIÓN Y TIPOS DE DIAGRAMAS 1.1 Qué es el UML? UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar

Más detalles

EJ_SA. Ejemplo Sistema de Acceso

EJ_SA. Ejemplo Sistema de Acceso EJ_SA Ejemplo Sistema de Acceso 1 2 "Aplicación de control de acceso" Requisitos / Descripción del sistema Se dispone de un espacio a ser protegido que se haya compuesto de 4 pisos. El área total es de

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

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

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

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

Más detalles

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

Descripción del tutorial. Contenidos. www.facebook.com/codigonexogr. @codigonexo. www.plus.google.com/+codigonexogr/

Descripción del tutorial. Contenidos. www.facebook.com/codigonexogr. @codigonexo. www.plus.google.com/+codigonexogr/ www.facebook.com/codigonexogr @codigonexo www.plus.google.com/+codigonexogr/ Contenidos 1. Introducción al patrón MVC 1.1.Conceptos básicos Qué es un patrón 1.2.Estructura del patrón MVC 1.3.Cómo funciona

Más detalles

Elementos del modelo de análisis. Modelado del análisis

Elementos del modelo de análisis. Modelado del análisis Mecanismos del anál. Ingeniería del Software 1 Elementos del modelo de análisis Objetivos Describir lo que requiere el cliente Establecer base para la creación de un diseño SW Definir conjunto de requisitos

Más detalles

1. Cuál es el objetivo del Diseño del Sistema de Información? del sistema. información. a. 5. b. 4. c. 3. d. 2. c. Diseño de. b.

1. Cuál es el objetivo del Diseño del Sistema de Información? del sistema. información. a. 5. b. 4. c. 3. d. 2. c. Diseño de. b. 1. Cuál es el objetivo del Diseño del Sistema de Información? a. La definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte junto con la especificación detallada de

Más detalles

EL PROCESO DE DISEÑO DEL SOFTWARE

EL PROCESO DE DISEÑO DEL SOFTWARE UNIDAD VI EL PROCESO DE DISEÑO DEL SOFWARE Contenido: 6.1 El diseño en la Ingeniería de Software 6.2 El proceso de Diseño 6.3 Fundamentos de Diseño 6.4 Diseño de Datos 6.5 Diseño Arquitectónico 6.6 Diseño

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

Capítulo 4 Análisis y diseño del software de los Robots

Capítulo 4 Análisis y diseño del software de los Robots Capítulo 4 Análisis y diseño del software de los Robots En el capítulo del diseño mecánico de los robots se muestran los distintos sensores que se utilizarán como entradas, así como los motores que deberán

Más detalles

Orientación acerca del enfoque basado en procesos para los sistemas de gestión de la calidad

Orientación acerca del enfoque basado en procesos para los sistemas de gestión de la calidad Orientación acerca del enfoque basado en procesos para los sistemas de gestión de la calidad Documento: ISO/TC 176/SC 2/N 544R Mayo 2001 ISO Traducción aprobada el 2001-05-31 Prólogo de la versión en español

Más detalles

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a 5. METODOLOGIAS COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a incrementar su valor a través de las tecnologías, y permite su alineamiento con los objetivos del negocio

Más detalles

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos 65 CAPITULO 3 DISEÑO 3.1. DISEÑO El diseño del software es el proceso que permite traducir los requisitos analizados de un sistema en una representación del software. 66 Diseño procedural Diseño de la

Más detalles

Especificación de Requerimientos Funcionales y No Funcionales. Sistema Reservación Hotelera

Especificación de Requerimientos Funcionales y No Funcionales. Sistema Reservación Hotelera Funcionales y No Funcionales Sistema Reservación Hotelera Grupo N. XX Integrantes del Grupo Wenfri Grijalba Villegas. Kevin Jimenez Baltodano. Luis Mauricio Chavarria Perez. Fecha 19/05/15 Historia de

Más detalles

ELABORACIÓN DE TABLEROS DINÁMICOS DE COMUNICACIÓN CON EL PROGRAMA EDITOR TICO

ELABORACIÓN DE TABLEROS DINÁMICOS DE COMUNICACIÓN CON EL PROGRAMA EDITOR TICO ELABORACIÓN DE TABLEROS DINÁMICOS DE COMUNICACIÓN CON EL PROGRAMA (Tico 2.0) EDITOR TICO La idea principal que motivo este proyecto fue trasladar la definición tradicional de tablero de comunicación en

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

Consultoría Santa Cruz. Buscador Web de Restaurants Software Architecture Document. Version 1.0

Consultoría Santa Cruz. Buscador Web de Restaurants Software Architecture Document. Version 1.0 Consultoría Santa Cruz Buscador Web de Restaurants Version 1.0 Revision History Date Version Description Author 29/enero/2015 1.0 Primera versión : Buscador Web de Restaurants Rodríguez Vázquez Cristhian

Más detalles

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

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

Más detalles

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

Modelo Entidad-Relación

Modelo Entidad-Relación Modelo Entidad-Relación El modelo de datos de entidad-relación (ER) se basa en una percepción de un mundo real que consiste en un conjunto de objetos básicos llamados entidades y de relaciones entre estos

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

En este capítulo se describe las herramientas, así como los procesos involucrados en el análisis y desarrollo de sistemas de información, por otro

En este capítulo se describe las herramientas, así como los procesos involucrados en el análisis y desarrollo de sistemas de información, por otro CAPITULO 5 TEORIA SOBRE ANALISIS Y DISEÑO DE SISTEMAS DE INFORMACION En este capítulo se describe las herramientas, así como los procesos involucrados en el análisis y desarrollo de sistemas de información,

Más detalles

Programación de Aplicaciones Tarea 2 Curso 2015

Programación de Aplicaciones Tarea 2 Curso 2015 Programación de Aplicaciones Tarea 2 Curso 2015 Información Administrativa La tarea comienza el lunes 14 de setiembre y finaliza el lunes 19 de octubre. La tarea constará de múltiples entregas parciales

Más detalles

UML. Diagramas de Estados Diagrama de Actividades (UML Ilustrado) Universidad de los Andes Demián Gutierrez Mayo 2011 1

UML. Diagramas de Estados Diagrama de Actividades (UML Ilustrado) Universidad de los Andes Demián Gutierrez Mayo 2011 1 UML Diagramas de Estados Diagrama de Actividades (UML Ilustrado) Universidad de los Andes Demián Gutierrez Mayo 2011 1 Diagramas de Estados Diagramas de Estados 2 Diagramas de Estados ( Qué Muestran?)

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

Diseño y desarrollo de el Generador de Tiendas virtuales usando Líneas de Diseño de productos

Diseño y desarrollo de el Generador de Tiendas virtuales usando Líneas de Diseño de productos Pontificia Universidad Javeriana Informe Final Proyecto Dirigido Diseño y desarrollo de el Generador de Tiendas virtuales usando Líneas de Diseño de productos Autor: Luis Gabriel Rodríguez Profesora: Luisa

Más detalles

ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Resumen

ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Resumen ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Sergio Valero Orea, svalero@utim.edu.mx, UTIM, Izúcar de Matamoros, Puebla. Resumen El desarrollo de sistemas

Más detalles

Programa de Cátedra Desarrollo de Aplicaciones Cliente Servidor

Programa de Cátedra Desarrollo de Aplicaciones Cliente Servidor Programa de Cátedra Desarrollo de Aplicaciones Cliente Servidor Profesor: Ing Martin I. Scattini Aux: Ing. Lucas Kloster Índice Análisis de la materia... 3 Objetivos... 3 Programa sintético... 3 Programa

Más detalles

Transformació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 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 detalles

Carrera: SCM - 0406 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos.

Carrera: SCM - 0406 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos Desarrollo de proyectos de software Ingeniería en Sistemas Computacionales SCM

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

PREGUNTAS FRECUENTES DEL SISTEMA DE FONDOS

PREGUNTAS FRECUENTES DEL SISTEMA DE FONDOS PREGUNTAS FRECUENTES DEL SISTEMA DE FONDOS 1. EL SISTEMA NO ME PERMITE INGRESAR CON MI USUARIO Y CONTRASEÑA... 2 2. CÓMO ACCEDO A MI SOLICITUD?... 9 3. PARA QUÉ SIRVEN LAS LUPAS?...15 4. EXISTEN LIMITANTES

Más detalles

Desarrollo de Software con

Desarrollo de Software con Desarrollo de Software con Antonio J. Vélez Q. Universidad del Valle Sede Palmira Contenido Modelo de Aplicaciones Java EE Arquitectura de las aplicaciones JEE Comunicación entre componentes Contenedores

Más detalles

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

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

Más detalles