DISEÑO DE SOFTWARE 1ª. Parte

Slides:



Advertisements
Presentaciones similares
Fundamentos de Diseño de Software INFT.1
Advertisements

Diseño del Software Diseño de datos Diseño arquitectónico
(c) P. Gomez-Gil, INAOE DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP.
DISEÑO DE SOFTWARE 1ª. Parte
Diseño e Implementación
Universidad Central de Venezuela Facultad de Ciencias Postgrado en Ciencias de la Computación Sistemas Distribuidos Albany Márquez.
Diseño de Sistemas.
Clase 09.  Garantizar la calidad de software  La prueba nunca termina, del IS translada se translada al usuario  Las casas de software invierte del.
Sistema de notificación de incidencias de analizadores para dispositivos móviles Master Universitario de Desarrollo de aplicaciones para dispositivos móviles.
Lcda. Ingrid Graü Diseño de Sistemas 1. Lcda. Ingrid Graü Diseño de Sistemas 2.
1 Ingeniería del Software Diseñó de Software Universidad de los Andes Demián Gutierrez Mayo 2011.
Conferencia 1: Principios de la Tecnología de Objetos Conceptos básicos de la Orientación a Objetos.
Diseño (Diagrama de Clases) Francisco Valdés Souto 2 al 6 de marzo 2009 © Avantare Consultores S. A. de C. V. – Derechos.
Instituto tecnológico superior de lerdo Sistemas de información II Diseño orientado a flujo de datos Profesor: Ing. Ricardo de Jesús Bustamante. Alumna:
Ingeniería del Software Diseñó de Software Universidad de los Andes Demián Gutierrez Abril 2009.
Calidad de Software.   ¿Qué es?  ¿Quién lo hace?  ¿Por qué es importante?  ¿Cuáles son los pasos?  ¿Cuál es el producto final?  ¿Cómo me aseguro.
TEMA: PSP (Personal Software Process) ANALISIS DE SISTEMAS I ING. EDGAR RAUL MOLINA INTEGRAMTES: HANNSEL E. CORDON AC JESSICA IDALMY KRESS FREDERIC HESTIB.
NIA Planeación de una auditoria de Estados Financieros. NOMBRE: Beatriz Acero Zapana CURSO: Auditoria Financiera ESCUELA: Ciencias Contables y Financiera.
INGENIERÍA DE SOFTWARE RODRÍGUEZ CADENA CYNTHIA VIRIDIANA GRANADOS HERNÁNDEZ ERICK METODOLOGÍA OMT.
Organizaciones involucradas: El centro de cálculo noruego. Crea lenguaje llamado Simula 67, desarrollado por Krinsten Nygaard y Ole-Johan Dahl, en 1967.
Análisis de Proyecto de Software.
Herencia Multiple en Java
Ingreso , proceso y salida de datos
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
Ingeniería de Software
Sistema de Base de datos
Programación Orientada a Objetos
U.T. 11: Introducción A Las Bases De Datos
Gestión de Riesgos Corporativos
Proyecto de Software. t07
Proyecto de Software. Clase 06
MOPROSOFT.
Ingeniería en Sistemas de Información
INTRODUCCIÒN AL SISTEMA GESTOR DE BASE DE DATOS
Ingeniería de Sistemas Requerimientos
Ingeniería de Software Somerville
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno. INTRODUCCIÓN A UML  QUE ES UML?  PARA QUE SE UTILIZA  COMPONENTES  DIAGRAMAS.
Tema 3. Lenguaje unificado de modelado UML
Diagrama de flujo y algoritmo
NIAS 320 IMPORTANCIA RELATIVA.
Programación Orientada a Objetos
Ingeniería del Software
CONCEPTOS PRELIMINARES (Cont)
Modelo de interacción de usuario.  El Desarrollo basado en modelos de la interfaz de usuario, en inglés Model-based User Interface Development (MB-UID),
FUNDAMENTOS DE PROGRAMACION EN ENTORNO WEB. Rodrigo Cabello Ing. Informático Director de proyectos Think – Ideas in Motion FUNDAMENTOS.
Metodologías de Desarrollo de Software RUP – Proceso Racional Unificado Gilber BASILIO ROBLES I.E.S.T.P. “DANIEL ALCIDES CARRIÓN” Taller de Modelamiento.
DIAGRAMA DE COMPONENTES INTEGRANTES Córdova Vásquez Giovanny Escobar Alvares Calixto Gomez Quinteros Adelaida Pinto Flores Yarmila.
ANALISIS DE SISTEMAS ANALISIS ORIENTADO A OBJETOS.
2.2 Diseño de la lógica. El esquema lógico es una fuente de información para el diseño físico. Además, juega un papel importante durante la etapa de mantenimiento.
Curso: fundamentos de redes Profesor: Miguel farfan Sesion: 03
Identificación y Clasificación de los Componentes Reutilizables.
Identificación y Clasificación de los Componentes Reutilizables.
INGENIERIA DE REQUISITOS
Temario Unidad 1: Diseño de Software 1. Fundamentos de diseño de software 2. Diseño arquitectónico 3. Diseño de objetos 4. Diseño de la persistencia de.
Estructura de Sistemas Operativos CAMPOS CHACALTANA, ANTHONY.
Estructura de los sistemas Operativos 1. Componentes de un sistema operativo  Administración de procesos  Administración de memoria  Subsistema de Entrada/Salida.
DISEÑO DE SOFTWARE 1ª. Parte
ESTRUCTURA DE SISTEMAS OPERATIVOS Carbajal Rojas karla.
IEEE-STD PRÁCTICA RECOMENDADA PARA LA ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE.
PRESENTACION DE INGENIERIA ORIENTADA A OBJETOS. INTRODUCCION. ¿ Qué es UML ?. UML, por sus siglas en Ingles, Unified Modeling Languaje.(Lenguaje Unificado.
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno. INTRODUCCIÓN A UML  QUE ES UML?  PARA QUE SE UTILIZA  COMPONENTES  DIAGRAMAS.
Características de los Sistemas Operativos
Desarrollo de Sistemas de Información Contable - Sis USB 1 METODOLOGIAS DE DESARROLLO DE SOFTWARE.
NORMA ISO/IEC 9126 Norma publicada en Usada para la evaluación de la calidad de software. Establece las características de calidad para productos.
INTRODUCCIÓN A UML.  QUE ES UML?  PARA QUE SE UTILIZA  COMPONENTES  DIAGRAMAS.
Desarrollo de Sistemas de Información Contable - Sis USB 1 METODOLOGIAS DE DESARROLLO DE SOFTWARE.
PRUEBAS DE CAJA NEGRA. -Internationa Software Testing Qualification Board (ISTQB) Internationa Software Testing Qualification Board (ISTQB) Técnica de.
ESTRUCTURA DE SISTEMAS OPERATIVOS - ROY CANEPA JUAN FABIO
EL C.P.M El C.P.M, (Método del Camino Crítico) es una nueva técnica do la Ingeniería Industrial que ayuda principalmente al control del desarrollo de.
Transcripción de la presentación:

DISEÑO DE SOFTWARE 1ª. Parte NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP Versión:25-10-2009 (c) P. Gomez-Gil, INAOEP. 2009

Pasando del Análisis al Diseño [Pressman 05] (c) P. Gomez-Gil, INAOEP. 2009

Diseño Es el proceso de aplicar varias técnicas y principios con el propósito de definir un dispositivo, proceso o sistema con suficiente detalle que permita su realización física. Diseño es mas que programar o escribir código… (c) P. Gomez-Gil, INAOEP. 2009

Guías para un Diseño de Calidad . . .Hay una diferencia entre hacer que un software trabaje, y hacerlo que trabaje correctamente. . . (c) P. Gomez-Gil, INAOEP. 2009

Guías para un Diseño de Calidad (cont.) Un buen diseño debe tener una arquitectura que: Se ha creado utilizando estilos o patrones “reconocidos” Esta hecho de componentes Se puede implementar de una manera evolutiva, facilitando la implementación y las pruebas Un buen diseño es modular, es decir, puede partirse de manera lógica en elementos o subsistemas. Un buen diseño contiene representaciones diferenciales de datos, arquitectura, interfaces y componentes. (c) P. Gomez-Gil, INAOEP. 2009

Guías para un Diseño de Calidad (cont.) Un buen diseño debe conducir a estructuras de datos que son apropiadas para las clases a implementarse, y que resultan de patrones reconocidos. Un buen diseño debe llevar a componentes que presentan características funcionales independientes. Un buen diseño debe conducir a interfaces que reducen la complejidad de las conexiones entre componentes y el medio externo. (c) P. Gomez-Gil, INAOEP. 2009

Guías para un Diseño de Calidad (cont.) Un buen diseño debe llevarse a cabo utilizando métodos repetibles y que es conducida por la información obtenida en el análisis. Un buen diseño debe representarse usando una notación que es efectiva en la manera que comunica el significado del diseño. (c) P. Gomez-Gil, INAOEP. 2009

Atributos de Calidad en el Diseño Funcionalidad Usabilidad Confiabilidad Desempeño Sustentabilidad …y que significa todo esto?? (c) P. Gomez-Gil, INAOEP. 2009

Conceptos fundamentales de Diseño Abstracción Refinamiento Arquitectura Modularidad Patrones Clases del diseño (c) P. Gomez-Gil, INAOEP. 2009

Conceptos fundamentales de diseño: Abstracción y Refinamiento La solución a cualquier problema se presenta en varios niveles de abstracción. En el nivel mas alto se presenta una solución general. En el nivel mas bajo se presenta una solución que puede implementarse directamente.   2. REFINAMIENTO La arquitectura de un programa se desarrolla a través del detallado sucesivo de niveles. (c) P. Gomez-Gil, INAOEP. 2009

Conceptos fundamentales de diseño: 3. Arquitectura La arquitectura de software se refiere a la estructura global del software y la manera en que esta estructura proporciona integridad conceptual al sistema. Representa los componentes que tiene el software, como interactúan y la estructura de los datos que usan estos componentes El uso de patrones arquitectónicos permitirán a los diseñadores reutilizar componentes La arquitectura del diseño se puede representar utilizando diferentes modelos: Estructurales, Plantillas, Dinámicos, de procesos, y funcionales. (c) P. Gomez-Gil, INAOEP. 2009

Conceptos fundamentales de diseño: 4. Modularidad Es un atributo del software que permite que un programa sea manejable intelectualmente hablando. Teóricamente el aumento en el número de módulos disminuye la complejidad, y por lo tanto el esfuerzo de resolver un problema; entonces con un número infinito de módulos tendríamos un problema de complejidad cero. Sin embargo el aumento en el número de módulos genera un aumento en el costo por comunicación entre módulos. (c) P. Gomez-Gil, INAOEP. 2009

Número de módulos vs. costo (c) P. Gomez-Gil, INAOEP. 2009

Otras características de modularidad COHESIÓN Es la medida de la fuerza funcional de un módulo o clase. Se busca que la clase tenga la cohesión mas alta posible, lo cual ocurre cuando todos sus elementos contribuyen a la ejecución de una misma tarea.   ACOPLAMIENTO Es la medida de la interdependencia relativa entre clases. Se busca que exista el mínimo posible de acoplamiento entre clases, lo cual sucede cuando las clases se comunican solamente por medio de mensajes. (c) P. Gomez-Gil, INAOEP. 2009

Conceptos fundamentales de diseño: 5. Patrones Un patrón de diseño describe una estructura de diseño que resuelve un problema de diseño particular, dentro de un contexto específico. Un patrón de diseño provee información que permite al diseñador determinar si el patrón es aplicable, si puede re-usarse y si se puede usar como guía para desarrollar algún patrón similar con estructura diferente. (c) P. Gomez-Gil, INAOEP. 2009

Conceptos Fundamentales del diseño (cont.) 6. Clases de Diseño Las clases generadas en el análisis definen el dominio del problema. En el diseño, las clases se definen de manera que se refinan las clases obtenidas en el análisis a fin de que se puedan implementar, El diseño crea un nuevo conjunto de clases que permiten implementar la infraestructura de software que va a sostener la solución. (c) P. Gomez-Gil, INAOEP. 2009

Niveles de clases del diseño Se sugieren 5 niveles de clases de diseño: Clases para el manejo de la interfaz con el usuario Clases para el dominio del negocio Clases para el proceso Clases para la persistencia Clases de administración y control del sistema (c) P. Gomez-Gil, INAOEP. 2009

Características de clases “bien formadas” Completa y suficiente. Una clase de diseño debe tener todos los atributos y métodos razonablemente esperados para existir. Primitividad. Los métodos se deben enfocar en resolver UN servicio de la clase. Una vez que se ha implementado un servicio a través de un método, la clase no debe proveer ninguna otra manera de hacer la misma cosa Alta cohesión. Una clase con un diseño cohesivo tiene un conjunto pequeño y enfocado de responsabilidades y enfoca exclusivamente sus atributos y métodos a cumplir esas responsabilidades Bajo acoplamiento. Aunque las clases tienen que colaborar entre sí, esta colaboración debe ser lo mínimo necesario (c) P. Gomez-Gil, INAOEP. 2009

El modelo de diseño Puede verse desde 2 posibles dimensiones: proceso y abstracción La dimensión del proceso indica la evolución del modelo confirme se van ejecutado el proceso de desarrollo de software La dimensión de abstracción representa el nivel de detalle que surge cuando cada elemento del modelo de análisis se va transformando en su equivalente de diseño, y posteriormente se va refinando iterativamente La línea punteada en la figura indica la frontera (difusa) entre análisis y diseño (c) P. Gomez-Gil, INAOEP. 2009

Dimensiones del modelo de diseño [Pressman 05] (c) P. Gomez-Gil, INAOEP. 2009

Elementos de diseño de datos Crea el modelo de datos e información, representado en un nivel de abstracción alto, y se va refinando progresivamente En la implementación este modelo de datos se traduce en bases de datos, las cuales en un futuro formarán “warehouses” que permitirán el manejo de sistemas administradores de conocimiento de la empresa (c) P. Gomez-Gil, INAOEP. 2009

Elementos de diseño de arquitectura El modelo de arquitectura se obtiene principalmente de 3 fuentes: Información acerca del dominio de aplicación del software a construirse Elementos del modelo de análisis tales como diagramas de flujo o clases generadas en el análisis sus relaciones y colaboraciones Disponibilidad de patrones de arquitectura (c) P. Gomez-Gil, INAOEP. 2009

Elementos de diseño de interfaz Los elementos de diseño de interfaz describen como la información fluye entrando y saliendo del sistema, y como se comunican a través de los componentes definidos como parte de la arquitectura Hay 3 elementos importantes en el diseño de interfaces: Interfaz con el usuario Interfaces externas con otros sistemas, dispositivos, redes u otros productores o consumidores de información Interfaces internas entre los diferentes componentes de diseño (c) P. Gomez-Gil, INAOEP. 2009

Diseño de interfaces externas Requiere información definitiva sobre la entidad a la cual la información se manda o recibe. Debe incluir pruebas de errores y características de seguridad (c) P. Gomez-Gil, INAOEP. 2009

Diseño de interfaces internas Está fuertemente relacionado con el diseño a nivel componentes (diseño detallado) En algunos casos, una interface se diseña de igual manera que una clase. Según la OMG “una interfaz es un especificador de operaciones externamente visibles (publicas) de una clase, componente u otro clasificador (incluyendo subsistemas) sin la especificación de una estructura interna” Una interfaz es un conjunto de operaciones que describe alguna parte del comportamiento de un sistema y las operaciones necesarias para accesar esas operaciones (c) P. Gomez-Gil, INAOEP. 2009