Tema5 Principiosdeldisenodelsoftware 1pp

Ingeniera del Software
Tema 5: Principios del diseo del software

Dr. Francisco Jos Garca Pealvo (fgarcia@usal.es) Miguel ngel Conde Gonzlez (mconde@usal.es) Sergio Bravo Martn (ser@usal.es)
3 I.T.I.S. Fecha de ltima modificacin: 16-10-2008
Ob l i ve er n i o t en r Ob usua de
el N iv r io a u su
l i ve er n t en u ar i o s de u vel r ni o Lee s u ar i u de
el N ivr io a u su
vel r ni Lee u ar i o us de
Universidad de Salamanca Departamento de Informtica y Automtica
Ingeniera del Software Principios del diseo del software
Resumen
El diseo y la construccin del software est soportada por varios principios fundamentales. Estos principios favorecen que los objetivos de calidad del software se alcancen con mayor facilidad. En este tema se estudiarn los principios y tcnicas que permiten construir arquitecturas software correctas. Primeramente se introducir la fase de diseo y el proceso de diseo, para posteriormente centrarse en los principios y conceptos fundamentales del diseo del software, haciendo un especial hincapi en todos aqullos que permitan alcanzar un diseo modular eficaz, basado en mdulos altamente cohesionados, con bajo acoplamiento y construidos sobre la base de la ocultacin de la informacin Diseo de software; Diseo arquitectnico; Diseo de datos; Diseo de procedimientos; Diseo de la interfaz; Abstraccin; Refinamiento sucesivo; Modularidad; Arquitectura del software; Jerarqua de control; Particin estructural; Estructura de datos; Procedimiento del software; Ocultacin de la informacin; Diseo modular; Mdulo; Independencia modular; Cohesin; Acoplamiento [Meyer, 1999] Captulo 3 [Piattini et al., 2004] Captulo 8 [Pressman, 2006] Captulos 9, 10, 11 y 12 [Sommerville, 2005] Captulos 11 y 16
Resumen
Descriptores
Bibliografa
Esquema
Introduccin
Proceso de diseo del software Principios y conceptos del diseo del software Aportaciones principales del tema Ejercicios Lecturas complementarias Referencias
1. Introduccin
Concepto de diseo
Proceso de aplicar distintas tcnicas y principios con el propsito de definir un dispositivo, proceso o sistema con los suficientes detalles como para permitir su realizacin fsica [Taylor, 1959]

Proceso comn en la actividad humana Intuitivamente es el proceso que se trata de formular y evaluar una solucin para un problema dado En el caso del diseo de un sistema software ser la bsqueda de soluciones que se ajusten a los requisitos del usuario Actividad necesaria para conseguir un software bien acabado
5
Importancia del diseo en el ciclo de vida de un producto

Mantenimiento
Mantenimiento Prueba
Prueba
Implementacin Diseo
Implementacin
Con diseo
Sin diseo
Definicin de requisitos
Diseo
Aplicacin software
Diseo como actividad creativa
El diseo combina

Creatividad Intuicin Experiencia
Del ingeniero del software
Guas Mtodos Heursticas
Del proceso de diseo
Diseo Final
Criterios de calidad Proceso iterativo
Definicin de diseo de software (i)
Es el proceso de definicin de la arquitectura software: componentes mdulos, interfaces, procedimientos de prueba y datos de un sistema que se crean para satisfacer unos requisitos especificados [AECC, 1986] En un sentido, el diseo es la representacin de un objeto que est siendo creado. Un diseo es una informacin de base que describe aspectos de este objeto, y el proceso de diseo puede ser visto como una elaboracin sucesiva de representaciones, tales como aadir ms informacin, puntos de retorno y explorar alternativas [Webster, 1988] Es la prctica de tomar una especificacin del comportamiento observable externamente y aadir los detalles necesarios para la implementacin actual del sistema computacional, incluyendo detalles sobre la interaccin de los usuarios, la gestin de tareas y la gestin de datos [Coad y Yourdon, 1991]
Definicin de diseo de software (ii)
Es un proceso de invencin y seleccin de programas que cumplan los objetivos de un sistema software. La entrada incluye el entendimiento de los requisitos, las restricciones de entorno y los criterios de diseo. La salida del proceso de diseo est compuesta de una arquitectura de diseo que muestra como las piezas estn interrelacionadas, de especificaciones de cualquier pieza nueva y de las definiciones de cualquier dato nuevo [Stevens, 1991] El diseo de software es el proceso de definir la arquitectura, componentes, interfaces y otras caractersticas de un sistema o componente; el resultado de ese proceso IEEE-Std. 610.12 [IEEE, 1999] El diseo del software es una descripcin de la estructura del software que se va a implementar, los datos que son parte del sistema, las interfaces entre los componentes del sistema y, algunas veces, los algoritmos utilizados [Sommerville, 2005]
Evolucin del diseo de software

El diseo de software disciplina que evoluciona Primeros aos de la dcada de los 70s

Programacin modular [Dennis, 1973] Refinamiento descendente [Wirth, 1971] Evolucin hacia la programacin estructurada [Dahl et al., 1972] Transformaciones de los flujos de datos [Stevens et al., 1974] Transformaciones de la estructura de datos [Warnier, 1974], [Jackson, 1975] Diseo Orientado a Objeto (DOO) [Wirfs-Brock et al., 1990], [Gamma et al., 1995], [Buschmann et al., 1996]
Mediados de los 70s

Finales de los 80s, dcada de los 90s
Las diferentes tendencias en diseo han dado lugar a mtodos de diseo
10
2. Proceso de diseo del software

11
El proceso de diseo
El diseo es un proceso de resolucin de problemas cuyo objetivo es encontrar y describir una forma
Para implementar los requisitos funcionales del sistema Respetando las restricciones impuestas por los requisitos no funcionales
Incluyendo las presupuestarias
Ajustndose a los principios generales de calidad
El proceso de diseo es, por tanto, un proceso iterativo, mediante el cual se va a realizar una traduccin de los requisitos en una representacin del software
Diseo Informal Inicial
Diseo Informal
Diseo Ms Formal
Diseo Final
12
Diseo como toma de decisiones
El diseador se enfrenta a una coleccin de problemas de diseo
Cada problema tiene normalmente varias soluciones alternativas
Opciones de diseo
El diseador toma una decisin de diseo para resolver cada problema
Este proceso implica elegir la mejor opcin entre las alternativas
Para tomar las decisiones de diseo el ingeniero software utiliza el conocimiento que tiene de

Los requisitos El diseo realizado hasta el momento La tecnologa disponible Los principios de diseo y de las buenas prcticas Lo que ha funcionado bien en situaciones anteriores
13
Objetivos de la fase de diseo
Descomponer el sistema en subsistemas
Identificar la arquitectura software
Determinar las relaciones entre componentes
Identificar las dependencias entre componentes y determinar los mecanismos de comunicacin entre componentes
Especificar las interfaces entre los componentes
Interfaces bien definidas para facilitar la prueba y comunicacin entre los componentes
Describir la funcionalidad de los componentes

14
Actividades del proceso de diseo (i)
Segn Roger S. Pressman (1992)
Diseo preliminar
Tambin llamado diseo de sistema, diseo arquitectnico o diseo de alto
nivel
Diseo preliminar Diseo detallado

Diseo de datos
Identificar los mdulos en los que puede dividirse atendiendo a motivos de conveniencia de implementacin Se centra en la lgica interna de dichos mdulos Se ocupa del refinamiento de la representacin arquitectnica que lleva a una estructura de datos detallada y a las representaciones algortmicas del software
Diseo detallado
Vertiente Tcnica
Diseo arquitectnico Diseo procedimental Diseo de la interfaz
Hay una vertiente tcnica y una vertiente de gestin en el diseo

15
Actividades del proceso de diseo (ii)
Diseo arquitectnico
Define la relacin entre los elementos estructurales principales del software, los patrones de diseo que se pueden utilizar para lograr los requisitos que se han definido para el sistema, y las restricciones que afectan a la manera en que se pueden aplicar los patrones de diseo arquitectnicos [Shaw y Garlan, 1996] Transforma el modelo del dominio de informacin creado en el anlisis en las estructuras de datos necesarias para la implementacin del software [Pressman, 2006] Influencia de la estructura de datos en la estructura del programa y en la complejidad de los procedimientos Ocultacin de la informacin y Abstraccin Datos bien diseados conducen a

Diseo de datos
Mejor estructura del programa Modularidad efectiva Reduccin de la complejidad procedimental

16
Actividades del proceso de diseo (iii)
Principios de Wasserman (1996) para el diseo de datos
Los principios sistemticos del anlisis aplicados a la funcin y al comportamiento tambin deben aplicarse a los datos Deben identificarse todas las estructuras de datos y las operaciones que se han de realizar sobre cada una de ellas Debe establecerse y usarse un diccionario de datos para definir el diseo de los datos y del programa Deben posponerse las decisiones de datos de bajo nivel hasta el diseo detallado La representacin de una estructura de datos slo debe ser conocida por los mdulos que hagan uso directo de los datos contenidos en la estructura Se debe desarrollar una biblioteca de estructuras de datos tiles y de las operaciones que se les pueden aplicar El diseo del software y el lenguaje de programacin deben soportar la especificacin y la realizacin de tipos abstractos de datos
17
Actividades del proceso de diseo (iv)
Diseo a nivel de componentes (diseo procedimental)
Transforma los elementos estructurales de la arquitectura del software en una descripcin procedimental de los componentes del software Diseo de algoritmos Diseo de interfaces hombre-mquina para facilitar al usuario la utilizacin del sistema Propsito
Diseo de la interfaz
Recoger de los usuarios la informacin del sistema y ponerla a disposicin de otros usuarios
La interfaz cubre las entradas y las salidas
Se debe tener en cuenta la psicologa del usuario

Sobrecarga de la informacin Complejidad de la tarea Grado de control del sistema permitido al usuario
Ergonoma
Estudio de datos biolgicos y tecnolgicos aplicados a problemas de mutua adaptacin entre el hombre y la mquina [RAE, 2001]
18
Actividades del proceso de diseo (v)
Por su parte D. E. Webster (1988) y L. A. Belady (1990) hablan de
Diseo de flujo ascendente (Upstream design)
Es adaptable y abstracto y tiende a corresponderse con las fases de anlisis de requisitos y de diseo preliminar Se refiere a los mdulos, codificacin y documentacin, correspondindose con las fases de diseo detallado e implementacin
Diseo de flujo descendente (Downstream design)
19
3. Principios y conceptos del diseo del software
20
Introduccin
El comienzo de la sabidura de un programador de computadoras est en reconocer la diferencia entre obtener un programa que funcione y obtener uno que funcione correctamente M. A. Jackson (1975)
Qu criterios se pueden usar para partir el software en componentes individuales? Cmo se separan los detalles de una funcin o de la estructura de los datos de la representacin conceptual del software? Existen criterios uniformes que definen la calidad tcnica de un diseo de programas?
21
Principios del diseo del software
Los principios bsicos de diseo hacen posible que el ingeniero del software navegue por el proceso de diseo [Pressman, 2002]

En el proceso de diseo no deber utilizarse orejeras El diseo deber poderse rastrear hasta el modelo de anlisis El diseo no deber inventar nada que ya est inventado El diseo deber minimizar la distancia intelectual entre el software y el problema, como si de misma vida real se tratara El diseo deber presentar uniformidad e integracin El diseo deber estructurarse para admitir cambios El diseo deber estructurarse para degradarse poco a poco, incluso cuando se enfrenta con datos, sucesos o condiciones de operacin aberrantes El diseo no es escribir cdigo y escribir cdigo no es disear El diseo deber evaluarse en funcin de la calidad mientras que se va creando, no despus de terminarlo El diseo deber revisarse para minimizar los errores conceptuales (semnticos)
22
Conceptos del diseo
Los conceptos fundamentales del diseo del software
Proporcionan el marco de trabajo necesario para conseguir que se haga correctamente Favorecen la gestin de la complejidad de los sistemas software y la consecucin de los factores de calidad que estos sistemas han de exhibir
Los conceptos del diseo a tratar son [Pressman, 2002]
Abstraccin Refinamiento sucesivo (descomposicin) Ocultacin de la informacin Modularidad Arquitectura del software Jerarqua de control Divisin estructural Estructura de datos Procedimiento de software
23
Abstraccin (i)
Definicin
Separar por medio de una operacin intelectual las cualidades de un objeto para considerarlas aisladamente o para considerar el mismo objeto en su pura esencia o nocin [RAE, 2001] La representacin de las caractersticas esenciales de algo sin incluir antecedentes o detalles irrelevantes [Graham, 1994] La nocin psicolgica de abstraccin permite concentrarse en un problema a un nivel de generalizacin independiente de los detalles de nivel inferior; la abstraccin tambin permite trabajar con conceptos y trminos que son familiares en el entorno del problema sin tener que transformarlos en una estructura poco familiar [Wasserman, 1983]
24
Abstraccin (ii)

Los diseos han de ocultar o diferir los detalles de implementacin Las abstracciones permiten comprender la esencia de los subsistemas sin tener que conocer detalles innecesarios Las decisiones de diseo susceptibles de cambio deben ocultarse detrs de interfaces abstractas Los mdulos se han de disear de forma que la informacin interna del mdulo sea inaccesible a otros mdulos que no la necesitan
Una solucin modular implica niveles de abstraccin Define y refuerza las restricciones de acceso Facilita el mantenimiento y la evolucin de los sistemas software Reduce los efectos laterales Limita el impacto global de las decisiones de diseo locales Favorece la encapsulacin, uno de los elementos de un buen diseo
25
Ventajas

Abstraccin (iii)
Descripcin de una funcin de un programa en el nivel de detalle adecuado Cada paso en el proceso del software es un refinamiento del nivel de abstraccin de la solucin software (abstracciones funcionales y abstracciones de datos) Refinamiento y modularidad son conceptos cercanos al concepto de abstraccin Abstraccin de datos
Coleccin identificada de datos que describe un objeto de datos

Secuencia identificada de instrucciones que tiene una funcin especificada y limitada Mecanismo de control de programa sin especificar los datos internos
Abstraccin procedimental
Abstraccin de control
26
Abstraccin (iv)
Principios
Especializacin
Forma comn de la herencia, donde el objeto derivado tiene propiedades ms precisas que el objeto base Principio de separacin de una abstraccin en sus componentes Es el proceso de crear instancias de una clase
Descomposicin
Instanciacin
Individualizacin

El agrupamiento de objetos similares para propsitos comunes Un objeto de una clase dada tiene un propsito o rol dado
27
Refinamiento sucesivo (i)

Estrategia de diseo descendente El diseo se refina con una jerarqua de detalles creciente Concepto muy ligado a la abstraccin
El refinamiento es un concepto complementario a la abstraccin
Es el procedimiento por el que se va pasando de los niveles superiores de abstraccin a los niveles inferiores, es decir, la manera en que se va aadiendo informacin de un nivel a otro [Wirth, 1971]
En cada paso, una o varias instrucciones del programa dado se descomponen en instrucciones ms detalladas Refinamiento paralelo de funciones y datos Cada refinamiento implica decisiones de diseo
28
Refinamiento sucesivo (ii)
Similitud con el procedimiento de particin y refinamiento del anlisis de requisitos
La diferencia est en el nivel de detalle, no en el enfoque Funcin descrita a un nivel conceptual Refinamientos sucesivos que incorporan ms detalles
El refinamiento es un procedimiento de elaboracin

Gestiona la complejidad dividiendo problemas grandes en problemas pequeos

Permite que personas diferentes puedan trabajar con cada parte Permite la especializacin de los ingenieros del software Cada componente individual es ms pequeo y, por tanto, su comprensin es ms sencilla Las partes se pueden remplazar o cambiar sin tener que remplazar o cambiar de forma generalizada el resto de las partes
29
Refinamiento sucesivo (iii)
Proceso
1. 2.
Seleccionar un problema (inicialmente el sistema completo) Determinar los componentes de este problema o parte del problema mediante un paradigma de diseo
1.
Funcional, estructurado, orientado al objeto...
3. 4.
Describir las interacciones entre los componentes Repetir los pasos 1-3 hasta que se verifique el criterio de finalizacin
Cada pieza en el mismo nivel de detalle Cada pieza resoluble independientemente Se pueden combinar piezas para resolver el problema original
Objetivos

30
Refinamiento sucesivo (iv)
Tamao y escala
Sistema Subsistema Componentes/servicios Clases Funciones
Propsito Sistema
31
Ocultacin de la informacin (i)
Los mdulos se caracterizan por las decisiones de diseo que (cada uno) oculta al resto [Parnas, 1972]
Los mdulos debern especificarse y disearse de manera que la informacin (procedimientos y datos) que est dentro de un mdulo sea inaccesible a otros mdulos que no necesiten esa informacin
El ocultamiento de la informacin es un buen medio para conseguir abstraccin Restricciones de acceso
Detalle procedimental dentro del mdulo Estructura de datos local empleada por el mdulo
El diseador de cada mdulo debe seleccionar un subconjunto de las propiedades del mdulo como informacin oficial del mdulo, para ponerlas a disposicin de los autores de mdulos o de mdulos clientes
32
Ocultacin de la informacin (ii)
Las decisiones de diseo sujetas a cambio deben ocultarse detrs de interfaces abstractas
Las aplicaciones software han de comunicarse nicamente a travs de interfaces bien definidas La interfaz de un mdulo debe revelar lo menos posible de su funcionamiento interno Intercambio de mdulos mientras que se mantengan intactas las interfaces Ventajas a la hora de hacer cambios
Ocultacin significa que se puede conseguir una modularidad efectiva definiendo un conjunto de mdulos independientes que se comunican intercambiando la informacin necesaria para realizar la funcin software
33
Modularidad (i)
Es una particin lgica del diseo software que permite al software complejo ser manejable para propsitos de implementacin y mantenimiento Es el atributo individual del software que permite a un programa ser intelectualmente manejable [Myers, 1978] Es la propiedad que tiene un sistema que ha sido descompuesto en un conjunto de mdulos cohesivos y dbilmente acoplados [Booch, 1994] Propuesta de descomposicin funcional del sistema

Sistema dividido en subsistemas Subsistemas son repetidamente divididos hasta que son intelectual y tcnicamente manejables como unidades individuales
34
Modularidad (ii)
La modularidad facilita
Los factores de calidad del software

Extensibilidad: interfaces abstractas, bien definidas Reusabilidad: bajo acoplamiento, alta cohesin Portabilidad: oculta las dependencias mquina Mejora la separacin de aspectos Permite reducir la complejidad del sistema global mediante arquitecturas software descentralizadas Incrementa la escalabilidad mediante el soporte al desarrollo independiente y concurrente por varias personas
La calidad de los diseos software

35
Modularidad (iii)
Un mdulo es cualquier parte o subsistema de un sistema mayor

Componente bien definido de un sistema software Autnomo, auto-contenido, cohesin lgica Mdulos internos: se descomponen en otros Mdulos hojas: no se descomponen ms
Se distingue entre

Un sistema es modular si est compuesto de mdulos bien definidos, conceptualmente simples e independientes, que interactan a travs de interfaces bien definidas
36
Modularidad (iv)
Modularidad y costes de software [Pressman, 2006]

Coste total del software Coste de las interfaces
Coste o esfuerzo
Regin de mnimo coste
M
Coste/mdulo
Nmero de mdulos
37
Modularidad (v)
Los sistemas modulares son deseables por las siguientes razones
Son fciles de entender y explicar porque se puede estudiar cada mdulo por separado, y adems estos mdulos tienen bien definidas las interdependencias Al ser ms fciles de entender y explicar, son fciles de documentar Son ms fciles de programar porque grupos independientes pueden trabajar en mdulos diferentes con poca comunicacin Son ms fciles de probar porque pueden ser probados por separado, y despus integrados y probados juntos Cuando los mdulos son realmente independientes, son ms fciles de mantener. Se pueden hacer cambios en algunos mdulos sin afectar al resto del sistema Reduce la complejidad Aumenta la claridad Facilita implementacin, depuracin, pruebas, documentacin y mantenimiento del software
38
La modularidad mejora la calidad del diseo

Modularidad (vi)
Criterios de evaluacin de la modularidad [Meyer, 1997] Capacidad de la descomposicin modular Capacidad de empleo de componentes modulares Capacidad de comprensin modular Continuidad modular Proteccin modular Reglas de evaluacin de la modularidad [Meyer, 1997] Correspondencia directa Pocas interfaces Interfaces pequeas Interfaces explcitas Ocultacin de la informacin
39
Modularidad (vii)
Descomposicin
Los componentes grandes se pueden descomponer en componentes pequeos? Un mtodo de construccin de software satisface el principio de capacidad de descomposicin modular si ayuda en la tarea de descomponer un problema software en un nmero pequeo de subproblemas menos complejos, conectados por una estructura simple y lo suficientemente independiente para permitir trabajar de forma separada en cada uno de ellos

Ejemplo: Diseo descendente Contraejemplo: Mdulo de inicializacin que lo inicializa todo para todos
Composicin

Los componentes grandes se componen de componentes pequeos? Un mtodo satisface la capacidad de empleo de componentes modulares si favorece la produccin de elementos software que pueden ser libremente combinados con el resto para producir nuevos sistemas, posiblemente en un entorno algo diferente del cual fueron inicialmente desarrollados

En diferentes entornos -> componentes Ejemplo: Bibliotecas matemticas; rdenes y tuberas UNIX Contraejemplo: Preprocesadores (problemas de compatibilidad)
40
Modularidad (viii)
Comprensin

Los componentes son comprensibles individualmente? Un mtodo favorece la capacidad de comprensin modular si ayuda a producir software, en el cual un lector humano pueda entender cada mdulo sin tener que conocer el resto de los mdulos, o, en el peor de los casos, teniendo que examinar slo un conjunto reducido del resto de los mdulos

Importancia para el mantenimiento Independencia del nivel de abstraccin del mdulo La informacin relevante de un mdulo debe aparecer en el texto del mdulo
Contraejemplo: Dependencias secuenciales (A|B|C)
41
Modularidad (ix)
Continuidad
Pequeos cambios en la especificacin afectan a un nmero limitado y localizado de componentes? Los resultados de un pequeo cambio en la especificacin

Solamente cambia un nmero pequeo de mdulos No afecta a la arquitectura Ejemplos: Constante simblicas; Principio uniforme de acceso Contraejemplo: Arrays estticos
Unido a la extensibilidad del software

Proteccin
Estn los efectos de las anomalas de ejecucin confinados a un nmero pequeo de componentes relacionados? Se cumple el principio de proteccin modular cuando si se da una condicin anormal en tiempo de ejecucin dentro de un mdulo, permanecer confinada dentro de dicho mdulo, o en el peor de los casos se propagar slo a unos pocos mdulos cercanos
Ejemplo: Validacin de las entradas en la fuente Contraejemplo: Excepciones no disciplinadas
42
Modularidad (x)
Correspondencia directa (direct mapping) Debe existir una relacin consistente entre el modelo del problema y la estructura de la solucin Mantener la estructura de la solucin compatible con la estructura del dominio del problema modelado Afecta a

Continuidad: Facilita y limita el impacto del cambio Descomposicin: La descomposicin del dominio del problema es un buen punto de partida para la descomposicin del software
Interfaces pequeas
Si dos componentes se comunican, deben intercambiar la menor informacin posible Se refiere al tamao de las conexiones entre mdulos ms que a su nmero Afecta a la Continuidad y la Proteccin
43
Modularidad (xi) Interfaces explcitas
Cuando dos componentes se comunican, esto debe ser evidente en la especificacin de al menos uno de ellos Afecta a la Descomposicin, Composicin, Continuidad, Comprensin Cada componente debe comunicarse con el menor nmero posible de componentes Restringe el nmero de canales de comunicacin entre los mdulos de una arquitectura software Afecta a la Continuidad, Proteccin, Composicin, Comprensin Cada mdulo debe seleccionar un subconjunto de las propiedades del mdulo como informacin oficial del mdulo, para ponerlas a disposicin de los autores de mdulos o de mdulos clientes Afecta a Continuidad, Descomposicin, Composicin, Comprensin
44
Pocas interfaces
Ocultacin de la Informacin
Modularidad (xii)
Diseo modular efectivo
Se logra desarrollando mdulos con una funcin claramente definida y evitando una excesiva interaccin con otros mdulos Suma de la modularidad y los conceptos de abstraccin y ocultacin de la informacin [Presman, 2002] Ventajas

Mdulos ms fciles de desarrollar Mdulos ms fciles de mantener y probar Facilidad para su reutilizacin Cohesin Acoplamiento
La independencia se mide mediante dos criterios cualitativos

45
Modularidad Cohesin (i)
La cohesin es la medida de la relacin funcional de los elementos de un mdulo. Aqu un elemento hace referencia a cualquier componente del mdulo, instruccin o grupo de instrucciones, definiciones de datos, procedimientos que lleva a cabo algn trabajo o define algn dato Estudia la medida de la relacin que existe entre los elementos de un mismo mdulo Organizacin de los elementos de forma que los que tengan una mayor relacin para realizar una tarea, pertenezcan al mismo mdulo y los elementos no relacionados se encuentren en mdulos separados
Un subsistema o mdulo tiene un alto grado de cohesin si mantiene unidas cosas que estn relacionadas entre ellas y mantiene fuera el resto
Favorece la comprensin y el cambio de los sistemas Fortaleza de la asociatividad funcional de las actividades Un mdulo cohesivo lleva a cabo una sola tarea dentro de un procedimiento software
46
Modularidad Cohesin (ii)

1. 2.
3.
4.
5.
6.
7.
Buena Funcional Secuencial Comunicacin Procedural Temporal Lgica Coincidencia Mala
Caja negra
Caja gris
Caja transparente
47
Modularidad Cohesin (iii)
Cohesin funcional
Todos los elementos que componen el mdulo estn relacionados en el desarrollo de una funcin nica y perfectamente definida Devuelve un resultado sin efectos colaterales Fcil comprensin, reutilizable, fcil reemplazamiento Los elementos contribuyen a la ejecucin de una tarea relacionada con el problema Grado ms alto de cohesin Un mdulo representa el empaquetamiento fsico de varios mdulos con cohesin funcional, donde cada uno proporciona la entrada al siguiente Un servicio secuencialmente cohesivo reduce el acoplamiento encapsulando funcionalidad relacionada Varios mdulos con cohesin funcional trabajan sobre la misma estructura de datos, pero han de existir tantos puntos de entrada como nmero de funciones realice dicho mdulo Menor grado de cohesin que la cohesin funcional
48
Cohesin secuencial
Modularidad Cohesin (iv)
Cohesin de comunicacin
Todos los mdulos que acceden o manipulan ciertos datos se mantienen unidos y el resto se excluye Los elementos contribuyen en actividades que utilizan los mismos datos de entrada o de salida
Dado un ISBN como entrada a un servicio: encontrar el ttulo del libro, encontrar el precio del libro, encontrar la editorial del libro
No importa el orden en la ejecucin de las actividades Evitar la tentacin de incluir todas las actividades definidas en un servicio Si se localiza un conjunto de actividades no secuenciales actuando sobre los mismos datos es un indicador de cohesin de comunicacin
49
Modularidad Cohesin (v)
Cohesin procedural
Composicin de partes de funcionalidad que se organizan secuencialmente pero que, por otra parte, tienen poca relacin entre s Mal mantenimiento
Un mdulo que posee cohesin temporal es aqul cuyos elementos estn implicados en actividades que estn relacionadas con el tiempo Las operaciones que se realizan durante la misma fase de la ejecucin del programa se mantienen unidas Organiza actividades relacionadas de forma secuencial por tiempo Mal mantenimiento
Cohesin temporal
50
Modularidad Cohesin (vi)
Cohesin lgica
Agrupa una serie de actividades en la misma categora general
Cuando existe alguna relacin entre los elementos del mdulo, aunque sea dbil
En algunos casos puede dar lugar a confusiones por no estar bien definidas las fronteras entre los diferentes elementos del mdulo La actividad a ejecutar se determina normalmente por un parmetro de entrada Se relacionan utilidades que no se pueden ser situadas de forma lgica en otras unidades cohesivas Cuando entre los elementos que componen el mdulo no existe ninguna relacin con sentido
Cohesin por coincidencia
Procede de un programa que ya existe y que simplemente se ha dividido en mdulos Se crean mdulos con grupos de sentencias que se repiten en mismo mdulo o en mdulos diferentes. Es un intento de evitar la duplicidad de cdigo Un programa ya creado se fragmenta por alguna causa, como puede ser la limitacin de memoria
51
Modularidad Acoplamiento (i)
El acoplamiento es una medida de la interconexin entre los mdulos de una estructura de software [Pressman, 2006] El acoplamiento depende de la complejidad de la interconexin entre los mdulos, el punto donde se realiza una entrada o referencia a un mdulo y los datos que se pasan a travs de la interfaz Minimizar el acoplamiento implica un buen diseo
Un acoplamiento bajo indica un sistema bien dividido y puede conseguirse mediante la eliminacin o reduccin de relaciones innecesarias Ningn mdulo tiene que preocuparse de los detalles de la construccin interna del resto de los mdulos
52
Acoplamiento mnimo
Modularidad Acoplamiento (ii)
Se produce una situacin de acoplamiento cuando un elemento de un diseo depende de alguna forma de otro elemento del diseo El objetivo es conseguir un acoplamiento lo ms bajo posible
Conseguir que cada componente sea tan independiente como sea posible Un software ms fcil de entender Un software menos propenso al efecto ola
Una conectividad sencilla entre los mdulos da como resultado

El causado cuando los errores que se producen en un lugar del sistema se propagan por el resto del sistema
Un bajo acoplamiento significa que un cambio en un componente no implicar un cambio en otro Cuando el nivel de acoplamiento es bajo, el diseo, por regla general, se mantiene y extiende mejor
53
Modularidad Acoplamiento (iii)
El acoplamiento depende de varios factores
Referencias hechas de un componente a otro
El componente A puede invocar al componente B; por lo tanto A depende de B para completar su funcin o proceso El componente A puede pasarle a B un parmetro, el contenido de un vector secuencial o un bloque de datos El componente A puede pasar una seal de control (flag) a un componente B. El valor de la seal de control indica al componente B el estado de un recurso o subsistema, qu proceso debe invocar o si debe o no invocar alguno A pasa un parmetro a B y ste puede ejecutarse C y D intercambian valores antes de que D pueda completar su ejecucin
54
Cantidad de datos pasados de un componente a otro
El grado de control que un componente tiene sobre el otro
El grado de complejidad de la interfaz entre los componentes

Modularidad Acoplamiento (iv)
En general, los mdulos estn fuertemente acoplados si utilizan variables compartidas o intercambian informacin de control Acoplamiento dbil
Garantizar que los detalles de la representacin de datos se mantiene dentro de un componente Interfaz con otros componentes mediante lista de parmetros Si es necesario que exista informacin compartida se debe limitar a aquellos componentes que necesitan acceder a la informacin Se debe evitar informacin compartida de forma global
55
Modularidad Acoplamiento (v)

1. 2. 3. 4. 5. 6. 7.
Normal De datos Por estampado De control Externo Comn De contenido
Mejor
Bajo
Dbil
Peor
Alto
56
Modularidad Acoplamiento (vi) Niveles bajos de acoplamiento
Acoplamiento normal
Dos mdulos A y B estn normalmente acoplados s: un mdulo A llama a otro B, y B retorna el control a A Dos mdulos estn acoplados normalmente cuando no se pasan ningn parmetro entre ellos, slo existe la llamada de uno a otro
B
Obtener nivel
Acoplamiento de datos

Los mdulos se comunican mediante parmetros de usuario Cada parmetro es una unidad elemental de datos Nivel usuario Todas las E/S al y desde el mdulo llamado son argumentos de datos y no de control Leer nivel Reducir el nmero de parmetros de usuario
Acoplamiento por estampado
Dos mdulos estn acoplados por estampado si ambos hacen referencia a la misma estructura de datos Cliente No estructura de datos global Leer No es deseable si el mdulo que recibe esa estructura de datos, necesita cliente slo parte de los elementos que se le pasan
57
Obtener nombre cliente
Modularidad Acoplamiento (vii)
Niveles moderados se caracterizan por el paso de control entre mdulos
Datos
Re sultado
Acoplamiento de control

Paso de parmetros de control entre mdulos Influencia de un mdulo en la ejecucin de otro
o at
at
2
O pe
i ac
Una variable controla las decisiones en un mdulo superior o subordinado
Operar
Acoplamiento externo
Los mdulos estn ligados a un entorno externo al software. Por ejemplo la E/S acopla un mdulo a dispositivos, formatos y protocolos de comunicacin. Este acoplamiento es esencial pero deber estar limitado a unos pocos mdulos
58
Modularidad Acoplamiento (viii) Niveles altos de acoplamiento
Acoplamiento comn Los mdulos acceden a datos en un rea de datos global (un rea de memoria accesible por ejemplo). Comparten una estructura de datos global Viola los principios bsicos de encapsulamiento y modularidad El diagnostico de problemas en estructuras con acoplamiento comn es costoso en tiempo y difcil de realizar Acoplamiento de contenido Se da cuando un mdulo hace uso de datos o de informacin de control mantenidos dentro de los lmites de otro mdulo
Un mdulo modifica algn elemento en el otro mdulo Un mdulo utiliza una variable local del otro Desde un mdulo se salta a otro, pero la sentencia a la que se pasa no est definida como punto de entrada Dos mdulos comparten los mismos contenidos Inaceptable
59
Arquitectura del software (i)
La arquitectura del software alude a la estructura global del software y las formas en que esa estructura proporciona integridad conceptual a un sistema [Shaw y Garlan, 1995] La arquitectura del software es la estructura lgica y fsica de un sistema, forjada por todas las decisiones de diseo estratgicas y tcticas aplicadas durante el desarrollo [Booch, 1994] Una arquitectura software es la descripcin de los subsistemas y componentes de un sistema software y de las relaciones entre ellos. Los subsistemas y componentes se especifican habitualmente desde diferentes puntos de vista para mostrar las propiedades funcionales y no funcionales relevantes de un sistema software. La arquitectura software de un sistema es un artefacto, es el resultado de la actividad de diseo del sistema [Buschmann et al., 1996]
60
Arquitectura del software (ii)
En su forma ms simple se refiere a

La estructura jerrquica de los mdulos Sus interacciones Sus estructuras de datos Generalizacin de los componentes
En un sentido ms amplio
Elementos principales del sistema y sus interacciones
Un objetivo del diseo software es crear una versin arquitectnica de un sistema
Esta versin sirve como estructura desde la cual llevar a cabo actividades de diseo ms detalladas
Un conjunto de patrones arquitectnicos permiten que el ingeniero del software reutilice los conceptos a nivel de diseo
61
Arquitectura del software (iii)
P1 P2 P5
S1 S3
S2
P3
P4
S4
S5
Problema a resolver
Solucin software
62
Arquitectura del software (iv)
Propiedades que deberan especificarse como parte de un diseo arquitectnico [Shaw y Garlan, 1995]
Propiedades estructurales
Define los componentes de un sistema (mdulos, objetos, filtros) y la manera en que estos componentes se empaquetan e interactan unos con otros La descripcin del diseo arquitectnico deber ocuparse de cmo la arquitectura de diseo consigue los requisitos para el rendimiento, capacidad, fiabilidad, seguridad, capacidad de adaptacin y otras caractersticas del sistema El diseo arquitectnico deber dibujarse sobre patrones repetibles que se basen comnmente en el diseo de familias de sistemas similares. En esencia, el diseo deber tener la habilidad de volver a utilizar bloques de construccin arquitectnicos
63
Propiedades extra-funcionales
Familias de sistemas relacionados
Arquitectura del software (v)
El diseo arquitectnico se puede representar mediante uno o ms modelos diferentes [Garlan y Shaw, 1995]
Modelos estructurales
Representan la arquitectura como una coleccin organizada de componentes de programa Aumentan el nivel de abstraccin del diseo en un intento de identificar los marcos de trabajo (patrones) repetibles del diseo arquitectnico que se encuentran en aplicaciones similares Tratan los aspectos de comportamiento de la arquitectura del programa, indicando cmo puede cambiar la estructura o la configuracin del sistema en funcin de los acontecimientos externos
Modelos de marco de trabajo
Modelos dinmicos
Modelos de proceso
Se centran en el diseo del proceso tcnico de negocio que tiene que adaptar el sistema
Se pueden utilizar para representar la jerarqua funcional de un sistema
64
Modelos funcionales
Jerarqua de control (i)
Tambin denominada estructura de programa Representa la organizacin jerrquica de los mdulos Jerarqua de control basada en el flujo de control entre diferentes partes de un programa No presenta detalles procedimentales No se tiene que aplicar necesariamente a todos los estilos arquitectnicos La forma ms comn de representarla es mediante un grafo que represente el control jerrquico para las arquitecturas de llamada y retorno
65
Jerarqua de control (ii)

M a
Profundidad Grado de Salida
b e k l
c m
j
Anchura
Grado de Entrada
66
Divisin estructural (i)

La estructura de un programa debe partirse horizontal y verticalmente La particin horizontal define ramas separadas de la jerarqua modular para cada funcin principal del programa

Mdulos de control Enfoque entrada/proceso/salida Proporciona software ms fcil de probar Lleva a un software ms fcil de mantener Propaga menos efectos secundarios Proporciona software ms fcil de ampliar Aumenta la comunicacin entre mdulos, pudiendo complicar el control global del flujo del programa
Beneficios de la particin horizontal

Puntos en contra de la particin horizontal
67
Divisin estructural (ii)
Particin vertical o descomposicin en factores (factoring) La particin vertical expresa que el control, toma de decisiones, y el trabajo se distribuyan de forma descendente en la arquitectura del programa Los mdulos de nivel superior deben realizar funciones de control y poco trabajo de procesamiento Los mdulos que residen en la parte baja de la arquitectura deben de ser los que realicen las tareas de entrada, clculo y salida
68
Divisin estructural (iii)
Funcin 1
Funcin 3
Funcin 2
Mdulo de control
69
Divisin estructural (iv)
Mdulos de toma de decisiones
Mdulos de trabajo
Mdulo de control
70
Estructura de datos
Representacin de la relacin lgica existente entre los elementos individuales de datos La estructura de datos dicta la organizacin, los mtodos de acceso, el grado de asociatividad y las alternativas de procesamiento para la informacin Estructuras clsicas

Elemento escalar Vector secuencial Espacio n-dimensional Lista enlazada
71
Procedimiento del software
Se centra en los detalles de procesamiento de cada mdulo individual Debe proporcionar una especificacin precisa del procesamiento Existe relacin entre la estructura del programa y el procedimiento Debe incluir una referencia a todos los mdulos subordinados al mdulo que se describe
72
4. Aportaciones principales del tema

73
Aportaciones principales (i)
El diseo es una representacin significativa de ingeniera de algo que se va a construir El diseo del software es fundamental como base para un producto software de calidad El diseo del software se encuentra en el ncleo tcnico de la ingeniera del software y se aplica independientemente del modelo de diseo de software que se utilice Cada uno de los elementos del modelo de anlisis proporciona la informacin necesaria para crear los cuatro modelos de diseo que se requieren en una especificacin completa de diseo
Diseo Diseo Diseo Diseo
arquitectnico de datos procedimental de la interfaz
74
Aportaciones principales (ii)
El diseo arquitectnico define la relacin entre los elementos estructurales principales del software, los patrones de diseo que se pueden utilizar para lograr los requisitos, y las restricciones que afectan a la manera en que se pueden aplicar los patrones de diseo arquitectnico Una arquitectura del software es el producto de trabajo de desarrollo que ofrece la mayor inclinacin a invertir en lo que se refiere a calidad, planificacin y coste
75
Aportaciones principales (iii)
Importancia del diseo de la interfaz de usuario
Para muchos usuarios de sistemas de ordenador, la frustracin y la ansiedad forman parte de la vida diaria. Se esfuerzan por aprender un lenguaje de rdenes o un sistema de seleccin de mens que, se supone, les ayudar en su trabajo. Algunas personas sufren casos tan serios de shock con el ordenador, de terror al terminal o de neurosis de red, que evitan utilizar sistemas informticos (Ben Shneiderman) La simplicidad, la claridad y la comprensibilidad son las caractersticas deseadas Situacin de la informacin en pantalla de forma adecuada
Heursticas en el diseo de pantallas

Se indica como punto de partida la esquina superior izquierda de la pantalla, y se reservan reas especficas de la pantalla para diferentes tipos de informacin, proporcionando una composicin agradable a la vista Slo la informacin esencial Tipos de letra utilizar...
Seleccin de la informacin que se coloca en la pantalla
Cuidar cmo situar la informacin en la pantalla
No introducir errores Combinaciones de teclas estndar Cuidado del color

76
Aportaciones principales (iv)

El diseo no es escribir cdigo y escribir cdigo no es disear La consistencia del diseo y la uniformidad es crucial cuando se van a construir sistemas de gran tamao
Se deber establecer un conjunto de reglas de diseo para el equipo del software antes de comenzar a trabajar
Los principios del diseo cuidan que un ingeniero de software cree un diseo que muestre los factores de calidad tanto internos como externos Un sistema software ha de descomponerse en un conjunto de mdulos cohesivos y dbilmente acoplados La ocultacin de la informacin sirve para prevenir accidentes, no fraudes La ocultacin de la informacin conduce a la modularidad efectiva No se debe modularizar de ms, la simplicidad de cada mdulo se eclipsar con las complejidad de la integracin
77
Aportaciones principales (v)
La cohesin es la medida de la relacin funcional de los elementos de un mdulo El acoplamiento es una medida de la interconexin entre los mdulos de una estructura de programa Los mdulos estn fuertemente acoplados si utilizan variables compartidas o intercambian informacin de control Se debe evitar informacin compartida de forma global
No se deben usar variables globales
78
5. Cuestiones y ejercicios
79
Cuestiones y ejercicios

Estudiar el acoplamiento y la cohesin en diferentes sistemas software Aplicar un enfoque de refinamiento paso a paso para desarrollar tres niveles diferentes de abstraccin procedimental para el problema del salto del caballo Establecer la relacin existente entre el concepto de ocultacin de la informacin y el concepto de independencia modular
80
6. Lecturas complementarias
81
Lecturas complementarias
Davis, A. 201 Principles of Software Development. McGraw-Hill, 1995
Libro dedicado a los principios de diseo del software
Guttag, J. Abstract Data Types and the Development of Data Structures. Communications of the ACM, 20(6):396-404. June 1977
Artculo que sirve de repaso al concepto de tipo abstracto de dato y su utilizacin para el diseo de las estructuras de datos. Tambin es un ejemplo de la idea de que la abstraccin y el refinamiento alcanzan tanto a los procesos como a los datos de un sistema software
Parnas, D. L. On the Criteria To Be Used in Descomposing Systems into Modules. Communications of the ACM, 15(12):1053-1058. December 1972
Artculo clsico donde David Parnas enuncia su afamado principio de ocultacin de la informacin
Vienneau, R. L., Senn, R. A State of the Art Report: Software Design Methods. http://www.dacs.dtic.mil/techs/design/Design.Title.html. March 1995
Informe dedicado al estado del arte del diseo software
Wirth, N. Program Development by Stepwise Refinement. Communication of the ACM, 14(4): 221-227. April 1971
Artculo clsico donde, a travs del problema de las ocho reinas, Niklaus Wirth va aplicando el principio de refinamiento sucesivo para obtener el diseo final
82
7. Referencias
83
Referencias (i)
[AECC, 1986] Asociacin Espaola para la Calidad. Glosario de Trminos de Calidad e Ingeniera del Software. AECC, 1986 [Belady, 1990] Belady, L. A. Leonardo: The MCC Software Research Project. En Ng, P. A., Yeh, R. T. (Eds.). Modern Software Engineering: Foundations and Perspectives. Van Nostrand Reinhold, 1990 [Booch, 1994] Booch, G. Object Oriented Analysis and Design with Applications. 2nd Edition. The Benjamin/Cummings Publishing Company, 1994 [Buschmann et al., 1996] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. Pattern Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1996 [Coad y Yourdon, 1991] Coad, P., Yourdon, E. Object-Oriented Design. Yourdon Press, 1991 [Dahl et al., 1972] Dahl, O.-J., Dijkstra, E., Hoare, C. A. R. Structured Programming. Academic Press, 1972 [Dennis, 1973] Dennis, J. Modularity. En Advanced Course on Software Engineering, F. L. Bauer (Ed.). Springer-Verlag, pp. 128-192, 1973 [Gamma et al., 1995] Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995
84
Referencias (ii)
[Garlan y Shaw, 1995] Garlan, D., Shaw, M. An Introduction to Software Architecture. En Ambriola, V., Tortora, G. (Eds.), Advances in Software Engineering and Knowledge Engineering, Vol. 1. World Scientific Publishing Company, 1995 [Graham, 1994] Graham, I. Object-Oriented Methods. 2nd Edition. Addison-Wesley, 1994 [IEEE, 1999] IEEE. IEEE Software Engineering Standards Collection 1999 Edition. IEEE Computer Society Press, 1999 [Jackson, 1975] Jackson, M. A. Principles of Program Design. Academic Press, 1975 [Meyer, 1997] Meyer, B. Object Oriented Software Construction. 2nd Edition. Prentice Hall, 1997 [Myers, 1978] Myers, G. Composite/Structured Design. Van Nostrand Reinhold, 1978 [Parnas, 1972] Parnas, D. L. On the Criteria To Be Used in Descomposing Systems into Modules. Communications of the ACM, 15(12):1053-1058. December 1972 [Pressman, 1992] Pressman, R. S. Software Engineering. A Practitioners Approach. 3rd Edition. McGraw Hill, 1992 [Pressman, 2002] Pressman, R. S. Ingeniera del Software: Un Enfoque Prctico. 5 Edicin. McGraw-Hill. 2002 [Pressman, 2006] Pressman, R. S. Ingeniera del Software: Un Enfoque Prctico. 6 Edicin. McGraw-Hill. 2006
85
Referencias (iii)
[RAE, 2001] Real Academia Espaola Diccionario de la Lengua Espaola. Vigsimo segunda edicin. http://www.rae.es. [ltima vez visitado, 10-12-2007]. 2001 [Shaw y Garlan, 1995] Shaw, M., Garlan, D. Formulations and Formalisms in Software Architecture. Volume 1000-Lecture Notes in Computer Science, Springer-Verlag, 1995 [Shaw y Garlan, 1996] Shaw, M., Garlan, D. Software Architecture: Perspectives on a Emerging Discipline. Prentice-Hall, 1996 [Sommerville, 2005] Sommerville, I. Ingeniera del Software. 7 Edicin, Addison-Wesley. 2005 [Stevens, 1991] Stevens, W. P. Software Design: Concepts and Methods. Prentice Hall Intenational Ltd., 1991 [Stevens et al., 1974] Stevens, W. P., Myers G. J., Constantine, L. L. Structured Design. IBM Journal, 13(2):115-119, 1974 [Taylor, 1959] Taylor, E. S. An Interim Report on Engineering Design. Massachusetts Institute of Technology, 1959 [Warnier, 1974] Warnier, J. Logical Construction of Programs. Van Nostrand Reinhold, 1974 [Wasserman, 1983] Wasserman, A. Information Systems Design Methodology. En Software Design Techniques. P. Freeman, A. Wasserman (Eds.), 4th Edition. IEEE Computer Society Press, 1983
86
Referencias (iv)
[Wasserman, 1996] Wasserman, A. Toward a Discipline of Software Engineering. IEEE Software, 13(6):23-31. November/December 1996 [Webster, 1988] Webster, D. E. Mapping the Design Information Representation Terrain. Computer, 21(12), 8-23. December 1988 [Wirfs-Brock et al., 1990] Wirfs-Brock, R., Wilkerson, B., Wiener, L. Designing ObjectOriented Software. Prentice-Hall, 1990 [Wirth, 1971] Wirth, N. Program Development by Stepwise Refinement. Communication of the ACM, 14(4): 221-227. April 1971
87
Ingeniera del Software

Tema 5: Principios del diseo del software
Dr. Francisco Jos Garca Pealvo (fgarcia@usal.es) Miguel ngel Conde Gonzlez (mconde@usal.es) Sergio Bravo Martn (ser@usal.es)
3 I.T.I.S. Fecha de ltima modificacin: 16-10-2008
Ob l i ve er n i o t en r Ob usua de
el N iv r io a u su
l i ve er n t en u ar i o s de u vel r ni o Lee s u ar i u de
el N ivr io a u su
vel r ni Lee u ar i o us de

Tema5 Principiosdeldisenodelsoftware 1pp

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema5 Principiosdeldisenodelsoftware 1pp

Cargado por

Copyright:

Formatos disponibles

Ingeniera del Software

Tema 5: Principios del diseo del software

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Importancia del diseo en el ciclo de vida de un producto

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Diseo como actividad creativa

Creatividad Intuicin Experiencia

Del ingeniero del software

Guas Mtodos Heursticas

Del proceso de diseo

Criterios de calidad Proceso iterativo

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Definicin de diseo de software (i)

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Definicin de diseo de software (ii)

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Evolucin del diseo de software

Mediados de los 70s

Finales de los 80s, dcada de los 90s

Universidad de Salamanca Departamento de Informtica y Automtica

Las diferentes tendencias en diseo han dado lugar a mtodos de diseo

Ingeniera del Software Principios del diseo del software

2. Proceso de diseo del software

Ingeniera del Software Principios del diseo del software

Incluyendo las presupuestarias

Ajustndose a los principios generales de calidad

Diseo Informal Inicial

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Diseo como toma de decisiones

El diseador se enfrenta a una coleccin de problemas de diseo

Cada problema tiene normalmente varias soluciones alternativas

El diseador toma una decisin de diseo para resolver cada problema

Este proceso implica elegir la mejor opcin entre las alternativas

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Objetivos de la fase de diseo

Descomponer el sistema en subsistemas

Identificar la arquitectura software

Determinar las relaciones entre componentes

Especificar las interfaces entre los componentes

Describir la funcionalidad de los componentes

Universidad de Salamanca Departamento de Informtica y Automtica

Ingeniera del Software Principios del diseo del software

Actividades del proceso de diseo (i)

Segn Roger S. Pressman (1992)

Tambin llamado diseo de sistema, diseo arquitectnico o diseo de alto

Diseo preliminar Diseo detallado

Diseo arquitectnico Diseo procedimental Diseo de la interfaz

Hay una vertiente tcnica y una vertiente de gestin en el diseo