Diseño de Software 1

Transcripción

1 Diseño de Software 1

2 Qué es diseño? El proceso de aplicar distintas técnicas y principios con el propósito de 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: Satisfaga determinada especificación del sistema Se ajuste a las limitaciones impuestas por el medio de destino Respete requisitos sobre forma, rendimiento utilización de recursos, coste, etc.

3 Qué es diseño? El diseño es la primera etapa técnica del proceso de Ingeniería del Software, consiste en producir un modelo o representación técnica del software que se va a desarrollar El diseño es el proceso sobre el que se asienta la calidad del software El diseño se representa a un alto nivel de abstracción, un nivel que se puede seguir hasta requisitos específicos de datos, funcionales y de comportamiento 3

4 Directrices para un buen diseño El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acomodar todos los requisitos implícitos que desee el cliente 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 4

5 Directrices para un buen diseño El diseño debería proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y de comportamiento desde la perspectiva de la implementación 5

6 Principios básicos de diseño Se deberían poder seguir los pasos de diseño hasta el modelo de análisis El diseño no va a reinventar nada que ya esté inventado El diseño debería presentar uniformidad e integración. Debe estructurarse para admitir cambios 6

7 Principios básicos de diseño El diseño no es escribir código y escribir código no es diseñar Se debería valorar la calidad del diseño mientras se crea, no después de terminado 7

8 Conceptos del diseño A la hora de realizar el diseño del software debe plantearse: Qué criterios se pueden usar para dividir el software en componentes individuales? Cómo se separan los detalles de una función o de la estructura de datos de la representación conceptual del software? Existen criterios uniformes que definan la calidad técnica de un diseño de programas? 8

9 Conceptos del diseño Para ayudar a resolver las anteriores preguntas se han establecido unos conceptos fundamentales del diseño del software Abstracción Refinamiento Modularidad Arquitectura del software Ocultamiento de la información Jerarquía de control Partición estructural (horizontal y vertical) Estructura de datos Procedimientos 9

10 Conceptos del diseño El diseño modular efectivo reduce la complejidad, facilita los cambios y produce como resultado una implementación más sencilla. La independencia funcional se adquiere desarrollando módulos con una clara función evitando una excesiva interacción con otros módulos. 10

11 Conceptos del diseño La independencia funcional se mide con dos criterios: Cohesión: extensión del concepto de ocultamiento de información. Un módulo cohesivo ejecuta una tarea sencilla de un procedimiento de software y requiere poca interacción con procedimientos que ejecutan otras partes de un programa Acoplamiento: medida de la interconexión entre módulos de un programa Interesa una cohesión alta y un acoplamiento bajo 11

12 Niveles de Diseño Diseño conceptual Diseño lógico Diseño físico 12

13 Diseño conceptual En esta etapa se debe construir un esquema de la información que se usa en la empresa, independiente de cualquier consideración física. A este esquema se le denomina esquema conceptual. Al construir el esquema, los diseñadores descubren la semántica (significado) de los datos de la empresa: encuentran entidades, atributos y relaciones. 13

14 Diseño conceptual El objetivo es comprender: La perspectiva que cada usuario tiene de los datos. La naturaleza de los datos, independientemente de su representación física. El uso de los datos a través de las áreas de aplicación. El esquema conceptual se puede utilizar para que el diseñador transmita a la empresa lo que ha entendido sobre la información que ésta maneja. 14

15 Diseño Lógico Traduce los escenarios de uso creados en el diseño conceptual en un conjunto de objetos de negocio y sus servicios. El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. El diseño lógico es independiente de la tecnología. El diseño lógico refina, organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios 15

16 Diseño Lógico El diseño lógico comprende las siguientes tareas: Identificar y definir los objetos de negocio y sus servicios Definir las interfaces Identificar las dependencias entre objetos Validar contra los escenarios de uso Comparar con la arquitectura de la empresa Revisar y refinar tanto como sea necesario 16

17 Diseño Físico El diseño físico es el proceso de producir la descripción de la implementación de la base de datos Para llevar a cabo esta etapa, se debe haber decidido cuál es el SGBD que se va a utilizar, ya que el esquema físico se adapta a él. Entre el diseño físico y el diseño lógico hay una realimentación, ya que algunas de las decisiones que se tomen durante el diseño físico para mejorar las prestaciones, pueden afectar a la estructura del esquema lógico. 17

18 Diseño Físico El propósito del diseño físico es describir cómo se va a implementar físicamente el esquema lógico. Concretamente, en el modelo relacional, esto consiste en: Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir sobre ellas. Determinar las estructuras de almacenamiento y los métodos de acceso que se van a utilizar para conseguir unas prestaciones óptimas. Diseñar el modelo de seguridad del sistema. 18

19 Diseño de aplicaciones Diseño de transacciones Diseño de interfaces de usuario 19

20 Diseño de transacciones Una transacción es un conjunto de acciones llevadas a cabo por un usuario o un programa de aplicación, que acceden o cambian el contenido de la base de datos. Una transacción puede estar compuesta por varias operaciones, como la transferencia de dinero de una cuenta bancaria a otra. Sin embargo, desde el punto de vista del usuario, estas operaciones conforman una sola tarea. 20

21 Diseño de transacciones Desde el punto de vista del SGBD, una transacción lleva a la base de datos de un estado consistente a otro estado consistente. El SGBD garantiza la consistencia de la base de datos incluso si se produce algún fallo, y también garantiza que una vez se ha finalizado una transacción, los cambios realizados por ésta quedan permanentemente en la base de datos. 21

22 Diseño de transacciones El objetivo del diseño de las transacciones es definir y documentar las características de alto nivel de las transacciones que requiere el sistema. Esta tarea se debe llevar a cabo al principio del proceso de diseño para garantizar que el esquema lógico es capaz de soportar todas las transacciones necesarias. 22

23 Características de transacciones Datos que utiliza la transacción. Características funcionales de la transacción. Salida de la transacción. Importancia para los usuarios. Frecuencia de utilización. 23

24 Tipos de transacciones Transacciones de recuperación: se accede a los datos para visualizarlos en la pantalla o a modo de informe. Transacciones de actualización: se insertan, borran o actualizan datos de la base de datos. Transacciones mixtas: se mezclan operaciones de recuperación de datos y de actualización. 24

25 Diseño de interfaces de usuario Antes de implementar los formularios y los informes, hay que diseñar su aspecto. Es conveniente tener en cuenta las siguientes recomendaciones: Utilizar títulos que sean significativos, que identifiquen sin ambigüedad el propósito del informe o formulario. Dar instrucciones breves y fáciles de comprender. Agrupar y secuenciar los campos de forma lógica. Hacer que el aspecto del informe o formulario sea atractivo a la vista. 25

26 Diseño de interfaces de usuario Utilizar nombres familiares para etiquetar los campos. Utilizar terminología y abreviaturas consistentes. Hacer un uso razonable y consistente de los colores. Dejar un espacio visible para los datos de entrada y delimitarlos. Marcar los campos que sean opcionales. Dar mensajes a nivel de campo para explicar su significado. Dar una señal que indique cuándo el informe o formulario está completo. 26

27 Diseño Detallado 27

28 Diseño detallado Completa la fase de diseño del ciclo de vida del proyecto. Puede partir de: Un diseño conceptual, cuando hubo necesidad de hacer una propuesta al cliente y obtener su aprobación Un prototipo, cuando el software es rico en interfaz de usuario y esta herramienta resultó más adecuada para comunicarse con el cliente

29 Diseño detallado La especificación de requerimientos, cuando hay pocas alternativas de implementación y no se ha requerido una aprobación previa del cliente del enfoque de la solución. Ninguno de los anteriores, caso en el que el DD es el primer producto tangible del proyecto. En este caso están implícitos los requerimientos y procede cuando el proyecto es pequeño, son muy claros los requerimientos y la contraparte tiene la habilidad para validar este producto.

30 Diseño detallado A diferencia del diseño conceptual, el usuario principal de este producto será el programador. El objetivo principal del diseño detallado es el de comunicar a los programadores lo que se debe implementar (a más bajo nivel), usando medios y herramientas de mayor carácter técnico.

31 Diseño detallado Independientemente de las técnicas empleadas, normalmente incluyen aspectos comunes como diseño de la interfaz de uso, clases, interfaces, propiedades, métodos, flujos de información, algoritmos propuestos para procesos complejos, esquemas de bases de datos, etc. El contenido varía con la naturaleza del producto.

32 Diseño detallado Este producto es la base para la estimación definitiva del proyecto, pues es el producto que finalmente especifica en detalle qué es lo que debe implementarse. Nótese que esto es independiente del ciclo de vida que se utilice (tradicional, incremental, ágil, etc.)

33 Diseño detallado Si hubo una estimación temprano en el proyecto, debe ser refinada a partir del diseño detallado, pues es a partir de este producto que la estimación del proyecto puede estar mejor fundamentada. También deben ser completados o refinados los planes o casos de pruebas para incorporar la verificación de aspectos derivados directamente del diseño y no tanto de los requerimientos.

34 Diseño detallado (recomendaciones) El diseño detallado debe incluir toda la información necesaria para que sirva de guía (completa) para que los programadores puedan hacer el trabajo tal y como lo espera el arquitecto del producto, para evitar que los programadores se tornen creativos en exceso y terminen tomando decisiones importantes por sí mismos.

35 Diseño detallado (recomendaciones) El formato del producto debe ser elegido y m e j o r a d o constantemente para incorporar los métodos y modelos que describan mejor el trabajo que se requiere y minimicen a la vez el esfuerzo requerido para documentarlo. Cuanta menos prosa sea necesaria, mejor.

36 Diseño detallado (recomendaciones) El formato también debe estar previsto para hacerle lugar a los cambios con facilidad y flexibilidad. Además, debe i n c l u i r l o s medios necesarios para poder dar trazabilidad a los requerimientos, esto es determinar que pieza del diseño está cubriendo cada requerimiento contemplado en el alcance del proyecto.

37 Diseño detallado (recomendaciones) Igual que los demás productos importantes del proyecto, debe incluir las cláusulas, versionamiento, espacio para firmas y demás formalismos que permitan ejercer control sobre el producto. En el caso del diseño detallado, será más difícil poder conseguir la aprobación directa del cliente, pues éste normalmente no tendrá el conocimiento ni el interés para hacerlo.

38 Diseño detallado (recomendaciones) Sin embargo, si no hubo diseño conceptual o en el diseño detallado se están tomando decisiones importantes q u e afectarán la experiencia del usuario con el producto, el cliente debería ser enterado y su aprobación registrada. En la medida de lo posible, es conveniente que el formato también esté diseñado para incorporar elementos que faciliten la generación de la documentación de uso del sistema, para maximizar la eficiencia del esfuerzo invertido en esta actividad.

39 Diseño detallado (precauciones) El producto debe incluir toda la información estrictamente requerida, ni más ni menos. Si falta información, podría dejarse fuera funcionalidad aprobada. Si sobra información, se habrá perdido esfuerzo que no aporta valor agregado al producto o al proyecto.

40 Diseño detallado (precauciones) El proceso debe asegurar la vigencia del diseño en todo momento. Es sumamente sencillo que un diseño se desactualice con la llegada de cambios en el proyecto, sobre todo si los programadores son quienes deciden incorporarlos por cuenta propia. También en la etapa de mantenimiento suele perderse de vista la actualización de este producto.