Diseño del Software. Requirements. specification. Design acti vities. Data structure design. Abstract specificatio n.
|
|
- Gustavo del Río de la Cruz
- hace 8 años
- Vistas:
Transcripción
1 Diseño del Software Requirements specification Design acti vities Architectural design Abstract specificatio n Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Data structure specification Algorithm specification Design pr oducts
2 De la Arquitectura al Diseño ξ ω α(ω) (α σ) ε β(ε) ρ(ε) ε ε Ω φ(ε) 2.4 λ δ τ program pepe(); Diseño del Software Ingeniería del Software 1 2
3 Criterios Generales No existe el método ni el criterio general Hay criterios Uso de varias técnicas Formalidad vs. facilidad de instrumentos División en módulos para reducir la complejidad y prevenir cambios Diseño del Software Ingeniería del Software 1 3
4 Módulos: Visión estática De c/u de los subsistemas. El detalle hacia el código pueden estar divididos en submódulos no son rutinas pueden tener memoria persistente Herramienta para reagrupar tipos, estructuras de datos, subprogramas, etc. Porción de software que brinda recursos y servicios computacionales Diseño del Software Ingeniería del Software 1 4
5 Diseño Esta fase se refiere por lo tanto a la identificación de varios módulos y su interrrelación Diseño del Software Ingeniería del Software 1 5
6 Estrategias de Diseño Diseño funcional El sistema es diseñado desde un punto de vista funcional. El estado del sistema es centralizado y compartido entre las funciones que operan sobre el mismo. Diseño Orientado a Objetos El sistema es visto como una colección de objetos interactuando. El estado del sistema es decentralizado y cada objeto maneja su propio estado. Objetos pueden ser instancias de clases de objetos y pueden comunicarse a través de métodos. Diseño del Software Ingeniería del Software 1 6
7 Factores Principales Cohesión: unidad sustancialmente homogénea y que sea fácilmente comprendida Desacoplamiento entre módulos ser comprendidos mirando sólo a ellos Hacen a la independencia funcional Alta cohesión no implica alto desacoplamiento, ni viceversa Diseño del Software Ingeniería del Software 1 7
8 Niveles Cohesión Coincidental cohesion (débil) Las partes son unidas por coincidencia Logical association (débil) Componentes que realizan funciones similares son agrupadas Temporal cohesion (débil) Componentes que son activadas al mismo tiempo son agrupadas Procedural cohesion (débil) Los elementos en una misma secuencia son agrupados Diseño del Software Ingeniería del Software 1 8
9 Niveles de Cohesión Communicational cohesion (media) Todos los elementos de una misma componente operan sobre el mismo input o producen el mismo output Sequential cohesion (media) El output de una parte del componente es el input de otra parte Functional cohesion (fuerte) Cada parte de una componente es necesaria para la ejecución de una función Object cohesion (fuerte) Cada operación provee funcionalidades para modificar o inspeccionar los atributos de un objeto Diseño del Software Ingeniería del Software 1 9
10 Acoplamiento fuerte Module A Module B Module C Module D Shared data area Diseño del Software Ingeniería del Software 1 10
11 Acoplamiento débil Module A A s data Module B B s data Module C C s data Module D D s data Diseño del Software Ingeniería del Software 1 11
12 Hacia un Diseño Modular 5 Criterios Descomponibilidad Componibilidad Comprensibilidad Continuidad Protección 5 Reglas Mapeo Directo Pocas Interfaces Pequeñas interfaces Interfaces explícitas Information Hiding 5 Principios Unidad Lingüística Modular Autodocumentación Uniformidad de Acceso Abierto-Cerrado Simple Opción Diseño del Software Ingeniería del Software 1 12
13 Descomponibilidad Modular Un método de construcción satisface DM si ayuda en la tarea de descomposición del problema software en un número de problemas menos complejos conectados por una estructura simple y lo suficientemente independiente para permitir que el resto del trabajo proceda separadamente (B. Meyer) División de Trabajo Dependencias: pocas pero Conocidas Ej. Top-Down Design ContraEj.: Módulo global de inicialización buena cohesión temporal poca autonomía modular se rompe information hiding En OO cada módulo es responsable de su inicialización. Diseño del Software Ingeniería del Software 1 13
14 Componibilidad Modular Un método de construcción satisface CM si ayuda en la producción de elementos que pueden ser libremente compuestos uno con el otro para producir sistemas nuevos, posiblemente en un ambiente distinto del cual fue inicialmente desarrollado. Sacarlos del contexto original para ser reusados El sueño de la fábrica de ensamblaje Independiente de Descomponibilidad atención con Top-Down Design EJ.1.: librerías (B. Meyer) Ej.2: Shells Unix ContraEj.: Preprocesadores (c++) Diseño del Software Ingeniería del Software 1 14
15 Comprensibilidad Modular Un método de construcción satisface Comprensibilidad Modular si ayuda en la producción de software en la cual un lector humano puede entender cada módulo sin tener que conocer o examinar a ninguno del resto. Proceso de Mantenimiento ContraEj.: dependencia secuencial A!B!C (se entiende B sin A y C?) Documentación (B. Meyer) Diseño del Software Ingeniería del Software 1 15
16 Continuidad Modular Un método de construcción satisface Continuidad Modular, si en la arquitectura de software en la cual se basa, un pequeño problema en la especificaicón dispara un cambio de sólo un módulo o un pequeño grupo de módulos Extendibilidad No definible formalmente Ej.1.: Constantes simbólicas Ej.2.: Principio de Acceso Uniforme (a un objeto sea este un dato directo o algo a ser computado) ContraEj.1: Usar representaciones físicas (B. Meyer) ContraEj.2: Arrays estáticos Diseño del Software Ingeniería del Software 1 16
17 Protección Modular Un método de construcción satisface Protección Modular, si lleva a que en las arquitecturas en las que ocurre una condición anormal en run time en un módulo queden confinados al mismo, o a lo sumo sólo a pocos vecinos. (B. Meyer) Evitar propagación de Errores Runtime por hardware, mal input, falta de recursos como memoria, etc. Ej.: validar input en la fuente ContraEj.: Excepciones Indisciplinadas Diseño del Software Ingeniería del Software 1 17
18 Mapeo Directo Pocas Interfaces Una estructura modular definida en el proceso de construcción de un sistema software debe mantenerse compatible con toda estructura modular definida en el proceso de modelar el dominio del problema. Modelos (B. Meyer) Cada Módulo debe comunicarse con los menos posibles de otros (B. Meyer) Si hay n módulos en lo posible lo más cerca de n-1 conexiones y no a n(n-1)/2! Continuidad Componibilidad Continuidad Descomponibilidad (aprovechar lo hecho) Diseño del Software Ingeniería del Software 1 18
19 Pequeñas Interfaces Explícitas Si dos módulos se comunican, deberían intercambiar la menor cantidad de información posible. Continuidad Protección (B. Meyer) ContraEj.: Common de Fortran, Programación extremadamente estructurada (muchos parámetros) Cuando dos módulos A y B se comunican, esto debe ser obvio del texto código de ambos. Continuidad Componibilidad (B. Meyer) Descomponibilidad Comprensibilidad Problema con los acoplamientos indirectos como por Shared Memory Diseño del Software Ingeniería del Software 1 19
20 Information Hiding El diseñador de cada módulo debe seleccionar un subconjuto de propiedades del módulo como la información oficial sobre el mismo, para hacerlo disponible a los autores de los módulos clientes. Propiedades Publicas y Privadas (o secretas) Separación de funciones de implementación (TDA y OO) Interfaz --- Iceberg Continuidad Descomponibilidad (B. Meyer) Componibilidad No implica protección Encapsulamiento Comprensibilidad Ej.: procedimiento de acceso a una tabla indexada Diseño del Software Ingeniería del Software 1 20
21 Notación Sea M un conjunto de módulos: M = {m 1,m 2,...,m n } Una relación R sobre M es R M x M Un módulo m i está en relación R con m j ssi <m i,m j > R. Notación: m i Rm j Diseño del Software Ingeniería del Software 1 21
22 Representación en Grafo Grafo dirigido G = <N,A> A N x N a N M A R b e Ej: M = {a,b,c,d,e} R = {<a,b>,<a,e>,<b,c> <e,d>,<d,c>} c d Diseño del Software Ingeniería del Software 1 22
23 Características de la relación No puede ser reflexiva: <m i,m i > R puede ser simétrica y transitiva grafos acíclicos: Ej.: árboles si i <m i,m i > R* (clausura transitiva) directo y acíclico jerarquía muchos caminos entre dos nodos concepto de nivel Diseño del Software Ingeniería del Software 1 23
24 Distintos Niveles System level Sub-system level Diseño del Software Ingeniería del Software 1 24
25 La relación USA Describe las funcionalidades que brinda un módulo y cuales son las funcionalidades que un módulo necesita m i resulta ser un cliente de los servicios que provee m i esta en relación USA con m j (m i USA m j ) si para que el módulo m i sea correcto si necesita la correcta ejecución de m j. m j Diseño del Software Ingeniería del Software 1 25
26 La relación USA se define estáticamente describe el desacoplamiento llamadas a procedimientos no siempre implican USA y viceversa aciclicidad Casos extremos: USA = M x M USA = Indicaciones: minimizar arcos salientes maximizar arcos entrantes análisis por niveles de abstracción Diseño del Software Ingeniería del Software 1 26
27 La relación Es_Componente_De Relación en la dirección de refinamiento sucesivos (topdown) Debe ser una jerarquía (no necesariamente un árbol) Sólo las hojas se implementan efectivamente Los nodos internos son módulos lógicos Diseño del Software Ingeniería del Software 1 27
28 Indicaciones Redefinición de USA respecto a Es_Componenete_De Construcción Incremental Postergar las decisiones INFORMATION HIDING cajas negras definidas por los servicios que brindan Interfaz e Implementación Exportación e Importación principio de división de trabajo Qué esconder? Diseño del Software Ingeniería del Software 1 28
29 Descripciones de Diseño Notaciones Gráficas. Usadas para mostrar relaciones entre los componentes Lenguajes de descripción de Programas. Basados en lenguajes de prog. pero con más flexibilidad para representar conceptos abstractos. Texto informal Descripción en lenguaje natural Todas estas notaciones pueden ser usadas para diseñar sistemas grandes Diseño del Software Ingeniería del Software 1 29
30 Diseño Orientado a Objetos Estrategia de diseño basada en INFORMATION HIDING ABSTRACCION MODULARIDAD Crea una representación del mundo real y lo corresponde con una solución basada en los datos Diseño del Software Ingeniería del Software 1 30
31 Diseño OO El software es visto como un conjunto de objetos que interactúan, con su estado privado, en vez de un conjunto de funciones que comparten un estado global O1 estado 1 O2 estado 2 O3 estado 3 O4 estado 4 El mundo es visto como un conjunto... Diseño del Software Ingeniería del Software 1 31
32 Características Los objetos son abstracciones del mundo real o entidades del sistema que son responsables de manejar su estado privado y ofrecen servicios a otros objetos. Son un modelo de los objetos externos que pueblan el mundo en que actúa el programa. Los objetos son entidades independientes que pueden ser rápidamente cambiados por la información de la representación y el estado queda dentro del objeto. un objeto es caracterizado al exterior sólo por la interfaz que brinda, es decir el conjunto de recursos que pone a disposición. Diseño del Software Ingeniería del Software 1 32
33 Características La funcionalidad del sistema es expresada en términos de operaciones y servicios asociados con cada objeto. Áreas de datos compartidos son eliminados. Los objetos se comunican llamando los servicios ofrecidos en vez de compartir variables. Disminuye el acoplamiento Disminuye el riesgo de modificaciones a datos compartidos Los objetos pueden ser distribuidos y pueden ejecutarse en paralelo o concurrentemente. Estas decisiones no deben tomarse tempranamente. recordar: posponer lo mayor posible toda decisión trascendente de diseño. Diseño del Software Ingeniería del Software 1 33
34 No preguntes qué hace el sistema sino qué le hace a qué cosa OOD es el método que permite definir arquitecturas del software basados en los objetos que todo sistema o subsistema usa OOD es la construcción de sistemas software como una colección estructurada de TAD. Diseño del Software Ingeniería del Software 1 34
35 Criterios Descomponibilidad: facilidad de descomponer un gran problema en subproblemas Componibilidad: facilidad de reuso Comprensibilidad: facilidad de entender un módulo por sí solo Continuidad: pequeños cambios implican pocos cambios Protección: reducir efectos colaterales lo buscado por cualquier método de diseño Diseño del Software Ingeniería del Software 1 35
36 7 conceptos Object based modular structure: los sistemas están modularizados en base a su estructura de datos. Data abstraction: los objetos deberían ser descriptos como implementaciones de TADs. Automatic Memory Management: los objetos no usados deberían ser liberados por el lenguaje subyacente. Clases: cada tipo no primitivo es un módulo y cada módulo de alto nivel es un tipo. Diseño del Software Ingeniería del Software 1 36
37 7 conceptos Una clase puede ser definida como una extensión o una restricción sobre otras. Polimorfismo y Dynamic Binding: se deben permitir referencias a objetos de más de una clase y las operaciones deben poder realizarse en diferentes clases. Múltiple y repetida herencia: debe ser posible declarar una clase como herede de más de una clase o más veces de la misma. Diseño del Software Ingeniería del Software 1 37
38 Clases module exports La clase es el tipo del objeto Clase Persona atributos nombre: string; apellido: string; servicios presentate() implementation Francisca Verdi Mario Rossi Carla Bianchi clase persona: descripción de las características comunes a todos los objetos de tipo persona Diseño del Software Ingeniería del Software 1 38
39 HERENCIA En el mundo real los objetos son clasificados según características comunes Título del diagrama Vertebrados Peces Anfibios Reptiles Pájaros Mamíferos Corvinas Surubíes Carnívoros Herbívoros El mismo principio se puede aplicar a los objetos de un programa. La clasificación se hace definiendo un nuevo tipo como extensión de un tipo preexistente Diseño del Software Ingeniería del Software 1 39
40 La relación HEREDA_DE presentate() presentate() Persona Atributos nombre: string; apellido: string Estudiante Atributos matrícula: int; la clase (el módulo) estudiante extiende la clase (el módulo) persona: AGREGANDO un nuevo atributo (matrícula) REDEFINIENDO un servicio (presentate) Heredadas por por ser ser persona también nombre = Piero apellido = Fraternalli matricula = 585/96 presentate() = Buen día soy Fraternalli, estudiante 585/96 Diseño del Software Ingeniería del Software 1 40
41 HEREDA_DE => ES_UN (IS_A) nombre peso Persona unión existe vacío Conj. de Enteros Hombre Embarazada Mujer Conj. de Enteros Ordenados 1er Elem existe Diseño del Software Ingeniería del Software 1 41
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 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 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 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 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 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 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 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 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 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 detallesCurso 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 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 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 detallesModelado arquitectónico con UML
Modelado arquitectónico con UML Qué es la arquitectura de software El modelo de 4+1 vistas arquitectónicas Cohesión y acoplamiento Cómo lograr una descomposición modular eficaz Criterios para la selección
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 detallesJava 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 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 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 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 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 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 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 detallesIngeniería Software. Análisis orientado a objetos. Ingeniería software 4º de Físicas. José M. Drake y Patricia López Computadores y Tiempo Real
Ingeniería Software Ingeniería software 4º de Físicas 4º Análisis orientado a objetos José M. Drake y Patricia López Computadores y Tiempo Real Santander, 1 Ingeniería de Programación (4º Físicas) J.M.
Más detallesRegistro (record): es la unidad básica de acceso y manipulación de la base de datos.
UNIDAD II 1. Modelos de Bases de Datos. Modelo de Red. Representan las entidades en forma de nodos de un grafo y las asociaciones o interrelaciones entre estas, mediante los arcos que unen a dichos nodos.
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 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 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 detallesGUIA 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 detallesIWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1
IWG-101: Introducción a la Ingeniería Departamento de Informática, UTFSM 1 Introducción a UML Historia Potencialidades Diagramas soportados UML en el proceso de desarrollo de SW. Introducción a UML Necesidad
Más 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 detallesIntroducció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 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 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 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 detallesPatrones para persistencia (I) Ingeniería del Software II
Patrones para persistencia (I) Ingeniería del Software II 1 Patrones para la construcción del esquema relacional En todos los ejemplos realizaremos transformaciones del siguiente diagrama de clases: Figura
Más detallesUNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS
UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS CURSO: JAVA BASICO PROFESOR: EMERSON CASTAÑEDA SANABRIA TEMA: Programación Orientada a Objetos OBJETIVOS: Familiarizarse con la Programació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 detallesPatrones 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 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 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 detallesSOLUCION 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 detalles2. Métricas del Producto
Medición 52 Programa 1. Medición ió y experimentación ió en Ingeniería del Software Introducción Teoría representacional de la medición. Experimentación en Ingeniería del software. 2. Medidas del Producto
Más detallesIngeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado
Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:
Más detallesTEMA 7: DIAGRAMAS EN UML
TEMA 7: DIAGRAMAS EN UML Diagramas en UML El bloque de construcción básico de UML es un Diagrama Introducción a UML 2 1 Modelo de Casos de Uso (MCU) Todos los casos de uso constituyen el MCU que describe
Más detallesBASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS. Dámaso López Aragón
BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS Dámaso López Aragón Introducción En la actualidad, la orientación a objetos es una nueva forma de comprender los problemas y modelar el negocio de una empresa,
Más detallesResumen. El rol del lenguaje SQL en los SGBDR y en la Relacional. cjimenez@inf.udec.cl, tamrstro@inf.udec.cl
El rol del lenguaje SQL en los SGBDR y en la Relacional. cjimenez@inf.udec.cl, tamrstro@inf.udec.cl Resumen demandas de almacenamiento y procesamiento de datos. Es el conjunto de estas dos capacidades
Más detallesMODELADO DEL DOMINIO (MODELO CONCEPTUAL)
MODELADO DEL DOMINIO (MODELO CONCEPTUAL) Es el Artefacto más importante en el Análisis Orientado a Objetos. Explica los conceptos más significativos en un dominio del problema. Previo a esto es fundamental
Más detalles2.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 detallesInicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases
3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología
Más detallesEjercicio 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 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 detallesELEMENTO 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 detallesDiagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases
El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los
Más 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 detallesTópicos a ser desarrollados
Diseño de Software El Diseño no puede ser definido solo puede explicarse en base a los distintos puntos de vista y tareas que realizan los diseñadores del software Basado en la traducción de Sommerville
Más detallesEl Proceso Unificado de Desarrollo de Software
El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:
Más 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 detallesPlataforma desarrollo Java Formación elearning tutorizada en castellano. Fabricante: Java Grupo: Desarrollo Subgrupo: Master Java
C/Comandante Zorita 4 28020 Madrid/ info@ceticsa.es 902 425 524 / 91 700 01 17 Plataforma desarrollo Java Formación elearning tutorizada en castellano JAVA00d Ciclo de formación en plataforma Java Curso
Más detallesYalù Galicia Hernàndez. Yalú Galicia Hdez. (FCC/BUAP)
Yalù Galicia Hernàndez Yalú Galicia Hdez. (FCC/BUAP) 1 Introducción Qué es la Programación Orientada a Objetos? Conceptos básicos Abstracción Jerarquía Encapsulación Objeto Clase Herencia Polimorfismo
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 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 detallesEstructuras de Control - Diagrama de Flujo
RESOLUCIÓN DE PROBLEMAS Y ALGORITMOS Ingeniería en Computación Ingeniería en Informática UNIVERSIDAD NACIONAL DE SAN LUIS DEPARTAMENTO DE INFORMÁTICA AÑO 2015 Índice 1. Programación estructurada 2 1.1.
Más detallesServidores Donantonio
Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3
Más detallesFORMACIÓN Principios de la programación orientada a objetos
FORMACIÓN Principios de la programación orientada a objetos En un mercado laboral en constante evolución, la formación continua de los profesionales debe ser una de sus prioridades. En Galejobs somos conscientes
Más detallesAlmacenamiento virtual de sitios web HOSTS VIRTUALES
Almacenamiento virtual de sitios web HOSTS VIRTUALES El término Hosting Virtual se refiere a hacer funcionar más de un sitio web (tales como www.company1.com y www.company2.com) en una sola máquina. Los
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 detallesSEGURIDAD Y PROTECCION DE FICHEROS
SEGURIDAD Y PROTECCION DE FICHEROS INTEGRIDAD DEL SISTEMA DE ARCHIVOS ATAQUES AL SISTEMA PRINCIPIOS DE DISEÑO DE SISTEMAS SEGUROS IDENTIFICACIÓN DE USUARIOS MECANISMOS DE PROTECCIÓN Y CONTROL INTEGRIDAD
Más detallesPattern Oriented Software Architecture. Whole-Part. Jamir Antonio Avila Mojica César Julio Bustacara Medina. Patrones de Software
Pattern Oriented Software Architecture Whole-Part Jamir Antonio Avila Mojica César Julio Bustacara Medina Patrones de Software Agenda Introducción Whole-Part Ejemplo Contexto Problema Solución Estructura
Más detallesINGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones
INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones Univ. Cantabria Fac. de Ciencias Patricia López Modelo de Casos de Uso vs Modelo de Análisis Modelo de Casos de Uso Modelo de Análisis Descrito con el
Más detalles10 razones para cambiarse a un conmutador IP
10 razones para cambiarse a un conmutador IP Los beneficios de reemplazar su antiguo conmutador por un conmutador IP Nick Galea* Introducción Este artículo explica los 10 principales beneficios de un conmutador
Más detallesMetodologías de diseño de hardware
Capítulo 2 Metodologías de diseño de hardware Las metodologías de diseño de hardware denominadas Top-Down, basadas en la utilización de lenguajes de descripción de hardware, han posibilitado la reducción
Más detallesProgramación orientada a objetos
Repaso Programación orientada a objetos Curso INEM. Programación en Java Santiago Muelas Pascual smuelas@fi.upm.es! Clase! Objeto! Atributo o variable de instancia! Método! Instanciar/crear un objeto!
Más detallesPRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE
VI PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE 6.1 PRUEBAS DEL SOFTWARE Una vez generado el código el software debe ser probado para descubrir el máximo de errores posibles antes de su entrega al cliente.
Más detallesFundamentos del diseño de software
Fundamentos del diseño de software El diseño es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniería. Definición de diseño según Taylor Proceso de aplicar distintas técnicas
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 detallesProgramación Orientada a Objetos con Java
Programación Orientada a Objetos con Java M.C. Jorge Eduardo Ibarra Esquer jorgeeie@uabc.mx Sobrecarga de métodos Java permite la definición de dos o más métodos que tengan el mismo nombre, dentro de la
Más detallesUniversidad de Colima Facultad de Ingeniería Mecánica y Eléctrica. Base de Datos I. Maestra: Martha E. Evangelista Salazar
Universidad de Colima Facultad de Ingeniería Mecánica y Eléctrica Base de Datos I Maestra: Martha E. Evangelista Salazar Introducción a los conceptos de Bases de Datos a).- Definiciones básicas sobre bases
Más detallesTema 1. Conceptos básicos
Conceptos básicos Sistema de Gestión de Bases de Datos, SGBD (DBMS, Database Management System): software diseñado específicamente para el mantenimiento y la explotación de grandes conjuntos de datos 1
Más detallesINSTALACIÓN, OPERACIÓN Y PROGRAMACIÓN DE EQUIPOS Y SISTEMAS TELEFÓNICOS
09-06-2015 1 Descripción y funcionamiento de una central PABX 09-06-2015 2 Un PBX o PABX (siglas en inglés de Private Branch Exchange y Private Automatic Branch Exchange para PABX), la cual es la red telefónica
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 detallesBase de datos relacional
Base de datos relacional Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para modelar problemas reales y administrar
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 detallesCreando Arquitecturas
Creando Arquitecturas orientadas a servicios SOA Suite Abril 2013 Buenos Aires - Argentina Índice 1. Introducción. 2. Nuestro camino para la creación de SOAs. 3. Como justificar el cambio? 4. Nuestras
Más detallesDiseño de algoritmos.
TEMA 5 Diseño de algoritmos. Elementos de Programación I Contenido del Tema T E M A 5 5.1.- Programación Modular y desarrollo de Programas 5.2.- Diseño de interfaces. 5.3.- Notación algorítmica. Elementos
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 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 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 detallesCAPÍTULO 1 Instrumentación Virtual
CAPÍTULO 1 Instrumentación Virtual 1.1 Qué es Instrumentación Virtual? En las últimas décadas se han incrementado de manera considerable las aplicaciones que corren a través de redes debido al surgimiento
Más detallesBASES DE DATOS, MODELOS DE DATOS Y DBMS
BASES DE DATOS, MODELOS DE DATOS Y DBMS Maestría en Bioinformática Marzo 2010 Bases de Datos Algunas definiciones: Bases de Datos y DBMS Procesos y Actores Involucrados Por qué usar DBMSs? Cuándo no usar
Más detallesUna computadora de cualquier forma que se vea tiene dos tipos de componentes: El Hardware y el Software.
ARQUITECTURA DE LAS COMPUTADORAS QUE ES UNA COMPUTADORA (UN ORDENADOR)? Existen numerosas definiciones de una computadora, entre ellas las siguientes: 1) Una computadora es un dispositivo capaz de realizar
Más detalles1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).
1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada
Más detallesComplejidad - Problemas NP-Completos. Algoritmos y Estructuras de Datos III
Complejidad - Problemas NP-Completos Algoritmos y Estructuras de Datos III Teoría de Complejidad Un algoritmo eficiente es un algoritmo de complejidad polinomial. Un problema está bien resuelto si se conocen
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 detallesEstructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos
3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura
Más detallesBASE DE DATOS RELACIONALES
BASE DE DATOS RELACIONALES Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para implementar bases de datos ya
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 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 detallesResolución de problemas en paralelo
Resolución de problemas en paralelo Algoritmos Paralelos Tema 1. Introducción a la computación paralela (segunda parte) Vicente Cerverón Universitat de València Resolución de problemas en paralelo Descomposición
Más detallesEstructuras de datos: Proyecto 2
Estructuras de datos: Proyecto 2 28 de mayo de 2013 Instrucciones Enviar las soluciones por email a los ayudantes, con copia a la profesora. Plazo de entrega: 16 de junio (durante todo el día). Se debe
Más detallesWorkflow, BPM y Java Resumen de la presentación de Tom Baeyens
Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Página 1 de 11 1. Introducción Tom Baeyens es el fundador y arquitecto del proyecto de JBoss jbpm, la máquina de workflow
Más detalles