Unidad 2
Diseño: es el proceso de transformar un problema en una solución. El objetivo es definir un producto con los suficientes
detalles como para permitir su realización física. Con el diseño se pretende construir un sistema que respete los
requisitos obtenidos. Se debe tener en cuenta que se pueden elaborar muchos diseños, que dan diferentes soluciones al
problema.
El diseño del software comienza una vez que se analizaron y modelaron los requerimientos. El diseño prepara la etapa
de construcción (generación y prueba de código).
El trabajo principal que se produce durante el diseño del software es un modelo de diseño. El Diseño debe ser una guía
que puedan leer y entender los que construyan el código y los que prueban y mantienen el software. Los elementos del
modelo de diseño usan muchos de los diagramas UML que se utilizaron en el modelo del análisis. La diferencia es que
estos diagramas se refinan y elaboran como parte del diseño.
Primero se elabora un Diseño conceptual, en el cual se describe en el lenguaje del cliente qué hará el sistema y sus
funciones. Es independiente de la implementación.
Una vez que el cliente aprueba el diseño conceptual se pasa al diseño técnico, donde se describe en un documento más
detallado las funciones de los componentes y la estructura y flujo de los datos. Se realiza analizando de lo general a lo
particular, es decir, primero se enfoca en todo el sistema, luego se definen los subsistemas, cómo se comunican, se
describe cada componente por separado, etc.
Las características de un buen diseño técnico son:
La modularidad significa que los componentes tienen entradas y salidas claramente definidas y cada componente tiene
un propósito claramente establecido.
La modularidad es la manifestación más común de la división de problemas. El software se divide en componentes
separados, en ocasiones llamados módulos, que se integran para satisfacer los requerimientos del problema.
El diseño modular efectivo reduce la complejidad, facilita los cambios y produce como resultado una implementación
más sencilla, permitiendo el desarrollo paralelo de las diferentes partes del sistema.
Otras características de un buen diseño:
• Facilidad de comprender (Legibilidad)
• Facilidad de modificar (Extensibilidad)
• Facilidad de uso (aprender el sistema, operar y preparar datos)
• Correcta traducción de las especificaciones de requerimientos (Funcionalidad)
• Eficiencia
• Reutilización
• Robustez (firme)
• Compatibilidad
• Portabilidad (poder ejecutarse en diferentes plataformas, esfuerzo transferir un programa)
• Facilidad de implementar
• Facilidad de probar
Hace uso de estructuras de datos y algoritmos establecidos, no reinventes la ruada
Hace uso de buenos nombres (para variables, funciones, clases etc.): los nombres apropiados son aquellos que hacen
referencia a la responsabilidad que tienen estos elementos del código y ayudan a la legibilidad del código.
Independencia de los componentes/independencia funcional: cada módulo resuelva un subconjunto específico de
requerimientos y tenga una interfaz sencilla cuando se vea desde otras partes de la estructura del programa.
• Acoplamiento: Dos componentes están altamente acoplados cuando existe mucha dependencia entre ellos. Los
poco acoplados tienen alguna dependencia, pero las interconexiones entre ellos son débiles. Los componentes
no acoplados no tienen interconexiones con el resto; son completamente independientes
• Cohesión: Se refiere al grado de “adhesivo” interno con el que se ha construido el componente. Cuando más
cohesivo es un componente, más relacionadas están las partes internas de él, tanto entre ellas como en relación
al propósito global. Un módulo cohesivo ejecuta una tarea sencilla de un procedimiento de SW y requiere poca
interacción con
Diseño a nivel de componentes: Define las estructuras de datos, los algoritmos, las características de la interfaz y los
mecanismos de comunicación asignados a cada componente de software. Como resultado se obtiene el diseño de cada
componente, representado en una notación gráfica, tabular o textual.
Componente: parte modular de un sistema, bloque de construcción modular para el software de cómputo.
• Concepto orientado a objetos: Es un conjunto de clases que colaboran entre sí. Cada clase un componente se ha
elaborado completamente para incluir todos los atributos y las operaciones relevantes para su implementación.
Como parte de la elaboración del diseño, también deben definirse todas las interfaces (mensajes) que permiten
que las clases se comuniquen con otras. Diagrama de secuencia
• Concepto convencional: Es un elemento funcional de un programa que incorpora la lógica del procedimientos
que ejecutan otras partes de un programa
Diseño estructurado: Los programas se dividen en módulos definidos por las funciones (subrutinas, procedimientos,
funciones, etc.). Se divide al proyecto en tareas y los productos pasan de una tarea a otra en forma secuencial. Este
método da lugar a enormes dificultades cuando se debe modificar o extender el programa ya que los datos son
compartidos por todos los módulos funcionales.
Diseño OO: Los elementos fundamentales son los datos. Las funciones (los métodos) se definen e implementan de
acuerdo a la modularización establecida por los datos. Cada módulo del programa (objeto) es responsable de sus
propios datos, los cuales solo pueden ser modificados por los métodos propios y “observados por los otros objetos a
través de protocolos que resguardan el encapsulamiento” (ocultamiento). Otros conceptos que ayudan a la
extensibilidad y modificación futura son: abstracción, herencia y polimorfismo. Clase: Es un patrón o plantilla para una
categoría de objetos con la misma estructura. Es una fábrica de instancia.
Calidad: El grado en el que un sistema, componente o proceso cumple con los requisitos.
La gestión de la calidad implica:
Calidad del Proyecto: es aplicable a cualquier proyecto, más allá de su producto. (buena documentación, legible,
organizadas las tareas, etc) La verificación comprueba si se está construyendo el producto correctamente mientras que
la validación comprueba si se está construyendo el producto correcto.
Calidad del Producto: es específica para cada tipo de producto. Se centra en la planificación (definir los estándares de
calidad relevantes para el proyecto y cómo satisfacerlos, por ej con Lista de control de Calidad; especifica de cada
componente que se utiliza para verificar que se han realizado un conjunto de pasos necesarios. Usualmente expresan
frases imperativas o interrogativas), aseguramiento (aplicar las actividades programadas para asegurar que se
alcanzarán los requisitos del proyecto) y control de la calidad (se usa lista de control, supervisar los resultados
específicos del proyecto, durante todo el ciclo de vida, una forma es en la verificacion).
La calidad en el diseño es especialmente importante porque es la parte en la que se dan representaciones del software
que pueden evaluarse en su calidad. Es la forma de traducir los requerimientos de los participantes en un producto.
Sin diseño se corre el riesgo de obtener un sistema inestable, que falle cuando se hagan cambios pequeños.
Atributos de calidad: FURPS (Functionality, Usability, Reliability, Performance, Supportability) = FUCRM. (se deben
valorizar, considerarlo al comienzo del diseño)
• Funcionalidad = evaluar conjunto de características y capacidades de la funciones que se entregan sistema y
seguridad en su totalidad. (que tan práctico y útil es)
• Facilidad de uso (usabilidad) = estética, consistencia, documentación.
• Confiabilidad = frecuencia y severidad de fallas, precisión resultados de salida, media de fallas, habilidad de
recuperarse de fallas y la previsibilidad del programa.
• Desempeño = velocidad procesamiento, tiempo de respuesta, consumo de recursos, rendimiento y eficacia.
• Soportabilidad = extender el programa (extensibilidad) , adaptabilidad, servicialidad (los 3 conforman facilidad
de mantenimiento), resistencia a pruebas, compatibilidad, configurabilidad (habilidad para organizar y controlar
elementos configuración del SW)
