Transcript iii el diseño estructurado

Diseño
I.- INTRODUCCION
II.- EL DISEÑO EN GENERAL
1.- ANTECEDENTES
2.- ESTIMACIONES BRAINSTORMING
III.- DISEÑO ESTRUCTURADO
1.2.3.4.5.-
INTRODUCCION
DIAGRAMAS DE ESTRUCTURA
CONVERSIÓN DE DFD EN DIAGRAMA DE ESTRUCTURA
MODULARIZACIÓN
CRITERIOS DE DESCOMPOSICION MODULAR
5.1.- Clausura
5.2.- Independencia
5.2.1.- Acoplamiento
5.2.2.- Cohesión
6.- DISEÑO DE LA INTERFAZ ENTRE DOS MODULOS
IV.- METRICAS DE DISEÑO
V.- DISEÑO ORIENTADO A OBJETOS
Inacap
Ingeniería de Software,
Diapositiva 1
INTRODUCCIÓN
PRINCIPIOS DE DISEÑO
1.
Los Datos y los algoritmos que los manipulan deben crearse como un
conjunto de abstracciones interrelacionadas.
2.
Los detalles internos del diseño de las estructuras de datos y los
algoritmos deben ocultarse de otros componentes software que hacen
uso de dichas estructuras de datos o algoritmos.
3.
Los módulos deben exhibir independencia.
4.
Los algoritmos deben diseñarse utilizando un conjunto restringido de
constructores lógicos.
Inacap
Ingeniería de Software,
Diapositiva 2
INTRODUCCIÓN
Actividades del Diseño de Software
Inacap
Ingeniería de Software,
Diapositiva 3
II EL DISEÑO EN GENERAL




Inacap
El diseño de los datos traduce el modelo de datos creado durante el
análisis a estructuras de datos que satisfacen las necesidades del
problema
El diseño de la arquitectura va a depender del punto de vista o
enfoque del diseñador: por ejemplo, en un diseño convencional se
creará una arquitectura jerárquica, mientras que en un enfoque
orientado al objeto, se creará una red de mensajes que permite la
comunicación entre los objetos.
El diseño de la interfaz crea un modelo de implementación para la
interfaz humano-computador, las interfaces externas del sistema que
le permiten interactuar con otras aplicaciones, y las interfaces internas
que permiten a los datos ser comunicados a través de los
componentes del software.
El diseño procedural define algoritmos para implementar los
requerimientos de procesamiento de los componentes del software.
Ingeniería de Software,
Diapositiva 4
II EL DISEÑO EN GENERAL
1.- ANTECEDENTES
El diseño es un proceso iterativo cuyo resultado es la
especificación de un sistema físico que cumpla con los
requerimientos

Existen diversas técnicas básicas:
•
•
•

y técnicas complementarias
•
•
Inacap
DISEÑO ESTRUCTURADO
DISEÑO INCREMENTAL O EVOLUTIVO
DISEÑO ORIENTADO A OBJETOS
CONTROL DE CALIDAD DEL DISEÑO
ESTIMACION DE COSTOS DE DISEÑO
Ingeniería de Software,
Diapositiva 5
III EL DISEÑO ESTRUCTURADO
1.- INTRODUCCIÓN
La técnica consiste básicamente en la conversión sistemática de
los DFD en Diagramas de estructura
2.- OBJETIVOS
 Reducir la complejidad de un sistema a través de la técnica de
Modularización de sus funciones
 Abaratar los costos de construcción a través de la Reutilización de
Módulos
 Disminuir los costos de construcción a través de:
•
•
•
•
Inacap
diseños simples de comprender
Flexibles a cambios
eficientes en su operación
fáciles de construir
Ingeniería de Software,
Diapositiva 6
III EL DISEÑO ESTRUCTURADO
La técnica utiliza criterios de evaluación de la calidad del
diseño respecto del problema que se desea resolver.
La técnica se apoya en notaciones gráficas - los diagramas de
estructura - y en pseudocódigo.
Inacap
Ingeniería de Software,
Diapositiva 7
III EL DISEÑO ESTRUCTURADO
3.- DIAGRAMAS DE ESTRUCTURA
A
B
B
MODULO
MODULO PREDEFINIDO
A
X,Y Z
A
El modulo B hace referencia a Datos en el A
El modulo A llama al modulo B y pasa los parámetros
X;Y de A a B. El modulo B remite el parámetro Z al
modulo B
B
A
B
Inacap
El modulo A llama a los módulos B y C.
Los módulos se colocan de izquierda a derecha
en orden de invocación.
B
Ingeniería de Software,
Diapositiva 8
III EL DISEÑO ESTRUCTURADO
4.- MODULARIZACIÓN
El MODULO es el componente básico de un sistema
estructurado

Se puede concebir como un subprograma con una interfaz a través de
la cual se comunica con otros subprogramas
•
Ejemplos
»
»
»
»
Inacap
Un programa compilado separadamente
Una rutina fortran
Un subprograma en C o C++
Un subprograma o unidad en PASCAL
Ingeniería de Software,
Diapositiva 9
III EL DISEÑO ESTRUCTURADO
4.1.- TECNICA DE DISEÑO ESTRUCTURADO

Se particiona el sistema en una jerarquía de módulos o subsistemas
que pueden concebirse y construirse en forma independiente (pueden
verse como cajas negras
La idea es que otros módulos sólo necesiten saber QUE hace un
determinado módulo - su función- y no COMO lo hace.

Ventajas
•
•
•
Inacap
Simplifica la construcción, ya que las decisiones internas son propias al
módulo y no dependen de otros módulos
simplifica las pruebas como unidad independiente, ya que se han reducido los
efectos laterales y es más fácil identificar la fuente de error.
Simplifica la mantención, especialmente si hay suficiente independencia de
otros módulos.
Ingeniería de Software,
Diapositiva 10
III EL DISEÑO ESTRUCTURADO
5.- CRITERIOS DE DESCOMPOSICIÓN MODULAR
Las propiedades que deben preservarse al descomponer un sistema en
módulos son:



un módulo es una unidad auto contenida
puede probarse en forma separada
puede conectarse con otros módulos sólo a través de su interfaz
5.1.- Clausura
Cada módulo debiera realizar una tarea que constituya una
unidad lógica, debiera ser lo más conciso posible, englobando
un solo concepto.
Inacap
Ingeniería de Software,
Diapositiva 11
III EL DISEÑO ESTRUCTURADO
5.2.- Independencia
Se busca maximizar la independencia inter módulos en base a un bajo
acoplamiento y una Alta cohesión
El ACOPLAMIENTO es una medida de qué tan estrecha es la
conexión o interrelación entre 2 módulos.
La COHESIÓN es una medida de la interrelación entre las
funciones que contienen un módulo
Inacap
Ingeniería de Software,
Diapositiva 12
III EL DISEÑO ESTRUCTURADO
5.2.1.- Acoplamiento
una conexión es una referencia a un objeto o proceso definido en otro
módulo:

al minimizar las conexiones entre módulos, también se minimizan las
trayectorias a lo largo de las cuales se propagan los errores y os
cambios.
La propagación de un error o de un cambio, a través de una conexión,
provoca efectos de amplificación, propiciando la aparición de nuevos
errores.

Inacap
Con conexiones simples es más fácil entender módulos sin hacer
referencia a otros
Ingeniería de Software,
Diapositiva 13
III EL DISEÑO ESTRUCTURADO

Un alto grado de acoplamiento complica la mantención de un módulo
ya que debe ser corregido y probado con referencia a los módulos
conectados
Ejemplo:
si saca el módulo X del sistema para hacerle mantención
¿qué otras partes del sistema podrán seguir funcionando?
Factores que afectan el grado de acoplamiento
El grado de acoplamiento de mide en tres dimensiones
1.- tamaño de la conexión
2.- Tipo de conexión
3.- qué es lo une se envía y recibe
Inacap
Ingeniería de Software,
Diapositiva 14
III EL DISEÑO ESTRUCTURADO
1.- tamaño de la conexión
 Entre menos datos se pasen entre módulos, menor será el grado de
acoplamiento

La medida es la cantidad de datos pasados cada vez que se usa la
interfaz
Se recomienda NO pasar los datos armados dentro de una
estructura, sino que pasarlos individualmente como
parámetros, para así aumentar la claridad.
Típicamente, una interfaz debiera tener 5 +- 2 parámetros
Inacap
Ingeniería de Software,
Diapositiva 15
III EL DISEÑO ESTRUCTURADO
2.- Tipo de conexión
 Si un módulo hace referencia a una variable que está definida en otro
módulo, entonces el contenido de ese otro módulo deberá tomarse en
cuenta al hacer un cambio o corregir un error.

Un sistema es más simple si sus módulos pueden usarse sin necesidad
de conocer su interior.
3.- Qué es lo que se comunica
 Los módulos por lo menos deberán pasarse datos entre sí para que
formen parte de un mismo sistema

Cuando se pasa información de control de un módulo a otro (switch,
flags, etc.) se agrega complejidad al sistema
(Siempre existirá una estructura alterna que elimine esa complejidad)
Inacap
Ingeniería de Software,
Diapositiva 16
III EL DISEÑO ESTRUCTURADO
Caracterización de las comunicaciones. En orden creciente de fuente de
problemas
Acoplamiento por datos
Es inevitable pero controlable si se da a través de un número mínimo de
parámetros en que se pasan tipos de datos básicos y no estructuras
complejas o registros
Ejemplo
CALCULO DE
LA FACTURA
Monto
Plazo
Valor
CALCULO DEL
CREDITO
Inacap
Ingeniería de Software,
Diapositiva 17
III EL DISEÑO ESTRUCTURADO
Acoplamiento por registros
Se da cuando dos o más comparten registros de datos entre si.

Puede darse conexiones entre módulos que de otra forma no tendrían
relación entre sí.
Ej. A través de los campos de un registro compartido


Inacap
La mantención del registro debe hacerse en consideración a todos los
módulos que lo comparten.
Además, este acoplamiento puede exponer más datos que los
necesarios a un módulo, con posibles consecuencias negativas.
Ingeniería de Software,
Diapositiva 18
III EL DISEÑO ESTRUCTURADO
Acoplamiento por control




Se da cuando un módulo intenta alterar el control de la lógica de otro
módulo
es un tipo de acoplamiento potencialmente problemático
Suele darse a través de switches o flags de control
En estos casos, el módulo llamado no es visto como una caja negra
sino que parte de su funcionamiento interno se hace visible y
modificable
COBOL : Perform A through B Varying ...until
(ALTER: excomulgado y proscrito)
Inacap
Ingeniería de Software,
Diapositiva 19
III EL DISEÑO ESTRUCTURADO
Acoplamiento por áreas de datos comunes
Se da cuando dos módulos hacen referencia a una misma zona
de datos
Problemas
 los datos no se aislan en torno a la función que los utiliza sino que son
susceptibles de ser alterados por todas las partes que los visualizan
 Las áreas de datos comunes son susceptibles de ser mal utilizadas
durante la programación.

Inacap
Ejemplo: definir variables globales de propósito múltiple como
switch-1 o Flag-1 para almacenar datos intermedios de funciones
totalmente ajenas entre sí.
Los programas con grandes áreas de datos comunes son más difíciles
de mantener, ya que es necesario distinguir que dato se utiliza porqué
módulo
Ingeniería de Software,
Diapositiva 20
III EL DISEÑO ESTRUCTURADO
5.2.2.- cohesión

Medida de la interrelación entre las funciones que contiene un
módulo, o bien la medida de la fuerza de la asociación funcional entre
los elementos de un módulo (instrucción, grupo de instrucciones o
llamadas a otros módulos)
Se desea que los módulos tengan ALTA cohesión.
La cohesión es complementaria al acoplamiento y también
determina la manera en que se particionan los módulos y su
nivel de interdependencia
Inacap
Ingeniería de Software,
Diapositiva 21
III EL DISEÑO ESTRUCTURADO
Escala de cohesión, de peor a mejor o de menor a mayor
Cohesión Coincidental


Los elementos del módulo contribuyen a actividades que no están
relacionadas entre sí.
Se da cuando se pregunta por qué un grupo de instrucciones están en
un programa y la respuesta es: “por que tenían que estar en algún
lugar”
Ejemplo Modulo DeTodoUnPoco
Listar errores
Llenar formularios
Listar cambios
Ordenar resultados
Cambiar Fecha

Inacap
Para realizar alguna de estas funciones, típicamente se utiliza algún
flag o switch, es decir, se provoca acoplamiento por control
Ingeniería de Software,
Diapositiva 22
III EL DISEÑO ESTRUCTURADO
Cohesión Temporal
Estos módulos se caracterizan porque sus elementos se relacionan con
actividades relacionadas en el tiempo

Normalmente, todos sus elementos se ejecutan en cada llamada al
módulo.
Ejemplo Modulo TodoDeUnViaje
Abrir Archivo Maestro
Poner contador-maestro en cero
Abrir archivo Cambios
Poner Contador-maestro en cero
Abrir archivo Errores
Poner Contador-maestro en cero
Inacap
Ingeniería de Software,
Diapositiva 23
III EL DISEÑO ESTRUCTURADO

También se utilizan flags de control para ocupar alguna de estas
funciones, especialmente si alguna o varias de ellas se deben reutilizar en
otro momento del proceso
Los siguientes tipos de cohesión son considerablemente mas fuertes que
las anteriores.
Inacap
Ingeniería de Software,
Diapositiva 24
III EL DISEÑO ESTRUCTURADO
Cohesión Procedural
Los elementos participan de actividades diferentes y posiblemente no
relacionadas, en las cuales el control fluye de una actividad a la
siguiente.
Lo que relaciona los componentes es el orden de ejecución y no el hecho de
ser elementos funcionalmente relacionados
Ejemplo Modulo UnoTrasOtro
Mientras existan datos
Leer orden
procesar orden
Inacap
Ingeniería de Software,
Diapositiva 25
III EL DISEÑO ESTRUCTURADO
Cohesión Por Comunicación

Los elementos del módulo se refieren a los mismos datos de entrada y
salida.
Ejemplo Producción de gráficos o de informes a partir de los mismos datos
de entrada y salida
Cohesión secuencial

Ocurre cuando la salida de un elemento es usada como entrada para el
siguiente elemento
Ejemplo leer y editar datos, crear y almacenar registros, resumir e imprimir
resultados
Modulo Secuencia
leer datos cliente; validar datos del cliente; Imprimir errores
Inacap
Ingeniería de Software,
Diapositiva 26
III EL DISEÑO ESTRUCTURADO
Cohesión Funcional
Una función describe la transformación de datos de entrada en datos de
salida


Si todos los elementos de un módulo contribuyen a un mismo objetivo
posiblemente el módulo está ligado funcionalmente
Todos los elementos del módulo son esenciales para realizar la función
del módulo
Una técnica útil para saber si un módulo tiene cohesión funcional
es describir su función y examinar la oración resultante

Inacap
Si la oración resultante contiene más de un verbo probablemente el
módulo desempeñe más de una función
Ingeniería de Software,
Diapositiva 27
III EL DISEÑO ESTRUCTURADO



Si tiene palabras que tengan que ver con tiempo (primero, siguiente,
cuando, inicio, etc) probablemente el módulo tenga cohesión secuencial
o temporal
Si el predicado no contiene un solo objeto específico, probablemente hay
cohesión lógica.
Palabras como inicializar, limpiar, etc. Implican cohesión temporal
Los módulos con cohesión funcional siempre pueden describirse en
términos de sus elementos utilizando una oración
Inacap
Ingeniería de Software,
Diapositiva 28
III EL DISEÑO ESTRUCTURADO
6.- DISEÑO DE LA INTERFAZ ENTRE MÓDULOS
1.- Minimalidad en la Interfaz
La interfaz entre 2 módulos es el conjunto de supuestos que
cada uno puede hacer del otro
Ej.: supuestos acerca de los datos que se usan
Las interfaces debieran ser lo más simples posibles, con un
mínimo de parámetros
Inacap
Ingeniería de Software,
Diapositiva 29
III EL DISEÑO ESTRUCTURADO
2.- Independencia de la interfaz
Un módulo debiera poder reemplazarse por otro ofrezca la
misma definición de la interfaz, sin producir efectos nuevos
en el resto del sistema.
3.- Número de Parámetros
El número de otros módulos que debe importar un cierto módulo
debe ser considerado.
 Un número grande de parámetros puede indicar que el módulo debe
realizar muchas actividades de coordinación y decisión

Inacap
Si los parámetros son pocos, es posible que se requiera una mayor
descomposición del problema
Ingeniería de Software,
Diapositiva 30
IV METRICAS DE DISEÑO
1.- INTRODUCCIÓN
Durante el diseño se registra.
 Módulos : cantidad
 Defectos : Número y tipo durante inspecciones; costo de repararlos
 Fuerza de trabajo : número y tipo de personas requeridas en cada
módulo; tiempo requerido
PRIMERA APROXIMACIÓN, en general, cada módulo tiene entre 2 y 7
módulos subordinados
 Si un módulo tiene 1 solo subordinado es posible que se haya extraído
una función (importante o larga) del módulo => baja cohesión
 Si un módulo tiene muchos subordinados, es posible que, en esa
etapa, el diseño haya sido efectuado hasta un nivel muy bajo
Inacap
Ingeniería de Software,
Diapositiva 31
IV METRICAS DE DISEÑO
2.- ENFOQUE CUANTITATIVO
Utilización de herramientas para analizar diseños:
Premisa: en un buen diseño las unidades individuales están aisladas unas
de otras
Por lo tanto:
Se considera la modularidad y el acoplamiento como bases de un
sistema de métricas de complejidad de diseño
Inacap
Ingeniería de Software,
Diapositiva 32
V.- DISEÑO ORIENTADO A OBJETOS

Objeto
• Dentro del software orientado a objeto, un objeto es cualquier cosa,
real o abstracta, acerca de la cual almacenamos datos y los métodos
que controlan dichos datos.
•
Inacap
Un objeto puede estar compuesto por otros objetos. Estos últimos a
su vez también pueden estar compuestos por otros objetos. Esta
intrincada estructura es la que permite construir objetos muy
complejos.
Ingeniería de Software,
Diapositiva 33
V.- DISEÑO ORIENTADO A OBJETOS

Tipo de Objeto
• Los conceptos que poseemos se aplican a tipos determinados de
objetos. Por ejemplo, empleado se aplica a los objetos que son
personas empleadas por alguna organización. Algunas instancias de
empleado podrían ser Juan Pérez, José Martínez, etc. En el análisis
orientado a objetos, estos conceptos se llaman tipos de objetos; las
instancias se llaman objetos.
•
Inacap
Así, un tipo de objeto es una categoría de objeto, mientras que un
objeto es una instancia de un tipo de objeto.
Ingeniería de Software,
Diapositiva 34
V.- DISEÑO ORIENTADO A OBJETOS

Métodos
• Los métodos especifican la forma en que se controlan los datos
de un objeto. Los métodos en un tipo de objeto sólo hacen
referencia a la estructura de datos de ese tipo de objeto. No deben
tener acceso directo a las estructuras de datos de otros objetos.
Para utilizar la estructura de datos de otro objeto, deben enviar un
mensaje a éste. El tipo de objeto empaca juntos los tipos de datos
y su comportamiento.
•
Inacap
Un objeto entonces es una cosa cuyas propiedades están
representadas por tipos de datos y su comportamiento por
métodos.
Ingeniería de Software,
Diapositiva 35
V.- DISEÑO ORIENTADO A OBJETOS

Inacap
Encapsulado
•
El encapsulado oculta los detalles de su implantación interna a
los usuarios de un objeto. Los usuarios se dan cuenta de las
operaciones que puede solicitar del objeto, pero desconocen los
detalles de cómo se lleva a cabo la operación. Todos los detalles
específicos de los datos del objeto y la codificación de sus
operaciones están fuera del alcance del usuario.
•
Así, encapsulado es el resultado (o acto) de ocultar los detalles
de implantación de un objeto respecto de su usuario.
•
El encapsulado, al separar el comportamiento del objeto de su
implantación, permite la modificación de ésta sin que se tengan
que modificar las aplicaciones que lo utilizan.
Ingeniería de Software,
Diapositiva 36
V.- DISEÑO ORIENTADO A OBJETOS
Inacap
Ingeniería de Software,
Diapositiva 37
V.- DISEÑO ORIENTADO A OBJETOS

Inacap
Mensajes
•
Para que un objeto haga algo, le enviamos una solicitud. Esta
hace que se produzca una operación. La operación ejecuta el
método apropiado y, de manera opcional, produce una
respuesta. El mensaje que constituye la solicitud contiene el
nombre del objeto, el nombre de una operación y, a veces, un
grupo de parámetros.
•
Los objetos pueden ser muy complejos, puesto que pueden
contener muchos subobjetos, éstos a su vez pueden contener
otros, etc. La persona que utilice el objeto no tiene que conocer
su complejidad interna, sino la forma de comunicarse con él y
la forma en que responde.
Ingeniería de Software,
Diapositiva 38
V.- DISEÑO ORIENTADO A OBJETOS
Inacap
Ingeniería de Software,
Diapositiva 39
V.- DISEÑO ORIENTADO A OBJETOS

Inacap
Clase
•
El término clase se refiere a la implantación en software de un
tipo de objeto.
•
El tipo de objeto es una noción de concepto. Especifica una
familia de objetos sin estipular la forma en que se implanten.
Los tipos de objetos se especifican durante el análisis OO.
•
Así, una clase es una implantación de un tipo de objeto.
Especifica una estructura de datos y los métodos operativos
permisibles que se aplican a cada uno de sus objetos.
Ingeniería de Software,
Diapositiva 40
V.- DISEÑO ORIENTADO A OBJETOS

Inacap
Herencia
•
Un tipo de objeto de alto nivel puede especializarse en tipos de
objeto de bajo nivel. Un tipo de objeto puede tener subtipos.
Por ejemplo, el tipo de objeto persona puede tener subtipos
estudiante y empleado. A su vez, el tipo de objeto estudiante
puede tener como subtipo estudiante de pregrado y estudiante
de postgrado, mientras que empleado puede tener como subtipo
a académico y administrativo. Existe de este modo una
jerarquía de tipos, subtipos, subsubtipos, etc.
•
Una clase implanta el tipo de objeto. Una subclase hereda
propiedades de su clase padre; una sub-subclase hereda
propiedades de las subclases; etc. Una subclase puede heredar
la estructura de datos y los métodos, o algunos de los métodos,
de su superclase. También tiene sus métodos e incluso tipos de
datos propios.
Ingeniería de Software,
Diapositiva 41