Tabla de contenidos

Diseo de software.............................................................................................................2
Introduccin.....................................................................................................................2
Unidad I. Diseo de software...........................................................................................5
Definicin del diseo....................................................................................................5
Diseo y calidad de software....................................................................................6
Caractersticas comunes de las metodologas de diseo..........................................7
Fundamentos del diseo..............................................................................................7
Abstraccin...............................................................................................................7
Refinamiento.............................................................................................................8
Modularidad..............................................................................................................8
Arquitectura del software..........................................................................................9
Jerarqua de control.................................................................................................10
Estructura de datos.................................................................................................10
Procedimientos del software...................................................................................11
Ocultamiento de informacin..................................................................................11

Diseo de software
Introduccin
Durante mucho tiempo, las organizaciones han reconocido la importancia de administrar
recursos clave como las personas y la materia prima. Actualmente, la informacin ha
encontrado su lugar apropiado como recurso clave. Los responsables de la toma de
decisiones por fin comprenden que la informacin no es slo un producto derivado de las
operaciones comerciales, sino que adems provee impulso a las empresas y puede
constituir el factor decisivo para determinar el xito o el fracaso de un negocio. Para
maximizar la utilidad de la informacin, una empresa debe administrarla en forma
apropiada, de la misma manera en que administra los dems recursos. Los
administradores necesitan comprender que hay costos asociados con la produccin,
distribucin, seguridad, el almacenamiento y la recuperacin de toda informacin.
El proceso de administrar la informacin generada por computadora difiere de manera
considerable del proceso de manejar los datos producidos en forma manual; por lo
general debemos administrar una mayor cantidad de informacin computacional. Los
costos de administracin y mantenimiento pueden aumentar a ritmos alarmantes, y a
menudo los usuarios consideran este tipo de informacin con menos escepticismo que la
que se obtiene de otras fuentes.
Por lo anterior, la importancia de este curso, en el que se tomar conciencia de la
importancia de abordar la construccin del software desde una perspectiva de
ingeniera, adems, se presentar los conceptos relacionados con Ingeniera del software
en el paradigma de la orientacin a objetos estudiando el marco conceptual que
proporciona este paradigma para el diseo de software. Posteriormente, los conceptos
introducidos se presentarn mediante su correspondiente representacin en el Lenguaje
Unificado de Modelado (UML) y, finalmente, introducir el conjunto de diagramas que
propone UML para el modelado de los diferentes aspectos de un software.

Realidades del software

El 55% de los sistemas cuestan ms de lo esperado, el 68% superan la fecha de

entrega y el 88% tuvieron que ser sustancialmente rediseados.
Cada 6 nuevos sistemas puestos en funcionamiento, 2 son cancelados, la
probabilidad de cancelacin est alrededor del 50% para sistemas grandes, la
media de proyectos que sobrepasa el calendario es del 50%, 3 de cada 4 sistemas
son considerados como fallos de operacin.
El 74% de todos los proyectos de tecnologas de la informacin fallan porque se
pasan de presupuesto, porque no cumplen el plazo de entrega y el 28% de los
proyectos fallan completamente.
Cada ao se gastan 75 billones de dlares en proyectos de tecnologas de la
informacin fallidos en USA.
El 52,7% de los proyectos relacionados con las tecnologas de la informacin
cuestan el 189% de su coste inicial estimado
En grandes compaas, donde la media de coste de un proyecto de desarrollo es
de $2,322,000 dlares, slo el 9% de los proyectos estuvieron en la fecha prevista
y dentro del presupuesto.
El 31% de los proyectos se cancelan antes de completarse.
Cerca de la mitad de los proyectos de desarrollo cuestan un 70% ms de lo que
inicialmente fue presupuestado. Los gestores citan a la falta de informacin de los
usuarios como principal razn para el fallo de un proyecto.

Historias preocupantes
Un caso divertido?

El computador de un hospital comete un error fatal: De acuerdo con esto, estoy

muerto
o El problema sucedi durante una actualizacin rutinaria de los ficheros del
ordenador del Hospital Saint Marys en octubre, Jennifer Cammenga, la
portavoz del Saint Marys, declar al Grand Rapid Press Un dgito fue
omitido en el cdigo, indicando que los pacientes haban fallecido, en lugar
de indicar que haban sido dados de alta- Noticia de prensa del 8 de enero
de 2003.

Casos no tan divertidos

Varias muertes de pacientes de cncer acaecidas entre 1985-1987 se debieron a

3

una sobredosis de radiacin debida a un problema en las tareas concurrentes en

el
software
de
la
mquina
de
radioterapia
Therac-25
http://sunnyday.mit.edu/therac-25.html, Leveson y Turner, 1993; Leveson, 1995.
En mayo de 2001 la Agencia Internacional para la Energa Atmica declar una
emergencia radiolgica en Panam. 28 pacientes sufrieron una sobre exposicin,
8 murieron, y partes de los supervivientes pueden sufrir serias complicaciones
que en algunos casos pueden llegar a ser mortales. Se concluy que uno de los
factores que provocaron el accidente se debi a un error en el software que
controlaba
ciertas
entradas
de
datos
http://www.fda.gov/cdrh/ocd/panamaradexp.html
Servicio de Ambulancias de Londres, 1992. Fallo en las pruebas de instalacin del
sistema y su compatibilidad con los ya existentes provocaron prdida de llamadas
y
salidas
mltiples
debidas
a
llamadas
duplicadas
http://www.cs.ucl.ac.uk/staff/A.Finkelstein/las.html, Finkelstein y Dowell 1996.
El fallo en el lanzamiento del satlite Ariane 5 en 1996 fue causado por una rutina
de excepcin defectuosa en el cdigo Ada, que se invocaba como resultado de
una conversin errnea de un nmero en coma flotante de 64 bits a un entero de
16 bits
Dos oficiales de polica en una regin escocesa utilizaban una pistola de radar
para identificar a motociclistas que infringan los lmites de velocidad.
Repentinamente la pistola de radar qued bloqueada apuntando al cielo e
indicando una velocidad de 300 millas por hora. Segundos ms tarde, un caza
Harrier, volando a baja altura, pas por all. El buscador de blancos del avin
haba detectado el radar y lo haba tomado por un enemigo. Por fortuna, el Harrier
volaba desarmado, ya que el comportamiento normal hubiera sido el disparo de
un
misil
de
contraataque
automtico
http://catless.ncl.ac.uk/Risks/17.67.html#subj1.1, Pfleeger, 2002.
El 15 de enero de 1990 la red de comunicaciones de larga distancia de AT&T
estuvo fuera de servicio durante nueve horas a consecuencia de un fallo de
software. Millones de llamadas quedaron bloqueadas. Algunos negocios que
dependan en gran medida de los servicios telefnicos, como agencias de viajes,
quedaron prcticamente colapsados, con la consiguiente prdida econmica.
En febrero de 2003 un fallo en la red de Vodafone deja sin servicio a sus 8,6
millones de usuarios. La avera se produjo en el transcurso de las tareas de
mantenimiento del software de la red llevadas a cabo por la operadora,
impidiendo las comunicaciones con sus lneas en toda Espaa desde las siete de
la maana.
La Mars Polar Lander se estrell en su aterrizaje en Marte en diciembre de 1999
por un fallo de software. Los motores de descenso se apagaron prematuramente
porque un fallo en los sensores indicaban que haba tomado tierra cuando estaba
a unos 40 metros - Clark, 2000.
El robot Spirit en Marte tuvo que ser reseteado y actualizado desde la tierra por
4

fallos en su memoria flash 2004.

Unidad I. Diseo de software

Definicin del diseo
Del italiano disegno, la palabra diseo se refiere a un boceto, bosquejo o esquema que
se realiza, ya sea mentalmente o en un soporte material, antes de concretar la
produccin de algo. El concepto de diseo suele utilizarse en el contexto de las artes, la
arquitectura, la ingeniera y otras disciplinas; y llevarlo a cabo implica una
representacin mental y la posterior plasmacin de dicha idea en algn formato grfico
para exhibir cmo ser la obra que se planea realizar. El diseo, por lo tanto, puede
incluir un dibujo o trazado que anticipe las caractersticas de la obra.
En el diseo de software no slo se debe tener en cuenta aspectos estticos, sino
tambin cuestiones funcionales y tcnicas. Esto exige a los diseadores estudios,
investigaciones y tareas de modelado que le permitan encontrar la mejor manera de
desarrollar el software que pretenden crear. Adems, necesita numerosas fases como
observacin, investigacin, anlisis, pruebas, ajustes, modelados y adaptaciones previas
a la produccin definitiva. Es una tarea compleja, dinmica e intrincada, es la integracin
de requisitos tcnicos, sociales y econmicos y necesidades organizacionales, todo esto
pensado e interrelacionado con el medio que rodea al software que se desea crear.
Para analizar y disear software apropiado, los analistas deben concebir a las
organizaciones en que trabajan como sistemas configurados por la interaccin de tres
fuerzas principales:

Los niveles de administracin.

El diseo de las organizaciones.
Las culturas organizacionales.

Las
organizaciones
son
sistemas
extensos
compuestos
por
subsistemas
interrelacionados. Los subsistemas se ven influenciados por tres amplios niveles de
personas que toman decisiones administrativas (operaciones, administracin a nivel
medio y administracin estratgica) y atraviesan horizontalmente todo el sistema
organizacional. Las culturas y subculturas organizacionales influyen en la forma en que
las personas se interrelacionan en los subsistemas.
El diseo de software, al igual que los mtodos de diseo de todas las ingenieras,
cambian continuamente al aparecer nuevos mtodos, mejores anlisis y ampliar los
conocimientos. El problema es que el diseo de software se encuentra en una etapa
relativamente temprana en su evolucin. La idea de realizar diseo de software en lugar
6

de programar, surgi a principios de los aos 60, por lo que a las metodologas de
diseo les falta la profundidad y la flexibilidad que tiene el diseo en otras ingenieras.
Pero ya existen tcnicas de diseo de software para poder evaluar la calidad del
software.
En resumidas cuentas, la cuestin fundamental del desarrollo del software es la
escritura del cdigo. Despus de todo, los diagramas son slo imgenes bonitas.
Ningn usuario va a agradecer la belleza de los dibujos, lo que el usuario quiere es
software que funcione.
El diseo juega un papel clave en el desarrollo de software porque permite a los
ingenieros de software producir diversos modelos que caracterizan la solucin a
implementar, pueden ser analizados y evaluados con el fin de determinar si se satisfacen
los requisitos, facilitan el examen y evaluacin de alternativas y sirven para planificar las
siguientes actividades del desarrollo.
Una vez que se han establecido los requisitos del software, el diseo es la primera de
tres actividades tcnicas: diseo, codificacin y prueba. Cada actividad transforma la
informacin de forma que al final se obtiene un software validado.
El diseo es tcnicamente la parte central de la ingeniera del software. Durante el
diseo se desarrollan, revisan y se documentan los refinamientos progresivos de las
estructuras de datos, de la estructura del programa y de los detalles procedimentales. El
diseo da como resultado representaciones cuya calidad puede ser evaluada.

Diseo y calidad de software

A lo largo del proceso de diseo, la calidad del diseo se evala mediante una serie de
revisiones tcnicas formales (RTF) que son una actividad de garanta del software cuyos
objetivos son:
1. Descubrir los errores en la funcin, la lgica o la implementacin de cualquier
representacin del software.
2. Verificar que el software alcanza sus requisitos.
3. Garantizar que el software se ha representado segn los estndares establecidos.
4. Conseguir un software desarrollado de forma uniforme.
5. Hacer que los proyectos sean manejables.
Cada RTF se lleva a cabo mediante una reunin y slo tendr xito si est bien
planificada, controlada y atendida.
A continuacin, se listan una serie de criterios para determinar la calidad del software.
1. Un diseo debe tener una organizacin jerrquica.
2. Un diseo debe ser modular, es decir, el software debe estar dividido en elementos
que realicen funciones especficas.
7

3. Un diseo debe tener representaciones distintas y separadas de los datos y de los

procedimientos.
4. Un diseo debe llevar a mdulos que exhiban caractersticas funcionales
independientes.
5. Un diseo debe conducir a interfaces que reduzcan la complejidad de las
conexiones entre los mdulos y el exterior.
6. Un diseo debe obtenerse mediante un mtodo que sea reproducible y que est
dirigido por la informacin obtenida durante el anlisis de requerimientos.
Un buen diseo de software no se consigue fcilmente, resultando de la aplicacin de
principios fundamentales de diseo, de una metodologa sistemtica y de una revisin
exhaustiva.

Caractersticas comunes de las metodologas de diseo

Independientemente de la metodologa de diseo que se utilice, todas tienen varias
caractersticas comunes:
1.
2.
3.
4.

Mecanismo para la traduccin de requisitos en una representacin de diseo.

Notacin para representar los componentes funcionales y sus interfaces.
Heursticas para el refinamiento y la particin.
Criterios para la valoracin de la calidad.

Independientemente de la metodologa de diseo que se utilice, el desarrollador tiene

que aplicar una serie de conceptos fundamentales al diseo de datos, arquitectnico y
procedimental.

Fundamentos del diseo

Los fundamentos del diseo ayudan al desarrollador de software a responder a estas
preguntas:

Qu criterios puedo utilizar para dividir 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 definan la calidad tcnica de un diseo de
software?

El principio de la sabidura de un programador est en reconocer la diferencia entre

obtener un programa que funcione y uno que funcione correctamente - Michael A.
Jackson.

Abstraccin
8

Cuando se considera una solucin modular para cualquier problema, pueden formularse
varios niveles de abstraccin.
En el nivel superior de abstraccin se establece una solucin en trminos generales, en
lenguaje natural. En los niveles inferiores de abstraccin se utiliza una orientacin ms
procedimental. Por ltimo, en el nivel ms bajo de abstraccin, se establece una
solucin, de forma que pueda implementarse directamente.
Cada paso de los procesos de la ingeniera del software es un refinamiento del nivel de
abstraccin de la solucin software. Conforme nos movemos desde los preliminares
hacia el diseo detallado, se reduce el nivel de abstraccin. Finalmente, el nivel ms bajo
de abstraccin se alcanza cuando se genera el cdigo fuente.
Conforme nos movemos por los diferentes niveles de abstraccin, trabajamos para crear
abstracciones de datos y de procedimientos.

Una abstraccin de datos es un conjunto de datos que describen un objeto, como

puede ser el la identificacin de una persona, que est compuesta por conjunto de
partes de informacin, pero que nos podemos referir a todos los datos
mencionando el nombre de la abstraccin de datos.
Una abstraccin procedimental es una determinada secuencia de instrucciones
que tienen una funcin limitada y especfica, como puede ser mover objeto, que
supone la secuencia de pasos abrir pinza, mover hasta posicin de destino 1,
cerrar pinza, mover hasta posicin 2, abrir pinza, mover hasta posicin
origen, cerrar pinza.

Estas abstracciones permiten al diseador representar un objeto a diferentes niveles de

detalle.

Refinamiento
El refinamiento sucesivo es una primera estrategia de diseo descendente propuesta por
Niklaus Wirth. La arquitectura de un programa se desarrolla en niveles sucesivos de
refinamiento de los detalles procedimentales. Se desarrolla una jerarqua
descomponiendo una funcin de forma sucesiva hasta que se llega a las sentencias del
lenguaje de programacin.
Comenzamos con una declaracin de la funcin (o una descripcin de la informacin)
definida a un nivel superior de abstraccin. Es decir, la declaracin describe la funcin o
la informacin conceptualmente, pero no proporciona informacin sobre el
funcionamiento interno de la funcin o sobre la estructura interna de la informacin, sino
que se va a realizando sucesivamente, dando cada vez ms detalles.

Modularidad

El software se divide en componentes con nombres y ubicaciones determinados, que se

denominan mdulos y que se integran para satisfacer los requisitos del proveedor.
El software monoltico (es decir, un programa grande compuesto de un solo mdulo) no
puede ser estudiado fcilmente por un lector, ya que el nmero de caminos de control, el
nmero de variables y la complejidad global haran el cdigo prcticamente
indescifrable.
Esto nos lleva a la conclusin divide y vencers, por tanto la modularidad del software
facilita el desarrollo del mismo, pero hasta un cierto lmite, porque si llegramos a dividir
el problema en infinitos mdulos, los mdulos tendran una complejidad y un esfuerzo
mucho menor, pero crecera el coste asociado a la creacin de interfaces entre los
mdulos.

Arquitectura del software

La arquitectura del software se refiere a dos caractersticas importantes del software:

La estructura jerrquica de los mdulos del software

La estructura de los datos

La arquitectura del software se obtiene mediante un proceso de particin, que relaciona

los problemas del mundo real (definidos en el anlisis de requerimientos) con las
soluciones software para resolver los problemas.

10

Jerarqua de control
Tambin se le conoce como estructura del programa, y representa la organizacin
jerrquica de los mdulos de un programa e implica una jerarqua de control.
La representacin de jerarqua se suele representar con diagramas de rbol, aunque
tambin se pueden utilizar otros tipos de notaciones. A continuacin, un ejemplo de
estructura de programa

Profundidad es el nmero de niveles de control, anchura es la amplitud global del

control, grado de salida es el nmero de mdulos que controla un mdulo y grado de
entrada es el nmero de mdulos que controlan a un mdulo.
11

Estructura de datos
La estructura de datos es una representacin de la lgica que existe entre los elementos
individuales de informacin. Debido a que la estructura de la informacin afectar de
forma determinante al diseo procedimental, la estructura de datos es tan importante
como la estructura del programa en la representacin de la arquitectura del software.
La estructura de datos dicta la organizacin, los mtodos de acceso, el grado de
asociacin y las alternativas para el tratamiento de la informacin.
Las estructuras de datos clsicas son los elementos vectores unidimensionales,
bidimensionales, las listas y los rboles.

Procedimientos del software

La estructura del programa define la jerarqua de control, independientemente de las
decisiones y secuencias de procesamiento. El procedimiento del software se centra en
los detalles de procesamiento de cada mdulo individual.

El procedimiento debe proporcionar una especificacin precisa del procesamiento,

incluyendo la secuencia de sucesos, los puntos concretos de decisiones, la repeticin de
operaciones e incluso la organizacin/estructura de los datos.

12

Como existe una relacin entre la estructura y el procedimiento, ya que el

procesamiento de un mdulo puede suponer la llamada a otros mdulos. A esto se le
conoce como representacin procedimental del software por capas.

Ocultamiento de informacin
El concepto de modularidad nos lleva a esta pregunta: cmo descomponer una solucin
de software en el mejor conjunto de mdulos?
El principio de ocultamiento de la informacin sugiere que los mdulos deben
especificarse de forma que la informacin (procedimientos y datos) contenida dentro de
un mdulo sea inaccesible a otros mdulos que no necesiten tal informacin.
Por tanto se trata de definir una serie de mdulos independientes que se comuniquen
slo a travs de la informacin necesaria para realizar la funcin de software.
El uso de ocultamiento de informacin en el diseo facilitar las modificaciones, prueba
y mantenimiento del software, ya que como la mayora de los datos y de los
procedimientos estn ocultos a otras partes del software, ser menos probable que los
errores que se introduzcan durante la modificacin se propaguen a otros mdulos del
software.

Modelado estructural

13

14