INGENIERA DEL SOFTWARE

Javier Martn Centro Asociado de Mstoles / Tres Cantos UNED

Introduccin

JAVIER MARTIN ([email protected])

TUTORIAS:

JUEVES/VIERNES de 7 a 9

PLAN DE TRABAJO
Exposicin

de los temas y mediante transparencia, abundando en los puntos ms importantes. Resolucin de dudas Propuesta y resolucin de ejercicios y problemas

INGENIERA DEL SOFTWARE Javier Martn

Temas

INTRODUCCIN ESPECIFICACIN DEL SOFTWARE FUNDAMENTOS DEL DISEO SOFTAWARE TCNICAS GENERALES DE DISEO SOFTWARE CODIFICACIN Y PRUEBAS AUTOMATIZACIN Y PROCESO DE DESARROLLO
INGENIERA DEL SOFTWARE Javier Martn 3

Tema 1: INTRODUCCIN

INGENIERA DEL SOFTWARE Javier Martn

Concepto de Ingeniera de Sistemas

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

Concepto de Ingeniera del Software

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

La crisis del Software

Se produce cuando surge la necesidad de desarrollar aplicaciones software demasiado complejas, a mediados de los 60. Para superar la crisis:
Aparicin de metodologas concretas de desarrollo Concepcin de la Ingeniera del Software como disciplina Trabajo en equipo y especializacin (analistas, programadores, ...)

No se ha llegado a una situacin estable, sino a una evolucin permanente con avances continuos en la IS, forzados por el rpido abaratamiento y aumento de capacidad del hardware.

INGENIERA DEL SOFTWARE Javier Martn

Mitos del Software

El hardware es mucho ms importante que el software El software es fcil de desarrollar El software consiste exclusivamente en programas ejecutables El desarrollo del software es slo una labor de programacin Es natural que el software contenga errores

INGENIERA DEL SOFTWARE Javier Martn

Formalizacin del proceso de desarrollo

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

Prcticamente identifican actividades similares y slo se diferencian en la forma de presentacin.

INGENIERA DEL SOFTWARE Javier Martn 9

MODELO EN CASCADA

INGENIERA DEL SOFTWARE Javier Martn

10

MODELO EN CASCADA

ANLISIS, determinar qu debe hacer el software -> especificacin DISEO, descomponer y organizar el sistema para que los mdulos puedan ser desarrollados por separado CODIFICACIN, escribir el cdigo fuente de cada mdulo y realizar sobre ellos las pruebas necesarias INTEGRACIN, combinar todos los mdulos y probar el sistema completo antes de pasar a su explotacin MANTENIMIENTO, durante la explotacin es necesario realizar cambios ocasionales bien para corregir errores o para introducir mejoras, Se trata de aislar cada fase de las otras, lo que facilita la especializacin de los desarrolladores. Al final de cada fase se requiere un proceso de revisin`para evitar que los errores se propaguen a fases posteriores provocando la vuelta atrs. INGENIERA DEL SOFTWARE Javier Martn 11

MODELO EN CASCADA AMPLIADO

INGENIERA DEL SOFTWARE Javier Martn

12

MODELO EN CASCADA

Cada fase debe generar una informacin de salida precisa y suficiente:

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

INGENIERA DEL SOFTWARE Javier Martn 13

MODELO EN V

INGENIERA DEL SOFTWARE Javier Martn

14

MODELO EN V AMPLIADO

INGENIERA DEL SOFTWARE Javier Martn

15

MODELO EN V

Incluye fases similares a las del modelo en cascada pero de forma jerrquica. En horizontal se representa el avance en el desarrollo y en vertical el nivel de detalle. VERIFICACIN, comprobacin de que una parte del sistema cumple con sus especificaciones. VALIDACIN, comprobacin de que un elmento satisface las necesidades del usuario identificadas durante el anlisis.

INGENIERA DEL SOFTWARE Javier Martn

16

PROTOTIPOS

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

INGENIERA DEL SOFTWARE Javier Martn 17

PROTOTIPOS RPIDOS

Su finalidad es solo adquirir experiencia, no se aprovechan como producto (usar y tirar). Se denominan maquetas cuando su funcionalidad o capacidad es muy limitada. El sistema final se codifica totalmente partiendo de cero, no se aprovecha el cdigo del prototipo Lo importante de estos prototipos es que se desarrollen en poco tiempo.

INGENIERA DEL SOFTWARE Javier Martn

18

PROTOTIPOS RPIDOS

INGENIERA DEL SOFTWARE Javier Martn

19

PROTOTIPOS EVOLUTIVOS

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

PROTOTIPOS EVOLUTIVOS

INGENIERA DEL SOFTWARE Javier Martn

21

MODELO EN ESPIRAL

Puede considerarse como un refinamiento del modelo evolutivo general que introduce el anlisis de riesgo como elemento fundamental para guiar la evolucin del proceso de desarrollo. En la dimensin radial se representa el esfuerzo realizado en el desarrollo (siempre creciente) En cada iteracin 4 fases:
PLANIFICACIN, determina que parte del desarrollo se abordar en ese ciclo. ANALISIS DE RIESGO, evaluar diferentes alternativas para esa parte del desarrollo seleccionando la ms ventajosa y tomando precauciones para evitar los posibles inconvenientes. INGENIERA, las actividades de los modelos clsicos EVALUACIN, se analizan los resultados de la fase de ingeniera.

INGENIERA DEL SOFTWARE Javier Martn 22

MODELO EN ESPIRAL

INGENIERA DEL SOFTWARE Javier Martn

23

MANTENIMIENTO DEL SOFTWARE

El mantenimiento no representa una actividad especfica, sino que consiste en rehacer parte de las actividades correspondientes a las otras fases del desarrollo para introducir cambios sobre una aplicacin ya en fase de explotacin. MANTENIMIENTO CORRECTIVO, su finalidad es corregir errores que no fueron detectados en el desarrollo del producto. MANTENIMIENTO ADAPTATIVO, modificar una aplicacin para adaptarla a las nuevas necesidades del entorno. MANTENIMIENTO PERFECTIVO, se trata de ir obteniendo versiones mejoradas del producto
INGENIERA DEL SOFTWARE Javier Martn 24

GESTIN DE CAMBIOS

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

REINGENIERA, es necesaria cuando el desarrollo de una aplicacin no est documentado y se dispone solamente del cdigo. Se llama tambin ingeniera inversa porque supone reconstruir y documentar las fases de anlisis y diseo llegando a la estructura modular de la aplicacin y las dependencias entre mdulos y funciones. Estas actividades organizan y documentan un sistema deficiente. INGENIERA DEL SOFTWARE Javier Martn 25

GARANTA DE CALIDAD

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

PLAN DE GARANTA DE CALIDAD (SQAP)

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

INGENIERA DEL SOFTWARE Javier Martn 27

REVISIONES

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

INGENIERA DEL SOFTWARE Javier Martn 28

PRUEBAS

Consiste en hacer funcionar el producto o una parte de l y comprobar si los resultados son correctos. No permite garantizar la calidad del producto. En general no es posible probar un producto de forma exhaustiva, debido a su complejidad.

INGENIERA DEL SOFTWARE Javier Martn

29

GESTIN DE CONFIGURACIN CONFIGURACIN, disposicin de las partes que componen una cosa y le
dan su peculiar figura. La CONFIGURACN SOFTWARE se refiere a la manera en que diversos elementos se combinan para construir un producto software. Se han de combinar todos los elementos que intervienen en el desarrollo: Documentos del desarrollo Cdigo fuente Programas, datos y resultado de las pruebas Manuales de usuario Documentos de mantenimiento, informes de problemas y cambios Prototipos intermedios Normas particulares del proyecto Dado que los elementos software van evolucionando a lo largo del desarrollo se requiere: Control de versiones, almacenar de forma organizada las sucesivas versiones de cada elemento de la configuracin. Control de cambios, garantizar que las diferentes configuraciones del software se componen de elementos compatibles entre s (lnea base).
INGENIERA DEL SOFTWARE Javier Martn 30

NORMAS Y ESTNDARES

IEEE, Institute of Electrical and Electronics Engineer de USA [IEEE93] DoD, Departament od Defense de USA [DoD88] ESA, Agencia Europea del Espacio [ESA91] ISO, organismo internacional de normalizacin (International Standars Organization). En Espaa AENOR. METRICA-2, desarrollada por el Consejo Superior de Informtica del MAP. Se basa en la metodologa de anlisis y diseo de Yourdon/DeMarco.
INGENIERA DEL SOFTWARE Javier Martn 31

Tema 2: ESPECIFICACIN DE SOFTWARE

INGENIERA DEL SOFTWARE Javier Martn

32

MODELADO DE SISTEMAS

El anlisis y la definicin de los requisitos debe dar lugar a la especificacin software, en la que se concretan las necesidades que se desean cubrir y se fijan las restricciones con las que debe trabajar el software. El modelado de los sistemas tiene como objetivo entender mejor el comportamiento requerido y facilitar la comprensin de los problemas planteados. Se trata de establecer modelos conceptuales que reflejen la organizacin de la informacin y las diversas transformaciones que se deben llevar a cabo con dicha informacin. Las metodologas de anlisis de requisitos tratan de facilitara obtencin de uno o varios modelos que detallen el comportamiento deseado del sistema.
INGENIERA DEL SOFTWARE Javier Martn 33

CONCEPTO DE MODELO

Un modelo conceptual es una abstraccin lgicomatemtica del mundo real que facilita la comprensin del problema a resolver. Se trata de ofrecer una visin de lato nivel, sin descender a explicar detalles concretos del mismo. Indica QU hace el sistema y no CMO lo debe hacer. Los OBJETIVOS a cubrir con los modelos son:
Facilitar la comprensin de l problema Establecer un marco para la discusin que simplifique y sistematice el anlisis Fijar las base para el diseo Facilitar la verificacin del cumplimiento de los objetivos del sistema

INGENIERA DEL SOFTWARE Javier Martn

34

TCNICAS DE MODELADO (I)

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

TCNICAS DE MODELADO (II)

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

Las ventajas de realizar un modelos ms general son:

Facilitar la comunicacin entre el analista y el usuario del sistema, p.e. usando la misma terminologa. Creacin de elementos realmente significativos del sistema, si se ajusta a la normativa especfica establecida. Reutilizacin posterior del software desarrollado.

INGENIERA DEL SOFTWARE Javier Martn 36

ANLISIS DE REQUISITOS DE SOFTWARE

El anlisis es la fase de definicin del futuro sistema y tiene una importancia decisiva en el desarrollo de todas las etapas posteriores. Con el anlisis de requisitos se trata de caracterizar el problema a resolver. El cliente trabaja con el analista para elaborar las especificaciones y posteriormente se encargarn de verificar el cumplimiento de las mismas (contrato). El anlisis debe producir un modelo vlido necesario y suficiente para recoger todas las necesidades y exigencias del sistema, as como las restricciones que los limiten. Para una especificacin correcta se requiere: Completo y sin omisiones Conciso y sin trivialidades Sin ambigedades Sin detalles de diseo o implementacin Fcilmente entendible por el cliente Separando requisitos funcionales u no funcionales (capacidades mnimas y mximas, interfaces estndares, recursos necesarios, seguridad, fiabilidad, mantenimiento, etc. Divisin y jerarqua del modelo global, con el fin de simplificar su comprensin Incluyendo los criterios de validacin del sistema, para comprobar si se ajusta al contrato inicial.
INGENIERA DEL SOFTWARE Javier Martn 37

TAREAS DEL ANLISIS

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

NOTACIONES PARA LA ESPECIFICACIN

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

INGENIERA DEL SOFTWARE Javier Martn 39

DIAGRAMAS DE FLUJO DE DATOS (DFD)

Se trata de realizar un modelo grfico para representar el flujo de datos que entra en el sistema, las transformaciones que debe realizar y la salida producida. Tambin se representan las entidades externas la sistema que producen o consumen datos. El DFD inicial es el de contexto, posteriormente y de forma jerrquica se van desarrollando otros DFDs que detallan las transformaciones, las entradas y salidas del diagrama detallado deben coincidir con el proceso correspondiente. Recoge de forma esttica los procesos, dnde en el ltimo nivel de refinamiento se especifican en lenguaje natural estructurado, y su interrelacin.

INGENIERA DEL SOFTWARE Javier Martn

40

DIAGRAMAS DE TRANSICIN DE ESTADOS

Describe el comportamiento dinmico del sistema basndose en sus estados ms importantes. Al igual que en los autmatas de estados finitos, los eventos motiva el cambio de estado del sistema.

INGENIERA DEL SOFTWARE Javier Martn

41

DIAGRAMAS DE MODELO DE DATOS

Se trata de organizar e interrelacionar los datos que utiliza el sistema. El MODELO ENTIDAD-RELACIN permite definir todos los datos y establecer las relaciones que deben existir entre ellos.

INGENIERA DEL SOFTWARE Javier Martn

42

DOC. DE ESPECIFICACIN DE REQUISITOS

El documento o la especificacin de requisitos (SRD o SRS) recoge de forma integral los resultados del anlisis. Puede haber documentos previos al SRD, como estudios de viabilidad o de alternativas posibles. El SRD debe ser revisado con cierta frecuencia durante el desarrollo y debe facilitar la varificacin de las especificaciones (contrato). Diversos organismos de estandarizacin hacen propuestas sobre la estructura del SRD: IEEE, DoD, etc. Vemos el modelo de SRD de la Agencia Espacial Europea. Dependiendo de las caractersticas y complejidad del proceso tal vez no sea necesario cubrir todos los apartados.
INGENIERA DEL SOFTWARE Javier Martn 43

MODELO DE SRD
1. Introduccin 1. Objetivo: objetivos, participantes, calendario,...
2. 3. 4. 5. mbito, identificar y dar nombre al producto Definiciones, siglas y abreviaturas Referencias, la descripcin bibliogrfica de los documentos referenciados. Panormica del documento Relacin con otros proyectos, similares o complementarios Relacin con proyectos anteriores o posteriores Objetivo y funciones Consideraciones de entorno Relaciones con otros sistemas, que utilicen entradas o salidas indirectas de informacin Restricciones generales: metodologas, lenguajes, de hardware,... Descripcin del modelo, es el apartado ms extenso y ms importante. Se utilizan todas las notaciones y herramientas disponibles

2.

Descripcin general
1. 2. 3. 4. 5. 6. 7.

INGENIERA DEL SOFTWARE Javier Martn

44

MODELO DE SRD
3. Requisitos especficos, lista detallada y completa de los requisitos del sistema, indicando su grado de cumplimiento (obligatorio, recomendable, opcional. No incluir aspectos de diseo o desarrollo, ni tampoco soluciones particulares que no sean obligadas 3. Requisitos especficos, QU debe hacer el sistema especificando el tratamiento de la informacin. 4. Requisitos de interfase, conexin con otros sistemas con los que interacta (bases de datos, ficheros, SSOO,...). 5. Requisitos de operacin, es decir, del interfaz de usuario 6. Requisitos de capacidad, volumen procesador, tiempo respuesta, tamao ficheros. Se debe cuantificar para el peor, el mejor y el caso ms habitual. 7. Requisitos de verificacin, que debe cumplir el sistema para que se posible verificar su correccin 8. Requisitos de pruebas de aceptacin 9. Requisitos de recursos, instalaciones y elementos necesarios para el funcionamiento del sistema 10. Requisitos de documentacin 11. Requisitos de transportabilidad, para adaptalo a otras plataformas 12. Requisitos de calidad, que no hayan sido recogidos en otros apartados 13. Requisitos de fiabilidad, imponiendo un lmite aceptable de fallos 14. Requisitos de mantenibilidad 15. Requisitos de seguridad, contra utilizacin indebida 16. Requisitos de salvaguarda, para evitar consecuencias graves en equipos o en personas APENDICES, para complementar el contenido del documento
INGENIERA DEL SOFTWARE Javier Martn 45

4.

VIDEOJUEGO DE LAS MINAS

INGENIERA DEL SOFTWARE Javier Martn

46

SISTEMA DE GESTIN DE BIBLIOTECA

INGENIERA DEL SOFTWARE Javier Martn

47

SISTEMA DE GESTIN DE BIBLIOTECA

INGENIERA DEL SOFTWARE Javier Martn

48

SISTEMA DE GESTIN DE BIBLIOTECA

INGENIERA DEL SOFTWARE Javier Martn

49

SISTEMA DE GESTIN DE BIBLIOTECA

INGENIERA DEL SOFTWARE Javier Martn

50

SISTEMA DE GESTIN DE BIBLIOTECA

INGENIERA DEL SOFTWARE Javier Martn

51

Tema 3: FUNDAMENTOS DEL DISEO DEL SOFTWARE

INGENIERA DEL SOFTWARE Javier Martn

52

CONCEPTO DE DISEO

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

ACTIVIDADES DE UN DISEO SISTEMTICO

DISEO ARQUITECTNICO, se abordan los aspectos estructurales y de organizacin del sistema, y su posible divisin en subsistemas DISEO DETALLADO, organizacin y estructura de los mdulos DISEO PROCEDIMENTAL, organizacin de las operaciones o servicios que ofrecer cada mdulo. Se suele realizar en pseudocdigo o PDL, pero desarrollando slo los aspectos ms relevantes del algoritmo DISEO DE DATOS, organizacin de la base d edatos del sistema. Se parte de los diagramas E-R. DISEO DE LA INTERFAZ DE USUARIO, organizar y facilitar la utilizacin del sistema por parte del usuario El resultado de estas actividades debe plasmarse en el Documento d Diseo Software (SDD) INGENIERA DEL SOFTWARE Javier Martn 54

CONCEPTOS PARA EL DISEO

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

INGENIERA DEL SOFTWARE Javier Martn

55

NOTACIONES PARA EL DISEO

Debe resultar precisa, clara y fcil de interpretar. Se emplean notaciones formales cuasimatemticas NOTACIONES ESTRUCTURALES, se desglosa y estructura el sistema en sus partes
DIAGRAMAS

DE BLOQUES

CAJAS

ADOSADAS

INGENIERA DEL SOFTWARE Javier Martn

56

DIAGRAMAS DE ESTRUCTURA (Yourdon)

Describen la estructura de los sistemas software como una jerarqua de mdulos, reflejando slo su organizacin esttica
RECTNGULO, mdulo LNEA, relacin entre mdulos, el superior utiliza el mdulo inferior ROMBO, opcional ARCO, repetitiva CIRCULO CON FLECHA, envio de datos o informacin de control (correcto, repetir, desconectar, etc)

INGENIERA DEL SOFTWARE Javier Martn

57

DIAGRAMAS HIPO (Hierachy-InputProcess-Output)

Se muestra primero la jerarqua entre los mdulos del sistema

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

INGENIERA DEL SOFTWARE Javier Martn

58

DIAGRAMAS DE JACKSON
El proceso de diseo es sistemtico y se lleva a cabo en tres pasos: Especificacin de la estructura de datos de entrada y de salida Obtencin de la estructura del programa

Expansin de la estructura del programa para lograr el diseo detallado

INGENIERA DEL SOFTWARE Javier Martn

59

NOTACIONES ESTTICAS

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

INGENIERA DEL SOFTWARE Javier Martn 60

NOTACIONES DINMICAS

Permiten describir el funcionamiento del sistema durante su funcionamiento. Las notaciones son las misma utilizadas en la especificacin:
DIAGRAMAS

DE FLUJO DE DATOS, sern mucho ms exhaustivos que los de la especificacin. DIAGRAMAS DE TRANSICIN DE ESTADOS, ms detallados que reflejen las transiciones entre estados internos. LENGUAJE DE DESCRIPCIN DE PROGRAMAS (PLD), permite realizar la especificacin funcional del sistema.
INGENIERA DEL SOFTWARE Javier Martn 61

NOTACIONES HIBRIDAS: DIAGRAMAS DE ABSTRACCIONES

Permiten un enfoque globalizado del diseo atendiendo a aspectos estticos (datos), dinmicos (operaciones) y de estructura del sistema.
DIAGRAMAS DE ABSTRACCIONES, se contemplan dos tipos de abstracciones: las funciones y los tipos abstractos de datos. En una abstraccin se distinguen 3 partes: NOMBRE, es su identificador CONTENIDO, dnde se define la organizacin de los datos OPERACIONES, para manejar el contenido de la abstraccin Las abstracciones funcionales (funciones o procedimientos), slo tiene la parte de operacin.

El dato encapsulado tiene como el tipo abstracto contenido y operaciones, pero no permite declarar otras variables de su mismo tipo.

En los diagramas se muestra la relacin jerrquica entre abstracciones, de manera que la abstraccin superior utiliza la inferior.

INGENIERA DEL SOFTWARE Javier Martn

62

NOTACIONES HIBRIDAS: DIAGRAMAS DE OBJETOS

Se emplea una terminologa distinta, pero las similitudes con los diagramas de abstracciones es muy grande, excepto que: 1. No existe nada equivalente a los datos encapsulados ni a las abstracciones funcionales en el modelo de objetos

2.

En los diagramas de objetos hay relaciones de herencia

De acuerdo con las propiedades de los objetos podemos tener relaciones especiales entre ellos:
CLASIFICACIN, ESPECIALIZACIN O HERENCIA COMPOSICIN, permite describir un objeto mediante los elementos que lo forman

INGENIERA DEL SOFTWARE Javier Martn

63

DOCUMENTOS DE DISEO: ADD

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

INGENIERA DEL SOFTWARE Javier Martn

64

DOCUMENTOS DE DISEO: DDD

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

65

Tema 4: TCNICAS GENERALES DE DISEO SOFTWARE

INGENIERA DEL SOFTWARE Javier Martn

66

TCNICAS DE DISEO

Los objetivos de las tcnicas de diseo software son fundamentalmente:

La descomposicin modular del sistema Los diseos de los algoritmos y estructuras de datos fundamentales que se deben usar en el sistema

Primero veremos las caractersticas deseables de una buena descomposicin modular del sistema, y luego se presentarn tcnicas de diseo:
Diseo funcional descendente Diseo orientado a objetos Diseo de datos

INGENIERA DEL SOFTWARE Javier Martn

67

DESCOMPOSICIN MODULAR

Los pasos a seguir son: 1. Identificar los mdulos 2. Describir cada mdulo 3. Describir las relaciones entre mdulos Tipos de mdulos: 1. Cdigo fuente, en el lenguaje de programacin usado 2. Tabla de datos, para datos de inicializacin u otros 3. Configuracin, se agrupa en un mdulo toda la informacin de configuracin en el entorno de trabajo 4. Otros: ficheros de ayuda en lnea, manuales, etc. Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda considerar suficientemente vlida Independencia fucional Acoplamiento Cohesin Comprensibilidad Adaptabilidad
INGENIERA DEL SOFTWARE Javier Martn 68

DESCOMPOSICIN MODULAR: INDEPENDENCIA FUNCIONAL

DESCOMPOSICIN MODULAR: ACOPLAMIENTO

Al final de los documentos ADD y DDD debe haber una matriz REQUISITOS/COMPONNETES. En principio, cada funcin ser realizada en un mdulo distinto. Si las funciones son independientes los mdulos tendrn independencia funcional. Cada mdulo debe realizar una funcin concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre mdulos al mnimo. Para medir la independencia funcional hay dos criterios: acoplamiento y cohesin.

El grado de acoplamiento mide la interrelacin entre dos mdulos, segn el tipo de conexin y la complejidad de la interfase: FUERTE, POR CONTENIDO, cuando desde un mdulo se pueden cambiar datos locales de otro COMN, se emplea una zona comn de datos a la que tienen acceso varios mdulos MODERADO, DE CONTROL, la zona comn es un dispositivo externo al que estn ligados los mdulos, esto implica que un cambio en el formato de datos afecta a todos estos mdulos POR ETIQUETA, en ontercambio de datos se realiza mediante una referencia a la estructura completa de datos (vector, pila, rbol, grafo, ...) DBIL, DE DATOS, viene dado por los datos que intercambian los mdulos. Es el mejor posible SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe
INGENIERA DEL SOFTWARE Javier Martn 69

DESCOMPOSICIN MODULAR: COHESIN

Es necesario lograr que el contenido de cada mdulo tenga la mxima coherencia. Para que el n de mdulos no sea demasiado elevado y complique el diseo se tratan de agrupar elementos afines y relacionados en un mismo mdulo. ALTA COHESIN ABSTRACCIONAL, se logra cuando se disea el mdulo como tipo abstracto de datos o como una clase de objetos COHESIN FUNCIONAL, el mdulo realiza una funcin concreta y especfica MEDIA COHESIN SECUENCIAL, los elementos del mdulo trabajan de forma secuencial COHESIN DE COMUNICACIN, elementos que operan con le mismo conjunto de datos de entrada o de salida COHESIN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej. Arrancar o parar dispositivos BAJA COHESIN LGICA, se agrupan elementos que realizan funciones similares. Ejs.: mdulos de E/S o de tratamiento de errores COHESIN COINCIDENTAL, es la peor y se produce cuando los elementos de un mdulo no guardan relacin alguna La descripcin del comportamiento de un mdulo permite establecer el grado de cohesin: Si es una frase compuesta y contiene ms de un verbo la cohesin ser MEDIA Si contiene expresiones secuenciales (primero, entonces, cuando...), ser temporal o secuencial Si la descripcin no se refiere a algo especfico (Ej. Todos los errores), cohesin lgica Si aparece inicializar, preparar, configurar, probablemente sea temporal.
INGENIERA DEL SOFTWARE Javier Martn 70

DESCOMPOSICIN MODULAR: COMPRENSIBILIDAD

Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero adems es deseable: IDENTIFICACIN, el nombre debe ser adecuado y descriptivo DOCUMENTACIN, debe aclarar todos los detalles de diseo e implementacin que no queden de manifiesto en el propio cdigo SIMPLICIDAD, las soluciones sencillas son siempre las mejores
La adaptacin de un sistema resulta ms dificil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesin, y cuando el diseo es poco comprensible. Otros factores para facilitar la adaptabilidad: PREVISIN, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en mdulos independientes, de manera que su modificacin afecte al menor nmero de mdulos posible ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificacin, diseo, e implementacin para obtener un conocimiento suficiente del sistema antes de proceder a su adaptacin CONSISTENCIA, despus de cualquier adaptacin se debe mantener la consistencia del sistema, incluidos los documentos afectados
INGENIERA DEL SOFTWARE Javier Martn 71

DESCOMPOSICIN MODULAR: ADAPTABILIDAD

TCNICAS DE DISEO FUNCIONAL DESCENDENTE

TCNICAS DE DISEO FUNCIONAL DESCENDENTE: DESARROLLO POR REFINAMIENTO PROGRESIVO

La descomposicin del sistema se hace desde un punto de vista funcional. Desde el punto de vista de la codificacin, cada mdulo corresponde esencialmente a un subprograma.

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

INGENIERA DEL SOFTWARE Javier Martn

72

TCNICAS DE DISEO FUNCIONAL DESCENDENTE: PROGRAMACIN ESTRUCTURADA DE JACKSON

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

TCNICAS DE DISEO FUNCIONAL DESCENDENTE: PROGRAMACIN ESTRUCTURADA DE JACKSON

En el PASO 2 se trata de encontrar una estructura del programa que se ajuste a las estructuras de los datos de entrada y salida

INGENIERA DEL SOFTWARE Javier Martn

74

TCNICAS DE DISEO FUNCIONAL DESCENDENTE: DISEO ESTRUCTURADO

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

INGENIERA DEL SOFTWARE Javier Martn

75

TCNICAS DE DISEO FUNCIONAL DESCENDENTE: DISEO ESTRUCTURADO

Para establecer la jerarqua de control entre mdulos se recomienda hacer ciertos anlisis en el flujo de datos: de flujo de transformacin y de flujo de transaccin. Para ello es recomendable construir un DFD con todos los procesos contenidos en los primeros niveles prescindiendo de los almacenes. El anlisis de flujo de transformacin consiste en identificar un flujo global de informacin desde los elementos de entrada hasta los de salida. Los procesos se agrupan en 23 regiones: flujo de entrada, de transformacin y de salida.
INGENIERA DEL SOFTWARE Javier Martn 76

TCNICAS DE DISEO FUNCIONAL DESCENDENTE: DISEO ESTRUCTURADO

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

INGENIERA DEL SOFTWARE Javier Martn

77

TCNICAS DE DISEO FUNCIONAL DESCENDENTE: DISEO ESTRUCTURADO. EJ. GESTIN DE BIBLIOTECA

INGENIERA DEL SOFTWARE Javier Martn

78

TCNICAS DE DISEO BASADO EN ABSTRACCIONES

TCNICAS DE DISEO BASADO EN ABSTRACCIONES: DESCOMPOSICIN MODULAR BASADA EN ABSTRACCIONES

La idea es que los mdulos corresponden a funciones o a tipos abstractos de datos. Los lenguajes que dan ms facilidades para la implementacin son los orientados a objetos

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

INGENIERA DEL SOFTWARE Javier Martn

79

TCNICAS DE DISEO BASADO EN ABSTRACCIONES: MTODO DE ABBOTT

A partir de la descripcin o especificacin de los mdulos es posible identificar las palabras o trminos que puedan corresponder a elementos significativos del diseo: Tipos de datos, que aparecen como sustantivos genricos Atributos, son sustantivos en general Operaciones, tienen la forma de verbos o nombres de acciones Se subrayan en la descripcin las palabras significativas haciendo una lista de nombres y otra de verbos u operaciones. Hay que eliminar los trminos irrelevantes o los sinnimos de palabras ya aparecidas DATO Palabra Prrafo Atributos Caracteres Separador Lnea salida Lneas en blanco Sangrado Sangrado Palabras Iniciar lnea cabe palabra? Poner palabra Imprimir sin ajustar Imprimir ajustada 80 Operaciones Imprimir Iniciar prrafo Poner palabra Terminar prrafo

Separador de prrafo Lnea

INGENIERA DEL SOFTWARE Javier Martn

TCNICAS DE DISEO ORIENTADAS A OBJETOS

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

Identificar los objetos, sus atributos y sus componentes Identificar las operaciones sobre los objetos y asociarlas a la clase adecuada Aplicar herencia donde convenga Describir cada operacin en funcin de las otras, y subsanar posibles omisiones Asignar clases y objetos a los mdulos del sistema

INGENIERA DEL SOFTWARE Javier Martn

81

TCNICAS DE DISEO DE DATOS

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

FN1, la informacin asociada a cada columna de la tabla es un nico valor, y no una coleccin FN2, si hay una clave primaria que distingue e identifica cada fila, el resto de los datos dependen de toda la clave primaria FN3, el valor de cada columna que no es clave primaria depende directamente de la clave primaria. Se puede conseguir si se separan las tablas.

Los INDICES, que mejoran la velocidad de acceso a los datos

INGENIERA DEL SOFTWARE Javier Martn 82

TCNICAS DE DISEO DE DATOS: DISEO DE LAS ENTIDADES

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

TCNICAS DE DISEO DE DATOS: COMPOSICIN Y HERENCIA

(a)

(b)

(c)

Las relaciones de COMPOSICIN se tratan como las de asociacin, y en ellas la cardinalidad del objeto compuesto suele ser 1, por lo que se puede aplicar la simplificacin. Cuando una clase tiene carias subclases hay 3 formas de amacenar las entidades ne tablas: Una tabla para la superclase con los atributos comunes y una tabla para cada subclase Desaparece la tabla de la superclase y los atributos comunes heredados se repiten en las subclases Se prescinde de las tablas de la subclase y se amplia la tabla de la superclase con todos los atributos de las subclases, de forma que estos valores sern opcionales para los elementos

INGENIERA DEL SOFTWARE Javier Martn

84

Tema 5: CODIFICACIN Y PRUEBAS

INGENIERA DEL SOFTWARE Javier Martn

85

CODIFICACIN DEL DISEO

Nos vamos a referir a las ltimas fases del ciclo de vida: codificacin, pruebas de unidades, integracin y pruebas de sistema. Cuando alguna de las pruebas no resulta positiva es necesario repetir la codificacin o la integracin y probar de nuevo. La fase de codificacin constituye el ncleo central en cualquiera de los modelos y tiene una importancia fundamental ya que elabora los programas fuente. Previamente a la codificacin es necesario elegir el lenguaje que se emplear as como la metodologa de programacin. Tambin se pueden establecer en el equipo unas normas y un estilo de programacin comn, lo que mejorar la coordinacin y facilitar el trabajo. Adems se consigue facilitar el mantenimiento y mejorar la reusabilidad del software. Cuando el resultado de las pruebas no sea satisfactorio ser necesario modificar el cdigo, lo que podr introducir nuevos errores. Si la programacin es estructurada ser ms fcil localizar la disfuncin y la posterior modificacin y las pruebas del cdigo, dnde podemos introducir puntos de test.
INGENIERA DEL SOFTWARE Javier Martn 86

LENGUAJES DE PROGRAMACIN

Aunque los lenguajes han evolucionado mucho desde los aos 50 todava estn ms prximos a la mquina que al pensamiento humano. Los lenguajes suelen adoptar los avances metodolgicos que se producen en el desarrollo del software. Ej.: C y C++ DESARROLLO HISTRICO, muchos han sido desarrollados con fines experimentales y muy pocos han llegado a ser utilizados industrialmente: 1 GENERACIN: muy prximos al lenguaje mquina Ensamblador, asocia a cada instruccin de la mquina un nemnico 2 GENERACIN: no dependen de la CPU, se programa de manera simblica, en alto nivel. FORTRAN (FORula TRANslator), para aplicaciones cientficas COBOL, para procesamiento de informacin. Supone el 70 % ALGOL, da gran importancia a la tipificacin de datos BASIC, sencillo y fcil de aprender. Desarrollado para el PC. 3 GENERACIN: programacin estructurada con declaracin de tipos. Los ltimos van asociados a otros paradigmas. PASCAL, fue diseado para la enseanza de la programacin estructurada. Tipificacin rgida y no contempla la codificacin por separado MDULA-2, descendiente de pascal, se incorpora la estructura de mdulo. Se mejora modularidad, concurrencia, abstraccin y ocultacin C, desarrollado para la codificacin del UNIX. Flexible y potente. No hay restricciones sobre las operaciones con distintos tipos. ADA, descendiente de pscal, mucho ms potente y complejo. Incorpora modularidad, abstraccin, ocultacin, concurrencia y sincronizacin entre tareas. SMALLTALK, precursos de los lenguajes orientados a objetos C++, incorpora en C los mecanismos de la POO: ocultacin, clases, herencia y polimorfismo. EIFFEL, permite la definicin de clases genricas, herencia mltiple y polimorfismo. LISP, lenguaje funcional usado en IA y sistemas expertos. Basado en listas admite recursividad. Maneja bien los smbolos PROLOG, lenguaje lgico en que se construye una base de conocimiento basada en reglas a partir de la cual podemos inferir nuevos hechos o reglas. 4 GENERACIN: mayor grado de abstraccin. Se agrupan en: BASES DE DATOS; como SQL permiten acceder y manipular la informacin. GENERADORES DE PROGRAMAS, son eficientes en un dominio de aplicaciones limitado. La mayora producen aplicaciones de gestin y la salida va en cobol, aunque se han desarrollado herramientas CASE que generan programas en C++ o ADA. CLCULO, hojas de clculo, herramientas de simulacin y diseo para el control, etc. OTROS: herramientas para la especificacin y verificacin formal de programas, lenguajes de simulacin, de prototipos, etc.

INGENIERA DEL SOFTWARE Javier Martn

87

PRESTACIONES DE LOS LENGUAJES: ESTRUCTURAS DE CONTROL

se incluyen aqu, adems de las caractersticas propias de la programacin estructurada, el manejo de excepciones y la concurrencia. Programacin estructurada: secuencia, iteracin y seleccin (verdadero-falso y por casos) Manejo de excepciones: errores humanos, fallos hardware, errores software, datos de entrada vacos, valores fuera de rango, etc. (estructuras exception when y raise). Concurrencia, tareas simultneas, sincronizacin, comunicacin e interbloqueos. Los lenguajes han implementado la posibilidad de lanzar tareas concurrentes de distintas formas:

CORRUTINAS, tienen una estructura semejante a subprogramas pero con una transferencia del control ms flexible. El avance en la ejecucin de las corrutinas se produce segn el avance entre ellas. FORK-JOIN, es la propuesta de UNIX. COBEGIN-COEND, entre estas palabras se inician todas las tareas y se finalizan. Es posible el anidamiento. PROCESOS; cada tarea se declara como un proceso y estos y se ejecutan concurrentemente. En algunos casos es posible lanzar dinmicamente nuevos procesos una vez iniciado el programa. PARA LA COMUNICACIN ENTRE TAREAS.
VARIABLES COMPARTIDAS SEMFOROS REGIONES CRTICAS MONITORES PASO DE MENSAJES CSP LLAMADA A PROCEDIMIENTOS REMOTOS REDENZVOUS, DE ADA

INGENIERA DEL SOFTWARE Javier Martn

88

PRESTACIONES DE LOS LENGUAJES: ESTRUCTURAS DE DATOS

DATOS SIMPLES. Para los eneros hay que tener en cuenta el rango posible y para los de coma flotante la precisin. En ocasiones tambin permiten el manejo de complejos.

Otros tipos simples son char y string, para el manejo de cadenas. Los tipos enumerados tambin pueden resultar tiles, un tipo enumerado muy frecuente son los booleanos. En ocasiones los lenguajes permiten utilizar subrangos.

DATOS COMPUESTOS, son combinaciones de datos simples y compuestos ya definidos. Pueden ser homogneos como los ARRAYS y heterogneos como los RECORDS o STRUCTS.

Para el manejo de estructuras dinmicas de datos muchos lenguajes incluyen punteros

CONSTANTES, en los lenguajes modernos se pueden declarar constantes simblicas, sin indicar directamente su valor numrico. COMPROBACIN DE TIPOS, se pueden distinguir 5 niveles:

Nivel 0: sin tipos, no es posible declarar nuevos tipos y todos los datos deben pertenecer a tipos predefinidos Nivel 1: tipado automtico, el compilador decide cul es el tipo ms adecuado para cada dato. Nivel 2: tipado dbil, el compilador hace inferencias sobre los tipos y solo son posibles determinadas conversiones Nivel 3: tipado semirgido, todos los datos deben ser declarados con su tipo Nivel 4: tipado fuerte, aqu adems de declarar los tipos, el programador est obligado a hacer explcita cualquier conversin de tipos. ABSTRACCIONES FUNCIONALES TIPOS ABSTRACTOS DE DATOS OBJETOS

ABSTRACCIONES Y OBJETOS.

MOODULARIDAD. Se requiere la compilacin por separado. Adems se introducen de forma redundante la declaracin y la definicin de cada mdulo, para permitir al compilador hacer comprobaciones acerca de la consistencia. C y modula-2 lo tienen, pero pascal es monoltico.

INGENIERA DEL SOFTWARE Javier Martn

89

CRITERIOS DE SELECCIN DEL LENGUAJE

El lenguaje es uno de los elementos ms importantes de cualquier desarrollo y tiene una influencia decisiva en la depuracin y el mantenimiento dela aplicacin. Criterios: IMPOSICIN DEL CLIENTE, a veces para disminuir los costes de desarrollo y mantenimiento que se producen cuando una empresa utiliza lenguajes diferentes. TIPO DE APLICACIN, hay lenguajes orientados a un campo de aplicacin concreto.

Aplicaciones tiempo real crticas -> ensamblador Gestin -> cobol rea cientfico-tcnica -> Fortran, Pascal, C Inteligencia artificial -> Lisp, Prolog Orientado a objeots ->> Eifel, C++

DISPONIBILIDAD Y ENTORNO, hay que comprobar los compiladores existentes para la plataforma elegida. Estudio comparativo de eficiencia con un programa de prueba. Herramientas del entorno de desarrollo: editor, montador, depurador, control versiones, manejo de libreras, etc. EXPERIENCIA PREVIA, aprovechar la experiencia aumenta el rendimiento y disminuye las posibilidades de error. La formacin supone una fuerte inversin. RESUABILIDAD, organizacin de libreras que faciliten la bsqueda y almacenamiento de mdulos reutilizables. TRANSPORTABILIDAD, depende del lenguaje USO DE VARIOS LENGUAJES, no es aconsejable a no ser que las distintas partes sean ms fciles de desarrollar en lenguajes concretos. Hay que tener en cuenta la compatibilidad de los compiladores
INGENIERA DEL SOFTWARE Javier Martn 90

ASPECTOS METODOLGICOS

Estos aspectos pueden mejorar la codificacin bajo determinados puntos de vista: claridad, manejo de errores eficiencia y transportabilidad. Normas y estilo, para conseguir un trabajo del equipo homogneo. Ejemplos: Formato y contenido del as cabeceras de cada mdulo Formato y contenido para los comentarios Uso del indentado Eleccin de nombre y uso de maysculas Restricciones sobre el tamao del os mdulos, evitar anidamiento excesivo, no usar goto, etc. Manejo de errores. Las causas de los errores pueden estar en el hardware o en el software, incluso de pueden producir por la introduccin de datos incorrectos. DEFECTO, incorreccin en el software. Pueden permanecer ocultos hasta que no se ejecutan determinadas partes del programa FALLO, elemnto del programa que no funciona correctamente, produciendo un resultado errneo ERROR, estado no vlido de un programa al que se llega como consecuencia de un fallo. Al codificar podemos adoptar distintas actitudes ante los errores: NO CONSIDERAR LOS ERRORES, no es realista esta postura PREVENCIN DE ERRORES, consiste en detectar los fallos antes de que provoquen un error. Hay que evitar la propagacin de errores y tener siempre a la salida un resultado correcto o una seal de fallo. RECUPERACIN DE ERRORES, Cuando no es posible depurar todos los fallos es necesario hacer un tratamiento de errores para devolver al programa a un estado vlido y evitar que el error se propague 1. Deteccin del error 2. Recuperacin del error. Se pueden usar dos esquemas en general: 1. RECUPERACIN HACIA DELANTE, hay que programas un mecanismo de excepciones para que cuando se detecte el error se corrija el estado y se contine correctamente la ejecucin. 2. RECUPERACIN HACIA ATRS, corrige el estado no vlido restaurando el programa a un estado correcto anterior,

Una transaccin es una operacin que puede terminar con xito o con fallo, en cuyo caso se aborta y se restaura el estado de antes de comenzar dicha transaccin.

INGENIERA DEL SOFTWARE Javier Martn

91

ASPECTOS METODOLGICOS: EFICIENCIA Y TRANSPORTABILIDAD

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

Tabular clculo complejos Expansin en lnea, emplear macros en vez de subrutinas Simplificar las expresiones aritmticas y lgicas Sacar fuera de los bucles lo que no sea necesario repetir Usar estructuras de datos de acceso rpido Evitar operaciones en coma flotante, mejor en coma fija Evitar conversiones innecesarias de tipos

TRANSPORTABILIDAD DEL SOFTWARE, no solo es rentable a corto plazo para obtener versiones para diferentes plataformas, a medio y largo plazo facilita el mantenimiento y la adaptacin de la aplicacin a las nuevas arquitecturas.

Los factores para la transportabilidad son:

Utilizacin de estndares Aislar las peculiaridades, colocndolas en mdulos separados. Se procurar evitar aquellos elementos no consolidados y que pueden estar sujetos a futuros cambios o revisiones.

Las peculiaridades de los distintos tipos de computadores depende de la arquitectura y del sistema operativo utilizado.
INGENIERA DEL SOFTWARE Javier Martn 92

TCNICAS DE PRUEBAS

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

buena prueba encuentra los errores y no los encubre Para determinar si hubo error es necesario conocer el resultado correcto Deben participar codificador y diseador Al corregir un error se pueden introducir otros nuevos No es posible demostrar la ausencia de defectos mediante pruebas No son posibles las pruebas exhaustivas. Con el menor esfuerzo posible hay que detectar el mximo n de defectos, en especial los ms graves. Las pruebas se realizan en un entorno de ejecucin controlado, para asegurar la estabilidad en los pruebas y automatizar en lo posible este proceso. INGENIERA DEL SOFTWARE Javier Martn 93

TCNICAS DE PRUEBAS DE UNIDADES: CAJA NEGRA

Las tcnicas de pruebas de unidades siguen dos estrategias fundamentales: PRUEBAS DE CAJA NEGRA, se ignora por completo la estructura interna del programa y se comprueba la correccin de entradas y salidas del programa.

Lo importante es la elaboracin de los casos de prueba con el objetivo de descubrir los errores e incorrecciones. Mtodos:

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

INGENIERA DEL SOFTWARE Javier Martn

94

TCNICAS DE PRUEBAS DE UNIDADES: CAJA TRANSPARENTE

Se tiene en cuenta la estructura interna del mdulo. Los casos de prueba deben conseguir que: Todas las decisiones se ejecuten en uno y otro sentido Todos los bucles se ejecuten en los supuestos ms diversos posibles Todas las estructuras de datos se modifiquen y consulten alguna vez La complejidad de los mdulos dificulta realizar exhaustivas pruebas de caja transparente. Conviene que participen expertos con un conocimiento amplio de las estructura del programa. Mtodos:

CUBRIMIENTO LGICO, consiste en no dejar ninguna seccin PRUEBAS DE BUCLES, que son elemento esencial en del cdigo sin ejecutar en pruebas. Se llama camino bsico a cualquier programa. Casos: cualquier recorrido sobre el diagrama de flujo que nos permita Bucles con n no acotado de repeticiones, probar 0, 1, 2, llegar al final desde el punto de entrada. bastantes y muchas iteraciones. Hay que determinar el conjunto de caminos bsicos que recorran todas las lneas de flujo del programa al menos una Bucles con n mximo de repeticiones, probar 0, 1, 2 bastantes, M-1, M y M+1 iteraciones vez. N mximo de caminos = N predicados + 1 En un segundo nivel de casos de prueba se trata de que se ejecuten todas las combinaciones de caminos bsicos por parejas Bucles anidados, el n de pruebas para comprobar todas las situaciones crece. EMPLEO DE LA INTUICIN, conocer con detalle la estructura del mdulo y tener experiencia.

A otros niveles se generan casos de pruebas para que se ejecuten un n significativo de combinaciones de caminos INGENIERA DEL SOFTWARE Javier Martn bsicos

95

TCNICAS DE PRUEBAS DE UNIDADES: CAJA TRANSPARENTE

Diagramas de flujo con 3 y con 4 predicados lgicos simples

INGENIERA DEL SOFTWARE Javier Martn

96

ESTIMACIN DE ERRORES NO DETECTADOS

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

En funcin de los resultados se valorar la necesidad de preparar nuevos casos de prueba.

INGENIERA DEL SOFTWARE Javier Martn 97

ESTRATEGIAS DE INTEGRACIN

Se integran los mdulos del sistema para conformar el sistema completo. Causas de error: Desacuerdos en el interfaz entre mdulos Interaccin indebida entre mdulos Imprecisiones acumuladas Estrategias bsicas para la integracin: INTEGRACIN BIG BANG, en un nico paso se integran todos los mdulos, de forma que todos los defectos se manifiestan a la vez. Solo recomendable para sistemas pequeos. INTEGRACIN DESCENDENTE, se parte de un mdulo principal P, que se prueba con mdulos de andamiaje, los cuales van siendo sustituidos por los verdaderos de forma progresiva por niveles. Los mdulos de andamiaje;

No hacen nada y solo sirven para comprobar el interfaz Imprimen un mensaje de seguimiento, con informacin de la llamada Suministran un resultado fijo Suministran un resultado aleatorio Suministran un resultado tabulado u obtenido con un algoritmo simplificado

El trabajo de elaborar estos mdulos puede ser aprovechado para hacer un prototipo y mostrar al cliente un avance del programa. Inconvenientes:

Impide el trabajo en paralelo en las pruebas Es difcil buscar los casos de pruebas especiales o dirigidas a los ltimos mdulos integrados

INTEGRACIN ASCENDENTE, se codifican por separado y en paralelo todos los mdulos del nivel ms bajo. Para probarlos se codifican mdulos gestores o conductores que los hacen funcionar independientemente o en combinaciones sencillas. Las ventajas son:

Facilita el trabajo en paralelo Facilita el ensayo de situaciones especiales

La Integracin Sandwich consiste en realizar integracin ascendente con los mdulos de nivel ms bajo y descendente con los de nivel ms alto. INGENIERA DEL SOFTWARE Javier Martn 98

INTEGRACIN DESCENDENTE Y ASCENDENTE

INGENIERA DEL SOFTWARE Javier Martn

99

PRUEBAS DE SISTEMA

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

Pruebas alfa, son las primeras pruebas que se realizan en un entorno controlado donde el usuario tiene el apoyo de alguien del equipo de desarrollo Pruebas beta, los usuarios trabajan con el sistema en un entorno real y sin ayuda, anotando los problemas que se le presentan
INGENIERA DEL SOFTWARE Javier Martn 100

Tema 6: AUTOMATIZACIN DE PROCESO DE DESARROLLO

INGENIERA DEL SOFTWARE Javier Martn

101

ENTORNOS DE DESARROLLO SOFTWARE

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

OBJETIVO Y CLASIFICACIN DE ENTORNOS DE DESARROLLO

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

CLASIFICACIN DE ENTORNOS POR NIVELES

Nivel de servicio. Corresponde a un producto que realiza una funcin u operacin elemental, que una vez invocada no se interrumpe (compilador). Nivel de herramienta. Producto software que permite invocar diferentes servicios u operaciones correspondientes a una misma actividad individual. (editor de textos). Nivel de banco de trabajo o equipo de herramientas. Corresponde a un producto CASE que automatiza o soporta un perfil concreto de actividad profesional dentro del proceso de desarrollo. Un banco de trabajo suele englobar varias herramientas, integradas con una interfaz de usuario uniforme. En la actividad de codificacin el banco de trabajo se denomina entorno de programacin. Entorno de desarrollo. Producto CASE que soporta el proceso completo de desarrollo de software (IPSE o ICASE). Los dos primeros niveles se describen a veces como uno solo.

INGENIERA DEL SOFTWARE Javier Martn

104

HERRAMIENTAS DE SOFTWARE
Herramientas clsicas. Editor de texto. Compilador Montador de enlaces. Construye ejecutables combinando varios ficheros objeto. Gestor de librera. Combina ficheros objeto en una librera. Herramienta MAKE. Automatiza la actualizacin de los ficheros a partir de otros. Intrprete interactivo. Casi Constituye un entorno de programacin completo (si lo es se debe clasificar a nivel de banco de trabajo y no de herramienta). Engloba funciones equivalentes a las de edicin, compilacin, montaje y ejecucin. Compilador/Intrprete. Procesador de un lenguaje interpretado de forma no interactiva.Incluye un compilador a cdigo intermedio y un intrprete de ejecucin de dicho cdigo intermedio con todas las libreras de soporte. No incluye funciones de editor de programas. Depurador absoluto. Ejecuta el programa de forma controlada. Resulta incomodo de usar ya que hace referencia a posiciones de memoria y a los registros del procesador. Depurador simblico. Realiza una funcin anloga al anterior pero con referencia al cdigo fuente por lo que es ms cmodo de usar. Herramientas evolucionadas. Editores orientados al lenguaje. Son editores de estructura. Herramienta MAKE automtica. Se incorpora la funcin MAKE al compilador. Manejador de versiones. Almacena de forma organizada y eficiente una serie de versiones del mismo elemento software. Se suelen usar desde las utilidades MAKE al recompilar una aplicacin en desarrollo. Procesadores/Analizadores de cdigo fuente. Grupo en que se pueden incluir diferentes herramientas que procesan el texto fuente para obtener mediciones, generar tablas de referencias, encolumnar etc. Estas funciones podran estar incorporadas en los compiladores. Procesadores de documentos. No son especficos del desarrollo pero son un soporte fundamental. Herramientas de control de pruebas. Ayudan a la realizacin de pruebas unitarias o de integracin. Herramientas de control de cambios. Ayudan a la realizacin del desarrollo y al mantenimiento de aplicaciones. Procesadores de ficheros de texto. Herramientas de 4 generacin. Hojas de clculo. Procesadores de documentos Gestores de bases de datos Lenguajes de 4 generacin. Generadores de programas.

INGENIERA DEL SOFTWARE Javier Martn

105

ENTORNOS INTEGRADOS
Integracin de datos. Significa que la informacin almacenada en el entorno es gestionada de manera uniforme, con independencia de las transformaciones que se hagan con cada elemento de informacin. Debe de conseguir: Interoperatividad entre herramientas. No redundancia de datos Consistencia de datos. Paso de datos de una herramienta a otra. La integracin de datos puede conseguirse de diversas maneras: Transferencia directa de datos de una herramienta a otra. Eficiente pero poco flexible. Complicada para integrar muchas herramientas diferentes. Transferencia mediante ficheros. Es la ms sencilla. Existe un formato normalizado (CDIF). Transferencia basada en comunicacin. Alternativa a la anterior y puede ser usada en sistemas distribuidos y en sistemas abiertos. Repositorio comn. Se utiliza en los entornos modernos con un grado de integracin elevado. Integracin de control. Consiste en la combinacin flexible de funciones para cumplir con las particularidades del proceso y actividades que hay que informatizar. El mayor grado se consigue cuando desde una herramienta se puede invocar funciones de otra herramienta. Exige como paso previo la integracin de los datos. Integracin de la presentacin. Trata de realizar la interaccin con el usuario de manera uniforme, con cierta independencia dela funcin o herramienta en uso. Para ello se deben conseguir los objetivos de un sistema amigable: Limitar el nmero de formas de interaccin diferentes. Usar formas de interaccin y presentacin adecuadas al modelo mental que el usuario tiene del entorno. Satisfacer los tiempos de respuesta esperados y dar indicacin del avance del proceso en caso de tratamiento de larga duracin. Mantener informacin til a disposicin del usuario. Integracin del proceso. Consiste en que las herramientas se combinan de manera que apoyan o fuerzan el uso de una metodologa de desarrollo definida. Este modo exige una buena integracin de control y datos. El proceso de desarrollo puede definirse en base a los siguientes elementos. Un paso del desarrollo es una unidad de trabajo concreta que produce un resultado (por ejemplo revisin del DDD). Un suceso o evento es un condicin que ocurre durante la ejecucin de un paso y que puede desencadenar la ejecucin de una accin asociada (compilacin de un mdulo). Una restriccin del desarrollo es una limitacin que debe cumplirse. Un buen grado de integracin del proceso exige que todo los pasos, eventos y restricciones que definen de forma natural la metodologa de desarrollo a utilizar, sean representables y tratables dentro del entorno.

INGENIERA DEL SOFTWARE Javier Martn

106

ENTORNOS INTEGRADOS: EL REPOSITORIO CASE

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

INGENIERA DEL SOFTWARE Javier Martn

107

BANCOS O EQUIPOS DE TRABAJO

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

ENTORNOS ORIENTADOS AL PROCESO

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