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.
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
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.
MODELO EN CASCADA AMPLIADO
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

MODELO EN V AMPLIADO

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.
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
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.
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.
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.
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
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.
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
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
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
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.
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).
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.
Tema 2:
ESPECIFICACIN DE SOFTWARE
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.
CONCEPTO DE MODELO
Un modelo conceptual es una abstraccin lgico-matemtica 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
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.
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.
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.
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
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
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.
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.
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.
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.
MODELO DE SRD
1. Introduccin
1. Objetivo: objetivos, participantes, calendario,...
2. mbito, identificar y dar nombre al producto
3. Definiciones, siglas y abreviaturas
4. Referencias, la descripcin bibliogrfica de los documentos referenciados.
5. Panormica del documento
2. Descripcin general
1. Relacin con otros proyectos, similares o complementarios
2. Relacin con proyectos anteriores o posteriores
3. Objetivo y funciones
4. Consideraciones de entorno
5. Relaciones con otros sistemas, que utilicen entradas o salidas indirectas
de informacin
6. Restricciones generales: metodologas, lenguajes, de hardware,...
7. Descripcin del modelo, es el apartado ms extenso y ms importante. Se
utilizan todas las notaciones y herramientas disponibles

1. 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
2. APENDICES, para complementar el contenido del documento
Tema 3:
FUNDAMENTOS DEL DISEO DEL SOFTWARE
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.
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)
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
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
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)
DIAGRAMAS HIPO (Hierachy-Input-Process-Output)
Se muestra primero la jerarqua entre los mdulos del sistema
Y en los diagramas HIPO de detalle hay 3 zonas: Entrada, Proceso y Salida
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
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.
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.
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.
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






Tema 4:
TCNICAS GENERALES DE DISEO SOFTWARE
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
DESCOMPOSICIN MODULAR
Los pasos a seguir son:
1. Identificar los mdulos
2. Describir cada mdulo
3. Describir las relaciones entre mdulos
Tipos de mdulos:
1. Cdigo fuente, en el lenguaje de programacin usado
2. Tabla de datos, para datos de inicializacin u otros
3. Configuracin, se agrupa en un mdulo toda la informacin de configuracin en el entorno
de trabajo
4. Otros: ficheros de ayuda en lnea, manuales, etc.
Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda considerar
suficientemente vlida
1. Independencia fucional
2. Acoplamiento
3. Cohesin
4. Comprensibilidad
5. Adaptabilidad
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
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.
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
TCNICAS DE DISEO FUNCIONAL DESCENDENTE
La descomposicin del sistema se hace desde un punto de vista funcional.
Desde el punto de vista de la codificacin, cada mdulo corresponde esencialmente a un
subprograma.
TCNICAS DE DISEO FUNCIONAL DESCENDENTE: DESARROLLO POR REFINAMIENTO
PROGRESIVO
Esta tcnica consiste en la aplicacin de la fase de diseo de la programacin estructurada. Las
estructuras bsicas son la secuencia, la seleccin entre alternativas y la iteracin.
Cada paso en la descomposicin consiste en refinar o detallar una parte del programa global u
operacin, que a su vez podr ser descompuesta en otras operaciones. Los refinamientos se basan
en la aplicacin de estructuras de control en el programa. Veamos como ejemplo obtener las races
de una ec. de 2 grado:
Obtener races ->
Leer coeficientes
Resolver ecuacin -->
Calcular discriminante
Calcular races -->
SI el discriminante es negativo ENTONCES
Calcular races complejas
SI-NO
Calcular races reales
FIN-SI
Imprimir races
TCNICAS DE DISEO FUNCIONAL DESCENDENTE: PROGRAMACIN ESTRUCTURADA DE
JACKSON
Esta tcnica sigue las ideas de la programacin estructurada (secuencia, seleccin, iteracin) y el
mtodo de refinamientos sucesivos pra construir la estructura del programa en forma descendente.
Se recomienda construir la estructura del programa de forma similar a las estructuras de datos de
entrada y de salida
Pasos de la tcnica JSP:
1) Analizar el entorno del problema y describir las estructuras de datos a procesar
2) Construir la estructura del programa basndose en las estructuras de datos
3) Definir las tareas a realizar en cada mdulo de la estructura del programa
Este tercer paso corresponde en su detalle a la fase de codificacin
Ej.: Programa para justificar el texto, es decir, reagrupar las palabras en lneas e intercalar los
espacios adecuados para que se ajusten a los mrgenes
1) PASO 1. Las estructuras de datos que reconocemos son
n Texto de entrada = {[separador de prrafo | palabra]}
n Texto de salida = {[lnea ajustada | lnea final | lnea en blanco]}
TCNICAS DE DISEO FUNCIONAL DESCENDENTE: PROGRAMACIN ESTRUCTURADA DE
JACKSON
En el PASO 2 se trata de encontrar una estructura del programa que se ajuste a las estructuras de
los datos de entrada y salida
TCNICAS DE DISEO FUNCIONAL DESCENDENTE: DISEO ESTRUCTURADO
Segn esta tcnica, la tarea de diseo consiste en pasar de los DFDs a los diagramas de estructura.
Hay que establecer una jerarqua o estructura de control entre los diferentes mdulos, que no est
implcita en el modelo funcional descrito en los DFDs
Para dos mdulos relacionados en el DFD (A) tenemos 3 posibilidades de organizacin modular
diferentes.
TCNICAS DE DISEO FUNCIONAL DESCENDENTE: 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.
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

TCNICAS DE DISEO BASADO EN ABSTRACCIONES
La idea es que los mdulos corresponden a funciones o a tipos abstractos de datos.
Los lenguajes que dan ms facilidades para la implementacin son los orientados a objetos
TCNICAS DE DISEO BASADO EN ABSTRACCIONES: DESCOMPOSICIN MODULAR BASADA
EN ABSTRACCIONES
Se trata de ampliar el lenguaje de programacin con nuevas operaciones y tipos de datos definidos
por el usuario, de forma que se simplifique la escritura de los niveles superiores del programa,
basndose en mdulos que realicen estas operaciones
Podemos identificar los tipos abstractos correspondientes a un nmero
complejo y a una ecuacin de 2 grado y definir sobre dichos tipos abstractos las siguientes
operaciones:
Ecuacin de 2 grado: Nmero complejo:
Leer ecuacin Escribir
Escribir ecuacin Sumar, Restar, etc..
Obtener races Raz cuadrada
La estructura modular del programa sera:
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
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
TCNICAS DE DISEO DE DATOS
Muchas aplicaciones necesitan almacenar informacin de forma permanente y la mejor forma de
hacerlo es crear una base de datos subyacente
Podemos enfocar la organizacin de la base de datos de 3 formas:
Nivel externo Esquemas de usuario
Nivel conceptual Esquemas lgicos
Nivel interno Esquemas fsicos
El nivel externo corresponde a la visin del usuario, en la fase de anlisis de pasa al nivel conceptual,
que establece la organizacin de los datos, y finalmente en la etapa de diseo se pasa al nivel
interno.
DISEO DE BASES DE DATOS RELACIONALES, en este modelo la eficiencia se basa en:
Las FORMAS NORMALES, que tienden a evitar las redundancias en los datos
almacenados
FN1, la informacin asociada a cada columna de la tabla es un nico valor, y no
una coleccin
FN2, si hay una clave primaria que distingue e identifica cada fila, el resto de los
datos dependen de toda la clave primaria
FN3, el valor de cada columna que no es clave primaria depende directamente de
la clave primaria. Se puede conseguir si se separan las tablas.
Los INDICES, que mejoran la velocidad de acceso a los datos
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.
TCNICAS DE DISEO DE DATOS: COMPOSICIN Y HERENCIA
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:
(a) Una tabla para la superclase con los atributos comunes y una tabla para cada subclase
(b) Desaparece la tabla de la superclase y los atributos comunes heredados se repiten en las subclases
(c) 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
Tema 5:
CODIFICACIN Y PRUEBAS
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.
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.
PRESTACIONES DE LOS LENGUAJES: ESTRUCTURAS DE CONTROL
se incluyen aqu, adems de las caractersticas propias de la programacin estructurada, el manejo
de excepciones y la concurrencia.
Programacin estructurada: secuencia, iteracin y seleccin (verdadero-falso y por casos)
Manejo de excepciones: errores humanos, fallos hardware, errores software, datos de
entrada vacos, valores fuera de rango, etc. (estructuras exception when y raise).
Concurrencia, tareas simultneas, sincronizacin, comunicacin e interbloqueos. Los
lenguajes han implementado la posibilidad de lanzar tareas concurrentes de distintas
formas:
CORRUTINAS, tienen una estructura semejante a subprogramas pero con una
transferencia del control ms flexible. El avance en la ejecucin de las corrutinas se
produce segn el avance entre ellas.
FORK-JOIN, es la propuesta de UNIX.
COBEGIN-COEND, entre estas palabras se inician todas las tareas y se finalizan.
Es posible el anidamiento.
PROCESOS; cada tarea se declara como un proceso y estos y se ejecutan
concurrentemente. En algunos casos es posible lanzar dinmicamente nuevos
procesos una vez iniciado el programa.
PARA LA COMUNICACIN ENTRE TAREAS.
VARIABLES COMPARTIDAS
SEMFOROS
REGIONES CRTICAS
MONITORES
PASO DE MENSAJES
CSP
LLAMADA A PROCEDIMIENTOS REMOTOS
REDENZVOUS, DE ADA
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.
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.
DATOS COMPUESTOS, son combinaciones de datos simples y compuestos ya definidos.
Pueden ser homogneos como los ARRAYS y heterogneos como los RECORDS o
STRUCTS.
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:
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.
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.
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
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.
ASPECTOS METODOLGICOS: EFICIENCIA Y TRANSPORTABILIDAD
La potencia de clculo y la cantidad de memoria disponible en los computadores actuales hacer
preferible la claridad en el cdigo que la EFICIENCIA.
EFICIENCIA EN MEMORIA, en la fase de diseo se estudian las posibles alternativas y se
opta por el algoritmo que optimiza el uso dela memoria.
EFICIENCIA DE TIEMPO, es importante en el desarrollo de sistemas de tiempo real muy
crticos. A veces se mejora la eficiencia de tiempo a costa de ocupar ms memoria. En el
diseo se estudian las alternativas y se adopta el algoritmo ms rpido. Tcnicas de
codificacin para aumentar la eficiencia de tiempo:
Tabular clculo complejos
Expansin en lnea, emplear macros en vez de subrutinas
Simplificar las expresiones aritmticas y lgicas
Sacar fuera de los bucles lo que no sea necesario repetir
Usar estructuras de datos de acceso rpido
Evitar operaciones en coma flotante, mejor en coma fija
Evitar conversiones innecesarias de tipos
TRANSPORTABILIDAD DEL SOFTWARE, no solo es rentable a corto plazo para obtener versiones
para diferentes plataformas, a medio y largo plazo facilita el mantenimiento y la adaptacin de la
aplicacin a las nuevas arquitecturas.
Los factores para la transportabilidad son:
Utilizacin de estndares
Aislar las peculiaridades, colocndolas en mdulos separados. Se procurar evitar
aquellos elementos no consolidados y que pueden estar sujetos a futuros cambios
o revisiones.
Las peculiaridades de los distintos tipos de computadores depende de la arquitectura y del
sistema operativo utilizado.
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.
TCNICAS DE PRUEBAS DE UNIDADES: CAJA NEGRA
Las tcnicas de pruebas de unidades siguen dos estrategias fundamentales:
PRUEBAS DE CAJA NEGRA, se ignora por completo la estructura interna del programa y
se comprueba la correccin de entradas y salidas del programa.
Lo importante es la elaboracin de los casos de prueba con el objetivo de descubrir los
errores e incorrecciones. Mtodos:
PARTICIN EN CLASES DE EQUIVALENCIA, se trata de ividir el espacio de ejecucin del
programa en varios subestapacios o clases equivalentes desde el punto de vista del a caja negra.
Hay que:
Determinar las clases equivalentes apropiadas
Establecer pruebas para cada clase de equivalencia, con datos de entrada vlidos y no
vlidos. Se repiten las pruebas hasta cubrir todos los casos vlidos de todas las clases.
ANLISIS DE VALORES LMITE, los errores tienden a aparecer al operar en las fronteras.
Directrices para la elaboracin de casos de pruebas:
Entradas, probar los valores del lmite y justo fuera del lmite
Salidas, probar los valores del lmite y justo fuera del lmite
Memoria, probar tamaos nulos, lmite superior y superior al lmite de todas las estructuras
de datos del programa
Recursos, probar lmites. Si terminales=30, probar 0, 20 y 31
Otros, probar los valores lmite y establecer las pruebas
COMPARACIN DE VERSIONES, se desarrollan varias versiones software para resolver la
especificacin del mdulo y se comparan los resultados con el fin de detectar errores.
EMPLEO DELA INTUICIN, la intuicin y la experiencia puede mejorar los casos de prueba, tambin
es conveniente que participen expertos ajenos al desarrollo.
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:
UBRIMIENTO LGICO, consiste en no dejar ninguna seccin del cdigo sin ejecutar en pruebas. Se
llama camino bsico a cualquier recorrido sobre el diagrama de flujo que nos permita llegar al final
desde el punto de entrada.
Hay que determinar el conjunto de caminos bsicos que recorran todas las lneas de flujo
del programa al menos una vez.
N mximo de caminos = N predicados + 1
En un segundo nivel de casos de prueba se trata de que se ejecuten todas las
combinaciones de caminos bsicos por parejas
A otros niveles se generan casos de pruebas para que se ejecuten un n significativo de
combinaciones de caminos bsicos
PRUEBAS DE BUCLES, que son elemento esencial en cualquier programa. Casos:
Bucles con n no acotado de repeticiones, probar 0, 1, 2, bastantes y muchas iteraciones.
Bucles con n mximo de repeticiones, probar 0, 1, 2 bastantes, M-1, M y M+1 iteraciones
Bucles anidados, el n de pruebas para comprobar todas las situaciones crece.
EMPLEO DE LA INTUICIN, conocer con detalle la estructura del mdulo y tener experiencia.
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.
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;
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
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:
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.
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
Tema 6:
AUTOMATIZACIN DE PROCESO DE DESARROLLO
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.
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.
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.
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.
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.
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.
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.
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.