PATRONES. Experto. Solución:

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

Download "PATRONES. Experto. Solución:"

Transcripción

1 PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los objetos? Durante el diseño OO, cuando se definen las interacciones entre los objetos, tomamos decisiones sobre la asignación de responsabilidades a las clases. Si se hacen de forma adecuada, los sistemas tienden a ser más fáciles de entender, mantener y ampliar, y se nos presenta la oportunidad de reutilizar componentes. Ejemplo: En la aplicación punto de venta, alguna clase necesita conocer el gran total de la venta. Se plantea esta pregunta: Quién es el responsable de conocer el gran total de la venta? Para calcular el total hay que conocer todas las instancias VentasLineadeProducto de una venta y la suma de sus subtotales. Y esto conoce únicamente la instancia Venta; desde el punto de vista del Experto, Venta es la clase correcta para asumir esta responsabilidad; es el experto en información. Para determinar el subtotal de la línea de productos se necesitan VentasLineadeProducto.cantidad y EspecificaciondeProducto.precio; desde la perspectiva del patrón Experto, VentasLineadeProducto debería calcular el subtotal; es el experto en información. VentasLineadeProducto no puede cumplir la responsabilidad de conocer y dar el subtotal, si no conoce el precio del producto. EspecificaciondeProcucto es un Experto en información para contestar su precio; por tanto, habrá que enviarle un mensaje preguntándole el precio.

2 Para cumplir con la responsabilidad de conocer y dar el total de la venta, se asignaron tres responsabilidades a las tres clases objeto: Clase. Venta: VentasLineasdeProducto: EspecificaciondeProducto: Responsabilidad. Conoce el total de la venta. Conoce el subtotal de la línea de producto. Conoce el precio del producto. Explicación: El Experto en Información se utiliza con frecuencia en la asignación de responsabilidades; es un principio de guía básico que se utiliza continuamente en el diseño de objetos. El Experto expresa la intuición común de que los objetos hacen las cosas relacionadas con la información que tienen. A menudo el cumplimiento de la responsabilidad requiere información que está dispersa por diferentes clases de objetos. Esto implica que hay muchos expertos en información parcial que colaborarán en la tarea. Contraindicaciones: En algunas ocasiones la solución que sugiere el Experto no es deseable debido a problemas de cohesión y acoplamiento. - Se conserva el encapsulamiento, ya que los objetos se valen de su propia información para hacer lo que se les pide. Esto soporta un bajo acoplamiento, lo que favorece al hecho de tener sistemas más robustos y de fácil mantenimiento. - El comportamiento se distribuye entre clases que cuentan con la información requerida, alentando con ello definiciones de clase sencillas y más cohesivas que son más fáciles de comprender y mantener. Así se brinda soporte a una alta cohesión. - Bajo Acoplamiento. - Alta Cohesión.

3 Creador. Asignarle a la clase B la responsabilidad de crear una instancia de clase A en uno de los siguientes casos: B agrega los objetos A. B contiene los objetos A. B registra las instancias de los objetos A. B utiliza específicamente los objetos A. B tiene datos de inicialización que serán transmitidos a A cuando este objeto sea creado (así que B es un Experto respecto a la creación de A). Quién debería ser responsable de crear una nueva instancia de alguna clase? B es un creador de los objetos A. Si se puede aplicar más de una opción, B es una clase que agrega o contiene objetos de A. Ejemplo: En la aplicación del punto de venta, quién debería encargarse de crear una instancia VentasLineadeProducto? Desde el punto de vista del patrón Creador, deberíamos buscar una clase que agregue, contenga y realice otras operaciones sobre ese tipo de instancias. Una Venta contiene (agrega) muchos objetos VentasLineadeProducto; por ello, el oatrón Creador sugiere que Venta es idónea para asumir la responsabilidad decrear las instancias VentasLineadeProducto. Esta asignación de responsabilidades requiere definir en Venta un método de hacerlineadeproducto. Explicación: La intención básica del patrón Creador es encontrar un creador que necesite conectarse al objeto creado en alguna situación. Eligiéndolo como creador se favorece el Bajo Acoplamiento. Algunas veces se encuentra un creador buscando las clases que contienen los datos de inicialización que se pasaran durante la creación. se brinda soporte a un bajo acoplamiento.

4 Bajo acoplamiento. Asignar una responsabilidad para mantener bajo acoplamiento. Cómo dar soporte a una dependencia escasa y a un aumento de la reutilización? El acoplamiento es una medida de fuerza con que una clase está conectada a otras clases, con las que conoce y con que recurre a ellas. Una clase con bajo acoplamiento no depende de muchas otras. Una clase con alto acoplamiento recurre a muchas otras. Presentan los siguientes problemas: - Los cambios de las clases afines ocasionan cambios locales. - Son más difíciles de entender cuando están aisladas. - Son más difíciles de reutilizar porque se requiere la presencia de otras clases de las que dependen. Explicación: El patrón Bajo Acoplamiento impulsa la asignación de responsabilidades de manera que su localización no incremente el acoplamiento hasta un nivel que nos lleve a resultados negativos. Ejemplo: Suponiendo que se necesita crear una instancia Pago y asociarla a Venta. Qué clase se encargará de hacer esto? Puesto que una instancia TPDV registra un Pago, el patrón Creador indica que TPDV es un buen candidato para producir el Pago. La instancia TPDV podría entonces enviarle a Venta el mensaje agregarpago, transmitiendo al mismo tiempo el nuevo Pago como parámetro. - No se afectan por cambios de otros componentes. - Fáciles de entender por separado. - Fáciles de reutilizar.

5 Alta cohesión. Asignar una responsabilidad de modo que la cohesión siga siendo alta. Cómo mantener la complejidad dentro de los límites manejables? La cohesión es una medida de cuán relacionadas y enfocadas están las responsabilidades de una clase. Un elemento con responsabilidades altamente relacionadas y que no hace una gran cantidad de trabajo tiene alta cohesión. Una clase con baja cohesión hace muchas cosas no relacionadas o demasiado trabajo. No convienen este tipo de clases pues presentan los siguientes problemas: - Son difíciles de comprender. - Son difíciles de reutilizar. - Son difíciles de conservar. - Son delicadas: les afectan constantemente los cambios. Las clases con baja cohesión a menudo representan un alto grado de abstracción o han asumido responsabilidades que deberían haber delegado a otros objetos. - Mejoran la claridad y la facilidad con que se entiende el diseño. - Se simplifican el mantenimiento y las mejoras en funcionalidad. - A menudo se genera un bajo acoplamiento. - La ventaja de una gran funcionalidad soporta una mayor capacidad de reutilización, porque una clase muy cohesiva puede destinarse a un propósito muy específico.

6 Controlador. Asignar la responsabilidad del manejo de un mensaje de los eventos de un sistema a una clase que represente una de las siguientes opciones: El sistema global: controlador de fachada. La empresa u organización global: controlador de fachada. Algo en el mundo real que es activo y que pueda participar en la tarea: controlador de tareas. Un manejador artificial de todos los eventos del sistema de un caso de uso: controlador de casos de uso. Quién debería encargarse de atender un evento del sistema? Un evento del sistema es un evento de alto nivel generado por un actor externo; es un evento de entrada externa. Se asocia a operaciones del sistema: las que emite en respuesta a los eventos del sistema. Un controlador es un objeto que no pertenece a la interfaz de usuario,responsable de manejar un evento del sistema. Define además el método de su operación. Ejemplo: Quién debería ser el controlador de eventos sistémicos como introducirproducto y terminarventa? De acuerdo con el patrón Controlador, disponemos de las siguientes opciones: - TPDV: representa el sistema global. - Tienda: representa la empresa u organización global. - Cajero: representa algo en el mundo real que está activo (por ejemplo, el papel de una persona) y que puede intervenir en la tarea. - ManejadordeComprarProductos: representa un manejador artificial de todas las operaciones del sistema de un caso de uso.

7 Explicación: La misma clase controlador debería utilizarse con todos los eventos sistémicos de un caso de uso, de modo que podamos conservar la información referente al estado del caso en el controlador. Esta información será útil para identificar los eventos del sistema fuera de la secuencia establecida. Puede emplearse varios controladores en los casos de uso. Un defecto frecuente al diseñar controladores consiste en asignarles demasiada responsabilidad. Normalmente un controlador debería delegar a otros objetos el trabajo que ha de realizarse mientras coordina la actividad. La primera categoría de controlador es un controlador de fachada que representa al sistema global. Es una clase que para el diseñador representa al sistema entero. Los controladores de fachada son adecuados cuando el sistema sólo tiene unos cuántos eventos o cuando es imposible redirigir los mensajes de los eventos del sistema a otros controladores. Si se elige un controlador de casos de uso entonces habrá un controlador diferente para cada caso de uso. No es un objeto del dominio; es una construcción artificial para dar soporte al sistema. Este controlador es una alternativa a tener en cuenta cuando la asignación de las responsabilidades a un controlador de fachada no conduce a diseños con baja cohesión o alto acoplamiento. Es una buena elección cuando hay muchos eventos del sistema repartidos por diferentes procesos; el controlador factoriza la gestión en clases separadas manejables. Resumiendo, el Controlador recibe la solicitud del servicio desde la capa de la IU y coordina su realización, normalmente delegando a otros objetos. - Mayor potencial de los componentes reutilizables. - Reflexionar sobre el estado del caso de uso.

8 Polimorfismo. Cuando por el tipo varían las alternativas o comportamientos afines, las responsabilidades del comportamiento se asignarán a los tipos en que el comportamiento presenta variantes. Cómo manejar las alternativas basadas en el tipo? De qué manera crear componentes software conectables? Alternativas basadas en el tipo. La variación condicional es un tema esencial en la programación. Si se diseña un programa mediante la lógica condicional if - then else o case, habrá que modificar la lógica del case cuando surja una variante. Este procedimiento dificulta extender un programa con otras variantes, porque se tiende a necesitar los cambios en varios lugares donde exista la lógica condicional. Componentes de software conectables. Viendo los componentes en las relaciones clienteservidor, cómo podemos reemplazar un componente por otro sin afectar al cliente? Explicación: Puesto que el comportamiento para la adaptación de un objeto varía según el objeto, según el patrón Polimorfismo deberíamos asignar la responsabilidad de la adaptación a los diferentes objetos de ese tipo, implementada con una operación polimórfica. Estos objetos no son externos, sino objetos software locales que representan a los externos. El Polimorfismo es un principio fundamental para diseñar cómo se organiza el sistema para gestionar variaciones similares. Según el Polimorfismo, un diseño basado en la asignación de responsabilidades puede ser extendido fácilmente para que realice nuevas variantes. Los objetos requerirán poca o nula modificación si soportan las operaciones polimórficas implementadas. Es fácil agregar las futuras extensiones para nuevas variaciones. Las nuevas implementaciones se pueden introducir sin afectar a los clientes.

9 Fabricación Pura. Problema que Asignar un conjunto altamente cohesivo de responsabilidades a una clase artificial que no representa nada en el dominio del problema: una cosa inventada para dar soporte a una alta cohesión, un bajo acoplamiento y reutilización. A quién asignar la responsabilidad cuando uno está desesperado y no quiere violar los patrones Alta Cohesión y Bajo Acoplamiento? Esa clase es una fabricación de la imaginación. En teoría, las responsabilidades que se asignan brindan soporte a una alta cohesión y a bajo acoplamiento, de modo que el diseño de fabricación sea muy limpio, o puro. Se dan muchas situaciones donde el asignar responsabilidades exclusivamente a las clases del dominio origina problemas por una mala cohesión o acoplamiento o bien por un escaso potencial de reutilización. Ejemplo: Supongamos que se necesita soporte para guardar las instancias Venta en una base de datos relacional. En virtud del patrón Experto, en cierto modo se justifica asignar esta responsabilidad a la clase Venta. Aunque en virtud del patrón Experto Venta es un candidato lógico para guardarse a sí misma en una base de datos, da origen a un diseño de baja cohesión, alto acoplamiento y bajo potencial de reutilización, precisamente el tipo de situación desesperada exige inventar algo. Una solución razonable consiste en crear una clase nueva que se encargue tan sólo de guardar los objetos en algún tipo de almacenamiento persistente: una base de datos relacional. Esta clase es una de Fabricación Pura, una mera abstracción de la imaginación. Crear una fabricación pura justifica su uso para lo siguiente: eliminar un diseño ineficiente, con mala cohesión y acoplamiento y cambiar por un buen diseño que ofrezca un mayor potencial de reutilización. Explicación: Para diseñar una Fabricación Pura debe buscarse ante todo un gran potencial de reutilización, asegurándose para ello de que sus responsabilidades sean pequeñas y cohesivas. Estas clases tienden a tener un conjunto de responsabilidades de grano fino. Una fabricación pura suele partirse atendiendo a su funcionalidad y, por lo mismo, es una especie de objeto de función central. No es crítico identificar una clase como Fabricación Pura. Algunas clases software se inspiran de acuerdo con las representaciones del dominio, y otras simplemente se crean por conveniencia del diseñador de objetos. Estas clases de conveniencia normalmente se crean para agrupar algún comportamiento común y por tanto, se inspiran según una descomposición de comportamiento en lugar de una descomposición de la representación.

10 Dicho de otro modo, una Fabricación Pura normalmente se organiza en base a funcionalidad relacionada. - Se brinda soporte a una Alta Cohesión porque las responsabilidades se dividen en una clase de gano fino que se centra exclusivamente en un conjunto muy específico de tareas afines. - Puede aumentar el potencial de reutilización debido a la presencia de clases de Fabricación Pura de grano fino, cuyas responsabilidades pueden utilizarse en otras aplicaciones.

11 Indirección. Problema que Se asigna la responsabilidad a un objeto intermedio para que medie entre otros componentes o servicios, y estos no terminen directamente acoplados. El intermedio crea una indirección entre el resto de los componentes o servicios. A quién se asignará las responsabilidades a fin de evitar el acoplamiento directo? De qué manera se desacoplarán los objetos de modo que se obtenga un Bajo Acoplamiento y se conserve un alto potencial de reutilización? Explicación: El motivo para la Indirección normalmente es el Bajo Acoplamiento; se añade un intermediario para desacoplar otros componentes o servicios. Bajo Acoplamiento. Variaciones Protegidas. Identifique los puntos de variaciones previstas o de inestabilidad; asigne responsabilidades para crear una interfaz estable alrededor de ellos. Cómo diseñar objetos, subsistemas y sistemas de manera que las variaciones o inestabilidades en estos elementos no tengan un impacto no deseable en otros elementos? Añadiendo un nivel de indirección, una interfaz, y utilizando el polimorfismo con varias implementaciones, se consigue proteger al sistema de las variaciones externas. Los objetos internos colaboran con una interfaz estable; las distintas implementaciones del adaptador ocultan las variaciones de los sistemas externos. Se añaden fácilmente las extensiones que se necesitan para nuevas variaciones. Se pueden introducir nuevas implementaciones sin afectar a los clientes. Se reduce el acoplamiento. Puede disminuirse el impacto o coste de los cambios.

12 Adaptador. Convierta la interfaz original de un componente en otra interfaz, mediante un objeto adaptador intermedio. Cómo resolver interfaces incompatibles, o proporcionar una interfaz estable para componentes parecidos con diferentes interfaces? Es un ejemplo del patrón Polimorfismo. Factoría. El Adaptador da lugar a un nuevo problema en el diseño: quién crea el adaptador? Cómo determinar qué clase de adaptador crear? Si los crea algún objeto del dominio, las responsabilidades de los objetos del dominio exceden la lógica pura de la aplicación y entran en otras cuestiones relacionadas con la conexión con componentes software externos. Además, hay que dividir en módulos o separar intereses distintos en áreas diferentes, de manera que cada una tenga un propósito cohesivo. Por tanto, la elección de un objeto del dominio para crear los adaptadores no está de acuerdo con el objetivo de separación de intereses, y disminuye su cohesión. Una alternativa típica es aplicar el patrón Factoría (o Factoría Concreta), en el que se define un objeto Fabricación Pura factoría para crear los objetos. Los objetos Factoría tienen varias ventajas: Separan la responsabilidad de la creación compleja en objetos de apoyo cohesivos. Ocultan la lógica de creación potencialmente compleja. Permiten introducir estrategias para mejorar el rendimiento de la gestión de la memoria, como objetos caché o de reciclaje. A menudo se accede a las factorías con el patrón Singleton.

13 Factoría Abstracta. Proporciones una interfaz para crear familias de objetos relacionados o que dependen entre sí, sin especificar sus clases concretas. Cómo crear familias de clases relacionadas que implementan una interfaz común? Contraindicaciones: Es difícil soportar nuevas clases de productos. Aísla a los clientes de las clases concretas de implementación. Favorece la consistencia entre productos. Singleton. Definir un método de clase o una función que no sea miembro y que devuelve el singleton. Permitir solo una instancia de una clase. Los objetos necesitan un solo punto de acceso. A veces conviene soportar la visibilidad global o un solo punto de acceso a una instancia individual de una clase y no a alguna otra forma de visibilidad. Puesto que la visibilidad ante las clases tiene un ámbito global, todo objeto puede llamar directamente el método clase que devuelva el elemento considerado Singleton. Permite el manejo de objetos únicos y que sean accesibles a otros objetos. Acceso controlado a la única instancia.

CLASE 10: MÁS PATRONES. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez

CLASE 10: MÁS PATRONES. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez CLASE 10: MÁS PATRONES Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez Polimorfismo Problema: Cómo manejar las alternativas basadas en el tipo? Cómo crear componentes conectables?

Más detalles

Patrones de diseño. Programación III.I.T.I. de Sistemas. Contenidos. Información sobre patrones de diseño. Motivación.

Patrones de diseño. Programación III.I.T.I. de Sistemas. Contenidos. Información sobre patrones de diseño. Motivación. Departamento de Informática Universidad de Valladolid Programación III.I.T.I. de Sistemas Patrones 1 Contenidos Programación III.I.T.I. de Sistemas Patrones de diseño Patrones de diseño Introducción Conceptos

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

DISEÑO DE FUNCIONES (TRATAMIENTOS)

DISEÑO DE FUNCIONES (TRATAMIENTOS) DISEÑO DE FUNCIONES (TRATAMIENTOS) Diseño Estructurado. Estrategias para Derivar el Diagrama de Estructura. Diseño de Módulos Programables. 1. DISEÑO ESTRUCTURADO El Diseño es el proceso por el cual se

Más detalles

Diseño orientado al flujo de datos

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

Más detalles

Fundamentos de Ingeniería de Software

Fundamentos de Ingeniería de Software Fundamentos de Ingeniería de Software Marcello Visconti y Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María {visconti,hernan} en inf.utfsm.cl Fundamentos de Ingeniería

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

a) Cita y comenta brevemente los grados de acoplamiento. Clasifícalos y ordénalos en orden creciente al nivel de acoplamiento asociado.

a) Cita y comenta brevemente los grados de acoplamiento. Clasifícalos y ordénalos en orden creciente al nivel de acoplamiento asociado. Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE II: CONCEPTOS TEÓRICOS Y PRÁCTICOS DNI Apellidos y nombre 1. Responde a las siguientes cuestiones (2 puntos): a) Cita y comenta brevemente

Más detalles

Java Inicial (20 horas)

Java Inicial (20 horas) Java Inicial (20 horas) 1 Temario 1. Programación Orientada a Objetos 2. Introducción y Sintaxis Java 3. Sentencias Control Flujo 4. POO en Java 5. Relaciones entre Objetos 6. Polimorfismo, abstracción

Más detalles

UNIDAD Nº 4. Construcción de un Modelo Conceptual

UNIDAD Nº 4. Construcción de un Modelo Conceptual UNIDAD Nº 4 Construcción de un Modelo Conceptual 1. Introducción Un Modelo Conceptual explica (a sus creadores) los conceptos significativos en un dominio del problema, es el artefacto más importante a

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

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

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

Curso de Spring Framework

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

Más detalles

Introducción a los Tipos Abstractos de Datos

Introducción a los Tipos Abstractos de Datos Página 1 de 8 Introducción a los Tipos Abstractos de Datos Introducción: Concepto de abstracción Abstracción funcional y abstracción de datos Construcción de tipos abstractos de datos Especificación de

Más detalles

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

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

Parte 1 Múltiple Opción

Parte 1 Múltiple Opción Cada pregunta de la parte múltiple opción contestada correctamente tiene un valor de 1,5 puntos. Cada pregunta incorrecta de la múltiple opción resta 0,5 puntos. Esta parte consta de 25 preguntas por lo

Más detalles

Introducción a Bases de Datos

Introducción a Bases de Datos de a M. -Tastets Universidad de Concepción,Chile www.inf.udec.cl\ andrea andrea@udec.cl II Semestre - 2007 y del s: Sistemas de y del s: de y del s: Objetivos de la Unidad Dar a conocer las características,

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

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Modelado de datos Relacional Modelado de datos Orientado a Objeto Modelado de datos Objeto-Relacional

Modelado de datos Relacional Modelado de datos Orientado a Objeto Modelado de datos Objeto-Relacional 2. 1 Modelado de Datos El manejo de información implica el saber como organizar los datos. Un apoyo lo encontramos en las herramientas de bases de datos que a su vez se apoyan en el modelo de datos. Para

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

Q-flow 3.1: Introducción a Q-flow

Q-flow 3.1: Introducción a Q-flow Q-flow 3.1: Introducción a Q-flow Código del manual: Qf310001ESP Versión: 1.1 Se aplica a: Q-flow 3.1 Última revisión: 13/12/2010 i Q f 3 1 0 0 0 1 E S P v 1. 1 Q - f l o w 3.1 Introducción a Q-flow Urudata

Más detalles

Qué se entiende por diseño arquitectónico? Comprende el establecimiento de un marco de trabajo estructural básico para un sistema. Alude a la estructura general del software y el modo en que la estructura

Más detalles

Programación Orientada a Objetos en Java

Programación Orientada a Objetos en Java Programación Orientada a Objetos en Java Curso 2006-2007 Tema 4 Herencia y Polimorfismo Gonzalo Méndez Pozo Dpto. de Ingeniería de Software e Inteligencia Artificial Universidad Complutense de Madrid Herencia

Más detalles

Evolución histórica 60 -. Metodologías

Evolución histórica 60 -. Metodologías TEMA 1 INTRODUCCIÓN Historia Evolución de las técnicas de programación Qué es orientado a objetos? Factores cruciales que miden la calidad del software Externos Internos La familia Orientada a objetos

Más detalles

- MANUAL TÉCNICO - Implantación de software de Marketing Online

- MANUAL TÉCNICO - Implantación de software de Marketing Online - MANUAL TÉCNICO - Implantación de software de Marketing Online Rev. 01- MAYO 2013 Implantación de software de Marketing Online Teléfono Adeada: 945 253 388 Email Adeada: adeada@adeada.com REALIZADO POR:

Más detalles

2.2.- Paradigmas de la POO

2.2.- Paradigmas de la POO 2.2.- Paradigmas de la POO Los principios propios de la orientación a objetos son: 2.2.1.- Abstracción de Datos 2.2.2.- Encapsulamiento 2.2.3.- Ocultamiento 2.2.4.- Herencia 2.2.5.- Polimorfismo Cualquier

Más detalles

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software 2. Conceptos básicos Hoy en día las aplicaciones son demasiado voluminosas y complejas para ser manejadas por una sola persona. Las aplicaciones de software son complejas porque modelan la complejidad

Más detalles

A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013

A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013 3.3: Realización de diagramas de secuencia: capas software y patrones GRASP A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013 3.3.- Cómo realizar los diagramas de 30 secuencia a partir de los flujos

Más detalles

Introducción CAPÍTULO 1

Introducción CAPÍTULO 1 Introducción CAPÍTULO 1 6 CAPÍTULO 1 - Introducción. En la actualidad hay una gran cantidad de repositorios en los que se puede alojar código fuente para poder compartirlo con los usuarios que visiten

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

BASES DE DATOS TEMA 1. INTRODUCCION

BASES DE DATOS TEMA 1. INTRODUCCION Contenidos generales BASES DE DATOS TEMA 1. INTRODUCCION Bases de datos, Sistemas de gestión de bases de datos y Sistemas de bases de datos Bases de datos vs. Sistemas de archivos Objetivos de los Sistemas

Más detalles

Patrones GRASP. Macario Polo Usaola - Patrones GRASP 1

Patrones GRASP. Macario Polo Usaola - Patrones GRASP 1 Patrones GRASP Macario Polo Usaola - Patrones GRASP 1 Patrones GRASP Acrónimo de General Responsibility Assignment Software Patterns. Describen los principios fundamentales para asignar responsabilidades

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

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

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

Estructura de Bases de datos. Leonardo Víquez Acuña

Estructura de Bases de datos. Leonardo Víquez Acuña Estructura de Bases de datos Leonardo Víquez Acuña Lenguajes de Bases de Datos Un sistema de bases de datos proporciona Un lenguaje de definición de datos para especificar el esquema de la base de datos

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

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

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas Departamento de Informática PROGRAMACIÓN DIDÁCTICA Curso 11-12 1 CONSEJERÍA DE EDUCACIÓN I.E.S. NERVIÓN Departamento de Informática CICLO FORMATIVO: TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA.

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

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

CAPITULO V DISEÑO DEL CUADRO DE MANDO INTEGRAL

CAPITULO V DISEÑO DEL CUADRO DE MANDO INTEGRAL CAPITULO V DISEÑO DEL CUADRO DE MANDO INTEGRAL Al hablar del balance scorecard, no deberíamos referirnos al mismo como Proyecto, sino más bien como Programa. Esto solamente para dar al balanced scorecard

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

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

CAPÍTULO 6. El Software Orientado a Objetos (OO) es fundamentalmente distinto del

CAPÍTULO 6. El Software Orientado a Objetos (OO) es fundamentalmente distinto del CAPÍTULO 6 Métricas para Sistemas Orientados a Objetos El Software Orientado a Objetos (OO) es fundamentalmente distinto del software que se desarrolla utilizando métodos convencionales. Las métricas para

Más detalles

UML 2 Iniciación, ejemplos y ejercicios corregidos

UML 2 Iniciación, ejemplos y ejercicios corregidos Ediciones ENI UML 2 Iniciación, ejemplos y ejercicios corregidos (3ª edición) Colección Recursos Informáticos Contenido Contenido 1 Capítulo 1 Introducción 1. Motivaciones de la obra.....................................

Más detalles

Capítulo 5. Cliente-Servidor.

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

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS ANÁLISIS Y DISEÑO DE SISTEMAS Clase XVIII: Modelo Dinámico Diagramas de Actividades Primer Cuatrimestre 2013 Diagrama de Actividades (DA) Un grafo o diagrama de actividad (DA) es un tipo especial de máquina

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 3: Estructura del sistema operativo. 3.1 Componentes del sistema. 3.2 Servicios del sistema operativo. 3.3 Llamadas al sistema. 3.4 Programas

Más detalles

Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT

Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT Proyecto de Fin de Carrera Universidad Politécnica de Valencia Escuela Técnica Superior de Informática Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT Realizado por: Dirigido

Más detalles

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Base de Datos ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Una base de datos es un conjunto de elementos de datos que se describe a sí mismo, con relaciones entre esos elementos, que presenta

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

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

Bloques Repetitivos: Iteración

Bloques Repetitivos: Iteración Fuente: www.appinventor.org Traducción hecha con Google Traductor y mejorada por mi: piatticarlos@gmail.com Bloques Repetitivos: Iteración Una cosa para la que los ordenadores son buenos es la repetición

Más detalles

Curso de Java POO: Programación orientada a objetos

Curso de Java POO: Programación orientada a objetos Curso de Java POO: Programación orientada a objetos Luis Guerra Velasco Curso INEM 02830. Programación en Java Marzo 2010 Índice 1 Introducción a la POO 2 Herencia y polimorfismo 3 Empaquetado de proyectos

Más detalles

Unidad I: Sistemas Gestores de Bases de Datos. 1.1 Objetivo de las Bases de Datos

Unidad I: Sistemas Gestores de Bases de Datos. 1.1 Objetivo de las Bases de Datos Unidad I: Sistemas Gestores de Bases de Datos. 1.1 Objetivo de las Bases de Datos Redundancia e inconsistencia de datos: Puesto que los archivos que mantienen almacenada la información son creados por

Más detalles

Unidad 8. Análisis y evaluación de inversiones

Unidad 8. Análisis y evaluación de inversiones Unidad 8. Análisis y evaluación de inversiones 0. ÍNDICE. 1. CONCEPTO DE INVERSIÓN. 2. TIPOS DE INVERSIÓN. 2.1. Atendiendo a su período de vinculación con la empresa. 2.2. Según su materialización. 2.3.

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reutilizable Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Objetivos Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir

Más detalles

Especificación de Requisitos según el estándar de IEEE 830

Especificación de Requisitos según el estándar de IEEE 830 Especificación de Requisitos según el estándar de IEEE 830 IEEE Std. 830-1998 22 de Octubre de 2008 Resumen Este documento presenta, en castellano, el formato de Especificación de Requisitos Software (ERS)

Más detalles

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa.

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. BASES DE DATOS Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. La creación de una base de datos debe ser realizada cuidadosamente procurando

Más detalles

Ejemplos de conversión de reales a enteros

Ejemplos de conversión de reales a enteros Ejemplos de conversión de reales a enteros Con el siguiente programa se pueden apreciar las diferencias entre las cuatro funciones para convertir de reales a enteros: program convertir_real_a_entero print

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

El modelo de casos de uso. Ingeniería de la Programación

El modelo de casos de uso. Ingeniería de la Programación El modelo de casos de uso Ingeniería de la Programación Prácticas cas 1 Contenidos Introducción RF y RNF Introducción al modelo de RF de UML. Actores y Casos de Uso Modelo de casos de uso Diagrama de contexto

Más detalles

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA)

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) SOLUCIÓN (más completa que el mínimo requerido para obtener los máximos puntajes) Pregunta 1 En el sistema de nombre de dominio (DNS): a)

Más detalles

Simarro Software, S.A

Simarro Software, S.A DE SERVICIOS WEBS. PRESENTACIÓN DEL LENGUAJE HTS Objetivos generales Módulo Herramienta Web Simarro Software, S.A También se han desarrollado una serie de aplicaciones como son: Este lenguaje representa

Más detalles

11/06/2011. Alumno: José Antonio García Andreu Tutor: Jairo Sarrias Guzman

11/06/2011. Alumno: José Antonio García Andreu Tutor: Jairo Sarrias Guzman 11/06/2011 Alumno: José Antonio García Andreu Tutor: Jairo Sarrias Guzman Introducción Gestión de tareas Unificar la vía por la que se requieren las tareas Solución única y global Seguimiento de las tareas

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

INTRODUCCIÓN. Estructura de Datos Tipos Abstractos de Datos (TAD S) Profs. Lorna Figueroa M. Mauricio Solar F. UTFSM 1 / 2008

INTRODUCCIÓN. Estructura de Datos Tipos Abstractos de Datos (TAD S) Profs. Lorna Figueroa M. Mauricio Solar F. UTFSM 1 / 2008 INTRODUCCIÓN Estructura de Datos Tipos Abstractos de Datos (TAD S) Para poder obtener un programa que resuelva un problema dado, son necesarios varios pasos : La formulación y especificación del problema

Más detalles

Ejemplo de Análisis Orientado a Objetos ATMs

Ejemplo de Análisis Orientado a Objetos ATMs Ejemplo de Análisis Orientado a Objetos ATMs Se desea diseñar el software necesario para una red bancaria provista de cajeros automáticos (ATMs), que serán compartidos por un consorcio de bancos. Cada

Más detalles

Tema 1. Arquitectura Cliente/Servidor

Tema 1. Arquitectura Cliente/Servidor Tema 1. Arquitectura Cliente/Servidor SCS Sistemas Cliente/Servidor 4 o informática http://ccia.ei.uvigo.es/docencia/scs 27 de septiembre de 2009 FJRP, FMBR [sistemas cliente-servidor] CCIA 1.1 Sistemas

Más detalles

Tema 1 Introducción a la Ingeniería de Software

Tema 1 Introducción a la Ingeniería de Software Tema 1 Introducción a la Ingeniería de Software Curso Ingeniería de Software UMCA Profesor Luis Gmo. Zúñiga Mendoza 1. Software En la actualidad todo país depende de complejos sistemas informáticos. Podemos

Más detalles

Diseño Organizacional. Lectura No. 8 Estructura y Diseño Organizacional

Diseño Organizacional. Lectura No. 8 Estructura y Diseño Organizacional Diseño Organizacional Lectura No. 8 Estructura y Diseño Organizacional Contextualización 1. Concepto 9. Características de las estructuras efectivas 2. Elementos de la estructura organizacional 8. Tendencias

Más detalles

- MANUAL TÉCNICO - Software de diagnóstico de la seguridad de la información y autoimplantación de LOPD. Rev. 01- FEBRERO 2013

- MANUAL TÉCNICO - Software de diagnóstico de la seguridad de la información y autoimplantación de LOPD. Rev. 01- FEBRERO 2013 - MANUAL TÉCNICO - Software de diagnóstico de la seguridad de la información y autoimplantación de LOPD Rev. 01- FEBRERO 2013 Software de diagnóstico de la seguridad de la información y autoimplantación

Más detalles

Patrones Creacionales Builder. Patrones Creacionales Abstract Factory. Patrones Creacionales Singleton. Patrones Creacionales Prototype

Patrones Creacionales Builder. Patrones Creacionales Abstract Factory. Patrones Creacionales Singleton. Patrones Creacionales Prototype Temario Patrones de Diseño de Software Fundamentos de Ingeniería de SW Jocelyn Simmonds GOF: Patrones Creacionales Patrones Estructurales ILI-236 (JS) Patrones II 1 / 31 ILI-236 (JS) Patrones II 2 / 31

Más detalles

CLASE 6: MODELO CONCEPTUAL/ MODELO DE DOMINIO. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Carolina Martínez

CLASE 6: MODELO CONCEPTUAL/ MODELO DE DOMINIO. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Carolina Martínez CLASE 6: MODELO CONCEPTUAL/ MODELO DE DOMINIO Universidad Simón Bolívar. Ing. de Software. Prof. Ivette Carolina Martínez Qué es un Modelo de Dominio Un Modelo de Dominio es una representación visual de

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

GUIA PROGRAMACIÓN ORIENTADA A OBJETOS

GUIA PROGRAMACIÓN ORIENTADA A OBJETOS GUIA PROGRAMACIÓN ORIENTADA A OBJETOS 1. Por qué la P.O.O? R= A medida que se van desarrollando los lenguajes, se va desarrollando también la posibilidad de resolver problemas más complejos. En la evolución

Más detalles

8 Conjunto de protocolos TCP/IP y direccionamiento IP

8 Conjunto de protocolos TCP/IP y direccionamiento IP 8 Conjunto de protocolos TCP/IP y direccionamiento IP 8.1 Introducción a TCP/IP 8.1.1 Historia de TCP/IP El Departamento de Defensa de EE.UU. (DoD) creó el modelo de referencia TCP/IP porque necesitaba

Más detalles

Sistema de gestión de tareas y proyectos

Sistema de gestión de tareas y proyectos Sistema de gestión de tareas y proyectos Propuesta de proyecto Seminario de Informática I Luis Muñoz Enrique Viard Contenido Introducción... 3 Descripción general... 3 Arquitectura propuesta... 5 Requisitos...

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

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

Compiladores y Lenguajes de Programación. Maria de Guadalupe Cota Ortiz

Compiladores y Lenguajes de Programación. Maria de Guadalupe Cota Ortiz Compiladores y Lenguajes de Programación Maria de Guadalupe Cota Ortiz Organizaciones que rigen las normas para estandarización de Lenguajes de Programación IEEE (Instituto de Ingenieros Eléctricos y Electrónicos)

Más detalles

Patrones de diseño. Sesión 1: Introducción y patrones básicos. Especialista Universitario Java Enterprise

Patrones de diseño. Sesión 1: Introducción y patrones básicos. Especialista Universitario Java Enterprise Sesión 1: Introducción y patrones básicos Titulo Módulo 2006-2007 Depto. Ciencia de la Computación e IA Titulo sesión-1 En el desarrollo de aplicaciones J2EE ( y no J2EE!) se presentan una y otra vez los

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

PATRONES DE DISEÑO. FAVA - Formación en Ambientes Virtuales de Aprendizaje. SENA - Servicio Nacional de Aprendizaje

PATRONES DE DISEÑO. FAVA - Formación en Ambientes Virtuales de Aprendizaje. SENA - Servicio Nacional de Aprendizaje PATRONES DE DISEÑO 1. Generalidades 2. Patrones Gof 2.1. Patrones Creacionales 2.1.1.Fábrica Abstracta 2.1.2.Constructor 2.1.3.Método de Factoría 2.1.4.Prototipo 2.1.5.Singleton 2.2. Patrones Estructurales

Más detalles

Model View Controller Architecture. Dra. Marcela Capobianco

Model View Controller Architecture. Dra. Marcela Capobianco Diseño y Desarrollo de Software Model View Controller Architecture Dra. Marcela Capobianco 1 Qué es MVC? Model View Controller (MVC) es un patrón agregado que separa los datos de una aplicación, la interfaz

Más detalles

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

SOLUCION PARCIAL TASK SCHEDULER. Task Scheduler

SOLUCION PARCIAL TASK SCHEDULER. Task Scheduler Task Scheduler Se necesita modelar una aplicación que permita definir tareas y ejecutarlas en forma programada. Las tareas pueden ser: La ejecución de programa cualquiera o comando del sistema operativo,

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

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

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

Más detalles

ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS

ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS INGENIERIA DE SOFTWARE Trabajo Final de Carrera ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS Jordi Cid Rodríguez - ETIG - Consultor: José Antonio Raya Martos Septiembre 2011 Objetivo El

Más detalles

Cuaderno de notas del OBSERVATORIO

Cuaderno de notas del OBSERVATORIO Cuaderno de notas del OBSERVATORIO Instituto Nacional de Tecnologías de la Comunicación CORTAFUEGOS (FIREWALLS): QUÉ SON Y PARA QUÉ SIRVEN Los firewalls o cortafuegos son una de las herramientas básicas

Más detalles

SOFTWARE COLABORATIVO

SOFTWARE COLABORATIVO SOFTWARE COLABORATIVO Software colaborativo o groupware son un conjunto de programas informáticos que integran el trabajo en un sólo proyecto con muchos usuarios concurrentes que se encuentran en diversas

Más detalles