SlideShare uma empresa Scribd logo
1 de 69
Ingeniería de Software Unidad II Diseño de Sistemas 13 de abr de 2011 Sergio Sánchez Rios Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática
Diseño Conceptual y Técnico ,[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
¿Qué es el diseño? ,[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Diseño Conceptual y Técnico ,[object Object],[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Diseño Conceptual y Técnico ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Diseño Conceptual y Técnico ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Diseño Conceptual y Técnico ,[object Object],[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Diseño Conceptual y Técnico ,[object Object],13 de abr de 2011 Sergio Sánchez Rios CÓMO DISEÑO CONCEPTUAL  función DISEÑO TÉCNICO forma QUÉ Constructores del Sistema Diseñadores del Sistema Clientes
Diseño Conceptual y Técnico ,[object Object],13 de abr de 2011 Sergio Sánchez Rios “ El usuario podrá enviar mensajes a cualquier usuario en cualquier otra computadora en red” DISEÑO TÉCNICO DISEÑO CONCEPTUAL Topología de Red Protocolo  Velocidad (bps) . . .
Descomposición y Modularidad ,[object Object],13 de abr de 2011 Sergio Sánchez Rios Nivel Superior Primer Nivel de  descomposición Segundo Nivel de  descomposición
Descomposición y Modularidad ,[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Niveles de Diseño ,[object Object],[object Object],[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Niveles de Diseño ,[object Object],[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Etapas del proceso de diseño arquitectónico ,[object Object],[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Etapas del proceso de diseño arquitectónico Estructura del sistema ,[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Etapas del proceso de diseño arquitectónico   Estructura del sistema 13 de abr de 2011 Sergio Sánchez Rios Ejemplo abstracto para un diagrama de bloques. Se pueden desarrollar modelos más específicos de la estructura, que muestren cómo los subsistemas comparten datos, cómo están distribuidos y como se conectan entre ellos. Subsistemas Dirección de la relación
Etapas del proceso de diseño arquitectónico   Estructura del sistema – Modelo de Depósito ,[object Object],[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Etapas del proceso de diseño arquitectónico  Estructura del sistema – Modelo de Depósito ,[object Object],13 de abr de 2011 Sergio Sánchez Rios Depósito de  Proyectos  Editor de  Diseño  Generador de Código  Traductor de diseño Analizador de Diseño Generador de informes  Editor de  Programas
Etapas del proceso de diseño arquitectónico   Estructura del sistema – Modelo de Depósito ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Etapas del proceso de diseño arquitectónico   Estructura del sistema – Modelo Cliente - Servidor ,[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios Ofrecen Servicios Llaman a los servicios ofrecidos Permite a los clientes acceder a los servicios Servidor 1 Servicio 1 Servidor 2 Servicio 2 Servidor 3 Servicio 3 RED  Clientes Clientes Clientes Clientes
Etapas del proceso de diseño arquitectónico  Estructura del sistema – Modelo Cliente - Servidor ,[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Etapas del proceso de diseño arquitectónico   Estructura del sistema – Modelo de Capas ,[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios Subsistema 5 Subsistema 1 Subsistema 2 Subsistema 3 Subsistema 4
Etapas del proceso de diseño arquitectónico  Estructura del sistema – Modelo de Capas ,[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Etapas del proceso de diseño arquitectónico   Modelos de Control ,[object Object],[object Object],[object Object],[object Object],[object Object],13 de abr de 2011 Sergio Sánchez Rios
Etapas del proceso de diseño arquitectónico  Modelos de Control – Control Centralizado 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],Aplicable solo a sistemas secuenciales Programa Principal Rutina 1 Rutina 2 Rutina 3 Rutina 1.2 Rutina 1.1 Rutina 3.1 Rutina 3.2
Etapas del proceso de diseño arquitectónico  Modelos de Control – Control Centralizado 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],Controlador del Sistema Proceso 1 Proceso 2 Proceso 3 Proceso 4
Etapas del proceso de diseño arquitectónico  Modelos de Control – Dirigidos por eventos 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object]
Etapas del proceso de diseño arquitectónico   Modelos de Control – Dirigidos por eventos 13 de abr de 2011 Sergio Sánchez Rios La ventaja de este modelo, es su evolución relativamente sencilla. Un nuevo subsistema que maneje clases particulares de eventos, se puede integrar registrando sus eventos en el controlador de eventos. La desventaja es que los subsistemas no saben si los eventos se manejarán, ni cuando lo harán.  Controlador de eventos y mensajes Subsistema 1 Subsistema 2 Subsistema 3
Etapas del proceso de diseño arquitectónico   Modelos de Control – Dirigidos por eventos 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],Controlador 1 Controlador 2 Controlador 3 Controlador 4 Proceso 1 Proceso 2 Proceso 3 Proceso 4 INTERRUPCIONES Vector de interrupciones
Etapas del proceso de diseño arquitectónico   Descomposición modular 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Etapas del proceso de diseño arquitectónico   Descomposición modular – Modelo de Objetos 13 de abr de 2011 Sergio Sánchez Rios El modelo orientado a objetos de una arquitectura de sistema, estructura el sistema en un conjunto de objetos débilmente acoplados con interfaces bien definidas. Los objetos llaman a los servicios ofrecidos por otros objetos. Una descomposición orientada a objetos, comprende clases de objetos, sus atributos y operaciones. Cliente Cliente# Nombre Dirección Periodo de crédito Recibo Factura# Fecha Monto Cliente# Pago Factura# Fecha Monto Cliente# Factura Factura# Fecha Monto cliente Emitir() enviarRecordatorio() aceptarPago() enviarRecibo()
Etapas del proceso de diseño arquitectónico   Descomposición modular – Modelo de Objetos 13 de abr de 2011 Sergio Sánchez Rios Las ventajas de este modelo son bien conocidas, puesto que los objetos están débilmente acoplados, la implementación de objetos se puede modificar sin afectar a otros objetos. Además, los objeto se pueden reutilizar. La desventaja, es que los objetos para utilizar los servicios deben hacer referencia explicita al nombre y la interfaz de otros objetos.
Etapas del proceso de diseño arquitectónico  Descomposición modular – Modelo de Flujo de datos. 13 de abr de 2011 Sergio Sánchez Rios En un modelo de flujo de datos, las transformaciones funcionales procesan sus entradas y producen sus salidas . Los datos fluyen de un lugar a otro y se transforman durante este movimiento.  Leer facturas emitidas Identificar Pagos Emitir  Recibos Hallar pagos retrasados Emitir Recordatorio De pago Facturas Pagos Recordatorios Recibos
Etapas del proceso de diseño arquitectónico   Descomposición modular – Modelo de Flujo de datos. 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Problemas en la creación del diseño Modularidad y nivel de abstracción 13 de abr de 2011 Sergio Sánchez Rios En un diseño modular, los componentes tienen entradas y salidas bien definidas y cada componente tiene un propósito previamente establecido. Los componentes modulares están organizados en una jerarquía, como resultado de la descomposición o abstracción. A medida que nos desplazamos hacia abajo encontramos mayor nivel de detalle para cada componente. El nivel más alto es el más abstracto. Los niveles más abstractos se resuelven primero y la solución se alcanza al desarrollar el detalle.
Problemas en la creación del diseño Modularidad y nivel de abstracción 13 de abr de 2011 Sergio Sánchez Rios La modularidad oculta los detalles. Una ventaja de este  “ocultamiento de información” , es que cada componente oculta de los demás una decisión de diseño.  Por esto es probable que cambien las decisiones de diseño, pero el diseño como un todo puede permanecer intacto, solo cambia el diseño de componentes.
Características de un buen diseño  13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object]
Características de un buen diseño Independencia de los componentes   13 de abr de 2011 Sergio Sánchez Rios En la mayoría de los diseños se trata de que los componentes sean independientes unos de otros. Ya que, un componente independiente es mucho más fácil de modificar. Para reconocer y medir el grado de independencia de los componentes de un diseño se aplican dos conceptos :  acoplamiento  y  cohesión  (Yourdon y Constantine 1978).
Características de un buen diseño Independencia de los componentes - Acoplamiento 13 de abr de 2011 Sergio Sánchez Rios Se dice que dos componentes están “altamente acoplado” cuando existe mucha dependencia entre ellos.  Los componentes “poco acoplado” tienen algunas dependencias, pero las interconexiones entre ellos son débiles. No acoplado Débilmente acoplado (pocas dependencias) Fuertemente acoplado (muchas dependencias)
Características de un buen diseño Independencia de los componentes - Acoplamiento 13 de abr de 2011 Sergio Sánchez Rios Se puede medir el acoplamiento en función de un rango de dependencia, que va de la dependencia completa a la completa independencia. La meta no necesariamente es la completa independencia, sino mantener el menor grado de acoplamiento posible. El bajo acoplamiento contribuye a minimizar el número de componentes que necesitan revisión. Tipos de acoplamiento: Acoplamiento de Contenido Acoplamiento Común Acoplamiento por Control Acoplamiento por estampado Acoplamiento por datos No acoplado ALTO BAJO DÉBIL
Características de un buen diseño Independencia de los componentes - Acoplamiento 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Características de un buen diseño Independencia de los componentes - Acoplamiento 13 de abr de 2011 Sergio Sánchez Rios Acoplamiento Común Los datos son accesibles desde un almacenamiento común de datos.  La dependencia todavía existe, dado que hacer un cambio a los datos comunes significa rastrear en todos los componentes que tienen acceso a estos datos, a fin de evaluar el efecto del cambio.  Global: A1 A2 A3 Variables: V1 V2 Área común de datos y nombres de variables. ------------------- ------------------- Cambiar V1 a cero ----------------------- ---------------------- ------------------- ------------------- Incrementar V1 ----------------------- ---------------------- ------------------- ------------------- V1 = V2 + A1 ----------------------- ---------------------- Componente X Componente Z Componente Y
Características de un buen diseño Independencia de los componentes - Acoplamiento 13 de abr de 2011 Sergio Sánchez Rios Acoplamiento de Control Se produce cuando un componente pasa parámetros para controlar la actividad del otro. Para el componente controlado es imposible funcionar sin la dirección del que lo controla. Acoplamiento por estampado Se produce cuando se usa una estructura de datos para pasar información de un componente a otro, y es la estructura misma la que se pasa.
Características de un buen diseño Independencia de los componentes - Acoplamiento 13 de abr de 2011 Sergio Sánchez Rios Acoplamiento por Datos (deseable) Es el más simple, es solo el paso de datos a otro componente. Lo aceptable para un buen diseño es poseer un acoplamiento débil (lo ideal es bajo).
Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Un componente es cohesivo si todos sus elementos están orientados a la realización de una única tarea y son esenciales para llevarla a cabo. Tipos de cohesión: Funcional Secuencial Procedimental Comunicacional Temporal Lógica Coincidental ALTA BAJO
Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Coincidental Ocurre cuando las partes de un componente no tienen relación alguna entre si.(Cohesión baja) Partes no relacionadas. Función A Función B Función C Función D Función E
Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Lógica Algunas funciones o elementos de datos relacionados lógicamente están puestos en el mismo componente. Ej: Componente que lee todo tipo de entradas (cinta, disco, puertos, etc.) existe una relación lógica, pero no todas las formas son iguales Lógica Funciones Similares Función A Función A’ Función A’’
Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Temporal A veces un componente se utiliza para inicializar un sistema o un conjunto de variables. Este componente realiza varias funciones en secuencia, pero las funciones en si solo se realizan en el momento que ocurren.  Temporal Relacionadas por el tiempo. Tiempo T0 Tiempo T0 + X Tiempo T0 + 2X
Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Procedimental  Es cuando las funciones se agrupan en un mismo componente para asegurar un orden previsto. Por Ejemplo: los datos deben ser ingresados antes de chequearlos o de manipularlos, tres funciones en una secuencia específica. Procedimental Relacionada por el orden de las funciones. Función A Función B Función C
Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Comunicacional  Es cuando en un componente se asocian funciones que acceden a un mismo conjunto de datos. Comunicacional Acceso a algunos datos Función A Función B Función C DATOS
Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Secuencial Se produce cuando la salida por una parte del componente actúa como entrada para la parte que le sigue. Secuencial La salida de una parte es entrada para la siguiente Función A Función B Función C
Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión funcional (deseable) Es la ideal, donde cada elemento de proceso es esencial para la realización de una única función y todos los elementos esenciales están contenidos en un único componente. Funcional Secuencial con funciones completamente relacionadas Función A – parte 1 Función B – parte 2 Función C – parte 3
Características de un buen diseño Identificación y tratamiento de excepciones 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object]
Características de un buen diseño Identificación y tratamiento de excepciones 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Características de un buen diseño Prevención de defectos y tolerancia de defectos 13 de abr de 2011 Sergio Sánchez Rios La meta es hacer un código tan libre de defectos como sea posible incorporando al sistema la prevención y la tolerancia de defectos. Una de las características de un buen diseño es la forma en que previene y tolera los defectos. En lugar de esperar hasta que el sistema falle para corregir el problema, los diseñadores pueden anticipar lo que puede ocurrir y construir el sistema para que reaccione de manera aceptable.
Características de un buen diseño Prevención de defectos y tolerancia de defectos 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object]
Características de un buen diseño Prevención de defectos y tolerancia de defectos 13 de abr de 2011 Sergio Sánchez Rios Corrección de defectos Una vez descubierto el defecto se debe corregir. Por lo general, la corrección del defecto subsana el daño producido, así como  modifica el producto para eliminar tal defecto. Los diseñadores deben incluir una estrategia para los defectos a medida que son encontrados. Se puede optar por detener el sistema cuando lo afecta el defecto de algún modo o  simplemente se registra la existencia de la falla, apuntar el estado del sistema en el momento de producirse la falla y arreglar el daño después. La criticidad del sistema determinara la estrategia a usar.
Características de un buen diseño Prevención de defectos y tolerancia de defectos 13 de abr de 2011 Sergio Sánchez Rios Tolerancia a defectos Muchas veces la corrección de un defecto es demasiado costosa, riesgosa e inconveniente. La tolerancia de fallas en el aislamiento del daño producido por una falla y es conveniente y hasta deseable en muchas circunstancias. Para poder aplicar tolerancia debe existir una anticipación de los defectos, lo que es difícil sobre todo en sistemas complejos.
Revisiones del diseño 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object]
Revisiones del diseño Revisión del diseño preliminar 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Revisiones del diseño Revisión del diseño preliminar 13 de abr de 2011 Sergio Sánchez Rios Se recomienda que el número de integrantes sea pequeño de modo que facilite las discusiones. Durante la revisión se presenta a la audiencia el diseño conceptual. Al hacerlo, se demuestra que el sistema tiene la estructura requerida, las funciones y las características especificadas por los documentos de análisis. Todos los participantes, en conjunto, verifican que el diseño propuesto incluya el hardware necesario, interfaces con otros sistemas, entradas y salidas. Los clientes aprueban los diálogos y menús, los formatos de los informes y el tratamiento de defectos propuestos.
Revisiones del diseño Revisión crítica del diseño 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Revisiones del diseño Revisión crítica del diseño 13 de abr de 2011 Sergio Sánchez Rios Este grupo es más técnico que el anterior. Ya que la revisión trata de aspectos técnicos. El moderador conduce la reunión para que se traten dos puntos: si el diseño implementa todos los requerimientos y si es un diseño de calidad. Usando diagramas, datos o ambas cosas, se explican las estrategias de diseño alternativa y como y porque se han tomado las principales decisiones de diseño. Si se identifican problemas mayores el diseño se rehace.
Revisiones del diseño Revisión del diseño de programas 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]
Revisiones del diseño Revisión del diseño de programas 13 de abr de 2011 Sergio Sánchez Rios Este proceso se centra en la detección de defectos más que en su corrección. Además se esta evaluando el diseño no a los diseñadores. El proceso beneficia a todos al encontrar defectos y problemas cuando aún son fáciles y poco costosos de corregir.
Documentando el diseño 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object]
Documentando el diseño 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Por lo general, un conjunto de diagramas o de notaciones formales describe la organización y estructura global del sistema, incluyendo todos los niveles de abstracción.
Documentando el diseño 13 de abr de 2011 Sergio Sánchez Rios 3.  Finalmente se realiza un referencia cruzada del diseño y los requerimientos.
Bibliografía 13 de abr de 2011 Sergio Sánchez Rios ,[object Object],[object Object],[object Object],[object Object],[object Object]

Mais conteúdo relacionado

Mais procurados

2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicoslandeta_p
 
Unidad 2 concepto de Programa,Proceso y Procesador
Unidad 2  concepto de Programa,Proceso y ProcesadorUnidad 2  concepto de Programa,Proceso y Procesador
Unidad 2 concepto de Programa,Proceso y ProcesadorMario Alberto Antonio Lopez
 
Ejemplos de proyectos al modelo en cascada
Ejemplos de proyectos  al modelo en cascadaEjemplos de proyectos  al modelo en cascada
Ejemplos de proyectos al modelo en cascadaaics-1986-13-saraguro
 
Modelo requisitos UML
Modelo requisitos UMLModelo requisitos UML
Modelo requisitos UMLramirezjaime
 
Modelo relacional y reglas de integridad
Modelo relacional y reglas de integridadModelo relacional y reglas de integridad
Modelo relacional y reglas de integridadkamui002
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de softwareYaskelly Yedra
 
Etapas del Proceso de la Ingeniería del Software
Etapas del Proceso de la Ingeniería del SoftwareEtapas del Proceso de la Ingeniería del Software
Etapas del Proceso de la Ingeniería del SoftwareT.I.C
 
Diccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de informaciónDiccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de informaciónYaskelly Yedra
 
Enfoque estructurado enfoque oo
Enfoque estructurado   enfoque ooEnfoque estructurado   enfoque oo
Enfoque estructurado enfoque ookarlanm07
 
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)Micael Gallego
 
Diagrama de actividades
Diagrama de actividadesDiagrama de actividades
Diagrama de actividadesGracielaPinedo
 
Introduccion a la administracion de los procesos y el procesador (S.O)
Introduccion a la administracion de los procesos y el procesador (S.O)Introduccion a la administracion de los procesos y el procesador (S.O)
Introduccion a la administracion de los procesos y el procesador (S.O)Javier Alvarez
 
Modelos de arquitecturas de computadoras
Modelos de arquitecturas de computadorasModelos de arquitecturas de computadoras
Modelos de arquitecturas de computadorasYESENIA CETINA
 
Unidad 1.2 A IntroduccióN A Los Proceso De Software Modelos Tradicionales
Unidad 1.2 A IntroduccióN A Los Proceso De Software   Modelos TradicionalesUnidad 1.2 A IntroduccióN A Los Proceso De Software   Modelos Tradicionales
Unidad 1.2 A IntroduccióN A Los Proceso De Software Modelos TradicionalesSergio Sanchez
 

Mais procurados (20)

2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
 
Unidad 2 concepto de Programa,Proceso y Procesador
Unidad 2  concepto de Programa,Proceso y ProcesadorUnidad 2  concepto de Programa,Proceso y Procesador
Unidad 2 concepto de Programa,Proceso y Procesador
 
Ejemplos de proyectos al modelo en cascada
Ejemplos de proyectos  al modelo en cascadaEjemplos de proyectos  al modelo en cascada
Ejemplos de proyectos al modelo en cascada
 
Modelo requisitos UML
Modelo requisitos UMLModelo requisitos UML
Modelo requisitos UML
 
Modelo relacional y reglas de integridad
Modelo relacional y reglas de integridadModelo relacional y reglas de integridad
Modelo relacional y reglas de integridad
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de software
 
Etapas del Proceso de la Ingeniería del Software
Etapas del Proceso de la Ingeniería del SoftwareEtapas del Proceso de la Ingeniería del Software
Etapas del Proceso de la Ingeniería del Software
 
Diccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de informaciónDiccionario de datos en los sistemas de información
Diccionario de datos en los sistemas de información
 
Enfoque estructurado enfoque oo
Enfoque estructurado   enfoque ooEnfoque estructurado   enfoque oo
Enfoque estructurado enfoque oo
 
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
 
control de concurrencia
control de concurrenciacontrol de concurrencia
control de concurrencia
 
Diagrama de actividades
Diagrama de actividadesDiagrama de actividades
Diagrama de actividades
 
Introduccion a la administracion de los procesos y el procesador (S.O)
Introduccion a la administracion de los procesos y el procesador (S.O)Introduccion a la administracion de los procesos y el procesador (S.O)
Introduccion a la administracion de los procesos y el procesador (S.O)
 
Modelos de arquitecturas de computadoras
Modelos de arquitecturas de computadorasModelos de arquitecturas de computadoras
Modelos de arquitecturas de computadoras
 
Proyecto final de software
Proyecto final de softwareProyecto final de software
Proyecto final de software
 
Rational rose
Rational roseRational rose
Rational rose
 
Unidad 1.2 A IntroduccióN A Los Proceso De Software Modelos Tradicionales
Unidad 1.2 A IntroduccióN A Los Proceso De Software   Modelos TradicionalesUnidad 1.2 A IntroduccióN A Los Proceso De Software   Modelos Tradicionales
Unidad 1.2 A IntroduccióN A Los Proceso De Software Modelos Tradicionales
 
UML - Analisis de Sistemas
UML - Analisis de SistemasUML - Analisis de Sistemas
UML - Analisis de Sistemas
 
Conceptos de diseño
Conceptos de diseñoConceptos de diseño
Conceptos de diseño
 
Tesis Control de Inventarios
Tesis Control de InventariosTesis Control de Inventarios
Tesis Control de Inventarios
 

Destaque

Diseño de Sistemas
Diseño de SistemasDiseño de Sistemas
Diseño de SistemasJUANESTEFA
 
Unidad 2 ing de software
Unidad 2 ing de softwareUnidad 2 ing de software
Unidad 2 ing de softwareArmando Barrera
 
DiseñO Del Software E IngenieríA Del Software
DiseñO Del Software E IngenieríA Del SoftwareDiseñO Del Software E IngenieríA Del Software
DiseñO Del Software E IngenieríA Del Softwarelcastillo110
 
Diseño de sistemas
Diseño de sistemasDiseño de sistemas
Diseño de sistemasMARTHALU11
 
Análisis de sistemas fases del diseño de sistemas
Análisis de sistemas fases del diseño de sistemasAnálisis de sistemas fases del diseño de sistemas
Análisis de sistemas fases del diseño de sistemasprofmyriamsanuy
 
Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwaresergio
 
DISEÑO DE LA ARQUITECTURA DEL SOFTWARE
DISEÑO DE LA ARQUITECTURA DEL SOFTWAREDISEÑO DE LA ARQUITECTURA DEL SOFTWARE
DISEÑO DE LA ARQUITECTURA DEL SOFTWAREjose_rob
 
Unidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De ProgramasUnidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De ProgramasSergio Sanchez
 
Unidad 6 Lenguaje Sql 2
Unidad 6 Lenguaje Sql 2Unidad 6 Lenguaje Sql 2
Unidad 6 Lenguaje Sql 2Sergio Sanchez
 
Unidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De SoftwareUnidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De SoftwareSergio Sanchez
 
Unidad 4 Modelo De Datos Para La ImplementacióN
Unidad 4 Modelo De Datos Para La ImplementacióNUnidad 4 Modelo De Datos Para La ImplementacióN
Unidad 4 Modelo De Datos Para La ImplementacióNSergio Sanchez
 
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)Sergio Sanchez
 
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El ProgramaUnidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El ProgramaSergio Sanchez
 
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)Sergio Sanchez
 
Unidad 5 TransformacióN Er A Relacional NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióNUnidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional NormalizacióNSergio Sanchez
 

Destaque (20)

Diseño de Sistemas
Diseño de SistemasDiseño de Sistemas
Diseño de Sistemas
 
Unidad 2 ing de software
Unidad 2 ing de softwareUnidad 2 ing de software
Unidad 2 ing de software
 
Diseño de sistemas
Diseño de sistemasDiseño de sistemas
Diseño de sistemas
 
DiseñO Del Software E IngenieríA Del Software
DiseñO Del Software E IngenieríA Del SoftwareDiseñO Del Software E IngenieríA Del Software
DiseñO Del Software E IngenieríA Del Software
 
Diseño de sistemas
Diseño de sistemasDiseño de sistemas
Diseño de sistemas
 
Unidad 6 Lenguaje Sql
Unidad 6 Lenguaje SqlUnidad 6 Lenguaje Sql
Unidad 6 Lenguaje Sql
 
Análisis de sistemas fases del diseño de sistemas
Análisis de sistemas fases del diseño de sistemasAnálisis de sistemas fases del diseño de sistemas
Análisis de sistemas fases del diseño de sistemas
 
Diseño arquitectónico
Diseño arquitectónicoDiseño arquitectónico
Diseño arquitectónico
 
Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de software
 
DISEÑO DE LA ARQUITECTURA DEL SOFTWARE
DISEÑO DE LA ARQUITECTURA DEL SOFTWAREDISEÑO DE LA ARQUITECTURA DEL SOFTWARE
DISEÑO DE LA ARQUITECTURA DEL SOFTWARE
 
Sistemas de información
Sistemas de informaciónSistemas de información
Sistemas de información
 
Unidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De ProgramasUnidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De Programas
 
Unidad 6 Lenguaje Sql 2
Unidad 6 Lenguaje Sql 2Unidad 6 Lenguaje Sql 2
Unidad 6 Lenguaje Sql 2
 
Unidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De SoftwareUnidad 1.1 Que Es La Ing. De Software
Unidad 1.1 Que Es La Ing. De Software
 
Unidad 4 Modelo De Datos Para La ImplementacióN
Unidad 4 Modelo De Datos Para La ImplementacióNUnidad 4 Modelo De Datos Para La ImplementacióN
Unidad 4 Modelo De Datos Para La ImplementacióN
 
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)
Unidad 6 Lenguaje Sql 3 (Restricciones Ddl Avanzado)
 
Unidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El ProgramaUnidad 2.2 Escribiendo El Programa
Unidad 2.2 Escribiendo El Programa
 
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)
Unidad 6 Lenguaje Sql 4 (Consultas Dml Avanzado)
 
Unidad 5 TransformacióN Er A Relacional NormalizacióN
Unidad 5 TransformacióN Er A Relacional   NormalizacióNUnidad 5 TransformacióN Er A Relacional   NormalizacióN
Unidad 5 TransformacióN Er A Relacional NormalizacióN
 
Diagrama de entidad relacion
Diagrama de entidad relacionDiagrama de entidad relacion
Diagrama de entidad relacion
 

Semelhante a Unidad 2.1 DiseñO De Sistemas

Exposición Unidad I - Ingeniería en Software II.pptx
Exposición Unidad I - Ingeniería en Software II.pptxExposición Unidad I - Ingeniería en Software II.pptx
Exposición Unidad I - Ingeniería en Software II.pptxjuan351241
 
210452 arquitectura-de-software-adrian-lasso
210452 arquitectura-de-software-adrian-lasso210452 arquitectura-de-software-adrian-lasso
210452 arquitectura-de-software-adrian-lassoEpmaps q
 
Glosario de terminos
Glosario de terminosGlosario de terminos
Glosario de terminosJose Risso
 
diseño lógico y diseño físico
diseño lógico y diseño físicodiseño lógico y diseño físico
diseño lógico y diseño físicoerrroman
 
Arquitectura de software.docx
Arquitectura de software.docxArquitectura de software.docx
Arquitectura de software.docxKeiberOrtiz1
 
Fundamentos, Garantías y Técnicas en el diseño de software
Fundamentos, Garantías y Técnicas en el diseño de softwareFundamentos, Garantías y Técnicas en el diseño de software
Fundamentos, Garantías y Técnicas en el diseño de softwareGerardo Valera
 
Clase De Fds22
Clase De Fds22Clase De Fds22
Clase De Fds22masa832
 
Presentación Diseño de Software Gabriel Augusto Peña Antonetti CI 27687011
Presentación Diseño de Software Gabriel Augusto Peña Antonetti CI 27687011Presentación Diseño de Software Gabriel Augusto Peña Antonetti CI 27687011
Presentación Diseño de Software Gabriel Augusto Peña Antonetti CI 27687011gabrielpea60
 
diseño de arquitectura de un sistema de informacion
diseño de arquitectura de un sistema de informaciondiseño de arquitectura de un sistema de informacion
diseño de arquitectura de un sistema de informacionzulaymaylin
 
Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteCAMILO
 
Fundamentos del diseño de software
Fundamentos del diseño de software Fundamentos del diseño de software
Fundamentos del diseño de software AlessandreMndez
 
Ingenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de softwareIngenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de softwareJosé Antonio Sandoval Acosta
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de softwareLiliana Pacheco
 
Desarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a ObjetosDesarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a ObjetosDat@center S.A
 

Semelhante a Unidad 2.1 DiseñO De Sistemas (20)

1127082.ppt
1127082.ppt1127082.ppt
1127082.ppt
 
9.diseño de la arquitectura
9.diseño de la arquitectura9.diseño de la arquitectura
9.diseño de la arquitectura
 
Unidad 4. diseno del sistema
Unidad 4. diseno del sistemaUnidad 4. diseno del sistema
Unidad 4. diseno del sistema
 
Exposición Unidad I - Ingeniería en Software II.pptx
Exposición Unidad I - Ingeniería en Software II.pptxExposición Unidad I - Ingeniería en Software II.pptx
Exposición Unidad I - Ingeniería en Software II.pptx
 
210452 arquitectura-de-software-adrian-lasso
210452 arquitectura-de-software-adrian-lasso210452 arquitectura-de-software-adrian-lasso
210452 arquitectura-de-software-adrian-lasso
 
Glosario de terminos
Glosario de terminosGlosario de terminos
Glosario de terminos
 
Diseño arquitectónico
Diseño arquitectónicoDiseño arquitectónico
Diseño arquitectónico
 
diseño lógico y diseño físico
diseño lógico y diseño físicodiseño lógico y diseño físico
diseño lógico y diseño físico
 
Arquitectura de software.docx
Arquitectura de software.docxArquitectura de software.docx
Arquitectura de software.docx
 
Presentacion
PresentacionPresentacion
Presentacion
 
Fundamentos, Garantías y Técnicas en el diseño de software
Fundamentos, Garantías y Técnicas en el diseño de softwareFundamentos, Garantías y Técnicas en el diseño de software
Fundamentos, Garantías y Técnicas en el diseño de software
 
Clase De Fds22
Clase De Fds22Clase De Fds22
Clase De Fds22
 
Presentación Diseño de Software Gabriel Augusto Peña Antonetti CI 27687011
Presentación Diseño de Software Gabriel Augusto Peña Antonetti CI 27687011Presentación Diseño de Software Gabriel Augusto Peña Antonetti CI 27687011
Presentación Diseño de Software Gabriel Augusto Peña Antonetti CI 27687011
 
Diseño
DiseñoDiseño
Diseño
 
diseño de arquitectura de un sistema de informacion
diseño de arquitectura de un sistema de informaciondiseño de arquitectura de un sistema de informacion
diseño de arquitectura de un sistema de informacion
 
Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de Coste
 
Fundamentos del diseño de software
Fundamentos del diseño de software Fundamentos del diseño de software
Fundamentos del diseño de software
 
Ingenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de softwareIngenieria de software - Unidad 3 arquitecturas de software
Ingenieria de software - Unidad 3 arquitecturas de software
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de software
 
Desarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a ObjetosDesarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a Objetos
 

Mais de Sergio Sanchez

Unidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos ConceptualUnidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos ConceptualSergio Sanchez
 
Unidad 2 Modelo De Datos
Unidad 2 Modelo De DatosUnidad 2 Modelo De Datos
Unidad 2 Modelo De DatosSergio Sanchez
 
Unidad 1 IntroduccióN A Las Bases De Datos
Unidad 1 IntroduccióN A Las Bases De DatosUnidad 1 IntroduccióN A Las Bases De Datos
Unidad 1 IntroduccióN A Las Bases De DatosSergio Sanchez
 
Unidad 3.1 Prueba De Sistemas
Unidad 3.1 Prueba De SistemasUnidad 3.1 Prueba De Sistemas
Unidad 3.1 Prueba De SistemasSergio Sanchez
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosSergio Sanchez
 
Unidad 1.2 B Metodos Agiles 1
Unidad 1.2 B Metodos Agiles  1Unidad 1.2 B Metodos Agiles  1
Unidad 1.2 B Metodos Agiles 1Sergio Sanchez
 
Unidad 10 Mad Diagrama De Clases
Unidad 10 Mad Diagrama De ClasesUnidad 10 Mad Diagrama De Clases
Unidad 10 Mad Diagrama De ClasesSergio Sanchez
 
Unidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñOUnidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñOSergio Sanchez
 
Unidad 8 Diagramas De InteraccióN
Unidad 8 Diagramas De InteraccióNUnidad 8 Diagramas De InteraccióN
Unidad 8 Diagramas De InteraccióNSergio Sanchez
 
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso RealesUnidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso RealesSergio Sanchez
 
Unidad 6 Mad Modelado Analsis Diagrama De Secuencia Del Sistema
Unidad 6 Mad Modelado Analsis    Diagrama De Secuencia Del SistemaUnidad 6 Mad Modelado Analsis    Diagrama De Secuencia Del Sistema
Unidad 6 Mad Modelado Analsis Diagrama De Secuencia Del SistemaSergio Sanchez
 
Unidad 5 Mad Modelado Analisis Modelo Conceptual
Unidad 5 Mad Modelado Analisis   Modelo ConceptualUnidad 5 Mad Modelado Analisis   Modelo Conceptual
Unidad 5 Mad Modelado Analisis Modelo ConceptualSergio Sanchez
 
Unidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoUnidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoSergio Sanchez
 
Unidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioUnidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioSergio Sanchez
 
Unidad 2 ProgramacióN Orientada A Objetos (Repaso)
Unidad 2 ProgramacióN Orientada A Objetos (Repaso)Unidad 2 ProgramacióN Orientada A Objetos (Repaso)
Unidad 2 ProgramacióN Orientada A Objetos (Repaso)Sergio Sanchez
 
Unidad 1 Mad IntroduccióN
Unidad 1 Mad IntroduccióNUnidad 1 Mad IntroduccióN
Unidad 1 Mad IntroduccióNSergio Sanchez
 
Melado de Proceso de Negocios con UML
Melado de Proceso de Negocios con UMLMelado de Proceso de Negocios con UML
Melado de Proceso de Negocios con UMLSergio Sanchez
 

Mais de Sergio Sanchez (17)

Unidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos ConceptualUnidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos Conceptual
 
Unidad 2 Modelo De Datos
Unidad 2 Modelo De DatosUnidad 2 Modelo De Datos
Unidad 2 Modelo De Datos
 
Unidad 1 IntroduccióN A Las Bases De Datos
Unidad 1 IntroduccióN A Las Bases De DatosUnidad 1 IntroduccióN A Las Bases De Datos
Unidad 1 IntroduccióN A Las Bases De Datos
 
Unidad 3.1 Prueba De Sistemas
Unidad 3.1 Prueba De SistemasUnidad 3.1 Prueba De Sistemas
Unidad 3.1 Prueba De Sistemas
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De Requerimientos
 
Unidad 1.2 B Metodos Agiles 1
Unidad 1.2 B Metodos Agiles  1Unidad 1.2 B Metodos Agiles  1
Unidad 1.2 B Metodos Agiles 1
 
Unidad 10 Mad Diagrama De Clases
Unidad 10 Mad Diagrama De ClasesUnidad 10 Mad Diagrama De Clases
Unidad 10 Mad Diagrama De Clases
 
Unidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñOUnidad 9 Patrones De DiseñO
Unidad 9 Patrones De DiseñO
 
Unidad 8 Diagramas De InteraccióN
Unidad 8 Diagramas De InteraccióNUnidad 8 Diagramas De InteraccióN
Unidad 8 Diagramas De InteraccióN
 
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso RealesUnidad 7 Mad Modelado DiseñO    Contratos Y Casos De Uso Reales
Unidad 7 Mad Modelado DiseñO Contratos Y Casos De Uso Reales
 
Unidad 6 Mad Modelado Analsis Diagrama De Secuencia Del Sistema
Unidad 6 Mad Modelado Analsis    Diagrama De Secuencia Del SistemaUnidad 6 Mad Modelado Analsis    Diagrama De Secuencia Del Sistema
Unidad 6 Mad Modelado Analsis Diagrama De Secuencia Del Sistema
 
Unidad 5 Mad Modelado Analisis Modelo Conceptual
Unidad 5 Mad Modelado Analisis   Modelo ConceptualUnidad 5 Mad Modelado Analisis   Modelo Conceptual
Unidad 5 Mad Modelado Analisis Modelo Conceptual
 
Unidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoUnidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De Uso
 
Unidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioUnidad 3 Modelo De Negocio
Unidad 3 Modelo De Negocio
 
Unidad 2 ProgramacióN Orientada A Objetos (Repaso)
Unidad 2 ProgramacióN Orientada A Objetos (Repaso)Unidad 2 ProgramacióN Orientada A Objetos (Repaso)
Unidad 2 ProgramacióN Orientada A Objetos (Repaso)
 
Unidad 1 Mad IntroduccióN
Unidad 1 Mad IntroduccióNUnidad 1 Mad IntroduccióN
Unidad 1 Mad IntroduccióN
 
Melado de Proceso de Negocios con UML
Melado de Proceso de Negocios con UMLMelado de Proceso de Negocios con UML
Melado de Proceso de Negocios con UML
 

Unidad 2.1 DiseñO De Sistemas

  • 1. Ingeniería de Software Unidad II Diseño de Sistemas 13 de abr de 2011 Sergio Sánchez Rios Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16. Etapas del proceso de diseño arquitectónico Estructura del sistema 13 de abr de 2011 Sergio Sánchez Rios Ejemplo abstracto para un diagrama de bloques. Se pueden desarrollar modelos más específicos de la estructura, que muestren cómo los subsistemas comparten datos, cómo están distribuidos y como se conectan entre ellos. Subsistemas Dirección de la relación
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28. Etapas del proceso de diseño arquitectónico Modelos de Control – Dirigidos por eventos 13 de abr de 2011 Sergio Sánchez Rios La ventaja de este modelo, es su evolución relativamente sencilla. Un nuevo subsistema que maneje clases particulares de eventos, se puede integrar registrando sus eventos en el controlador de eventos. La desventaja es que los subsistemas no saben si los eventos se manejarán, ni cuando lo harán. Controlador de eventos y mensajes Subsistema 1 Subsistema 2 Subsistema 3
  • 29.
  • 30.
  • 31. Etapas del proceso de diseño arquitectónico Descomposición modular – Modelo de Objetos 13 de abr de 2011 Sergio Sánchez Rios El modelo orientado a objetos de una arquitectura de sistema, estructura el sistema en un conjunto de objetos débilmente acoplados con interfaces bien definidas. Los objetos llaman a los servicios ofrecidos por otros objetos. Una descomposición orientada a objetos, comprende clases de objetos, sus atributos y operaciones. Cliente Cliente# Nombre Dirección Periodo de crédito Recibo Factura# Fecha Monto Cliente# Pago Factura# Fecha Monto Cliente# Factura Factura# Fecha Monto cliente Emitir() enviarRecordatorio() aceptarPago() enviarRecibo()
  • 32. Etapas del proceso de diseño arquitectónico Descomposición modular – Modelo de Objetos 13 de abr de 2011 Sergio Sánchez Rios Las ventajas de este modelo son bien conocidas, puesto que los objetos están débilmente acoplados, la implementación de objetos se puede modificar sin afectar a otros objetos. Además, los objeto se pueden reutilizar. La desventaja, es que los objetos para utilizar los servicios deben hacer referencia explicita al nombre y la interfaz de otros objetos.
  • 33. Etapas del proceso de diseño arquitectónico Descomposición modular – Modelo de Flujo de datos. 13 de abr de 2011 Sergio Sánchez Rios En un modelo de flujo de datos, las transformaciones funcionales procesan sus entradas y producen sus salidas . Los datos fluyen de un lugar a otro y se transforman durante este movimiento. Leer facturas emitidas Identificar Pagos Emitir Recibos Hallar pagos retrasados Emitir Recordatorio De pago Facturas Pagos Recordatorios Recibos
  • 34.
  • 35. Problemas en la creación del diseño Modularidad y nivel de abstracción 13 de abr de 2011 Sergio Sánchez Rios En un diseño modular, los componentes tienen entradas y salidas bien definidas y cada componente tiene un propósito previamente establecido. Los componentes modulares están organizados en una jerarquía, como resultado de la descomposición o abstracción. A medida que nos desplazamos hacia abajo encontramos mayor nivel de detalle para cada componente. El nivel más alto es el más abstracto. Los niveles más abstractos se resuelven primero y la solución se alcanza al desarrollar el detalle.
  • 36. Problemas en la creación del diseño Modularidad y nivel de abstracción 13 de abr de 2011 Sergio Sánchez Rios La modularidad oculta los detalles. Una ventaja de este “ocultamiento de información” , es que cada componente oculta de los demás una decisión de diseño. Por esto es probable que cambien las decisiones de diseño, pero el diseño como un todo puede permanecer intacto, solo cambia el diseño de componentes.
  • 37.
  • 38. Características de un buen diseño Independencia de los componentes 13 de abr de 2011 Sergio Sánchez Rios En la mayoría de los diseños se trata de que los componentes sean independientes unos de otros. Ya que, un componente independiente es mucho más fácil de modificar. Para reconocer y medir el grado de independencia de los componentes de un diseño se aplican dos conceptos : acoplamiento y cohesión (Yourdon y Constantine 1978).
  • 39. Características de un buen diseño Independencia de los componentes - Acoplamiento 13 de abr de 2011 Sergio Sánchez Rios Se dice que dos componentes están “altamente acoplado” cuando existe mucha dependencia entre ellos. Los componentes “poco acoplado” tienen algunas dependencias, pero las interconexiones entre ellos son débiles. No acoplado Débilmente acoplado (pocas dependencias) Fuertemente acoplado (muchas dependencias)
  • 40. Características de un buen diseño Independencia de los componentes - Acoplamiento 13 de abr de 2011 Sergio Sánchez Rios Se puede medir el acoplamiento en función de un rango de dependencia, que va de la dependencia completa a la completa independencia. La meta no necesariamente es la completa independencia, sino mantener el menor grado de acoplamiento posible. El bajo acoplamiento contribuye a minimizar el número de componentes que necesitan revisión. Tipos de acoplamiento: Acoplamiento de Contenido Acoplamiento Común Acoplamiento por Control Acoplamiento por estampado Acoplamiento por datos No acoplado ALTO BAJO DÉBIL
  • 41.
  • 42. Características de un buen diseño Independencia de los componentes - Acoplamiento 13 de abr de 2011 Sergio Sánchez Rios Acoplamiento Común Los datos son accesibles desde un almacenamiento común de datos. La dependencia todavía existe, dado que hacer un cambio a los datos comunes significa rastrear en todos los componentes que tienen acceso a estos datos, a fin de evaluar el efecto del cambio. Global: A1 A2 A3 Variables: V1 V2 Área común de datos y nombres de variables. ------------------- ------------------- Cambiar V1 a cero ----------------------- ---------------------- ------------------- ------------------- Incrementar V1 ----------------------- ---------------------- ------------------- ------------------- V1 = V2 + A1 ----------------------- ---------------------- Componente X Componente Z Componente Y
  • 43. Características de un buen diseño Independencia de los componentes - Acoplamiento 13 de abr de 2011 Sergio Sánchez Rios Acoplamiento de Control Se produce cuando un componente pasa parámetros para controlar la actividad del otro. Para el componente controlado es imposible funcionar sin la dirección del que lo controla. Acoplamiento por estampado Se produce cuando se usa una estructura de datos para pasar información de un componente a otro, y es la estructura misma la que se pasa.
  • 44. Características de un buen diseño Independencia de los componentes - Acoplamiento 13 de abr de 2011 Sergio Sánchez Rios Acoplamiento por Datos (deseable) Es el más simple, es solo el paso de datos a otro componente. Lo aceptable para un buen diseño es poseer un acoplamiento débil (lo ideal es bajo).
  • 45. Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Un componente es cohesivo si todos sus elementos están orientados a la realización de una única tarea y son esenciales para llevarla a cabo. Tipos de cohesión: Funcional Secuencial Procedimental Comunicacional Temporal Lógica Coincidental ALTA BAJO
  • 46. Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Coincidental Ocurre cuando las partes de un componente no tienen relación alguna entre si.(Cohesión baja) Partes no relacionadas. Función A Función B Función C Función D Función E
  • 47. Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Lógica Algunas funciones o elementos de datos relacionados lógicamente están puestos en el mismo componente. Ej: Componente que lee todo tipo de entradas (cinta, disco, puertos, etc.) existe una relación lógica, pero no todas las formas son iguales Lógica Funciones Similares Función A Función A’ Función A’’
  • 48. Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Temporal A veces un componente se utiliza para inicializar un sistema o un conjunto de variables. Este componente realiza varias funciones en secuencia, pero las funciones en si solo se realizan en el momento que ocurren. Temporal Relacionadas por el tiempo. Tiempo T0 Tiempo T0 + X Tiempo T0 + 2X
  • 49. Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Procedimental Es cuando las funciones se agrupan en un mismo componente para asegurar un orden previsto. Por Ejemplo: los datos deben ser ingresados antes de chequearlos o de manipularlos, tres funciones en una secuencia específica. Procedimental Relacionada por el orden de las funciones. Función A Función B Función C
  • 50. Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Comunicacional Es cuando en un componente se asocian funciones que acceden a un mismo conjunto de datos. Comunicacional Acceso a algunos datos Función A Función B Función C DATOS
  • 51. Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión Secuencial Se produce cuando la salida por una parte del componente actúa como entrada para la parte que le sigue. Secuencial La salida de una parte es entrada para la siguiente Función A Función B Función C
  • 52. Características de un buen diseño Independencia de los componentes - Cohesión 13 de abr de 2011 Sergio Sánchez Rios Cohesión funcional (deseable) Es la ideal, donde cada elemento de proceso es esencial para la realización de una única función y todos los elementos esenciales están contenidos en un único componente. Funcional Secuencial con funciones completamente relacionadas Función A – parte 1 Función B – parte 2 Función C – parte 3
  • 53.
  • 54.
  • 55. Características de un buen diseño Prevención de defectos y tolerancia de defectos 13 de abr de 2011 Sergio Sánchez Rios La meta es hacer un código tan libre de defectos como sea posible incorporando al sistema la prevención y la tolerancia de defectos. Una de las características de un buen diseño es la forma en que previene y tolera los defectos. En lugar de esperar hasta que el sistema falle para corregir el problema, los diseñadores pueden anticipar lo que puede ocurrir y construir el sistema para que reaccione de manera aceptable.
  • 56.
  • 57. Características de un buen diseño Prevención de defectos y tolerancia de defectos 13 de abr de 2011 Sergio Sánchez Rios Corrección de defectos Una vez descubierto el defecto se debe corregir. Por lo general, la corrección del defecto subsana el daño producido, así como modifica el producto para eliminar tal defecto. Los diseñadores deben incluir una estrategia para los defectos a medida que son encontrados. Se puede optar por detener el sistema cuando lo afecta el defecto de algún modo o simplemente se registra la existencia de la falla, apuntar el estado del sistema en el momento de producirse la falla y arreglar el daño después. La criticidad del sistema determinara la estrategia a usar.
  • 58. Características de un buen diseño Prevención de defectos y tolerancia de defectos 13 de abr de 2011 Sergio Sánchez Rios Tolerancia a defectos Muchas veces la corrección de un defecto es demasiado costosa, riesgosa e inconveniente. La tolerancia de fallas en el aislamiento del daño producido por una falla y es conveniente y hasta deseable en muchas circunstancias. Para poder aplicar tolerancia debe existir una anticipación de los defectos, lo que es difícil sobre todo en sistemas complejos.
  • 59.
  • 60.
  • 61. Revisiones del diseño Revisión del diseño preliminar 13 de abr de 2011 Sergio Sánchez Rios Se recomienda que el número de integrantes sea pequeño de modo que facilite las discusiones. Durante la revisión se presenta a la audiencia el diseño conceptual. Al hacerlo, se demuestra que el sistema tiene la estructura requerida, las funciones y las características especificadas por los documentos de análisis. Todos los participantes, en conjunto, verifican que el diseño propuesto incluya el hardware necesario, interfaces con otros sistemas, entradas y salidas. Los clientes aprueban los diálogos y menús, los formatos de los informes y el tratamiento de defectos propuestos.
  • 62.
  • 63. Revisiones del diseño Revisión crítica del diseño 13 de abr de 2011 Sergio Sánchez Rios Este grupo es más técnico que el anterior. Ya que la revisión trata de aspectos técnicos. El moderador conduce la reunión para que se traten dos puntos: si el diseño implementa todos los requerimientos y si es un diseño de calidad. Usando diagramas, datos o ambas cosas, se explican las estrategias de diseño alternativa y como y porque se han tomado las principales decisiones de diseño. Si se identifican problemas mayores el diseño se rehace.
  • 64.
  • 65. Revisiones del diseño Revisión del diseño de programas 13 de abr de 2011 Sergio Sánchez Rios Este proceso se centra en la detección de defectos más que en su corrección. Además se esta evaluando el diseño no a los diseñadores. El proceso beneficia a todos al encontrar defectos y problemas cuando aún son fáciles y poco costosos de corregir.
  • 66.
  • 67.
  • 68. Documentando el diseño 13 de abr de 2011 Sergio Sánchez Rios 3. Finalmente se realiza un referencia cruzada del diseño y los requerimientos.
  • 69.