Concepto de Ingeniería 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 informáticos están compuestos por ordenadores y sus periféricos. Entre ellos
podemos distinguir dos tipos de subsistemas:

o Sistemas Hardware, son los elementos materiales, los que se pueden tocar.
o Sistemas Software, los programas que gobiernan el funcionamiento del
computador.
 El objetivo de los sistemas informáticos es el tratamiento de la información:
almacenamiento, elaboración y presentación de datos. De esta forma se automatizan
determinadas acciones.

 En la concepción del sistema informático no solo se decide el trabajo a realizar, sino también
cómo ha de ser utilizado por los usuarios.

Concepto de Ingeniería de Software

 Características del software (lo contrario para el hardware):

o No se desgasta ni envejece, y por este motivo no requiere reparaciones ocasionales

o Su duplicación es poco costosa, lo caro es el desarrollo
o Puede ser modificado fácilmente, tanto que es necesario un control de versiones
 La Ingeniería del Software comprende las técnicas y procedimientos ingenieriles para el
desarrollo del software.
o La IS no se plantea solo una actividad de programación, previamente son necesarias
las fases de análisis y diseño y posteriormente la integración y la verificación, incluso
el manteniendo cuando el producto ya está en explotación. (CICLO DE VIDA).
o Inicialmente la tarea de desarrollo era realizada individualmente por hábiles
creativos, de forma poco disciplinada. El trabajo en equipo supone la división y
organización del trabajo utilizando metodologías de desarrollo.
o En los 70 y los 80 empiezan a usarse herramientas CASE (Computer Aided Software
Engineering). En los 90 IPSE e ICASE.

Mitos del Software

 El hardware es mucho más importante que el software

 El software es fácil de desarrollar
 El software consiste exclusivamente en programas ejecutables
 El desarrollo del software es sólo una labor de programación
 Es natural que el software contenga errores
Formalización del proceso de desarrollo
 La ingeniería supone la existencia de procesos bien establecidos para la realización de
actividades de desarrollo, construcción, fabricación, etc.
 El ciclo de vida es el proceso de desarrollo y mantenimiento del software. Según el modelo
elegido se describen un conjunto de actividades para llevar a cabo el ciclo de vida,
 Los modelos clásicos:
o MODELO EN CASCADA
o MODELO EN V
 Prácticamente identifican actividades similares y sólo se diferencian en la forma de
presentación.
Modelo en Cascada

 ANÁLISIS, determinar qué debe hacer el software ->

especificación
 DISEÑO, descomponer y organizar el sistema para que los
módulos puedan ser desarrollados por separado
 CODIFICACIÓN, escribir el código fuente de cada módulo
y realizar sobre ellos las pruebas necesarias
 INTEGRACIÓN, combinar todos los módulos y probar el
sistema completo antes de pasar a su explotación
 MANTENIMIENTO, durante la explotación 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 especialización de los desarrolladores.
Al final de cada fase se requiere un proceso de revisión para evitar que los errores se
propaguen a fases posteriores provocando la vuelta atrás.
MODELO EN CASCADA AMPLIADO

 Cada fase debe generar una información de salida precisa y suficiente:

o DOCUMENTOS DE REQUISITOS DEL SOFTWARE

(SRD), es una especificación precisa y completa a
partir de los requisitos establecidos por el
cliente.
o DOCUMENTO DE DISEÑO DEL SOFTWARE (SDD),
descripción de la estructura global del sistema,
especificación de qué debe hacer cada uno de los
módulos y de cómo se combinan.
o CÓDIGO FUENTE, el programa debidamente
comentado (documentación interna).
o SISTEMA SOFTWARE, el ejecutable producto dela fase de integración y la
documentación de las pruebas realizadas.
o DOCUMENTOS DE CAMBIOS, después de cada modificación realizada en la fase de
mantenimiento: problema detectado y solución adoptada.
MODELO EN V MODELO EN V AMPLIADO

 Incluye fases similares a las del modelo en cascada, pero de forma jerárquica. En horizontal se
representa el avance en el desarrollo y en vertical el nivel de detalle.
 VERIFICACIÓN, comprobación de que una parte del sistema cumple con sus especificaciones.
 VALIDACIÓN, comprobación de que un elemento satisface las necesidades del usuario
identificadas durante el análisis.
PROTOTIPOS
 En los modelos clásicos se insiste en las actividades de revisión de resultados al final de cada
fase para evitar la vuelta atrás, que no se contempla de una forma organizada y resulta muy
costosa. Están 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 relación al del sistema final podemos:
o Limitar las funciones
o Limitar su capacidad
o Limitar su eficiencia
o Evitar limitaciones de diseño, utilizando un hardware más potente que el que ejecutará
el sistema final
o Reducir la parte a desarrollar
PROTOTIPOS RÁPIDOS
 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 código del prototipo
 Lo importante de estos prototipos es que se desarrollen
en poco tiempo.
PROTOTIPOS EVOLUTIVOS
 En este caso se intenta aprovechar al
máximo el código del prototipo, y para ello
se emplea el mismo hardware/software del
sistema final.
 Se realizan fases de análisis y diseño 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 iteración se va
avanzando en el desarrollo.
 HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS, se emplean lenguajes de 4ª generación,
que son de alto nivel y de tipo declarativo. También se emplean lenguajes de especificación,
como VDM y Z. Si disponemos del compilador correspondiente podemos obtener
automáticamente el código del prototipo.
 En el desarrollo de prototipos es clave la reutilización de software.
MODELO EN ESPIRAL
 Puede considerarse como un refinamiento del
modelo evolutivo general que introduce el análisis
de riesgo como elemento fundamental para guiar
la evolución del proceso de desarrollo.
 En la dimensión radial se representa el esfuerzo
realizado en el desarrollo (siempre creciente)
 En cada iteración 4 fases:
o PLANIFICACIÓN, determina que parte del
desarrollo se abordará en ese ciclo.
o ANALISIS DE RIESGO, evaluar diferentes
alternativas para esa parte del desarrollo
seleccionando la más ventajosa y tomando precauciones para evitar los posibles
inconvenientes.
o INGENIERÍA, las actividades de los modelos clásicos
o EVALUACIÓN, se analizan los resultados de la fase de ingeniería.

MANTENIMIENTO DEL SOFTWARE

 El mantenimiento no representa una actividad específica, sino que consiste en rehacer parte de
las actividades correspondientes a las otras fases del desarrollo para introducir cambios sobre
una aplicación ya en fase de explotación.
 MANTENIMIENTO CORRECTIVO, su finalidad es corregir errores que no fueron detectados en el
desarrollo del producto.
 MANTENIMIENTO ADAPTATIVO, modificar una aplicación para adaptarla a las nuevas
necesidades del entorno.
 MANTENIMIENTO PERFECTIVO, se trata de ir obteniendo versiones mejoradas del producto.
GESTIÓN DE CAMBIOS
 El mantenimiento supone la realización 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:
o INFORME DEL PROBLEMA, que ocasiona el cambio. Suele ser propuesto por el cliente.
o INFORME DE CAMBIO, describe la solución dada al problema y el cambio realizado
 REINGENIERÍA, es necesaria cuando el desarrollo de una aplicación no está documentado y se
dispone solamente del código. Se llama también ingeniería inversa porque supone reconstruir
y documentar las fases de análisis y diseño llegando a la estructura modular de la aplicación y
las dependencias entre módulos y funciones. Estas actividades organizan y documentan un
sistema deficiente.
GARANTÍA DE CALIDAD
 Para evaluar la calidad son necesarias técnicas de aplicación de métricas precisas tanto sobre
los productos software como a sus procesos de desarrollo.
 McCall propone un esquema basado en valoraciones a 3 niveles:
o FACTORES, valoración significativa de la calidad en base a los criterios establecidos
o CRITERIOS, aspectos de nivel intermedio que influyen en los factores de calidad
o MÉTRICAS, mediciones puntuales de determinadas características del producto.
 Entre los factores de calidad tenemos:
o CORRECCIÓN, grado en que cumple con las especificaciones
o FIABILIDAD, grado de ausencia de fallos
o EFICIENCIA, relación entre la cantidad de resultados y los recursos requeridos
o SEGURIDAD, dificultad para el acceso a datos por personas no autorizadas
o FACILIDAD DE USO, esfuerzo requerido para el aprendizaje de la aplicación
o MANTENIBILIDAD. Facilidad para corregir el producto en caso necesario.
o FLEXIBILIDAD, facilidad para modificar el producto
o FACILIDAD DE PRUEBA, depende del esfuerzo requerido para comprobar su corrección
o fiabilidad
o TRANSPORTABILIDAD, facilidad para adaptar el producto a otra plataforma
o REUSABILIDAD, facilidad para usar partes del producto en otros desarrollos
o INTEROPERATIVIDAD, facilidad del producto para trabajar con otros
PLAN DE GARANTÍA 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:
o Organización, dirección y seguimiento de los equipos de desarrollo
o Modelo de ciclo de vida a seguir, detallando fases y actividades
o Documentación requerida, determinando contenido y guión de cada documento
o Revisiones y auditorias, para garantizar que las actividades y los documentos son
correctos
o Organización de las pruebas, a distintos niveles
o Organización de la etapa de mantenimiento, determinando cómo gestionar la
realización de cambios
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:
o Deben ser realizadas por un grupo de personas y no individualmente
o El grupo de be ser reducido
o Debe ser imparcial, nada que ver con los desarrolladores
o Se debe revisar el producto, pero no el productor ni el proceso de producción
o Se debe establecer de antemano una lista formal de comprobaciones
o Se debe levantar acta de la reunión de revisión, recogiendo las decisiones tomadas
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
GESTIÓN DE CONFIGURACIÓN
 CONFIGURACIÓN, disposición de las partes que componen una cosa y le dan su peculiar figura.
 La CONFIGURACÏÓN 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:
o Documentos del desarrollo
o Código fuente
o Programas, datos y resultado de las pruebas
o Manuales de usuario
o Documentos de mantenimiento, informes de problemas y cambios
o Prototipos intermedios
o Normas particulares del proyecto
 Dado que los elementos software van evolucionando a lo largo del desarrollo se requiere:
o Control de versiones, almacenar de forma organizada las sucesivas versiones de cada
elemento de la configuración.
o Control de cambios, garantizar que las diferentes configuraciones del software se
componen de elementos compatibles entre sí (línea base).
NORMAS Y ESTÁNDARES
 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 normalización (International Standars Organization). En España
AENOR.
 METRICA-2, desarrollada por el Consejo Superior de Informática del MAP. Se basa en la
metodología de análisis y diseño de Yourdon/DeMarco.

ESPECIFICACIÓN DE SOFTWARE
MODELADO DE SISTEMAS
 El análisis y la definición de los requisitos debe dar lugar a la especificación 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 comprensión de los problemas planteados. Se trata de establecer modelos
conceptuales que reflejen la organización de la información y las diversas transformaciones que
se deben llevar a cabo con dicha información.
 Las metodologías de análisis de requisitos tratan de facilitar obtención de uno o varios modelos
que detallen el comportamiento deseado del sistema.
CONCEPTO DE MODELO
 Un modelo conceptual es una abstracción lógico-matemática del mundo real que facilita la
comprensión del problema a resolver. Se trata de ofrecer una visión de lato nivel, sin descender
a explicar detalles concretos del mismo. Indica QUÉ hace el sistema y no CÓMO lo debe hacer.
 Los OBJETIVOS a cubrir con los modelos son:
 o Facilitar la comprensión del problema
o Establecer un marco para la discusión que simplifique y sistematice el análisis
o Fijar las bases para el diseño
o Facilitar la verificación del cumplimiento de los objetivos del sistema
TÉCNICAS DE MODELADO (I)
 DESCOMPOSICIÓN. MODELO JERARQUIZADO, aplica el “divide y vencerás”, y así el problema
queda dividido en un subconjunto de subproblemas. Se trata de una descomposición 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 irán 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 gráficas que sean
entendibles por todos los que participan en el proyecto. Se suele recurrir a notaciones precisas
que combinan texto, tablas, diagramas y gráficos.
TÉCNICAS DE MODELADO (II)
 CONSIDERAR DISITNTOS PUNTOS DE VISTA, en la elaboración del modelo es necesario adoptar
un determinado punto de vista. Si así la descripción es insuficiente conviene adoptar más de
uno.
 REALIZAR UN ANÁLISIS DEL DOMINIO, es decir en campo de aplicación en que se enmarca el
sistema a desarrollar. Hay que considerar:
o Normativa que afecta al sistema
o Otros sistemas semejantes
o Estudios recientes en el campo de la aplicación, bibliografía, etc.
 Las ventajas de realizar un modelo más general son:
o Facilitar la comunicación entre el analista y el usuario del sistema, p.e. usando la misma
terminología.
o Creación de elementos realmente significativos del sistema, si se ajusta a la normativa
específica establecida.
o Reutilización posterior del software desarrollado.
ANÁLISIS DE REQUISITOS DE SOFTWARE
 El análisis es la fase de definición del futuro sistema y tiene una importancia decisiva en el
desarrollo de todas las etapas posteriores.
 Con el análisis de requisitos se trata de caracterizar el problema a resolver. El “cliente”
trabaja con el analista para elaborar las especificaciones y posteriormente se encargarán de
verificar el cumplimiento de las mismas (contrato).
 El análisis debe producir un modelo válido necesario y suficiente para recoger todas las
necesidades y exigencias del sistema, así como las restricciones que los limiten. Para una
especificación correcta se requiere:
o Completo y sin omisiones
o Conciso y sin trivialidades
o Sin ambigüedades
 o Sin detalles de diseño o implementación
o Fácilmente entendible por el cliente
o Separando requisitos funcionales u no funcionales (capacidades mínimas y
máximas, interfaces estándares, recursos necesarios, seguridad, fiabilidad,
mantenimiento, etc.
o División y jerarquía del modelo global, con el fin de simplificar su comprensión
o Incluyendo los criterios de validación del sistema, para comprobar si se ajusta al
contrato inicial.
TAREAS DEL ANÁLISIS
 Dependiendo de las características y complejidad del sistema se podrán seguir los siguientes
pasos:
o ESTUDIO DEL SISTEMA EN SU CONTEXTO, análisis del dominio en un contexto
globalizador
o IDENTIFICACIÓN DE NECESIDADES, detectar necesidades de medios dentro de plazos y
presupuestos
o ANÁLISIS DE ALTERNATIVAS Y ESTUDIO DE VIABILIDAD, tanto técnica como económica
o ESTABLECIMIENTO DEL MODELO DEL SISTEMA, para lo que podemos usar técnicas
gráficas, texto, herramientas CASE, etc.
o ELABORACIÓN DEL DOCUMENTO DE ESPECIFICACIÓN DE REQUISITOS, dónde se
recogen las conclusiones del análisis y sirve de punto de partida para el diseñador.
o REVISIÓN CONTINUADA DEL ANÁLISIS, a menudo en las etapas de diseño e
implementación se hace necesaria la revisión de alguno de los requisitos, o bien por
cambios de criterio del cliente
NOTACIONES PARA LA ESPECIFICACIÓN
 La especificación es una descripción del modelo del sistema a desarrollar.
 Se debe usar una notación fácil de entender por el cliente:
o Lenguaje natural, utilizando explicaciones más o menos precisas y exhaustivas. Es
posible limitar precisiones y ambigüedades si se establecen reglas de uso del lenguaje.
o Diagramas de flujo de datos
o Diagramas de transición de estados
o Descripciones funcionales. Pseudocódigo. Se emplea un preciso lenguaje natural
estructurado. No se debe detallar demasiado el cómo, pues esto corresponde a la fase
de diseño, donde se usan lenguajes estructurados como PLD.
o Descripción de datos, de trata de detallar la estructura interna de los datos que maneja
el sistema. En la metodología Yourdon se conoce como diccionario de datos, incluyendo
nombre de cada dato, utilización y estructura.
o Diagramas de modelos de datos
DIAGRAMAS DE FLUJO DE DATOS (DFD)
 Se trata de realizar un modelo gráfico para representar el flujo de datos que entra en el sistema,
las transformaciones que debe realizar y la salida producida. También se representan las
entidades externas la sistema que producen o consumen datos. El DFD inicial es el de contexto,
posteriormente y de forma jerárquica se van desarrollando otros DFD’s que detallan las
transformaciones, las entradas y salidas del diagrama detallado deben coincidir con el proceso
correspondiente.
 Recoge de forma estática los procesos, dónde en el último nivel de refinamiento se especifican
en lenguaje natural estructurado, y su interrelación.

DIAGRAMAS DE TRANSICIÓN DE ESTADOS

 Describe el
comportamiento
dinámico del sistema
basándose en sus
estados más
importantes.
 Al igual que en los
autómatas de estados
finitos, el evento motiva el cambio de estado del sistema.
DIAGRAMAS DE MODELO DE DATOS
 Se trata de organizar e interrelacionar los datos que utiliza el sistema.
 El MODELO ENTIDAD-RELACIÓN permite definir todos los datos y establecer las relaciones que
deben existir entre ellos.

DOC. DE ESPECIFICACIÓN DE REQUISITOS

 El documento o la especificación de requisitos (SRD o SRS) recoge de forma integral los
resultados del análisis.
 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
verificación de las especificaciones (contrato).
 Diversos organismos de estandarización hacen propuestas sobre la estructura del SRD: IEEE,
DoD, etc. Vemos el modelo de SRD de la Agencia Espacial Europea. Dependiendo de las
características y complejidad del proceso tal vez no sea necesario cubrir todos los apartados.
FUNDAMENTOS DEL DISEÑO DEL SOFTWARE
CONCEPTO DE DISEÑO
 Descripción o bosquejo de alguna cosa hecho por palabras.
 En un sistema software la realización del diseño 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 técnicas para realizar diseños nuevos son empíricas y no están suficientemente
formalizadas, mientras que para proyectos ya conocidos, como los de gestión, existen
herramientas tales como lenguajes de 4ª generación.
 En el diseño se establece el CÓMO debe funcionar el sistema, determinando la organización y
la estructura del software.
ACTIVIDADES DE UN DISEÑO SISTEMÁTICO
 DISEÑO ARQUITECTÓNICO, se abordan los aspectos estructurales y de organización del sistema,
y su posible división en subsistemas
 DISEÑO DETALLADO, organización y estructura de los módulos
 DISEÑO PROCEDIMENTAL, organización de las operaciones o servicios que ofrecerá cada
módulo. Se suele realizar en pseudocódigo o PDL, pero desarrollando sólo los aspectos más
relevantes del algoritmo
 DISEÑO DE DATOS, organización de la base d edatos del sistema. Se parte de los diagramas E-R.
 DISEÑO DE LA INTERFAZ DE USUARIO, organizar y facilitar la utilización del sistema por parte del
usuario
 El resultado de estas actividades debe plasmarse en el Documento d Diseño Software (SDD)
CONCEPTOS PARA EL DISEÑO
 ABSTACCIÓN, identificar los elementos significativos del sistema y abstraer la utilidad específica
de cada uno
o ABSTRACCIONES FUNCIONALES, sirven para crear expresiones parametrizadas usando
funciones o procedimientos
o TIPOS ABSTRACTOS, junto con el tipo de datos se deben crear los métodos que manejan
estos datos
o MÁQUINAS ABSTRACTAS, definición formal del comportamiento de una máquina
 MODULARIDAD, el diseño modular propone dividir el sistema en partes diferenciadas y definir
sus interfaces. Sus ventajas: claridad, reducción de costos y reutilización
 REFINAMIENTO, a partir de una idea no muy concreta se va refinando mediante aproximaciones
hasta el detalle
 ESTRUCTURAS DE DATOS, para organizar la información que maneja el sistema: registros,
conjuntos, listas, pilas, colas, árboles, grafos, tablas, ficheros, ...
 OCULTACIÓN, de la organización de los datos internos y de los detalles del algoritmo, se muestra
en el interfaz sólo aquello que resultará invariable ante cambios. Ventajas: depuración,
mantenimiento, ...
 GENERICIDAD, consiste en diseñar un elemento genérico, con las características 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 programación 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 anulación
de una operación. A veces en el padre interesa declarar un método sin implementarlo, lo harán
los hijos en diferido
 CONCURRENCIA, se trata de aprovechar al máximo el procesador garantizando unos tiempos
máximos de respuesta para tareas críticas. Problemas de los sistemas con restricciones:
o Tareas concurrentes, asegurar que todas cumplen sus restricciones
o Sincronización de tareas, determinando los puntos de sincronización entre ellas
o Comunicación entre tareas, unas serán productoras de datos y otras consumidoras.
Para evitar la corrupción de datos compartidos permitir sólo concurrencia en lectura
con semáforos, monitores y regiones críticas
o Interbloqueos (deadlock) cuando varias tareas esperan un evento que nunca se
producirá.
NOTACIONES PARA EL DISEÑO
 Debe resultar precisa, clara y fácil de interpretar. Se emplean notaciones formales cuasi
matemáticas
 NOTACIONES ESTRUCTURALES, se desglosa y estructura el sistema en sus partes
o DIAGRAMAS DE BLOQUES
o CAJAS ADOSADAS

DIAGRAMAS DE ESTRUCTURA (Yourdon)

Describen la estructura de los sistemas software como una jerarquía de módulos, reflejando sólo su
organización estática
RECTÁNGULO, módulo
LÍNEA, relación entre módulos, el superior utiliza el módulo inferior
ROMBO, opcional
ARCO, repetitiva
CIRCULO CON FLECHA, envio de datos o información de control (correcto, repetir,
desconectar, etc)

DIAGRAMAS HIPO (Hierachy-Input-Process-Output)

Se muestra primero la jerarquía entre los módulos del sistema

Y en los diagramas HIPO de detalle hay 3 zonas: Entrada, Proceso y

Salida
DIAGRAMAS DE JACKSON
El proceso de diseño es sistemático y se lleva a cabo en tres pasos:
• Especificación de la estructura de datos de entrada y de salida
• Obtención de la estructura del programa
• Expansión de la estructura del programa para lograr el diseño detallado
NOTACIONES ESTÁTICAS
 Describen las características estáticas del sistema, tales como la organización de la
información, sin tener en cuenta su evolución durante el funcionamiento del sistema.
 Las notaciones son las mismas que se emplean en la especificación:
o DICCIONARIO DE DATOS, dónde se detalla la estructura interna de los datos que
maneja el sistema. En el diseño se amplía y se completa el diccionario de la
especificación hasta el nivel de detalle necesario para iniciar la codificación.
o DIAGRAMAS ENTIDAD-RELACIÓN, definiendo las relaciones entre datos y la
organización de la información. Se amplia y detalla el diagrama de la especificación
con las nuevas entidades y relaciones.
NOTACIONES DINÁMICAS
 Permiten describir el funcionamiento del sistema durante su funcionamiento.
 Las notaciones son las misma utilizadas en la especificación:
o DIAGRAMAS DE FLUJO DE DATOS, serán mucho más exhaustivos que los de la
especificación.
o DIAGRAMAS DE TRANSICIÓN DE ESTADOS, más detallados que reflejen las transiciones
entre estados internos.
o LENGUAJE DE DESCRIPCIÓN DE PROGRAMAS (PLD), permite realizar la especificación
funcional del sistema.
NOTACIONES HIBRIDAS: DIAGRAMAS DE ABSTRACCIONES
Permiten un enfoque globalizado del diseño atendiendo a aspectos estáticos (datos), dinámicos
(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 abstracción se distinguen 3 partes:
NOMBRE, es su identificador
CONTENIDO, dónde se define la organización de los datos
OPERACIONES, para manejar el contenido de la abstracción
Las abstracciones funcionales (funciones o procedimientos), sólo tiene la parte de operación.
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 relación jerárquica entre abstracciones, de
manera que la abstracción superior utiliza la inferior.

NOTACIONES HIBRIDAS: DIAGRAMAS DE OBJETOS

Se emplea una terminología distinta, pero la similitud 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
TÉCNICAS GENERALES DE DISEÑO SOFTWARE
TÉCNICAS DE DISEÑO
 Los objetivos de las técnicas de diseño software son fundamentalmente:
o La descomposición modular del sistema
o Los diseños de los algoritmos y estructuras de datos fundamentales que se deben usar
en el sistema
 Primero veremos las características deseables de una buena descomposición modular del
sistema, y luego se presentarán técnicas de diseño:
o Diseño funcional descendente
o Diseño orientado a objetos
o Diseño de datos
DESCOMPOSICIÓN MODULAR
 Los pasos a seguir son:
1. Identificar los módulos
2. Describir cada módulo
3. Describir las relaciones entre módulos
 Tipos de módulos:
1. Código fuente, en el lenguaje de programación usado
2. Tabla de datos, para datos de inicialización u otros
3. Configuración, se agrupa en un módulo toda la información de configuración en el
entorno de trabajo
4. Otros: ficheros de ayuda en línea, manuales, etc.
 Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda
considerar suficientemente válida
o Independencia fucional
o Acoplamiento
o Cohesión
o Comprensibilidad
o Adaptabilidad
DESCOMPOSICIÓN MODULAR: INDEPENDENCIA FUNCIONAL
 Al final de los documentos ADD y DDD debe haber una matriz REQUISITOS/COMPONNETES. En
principio, cada función será realizada en un módulo distinto. Si las funciones son independientes
los módulos tendrán independencia funcional.
 Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es
recomendable reducir las relaciones entre módulos al mínimo.
 Para medir la independencia funcional hay dos criterios: acoplamiento y cohesión.

DESCOMPOSICIÓN MODULAR: ACOPLAMIENTO

El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la
complejidad de la interfase:
 FUERTE,
o POR CONTENIDO, cuando desde un módulo se pueden cambiar datos locales de
otro
o COMÚN, se emplea una zona común de datos a la que tienen acceso varios módulos
  MODERADO,
o DE CONTROL, la zona común es un dispositivo externo al que están ligados los
módulos, esto implica que un cambio en el formato de datos afecta a todos estos
módulos
o POR ETIQUETA, en intercambio de datos se realiza mediante una referencia a la
estructura completa de datos (vector, pila, árbol, grafo, ...)
 DÉBIL,
o DE DATOS, viene dado por los datos que intercambian los módulos. Es el mejor
posible
o SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe

DESCOMPOSICIÓN MODULAR: COHESIÓN

 Es necesario lograr que el contenido de cada módulo tenga la máxima coherencia. Para que
el nº de módulos no sea demasiado elevado y complique el diseño se tratan de agrupar
elementos afines y relacionados en un mismo módulo.
o ALTA
 COHESIÓN ABSTRACCIONAL, se logra cuando se diseña el módulo como tipo
abstracto de datos o como una clase de objetos
 COHESIÓN FUNCIONAL, el módulo realiza una función concreta y específica
o MEDIA
 COHESIÓN SECUENCIAL, los elementos del módulo trabajan de forma
secuencial
 COHESIÓN DE COMUNICACIÓN, elementos que operan con le mismo
conjunto de datos de entrada o de salida
 COHESIÓN TEMPORAL, se agrupan elementos que se ejecutan en el mismo
momento. Ej. Arrancar o parar dispositivos
o BAJA
 COHESIÓN LÓGICA, se agrupan elementos que realizan funciones similares.
Ejs.: módulos de E/S o de tratamiento de errores
 COHESIÓN COINCIDENTAL, es la peor y se produce cuando los elementos
de un módulo no guardan relación alguna
 La descripción del comportamiento de un módulo permite establecer el grado de cohesión:
o Si es una frase compuesta y contiene más de un verbo la cohesión será MEDIA
o Si contiene expresiones secuenciales (primero, entonces, cuando...), será temporal
o secuencial
o Si la descripción no se refiere a algo específico (Ej. Todos los errores), cohesión
lógica
o Si aparece “inicializar”, “preparar”, “configurar”, probablemente sea temporal.
DESCOMPOSICIÓN MODULAR: COMPRENSIBILIDAD
 Para facilitar los cambios, el mantenimiento y la reutilización de módulos es necesario que
cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia
funcional, pero además es deseable:
o IDENTIFICACIÓN, el nombre debe ser adecuado y descriptivo
 o DOCUMENTACIÓN, debe aclarar todos los detalles de diseño e implementación que
no queden de manifiesto en el propio código
o SIMPLICIDAD, las soluciones sencillas son siempre las mejores
DESCOMPOSICIÓN MODULAR: ADAPTABILIDAD
 La adaptación de un sistema resulta más dificil cuando no hay independencia funcional, es
decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible.
Otros factores para facilitar la adaptabilidad:
o PREVISIÓN, es necesario prever que aspectos del sistema pueden ser susceptibles de
cambios en el futuro, y poner estos elementos en módulos independientes, de manera
que su modificación afecte al menor número de módulos posible
o ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificación,
diseño, e implementación para obtener un conocimiento suficiente del sistema antes
de proceder a su adaptación
o CONSISTENCIA, después de cualquier adaptación se debe mantener la consistencia del
sistema, incluidos los documentos afectados
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE
 La descomposición del sistema se hace desde un punto de vista funcional.
 Desde el punto de vista de la codificación, cada módulo corresponde esencialmente a un
subprograma.
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE: DESARROLLO POR REFINAMIENTO
PROGRESIVO

 Esta técnica consiste en la aplicación de la fase de diseño de la programación estructurada.

Las estructuras básicas son la secuencia, la selección entre alternativas y la iteración.
 Cada paso en la descomposición consiste en refinar o detallar una parte del programa global
u operación, que a su vez podrá ser descompuesta en otras operaciones. Los refinamientos
se basan en la aplicación de estructuras de control en el programa. Veamos como ejemplo
“obtener las raíces de una ec. de 2º grado”:
Obtener raíces ->
Leer coeficientes
Resolver ecuación -->
Calcular discriminante
Calcular raíces -->
SI el discriminante es negativo ENTONCES
Calcular raíces complejas
SI-NO
Calcular raíces reales
FIN-SI
Imprimir raíces
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE: PROGRAMACIÓN ESTRUCTURADA DE JACKSON
 Esta técnica sigue las ideas de la programación estructurada (secuencia, selección, iteración)
y el método de refinamientos sucesivos pàra 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 técnica JSP:
1. Analizar el entorno del problema y describir las estructuras de datos a procesar
2. Construir la estructura del programa basándose en las estructuras de datos
3. Definir las tareas a realizar en cada módulo de la estructura del programa
 Este tercer paso corresponde en su detalle a la fase de codificación
 Ej.: Programa para justificar el texto, es decir, reagrupar las palabras en líneas e intercalar
los espacios adecuados para que se ajusten a los márgenes
o PASO 1. Las estructuras de datos que reconocemos son
 Texto de entrada = {[separador de párrafo | palabra]}
 Texto de salida = {[línea ajustada | línea final | línea en blanco]}

o 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

TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE: DISEÑO ESTRUCTURADO

 Según esta técnica, la tarea de diseño consiste en

pasar de los DFDs a los diagramas de estructura.
 Hay que establecer una jerarquía o estructura de
control entre los diferentes módulos, que no está
implícita en el modelo funcional descrito en los
DFDs
 Para dos módulos relacionados en el DFD (A)
tenemos 3 posibilidades de organización modular
diferentes.

 Para establecer la jerarquía de control entre módulos se

recomienda hacer ciertos análisis en el flujo de datos: de flujo
de transformación y de flujo de transacción. Para ello es
recomendable construir un DFD con todos los procesos
contenidos en los primeros niveles prescindiendo de los
almacenes.
El análisis de flujo de transformación consiste en identificar un flujo global de información
desde los elementos de entrada hasta los de salida.
Los procesos se agrupan en 23 regiones: flujo de entrada, de transformación y de salida.
 El flujo de transacción es aplicable cuando el flujo de datos se puede
descomponer en varias líneas separadas. El análisis consiste en
identificar el centro de transacción a partir del cual se ramifican las
líneas de flujo a las regiones correspondientes a cada una de las
transacciones

TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE: DISEÑO

ESTRUCTURADO. EJ. GESTIÓN DE BIBLIOTECA

TÉCNICAS DE DISEÑO BASADO EN ABSTRACCIONES: MÉTODO DE ABBOTT

 A partir de la descripción o especificación de los módulos es posible identificar las palabras o
términos que puedan corresponder a elementos significativos del diseño:
o Tipos de datos, que aparecen como sustantivos genéricos
o Atributos, son sustantivos en general
o Operaciones, tienen la forma de verbos o nombres de acciones
 Se subrayan en la descripción las palabras significativas haciendo
una lista de nombres y otra de verbos u operaciones. Hay que
eliminar los términos irrelevantes o los sinónimos de palabras ya
aparecidas

TÉCNICAS DE DISEÑO ORIENTADAS A OBJETOS

 Es esencialmente igual al diseño basado en abstracciones, añadiendo la herencia y el

polimorfismo.
 En la descomposición modular del sistema cada módulo contiene la descripción de una clase de
objetos o de varias clases relacionadas entre sí.
 PASOS:
o Estudiar y comprender el problema a resolver
o Desarrollar en líneas generales una posible solución, al menos informal
o Formalizar dicha estrategia en términos 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 operación en función de las otras, y subsanar posibles omisiones
 Asignar clases y objetos a los módulos del sistema
TÉCNICAS DE DISEÑO DE DATOS
 Muchas aplicaciones necesitan almacenar información de forma permanente y la mejor forma
de hacerlo es crear una base de datos subyacente
 Podemos enfocar la organización de la base de datos de 3 formas:
o Nivel externo Esquemas de usuario
o Nivel conceptual Esquemas lógicos
o Nivel interno Esquemas físicos
 El nivel externo corresponde a la visión del usuario, en la fase de análisis de pasa al nivel
conceptual, que establece la organización de los datos, y finalmente en la etapa de diseño se
pasa al nivel interno.
 DISEÑO DE BASES DE DATOS RELACIONALES, en este modelo la eficiencia se basa en:
o Las FORMAS NORMALES, que tienden a evitar las redundancias en los datos
almacenados
 FN1, la información asociada a cada columna de la tabla es un único valor, y no
una colección
 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.
o Los INDICES, que mejoran la velocidad de acceso a los datos
TÉCNICAS DE DISEÑO DE DATOS: DISEÑO 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 número de referencia o identificador que
las relaciona, sirve como clave primaria.
 En el modelo E-R todas las relaciones se consideran de
asociación, y la manera de trasladar esto a las tablas
depende de la cardinalidad de la relación. La relación se
convierte en una tabla que contiene referencias a las tablas
de las entidades relacionadas, así como los atributos de la
relación (cale para cualquier cardinalidad, incluso N:N). Si es
1:N es posible incluir los datos de la relación en la tabla con
cardinalidad 1. Si la cardinalidad es 1:1 se pueden fundir las
tablas de las dos entidades.
TÉCNICAS DE DISEÑO DE DATOS: COMPOSICIÓN Y HERENCIA
 Las relaciones de COMPOSICIÓN se tratan como las de asociación, y en ellas la cardinalidad del
objeto compuesto suele ser 1, por lo que se puede aplicar la simplificación.
 Cuando una clase tiene carias subclases hay 3 formas de almacenar las entidades en tablas:
o Una tabla para la superclase con los atributos comunes y una tabla para cada subclase
o Desaparece la tabla de la superclase y los atributos comunes heredados se repiten en
las subclases
 o 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 serán opcionales para los
elementos
CODIFICACIÓN Y PRUEBAS
CODIFICACIÓN DEL DISEÑO
 Nos vamos a referir a las últimas fases del ciclo de vida: codificación, pruebas de unidades,
integración y pruebas de sistema.
 Cuando alguna de las pruebas no resulta positiva es necesario repetir la codificación o la
integración y probar de nuevo.
 La fase de codificación constituye el núcleo central en cualquiera de los modelos y tiene una
importancia fundamental ya que elabora los programas fuente.
 Previamente a la codificación es necesario elegir el lenguaje que se empleará así como la
metodología de programación. También se pueden establecer en el equipo unas normas y un
estilo de programación común, lo que mejorará la coordinación y facilitará el trabajo. Además
se consigue facilitar el mantenimiento y mejorar la reusabilidad del software.
 Cuando el resultado de las pruebas no sea satisfactorio será necesario modificar el código, lo
que podrá introducir nuevos errores. Si la programación es estructurada será más fácil localizar
la disfunción y la posterior modificación y las pruebas del código, dónde podemos introducir
puntos de test.
LENGUAJES DE PROGRAMACIÓN
 Aunque los lenguajes han evolucionado mucho desde los años 50 todavía están más próximos
a la máquina que al pensamiento humano. Los lenguajes suelen adoptar los avances
metodológicos que se producen en el desarrollo del software. Ej.: C y C++
 DESARROLLO HISTÓRICO, muchos han sido desarrollados con fines experimentales y muy pocos
han llegado a ser utilizados industrialmente:
o 1ª GENERACIÓN: muy próximos al lenguaje máquina
 Ensamblador, asocia a cada instrucción de la máquina un nemónico
o 2ª GENERACIÓN: no dependen de la CPU, se programa de manera simbólica, en “alto
nivel”.
 FORTRAN (FORula TRANslator), para aplicaciones científicas
 COBOL, para procesamiento de información. Supone el 70 %
 ALGOL, da gran importancia a la tipificación de datos
 BASIC, sencillo y fácil de aprender. Desarrollado para el PC.
o 3ª GENERACIÓN: programación estructurada con declaración de tipos. Los últimos van
asociados a otros paradigmas.
 PASCAL, fue diseñado para la enseñanza de la programación estructurada.
Tipificación rígida y no contempla la codificación por separado
 MÓDULA-2, descendiente de pascal, se incorpora la estructura de módulo. Se
mejora modularidad, concurrencia, abstracción y ocultación
 C, desarrollado para la codificación del UNIX. Flexible y potente. No hay
restricciones sobre las operaciones con distintos tipos.
 ADA, descendiente de pscal, mucho más potente y complejo. Incorpora
modularidad, abstracción, ocultación, concurrencia y sincronización entre
tareas.
  SMALLTALK, precursos de los lenguajes orientados a objetos
 C++, incorpora en C los mecanismos de la POO: ocultación, clases, herencia y
polimorfismo.
 EIFFEL, permite la definición de clases genéricas, herencia múltiple y
polimorfismo.
 LISP, lenguaje funcional usado en IA y sistemas expertos. Basado en listas
admite recursividad. Maneja bien los símbolos
 PROLOG, lenguaje lógico en que se construye una base de conocimiento basada
en reglas a partir de la cual podemos inferir nuevos hechos o reglas.
o 4ª GENERACIÓN: mayor grado de abstracción. Se agrupan en:
 BASES DE DATOS; como SQL permiten acceder y manipular la información.
 GENERADORES DE PROGRAMAS, son eficientes en un dominio de aplicaciones
limitado. La mayoría producen aplicaciones de gestión y la salida va en cobol,
aunque se han desarrollado herramientas CASE que generan programas en C++
o ADA.
 CÁLCULO, hojas de cálculo, herramientas de simulación y diseño para el control,
etc.
 OTROS: herramientas para la especificación y verificación formal de programas,
lenguajes de simulación, de prototipos, etc.
PRESTACIONES DE LOS LENGUAJES: ESTRUCTURAS DE CONTROL
 se incluyen aquí, además de las características propias de la programación estructurada, el
manejo de excepciones y la concurrencia.
o Programación estructurada: secuencia, iteración y selección (verdadero-falso y por
casos)
o Manejo de excepciones: errores humanos, fallos hardware, errores software, datos de
entrada vacíos, valores fuera de rango, etc. (estructuras exception when y raise).
o Concurrencia, tareas simultáneas, sincronización, comunicación 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 más flexible. El avance en la ejecución de las corrutinas
se produce según 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 dinámicamente nuevos
procesos una vez iniciado el programa.
 PARA LA COMUNICACIÓN ENTRE TAREAS.
 VARIABLES COMPARTIDAS
o SEMÁFOROS
o REGIONES CRÍTICAS
o MONITORES
 PASO DE MENSAJES
 o CSP
o LLAMADA A PROCEDIMIENTOS REMOTOS
o REDENZVOUS, DE ADA
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 precisión. En ocasiones también permiten el manejo de complejos.
o Otros tipos simples son char y string, para el manejo de cadenas. Los tipos
enumerados también pueden resultar útiles, un tipo enumerado muy frecuente son
los booleanos.
o En ocasiones los lenguajes permiten utilizar subrangos.
 DATOS COMPUESTOS, son combinaciones de datos simples y compuestos ya definidos.
Pueden ser homogéneos como los ARRAYS y heterogéneos como los RECORDS o STRUCTS.
o Para el manejo de estructuras dinámicas de datos muchos lenguajes incluyen
punteros
 CONSTANTES, en los lenguajes modernos se pueden declarar constantes simbólicas, sin
indicar directamente su valor numérico.
 COMPROBACIÓN DE TIPOS, se pueden distinguir 5 niveles:
o Nivel 0: sin tipos, no es posible declarar nuevos tipos y todos los datos deben
pertenecer a tipos predefinidos
o Nivel 1: tipado automático, el compilador decide cuál es el tipo más adecuado para
cada dato.
o Nivel 2: tipado débil, el compilador hace inferencias sobre los tipos y solo son
posibles determinadas conversiones
o Nivel 3: tipado semirígido, todos los datos deben ser declarados con su tipo
o Nivel 4: tipado fuerte, aquí además de declarar los tipos, el programador está
obligado a hacer explícita cualquier conversión de tipos.
 ABSTRACCIONES Y OBJETOS.
o ABSTRACCIONES FUNCIONALES
o TIPOS ABSTRACTOS DE DATOS
o OBJETOS
 MOODULARIDAD. Se requiere la compilación por separado. Además se introducen de forma
redundante la declaración y la definición de cada módulo, para permitir al compilador hacer
comprobaciones acerca de la consistencia. C y modula-2 lo tienen, pero pascal es
monolítico.
ASPECTOS METODOLÓGICOS
 Estos aspectos pueden mejorar la codificación bajo determinados puntos de vista: claridad,
manejo de errores eficiencia y transportabilidad.
 Normas y estilo, para conseguir un trabajo del equipo homogéneo. Ejemplos:
o Formato y contenido del as cabeceras de cada módulo
o Formato y contenido para los comentarios
o Uso del indentado
o Elección de nombre y uso de mayúsculas
o Restricciones sobre el tamaño del os módulos, 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 introducción de datos incorrectos.
 DEFECTO, incorrección 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 erróneo
 ERROR, estado no válido de un programa al que se llega como consecuencia
de un fallo.
o Al codificar podemos adoptar distintas actitudes ante los errores:
 NO CONSIDERAR LOS ERRORES, no es realista esta postura
 PREVENCIÓN DE ERRORES, consiste en detectar los fallos antes de que
provoquen un error. Hay que evitar la propagación de errores y tener
siempre a la salida un resultado correcto o una señal de fallo.
 RECUPERACIÓN DE ERRORES, Cuando no es posible depurar todos los fallos
es necesario hacer un tratamiento de errores para devolver al programa a
un estado válido y evitar que el error se propague
 Detección del error
 Recuperación del error. Se pueden usar dos esquemas en general:
o RECUPERACIÓN HACIA DELANTE, hay que programas un
mecanismo de excepciones para que cuando se detecte el
error se corrija el estado y se continúe correctamente la
ejecución.
o RECUPERACIÓN HACIA ATRÁS, corrige el estado no válido
restaurando el programa a un estado correcto anterior,
 Una transacción es una operación que puede terminar con éxito o con fallo,
en cuyo caso se aborta y se restaura el estado de antes de comenzar dicha
transacción.
ASPECTOS METODOLÓGICOS: EFICIENCIA Y TRANSPORTABILIDAD
 La potencia de cálculo y la cantidad de memoria disponible en los computadores actuales hacer
preferible la claridad en el código que la EFICIENCIA.
o EFICIENCIA EN MEMORIA, en la fase de diseño se estudian las posibles alternativas y se
opta por el algoritmo que optimiza el uso dela memoria.
o EFICIENCIA DE TIEMPO, es importante en el desarrollo de sistemas de tiempo real muy
críticos. A veces se mejora la eficiencia de tiempo a costa de ocupar más memoria. En
el diseño se estudian las alternativas y se adopta el algoritmo más rápido. Técnicas de
codificación para aumentar la eficiencia de tiempo:
 Tabular cálculo complejos
 Expansión en línea, emplear macros en vez de subrutinas
 Simplificar las expresiones aritméticas y lógicas
 Sacar fuera de los bucles lo que no sea necesario repetir
 Usar estructuras de datos de acceso rápido
 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 adaptación de
la aplicación a las nuevas arquitecturas.
o Los factores para la transportabilidad son:
 Utilización de estándares
 Aislar las peculiaridades, colocándolas en módulos separados. Se procurará
evitar aquellos elementos no consolidados y que pueden estar sujetos a futuros
cambios o revisiones.
 La peculiaridad de los distintos tipos de computadores depende de la arquitectura y del sistema
operativo utilizado
TÉCNICAS 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 módulo, según avanza la codificación del proyecto. Finalmente
se harán las pruebas de integración entre módulos 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:
o Una buena prueba encuentra los errores y no los encubre
o Para determinar si hubo error es necesario conocer el resultado correcto
o Deben participar codificador y diseñador
o Al corregir un error se pueden introducir otros nuevos
o No es posible demostrar la ausencia de defectos mediante pruebas
o No son posibles las pruebas exhaustivas. Con el menor esfuerzo posible hay que
detectar el máximo nº de defectos, en especial los más graves.
o Las pruebas se realizan en un entorno de ejecución controlado, para asegurar la
estabilidad en los pruebas y automatizar en lo posible este proceso.
TÉCNICAS DE PRUEBAS DE UNIDADES: CAJA NEGRA
 Las técnicas de pruebas de unidades siguen dos estrategias fundamentales:
o PRUEBAS DE CAJA NEGRA, se ignora por completo
la estructura interna del programa y se
comprueba la corrección de entradas y salidas del
programa.
o Lo importante es la elaboración de los casos de
prueba con el objetivo de descubrir los errores e
incorrecciones. Métodos:

 PARTICIÓN EN CLASES DE EQUIVALENCIA, se trata de ividir el espacio de ejecución del programa

en varios subestapacios o clases equivalentes desde el punto de vista del a caja negra. Hay que:
o Determinar las clases equivalentes apropiadas
o Establecer pruebas para cada clase de equivalencia, con
datos de entrada válidos y no válidos. Se repiten las pruebas
hasta cubrir todos los casos válidos de todas las clases.
 ANÁLISIS DE VALORES LÍMITE, los errores tienden a aparecer al
operar en las fronteras. Directrices para la elaboración de casos de pruebas:
 o Entradas, probar los valores del límite y justo fuera del límite
o Salidas, probar los valores del límite y justo fuera del límite
o Memoria, probar tamaños nulos, límite superior y superior al límite de todas las
estructuras de datos del programa
o Recursos, probar límites. Si terminales=30, probar 0, 20 y 31
o Otros, probar los valores límite y establecer las pruebas
 COMPARACIÓN DE VERSIONES, se desarrollan varias
versiones software para resolver la especificación del módulo
y se comparan los resultados con el fin de detectar errores.
 EMPLEO DELA INTUICIÓN, la intuición y la experiencia puede
mejorar los casos de prueba, también es conveniente que
participen expertos ajenos al desarrollo.
TÉCNICAS DE PRUEBAS DE UNIDADES: CAJA TRANSPARENTE
 Se tiene en cuenta la estructura interna del módulo. Los casos de prueba deben conseguir que:
o Todas las decisiones se ejecuten en uno y otro
sentido
o Todos los bucles se ejecuten en los supuestos más
diversos posibles
o Todas las estructuras de datos se modifiquen y
consulten alguna vez
 La complejidad de los módulos dificulta realizar exhaustivas pruebas de caja transparente.
Conviene que participen expertos con un conocimiento amplio de las estructura del programa.
Métodos:

TÉCNICAS DE PRUEBAS DE UNIDADES: CAJA TRANSPARENTE

Diagramas de flujo con 3 y con 4 predicados lógicos simples

ESTIMACIÓN DE ERRORES NO DETECTADOS

 Resulta imposible demostrar que un módulo carece de defectos, pero podemos hacer una
estimación estadísitca de erratas que permanecen sin detectar:
o Anotar el nº de errores que se producen inicialmente al pasar los casos de prueba.
o Corregir el módulo hasta que sdesaparezcan todos esos errores
o Introducir en el módulo, de forma aleatoria un nº razonable de errores
o Someter al módulo nuevamente a los casos de prueba y ver el nº de errores que se
detectan
o De esta forma podemos estimar el nº de errores que han permanecido sin ser
detectados en el programa
 En función de los resultados se valorará la necesidad de preparar nuevos casos de prueba.
ESTRATEGIAS DE INTEGRACIÓN
 Se integran los módulos del sistema para conformar el sistema completo. Causas de error:
o Desacuerdos en el interfaz entre módulos
o Interacción indebida entre módulos
o Imprecisiones acumuladas
 Estrategias básicas para la integración:
o INTEGRACIÓN BIG BANG, en un único paso se integran todos los módulos, de forma que
todos los defectos se manifiestan a la vez. Solo recomendable para sistemas pequeños.
o INTEGRACIÓN DESCENDENTE, se parte de un módulo principal P, que se prueba con
“módulos de andamiaje”, los cuales van siendo sustituidos por los verdaderos de forma
progresiva por niveles. Los módulos de andamiaje;
 No hacen nada y solo sirven para comprobar el interfaz
 Imprimen un mensaje de seguimiento, con información de la llamada
 Suministran un resultado fijo
 Suministran un resultado aleatorio
 Suministran un resultado tabulado u obtenido con un algoritmo simplificado
o El trabajo de elaborar estos módulos 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 difícil buscar los casos de pruebas especiales o dirigidas a los últimos módulos
integrados
o INTEGRACIÓN ASCENDENTE, se codifican por separado y en paralelo todos los módulos
del nivel más bajo. Para probarlos se codifican módulos gestores o conductores que los
hacen funcionar independientemente o en combinaciones sencillas. Las ventajas son:
 Facilita el trabajo en paralelo
 Facilita el ensayo de situaciones especiales
o La Integración Sandwich consiste en realizar integración ascendente con los módulos de
nivel más bajo y descendente con los de nivel más alto.

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:
o PRUEBAS DE RECUPERACIÓN, para comprobar la capacidad del sistema para
recuperarse ante fallos
 o PRUEBAS DE SEGURIDAD, par comprobar los mecanismos de protección ante un
acceso no autorizado
o PRUEBAS DE RESISTENCIA, para comprobar el comportamiento del sistema ante
situaciones excepcionales
o PRUEBAS DE SENSIBILIDAD, para comprobar el tratamiento que da el sistema a ciertas
singularidades relacionadas casi siempre con los algoritmos matemáticos utilizados
o PRUEBAS DE RENDIMIENTO, para comprobar las prestaciones del sistema que son
críticas en tiempo
 PRUEBAS ALFA Y BETA. Los usuarios también deben intervenir en las pruebas finales del
sistema
o 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
o Pruebas beta, los usuarios trabajan con el sistema en un entorno real y sin ayuda,
anotando los problemas que se le presentan
AUTOMATIZACIÓN DE PROCESO DE DESARROLLO
ENTORNOS DE DESARROLLO SOFTWARE
 Entorno se refiere al contexto dentro del cual se desarrolla una determinada actividad, o
también a la combinación de instrumentos utilizados.
 El entorno de desarrollo software, SEE, cuenta con una serie de técnicas de automatización
denominadas CASE.
 Las primeras herramientas se referían a la fase de codificación, así el entorno de programación
clásico consiste en un compilador con editor, montador de enlaces, etc. Posteriormente con el
empleo del término CASE se ha extendido la automatización a las fases de análisis y diseño.
 Para las pruebas de integración se puede disponer de herramientas de ensayo y para la fase
de mantenimiento se dispone de soporte de gestión de configuración, que incluye la gestión
de versiones y el control de cambios.
 El futuro de las técnicas CASE está en el soporte completo de todo el ciclo de vida. Se ha
denominado IPSE, ICASE e ISEE.
 FORMAS DE ORGANIZACIÓN:
o 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
o Con repositorio, las herramientas integradas guardan su información en este almacén
común. Una parte del repositorio es el diccionario de datos
o Como una única herramienta global, capaz de realizar todas las operaciones
necesarias.
OBJETIVO Y CLASIFICACIÓN DE ENTORNOS DE DESARROLLO
 Dar soporte a la programación en un lenguaje concreto
 Dar soporte a una metodología de desarrollo
 Ayudar al desarrollo de entornos de desarrollo (meta-entornos)
 CLASIFICACIÓN, desde un punto de vista pragmático:
o ENTORNOS ASOCIADOS A UN LENGUAJE. Un primer paso lo constituyen los intérpretes
de los lenguajes de programación interactivos (BASIC, LISP, SmallTalk, ada).
o ENTORNOS ASOCIADOS A ESTRUCTURA. En ellos se almacena la información
correspondiente al programa en forma estructurada y no simplemente como texto. La
 edición 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 básicas (PL/).
o ENTORNOS BASADOS EN HERRAMIENTAS. Consisten en una colección de herramientas
(toolkit o toolbox) relativamente independientes, aunque compatibles entre sí,
además deben de existir algún medio para hacerlas funcionar en forma combinada.
Suele presentar como ventaja el ser bastante abiertos, permitiendo la incorporación
de nuevas herramientas. Su inconveniente es la falta de una interfaz de usuario
interactiva y uniforme.
o ENTORNOS ASOCIADOS A UNA METODOLOGÍA. La integración de los distintos
elementos del entorno se suele conseguir mediante el empleo de un almacén único o
repositorio CASE para almacenar todos los elementos de información contemplados
en la metodología soportada. El repositorio contiene información de los diagramas de
flujo de datos, descripción de cada dato y de cada proceso.
o ENTORNOS DE 4ª GENERACIÓN. Se apoyan en un sistema de gestión de base de datos
dotado de un lenguaje de consulta con herramientas complementarias.
CLASIFICACIÓN DE ENTORNOS POR NIVELES
 Nivel de servicio. Corresponde a un producto que realiza una función u operación
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 codificación el banco de trabajo se
denomina entorno de programación.
 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.
HERRAMIENTAS DE SOFTWARE
Herramientas clásicas.
 Editor de texto.
 Compilador
 Montador de enlaces. Construye ejecutables combinando varios ficheros objeto.
 Gestor de librería. Combina ficheros objeto en una librería.
 Herramienta ‘MAKE’. Automatiza la actualización de los ficheros a partir de otros.
 Intérprete interactivo. Casi Constituye un entorno de programación completo (si lo es se debe
clasificar a nivel de banco de trabajo y no de herramienta). Engloba funciones equivalentes a
las de edición, compilación, montaje y ejecución.
 Compilador/Intérprete. Procesador de un lenguaje interpretado de forma no
interactiva.Incluye un compilador a código intermedio y un intérprete de ejecución de dicho
código intermedio con todas las librerías 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 simbólico. Realiza una función análoga al anterior pero con referencia al código
fuente por lo que es más cómodo de usar.
 Herramientas evolucionadas.
 Editores orientados al lenguaje. Son editores de estructura.
 Herramienta ‘MAKE’ automática. Se incorpora la función ‘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
aplicación en desarrollo.
 Procesadores/Analizadores de código 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 podrían estar incorporadas en los
compiladores.
 Procesadores de documentos. No son específicos del desarrollo pero son un soporte
fundamental.
 Herramientas de control de pruebas. Ayudan a la realización de pruebas unitarias o de
 integración.
 Herramientas de control de cambios. Ayudan a la realización del desarrollo y al mantenimiento
de aplicaciones.
 Procesadores de ficheros de texto.
 Herramientas de 4º generación.
 Hojas de cálculo. Procesadores de documentos
 Gestores de bases de datos Lenguajes de 4ª generación.
 Generadores de programas.

ENTORNOS INTEGRADOS

Integración de datos. Significa que la información almacenada en el entorno es gestionada de

manera uniforme, con independencia de las transformaciones que se hagan con cada elemento de
información. Debe de conseguir:
¤ Interoperatividad entre herramientas.
¤ No redundancia de datos
¤ Consistencia de datos.
¤ Paso de datos de una herramienta a otra.
La integración 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 más sencilla. Existe un formato
normalizado (CDIF).
• Transferencia basada en comunicación. Alternativa a la anterior y puede ser
usada en sistemas distribuidos y en sistemas abiertos.
• Repositorio común. Se utiliza en los entornos modernos con un grado de
integración elevado.
Integración de control. Consiste en la combinación 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 integración de los datos.
Integración de la presentación. Trata de realizar la interacción con el usuario de manera uniforme,
con cierta independencia dela función o herramienta en uso. Para ello se deben conseguir los
objetivos de un sistema amigable:
· Limitar el número de formas de interacción diferentes.
· Usar formas de interacción y presentación adecuadas al modelo mental que el
usuario tiene del entorno.
· Satisfacer los tiempos de respuesta esperados y dar indicación del avance del
proceso en caso de tratamiento de larga duración.
· Mantener información útil a disposición del usuario.
Integración del proceso. Consiste en que las herramientas se combinan de manera que apoyan o
fuerzan el uso de una metodología de desarrollo definida. Este modo exige una buena integración
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 revisión del DDD).
• Un suceso o evento es un condición que ocurre durante la ejecución de un paso
y que puede desencadenar la ejecución de una acción asociada (compilación de un módulo).
• Una restricción del desarrollo es una limitación que debe cumplirse.
Un buen grado de integración del proceso exige que todo los pasos, eventos y restricciones que
definen de forma natural la metodología de desarrollo a utilizar, sean representables y tratables
dentro del entorno.
ENTORNOS INTEGRADOS: EL REPOSITORIO CASE
El repositorio CASE Es un almacén común en el que se guarda toda la información necesaria para
la operación de un grupo de herramientas o de un entorno de desarrollo. El repositorio facilita las
funciones de almacenamiento y recuperación de datos, normalmente en forma concurrente
multiusuario, y el mantenimiento de relaciones entre los datos. Además puede suministrar
funciones de gestión de versiones, de seguridad y de gestión de transacciones. Para proporcionar
las funciones de almacenamiento y recuperación 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 actualización (query) que permita acceder y manipular la información
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 importación y exportación de información
mediante ficheros externos.
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:
· Integración de la presentación
 · Integración de control
· Integración de datos (preferentemente con repositorio común).
Según la actividad soportada, tendremos distintos bancos o equipos de trabajo, entre ellos:
• Equipos de análisis y diseño: Herramienta CASE o CASE superior. Corresponde al
entorno asociado a la metodología. Muchos de ellos cubren las dos fases (análisis y diseño),
mientras que otros sólo cubren una. El repositorio común almacena todos los elementos definidos
en la metodología soportada.
• Entorno de programación. Es el banco de trabajo para la actividad de
codificación pudiéndose extender al diseño detallado y a las pruebas de unidades.
• Equipo de verificación y validación: Capaz de facilitar las tareas de inspección y
pruebas de módulos y sistemas. Suelen estar ligados al entorno de programación. Pueden incluir
funciones de:
¤ Análisis estático, con evaluación de métricas de calidad y generación de
matrices o grafos de llamadas entre funciones y módulos.
¤ Generación de tablas de referencias cruzadas.
¤ Gestión de pruebas, automatizando la realización de ensayos.
• Equipo de construcción de interfaz del usuario. Permite definir cómodamente el
esquema de diálogo con el usuario, así como los elementos de interacción.
• Equipo de gestión de configuración. Permite almacenar diferentes versiones de
los elementos del proyecto, definir distintas configuraciones y controlar los cambios sucesivos.
• Equipo de ingeniería inversa. Debe facilitar la extracción de información de
diseño, los elementos abstractos a partir de un código o sistema software existente.
• Equipo de gestión de proyectos. Facilita la confección de planes de trabajo, con
la asignación de tiempos y recursos a diferentes tareas, y el seguimiento de su realización.