Clase 1

Diseo e Implementacin
Introduccin
Departamento de Informtica
Universidad Tcnica Federico Santa Mara
Introduccin
La Ingeniera del diseo abarca un conjunto de
principios, conceptos y prcticas que conducen al
desarrollo de un sistema o producto de calidad.
Los principios del diseo establecen una filosofa
primordial que guan al diseador en el
desempeo de su trabajo.
Es necesario comprender estos principios y
conceptos antes de que se apliquen las
mecnicas de la prctica del diseo.
Pedro Francisco Godoy Barrera

Anlisis e implementacin de Sistemas
Principios del Diseo
Principios del diseo

El modelado del diseo del SW comienza con la
representacin de la totalidad del objeto que ser
construido y con lentitud se refina hasta proporcionar una
gua para construir cada detalle, proporcionando
diferentes vistas del sistema.
No hay pocos mtodos para derivar los diferentes
elementos de un diseo de SW.
Mtodos que se guan de los datos arquitectura del SW
y los componentes de procesamiento resultante.
Patrn al utilizar la informacin acerca del dominio del
problema estilos arquitectnicos y patrones de
procesamiento.
Orientados a Objetos creacin de estructuras de datos
y los mtodos para manipularlos.
Principios del diseo

1. Diseos rastreables hasta el modelo de anlisis.
2. Antes de disear considerar la arquitectura
3. Diseo de datos es tan importante como el de
funciones.
4. Disear con cuidado las interfaces int-externa.
5. Considerar al usuario en el diseo de Interfaz
6. Diseo al nivel de componente diferentes al
funcional.
7. Bajo acoplamiento, vinculado a ambiente externo
8. Representacin comprensible por todos
9. Diseo iterativo, buscando la calidad y simplicidad
1.- El diseo debe ser rastreable hasta

el modelo de anlisis
El anlisis describe:
El dominio de la informacin del problema

Las funciones visibles para el usuario
El comportamiento del sistema
Y un conjunto de clases de anlisis
El Diseo traduce esta informacin a una arquitectura

Un conjunto de subsistemas que implementan las funciones
ms importantes y un conjunto de diseos al nivel de
componentes que son la realizacin de las clases de anlisis.
Excepto el modelo asociado a la infraestructura de SW,

todos los elementos del diseo deben ser mapeados al
modelo de anlisis
2.- Siempre se debe considerar la

arquitectura del sistema que se va a construir
La arquitectura del SW es el esqueleto del

sistema. Esta afecta:
Las interfaces
La estructura de datos
El flujo y comportamiento de control del programa
La manera en que se realizarn las pruebas
Facilidad de mantenimiento del sistema resultante
Por esas razones el diseo debe iniciarse con las

consideraciones del diseo arquitectnico.
Slo despus de haberse establecido la
arquitectura, se pueden considerar aspectos a
nivel de componentes.
3.- El diseo de datos es tan importante como

el diseo de funciones de procesamiento
Un diseo de datos bien estructurado ayuda a

simplificar el flujo del programa.
Facilita el diseo e implementacin de los
componentes del SW y confiere ms eficiencia al
procesamiento en general
Por lo tanto no se puede dejar a la suerte la
manera en que se realizan los objetos de los
datos dentro del sistema.

4.- Las interfaces (interna y externas)

deben disearse con cuidado
La manera en la que fluyen los datos entre los

componentes de un sistema tiene mucho que ver
con:
La eficiencia del procesamiento
La propagacin del error
La simplicidad del diseo
Una interfaz bien diseada facilita la integracin y

ayuda a quien realiza la prueba de validar
funciones de componentes.

5.- El diseo de la interfaz del usuario debe

ajustarse a la necesidad del usuario final
Hay que resaltar la facilidad de uso.

La interfaz del usuario es la manifestacin visible
del SW, no importa:
Que tan sofisticadas sean las funciones internas
Que tan comprensibles sean las estructuras de
datos
Que tan bien diseada est su arquitectura
Si el diseo de la interfaz es pobre conduce a la

percepcin de que el SW est mal hecho

6.- El diseo a nivel de componentes debe

ser independiente del modo funcional
La independencia funcional componente de

SW Sencillo.
La funcionalidad que entrega un componente
debe ser cohesiva, es decir, debe centrarse en
una y slo una funcin o subfuncin.

7.- Los componentes deben estar acoplados entre si

en forma mnima y vinculados con el ambiente
externo
El acoplamiento se consigue de las siguientes

formas:
Va interfaz de componentes
Por mensajes
A travs de datos globales.
A mayor acoplamiento:
Mayor es la probabilidad de propagacin del error
Menor facilidad de mantenimiento general del SW

8.- La representaciones del diseo deben

ser fcilmente comprensibles
El propsito del diseo es comunicar informacin

a los profesionales que:
Generarn cdigos
Probarn el SW
Mantengan el SW en el futuro.
Por lo tanto si el diseo es difcil de entender, no

servir como un medio efectivo de comunicacin

9.- El diseo debe desarrollarse de manera iterativa.

En cada iteracin el diseador debe buscar mayor
simplicidad.
Cmo es casi todas las actividades creativas, el

diseo ocurre de modo iterativo.
Las primeras iteraciones sirven para refinar el
diseo y corregir errores, pero las iteraciones
posteriores deben buscar que el diseo sea tan
simple como sea posible.

Factores de calidad
Cuando se aplican estos principios de manera apropiada,
el ingeniero de SW crea un diseo que muestra los
factores internos y externos de calidad.
Los factores externos son aquellos que los usuarios
pueden
observar
fcilmente
(como
velocidad,
confiabilidad, correccin, facilidad de uso).
Los factores internos son importante para los Ing de SW,
ya que conducen a un diseo de alta calidad desde una
perspectiva tcnica
Lograr factores de calidad internos requiere que el
diseador entienda conceptos bsicos de diseo.

Caractersticas de un buen SW
Un buen SW debe cumplir con lo siguiente:
Firmeza: El programa no debe tener ningn error
que inhiba su funcin.
Comodidad: Un programa debe cumplir con los
propsitos para los cuales fue creado.
Placer: La experiencia de usar el programa debe
ser agradable

Para lograr diseos de calidad, el diseador debe practicar

la diversificacin y la convergencia.
Diversificacin: es la adquisicin de un repertorio de
alternativas, la materia prima del diseo: componentes,
soluciones de componentes y conocimiento todo
contenido en catlogos, libros de texto y en la mente.
Convergencia: una vez que se ha integrado todo la
informacin de las alternativas el diseador debe elegir y
tomar elementos del repertorio que cumplan con los
requisitos y el modelo de anlisis. Con esto se consideran
y rechazan las alternativas y se converge a una
configuracin en particular y por lo tanto a un producto
final.
Un buen diseo es clave para la prctica efectiva

de cualquier disciplina de la ingeniera
No es posible formalizar el proceso de diseo,
debido al carcter de creativo que debe
practicarse.
Este proceso se aprende por medio de la
experiencia y el estudio de sistemas existentes.

Proceso de diseo
Etapas para atacar cualquier proceso

de diseo
Identificar y entender el problema desde distintos

puntos de vista.
Identificar las caractersticas fundamentales de
algunas posibles soluciones y evaluarlas sobre la
experiencia del diseador, la disponibilidad de
componentes reusables y la simplicidad del
producto derivado.
Describir y analizar en detalle cada abstraccin
usada en la solucin elegida, con el propsito de
encontrar y corregir errores, omisiones, etc.
Rol del diseo dentro del proceso de

desarrollo de SW
El proceso de diseo se desarrolla iterativamente

a travs de varias versiones diferentes, en las que
se van agregando correcciones, formalidad y
detalle a las versiones anteriores.
Como resultado se tienen varios modelos del
sistema de distintos niveles de abstraccin.
Se considera el ncleo tcnico.
Una vez que se analizan y se especifican los
requerimientos, el diseo del SW es la ltima
accin de la ingeniera de SW dentro de la
actividad de modelado, la cual establece una
plataforma para la construccin
Modelo general para el proceso de diseo

Modelo general para el proceso de diseo
No hay lmites rgidos entre las actividades, pero

identificarlas le da visibilidad al proceso facilitando
su gestin.
El resultado de cada actividad es una
especificacin de algn tipo
El resultado final es una especificacin precisa de
los algoritmos y estructuras de datos que deben
implementarse.
Las actividades aparecen como secuenciales,
pero en la prctica pueden proceder en paralelo.

Las actividades del proceso de diseo son
Diseo Arquitectnico: Se identifican y

documentan los subsistemas que componen el
sistema y sus relaciones.
Especificacin Abstracta: se especifican los
servicios que proveen cada uno de los
subsistemas y las restricciones bajo las cuales
operan.
Diseo de Interfaces: Se disean y documentan
las interfaces de cada subsistema (con c/u de los
otros subsistemas). De manera de permitir que
puedan ser usados sin conocimientos de cmo
operan.
Las actividades del proceso de diseo son
Diseo de componentes: Se completan las

especificaciones y los diseos no detallados de
cada subsistema. Transforma los elementos
estructurales de la arquitectura del SW en una
descripcin procedimental de los componentes de
ste.
Diseo de estructuras de datos: Se especifican
y disean detalladamente las estructuras de datos
del sistema.
Diseo de algoritmos: Se especifican y disean
los algoritmos del sistema.
Normalmente se hacen distinciones entre un

diseo de alto nivel y un detallado.
El diseo de alto nivel considera el diseo
arquitectnico, la especificacin abstracta, el
diseo de la interfaz y el diseo de componentes.
El diseo detallado abarca el diseo de las
estructuras de datos y el de los algoritmos.

Productos del proceso de diseo

Los productos se usan como la base sobre la cual
se implementa el sistema.
Sirven como medio de comunicacin entre las
personas involucradas en el desarrollo del
sistema.
Dan informacin al equipo de mantencin del
mismo.

Notaciones que se usan en los documentos

de diseo de SW
Texto informal: permite expresar la racionalidad

del diseo, consideraciones no funcionales, etc.
Lenguajes (textuales) para la descripcin de
programas (PDL): combinan construcciones
formales de estructuracin y control, similares a
las de los lenguajes de programacin, con textos
explicativos.
Lenguajes grficos: apropiados para mostrar
relaciones entre componentes y para relacionar el
diseo con el sistema que se est modelando
Importancia del Diseo
Importancia del Diseo

Calidad
El diseo es la etapa en la que se fomentar la calidad en la
ingeniera de SW
El diseo es la nica forma en que, de manera exacta, un

requisito del cliente se puede convertir en un sistema o
producto de SW.
Sin diseo se corre el riesgo de:
Construir un sistema inestable, el cual fallar cuando se
realicen cambios pequeos.
Sistema difcil de probar
Su calidad no podr evaluarse sino hasta etapas tardas del
proceso de SW, cuando queda poco tiempo y ya se ha
gastado mucho dinero en l. (Anlisis de factibilidad).
Proceso y Calidad del Diseo

El diseo se representa en un grado alto de
abstraccin, el cual puede rastrearse de manera
directa hasta conseguir:
El objetivo especfico del sistema
Requisitos ms detallados de
funcionales y de datos
comportamiento
A medida que ocurren las iteraciones del diseo, un

refinamiento conduce a representaciones del diseo a
grados mucho ms bajos de abstraccin.
Estos grados an se pueden rastrear hasta los
requisitos, pero la conexin es ms sutil.
Proceso y Calidad del Diseo

Tcnicas formales para evaluar la calidad del proceso
de diseo.
McGlaughlin sugiere 3 caractersticas que sirven
como gua de evaluacin:
El diseo debe implementar todos los requisitos explcitos
contenidos en el modelo de anlisis, y debe ajustarse a
todos los requisitos implcitos que desea el cliente.
El diseo debe ser una gua legible y comprensible para
quienes generan cdigo y quienes realizan las pruebas y,
en consecuencia, dan soporte al SW.
El diseo debe proporcionar una imagen completa del
SW, dando direccin a los dominios de datos, funcionales
y de comportamiento desde una perspectiva de
implementacin
Directrices de calidad del diseo
Directrices de Calidad del diseo

Con el fin de evaluar la calidad de una representacin de
diseo se deben establecer los criterios tcnicos para un
buen diseo. Para esto se presentan las siguientes
directrices:
Un diseo debe presentar una estructura arquitectnica que:
Se haya creado mediante patrones de diseo reconocibles
La integren componentes que exhiban buenas caractersticas
de diseo ( se explicarn ms adelante).
Pueda implementarse de manera evolutiva para que de esta
forma facilite la implementacin y las pruebas.
Un diseo debe ser modular, esto es el SW deber dividirse

de manera lgica en elementos o subsistemas.
Un diseo debe contener distintas representaciones de los
datos, la arquitectura, las interfaces y los componentes.
Directrices de Calidad del diseo

Un diseo debe conducir a:
Estructuras de datos que sean apropiadas para las clases que
habrn de implementarse y que procedan de patrones de
datos reconocibles.
Componentes que presenten caractersticas funcionales
independientes.
Interfaces que reduzcan las complejidad de las conexiones
entre los componentes y el ambiente externo.
Un diseo debe obtenerse por medio de un mtodo repetible

que se base en la informacin obtenida durante el anlisis
de requisitos del SW.
Un diseo debe representarse por medio de una notacin
que comunique de manera eficaz su significado.
Atributos de calidad del diseo
Atributos de Calidad del diseo

HP desarrollo un conjunto de atributos de calidad, los
cuales representan un objetivo para todo el diseo de SW.
Estos son:
La funcionalidad se estima al evaluar el conjunto de
caractersticas y capacidades del programa, la generalidad
de las funciones que se entregan y la seguridad del sistema
en su totalidad.
La facilidad de uso se valora al considerar los factores
humanos, la esttica, la consistencia y documentacin en
general.
La confiabilidad se evala al medir la frecuencia y
severidad de las fallas, la precisin de los resultados de
salida, la medida del momento de fallas, la habilidad para
recuperarse de las fallas y la previsibilidad del programa.
Atributos de Calidad del diseo

El desempeo se mide con la velocidad de
procesamiento, tiempo de respuesta, consumo de
recursos, rendimiento y eficacia.
La soportabilidad combina la habilidad de extender el
programa (extendibilidad), la adaptabilidad y la
serviciabilidad, estos atributos representan un concepto
ms comn:
Facilidad de mantenimiento
Resistencia a pruebas
Compatibilidad
Configurabilidad (habilidad para organizar y controlar
elementos de la configuracin de SW)
Facilidad con que se instala el sistema
Facilidad con la que se puede localizar el problema
No todos los atributos tienen el mismo peso cuando se

desarrolla el diseo del SW.
Conceptos del diseo

M.A.Jackson seal una vez: El comienzo de la sabidura para
un Ing. De SW es reconocer la diferencia entre hacer que un
programa funcione y conseguir que lo haga del modo correcto.
Los conceptos fundamentales del diseo ofrecen el marco de
trabajo necesario para hacer las cosas del modo correcto.
Abstraccin
Arquitectura
Patrones
Modularidad
Ocultacin de la Informacin
Independencia Funcional
Refinamiento
Refabricacin
Clases de Diseo
Conceptos de diseo
1.- Abstraccin
Cuando se considera una solucin modular a
cualquier problema se pueden exponer muchos
grados de abstraccin.
Alto
Solucin se establece en trminos generales,

entorno del problema
Nivel de
Abstraccin
Bajo
Se proporciona una descripcin ms detallada

de la solucin, al nivel de implementacin
El nivel ms bajo de abstraccin permitir que la

solucin pueda implementarse directamente.
1.- Abstraccin
En la medida en que cambien los diferentes grados de
abstraccin se trabaja para crear abstracciones
procedimentales y de datos.
Una abstraccin procedimental, se refiere a una
secuencia de instrucciones que tiene una funcin
especfica y limitada.
Un ejemplo de abstraccin procedimental sera la palabra
abrir para una puerta.
Una abstraccin de datos es una coleccin nombrada de
datos que describe un objeto de datos.
En el contexto de abstraccin procedimental, abrir se
puede definir como una abstraccin de datos llamada
puerta.
2.- Arquitectura
La arquitectura de SW alude a La estructura general del
SW y las formas en que la estructura proporciona una
integridad conceptual para un sistema.
Desde un punto de vista ms simple, la arquitectura es la
estructura u organizacin de los componentes del
programa (mdulos), la manera es que stos
componentes interactan y la estructura de datos que
utilizan los componentes.
Una de las metas del diseo de SW es derivar una
representacin arquitectnica de un sistema.
Esta representacin sirve como el marco de trabajo a
partir del cual se conducen actividades de diseo ms
detalladas.
2.- Arquitectura
Un conjunto de patrones arquitectnicos permite que se
reutilicen conceptos a nivel de diseo.
Existen diferentes tipos de modelos que se pueden usar
para representar a una arquitectura.
Modelos estructurales: Representan la arquitectura como
una coleccin organizada de componentes del programa.
Modelos del marco de trabajo: incrementan el grado de
abstraccin del diseo al intentar identificar marcos de
trabajo repetibles del diseo arquitectnico que se
encuentran en tipos de aplicaciones similares.
Modelos dinmicos: abordan los aspectos conductuales de
la arquitectura del programa, al indicar cmo puede cambiar
la configuracin de la estructura o el sistema, como funcin
de los eventos externos.
2.- Arquitectura
Los modelos del proceso: se centran en el
diseo del proceso tcnico o de negocios que el
sistema debe contener.
Los modelos funcionales: pueden utilizarse para
representar la jerarqua funcional de un sistema.

3.- Patrones
Un patrn es una semilla de conocimiento, la cual tiene un
nombre y transporta la esencia de una solucin probada a
un problema recurrente dentro de cierto contexto en medio
de intereses en competencia.[Brad Appleton 98].
Un patrn de diseo describe una estructura de diseo que
resuelve un problema de diseo particular dentro de un
contexto especfico y en medio de fuerzas que pueden
tener un impacto en la manera en que se aplica y utiliza el
patrn.
Cada patrn describe un problema que ocurre una u otra
vez en nuestro entorno y despus describe la esencia de la
solucin a dicho problema, de tal forma que puedas usar
esta solucin un milln de veces ms, sin nunca hacerlo las
veces de la misma forma. [Christopher Alexander]
3.- Patrones
La finalidad de cada patrn de diseo es
proporcionar una descripcin que le permita al
diseador determinar:
Si el patrn es aplicable al trabajo actual
Si el patrn se puede reutilizar
Si el patrn puede servir como gua para
desarrollar un patrn similar, pero diferente en
cuanto a la funcionalidad o estructura.

4.- Modularidad
El SW se divide en componentes con nombres
independientes y que es posible abordar en forma
individual.
Estos componentes, llamados mdulos, se integran para
satisfacer los requisitos del problema.
Mdulo: cada una de las unidades claramente definidas y
manejables constituyentes del SW.
La modularidad es el atributo particular del SW que
permite que un programa sea manejable de manera
intelectual
Esta consiste en el particionamiento del SW en elementos
con nombres y direcciones separadas que se denominan
mdulos, los cuales en su composicin generan una
totalidad que debe ser capaz de resolver el problema que
da origen a la necesidad de construir un producto de SW.
4.- Modularidad
Tiene que ver con la divisin de las funciones que en
conjunto cumplen un objetivo mayor, esto es, responden a
la idea de totalidades emergentes propia de la nocin de
sistemas.
Sus beneficios son:
Programas ms simples, ya que puede ser comprendido,
verificado, programado, depurado, mejorado y alterado por
partes.
Mdulos que pueden ser desarrollados con relativa
independencia
Disminucin de la posibilidad de errores al reducir la
complejidad
Programas que pueden evaluarse por partes, por lo cual
todo test se hace ms fcil.
Programas ms fciles de alterar ya que son menores las
lneas de cdigo a considerar para incorporar los cambios.
4.- Modularidad
Sus beneficios son:
Mdulos de funcin nica que pueden ser reutilizados.
El programa puede ser comprendido por partes.
Disminuye errores de programacin. Son menos las lneas
de cdigo que deben enfrentar al mismo tiempo los
programadores.
Los efectos colaterales de los cambios que afectan al
sistema son drsticamente reducidos.
Rotacin de personal menos crtica, ya que los
programadores estn involucrados en unidades de cdigo
ms pequeas por lo cual la sustitucin resulta menos
dificultosa.
Responde al requerimiento de la divisin del cdigo en
segmentos de una pgina, como lo sugiere la programacin
estructurada.
4.- Modularidad
Un mdulo que controla a otro se dice que es
superordinado a ste y, reciprocamente, un
mdulo controlado por otro se dice que es
subordinado.
El FAN OUT es una medida del nmero de
mdulos controlados directamente por otro
mdulo (nmero de subordinados inmediatos que
posee).
El FAN IN indica cuntos mdulos controlan
directamente un determinado mdulo (Nmero de
superiores inmediatos que posee)
4.- Modularidad
Mdulo Superordinado
Mdulo Subordinado
FAN OUT: 2
FAN IN : 1

4.- Modularidad
Dividir hasta el infinito para que el Esfuerzo sea Cero ?
Costos
o Esfuerzo
Costo Total SW
Costo por Integracin
Costos Mnimos
Costo por Mdulo
N Mdulos
5.- Ocultacin de la Informacin

El principio de ocultacin de informacin sugiere que los
mdulos se caracterizan por las decisiones de diseo que
cada uno oculta a los otros.
En otras palabras, los mdulos deben especificarse y
disearse de manera que la informacin (procedimiento y
datos) que est dentro del mdulo sea inaccesible para
otros mdulos que no necesiten esa informacin.
La ocultacin implica que se puede conseguir una
modularidad efectiva al definir un conjunto de mdulos
independientes que se comuniquen entre si y que
intercambien slo la informacin necesaria para lograr la
funcin del SW.
5.- Ocultacin de la Informacin

La abstraccin ayuda a definir las entidades del
procedimiento (o informacin) que conforman el SW.
La ocultacin define y fortalece las restricciones de acceso
para los detalles de procedimiento dentro de un mdulo y
para cualquier estructura de datos local que utilice el
mdulo.
Beneficios:
Cuando se requieren modificaciones durante la realizacin
de las pruebas y, despus, en el curso de mantenimiento del
SW.
Cmo la mayora de los datos y procedimientos est oculta
de las otras partes del SW, existe una probabilidad menor de
introducir errores inadvertidos al realizar las modificaciones
y propagarlos a otros lugares dentro del SW.
6.- Independencia Funcional

El concepto de independencia funcional es la suma directa
de la modularidad y de los conceptos de abstraccin y
ocultacin de informacin.
La independencia funcional se consigue al desarrollar
mdulos con una funcin determinante y una aversin
a la interaccin excesiva con otros mdulos. Es decir, se
desea disear el SW de tal manera que cada mdulo
aborde una subfuncin especfica de los requisitos y tenga
una sola interfaz cuando se observe desde otras partes de
la estructura del programa.
El SW con una modularidad efectiva, es decir, con
mdulos independientes, es ms fcil de desarrollar
porque la funcin se puede fraccionar y las interfaces se
simplifican.

Beneficios:
Los mdulos independientes son ms fciles de
mantener y probar, porque se limitan los efectos
secundarios que originan las modificaciones al
diseo o al cdigo, se reduce la propagacin de
errores, y es posible emplear mdulos reutilizables.
La independencia funcional es una clave para el
buen diseo, y el diseo es clave para lograr la
calidad del SW.


Cmo evaluar la independencia??
Aplicando
2
criterios
cualitativos:
acoplamiento.
Cohesin
La cohesin: es una medida de la fuerza funcional relativa de

un mdulo.
El acoplamiento: es una medida de la interdependencia
relativa entre los mdulos.
Cohesin ocultacin de informacin. Un mdulo

cohesivo realiza una sola tarea , para lo cual requiere muy
poca interaccin con otros componentes en otras partes
del programa.
Un mdulo cohesivo debe (idealmente) hacer una sola
cosa.

El acoplamiento es una medida de la
interconexin entre los mdulos de una estructura
de SW.
El acoplamiento depende de la complejidad de la
interfaz entre los mdulos, el punto donde se
realiza una entrada o referencia a un mdulo, y
los datos que pasan a travs de la interfaz.
Una conectividad sencilla entre los mdulos da
como resultado un SW ms fcil de entender y
menos propenso a experimentar el efecto ola, el
cual se presenta cuando surgen problemas en un
lugar y despus se propagan a travs del sistema
7.- Refinamiento
Proceso iterativo mediante el cual la arquitectuta del SW es
el reflejo de la especificacin de requerimientos del sistema,
el cual se realiza sistemticamente con el propsito de
lograr una estructura modular, es decir, una representacin
que explicite las relaciones entre los principales elementos
del SW.
Se configura una representacin que muestra una visin
global tanto de las estructuras de datos como de las
estructuras de los componentes.
Tras un proceso de refinamiento sucesivo se transforma en
una representacin del diseo muy cercana al cdigo fuente
En cuanto a los detalles de los procedimientos que han de
regir las transformaciones que deben llevarse a cabo en cada
mdulo y en estructuras de datos detalladas.
7.- Refinamiento
En cada etapa del refinamiento, se descomponen una o varias de
las instrucciones del programa dado en instrucciones cada vez
ms detalladas.
Esta descomposicin o refinamiento sucesivo termina cuando
todas las instrucciones estn expresadas en trminos de cualquier
lenguaje bsico de computacin o de programacin.
El refinamiento es un proceso de elaboracin, que se inicia con el
enunciado de una funcin (o una descripcin de datos) que se
define con un alto grado de abstraccin.
El enunciado describe los datos o la funcin de manera
conceptual, pero no proporciona informacin acerca de los trabajos
internos de la funcin o de la estructura interna de los datos.
El refinamiento hace que el diseador trabaje sobre el enunciado
original y que proporcione ms y ms detalles conforme se realiza
cada refinamiento sucesivo.
7.- Refinamiento
La abstraccin y el refinamiento son conceptos
complementarios.
La abstraccin permite al diseador especificar
procedimientos y datos sin considerar detalles de
grado menor.
El refinamiento ayuda al diseador a revelar los
detalles de grado menor mientras se realiza el
diseo.
Ambos conceptos auxilian al diseador en la
creacin de un modelo de diseo completo a
medida que evoluciona la actividad de diseo.
7.- Refinamiento
En la ISW, la modularizacin se apoya en lo que se
conoce como refinamiento sucesivo gradual para la
configuracin de la estructura del SW
Refinamiento
Gradual
Abstraccin
Mdulo A
Modularidad
A1
A2

Factorizacin
8.- Refabricacin
Es la tcnica de reorganizacin que simplifica el diseo (o
cdigo) de un componente sin cambiar su funcin o
comportamiento.
La refabricacin es el proceso de cambiar un sistema de
SW de tal forma que no se altere el comportamiento
externo de su cdigo y diseo y an as se mejore su
estructura interna.
Cuando un SW se refabrica el diseo existente se
examina en busca de redundancias, elementos de diseo
intiles,
algoritmos
innecesarios
o
insuficientes,
estructuras de datos inapropiadas o construidas de
manera incorrecta, o cualquier otra falla de diseo que se
pueda corregir para lograr un mejor diseo.
9.- Clases de Diseo

En la etapa de anlisis se definen un conjunto completo de
clases de anlisis.
Cada una de estas clases describe algn elemento del
dominio del problema.
El grado de abstraccin de una clase de anlisis es
relativamente alto.
Conforme evoluciona el modelado del diseo, el equipo de
SW debe definir un conjunto de clases de diseo que:
Refine las clases de anlisis al proporcionar detalles del
diseo que permitirn la implementacin de las clases.
Produzca un conjunto nuevo de clases de diseo que
implementen una infraestructura de SW para soportar la
solucin del negocio.
9.- Clases de Diseo

Se sugieren 5 diferentes tipos de clases de diseo, cada
una representa una capa distinta de la arquitectura de
diseo.
Las clases de interfaz con el usuario definen todas las
abstracciones necesarias para la interaccin humanocomputadora (IHC). En muchos casos, la IHC ocurre dentro
del contexto de una metfora y las clases de diseo para la
interfaz pueden ser representaciones visuales de los
elementos de la mtafora.
Las clases del dominio de negocios a menudo son
refinamientos de las clases de anlisis definidas antes. Las
clases identifican los atributos y servicios (mtodos)
necesarios para implementar algn elemento del dominio de
negocios.
9.- Clases de Diseo

Las clases del proceso implementan abstracciones
del negocio en un nivel ms bajo, las cuales se
requieren para manejar por completo las clases del
dominio de negocios.
Las
clases
persistentes
representan
almacenamientos de datos (por ej. Una BD) que
persistirn ms all de la ejecucin del SW.
Las clases de sistema implementan las funciones
de gestin y control del SW que permiten que el
sistema opere y se comunique dentro de su
entorno de computacin y con el mundo exterior.
9.- Clases de Diseo

A medida que evoluciona el modelo de diseo, el
equipo debe desarrollar un conjunto completo de
atributos y operaciones para cada clase de
diseo.
El grado de abstraccin se reduce conforme cada
clase de anlisis se transforma en una
representacin del diseo.
Las clases de diseo presentan un mayor detalle
tcnico, pues son una gua para la
implementacin.
9.- Clases de Diseo

4 caractersitcas de una clase de diseo bien formada:
Completa y suficiente: Una clase de diseo debe ser la
encapsulacin completa de todos los atributos y mtodos
que se pueden esperar.
Primitivismo: Los mtodos asociados con una clase de
diseo deben enfocarse en el cumplimiento de un servicio
para la clase. Una vez que el servicio ha sido implementado
con un mtodo, la clase no debe proporcionar otra forma de
complementar la misma cosa. Ej VideoClip (inicio-fin).
Cohesin alta: Una clase de diseo cohesiva tiene un
conjunto de responsabilidades pequeo y enfocado, aplica
atributos y mtodos de manera sencilla para implementar
dichas responsabilidades. Ej: Edicin VideoClip
9.- Clases de Diseo

Bajo Acoplamiento: Dentro del modelo de diseo es
necesario que las clases de diseo colaboren con alguna
otra. Sin embargo, la colaboracin se debe mantener en un
mnimo aceptable. Si el sistema tiene un alto grado de
acoplamiento, es decir, todas las clases de diseo colaboran
con todas las otras clases, el sistema es difcil de
implementar, probar y difcil de mantener a travs del
tiempo.
En general las clases de diseo de un sistema deben de
tener slo un conocimiento limitado de las clases en otros
subsistemas.
La ley de DEMTER sugiere que un mtodo slo debe
enviar mensajes a mtodos de clases vecinas.
Fin conceptos de diseo
Acoplamiento y cohesin
Factores de calidad
Acoplamiento: Corresponde al grado de
independencia entre los mdulos.
Minimizar el acoplamiento aparece entonces
como un objetivo al configurar la estructura.
La obtencin de mdulos tan independientes
como sea posible se puede lograr de 3 maneras:
Eliminando relaciones innecesarias
Reduciendo el nmero de relaciones necesarias
Debilitando la dependencia de las relaciones
necesarias.
Cohesin: Corresponde a la medida de relacin

funcional de los elementos en un mdulo.
Los elementos de un mdulo corresponden a
instrucciones, definiciones de datos, o llamadas a
otros mdulos.
La idea es organizar estos elementos de tal
manera que tengan una mayor relacin entre ellos
al momento de cumplir su tarea.

Tipos de Acoplamiento
1.
2.
3.
4.
5.
6.
7.
Acoplamiento normal
Acoplamiento de Datos.
Acoplamiento de Marca (stramp)
Acoplamiento de Control
Acoplamiento Comn
Acoplamiento Externo
Acoplamiento de contenido

Tipos de Acoplamiento
Mejor Acoplamiento
NORMAL
DATOS
DE MARCA (STAMP)
CONTROL
EXTERNO (caso especial de COMN)
COMN
CONTENIDO (grado ms alto : peor)
Grado de
Acoplamiento
1.- Acoplamiento Normal

Dos mdulos A y B estn Normalmente Acoplados si:
Un mdulo A llama a Otro B
B retorna el contol a A
No se produce traspaso de parmetros entre ellos, solo

existe la llamada de uno a otro.
A

2.- Acoplamiento de datos

Dos mdulos estn acoplados por
datos si ellos se comunican por
parmetros.
Siendo cada parmetro una unidad
elemental de datos.
El
acoplamiento
de
datos
corresponde a la comunicacin de
datos necesaria entre mdulos.
Toda vez que los mdulos tienen
que comunicarse entre s, la
ligazn por datos es inevitable y
sern adecuados si se mantienen
a niveles mnimos
Obtener
Datos
Cliente
Rut_cliente

Leer Rut
3.- Acoplamiento de Marca (stramp)

Dos mdulos aparecen
acoplados de marca si
ellos se refieren a la
misma estructura de
datos local.
Por estructura de datos
se debe entender un
grupo compuesto de
datos
en
vez
de
argumentos simples.
Por ejemplo un registro.
Calcular
Deuda
Cliente
Cliente
Leer Cliente
Cliente= rut+nombres+apellido_paterno+
apellido_materno+direccin+fono+e_mail

4.- Acoplamiento de Control

Dos
mdulos
estn
acoplados
por
control
cuando uno de ellos pasa
al otro mdulo indicadores
de control (flag, switch).
Provoca dependencia de
ejecucin entre un mdulo
y otro.
No
es
recomendable.
Tratar
de
utilizarlo
moderadamente.
Obtener
Datos
Cliente
Tipo_dato
Cliente
Leer Cliente

5.- Acoplamiento Comn

Dos mdulos presentan
acoplamiento comn, si
ellos se refieren a la misma
rea global de datos
(Archivo
o
rea
de
memoria).
Programas con muchos
datos globales son difciles
de entender por los
programadores
de
mantencin, porque no es
fcil saber cuales son los
datos usados por un cierto
mdulo.
Actualizar
Stock
Video
Obtener
Nombre
Video
video
Leer Registro
Video

6.- Acoplamiento Externo

Cuando los mdulos estn
atados a un entorno
externo al SW se dan
niveles relativamente altos
de acoplamiento.
Por ejemplo, la E/S acopla
un mdulo a dispositivos,
formatos y protocolos de
comunicacin.
El acoplamiento externo
debe limitarse a unos
pocos mdulos en la
estructura.
Actualizar
DW
Obtener
Nmina
Registro_act

Nmina
DW
7.- Acoplamiento de Contenido

Este es un tipo de acoplamiento
indeseable.
Dos
mdulos
presentan
acoplamiento de contenido (o
patolgico)
si
uno
hace
referencia al interior del otro.
Esto ocurre si por ejemplo en un
mdulo se desva la secuencia
de instrucciones al interior de
otro o si un mdulo altera un
comando de otro
Tal acoplamiento rompe el
concepto
de
mdulos
configurados bajo el criterio de la
caja negra. Forzando a un
mdulo conocer explicitamente
los
contenidos
y
la
implementacin de otro
A
..
Srch: Move..
..
.
.

B
..
..
Jump to Srch
.
Tipos de acoplamiento
Los mdulos pueden estar relacionados por ms
de un tipo de acoplamiento. Si esto ocurre, el
acoplamiento que caracteriza la relacin entre
ellos queda definido por el peor tipo que
presenten.
Por ejemplo, si dos mdulos estn ligados por
acoplamiento de marca y acoplamiento comn a
la vez, se dir que los mdulos estn ligados por
acoplamiento comn.

Cmo analizar el tipo de

Acoplamiento?
Imaginar el mdulo como una biblioteca
Cmo el mdulo podra ser ms fcilmente entendido.
Cmo el mdulo podra ser ms utilizado por otros sistemas
o invocado por otros mdulos del mismo sistema.
Cada mdulo es codificado por un programador diferente

Qu
tan
independientes
pueden
trabajar
los
programadores?
Existe algn supuesto, convencin o decisiones de
implementacin a los cuales ms de un mdulo deba prestar
atencin?
Cuales son las posibilidades de cambio que existen en
relacin a los supuestos, convenciones o a la
implementacin?
Existe alguna manera de aislar aquellos cambios y
situarlos en un solo mdulo?
Ideas centrales
Sistemas altamente acoplados conducen a
depurar verdaderas pesadillas. Evtelo.
Sistemas altamente acoplados, tienden a tratarse
como una sola gran unidad, y un sistema
monoltico es la contrapartida a particionar.
Hablar de mdulos, cajas negras, es hablar de
particionamiento
Particionar es la estrategia para abordar la
complejidad.
Las cajas negras se organizan jerrquicamente.
Tipos de Cohesin
Mayor Cohesin
FUNCIONAL
Mdulo como
Caja Negra
SECUENCIAL
COMUNICACIONAL
PROCEDURAL
TEMPORAL
Mdulo
Transparente
LGICA
COINCIDENTAL
Grado de
Cohesin
STEVEN, MYERS, CONSTANTINE y YOURDON (1974)

establecieron "una escala de cohesin"
1.- Cohesin Funcional

Un mdulo con cohesin funcional es aquel que
contiene elementos que contribuyen a la
ejecucin de una y slo una tarea relacionada al
problema.
Ejemplos
Calcular el coseno de un ngulo
Calcular el I.V.A. de una factura
Verificar el dgito de un rut

2.- Cohesin Secuencial

Un mdulo secuencialmente
cohesionado es aquel cuyos
elementos estn envueltos
en actividades tales que los
datos de salida de una
actividad en general sirven
como datos de entrada para
la prxima actividad.
1.
2.
3.
4.
5.
6.
7.
.
Ejemplo:
Calcular
el
salario.
Obtener el suelo base
Verificar
nmero
de
cargas
Revisar das con permiso
Revisar das con licencia
Calcular horas de trabajo
Descontar
horas
de
atraso
Agregar horas extras.

3.- Cohesin Comunicacional

Un
mdulo
presenta
cohesin comunicacional
cuando sus elementos
contribuyen a actividades
que usan la misma
entrada o la misma salida.
No importa el orden
secuencial.
Ejemplo obtener
producto
1. Obtener nombre
2. Obtener Stock
3. Obtener ubicacin
4. Obtener precio
..

datos
4.- Cohesin Procedimental

Cuando sus elementos de procesamiento estn
relacionados y deben ejecutarse en un orden
especfico.

5.- Cohesin Temporal

Un mdulo con cohesin
temporal es aquel cuyos
elementos estn envueltos
en actividades que estn
relacionadas en funcin
del momento en que se
realizan
Actividades al iniciar el
da
1. Apagar despertador
2. Tomar ducha
3. Vestirse
4. Hacer la cama
5. Tomar desayuno
.

6.- Cohesin lgica

Un mdulo tiene cohesin
lgica,
cuando
existe
alguna relacin entre los
elementos del mdulo,
contribuyendo
al
desarrollo de actividades
de una misma categora
general, donde la actividad
o las actividades a ser
ejecutadas se seleccionan
desde fuera del mdulo.
Ejemplo Registrar Pago

1. Registrar pago con tarjeta
de crdito
2. Registrar
pago
con
cheques.
3. Registrar
pago
con
efectivo.

7.- Cohesin Coincidental

Un mdulo coincidentalmente
cohesioando es aquel cuyos
elementos
desarrollan
actividades
sin
relacin
significativa entre si.
Ejemplo:
1. Comprar un libro
2. Comer un trozo de
torta
3. Ir al teatro
4. Lavar la ropa
5. Dormir
.

Cmo medir la calidad del diseo
Evaluacin de la calidad del diseo: RTF

Durante el diseo la calidad se evala al realizar una serie
de revisiones tcnicas formales (RTF).
Una RTF es una reunin que dirigen miembros del equipo
de SW
Por lo general participan de 2 a 4 personas, dependiendo
del mbito de informacin del diseo que se revisar.
Cada persona desempea un rol:
El lder de revisin planea la reunin, establece la agenda y
despus realiza la reunin
El relator toma notas para que nada se olvide
El productor es la persona a la cual se le revisa el producto

Evaluacin de la calidad del diseo: RTF

Antes de cada reunin, cada persona del equipo recibe
una copia del producto de trabajo de diseo y se solicita
que sea ledo en busca de errores, omisiones y
ambigedades
El objetivo de la reunin es el de detectar todos los
problemas del producto de diseo, para que estos puedan
corregirse antes de la implementacin, con una duracin
de 90 a 120 min.
Al termino de la RTF, el equipo de revisin determina si se
requieren acciones posteriores por parte del productor
antes que el producto pase a ser parte del producto de
diseo final
Fin Conceptos de Diseo

Clase 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Clase 1

Uploaded by

Copyright:

Available Formats

Diseo e Implementacin

Pedro Francisco Godoy Barrera

Principios del Diseo

Principios del diseo

Principios del diseo

1.- El diseo debe ser rastreable hasta

El dominio de la informacin del problema

El Diseo traduce esta informacin a una arquitectura

Excepto el modelo asociado a la infraestructura de SW,

2.- Siempre se debe considerar la

La arquitectura del SW es el esqueleto del

Por esas razones el diseo debe iniciarse con las

3.- El diseo de datos es tan importante como

Un diseo de datos bien estructurado ayuda a

Pedro Francisco Godoy Barrera

4.- Las interfaces (interna y externas)

La manera en la que fluyen los datos entre los

Una interfaz bien diseada facilita la integracin y

Pedro Francisco Godoy Barrera

5.- El diseo de la interfaz del usuario debe

Hay que resaltar la facilidad de uso.

Si el diseo de la interfaz es pobre conduce a la

Pedro Francisco Godoy Barrera

6.- El diseo a nivel de componentes debe

La independencia funcional componente de

Pedro Francisco Godoy Barrera

7.- Los componentes deben estar acoplados entre si

El acoplamiento se consigue de las siguientes

Pedro Francisco Godoy Barrera

8.- La representaciones del diseo deben

El propsito del diseo es comunicar informacin

Por lo tanto si el diseo es difcil de entender, no

Pedro Francisco Godoy Barrera

9.- El diseo debe desarrollarse de manera iterativa.

Cmo es casi todas las actividades creativas, el

Pedro Francisco Godoy Barrera

Pedro Francisco Godoy Barrera

Pedro Francisco Godoy Barrera

Para lograr diseos de calidad, el diseador debe practicar

Un buen diseo es clave para la prctica efectiva

Pedro Francisco Godoy Barrera

Etapas para atacar cualquier proceso

Identificar y entender el problema desde distintos

Rol del diseo dentro del proceso de

El proceso de diseo se desarrolla iterativamente

Modelo general para el proceso de diseo

Pedro Francisco Godoy Barrera

Modelo general para el proceso de diseo

No hay lmites rgidos entre las actividades, pero

Pedro Francisco Godoy Barrera

Las actividades del proceso de diseo son

Diseo Arquitectnico: Se identifican y

Las actividades del proceso de diseo son

Diseo de componentes: Se completan las

Normalmente se hacen distinciones entre un

Pedro Francisco Godoy Barrera

Productos del proceso de diseo

Pedro Francisco Godoy Barrera

Notaciones que se usan en los documentos

Texto informal: permite expresar la racionalidad

Importancia del Diseo

Importancia del Diseo

El diseo es la nica forma en que, de manera exacta, un