Is

590 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
590
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 11/05/13 ,
  • Is

    1. 1. INGENIERÍA DELSOFTWAREJavier MartínCentro Asociado de Móstoles /Tres CantosUNED
    2. 2. INGENIERÍA DEL SOFTWARE Javier Martín 2IntroducciónJAVIER MARTIN (jmartin@escet.urjc.es)TUTORIAS: JUEVES/VIERNES de 7 a 9PLAN DE TRABAJOExposición de los temas y mediantetransparencia, abundando en los puntosmás importantes.Resolución de dudasPropuesta y resolución de ejercicios yproblemas
    3. 3. INGENIERÍA DEL SOFTWARE Javier Martín 3TemasINTRODUCCIÓNESPECIFICACIÓN DEL SOFTWAREFUNDAMENTOS DEL DISEÑOSOFTAWARETÉCNICAS GENERALES DE DISEÑOSOFTWARECODIFICACIÓN Y PRUEBASAUTOMATIZACIÓN Y PROCESO DEDESARROLLO
    4. 4. INGENIERÍA DEL SOFTWARE Javier Martín 4Tema 1: INTRODUCCIÓN
    5. 5. INGENIERÍA DEL SOFTWARE Javier Martín 5Concepto de Ingeniería de SistemasConcepto de sistema, conjunto de cosas que ordenadamenterelacionadas entre sí contribuyen a un determinado objeto. De formarecursiva, las partes de un sistema pueden ser consideradas comonuevos sistemas (subsistemas).Los sistemas informáticos están compuestos por ordenadores y susperiféricos. Entre ellos podemos distinguir dos tipos de subsistemas:Sistemas Hardware, son los elementos materiales, los que sepueden tocar.Sistemas Software, los programas que gobiernan elfuncionamiento del computador.El objetivo de los sistemas informáticos es el tratamiento de lainformación: almacenamiento, elaboración y presentación de datos. Deesta forma se automatizan determinadas acciones.En la concepción del sistema informático no solo se decide el trabajo arealizar, sino también cómo ha de ser utilizado por los usuarios.
    6. 6. INGENIERÍA DEL SOFTWARE Javier Martín 6Concepto de Ingeniería del SoftwareCaracterísticas del software (lo contrario para el hardware):No se desgasta ni envejece, y por este motivo no requierereparaciones ocasionalesSu duplicación es poco costosa, lo caro es el desarrolloPuede ser modificado fácilmente, tanto que es necesario un controlde versionesLa Ingeniería del Software comprende las técnicas y procedimientosingenieriles para el desarrollo del software.La IS no se plantea solo una actividad de programación, previamenteson necesarias las fases de análisis y diseño y posteriormente laintegración y la verificación, incluso el manteniendo cuando el productoya está en explotación. (CICLO DE VIDA).Inicialmente la tarea de desarrollo era realizada individualmente porhábiles creativos, de forma poco disciplinada. El trabajo en equiposupone la división y organización del trabajo utilizando metodologíasde desarrollo.En los 70 y los 80 empiezan a usarse herramientas CASE (ComputerAided Software Engineering). En los 90 IPSE e ICASE.
    7. 7. INGENIERÍA DEL SOFTWARE Javier Martín 7La crisis del SoftwareSe produce cuando surge la necesidad de desarrollaraplicaciones software demasiado complejas, a mediadosde los 60.Para superar la crisis:Aparición de metodologías concretas de desarrolloConcepción de la Ingeniería del Software como disciplinaTrabajo en equipo y especialización (analistas,programadores, ...)No se ha llegado a una situación estable, sino a unaevolución permanente con avances continuos en la IS,forzados por el rápido abaratamiento y aumento decapacidad del hardware.
    8. 8. INGENIERÍA DEL SOFTWARE Javier Martín 8Mitos del SoftwareEl hardware es mucho más importante que elsoftwareEl software es fácil de desarrollarEl software consiste exclusivamente en programasejecutablesEl desarrollo del software es sólo una labor deprogramaciónEs natural que el software contenga errores
    9. 9. INGENIERÍA DEL SOFTWARE Javier Martín 9Formalización del proceso de desarrolloLa ingeniería supone la existencia de procesos bienestablecidos para la realización de actividades dedesarrollo, construcción, fabricación, etc.El ciclo de vida es el proceso de desarrollo ymantenimiento del software. Según el modelo elegido sedescriben un conjunto de actividades para llevar a cabo elciclo de vida,Los modelos clásicos:MODELO EN CASCADAMODELO EN VPrácticamente identifican actividades similares y sólo sediferencian en la forma de presentación.
    10. 10. INGENIERÍA DEL SOFTWARE Javier Martín 10MODELO EN CASCADA
    11. 11. INGENIERÍA DEL SOFTWARE Javier Martín 11MODELO EN CASCADAANÁLISIS, determinar qué debe hacer el software ->especificaciónDISEÑO, descomponer y organizar el sistema para que losmódulos puedan ser desarrollados por separadoCODIFICACIÓN, escribir el código fuente de cada móduloy realizar sobre ellos las pruebas necesariasINTEGRACIÓN, combinar todos los módulos y probar elsistema completo antes de pasar a su explotaciónMANTENIMIENTO, durante la explotación es necesariorealizar cambios ocasionales bien para corregir errores opara introducir mejoras,Se trata de aislar cada fase de las otras, lo que facilita laespecialización de los desarrolladores. Al final de cada fasese requiere un proceso de revisión`para evitar que loserrores se propaguen a fases posteriores provocando lavuelta atrás.
    12. 12. INGENIERÍA DEL SOFTWARE Javier Martín 12MODELO EN CASCADA AMPLIADO
    13. 13. INGENIERÍA DEL SOFTWARE Javier Martín 13MODELO EN CASCADACada fase debe generar una información de salida precisay suficiente:DOCUMENTOS DE REQUISITOS DEL SOFTWARE (SRD),es una especificación precisa y completa a partir de losrequisitos establecidos por el cliente.DOCUMENTO DE DISEÑO DEL SOFTWARE(SDD),descripción de la estructura global del sistema,especificación de qué debe hacer cada uno de los módulos yde cómo se combinan.CÓDIGO FUENTE, el programa debidamente comentado(documentación interna).SISTEMA SOFTWARE, el ejecutable producto dela fase deintegración y la documentación de las pruebas realizadas.DOCUMENTOS DE CAMBIOS, después de cadamodificación realizada en la fase de mantenimiento: problemadetectado y solución adoptada
    14. 14. INGENIERÍA DEL SOFTWARE Javier Martín 14MODELO EN V
    15. 15. INGENIERÍA DEL SOFTWARE Javier Martín 15MODELO EN V AMPLIADO
    16. 16. INGENIERÍA DEL SOFTWARE Javier Martín 16MODELO EN VIncluye fases similares a las del modelo encascada pero de forma jerárquica. En horizontal serepresenta el avance en el desarrollo y en verticalel nivel de detalle.VERIFICACIÓN, comprobación de que una partedel sistema cumple con sus especificaciones.VALIDACIÓN, comprobación de que un elmentosatisface las necesidades del usuario identificadasdurante el análisis.
    17. 17. INGENIERÍA DEL SOFTWARE Javier Martín 17PROTOTIPOSEn los modelos clásicos se insiste en las actividades derevisión de resultados al final de cada fase para evitar lavuelta atrás, que no se contempla de una forma organizaday resulta muy costosa. Están orientados a una forma dedesarrollo lineal.PROTOTIPO, es un sistema auxiliar que permite probarexperimentalmente soluciones parciales a los requisitos delsistemaPara que el coste de desarrollo del prototipo sea bajo enrelación al del sistema final podemos:Limitar las funcionesLimitar su capacidadLimitar su eficienciaEvitar limitaciones de diseño, utilizando un hardware máspotente que el que ejecutará el sistema finalReducir la parte a desarrollar
    18. 18. INGENIERÍA DEL SOFTWARE Javier Martín 18PROTOTIPOS RÁPIDOSSu finalidad es solo adquirir experiencia, no seaprovechan como producto (usar y tirar). Sedenominan maquetas cuando su funcionalidad ocapacidad es muy limitada.El sistema final se codifica totalmente partiendo decero, no se aprovecha el código del prototipoLo importante de estos prototipos es que sedesarrollen en poco tiempo.
    19. 19. INGENIERÍA DEL SOFTWARE Javier Martín 19PROTOTIPOS RÁPIDOS
    20. 20. INGENIERÍA DEL SOFTWARE Javier Martín 20PROTOTIPOS EVOLUTIVOSEn este caso se intenta aprovechar al máximo el código delprototipo, y para ello se emplea el mismohardware/software del sistema final.Se realizan fases de análisis y diseño parcial, que se vanampliando hasta construir el sistema final medianteadiciones sucesivas.Se puede considerar un modelo en cascada en bucle, demanera que en cada iteración se va avanzando en eldesarrollo.HERRAMIENTAS PARA EL DESARROLLO DEPROTOTIPOS, se emplean lenguajes de 4ª generación,que son de alto nivel y de tipo declarativo. También seemplean lenguajes de especificación, como VDM y Z. Sidisponemos del compilador correspondiente podemosobtener automáticamente el código del prototipo.En el desarrollo de prototipos es clave la reutilización desoftware.
    21. 21. INGENIERÍA DEL SOFTWARE Javier Martín 21PROTOTIPOS EVOLUTIVOS
    22. 22. INGENIERÍA DEL SOFTWARE Javier Martín 22MODELO EN ESPIRALPuede considerarse como un refinamiento del modeloevolutivo general que introduce el análisis de riesgo comoelemento fundamental para guiar la evolución del procesode desarrollo.En la dimensión radial se representa el esfuerzo realizadoen el desarrollo (siempre creciente)En cada iteración 4 fases:PLANIFICACIÓN, determina que parte del desarrollo seabordará en ese ciclo.ANALISIS DE RIESGO, evaluar diferentes alternativas paraesa parte del desarrollo seleccionando la más ventajosa ytomando precauciones para evitar los posiblesinconvenientes.INGENIERÍA, las actividades de los modelos clásicosEVALUACIÓN, se analizan los resultados de la fase deingeniería.
    23. 23. INGENIERÍA DEL SOFTWARE Javier Martín 23MODELO EN ESPIRAL
    24. 24. INGENIERÍA DEL SOFTWARE Javier Martín 24MANTENIMIENTO DEL SOFTWAREEl mantenimiento no representa una actividad específica,sino que consiste en rehacer parte de las actividadescorrespondientes a las otras fases del desarrollo paraintroducir cambios sobre una aplicación ya en fase deexplotación.MANTENIMIENTO CORRECTIVO, su finalidad es corregirerrores que no fueron detectados en el desarrollo delproducto.MANTENIMIENTO ADAPTATIVO, modificar una aplicaciónpara adaptarla a las nuevas necesidades del entorno.MANTENIMIENTO PERFECTIVO, se trata de ir obteniendoversiones mejoradas del producto
    25. 25. INGENIERÍA DEL SOFTWARE Javier Martín 25GESTIÓN DE CAMBIOSEl mantenimiento supone la realización de una serie decambios sucesivosSi afectan a la mayor parte del sistema se puede plantearcomo un nuevo desarrollo.Cada cambio debe ser documentado con:INFORME DEL PROBLEMA, que ocasiona el cambio. Sueleser propuesto por el cliente.INFORME DE CAMBIO, describe la solución dada alproblema y el cambio realizadoREINGENIERÍA, es necesaria cuando el desarrollo de unaaplicación no está documentado y se dispone solamentedel código. Se llama también ingeniería inversa porquesupone reconstruir y documentar las fases de análisis ydiseño llegando a la estructura modular de la aplicación ylas dependencias entre módulos y funciones. Estasactividades organizan y documentan un sistema deficiente.
    26. 26. INGENIERÍA DEL SOFTWARE Javier Martín 26GARANTÍA DE CALIDADPara evaluar la calidad son necesarias técnicas de aplicación de métricas precisastanto sobre los productos software como a sus procesos de desarrollo.McCall propone un esquema basado en valoraciones a 3 niveles:FACTORES, valoración significativa de la calidad en base a los criteriosestablecidosCRITERIOS, aspectos de nivel intermedio que influyen en los factores de calidadMÉTRICAS, mediciones puntuales de determinadas características del producto.Entre los factores de calidad tenemos:CORRECCIÓN, grado en que cumple con las especificacionesFIABILIDAD, grado de ausencia de fallosEFICIENCIA, reilación entre la cantidad de resultados y los recursos requeridosSEGURIDAD, dificultad para el acceso a datos por personas no autorizadasFACILIDAD DE USO, esfuerzo requerido para el aprendizaje de la aplicaciónMANTENIBILIDAD. Facilidad para corregir el producto en caso necesario.FLEXIBILIDAD, facilidad para modificar el productoFACILIDAD DE PRUEBA, depende del esfuerzo requerido para comprobar sucorrección o fiabilidadTRANSPORTABILIDAD, facilidad para adaptar el producto a otra plataformaREUSABILIDAD, facilidad para usar partes del producto en otros desarrollosINTEROPERATIVIDAD, facilidad del producto para trabajar con otros
    27. 27. INGENIERÍA DEL SOFTWARE Javier Martín 27PLAN DE GARANTÍA DE CALIDAD (SQAP)Es un documento formal para organizar el proceso dedesarrollo software de manera que se asegure la calidaddel producto final. Debe contemplar:Organización, dirección y seguimiento de los equipos dedesarrolloModelo de ciclo de vida a seguir, detallando fases yactividadesDocumentación requerida, determinando contenido y guiónde cada documentoRevisiones y auditorias, para garantizar que las actividades ylos documentos son correctosOrganización de las pruebas, a distintos nivelesOrganización de la etapa de mantenimiento, determinandocómo gestionar la realización de cambios
    28. 28. INGENIERÍA DEL SOFTWARE Javier Martín 28REVISIONESConsiste en inspeccionar el resultado de una actividad paradeterminar si es aceptable o contiene defectos que han deser subsanados.Las revisiones deben ser formalizadas y contempladas enel modelo de ciclo de vida:Deben ser realizadas por un grupo de personas y noindividualmenteEl grupo de be ser reducidoDebe ser imparcial, nada que ver con los desarrolladoresSe debe revisar el producto, pero no el productor ni elproceso de producciónSe debe establecer de antemano una lista formal decomprobacionesSe debe levantar acta de la reunión de revisión, recogiendolas decisiones tomadas
    29. 29. INGENIERÍA DEL SOFTWARE Javier Martín 29PRUEBASConsiste en hacer funcionar el producto o unaparte de él y comprobar si los resultados soncorrectos.No permite garantizar la calidad del producto. Engeneral no es posible probar un producto de formaexhaustiva, debido a su complejidad.
    30. 30. INGENIERÍA DEL SOFTWARE Javier Martín 30GESTIÓN DE CONFIGURACIÓNCONFIGURACIÓN, disposición de las partes que componen una cosa y ledan su peculiar figura.La CONFIGURACÏÓN SOFTWARE se refiere a la manera en que diversoselementos se combinan para construir un producto software.Se han de combinar todos los elementos que intervienen en el desarrollo:Documentos del desarrolloCódigo fuenteProgramas, datos y resultado de las pruebasManuales de usuarioDocumentos de mantenimiento, informes de problemas y cambiosPrototipos intermediosNormas particulares del proyectoDado que los elementos software van evolucionando a lo largo deldesarrollo se requiere:Control de versiones, almacenar de forma organizada las sucesivasversiones de cada elemento de la configuración.Control de cambios, garantizar que las diferentes configuraciones delsoftware se componen de elementos compatibles entre sí (línea base).
    31. 31. INGENIERÍA DEL SOFTWARE Javier Martín 31NORMAS Y ESTÁNDARESIEEE, Institute of Electrical and ElectronicsEngineer de USA [IEEE93]DoD, Departament od Defense de USA [DoD88]ESA, Agencia Europea del Espacio [ESA91]ISO, organismo internacional de normalización(International Standars Organization). En EspañaAENOR.METRICA-2, desarrollada por el Consejo Superiorde Informática del MAP. Se basa en lametodología de análisis y diseño deYourdon/DeMarco.
    32. 32. INGENIERÍA DEL SOFTWARE Javier Martín 32Tema 2:ESPECIFICACIÓN DE SOFTWARE
    33. 33. INGENIERÍA DEL SOFTWARE Javier Martín 33MODELADO DE SISTEMASEl análisis y la definición de los requisitos debe dar lugar ala especificación software, en la que se concretan lasnecesidades que se desean cubrir y se fijan lasrestricciones con las que debe trabajar el software.El modelado de los sistemas tiene como objetivo entendermejor el comportamiento requerido y facilitar lacomprensión de los problemas planteados. Se trata deestablecer modelos conceptuales que reflejen laorganización de la información y las diversastransformaciones que se deben llevar a cabo con dichainformación.Las metodologías de análisis de requisitos tratan defacilitara obtención de uno o varios modelos que detallen elcomportamiento deseado del sistema.
    34. 34. INGENIERÍA DEL SOFTWARE Javier Martín 34CONCEPTO DE MODELOUn modelo conceptual es una abstracción lógico-matemática del mundo real que facilita la comprensión delproblema a resolver. Se trata de ofrecer una visión de latonivel, sin descender a explicar detalles concretos delmismo. Indica QUÉ hace el sistema y no CÓMO lo debehacer.Los OBJETIVOS a cubrir con los modelos son:Facilitar la comprensión de l problemaEstablecer un marco para la discusión que simplifique ysistematice el análisisFijar las base para el diseñoFacilitar la verificación del cumplimiento de los objetivos delsistema
    35. 35. INGENIERÍA DEL SOFTWARE Javier Martín 35TÉCNICAS DE MODELADO (I)DESCOMPOSICIÓN. MODELO JERARQUIZADO, aplica el “divide yvencerás”, y así el problema queda dividido en un subconjunto desubproblemas. Se trata de una descomposición funcional que sedenomina horizontal o bien se descompone tratando de detallar laestructura, de forma vertical. Para completar el modelado es necesarioestablecer los interfaces entre las partes del sistema para posibilitar elfuncionamiento del sistema global.APROXIMACIONES SUCESIVAS, podemos tomar como partida elmodelo de un sistema similar, y luego mediante la experiencia delanalista y el conocimiento del problema que proporciona el experto seirán proponiendo modelos intermedios, discutiendo sus ventajas einconvenientes.EMPLEO DE DIVERSAS ANOTACIONES, el lenguaje naturalintroduce imprecisiones, repeticiones e incluso incorrecciones en elmodelo. Es recomendable emplear notaciones gráficas que seanentendibles por todos los que participan en el proyecto. Se suelerecurrir a notaciones precisas que combinan texto, tablas, diagramas ygráficos.
    36. 36. INGENIERÍA DEL SOFTWARE Javier Martín 36TÉCNICAS DE MODELADO (II)CONSIDERAR DISITNTOS PUNTOS DE VISTA, en laelaboración del modelo es necesario adoptar un determinadopunto de vista. Si así la descripción es insuficiente convieneadoptar más de uno.REALIZAR UN ANÁLISIS DEL DOMINIO, es decir en campode aplicación en que se enmarca el sistema a desarrollar. Hayque considerar:Normativa que afecta al sistemaOtros sistemas semejantesEstudios recientes en el campo de la aplicación, bibliografía, etc.Las ventajas de realizar un modelos más general son:Facilitar la comunicación entre el analista y el usuario del sistema,p.e. usando la misma terminología.Creación de elementos realmente significativos del sistema, si seajusta a la normativa específica establecida.Reutilización posterior del software desarrollado.
    37. 37. INGENIERÍA DEL SOFTWARE Javier Martín 37ANÁLISIS DE REQUISITOS DE SOFTWAREEl análisis es la fase de definición del futuro sistema y tiene una importancia decisivaen el desarrollo de todas las etapas posteriores.Con el análisis de requisitos se trata de caracterizar el problema a resolver. El“cliente” trabaja con el analista para elaborar las especificaciones y posteriormentese encargarán de verificar el cumplimiento de las mismas (contrato).El análisis debe producir un modelo válido necesario y suficiente para recoger todaslas necesidades y exigencias del sistema, así como las restricciones que los limiten.Para una especificación correcta se requiere:Completo y sin omisionesConciso y sin trivialidadesSin ambigüedadesSin detalles de diseño o implementaciónFácilmente entendible por el clienteSeparando requisitos funcionales u no funcionales (capacidades mínimas ymáximas, interfaces estándares, recursos necesarios, seguridad, fiabilidad,mantenimiento, etc.División y jerarquía del modelo global, con el fin de simplificar su comprensiónIncluyendo los criterios de validación del sistema, para comprobar si se ajusta alcontrato inicial.
    38. 38. INGENIERÍA DEL SOFTWARE Javier Martín 38TAREAS DEL ANÁLISISDependiendo de las características y complejidad del sistemase podrán seguir los siguientes pasos:ESTUDIO DEL SISTEMA EN SU CONTEXTO, análisis deldominio en un contexto globalizadorIDENTIFICACIÓN DE NECESIDADES, detectar necesidades demedios dentro de plazos y presupuestosANÁLISIS DE ALTERNATIVAS Y ESTUDIO DE VIABILIDAD,tanto técnica como económicaESTABLECIMIENTO DEL MODELO DEL SISTEMA, para lo quepodemos usar técnicas gráficas, texto, herramientas CASE, etc.ELABORACIÓN DEL DOCUMENTO DE ESPECIFICACIÓN DEREQUISITOS, dónde se recogen las conclusiones del análisis ysirve de punto de partida para el diseñador.REVISIÓN CONTINUADA DEL ANÁLISIS, a menudo en lasetapas de diseño e implementación se hace necesaria la revisiónde alguno de los requisitos, o bien por cambios de criterio delcliente
    39. 39. INGENIERÍA DEL SOFTWARE Javier Martín 39NOTACIONES PARA LA ESPECIFICACIÓNLa especificación es una descripción del modelo delsistema a desarrollar.Se debe usar una notación fácil de entender por el cliente:Lenguaje natural, utilizando explicaciones más o menosprecisas y exhaustivas. Es posible limitar precisiones yambigüedades si se establecen reglas de uso del lenguaje.Diagramas de flujo de datosDiagramas de transición de estadosDescripciones funcionales. Pseudocódigo. Se emplea unpreciso lenguaje natural estructurado. No se debe detallardemasiado el cómo, pues esto corresponde a la fase dediseño, donde se usan lenguajes estructurados como PLD.Descripción de datos, de trata de detallar la estructura internade los datos que maneja el sistema. En la metodologíaYourdon se conoce como diccionario de datos, incluyendonombre de cada dato, utilización y estructura.Diagramas de modelos de datos
    40. 40. INGENIERÍA DEL SOFTWARE Javier Martín 40DIAGRAMAS DE FLUJO DE DATOS (DFD)Se trata de realizar un modelo gráfico para representar el flujo de datosque entra en el sistema, las transformaciones que debe realizar y lasalida producida. También se representan las entidades externas lasistema que producen o consumen datos. El DFD inicial es el decontexto, posteriormente y de forma jerárquica se van desarrollandootros DFD’s que detallan las transformaciones, las entradas y salidasdel diagrama detallado deben coincidir con el proceso correspondiente.Recoge de forma estática los procesos, dónde en el último nivel derefinamiento se especifican en lenguaje natural estructurado, y suinterrelación.
    41. 41. INGENIERÍA DEL SOFTWARE Javier Martín 41DIAGRAMAS DE TRANSICIÓN DE ESTADOSDescribe el comportamiento dinámico del sistemabasándose en sus estados más importantes.Al igual que en los autómatas de estados finitos,los eventos motiva el cambio de estado delsistema.
    42. 42. INGENIERÍA DEL SOFTWARE Javier Martín 42DIAGRAMAS DE MODELO DE DATOSSe trata de organizar e interrelacionar los datosque utiliza el sistema.El MODELO ENTIDAD-RELACIÓN permite definirtodos los datos y establecer las relaciones quedeben existir entre ellos.
    43. 43. INGENIERÍA DEL SOFTWARE Javier Martín 43DOC. DE ESPECIFICACIÓN DE REQUISITOSEl documento o la especificación de requisitos (SRD oSRS) recoge de forma integral los resultados del análisis.Puede haber documentos previos al SRD, como estudiosde viabilidad o de alternativas posibles.El SRD debe ser revisado con cierta frecuencia durante eldesarrollo y debe facilitar la varificación de lasespecificaciones (contrato).Diversos organismos de estandarización hacen propuestassobre la estructura del SRD: IEEE, DoD, etc. Vemos elmodelo de SRD de la Agencia Espacial Europea.Dependiendo de las características y complejidad delproceso tal vez no sea necesario cubrir todos losapartados.
    44. 44. INGENIERÍA DEL SOFTWARE Javier Martín 44MODELO DE SRD1. Introducción1. Objetivo: objetivos, participantes, calendario,...2. Ámbito, identificará y dará nombre al producto3. Definiciones, siglas y abreviaturas4. Referencias, la descripción bibliográfica de los documentos referenciados.5. Panorámica del documento2. Descripción general1. Relación con otros proyectos, similares o complementarios2. Relación con proyectos anteriores o posteriores3. Objetivo y funciones4. Consideraciones de entorno5. Relaciones con otros sistemas, que utilicen entradas o salidas indirectas deinformación6. Restricciones generales: metodologías, lenguajes, de hardware,...7. Descripción del modelo, es el apartado más extenso y más importante. Seutilizan todas las notaciones y herramientas disponibles
    45. 45. INGENIERÍA DEL SOFTWARE Javier Martín 45MODELO DE SRD3. Requisitos específicos, lista detallada y completa de los requisitos del sistema, indicando sugrado de cumplimiento (obligatorio, recomendable, opcional. No incluir aspectos de diseño odesarrollo, ni tampoco soluciones particulares que no sean obligadas1. Requisitos específicos, QUÉ debe hacer el sistema especificando el tratamiento dela información.2. Requisitos de interfase, conexión con otros sistemas con los que interactúa (basesde datos, ficheros, SSOO,...).3. Requisitos de operación, es decir, del interfaz de usuario4. Requisitos de capacidad, volumen procesador, tiempo respuesta, tamaño ficheros.Se debe cuantificar para el peor, el mejor y el caso más habitual.5. Requisitos de verificación, que debe cumplir el sistema para que se posible verificarsu corrección6. Requisitos de pruebas de aceptación7. Requisitos de recursos, instalaciones y elementos necesarios para elfuncionamiento del sistema8. Requisitos de documentación9. Requisitos de transportabilidad, para adaptalo a otras plataformas10. Requisitos de calidad, que no hayan sido recogidos en otros apartados11. Requisitos de fiabilidad, imponiendo un límite aceptable de fallos12. Requisitos de mantenibilidad13. Requisitos de seguridad, contra utilización indebida14. Requisitos de salvaguarda, para evitar consecuencias graves en equipos o enpersonas4. APENDICES, para complementar el contenido del documento
    46. 46. INGENIERÍA DEL SOFTWARE Javier Martín 46VIDEOJUEGO DE LAS MINAS
    47. 47. INGENIERÍA DEL SOFTWARE Javier Martín 47SISTEMA DE GESTIÓN DE BIBLIOTECA
    48. 48. INGENIERÍA DEL SOFTWARE Javier Martín 48SISTEMA DE GESTIÓN DE BIBLIOTECA
    49. 49. INGENIERÍA DEL SOFTWARE Javier Martín 49SISTEMA DE GESTIÓN DE BIBLIOTECA
    50. 50. INGENIERÍA DEL SOFTWARE Javier Martín 50SISTEMA DE GESTIÓN DE BIBLIOTECA
    51. 51. INGENIERÍA DEL SOFTWARE Javier Martín 51SISTEMA DE GESTIÓN DE BIBLIOTECA
    52. 52. INGENIERÍA DEL SOFTWARE Javier Martín 52Tema 3:FUNDAMENTOS DEL DISEÑO DELSOFTWARE
    53. 53. INGENIERÍA DEL SOFTWARE Javier Martín 53CONCEPTO DE DISEÑODescripción o bosquejo de alguna cosa hecho porpalabras.En un sistema software la realización del diseño parte delSRD y no es nada trivial. Cuando no se tiene experienciaen el desarrollo concreto se hace de forma iterativamediante ensayo y error, en caso contrario se aprovecha el“know-how” (saber hacer).Las técnicas para realizar diseños nuevos son empíricas yno están suficientemente formalizadas, mientras que paraproyectos ya conocidos, como los de gestión, existenherramientas tales como lenguajes de 4ª generación.En el diseño se establece el CÓMO debe funcionar elsistema, determinando la organización y la estructura delsoftware.
    54. 54. INGENIERÍA DEL SOFTWARE Javier Martín 54ACTIVIDADES DE UN DISEÑO SISTEMÁTICODISEÑO ARQUITECTÓNICO, se abordan los aspectosestructurales y de organización del sistema, y su posibledivisión en subsistemasDISEÑO DETALLADO, organización y estructura de losmódulosDISEÑO PROCEDIMENTAL, organización de lasoperaciones o servicios que ofrecerá cada módulo. Sesuele realizar en pseudocódigo o PDL, pero desarrollandosólo los aspectos más relevantes del algoritmoDISEÑO DE DATOS, organización de la base d edatos delsistema. Se parte de los diagramas E-R.DISEÑO DE LA INTERFAZ DE USUARIO, organizar yfacilitar la utilización del sistema por parte del usuarioEl resultado de estas actividades debe plasmarse en elDocumento d Diseño Software (SDD)
    55. 55. INGENIERÍA DEL SOFTWARE Javier Martín 55CONCEPTOS PARA EL DISEÑOABSTACCIÓN, identificar los elementos significativos del sistema y abstraer la utilidad específica de cada unoABSTRACCIONES FUNCIONALES, sirven para crear expresiones parametrizadas usando funciones oprocedimientosTIPOS ABSTRACTOS, junto con el tipo de datos se deben crear los métodos que manejan estos datosMÁQUINAS ABSTRACTAS, definición formal del comportamiento de una máquinaMODULARIDAD, el diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. Susventajas: claridad, reducción de costos y reutilizaciónREFINAMIENTO, a partir de una idea no muy concreta se va refinando mediante aproximaciones hasta el detalleESTRUCTURAS DE DATOS, para organizar la información que maneja el sistema: registros, conjuntos, listas, pilas,colas, árboles, grafos, tablas, ficheros, ...OCULTACIÓN, de la organización de los datos internos y de los detalles del algoritmo, se muestra en el interfaz sóloaquello que resultará invariable ante cambios. Ventajas: depuración, mantenimiento, ...GENERICIDAD, consiste en diseñar un elemento genérico, con las características comunes a todos los elementosagrupadosHERENCIA, los elementos hijos heredan del padre su estructura y operaciones para ampliarlos, mejorarlos oadaptarlos. Es conveniente utilizar un lenguaje de programación orientado a objetosPOLIMORFISMO, es la propiedad de los elementos que pueden variar su formar sin cambiar su naturaleza. Seemplea el concepto de genericidad. En los hijos se puede producir la anulación de una operación. A veces en elpadre interesa declarar un método sin implementarlo, lo harán los hijos en diferidoCONCURRENCIA, se trata de aprovechar al máximo el procesador garantizando unos tiempos máximos derespuesta para tareas críticas. Problemas de los sistemas con restricciones:Tareas concurrentes, asegurar que todas cumplen sus restriccionesSincronización de tareas, determinando los puntos de sincronización entre ellasComunicación entre tareas, unas serán productoras de datos y otras consumidoras. Para evitar la corrupción dedatos compartidos permitir sólo concurrencia en lectura con semáforos, monitores y regiones críticasInterbloqueos (deadlock) cuando varias tareas esperan un evento que nunca se producirá
    56. 56. INGENIERÍA DEL SOFTWARE Javier Martín 56NOTACIONES PARA EL DISEÑODebe resultar precisa, clara y fácil de interpretar.Se emplean notaciones formalescuasimatemáticasNOTACIONES ESTRUCTURALES, se desglosa yestructura el sistema en sus partesDIAGRAMAS DE BLOQUESCAJAS ADOSADAS
    57. 57. INGENIERÍA DEL SOFTWARE Javier Martín 57DIAGRAMAS DE ESTRUCTURA(Yourdon)Describen la estructura de los sistemas software como unajerarquía de módulos, reflejando sólo su organizaciónestáticaRECTÁNGULO,móduloLÍNEA, relaciónentre módulos, elsuperior utiliza elmódulo inferiorROMBO, opcionalARCO, repetitivaCIRCULO CONFLECHA, envio dedatos o informaciónde control (correcto,repetir, desconectar,etc)
    58. 58. INGENIERÍA DEL SOFTWARE Javier Martín 58DIAGRAMAS HIPO (Hierachy-Input-Process-Output)Se muestra primero lajerarquía entre losmódulos del sistemaY en losdiagramas HIPOde detalle hay 3zonas: Entrada,Proceso y Salida
    59. 59. INGENIERÍA DEL SOFTWARE Javier Martín 59DIAGRAMAS DE JACKSONEl proceso de diseño es sistemático y selleva a cabo en tres pasos:•Especificación de la estructura de datos deentrada y de salida•Obtención de la estructura del programa•Expansión de la estructura del programapara lograr el diseño detallado
    60. 60. INGENIERÍA DEL SOFTWARE Javier Martín 60NOTACIONES ESTÁTICASDescriben las características estáticas del sistema, talescomo la organización de la información, sin tener en cuentasu evolución durante el funcionamiento del sistema.Las notaciones son las mismas que se emplean en laespecificación:DICCIONARIO DE DATOS, dónde se detalla la estructurainterna de los datos que maneja el sistema. En el diseño seamplía y se completa el diccionario de la especificación hastael nivel de detalle necesario para iniciar la codificación.DIAGRAMAS ENTIDAD-RELACIÓN, definiendo lasrelaciones entre datos y la organización de la información. Seamplia y detalla el diagrama de la especificación con lasnuevas entidades y relaciones.
    61. 61. INGENIERÍA DEL SOFTWARE Javier Martín 61NOTACIONES DINÁMICASPermiten describir el funcionamiento del sistemadurante su funcionamiento.Las notaciones son las misma utilizadas en laespecificación:DIAGRAMAS DE FLUJO DE DATOS, serán muchomás exhaustivos que los de la especificación.DIAGRAMAS DE TRANSICIÓN DE ESTADOS,más detallados que reflejen las transiciones entreestados internos.LENGUAJE DE DESCRIPCIÓN DE PROGRAMAS(PLD), permite realizar la especificación funcionaldel sistema.
    62. 62. INGENIERÍA DEL SOFTWARE Javier Martín 62NOTACIONES HIBRIDAS: DIAGRAMASDE ABSTRACCIONESPermiten un enfoque globalizado del diseño atendiendo a aspectos estáticos (datos), dinámicos(operaciones) y de estructura del sistema.DIAGRAMAS DE ABSTRACCIONES, se contemplan dos tipos de abstracciones: las funciones y los tipos abstractos dedatos.En una abstracción se distinguen 3 partes:NOMBRE, es su identificadorCONTENIDO, dónde se define la organización de los datosOPERACIONES, para manejar el contenido de la abstracciónLas abstracciones funcionales (funciones o procedimientos), sólo tiene la parte de operación.El dato encapsulado tiene como el tipo abstracto contenido y operaciones, pero no permite declarar otras variables de sumismo tipo.En los diagramas se muestra la relaciónjerárquica entre abstracciones, de maneraque la abstracción superior utiliza lainferior.
    63. 63. INGENIERÍA DEL SOFTWARE Javier Martín 63NOTACIONES HIBRIDAS: DIAGRAMASDE OBJETOSSe emplea una terminología 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 deobjetos2. En los diagramas de objetos hay relaciones de herenciaDe acuerdo con las propiedades de los objetospodemos tener relaciones especiales entre ellos:•CLASIFICACIÓN, ESPECIALIZACIÓN O HERENCIA•COMPOSICIÓN, permite describir un objeto mediantelos elementos que lo forman
    64. 64. INGENIERÍA DEL SOFTWARE Javier Martín 64DOCUMENTOS DE DISEÑO: ADD1. INTRODUCCIÓN – Para dar una visión general de todo el documento. Los contenidos de los apartados como en el SRD1.1 Objetivo ...1.2 Ámbito1.3 Definiciones, siglas y abreviaturas1.4 Referencias2. PANORÁMICA DEL SISTEMA, visión general de los requisitos funcionales y de otro tipo del sistema a diseñar3. CONTEXTO DEL SISTEMA, si posee conexiones con otros3.n Definición de interfaz externa4. DISEÑO DEL SISTEMA, se describe el nivel superior del diseño del sistema4.1 Metodología de diseño de alto nivel4.2 Descomposición del sistema , primer nivel de descomposición del sistema en sus componentes principales5. DISEÑO DE LOS COMPONENTES, se procede a la decripción detallada de l,os componentes mencionados en 4.25.n Identificador del componente5.n.l Tipo (subprograma, módulo, procedimiento, proceso, datos5.n.2 Objetivo, o necesidad de que exista el componente5.n.3 Función , lo que hace el componente5.n.4 Subordinados, se enumeran todos los componentes que utiliza5.n.5 Dependencias y su naturaleza: invocación de operación, datos compartidos, inicialización, creación, etc.5.n.6 Interfases, de cómo otros componentes interactúan con éste5.n.7 Recursos , elementos usados por el componente5.n.8 Referencias, que se han utilizado en el texto5.n.9 Proceso, algoritmos o reglas que utiliza el componente para realizar su función5.n.l0 Datos, descripción de los datos, su tipo, sus valores iniciales, se puede realizar con un diccionario de datos6. VIABILIDAD y RECURSOS ESTIMADOS7. MATRIZ REQUISITOS/COMPONENTES, se pone en las filas los requisitos y en las columnas los componentes
    65. 65. INGENIERÍA DEL SOFTWARE Javier Martín 65DOCUMENTOS DE DISEÑO: DDDParte 1. DESCRIPCIÓN GENERAL1. INTRODUCCIÓN1.1 Objetivo1.2 Ámbito1.3 Definiciones, siglas y abreviaturas1.4 Referencias1.5 Panorámica2. NORMAS, CONVENIOS y PROCEDIMIENTOS2.1 Normas de diseño de bajo nivel2.2 Normas y convenios de documentación2.3 Convenios de nombres (ficheros, programas, módulos, etc.)2.4 Normas de programación2.5 Herramientas de desarrollo de softwareParte 2. ESPECIFICACIONES DE DISEÑO DETALLADOn. Identificador del componenten.l Identificadorn.2 Tipon.3 Objetivon.4 Funciónn.5 Subordinadosn.6 Dependenciasn.7 Interfasesn.8 Recursosn.9 Referenciasn.l0 Proceson.ll DatosAPÉNDICE A. LISTADOS FUENTEAPÉNDICE E. MATRIZ REQUISITOS/COMPONENTES
    66. 66. INGENIERÍA DEL SOFTWARE Javier Martín 66Tema 4:TÉCNICAS GENERALES DEDISEÑO SOFTWARE
    67. 67. INGENIERÍA DEL SOFTWARE Javier Martín 67TÉCNICAS DE DISEÑOLos objetivos de las técnicas de diseño software sonfundamentalmente:La descomposición modular del sistemaLos diseños de los algoritmos y estructuras de datosfundamentales que se deben usar en el sistemaPrimero veremos las características deseables de unabuena descomposición modular del sistema, y luego sepresentarán técnicas de diseño:Diseño funcional descendenteDiseño orientado a objetosDiseño de datos
    68. 68. INGENIERÍA DEL SOFTWARE Javier Martín 68DESCOMPOSICIÓN MODULARLos pasos a seguir son:1. Identificar los módulos2. Describir cada módulo3. Describir las relaciones entre módulosTipos de módulos:1. Código fuente, en el lenguaje de programación usado2. Tabla de datos, para datos de inicialización u otros3. Configuración, se agrupa en un módulo toda la información deconfiguración en el entorno de trabajo4. Otros: ficheros de ayuda en línea, manuales, etc.Una descomposición modular debe poseer ciertas cualidades mínimaspara que se pueda considerar suficientemente válidaIndependencia fucionalAcoplamientoCohesiónComprensibilidadAdaptabilidad
    69. 69. INGENIERÍA DEL SOFTWARE Javier Martín 69DESCOMPOSICIÓN MODULAR: INDEPENDENCIA FUNCIONALAl final de los documentos ADD y DDD debe haber una matrizREQUISITOS/COMPONNETES. En principio, cada función será realizada enun módulo distinto. Si las funciones son independientes los módulos tendránindependencia funcional.Cada módulo debe realizar una función concreta o un conjunto de funcionesafines. Es recomendable reducir las relaciones entre módulos al mínimo.Para medir la independencia funcional hay dos criterios: acoplamiento ycohesión.DESCOMPOSICIÓN MODULAR: ACOPLAMIENTOEl grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y lacomplejidad de la interfase:FUERTE,POR CONTENIDO, cuando desde un módulo se pueden cambiar datos locales de otroCOMÚN, se emplea una zona común de datos a la que tienen acceso varios módulosMODERADO,DE CONTROL, la zona común es un dispositivo externo al que están ligados los módulos,esto implica que un cambio en el formato de datos afecta a todos estos módulosPOR ETIQUETA, en ontercambio de datos se realiza mediante una referencia a laestructura completa de datos (vector, pila, árbol, grafo, ...)DÉBIL,DE DATOS, viene dado por los datos que intercambian los módulos. Es el mejor posibleSIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe
    70. 70. INGENIERÍA DEL SOFTWARE Javier Martín 70DESCOMPOSICIÓN MODULAR: COHESIÓNEs necesario lograr que el contenido de cada módulo tenga la máxima coherencia. Para que el nº demódulos no sea demasiado elevado y complique el diseño se tratan de agrupar elementos afines yrelacionados en un mismo módulo.ALTACOHESIÓN ABSTRACCIONAL, se logra cuando se diseña el módulo como tipo abstractode datos o como una clase de objetosCOHESIÓN FUNCIONAL, el módulo realiza una función concreta y específicaMEDIACOHESIÓN SECUENCIAL, los elementos del módulo trabajan de forma secuencialCOHESIÓN DE COMUNICACIÓN, elementos que operan con le mismo conjunto de datosde entrada o de salidaCOHESIÓN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej.Arrancar o parar dispositivosBAJACOHESIÓN LÓGICA, se agrupan elementos que realizan funciones similares. Ejs.:módulos de E/S o de tratamiento de erroresCOHESIÓN COINCIDENTAL, es la peor y se produce cuando los elementos de un módulono guardan relación algunaLa descripción del comportamiento de un módulo permite establecer el grado de cohesión:Si es una frase compuesta y contiene más de un verbo la cohesión será MEDIASi contiene expresiones secuenciales (primero, entonces, cuando...), será temporal o secuencialSi la descripción no se refiere a algo específico (Ej. Todos los errores), cohesión lógicaSi aparece “inicializar”, “preparar”, “configurar”, probablemente sea temporal.
    71. 71. INGENIERÍA DEL SOFTWARE Javier Martín 71DESCOMPOSICIÓN MODULAR: COMPRENSIBILIDADPara facilitar los cambios, el mantenimiento y la reutilización de módulos esnecesario que cada uno sea comprensible de forma aislada. Para ello es buenoque posea independencia funcional, pero además es deseable:IDENTIFICACIÓN, el nombre debe ser adecuado y descriptivoDOCUMENTACIÓN, debe aclarar todos los detalles de diseño eimplementación que no queden de manifiesto en el propio códigoSIMPLICIDAD, las soluciones sencillas son siempre las mejoresLa adaptación de un sistema resulta más dificil cuando no hay independenciafuncional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseñoes poco comprensible. Otros factores para facilitar la adaptabilidad:PREVISIÓN, es necesario prever que aspectos del sistema pueden sersusceptibles de cambios en el futuro, y poner estos elementos en módulosindependientes, de manera que su modificación afecte al menor número demódulos posibleACCESIBILIDAD, debe resultar sencillo el acceso a los documentos deespecificación, diseño, e implementación para obtener un conocimientosuficiente del sistema antes de proceder a su adaptaciónCONSISTENCIA, después de cualquier adaptación se debe mantener laconsistencia del sistema, incluidos los documentos afectadosDESCOMPOSICIÓN MODULAR: ADAPTABILIDAD
    72. 72. INGENIERÍA DEL SOFTWARE Javier Martín 72TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTELa descomposición del sistema se hace desde un punto de vista funcional.Desde el punto de vista de la codificación, cada módulo correspondeesencialmente a un subprograma.TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:DESARROLLO POR REFINAMIENTO PROGRESIVOEsta técnica consiste en la aplicación de la fase de diseño de la programaciónestructurada. Las estructuras básicas son la secuencia, la selección entrealternativas y la iteración.Cada paso en la descomposición consiste en refinar o detallar una parte delprograma global u operación, que a su vez podrá ser descompuesta en otrasoperaciones. Los refinamientos se basan en la aplicación de estructuras de controlen el programa. Veamos como ejemplo “obtener las raíces de una ec. de 2º grado”:Obtener raíces ->Leer coeficientesResolver ecuación -->Calcular discriminanteCalcular raíces -->SI el discriminante es negativo ENTONCESCalcular raíces complejasSI-NOCalcular raíces realesFIN-SIImprimir raíces
    73. 73. INGENIERÍA DEL SOFTWARE Javier Martín 73TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:PROGRAMACIÓN ESTRUCTURADA DE JACKSONEsta técnica sigue las ideas de la programación estructurada (secuencia,selección, iteración) y el método de refinamientos sucesivos pàra construir laestructura del programa en forma descendente.Se recomienda construir la estructura del programa de forma similar a lasestructuras de datos de entrada y de salidaPasos de la técnica JSP:1) Analizar el entorno del problema y describir las estructuras de datos aprocesar2) Construir la estructura del programa basándose en las estructuras dedatos3) Definir las tareas a realizar en cada módulo de la estructura del programaEste tercer paso corresponde en su detalle a la fase de codificaciónEj.: Programa para justificar el texto, es decir, reagrupar las palabras en línease intercalar los espacios adecuados para que se ajusten a los márgenesPASO 1. Las estructuras de datos que reconocemos sonTexto de entrada = {[separador de párrafo | palabra]}Texto de salida = {[línea ajustada | línea final | línea en blanco]}
    74. 74. INGENIERÍA DEL SOFTWARE Javier Martín 74TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:PROGRAMACIÓN ESTRUCTURADA DE JACKSONEn el PASO 2 se trata de encontraruna estructura del programa que seajuste a las estructuras de los datosde entrada y salida
    75. 75. INGENIERÍA DEL SOFTWARE Javier Martín 75TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:DISEÑO ESTRUCTURADOSegún esta técnica, la tarea de diseño consiste en pasar de los DFDs a losdiagramas de estructura.Hay que establecer una jerarquía o estructura de control entre los diferentesmódulos, que no está implícita en el modelo funcional descrito en los DFDsPara dos módulos relacionados en el DFD (A) tenemos 3 posibilidades deorganización modular diferentes.
    76. 76. INGENIERÍA DEL SOFTWARE Javier Martín 76TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:DISEÑO ESTRUCTURADOPara establecer la jerarquía de control entre módulos se recomienda hacerciertos análisis en el flujo de datos: de flujo de transformación y de flujo detransacción. Para ello es recomendable construir un DFD con todos losprocesos contenidos en los primeros niveles prescindiendo de los almacenes.El análisis de flujo detransformaciónconsiste en identificarun flujo global deinformación desde loselementos de entradahasta los de salida.Los procesos seagrupan en 23regiones: flujo deentrada, detransformación y desalida.
    77. 77. INGENIERÍA DEL SOFTWARE Javier Martín 77TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:DISEÑO ESTRUCTURADOEl flujo de transacción es aplicable cuando el flujo de datos se puede descomponer en variaslíneas separadas. El análisis consiste en identificar el centro de transacción a partir del cualse ramifican las líneas de flujo a las regiones correspondientes a cada una de lastransacciones
    78. 78. INGENIERÍA DEL SOFTWARE Javier Martín 78TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE:DISEÑO ESTRUCTURADO. EJ. GESTIÓN DE BIBLIOTECA
    79. 79. INGENIERÍA DEL SOFTWARE Javier Martín 79TÉCNICAS DE DISEÑO BASADO EN ABSTRACCIONESLa idea es que los módulos corresponden a funciones o a tipos abstractos de datos.Los lenguajes que dan más facilidades para la implementación son los orientados aobjetosTÉCNICAS DE DISEÑO BASADO EN ABSTRACCIONES:DESCOMPOSICIÓN MODULAR BASADA EN ABSTRACCIONESSe trata de ampliar el lenguaje de programación con nuevas operaciones y tipos dedatos definidos por el usuario, de forma que se simplifique la escritura de los nivelessuperiores del programa, basándose en módulos que realicen estas operacionesPodemos identificar los tipos abstractos correspondientes a un númerocomplejo y a una ecuación de 2° grado y definir sobre dichos tipos abstractos lassiguientes operaciones:Ecuación de 2° grado: Número complejo:Leer ecuación EscribirEscribir ecuación Sumar, Restar, etc..Obtener raíces Raíz cuadradaLa estructura modular del programa sería:
    80. 80. INGENIERÍA DEL SOFTWARE Javier Martín 80TÉCNICAS DE DISEÑO BASADO EN ABSTRACCIONES: MÉTODO DEABBOTTA partir de la descripción o especificación de los módulos es posible identificar las palabras o términos quepuedan corresponder a elementos significativos del diseño:Tipos de datos, que aparecen como sustantivos genéricosAtributos, son sustantivos en generalOperaciones, tienen la forma de verbos o nombres de accionesSe subrayan en la descripción las palabras significativas haciendo una lista de nombres y otra de verbos uoperaciones. Hay que eliminar los términos irrelevantes o los sinónimos de palabras ya aparecidasDATO Atributos OperacionesPalabra Caracteres ImprimirPárrafo SeparadorLínea salidaIniciar párrafoPoner palabraTerminar párrafoSeparador depárrafoLíneas en blancoSangradoLínea SangradoPalabrasIniciar línea¿cabe palabra?Poner palabraImprimir sin ajustarImprimir ajustada
    81. 81. INGENIERÍA DEL SOFTWARE Javier Martín 81TÉCNICAS DE DISEÑO ORIENTADAS A OBJETOSEs esencialmente igual al diseño basado en abstracciones, añadiendo laherencia y el polimorfismo.En la descomposición modular del sistema cada módulo contiene ladescripción de una clase de objetos o de varias clases relacionadas entresí.PASOS:Estudiar y comprender el problema a resolverDesarrollar en líneas generales uan posible solución, al menosinformalFormalizar dicha estrategía en términos de clases, objetos y susrelaciones:Identificar los objetos, sus atributos y sus componentesIdentificar las operaciones sobre los objetos y asociarlas a la claseadecuadaAplicar herencia donde convengaDescribir cada operación en función de las otras, y subsanar posiblesomisionesAsignar clases y objetos a los módulos del sistema
    82. 82. INGENIERÍA DEL SOFTWARE Javier Martín 82TÉCNICAS DE DISEÑO DE DATOSMuchas aplicaciones necesitan almacenar información de forma permanente y lamejor forma de hacerlo es crear una base de datos subyacentePodemos enfocar la organización de la base de datos de 3 formas:Nivel externo Esquemas de usuarioNivel conceptual Esquemas lógicosNivel interno Esquemas físicosEl nivel externo corresponde a la visión del usuario, en la fase de análisis de pasaal nivel conceptual, que establece la organización de los datos, y finalmente en laetapa de diseño se pasa al nivel interno.DISEÑO DE BASES DE DATOS RELACIONALES, en este modelo la eficiencia sebasa en:Las FORMAS NORMALES, que tienden a evitar las redundancias en los datosalmacenadosFN1, la información asociada a cada columna de la tabla es un único valor, y nouna colecciónFN2, si hay una clave primaria que distingue e identifica cada fila, el resto de losdatos dependen de toda la clave primariaFN3, el valor de cada columna que no es clave primaria depende directamente dela clave primaria. Se puede conseguir si se separan las tablas.Los INDICES, que mejoran la velocidad de acceso a los datos
    83. 83. INGENIERÍA DEL SOFTWARE Javier Martín 83TÉCNICAS DE DISEÑO DE DATOS: DISEÑO DE LAS ENTIDADESEn el modelo relacional cada entidaddel modelo E-R se traduce en unatabla por cada clase de entidad, conuna fila por cada elemento de esaclase y una columna por cada atributode esa entidad.Entre las entidades relacionadas sepuede incluir una columna con unnúmero de referencia o identificadorque las relaciona, sirve como claveprimaria.En el modelo E-R todas lasrelaciones se consideran deasociación, y la manera de trasladaresto a las tablas depende de lacardinalidad de la relación. Larelación se convierte en una tabla quecontiene referencias a las tablas delas entidades relacionadas, así comolos atributos de la relación (cale paracualquier cardinalidad, incluso N:N).Si es 1:N es posible incluir los datosde la relación en la tabla concardinalidad 1. Si la cardinalidad es1:1 se pueden fundir las tablas de lasdos entidades.
    84. 84. INGENIERÍA DEL SOFTWARE Javier Martín 84TÉCNICAS DE DISEÑO DE DATOS: COMPOSICIÓN Y HERENCIALas relaciones de COMPOSICIÓNse tratan como las de asociación, yen ellas la cardinalidad del objetocompuesto suele ser 1, por lo quese puede aplicar la simplificación.Cuando una clase tiene cariassubclases hay 3 formas deamacenar las entidades ne tablas:(a) Una tabla para la superclase conlos atributos comunes y una tablapara cada subclase(b) Desaparece la tabla de lasuperclase y los atributos comunesheredados se repiten en lassubclases(c) Se prescinde de las tablas de lasubclase y se amplia la tabla de lasuperclase con todos los atributosde las subclases, de forma queestos valores serán opcionalespara los elementos
    85. 85. INGENIERÍA DEL SOFTWARE Javier Martín 85Tema 5:CODIFICACIÓN Y PRUEBAS
    86. 86. INGENIERÍA DEL SOFTWARE Javier Martín 86CODIFICACIÓN DEL DISEÑONos vamos a referir a las últimas fases del ciclo de vida: codificación,pruebas de unidades, integración y pruebas de sistema.Cuando alguna de las pruebas no resulta positiva es necesario repetirla codificación o la integración y probar de nuevo.La fase de codificación constituye el núcleo central en cualquiera de losmodelos y tiene una importancia fundamental ya que elabora losprogramas fuente.Previamente a la codificación es necesario elegir el lenguaje que seempleará así como la metodología de programación. También sepueden establecer en el equipo unas normas y un estilo deprogramación común, lo que mejorará la coordinación y facilitará eltrabajo. Además se consigue facilitar el mantenimiento y mejorar lareusabilidad del software.Cuando el resultado de las pruebas no sea satisfactorio será necesariomodificar el código, lo que podrá introducir nuevos errores. Si laprogramación es estructurada será más fácil localizar la disfunción y laposterior modificación y las pruebas del código, dónde podemosintroducir puntos de test.
    87. 87. INGENIERÍA DEL SOFTWARE Javier Martín 87LENGUAJES DE PROGRAMACIÓNAunque los lenguajes han evolucionado mucho desde los años 50 todavía están más próximos a la máquina que al pensamiento humano.Los lenguajes suelen adoptar los avances metodológicos que se producen en el desarrollo del software. Ej.: C y C++DESARROLLO HISTÓRICO, muchos han sido desarrollados con fines experimentales y muy pocos han llegado a ser utilizadosindustrialmente:1ª GENERACIÓN: muy próximos al lenguaje máquinaEnsamblador, asocia a cada instrucción de la máquina un nemónico2ª GENERACIÓN: no dependen de la CPU, se programa de manera simbólica, en “alto nivel”.FORTRAN (FORula TRANslator), para aplicaciones científicasCOBOL, para procesamiento de información. Supone el 70 %ALGOL, da gran importancia a la tipificación de datosBASIC, sencillo y fácil de aprender. Desarrollado para el PC.3ª GENERACIÓN: programación estructurada con declaración de tipos. Los últimos van asociados a otros paradigmas.PASCAL, fue diseñado para la enseñanza de la programación estructurada. Tipificación rígida y no contempla la codificaciónpor separadoMÓDULA-2, descendiente de pascal, se incorpora la estructura de módulo. Se mejora modularidad, concurrencia,abstracción y ocultaciónC, desarrollado para la codificación del UNIX. Flexible y potente. No hay restricciones sobre las operaciones con distintostipos.ADA, descendiente de pscal, mucho más potente y complejo. Incorpora modularidad, abstracción, ocultación, concurrencia ysincronización entre tareas.SMALLTALK, precursos de los lenguajes orientados a objetosC++, incorpora en C los mecanismos de la POO: ocultación, clases, herencia y polimorfismo.EIFFEL, permite la definición de clases genéricas, herencia múltiple y polimorfismo.LISP, lenguaje funcional usado en IA y sistemas expertos. Basado en listas admite recursividad. Maneja bien los símbolosPROLOG, lenguaje lógico en que se construye una base de conocimiento basada en reglas a partir de la cual podemosinferir nuevos hechos o reglas.4ª GENERACIÓN: mayor grado de abstracción. Se agrupan en:BASES DE DATOS; como SQL permiten acceder y manipular la información.GENERADORES DE PROGRAMAS, son eficientes en un dominio de aplicaciones limitado. La mayoría producenaplicaciones de gestión y la salida va en cobol, aunque se han desarrollado herramientas CASE que generan programas enC++ o ADA.CÁLCULO, hojas de cálculo, herramientas de simulación y diseño para el control, etc.OTROS: herramientas para la especificación y verificación formal de programas, lenguajes de simulación, de prototipos, etc.
    88. 88. INGENIERÍA DEL SOFTWARE Javier Martín 88PRESTACIONES DE LOS LENGUAJES:ESTRUCTURAS DE CONTROLse incluyen aquí, además de las características propias de la programación estructurada, elmanejo de excepciones y la concurrencia.Programación estructurada: secuencia, iteración y selección (verdadero-falso y por casos)Manejo de excepciones: errores humanos, fallos hardware, errores software, datos deentrada vacíos, valores fuera de rango, etc. (estructuras exception when y raise).Concurrencia, tareas simultáneas, sincronización, comunicación e interbloqueos. Loslenguajes han implementado la posibilidad de lanzar tareas concurrentes de distintas formas:CORRUTINAS, tienen una estructura semejante a subprogramas pero con una transferencia delcontrol más flexible. El avance en la ejecución de las corrutinas se produce según el avance entreellas.FORK-JOIN, es la propuesta de UNIX.COBEGIN-COEND, entre estas palabras se inician todas las tareas y se finalizan. Es posible elanidamiento.PROCESOS; cada tarea se declara como un proceso y estos y se ejecutan concurrentemente. Enalgunos casos es posible lanzar dinámicamente nuevos procesos una vez iniciado el programa.PARA LA COMUNICACIÓN ENTRE TAREAS.• VARIABLES COMPARTIDAS– SEMÁFOROS– REGIONES CRÍTICAS– MONITORES• PASO DE MENSAJES– CSP– LLAMADA A PROCEDIMIENTOS REMOTOS– REDENZVOUS, DE ADA
    89. 89. INGENIERÍA DEL SOFTWARE Javier Martín 89PRESTACIONES DE LOS LENGUAJES:ESTRUCTURAS DE DATOSDATOS SIMPLES. Para los eneros hay que tener en cuenta el rango posible y para los de coma flotante laprecisión. En ocasiones también permiten el manejo de complejos.Otros tipos simples son char y string, para el manejo de cadenas. Los tipos enumerados también puedenresultar ú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 serhomogéneos como los ARRAYS y heterogéneos como los RECORDS o STRUCTS.Para el manejo de estructuras dinámicas de datos muchos lenguajes incluyen punterosCONSTANTES, en los lenguajes modernos se pueden declarar constantes simbólicas, sin indicardirectamente su valor numérico.COMPROBACIÓN 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 predefinidosNivel 1: tipado automático, el compilador decide cuál es el tipo más adecuado para cada dato.Nivel 2: tipado débil, el compilador hace inferencias sobre los tipos y solo son posibles determinadasconversionesNivel 3: tipado semirígido, todos los datos deben ser declarados con su tipoNivel 4: tipado fuerte, aquí además de declarar los tipos, el programador está obligado a hacer explícitacualquier conversión de tipos.ABSTRACCIONES Y OBJETOS.ABSTRACCIONES FUNCIONALESTIPOS ABSTRACTOS DE DATOSOBJETOSMOODULARIDAD. Se requiere la compilación por separado. Además se introducen de forma redundante ladeclaración y la definición de cada módulo, para permitir al compilador hacer comprobaciones acerca de laconsistencia. C y modula-2 lo tienen, pero pascal es monolítico.
    90. 90. INGENIERÍA DEL SOFTWARE Javier Martín 90CRITERIOS DE SELECCIÓN DEL LENGUAJEEl lenguaje es uno de los elementos más importantes de cualquier desarrollo y tiene unainfluencia decisiva en la depuración y el mantenimiento dela aplicación. Criterios:IMPOSICIÓN DEL CLIENTE, a veces para disminuir los costes de desarrollo ymantenimiento que se producen cuando una empresa utiliza lenguajes diferentes.TIPO DE APLICACIÓN, hay lenguajes orientados a un campo de aplicación concreto.Aplicaciones tiempo real críticas -> ensambladorGestión -> cobolÁrea científico-técnica -> Fortran, Pascal, CInteligencia artificial -> Lisp, PrologOrientado a objeots ->> Eifel, C++DISPONIBILIDAD Y ENTORNO, hay que comprobar los compiladores existentes parala plataforma elegida. Estudio comparativo de eficiencia con un programa de prueba.Herramientas del entorno de desarrollo: editor, montador, depurador, control versiones,manejo de librerías, etc.EXPERIENCIA PREVIA, aprovechar la experiencia aumenta el rendimiento y disminuyelas posibilidades de error. La formación supone una fuerte inversión.RESUABILIDAD, organización de librerías que faciliten la búsqueda y almacenamientode módulos reutilizables.TRANSPORTABILIDAD, depende del lenguajeUSO DE VARIOS LENGUAJES, no es aconsejable a no ser que las distintas partessean más fáciles de desarrollar en lenguajes concretos. Hay que tener en cuenta lacompatibilidad de los compiladores
    91. 91. INGENIERÍA DEL SOFTWARE Javier Martín 91ASPECTOS METODOLÓGICOSEstos aspectos pueden mejorar la codificación bajo determinados puntos de vista: claridad, manejo de errores eficienciay transportabilidad.Normas y estilo, para conseguir un trabajo del equipo homogéneo. Ejemplos:Formato y contenido del as cabeceras de cada móduloFormato y contenido para los comentariosUso del indentadoElección de nombre y uso de mayúsculasRestricciones sobre el tamaño del os módulos, evitar anidamiento excesivo, no usar goto, etc.Manejo de errores. Las causas de los errores pueden estar en el hardware o en el software, incluso de pueden producirpor la introducción de datos incorrectos.DEFECTO, incorrección en el software. Pueden permanecer ocultos hasta que no se ejecutan determinadaspartes del programaFALLO, elemnto del programa que no funciona correctamente, produciendo un resultado erróneoERROR, estado no válido 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 posturaPREVENCIÓN DE ERRORES, consiste en detectar los fallos antes de que provoquen un error. Hay queevitar la propagación de errores y tener siempre a la salida un resultado correcto o una señal de fallo.RECUPERACIÓN DE ERRORES, Cuando no es posible depurar todos los fallos es necesario hacer untratamiento de errores para devolver al programa a un estado válido y evitar que el error se propague1. Detección del error2. Recuperación del error. Se pueden usar dos esquemas en general:1. RECUPERACIÓN HACIA DELANTE, hay que programas un mecanismo de excepciones paraque cuando se detecte el error se corrija el estado y se continúe correctamente la ejecución.2. RECUPERACIÓN HACIA ATRÁS, corrige el estado no válido restaurando el programa a unestado correcto anterior,• Una transacción es una operación que puede terminar con éxito o con fallo, en cuyo caso seaborta y se restaura el estado de antes de comenzar dicha transacción.
    92. 92. INGENIERÍA DEL SOFTWARE Javier Martín 92ASPECTOS METODOLÓGICOS: EFICIENCIA YTRANSPORTABILIDADLa potencia de cálculo y la cantidad de memoria disponible en los computadores actualeshacer preferible la claridad en el código que la EFICIENCIA.EFICIENCIA EN MEMORIA, en la fase de diseño se estudian las posibles alternativas yse opta por el algoritmo que optimiza el uso dela memoria.EFICIENCIA DE TIEMPO, es importante en el desarrollo de sistemas de tiempo realmuy críticos. A veces se mejora la eficiencia de tiempo a costa de ocupar más memoria.En el diseño se estudian las alternativas y se adopta el algoritmo más rápido. Técnicasde codificación para aumentar la eficiencia de tiempo:Tabular cálculo complejosExpansión en línea, emplear macros en vez de subrutinasSimplificar las expresiones aritméticas y lógicasSacar fuera de los bucles lo que no sea necesario repetirUsar estructuras de datos de acceso rápidoEvitar operaciones en coma flotante, mejor en coma fijaEvitar conversiones innecesarias de tiposTRANSPORTABILIDAD DEL SOFTWARE, no solo es rentable a corto plazo para obtenerversiones para diferentes plataformas, a medio y largo plazo facilita el mantenimiento y laadaptación de la aplicación a las nuevas arquitecturas.Los factores para la transportabilidad son:Utilización de estándaresAislar las peculiaridades, colocándolas en módulos separados. Se procurará evitar aquelloselementos 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 delsistema operativo utilizado.
    93. 93. INGENIERÍA DEL SOFTWARE Javier Martín 93TÉCNICAS DE PRUEBASPara garantizar su calidad es necesario someter al programa a diversaspruebas para garantizar su funcionamiento correcto.Se deben hacer pruebas a cada módulo, según avanza la codificacióndel proyecto. Finalmente se harán las pruebas de integración entremódulos y las pruebas de sistemaOBJETIVOS, el principal objetivo es conseguir que el programa funcioneincorrectamente para ir depurando los errores y que se descubran losefectos. Para elaborar los casos de prueba:Una buena prueba encuentra los errores y no los encubrePara determinar si hubo error es necesario conocer elresultado correctoDeben participar codificador y diseñadorAl corregir un error se pueden introducir otros nuevosNo es posible demostrar la ausencia de defectos mediantepruebasNo son posibles las pruebas exhaustivas. Con el menoresfuerzo posible hay que detectar el máximo nº de defectos,en especial los más graves.Las pruebas se realizan en un entorno de ejecucióncontrolado, para asegurar la estabilidad en los pruebas yautomatizar en lo posible este proceso.
    94. 94. INGENIERÍA DEL SOFTWARE Javier Martín 94TÉCNICAS DE PRUEBAS DE UNIDADES: CAJA NEGRALas técnicas de pruebas de unidades siguen dos estrategias fundamentales:PRUEBAS DE CAJA NEGRA, se ignora por completo la estructura interna del programa y secomprueba la corrección de entradas y salidas del programa.Lo importante es la elaboración de los casos de prueba con el objetivo de descubrir los errores eincorrecciones. Métodos:•PARTICIÓN EN CLASES DE EQUIVALENCIA, se trata de ividir el espacio de ejecución delprograma en varios subestapacios o clases equivalentes desde el punto de vista del a caja negra. Hayque:•Determinar las clases equivalentes apropiadas•Establecer pruebas para cada clase de equivalencia, con datos de entrada válidos y noválidos. Se repiten las pruebas hasta cubrir todos los casos válidos de todas las clases.•ANÁLISIS DE VALORES LÍMITE, los errores tienden a aparecer al operar en las fronteras.Directrices para la elaboración de casos de pruebas:•Entradas, probar los valores del límite y justo fuera del límite•Salidas, probar los valores del límite y justo fuera del límite•Memoria, probar tamaños nulos, límite superior y superior al límite de todas las estructurasde datos del programa•Recursos, probar límites. Si terminales=30, probar 0, 20 y 31•Otros, probar los valores límite y establecer las pruebas•COMPARACIÓN DE VERSIONES, se desarrollan varias versiones software para resolver laespecificación del módulo y se comparan los resultados con el fin de detectar errores.•EMPLEO DELA INTUICIÓN, la intuición y la experiencia puede mejorar los casos de prueba,también es conveniente que participen expertos ajenos al desarrollo.
    95. 95. INGENIERÍA DEL SOFTWARE Javier Martín 95TÉCNICAS DE PRUEBAS DE UNIDADES: CAJA TRANSPARENTESe tiene en cuenta la estructura interna del módulo. Loscasos de prueba deben conseguir que:Todas las decisiones se ejecuten en uno y otro sentidoTodos los bucles se ejecuten en los supuestos másdiversos posiblesTodas las estructuras de datos se modifiquen yconsulten alguna vezLa complejidad de los módulos dificulta realizar exhaustivaspruebas de caja transparente. Conviene que participenexpertos con un conocimiento amplio de las estructura delprograma. Métodos:CUBRIMIENTO LÓGICO, consiste en no dejar ninguna seccióndel código sin ejecutar en pruebas. Se llama camino básico acualquier recorrido sobre el diagrama de flujo que nos permitallegar al final desde el punto de entrada.Hay que determinar el conjunto de caminos básicosque recorran todas las líneas de flujo del programa al menos unavez.Nº máximo de caminos = Nº predicados + 1En un segundo nivel de casos de prueba se trata deque se ejecuten todas las combinaciones de caminos básicos porparejasA otros niveles se generan casos de pruebas paraque se ejecuten un nº significativo de combinaciones de caminosbásicosPRUEBAS DE BUCLES, que son elemento esencial encualquier programa. Casos:•Bucles con nº no acotado de repeticiones, probar 0, 1, 2,bastantes y muchas iteraciones.•Bucles con nº máximo de repeticiones, probar 0, 1, 2bastantes, M-1, M y M+1 iteraciones•Bucles anidados, el nº de pruebas para comprobar todaslas situaciones crece.EMPLEO DE LA INTUICIÓN, conocer con detalle laestructura del módulo y tener experiencia.
    96. 96. INGENIERÍA DEL SOFTWARE Javier Martín 96TÉCNICAS DE PRUEBAS DE UNIDADES: CAJA TRANSPARENTEDiagramas de flujo con 3 y con 4 predicados lógicos simples
    97. 97. INGENIERÍA DEL SOFTWARE Javier Martín 97ESTIMACIÓN DE ERRORES NO DETECTADOSResulta imposible demostrar que un módulo carece dedefectos, pero podemos hacer una estimación estadísitcade erratas que permanecen sin detectar:Anotar el nº de errores que se producen inicialmente al pasarlos casos de prueba.Corregir el módulo hasta que sdesaparezcan todos esoserroresIntroducir en el módulo, de forma aleatoria un nº razonable deerroresSometer al módulo nuevamente a los casos de prueba y verel nº de errores que se detectanDe esta forma podemos estimar el nº de errores que hanpermanecido sin ser detectados en el programaEn función de los resultados se valorará la necesidad depreparar nuevos casos de prueba.
    98. 98. INGENIERÍA DEL SOFTWARE Javier Martín 98ESTRATEGIAS DE INTEGRACIÓNSe integran los módulos del sistema para conformar el sistema completo. Causas de error:Desacuerdos en el interfaz entre módulosInteracción indebida entre módulosImprecisiones acumuladasEstrategias básicas para la integración:INTEGRACIÓN BIG BANG, en un único paso se integran todos los módulos, de forma quetodos los defectos se manifiestan a la vez. Solo recomendable para sistemas pequeños.INTEGRACIÓN DESCENDENTE, se parte de un módulo principal P, que se prueba con“módulos de andamiaje”, los cuales van siendo sustituidos por los verdaderos de formaprogresiva por niveles. Los módulos de andamiaje;No hacen nada y solo sirven para comprobar el interfazImprimen un mensaje de seguimiento, con información de la llamadaSuministran un resultado fijoSuministran un resultado aleatorioSuministran un resultado tabulado u obtenido con un algoritmo simplificadoEl trabajo de elaborar estos módulos puede ser aprovechado para hacer un prototipo y mostraral cliente un avance del programa. Inconvenientes:Impide el trabajo en paralelo en las pruebasEs difícil buscar los casos de pruebas especiales o dirigidas a los últimos módulos integradosINTEGRACIÓN ASCENDENTE, se codifican por separado y en paralelo todos los módulos delnivel más bajo. Para probarlos se codifican módulos gestores o conductores que los hacenfuncionar independientemente o en combinaciones sencillas. Las ventajas son:Facilita el trabajo en paraleloFacilita el ensayo de situaciones especialesLa Integración Sandwich consiste en realizar integración ascendente con los módulos de nivelmás bajo y descendente con los de nivel más alto.
    99. 99. INGENIERÍA DEL SOFTWARE Javier Martín 99INTEGRACIÓN DESCENDENTE Y ASCENDENTE
    100. 100. INGENIERÍA DEL SOFTWARE Javier Martín 100PRUEBAS DE SISTEMASe trata de probar el sistema completo para ver si realmente cumple lasespecificaciones.Se suelen emplear estrategias de caja negra. Podemos distinguir diferentesclases de pruebas:PRUEBAS DE RECUPERACIÓN, para comprobar la capacidad del sistemapara recuperarse ante fallosPRUEBAS DE SEGURIDAD, par comprobar los mecanismos de protecciónante un acceso no autorizadoPRUEBAS DE RESISTENCIA, para comprobar el comportamiento delsistema ante situaciones excepcionalesPRUEBAS DE SENSIBILIDAD, para comprobar el tratamiento que da elsistema a ciertas singularidades relacionadas casi siempre con losalgoritmos matemáticos utilizadosPRUEBAS DE RENDIMIENTO, para comprobar las prestaciones delsistema que son críticas en tiempoPRUEBAS ALFA Y BETA. Los usuarios también deben intervenir en laspruebas finales del sistemaPruebas alfa, son las primeras pruebas que se realizan en un entornocontrolado donde el usuario tiene el apoyo de alguien del equipo de desarrolloPruebas beta, los usuarios trabajan con el sistema en un entorno real y sinayuda, anotando los problemas que se le presentan
    101. 101. INGENIERÍA DEL SOFTWARE Javier Martín 101Tema 6:AUTOMATIZACIÓN DE PROCESODE DESARROLLO
    102. 102. INGENIERÍA DEL SOFTWARE Javier Martín 102ENTORNOS DE DESARROLLO SOFTWAREEntorno se refiere al contexto dentro del cual se desarrolla una determinadaactividad, o también a la combinación de instrumentos utilizados.El entorno de desarrollo software, SEE, cuenta con una serie de técnicas deautomatización denominadas CASE.Las primeras herramientas se referían a la fase de codificación, así el entornode programación clásico consiste en un compilador con editor, montador deenlaces, etc. Posteriormente con el empleo del término CASE se ha extendidola automatización a las fases de análisis y diseño.Para las pruebas de integración se puede disponer de herramientas de ensayoy para la fase de mantenimiento se dispone de soporte de gestión deconfiguración, que incluye la gestión de versiones y el control de cambios.El futuro de las técnicas CASE está en el soporte completo de todo el ciclo devida. Se ha denominado IPSE, ICASE e ISEE.FORMAS DE ORGANIZACIÓN:En cadena, se combinan una serie de herramientas de manera que lasalida de cada una es la entrada de la siguiente. Ej.: editor-compilador-montadorCon repositorio, las herramientas integradas guardan su información eneste almacén común. Una parte del repositorio es el diccionario de datosComo una única herramienta global, capaz de realizar todas lasoperaciones necesarias.
    103. 103. INGENIERÍA DEL SOFTWARE Javier Martín 103OBJETIVO Y CLASIFICACIÓN DE ENTORNOS DE DESARROLLODar soporte a la programación en un lenguaje concretoDar soporte a una metodología de desarrolloAyudar al desarrollo de entornos de desarrollo (meta-entornos)CLASIFICACIÓN, desde un punto de vista pragmático:ENTORNOS ASOCIADOS A UN LENGUAJE. Un primer paso lo constituyen losintérpretes de los lenguajes de programación interactivos (BASIC, LISP, SmallTalk, ada).ENTORNOS ASOCIADOS A ESTRUCTURA. En ellos se almacena la informacióncorrespondiente al programa en forma estructurada y no simplemente como texto. La edicióndel programa se consigue mediante un editor de estructura, que permite construir o modificarun programa operando sobre los elementos de su estructura. El entorno se basa en plantillasque describen las estructuras básicas (PL/).ENTORNOS BASADOS EN HERRAMIENTAS. Consisten en una colección deherramientas (toolkit o toolbox) relativamente independientes, aunque compatibles entre sí,además deben de existir algún medio para hacerlas funcionar en forma combinada. Suelepresentar como ventaja el ser bastante abiertos, permitiendo la incorporación de nuevasherramientas. Su inconveniente es la falta de una interfaz de usuario interactiva y uniforme.ENTORNOS ASOCIADOS A UNA METODOLOGÍA. La integración de los distintoselementos del entorno se suele conseguir mediante el empleo de un almacén único orepositorio CASE para almacenar todos los elementos de información contemplados en lametodología soportada. El repositorio contiene información de los diagramas de flujo dedatos, descripción de cada dato y de cada proceso.ENTORNOS DE 4ª GENERACIÓN. Se apoyan en un sistema de gestión de base de datosdotado de un lenguaje de consulta con herramientas complementarias.
    104. 104. INGENIERÍA DEL SOFTWARE Javier Martín 104CLASIFICACIÓN DE ENTORNOS POR NIVELESNivel de servicio. Corresponde a un producto que realiza una función uoperación elemental, que una vez invocada no se interrumpe (compilador).Nivel de herramienta. Producto software que permite invocar diferentesservicios u operaciones correspondientes a una misma actividad individual.(editor de textos).Nivel de banco de trabajo o equipo de herramientas. Corresponde a unproducto CASE que automatiza o soporta un perfil concreto de actividadprofesional dentro del proceso de desarrollo. Un banco de trabajo sueleenglobar varias herramientas, integradas con una interfaz de usuario uniforme.En la actividad de codificación el banco de trabajo se denomina entorno deprogramación.Entorno de desarrollo. Producto CASE que soporta el proceso completo dedesarrollo de software (IPSE o ICASE).Los dos primeros niveles se describen a veces como uno solo.
    105. 105. INGENIERÍA DEL SOFTWARE Javier Martín 105HERRAMIENTAS DE SOFTWAREHerramientas clásicas.• Editor de texto.• Compilador• Montador de enlaces. Construye ejecutables combinando varios ficheros objeto.• Gestor de librería. Combina ficheros objeto en una librería.• Herramienta ‘MAKE’. Automatiza la actualización de los ficheros a partir de otros.• Intérprete interactivo. Casi Constituye un entorno de programación completo (si lo es se debe clasificar a nivel de banco de trabajo y no deherramienta). Engloba funciones equivalentes a las de edición, compilación, montaje y ejecución.• Compilador/Intérprete. Procesador de un lenguaje interpretado de forma no interactiva.Incluye un compilador a código intermedio y unintérprete de ejecución de dicho código intermedio con todas las librerías de soporte. No incluye funciones de editor de programas.• Depurador absoluto. Ejecuta el programa de forma controlada. Resulta incomodo de usar ya que hace referencia a posiciones de memoria y a losregistros del procesador.• Depurador simbólico. Realiza una función análoga al anterior pero con referencia al código fuente por lo que es más cómodo de usar.Herramientas evolucionadas.• Editores orientados al lenguaje. Son editores de estructura.• Herramienta ‘MAKE’ automática. Se incorpora la función ‘MAKE’ al compilador.• Manejador de versiones. Almacena de forma organizada y eficiente una serie de versiones del mismo elemento software. Se suelen usar desde lasutilidades MAKE al recompilar una aplicación en desarrollo.• Procesadores/Analizadores de código fuente. Grupo en que se pueden incluir diferentes herramientas que procesan el texto fuente para obtenermediciones, generar tablas de referencias, encolumnar …etc. Estas funciones podrían estar incorporadas en los compiladores.• Procesadores de documentos. No son específicos del desarrollo pero son un soporte fundamental.• Herramientas de control de pruebas. Ayudan a la realización de pruebas unitarias o deintegración.• Herramientas de control de cambios. Ayudan a la realización del desarrollo y al mantenimiento de aplicaciones.• Procesadores de ficheros de texto.Herramientas de 4º generación.Hojas de cálculo. Procesadores de documentosGestores de bases de datos Lenguajes de 4ª generación.Generadores de programas.
    106. 106. INGENIERÍA DEL SOFTWARE Javier Martín 106ENTORNOS INTEGRADOSIntegración de datos. Significa que la información almacenada en el entorno es gestionada de manera uniforme, con independencia de lastransformaciones que se hagan con cada elemento de información. Debe de conseguir:¤ Interoperatividad entre herramientas.¤ No redundancia de datos¤ Consistencia de datos.¤ Paso de datos de una herramienta a otra.La integración de datos puede conseguirse de diversas maneras:• Transferencia directa de datos de una herramienta a otra. Eficiente pero poco flexible. Complicada para integrar muchasherramientas diferentes.• Transferencia mediante ficheros. Es la más sencilla. Existe un formato normalizado (CDIF).• Transferencia basada en comunicación. Alternativa a la anterior y puede ser usada en sistemas distribuidos y en sistemasabiertos.• Repositorio común. Se utiliza en los entornos modernos con un grado de integración elevado.Integración de control. Consiste en la combinación flexible de funciones para cumplir con las particularidades del proceso y actividades quehay que informatizar. El mayor grado se consigue cuando desde una herramienta se puede invocar funciones de otra herramienta. Exigecomo paso previo la integración de los datos.Integración de la presentación. Trata de realizar la interacción con el usuario de manera uniforme, con cierta independencia dela función oherramienta en uso. Para ello se deben conseguir los objetivos de un sistema amigable:• Limitar el número de formas de interacción diferentes.• Usar formas de interacción y presentación adecuadas al modelo mental que el usuario tiene del entorno.• Satisfacer los tiempos de respuesta esperados y dar indicación del avance del proceso en caso de tratamiento de larga duración.• Mantener información útil a disposición del usuario.Integración del proceso. Consiste en que las herramientas se combinan de manera que apoyan o fuerzan el uso de una metodología dedesarrollo definida. Este modo exige una buena integración de control y datos. El proceso de desarrollo puede definirse en base a lossiguientes elementos.• Un paso del desarrollo es una unidad de trabajo concreta que produce un resultado (por ejemplo revisión del DDD).• Un suceso o evento es un condición que ocurre durante la ejecución de un paso y que puede desencadenar la ejecución de unaacción asociada (compilación de un módulo).• Una restricción del desarrollo es una limitación que debe cumplirse.Un buen grado de integración del proceso exige que todo los pasos, eventos y restricciones que definen de forma natural la metodología dedesarrollo a utilizar, sean representables y tratables dentro del entorno.
    107. 107. INGENIERÍA DEL SOFTWARE Javier Martín 107ENTORNOS INTEGRADOS: EL REPOSITORIO CASEEl repositorio CASE Es un almacén común en el que se guarda toda la información necesariapara la operación de un grupo de herramientas o de un entorno de desarrollo. El repositoriofacilita las funciones de almacenamiento y recuperación de datos, normalmente en formaconcurrente multiusuario, y el mantenimiento de relaciones entre los datos. Además puedesuministrar funciones de gestión de versiones, de seguridad y de gestión de transacciones.Para proporcionar las funciones de almacenamiento y recuperación de datos se requiere:• Un servicio de metamodelo, que permita definir las estructuras de datos que han dealmacenarse en el repositorio.• Un servicio de consulta y actualización (query) que permita acceder y manipular lainformación contenida en el repositorio.• Un servicio de vistas que permita definir subconjuntos de datos y operaciones que constituyanel subentorno de trabajo de ciertas actividades y entre los que haya que mantener relacionesconcretas de consistencia.• Un servicio de intercambio de datos, que facilite la importación y exportación de informaciónmediante ficheros externos.
    108. 108. INGENIERÍA DEL SOFTWARE Javier Martín 108BANCOS O EQUIPOS DE TRABAJOUn banco de trabajo debe integrar las herramientas necesarias para dar soporte a un determinado perfil profesional oactividad general de desarrollo. Un banco de trabajo debe de conseguir:• Integración de la presentación• Integración de control• Integración de datos (preferentemente con repositorio común).Según la actividad soportada, tendremos distintos bancos o equipos de trabajo, entre ellos:• Equipos de análisis y diseño: Herramienta CASE o CASE superior. Corresponde al entorno asociado a lametodología. Muchos de ellos cubren las dos fases (análisis y diseño), mientras que otros sólo cubren una. Elrepositorio común almacena todos los elementos definidos en la metodología soportada.• Entorno de programación. Es el banco de trabajo para la actividad de codificación pudiéndose extender aldiseño detallado y a las pruebas de unidades.• Equipo de verificación y validación: Capaz de facilitar las tareas de inspección y pruebas de módulos ysistemas. Suelen estar ligados al entorno de programación. Pueden incluir funciones de:¤ Análisis estático, con evaluación de métricas de calidad y generación de matrices o grafos dellamadas entre funciones y módulos.¤ Generación de tablas de referencias cruzadas.¤ Gestión de pruebas, automatizando la realización de ensayos.• Equipo de construcción de interfaz del usuario. Permite definir cómodamente el esquema de diálogo conel usuario, así como los elementos de interacción.• Equipo de gestión de configuración. Permite almacenar diferentes versiones de los elementos delproyecto, definir distintas configuraciones y controlar los cambios sucesivos.• Equipo de ingeniería inversa. Debe facilitar la extracción de información de diseño, los elementosabstractos a partir de un código o sistema software existente.• Equipo de gestión de proyectos. Facilita la confección de planes de trabajo, con la asignación de tiemposy recursos a diferentes tareas, y el seguimiento de su realización.
    109. 109. INGENIERÍA DEL SOFTWARE Javier Martín 109ENTORNOS ORIENTADOS AL PROCESODeben de ser capaces de soportar todas las actividades del ciclo de vida de desarrollo siguiendo un modelo definido. Unentorno global de estas características se designa como IPSE, ICASE o ISEE. La característica principal que distingueun entorno de esta clase de un banco de trabajo amplio es el soporte explícito de un modelo global de desarrollo. Elentorno debe poseer las características de integración del proceso, además de las de integración de datos, control ypresentación.Para conseguir este nivel de integración es necesario contar con un modelo formal del proceso de desarrollo. A diferencia delas metodologías parciales de análisis y diseño, este modelo suele construirse a medida de cada empresa productora desoftware. Un ISEE de uso general deberá permitir:• Construir la definición formal del modelo del proceso de desarrollo.• Asegurar la aplicación práctica del modelo definido.Aunque no existen entornos ISEE disponibles si existen esquemas generales de arquitectura de entornos orientados alproceso, 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 repositoriocomún. Su elemento principal es la definición de interfaz de acceso al repositorio. Sobre él pueden operar herramientasque automaticen las actividades previstas en el modelo del proceso. Existen implementaciones de repositorio quecumplen con la especificación PCTE, y también algunas colecciones de herramientas como las del proyecto PACT.¤ ESF (Eureka Software Factory). Define otro modelo de arquitectura, cuyo elemento central de integración es eldenominado ‘software bus’, que es un interfaz normalizado para la interconexión de herramientas. Se distinguen dosclases de herramientas: servidores y herramientas de interacción. Los servidores pueden realizar las funciones derepositorio, tanto centralizado como distribuido, y suministrar servicios o funciones automatizadas. Las herramientas deinteracción permiten la comunicación con los usuarios, que pueden acceder a los repositorios y a los servicios a travésde ellas.¤ Modelo NIST/ECMA. Contempla una estructura fija, compuesta por elementos que proporcionan una integración dedatos, basada en un repositorio común, integración de presentación mediante un soporte global de interfaz de usuario, eintegración del control, basada en la gestión de procesos y mensajes. El entorno puede particularizarse para un modelode desarrollo determinado instalando sobre estos elementos fijos una colección de herramientas.Ante la ausencia de productos CASE listos para usar se debe de tomar el enfoque de combinar productos para construir unentorno global.

    ×