Temas IS

INGENIERA DEL
SOFTWARE
Javier Martn
Centro Asociado de Mstoles /
Tres Cantos
UNED
Introduccin
JAVIER MARTIN (jmartin@escet.urjc.es)

TUTORIAS:
JUEVES/VIERNES de 7 a 9
PLAN DE TRABAJO
Exposicin
de los temas y mediante

transparencia, abundando en los puntos
ms importantes.
Resolucin de dudas
Propuesta y resolucin de ejercicios y
problemas
INGENIERA DEL SOFTWARE Javier Martn
Temas
INTRODUCCIN
ESPECIFICACIN DEL SOFTWARE
FUNDAMENTOS DEL DISEO
SOFTAWARE
TCNICAS GENERALES DE DISEO
SOFTWARE
CODIFICACIN Y PRUEBAS
AUTOMATIZACIN Y PROCESO DE
DESARROLLO
Tema 1: INTRODUCCIN
Concepto de Ingeniera de Sistemas
Concepto de sistema, conjunto de cosas que ordenadamente

relacionadas entre s contribuyen a un determinado objeto. De forma
recursiva, las partes de un sistema pueden ser consideradas como
nuevos sistemas (subsistemas).
Los sistemas informticos estn compuestos por ordenadores y sus
perifricos. Entre ellos podemos distinguir dos tipos de subsistemas:
Sistemas Hardware, son los elementos materiales, los que se
pueden tocar.
Sistemas Software, los programas que gobiernan el
funcionamiento del computador.
El objetivo de los sistemas informticos es el tratamiento de la
informacin: almacenamiento, elaboracin y presentacin de datos. De
esta forma se automatizan determinadas acciones.
En la concepcin del sistema informtico no solo se decide el trabajo a
realizar, sino tambin cmo ha de ser utilizado por los usuarios.
Concepto de Ingeniera del Software
Caractersticas del software (lo contrario para el hardware):

No se desgasta ni envejece, y por este motivo no requiere
reparaciones ocasionales
Su duplicacin es poco costosa, lo caro es el desarrollo
Puede ser modificado fcilmente, tanto que es necesario un control
de versiones
La Ingeniera del Software comprende las tcnicas y procedimientos
ingenieriles para el desarrollo del software.
La IS no se plantea solo una actividad de programacin, previamente
son necesarias las fases de anlisis y diseo y posteriormente la
integracin y la verificacin, incluso el manteniendo cuando el producto
ya est en explotacin. (CICLO DE VIDA).
Inicialmente la tarea de desarrollo era realizada individualmente por
hbiles creativos, de forma poco disciplinada. El trabajo en equipo
supone la divisin y organizacin del trabajo utilizando metodologas
de desarrollo.
En los 70 y los 80 empiezan a usarse herramientas CASE (Computer
Aided Software Engineering). En los 90 IPSE e ICASE.
La crisis del Software
Se produce cuando surge la necesidad de desarrollar

aplicaciones software demasiado complejas, a mediados
de los 60.
Para superar la crisis:
Aparicin de metodologas concretas de desarrollo
Concepcin de la Ingeniera del Software como disciplina
Trabajo en equipo y especializacin (analistas,
programadores, ...)
No se ha llegado a una situacin estable, sino a una

evolucin permanente con avances continuos en la IS,
forzados por el rpido abaratamiento y aumento de
capacidad del hardware.
Mitos del Software
El hardware es mucho ms importante que el

software
El software es fcil de desarrollar
El software consiste exclusivamente en programas
ejecutables
El desarrollo del software es slo una labor de
programacin
Es natural que el software contenga errores
Formalizacin del proceso de desarrollo
La ingeniera supone la existencia de procesos bien

establecidos para la realizacin de actividades de
desarrollo, construccin, fabricacin, etc.
El ciclo de vida es el proceso de desarrollo y
mantenimiento del software. Segn el modelo elegido se
describen un conjunto de actividades para llevar a cabo el
ciclo de vida,
Los modelos clsicos:
MODELO EN CASCADA
MODELO EN V
Prcticamente identifican actividades similares y slo se

diferencian en la forma de presentacin.
MODELO EN CASCADA
10
MODELO EN CASCADA
ANLISIS, determinar qu debe hacer el software ->

especificacin
DISEO, descomponer y organizar el sistema para que los
mdulos puedan ser desarrollados por separado
CODIFICACIN, escribir el cdigo fuente de cada mdulo
y realizar sobre ellos las pruebas necesarias
INTEGRACIN, combinar todos los mdulos y probar el
sistema completo antes de pasar a su explotacin
MANTENIMIENTO, durante la explotacin es necesario
realizar cambios ocasionales bien para corregir errores o
para introducir mejoras,
Se trata de aislar cada fase de las otras, lo que facilita la
especializacin de los desarrolladores. Al final de cada fase
se requiere un proceso de revisin`para evitar que los
errores se propaguen a fases posteriores provocando la
vuelta atrs.
11
MODELO EN CASCADA AMPLIADO
12
MODELO EN CASCADA
Cada fase debe generar una informacin de salida precisa

y suficiente:
DOCUMENTOS DE REQUISITOS DEL SOFTWARE (SRD),
es una especificacin precisa y completa a partir de los
requisitos establecidos por el cliente.
DOCUMENTO DE DISEO DEL SOFTWARE
(SDD),descripcin de la estructura global del sistema,
especificacin de qu debe hacer cada uno de los mdulos y
de cmo se combinan.
CDIGO FUENTE, el programa debidamente comentado
(documentacin interna).
SISTEMA SOFTWARE, el ejecutable producto dela fase de
integracin y la documentacin de las pruebas realizadas.
DOCUMENTOS DE CAMBIOS, despus de cada
modificacin realizada en la fase de mantenimiento: problema
detectado y solucin adoptada
13
MODELO EN V
14
MODELO EN V AMPLIADO
15
MODELO EN V
Incluye fases similares a las del modelo en

cascada pero de forma jerrquica. En horizontal se
representa el avance en el desarrollo y en vertical
el nivel de detalle.
VERIFICACIN, comprobacin de que una parte
del sistema cumple con sus especificaciones.
VALIDACIN, comprobacin de que un elmento
satisface las necesidades del usuario identificadas
durante el anlisis.
16
PROTOTIPOS
En los modelos clsicos se insiste en las actividades de

revisin de resultados al final de cada fase para evitar la
vuelta atrs, que no se contempla de una forma organizada
y resulta muy costosa. Estn orientados a una forma de
desarrollo lineal.
PROTOTIPO, es un sistema auxiliar que permite probar
experimentalmente soluciones parciales a los requisitos del
sistema
Para que el coste de desarrollo del prototipo sea bajo en
relacin al del sistema final podemos:
Limitar las funciones
Limitar su capacidad
Limitar su eficiencia
Evitar limitaciones de diseo, utilizando un hardware ms
potente que el que ejecutar el sistema final
Reducir la parte a desarrollar
17
PROTOTIPOS RPIDOS
Su finalidad es solo adquirir experiencia, no se

aprovechan como producto (usar y tirar). Se
denominan maquetas cuando su funcionalidad o
capacidad es muy limitada.
El sistema final se codifica totalmente partiendo de
cero, no se aprovecha el cdigo del prototipo
Lo importante de estos prototipos es que se
desarrollen en poco tiempo.
18
PROTOTIPOS RPIDOS
19
PROTOTIPOS EVOLUTIVOS
En este caso se intenta aprovechar al mximo el cdigo del

prototipo, y para ello se emplea el mismo
hardware/software del sistema final.
Se realizan fases de anlisis y diseo parcial, que se van
ampliando hasta construir el sistema final mediante
adiciones sucesivas.
Se puede considerar un modelo en cascada en bucle, de
manera que en cada iteracin se va avanzando en el
desarrollo.
HERRAMIENTAS PARA EL DESARROLLO DE
PROTOTIPOS, se emplean lenguajes de 4 generacin,
que son de alto nivel y de tipo declarativo. Tambin se
emplean lenguajes de especificacin, como VDM y Z. Si
disponemos del compilador correspondiente podemos
obtener automticamente el cdigo del prototipo.
En el desarrollo de prototipos es clave la reutilizacin de
20
software.
PROTOTIPOS EVOLUTIVOS
21
MODELO EN ESPIRAL
Puede considerarse como un refinamiento del modelo

evolutivo general que introduce el anlisis de riesgo como
elemento fundamental para guiar la evolucin del proceso
de desarrollo.
En la dimensin radial se representa el esfuerzo realizado
en el desarrollo (siempre creciente)
En cada iteracin 4 fases:
PLANIFICACIN, determina que parte del desarrollo se
abordar en ese ciclo.
ANALISIS DE RIESGO, evaluar diferentes alternativas para
esa parte del desarrollo seleccionando la ms ventajosa y
tomando precauciones para evitar los posibles
inconvenientes.
INGENIERA, las actividades de los modelos clsicos
EVALUACIN, se analizan los resultados de la fase de
ingeniera.
22
MODELO EN ESPIRAL
23
MANTENIMIENTO DEL SOFTWARE
El mantenimiento no representa una actividad especfica,

sino que consiste en rehacer parte de las actividades
correspondientes a las otras fases del desarrollo para
introducir cambios sobre una aplicacin ya en fase de
explotacin.
MANTENIMIENTO CORRECTIVO, su finalidad es corregir
errores que no fueron detectados en el desarrollo del
producto.
MANTENIMIENTO ADAPTATIVO, modificar una aplicacin
para adaptarla a las nuevas necesidades del entorno.
MANTENIMIENTO PERFECTIVO, se trata de ir obteniendo
versiones mejoradas del producto
24
GESTIN DE CAMBIOS
El mantenimiento supone la realizacin de una serie de

cambios sucesivos
Si afectan a la mayor parte del sistema se puede plantear
como un nuevo desarrollo.
Cada cambio debe ser documentado con:
INFORME DEL PROBLEMA, que ocasiona el cambio. Suele
ser propuesto por el cliente.
INFORME DE CAMBIO, describe la solucin dada al
problema y el cambio realizado
REINGENIERA, es necesaria cuando el desarrollo de una

aplicacin no est documentado y se dispone solamente
del cdigo. Se llama tambin ingeniera inversa porque
supone reconstruir y documentar las fases de anlisis y
diseo llegando a la estructura modular de la aplicacin y
las dependencias entre mdulos y funciones. Estas
actividades organizan
y documentan un sistema deficiente.25
GARANTA DE CALIDAD
Para evaluar la calidad son necesarias tcnicas de aplicacin de mtricas precisas

tanto sobre los productos software como a sus procesos de desarrollo.
McCall propone un esquema basado en valoraciones a 3 niveles:
FACTORES, valoracin significativa de la calidad en base a los criterios
establecidos
CRITERIOS, aspectos de nivel intermedio que influyen en los factores de calidad
MTRICAS, mediciones puntuales de determinadas caractersticas del producto.
Entre los factores de calidad tenemos:
CORRECCIN, grado en que cumple con las especificaciones
FIABILIDAD, grado de ausencia de fallos
EFICIENCIA, reilacin entre la cantidad de resultados y los recursos requeridos
SEGURIDAD, dificultad para el acceso a datos por personas no autorizadas
FACILIDAD DE USO, esfuerzo requerido para el aprendizaje de la aplicacin
MANTENIBILIDAD. Facilidad para corregir el producto en caso necesario.
FLEXIBILIDAD, facilidad para modificar el producto
FACILIDAD DE PRUEBA, depende del esfuerzo requerido para comprobar su
correccin o fiabilidad
TRANSPORTABILIDAD, facilidad para adaptar el producto a otra plataforma
REUSABILIDAD, facilidad para usar partes del producto en otros desarrollos
26
INTEROPERATIVIDAD, facilidad del producto para trabajar con otros
PLAN DE GARANTA DE CALIDAD (SQAP)
Es un documento formal para organizar el proceso de

desarrollo software de manera que se asegure la calidad
del producto final. Debe contemplar:
Organizacin, direccin y seguimiento de los equipos de
desarrollo
Modelo de ciclo de vida a seguir, detallando fases y
actividades
Documentacin requerida, determinando contenido y guin
de cada documento
Revisiones y auditorias, para garantizar que las actividades y
los documentos son correctos
Organizacin de las pruebas, a distintos niveles
Organizacin de la etapa de mantenimiento, determinando
cmo gestionar la realizacin de cambios
27
REVISIONES
Consiste en inspeccionar el resultado de una actividad para

determinar si es aceptable o contiene defectos que han de
ser subsanados.
Las revisiones deben ser formalizadas y contempladas en
el modelo de ciclo de vida:
Deben ser realizadas por un grupo de personas y no
individualmente
El grupo de be ser reducido
Debe ser imparcial, nada que ver con los desarrolladores
Se debe revisar el producto, pero no el productor ni el
proceso de produccin
Se debe establecer de antemano una lista formal de
comprobaciones
Se debe levantar acta de la reunin de revisin, recogiendo
las decisiones tomadas
28
PRUEBAS
Consiste en hacer funcionar el producto o una

parte de l y comprobar si los resultados son
correctos.
No permite garantizar la calidad del producto. En
general no es posible probar un producto de forma
exhaustiva, debido a su complejidad.
29
GESTIN
DE
CONFIGURACIN
CONFIGURACIN, disposicin de las partes que componen una cosa y le
dan su peculiar figura.
La CONFIGURACN SOFTWARE se refiere a la manera en que diversos
elementos se combinan para construir un producto software.
Se han de combinar todos los elementos que intervienen en el desarrollo:
Documentos del desarrollo
Cdigo fuente
Programas, datos y resultado de las pruebas
Manuales de usuario
Documentos de mantenimiento, informes de problemas y cambios
Prototipos intermedios
Normas particulares del proyecto
Dado que los elementos software van evolucionando a lo largo del
desarrollo se requiere:
Control de versiones, almacenar de forma organizada las sucesivas
versiones de cada elemento de la configuracin.
Control de cambios, garantizar que las diferentes configuraciones del
software se componen de elementos compatibles entre s (lnea base).
30
NORMAS Y ESTNDARES
IEEE, Institute of Electrical and Electronics

Engineer de USA [IEEE93]
DoD, Departament od Defense de USA [DoD88]
ESA, Agencia Europea del Espacio [ESA91]
ISO, organismo internacional de normalizacin
(International Standars Organization). En Espaa
AENOR.
METRICA-2, desarrollada por el Consejo Superior
de Informtica del MAP. Se basa en la
metodologa de anlisis y diseo de
Yourdon/DeMarco.
31
Tema 2:
ESPECIFICACIN DE SOFTWARE
32
MODELADO DE SISTEMAS
El anlisis y la definicin de los requisitos debe dar lugar a

la especificacin software, en la que se concretan las
necesidades que se desean cubrir y se fijan las
restricciones con las que debe trabajar el software.
El modelado de los sistemas tiene como objetivo entender
mejor el comportamiento requerido y facilitar la
comprensin de los problemas planteados. Se trata de
establecer modelos conceptuales que reflejen la
organizacin de la informacin y las diversas
transformaciones que se deben llevar a cabo con dicha
informacin.
Las metodologas de anlisis de requisitos tratan de
facilitara obtencin de uno o varios modelos que detallen el
comportamiento deseado del sistema.
33
CONCEPTO DE MODELO
Un modelo conceptual es una abstraccin lgicomatemtica del mundo real que facilita la comprensin del
problema a resolver. Se trata de ofrecer una visin de lato
nivel, sin descender a explicar detalles concretos del
mismo. Indica QU hace el sistema y no CMO lo debe
hacer.
Los OBJETIVOS a cubrir con los modelos son:
Facilitar la comprensin de l problema
Establecer un marco para la discusin que simplifique y
sistematice el anlisis
Fijar las base para el diseo
Facilitar la verificacin del cumplimiento de los objetivos del
sistema
34
TCNICAS DE MODELADO (I)
DESCOMPOSICIN. MODELO JERARQUIZADO, aplica el divide y

vencers, y as el problema queda dividido en un subconjunto de
subproblemas. Se trata de una descomposicin funcional que se
denomina horizontal o bien se descompone tratando de detallar la
estructura, de forma vertical. Para completar el modelado es necesario
establecer los interfaces entre las partes del sistema para posibilitar el
funcionamiento del sistema global.
APROXIMACIONES SUCESIVAS, podemos tomar como partida el
modelo de un sistema similar, y luego mediante la experiencia del
analista y el conocimiento del problema que proporciona el experto se
irn proponiendo modelos intermedios, discutiendo sus ventajas e
inconvenientes.
EMPLEO DE DIVERSAS ANOTACIONES, el lenguaje natural
introduce imprecisiones, repeticiones e incluso incorrecciones en el
modelo. Es recomendable emplear notaciones grficas que sean
entendibles por todos los que participan en el proyecto. Se suele
recurrir a notaciones precisas que combinan texto, tablas, diagramas y
grficos.
35
TCNICAS DE MODELADO (II)
CONSIDERAR DISITNTOS PUNTOS DE VISTA, en la

elaboracin del modelo es necesario adoptar un determinado
punto de vista. Si as la descripcin es insuficiente conviene
adoptar ms de uno.
REALIZAR UN ANLISIS DEL DOMINIO, es decir en campo
de aplicacin en que se enmarca el sistema a desarrollar. Hay
que considerar:
Normativa que afecta al sistema
Otros sistemas semejantes
Estudios recientes en el campo de la aplicacin, bibliografa, etc.
Las ventajas de realizar un modelos ms general son:

Facilitar la comunicacin entre el analista y el usuario del sistema,
p.e. usando la misma terminologa.
Creacin de elementos realmente significativos del sistema, si se
ajusta a la normativa especfica establecida.
Reutilizacin posterior del software desarrollado.
36
ANLISIS DE REQUISITOS DE SOFTWARE
El anlisis es la fase de definicin del futuro sistema y tiene una importancia decisiva
en el desarrollo de todas las etapas posteriores.
Con el anlisis de requisitos se trata de caracterizar el problema a resolver. El
cliente trabaja con el analista para elaborar las especificaciones y posteriormente
se encargarn de verificar el cumplimiento de las mismas (contrato).
El anlisis debe producir un modelo vlido necesario y suficiente para recoger todas
las necesidades y exigencias del sistema, as como las restricciones que los limiten.
Para una especificacin correcta se requiere:
Completo y sin omisiones
Conciso y sin trivialidades
Sin ambigedades
Sin detalles de diseo o implementacin
Fcilmente entendible por el cliente
Separando requisitos funcionales u no funcionales (capacidades mnimas y
mximas, interfaces estndares, recursos necesarios, seguridad, fiabilidad,
mantenimiento, etc.
Divisin y jerarqua del modelo global, con el fin de simplificar su comprensin
Incluyendo los criterios de validacin del sistema, para comprobar si se ajusta al
contrato inicial.
37
TAREAS DEL ANLISIS
Dependiendo de las caractersticas y complejidad del sistema

se podrn seguir los siguientes pasos:
ESTUDIO DEL SISTEMA EN SU CONTEXTO, anlisis del
dominio en un contexto globalizador
IDENTIFICACIN DE NECESIDADES, detectar necesidades de
medios dentro de plazos y presupuestos
ANLISIS DE ALTERNATIVAS Y ESTUDIO DE VIABILIDAD,
tanto tcnica como econmica
ESTABLECIMIENTO DEL MODELO DEL SISTEMA, para lo que
podemos usar tcnicas grficas, texto, herramientas CASE, etc.
ELABORACIN DEL DOCUMENTO DE ESPECIFICACIN DE
REQUISITOS, dnde se recogen las conclusiones del anlisis y
sirve de punto de partida para el diseador.
REVISIN CONTINUADA DEL ANLISIS, a menudo en las
etapas de diseo e implementacin se hace necesaria la revisin
de alguno de los requisitos, o bien por cambios de criterio del
cliente
38
NOTACIONES PARA LA ESPECIFICACIN
La especificacin es una descripcin del modelo del

sistema a desarrollar.
Se debe usar una notacin fcil de entender por el cliente:
Lenguaje natural, utilizando explicaciones ms o menos
precisas y exhaustivas. Es posible limitar precisiones y
ambigedades si se establecen reglas de uso del lenguaje.
Diagramas de flujo de datos
Diagramas de transicin de estados
Descripciones funcionales. Pseudocdigo. Se emplea un
preciso lenguaje natural estructurado. No se debe detallar
demasiado el cmo, pues esto corresponde a la fase de
diseo, donde se usan lenguajes estructurados como PLD.
Descripcin de datos, de trata de detallar la estructura interna
de los datos que maneja el sistema. En la metodologa
Yourdon se conoce como diccionario de datos, incluyendo
nombre de cada dato, utilizacin y estructura.
Diagramas de modelos de datos
39
DIAGRAMAS DE FLUJO DE DATOS (DFD)
Se trata de realizar un modelo grfico para representar el flujo de datos

que entra en el sistema, las transformaciones que debe realizar y la
salida producida. Tambin se representan las entidades externas la
sistema que producen o consumen datos. El DFD inicial es el de
contexto, posteriormente y de forma jerrquica se van desarrollando
otros DFDs que detallan las transformaciones, las entradas y salidas
del diagrama detallado deben coincidir con el proceso correspondiente.
Recoge de forma esttica los procesos, dnde en el ltimo nivel de
refinamiento se especifican en lenguaje natural estructurado, y su
interrelacin.
40
DIAGRAMAS DE TRANSICIN DE ESTADOS
Describe el comportamiento dinmico del sistema

basndose en sus estados ms importantes.
Al igual que en los autmatas de estados finitos,
los eventos motiva el cambio de estado del
sistema.
41
DIAGRAMAS DE MODELO DE DATOS
Se trata de organizar e interrelacionar los datos

que utiliza el sistema.
El MODELO ENTIDAD-RELACIN permite definir
todos los datos y establecer las relaciones que
deben existir entre ellos.
42
DOC. DE ESPECIFICACIN DE REQUISITOS
El documento o la especificacin de requisitos (SRD o

SRS) recoge de forma integral los resultados del anlisis.
Puede haber documentos previos al SRD, como estudios
de viabilidad o de alternativas posibles.
El SRD debe ser revisado con cierta frecuencia durante el
desarrollo y debe facilitar la varificacin de las
especificaciones (contrato).
Diversos organismos de estandarizacin hacen propuestas
sobre la estructura del SRD: IEEE, DoD, etc. Vemos el
modelo de SRD de la Agencia Espacial Europea.
Dependiendo de las caractersticas y complejidad del
proceso tal vez no sea necesario cubrir todos los
apartados.
43
MODELO DE SRD
1.
Introduccin
1.
Objetivo: objetivos, participantes, calendario,...
2.
3.
4.
5.
2.
mbito, identificar y dar nombre al producto

Definiciones, siglas y abreviaturas
Referencias, la descripcin bibliogrfica de los documentos referenciados.
Panormica del documento
Descripcin general
1.
2.
3.
4.
5.
6.
7.
Relacin con otros proyectos, similares o complementarios

Relacin con proyectos anteriores o posteriores
Objetivo y funciones
Consideraciones de entorno
Relaciones con otros sistemas, que utilicen entradas o salidas indirectas de
informacin
Restricciones generales: metodologas, lenguajes, de hardware,...
Descripcin del modelo, es el apartado ms extenso y ms importante. Se
utilizan todas las notaciones y herramientas disponibles
44
MODELO DE SRD
3.
4.
Requisitos especficos, lista detallada y completa de los requisitos del sistema, indicando su
grado de cumplimiento (obligatorio, recomendable, opcional. No incluir aspectos de diseo o
desarrollo, ni tampoco soluciones particulares que no sean obligadas
3.
Requisitos especficos, QU debe hacer el sistema especificando el tratamiento de
la informacin.
4.
Requisitos de interfase, conexin con otros sistemas con los que interacta (bases
de datos, ficheros, SSOO,...).
5.
Requisitos de operacin, es decir, del interfaz de usuario
6.
Requisitos de capacidad, volumen procesador, tiempo respuesta, tamao ficheros.
Se debe cuantificar para el peor, el mejor y el caso ms habitual.
7.
Requisitos de verificacin, que debe cumplir el sistema para que se posible verificar
su correccin
8.
Requisitos de pruebas de aceptacin
9.
Requisitos de recursos, instalaciones y elementos necesarios para el
funcionamiento del sistema
10.
Requisitos de documentacin
11.
Requisitos de transportabilidad, para adaptalo a otras plataformas
12.
Requisitos de calidad, que no hayan sido recogidos en otros apartados
13.
Requisitos de fiabilidad, imponiendo un lmite aceptable de fallos
14.
Requisitos de mantenibilidad
15.
Requisitos de seguridad, contra utilizacin indebida
16.
Requisitos de salvaguarda, para evitar consecuencias graves en equipos o en
personas
APENDICES, para complementar el contenido del documento
45
VIDEOJUEGO DE LAS MINAS
46
SISTEMA DE GESTIN DE BIBLIOTECA
47
48
49
50
51
Tema 3:
FUNDAMENTOS DEL DISEO DEL
SOFTWARE
52
CONCEPTO DE DISEO
Descripcin o bosquejo de alguna cosa hecho por

palabras.
En un sistema software la realizacin del diseo parte del
SRD y no es nada trivial. Cuando no se tiene experiencia
en el desarrollo concreto se hace de forma iterativa
mediante ensayo y error, en caso contrario se aprovecha el
know-how (saber hacer).
Las tcnicas para realizar diseos nuevos son empricas y
no estn suficientemente formalizadas, mientras que para
proyectos ya conocidos, como los de gestin, existen
herramientas tales como lenguajes de 4 generacin.
En el diseo se establece el CMO debe funcionar el
sistema, determinando la organizacin y la estructura del
software.
53
ACTIVIDADES DE UN DISEO SISTEMTICO

DISEO ARQUITECTNICO, se abordan los aspectos
estructurales y de organizacin del sistema, y su posible
divisin en subsistemas
DISEO DETALLADO, organizacin y estructura de los

mdulos
DISEO PROCEDIMENTAL, organizacin de las

operaciones o servicios que ofrecer cada mdulo. Se
suele realizar en pseudocdigo o PDL, pero desarrollando
slo los aspectos ms relevantes del algoritmo
DISEO DE DATOS, organizacin de la base d edatos del

sistema. Se parte de los diagramas E-R.
DISEO DE LA INTERFAZ DE USUARIO, organizar y

facilitar la utilizacin del sistema por parte del usuario
El resultado de estas actividades debe plasmarse en el
Documento d Diseo
Software (SDD)
54
CONCEPTOS PARA EL DISEO
ABSTACCIN, identificar los elementos significativos del sistema y abstraer la utilidad especfica de cada uno
ABSTRACCIONES FUNCIONALES, sirven para crear expresiones parametrizadas usando funciones o
procedimientos
TIPOS ABSTRACTOS, junto con el tipo de datos se deben crear los mtodos que manejan estos datos
MQUINAS ABSTRACTAS, definicin formal del comportamiento de una mquina
MODULARIDAD, el diseo modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. Sus
ventajas: claridad, reduccin de costos y reutilizacin
REFINAMIENTO, a partir de una idea no muy concreta se va refinando mediante aproximaciones hasta el detalle
ESTRUCTURAS DE DATOS, para organizar la informacin que maneja el sistema: registros, conjuntos, listas, pilas,
colas, rboles, grafos, tablas, ficheros, ...
OCULTACIN, de la organizacin de los datos internos y de los detalles del algoritmo, se muestra en el interfaz slo
aquello que resultar invariable ante cambios. Ventajas: depuracin, mantenimiento, ...
GENERICIDAD, consiste en disear un elemento genrico, con las caractersticas comunes a todos los elementos
agrupados
HERENCIA, los elementos hijos heredan del padre su estructura y operaciones para ampliarlos, mejorarlos o
adaptarlos. Es conveniente utilizar un lenguaje de programacin orientado a objetos
POLIMORFISMO, es la propiedad de los elementos que pueden variar su formar sin cambiar su naturaleza. Se
emplea el concepto de genericidad. En los hijos se puede producir la anulacin de una operacin. A veces en el
padre interesa declarar un mtodo sin implementarlo, lo harn los hijos en diferido
CONCURRENCIA, se trata de aprovechar al mximo el procesador garantizando unos tiempos mximos de
respuesta para tareas crticas. Problemas de los sistemas con restricciones:
Tareas concurrentes, asegurar que todas cumplen sus restricciones
Sincronizacin de tareas, determinando los puntos de sincronizacin entre ellas
Comunicacin entre tareas, unas sern productoras de datos y otras consumidoras. Para evitar la corrupcin
de datos compartidos permitir slo concurrencia en lectura con semforos, monitores y regiones crticas
Interbloqueos (deadlock) cuando varias tareas esperan un evento que nunca se producir
55
NOTACIONES PARA EL DISEO
Debe resultar precisa, clara y fcil de interpretar.

Se emplean notaciones formales
cuasimatemticas
NOTACIONES ESTRUCTURALES, se desglosa y
estructura el sistema en sus partes
DIAGRAMAS
CAJAS
DE BLOQUES
ADOSADAS
56
DIAGRAMAS DE ESTRUCTURA
(Yourdon)
Describen la estructura de los sistemas software como una
jerarqua de mdulos, reflejando slo su organizacin
esttica
RECTNGULO,
mdulo
LNEA, relacin
entre mdulos, el
superior utiliza el
mdulo inferior
ROMBO, opcional
ARCO, repetitiva
CIRCULO CON
FLECHA, envio de
datos o informacin
de control (correcto,
repetir, desconectar,
etc)
57
DIAGRAMAS HIPO (Hierachy-InputProcess-Output)

Se muestra primero la
jerarqua entre los
mdulos del sistema
Y en los diagramas
HIPO de detalle
hay 3 zonas:
Entrada, Proceso y
Salida
58
DIAGRAMAS DE JACKSON
El proceso de diseo es sistemtico y se
lleva a cabo en tres pasos:
Especificacin de la estructura de datos de
entrada y de salida
Obtencin de la estructura del programa
Expansin de la estructura del programa

para lograr el diseo detallado
59
NOTACIONES ESTTICAS
Describen las caractersticas estticas del sistema, tales

como la organizacin de la informacin, sin tener en cuenta
su evolucin durante el funcionamiento del sistema.
Las notaciones son las mismas que se emplean en la
especificacin:
DICCIONARIO DE DATOS, dnde se detalla la estructura
interna de los datos que maneja el sistema. En el diseo se
ampla y se completa el diccionario de la especificacin hasta
el nivel de detalle necesario para iniciar la codificacin.
DIAGRAMAS ENTIDAD-RELACIN, definiendo las
relaciones entre datos y la organizacin de la informacin. Se
amplia y detalla el diagrama de la especificacin con las
nuevas entidades y relaciones.
60
NOTACIONES DINMICAS
Permiten describir el funcionamiento del sistema

durante su funcionamiento.
Las notaciones son las misma utilizadas en la
especificacin:
DIAGRAMAS
DE FLUJO DE DATOS, sern mucho

ms exhaustivos que los de la especificacin.
DIAGRAMAS DE TRANSICIN DE ESTADOS,
ms detallados que reflejen las transiciones entre
estados internos.
LENGUAJE DE DESCRIPCIN DE PROGRAMAS
(PLD), permite realizar la especificacin funcional
del sistema.
61
NOTACIONES HIBRIDAS: DIAGRAMAS

DE ABSTRACCIONES
Permiten un enfoque globalizado del diseo atendiendo a aspectos estticos (datos), dinmicos
(operaciones) y de estructura del sistema.
DIAGRAMAS DE ABSTRACCIONES, se contemplan dos tipos de abstracciones: las funciones y los tipos abstractos de
datos.
En una abstraccin se distinguen 3 partes:
NOMBRE, es su identificador
CONTENIDO, dnde se define la organizacin de los datos
OPERACIONES, para manejar el contenido de la abstraccin
Las abstracciones funcionales (funciones o procedimientos), slo tiene la parte de operacin.
El dato encapsulado tiene como el tipo abstracto contenido y operaciones, pero no permite declarar otras variables de su
mismo tipo.
En los diagramas se muestra la relacin

jerrquica entre abstracciones, de manera
que la abstraccin superior utiliza la inferior.
62
NOTACIONES HIBRIDAS: DIAGRAMAS

DE OBJETOS
Se emplea una terminologa distinta, pero las similitudes con los diagramas de abstracciones es muy grande,
excepto que:
1.
No existe nada equivalente a los datos encapsulados ni a las abstracciones funcionales en el modelo de
objetos
2.
En los diagramas de objetos hay relaciones de herencia
De acuerdo con las propiedades de los objetos

podemos tener relaciones especiales entre ellos:
CLASIFICACIN, ESPECIALIZACIN O HERENCIA
COMPOSICIN, permite describir un objeto mediante
los elementos que lo forman
63
DOCUMENTOS DE DISEO: ADD
1. INTRODUCCIN Para dar una visin general de todo el documento. Los contenidos de los apartados como en el SRD
1.1 Objetivo ...
1.2 mbito
1.3 Definiciones, siglas y abreviaturas
1.4 Referencias
2. PANORMICA DEL SISTEMA, visin general de los requisitos funcionales y de otro tipo del sistema a disear
3. CONTEXTO DEL SISTEMA, si posee conexiones con otros
3.n Definicin de interfaz externa
4. DISEO DEL SISTEMA, se describe el nivel superior del diseo del sistema
4.1 Metodologa de diseo de alto nivel
4.2 Descomposicin del sistema , primer nivel de descomposicin del sistema en sus componentes principales
5. DISEO DE LOS COMPONENTES, se procede a la decripcin detallada de l,os componentes mencionados en 4.2
5.n Identificador del componente
5.n.l Tipo (subprograma, mdulo, procedimiento, proceso, datos
5.n.2 Objetivo, o necesidad de que exista el componente
5.n.3 Funcin , lo que hace el componente
5.n.4 Subordinados, se enumeran todos los componentes que utiliza
5.n.5 Dependencias y su naturaleza: invocacin de operacin, datos compartidos, inicializacin, creacin, etc.
5.n.6 Interfases, de cmo otros componentes interactan con ste
5.n.7 Recursos , elementos usados por el componente
5.n.8 Referencias, que se han utilizado en el texto
5.n.9 Proceso, algoritmos o reglas que utiliza el componente para realizar su funcin
5.n.l0 Datos, descripcin de los datos, su tipo, sus valores iniciales, se puede realizar con un diccionario de datos
6. VIABILIDAD y RECURSOS ESTIMADOS
7. MATRIZ REQUISITOS/COMPONENTES, se pone en las filas los requisitos y en las columnas los componentes
64
DOCUMENTOS DE DISEO: DDD

Parte 1. DESCRIPCIN GENERAL
1. INTRODUCCIN
1.1 Objetivo
1.2 mbito
1.3 Definiciones, siglas y abreviaturas
1.4 Referencias
1.5 Panormica
2. NORMAS, CONVENIOS y PROCEDIMIENTOS
2.1 Normas de diseo de bajo nivel
2.2 Normas y convenios de documentacin
2.3 Convenios de nombres (ficheros, programas, mdulos, etc.)
2.4 Normas de programacin
2.5 Herramientas de desarrollo de software
Parte 2. ESPECIFICACIONES DE DISEO DETALLADO
n. Identificador del componente
n.l Identificador
n.2 Tipo
n.3 Objetivo
n.4 Funcin
n.5 Subordinados
n.6 Dependencias
n.7 Interfases
n.8 Recursos
n.9 Referencias
n.l0 Proceso
n.ll Datos
APNDICE A. LISTADOS FUENTE
APNDICE E. MATRIZ REQUISITOS/COMPONENTES
65
Tema 4:
TCNICAS GENERALES DE
DISEO SOFTWARE
66
TCNICAS DE DISEO
Los objetivos de las tcnicas de diseo software son

fundamentalmente:
La descomposicin modular del sistema
Los diseos de los algoritmos y estructuras de datos
fundamentales que se deben usar en el sistema
Primero veremos las caractersticas deseables de una

buena descomposicin modular del sistema, y luego se
presentarn tcnicas de diseo:
Diseo funcional descendente
Diseo orientado a objetos
Diseo de datos
67
DESCOMPOSICIN MODULAR
Los pasos a seguir son:

1.
Identificar los mdulos
2.
Describir cada mdulo
3.
Describir las relaciones entre mdulos
Tipos de mdulos:
1.
Cdigo fuente, en el lenguaje de programacin usado
2.
Tabla de datos, para datos de inicializacin u otros
3.
Configuracin, se agrupa en un mdulo toda la informacin de
configuracin en el entorno de trabajo
4.
Otros: ficheros de ayuda en lnea, manuales, etc.
Una descomposicin modular debe poseer ciertas cualidades mnimas
para que se pueda considerar suficientemente vlida
Independencia fucional
Acoplamiento
Cohesin
Comprensibilidad
Adaptabilidad
68
DESCOMPOSICIN MODULAR: INDEPENDENCIA FUNCIONAL
Al final de los documentos ADD y DDD debe haber una matriz

REQUISITOS/COMPONNETES. En principio, cada funcin ser realizada en
un mdulo distinto. Si las funciones son independientes los mdulos tendrn
independencia funcional.
Cada mdulo debe realizar una funcin concreta o un conjunto de funciones
afines. Es recomendable reducir las relaciones entre mdulos al mnimo.
Para medir la independencia funcional hay dos criterios: acoplamiento y
cohesin.
DESCOMPOSICIN MODULAR: ACOPLAMIENTO
El grado de acoplamiento mide la interrelacin entre dos mdulos, segn el tipo de conexin y la
complejidad de la interfase:
FUERTE,
POR CONTENIDO, cuando desde un mdulo se pueden cambiar datos locales de otro
COMN, se emplea una zona comn de datos a la que tienen acceso varios mdulos
MODERADO,
DE CONTROL, la zona comn es un dispositivo externo al que estn ligados los mdulos,
esto implica que un cambio en el formato de datos afecta a todos estos mdulos
POR ETIQUETA, en ontercambio de datos se realiza mediante una referencia a la
estructura completa de datos (vector, pila, rbol, grafo, ...)
DBIL,
DE DATOS, viene dado por los datos que intercambian los mdulos. Es el mejor posible
SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe
69
DESCOMPOSICIN MODULAR: COHESIN
Es necesario lograr que el contenido de cada mdulo tenga la mxima coherencia. Para que el n de
mdulos no sea demasiado elevado y complique el diseo se tratan de agrupar elementos afines y
relacionados en un mismo mdulo.
ALTA
COHESIN ABSTRACCIONAL, se logra cuando se disea el mdulo como tipo abstracto

de datos o como una clase de objetos
COHESIN FUNCIONAL, el mdulo realiza una funcin concreta y especfica
MEDIA
COHESIN SECUENCIAL, los elementos del mdulo trabajan de forma secuencial
COHESIN DE COMUNICACIN, elementos que operan con le mismo conjunto de datos

de entrada o de salida
COHESIN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej.

Arrancar o parar dispositivos
BAJA
COHESIN LGICA, se agrupan elementos que realizan funciones similares. Ejs.: mdulos
de E/S o de tratamiento de errores
COHESIN COINCIDENTAL, es la peor y se produce cuando los elementos de un mdulo

no guardan relacin alguna
La descripcin del comportamiento de un mdulo permite establecer el grado de cohesin:
Si es una frase compuesta y contiene ms de un verbo la cohesin ser MEDIA
Si contiene expresiones secuenciales (primero, entonces, cuando...), ser temporal o secuencial
Si la descripcin no se refiere a algo especfico (Ej. Todos los errores), cohesin lgica
Si aparece inicializar, preparar, configurar, probablemente sea temporal.

70
DESCOMPOSICIN MODULAR: COMPRENSIBILIDAD
Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es

necesario que cada uno sea comprensible de forma aislada. Para ello es bueno
que posea independencia funcional, pero adems es deseable:
IDENTIFICACIN, el nombre debe ser adecuado y descriptivo
DOCUMENTACIN, debe aclarar todos los detalles de diseo e

implementacin que no queden de manifiesto en el propio cdigo
SIMPLICIDAD, las soluciones sencillas son siempre las mejores
DESCOMPOSICIN MODULAR: ADAPTABILIDAD
La adaptacin de un sistema resulta ms dificil cuando no hay independencia

funcional, es decir, con alto acoplamiento y baja cohesin, y cuando el diseo
es poco comprensible. Otros factores para facilitar la adaptabilidad:
PREVISIN, es necesario prever que aspectos del sistema pueden ser

susceptibles de cambios en el futuro, y poner estos elementos en mdulos
independientes, de manera que su modificacin afecte al menor nmero de
mdulos posible
ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de

especificacin, diseo, e implementacin para obtener un conocimiento
suficiente del sistema antes de proceder a su adaptacin
CONSISTENCIA, despus de cualquier adaptacin se debe mantener la

consistencia del sistema, incluidos los documentos afectados
71
TCNICAS DE DISEO FUNCIONAL DESCENDENTE
La descomposicin del sistema se hace desde un punto de vista funcional.

Desde el punto de vista de la codificacin, cada mdulo corresponde
esencialmente a un subprograma.
TCNICAS DE DISEO FUNCIONAL DESCENDENTE:

DESARROLLO POR REFINAMIENTO PROGRESIVO
Esta tcnica consiste en la aplicacin de la fase de diseo de la programacin

estructurada. Las estructuras bsicas son la secuencia, la seleccin entre
alternativas y la iteracin.
Cada paso en la descomposicin consiste en refinar o detallar una parte del
programa global u operacin, que a su vez podr ser descompuesta en otras
operaciones. Los refinamientos se basan en la aplicacin de estructuras de control
en el programa. Veamos como ejemplo obtener las races de una ec. de 2 grado:
Obtener races ->
Leer coeficientes
Resolver ecuacin -->
Calcular discriminante
Calcular races -->
SI el discriminante es negativo ENTONCES
Calcular races complejas
SI-NO
Calcular races reales
FIN-SI
Imprimir races
72

PROGRAMACIN ESTRUCTURADA DE JACKSON
Esta tcnica sigue las ideas de la programacin estructurada (secuencia,

seleccin, iteracin) y el mtodo de refinamientos sucesivos pra construir la
estructura del programa en forma descendente.
Se recomienda construir la estructura del programa de forma similar a las
estructuras de datos de entrada y de salida
Pasos de la tcnica JSP:
1)
Analizar el entorno del problema y describir las estructuras de datos a
procesar
2)
Construir la estructura del programa basndose en las estructuras de
datos
3)
Definir las tareas a realizar en cada mdulo de la estructura del programa
Este tercer paso corresponde en su detalle a la fase de codificacin
Ej.: Programa para justificar el texto, es decir, reagrupar las palabras en lneas
e intercalar los espacios adecuados para que se ajusten a los mrgenes
PASO 1. Las estructuras de datos que reconocemos son
Texto de entrada = {[separador de prrafo | palabra]}
Texto de salida = {[lnea ajustada | lnea final | lnea en blanco]}

73

PROGRAMACIN ESTRUCTURADA DE JACKSON
En el PASO 2 se trata de encontrar

una estructura del programa que se
ajuste a las estructuras de los datos
de entrada y salida
74

DISEO ESTRUCTURADO
Segn esta tcnica, la tarea de diseo consiste en pasar de los DFDs a los
diagramas de estructura.
Hay que establecer una jerarqua o estructura de control entre los diferentes
mdulos, que no est implcita en el modelo funcional descrito en los DFDs
Para dos mdulos relacionados en el DFD (A) tenemos 3 posibilidades de
organizacin modular diferentes.
75

DISEO ESTRUCTURADO
Para establecer la jerarqua de control entre mdulos se recomienda hacer

ciertos anlisis en el flujo de datos: de flujo de transformacin y de flujo de
transaccin. Para ello es recomendable construir un DFD con todos los
procesos contenidos en los primeros niveles prescindiendo de los almacenes.
El anlisis de flujo de
transformacin
consiste en identificar
un flujo global de
informacin desde los
elementos de entrada
hasta los de salida.
Los procesos se
agrupan en 23
regiones: flujo de
entrada, de
transformacin y de
salida.
76

DISEO ESTRUCTURADO
El flujo de transaccin es aplicable cuando el flujo de datos se puede descomponer en varias
lneas separadas. El anlisis consiste en identificar el centro de transaccin a partir del cual se
ramifican las lneas de flujo a las regiones correspondientes a cada una de las transacciones
77

DISEO ESTRUCTURADO. EJ. GESTIN DE BIBLIOTECA
78
TCNICAS DE DISEO BASADO EN ABSTRACCIONES
La idea es que los mdulos corresponden a funciones o a tipos abstractos de datos.

Los lenguajes que dan ms facilidades para la implementacin son los orientados a
objetos
TCNICAS DE DISEO BASADO EN ABSTRACCIONES:

DESCOMPOSICIN MODULAR BASADA EN ABSTRACCIONES
Se trata de ampliar el lenguaje de programacin con nuevas operaciones y tipos de

datos definidos por el usuario, de forma que se simplifique la escritura de los niveles
superiores del programa, basndose en mdulos que realicen estas operaciones
Podemos identificar los tipos abstractos correspondientes a un nmero
complejo y a una ecuacin de 2 grado y definir sobre dichos tipos abstractos las
siguientes operaciones:
Ecuacin de 2 grado:
Nmero complejo:
Leer ecuacin
Escribir
Escribir ecuacin
Sumar, Restar, etc..
Obtener races
Raz cuadrada
La estructura modular del programa sera:
79
TCNICAS DE DISEO BASADO EN ABSTRACCIONES: MTODO DE

ABBOTT
A partir de la descripcin o especificacin de los mdulos es posible identificar las palabras o trminos que
puedan corresponder a elementos significativos del diseo:
Tipos de datos, que aparecen como sustantivos genricos
Atributos, son sustantivos en general
Operaciones, tienen la forma de verbos o nombres de acciones

Se subrayan en la descripcin las palabras significativas haciendo una lista de nombres y otra de verbos u
operaciones. Hay que eliminar los trminos irrelevantes o los sinnimos de palabras ya aparecidas
DATO
Atributos
Operaciones
Palabra
Caracteres
Imprimir
Prrafo
Separador
Lnea salida
Iniciar prrafo
Poner palabra
Terminar prrafo
Separador de
prrafo
Lneas en blanco
Sangrado
Lnea
Sangrado
Palabras
Iniciar lnea
cabe palabra?
Poner palabra
Imprimir sin ajustar
Imprimir ajustada
80
TCNICAS DE DISEO ORIENTADAS A OBJETOS
Es esencialmente igual al diseo basado en abstracciones, aadiendo la

herencia y el polimorfismo.
En la descomposicin modular del sistema cada mdulo contiene la
descripcin de una clase de objetos o de varias clases relacionadas entre
s.
PASOS:
Estudiar y comprender el problema a resolver
Desarrollar en lneas generales uan posible solucin, al menos
informal
Formalizar dicha estratega en trminos de clases, objetos y sus
relaciones:
Identificar los objetos, sus atributos y sus componentes

Identificar las operaciones sobre los objetos y asociarlas a la clase
adecuada
Aplicar herencia donde convenga
Describir cada operacin en funcin de las otras, y subsanar posibles
omisiones
Asignar clases y objetos a los mdulos del sistema
81
TCNICAS DE DISEO DE DATOS
Muchas aplicaciones necesitan almacenar informacin de forma permanente y la

mejor forma de hacerlo es crear una base de datos subyacente
Podemos enfocar la organizacin de la base de datos de 3 formas:
Nivel externo
Esquemas de usuario
Nivel conceptual
Esquemas lgicos
Nivel interno
Esquemas fsicos
El nivel externo corresponde a la visin del usuario, en la fase de anlisis de pasa
al nivel conceptual, que establece la organizacin de los datos, y finalmente en la
etapa de diseo se pasa al nivel interno.
DISEO DE BASES DE DATOS RELACIONALES, en este modelo la eficiencia se
basa en:
Las FORMAS NORMALES, que tienden a evitar las redundancias en los datos
almacenados
FN1, la informacin asociada a cada columna de la tabla es un nico valor, y no

una coleccin
FN2, si hay una clave primaria que distingue e identifica cada fila, el resto de los
datos dependen de toda la clave primaria
FN3, el valor de cada columna que no es clave primaria depende directamente de
la clave primaria. Se puede conseguir si se separan las tablas.
Los INDICES, que mejoran la velocidad de acceso a los datos

82
TCNICAS DE DISEO DE DATOS: DISEO DE LAS ENTIDADES
En el modelo relacional cada entidad

del modelo E-R se traduce en una
tabla por cada clase de entidad, con
una fila por cada elemento de esa
clase y una columna por cada atributo
de esa entidad.
Entre las entidades relacionadas se
puede incluir una columna con un
nmero de referencia o identificador
que las relaciona, sirve como clave
primaria.
En el modelo E-R todas las
relaciones se consideran de
asociacin, y la manera de trasladar
esto a las tablas depende de la
cardinalidad de la relacin. La
relacin se convierte en una tabla que
contiene referencias a las tablas de
las entidades relacionadas, as como
los atributos de la relacin (cale para
cualquier cardinalidad, incluso N:N).
Si es 1:N es posible incluir los datos
de la relacin en la tabla con
cardinalidad 1. Si la cardinalidad es
1:1 se pueden fundir las tablas de las
dos entidades.
83
TCNICAS DE DISEO DE DATOS: COMPOSICIN Y HERENCIA
(a)
(b)
(c)
Las relaciones de COMPOSICIN

se tratan como las de asociacin, y
en ellas la cardinalidad del objeto
compuesto suele ser 1, por lo que
se puede aplicar la simplificacin.
Cuando una clase tiene carias
subclases hay 3 formas de
amacenar las entidades ne tablas:
Una tabla para la superclase con
los atributos comunes y una tabla
para cada subclase
Desaparece la tabla de la
superclase y los atributos comunes
heredados se repiten en las
subclases
Se prescinde de las tablas de la
subclase y se amplia la tabla de la
superclase con todos los atributos
de las subclases, de forma que
estos valores sern opcionales
para los elementos
84
Tema 5:
CODIFICACIN Y PRUEBAS
85
CODIFICACIN DEL DISEO
Nos vamos a referir a las ltimas fases del ciclo de vida: codificacin,
pruebas de unidades, integracin y pruebas de sistema.
Cuando alguna de las pruebas no resulta positiva es necesario repetir
la codificacin o la integracin y probar de nuevo.
La fase de codificacin constituye el ncleo central en cualquiera de los
modelos y tiene una importancia fundamental ya que elabora los
programas fuente.
Previamente a la codificacin es necesario elegir el lenguaje que se
emplear as como la metodologa de programacin. Tambin se
pueden establecer en el equipo unas normas y un estilo de
programacin comn, lo que mejorar la coordinacin y facilitar el
trabajo. Adems se consigue facilitar el mantenimiento y mejorar la
reusabilidad del software.
Cuando el resultado de las pruebas no sea satisfactorio ser necesario
modificar el cdigo, lo que podr introducir nuevos errores. Si la
programacin es estructurada ser ms fcil localizar la disfuncin y la
posterior modificacin y las pruebas del cdigo, dnde podemos
introducir puntos de test.
86
LENGUAJES DE PROGRAMACIN
Aunque los lenguajes han evolucionado mucho desde los aos 50 todava estn ms prximos a la mquina que al pensamiento humano.
Los lenguajes suelen adoptar los avances metodolgicos que se producen en el desarrollo del software. Ej.: C y C++
DESARROLLO HISTRICO, muchos han sido desarrollados con fines experimentales y muy pocos han llegado a ser utilizados
industrialmente:
1 GENERACIN: muy prximos al lenguaje mquina
Ensamblador, asocia a cada instruccin de la mquina un nemnico
2 GENERACIN: no dependen de la CPU, se programa de manera simblica, en alto nivel.
FORTRAN (FORula TRANslator), para aplicaciones cientficas
COBOL, para procesamiento de informacin. Supone el 70 %
ALGOL, da gran importancia a la tipificacin de datos
BASIC, sencillo y fcil de aprender. Desarrollado para el PC.
3 GENERACIN: programacin estructurada con declaracin de tipos. Los ltimos van asociados a otros paradigmas.
PASCAL, fue diseado para la enseanza de la programacin estructurada. Tipificacin rgida y no contempla la codificacin
por separado
MDULA-2, descendiente de pascal, se incorpora la estructura de mdulo. Se mejora modularidad, concurrencia, abstraccin
y ocultacin
C, desarrollado para la codificacin del UNIX. Flexible y potente. No hay restricciones sobre las operaciones con distintos
tipos.
ADA, descendiente de pscal, mucho ms potente y complejo. Incorpora modularidad, abstraccin, ocultacin, concurrencia y
sincronizacin entre tareas.
SMALLTALK, precursos de los lenguajes orientados a objetos
C++, incorpora en C los mecanismos de la POO: ocultacin, clases, herencia y polimorfismo.
EIFFEL, permite la definicin de clases genricas, herencia mltiple y polimorfismo.
LISP, lenguaje funcional usado en IA y sistemas expertos. Basado en listas admite recursividad. Maneja bien los smbolos
PROLOG, lenguaje lgico en que se construye una base de conocimiento basada en reglas a partir de la cual podemos inferir
nuevos hechos o reglas.
4 GENERACIN: mayor grado de abstraccin. Se agrupan en:
BASES DE DATOS; como SQL permiten acceder y manipular la informacin.
GENERADORES DE PROGRAMAS, son eficientes en un dominio de aplicaciones limitado. La mayora producen

aplicaciones de gestin y la salida va en cobol, aunque se han desarrollado herramientas CASE que generan programas en
C++ o ADA.
CLCULO, hojas de clculo, herramientas de simulacin y diseo para el control, etc.
OTROS: herramientas para la especificacin y verificacin formal de programas, lenguajes de simulacin, de prototipos, etc.
87
PRESTACIONES DE LOS LENGUAJES:

ESTRUCTURAS DE CONTROL
se incluyen aqu, adems de las caractersticas propias de la programacin estructurada, el
manejo de excepciones y la concurrencia.
Programacin estructurada: secuencia, iteracin y seleccin (verdadero-falso y por casos)
Manejo de excepciones: errores humanos, fallos hardware, errores software, datos de
entrada vacos, valores fuera de rango, etc. (estructuras exception when y raise).
Concurrencia, tareas simultneas, sincronizacin, comunicacin e interbloqueos. Los
lenguajes han implementado la posibilidad de lanzar tareas concurrentes de distintas formas:
CORRUTINAS, tienen una estructura semejante a subprogramas pero con una transferencia del
control ms flexible. El avance en la ejecucin de las corrutinas se produce segn el avance entre
ellas.
FORK-JOIN, es la propuesta de UNIX.
COBEGIN-COEND, entre estas palabras se inician todas las tareas y se finalizan. Es posible el
anidamiento.
PROCESOS; cada tarea se declara como un proceso y estos y se ejecutan concurrentemente. En
algunos casos es posible lanzar dinmicamente nuevos procesos una vez iniciado el programa.
PARA LA COMUNICACIN ENTRE TAREAS.
VARIABLES COMPARTIDAS
SEMFOROS
REGIONES CRTICAS
MONITORES
PASO DE MENSAJES
CSP
LLAMADA A PROCEDIMIENTOS REMOTOS
REDENZVOUS, DE ADA
88
PRESTACIONES DE LOS LENGUAJES:

ESTRUCTURAS DE DATOS
DATOS SIMPLES. Para los eneros hay que tener en cuenta el rango posible y para los de coma flotante la
precisin. En ocasiones tambin permiten el manejo de complejos.
DATOS COMPUESTOS, son combinaciones de datos simples y compuestos ya definidos. Pueden ser
homogneos como los ARRAYS y heterogneos como los RECORDS o STRUCTS.
Nivel 0: sin tipos, no es posible declarar nuevos tipos y todos los datos deben pertenecer a tipos predefinidos
Nivel 1: tipado automtico, el compilador decide cul es el tipo ms adecuado para cada dato.
Nivel 2: tipado dbil, el compilador hace inferencias sobre los tipos y solo son posibles determinadas
conversiones
Nivel 3: tipado semirgido, todos los datos deben ser declarados con su tipo
Nivel 4: tipado fuerte, aqu adems de declarar los tipos, el programador est obligado a hacer explcita cualquier
conversin de tipos.
ABSTRACCIONES Y OBJETOS.
Para el manejo de estructuras dinmicas de datos muchos lenguajes incluyen punteros
CONSTANTES, en los lenguajes modernos se pueden declarar constantes simblicas, sin indicar
directamente su valor numrico.
COMPROBACIN DE TIPOS, se pueden distinguir 5 niveles:
Otros tipos simples son char y string, para el manejo de cadenas. Los tipos enumerados tambin pueden
resultar tiles, un tipo enumerado muy frecuente son los booleanos.
En ocasiones los lenguajes permiten utilizar subrangos.
ABSTRACCIONES FUNCIONALES
TIPOS ABSTRACTOS DE DATOS
OBJETOS
MOODULARIDAD. Se requiere la compilacin por separado. Adems se introducen de forma redundante la

declaracin y la definicin de cada mdulo, para permitir al compilador hacer comprobaciones acerca de la
consistencia. C y modula-2 lo tienen, pero pascal es monoltico.
89
CRITERIOS DE SELECCIN DEL LENGUAJE
El lenguaje es uno de los elementos ms importantes de cualquier desarrollo y tiene una

influencia decisiva en la depuracin y el mantenimiento dela aplicacin. Criterios:
IMPOSICIN DEL CLIENTE, a veces para disminuir los costes de desarrollo y
mantenimiento que se producen cuando una empresa utiliza lenguajes diferentes.
TIPO DE APLICACIN, hay lenguajes orientados a un campo de aplicacin concreto.
Aplicaciones tiempo real crticas -> ensamblador

Gestin -> cobol
rea cientfico-tcnica -> Fortran, Pascal, C
Inteligencia artificial -> Lisp, Prolog
Orientado a objeots ->> Eifel, C++
DISPONIBILIDAD Y ENTORNO, hay que comprobar los compiladores existentes para

la plataforma elegida. Estudio comparativo de eficiencia con un programa de prueba.
Herramientas del entorno de desarrollo: editor, montador, depurador, control versiones,
manejo de libreras, etc.
EXPERIENCIA PREVIA, aprovechar la experiencia aumenta el rendimiento y disminuye
las posibilidades de error. La formacin supone una fuerte inversin.
RESUABILIDAD, organizacin de libreras que faciliten la bsqueda y almacenamiento
de mdulos reutilizables.
TRANSPORTABILIDAD, depende del lenguaje
USO DE VARIOS LENGUAJES, no es aconsejable a no ser que las distintas partes
sean ms fciles de desarrollar en lenguajes concretos. Hay que tener en cuenta la
compatibilidad de los compiladores
90
ASPECTOS METODOLGICOS
Estos aspectos pueden mejorar la codificacin bajo determinados puntos de vista: claridad, manejo de errores eficiencia y
transportabilidad.
Normas y estilo, para conseguir un trabajo del equipo homogneo. Ejemplos:
Formato y contenido del as cabeceras de cada mdulo
Formato y contenido para los comentarios
Uso del indentado
Eleccin de nombre y uso de maysculas
Restricciones sobre el tamao del os mdulos, evitar anidamiento excesivo, no usar goto, etc.
Manejo de errores. Las causas de los errores pueden estar en el hardware o en el software, incluso de pueden producir
por la introduccin de datos incorrectos.
DEFECTO, incorreccin en el software. Pueden permanecer ocultos hasta que no se ejecutan determinadas
partes del programa
FALLO, elemnto del programa que no funciona correctamente, produciendo un resultado errneo
ERROR, estado no vlido de un programa al que se llega como consecuencia de un fallo.
Al codificar podemos adoptar distintas actitudes ante los errores:
NO CONSIDERAR LOS ERRORES, no es realista esta postura
PREVENCIN DE ERRORES, consiste en detectar los fallos antes de que provoquen un error. Hay que
evitar la propagacin de errores y tener siempre a la salida un resultado correcto o una seal de fallo.
RECUPERACIN DE ERRORES, Cuando no es posible depurar todos los fallos es necesario hacer un
tratamiento de errores para devolver al programa a un estado vlido y evitar que el error se propague
1.
Deteccin del error
2.
Recuperacin del error. Se pueden usar dos esquemas en general:
1.
RECUPERACIN HACIA DELANTE, hay que programas un mecanismo de excepciones para
que cuando se detecte el error se corrija el estado y se contine correctamente la ejecucin.
2.
RECUPERACIN HACIA ATRS, corrige el estado no vlido restaurando el programa a un
estado correcto anterior,
Una transaccin es una operacin que puede terminar con xito o con fallo, en cuyo caso se
aborta y se restaura el estado de antes de comenzar dicha transaccin.
91
ASPECTOS METODOLGICOS: EFICIENCIA Y

TRANSPORTABILIDAD
La potencia de clculo y la cantidad de memoria disponible en los computadores actuales

hacer preferible la claridad en el cdigo que la EFICIENCIA.
EFICIENCIA EN MEMORIA, en la fase de diseo se estudian las posibles alternativas y
se opta por el algoritmo que optimiza el uso dela memoria.
EFICIENCIA DE TIEMPO, es importante en el desarrollo de sistemas de tiempo real
muy crticos. A veces se mejora la eficiencia de tiempo a costa de ocupar ms memoria.
En el diseo se estudian las alternativas y se adopta el algoritmo ms rpido. Tcnicas
de codificacin para aumentar la eficiencia de tiempo:
Tabular clculo complejos

Expansin en lnea, emplear macros en vez de subrutinas
Simplificar las expresiones aritmticas y lgicas
Sacar fuera de los bucles lo que no sea necesario repetir
Usar estructuras de datos de acceso rpido
Evitar operaciones en coma flotante, mejor en coma fija
Evitar conversiones innecesarias de tipos
TRANSPORTABILIDAD DEL SOFTWARE, no solo es rentable a corto plazo para obtener

versiones para diferentes plataformas, a medio y largo plazo facilita el mantenimiento y la
adaptacin de la aplicacin a las nuevas arquitecturas.
Los factores para la transportabilidad son:
Utilizacin de estndares
Aislar las peculiaridades, colocndolas en mdulos separados. Se procurar evitar aquellos
elementos no consolidados y que pueden estar sujetos a futuros cambios o revisiones.
Las peculiaridades de los distintos tipos de computadores depende de la arquitectura y del

sistema operativo utilizado.
92
TCNICAS DE PRUEBAS
Para garantizar su calidad es necesario someter al programa a diversas

pruebas para garantizar su funcionamiento correcto.
Se deben hacer pruebas a cada mdulo, segn avanza la codificacin del
proyecto. Finalmente se harn las pruebas de integracin entre mdulos y
las pruebas de sistema
OBJETIVOS, el principal objetivo es conseguir que el programa funcione
incorrectamente para ir depurando los errores y que se descubran los
efectos. Para elaborar los casos de prueba:
Una
buena prueba encuentra los errores y no los encubre

Para determinar si hubo error es necesario conocer el
resultado correcto
Deben participar codificador y diseador
Al corregir un error se pueden introducir otros nuevos
No es posible demostrar la ausencia de defectos mediante
pruebas
No son posibles las pruebas exhaustivas. Con el menor
esfuerzo posible hay que detectar el mximo n de defectos,
en especial los ms graves.
Las pruebas se realizan en un entorno de ejecucin
controlado, para asegurar la estabilidad en los pruebas y
automatizar en lo posible este proceso.
93
TCNICAS DE PRUEBAS DE UNIDADES: CAJA NEGRA
Las tcnicas de pruebas de unidades siguen dos estrategias fundamentales:

PRUEBAS DE CAJA NEGRA, se ignora por completo la estructura interna del programa y se
comprueba la correccin de entradas y salidas del programa.
Lo importante es la elaboracin de los casos de prueba con el objetivo de descubrir los errores e
incorrecciones. Mtodos:
PARTICIN EN CLASES DE EQUIVALENCIA, se trata de ividir el espacio de ejecucin del

programa en varios subestapacios o clases equivalentes desde el punto de vista del a caja negra. Hay
que:
Determinar las clases equivalentes apropiadas
Establecer pruebas para cada clase de equivalencia, con datos de entrada vlidos y no
vlidos. Se repiten las pruebas hasta cubrir todos los casos vlidos de todas las clases.
ANLISIS DE VALORES LMITE, los errores tienden a aparecer al operar en las fronteras.
Directrices para la elaboracin de casos de pruebas:
Entradas, probar los valores del lmite y justo fuera del lmite
Salidas, probar los valores del lmite y justo fuera del lmite
Memoria, probar tamaos nulos, lmite superior y superior al lmite de todas las estructuras
de datos del programa
Recursos, probar lmites. Si terminales=30, probar 0, 20 y 31
Otros, probar los valores lmite y establecer las pruebas
COMPARACIN DE VERSIONES, se desarrollan varias versiones software para resolver la
especificacin del mdulo y se comparan los resultados con el fin de detectar errores.
EMPLEO DELA INTUICIN, la intuicin y la experiencia puede mejorar los casos de prueba,
tambin es conveniente que participen expertos ajenos al desarrollo.
94
TCNICAS DE PRUEBAS DE UNIDADES: CAJA TRANSPARENTE
Se tiene en cuenta la estructura interna del mdulo. Los

casos de prueba deben conseguir que:
Todas las decisiones se ejecuten en uno y otro sentido
Todos los bucles se ejecuten en los supuestos ms
diversos posibles
Todas las estructuras de datos se modifiquen y
consulten alguna vez
La complejidad de los mdulos dificulta realizar exhaustivas
pruebas de caja transparente. Conviene que participen
expertos con un conocimiento amplio de las estructura del
programa. Mtodos:
CUBRIMIENTO LGICO, consiste en no dejar ninguna seccin PRUEBAS DE BUCLES, que son elemento esencial en
del cdigo sin ejecutar en pruebas. Se llama camino bsico a
cualquier programa. Casos:
cualquier recorrido sobre el diagrama de flujo que nos permita
Bucles con n no acotado de repeticiones, probar 0, 1, 2,
llegar al final desde el punto de entrada.
bastantes y muchas iteraciones.
Hay que determinar el conjunto de caminos bsicos
que recorran todas las lneas de flujo del programa al menos una Bucles con n mximo de repeticiones, probar 0, 1, 2
bastantes, M-1, M y M+1 iteraciones
vez.
N mximo de caminos = N predicados + 1
En un segundo nivel de casos de prueba se trata de
que se ejecuten todas las combinaciones de caminos bsicos por
parejas
Bucles anidados, el n de pruebas para comprobar todas

las situaciones crece.
EMPLEO DE LA INTUICIN, conocer con detalle la
estructura del mdulo y tener experiencia.
A otros niveles se generan casos de pruebas para que

se ejecuten un n significativo de combinaciones de caminos
bsicos
95
TCNICAS DE PRUEBAS DE UNIDADES: CAJA TRANSPARENTE

Diagramas de flujo con 3 y con 4 predicados lgicos simples
96
ESTIMACIN DE ERRORES NO DETECTADOS
Resulta imposible demostrar que un mdulo carece de

defectos, pero podemos hacer una estimacin estadsitca
de erratas que permanecen sin detectar:
Anotar el n de errores que se producen inicialmente al pasar
los casos de prueba.
Corregir el mdulo hasta que sdesaparezcan todos esos
errores
Introducir en el mdulo, de forma aleatoria un n razonable de
errores
Someter al mdulo nuevamente a los casos de prueba y ver
el n de errores que se detectan
De esta forma podemos estimar el n de errores que han
permanecido sin ser detectados en el programa
En funcin de los resultados se valorar la necesidad de

preparar nuevos casos de prueba.
97
ESTRATEGIAS DE INTEGRACIN
Se integran los mdulos del sistema para conformar el sistema completo. Causas de error:
Desacuerdos en el interfaz entre mdulos
Interaccin indebida entre mdulos
Imprecisiones acumuladas
Estrategias bsicas para la integracin:
INTEGRACIN BIG BANG, en un nico paso se integran todos los mdulos, de forma que todos
los defectos se manifiestan a la vez. Solo recomendable para sistemas pequeos.
INTEGRACIN DESCENDENTE, se parte de un mdulo principal P, que se prueba con
mdulos de andamiaje, los cuales van siendo sustituidos por los verdaderos de forma
progresiva por niveles. Los mdulos de andamiaje;
El trabajo de elaborar estos mdulos puede ser aprovechado para hacer un prototipo y mostrar al
cliente un avance del programa. Inconvenientes:
Impide el trabajo en paralelo en las pruebas

Es difcil buscar los casos de pruebas especiales o dirigidas a los ltimos mdulos integrados
INTEGRACIN ASCENDENTE, se codifican por separado y en paralelo todos los mdulos del
nivel ms bajo. Para probarlos se codifican mdulos gestores o conductores que los hacen
funcionar independientemente o en combinaciones sencillas. Las ventajas son:
No hacen nada y solo sirven para comprobar el interfaz

Imprimen un mensaje de seguimiento, con informacin de la llamada
Suministran un resultado fijo
Suministran un resultado aleatorio
Suministran un resultado tabulado u obtenido con un algoritmo simplificado
Facilita el trabajo en paralelo

Facilita el ensayo de situaciones especiales
La Integracin Sandwich consiste en realizar integracin ascendente con los mdulos de nivel
ms bajo y descendente con los de nivel ms alto.
98
INTEGRACIN DESCENDENTE Y ASCENDENTE
99
PRUEBAS DE SISTEMA
Se trata de probar el sistema completo para ver si realmente cumple las

especificaciones.
Se suelen emplear estrategias de caja negra. Podemos distinguir diferentes
clases de pruebas:
PRUEBAS DE RECUPERACIN, para comprobar la capacidad del sistema
para recuperarse ante fallos
PRUEBAS DE SEGURIDAD, par comprobar los mecanismos de proteccin
ante un acceso no autorizado
PRUEBAS DE RESISTENCIA, para comprobar el comportamiento del
sistema ante situaciones excepcionales
PRUEBAS DE SENSIBILIDAD, para comprobar el tratamiento que da el
sistema a ciertas singularidades relacionadas casi siempre con los
algoritmos matemticos utilizados
PRUEBAS DE RENDIMIENTO, para comprobar las prestaciones del
sistema que son crticas en tiempo
PRUEBAS ALFA Y BETA. Los usuarios tambin deben intervenir en las
pruebas finales del sistema
Pruebas alfa, son las primeras pruebas que se realizan en un entorno

controlado donde el usuario tiene el apoyo de alguien del equipo de desarrollo
Pruebas beta, los usuarios trabajan con el sistema en un entorno real y sin
ayuda, anotando los problemas que se le presentan
100
Tema 6:
AUTOMATIZACIN DE PROCESO
DE DESARROLLO
101
ENTORNOS DE DESARROLLO SOFTWARE
Entorno se refiere al contexto dentro del cual se desarrolla una determinada

actividad, o tambin a la combinacin de instrumentos utilizados.
El entorno de desarrollo software, SEE, cuenta con una serie de tcnicas de
automatizacin denominadas CASE.
Las primeras herramientas se referan a la fase de codificacin, as el entorno
de programacin clsico consiste en un compilador con editor, montador de
enlaces, etc. Posteriormente con el empleo del trmino CASE se ha extendido
la automatizacin a las fases de anlisis y diseo.
Para las pruebas de integracin se puede disponer de herramientas de ensayo
y para la fase de mantenimiento se dispone de soporte de gestin de
configuracin, que incluye la gestin de versiones y el control de cambios.
El futuro de las tcnicas CASE est en el soporte completo de todo el ciclo de
vida. Se ha denominado IPSE, ICASE e ISEE.
FORMAS DE ORGANIZACIN:
En cadena, se combinan una serie de herramientas de manera que la
salida de cada una es la entrada de la siguiente. Ej.: editor-compiladormontador
Con repositorio, las herramientas integradas guardan su informacin en
este almacn comn. Una parte del repositorio es el diccionario de datos
Como una nica herramienta global, capaz de realizar todas las
operaciones necesarias.
102
OBJETIVO Y CLASIFICACIN DE ENTORNOS DE DESARROLLO
Dar soporte a la programacin en un lenguaje concreto

Dar soporte a una metodologa de desarrollo
Ayudar al desarrollo de entornos de desarrollo (meta-entornos)
CLASIFICACIN, desde un punto de vista pragmtico:
ENTORNOS ASOCIADOS A UN LENGUAJE. Un primer paso lo constituyen los
intrpretes de los lenguajes de programacin interactivos (BASIC, LISP, SmallTalk, ada).
ENTORNOS ASOCIADOS A ESTRUCTURA. En ellos se almacena la informacin
correspondiente al programa en forma estructurada y no simplemente como texto. La edicin
del programa se consigue mediante un editor de estructura, que permite construir o modificar
un programa operando sobre los elementos de su estructura. El entorno se basa en plantillas
que describen las estructuras bsicas (PL/).
ENTORNOS BASADOS EN HERRAMIENTAS. Consisten en una coleccin de
herramientas (toolkit o toolbox) relativamente independientes, aunque compatibles entre s,
adems deben de existir algn medio para hacerlas funcionar en forma combinada. Suele
presentar como ventaja el ser bastante abiertos, permitiendo la incorporacin de nuevas
herramientas. Su inconveniente es la falta de una interfaz de usuario interactiva y uniforme.
ENTORNOS ASOCIADOS A UNA METODOLOGA. La integracin de los distintos
elementos del entorno se suele conseguir mediante el empleo de un almacn nico o
repositorio CASE para almacenar todos los elementos de informacin contemplados en la
metodologa soportada. El repositorio contiene informacin de los diagramas de flujo de
datos, descripcin de cada dato y de cada proceso.
ENTORNOS DE 4 GENERACIN. Se apoyan en un sistema de gestin de base de datos
dotado de un lenguaje de consulta con herramientas complementarias.
103
CLASIFICACIN DE ENTORNOS POR NIVELES

Nivel de servicio. Corresponde a un producto que realiza una funcin u
operacin elemental, que una vez invocada no se interrumpe (compilador).
Nivel de herramienta. Producto software que permite invocar diferentes

servicios u operaciones correspondientes a una misma actividad individual.
(editor de textos).
Nivel de banco de trabajo o equipo de herramientas. Corresponde a un

producto CASE que automatiza o soporta un perfil concreto de actividad
profesional dentro del proceso de desarrollo. Un banco de trabajo suele
englobar varias herramientas, integradas con una interfaz de usuario uniforme.
En la actividad de codificacin el banco de trabajo se denomina entorno de
programacin.
Entorno de desarrollo. Producto CASE que soporta el proceso completo de

desarrollo de software (IPSE o ICASE).
Los dos primeros niveles se describen a veces como uno solo.
104
HERRAMIENTAS DE SOFTWARE
Herramientas clsicas.
Editor de texto.
Compilador
Montador de enlaces. Construye ejecutables combinando varios ficheros objeto.
Gestor de librera. Combina ficheros objeto en una librera.
Herramienta MAKE. Automatiza la actualizacin de los ficheros a partir de otros.
Intrprete interactivo. Casi Constituye un entorno de programacin completo (si lo es se debe clasificar a nivel de banco de trabajo y no de
herramienta). Engloba funciones equivalentes a las de edicin, compilacin, montaje y ejecucin.
Compilador/Intrprete. Procesador de un lenguaje interpretado de forma no interactiva.Incluye un compilador a cdigo intermedio y un
intrprete de ejecucin de dicho cdigo intermedio con todas las libreras de soporte. No incluye funciones de editor de programas.
Depurador absoluto. Ejecuta el programa de forma controlada. Resulta incomodo de usar ya que hace referencia a posiciones de memoria y a
los registros del procesador.
Depurador simblico. Realiza una funcin anloga al anterior pero con referencia al cdigo fuente por lo que es ms cmodo de usar.
Herramientas evolucionadas.
Editores orientados al lenguaje. Son editores de estructura.
Herramienta MAKE automtica. Se incorpora la funcin MAKE al compilador.
Manejador de versiones. Almacena de forma organizada y eficiente una serie de versiones del mismo elemento software. Se suelen usar desde
las utilidades MAKE al recompilar una aplicacin en desarrollo.
Procesadores/Analizadores de cdigo fuente. Grupo en que se pueden incluir diferentes herramientas que procesan el texto fuente para obtener
mediciones, generar tablas de referencias, encolumnar etc. Estas funciones podran estar incorporadas en los compiladores.
Procesadores de documentos. No son especficos del desarrollo pero son un soporte fundamental.
Herramientas de control de pruebas. Ayudan a la realizacin de pruebas unitarias o de
integracin.
Herramientas de control de cambios. Ayudan a la realizacin del desarrollo y al mantenimiento de aplicaciones.
Procesadores de ficheros de texto.
Herramientas de 4 generacin.
Hojas de clculo. Procesadores de documentos
Gestores de bases de datos Lenguajes de 4 generacin.
Generadores de programas.
105
ENTORNOS INTEGRADOS
Integracin de datos. Significa que la informacin almacenada en el entorno es gestionada de manera uniforme, con independencia de las
transformaciones que se hagan con cada elemento de informacin. Debe de conseguir:
Interoperatividad entre herramientas.
No redundancia de datos
Consistencia de datos.
Paso de datos de una herramienta a otra.
La integracin de datos puede conseguirse de diversas maneras:
Transferencia directa de datos de una herramienta a otra. Eficiente pero poco flexible. Complicada para integrar muchas
herramientas diferentes.
Transferencia mediante ficheros. Es la ms sencilla. Existe un formato normalizado (CDIF).
Transferencia basada en comunicacin. Alternativa a la anterior y puede ser usada en sistemas distribuidos y en sistemas
abiertos.
Repositorio comn. Se utiliza en los entornos modernos con un grado de integracin elevado.
Integracin de control. Consiste en la combinacin flexible de funciones para cumplir con las particularidades del proceso y actividades que
hay que informatizar. El mayor grado se consigue cuando desde una herramienta se puede invocar funciones de otra herramienta. Exige
como paso previo la integracin de los datos.
Integracin de la presentacin. Trata de realizar la interaccin con el usuario de manera uniforme, con cierta independencia dela funcin o
herramienta en uso. Para ello se deben conseguir los objetivos de un sistema amigable:
Limitar el nmero de formas de interaccin diferentes.
Usar formas de interaccin y presentacin adecuadas al modelo mental que el usuario tiene del entorno.
Satisfacer los tiempos de respuesta esperados y dar indicacin del avance del proceso en caso de tratamiento de larga duracin.
Mantener informacin til a disposicin del usuario.
Integracin del proceso. Consiste en que las herramientas se combinan de manera que apoyan o fuerzan el uso de una metodologa de
desarrollo definida. Este modo exige una buena integracin de control y datos. El proceso de desarrollo puede definirse en base a los
siguientes elementos.
Un paso del desarrollo es una unidad de trabajo concreta que produce un resultado (por ejemplo revisin del DDD).
Un suceso o evento es un condicin que ocurre durante la ejecucin de un paso y que puede desencadenar la ejecucin de una
accin asociada (compilacin de un mdulo).
Una restriccin del desarrollo es una limitacin que debe cumplirse.
Un buen grado de integracin del proceso exige que todo los pasos, eventos y restricciones que definen de forma natural la metodologa de
desarrollo a utilizar, sean representables y tratables dentro del entorno.
106
ENTORNOS INTEGRADOS: EL REPOSITORIO CASE

El repositorio CASE Es un almacn comn en el que se guarda toda la informacin necesaria
para la operacin de un grupo de herramientas o de un entorno de desarrollo. El repositorio
facilita las funciones de almacenamiento y recuperacin de datos, normalmente en forma
concurrente multiusuario, y el mantenimiento de relaciones entre los datos. Adems puede
suministrar funciones de gestin de versiones, de seguridad y de gestin de transacciones.
Para proporcionar las funciones de almacenamiento y recuperacin de datos se requiere:
Un servicio de metamodelo, que permita definir las estructuras de datos que han de
almacenarse en el repositorio.
Un servicio de consulta y actualizacin (query) que permita acceder y manipular la
informacin contenida en el repositorio.
Un servicio de vistas que permita definir subconjuntos de datos y operaciones que constituyan
el subentorno de trabajo de ciertas actividades y entre los que haya que mantener relaciones
concretas de consistencia.
Un servicio de intercambio de datos, que facilite la importacin y exportacin de informacin
mediante ficheros externos.
107
BANCOS O EQUIPOS DE TRABAJO

Un banco de trabajo debe integrar las herramientas necesarias para dar soporte a un determinado perfil profesional o
actividad general de desarrollo. Un banco de trabajo debe de conseguir:
Integracin de la presentacin
Integracin de control
Integracin de datos (preferentemente con repositorio comn).
Segn la actividad soportada, tendremos distintos bancos o equipos de trabajo, entre ellos:
Equipos de anlisis y diseo: Herramienta CASE o CASE superior. Corresponde al entorno asociado a la
metodologa. Muchos de ellos cubren las dos fases (anlisis y diseo), mientras que otros slo cubren una. El
repositorio comn almacena todos los elementos definidos en la metodologa soportada.
Entorno de programacin. Es el banco de trabajo para la actividad de codificacin pudindose extender al
diseo detallado y a las pruebas de unidades.
Equipo de verificacin y validacin: Capaz de facilitar las tareas de inspeccin y pruebas de mdulos y
sistemas. Suelen estar ligados al entorno de programacin. Pueden incluir funciones de:
Anlisis esttico, con evaluacin de mtricas de calidad y generacin de matrices o grafos de
llamadas entre funciones y mdulos.
Generacin de tablas de referencias cruzadas.
Gestin de pruebas, automatizando la realizacin de ensayos.
Equipo de construccin de interfaz del usuario. Permite definir cmodamente el esquema de dilogo con el
usuario, as como los elementos de interaccin.
Equipo de gestin de configuracin. Permite almacenar diferentes versiones de los elementos del proyecto,
definir distintas configuraciones y controlar los cambios sucesivos.
Equipo de ingeniera inversa. Debe facilitar la extraccin de informacin de diseo, los elementos
abstractos a partir de un cdigo o sistema software existente.
Equipo de gestin de proyectos. Facilita la confeccin de planes de trabajo, con la asignacin de tiempos y
recursos a diferentes tareas, y el seguimiento de su realizacin.
108
ENTORNOS ORIENTADOS AL PROCESO

Deben de ser capaces de soportar todas las actividades del ciclo de vida de desarrollo siguiendo un modelo definido. Un
entorno global de estas caractersticas se designa como IPSE, ICASE o ISEE. La caracterstica principal que distingue
un entorno de esta clase de un banco de trabajo amplio es el soporte explcito de un modelo global de desarrollo. El
entorno debe poseer las caractersticas de integracin del proceso, adems de las de integracin de datos, control y
presentacin.
Para conseguir este nivel de integracin es necesario contar con un modelo formal del proceso de desarrollo. A diferencia de
las metodologas parciales de anlisis y diseo, este modelo suele construirse a medida de cada empresa productora de
software. Un ISEE de uso general deber permitir:
Construir la definicin formal del modelo del proceso de desarrollo.
Asegurar la aplicacin prctica del modelo definido.
Aunque no existen entornos ISEE disponibles si existen esquemas generales de arquitectura de entornos orientados al
proceso, que en algunos casos han dado lugar a colecciones de herramientas que facilitan las funciones deseadas.
Algunas son:
PCTE (Portable Common Tool Environment). Es una arquitectura de entorno integrado, basada en un repositorio
comn. Su elemento principal es la definicin de interfaz de acceso al repositorio. Sobre l pueden operar herramientas
que automaticen las actividades previstas en el modelo del proceso. Existen implementaciones de repositorio que
cumplen con la especificacin PCTE, y tambin algunas colecciones de herramientas como las del proyecto PACT.
ESF (Eureka Software Factory). Define otro modelo de arquitectura, cuyo elemento central de integracin es el
denominado software bus, que es un interfaz normalizado para la interconexin de herramientas. Se distinguen dos
clases de herramientas: servidores y herramientas de interaccin. Los servidores pueden realizar las funciones de
repositorio, tanto centralizado como distribuido, y suministrar servicios o funciones automatizadas. Las herramientas de
interaccin permiten la comunicacin con los usuarios, que pueden acceder a los repositorios y a los servicios a travs
de ellas.
Modelo NIST/ECMA. Contempla una estructura fija, compuesta por elementos que proporcionan una integracin de
datos, basada en un repositorio comn, integracin de presentacin mediante un soporte global de interfaz de usuario, e
integracin del control, basada en la gestin de procesos y mensajes. El entorno puede particularizarse para un modelo
de desarrollo determinado instalando sobre estos elementos fijos una coleccin de herramientas.
Ante la ausencia de productos CASE listos para usar se debe de tomar el enfoque de combinar productos para construir un
entorno global.
109

Temas IS

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Temas IS

Diunggah oleh

Hak Cipta:

Format Tersedia

INGENIERA DEL

JAVIER MARTIN (jmartin@escet.urjc.es)

de los temas y mediante

INGENIERA DEL SOFTWARE Javier Martn

INGENIERA DEL SOFTWARE Javier Martn

Concepto de Ingeniera de Sistemas

Concepto de sistema, conjunto de cosas que ordenadamente

Concepto de Ingeniera del Software

Caractersticas del software (lo contrario para el hardware):

La crisis del Software

Se produce cuando surge la necesidad de desarrollar

No se ha llegado a una situacin estable, sino a una

INGENIERA DEL SOFTWARE Javier Martn

Mitos del Software

El hardware es mucho ms importante que el

INGENIERA DEL SOFTWARE Javier Martn

Formalizacin del proceso de desarrollo

La ingeniera supone la existencia de procesos bien

Prcticamente identifican actividades similares y slo se

INGENIERA DEL SOFTWARE Javier Martn

ANLISIS, determinar qu debe hacer el software ->

MODELO EN CASCADA AMPLIADO

INGENIERA DEL SOFTWARE Javier Martn

Cada fase debe generar una informacin de salida precisa

INGENIERA DEL SOFTWARE Javier Martn

INGENIERA DEL SOFTWARE Javier Martn

INGENIERA DEL SOFTWARE Javier Martn

Incluye fases similares a las del modelo en

INGENIERA DEL SOFTWARE Javier Martn

En los modelos clsicos se insiste en las actividades de

INGENIERA DEL SOFTWARE Javier Martn

Su finalidad es solo adquirir experiencia, no se

INGENIERA DEL SOFTWARE Javier Martn

INGENIERA DEL SOFTWARE Javier Martn

En este caso se intenta aprovechar al mximo el cdigo del

INGENIERA DEL SOFTWARE Javier Martn

Puede considerarse como un refinamiento del modelo

INGENIERA DEL SOFTWARE Javier Martn

INGENIERA DEL SOFTWARE Javier Martn

MANTENIMIENTO DEL SOFTWARE

El mantenimiento no representa una actividad especfica,

El mantenimiento supone la realizacin de una serie de

REINGENIERA, es necesaria cuando el desarrollo de una

Para evaluar la calidad son necesarias tcnicas de aplicacin de mtricas precisas

PLAN DE GARANTA DE CALIDAD (SQAP)

Es un documento formal para organizar el proceso de

INGENIERA DEL SOFTWARE Javier Martn

Consiste en inspeccionar el resultado de una actividad para

INGENIERA DEL SOFTWARE Javier Martn

Consiste en hacer funcionar el producto o una

INGENIERA DEL SOFTWARE Javier Martn

IEEE, Institute of Electrical and Electronics

INGENIERA DEL SOFTWARE Javier Martn

El anlisis y la definicin de los requisitos debe dar lugar a

INGENIERA DEL SOFTWARE Javier Martn

TCNICAS DE MODELADO (I)

DESCOMPOSICIN. MODELO JERARQUIZADO, aplica el divide y

TCNICAS DE MODELADO (II)

CONSIDERAR DISITNTOS PUNTOS DE VISTA, en la

Las ventajas de realizar un modelos ms general son:

INGENIERA DEL SOFTWARE Javier Martn

ANLISIS DE REQUISITOS DE SOFTWARE

TAREAS DEL ANLISIS