UNIDAD 4 Modelo de Diseo

Diseo del software

Diseo

Definicin
El proceso de definicin de la arquitectura, componente, interfaces y otras caractersticas de un sistema o de un componente. El resultado de este proceso.
IEEE std. 610.12-1990 Glossary of software engineering terminology

El diseo del software comprende la descripcin de la arquitectura del sistema con el nivel de detalle suficiente para guiar su construccin. Descomposicin del sistema Organizacin entre los componentes del sistema Interfaces entre los componentes

Diseo del software

Diseo
Diseo es la actividad del ciclo de vida en la que se analizan los requisitos del software para desarrollar una descripcin de la estructura interna y la organizacin del sistema que servir de base para su construccin.

Requisitos

Diseo

Construccin

Diseo del software

Diseo

El diseo como creacin de modelos

Una vez conocidas las necesidades de los usuarios es preciso disear una solucin. Empleando el smil con la construccin de edificios, tras conocer cuales son las necesidades que se desean cubrir con un edificio (hotel, colegio, vivienda familiar, edificio de apartamentos), es el momento de disear la solucin. Las posibilidades son muchas, y exceptuando proyectos de tamao mnimo, la complejidad de concebir todas las facetas e interacciones del sistema desborda la capacidad de abstraccin mental para concebirlo en una nica visin. Al mismo tiempo es necesario que todas las personas implicadas en el proyecto conozcan y compartan los planos de la solucin. As pues, las razones del diseo son: Concepcin u anlisis de las posibles soluciones. Apoyo metodolgico para abordar la complejidad de la solucin. Registro documentado como medio de comunicacin entre los participantes. Un modelo es una representacin simplificada de la realidad. De igual forma que al concebir un edificio se divide la complejidad del sistema para hacerlo digerible, y se generan diversos modelos de los diferentes aspectos: planos de estructura, planos del subsistema de fontanera, del de electricidad, etc. los sistemas de software son tambin realidades complejas que es preciso conocer (modelizar) para llevar a cabo el diseo de su solucin.

Diseo del software

Actividades del diseo de software

El diseo del software comprende dos actividades intermedias entre la fase de requisitos y la de construccin:

Diseo de la arquitectura del software

Descripcin de la arquitectura general, identificacin de sus componentes y su organizacin y relaciones en el sistema.

Diseo detallado

del software

Definicin y estructura de los componentes y datos. Definicin de los interfaces Elaboracin de las estimaciones de tiempo y tamao.

Considerando que la descripcin del sistema (ConOps) dibuja una primera aproximacin del sistema en su conjunto, algunos autores diferencian entre: Diseo del sistema (la visin del documento de descripcin del sistema). Diseo de la arquitectura Diseo del detallado del software
5

Diseo del software

Razones del diseo del software

Por qu?
El resumen de las razones expuestas que hacen necesarias las tareas de diseo antes de comenzar la construccin de un sistema son:

Permite la descomposicin del problema en partes y vistas de menor tamao, ms manejables para el trabajo intelectual del diseo de la solucin. Permite el desarrollo de modelos que se pueden analizar para determinar si cumplen los distintos requisitos. Permite examinar soluciones alternativas. Los modelos se pueden utilizar para planificar el desarrollo de las actividades, y son el punto de partida para empezar las actividades de codificacin y pruebas.

Diseo del software

Razones del diseo de software

Descomposicin

de la complejidad

Class nombredeclase{ Public: funcion() {} }

7

Diseo del software

Razones del diseo de software

Anlisis de soluciones posibles a travs de su modelado.

Requisitos

Disponibilidad Coste desarrollo

Coste mantenimiento Robustez

Tiempos de respuesta Hardware necesario

Etc.
8

Diseo del software

Razones del diseo de software

Elemento de comunicacin, Base de planificacin

y del desarrollo

Diseo del software

Fin del proceso de diseo

Se considera que el proceso de diseo se ha completado cuando

Todas las preguntas Como tienen respuesta La descripcin del diseo de la arquitectura est completada La revisin del diseo se ha completado y cada equipo/persona implicado est de acuerdo con el diseo. estn realizados

Los borradores de manuales para mantenimiento y administracin Se ha realizado la trazabilidad del diseo Se ha revisado el diseo de la arquitectura Se ha verificado el diseo de la arquitectura Se ha escrito la planificacin de la integracin del software. Se ha establecido la lnea base del producto

10

Diseo del software

Vistas del diseo de la arquitectura

Un sistema de software es una entidad ortogonal que puede contemplarse o analizarse desde diferentes vistas: Puede enfocarse la atencin en: Distribucin fsica del software entre los diferentes elementos del sistema. Descomposicin en las diferentes funcionalidades que realiza. Estructuras de la informacin que gestiona. Etc. De esta forma el diseo puede generar modelos para cada una de las diferentes vistas empleadas en su anlisis (modelo fsico, modelo de datos, modelo se procesos, etc.).

11

Diseo del software

Notacin empleada
Si bien el concepto y la finalidad del diseo o modelado de un sistema de software es siempre el mismo, las notaciones pueden variar en funcin de las caractersticas de cada proyecto o de los conocimientos o preferencias de las personas u organizacin que lo realice. A travs del lenguaje de modelado empleado (UML, IDEF, Diagramas de flujo, etc.) se consiguen realizar dos tipo de descripciones:

Descripciones estructurales
Las notaciones para descripciones estructurales suelen ser grficas y representan los diferentes componentes y sus relaciones. Lenguajes de descripcin de arquitecturas (ADL): AADL, AESOP, CODE, MetaH, Gestalt, Modechart, UML, Unicon, Modechart, etc. Diagramas de clases y objetos Diagramas de componentes Diagramas entidad-relacin Lenguajes de descripcin de interfaz Etc.

Descripciones de comportamiento

Diagramas de actividad Diagramas de colaboracin Diagramas de flujo de datos Diagramas de flujo Pseudo-cdigo y lenguajes de diseo (PDL) Diagramas de secuencia Etc.
12

Diseo del software

Estrategias y mtodos para el diseo del software

Las principales estrategias que suelen emplearse para el diseo del software son: Orientadas a funciones (estructurada) Orientada a objetos (diseo orientado a objetos) Diseo centrado en las estructuras de datos (menos empleado)

Diseo estructurado
Esta es la aproximacin clsica y se centra en la identificacin y descomposicin de las principales funciones del sistema hacia niveles ms detallados.

Diseo orientado a objetos

Es la aproximacin ms popular actualmente, sobre la que se han desarrollado numerosos mtodos partiendo de su concepcin inicial en la dcada de los 80 A travs del diseo orientado a objetos (OOD), se desarrollan las especificaciones de sistemas como modelos de objetos (sistemas compuestos por conjuntos de objetos que interactan entre ellos). que, expuesta de forma muy bsica, identifica a los nombres como objetos, a los verbos como los comportamientos que pueden ofrecer y a los adjetivos como sus mtodos.

Para cada estrategia hay numerosos mtodos (notaciones, lenguajes de modelado, tcnicas).

13

Diseo del software

El paradigma 00 Orientacin a objetos

OO no es una estrategia de diseo. El paradigma de orientacin a objetos es ms amplio y abarca un enfoque general para conceptualizar, disear y programar los sistemas de software.

Estrategias
Las estrategias OO cubren tanto los requisitos como el anlisis, diseo y programacin. Anlisis Orientado a Objetos (OOA) Diseo Orientado a Objetos (OOD) Programacin Orientada a Objetos (OOP)

Mtodos
Las metodologas ms importantes de anlisis y diseo de sistemas, orientado a objetos, han terminado confluyendo en lo que es el UML (www.uml.org), bajo el respaldo del Object Management Group (www.omg.org).
Algunas de las principales metodologas, pioneras que han terminado confluyendo en el UML son: Object-Oriented Design (OOD), Booch. Object Modeling Technique (OMT), Rumbaugh. Object Oriented Analysis (OOA), Coad/Yourdon. Hierarchical Object Oriented Design (HOOD), ESA. Object Oriented Structured Design (OOSD), Wasserman. Object Oriented Systems Analysis (OOSA), Shaler y Mellor. Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.
14

Diseo del software

El paradigma 00 Orientacin a objetos

Enfoque OO
Este paradigma centra su foco en el concepto Objeto.
Objeto es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos). La estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento comn. La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstraccin, la "esencia" de un objeto, tal como son. De aqu que un objeto no es una clase, sin embargo, una clase puede ser un objeto.

Beneficios

del enfoque OO

Los beneficios sealados por Booch en 1986 son:

Potencia, el uso del modelo OO ayuda a explotar el poder expresivo de los lenguajes de programacin basados u orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, Java, C#
Reutilizacin, el uso del modelo OO favorece la reutilizacin, no solo del software, sino de diseos completos. Mantenibilidad, produce sistemas que estn construidos en formas intermedias estables y por ello son ms resistentes al cambio en especificaciones y tecnologa.

15

Diseo del software

El paradigma 00 Orientacin a objetos

Principios del modelo OO

Fundamentales: Abstraccin, encapsulacin, modularidad y jerarqua. Booch afirma que un modelo en el que no est presente alguno de estos principios NO es un modelo OO.
Complementarios: Tipificacin, concurrencia y persistencia

Abstraccin. Simplificacin en la descripcin o especificacin de un sistema consistente en enfatizar algunos detalles o propiedades del sistema, con detrimento o supresin de otros. Encapsulacin. Ocultacin de los detalles de un objeto que no contribuyen a sus caractersticas esenciales. Modularidad. Propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes. Jerarqua o herencia. Orden de las abstracciones organizado por niveles. Tipificacin. Definicin precisa de un objeto de forma tal que objetos de diferentes tipos no puedan ser intercambiados o, a lo sumo, pueden intercambiarse de manera muy restringida. Concurrencia . Propiedad que distingue un objeto que est activo de uno que no lo est. Persistencia. Propiedad de un objeto por la cual su existencia trasciende al tiempo (es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o al espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado).
16

Diseo del software

UML
UML es un lenguaje de modelado que permite especificar, visualizar y documentar modelos de sistemas de software. Desde sus inicios fue concebido para ayudar a las tareas de anlisis de los sistemas de software, y este es sin duda el mbito de mayor utilizacin, si bien es cierto que en la actualidad tambin se emplea en el modelado y diseo de otros tipos de sistemas (modelos de negocio, producciones cinematogrficas, etc.)

Tipos de diagramas UML

UML proporciona diagramas para representar modelos de las visiones estticas y dinmicas del sistema, as como de su modularizacin. REPRESENTACIONES Estructura esttica Comportamiento dinmico Modularizacin

Diagrama de clases Diagrama de objetos Diagrama de componentes Diagrama de despliegue

Diagrama de casos de uso Diagrama de secuencia Diagrama de colaboracin Diagrama de actividad Diagrama de colaboracin Diagrama de estados

Paquetes Subsistemas Modelos

17

Diseo del software

Descripcin del diseo del software (SDD)

El resultado del proceso de diseo es la documentacin denominada Descripcin del Diseo del Software. Un estndar empleado para desarrollar esta documentacin de forma normalizada es el IEEE Std. 1016-1998.

IEEE Std. 1016-1998

Describe prcticas recomendadas para describir los diseos de software. Especifica la informacin que debe contener, y recomienda cmo organizarla. Puede emplearse en software comercial, cientfico o militar sin limitaciones por el tamao, complejidad o nivel de criticidad. El estndar no establece ni limita determinadas metodologas de diseo, gestin de la configuracin o aseguramiento de la calidad.

18

Diseo del software

Descripcin del diseo del software (SDD)

Ejemplo de una posible

organizacin de la informacin en una SDD

1.- Introduccin 1.1 Propsito 1.2 Alcance 1.3 Definiciones y acrnimos 2.- Referencias 3.- Descomposicin de la informacin 3.1 Descomposicin modular 3.1.1. Descripcin del mdulo 1 3.1.2. Descripcin del mdulo 2 3.2 Descomposicin de los proceesos 3.2.1. Descomposicin del proceso 1 3.2.2. Descomposicin del proceso 2 3.3 Descomposicin de los datos 3.3.1. Descripcin de la entidad 1 3.3.2. Descripcin de la entidad 2

4.- Descripcin de las dependencias 4.1 Dependencias intermolulares 4.2 Dependencias inter-procesos 4.3 Dependencias de los datos 5.- Descripcin de interfaces 5.1 Interfaces entre mdulos 5.1.1 Interfaz del mdulo 1 5.1.2 Interfaz del mdulo 2 5.2 Interfaces entre procesos 5.2.1 Interfaz del proceso 1 5.2.2 Interfaz del proceso 2 6.- Diseo detallado 6.1 Diseo detallado de los mdulos 6.1.1 Detalle del mdulo 1 6.1.2 Detalle del mdulo 2 6.2 Diseo detallado de los datos 6.1.1 Detalle de la entidad 1 6.1.2 Detalle de la entidad 2

19

Diseo del software

Prcticas recomendadas

Trazabilidad

del diseo

Comprobacin de que el diseo incluye todos lols requisitos Comprobacin de que el diseo no incluye funciones adicionales no especificadas en el SRS. Los resultados de la trazabiliad del diseo deben estar documentados para la reunin de revisin del diseo

Reunin de revisin del diseo de la arquitectura

Revisin del diseo de la arquitectura Un equipo apropiado (Usuarios, cliente, ingeniero de soft) revisan el diseo. Una vez aprobado este diseo de puede comenzar a realizar el diseo detallado.

Verificacin del diseo de la arquitectura

El diseo se verifica contra el SRS El proceso de verificacin analiza si el diseo es incompleto, incorrecto, ineficiente, difcil de mantener, presenta un interfaz de usuario difcil de utilizar o aprender, o la documentacin es de baja calidad. Se realiza un informe para documentar los posibles problemas encontrados y tomar nota de posibles incompatibilidades entre documentos. LNEA BASE DE REQUISITOS LNEA BASE DE DISEO

QU
CMO
20

Diseo del software

Base para las tareas de planificacin

La planificacin comienza con la misma decisin de desarrollar un sistema de software, y es un esfuerzo continuo que termina cuando el proyecto ha concluido. La planificacin consiste en la especificacin de: Metas y objetivos para el proyecto Estrategias, poltica, y procedimientos Explicndolo de otra forma es la decisin de: qu hacer cmo hacerlo cuando hacerlo quien va a hacerlo. A lo largo del ciclo de vida, desde la concepcin inicial del proyecto, la planificacin se va revisando y depurando, y una vez obtenido el diseo se dispone de una base slida. El diseo es la representacin formal de qu hacer y cmo hacerlo, sobre la que se puede asignar cando y quin.

21

Diseo del software

Planificacin = tareas de ingeniera del software y de gestin

La planificacin del proyecto est dividido entre dos componentes relacionados:

Planificacin realizada por el gestor Planificacin realizada por el ingeniero de sistemas

Ingeniero de Software decide: Qu tareas hay que realizar Orden y Dependencias de tareas Tamao (Esfuerzo en horas) Solucin tcnica para la resolucin del problema Qu herramientas de anlisis y diseo hay que utilizar Riesgos tcnicos El modelo de procesos (Tcnicas) Actualizar la planificacin cuando los requisitos o el entorno cambian.

Gestor de Proyecto decide: Las habilidades necesarias para realizar las tareas La agenda para terminar el proyecto El coste de esfuerzo Metodologa para evaluar el estatus del proyecto Qu herramientas de planificacin hay que utilizar Gestin de riesgos El modelo de procesos (Gestin) Actualizar la planificacin cuando condiciones de gestin y entorno cambian. 22

Diseo del software

Consideraciones

El diseo es la estrategia de solucin. Las tareas de codificacin, integracin y mantenimiento del sistema son la tctica. La estrategia debe ser adecuada a las necesidades de los usuarios (requisitos y atributos de calidad esperados). No surge de procesos, herramientas o lenguajes de modelado. Surge del talento de su creador. Los procesos, las herramientas y los lenguajes de modelado pueden resultar tiles como ayuda para descomponer la complejidad, y para comunicar el diseo a los participantes del proyecto. El talento de algunos profesionales les puede permitir manejar niveles de complejidad elevados sin necesitar apoyo de procesos, herramientas o lenguajes de modelado. A travs del cdigo es posible ver el diseo y la arquitectura del sistema. La documentacin del cdigo resulta til para comunicar su diseo a travs del espacio en sistemas en los que intervienen muchos desarrolladores, y del tiempo para facilitar su mantenimiento. Al emplear documentacin para la comunicacin del diseo es necesario trabajar con procesos suficientes para garantizar su integridad y actualidad a travs de los cambios. El diseo no cumple su finalidad hasta que no queda plasmado en el cdigo. El resultado del diseo puede fallar tanto errores en su estrategia como por distorsiones introducidas en la codificacin, integracin y mantenimiento.

23