FUNDAMENTO DE DISEO DE SOFTWARE

A travs de la historia de la ingeniera del software ha evolucionado un conjunto de conceptos

fundamentales de diseo de software, aunque el grado de inters en cada concepto ha variado con los
aos, han pasado la prueba del tiempo ofreciendo cada uno al ingeniero de software fundamentos
sobre el cual pueden aplicarse mtodos de diseo ms elaborados.
El diseo de Software juega un papel importante en el desarrollo de software lo cual permite al
ingeniero de software producir varios modelos del sistema o producto de que se va a construir el mismo
que forman una especie de plan de la solucin de la aplicacin. Estos modelos puede evaluarse en
relacin con su calidad y mejorarse antes de generar cdigo, de realizar pruebas y de que los usuarios
finales se vean involucrados a gran escala. El diseo es el sitio en el que se establece la calidad del
software.
Diseo es definido como: "El proceso de definicin de la arquitectura, componentes, interfaces y
otras caractersticas de un sistema o componente que resulta de este proceso" [IEEE610.12-90].
Fundamentos del Diseo de Software

Conceptos generales de diseo.

El software no es el nico campo donde el diseo se encuentra inmiscuido. En general podemos ver el
diseo como una forma para resolucin de problemas. El problema sin solucin definitiva es interesante
en trminos de comprensin del diseo. Un nmero de otras nociones y conceptos son tambin de
inters en la comprensin del diseo en su sentido general, objetivos, limitaciones, alternativas,
representaciones y soluciones

Contexto del diseo de software.

El diseo del software se encuentra en el ncleo tcnico de la respectiva ingeniera y se aplica de

manera independiente al modelo de software que se utilice. Una vez que se analizan y especifican los
requisitos, el diseo del software es la ltima accin de la ingeniera correspondiente dentro de la
actividad del modelado, la cual establece una plataforma para la construccin (generacin de cdigo y
prueba).
"El milagro ms comn de la ingeniera de software es la transicin del anlisis al diseo y del
diseo al cdigo" Richard Due

Proceso del Diseo de Software.

Diseo Arquitectnico.

El diseo arquitectnico puede representarse al usar uno o ms de muchos modelos diferentes. Los
modelos estructurales representan la arquitectura como una coleccin organizada de componentes del
programa. Los modelos del marco de trabajo repetible 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.
El diseo de la arquitectura de software se describe cmo se descompone y como estn
organizados los componentes en el software. [IEEEP1471-00]

Diseo Detallado.

El diseo detallado se describe el comportamiento especfico de estos componentes.

Mtodo de Desarrollo de Software

El mtodo de diseo de software que se expone a continuacin es el mtodo de solucin de problemas
mediante tcnicas de ingeniera.
1. Definicin del Problema
En esta etapa, tambin conocida como Especificacin de Requerimientos, se establece el problema,
aclarndolo lo ms posible. Es la parte ms crtica de la solucin. Amerita un estudio cuidadoso. Se
deben identificar las teoras, fundamentos y/o principios matemticos, fsicos o de cualquier ndole que
permitan fundamentar satisfactoriamente el problema.
Se deben eliminar los aspectos poco importantes para el planteamiento del problema
Si el problema no est completamente definido se deben allegar la informacin adicional
2. Anlisis
En esta etapa se deben identificar las entradas del problema, los resultados deseados o salidas y
cualquier requerimiento o restriccin adicional en la solucin
Identificar qu informacin se proporciona (datos del problema)
Identificar qu resultados deben calcularse y/o desplegarse
Determinar la forma y las unidades en qu se deben desplegar los resultados
Acotar las teoras, fundamentos y/o principios necesarios haciendo los supuestos y
simplificaciones necesarias
Identificar los tipos y estructuras de datos necesarios para los datos del problema y para los
resultados
Identificar las funciones u operaciones necesarias para cubrir los requerimientos del problema
3. Diseo
El diseo consiste bsicamente en desarrollar una lista de pasos llamados algoritmo o receta de la
solucin, verificando que el problema se resuelve como se desea.
Es la parte ms difcil del proceso de solucin del problema
Debe verificarse que es correcto el algoritmo antes de continuar
Se auxilia de tcnicas de diseo como pseudocdigo y diagramas de flujo.
4. Implementacin
Esta etapa consiste en implementar o escribir el algoritmo como un programa de computadora en
lenguaje de programacin, convirtiendo cada paso del algoritmo en instrucciones en el lenguaje
programacin.
Se requiere el conocimiento de un lenguaje de programacin particular en lo referente a
gramtica, sintaxis y semntica, para ello se recomienda leer el manual del programador o
equivalente y utilizarlo como consulta siempre que sea necesario.

un
de
su
su

Una manera de iniciar el conocimiento del lenguaje de programacin es interpretando programas

ejemplo, ejecutarlos, observar los resultados y analizar las entradas, las salidas y los procesos de
clculo y/o flujo de informacin mediante instrucciones de salida que finalmente .
Se requiere mnimo de las siguientes herramientas:
Un editor de texto para escribir el cdigo fuente como un archivo de tipo texto plano (por
ejemplo notepad para guardar los archivos como html)

Un intrprete que procese el cdigo fuente y lo ejecute (por ejemplo el browser que
ejecuta scripts en javaScript al cargar la pgina web)

Un debugger que nos ayude a depurar los errores y a corregir el cdigo fuente hasta
lograr un programa ejecutable sin errores (por ejemplo el mismo browser que enva
mensajes a encontrar errores al ejecutar nuestro programa)

Se deben utilizar los tipos y estructuras de datos ms adecuados que permita el lenguaje de
programacin, teniendo especial cuidado en el uso de tipos de datos reales y los errores de
redondeo que introducen y pueden alterar los resultados.

5. Verificacin y Prueba
Esta etapa consiste en probar el programa completo y verificar que trabaja como se esperaba
Se deben probar cada una de las funciones primero por separado y luego en conjunto
Se debe probar el programa completo con distintos conjuntos de datos de prueba
En caso de que haya errores repetir el paso 4 y 5 hasta la satisfaccin de los requerimientos

La ingeniera de software cubre tres elementos claves:

Mtodos
Herramientas
Procedimientos

Facilitan al gestor controlar el proceso de desarrollo de software y suministrar las bases para construir
software de alta calidad de una forma productiva.
Los mtodos indican cmo construir tcnicamente el software. Estos mtodos abarcan tareas que
incluyen : planificacin y estimacin de proyectos, anlisis de los requisitos del sistema y del software,
diseo deestructuras de datos, arquitectura de programas y procedimientos algortmicos, codificacin,
prueba y mantenimiento.
Las herramientas suministran un soporte automtico o semiautomtico para los mtodos. Cuando se
integran las herramientas de forma que la informacin creada por una herramienta pueda ser usada por
otra, se establece un sistema de soporte llamada Ingeniera de Software Asistida por Computadora
(CASE).
Los procedimientos son el pegamento que junta los mtodos y las herramientas, y facilita un desarrollo
racional y oportuno. Definen la secuencia en la que se aplican los mtodos, las entregas (documentos,
informes, formas, etc.) que se requieren, los controles para asegurar la calidad y coordinar los cambios,
y las directrices que ayudan a los gestores de software a evaluar el progreso.
Persistencia. Es la propiedad de un diseo a travs de la cual su existencia trasciende el tiempo (es
decir, continua existiendo despus de que su creador ha dejado de existir)
Almacenamiento
Consiste en la recuperacin ms rpida de la informacin, en la organizacin de almacenar grandes
cantidades de datos, por eso, debe tenerse en cuenta donde almacenarlos y como recuperarlos cuando
se los necesita.
Cada metodologa de diseo de software introduce heursticas y notaciones propias, as como una
visin algo particular de lo que caracteriza a la calidad del diseo. Sin embargo, todas las metodologas
tienen varias caractersticas comunes:
Un mecanismo para la traduccin de la representacin del campo de informacin en una
representacin de diseo.
Una notacin para representar los componentes funcionales y sus interfaces.
Heursticas para el refinamiento y la particin, y
Criterios para la valoracin de la calidad.

Principios de diseo
Segn M.A. Jackson (1975) "El comienzo de la sabidura para un ingeniero de software es reconocer la
diferencia entre hacer que un programa funcione y conseguir que lo haga del modo correcto".

Los principios de diseo son aplicables a todos los niveles del diseo del software, desde la arquitectura
a la microarquitectura, adems todos estos principios se relacionan entre si.
Principios de diseo
Los principios de diseo a estudiar son los siguientes:
1) ABSTRACCIN Y REFINAMIENTO: se trata de ocultar los detalles, es decir no centrarse en
detalles concretos del diseo, sino hacer un esquema visual a alto nivel. De esta manera tenemos una
visin general de todo, tambin se utiliza en los microdiseos. La tctica del refinamiento es justamente
lo contrario, es decir, centrarse en los detalles del modelo abstracto dado anteriormente.
La tcnica de abstraccin y refinamiento se complementa con la de refinamiento, es decir, primero se
hace una abstraccin del problema y una vez que tenemos un esquema abstracto usamos la tcnica del
refinamiento para centrarnos en detalles concretos.
2)MODULARIDAD: se basa en el principio de "Divide y Vencers", que consiste un dividir el
problema en varios problemas ms pequeos para que el costo de resolverlos sea menor. Consiste en
dividir un sistema en varios subsistemas, cada uno de estos resuelve un problema pequeito y luego se
vuelven a unir. Esta tcnica se puede aplicar a distintas escalas. Esto nos plantea una pregunta: Cmo
lo divido? Pues no hay una forma exacta para hacer la divisin sino que depende de cada problema en
particular.
3) VARIACIONES PROTEGIDAS: hay que tener claros dos conceptos: punto de variacin y punto
de evolucin.
*Punto de variacin: es un requisito del sistema que tiene caractersticas variables y puede
cambiar, por tanto tengo que soportarlo en mi aplicacin.
*Punto de evolucin: es cuando nosotros prevemos que se puede convertir en un punto de
variacin.
En el desarrollo del software todo lo que sea cambios es un problema, hay que prestar atencin a estos
puntos que cambian, la idea es proteger al sistema de los cambios en los puntos de variacin y en los
puntos de evolucin.
Cuando detecte un punto de variacin y/o punto de evolucin tengo que disearlo de forma que los
cambios que se produzcan en el sistema afectan a lo mnimo posible.
4) ACOPLAMIENTO: medida cualitativa del grado en el que un mdulo esta conectado a otros y el
mundo exterior. El acoplamiento hay que mantenerlos bajo para que cada mdulo sea lo ms
independiente posible. De esta forma si un mdulo cambia, su cambio afecta lo menos posible al resto
de sistema. Nunca se puede dar el acoplamiento 0.
El acoplamiento es un principio evolutivo, tenemos que ir controlndolo a medida que se disea hay que
estar evaluando el grado de acoplamiento para conseguir que sea lo ms bajo posible
Hay que ser cautelar, es decir, no hay que intentar disminuir el acoplamiento a toda costa, sino que hay
que evaluar como hacerlo.
5) COHESIN: es la medida cualitativa del grado en el que un mdulo se enfoca a una sola cosa.
Un mdulo hace cosas muy parecidas, la cohesin debe ser alta en cada mdulo, se trata de conseguir

mdulos muy cohesivos y que estn poco acoplados. Para mejorar la cohesin lo mejor es dividir en
subsistemas. Las clases con muchos mtodos son poco cohesivas y habr que dividir.
La cohesin al igual que el acoplamiento es evolutiva, hay que ir evaluando a la vez que se disea para
aumentar la cohesin.
"Un elemento es altamente cohesivo si todos sus elementos trabajar juntos para proporcionar algn
comportamiento bien determinado"
A la cohesin y al acoplamiento se les denomina el Yin y el Yan del diseo software.
6)REFACTORIZACIN: segn Martin Fowler (1999) "Es el proceso de cambiar un sistema de
software de tal forma que no se altere el comportamiento externo de su cdigo (diseo) y an as se
mejora su estructura interna".

INTERACCION ENTRE DISEO Y REQUERIMIENTO

ESPECIFICACION DE REQUERIMIENTOS

Un requerimiento se visualiza como una declaracin abstracta de alto nivel de un servicio que debe
proveer el sistema o como una restriccin de ste.
En el diseo desde la fase de anlisis se deben considerar los requerimientos funcionales y no
funcionales, puesto que as se clasifican
Requerimientos funcionales
Son declaraciones de los servicios que proveer el software, de la manera en que ste reaccionar a
entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas tambin
declaran explcitamente lo que el sistema no debe hacer.
Los requerimientos funcionales de un software describen la funcionalidad o los servicios que se espera
que ste provea. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles
usuarios. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma
general mientras que los requerimientos funcionales del sistema describen con detalle la funcin de
ste, sus entradas y salidas, excepciones, etc. Muchos de los problemas de la ingeniera de software
provienen de la imprecisin en la especificacin de requerimientos. Para un desarrollador de sistemas
es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementacin.
Sin embargo, a menudo no es lo que el cliente desea.
En principio, la especificacin de requerimientos funcionales de un sistema debe estar completa y ser
consistente. Esto significa que todos los servicios solicitados por el usuario estn definidos. La
consistencia significa que los requerimientos no tienen definiciones contradictorias.
Requerimientos no funcionales
Son restricciones de los servicios o funciones ofrecidos por el software. Incluyen restricciones de
tiempo, sobre el proceso de desarrollo, estndares, etc.
Son aquellos requerimientos que no se refieren directamente a las funciones especficas que entrega el
sistema, sino a las propiedades emergentes de ste como la fiabilidad, la respuesta en el tiempo y la
capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la
capacidad de los dispositivos de entrada/salida y la representacin de datos que se utiliza en la
interfase del sistema.
Muchos requerimientos no funcionales se refieren al sistema como un todo ms que a rasgos
particulares del mismo. Esto significa que a menudo con ms crticos que los requerimientos
funcionales particulares. Mientras que el incumplimiento de este ltimo degradar el sistema, una falla
en un requerimiento no funcional del sistema lo inutiliza.
Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el
presupuesto, a las polticas de la organizacin, a la necesidad de interoperabilidad con otros sistemas
de software o hardware o a factores externos como los reglamentos de seguridad, las polticas de
privacidad, etctera.

Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.

Requerimientos del producto. Especifican el comportamiento del producto; como los requerimientos de
desempeo en la rapidez de ejecucin del sistema y cunta memoria se requiere; los de fiabilidad que
fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.
Requerimientos organizacionales. Se derivan de las polticas y procedimientos existentes en la
organizacin del cliente y en la del desarrollador: estndares en los procesos que deben utilizarse;
requerimientos de implementacin como los lenguajes de programacin o el mtodo de diseo a utilizar,
y los requerimientos de entrega que especifican cundo se entregar el producto y su documentacin.
Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de desarrollo.
Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interacta con
los otros sistemas de la organizacin; los requerimientos legales que deben seguirse para asegurar que
el sistema opere dentro de la ley, y los requerimientos ticos. Estos ltimos son impuestos el software
para asegurar que ser aceptado por el usuario y por el pblico en general.
EL DOCUMENTO DE REQUERIMIENTOS DEL SOFTWARE
ste es la declaracin oficial de qu es lo que requieren los desarrolladores del software.
Una gran variedad de organizaciones han definido estndares para los documentos de requerimientos.
El IEEE sugiere la siguiente estructura para los documentos de requerimientos.
1. Introduccin propsito del documento de requerimientos Alcance del producto Definiciones,
acrnimos y abreviaturas Referencias Resumen del resto del documento
2. Descripcin general Perspectiva del producto Funciones del producto caractersticas del usuario
Restricciones generales Suposiciones y dependencias
3. Requerimientos especficos. Cubren los requerimientos funcionales, no funcionales y de interfaz.
Obviamente, sta es la parte ms sustancial del documento, pero debido a la amplia variabilidad en la
prctica organizacional, no es apropiado definir una estructura estndar para esta seccin. Los
requerimientos pueden documentar las interfaces externas, describir la funcionalidad y el desempeo
del sistema, especificar los requerimientos lgicos de la base de datos, las restricciones de diseo, las
propiedades emergentes del sistema y las caractersticas de calidad.
4. Apndices
5. ndice
DISEO DE ATRIBUTO DE CALIDAD
Algunos Factores de Calidad del Software

La usabilidad de un producto es el grado en el que el producto es prctico y fcil de utilizar. Esta

caracterstica debe subdividirse en atributos ms fundamentales para que sea posible algn tipo de
medicin; algunos a considerar pueden ser
nivel requerido: medido en aos de experiencia con aplicaciones similares
aprendizaje: medido en horas de adiestramiento requeridas antes de la utilizacin
independiente
capacidad de manipulacin: medida en velocidad de trabajo despus del adiestramiento y/o
errores cometidos a velocidad normal de trabajo.
FACTOR

DEFINICIN

Correccin

Grado en el que un programa satisface las

especificaciones y cumple los objetivos del usuario.

Fiabilidad

Grado en el que un programa se espera que realice su

funcin con una precisin requerida.

Eficiencia

Cantidad de recursos y cdigo requeridos por un

programa para realizar una funcin.

Integridad

Grado en el que se controla el acceso al programa o los

datos por usuarios no autorizados.

Usabilidad

Esfuerzo necesario para aprender, operar, preparar

entradas e interpretar la salida de un programa.

Mantenibilidad

Esfuerzo requerido para localizar y corregir un error en un

programa en funcionamiento.

Facilidad de
prueba

Esfuerzo requerido para probar un programa (para

garantizar que realiza la funcin deseada).

Flexibilidad

Esfuerzo requerido para modificar un programa en

funcionamiento.

Portabilidad

Esfuerzo requerido para transferir un programa de una

configuracin hardware o entorno software a otro.

Reusabilidad

Grado en el que un programa se puede utilizar en otras

aplicaciones

Interoperatividad

Esfuerzo requerido para acoplar un sistema con otro.

Diseo con patrones

El objetivo es agrupar una coleccin de soluciones de diseo que son vlidas en distintos contextos y
que han sido aplicadas con xito en otras ocasiones.
Un patrn de diseo es una solucin a un problema de diseo no trivial que es efectiva (ya se resolvi
el problema satisfactoriamente en ocasiones anteriores) y reusable (se puede aplicar a diferentes
problemas de diseo en distintas circunstancias).
Los patrones son soluciones de sentido comn que deberan formar parte del conocimiento de un
diseador experto. Adems facilitan la comunicacin entre diseadores, pues establecen un marco de
referencia (terminologa, justificacin).
Por otro lado, los patrones de diseo, facilitan el aprendizaje al programador inexperto, pudiendo
establecer parejas problema-solucin.
Adems, los patrones de diseo, tambin nos ayudarn a especificar las interfaces, identificando los
elementos claves en las interfaces y las relaciones existentes entre distintas interfaces. De igual modo
nos facilitar la especificacin de las implementaciones.
Tambin, y de forma casi automtica, nos ayudan a reutilizar cdigo, facilitando la decisin entre
"herencia o composicin" (favorece la composicin sobre la herencia y hace uso de la delegacin).
Relacionan estructuras en tiempo de compilacin y en tiempo de ejecucin.
Y nos permiten hacer un diseo preparado para el cambio.
Los patrones ayudan a construir la experiencia colectiva de Ingeniera de Software.

Son una abstraccin de "problema solucin".

Se ocupan de problemas recurrentes.
Identifican y especifican abstracciones de niveles ms altos que componentes o clases
individuales.
Proporcionan vocabulario y entendimiento comn.

Patrones de producto de software

Anlisis
Arquitectura
Diseo
Lenguaje de programacin (idioms)

Patrones de Diseo

Proxy
Contexto
El cliente quiere tener acceso a servicios de algn componente pero el acceso directo no
es la mejor solucin.
Problema
Optimizar el acceso al servicio compartido entre varios clientes.
Solucin
El cliente accesa el servicio del componente va un representante local del componente,
llamado proxy. El representante ofrece los mismos servicios y asegura el acceso correcto
al componente original.
Practica en wikipedia patron de diseo

El Ventanal

Rinc
n

A todos les gusta sentarse en cmodos

sillones junto a un ventanal.
Si una sala de estar no tiene este tipo de
rincn, las personas se debaten
entre dos fuerzas:
quedarse y sentarse
confortablemente
irse hacia la luz
La arquitectura debe prever este
conflicto.

Contexto

Problema

Ventanal
Solucin

El objetivo es agrupar una coleccin de soluciones de diseo que son vlidas en distintos contextos y
que han sido aplicadas con xito en otras ocasiones.
Un patrn de diseo es una solucin a un problema de diseo no trivial que es efectiva (ya se resolvi
el problema satisfactoriamente en ocasiones anteriores) y reusable (se puede aplicar a diferentes
problemas de diseo en distintas circunstancias).
Los patrones son soluciones de sentido comn que deberan formar parte del conocimiento de un
diseador experto. Adems facilitan la comunicacin entre diseadores, pues establecen un marco de
referencia (terminologa, justificacin).
Podemos clasificar a los patrones segn su propsito:
Patrones de creacin: para creacin de instancias.
Patrones estructurales: relaciones entre clases, combinacin y formacin de estructuras mayores.
Patrones de comportamiento: interaccin y cooperacin entre clases.

Patrones de creacin
Los patrones de creacin abstraen la forma en la que se crean los objetos, permitiendo tratar las
clases a crear de forma genrica dejando para ms tarde la decisin de qu clases crear o cmo
crearlas.
Segn donde se tome dicha decisin podemos clasificar a los patrones de creacin en patrones de
creacin de clase (la decisin se toma en los constructores de las clases y usan la herencia para
determinar la creacin de las instancias) y patrones de creacin de objeto (se modifica la clase desde
el objeto).

Patrones estructurales
Tratan de conseguir que cambios en los requisitos de la aplicacin no ocasionen cambios en las
relaciones entre los objetos. Lo fundamental son las relaciones de uso entre los objetos, y, stas estn
determinadas por las interfaces que soportan los objetos. Estudian como se relacionan los objetos en
tiempo de ejecucin. Sirven para disear las interconexiones entre los objetos.

Patrones de comportamiento
Los patrones de comportamiento estudian las relaciones entre llamadas entre los diferentes objetos,
normalmente ligados con la dimensin temporal.