SISTEMAS DE INFORMACIÓN II TEORÍA
|
|
- Alejandra Henríquez Ríos
- hace 8 años
- Vistas:
Transcripción
1 CONTENIDO: ARQUITECTURA DEL SISTEMA DE SOFTWARE NIVELES DE DISEÑO DE LOS SISTEMAS DE SOFTWARE CUALIDADES DE LAS ARQUITECTURAS ESTILOS Y PATRONES - ESTILOS ARQUITECTÓNICO - PATRÓN ARQUITECTÓNICO FRAMEWORK PATRONES DE DISEÑO EL MODELO DE ARQUITECTURA 4+1 VISTAS Material diseñado y elaborado por: Prof. María A. Pérez de Ovalles Prof. Luis Eduardo Mendoza M.
2 ARQUITECTURA DEL SISTEMA DE SOFTWARE Se obtiene mediante un proceso de partición que relaciona los elementos de una solución de software con partes de un problema del del mundo real definido implícitamente durante el análisis de los requisitos. La solución aparece cuando cada parte del problema está resuelta mediante uno o más elementos de software. El diseño y la especificación completa de la estructura de los sistemas de software, según Shaw y Garlan (Shaw y Garlan, 1996), se está transformando en un aspecto de más importancia que la escogencia de los algoritmos y las estructuras de datos, en virtud del tamaño y la complejidad de estos es la actualidad Diseñar la arquitectura del software, según estos mismos autores, es definir los aspectos estructurales como una composición de componentes, las estructuras globales de control, los protocolos de comunicación, la sincronización y acceso a los datos, la asignación de la funcionalidad a los elementos del diseño, la composición de estos elementos, su distribución física, su escalabilidad y su desempeño.
3 ARQUITECTURA DEL SISTEMA DE SOFTWARE Define al sistema en términos de elementos computacionales y de las interacciones entre ellos. La arquitectura muestra la correspondencia entre los requerimientos de sistemas y los elementos del sistema construido, proveyendo así una exposición racional para las decisiones de diseño. ELEMENTOS COMPUTACIONALES. Son entidades tales como clientes, servidores, bases de datos, filtros y capas de un sistema jerárquico. Son además, una parte encapsulada del sistema de software, donde cada uno tiene una interfaz. INTERACCIONES. Ocurren entre los elementos a nivel de diseño, puediendo ser tan simples como las llamadas a procedimientos o variables de acceso, o tan complejas y semánticamente ricas como los protocolos del modelo cliente/servidor, los protocolos de acceso a las bases de datos, la difusión de ls eventos asincrónicos y las ráfagas (stream) de los pipes. (Shaw y Garlan, 1996).
4 ARQUITECTURA DEL SISTEMA DE SOFTWARE Una relación, además denota una conexión entre los componentes. Una relación puede ser estática o dinámica. Relaciones estáticas. Se muestran en el código fuente, ellas reflejan la colocación de los componentes dentro de la arquitectura. Relaciones dinámicas. tratan con las conexiones temporales y las interacciones dinámicas entre los componentes. Ellas no son fácilmente visibles a partir del código fuente. PROPIEDAD FUNCIONAL. Tiene que ver con un aspecto de la funcionalidad del sistema, como su nombre lo indica. Está usualmente relacionada con un requerimiento. PROPIEDAD NO FUNCIONAL. Trata de una característica del sistema que no está cubierta en la descripción funcional del mismo. Típicamente se refiere a aspectos tales como confiabilidad, compatibilidad, costo, facilidad de uso, etc.
5 NIVELES DE DISEÑO DE LOS SISTEMAS DE SOFTWARE ARQUITECTURA. Los aspectos de diseño involucran la asociación de la capacidad de todo el sistema con componentes. Los componentes son módulos y la interconexión entre los módulos se maneja de maneras diferentes. La composición está orienta hacia subsistemas. CÓDIGO. El diseño involucra algoritmos y estructuras de datos. Los componentes son primitivas de lenguajes de programación, tales como números, caracteres, etc. Los mecanismos de composición son arreglos, registros, procedimientos, etc. EJECUTABLE. El diseño involucra mapas de memoria, arreglos de datos, asignaciones de registros, etc. Los componentes son patrones de bits soportados por el hardware y las composiciones se escriben en lenguaje de máquina.
6 CUALIDADES DE LAS ARQUITECTURAS CONFORMIDAD FUNCIONAL. Según Pressman (Pressman, 1998) una arquitectura de calidad debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acomodar todos los requisitos implícitos que desea el cliente. Además, debe proporcionar una idea completa de que es el software, enfocando los dominios de los datos, las funciones y los comportamientos. Según Lawrence (Lawrence, 1998) la arquitectura del software le dice a los usuarios exactamente lo que el sistema de software hará. ADAPTABILIDAD. Esta característica la propone Sommerville (Sommerville, 1998) al señalar que ella mide cuan fácil es hacer cambios en una arquitectura; de seguro, esto implica componentes poco acoplados. En su opinión, un sistema de software adaptable tiene una alta trazabilidad; esto quiere decir, que hay una relación clara entre los diferentes niveles de abstracción.
7 CUALIDADES DE LAS ARQUITECTURAS MODULARIDAD. Sin considerar el enfoque de diseño utilizado (estilo arquitectural) (Lawrence, 1998), el proceso de descomposición separa el diseño en partes que lo componen, llamadas módulos o componentes. Se dice que un sistema es modular cuando cada actividad del sistema de software es ejecutada exactamente por un componente y cuando las entradas y las salidas de los componentes están bien definidas. Los módulos se organizan jerárquicamente como resultado de la descomposición. En la opinión de Pressman (Pressman, 1998), estos módulos se integrarán para satisfacer los requisitos del sistema. Para este autor modularidad es el atributo del software que permite a un sistema ser manejable intelectualmente. Lawrence (Lawrence, 1998) además agrega que los módulos encapsulan información; la ventaja de esta característica es que el diseño interno de cada componente está oculto para el resto de los otros componentes.
8 CUALIDADES DE LAS ARQUITECTURAS NIVELES DE ABSTRACCIÓN. Según Lawrence (Lawrence, 1998), estos módulos se estructuran según niveles de abstracción. Estos niveles de abstracción ayudan a entender el problema a ser resuelto por el sistema y la solución propuesta. Según Pressman (Pressman, 1998), cuando se plantea una solución modular se pueden presentar muchos niveles de abstracción. Cada fase del proceso de diseño es un refinamiento en el nivel de abstracción. Pressman (Pressman, 1998) propone tres (3) niveles de abstracción: Abstracción procedimental. Es una secuencia dada de instrucciones que tiene una función específica y limitada. Abstracción de datos. Es una colección determinada de datos que describen un objeto de datos. Abstracción de control. Implica un mecanismo de control del programa sin especificar detalles internos.
9 CUALIDADES DE LAS ARQUITECTURAS ENTENDIBLE. Sommerville (Sommerville, 1998) señala que un sistema antes de hacerle un cambio debe ser entendido. En su opinión este entendimiento estará afectado por: La cohesión, el acoplamiento, la nominación, la documentación y la complejidad; inclusive, señala que la complejidad tiene una relación directa con su fácil entendimiento. COHESIÓN. Es una consecuencia del ocultamiento de la información. Un módulo con cohesión (Pressman, 1998) realiza solamente una tarea, requiriendo poca interacción con el resto de los procedimientos que se realizan en el resto del sistema de software. Según Sommerville (Sommerville, 1998) la cohesión es deseable debido a que una unidad (componente) representa una parte simple de solución. Si es necesario cambiar el sistema, la parte correspondiente está en un solo lugar y lo que se desee hacer con él estará encapsulado en él. Según Lawrence (Lawrence, 1998) la meta es hacer que los componentes sean lo más cohesivos posible.
10 CUALIDADES DE LAS ARQUITECTURAS ACOPLAMIENTO. Está relacionado con la cohesión. Es un indicador de la fuerza de interconexión entre los componentes o elementos de la arquitectura (Sommerville, 1998). Sistemas altamente acoplados tienen una fuerte interconexión, lo que se refleja en una gran dependencia entre los componentes. Los sistemas poco acoplados, por otro lado, tienen poca relación entre sus componentes o elementos. La meta (Lawrence, 1998) es mantener el acoplamiento en el nivel más bajo posible; la conectividad sencilla entre módulos da como resultado un software que es más fácil de comprender y menos propenso al efecto onda (Stevens et al., 1975) producido cuando los errores aparecen en una posición y se propagan a lo largo del sistema. Pressman (Pressman, 1998) agrega que el acoplamiento depende de la complejidad de las interfaces entre los módulos, del punto en el que se hace una entrada o referencia a un módulo y de los datos pasan a través de esa interfaz.
11 ARQUITECTURA Y ATRIBUTOS DE CALIDAD DE LOS SISTEMAS Bass et al. (2000) establecen que para alcanzar un atributo específico, es necesario tomar decisiones de diseño arquitectónico que requieren un pequeño conocimiento de funcionalidad Bass et al. (2000) afirman que cada decisión incorporada en una arquitectura de software puede afectar potencialmente los atributos de calidad. Sin embargo, esto no es evidente, porque: Existen atributos de calidad que, luego de ser estudiados durante años, poseen definiciones generalmente aceptadas Los atributos no están aislados ni son independientes entre sí. El análisis de atributos no se presta a estandarizaciones. Las técnicas de análisis son específicas para un atributo en particular. La arquitectura es un artefacto que determina atributos de calidad del sistema.
12 ARQUITECTURA Y ATRIBUTOS DE CALIDAD DE LOS SISTEMAS Característica Subcaracterística Elementos de tipo arquitectónico Adecuación Refinamiento de los diagramas de secuencia Funcionalidad Confiabilidad Eficiencia Mantenibilidad Portabilidad Exactitud Interoperabilidad Seguridad Tolerancia a fallas Recuperabilidad Desempeño Utilización de recursos Acoplamiento Modularidad Adaptabilidad Instalabilidad Coexistencia Reemplazabilidad Identificación de los componentes con las funciones responsables de los cálculos Identificación de conectores de comunicación con sistemas externos Mecanismos o dispositivos que realizan explícitamente la tarea Existencia de mecanismos o dispositivos de software para manejar excepciones Existencia de mecanismos o dispositivos de software para reestablecer el nivel de desempeño y recuperar datos Componentes involucrados en un flujo de ejecución para una funcionalidad Relación de los componentes en términos de espacio y tiempo Interacciones entre componentes Número de componentes que dependen de un componente Presencia de mecanismos de adaptación Presencia de mecanismos de instalación Presencia de mecanismos que faciliten la coexistencia Lista de componentes reemplazables para cada componente
13 ESTILOS Y PATRONES Bosch (2000) establece que la imposición de ciertos estilos arquitectónicos mejora o disminuye las posibilidades de satisfacción de ciertos atributos de calidad del sistema Cada estilo propicia atributos de calidad, y la decisión de implementar alguno de los existentes depende de los requerimientos de calidad del sistema. Buschmann et al. (1996) afirman que un criterio importante del éxito de los patrones es la forma en que estos alcanzan de manera satisfactoria los objetivos de la ingeniería de software.
14 ESTILOS ARQUITECTÓNICOS Un estilo arquitectónico define una familia de sistemas de software en términos de su organización estructural. Un estilo arquitectónico representa los componentes y las relaciones entre ellos con las restricciones de su aplicación y las asociaciones y reglas de diseño para su construcción. Shaw y Garlan (Shaw y Garlan, 1996) precisan además, que un estilo arquitectónico define un vocabulario de componentes y tipos de conectores.
15 ESTILOS ARQUITECTÓNICOS PIPES and FILTERS (Tuberías y filtros) Cada componente tiene un conjunto de entradas y un conjunto de salidas. Filters (Filtros) Pipes (Tuberías) Un componente lee la ráfaga (stream) de datos en sus entradas y produce una ráfaga de datos en sus salidas. Los componentes se conocen como filtros y son independientes. Los conectores se comportan como conductores de las ráfagas, transmitiendo salidas de un componente hacia entradas de otro. El mejor ejemplo de este estilo son los programas escritos en el Shell de Unix (Bach, 1986). Otros ejemplos se observan en el área de procesamiento de señales, programación paralela y sistemas distribuidos.
16 ESTILOS ARQUITECTÓNICOS ORGANIZACIONES POR TIPOS DE DATOS ABSTRACTOS Y O-O La representación de los datos y sus operaciones primitivas se encapsulan en Tipos de Datos Abstractos (TDA) u objetos. Manejador (TDA) Llamada de un proceso op obj op op op obj obj op op Los componentes son objetos (o instancias de tipos de datos abstractos). Los objetos son ejemplos de un tipo de componente llamado manejador porque es el responsable de preservar la integridad de un recurso Los objetos interactúan a través de invocaciones a funciones y procedimientos. La implementación de las funciones y procedimientos está oculta para el objeto cliente, lo cual permite hacer las modificaciones fácilmente. Para hacer uso de un servicio se hace necesario conocer la identidad del objeto; al hacer un cambio en un objeto es necesario modificar todos los objetos que lo invocan. op obj op op op obj Nota: obj es un manejador op es una invocación
17 ESTILOS ARQUITECTÓNICOS BASADOS EN EVENTOS, INVOCACIÓN IMPLÍCITA En el estilo anterior, la interfaz de los componentes (objetos) cuentan con una colección de procedimientos y funciones, y la integración entre ellos se logra a través de la invocación explícita de éstos. En este estilo, se considera una técnica de integración conocida como invocación implícita. Los componentes son módulos cuyas interfaces proveen una colección de procedimientos y un conjunto de eventos. Los procedimientos se llaman de la manera usual pero el componente también puede activar algunos de sus procedimientos con los eventos del sistema. Esto hará que estos procedimientos sean invocados cuando los eventos ocurren en tiempo de ejecución. Los generadores de eventos no saben cuales componentes se afectarán por el evento. Ejemplos de este estilo son los sistemas de gestión de bases de datos cuando aseguran la consistencia de los datos, las aplicaciones con interfaces de usuarios al separar la representación de los datos de las aplicaciones que las gerencian.
18 ESTILOS ARQUITECTÓNICOS SISTEMAS EN CAPAS Están organizados jerárquicamente; cada capa le presta servicios a la capa superior y es cliente de la capa inferior. Sistemas útiles Servicio base Llamadas usuales de procedimientos Nivel central Composición de varios elementos Usuarios Los componentes implementan un máquina virtual en alguna capa de la jerarquía. Los conectores están definidos en los protocolos que determinan cómo las capas interactúan. Los ejemplos más conocidos de este estilo arquitectural son los protocolos de comunicación.
19 ESTILOS ARQUITECTÓNICOS REPOSITORIOS Consta de dos (2) tipos de componentes: una estructura central de datos que refleja el estado actual y una colección independiente de componentes que operan sobre el almacén central. Acceso directo Nota: fc es una fuente de conocimiento fc8 fc7 fc1 fc6 Blackboard (datos compartidos) Las interacciones entre los componentes pueden variar significativamente. El tipo de control seleccionado puede llevar a dos categorías: Si el tipo de transacción es una entrada que dispara la selección del proceso a ejecutarse, se está hablando de las tradicionales bases de datos. Si el estado actual de la estructura central de datos es el principal activador de los procesos a ejecutarse, se habla de un estilo de repositorio tipo pizarrón (blackboard). Son muy utilizados para aplicaciones que requieren interpretaciones complejas de procesamiento de señales, tales como reconocimiento del habla y de patrones. fc2 fc5 fc3 fc4 Computación Memoria
20 ESTILOS ARQUITECTÓNICOS INTÉRPRETES En una organización intérprete,una maquina virtual es producida en software. Un intérprete incluye el pseudoprograma interpretado y la máquina de interpretación misma. Entradas Computación (máquina) Datos (programa) Memoria Programa a ser interpretado Salidas Motor de interpretación simulado Instrucción seleccionada Datos seleccionados Estado interno del interpretador Acceso a datos (búsqueda/almacenamiento) Los intérpretes son a menudo usados para construir maquinas virtuales que enlazan la máquina de computación esperada por la semántica y la máquina de computación disponible en el hardware.
21 PATRONES ARQUITECTÓNICOS Buschmann et al. (1996) define patrón como una regla que consta de tres partes, la cual expresa una relación entre un contexto, un problema y una solución Estas son: Contexto. Es una situación de diseño en la que aparece un problema de diseño. Problema. Es un conjunto de fuerzas que aparecen repetidamente en el contexto. Solución. Es una configuración que equilibra estas fuerzas. Para Buschmann et al. (1996) son plantillas para arquitecturas de software concretas, que especifican las propiedades estructurales de una aplicación y tienen un impacto en la arquitectura de subsistemas. La selección de un patrón arquitectónico es, por tanto, una decisión fundamental de diseño en el desarrollo de un sistema de software.
22 PATRONES ARQUITECTÓNICOS Patrón Arquitectónico Layers Pipes and Filters Blackboard Broker Model-View- Controler Descripción Consiste en estructurar aplicaciones que pueden ser descompuestas en grupos de subtareas, las cuales se clasifican de acuerdo a un nivel particular de abstracción. Provee una estructura para los sistemas que procesan un flujo de datos. Cada paso de procesamiento está encapsulado en un componente filtro (filter). El dato pasa a través de conexiones (pipes), entre filtros adyacentes. Aplica para problemas cuya solución utiliza estrategias no determinísticas. Varios subsistemas ensamblan su conocimiento para construir una posible solución parcial ó aproximada. Puede ser usado para estructurar sistemas de software distribuido con componentes desacoplados que interactúan por invocaciones a servicios remotos. Un componente broker es responsable de coordinar la comunicación, como el reenvío de solicitudes, así como también la transmisión de resultados y excepciones. Divide una aplicación interactiva en tres componentes. El modelo (model) contiene la información central y los datos. Las vistas (view) despliegan información al usuario. Los controladores (controlers) capturan la entrada del usuario. Las vistas y los controladores constituyen la interfaz del usuario.
23 PATRONES ARQUITECTÓNICOS Patrón Arquitectónico Presentation- Abstraction- Control Microkernel Reflection Descripción Define una estructura para sistemas de software interactivos de agentes de cooperación organizados de forma jerárquica. Cada agente es responsable de un aspecto específico de la funcionalidad de la aplicación y consiste de tres componentes: presentación, abstracción y control. Aplica para sistemas de software que deben estar en capacidad de adaptar los requerimientos de cambio del sistema. Separa un núcleo funcional mínimo del resto de la funcionalidad y de partes específicas pertenecientes al cliente. Provee un mecanismo para sistemas cuya estructura y comportamiento cambia dinámicamente. Soporta la modificación de aspectos fundamentales como estructuras tipo y mecanismos de llamadas a funciones.
24 ESTILOS Y PATRONES ARQUITECTÓNICOS Estilo Arquitectónico Sólo describe el esqueleto estructural y general para aplicaciones Son independientes del contexto al que puedan ser aplicados Cada estilo es independiente de los otros Expresan técnicas de diseño desde una perspectiva que es independiente de la situación actual de diseño Son una categorización de sistemas Patrón Arquitectónico Existen en varios rangos de escala, comenzando con patrones que definen la estructura básica de una aplicación Partiendo de la definición de patrón, requieren de la especificación de un contexto del problema Depende de patrones más pequeños que contiene, patrones con los que interactúa, o de patrones que lo contengan Expresa un problema recurrente de diseño muy específico, y presenta una solución para él, desde el punto de vista del contexto en el que se presenta Son soluciones generales a problemas comunes
25 FRAMEWORK Un framework es más que una jerarquía de clases. Es una jerarquía de clases más un modelo de interacción entre los objetos instanciados a partir del framework. (Levis, Rosenstein, Pree, Weinand, Gamma, Calder, Andert, Vlissides and Schmucker, 1995) Un framework es una técnica de reuso (Johnson, 1997) Un framework es un diseño reusable de todo o partes del sistema que esta representado por un conjunto de clases abstractas y la forma como sus instancias interactúan. Un framework es un esqueleto de una aplicación que puede ser personalizado por un desarrollador de aplicaciones (Johnson, 1997). Un componente representa reuso de código. Los framework son una forma de reuso de diseño (Johnson, 1997).
26 FRAMEWORK Los framework son componentes en el sentido que los vendedores los venden como productos y porque una aplicación puede usar varios framework. Pero los framework son más personalizables que los componentes y tiene interfaces más complejas. (Johnson, 1997) Los framework son una clase de arquitectura de dominio específico. La diferencia principal es que un framework es un diseño orientado a objeto mientras que una arquitectura de un dominio específico puede no serlo (Johnson, 1997). Un framework es reusable, una aplicación semi completa que puede ser especializada para producir aplicaciones personalizadas. (Johnson y Foote, 1998; Fayad, Schmith y Johnson, 1997) En contraste con las técnicas de reuso OO iniciales basadas en librerías, los framework están orientados a unidades del negocio particulares y a dominios de aplicación. (Fayad y Schmith, 97)
27 FRAMEWORK El desarrollo de aplicaciones estará fuertemente basado en la integración de múltiples framework. Clasificando los framework por su alcance, tenemos: Infraestructura de Sistemas: simplifican el desarrollo de infraestructuras de sistemas eficientes y portables tales como sistemas operativos, de comunicación y herramientas de interfaces de usuarios y procesamiento de lenguajes Integración de middleware: Se usan comúnmente para integrar aplicaciones distribuidas y componentes. Se usan para mejorar la habilidad del desarrollador en modularidad, reuso y extensiones de software trabajando en un ambiente distribuido Aplicaciones de empresas: Dirigidos a dominios de aplicación amplios, tales como comunicaciones, manufactura, financieros, etc.
28 PATRONES DE DISEÑO Un patrón describe un problema a ser resuelto, una solución y el contexto en el cual la solución trabaja. Nomina una técnica y describe su costo y su beneficio Estos patrones fueron descubiertos al examinar varios framework y fueron seleccionados como representativos de software reusable. Un simple framework puede contener muchos patrones; es decir, estos patrones son más pequeños que los framework. Por lo tanto, los patrones son mas abstractos que los framework Los patrones de diseño son elementos microarquitectónicos de los framewrok. Aunque el término Patrón de Diseño no es usado explícitamente, los novatos obtienen ganancia de sus experiencias en el desarrollo de software OO al extraer patrones de diseño a partir de varios framework específicos (Pree, 1995)
29 PATRONES DE DISEÑO De acuerdo a Coad, los patrones de diseño son identificados al observar los bloques de construcción de más bajo nivel; esto es sus clases y objetos y las relaciones entre ellos (Pree, 1995). Clasificación: ALCANCE PROPOSITO CLASE CREACIÓN ESTRUCTURAL COMPORTAMIENTO Factory Method Adapter Clss Interpreter OBJECT Abstract Factory Adapter Object Chain of Responsibility Builder Bridge Command Protitype Composite Iterator Singleton Decorator Mediator Façade Memento Flyweight State Proxy Strategy Visitor
30 PATRONES DE DISEÑO Documentación: Nombre del patrón y su clasificación Intención: Qué hace? Qué problema resuelve? Alias o conocido también como Motivación Aplicabilidad Estructura: representación gráfica de la jerarquía de clases y el diagrama de interacción Participantes: las clases que lo componen y sus responsabilidades Consecuencias: trade-off de usar el patrón Implementación: sugerencias y ayudas sobre la implementación, fallas más comunes Usos conocidos: ejemplos donde ha sido usado Patrones relacionados: Qué patrón se relacionan con él? En qué se diferencia de otros?
31 ESTILOS Y PATRONES ARQUITECTÓNICOS Y DE DISEÑO
32 EL MODELO DE ARQUITECTURA 4+1 VISTAS Usuarios finales funcionalidad Vista Vista Lógica Lógica Programadores gerencia del software Vista Vista de de Desarrollo Desarrollo Escenarios Escenarios Vista Vista de de Proceso Proceso Vista Vista Física Física Integradores de sistemas desempeño escalabilidad rendimiento Ingenieros de sistemas topología del sistema entregas instalación telecomunicación El Modelo 4+1 Vistas organiza la descripción de la arquitectura de un software usando cinco (5) vistas concurrentes, cada una de las cuales está dirigida a un conjunto específico de conceptos. Los arquitectos exponen sus decisiones de diseño en cuatro (4) vistas y usan la quinta vista para ilustrar y validar dichas decisiones.
33 EL MODELO DE ARQUITECTURA 4+1 VISTAS VISTA LÓGICA. Describe el modelo objeto del diseño cuando un método de diseño O-O es usado;se puede usar un enfoque alterno para desarrollar alguna otra forma de vista lógica VISTA DE PROCESO. Describe los aspectos de diseño relacionados con la concurrencia y la sincronización. VISTA FÍSICA. Describe el mapa del SW dentro del HW refleja los aspectos de distribución. VISTA DE DESARROLLO. Describe la organización estática del software en el ambiente de desarrollo. ESCENARIOS. Los diseñadores de software organizan la descripción de sus decisiones arquitecturales alrededor de estas cuatro (4) vistas, y las ilustran con una pequeña selección de casos de uso o escenarios, constituyendo así la quinta vista. La arquitectura está parcialmente producida por esos escenarios.
34 INTERDEPENDENCIA ENTRE VISTAS Lógica Procesos Se identifican características tales como: Autonomía, quien invoca a quien. Persitencia. Distribución: desde donde son accesibles las operaciones. Lógica Desarrollo Una clase se puede implementar en un módulo, paquete, etc.
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 detallesEstilos 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 detallesArquitecturas de Software
Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña cjacunia@escet.urjc.es Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO
Más detallesQué se entiende por diseño arquitectónico? Comprende el establecimiento de un marco de trabajo estructural básico para un sistema. Alude a la estructura general del software y el modo en que la estructura
Más detallesFundamentos del diseño 3ª edición (2002)
Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software
Más detallesContenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas
Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a
Más detallesPatrones de software y refactorización de código
Patrones de software y refactorización de código Introducción y antecedentes de los patrones de software Los patrones permiten construir sobre la experiencia colectiva de ingenieros de software habilidosos.
Más detallesIngeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML
Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo
Más detalles3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)
3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.
Más detallesUNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos
2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven
Más detallesInstructivo para la elaboración de un Manual Técnico
Instructivo para la elaboración de un Manual Técnico Autora: Ing. Alena González Reyes. (agonzalez@ceis.cujae.edu.cu) Ciudad de la Habana, Cuba Marzo, 2010 Índice 1. Introducción... 3 2. Confección...
Más detallesSISTEMAS 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 detallesPROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso
PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer
Más detallesArquitectura de Aplicaciones
1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento
Más detallesDISEÑO DE FUNCIONES (TRATAMIENTOS)
DISEÑO DE FUNCIONES (TRATAMIENTOS) Diseño Estructurado. Estrategias para Derivar el Diagrama de Estructura. Diseño de Módulos Programables. 1. DISEÑO ESTRUCTURADO El Diseño es el proceso por el cual se
Más detallesIngenierí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 detallesEntidad Formadora: Plan Local De Formación Convocatoria 2010
Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú
Más detallesAnexo 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 detalles4. 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 detallesProceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:
PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo
Más detallesElementos requeridos para crearlos (ejemplo: el compilador)
Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción
Más detallesCapítulo 4. Prueba de Adaptabilidad
Capítulo 4 Prueba de Adaptabilidad Capítulo 4. Prueba de Adaptabilidad Como se mencionó en el capítulo 2 actualmente no es válido que el software únicamente funcione bien y resuelva el problema que le
Más detallesArquitectura de Software
Arquitectura de Software (Estilos Arquitectónicos) Universidad de los Andes Demián Gutierrez Mayo 2011 1 Diseño Arquitectónico Diseño Arquitectónico Arquitectura del Software Estilos Arquitectónicos Frameworks
Más detallesSERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO
SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3
Más detallesPRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE
PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,
Más detallesDiseñ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 detallesCLASE 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 detallesResumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software
Principio de Diseño Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002 Introducción al Diseño de Software Qué es el diseño? Representación ingenieril
Más detallesARC 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 detallesDISEÑ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 detallesCapítulo 5. Cliente-Servidor.
Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor
Más detallesEn un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuando y Como hacerlo. 6
2. MÉTODO, METODOLOGÍA Y MÉTRICA 2.1 MÉTODO Un método de ingeniería del software es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de alta
Más detallesProceso de desarrollo del software modelo en cascada
Proceso de desarrollo del software modelo en cascada Análisis: Necesidades del usuario especificaciones Diseño: Descomposición en elementos que puedan desarrollarse por separado especificaciones de cada
Más detallesa) 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 detallesIntroducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com
Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad.
Más detallesM.T.I. Arturo López Saldiña
M.T.I. Arturo López Saldiña Hoy en día, existen diversas aproximaciones al tema de cómo hacer que las personas trabajen dentro de una organización de manera colaborativa. El problema se vuelve más difícil
Más detallesArquitectura 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 detallesIntroducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO)
Diseño Orientado a Objetos. Metodología enfocada a la solución de problemas complejos. Complejidad del software. Problemas difíciles de precisar. Definición de requerimientos vago y cambio en el desarrollo
Más detallesforma de entrenar a la nuerona en su aprendizaje.
Sistemas expertos e Inteligencia Artificial,Guía5 1 Facultad : Ingeniería Escuela : Computación Asignatura: Sistemas expertos e Inteligencia Artificial Tema: SISTEMAS BASADOS EN CONOCIMIENTO. Objetivo
Más detallesOMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento
OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje
Más detalles5. Gestión de la Configuración del Software (GCS)
5. Gestión de la Configuración del Software (GCS) 5.1. La Configuración del Software El resultado del proceso de ingeniería del software es una información que se puede dividir en tres amplias categorías:
Más detallesUNIVERSIDAD AUTÓNOMA DE YUCATÁN FACULTAD DE MATEMÁTICAS MISIÓN
UNIVERSIDAD AUTÓNOMA DE YUCATÁN FACULTAD DE MATEMÁTICAS MISIÓN Formar profesionales altamente capacitados, desarrollar investigación y realizar actividades de extensión, en Matemáticas y Computación, así
Más detallesTópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN
Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.
Más detallesimplantación Fig. 1. Ciclo de vida tradicional
1. Ciclo de vida tradicional de los sistemas de software En ingeniería de software, la descripción tradicional del ciclo de vida del software está basada en un modelo conocido como el modelo de cascada
Más detallesDepartamento 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 detallesUnidad III. Software para la administración de proyectos.
Unidad III Software para la administración de proyectos. 3.1 Herramientas de software para administrar proyectos. El software de administración de proyectos es un concepto que describe varios tipos de
Más detallesCapitulo III. Diseño del Sistema.
Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje
Más detallesIntroducción. Conceptos y principios. Introducción. Introducción. Elementos del modelo de análisis. Elementos del modelo de diseño.
Definición de diseño Proceso para la definición detallada de un sistema con el fin de su realización física. Ingeniería del Software 1 Ingeniería del Software 2 Modelo de diseño vs. Paradigma de IS 3 actividades
Más detallesINTRODUCCION. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia
INTRODUCCION. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia Qué es una Red? Es un grupo de computadores conectados mediante cables o algún otro medio. Para que? compartir recursos. software
Más detallesTELECOMUNICACIONES 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 detallesLEY QUE NORMA EL USO, ADQUISICIÓN Y ADECUACIÓN DEL SOFTWARE EN LA ADMINISTRACIÓN PUBLICA
ADQUISICIÓN DE SOFTWARE DE CORREO 1. Nombre del Área :. Responsable de la Evaluación : Aldo Quispe Santa María. Cargo : Director (e) de Tecnología de la Información y Sistemas 4. Fecha : de Julio de 007
Más detallesEstilos Arquitectónicos
Estilos Arquitectónicos Ing. Ariel Cassan 2005 Agenda # Tema Duración 1 Que es un Patrón? 5 min 2 Introducción a estilos arquitectónicos 5 min 2.1 De Estructuración 20 min 2.2 Sistemas distribuidos 5 min
Más detallesMetodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales
Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com
Más detallesCapí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 detallesDiagrama 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 detallesANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN
ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini
Más detallesUniversidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática
Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Metodología Evolutiva Incremental Mediante Prototipo y Técnicas Orientada a Objeto (MEI/P-OO)
Más detallesDiseño de Base de Datos
Diseño de Base de Datos DISEÑO DE BASE DE DATOS 1 Lectura No. 2 Nombre: Arquitectura Cliente-Servidor Contextualización Qué es la arquitectura Cliente-Servidor? En la nueva de las comunicaciones a través
Más detallesARQUITECTURA DE DISTRIBUCIÓN DE DATOS
4 ARQUITECTURA DE DISTRIBUCIÓN DE DATOS Contenido: Arquitectura de Distribución de Datos 4.1. Transparencia 4.1.1 Transparencia de Localización 4.1.2 Transparencia de Fragmentación 4.1.3 Transparencia
Más detallesDiseño orientado a los objetos
Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia
Más detallesPROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción
PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para
Más detallesPlan de estudios ISTQB: Nivel Fundamentos
Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE
Más detalles6.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 detallesAnálisis de Sistemas. M.Sc. Lic. Aidee Vargas C. C. octubre 2007
Análisis de Sistemas M.Sc. Lic. Aidee Vargas C. C. octubre 2007 Metodologías de Desarrollo de Software Las metodologías existentes se dividen en dos grandes grupos: Metodologías estructuradas Metodologías
Más detallesLos 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 detalleshttp://www.cem.itesm.mx/extension/ms
Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos
Más detallesPatrones 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 detallesIngeniería de Software II Segundo Cuatrimestre 2007
Ingeniería de Software II Segundo Cuatrimestre 2007 Clase 4 Parte 1: Introducción a las Arquitecturas de Software Buenos Aires, 3 de Septiembre de 2007 Diagramas de ejemplo Analizando dibujitos Banco 3
Más detallesLICITACIÓ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 detallesWorkflows? 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 detallesProgramación orientada a
Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación
Más detallesSISTEMAS DE INFORMACIÓN I TEORÍA
CONTENIDO: CICLO DE VIDA DE DESARROLLO DE SI FASES GENÉRICAS DEL CICLO DE VIDA DE DESARROLLO DE SI VISIÓN TRADICIONAL DEL CICLO DE VIDA DE DESARROLLO DE SI DE DESARROLLO DE SI: ANÁLISIS Material diseñado
Más detallesINGENIERÍA DE SOFTWARE. Sesión 3: Tipos
INGENIERÍA DE SOFTWARE Sesión 3: Tipos Contextualización Actualmente existe una gran variedad en los software que se pueden clasificar en varias categorías, como pueden ser, por tipo de licencia, tipo
Más detallesTema 1. Conceptos fundamentales de los Sistemas Operativos
Tema 1. Conceptos fundamentales de los Sistemas Operativos 1. Introducción a los Sistemas Operativos. 1. Concepto de Sistema Operativo. Niveles del software. 2. Funciones principales de un Sistema Operativo.
Más detallesMarco 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 detallesRepetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos
I. INTRODUCCIÓN El reciente aumento de aplicaciones en donde se utiliza la computadora ha sido posible debido a un hardware de bajo costo, por lo cual la demanda de software ha crecido de forma exponencial.
Más detallesEstructura 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 detalles1.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 detallesIngeniería de Software en SOA
Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia
Más detalles<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 detallesFigure 7-1: Phase A: Architecture Vision
Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como
Más detallesMetodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web
Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web J.Corral-García, D.Cortés-Polo, C.Gómez-Martín, J.L.González-Sánchez
Más detallesCapítulo 4 Patrones y Patrones de Diseño (ii)
Capítulo 4 Patrones y Patrones de Diseño (ii) Orientado a Objetos Ingeniería Informática Ingeniería Técnica de Informática de Sistemas y Gestión Optativa (6 créditos) http://www.info-ab.uclm.es/asignaturas/42579
Más detallesEstilos Arquitectónicos
Estilos Arquitectónicos Lic. Gastón Coco Ing. Gustavo A. Brey Ing. Juan M. Arias Ing. Jorge García Ing. Santiago Blanco Ing. Fabián Pezet Vila Ing. Ariel Cassan 2005 Agenda # Tema Duración 1 Que es un
Más detallesPROCEDIMIENTO ESPECÍFICO. Código G114-01 Edición 0
Índice 1. TABLA RESUMEN... 2 2. OBJETO... 2 3. ALCANCE... 2 4. RESPONSABILIDADES... 3 5. ENTRADAS... 3 6. SALIDAS... 3 7. PROCESOS RELACIONADOS... 3 8. DIAGRAMA DE FLUJO... 4 9. DESARROLLO... 5 9.1. PROYECTO
Más detallesService Oriented Architecture: Con Biztalk?
Service Oriented Architecture: Con Biztalk? Pablo Abbate Servicios Profesionales Danysoft SOA supone una nueva forma de pensar acerca de la arquitectura IT para las empresas. De hecho, es una asociación
Más detallesIngeniería del Software I
- 1 - Ingeniería del Software I Introducción al Modelo Conceptual 2do. Cuatrimestre 2005 INTRODUCCIÓN... 2 CLASES CONCEPTUALES... 3 ESTRATEGIAS PARA IDENTIFICAR CLASES CONCEPTUALES... 3 Utilizar lista
Más detallesSISTEMAS DE INFORMACION ESTRATEGICOS
SISTEMAS DE INFORMACION ESTRATEGICOS DEFINICION Son el uso de la tecnología de la información para soportar o dar forma a la estrategia competitiva de la organización, a su plan para incrementar o mantener
Más detalles2.4 Modelado conceptual
2.4 Modelado conceptual 2.4. Búsqueda de conceptos Un modelo conceptual muestra clases conceptuales significativas en un dominio del problema; es el artefacto más importante que se crea durante el análisis
Más detallesEstas visiones de la información, denominadas vistas, se pueden identificar de varias formas.
El primer paso en el diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los
Más detallesCapas del Modelo ISO/OSI
Modelo ISO/OSI Fue desarrollado en 1984 por la Organización Internacional de Estándares (ISO), una federación global de organizaciones que representa aproximadamente a 130 países. El núcleo de este estándar
Más detallesrg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s
Especificación de requerimientos Diseño de bases de datos Documento de especificación del sistema 1. Definición del problema 2. Descripción funcional 2. 3. Restricciones 4. Diagramas de flujo de datos
Más detallesResumen 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 detallesInteroperabilidad 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 detallesCapítulo 5. Análisis del software del simulador del sistema de seguridad
1 Capítulo 5. Análisis del software del simulador del sistema de seguridad Para realizar análisis del simulador de sistema de seguridad se recurrió a diagramas de flujo de datos (DFD s), ya que se consideró
Más detallesWindows Server 2012: Identidad y Acceso. Módulo 2: Descripción General de Windows Server 2012 Remote Desktop Services.
Windows Server 2012: Identidad y Acceso Módulo 2: Descripción General de Windows Server 2012 Remote Desktop Services. Manual del Módulo Autor: Andrew J Warren, Content Master Publicado: Septiembre 10 de
Más detalles1.2 SISTEMAS DE PRODUCCIÓN
19 1.2 SISTEMAS DE PRODUCCIÓN Para operar en forma efectiva, una empresa manufacturera debe tener sistemas que le permitan lograr eficientemente el tipo de producción que realiza. Los sistemas de producción
Más detallesOferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo
Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes
Más detallesSolución GeoSAS. Otros módulos
Solución GeoSAS. Otros módulos Informe Marzo 2011 ÍNDICE ÍNDICE 3 1. SOLUCION GIS CORPORATIVA. GEOSAS 4 1.1 PLATAFORMA GEOSAS 5 1.1.1 Servidor de datos. 5 1.1.2 Servidor de aplicaciones. 6 1.1.3 Entornos
Más detallesCompiladores 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