• Author / Uploaded
• Alain Fl

Citation preview

U.N.E.D. Ingeniería Técnica en Informática de Gestión

Apuntes de

INGENIERÍA DEL SOFTWARE

Apuntes realizados por Antonio Reyes. C.A.Tenerife

1

Universidad Nacional de Educación a Distancia (UNED) Ingeniería Técnica en Informática de Gestión Ingeniería del Software. RESUMEN Concepto

Descripción

1. INTRODUCCIÓN 1.1. Concepto de Ingeniería de Sistemas Sistema Es un conjunto de cosas que ordenadamente relacionadas entre sí contribuyen a determinado objeto. Ingeniería de sistemas La ingeniería de sistemas atiende a los aspectos de organización de sistemas informáticos así como al proceso de su desarrollo. Subsistemas Son las partes de un sistema. Sistemas basados en Son los sistemas que ha de concebir y distribuir el ingeniero en informática. Contienen uno computador o más computadores dedicados a controlar el conjunto. Algunos sistemas sólo se pueden construir con equipos multidisciplinares. La tarea de tratamiento de información que realizan los sistemas informáticos puede ser realizada por tres elementos: • Hardware, de una forma directa, • Software, cuando la operación se puede programar, y • Usuario, que aunque no forme parte del sistema artificial se debe indicar como debe interactuar el usuario que opere en el sistema. La concepción de un sistema informático, que es la actividad de la ingeniería de sistemas basados en computadores, consiste en decidir qué elementos hardware y software se utilizarán o desarrollarán y qué usuarios operarán dicho sistema. También repartirá y asignará las actividades de cada uno de los elementos descritos. 1.2. Características del Software Hardware Son todos los elementos físicos del computador. Software Son los programas, pero también los documentos, bases de datos o los procedimientos de operación o de mantenimiento periódico. La ingeniería de software presenta las características especiales de que en su proceso de fabricación, lo realmente costoso es el proceso de desarrollo inicial, ya que posteriormente se limitará a distribuir miles de copias a un costo muy bajo. Es decir, el costo de producir miles de unidades de un producto software es similar al costo de fabricar uno solo. Tareas de mantenimiento El software no se desgasta. Las tareas de mantenimiento de software deben considerarse como tareas adicionales de desarrollo, realizadas ocasionalmente. 1.3. Concepto de Ingeniería de Software Utilizado por primera vez a finales de los años sesenta en la OTAN, el término de ingeniería de software se utiliza para designar el empleo de técnicas y procedimientos de la ingeniería en general en el desarrollo de productos software. Además amplia su visión de desarrollo de software con las actividades de análisis y diseño previos, y de integración y verificaciones posteriores, algo que se llama “ciclo de vida” del desarrollo software. 1.3.1. Perspectiva histórica El aumento de la capacidad de los computadores hizo evolucionar la actividad de desarrollo de software, que en un principio era una actividad casi artesanal y que dependía de la habilidad y creatividad del programador, hacia la aplicación de técnicas que permitieran: a) el trabajo en equipo; b) una organización del trabajo y; c) empleo de herramientas adecuadas. Se crearon metodologías de desarrollo específicas y particulares como las destinadas a la creación de los sistemas de información. CASE Computer Aided Software Engineering. Son herramientas de soportes que permiten aplicar las técnicas de la ingeniería de software. Sirven para apoyar las actividades inmediatamente anteriores a la codificación. Se emplearon en los años 80. IPSE Integrated Project Support Environment. ICASE Integrated CASE. Herramientas actuales Las IPSE e ICASE son las herramientas que se utilizan en la actualidad y permiten automatizar aún más la producción de software. Pueden ser utilizadas durante todo el ciclo de vida de desarrollo. 1.3.2. La crisis del software La crisis del software, iniciada en los años 60, debido a la fuerte evolución del hardware que requería desarrollar aplicaciones software más complejas, persiste hasta nuestros días, habiéndose convertido dicha crisis en una evolución constante del hardware, lo que obliga a la ingeniería del software a una evolución también contínua siendo dicha evolución insuficiente. 1.3.3.Mitos del software

Apuntes realizados por Antonio Reyes. C.A.Tenerife

2

La continua evolución de las disciplinas en el desarrollo del software ha provocado que se hayan creado ciertos mitos difíciles de erradicar: El hardware es más Es falso ya que el usuario interactúa con el software principalmente. Es censurable la importante que el software realización de copias piratas. El software es fácil de Esto es falso para cualquier aplicación de cierta importancia. El desarrollo de grandes desarrollar sistemas es muy complejo y costoso. El software consiste Un sistema informático se compone de hardware, software, personas y procedimientos de exclusivamente en utilización. También es software toda la documentación del desarrollo que se necesita para programas ejecutables el mantenimiento. El desarrollo de software es Es falso ya que las tareas de análisis y diseño son el fundamento para el resto del desarrollo. sólo una labor de programación Es natural que el software No exactamente. Si bien el desarrollo de software es susceptible de errores, no es admisible contenga errores que un software contenga siempre errores. Los errores del software son errores durante su desarrollo inicial y deben reducirse a un nivel lo más bajo posible. 1.4. Formalización del proceso de desarrollo Una de las características de la ingeniería es la existencia de procedimientos bien establecidos para la realización de actividades de desarrollo, construcción, fabricación, etc. En el caso de la ingeniería de software tenemos varios procedimientos o modelos: 1.4.1 El ciclo de vida del software. Modelos clásicos Ciclo de vida del software Constituye uno de los primeros logros de la ingeniería del software y consiste en identificar con detalle la forma que adopta el proceso de desarrollo del software. 1.4.1.1. El modelo en cascada Es el modelo de ciclo de vida más antiguo y en él figuran distintas fases ordenadas secuencialmente de forma que el resultado de una se utiliza como entrada de la siguiente. Su secuencia es: Análisis Æ Diseño Æ Codificación Æ Integración Æ Mantenimiento. Existen diferentes variantes en el que una de las fases se desarrolla aún más. Análisis Consiste en analizar las necesidades de los usuarios potenciales del software para determinar qué hace el sistema a desarrollar y, a partir de ello, escribir la especificación precisa. Diseño Descompone y organiza el sistema en elementos que se pueden desarrollar por separado. Se aprovecha así la división del trabajo. Produce la especificación de cada componente. Codificación En esta fase se escribe el código fuente de cada elemento por separado. Integración En esta fase se combinan todos los elementos y se comprueba el sistema completo. Se harán pruebas exhaustivas. Mantenimiento Durante la explotación se harán cambios no previstos, se corregirán errores no detectados, o se introducirán mejoras. Especialización El hecho de estar dividido en fases el ciclo de vida en cascada, hace que se permita una especialización, pudiendo encontrar analistas, diseñadores, programadores, etc. Documentos Los documentos que en cada fase se producen son: Documento de Requisitos SRD (Software Requirements Document). Es producto de la fase de análisis y consiste en del Software una especificación precisa y completa del sistema. Se prescinde de detalles. Documento de diseño del SDD (Software Design Document). Es producto de la fase de diseño. Es una descripción Software de la estructura global del sistema, y la especificación de qué debe hacer cada una de sus partes y cómo se combinan entre sí. Código Fuente Es el producto de la fase de codificación. Contiene el programa fuente debidamente comentado. El Sistema Software Es el producto de la fase de integración. Se deben documentar las pruebas realizadas. ejecutable Documentos de Cambios Se debe hacer después de cada modificación realizada durante el mantenimiento. Se incluirá el problema detectado, la solución adoptada y la modificación realizada. Es importante destacar la necesidad de terminar correctamente una fase antes de comenzar la siguiente, y ello porque es muy costoso corregir errores de una fase anterior si parte del trabajo de esa fase ya está hecho. En esos casos hay que retornar a un punto anterior del ciclo de vida. 1.4.1.2. El modelo en V Este modelo, que incluye las mismas fases que el modelo en cascada, tiene forma de V, e incluye en el tramo descendente de la V las fases de Análisis Æ Diseño Æ Codificación, mientras que en el trazo ascendente están las fases de Codificación Æ Integración Æ Explotación. En la rama izquierda el sistema se va descomponiendo en elementos cada vez más sencillos mientras que en la rama derecha se van construyendo poco a poco hasta disponer del sistema completo. Verificación Consiste en comprobar que una parte del sistema cumple con sus especificaciones formales. Validación Consiste en comprobar que un elemento satisface las necesidades del usuario identificadas durante el análisis. 1.5. Uso de prototipos

Apuntes realizados por Antonio Reyes. C.A.Tenerife

3

El inconveniente de los modelos clásicos es que, una vez detectado un error, las vueltas atrás para corregirlo, son muy costosas. Por otro lado, en sistemas innovadores, que carecen de experiencia previa, no siempre se puede saber si se han adoptado las decisiones adecuadas. Esto se intenta paliar con el uso de prototipos. Prototipo Es un sistema auxiliar que permite probar soluciones parciales. Su coste será inferior al del sistema final lo que permitirá corregir errores a un coste final inferior. Para reducir su coste se puede: limitar sus funciones, capacidad, eficacia, reduciendo la parte a desarrollar, usar un hardware más potente, etc. 1.5.1. Prototipos rápidos Prototipos rápidos La finalidad de los prototipos rápidos es adquirir experiencia. Se utilizan en las fases de diseño y análisis y sirven para experimentar alternativas y verificar las decisiones adoptadas. Una vez completadas estas fases el sistema final se escribe partiendo de cero. Lo importante es hacerlos rápidamente. Prototipos throw-away Son los prototipos de ”usar y tirar” y tienen limitada su funcionalidad. Prototipos mock up Son los prototipos “maqueta” y tiene limitada su capacidad. 1.5.2. Prototipos evolutivos Mediante el prototipo evolutivo se aprovecha al máximo su código. Se desarrollan en el mismo soporte hardware/software. Primero se construye un prototipo inicial que permitirá tomar las primeras decisiones de diseño; posteriormente, el prototipo se va ampliando con más funcionalidades, de forma que en cada iteración, el código es más y más completo hasta que el último prototipo constituye el sistema final. Al mismo tiempo que se desarrolla, se van generando los documentos de especificación. 1.5.3. Herramientas para realización de prototipos En los prototipos evolutivos se utilizarán las mismas herramientas que para el desarrollo del sistema definitivo. En prototipos rápidos se suelen utilizar herramientas de 4ª generación que son herramientas que se apoyan en la utilización de bases de datos, lenguajes especializados para construir el interfaz de usuario, formularios, etc. Lenguajes de muy alto nivel Son lenguajes que permiten un estilo declarativo. Lo son los lenguajes de 4ª generación. Lenguajes declarativos Son lenguajes que permiten describir el resultado deseado sin escribir las operaciones para conseguirlo. Lenguajes de especificación El objetivo de estos lenguajes es formalizar la especificación, para, a partir de un compilador, obtener directamente el prototipo. Algunos son: VDM y Z. Reutilización Es una técnica que consiste en realizar los programas con una visión un poco más general para que puedan ser utilizados en más de un proyecto. 1.6. El modelo en espiral El modelo en espiral es un refinamiento del modelo evolutivo. Consiste en una espiral dibujada sobre un cuadrado dividido en cuatro partes. En cada uno de los cuadrados figura una actividad: Planificación, Análisis de Riesgo, Ingeniería y, Evaluación. Planificación Establece el contexto del desarrollo. Dice qué parte del mismo se abordará en ese ciclo. Análisis de Riesgo Evalúa las diferentes alternativas, tomando la más adecuada. Ingeniería En los modelos clásicos corresponde a lo que sería: análisis, diseño, codificación, etc. Evaluación Se analiza los resultados de la fase de ingeniería con la colaboración del cliente. Su resultado se utilizará para el siguiente ciclo de la espiral. 1.7. Combinación de modelos Muchas veces resulta ventajoso combinar diferentes modelos de forma que, por ejp. para la fase de análisis se utilice el modelo de prototipo rápido, para el diseño, un modelo en cascada, o cualquier otro. De hecho el modelo en espiral es una combinación de modelos, pues la actividad de ingeniería puede realizarse con cualquier otro modelo. 1.8. Mantenimiento del software Esta actividad consiste en rehacer parte de las actividades anteriores (análisis, diseño, codificación y pruebas) para introducir cambios en una aplicación ya entregada al cliente y en explotación. 1.8.1. Evolución de las aplicaciones El software se caracteriza por la ausencia de deterioro o envejecimiento durante su utilización. Una aplicación funcionará igual que el primer día. Sin embargo, es necesario realizar un mantenimiento, existiendo tres tipos: Mantenimiento correctivo Su objetivo es eliminar errores no detectados en el desarrollo. Este tipo de mantenimiento no debería existir de haberse realizado con garantías de calidad. Mantenimiento adaptivo Este mantenimiento se produce para adaptar el software a plataformas hardware nuevas o para cambiar la interfaz de las aplicaciones. Mantenimiento perfectivo Este tipo de mantenimiento se produce para obtener mejores versiones de un producto sujeto a fuerte competencia. También se produce cuando las necesidades del usuario evolucionan y hay que modificar los requisitos iniciales lo que provoca un cambio en la especificación de requisitos. 1.8.2. Gestión de cambios La aplicación de técnicas de ingeniería a la actividad de mantenimiento exige organizar y gestionar adecuadamente el desarrollo de estos cambios. Se pueden dar dos enfoques:

Apuntes realizados por Antonio Reyes. C.A.Tenerife

4

Nuevo desarrollo.

Si el cambio afecta a la mayoría de los componentes del producto, dicho cambio se podría plantear como nuevo desarrollo y aplicar un nuevo ciclo de vida, utilizando el desarrollo actual como si fuera un prototipo. Modificación de algunos Si el cambio afecta a una parte localizada del producto, se puede organizar como una elementos modificación de algunos elementos. En ambos casos un cambio de código conlleva una revisión de la documentación del producto (diseño, especificación de requisitos). Informe de problema Es un documento que describe una dificultad en la utilización del producto, que requiere una modificación para subsanarla. Puede ser generado por los usuarios. Informe de cambio Describe la solución dada a un problema y el cambio realizado en el producto software. A veces el informe de problema y el informe de cambio se refunden en uno solo. 1.8.3. Reingeniería La reingeniería o ingeniería inversa son las técnicas que se utilizan para mantener productos no documentados o desarrollados de forma artesanal. Ingeniería inversa Consiste en tomar el código fuente y a partir de él tratar de construir alguna documentación, (diseño, estructura modular de la aplicación, dependencia entre módulos, etc.) lo que llevaría a aclarar la parte a modificar. Reingeniería La reingeniería trata de generar un sistema bien organizado y documentado a partir del sistema inicial deficiente. Puede ser necesario modificar el código fuente o reconstruir la documentación inexistente. 1.9. Garantía de calidad de software La calidad de un producto software viene determinado por el proceso seguido en su desarrollo. 1.9.1. Factores de calidad Los diferentes enfoques que se pueden aplicar para valorar la calidad de un producto no software, pureza, resistencia, etc., no son aplicables en general en los productos software, no existiendo métricas precisas que permitan valorar adecuadamente dicho producto. Las mediciones de la calidad se realizan basándose en tres valoraciones: a) factores, que constituyen el nivel superior; b) criterios, que constituyen el nivel intermedio, y; c) métricas, que constituyen el nivel inferior y son mediciones de ciertos atributos siendo la base para evaluar los criterios intermedios. Factores de calidad Lo son los siguientes: • Corrección. Grado en que un producto cumple con su especificación. • Fiabilidad. Grado de ausencia de fallos de un producto durante su operación. Puede verse como el nº de fallos o el tiempo inutilizable durante un período dado. • Eficiencia. Es la relación entre la cantidad de resultados obtenidos y los recursos requeridos para ello. Se mide como la inversa de los recursos consumidos para una operación dada. • Seguridad. Es la dificultad de acceso a los datos o a las operaciones por personal no autorizado. • Facilidad de uso. Es la inversa del esfuerzo requerido para aprender a utilizar un producto software y usarlo adecuadamente. • Mantenibilidad. Es la facilidad para corregir un producto software. • Flexibilidad. Es la facilidad para modificar el producto software. • Facilidad de prueba. Es la inversa del esfuerzo requerido para ensayar un producto software y comprobar su corrección o fiabilidad. • Transportabilidad. Es la facilidad para adaptar el producto software a una plataforma diferente de aquella para la que fue desarrollada inicialmente. • Reusabilidad. Es la facilidad para emplear partes del producto en otros desarrollos posteriores. • Interoperatividad. Es la facilidad o capacidad del producto software para trabajar en combinación con otros productos. 1.9.2. Plan de garantía de calidad Una adecuada calidad del producto es inalcanzable sin una buena organización del desarrollo. SQAP Acrónimo del inglés Software Quality Assurance Plan o Plan de Garantía de Calidad Software es el documento en el que se ha materializado la organización del proceso de desarrollo software. Incluye: • Organización de los equipos de personas y la dirección y seguimiento del proyecto. • Modelo de ciclo de vida a seguir, detallando sus fases y actividades. • Documentación requerida, especificando el contenido de cada documento. • Revisiones y auditorías a realizar durante el desarrollo para garantizar la corrección de las actividades y los proyectos. • Organización de las pruebas a realizar a distintos niveles.

Apuntes realizados por Antonio Reyes. C.A.Tenerife

5

•

Organización de la etapa de mantenimiento, especificando cómo ha de gestionarse la realización de cambios sobre el producto en explotación.

1.9.3. Revisiones Una revisión consiste en inspeccionar el resultado de una actividad para determinar si es aceptable o si contiene defectos a subsanar. Se aplica a la documentación generada en cada fase del desarrollo. Las revisiones han de ser formalizadas, es decir, deben estar contempladas en el ciclo de vida y debe existir también una normativa para su realización.. Recomendaciones • Las revisiones deben ser realizadas por un grupo de personas y no por un solo individuo. Esto permite diferentes puntos de vista. • El grupo que realiza la revisión debe ser reducido. De tres a cinco personas. • La revisión no debe ser realizada por los autores del producto para garantizar la imparcialidad de criterio. • Se debe revisar el producto, pero no el productor ni el proceso de producción. • Si la revisión ha de decidir si un producto se acepta o no, ha de realizarse antes una lista formal de comprobaciones y atenerse a ella. • Debe levantarse acta de la reunión de revisión, conteniendo los puntos importantes discutidos así como las decisiones adoptadas. 1.9.4. Pruebas Las pruebas consisten en hacer funcionar un producto software en condiciones determinadas y comprobar si los resultados obtenidos son correctos. Su objetivo es descubrir errores para subsanarlos. Las pruebas no permiten garantizar la calidad de un producto, pues pueden existir fallos que sólo se manifiesten con otras pruebas más exahustivas. Sin embargo, una prueba tiene éxito si descubre algún error, con lo que se sabe que el producto no cumple con algún criterio de calidad. 1.9.5. Gestión de configuración Configuración de Software Por configuración de software se entiende la manera en que diversos elementos se combinan para constituir un producto bien organizado, tanto desde el punto de vista de su explotación como de su mantenimiento. Los elementos que componen la configuración son aquellos que forman parte del desarrollo (especificaciones, diseño, código fuente, programas, datos y resultados de pruebas), así como aquellos que forman parte del producto entregado al cliente (programas, manuales de usuario, documentos de mantenimientos, normas del proyecto, etc.). Dado que estos elementos pueden variar a lo largo del tiempo, se puede dar el caso de tener diferentes configuraciones particulares. Para controlar dichas configuraciones se utilizan varias técnicas: Control de versiones Consiste en almacenar organizadamente las sucesivas versiones de cada elemento de la configuración, de forma que se pueda acceder a una configuración concreta cómodamente. Control de cambios Consiste en garantizar que las diferentes configuraciones se componen de elementos compatibles entre sí. Línea base Es una configuración particular del sistema que se utiliza en el control de cambios. Cada línea base se construye a partir de otra mediante la inclusión de ciertos cambios. Las líneas bases constituyen configuraciones estables “congeladas” y no pueden ser modificadas. Si se desea modificar una línea base se creará otra a partir de aquella. 1.9.6. Normas y estándares Las recomendaciones de la ingeniería de software ha dado lugar a la creación de normas que algunas organizaciones han recogido dando lugar a estándares. IEEE Institute of Electrical and Electronics Engineer. Ha establecido una colección de normas, muchas de ellas también admitidas como normas ANSI (American National Standards Institute). DoD Department of Defense. La norma fundamental es la DoD-STD-2167A. Será sustituida por la norma MIL-STD-SDD y contiene modelos de los documentos a redactar. ESA European Space Agency. Posee la norma ESA91 que es general para el desarrollo de software. ISO International Standards Organization. Integrado por los organismos nacionales de normalización de muchos paises (AENOR en España), publica un sinfín de normas para la actividad técnico-industrial. La norma ISO-9001 contiene normas para la ingeniería de software y establece los criterios que deben cumplir las empresas que desarrollen software para obtener certificaciones de determinados niveles de garantía de calidad. METRICA-2 Norma española desarrollada por el CSIC para el Ministerio de las Administraciones Públicas. Es una norma para el desarrollo de sistemas de información de las administraciones públicas, basada en la metodología de análisis y diseño estructurado de Yourdon/DeMarco. 2. ESPECIFICACIÓN DE SOFTWARE Este tema se dedica a describir la labor de análisis y definición de los requisitos que ha de cumplir un proyecto de software, lo que debe dar lugar a la especificación de software.

Apuntes realizados por Antonio Reyes. C.A.Tenerife

6

2.1. Modelado de Sistemas De la misma forma que en arquitectura se utilizan maquetas para analizar edificios, el desarrollo de sistemas permite la utilización de modelos conceptuales que reflejen, por un lado, la organización de la información y, por otro lado, las diversas transformaciones que han de llevarse a cabo con dicha información. Por modelo se entiende un modelo completo y preciso del comportamiento u organización del sistema software. No se trata de los modelos vistos en el tema 1. 2.1.1. Concepto de modelo Modelo Un modelo conceptual es todo aquello que nos permite conseguir una abstracción lógicomatemática del mundo real de forma que facilite comprender el problema a resolver. Características Un modelo debe establecer las propiedades y características del sistema. Ofrece una visión de alto nivel, sin explicar detalles. Debe explicar QUÉ hace el sistema. Objetivos 1. Facilitar la comprensión del problema a resolver. 2. Establecer un marco para la discusión que sistematice las labores de análisis inicial y revisiones futuras. 3. Fijar las bases para realizar el diseño. 4. Facilitar la verificación del cumplimiento de los objetivos del sistema. 2.1.2. Técnicas de modelado La obtención de un modelo que cumpla los objetivos anteriores es compleja. Puede no existir experiencia previa, o simplemente el sistema a modelar es complejo. Para su realización existen diversas técnicas: 2.1.2.1. Descomposición. Modelo jerarquizado La técnica de descomposición se basa en el axioma “divide y vencerás” y consiste en descomponer el problema original en subproblemas. Descomposición horizontal Consiste en descomponer funcionalmente un problema. Ejp. un sistema de nóminas se puede descomponer en subsistemas de pagos a la seg.soc., pago irpf, pago de nómina, etc. Para que funcione el sistema global se deberán establecer interfases entre los subsistemas. Descomposición vertical Consiste en descomponer un modelo detallando su estructura. Ejp. en el sistema de nóminas sería: 1º dar de alta el trabajador, 2º calcular ingresos brutos, 3º calcular retenciones, etc. 2.1.2.2. Aproximaciones sucesivas Cuando se va a desarrollar un sistema se puede utilizar uno ya existente como modelo de partida. Obviamente, el sistema a desarrollar será diferente. Por el contrario, cuando el sistema a desarrollar sustituya a uno manual se podrá utilizar éste como modelo preliminar, de forma que se pueda depurar mediante aproximaciones sucesivas. Esta depuración es compleja y requiere experiencia y estudio del problema a resolver. Es conveniente contar con la colaboración de alguien que conozca el sistema anterior. 2.1.2.3. Empleo de diversas notaciones A veces es necesario utilizar diferentes notaciones para elaborar un modelo. Se puede utilizar el lenguaje natural aunque éste adolece de imprecisiones e incorrecciones por lo que es preferible el uso de esquemas. CASE La utilización de herramientas CASE permiten la utilización de diversas notaciones (texto, tablas, diagramas, gráficos, etc.). 2.1.2.4. Considerar distintos puntos de vista La necesidad de adoptar un punto de vista en la creación de un modelo hará que éste se vea necesariamente influido por aquel. Algunos puntos de vista pueden ser: el del usuario, el del mantenedor del sistema, el funcional, etc. A veces un modelo puede estar definido desde varios puntos de vista. 2.1.2.5. Realizar un análisis del dominio Dominio Se entiende por dominio el campo de aplicación en el que se encuadra el sistema a desarrollar. Análisis del dominio Son las consideraciones a tener en cuenta al analizar una aplicación. Hay que analizar el dominio de la aplicación para situarla dentro de un entorno mucho más global. Puede ser la terminología utilizada en ese campo en concreto, la forma de hacer las cosas, etc. Aspectos a considerar A la hora de realizar el análisis del dominio ha de tenerse en cuenta: la normativa que afecte al sistema, otros sistemas semejantes, estudios recientes, bibliografía actualizada, etc. Ventajas del enfoque global 1. Facilitar la comunicación entre analista y usuario del sistema, entendiendo por usuario la persona que utilizará el sistema una vez terminado y que conoce el tema en profundidad. Uso de términos propios del campo a solucionar. 2. Creación de elementos realmente significativos del sistema. Esto evita que las aplicaciones queden particularizadas en exceso, adoptando soluciones globales. 3. Reutilización posterior del software desarrollado. 2.2. Análisis de requisitos de software Con el análisis de requisitos se trata de caracterizar el problema a resolver. Analista Es el ingeniero de software encargado de realizar el análisis de requisitos de software. Cliente Se entiende por tal el conjunto de personas que conoce en profundidad parte o todo el problema a automatizar. A veces no existirá como tal, debiendo investigar el analista por su cuenta; otras veces será el encargado de elaborar junto con el analista las especificaciones del proyecto software y que ambos verificarán una vez realizado; en otras ocasiones el

Apuntes realizados por Antonio Reyes. C.A.Tenerife

7

cliente es simplemente parte de una especificación de un problema mayor. 2.2.1. Objetivos del análisis El objetivo del análisis es obtener las especificaciones del sistema a desarrollar. Se realiza mediante un modelo válido que recoga todas las necesidades del cliente y todas las restricciones que el analista considere debe verificar el sistema. Propiedades del modelo Para lograr una especificación correcta, el modelo global del sistema deberá cumplir las siguientes propiedades: 1. Completo y sin omisiones Aunque parezca fácil de cumplir, a veces se omiten los requisitos mínimos del hardware o el sistema operativo sobre el que se ejecutará el sistema. 2. Conciso y sin Si la documentación es excesiva suele ser por contener repeticiones o trivialidades. Por otro trivialidades lado, si el sistema es muy extenso, puede ocurrir que se pasen por alto partes esenciales. 3. Sin ambigüedades Las ambigüedades han de evitarse totalmente pues pueden producir problemas tales como: dificultades de diseño, errores en la implementación, imposibilidad de verificar la especificación, etc. 4. Sin detalles de diseño o Un buen análisis nunca debe entrar en CÓMO resolver el problema sino en el QUÉ. implementación 5. Fácilmente entendible El cliente debe ser capaz de discutir todos los aspectos. Para ello se debe emplear un por el cliente lenguaje que facilite ese entendimiento. 6. Separando requisitos Los requisitos funcionales establecen el modelo de funcionamiento del sistema y son el funcionales y no fruto de las discusiones del analista con el cliente. Los requisitos no funcionales son más funcionales ‘técnicos’ y no interesan tanto al cliente; se refieren a temas como capacidad mínima y máxima, aspectos de seguridad, fiabilidad, mantenimiento, etc. Ambos requisitos, funcionales y no funcionales, han de ir separados. 7. Dividiendo y La forma más sencilla de simplificar un modelo es dividiéndolo y jerarquizándolo en jerarquizando el modelo submodelos. Se irá de lo general a lo particular. 8. Fijando los criterios de Es importante indicar en el modelo los criterios de validación del sistema. No hay que validación olvidar el aspecto contractual. Se podría realizar un manual del usuario preliminar. 2.2.2. Tareas de análisis La realización de un análisis de requisitos conlleva realizar una serie de tareas que por este orden son: 1. Estudio del sistema en su Lo primero que se ha de conocer es el medio hardware en el que se desenvolverá el sistema. contexto Habría que hacer un contexto global de funcionamiento del sistema para, posteriormente, hacer una configuración particular al cliente en concreto. 2. Identificación de Inicialmente, el cliente pedirá más funciones de las necesarias. El analista debe concretar necesidades las necesidades que se pueden cubrir con los recursos disponibles, respetando el presupuesto y el plazo de entrega. Debe haber una comunicación fluida con el cliente que permita hacer una propuesta satisfactoria para todos. Se deben descartar las funciones que son muy costosas y no aportan gran cosa al sistema. Si alguna función tiene cierto interés pero es excesivamente costosa, se debe proponer alguna solución parecida o incompleta. El analista ha de convencer a todos de que la solución propuesta es la adecuada. 3. Análisis de alternativas. Esta tarea, en la que aparece el enfoque de ingeniero de software que debe tener el analista, Estudio de viabilidad consiste en buscar la alternativa que cubra las necesidades reales detectadas en el paso anterior, teniendo en cuenta su viabilidad económica y técnica. Cada alternativa tendrá un estudio de viabilidad que será el que decidirá sobre la alternativa. Esta etapa es necesaria en proyectos de alto presupuesto o alta complejidad. 4.Establecimiento del Las conclusiones adoptadas en pasos anteriores se irán plasmando en el modelo del sistema modelo del sistema según se vaya avanzando. Al final, se obtendrá un modelo del sistema global jerarquizado en el que figurarán, a su vez, subsistemas que tendrán que ser desarrollados. Se utilizarán herramientas CASE, procesadores de texto, gráficos, etc. 5. Elaboración del El documento de especificación de requisitos es el resultado final del análisis. Es documento de importante señalar que este documento es el documento de partida para el trabajo del especificación de requisitos diseñador. 6. Revisión continuada del Es muy frecuente que se produzcan cambios en la especificación de requisitos, muchas análisis veces por cambios de criterio del cliente. Esto obliga a realizar una revisión continuada del análisis. Es frecuente que dicha revisión no se lleve a cabo y eso da lugar a problemas de verificación. 2.3. Notaciones para la especificación Si bien el empleo de diferentes notaciones para especificar un problema debería dar lugar a la misma especificación, nos vemos con que el empleo de una notación adecuada para cada caso dará lugar a una mejor especificación para ese caso. El cliente, usuario y, todos los que participen en el proyecto deberán conocer la notación que se utilice. Existen varias: 2.3.1. Lenguaje natural

Apuntes realizados por Antonio Reyes. C.A.Tenerife

8

El lenguaje natural es la forma más inmediata de realizar una especificación, sin embargo presenta los inconvenientes de imprecisiones, repeticiones e incorrecciones. Se utilizará cuando haya que aclarar algo concreto del sistema. Es importante organizar y estructurar los requisitos de la especificación. Para ello es conveniente concebir cada requisito como una claúsula entre el analista y el cliente. Por otro lado, el lenguaje natural estructurado, trata de establecer ciertas reglas para la construcción de frases de forma que tengan una estructura similar a las estructuras de secuencia, condición e iteración. 2.3.2. Diagramas de flujos de datos Enfoque de análisis El enfoque del análisis estructurado consiste en considerar que un sistema software se estructurado puede modelar mediante el flujo de datos que entra al sistema, las transformaciones realizadas al mismo y el flujo de datos producido en la salida. DFD Diagrama de Flujo de Mediante el diagrama de flujo de datos, se puede Datos modelar de forma sencilla las transformaciones y los flujos de datos utilizando: 1. Flechas, para indicar un flujo de datos, 2. Círculos, para indicar un proceso o transformación. 3. Rectángulos, para indicar una unidad externa. 4. Una línea doble para indicar un almacén de datos. DFD de contexto o nivel 0 Es un DFD del sistema global. Contiene un único proceso. Constituye el nivel 0. Niveles Para refinar un modelo, los DFD se usan de forma jerarquizada por niveles. “Explotar” Efecto mediante el cual un proceso de un DFD se detalla mediante otro DFD de un nivel más alto. DFD 0 o de nivel 1 Es el único DFD que se puede derivar del DFD de contexto. En él figurarán cuantos procesos sean necesarios, pero se respetarán los flujos de entrada y salida existentes en el DFD de contexto. Sólo puede exister un DFD 0 o de nivel 1. Refinamientos Cada refinamiento dará lugar a un nuevo nivel en la jerarquía del diagrama. Han de ir numerados con referencia al DFD del que explota. En todos ellos los flujos de datos de entrada y salida antes de la “explosión” del proceso debe coincidir con los flujos de entrada y salida del DFD resultado de la explosión o refinamiento. El refinamiento no debe ser excesivo. Ventajas La ventaja de los DFD es su fácil comprensión por los clientes. Desventajas Son diagramas estáticos, en ningún momento se puede saber el orden de los procesos. 2.3.3. Diagramas de transición de estados Dinámica del sistema Lo conforman todos los estados y las sucesivas transiciones entre ellos. Diagramas de transición Se complementan con los DFD y describe el comportamiento dinámico del sistema. Se usan: 1. Los dobles círculos para indicar el inicio o fin de un proceso. 2. Los rectángulos o círculos para indicar un estado intermedio del sistema. 3. Las flechas para indicar los eventos que provocan los cambios de estados. 2.3.4. Descripciones funcionales. Pseudocódigo Estructuras básicas Esta notación es esencial en la descripción de los requisitos funcionales. Mediante pseudocódigo y utilizando un lenguaje natural estructurado se pueden emplear las siguientes estructuras: a) Selección (IF); b) Selección por casos (SELECT CASE); c) Iteración con pre-condición (WHILE); d) Iteración con post-condición (REPEAT); e) Número de iteraciones conocido (FOR). PDL El PDL (Program Description Language), es un lenguaje pensado para realizar el diseño, es muy parecido al pseudocódigo pero incluye estructuras de lenguajes de alto nivel. 2.3.5. Descripción de datos Consiste en detallar la estructura interna de los datos (relevantes) que manejará el sistema sin descender a detalles de diseño o codificación. Diccionario de datos Es una notación utilizada en la metodología de análisis estructurado. Es más informal que las declaraciones de un lenguaje pero es útil para la especificación. Consta de: 1. Nombre o nombres. Será la denominación con la que se referirán a un dato. 2. Utilidad. Se indicarán los procesos en los que se utilizará el dato. 3. Estructura. Se indicarán los elementos de los que está constituido el dato. Se utilizará la notación: • A + B Æ Secuencia o concatenación de los elementos A y B

Apuntes realizados por Antonio Reyes. C.A.Tenerife

9

• • • •

[A | B] Æ Selección entre los distinos elementos A o bien B {A}N Æ Repetición N veces del elemento A. Si se ignora N, no se pone / descripción / Æ Descripción en lenguaje natural como comentarios = Æ Separador entre el nombre de un elemento y su descripción.

2.3.6. Diagrama de modelo de datos Modelo entidad-relación Es el modelo de datos que se considera fundamental para la especificación. Consta de: 1. Rombo, para indicar la relación. 2. Rectángulo, para indicar las entidades. 3. Líneas que sirven para unir las relaciones y las entidades. 4. La cardinalidad, que indican entre qué valores mínimo y máximo se mueve la relación entre entidades. Cardinalidad.

2.4. Documento de especificación de requisitos SRD El documento de especificación de requisitos o Software Requirements Document (SRD) o Software Requirements Specification (SRS) es el documento que recoge todo el fruto del trabajo realizado durante el análisis del sistema. Modelo de SRD de la ESA El modelo general de la Agencia Espacial Europea consta de varias partes: 1. Introducción 1.1. Objetivo. Describe brevemente el proyecto, destinatarios, calendario. 1.2. Ámbito. Se dará nombre al producto/ y qué hace cada uno y/o qué no hace. 1.3. Definiciones, siglas y abreviaturas que se utilizarán en el documento. 1.4. Referencias, a otros programas, bibliografía. 1.5. Panorámica del documento. Describe la organización y contenido del resto del doc. 2. Descripción general 2.1. Relación con otros proyectos. 2.2. Relación con proyectos anteriores y posteriores. 2.3. Objetivos y funciones. Se describirá el sistema en su conjunto con los objetivos y funciones principales. 2.4. Consideraciones de entorno. Son características especiales que debe tener el entorno. 2.5. Relaciones con otros sistemas. Describe si se integrará en otros sistemas, etc. 2.6. Restricciones generales. P. Ejp. metodología de desarrollo, lenguaje de programación, restricciones de hardware, de sistema operativo, etc. 2.7. Descripción del modelo. Debe describir el modelo conceptual que se propone para desarrollar el sistema en su conjunto y para cada una de sus partes más relevantes. 3. Requisitos específicos Los requisitos han de ser concisos y precisos, no han de incluirse aspectos de diseño o desarrollo. Se puede incluir el grado de cumplimiento según sea: obligatorio, recomendable u opcional. 3.1. Requisitos funcionales. Son los que describen el QUÉ hace el sistema y está ligado al modelo conceptual. Se concretarán operaciones de tratamiento de información, generación de informes, etc. 3.2. Requisitos de capacidad. Son los volúmenes de información a procesar. 3.3. Requisitos de interfase. Se refiere a la conexión con otros sistemas (protocolos, formato de ficheros, sistemas operativos, etc.). 3.4. Requisitos de operación. Incluye los requisitos de interfase de usuario pero además, el arranque y parada, copias de seguridad, instalación y configuración. 3.5. Requisitos de recursos. Elementos hardware, software, instalaciones, etc. 3.6. Requisitos de verificación. Son los que debe cumplir el sistema para su verificación. 3.7. Requisitos de prueba de aceptación. 3.8. Requisitos de documentación. La que formará parte del producto a entregar. 3.9. Requisitos de seguridad. Confidencialidad, virus, integridad. 3.10. Requisitos de transportabilidad. A otros sistemas operativos. 3.11. Requisitos de calidad. Son aquellos que no estén incluidos en otros apartados. 3.12. Requisitos de fiabilidad. Límite aceptable de fallos o caídas. 3.13. Requisitos de mantenibilidad. 3.14. Requisitos de salvaguarda. Deben evitar que los errores tengan consecuencias graves en los equipos o personas.

Apuntes realizados por Antonio Reyes. C.A.Tenerife

10

3. FUNDAMENTOS DEL DISEÑO DE SOFTWARE Este tema y el siguiente se dedica a CÓMO resolver el proyecto de software. En este tema se abordan los fundamentos de la etapa de diseño y se divide en cuatro apartados: a) Qué se entiende por diseño; b) Conceptos fundamentales; c) Notaciones utilizadas, y; d) Formatos propuestos 3.1. Introducción Diseño La palabra diseño es un término mediante el cual se trata de definir y formalizar la estructura del sistema con el suficiente detalle como para permitir su realización física. Para su realización se parte del SRD siendo un proceso creativo nada trivial donde prima el método iterativo de prueba y error. Know-how Es el aprovechamiento del enfoque dado en un proyecto diferente al actual y que puede ser útil para el proyecto presente. Adquirir experiencia La única forma de aprender a diseñar es adquirir experiencia, participar en muchos proyectos y analizar proyectos existentes. Objetivos actuales Los objetivos actuales del diseño es conseguir que el software sea fácil de mantener y de que su código sea reutilizable. No existe límite No existe un límite claro entre el análisis y el diseño, ya que el paso de aquél a éste se hace de forma gradual. Actividades Son realizadas a lo largo del proceso de diseño y tienen como objetivo sistematizar cada uno de los aspectos o elementos de la estructura del sistema. Con ellas se persigue un refinamiento progresivo del diseño. Algunas de esas actividades son: 1. Diseño arquitectónico En ella se deben abordar los aspectos estructurales y de organización del sistema y su posible división en subsistemas o módulos. Esto incluye las interfases entre los módulos y las relaciones entre los subsistemas. Aporta una visión general del sistema. 2. Diseño detallado Aquí se aborda la organización de los módulos. Se debe determinar cuál es la estructura más adecuada para cada módulo según el punto anterior. Módulos de Definición 3. Diseño procedimental Aquí se aborda la organización de las operaciones o servicios que ofrecerá cada módulo. Se desarrolla en pseudocódigo. Módulos de Implementación. 4. Diseño de datos Aquí se aborda la organización de la base de datos del sistema, pudiéndose realizar al mismo tiempo que el diseño detallado y procedimental. Se parte, para ello, del diagrama ER y diccionario de datos del SRD. 5. Diseño de la interfaz de Es la actividad encargada de la organización de la interfaz de usuario. usuario Producto del diseño Es el resultado de la aplicación de las actividades anteriores y se recogerá en el SDD (Software Design Document) o (Software Design Description). 3.2. Conceptos de base Los conceptos que se verán a continuación no se limitan en su mayoría a la etapa de diseño sino que serán útiles en otros ámbitos, habiendo dado lugar, algunos de ellos, a la creación de metodologías específicas. 3.2.1. Abstracción Abstracción La abstracción ayuda mucho a conseguir los objetivos de obtener elementos fácilmente mantenibles y reutilizables y consiste, esencialmente, en identificar los elementos realmente significativos de los que consta el nuevo sistema software con el fin de abstraer la utilidad específica de cada uno, incluso más allá del sistema software para el que se está diseñando. El proceso de abstracción se aplicará en todos los niveles de diseño. Formas de abstracción Existen tres formas de abstracción: 1. Abstracciones funcionales, que son aquellas que sirven para crear expresiones parametrizadas mediante la utilización de funciones o procedimientos. Se debe fijar los parámetros a facilitar, el algoritmo que resolverá el problema y los parámetros de salida o resultados. 2. Tipos abstractos, que sirven para crear los nuevos tipos de datos. Consta de su definición y de las operaciones que se pueden hacer con él. 3. Máquina abstracta, que sirve para definir formalmente el funcionamiento de una máquina (p.ejp. intérprete de SQL, protocolo de comunicaciones, etc.). 3.2.2. Modularidad División del trabajo La modularidad permite la división del trabajo entre diferentes personas de forma que cada una de ellas se dedique a un módulo bien definido. Ello exige una importante coordinación debiendo quedar definidas las interfases entre los diferentes módulos. Otras ventajas Otras ventajas de la modularidad son: 1. Claridad, pues es más fácil entender cada parte por separado que un todo. 2. Reducción de costos, siempre que el nº de módulos sea adecuado, resulta más barato desarrollar, mantener y documentar un sistema modular, que otro que no lo es. 3. Reutilización, pues si se realizan teniendo en cuenta otras posibles aplicaciones, se podrán reutilizar.

Apuntes realizados por Antonio Reyes. C.A.Tenerife

11

3.2.3. Refinamiento El objetivo de un sistema, consistente en plasmar la especificación en un lenguaje de alto nivel, se debe refinar en sucesivos pasos hasta que todo quede expresado en el lenguaje de programación del computador. 3.2.4 Estructuras de datos Las decisiones respecto a las estructuras de los datos son esenciales en el diseño de un sistema software. Tal es así, que se han desarrollado muchas metodologías que tienen como punto de partida la estructura de los datos. Se deben tener en cuenta estructuras tales como: registros, conjuntos, formaciones, listas, pilas, colas, árboles, grafos, tablas, ficheros, etc. 3.2.5. Ocultación El concepto de ocultación en el desarrollo de software tiene como objetivo ocultar al usuario de un módulo todo lo que pueda ser susceptible de cambio en un futuro y que además es irrelevante para el usuario; por el contrario, se muestra en la interfaz todo aquello que no variará con cualquier cambio. Ello tiene como ventaja: a) Depuración, pues resulta más fácil identificar el módulo que no funciona correctamente, y b) Mantenimiento, pues una modificación afectará a un módulo y no a todo el sistema. 3.2.6. Genericidad La genericidad es un concepto mediante el cual se trata de agrupar aquellos elementos del sistema que utilizan estructuras semejantes o tendrán un tratamiento similar. Prescindiendo de detalles particulares, se puede diseñar un elemento genérico que posteriormente será tratado para cada caso particular. 3.2.7. Herencia El concepto de herencia está muy ligado a las metodologías de diseño de software orientado a objetos. Se trata de que ciertos elementos, denominados hijos, puedan heredar de otros, denominados ‘padres’, que poseen una estructura y operaciones básicas, sus estructuras y operaciones para, ampliarlos, mejorarlos o simplemente, adaptarlos. A su vez los hijos pueden tener otros hijos. Tiene como ventaja la reutilización de software. 3.2.8. Polimorfismo Mediante polimorfismo se entiende la posibilidad de que un producto software adquiera varias formas simultáneamente. Algunas de ellas son: a) Concepto de genericidad, cuando se particulariza en cada caso; b) Concepto de herencia, cuando los hijos adoptan formas diferentes de los padres; c) Concepto de sobrecarga, en el que quienes adquieren diferentes formas son los operadores, funciones o procedimientos, p. Ejp. el operador +, pues no es lo mismo sumar un entero que un real. 3.2.9. Concurrencia En sistemas con restricciones de tiempo en el que debe existir una respuesta rápida debe tenerse en cuenta lo siguiente: 1. Tareas concurrentes Determinar qué tareas se deben ejecutar en paralelo para cumplir con las restricciones impuestas. Se debe prestar atención a las tareas más comunes y a las tareas con tiempos de respuesta más críticos. 2. Sincronización de tareas Determinar los puntos de sincronización entre las distintas tareas. Se pueden utilizar semáforos. 3. Comunicación entre Determinar si la cooperación se basa en emplear datos compartidos o mediante el paso de tareas mensajes entre las tareas. Se deben definir las tareas productoras y las consumidoras, así como si se pueden modificar datos durante una consulta y la forma de controlarlo (semáforos, monitores, región crítica, etc.) 4. Interbloqueos Estudiar los posibles interbloqueos entre las tareas. 3.3. Notaciones para el diseño Notaciones Al igual que para realizar la especificación, existen multitud de notaciones. Ha de conocerse qué significa cada cosa en cada notación, pues puede ocurrir que un mismo símbolo signifique cosas diferentes dependiendo de la notación utilizada. Objetivos Los objetivos de la notación es que resulte precisa, clara y sencilla de interpretar. Clasificación Las notaciones se clasifican en: a) estructurales, b) estáticas o de organización, c) dinámicas o de comportamiento, y, d) híbridas. 3.3.1. Notaciones estructurales Å Diagrama de bloques. Sirven para cubrir un primer nivel del diseño arquitectónico y con ellas se trata de desglosar y estructurar el sistema en sus partes fundamentales. Consiste en cajas unidas por líneas. En algunos diagramas las cajas situadas en la parte superior son las cajas de mayor nivel. Cajas adosadas Se denomina así al diagrama en el que las cajas están pegadas unas a otras. Entre capas adyacentes está definida una interfaz estándar que posibilita su comunicación. 3.3.1.1. Diagramas de estructura Sirven para representar la organización estática de los módulos. Fueron propuestos por Yourdon y sus símbolos sirven para describir la estructura de los sistemas software como jerarquía de subprogramas. Emplea los siguientes símbolos:

Rectángulos Líneas

Representan un módulo o subprograma cuyo nombre se incluye en el interior. Une dos rectángulos e indica que el superior utiliza o llama al módulo inferior.

Apuntes realizados por Antonio Reyes. C.A.Tenerife

12

Rombos Arcos Círculo con flecha

Situados sobre una línea, indica que esa llamada es opcional. Se sitúan sobre una línea e indican que esa llamada se efectúa repetidamente. Se sitúan en paralelo a una línea y representa el envío de unos datos en el sentido de la flecha. Si el círculo es relleno, indica que se envía una información de control.

3.3.1.2. Diagramas HIPO Diagramas HIPO

Los diagramas HIPO (Hierarchy-Input-Process-Output) son una notación propuesta por IBM destinadas a aplicaciones de gestión. Patrón Todos los módulos pueden adaptarse al patrón de que los datos entran, se procesan y salen. Diagrama de contenido En los diagramas HIPO, existe un diagrama HIPO de contenidos, que establece la jerarquía Diagrama de detalle entre los módulos del sistema, en el que cada rectángulo que representa un módulo tiene un nombre y una referencia a otro diagrama de detalle en el que se muestra el patrón I-P-O. En dicho diagrama de detalle se debe indicar el diagrama del que procede y el diagrama o diagramas en los que se desarrolla aún más. 3.3.1.3. Diagramas de Jackson Metodología de Jackson Esta metodología, a la que pertenecen estos diagramas, consiste en diseñar sistemas software a partir de las estructuras de los datos de entrada y salida. Proceso de diseño Es muy sistemático y se realiza en tres pasos: 1. Especificación de las estructuras de los datos de entrada y salida. 2. Obtención de una estructura del programa capaz de transformar las estructuras de datos de entrada en las de salida (tupla, unión, formación). 3. Expansión de la estructura del programa para lograr el diseño detallado del sistema. Se suele utilizar pseudocódigo. Notación En la notación de los diagramas de Jackson los módulos superiores se detallan según indican los elementos inmediatamente inferiores. Los elementos siempre van de izquierda a derecha. Si un elemento tiene el símbolo “*” quiere decir que se repetirá 0 o más veces. Si un elemento contiene el símbolo “O” quiere decir que forma parte de una selección con otro elemento. 3.3.2. Notaciones estáticas Las notaciones estáticas sirven para describir características estáticas del sistema como son la organización de la información sin tener en cuenta su evolución dinámica. En la fase de diseño la organización de la información debe tener en cuenta aspectos internos como son la utilización de datos auxiliares, datos redundantes, etc. Así que, en esta fase, se tendrá un detalle de la organización de la información mucho mayor. Se pueden utilizar las mismas notaciones que en la especificación: Notaciones 3.3.2.1. Diccionario de datos. Sirve para detallar la estructura interna de los datos. Se parte del diccionario de datos del SRD y se ampliará mediante refinamientos. 3.3.2.2. Diagrama Entidad-Relación. Sirve para definir el modelo de datos, las relaciones entre ellos y la organización de la información. Se partirá del SRD. 3.3.3. Notaciones dinámicas Permiten describir el comportamiento del sistema durante su funcionamiento. Para diseñar la dinámica del sistema se diseñará su comportamiento externo y se añadirá la descripción de un comportamiento interno de forma que se cumpla lo especificado en el SRD. Se utilizan las siguientes notaciones: Notaciones 3.3.3.1. Diagramas de flujo de datos. Serán mucho más exhaustivos que en el SRD. 3.3.3.2. Diagramas de transición de estados. No se debe ampliar o cambiar los diagramas de transición de estados del SRD. 3.3.3.3. Lenguaje de Descripción de Programas (PDL). En la etapa de diseño, la notación PDL se amplía con estructuras de algún lenguaje de alto nivel como Ada-PDL que ha sido incluído como estándar en las normas IEEE. 3.3.4. Notaciones híbridas Estas notaciones sirven para cubrir simultáneamente aspectos estructurales estáticos y dinámicos (p.ejp. la metodología Jackson). En concreto, permiten un enfoque globalizado del diseño en el que se aglutinan los aspectos estáticos (datos), dinámicos (operaciones) y de estructura del sistema. 3.3.4.1. Diagrama de abstracciones Abstracción Se compone de: • Nombre. • Contenido. Es el elemento estático de la abstracción y en él se define la organización de los datos que constituye la abstracción (def. de constantes, tipos de datos, variables, etc. en el módulo de definición). • Operaciones. Es el elemento dinámico de la abstracción y en él se agrupan todas las operaciones definidas para manejar el contenido de la misma. En Modula-2 serían las definiciones de funciones y/o procedimientos declaradas en el módulo de definición. Abstracción funcional Las abstracciones funcionales las constituyen los subprogramas. Tipo abstracto de datos Es una abstracción constituida por una estructura de datos y por las operaciones que se

Apuntes realizados por Antonio Reyes. C.A.Tenerife

13

Dato encapsulado

pueden hacer con dicha estructura. Tiene una parte de contenido y operaciones. Permiten crear nuevos tipos de datos. Es una forma de abstracción, que al igual que los tipos abstractos de datos, tiene contenido y operaciones, pero que a diferencia de éstos, su definición está encapsulada en la abstracción, es decir, se puede operar con ellos, pero no se pueden definir nuevas variables de ese tipo.

Notación gráfica

3.3.4.2. Diagramas de objetos Las equivalencias entre abstracciones (propuestos por progamadores) y objetos (propuestos por la inteligencia artificial) son enormes. Ello hace que se puedan equiparar los términos de unos y otros. Equivalencias Abstracciones Objetos Tipo abstracto de datos Clase de objeto Abstracción funcional No hay equivalencia Dato encapsulado No hay equivalencia Dato abstracto (variable o constante) Objeto (ejemplar de la Clase) Contenido Atributos Operaciones Métodos Llamada a una operación Mensaje al objeto Relaciones entre objetos Entre los objetos se pueden considerar las siguientes relaciones: 1. Clasificación, especialización o herencia (no contemplada en las abstracciones). Esta propiedad de los objetos permite adaptar a los hijos las operaciones heredadas a sus necesidades. No es necesario indicar la cardinalidad entre las clases de objetos. 2. Composición (también válida entre abstracciones). Permite describir un objeto mediante los elementos que lo forman. Es necesario indicar la cardinalidad en un sentido. Notación OMT Acrónimo de Object Modelling Technique utiliza el triángulo para indicar que los objetos inferiores heredan los atributos y operaciones del objeto superior, y el rombo para indicar que el objeto superior está formado por los objetos inferiores. 3.4. Documentos de diseño El resultado de la labor de diseño se plasma en un documento denominado Software Design Document (SDD). Veremos a continuación los utilizados por la ESA, llamados ADD y DDD. 3.4.1. Documento ADD (Arquitectural Design Document) 1. Introducción Se compone de objetivo, ámbito, definiciones, siglas y abreviaturas, referencias. Serán similares al SRD. 2. Panorámica del sistema Dará una visión general de los requisitos funcionales del sistema, basándose en el SRD. 3. Contexto del sistema Se debe indicar si existen conexiones con otros sistemas y si debe funcionar de forma integrada con ellos. Se definirá la interfase. 4. Diseño del sistema Describe el nivel superior de diseño: 4.1. Metodología de diseño de alto nivel. 4.2. Descomposición del sistema. Se describe el primer nivel de descomposición del sistema en sus primeros componentes. Se nombran las relaciones entre ellos. 5. Diseño de los Cada sección se repetirá para cada componente de 4.2. componentes 5.n. Identificador de componente. 5.n.1. Tipo. Es la clase de componente (módulo, proceso, datos, etc.). 5.n.2. Objetivo. Se describe la necesidad de este componente. 5.n.3. Función. Se describe qué hace el componente. 5.n.4. Subordinados. Componentes usados por éste. 5.n.5. Dependencias. Se enumeran los componentes que usan a éste. Se incluye su naturaleza. 5.n.6. Interfases. Indica cómo interactúan con éste otros componentes. 5.n.7. Recursos. Se indican los elementos usados por este componente externos al diseño: impresoras, disco, memoria, etc. 5.n.8. Referencias. 5.n.9. Proceso. Se describen los algoritmos que utiliza el componente para realizar su función como un refinamiento de 5.n.3. 5.1.10. Datos. Se describen los datos internos del componente incluyendo el método de representación, valores iniciales, formato, valores válidos, etc.

Apuntes realizados por Antonio Reyes. C.A.Tenerife

14

6. Viabilidad y recursos estimados Se analiza la viabilidad y se concretan los recursos necesarios. 7. Matriz requisitos / Se muestra una matriz poniendo en las filas los requisitos y en las columnas los componentes componentes, marcando según corresponda. 3.4.2. Documento DDD (Detailed Design Document) El DDD irá creciendo según se avance en el desarrollo del proyecto. Es muy aprecido al ADD pero se diferencia de aquel en que el nivel de detalle es mucho mayor. En algunos componentes se llega incluso al nivel de codificación. De hecho los listados fuente se recogen como un apéndice. Sección de normas Se incluye una sección de normas, convenios y procedimientos en la que se incluyen normas de diseño de bajo nivel, normas y convenios de documentación, convenios de nombres, normas de programación y herramientas de desarrollo de software. Estas normas son muy importantes en proyectos de envergadura y debe ser la primera actividad del diseño detallado antes de iniciar el diseño propiamente dicho. 4. TÉCNICAS GENERALES DE DISEÑO DE SOFTWARE El diseño de software es una actividad en la que prima la experiencia; sin embargo es necesario conocer muchas de las técnicas de diseño que tienen objetivos comunes. Objetivos Los objetivos inmediatos de las técnicas de diseño son: 1. Descomposición modular del sistema. Se trata de dividir el sistema en módulos. 2. La decisión sobre los aspectos de implementación de los datos. Se trata de decidir las estructuras de los datos y los algoritmos. 4.1. Descomposición modular La descomposición modular es una parte esencial del diseño y para hacer su descomposición de forma correcta se debe: a) identificar los módulos; b) describir cada módulo, y; c) describir las relaciones entre los módulos. Módulo Se puede definir como el fragmento de un sistema software que se puede elaborar con relativa independencia de los demás. Tipos de módulos Con la anterior definición de módulo se pueden definir diferentes clases: a) Código fuente, tal como son los módulos de Modula-2. b) Tabla de datos, de forma que dependiendo de cada proceso se pueda utilizar un módulo patrón de datos, etc. c) Configuración, p.ejp. cuando se elige un idioma u otro se utiliza un módulo u otro. d) Otros. Puede utilizarse para agrupar ciertos elementos relacionados entre sí que pueden ser tratados de forma separada del resto. Formato de módulos Depende de cada metodología o herramienta utilizada. No es lo mismo un módulo en Modula-2 que en Fortran. Cualidades Basados en la experiencia, una descomposición modular debe poseer ciertas cualidades mínimas para considerarla válida. Se trata de la independencia funcional (acoplamiento y cohesión), la comprensibilidad, y la adaptabilidad. 4.1.1. Independencia funcional La matriz de requisitos/componentes del ADD o DDD indica qué componente (módulo) se encarga de realizar cada uno de los requisitos (funciones) indicados en el SRD. En primer lugar se podría indicar que cada módulo se puede encargar de una función diferente, pero en sucesivos pasos de refinamiento del diseño algunas de esas funciones se agruparán en un solo módulo o algunos módulos se dividirán en otros. Independencia funcional Se consigue la independencia funcional cuando un módulo realiza una función concreta o un conjunto de funciones afines, sin apenas relación con el resto de módulos del sistema. Ventajas Las ventajas de la independencia funcional es una mayor facilidad de mantenimiento o cambio de módulos y aumenta las posibilidades de reutilización. Criterios Para medir la independencia funcional se utilizan dos criterios: acoplamiento y cohesión. 4.1.1.1. Acoplamiento El grado de acoplamiento entre módulos es una medida de la interrelación que existe entre ellos: tipo de conexión y complejidad de la interfase. Se utiliza la siguiente escala en las que figura el grado de acoplamiento: Escala. Grados de Fuerte Acoplamiento por Contenido acoplamiento Acoplamiento Común Moderado Acoplamiento Externo Acoplamiento de Control Débil Acoplamiento por Etiqueta Acoplamiento de Datos Sin Acoplamiento Directo Siempre se tratará de buscar un acoplamiento débil o a lo sumo, moderado. Acoplamiento por Se produce cuando desde un módulo se pueden cambiar los datos locales e incluso el Contenido código de otro módulo. Se logra sólo con lenguaje ensamblador. Un sistema con este tipo de acoplamiento resulta imposible de mantener e incluso de entender. Acoplamiento Común Se produce cuando se emplea una zona común de datos a la que tienen acceso varios

Apuntes realizados por Antonio Reyes. C.A.Tenerife

15

Acoplamiento Externo Acoplamiento de Control Acoplamiento por Etiqueta

módulos del sistema. El acceso es total, por lo que cualquier cambio debe ser tenido en cuenta por el resto de los módulos. La depuración es muy difícil y se debe evitar. Es un tipo de acoplamiento común en el que la zona común está constituida por algún dispositivo externo (disco, canal de comunicaciones, etc.). En este tipo de acoplamiento se le pasa al módulo un dato de control que determinará la línea de ejecución que seguirá. Se produce cuando se realiza un intercambio de los datos por referencia, permitiendo un acceso a la estructura de los datos. Se produce cuando se realiza exclusivamente un intercambio de los datos necesarios.

Acoplamiento de Datos 4.1.1.2. Cohesión El criterio de cohesión es complementario al de acoplamiento. Es necesario lograr que el contenido de cada módulo tenga coherencia. Tampoco se debe permitir que el nº de módulos crezca desmesuradamente. Se utiliza la siguiente escala: Escala. Grados de Alta Cohesión abstraccional Cohesión Cohesión funcional Media Cohesión secuencial Cohesión de comunicación Baja Cohesión temporal Cohesión lógica Cohesión coincidental Siempre se tratará de buscar una cohesión alta. Cohesión coincidental Es la peor de todas e indica que cualquier relación entre los elementos del módulo es casual. Cohesión lógica Se produce cuando en un mismo módulo se agrupan elementos que realizan funciones similares desde el punto de vista del usuario. Cohesión temporal Se produce cuando se agrupan en un mismo módulo elementos que se ejecutarán en un mismo momento (ejp. arrancar o parar dispositivos, etc.) Cohesión de comunicación Se produce cuando todos los elementos del módulo operan con el mismo conjunto de datos de entrada o producen el mismo conjunto de datos de salida. Cohesión secuencial Se produce cuando todos los elementos del módulo trabajan de forma secuencial. Es decir, el resultado de uno es la entrada del siguiente. Cohesión funcional Cada elemento está encargado de una función concreta. Cohesión abstraccional Se logra al cohesión abstraccional cuando se diseña un módulo como un tipo abstracto de datos o como una clase de objetos. En los dos casos se asocian un contenido (atributos) con las operaciones (métodos) que se utilizarán en su manejo. Criterios orientativos Para conocer el grado de cohesión de un módulo se pueden utilizar los siguientes criterios: Cohesión media Lo será si la descripción es una frase compuesta que contiene comas o más de un verbo. Cohesión secuencial Lo será si la descripción contiene palabras relacionadas con el tiempo como: “primero”, “cuando”, etc. Cohesión lógica Lo será si la descripción no se refiere a algo específico sino a algo más general. Cohesión temporal. Si contiene palabras como “inicializar” o “preparar” será probablemente de tipo temporal. 4.1.2. Comprensibilidad Un módulo debe ser comprensible de forma aislada. Para ello, el factor más importante es el de independencia funcional (acoplamiento débil y cohesión alta). Pero hay otros factores: 1. Identificación Una adecuada utilización de los nombres de los módulos y sus elementos ayuda mucho en su comprensión. 2. Documentación La documentación de cada módulo debe servir para facilitar la comprensión detallando los aspectos de diseño o implementación. Se deben evitar las explicaciones prolijas. 3. Simplicidad Las soluciones sencillas son siempre las mejores. 4.1.3. Adaptabilidad Un sistema es un “traje a medida” que si bien trata de diseñarse de forma que se pueda reutilizar alguna de sus partes, es inevitable que dicho sistema tenga que adaptarse a las imposiciones del cliente. Otros factores que facilitan la adaptabilidad son: 1. Previsión Consiste en hacer un esfuerzo que permita prever las partes que probablemente se verán modificadas en el futuro. P. Ejp. listados, presentaciones en pantalla, podrían agruparse en módulos con un acoplamiento lo más débil posible. 2. Accesibilidad Antes de hacer un cambio es necesario conocer en profundidad la estructura global del sistema. Se pueden utilizar CASE, de forma que se puedan crear prototipos. 3. Consistencia Cuando se realiza una adaptación es necesario cambiar todos los documentos de especificación, diseño e implementación. 4.2. Técnicas de diseño funcional descendente

Apuntes realizados por Antonio Reyes. C.A.Tenerife

16

En estas técnicas se incluyen todas aquellas en las que se atiende fundamentalmente a la función o funciones que ha de realizar el sistema. 4.2.1. Desarrollo por refinamiento progresivo (Wirth) Esta técnica corresponde a la fase de diseño de la metodología de programación estructurada (Dijstra). Dicha metodología recomienda utilizar únicamente las estructuras de control: secuencia, selección e iteración. La técnica de refinamientos consiste en plantear el problema inicial como una operación global e irla descomponiendo poco a poco en función de otras operaciones más sencillas. Esas operaciones constituirán en los pasos finales los módulos parciales que constituirán el sistema. 4.2.2. Programación estructurada de Jackson Esta técnica, que sigue las ideas de la programación estructurada en cuanto a las estructuras (secuencia, selección e iteración) y el método de refinamientos sucesivos, se diferencia de la programación estructurada en que aquí se irá construyendo la estructura del programa de forma similar a cómo se construyen las estructuras de los datos de entrada y salida. Pasos La técnica se basa en los siguientes pasos: 1. Analizar el entorno del problema y describir las estructuras de datos a procesar. 2. Construir la estructura del programa basada en las estructuras de los datos. 3. Definir las tareas a realizar en términos de las operaciones elementales, y situarlas en los módulos apropiados. 4.2.3. Diseño estructurado (Yourdon) Esta técnica consiste en pasar de los DFD a los diagramas de estructura. La dificultad estriba en realizar una jerarquía o estructura de control entre los diferentes módulos, y eso no está descrito en los DFD. Para ello hay que hacer lo que se denomina análisis de flujo de transformación y análisis de flujo de transacción. Ambos análisis se realizan mejor si se modifica la estructura jerárquica de los DFD, construyendo un único diagrama con todos los procesos contenidos en los primeros niveles de descomposición y se prescinde de los almacenes de información. Análisis de flujo de Consiste en identificar un flujo global de información desde los elementos de entrada al transformación sistema hasta los de salida. Se asignan módulos para las operaciones del diagrama y se añaden modulos de coordinación que realizan el control conforme a la distribución del flujo de transformación. Análisis del flujo de Es aplicable cuando el flujo de datos se puede descomponer en varias líneas separadas, transacción correspondiendo cada una de ellas a una función o transacción distinta, activándose según el dato entrado. Hay que identificar el centro de transacción desde el que se ramifican las líneas de flujo. 4.3. Técnicas de diseño basado en abstracciones Estas técnicas surgen cuando se precisan los conceptos de abstracción de datos y de ocultación y la idea consiste en hacer que los módulos se correspondan o bien con funciones o bien con tipos abstractos de datos. 4.3.1. Descomposición modular basada en abstracciones Como técnica de programación, esta técnica consiste en ampliar el lenguaje existente con nuevas operaciones y tipos de datos, definidos por el usuario. Como técnica de diseño consiste en dedicar módulos separados a la realización de cada tipo abstracto de datos y cada función importante. Notación Para la representación de la estructura, se utiliza la notación de diagramas de bloques. Forma descendente En forma descendente, esta técnica se puede considerar como una ampliación de la técnica de refinamiento progresivo, en que al realizar un refinamiento se plantea como alternativa, además de su descomposición, el que la operación a refinar se defina separadamente como abstracción funcional, o bien como operación sobre un tipo abstracto de datos. Forma ascendente En esta forma se trata de ir ampliando las primitivas existentes en el lenguaje de programación y las librerías asociadas con nuevas operaciones y tipos de mayor nivel, más adecuados para el campo de la aplicación que se está diseñando. 4.3.2. Método de Abbott Con el método anterior no se conocen a priori los mejores candidatos para ser considerados como abstracciones. La idea de este método, que se basa en la aplicación del lenguaje natural pero que da mejores resultados con un lenguaje más formal, consiste en identificar en el texto la descripción de las palabras que puedan corresponder a elementos significativos del diseño, como son, tipos de datos (mediante sustantivos genéricos), atributos (mediante sustantivos) y operaciones (mediante verbos o nombre de acciones). Procedimiento Se comienza subrayando los elementos descritos anteriormente y que sean significativos. Se establecen, así, dos listas, una con nombres (datos) y otra con verbos (operaciones). Posteriormente se reorganizan dichas listas extrayendo los posibles tipos de datos, y asociándoles sus atributos y operaciones. En este paso se eliminarán redundancias o términos irrelevantes y se añadirán términos no incluidos inicialmente. 4.4. Técnicas de diseño orientadas a objetos

Apuntes realizados por Antonio Reyes. C.A.Tenerife

17

Las técnicas de diseño orientado a objetos son prácticamente iguales que las basadas en abstracciones. Su casi única diferencia es que en las basadas en objetos existen las características de herencia y polimorfismo. Las diversas metodologías tienen como casi única diferencia la notación utilizada en los diagramas. La idea de estas técnicas consiste en que en la descomposición modular del sistema, cada módulo contenga la descripción de una clase de objetos o de varias clases relacionadas entre sí. La metodología se apoya en diagramas ampliados del modelo de datos. 4.4.1. Diseño orientado a objetos Veremos a continuación una técnica para derivar el diseño partiendo de la especificación del sistema. Se compone de los siguientes pasos: 1. Estudiar y comprender el Aunque se haya realizado en la fase de análisis, puede ocurrir que haya que modificar el problema SRD por imprecisiones o simplemente porque el equipo que desarrolló el SRD es diferente al que hace su diseño. 2. Desarrollar una posible Se tendrá que completar el trabajo hecho en el SRD. Habrá que considerar varias solución alternativas y elegir la más apropiada. Puede ser una descripción informal. 3a. Identificar las clases y Se trata de identificar las clases de objetos y sus atributos. También se definirán las objetos relaciones entre objetos que estén formados por otros objetos. Al final se obtendrá un diagrama inicial del modelo de objetos. Se puede usar la técnica de Abbott. 3b. Identificar las operacio- En este paso hay que identificar las operaciones y lo más complicado: decidir a qué objeto nes sobre los objetos se asocia cada operación. También se puede usar la técnica de Abbott. 3c.Aplicar Herencia Una vez realizado el punto anterior hay que detectar analogías entre los objetos, y establecer las relaciones de herencia apropiadas, reformulando las descripciones de los objetos si fuera necesario. Estas relaciones de herencia se incluirán en el diagrama de objetos que se irá desarrollando. 3d. Describir las Así se verifica que el diseño es consistente. Cada operación se hará en pseudocódigo, operaciones refiriéndose siempre a operaciones o clases de datos definidos en el diseño o predefinidos por el lenguaje de programación. Podría detectarse aquí la necesidad de añadir nuevas clases de objetos o nuevas operaciones. 3e. Establecer la estructura Se asignarán las clases, objetos y operaciones a módulos separados. Se intentará que cada modular módulo corresponda a una clase o, si es muy complicado, ciertas operaciones podrían establecerse en módulos separados. También se pueden agrupar varias clases u objetos relacionados entre sí en un solo módulo. Al final se obtendrá el diagrama de estructura del sistema. 4.5. Técnicas de diseño de datos La información que tendrá que almacenarse se hará probablemente en una base de datos y ésta se puede organizar desde la perspectiva clásica de enfocarla en tres niveles correspondiendo a cada uno de ellos un esquema de organización de los datos desde un punto de vista concreto: 1. Nivel externo Corresponde a la visión del usuario. La organización de los datos se realiza teniendo en cuenta el campo de la aplicación (su terminología, etc.). El esquema de usuario será la ficha del cliente, etc. 2. Nivel conceptual Establece una organización lógica independientemente del sentido en el campo de aplicación. Se resume en un diagrama de modelo de datos o en un diagrama E-R o como diagrama de modelo de objetos. 3. Nivel físico Organiza los datos según el sistema de gestión de base de datos elegido. El esquema físico será la tabla. Saltos entre pasos El salto del nivel externo al conceptual se realiza en la etapa de análisis. El salto del nivel conceptual al nivel físico, en la etapa de diseño. 4.6. Diseño de bases de datos relacionales Partiendo del modelo Entidad-Relación o bien del modelo de Objetos, es posible obtener el esquema de las tablas de una base de datos relacional. Las reglas que hacen esto posible traducen a esquemas de tablas los atributos de las entidades, y las relaciones entre ellas, incluyendo las de composición y herencia entre los objetos. Aspectos de eficacia En el modelo relacional la eficacia se contempla de dos formas: 1ª) forma normal, que evita la existencia de redundancia en los datos, y; 2ª) mediante el empleo de índices para aumentar la velocidad de acceso a los datos. 4.6.1. Formas normales Las formas normales de Codd definen criterios para establecer esquemas de tablas que sean claros y no redundantes, se numeran de menor a mayor nivel de restricción como formas normales 1ª, 2ª, 3ª... 1ª forma normal Una tabla está en la 1ª forma normal cuando la información asociada a cada columna es un valor único, y no una colección de valores en número variable. 2ª forma normal Ocurre cuando la tabla está en la 1ª forma normal y además, hay una clave primaria (una columna o combinación de ellas) que distingue cada fila, y cada casilla que no sea de la clave primaria depende de toda la clave primaria. Es decir, no se cumple cuando existe alguna columna en la tabla que no forma parte de la clave y que no depende de toda la clave sino de otra columna en la tabla (forme parte o no de la clave). Esa columna ha de ser

Apuntes realizados por Antonio Reyes. C.A.Tenerife

18

3ª forma normal

incluida en otra tabla auxiliar cuya clave será la columna de la que depende. Ocurre cuando la tabla está en la 2ª forma normal y además el valor de cada columna que no es clave primaria depende directamente de la clave primaria, es decir, no hay dependencias entre columnas que no son clave primaria.

4.6.2. 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. Las relaciones entre entidades se hacen incluyendo una columna que contenga un código (clave primaria) que identifique cada elemento de datos (fila de la tabla). 4.6.3. Tratamiento de las relaciones de asociación En el modelo E-R las relaciones se consideran relaciones de asociación. Lo que veremos ahora son relaciones binarias entre parejas de entidades. La técnica consiste en traducir la relación a una tabla conteniendo referencias a las tablas de las entidades relacionadas, así como los atributos de la relación, si los hay. Esto vale para cualquier cardinalidad. Relación N-N La referencia a las entidades relacionadas se hará mediante la clave primaria de cada una. Relación 1-N Aquí es posible incluir los datos de la relación en la misma tabla de una de las entidades relacionadas. Relación 1-1 En este caso se pueden fundir las tablas de las dos entidades en una sola. 4.6.4. Tratamiento de las relaciones de composición Las relaciones de composición funcionan de la misma forma que las de asociación, aunque aquí la cardinalidad del lado del objeto compuesto es casi siempre 1. 4.6.5. Tratamiento de la herencia Cuando una clase de objetos (entidad genérica) tiene varias subclases (entidades específicas), la información de las entidades se puede almacenar de tres formas: 1. Se usa una tabla de superclase con los atributos comunes, heredados por las subclases, más una tabla por cada subclase, con sus atributos específicos. 2. Se repiten los atributos comunes en las tablas de cada subclase, despareciendo la tabla de la superclase. 3. Se prescinde de las tablas separadas para cada subclase, y se amplía la tabla de la superclase con todos los atributos de la cada subclase. 4.6.6. Diseño de índices Los índices permiten acceder rápidamente a los datos reduciendo el tiempo de acceso pero el espacio de almacenamiento aumenta, de la misma forma que aumenta el tiempo necesario para almacenar un nuevo dato o, aún más, cambiar uno existente. Hay que mantener índices sobre las claves primarias y columnas de referencia de las entidades relacionadas. 4.7. Diseño de bases de datos de objetos En las bases de datos orientadas a objetos hay una mayor variedad de estructuras disponibles, pero distintas en cada caso. Existen dos enfoques: el primero es apropiado cuando la base de datos de objetos permite utilizar una gran variedad de estructura, en cuyo caso el diseño se puede hacer de la misma forma que para las estructuras de datos en memoria; el segundo enfoque se aplica cuando no existe gran variedad de estructuras de datos, resultando la base de datos de objetos análogo a una base de datos relacional en la que se establece una tabla por cada clase de objetos. Aquí es innecesaria la existencia de columnas explícitas de códigos o referencias pues el sistema de gestión de base de datos lo aporta de forma implícita. 5. CODIFICACIÓN Y PRUEBAS En este tema se repasan las últimas fases del cliclo de vida: codificación, prueba de unidades, fase de integración y pruebas del sistema. 5.1. Codificación del diseño La fase de codificación es el núcleo central de cualquiera de los modelos de desarrollo de software (ciclo de vida, prototipos, espiral,...). En pequeños desarrollos es casi la única actividad que se realiza. La importancia es evidente, pues de esta fase salen los programas fuentes. Un elemento esencial en esta fase es la elección del lenguaje de programación, pues eso impone una determinada forma de trabajo. Es necesario dejar por escrito la metodología de programación que utilizará el equipo (suele ser la misma en c/empresa). Para garantizar una adecuada homogeneidad, se deben establecer normas y estilos de codificación, lo que redundará en un mejor entendimiento, mantenimiento y reutilización. La codificación se debe estructurar para facilitar la depuración y las modificaciones derivadas de las pruebas. 5.2. Lenguajes de programación Los lenguajes de programación son el medio fundamental para realizar la codificación. No existe un único lenguaje ideal para todo y a veces hay que utilizar varios en un proyecto. 5.3. Desarrollo histórico De los cientos de lenguajes existentes, sólo un número relativamente pequeño se utiliza de forma industrial. Es difícil clasificarlos en un grupo concreto. Los lenguajes de las nuevas generaciones coexisten con los de la anterior generación hasta que aquellos se imponen por tener mejores prestaciones. 5.3.1. Primera generación (-1959) Código Máquina La programación se hacía introduciendo unos y ceros directamente en la memoria. Ensamblador Surge como solución a la tediosa tarea de programar en código máquina. El lenguaje

Apuntes realizados por Antonio Reyes. C.A.Tenerife

19

ensamblador asocia a cada instrucción del procesador un nemotécnico. Cada procesador tiene su juego de instrucciones, por lo que es un lenguaje que va asociado a la arquitectura. Hoy en día solo se utiliza cuando hay que hacer alguna operación crítica en tiempo real. 5.3.2. Segunda generación (1960-1970) Se caracterizan por dar respuesta a un aumento de la capacidad de la memoria y los discos. Debido a ese aumento de capacidad, los programas en ensamblador eran más grandes y difíciles de depurar, entender y mantener. Aparecen así, los primeros lenguajes de alto nivel que no dependían de una arquitectura concreta. Aparecen los primeros elementos abstractos, tipos de datos no soportados directamente por las instrucciones de la máquina, se puede trabajar con variables, (olvidando así la gestión directa de memoria) se dispone de las primeras estructura de control. Algunos de ellos son: FORTRAN FORmula TRANslator. Destinado a programar aplicaciones científico-técnicas. Su principal desventaja es que aún maneja directamente la memoria c/la sentencia COMMON. COBOL Destinado a sistemas de procesamiento de información. Aún se utiliza aunque cada vez menos. ALGOL Fue el precursor de lenguajes de 3ª generación como PASCAL, MODULA-2 o ADA. Es el primero que da una gran importancia a los tipos de datos. BASIC Diseñado originalmente para la enseñanza de la programación, tuvo gran éxito. Hoy en día existen innumerables versiones que incorporan infinidad de herramientas. 5.3.3. Tercera generación (1970-198-) A principio de los 70 se consolida las bases de la programación estructurada en la que la programación se concibe como una actividad metódica sin concesión a la genialidad. Facilitan las estructuras de datos y código con redundancia en declaraciones y el uso de cada tipo de dato. Algunos de ellos son (programación imperativa): PASCAL (1971) Fue diseñado para enseñar pero rápidamente tuvo éxito porque permite la estructuración del código mediante procedimientos, que pueden ser recursivos. Los tipos de datos son rígidos y no se contempla de forma apropiada la compilación separada. MODULA-2 Descendiente directo del Pascal, corrige sus deficiencias. Permite desarrollo a gran escala. Incorpora la estructura de módulo quedando separada la especificación y la implementación lo que facilita la compilación segura y permite la ocultación de los detalles de implement. C Aparece en 1975 y se desarrolla en paralelo al Pascal. Se creó para escribir el UNIX. Se utiliza para todo tipo de aplicaciones. Posee características que lo hacen considerar también un lenguaje próximo al ensamblador, lo que si no se utiliza bien puede ser muy peligroso (punteros, matrices). Posee un conjunto de operadores muy potentes que permiten hacer cualquier cosa con los datos. Esto puede hacer difícil la depuración. ADA Fue patrocinado por el Dpto. de Defensa de los EE.UU. Descendiente del Pascal es mucho más potente y complejo. No ha tenido mucha aceptación. Permite el diseño modular y la aplicación de los conceptos de abstracción y ocultación. También permite la definición de elementos genéricos, y tiene mecanismos para la programación concurrente de tareas y la sincronización entre ellas. SMALLTALK Es el precursor de los lenguajes orientados a objetos. C++ Incorpora al lenguaje C los mecanismos de programación orientada a objetos: ocultación, clases, herencia y polimorfismo. EIFFEL Es el intento más serio de hacer un lenguaje de programación orientado a objetos. Permite la definición de clases genéricas, herencia múltiple y polimorfismo. LISP Es un lenguaje funcional. Se utiliza en inteligencia artificial y sistemas expertos. Los datos se forman en listas a las que se les aplica funciones que pueden ser recursivas. Se utiliza también para demostrar teoremas, manipular símbolos, etc. PROLOG Es un lenguaje ‘lógico’ y se usa en sistemas expertos. Se basa en hechos y reglas. 5.3.4. Cuarta generación Los L4G ofrecen al programador un mayor nivel de abstracción. Suelen ser herramientas específicas que permiten a un usuario sin grandes conocimientos, hacer un pequeño sistema. Las aplicaciones complejas desarrolladas con L4G son ineficientes por el código generado, por lo que se utilizan como prototipo para, posteriormente, mejorar con un lenguaje de tercera generación. Se agrupan principalmente en: Bases de Datos Permiten acceder y manipular la información de la base de datos mediante un conjunto de ordenes de petición (Query) relativamente sencillas. Se pueden hacer listados, consultas, cálculos, se pueden seleccionar datos, etc. Generadores de Programas Permiten construir elementos abstractos fundamentales en un cierto campo de aplicación sin descender a detalles concretos. El programa generado se puede modificar y el lenguaje destino suele ser COBOL. Cálculo Son herramientas que han evolucionado hasta el punto de constituir un L4G. Lo son las hojas de cálculo, herramientas de cálculo matemático, de simulación, etc. Otros Lo constituyen las herramientas para la especificación y verificación formal, lenguajes de simulación, etc. 5.4. Prestaciones de los lenguajes

Apuntes realizados por Antonio Reyes. C.A.Tenerife

20

Vamos a dividir las prestaciones de los lenguajes en cuatro apartados para estudiar las estructuras más importantes: 5.4.1. Estructuras de control Se refiere a las instrucciones que se encuadran en la parte ejecutiva de un programa. Las constituyen las estructuras para el manejo de excepciones, para la programación concurrente, y para la programación estructurada. 5.4.1.1. Programación estructurada Cualquier lenguaje imperativo dispone ya de sentencias que permiten la programación estructurada. En concreto disponen de sentencias que permiten programar: Secuencia; Selección (If.. Then..Else..End); Iteración (While...Do). Lenguaje más rico El lenguaje debe ser más rico y deberá admitir sentencias de selección como (If-then-elsifthen-else) o (Case-of), o sentencias de iteración como: Repetición (Repeat – until); Bucle con contador (For – to – do); Bucle indefinido (Loop – Exit). Procedimientos La creación de subprogramas mediante procedimientos o funciones es otra de las características de que disponen los lenguajes. Las llamadas podrán ser recursivas. 5.4.1.2. Manejo de excepciones Excepción Lo constituye un error o suceso inusual que puede ser causado por un fallo humano, de software o de hardware. Pueden ser entradas vacías, valores fuera de rango, etc. Errores humanos Si bien los datos se pueden validar por separado, en su conjunto podrían ser erróneos, p.ejp. cuando el operador introduce un cero que se utilizará como divisor en una división. Fallos hardware Los fallos de los periféricos pueden dar lugar a datos erróneos. Errores software Son errores no detectados en la fase de pruebas. Datos de entrada vacíos P. ejp. un vector vacío. Valores fuera de rango Se trata de operaciones como una división por cero o la raíz cuadrada de un nº negativo. Los errores anteriores pueden ser detectados por el sistema operativo y abortar la ejecución del programa pero esto es inaceptable en ciertos sistemas. Manejo de excepciones Es la transferencia de control que contemplan ciertos lenguajes en el que se desvía automáticamente la ejecución hacia un fragmento de código apropiado cuando ocurre una situación anormal. 5.4.1.3. Concurrencia Muchos lenguajes han sistematizado estructuras de control que permiten controlar la concurrencia, en concreto permiten controlar: a) Las tareas que deben ejecutarse concurrentemente; b) Sincronización de tareas; c) Comunicación entre tareas. Sin embargo el control de los interbloqueos es un problema que debe estudiarse en cada caso particular. Existen diversas formas en que los lenguajes controlan las tareas concurrentes: Corrutinas No son tareas sino que tienen una estructura semejante a subprogramas pudiéndose transferir el control entre ellas sin tener la obligación de respetar la jerarquía. Modula-2. Fork-join Una tarea puede arrancar la ejecución concurrente de otras mediante una orden fork que finaliza con un join invocado por la misma tarea que ejecutó el fork y con el que ambas tareas se funden de nuevo en una única. La usan UNIX y PL-1. Cobegin-Coend Todas las tareas a ejecutarse de forma concurrente se declaran en una construcción cobegin T1 | T2 | Tn coend. Al alcanzar la orden cobegin se inicia la ejecución de todas las tareas T1..Tn. La finalización de la concurrencia exige que todas las tareas hayan acabado. Algol. Procesos Cada tarea se declara como un proceso. Todos ellos se ejecutan concurrentemente desde que comienza el programa no siendo posible iniciar la ejecución de uno nuevo. La usa Pascal y Ada, sólo que en Ada se puede lanzar un proceso dinámicamente en cualquier instante. Estructuras de control de En los lenguajes, son las que permiten lograr la sicncronización y la cooperación entre las sincronizaciones tareas. Se clasifican en dos grupos: Variables compartidas Lo constituyen los semáforos, regiones críticas condicionales y los monitores. Todas las tareas hen de ejecutarse en el mismo computador (multiprogramación) o al menos que tengan memoria compartida (multiproceso). Paso de mensajes Lo constituyen el “Communicating Sequential Processes” (CSP), Llamada a procedimientos remotos y el “Rendezvous” de Ada. Se pueden usar en computadores que no tienen ninguna memoria común (procesos distribuidos) y que están conectados en una red que permite el paso de mensajes. Problemas con semáforos Los semáforos, como estructuras de bajo nivel que son, han de ser utilizados correctamente. La utilización incorrecta de los semáforos provoca errores díficiles de detectar y depurar. Algunos de esos errores son: a) usar un recurso sin realizar el P(sincro); b) se puede bloquear un recurso si no se libera con el V(sincro); c) Es fácil equivocarse e invertir las instrucciones (P en vez de V, y viceversa); d) no se distingue un semáforo para sincronizar de otro para cooperar. 5.4.2. Estructuras de datos 5.4.2.1. Datos simples Rangos Todos los lenguajes permiten declarar valores de tipo entero o real, pero no todos tienen el mismo rango, existiendo rangos denominados normal, corto, largo, etc.

Apuntes realizados por Antonio Reyes. C.A.Tenerife

21

Strings Tipos enumerados Tipos subrango 5.4.2.2. Datos compuestos Datos compuestos Vectores o arrays Datos compuestos (tupla)

Igualmente, en todos los lenguajes existe el tipo ‘ristra de caracteres’ pero su organización y forma de operación suele ser diferente en cada lenguaje. P.ejp. Type Color=(Rojo, Amarillo, Verde). Cada color se puede sustituir por un nº entero que comienza por 0. También es enumerado el tipo lógico booleano. Permiten acotar el rango de un tipo de dato ordinal, p.ejp. Type diasmes= [1..31] Son combinaciones de datos simples y compuestos y se permiten en todos los lenguajes. Hay que conocer la sintaxis y semántica de cada lenguaje. En casi todos los lenguajes se utiliza la estructura registro: Type Circulo = Record CentroX, CentroY: Real; Radio: Integer; End; Lo permiten los derivados del Pascal. Type Mezcla = Set of Color;

Tipo conjunto 5.4.2.3. Constantes Constantes literales Son las que se representan directamente por su valor numérico o de caracteres. Constantes con nombre Son constantes simbólicas con nombre. Hay lenguajes, como Modula-2, en los que no se pueden declarar constantes de tipos estructurado: formación o registro. 5.4.2.4. Comprobación de tipos Las operaciones que se pueden realizar con los datos en un programa dependen del nivel de comprobación de tipos que permita el lenguaje utilizado. Existen 5 niveles Nivel 0: Sin tipos En estos lenguajes sólo existen tipos predefinidos (Basic, Cobol, Lisp, Apl). En ellos el compilador no realiza ninguna comprobación de tipos siendo responsabilidad del programador. Nivel 1: Tipado automático En estos lenguajes (PL1) el compilador decide cual es el tipo más adecuado para cada dato. También tiene en cuenta las operaciones que intervienen con los datos convirtiéndolas a su tipo correspondiente. Nivel 2: Tipado débil En este nivel también se realiza un tipado automático pero entre datos que poseen ciertas similitudes (p.ejp. entero a real). Fortran. Cuando se llama a subprogramas no se comprueban ni el nº ni el tipo de los argumentos. Nivel 3: Tipado semirrígido En este nivel (Pascal) todos los datos a usar han de ser declarados con sus tipos. Los tipos declarados por separado e idéntica estructura son incompatibles no admitiéndose operaciones entre ellos. En las llamadas a procedimientos se comprueba el nº de argumentos y el tipo de cada uno de ellos. Existe una vía de escape ya que no se comprueban los tipos de los argumentos de aquellas funciones o procedimientos que son pasados a su vez como argumentos de otros procedimientos. Nivel 4: Tipado fuerte En este nivel no existe ninguna escapatoria estando obligado el programador a hacer explícita cualquier conversión de tipo que necesite realizar. Se comprueba en compilación, carga y ejecución. Pertenecen a este nivel Ada y Modula-2. 5.4.3. Abstracciones y objetos 5.4.3.1. Abstracciones funcionales Todos los lenguajes permiten hacer abstracciones funcionales. Los nombres que reciben, subprogramas, subrutinas, procedimientos o funciones, dependen del lenguaje. Todos se definen por un nombre y una interfaz teniendo que codificar la operación que en algunos lenguajes se puede ocultar. 5.4.3.2. Tipos abstractos de datos Para codificar un t.a.d. se debe agrupar en una única entidad el contenido o atributos de los datos de la abstracción y las operaciones definidas para su manejo. Además debe existir un mecanismo de ocultación que impida el acceso al contenido por una vía diferente a las operaciones definidas. Modula-2 dispone para ello de la estructura MODULE en la que se puede definir de forma separada el contenido y operaciones de un tipo abstracto (Definition Module). Por otro lado las operaciones permanecerán ocultas (Implementation Module). 5.4.3.3. Objetos Modula-2 no dispone de mecanismos de herencia o polimorfismo. El lenguaje Ada permite la herencia pero no el polimorfismo. Tan sólo los lenguajes orientados a objetos (Objective C, C++, Eiffel, Object Pascal, Smalltalk) permiten la herencia simple o múltiple y polimorfismo. 5.4.4. Modularidad Compilación separada Es la primera cualidad que se exige a la hora de desarrollar un proyecto importante en el que trabaja un equipo de personas. Compilación segura Se produce cuando es posible comprobar en tiempo de compilación que el uso de un elemento es consistente con su definición. Fortran y Pascal no utilizan compilación segura. Sin embargo en Modula-2 la compilación es completamente segura. Ada también tiene compilación segura mediante sus package y sus package body (definición e implementación). 5.5. Criterios de selección del lenguaje

Apuntes realizados por Antonio Reyes. C.A.Tenerife

22

Es uno de los elementos más importantes de cualquier desarrollo por el nº de personas que lo utilizarán, sin embargo, existen otros criterios de selección, aparte de los técnicos que hay que considerar: Imposición del cliente P. ejp. el Dpto. de Defensa de EEUU ha impuesto Ada para reducir costes de mantenimiento. Tipo de aplicación Cada vez existen lenguajes más especializados en un campo concreto. En general se usa: • Ensamblador en aplicaciones de tiempo real muy críticas. • Cobol, en aplicaciones de gestión, aunque cada vez menos. • Fortran o C, en aplicaciones técnico/científicas. • C, Modula-2 o Ada, en aplicaciones de sistemas y tiempo real. • Lisp y Prolog, en aplicaciones de inteligencia artificial. Disponiblidad y entorno Se refiere a la disponibilidad del compilador para el computador elegido pues no existen compiladores para todos los computadores. Por otro lado, hay que tener en cuenta el entorno del compilador (herramientas, editor, montador de enlaces, depurador, control de versiones, etc.). Experiencia previa Normalmente una empresa no cambia de lenguaje, pues la experiencia adquirida con el lenguaje elegido hace aumentar el rendimiento. Reusabilidad Hay que conocer bien las librerías disponibles por lo que hay que tener herramientas dentro del entorno del lenguaje para organizar dichas librerías. Transportabilidad El lenguaje elegido ha de ser transportable a otros computadores. Uso de varios lenguajes La utilización de varios lenguajes en un proyecto debe estar convenientemente justificada. 5.6. Aspectos metodológicos 5.6.1. Normas y estilo de codificación Al inicio de la fase de codificación de un proyecto es necesario fijar unas normas que habitualmente serán las mismas que se use con generalidad en la empresa, y que deben ser adoptadas y respetadas por todos los participantes en el proyecto. Estilo • Formato y contenido de las cabeceras de cada módulo. Deben contener: identificación del módulo, descripción del módulo, autor y fecha, revisiones y fechas de revisión. • Formato y contenido para cada tipo de comentario. Sección, orden, al margen. • Utilización de encolumnado. Tabulador, máximo indentado, formato selección, iteración. • Elección de nombres. Convenio para el uso de mayúsculas y minúsculas, nombres de ficheros, identificadores de elementos del programa. Restricciones • Tamaño máximo de subrutinas (n páginas). • Las subrutinas tendrán como máximo n argumentos. • Evitar el anidamiento de sentencias IF. Restricciones de lenguaje • Evitar el uso de sentencias goto. 5.6.2. Manejo de errores Defecto Son erratas o gazapos de software. Pueden permanecer ocultos hasta que los elementos defectuosos se ejecuten. Fallo Es el hecho de que un elemento del programa no funcione correctamente, produciendo un resultado erróneo. Error Es un estado inadmisible de un programa al que se llega como consecuencia de un fallo. Puede ser la salida o almacenamiento de datos erróneos. En la fase de codificación se pueden adoptar diferentes actitudes respecto al tratamiento de los fallos: No considerar los errores Mediante esta actitud se declina toda responsabilidad si se produce algún error. Es la más cómoda desde el punto de vista de la codificación pero es poco realista no pudiéndose garantizar el resultado correcto del programa. Prevención de errores Se basa en la llamada programación a la defensiva “defensive programming” y consiste en que se desconfía sistemáticamente de los datos o argumentos que se introducen. Siempre devolverá: a) el resultado correcto, si los datos son válidos, o; b) una indicación precisa del fallo, si los datos son válidos. Hay que considerar que se trata de detectar un fallo y evitar que se produzcan y propaguen errores. Esto facilita el diagnóstico de defectos. Recuperación de errores Se produce cuando no se puede detectar un fallo y consiste en tratar el error con el fin de restaurar el programa en un estado correcto y evitar que el error se propague. Consta de dos fases: 1) Detección del error, en la que se concretarán las situaciones que se consideran erróneas y dónde realizar comprobaciones estratégicas, y; 2) Recuperación del error, en la que se decidirán que decisiones se adoptarán para corregir el estado del programa y llevarlo a una situación consistente. A su vez, la recuperación se puede hacer de dos formas: a) hacia delante, que trata de identificar la naturaleza o tipo del error (fuera de rango, etc.) y tomar las medidas para su corrección mediante el mecanismo de excepciones, y; b) hacia atrás, en el que el estado del programa se trata de corregir restaurándolo a un estado

Apuntes realizados por Antonio Reyes. C.A.Tenerife

23

correcto anterior a la aparición del error. Esto exige guardar periódicamente el último estado correcto. De esta forma se partirá de ese último estado para obtener otro nuevo estado. Si éste nuevo estado es correcto, la operación termina bien, de lo contrario se restaura un estado anterior y se realizará la operación por un camino diferente del algoritmo. Este esquema se utiliza en sistemas basados en transacciones (b.d., bancos) en el que una operación puede terminar con éxito, modificando el estado del sistema (“commit”), o con fallo, en cuyo caso la transacción se aborta (“abort”) y se restaura el estado anterior, con lo que la operación no produce ningún efecto. a Son aquellos que realizan una previsión o recuperación de errores.

Programas tolerantes fallos 5.6.3. Aspectos de eficiencia En la actualidad no existe prácticamente ningún caso en que haya que sacrificar la claridad en la codificación por una mayor eficiencia. La eficiencia se puede medir de dos formas: eficiencia en memoria y eficiencia en tiempo. Eficiencia en memoria Se puede mejorar utilizando un compilador que disponga de compresión por memoria. También se puede optimizar el algoritmo que utilice la memoria. Eficiencia en tiempo Es muy importante en sistemas de tiempo real con plazos críticos. En muchas ocasiones se puede aumentar la eficiencia en tiempo a costa de la eficiencia en memoria, consiste pues, en almacenar o tabular datos intermedios en memoria y consultarlos. Técnicas que permiten el ahorro son: • Tabular los cálculos complejos (almacenarlos par su consulta). • Expansión en línea. Macros en vez de subrutinas (ahorran la llamada, argumentos, etc.) • Desplegado de bucles. La evaluación de la condición del bucle se realiza una vez por lo que si el código se repite varias veces, se ahorra tiempo. • Simplificar expresiones aritméticas y lógicas. • Sacar fuera de los bucles todo lo que no sea necesario repetir. • Utilizar estructuras de acceso rápido (vectores en lugar de listas con encadenamiento). • Evitar la utilización de coma flotante, usar coma fija. • Evitar las conversiones innecesarias de tipos de datos. 5.6.4. Transportabilidad de software La realización de un programa transportable implica un esfuerzo adicional que se ve recompensado a corto, medio y largo plazo. Los factores esenciales de la transportabilidad son los siguientes: Utilización de estándares Un producto software desarrollado exclusivamente sobre elementos estándares es en teoría transportable sin ningún cambio, entre plataformas que cuenten con el soporte apropiado para dichos estándares. Si los estándares no estuvieran disponibles se deberían utilizar lenguajes, compiladores y herramientas que se puedan considerar estándares ‘de facto’. Aislar las peculiaridades Consiste en destinar un módulo específico para cada peculiaridad que será reprogramada en la nueva plataforma. Algunas de dichas peculiaridades están vinculadas a: Arquitectura del La arquitectura del computador determina la longitud de palabra (8, 16, 32 o 64 bits) y de computador esto se derivan la representación interna de los valores enteros o reales. Ello implica que podrían haber desbordamientos de los rangos lo que a su vez conlleva a tener que definir tipos abstractos para representar números, lo que significaría una disminución importante del rendimiento. Otro problema es la tabla de representación de caracteres. Casi siempre está basada en el código ASCII, pero hay que cerciorarse. Sistema Operativo Todos los sistemas operativos ofrecen servicios para acceder a ficheros, teclado, librerías, etc. El lenguaje accede a estos servicios mediante el sistema operativo, en concreto mediante procedimientos o funciones predefinidos para ello. Sin embargo, algunos compiladores en otra plataforma pueden tener funciones o procedimientos diferentes. Esto hace que las especificaciones y las interfaces de dichos procedimientos tengan que estar en módulos separados. 5.7. Técnicas de prueba de unidades Antes de entregar al cliente el producto software ha tenido que haberse probado todo el sistema. La forma mejor de probar un proyecto es realizar pruebas a cada unidad o módulo según se avanza en la codificación del proyecto. Esto facilitará las posteriores pruebas de integración entre módulos y las pruebas del sistema global. 5.7.1. Objetivos de las pruebas de software El objetivo de las pruebas de software es conseguir que el programa funcione de forma incorrecta con el fin de descubrir sus defectos. Casos de prueba Es el juego de pruebas al que se someterá el programa. Se debe tener en cuenta: • Una buena prueba es la que encuentra errores y no los encubre • Para detectar un error es necesario conocer cuál es el resultado correcto • Es bueno que no participen en la prueba el codificador y el diseñador • Siempre hay errores, y si no aparecen se deben diseñar pruebas mejores

Apuntes realizados por Antonio Reyes. C.A.Tenerife

24

• Al corregir un error se pueden producir otros nuevos • Es imposible demostrar la ausencia de defectos mediante pruebas Con las pruebas se explora una parte de todas las posibilidades del programa. Se trata de alcanzar un compromiso para que con el menor esfuerzo posible se puedan detectar el máximo nº de defectos. Es importante que el proceso de prueba se realice de la forma lo más automática posible con el fin de que una vez detectados y corregidos los defectos se pueda volver a realizar el proceso de prueba y ver si los cambios corrigieron el defecto. Las pruebas han de realizarse en un entorno de ejecución controlado y deben proporcionar, al menos, un informe con los resultados de las pruebas y un registro de todos los errores detectados con su discrepancia respecto al valor esperado. 5.7.2. Pruebas de caja negra (black box) Es la estrategia que debe adoptar el cliente y consiste en ignorar la estructura interna del programa centrándose exclusivamente en la comprobación de la especificación entrada-salida del software. Debe verificar todos los requisitos impuestos al programa. La elaboración del juego de prueba es muy importante, debiendo acudir a la experiencia del programador para indicar los módulos sospechosos. Algunos métodos para la elaboración de los casos de prueba son: Partición en clases de Consiste en dividir el espacio de ejecución equivalencia del programa en varios subespacios o clases equivalentes. Cada uno de ellos agrupa a todos aquellos datos de entrada al módulo que resultan equivalentes desde el punto de vista de la prueba de caja negra. El método se realiza en varios pasos: Pasos : 1. 2. 3.

Determinar las clases equivalentes apropiadas. Definir una prueba que cubra tantos casos válidos como sea posible de cualquier clase. Marcar las clases cubiertas y repetir el paso anterior hasta cubrir todos los casos válidos de todas las clases. 4. Definir una prueba específica para cada caso inválido. Como ejemplo se contempla: a) Rango de valores: contemplar uno válido, uno menor que el mínimo y uno mayor que el máximo; b) Valor específico: contemplar uno válido y otro inválido; c) Conjunto de valores, contemplar uno por elemento y uno fuera del conjunto. Análisis de valores límite Este método se utiliza cuando los programas se codifican con una perspectiva general y (boundary analysis) luego son modificardos para adaptarlos a casos especiales. Es en la frontera de estos casos donde con mayor frecuencia se registran los fallos. Este método hace hicapié en el espacio de ejecución próximo al borde y también debe proponer datos válidos e inválidos en la prueba. Pasos: Los pasos a seguir con este método son: 1. Entradas. Probar con los mismos valores límite y justo fuera de límites. 2. Salidas. Probar con los mismos valores límite y justo fuera de límites. Ejp. 70 lpp. 3. Memoria. Probar con tamaños nulos, límite, y superior al límite de todas las estructuras de información. 4. Recursos. Probar con ningún recurso, límite de recursos y superior al límite. 5. Pensar en otras situaciones límite y establecer las pruebas. Comparación de versiones En módulos críticos se puede hacer un desarrollo multi-versión (N-version) que consiste en que la codificación del módulo la realicen diferentes programadores. Cada versión obtenida será sometida al mismo juego de pruebas. Cuando todas las versiones produzcan los mismos resultados se podrá utilizar cualquiera de ellas. Por el contrario si existen diferencias en los resultados habrá que ver cual es el defecto que las ocasiona. Empleo de la intuición Es conveniente disponer de cierto tiempo para pensar en los estados que podrían provocar un error. También es importante, contar con gente ajena al proyecto que pueda aportar una perspectiva más fresca. 5.7.3. Pruebas de caja transparente (white box, clear box o glass box) Este método, que debe ser complementario con el de caja negra, debe ser propuesto por alguien que haya participado en la codificación y consiste en elaborar los casos de prueba teniendo en cuenta la estructura interna del programa, es decir, el programa debe transitar por todos los posibles caminos de ejcución, en particular, debe conseguir: que todas las decisiones se ejecuten en uno u otro sentido; que todos los bucles se ejecuten en los supuestos más diversos posibles, y; que todas las estructuras de datos se modifiquen y consulten alguna vez. Algunos de estos métodos son: Cubrimiento lógico Ya que resulta imposible cubrir todas las formas posibles de un programa, se puede intentar cubrir al menos un camino básico. Para hacer más fácil este cubrimiento se debe hacer un diagrama de flujo en el que cada rombo, correspondiente a una selección, representará la evaluación de un predicado simple (sin AND ni OR). El nº de caminos posibles será igual al nº de predicados más uno. Se pueden establecer ciertos niveles de cubrimiento: Nivel I. Se trata de elaborar casos de pruebas para que se ejecuten al menos una vez todos

Apuntes realizados por Antonio Reyes. C.A.Tenerife

25

los caminos básicos, cada uno de ellos por separado. Nivel II. Se trata de elaborar casos de prueba para que se ejecuten todas las combinaciones de caminos básicos por parejas. Las pruebas de cada módulo deben garantizar al menos el nivel I. Ello aseguraría al menos el 50% de los errores. Nunca se puede detectar cuando falta un fragmento de código. Prueba de bucles Existen varias situaciones: • Bucle con nº no acotado de repeticiones. Se harán pruebas para 0, 1, 2, un nº moderado y un nº elevado de veces. • Bucle con nº máximo de repeticiones. Se harán pruebas para 0, 1, 2, un nº intermedio, M-1, M y M+1 veces. • Bucles anidados. Se hará: 1) Ejecutar el bucle externo un nº mínimo de veces para probar el bucle interno; 2) Para el siguiente nivel de anidamiento, ejecutar los bucles externos en su nº mínimo de veces y los bucles internos un nº típico de veces con el algoritmo que le corresponda; 3) Repetir el paso 2 hasta completar todos los niveles. • Bucles concatenados. Estudiar cada caso. Empleo de la intuición La estrategia de caja transparente también hace rentable el pararse a pensar en pruebas en las que podría salir un defecto. 5.7.4. Estimación de errores no detectados Las pruebas no garantizan que un programa no tenga defectos. Se puede hacer una estimación de los errores según se describe a continuación: Estimación de errores 1. Anotar el nº de errores producidos inicialmente con el juego de pruebas. EI. 2. Corregir el módulo hasta que no salga ningún error con el mismo juego de pruebas. 3. Introducir aleatoriamente en el módulo un nº razonable de errores. EA. 4. Someter el módulo al juego de pruebas y recontar los errores detectados. ED. 5. Para el juego de pruebas el nº estimado de errores sin detectar será: EE = (EA – ED) * (EI – ED) 5.8. Estrategias de integración Los módulos de un producto software se han de integrar para conformar el sistema completo. Pueden aparecer errores en la interfaz, imprecisiones acumuladas, etc. Para corregir todos estos errores existen varias estrategias: 5.8.1. Integración Big Bang Consiste en realizar la integración de todos los módulos en un único paso. Es imposible de utilizar en proyectos grandes. 5.8.2. Integración descendente Con esta estrategia se parte de un módulo principal que se prueba con módulos de “andamiaje” o sustitutos “stubs” de los otros módulos usados directamente. Los módulos sustitutos se van reemplazando por los verdaderos y se realizan las pruebas de integración correspondientes. La codificación de los sustitutos se puede hacer de varias formas: no hacer nada y que sólo sirva para comprobar la interfaz; imprimir un mensaje de seguimiento con información de la llamada; suministrar un resultado fijo; suministrar un resultado aleatorio. Ventajas Desde el inicio se ven las posibilidades de la aplicación. Permite demostraciones al cliente. Desventajas Limita en cierta forma el trabajo en paralelo. Al conducir la integración de los nuevos módulos desde otros ya integrados se tienen bastantes limitaciones para hacer pruebas especiales. 5.8.3. Integración ascendente Con esta estrategia se comienza por codificar los módulos de un nivel más bajo. Luego se escriben los módulos gestores “drivers” que los hacen funcionar o en combinaciones sencillas. Los gestores se van sustituyendo posteriormente uno a uno por los módulos de mayor nivel según se codifiquen. Al final se obtendrá el sistema completo. Ventajas Facilita el trabajo en paralelo y facilita el ensayo de situaciones especiales. Desventajas Resulta difícil ensayar el funcionamiento global. Integración sandwich Es la mejor solución y consiste en utilizar una integración ascendente con los módulos de nivel más bajo y una integración descendente con los módulos de nivel más alto. 5.9. Pruebas de sistema Una vez finalizada la integración hay que probar el sistema completo. Se suele aplicar aquí una estrategia de caja negra. 5.9.1. Objetivos de las pruebas Clases de pruebas Existen diferentes clases de pruebas: • Pruebas de recuperación. Permite comprobar la capacidad del sistema para recuperarse ante fallos. Debe comprobar si el sistema lo detecta y/o lo corrige. • Pruebas de seguridad. Comprueba los mecanismos de protección contra accesos no autorizados. • Pruebas de resistencia. Debe comprobarse el sistema cuando éste se ve forzado por encima de su capacidad. • Pruebas de sensibilidad. Cómo responde el sistema ante algoritmos matemáticos. • Prueba de rendimiento. Comprueba las prestaciones del sistema que son críticas en

Apuntes realizados por Antonio Reyes. C.A.Tenerife

26

tiempo. 5.9.2. Pruebas alfa y beta Son pruebas en las que participan los usuarios. Permiten detectar fallos del tipo: mensajes ininteligibles para el usuario; deficiencias en el manual de usuario; procedimientos de operación inusuales, etc. Pruebas alfa Son aquellas (las primeras) que se realizan en un entorno controlado donde el usuario tiene el apoyo de alguna persona del equipo de desarrollo y a su vez esta misma persona puede seguir muy de cerca la evolución de las pruebas. Pruebas beta Con estas pruebas, uno o varios usuarios trabajan en un entorno normal y anotan cualquier anomalía. Deben advertir al equipo de programadores cuál fue el procedimiento que le llevó al error. 6. AUTOMATIZACIÓN DEL PROCESO DE DESARROLLO Este tema se dedica a analizar los elementos de soporte informático del proceso de desarrollo (herramientas CASE). 6.1. Entornos de desarrollo software Entorno (environment) Con la palabra entorno se designa el contexto en el que se realiza una actividad, y en particular para designar la combinación de instrumentos disponibles para ello. Hay que hacer especial hincapié en que el entorno engloba todos esos instrumentos de una forma coherente por lo que parece más una herramienta global que una colección de herramientas. SEE Un entorno de desarrollo de software (Software Engineering Environment) es un conjunto de elementos informáticos que permiten facilitar el desarrollo. Dichas técnicas de soporte informático se designan con CASE (Computer Aided Software Engineering). Diversos enfoques En los últimos años han aparecido diversos enfoques en el desarrollo de productos CASE que a veces provoca cierta confusión. 6.2. Panorámica de las técnicas CASE 6.2.1. Soporte de las fases de desarrollo Lo que hoy denominamos entorno fue evolucionando desde las fases centrales del ciclo de vida hasta sus extremos. Dicha evolución ha ido pareja con la evolución de los lenguajes. Un entorno de programación clásico consta de un compilador, un editor de texto y un montador de enlace. Alternativamente existen los intérpretes que en una sola herramienta constaba con funciones de edición y ejecución. La aparición de las herramientas CASE dieron soporte a las metodologías de análisis y diseño. Para la fase de pruebas existen herramientas que permiten ejecutar programas de prueba. Para la fase de mantenimiento también hay herramientas que admiten la gestión de versiones y el control de cambios. En la actualidad no existe una técnica CASE que controle el ciclo de vida completo, aunque ya se han establecido esquemas generales para integrar diversos elementos en un entorno común constituyendo lo que se denomina IPSE o ICASE. IPSE Integrated Project Software Engineering ICASE Integrated CASE 6.2.2. Formas de organización Entorno de desarrollo Un entorno de desarrollo de software es una combinación de elementos que automatizan una variedad mayor o menor de funciones. Estos entornos se pueden organizar de varias formas. Una de ellas consiste en que el resultado de un elemento sea la entrada del siguiente (cadenas de trabajos), p.ejp. editor-compilador-montador. Otra forma consiste en disponer de un almacén, denominado repositorio, en el que toda la información se guarda en un formato común, de forma que esté disponible para cualquier herramienta (esta es la forma en que se suelen organizar las herramientas CASE en el que los propios datos se utilizan para roturar las flechas de los diagramas, etc.). 6.2.3. Objetivo de un entorno de desarrollo La enorme cantidad de herramientas existentes en la actualidad hace que sea difícil su clasificación debido a los diferentes objetivos para los cuales se diseñaron. Uno de los objetivos parciales de los entornos es dar soporte a la programación en un lenguaje concreto, de hecho ha habido casos en que el entorno es tan importante como el lenguaje (Smalltalk y Ada). Otro objetivo consiste en dar soporte a una metodología de desarrollo concreta (CASE). Otros entornos se centran en la planificación y control del proceso de desarrollo de trabajo. 6.3. Una clasificación pragmática Se presenta a continuación una clasificación de entornos, poco formal, pragmática, en la que tenemos: entornos asociados a un lenguaje, entornos orientados a estructura, entornos basados en herramienta, entornos asociados a una metodología,y, entornos de 4ª generación. 6.3.1. Entornos asociados a un lenguaje Los primeros entornos asociados a un lenguaje lo constituyeron los intérpretes de LISP o BASIC. Estos intérpretes permiten modificar, ejecutar, y depurar los programas. Algunos como LISP permiten realizar cambios en variables, ver los valores, parar la ejecución, ver historial de órdenes, etc. Existen dos lenguajes dignos de mencionar: Smalltalk Un caso especial es el del lenguaje Smalltalk (primer lenguaje orientado a objetos), en el que el programa no constituye un elemento separado del entorno de desarrollo sino que se materializa como una versión modificada del propio entorno, es decir, se pueden utilizar todos los elementos existentes en el entorno, como estructuras, definiciones de clases, objetos, etc. y utilizarlos como propios.

Apuntes realizados por Antonio Reyes. C.A.Tenerife

27

Ada

Con el lenguaje Ada se ha definido el lenguaje en sí y la arquitectura y funciones elementales de los entornos de programación (el entorno se llama Stoneman). Dispone de: • KAPSE (Kernel Ada Program Support Environment) que es el núcleo base y debe estar disponible en cualquier sistema. En la actualidad está disponible de una serie de funciones denominadas CASI (Common APSE Interface Set). • MAPSE (Minimal Ada Program Support Environment) que es una serie de herramientas: editor, compilador, montador, etc. • APSE (Ada Programming Support Environment) que constituye el sistema completo. 6.3.2. Entornos orientados a estructura En estos sistemas el código del programa se guarda de forma estructurada de forma que no se modificará como un simple texto sino que se guardará su equivalente como árbol de sintaxis abstracta (AST: Abstract Syntax Tree) lo que permite operar con su estructura directamente. Algunas de estas técnicas han sido desarrolladas para el lenguaje PL/1 (Program Synthesizer y su evolucionado Synthesizer Generator) que basado en plantillas permite modificar la estructura codificada del programa. 6.3.3. Entornos basados en herramientas Son una serie de herramientas (toolkit o toolbox) más o menos independientes que son compatibles entre sí y que funcionan de forma combinada. Un buen ejemplo lo tenemos en Unix que dispone de las utilidades cc (compilador/montador), vi (editor de textos), ar (gestor de librerías), cdb (depurador simbólico), etc., además dispone de otras herramientas para tratar ficheros de texto. El sistema operativo dispone de mecanismos para combinar todas esas utilidades, en particular una de las más flexibles la constituye el ‘shell’ o intérprete de órdenes. Este tipo de entornos tiene la ventaja de que son bastante abiertos lo que permite la incorporación de nuevas herramientas. 6.3.4. Entornos asociados a metodología Una de las ventajas de utilizar herramientas CASE es que constituyen entornos de trabajo bien integrados y con una interfaz de usuario uniforme. Dicha integración se consigue con la utilización de un repositorio CASE. 6.3.5. Entornos de 4ª generación La mayoría de estos entornos, que están orientados al usuario final, consiste en un sistema de gestión de bases de datos dotado de un lenguaje de consulta, al que se añaden algunas herramientas complementarias. Muchos de estos entornos se pueden considerar como entornos de programación visuales. 6.4. Una clasificación por niveles Otro criterio de clasificación de las herramientas CASE es hacerlo por las funciones realizadas. Con esta clasificación se utiliza un criterio base que es el nivel de funcionalidad del producto CASE: Nivel de servicio Corresponde a un producto que realiza una operación de forma automática y sin interrupción, p. Ejp. la compilación de un programa fuente. Nivel de herramienta Corresponde a un producto que permite invocar diferentes servicios u operaciones en una misma actividad dentro del proceso de desarrollo, p. Ejp. un editor (de texto, diagrama). Nivel de banco de trabajo También llamado ‘Workbench’, ‘Toolkit’ o ‘Toolbox’ corresponde a un producto CASE que soporta un perfil concreto de actividad profesional dentro del proceso de desarrollo, p. Ejp. la actividad del analista. Cuando se trata de la actividad de programación hablamos de entorno de programación. Nivel de entorno de Corresponde a un producto CASE que soporta el proceso completo de desarrollo de desarrollo software. Son las IPSE o ICASE. 6.5. Herramientas de software 6.5.1. Herramientas clásicas Editor de texto Permite editar ficheros de texto formado por líneas y caracteres. No atiende a su contenido. Compilador Traduce un fichero de texto fuente a otro de código objeto reubicable, no ejecutable. Montador de enlaces También llamado linker permite construir un programa ejecutable combinando varios ficheros objeto. Maneja librerías de funciones invocadas en los programas. Gestor de librería Permite combinar varios ficheros objetos en una librería única. Herramienta “Make” Permite automatizar la actualización de un conjunto de ficheros a partir de otros. Utiliza un fichero de dependencias en el que se indica de qué ficheros depende uno dado. Intérprete interactivo Engloba funciones equivalentes a las de edición, compilación, montaje y ejecución. Compilador/Intérprete Es un procesador de lenguaje interpretado en forma no interactiva. Depurador absoluto Permite ejecutar un programa instrucción por instrucción de forma controlada. Permite cambiar cualquier dato en memoria de forma directa. Es incómodo de utilizar. Depurador simbólico Idem. Anterior pero trabajando con el código fuente por lo que es más cómodo. Se accede a las variables simbólicas. 6.5.2. Herramientas evolucionadas Editores orientados a lenguaje Suelen ser editores de estructura. Herramienta “Make” automática Permite automatizar las funciones del fichero de dependencia, analizando el código fuente.

Apuntes realizados por Antonio Reyes. C.A.Tenerife

28

Manejador de versiones

Permiten almacenar de forma organizada una serie de versiones de un mismo elemento de software. Permiten manejar ficheros de texto (SCCS de Unix). Se suele utilizar una numeración correlativa 1.1, 1.2, etc. Algunos productos utilizan ficheros separados para cada versión, otras agrupan todas las versiones de un mismo sistema. Procesadores/Analizadores de Son herramientas que analizan el código fuente para obtener mediciones, generar código fuente tablas de referencias, encolumnar según un estilo normalizado “prettyprinters”, comprobar consistencia de módulos, etc. Procesadores de documentos Permiten la edición de la documentación. Herramientas de control de pruebas Ayudan a la realización de pruebas unitarias o de integración. Las hay para comprobar el grado de cubrimiento, otros simulan la entrada de datos, etc. Herramientas de control de cambios Ayudan a la realización del desarrollo en forma incremental, y al mantenimiento de aplicaciones. Mantiene una configuración consistente del sistema, llamada línea base, y sólo permite incorporar cambios de forma controlada, garantizando que las modificaciones mantienen el sistema en estado operativo. Procesadores de ficheros de texto A este grupo pertenece gran cantidad de utilidades de Unix, como p. Ejp. ‘awk’ que es un compilador/intérprete de un lenguaje de manipulación de ficheros de texto. 6.5.3. Herramientas de 4ª generación Son herramientas destinadas al usuario final permitiendo a éste realizar sus propios desarrollos. Hoja de cálculo Facilita la realización de álculos basados en una plantilla de tipo matricial. Las casillas se pueden rellenar automáticamente o con datos calculados. Las fórmulas se editan de forma interactiva. Algunas permiten realizar gráficos. Procesadores de documento Ya se mencionó. Gestores de bases de datos Permiten definir los esquemas de las bases de datos, y realizar operaciones de consulta y manipulación. Lenguajes de 4ª generación Permiten programar operaciones de tratamiento de datos. Suelen ir asociados a un gestor de bases de datos (s.g.b.d.) e incluyen un lenguaje de consulta (SQL). Generadores de programas También suelen estar asociados a un s.g.b.d. y permiten la preparación interactiva de esquemas de informes, formularios, etc.Posteriormente generan programas en un L4G. 6.6. Entornos integrados La integración puede presentar diferentes aspectos: 6.6.1. Integración de datos Integración de datos Significa que la información almacenada en el entorno es uniformemente gestionada. Debe lograr: interoperatividad entre herramientas, no redundancia de datos, consistencia de datos, paso de datos de una herramienta a otra. Eso se puede lograr de varias formas: • Transferencia directa de datos de una herramienta a otra. Es poco flexible. • Transferencia mediante ficheros. Es la forma más sencilla. Existe incluso un formato. • Transferencia basada en comunicación. Para usar en sistemas distribuidos y abiertos. • Repositorio común. La más utilizada en entornos modernos. 6.6.2. Integración del control Consiste en permitir la combinación flexible de funciones para cumplir con las particularidades del proceso y actividades a informatizar. Ello exige que las herramientas puedan compartir los datos entre ellas y, como consecuencia, debe existir un sistema de gestión de procesos y mensajes 6.6.3. Integración de la presentación Integración de la Trata de realizar la interacción con el usuario de manera uniforme, independientemente de presentación la función herramienta que use en un momento dado. Esto hace que se reduzca el esfuerzo de memoria y sea un sistema amigable (user-friendly). Para ello se debe: • Limitar el nº 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 información del avance de la operación cuando va a tardar mucho. • Mantener información útil a disposición del usuario. 6.6.4. Integración del proceso

Apuntes realizados por Antonio Reyes. C.A.Tenerife

29

Integración del proceso

6.6.5. El repositorio CASE Repositorio CASE

Información a guardar

Consiste en que las herramientas se combinan de forma que fuerzan de manera efectiva el uso de una metodología de desarrollo definida. El proceso de desarrollo se puede definir en base a: • Un paso del desarrollo es una unidad de trabajo que produce un resultado. • Un evento de desarrollo es una condición que ocurre durante la ejecución de un paso y que puede desencadenar la ejecución de una acción asociada. • Una restricción del desarrollo es una limitación que debe cumplirse. Un 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. Para ello se requiere: • Un servicio metamodelo que permita definir las estructuras de datos que han de almacenarse. • Un servicio de consulta y actualización (query) que permita acceder a la información. • Un servicio de vistas, que permita definir subconjuntos de datos y operaciones que constituyan el subentorno de trabajo de ciertas actividades. • Un servicio de intercambio de datos, que facilite la importación y exportación de información mediante ficheros externos. Puede estar constituida por: código fuente, código objeto, código ejecutable, órdenes de compilación y montaje, dependencias entre módulos, estructura modular, programas de prueba, datos de prueba, resultados de pruebas, especificaciones de módulos, información de cambios, métricas de calidad, documentos de diseño, documentos de requisitos, informes de revisiones, definición de la metodología de desarrollo, información de la planificación del proyecto, información, de la gestión del proyecto, e información de la empresa.

6.7. Bancos o equipos de trabajo Para que un banco de trabajo se pueda definir como tal, es decir, que cumpla con el trabajo de integrar las herramientas necesarias para dar soporte a un determinado perfil, debe conseguir: a) integración de la presentación con una interfaz de usuario homogénea y consistente; b) integración del control, con la posibilidad de invocar cómodamente una herramienta, y; c) integración de datos, preferiblemente mediante un repositorio común. Según la actividad se tendrán diferentes bancos o equipos de trabajo: Equipo de análisis y diseño Llamados “upper” CASE deben soportar completamente una determinada metodología. La modificación de un elemento se debe apreciar en todos los diagramas o descripciones en donde aparezca. Entorno de programación Es el banco de trabajo para la actividad de codificación, y puede extenderse al diseño detallado y a las pruebas de unidades. Equipo de validación y verificación Debe ser capaz de facilitar las tareas de inspección y pruebas de módulos y sistemas. Suele estar ligado al entorno de programación. Equipo de construcción de intefaz de Permite definir cómodamente el esquema de diálogo con el usuario, así como los usuario elementos de interacción. Equipo de gestión de configuración Debe permitir almacenar las diversas versiones de los elementos de un proyecto. Equipo de ingeniería inversa Debe facilitar la extracción de información de diseño y los elementos abstractos a partir de un código ya desarrollado. Equipo de gestión de proyectos Facilita la confección de planes de trabajo con asignación de tiempos y recursos, gestión de reuniones, seguimiento, etc. 6.8. Entornos orientados al proceso Un entorno de desarrollo orientado al proceso debe ser capaz de soportar todas las actividades del ciclo de vida de desarrollo conforme a una metodología concreta (IPSE o ICASE o ISEE ‘Integrated Software Engineering Environment’). Este tipo de entornos debería permitir: a) construir la definición formal del modelo del proceso de desarrollo, y b) asegurar la aplicación práctica del modelo definido. Muchos de estos entornos son creados en empresas. Algunas propuestas de esta clase de entornos son: PCTE Portable Common Tool Environment. Es una arquitectura de entorno integrado basada en un repositorio común. En ella lo principal es la interfaz de acceso al repositorio. ESF Eureka Software Factory. Aquí el elemento central de integración es el ‘software bus’ que constituye la interfaz normalizada para la interconexión de herramientas, que se dividen en herramientas de interacción, y servidores. NIST/ECMA Propuesto por varios organismos europeos y americanos se compone de una estructura fija que tiene elementos que proporcionan integración de datos (repositorio común), integración de presentación (soporte global de interfaz de usuario) e integración de control (procesos y mensajes). ESSDE Es el entorno utilizado por la ESA y es el resultado de un enfoque pragmático. Se basa en Concerto (herramienta CASE basada en metodología HODD) y Rational Ada que es un entorno de programación en lenguaje Ada.

Apuntes realizados por Antonio Reyes. C.A.Tenerife

30

Apuntes realizados por Antonio Reyes. C.A.Tenerife

31