Patrones Arquitectónicos

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

Download "Patrones Arquitectónicos"

Transcripción

1 Diseño de Sistemas Curso: 3K3 Unidad: 2 - Diapositivas de clases Docentes: Ing. Marcela F. Cattaneo Ing. María Irene Mac William Ing. Germán Vélez Ing. Claudia Sánchez Arquitectura de Software Revisión de Concepto La Arquitectura del Software de un sistema de cómputo es la estructura o las estructuras del sistema que incluyen los componentes del software, las propiedades visibles externamente de esos componentes y las relaciones entre ellos (L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, Addison-Wesley, 2003) La Arquitectura se define como la organización fundamental de un sistema, incluyendo sus componentes, las relaciones entre ellos y el entorno, y los principios que gobiernan su diseño y evolución (ANSI / IEEE Std ) 2 1

2 Arquitectura de Software Vistas de la Arquitectura La Arquitectura de Software es un artefacto de diseño complejo por eso, como la mayoría de los artefactos complejos, hay varias formas de visualizar y comprender una arquitectura. El término Vistas de la Arquitectura fue introducido por Philippe Krutchen en 1995 en su publicación: The 4+1 View Model of Sotware Architecture (IEEE Sotware, Nov. 1995) 3 Arquitectura de Software Vistas de la Arquitectura La publicación de Krutchen presenta una forma de describir y comprender la arquitectura basada en las siguientes cuatro vistas: Vista Lógica Vista de Procesos Vista Física Vista de Desarrollo 4 2

3 Arquitectura de Software Vistas de la Arquitectura Vista Lógica: Describe los elementos significativos arquitectónicamente y las relaciones entre ellos. Esencialmente captura la estructura de la aplicación utilizando diagramas de clases o equivalentes. Vista de Procesos: Se enfoca en describir la concurrencia y elementos de comunicación de una arquitectura. El interés principal en esta vista es decribir los componentes multi-threaded (multi-hilos) o replicados y los mecanismos de comunicación sincrónos y asíncronos utilizados. 5 Arquitectura de Software Vistas de la Arquitectura Vista Física: Describe cómo se mapean los principales procesos y componentes en los nodos de hardware. Podría mostrar, por ej., cómo los servidores Web y de Base de Datos para una aplicación son distribuidos a través de un número de equipos servidores. Vista de Desarrollo: Captura la organización interna de los componentes de software, típicamente cómo están contenidos en un entorno de desarrollo o una herramienta de gestión de la configuración. Por ej. la descripción de un paquete anidado y una jerarquía de clases para una aplicación Java representaría la vista de Desarrollo de una arquitectura. 6 3

4 Arquitectura de Software Vistas de la Arquitectura Estas cuatro vistas están unidas por los casos de uso arquitectónicamente significativos. Estos casos de uso básicamente capturan los requerimientos para la arquitectura, de ahí que estén relacionados con más de una vista particular. Vista de diseño Vista de Casos de Uso Vista de implementación Vista de procesos Vista de despliegue 7 Proceso de Arquitectura de Software Para guiar al arquitecto hacia la definición de la arquitectura de la aplicación es útil seguir un proceso definido. La siguiente figura muestra un proceso de arquitectura iterativo en tres pasos que puede ser usado para guiar las actividades durante el diseño: Determinar los requerimientos significativos para la arquitectura Diseño de la Arquitectura Validación 8 4

5 Proceso de Arquitectura de Software 1. Definir requerimientos significativos para la arquitectura: Involucra la creación de una sentencia o modelo de los requerimientos que conducirán el diseño de la arquitectura. 2. Diseñar la arquitectura: Implica definir la estructura y responsabilidades de los componentes que comprenden la arquitectura. 3. Validación: Implica el testing (la prueba) de la arquitectura, típicamente revisar el diseño contra los requerimientos existentes y cualquier posible futuro requerimiento conocido. 9 Proceso de Arquitectura de Software Determinar requerimientos significativos Antes que la solución arquitectónica sea diseñada es necesario tener una buena idea de los requerimientos para la arquitectura de la aplicación, para ello debemos: 1. Identificar requerimientos significativos. 2. Priorizar los requerimientos significativos para la arquitectura. 10 5

6 Proceso de Arquitectura de Software Determinar requerimientos significativos Identificar requerimientos significativos: las principales fuentes para los requerimientos de arquitectura son: El documento de requerimientos funcionales Otros documentos que capturan diversas necesidades de los stakeholders (atributos de calidad y requerimientos no funcionales) Requerimientos Funcionales Determinar Requerimientos de la Arquitectura Requerimientos de la Arquitectura Requerimientos de los Stakeholders 11 Proceso de Arquitectura de Software Determinar requerimientos significativos Priorizar los requerimientos de arquitectura: Es muy raro que todos los requerimientos de arquitectura de una aplicación sean iguales. Frecuentemente la lista de requerimientos contiene items que son de prioridad baja o características del tipo sería bueno tenerla pero no necesario. En consecuencia, es importante identificar explícitamente estos casos y clasificar los requerimientos en función de su prioridad. Inicialmente, es suficiente ubicar cada requerimiento en una de estas tres categorías: Alta Media Baja 12 6

7 Proceso de Arquitectura de Software Determinar requerimientos significativos Priorizar los requerimientos de arquitectura: Prioridad Alta: La aplicación debe soportar este requerimiento. Estos requerimientos conducen el diseño de la arquitectura. Prioridad Media: Este requerimiento necesitará ser soportado en alguna etapa, pero no necesariamente en las primeras iteraciones. Prioridad Baja: Es parte de la lista de deseos de los requerimientos. Las soluciones que pueden componer estos requerimientos son deseadas pero no conducen el diseño de la arquitectura. La priorización puede provocar conflictos entre los requerimientos. Ejemplo 13 Proceso de Arquitectura de Software Si bien todas las tareas para realizar la arquitectura son importantes, lo que realmente importa es la calidad del diseño de la arquitectura. Los buenos arquitectos son resultado de muchos años de ingeniería de software y experiencia en diseño. En la siguiente figura se muestran las entradas y salidas de la actividad de diseño de la arquitectura. 14 7

8 Proceso de Arquitectura de Software Entradas y salidas del diseño de la Arquitectura Requerimientos de la Arquitectura Elegir el Framework (Patrones Arquitectónicos) Distribuir Componentes Vistas de la Arquitectura Documento de Arquitectura 15 Proceso de Arquitectura de Software Elegir el Framework de la Arquitectura: Ian Gorton, comenta que la mayoría de las aplicaciones en las que trabajó en los últimos años se basan en un número pequeño de bien comprendidas y probadas arquitecturas. Hay una razón para ello Funcionan Trabajaremos con los siguientes Patrones de Arquitectura: N Tier Client- Server Messaging Publish Suscribe Broker Process Cordinator 16 8

9 Proceso de Arquitectura de Software : Patrones de Arquitectura N Tier Client-Server Client Tier (Capa Cliente) Web Client Web Client Web Client Web Client Web Server Tier (Capa de Servidor Web) Business Logic Tier (Capa de lógica de Negocio) Web Server Application Server Data Managment Tier (Capa Administración Databases de datos) 17 Patrones de Arquitectura: Patrón N-Tier Las propiedades clave de este patrón son: Separación de intereses: La presentación, lógica de negocio y administración de datos están claramente particionadas en diferentes capas. Comunicaciones sincrónicas: Las comunicaciones entre capas son sincrónicas. Las peticiones van en una única dirección desde la capa cliente a través de las capas de servidor Web y lógica de negocios hacia la capa de administración de datos. Cada capa espera la respuesta de la otra capa antes de proceder Despliegue flexible: No hay restricciones respecto de cómo las aplicaciones multi-capa se despliegan. Todas las capas podrían correr en la misma máquina o en el otro extremo- cada capa puede ser desplegada en su propia máquina. En las aplicaciones Web, la capa cliente es usualmente un navegador corriendo en un equipo de escritorio del usuario comunicándose de manera remota vía Internet con los componentes de la capa Web. 18 9

10 Patrones de Arquitectura: Patrón N-Tier Atributo de calidad Disponibilidad Manejo de Fallas Cambiabilidad Características Los servidores en cada capa pueden estar replicados, de modo que si uno falla los otros continúan disponibles. En general, la aplicación proveerá una baja calidad de servicio hasta que el servidor que falló sea restaurado. Si un cliente se está comunicando con el servidor que falla, la mayoría de los servidores y aplicaciones Web implementan transparencia frente a fallos. Esto significa que la petición del cliente, sin que él lo sepa, será re-direccionada a la réplica del servidor que puede satisfacer la petición. La separación de intereses favorece la cambiabilidad, dado que la presentación, lógica de negocios y administración de datos están claramente encapsulados. Cada una puede tener modificaciones de su lógica interna, en muchos casos sin cambios en las otras capas. 19 Patrones de Arquitectura: Patrón N-Tier Atributo de calidad Características Rendimiento Escalabilidad Esta arquitectura prove alto rendimiento. Elementos clave a considerar son la cantidad de hilos concurrentes soportados en cada servidor, la velocidad de las conexiones entre capas y el volumen de transferencia de datos. Como en todos los sistemas distribuidos, es sensato minimizar las llamadas necesarias entre capas para completar cada petición. Como los servidores en cada capa pueden ser replicados y múltiples instancias de servidores corren en el mismo o diferentes equipos servidores, la arquitectura puede escalarse bien. En la práctica la capa de administración de datos frecuentemente se convierte en un cuello de botella en la capacidad de un sistema

11 Proceso de Arquitectura de Software : Patrones de Arquitectura Ejemplo patrón N Tier Client-Server Sistema: Gestión de Tasa Comercio e Industria Municipal Capa Cliente (Presentación) Cliente Web Cliente Web Atención al público Dirección de Rentas Procuración Fiscal Capa de Servicios Web Servidor Web Capa de lógica de Negocio Capa de Administración de datos Servidor de Aplicaciones del Municipio Servidor de Bases de Datos del Municipio 21 Proceso de Arquitectura de Software : Patrones de Arquitectura Messaging Client Queue Server Cliente Cola Servidor 22 11

12 Patrones de Arquitectura: Messaging Las propiedades clave de este patrón son: Comunicaciones asincrónicas: Los clientes envían las peticiones a la cola, donde los mensajes son almacenados hasta que una aplicación los remueve. Después que el cliente ha escrito un mensaje en la cola, continúa trabajando sin esperar que el mensaje sea removido. Calidad del Servicio (QoS) Configurable: La cola puede ser configurada para alta velocidad, noconfiable o baja, entrega confiable. Las operaciones de la cola se pueden coordinar con las transacciones de la base de datos. Libre de Acoplamiento: No hay binding (ligadura/atadura) directo entre clientes y servidores. 23 Atributo de calidad Patrones de Arquitectura: Messaging Características Disponibilidad Manejo de Fallas Cambiabilidad Las colas físicas con el mismo nombre lógico se pueden replicar a través de diferentes instancias de servidores messaging. Cuando una falla, los clients envían los mensajes a la réplica de la cola. Si un cliente se está comunicando con una cola que falla, puede encontrar una réplica de la cola y colocar el mensaje allí. Messaging es inherentemente libre de acoplamientos y promueve la alta cambiabilidad ya que clientes y servidores no están directamente sujetos a través de una interfaz. Cambiar el formato de los mensajes enviados por los clientes pueden causar cambios en las implementaciones de los servidores. Los formatos de mensajes autodefinidos pueden ayudar a reducir esta dependencia

13 Atributo de calidad Patrones de Arquitectura: Messaging Características Rendimiento Escalabilidad La tecnología de cola de mensajes puede entregar miles de mensajes por segundo. Los mensajes noconfiables son más rápidos que los confiables, con la diferencia dependiente de la calidad de tecnología de mensajería utilizada. Las colas pueden ser alojadas en los puntos finales de comunicación o ser replicados a través de clusters de servidores de mensajes alojados en un único o en múltiples equipos servidores. Esto lo hace una solución altamente escalable. 25 Proceso de Arquitectura de Software : Patrones de Arquitectura Ejemplo patrón Messaging Sistema HCU Provincial (Historia Clínica Unificada) Sistemas Centros Médicos Regionales Cola Replicar/Sincronizar Servidor de Aplicaciones Sistema HCU BD Replicar Información de consultas atendidas y datos de pacientes de los centros de salud a la base de datos del Ministerio de Salud de la Provincia

14 Proceso de Arquitectura de Software : Patrones de Arquitectura Publish Suscribe Publisher Topic Suscriber Publicante Tópico Suscriptor 27 Patrones de Arquitectura: Publish-Suscribe Las propiedades clave de este patrón son: Mensajería Muchos-a-Muchos: Los mensajes publicados son enviados a todos los suscriptores que se han registrado en un tópico. Muchos publicantes pueden publicar sobre el mismo tópico y muchos suscriptores pueden escuchar sobre el mismo tópico. Calidad del Servicio (QoS) Configurable: Además de los mensajes no-confiables y confiables, el mecanismo de comunicación puede ser punto-a-punto o broadcast/multicast. El primero envía un mensaje diferente para cada suscriptor en un tópico, el otro envía un mensaje que cada suscriptor recibe. Libre de Acoplamiento: Al igual que messaging, no hay ligaduras ( binding ) entre publicantes y suscriptores. Los publicantes no conocen quién recibe sus mensajes, y los suscriptores no conocen qué publicante envió el mensaje

15 Patrones de Arquitectura: Publish-Suscribe Atributo de calidad Características Disponibilidad Manejo de Fallas Cambiabilidad Los tópicos con el mismo nombre lógico pueden ser replicados en diferentes instancias de servidores administrados como un cluster. Cuando uno falla, los publicantes envían los mensajes a las réplicas. Si un publicante se está comunicando con un tópico alojado en un servidor que falla, puede encontrar un servidor réplica y enviar el mensaje allí. Publish-subscribe es inherentemente libre de acoplamiento promueve la alta cambiabilidad. Nuevos publicantes y suscriptores pueden agregarse al sistema sin cambiar la arquitectura o la configuración. Cambios en el formato de los mensajes publicados pueden causar cambios en las implementaciones de los suscriptores. 29 Patrones de Arquitectura: Publish-Suscribe Atributo de calidad Rendimiento Escalabilidad Características Publish-subscribe puede entregar miles de mensajes por segundo, con mensajes no-confiables más rápido que con los confiables. Si el broker publish-subscribe soporta multicast/broadcast, entregará múltiples mensajes en un tiempo más uniforme a cada suscriptor. Los tópicos pueden estar replicados a través de clusters de servers alojados en un único o en múltiples equipos servidores. Los clusters de servidores pueden escalarse para proveer un muy alto volumen de entrega de mensajes. También las soluciones multicast/ broadcast se escalan mejor que sus contrapartes punto-a-punto

16 Proceso de Arquitectura de Software : Patrones de Arquitectura Ejemplo patrón Publish Suscribe Sistema de notificaciones de tarjeta de débito Consultas de saldo Gestión de Compras Gestión de Novedades Tópico Generación de avisos Servicio de notificaciones por correo electrónico Servicio de notificaciones por celular Publicantes Tópico Suscriptores 31 Proceso de Arquitectura de Software : Patrones de Arquitectura Broker: Sender-1 inport 1 Sender-2 inport 2 OutPort 1 Receiver-1 Broker Receiver-2 OutPort 2 Remitente Broker Receptor 32 16

17 Patrones de Arquitectura: Broker Las propiedades clave de este patrón son: Arquitectura Hub-and-spoke (Eje-rayo): El broker actúa como un hub de mensajería (eje) y los Remitentes y Receptores se conectan como rayos (como en una rueda de bicicleta). Las conexiones con el broker son a través de puertos que están asociados con un formato de mensaje específico. Realiza ruteo de mensaje: El broker embebe la lógica de procesamiento para entregar un mensaje recibido en un puerto de entrada en un puerto de salida. El camino de entrega puede estar en el código o depender de valores en el mensaje de entrada. Realiza transformación del mensaje: La lógica del broker transforma el tipo de mensaje fuente recibido en el puerto de entrada al tipo de mensaje de destino requerido en el puerto de salida. 33 Atributo de calidad Disponibilidad Manejo de Fallas Cambiabilidad Patrones de Arquitectura: Broker Características Para construir arquitecturas con alta disponiblidad, los brokers deber estar replicados. Esto es típicamente soportado utilizando mecanismos similares al cluster de servidores del messaging y publish-subscribe Como los brokers tienen puertos de entrada de tipos definidos, validan y descartan cualquier mensaje enviado en un formato erróneo. Con Brokers replicados, los remitentes pueden sobrellevar una falla dirigiéndose a una réplica del broker en falla. Los Brokers separan la lógica de transformación y de ruteo del mensaje desde los remitentes a los receptores. Esto mejora la cambiabilidad ya que cambios en la lógica de ruteo o transformación pueden hacerse sin afectar a los remitentes o receptores

18 Atributo de calidad Patrones de Arquitectura: Broker Características Rendimiento Escalabilidad Los Brokers pueden potencialmente convertirse en cuellos de botella especialmente si deben manejar grandes volúmenes de mensajes y ejecutar lógica de transformaciones complejas. Su rendimiento será típicamente más bajo que un messaging simple con entrega confiable. Reunir en clusters instancias de Brokers hace posible construir sistemas escalables para manejar grandes cargas de peticiones. Los Brokers se adaptan a aplicaciones en las cuales los componentes intercambian mensajes que requieren una extensa transformación entre los formatos fuente y destino. 35 Proceso de Arquitectura de Software : Patrones de Arquitectura Ejemplo patrón Broker: Sistema de Información Radiológica (RIS) Sistema de reconocimiento interactivo de voz Captura de imágenes BD Pacientes Y consultas Puertos de entrada RIS (protocolo HL7) Puertos de salida Generador de reportes Almacenamiento formato texto Almacenamiento de imágenes (distintos formatos) Almacenamiento de sonido (distintos formatos) Remitentes Broker Receptores 36 18

19 Proceso de Arquitectura de Software : Patrones de Arquitectura Process Cordinator Start process request Process Cordinator Process result Paso 1 Paso 2 Paso 3 Paso 4 Server-1 Server-2 Server-3 Server-4 37 Patrones de Arquitectura: Process Cordinator Las propiedades clave de este patrón son: Encapsulamiento de Proceso: El coordinador de proceso encapsula la secuencia de pasos necesaria para completar un proceso de negocio. La secuencia puede ser arbitrariamente compleja. El coordinador es un único punto de definición para el proceso de negocio, haciendo fácil su comprensión y modificación. Recibe la petición de inicio del proceso, llama a los servidores en el orden definido por el proceso y emite los resultados. Libre de Acoplamiento: Los componentes servidores son inconcientes de su rol en todo el proceso de negocio y del orden de los pasos en el proceso. Los servidores simplemente definen un conjunto de servicios que deben realizar y el coordinador los llama como una parte necesaria del proceso de negocio. Comunicaciones flexibles: Las comunicaciones entre el coordinador y los servidores pueden ser sincrónicas o asincrónicas. Para comunicaciones sincrónicas el coordinador espera hasta que los servidores responden. Para las comunicaciones asincrónicas el coordinador provee un mecamismo de callback o queue/topic y espera hasta que el servidor responda utilizando el mecanismo definido

20 Patrones de Arquitectura: Process Cordinator Atributo de calidad Disponibilidad Características El coordinador es un único punto de falla. De ahí que necesite ser replicado para crear una solución con alta disponiblidad. Manejo de Fallas Cambiabilidad El manejo de fallas es complejo, puede ocurrir en cualquier etapa de la coordinación del proceso de negocio. Una falla en los últimos pasos en el proceso puede requerir que los primeros pasos sean deshechos usando transacciones de compensación. El manejo de fallas necesita un diseño cuidadoso para asegurar que los datos mantenidos en los servidores sigan siendo consistentes. La cambiabilidad del proceso se favorece porque la definición del proceso está encapsulada en el Coordinador de Procesos. Los servidores pueden cambiar su implementación sin afectar al coordinador o a los otros servidores mientras que la definición del servicio externamente no cambie. 39 Patrones de Arquitectura: Process Cordinator Atributo de calidad Características Rendimiento Escalabilidad Para proporcionar alto rendimiento el coordinador debe poder manejar múltiples peticiones concurrentes y administrar el estado de cada una a medida que progresan a través del proceso. También, el rendimiento de cualquier proceso está limitado por los pasos más lentos (denominados los servidores lentos en el proceso). El coordinador puede ser replicado para escalar la aplicación. El patrón Coordinador de Proceso es comúnmente utilizado para implementar procesos de negocio complejos que deben resolver peticiones de varios componentes de servidores diferentes 40 20

21 Proceso de Arquitectura de Software : Patrones de Arquitectura Ejemplo patrón Process Cordinator Start process request Paso 1 Sistema Bancario Gestión de Préstamos Paso 2 Paso 3 Process result Paso 4 Server Solicitudes Server Evaluación Financiera Server Riesgo crediticio Server Liquidaciones 41 Documentar la Arquitectura de Software Razones para documentar nuestras arquitecturas: Otras personas pueden comprender y evaluar el diseño. Esto incluye cualquiera de los stakeholders, pero más comúnmente otros miembros del equipo de diseño. Podemos comprender el diseño cuando retornamos a él después de un período de tiempo. Otras personas del equipo de proyecto y de la organización de desarrollo pueden aprender sobre la arquitectura asimilando los conceptos detrás del diseño. Podemos hacer análisis sobre el diseño, tal vez para valorar su probable rendimiento 42 21

22 Documentar la Arquitectura de Software Por otro lado documentar las arquitecturas, puede ser problemático porque : No hay una forma de documentación estándar universalmente aceptada. Una arquitectura puede ser compleja y documentarla en una manera comprensible es tiempo consumido y no de manera trivial. Una arquitectura tiene varias vistas posibles. Documentar todas las potencialmente útiles es tiempo consumido y costoso. Un diseño de la arquitectura frecuentemente evoluciona a medida que el sistema se desarrolla incrementalmente y se gana más conocimiento sobre el dominio de problema. 43 Vistas Arquitectónicas Utilizaremos algunos de los diagramas provistos por UML 2.0 para representar las vistas arquitectónicas más significativas. Diagramas de Casos de Uso Diagramas de Estructura Compuesta Diagrama de Despliegue Se pueden utilizar también diagramas de clases pero sin entrar en detalles innecesarios a nivel del diseño arquitectónico y diagramas de secuencia para modelar el comportamiento de los componentes en una arquitectura. Vistas Arquitectónicas 44 22

23 Vistas Arquitectónicas Vistas de la arquitectura: Vista Arquitectónica de la Funcionalidad: Casos de Uso significativos para la Arquitectura Vista Arquitectónica del Diseño: Subsistemas e Interfaces Vista Arquitectónica del Despliegue: Nodos y Componentes principales Vista Arquitectónica del Despliegue: Niveles de Hardware Ejemplo Vistas Arquitectónicas 45 Documento de Arquitectura Plantilla para Documentación de la Arquitectura: Nombre del proyecto: XXX 1 Contexto del Proyecto 2 Requerimientos de la Arquitectura 2.1 Descripción general de los objetivos clave. 2.2 Casos de Uso significativos para la arquitectura. 2.3 Requerimientos de Arquitectura de los Stakeholders 2.4 Restricciones 2.5 Requerimientos No Funcionales 2.6 Riesgos Vistas Arquitectónicas 46 23

24 Documento de Arquitectura Plantilla para Documentación de la Arquitectura (continuación): 3 Solución 3.1 relevantes. 3.2 Descripción general de la Arquitectura 3.3 Vistas Estructurales 3.4 Vistas de Comportamiento 3.5 Beneficios de Implementación 4 Análisis de la Arquitectura 4.1 Análisis de escenarios 4.2 Riesgos Vistas Arquitectónicas 47 Bibliografía Gorton Ian, Essential Sofware Architecture (2006), Springer. Patrones y Vistas Arquitectónicas 48 24

25 Anexo Componente Un componente se puede mostrar por uno o más artefactos. Un componente se dibuja como un cuadro con el estereotipo <component> y/o un ícono de componente. Los componentes pueden tener interfaces provistas y requeridas y puertos. Un componente puede tener una estructura interna. Puede mostrar las partes anidadas dentro del componente, así como sus interfaces provistas y requeridas. Vistas Arquitectónicas 49 Anexo Componente Modelado de componentes: Partes del componente Interfaces requeridas Interfaces provistas Otra vista de los componentes: Vista externa de los componentes: Vistas Arquitectónicas 50 25

26 Anexo Estructura interna de los Componentes Para modelar la estructura interna de los componentes utilizamos el Diagrama de Estructura Compuesta. Interfaz provista Interfaz requerida 51 DSI 3K3 - Vistas Arquitectónicas Anexo Componentes y Artefactos Un componente puede englobar, como en el ejemplo, la clase contexto, la interfaz estrategia y las clases que implementan la estrategia y se realizan por un solo artefacto que contiene código fuente. Vistas Arquitectónicas 52 26

27 Anexo Estereotipos de Componente Build Component Entity Implementation Specification Process Estereotipo Significado Un componente que define un conjunto de elementos para fines organizativos o de desarrollo a nivel sistema. Un componente de información persistente que representa un concepto de negocio. Una definición de componentes que no tiene especificación. Es un implementación para una <specification>. Un clasificador que especifica un dominio de objetos sin definir implementación física, sólo indica interfaces proporcionadas y requeridas. Un componente basado en transacción Service Subsystem Un componente funcional sin estado que computa un valor. Una unidad de descomposición jerárquica para grandes sistemas. Vistas Arquitectónicas 53 27

Capítulo 5. Cliente-Servidor.

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

Más detalles

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

Arquitectura de sistema de alta disponibilidad

Arquitectura de sistema de alta disponibilidad Mysql Introducción MySQL Cluster esta diseñado para tener una arquitectura distribuida de nodos sin punto único de fallo. MySQL Cluster consiste en 3 tipos de nodos: 1. Nodos de almacenamiento, son los

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

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

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

ARC 101 Architecture Overview Diagram

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

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

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

Más detalles

e-commerce, es hacer comercio utilizando la red. Es el acto de comprar y vender en y por medio de la red.

e-commerce, es hacer comercio utilizando la red. Es el acto de comprar y vender en y por medio de la red. Comercio electrónico. (e-commerce) Las empresas que ya están utilizando la red para hacer comercio ven como están cambiando las relaciones de la empresa con sus clientes, sus empleados, sus colaboradores

Más detalles

LICITACIÓN N L13045 NUEVO SISTEMA LEY DE TRANSPARENCIA

LICITACIÓN N L13045 NUEVO SISTEMA LEY DE TRANSPARENCIA LICITACIÓN N L13045 NUEVO SISTEMA LEY DE TRANSPARENCIA ACLARACIONES Y RESPUESTAS A CONSULTAS SEGUNDA PARTE De acuerdo a lo señalado en el numeral 11 de las Bases de Licitación, a continuación se presenta

Más detalles

4. Programación Paralela

4. Programación Paralela 4. Programación Paralela La necesidad que surge para resolver problemas que requieren tiempo elevado de cómputo origina lo que hoy se conoce como computación paralela. Mediante el uso concurrente de varios

Más detalles

Empresa Financiera Herramientas de SW Servicios

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

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

3. 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 detalles

Los mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas:

Los mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas: SISTEMAS DISTRIBUIDOS DE REDES 1. SISTEMAS DISTRIBUIDOS Introducción y generalidades La computación desde sus inicios ha sufrido muchos cambios, desde los grandes equipos que permitían realizar tareas

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

ARQUITECTURA DE DISTRIBUCIÓN DE DATOS

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

Más detalles

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

<Generador de exámenes> Visión preliminar

<Generador de exámenes> Visión preliminar 1. Introducción Proyecto Final del curso Técnicas de Producción de Sistemas Visión preliminar Para la evaluación de algunos temas de las materias que se imparten en diferentes niveles,

Más detalles

Figure 7-1: Phase A: Architecture Vision

Figure 7-1: Phase A: Architecture Vision Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como

Más detalles

Workflows? Sí, cuántos quiere?

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

Más detalles

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

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

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

Sistema de SaaS (Software as a Service) para centros educativos

Sistema de SaaS (Software as a Service) para centros educativos Sistema de SaaS (Software as a Service) para centros educativos Definiciones preliminares: Qué es SaaS? SaaS (1) es un modelo de distribución del software que permite a los usuarios el acceso al mismo

Más detalles

Windows Server 2012: Infraestructura de Escritorio Virtual

Windows Server 2012: Infraestructura de Escritorio Virtual Windows Server 2012: Infraestructura de Escritorio Virtual Módulo 1: Application Virtualization Módulo del Manual Autores: James Hamilton-Adams, Content Master Publicado: 5 de Octubre 2012 La información

Más detalles

BPMN Business Process Modeling Notation

BPMN Business Process Modeling Notation BPMN (BPMN) es una notación gráfica que describe la lógica de los pasos de un proceso de Negocio. Esta notación ha sido especialmente diseñada para coordinar la secuencia de los procesos y los mensajes

Más detalles

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

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

Más detalles

Capítulo 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

Gestión de la Configuración

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

Más detalles

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo. GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.

Más detalles

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

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

Más detalles

Novedades en Q-flow 3.02

Novedades en Q-flow 3.02 Novedades en Q-flow 3.02 Introducción Uno de los objetivos principales de Q-flow 3.02 es adecuarse a las necesidades de grandes organizaciones. Por eso Q-flow 3.02 tiene una versión Enterprise que incluye

Más detalles

Interoperabilidad de Fieldbus

Interoperabilidad de Fieldbus 2002 Emerson Process Management. Todos los derechos reservados. Vea este y otros cursos en línea en www.plantwebuniversity.com. Fieldbus 201 Interoperabilidad de Fieldbus Generalidades Qué es interoperabilidad?

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

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

Más detalles

ADMINISTRACIÓN CENTRALIZADA DELL POWERVAULT DL2000 CON TECNOLOGÍA SYMANTEC

ADMINISTRACIÓN CENTRALIZADA DELL POWERVAULT DL2000 CON TECNOLOGÍA SYMANTEC ADMINISTRACIÓN CENTRALIZADA DELL POWERVAULT DL2000 CON TECNOLOGÍA SYMANTEC RESUMEN EJECUTIVO Es un método ideal para que cualquier departamento de TI logre realizar respaldos y restauraciones más rápidas

Más detalles

Capítulo VI. Estudio de Caso de Aplicación del Integrador de Información Desarrollado

Capítulo VI. Estudio de Caso de Aplicación del Integrador de Información Desarrollado Capítulo VI Estudio de Caso de Aplicación del Integrador de Información Desarrollado 6.1 Organización elegida La Organización elegida para el caso de aplicación, es la empresa CTM Tours del grupo Costamar,

Más detalles

Microsoft SQL Server Conceptos.

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

Más detalles

Infraestructura Tecnológica. Sesión 1: Infraestructura de servidores

Infraestructura Tecnológica. Sesión 1: Infraestructura de servidores Infraestructura Tecnológica Sesión 1: Infraestructura de servidores Contextualización La infraestructura de cualquier servicio o mecanismo es importante, define el funcionamiento de los elementos en que

Más detalles

CAPÍTULO 3 Servidor de Modelo de Usuario

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

Más detalles

Introducción a las redes de computadores

Introducción a las redes de computadores Introducción a las redes de computadores Contenido Descripción general 1 Beneficios de las redes 2 Papel de los equipos en una red 3 Tipos de redes 5 Sistemas operativos de red 7 Introducción a las redes

Más detalles

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

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

Más detalles

M.T.I. Arturo López Saldiña

M.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 detalles

6.8 La Arquitectura del Sistema. [Proceso]

6.8 La Arquitectura del Sistema. [Proceso] 6.8 La Arquitectura del Sistema. [Proceso] En el Caso de Estudio se ha hecho énfasis en los objetos del Dominio del problema, ya que representan la esencia del sistema y definen su comportamiento. Sin

Más detalles

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

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

Más detalles

CMMI (Capability Maturity Model Integrated)

CMMI (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 detalles

Marco Normativo de IT

Marco Normativo de IT Marco Normativo de IT PC0901 - Proceso de control de cambios en software de aplicación provisto por Organismos Gobierno de la Ciudad Autónoma de Buenos Aires PC0901 - Proceso de control de cambios en software

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

Gestión y Desarrollo de Requisitos en Proyectos Software

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

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

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

Más detalles

Procesos Críticos en el Desarrollo de Software

Procesos Críticos en el Desarrollo de Software Metodología Procesos Críticos en el Desarrollo de Software Pablo Straub AgileShift Imagine una organización de desarrollo de software que consistentemente cumple los compromisos con sus clientes. Imagine

Más detalles

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

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

Más detalles

Unidad III. Software para la administración de proyectos.

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

2 EL DOCUMENTO DE ESPECIFICACIONES

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

Más detalles

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

Soporte y mantenimiento. Generalidades

Soporte y mantenimiento. Generalidades Soporte y mantenimiento Generalidades 2014 Tabla de Contenido 1 Introducción... 3 2 Objetivos generales... 3 3 Caso de soporte... 3 4 Condiciones... 4 5 Restricciones... 5 6 Sistema de soporte... 5 Página

Más detalles

Ingeniería de Software. Pruebas

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

Más detalles

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

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

Más detalles

CONSTRUCCIÓN DEL PROCESO TRANSACCIONAL Bizagi Process Modeler

CONSTRUCCIÓN DEL PROCESO TRANSACCIONAL Bizagi Process Modeler Bizagi Process Modeler Copyright 2011 - bizagi Contenido 1. INTRODUCCIÓN A LAS TRANSACCIONES... 3 2. DIAGRAMA DEL PROCESO... 4 SUB PROCESO RESERVA... 5 SUB PROCESO REPORTE DE GASTOS... 8 3. MODELO DE DATOS...

Más detalles

Sistema de Mensajería Empresarial para generación Masiva de DTE

Sistema de Mensajería Empresarial para generación Masiva de DTE Sistema de Mensajería Empresarial para generación Masiva de DTE TIPO DE DOCUMENTO: OFERTA TÉCNICA Y COMERCIAL VERSIÓN 1.0, 7 de Mayo de 2008 CONTENIDO 1 INTRODUCCIÓN 4 2 DESCRIPCIÓN DE ARQUITECTURA DE

Más detalles

La Pirámide de Solución de TriActive TRICENTER

La Pirámide de Solución de TriActive TRICENTER Información sobre el Producto de TriActive: Página 1 Documento Informativo La Administración de Sistemas Hecha Simple La Pirámide de Solución de TriActive TRICENTER Información sobre las Soluciones de

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

Documento Técnico Gerardo Barcia Jonathan Trujillo María Alejandra Uribe

Documento Técnico Gerardo Barcia Jonathan Trujillo María Alejandra Uribe Documento Técnico Gerardo Barcia Jonathan Trujillo María Alejandra Uribe Índice de contenido 1. Introducción...3 2. El modelo de negocio...3 2.1 Antecedentes...3 2.2 Planteamiento del problema actual...3

Más detalles

PEEPER PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS. Mayo 2014. Versión 2.1 OSCAR IVAN LÓPEZ PULIDO

PEEPER PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS. Mayo 2014. Versión 2.1 OSCAR IVAN LÓPEZ PULIDO PEEPER Implementación del cambio de técnica usada para la actualización de datos en los reportes de esfuerzo, usados como métrica de productividad, progreso y costo de los proyectos, de la compañía de

Más detalles

computadoras que tienen este servicio instalado se pueden publicar páginas web tanto local como remotamente.

computadoras que tienen este servicio instalado se pueden publicar páginas web tanto local como remotamente. Investigar Qué es un IIS? Internet Information Services o IIS es un servidor web y un conjunto de servicios para el sistema operativo Microsoft Windows. Originalmente era parte del Option Pack para Windows

Más detalles

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

Más detalles

CRM Gestión de Oportunidades Documento de Construcción Bizagi Process Modeler

CRM Gestión de Oportunidades Documento de Construcción Bizagi Process Modeler Bizagi Process Modeler Copyright 2011 - Bizagi Tabla de Contenido CRM- Gestión de Oportunidades de Venta... 4 Descripción... 4 Principales Factores en la Construcción del Proceso... 5 Modelo de Datos...

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

SIGPRE Sistema de Gestión Presupuestaria

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

Más detalles

WINDOWS 2008 5: TERMINAL SERVER

WINDOWS 2008 5: TERMINAL SERVER WINDOWS 2008 5: TERMINAL SERVER 1.- INTRODUCCION: Terminal Server proporciona una interfaz de usuario gráfica de Windows a equipos remotos a través de conexiones en una red local o a través de Internet.

Más detalles

http://www.statum.biz http://www.statum.info http://www.statum.org

http://www.statum.biz http://www.statum.info http://www.statum.org ApiaMonitor Monitor de Infraestructura BPMS Por: Ing. Manuel Cabanelas Product Manager de Apia Manuel.Cabanelas@statum.biz http://www.statum.biz http://www.statum.info http://www.statum.org Abstract A

Más detalles

Capítulo 1 Introducción

Capítulo 1 Introducción Capítulo 1 Introducción Dentro de los muchos campos que abarca la universidad para la investigación científica, se encuentra el de los Sistemas de Información Geográfica (SIG). Para ello, cuenta con el

Más detalles

Capítulo IV. Manejo de Problemas

Capítulo IV. Manejo de Problemas Manejo de Problemas Manejo de problemas Tabla de contenido 1.- En qué consiste el manejo de problemas?...57 1.1.- Ventajas...58 1.2.- Barreras...59 2.- Actividades...59 2.1.- Control de problemas...60

Más detalles

Servidores Donantonio

Servidores 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

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

Una puerta abierta al futuro

Una puerta abierta al futuro Una puerta abierta al futuro SOA E ITIL EN LA LEY DE ACCESO ELECTRÓNICO DE LOS CIUDADANOS A LOS SERVICIOS PÚBLICOS (LAECSP) por francisco javier antón Vique La publicación de la Ley de Acceso electrónico

Más detalles

LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN

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

Más detalles

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

ITIL FOUNDATION V3 2011

ITIL FOUNDATION V3 2011 ITIL FOUNDATION V3 2011 Examen de Certificación Instrucciones 1. Revise su Hoja de Respuesta, debe contener espacio para responder 40 preguntas y una sección para incorporar su Nombre 2. Espere por la

Más detalles

Gestión de Oportunidades

Gestión de Oportunidades Gestión de Oportunidades Bizagi Suite Gestión de Oportunidades 1 Tabla de Contenido CRM Gestión de Oportunidades de Negocio... 4 Elementos del Proceso... 5 Registrar Oportunidad... 5 Habilitar Alarma y

Más detalles

Soporte y mantenimiento. Generalidades

Soporte y mantenimiento. Generalidades Soporte y mantenimiento Generalidades Tabla de Contenido 1. Introducción 2. Objetivos generales 3. Caso de soporte 4. Condiciones 5. Restricciones 6. Sistema de soporte Soporte y mantenimiento 1. Introducción

Más detalles

Soporte Técnico de Software HP

Soporte Técnico de Software HP Soporte Técnico de Software HP Servicios Tecnológicos HP Servicios contractuales Datos técnicos El Soporte Técnico de Software HP ofrece servicios integrales de soporte remoto de para los productos de

Más detalles

CONSEJO DE NORMALIZACIÓN Y CERTIFICACIÓN DE COMPETENCIA LABORAL NORMAS TÉCNICAS DE COMPETENCIA LABORAL

CONSEJO DE NORMALIZACIÓN Y CERTIFICACIÓN DE COMPETENCIA LABORAL NORMAS TÉCNICAS DE COMPETENCIA LABORAL I. Datos Generales de la Calificación CINF0286.01 Título Análisis y diseño de redes de datos Propósito Proporcionar un referente para evaluar la competencia en las funciones relativas al análisis y diseño

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

Más detalles

MACROPROCESO GESTIÓN TECNOLÓGICA

MACROPROCESO GESTIÓN TECNOLÓGICA Versión 1.0 Página 1 de 5 1. OBJETIVO Suministrar las fases para la puesta en producción de aplicaciones y sistemas de información desarrollados o adquiridos por el Instituto Colombiano de Bienestar Familiar

Más detalles

Unidad 1. Fundamentos en Gestión de Riesgos

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

Más detalles

Testing. Tipos, Planificación y Ejecución de Pruebas

Testing. Tipos, Planificación y Ejecución de Pruebas Testing Tipos, Planificación y Ejecución de Pruebas Contenido Definiciones del Testing de Software Objetivos, conceptos Tipos de Test Testing a-la RUP Rol del Testing en el proceso Artefactos Trabajadores

Más detalles

Visión General de GXportal. Última actualización: 2009

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

SAP BusinessObjects Edge BI Standard Package La solución de BI preferida para. Empresas en Crecimiento

SAP BusinessObjects Edge BI Standard Package La solución de BI preferida para. Empresas en Crecimiento SAP BusinessObjects Edge BI Standard Package La solución de BI preferida para Empresas en Crecimiento Portfolio SAP BusinessObjects Soluciones SAP para Empresas en Crecimiento Resumen Ejecutivo Inteligencia

Más detalles

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

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

Más detalles

Prácticas ITIL para un mejor flujo de trabajo en el helpdesk

Prácticas ITIL para un mejor flujo de trabajo en el helpdesk Prácticas ITIL para un mejor flujo de trabajo en el helpdesk Se diferencia tres partes de gestión para mejorar la resolución de las incidencias de soporte técnico según el marco ITIL: 1. Gestión de Incidencias

Más detalles

Portal de Compras del Gobierno del Estado de Baja California (www.comprasbc.gob.mx) A. Antecedentes

Portal de Compras del Gobierno del Estado de Baja California (www.comprasbc.gob.mx) A. Antecedentes Buenas prácticas en la implementación de las recomendaciones de la Guía para Mejorar la Calidad Regulatoria de Trámites Estatales y Municipales e Impulsar la Competitividad de México Portal de Compras

Más detalles

TELECOMUNICACIONES Y REDES

TELECOMUNICACIONES Y REDES TELECOMUNICACIONES Y REDES Redes Computacionales I Prof. Cristian Ahumada V. Unidad V: Capa de Red OSI 1. Introducción. 2. Protocolos de cada Red 3. Protocolo IPv4 4. División de Redes 5. Enrutamiento

Más detalles

GUÍA DE SEGURIDAD DE LA INFORMACIÓN GUÍA GOBIERNO CORPORATIVO PARA EMPRESAS SEP

GUÍA DE SEGURIDAD DE LA INFORMACIÓN GUÍA GOBIERNO CORPORATIVO PARA EMPRESAS SEP GUÍA DE SEGURIDAD DE LA INFORMACIÓN GUÍA GOBIERNO CORPORATIVO PARA EMPRESAS SEP 1. Introducción La información puede adoptar o estar representada en diversas formas: impresa o escrita (papeles de trabajo,

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

Requerimientos Técnicos para mantenimiento anual de certificación del Área Perimetral

Requerimientos Técnicos para mantenimiento anual de certificación del Área Perimetral Requerimientos Técnicos para mantenimiento anual de certificación del Área Perimetral Trabajo a realizar Cotización de mantenimiento anual de certificación de seguridad informática para el área perimetral

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

Guía de uso del Cloud Datacenter de acens

Guía de uso del Cloud Datacenter de acens guíasdeuso Guía de uso del Cloud Datacenter de Calle San Rafael, 14 28108 Alcobendas (Madrid) 902 90 10 20 www..com Introducción Un Data Center o centro de datos físico es un espacio utilizado para alojar

Más detalles

Introducción a la Firma Electrónica en MIDAS

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

Más detalles

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO Ejercicio Guiado de Análisis y Diseño Orientado a Objetos Ejemplo: CAJERO AUTOMÁTICO El siguiente ejercicio muestra las diferentes actividades que se realizan dentro del desarrollo de un producto software

Más detalles