Ingeniería en Software

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 Javi
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 software.
20
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
INTEROPERATIVIDAD, facilidad del producto para trabajar con otros
26
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 DE BLOQUES
CAJAS 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-InputSeProcess-Output)

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:
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
1.
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
La descomposicin
del sistema
se hace desde DESCENDENTE
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
DEestructurada
JACKSON
Esta tcnica sigue las
ideas de la programacin
(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
JACKSON
En elDE
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
Segn estaESTRUCTURADO
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
DISEO
BASADO
EN ABSTRACCIONES
La idea es queDE
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
DEalmacenar
DATOSinformacin de forma permanente y la
Muchas aplicaciones
necesitan
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:

se incluyen aqu, adems de las caractersticas propias de la programacin estructurada, el manejo de
ESTRUCTURAS DE CONTROL
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

La
potencia de clculo y la cantidad de memoria disponible en los computadores actuales hacer preferible la
TRANSPORTABILIDAD
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 dePRUEBAS
UNIDADES:
CAJA NEGRA
Las tcnicas de pruebas
unidades siguenDE
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
Bucles anidados, el n de pruebas para comprobar todas

las situaciones crece.
En un segundo nivel de casos de prueba se trata de

que se ejecuten todas las combinaciones de caminos bsicos por EMPLEO DE LA INTUICIN, conocer con detalle la
estructura del mdulo y tener experiencia.
parejas
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-compilador-montador
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

Ingeniería en Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ingeniería en Software

Enviado por

Direitos autorais:

Formatos disponíveis

INGENIERA DEL

JAVIER MARTIN (jmartin@escet.urjc.es)

INGENIERA DEL SOFTWARE Javi

INGENIERA DEL SOFTWARE Javi

Concepto de Ingeniera de Sistemas

Concepto de sistema, conjunto de cosas que ordenadamente

INGENIERA DEL SOFTWARE Javi

Concepto de Ingeniera del Software

Caractersticas del software (lo contrario para el hardware):

INGENIERA DEL SOFTWARE Javi

La crisis del Software

Se produce cuando surge la necesidad de desarrollar

Aparicin de metodologas concretas de desarrollo

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

INGENIERA DEL SOFTWARE Javi

Mitos del Software

El hardware es mucho ms importante que el

INGENIERA DEL SOFTWARE Javi

Formalizacin del proceso de desarrollo

La ingeniera supone la existencia de procesos bien

Prcticamente identifican actividades similares y slo se

INGENIERA DEL SOFTWARE Javi

ANLISIS, determinar qu debe hacer el software ->

INGENIERA DEL SOFTWARE Javi

MODELO EN CASCADA AMPLIADO

INGENIERA DEL SOFTWARE Javi

Cada fase debe generar una informacin de salida precisa y

DOCUMENTOS DE REQUISITOS DEL SOFTWARE (SRD), es

INGENIERA DEL SOFTWARE Javi

INGENIERA DEL SOFTWARE Javi

INGENIERA DEL SOFTWARE Javi

Incluye fases similares a las del modelo en

INGENIERA DEL SOFTWARE Javi

En los modelos clsicos se insiste en las actividades de revisin

Limitar las funciones

INGENIERA DEL SOFTWARE Javi

Su finalidad es solo adquirir experiencia, no se

INGENIERA DEL SOFTWARE Javi

INGENIERA DEL SOFTWARE Javi

En este caso se intenta aprovechar al mximo el cdigo del

INGENIERA DEL SOFTWARE Javi

INGENIERA DEL SOFTWARE Javi

Puede considerarse como un refinamiento del modelo evolutivo

PLANIFICACIN, determina que parte del desarrollo se abordar

INGENIERA DEL SOFTWARE Javi

INGENIERA DEL SOFTWARE Javi

MANTENIMIENTO DEL SOFTWARE

El mantenimiento no representa una actividad especfica,

El mantenimiento supone la realizacin de una serie de cambios

INFORME DEL PROBLEMA, que ocasiona el cambio. Suele ser

REINGENIERA, es necesaria cuando el desarrollo de una

INGENIERA DEL SOFTWARE Javi

INGENIERA DEL SOFTWARE Javi

PLAN DE GARANTA DE CALIDAD (SQAP)

Es un documento formal para organizar el proceso de

Organizacin, direccin y seguimiento de los equipos de

INGENIERA DEL SOFTWARE Javi

Consiste en inspeccionar el resultado de una actividad para

Deben ser realizadas por un grupo de personas y no

INGENIERA DEL SOFTWARE Javi

Consiste en hacer funcionar el producto o una

INGENIERA DEL SOFTWARE Javi

INGENIERA DEL SOFTWARE Javi

IEEE, Institute of Electrical and Electronics