Apuntes UNED

U.N.E.D.
Ingeniera Tcnica en Informtica de Gestin
Apuntes de
INGENIERA DEL SOFTWARE
Apuntes realizados por Antonio Reyes. C.A.Tenerife
Universidad Nacional de Educacin a Distancia (UNED) Ingeniera Tcnica en Informtica de Gestin Ingeniera del Software. RESUMEN
Concepto Descripcin
1. INTRODUCCIN 1.1. Concepto de Ingeniera de Sistemas Sistema Es un conjunto de cosas que ordenadamente relacionadas entre s contribuyen a determinado objeto. Ingeniera de sistemas La ingeniera de sistemas atiende a los aspectos de organizacin de sistemas informticos as como al proceso de su desarrollo. Subsistemas Son las partes de un sistema. Sistemas basados en Son los sistemas que ha de concebir y distribuir el ingeniero en informtica. Contienen uno computador o ms computadores dedicados a controlar el conjunto. Algunos sistemas slo se pueden construir con equipos multidisciplinares. La tarea de tratamiento de informacin que realizan los sistemas informticos puede ser realizada por tres elementos: Hardware, de una forma directa, Software, cuando la operacin se puede programar, y Usuario, que aunque no forme parte del sistema artificial se debe indicar como debe interactuar el usuario que opere en el sistema. La concepcin de un sistema informtico, que es la actividad de la ingeniera de sistemas basados en computadores, consiste en decidir qu elementos hardware y software se utilizarn o desarrollarn y qu usuarios operarn dicho sistema. Tambin repartir y asignar las actividades de cada uno de los elementos descritos. 1.2. Caractersticas del Software Hardware Son todos los elementos fsicos del computador. Software Son los programas, pero tambin los documentos, bases de datos o los procedimientos de operacin o de mantenimiento peridico. La ingeniera de software presenta las caractersticas especiales de que en su proceso de fabricacin, lo realmente costoso es el proceso de desarrollo inicial, ya que posteriormente se limitar a distribuir miles de copias a un costo muy bajo. Es decir, el costo de producir miles de unidades de un producto software es similar al costo de fabricar uno solo. Tareas de mantenimiento El software no se desgasta. Las tareas de mantenimiento de software deben considerarse como tareas adicionales de desarrollo, realizadas ocasionalmente. 1.3. Concepto de Ingeniera de Software Utilizado por primera vez a finales de los aos sesenta en la OTAN, el trmino de ingeniera de software se utiliza para designar el empleo de tcnicas y procedimientos de la ingeniera en general en el desarrollo de productos software. Adems amplia su visin de desarrollo de software con las actividades de anlisis y diseo previos, y de integracin y verificaciones posteriores, algo que se llama ciclo de vida del desarrollo software. 1.3.1. Perspectiva histrica El aumento de la capacidad de los computadores hizo evolucionar la actividad de desarrollo de software, que en un principio era una actividad casi artesanal y que dependa de la habilidad y creatividad del programador, hacia la aplicacin de tcnicas que permitieran: a) el trabajo en equipo; b) una organizacin del trabajo y; c) empleo de herramientas adecuadas. Se crearon metodologas de desarrollo especficas y particulares como las destinadas a la creacin de los sistemas de informacin. CASE Computer Aided Software Engineering. Son herramientas de soportes que permiten aplicar las tcnicas de la ingeniera de software. Sirven para apoyar las actividades inmediatamente anteriores a la codificacin. Se emplearon en los aos 80. IPSE Integrated Project Support Environment. ICASE Integrated CASE. Herramientas actuales Las IPSE e ICASE son las herramientas que se utilizan en la actualidad y permiten automatizar an ms la produccin de software. Pueden ser utilizadas durante todo el ciclo de vida de desarrollo. 1.3.2. La crisis del software La crisis del software, iniciada en los aos 60, debido a la fuerte evolucin del hardware que requera desarrollar aplicaciones software ms complejas, persiste hasta nuestros das, habindose convertido dicha crisis en una evolucin constante del hardware, lo que obliga a la ingeniera del software a una evolucin tambin contnua siendo dicha evolucin insuficiente. 1.3.3.Mitos del software
La continua evolucin de las disciplinas en el desarrollo del software ha provocado que se hayan creado ciertos mitos difciles de erradicar: El hardware es ms Es falso ya que el usuario interacta con el software principalmente. Es censurable la importante que el software realizacin de copias piratas. El software es fcil de Esto es falso para cualquier aplicacin de cierta importancia. El desarrollo de grandes desarrollar sistemas es muy complejo y costoso. El software consiste Un sistema informtico se compone de hardware, software, personas y procedimientos de exclusivamente en utilizacin. Tambin es software toda la documentacin del desarrollo que se necesita para programas ejecutables el mantenimiento. El desarrollo de software es Es falso ya que las tareas de anlisis y diseo son el fundamento para el resto del desarrollo. slo una labor de programacin Es natural que el software No exactamente. Si bien el desarrollo de software es susceptible de errores, no es admisible contenga errores que un software contenga siempre errores. Los errores del software son errores durante su desarrollo inicial y deben reducirse a un nivel lo ms bajo posible. 1.4. Formalizacin del proceso de desarrollo Una de las caractersticas de la ingeniera es la existencia de procedimientos bien establecidos para la realizacin de actividades de desarrollo, construccin, fabricacin, etc. En el caso de la ingeniera de software tenemos varios procedimientos o modelos: 1.4.1 El ciclo de vida del software. Modelos clsicos Ciclo de vida del software Constituye uno de los primeros logros de la ingeniera del software y consiste en identificar con detalle la forma que adopta el proceso de desarrollo del software. 1.4.1.1. El modelo en cascada Es el modelo de ciclo de vida ms antiguo y en l figuran distintas fases ordenadas secuencialmente de forma que el resultado de una se utiliza como entrada de la siguiente. Su secuencia es: Anlisis Diseo Codificacin Integracin Mantenimiento. Existen diferentes variantes en el que una de las fases se desarrolla an ms. Anlisis Consiste en analizar las necesidades de los usuarios potenciales del software para determinar qu hace el sistema a desarrollar y, a partir de ello, escribir la especificacin precisa. Diseo Descompone y organiza el sistema en elementos que se pueden desarrollar por separado. Se aprovecha as la divisin del trabajo. Produce la especificacin de cada componente. Codificacin En esta fase se escribe el cdigo fuente de cada elemento por separado. Integracin En esta fase se combinan todos los elementos y se comprueba el sistema completo. Se harn pruebas exhaustivas. Mantenimiento Durante la explotacin se harn cambios no previstos, se corregirn errores no detectados, o se introducirn mejoras. Especializacin El hecho de estar dividido en fases el ciclo de vida en cascada, hace que se permita una especializacin, pudiendo encontrar analistas, diseadores, programadores, etc. Documentos Los documentos que en cada fase se producen son: Documento de Requisitos SRD (Software Requirements Document). Es producto de la fase de anlisis y consiste en del Software una especificacin precisa y completa del sistema. Se prescinde de detalles. Documento de diseo del SDD (Software Design Document). Es producto de la fase de diseo. Es una descripcin Software de la estructura global del sistema, y la especificacin de qu debe hacer cada una de sus partes y cmo se combinan entre s. Cdigo Fuente Es el producto de la fase de codificacin. Contiene el programa fuente debidamente comentado. El Sistema Software Es el producto de la fase de integracin. Se deben documentar las pruebas realizadas. ejecutable Documentos de Cambios Se debe hacer despus de cada modificacin realizada durante el mantenimiento. Se incluir el problema detectado, la solucin adoptada y la modificacin realizada. Es importante destacar la necesidad de terminar correctamente una fase antes de comenzar la siguiente, y ello porque es muy costoso corregir errores de una fase anterior si parte del trabajo de esa fase ya est hecho. En esos casos hay que retornar a un punto anterior del ciclo de vida. 1.4.1.2. El modelo en V Este modelo, que incluye las mismas fases que el modelo en cascada, tiene forma de V, e incluye en el tramo descendente de la V las fases de Anlisis Diseo Codificacin, mientras que en el trazo ascendente estn las fases de Codificacin Integracin Explotacin. En la rama izquierda el sistema se va descomponiendo en elementos cada vez ms sencillos mientras que en la rama derecha se van construyendo poco a poco hasta disponer del sistema completo. Verificacin Consiste en comprobar que una parte del sistema cumple con sus especificaciones formales. Validacin Consiste en comprobar que un elemento satisface las necesidades del usuario identificadas durante el anlisis. 1.5. Uso de prototipos
El inconveniente de los modelos clsicos es que, una vez detectado un error, las vueltas atrs para corregirlo, son muy costosas. Por otro lado, en sistemas innovadores, que carecen de experiencia previa, no siempre se puede saber si se han adoptado las decisiones adecuadas. Esto se intenta paliar con el uso de prototipos. Prototipo Es un sistema auxiliar que permite probar soluciones parciales. Su coste ser inferior al del sistema final lo que permitir corregir errores a un coste final inferior. Para reducir su coste se puede: limitar sus funciones, capacidad, eficacia, reduciendo la parte a desarrollar, usar un hardware ms potente, etc. 1.5.1. Prototipos rpidos Prototipos rpidos La finalidad de los prototipos rpidos es adquirir experiencia. Se utilizan en las fases de diseo y anlisis y sirven para experimentar alternativas y verificar las decisiones adoptadas. Una vez completadas estas fases el sistema final se escribe partiendo de cero. Lo importante es hacerlos rpidamente. Prototipos throw-away Son los prototipos de usar y tirar y tienen limitada su funcionalidad. Prototipos mock up Son los prototipos maqueta y tiene limitada su capacidad. 1.5.2. Prototipos evolutivos Mediante el prototipo evolutivo se aprovecha al mximo su cdigo. Se desarrollan en el mismo soporte hardware/software. Primero se construye un prototipo inicial que permitir tomar las primeras decisiones de diseo; posteriormente, el prototipo se va ampliando con ms funcionalidades, de forma que en cada iteracin, el cdigo es ms y ms completo hasta que el ltimo prototipo constituye el sistema final. Al mismo tiempo que se desarrolla, se van generando los documentos de especificacin. 1.5.3. Herramientas para realizacin de prototipos En los prototipos evolutivos se utilizarn las mismas herramientas que para el desarrollo del sistema definitivo. En prototipos rpidos se suelen utilizar herramientas de 4 generacin que son herramientas que se apoyan en la utilizacin de bases de datos, lenguajes especializados para construir el interfaz de usuario, formularios, etc. Lenguajes de muy alto nivel Son lenguajes que permiten un estilo declarativo. Lo son los lenguajes de 4 generacin. Lenguajes declarativos Son lenguajes que permiten describir el resultado deseado sin escribir las operaciones para conseguirlo. Lenguajes de especificacin El objetivo de estos lenguajes es formalizar la especificacin, para, a partir de un compilador, obtener directamente el prototipo. Algunos son: VDM y Z. Reutilizacin Es una tcnica que consiste en realizar los programas con una visin un poco ms general para que puedan ser utilizados en ms de un proyecto. 1.6. El modelo en espiral El modelo en espiral es un refinamiento del modelo evolutivo. Consiste en una espiral dibujada sobre un cuadrado dividido en cuatro partes. En cada uno de los cuadrados figura una actividad: Planificacin, Anlisis de Riesgo, Ingeniera y, Evaluacin. Planificacin Establece el contexto del desarrollo. Dice qu parte del mismo se abordar en ese ciclo. Anlisis de Riesgo Evala las diferentes alternativas, tomando la ms adecuada. Ingeniera En los modelos clsicos corresponde a lo que sera: anlisis, diseo, codificacin, etc. Evaluacin Se analiza los resultados de la fase de ingeniera con la colaboracin del cliente. Su resultado se utilizar para el siguiente ciclo de la espiral. 1.7. Combinacin de modelos Muchas veces resulta ventajoso combinar diferentes modelos de forma que, por ejp. para la fase de anlisis se utilice el modelo de prototipo rpido, para el diseo, un modelo en cascada, o cualquier otro. De hecho el modelo en espiral es una combinacin de modelos, pues la actividad de ingeniera puede realizarse con cualquier otro modelo. 1.8. Mantenimiento del software Esta actividad consiste en rehacer parte de las actividades anteriores (anlisis, diseo, codificacin y pruebas) para introducir cambios en una aplicacin ya entregada al cliente y en explotacin. 1.8.1. Evolucin de las aplicaciones El software se caracteriza por la ausencia de deterioro o envejecimiento durante su utilizacin. Una aplicacin funcionar igual que el primer da. Sin embargo, es necesario realizar un mantenimiento, existiendo tres tipos: Mantenimiento correctivo Su objetivo es eliminar errores no detectados en el desarrollo. Este tipo de mantenimiento no debera existir de haberse realizado con garantas de calidad. Mantenimiento adaptivo Este mantenimiento se produce para adaptar el software a plataformas hardware nuevas o para cambiar la interfaz de las aplicaciones. Mantenimiento perfectivo Este tipo de mantenimiento se produce para obtener mejores versiones de un producto sujeto a fuerte competencia. Tambin se produce cuando las necesidades del usuario evolucionan y hay que modificar los requisitos iniciales lo que provoca un cambio en la especificacin de requisitos. 1.8.2. Gestin de cambios La aplicacin de tcnicas de ingeniera a la actividad de mantenimiento exige organizar y gestionar adecuadamente el desarrollo de estos cambios. Se pueden dar dos enfoques:
Si el cambio afecta a la mayora de los componentes del producto, dicho cambio se podra plantear como nuevo desarrollo y aplicar un nuevo ciclo de vida, utilizando el desarrollo actual como si fuera un prototipo. Modificacin de algunos Si el cambio afecta a una parte localizada del producto, se puede organizar como una elementos modificacin de algunos elementos. En ambos casos un cambio de cdigo conlleva una revisin de la documentacin del producto (diseo, especificacin de requisitos). Informe de problema Es un documento que describe una dificultad en la utilizacin del producto, que requiere una modificacin para subsanarla. Puede ser generado por los usuarios. Informe de cambio Describe la solucin dada a un problema y el cambio realizado en el producto software. A veces el informe de problema y el informe de cambio se refunden en uno solo. 1.8.3. Reingeniera La reingeniera o ingeniera inversa son las tcnicas que se utilizan para mantener productos no documentados o desarrollados de forma artesanal. Ingeniera inversa Consiste en tomar el cdigo fuente y a partir de l tratar de construir alguna documentacin, (diseo, estructura modular de la aplicacin, dependencia entre mdulos, etc.) lo que llevara a aclarar la parte a modificar. Reingeniera La reingeniera trata de generar un sistema bien organizado y documentado a partir del sistema inicial deficiente. Puede ser necesario modificar el cdigo fuente o reconstruir la documentacin inexistente. 1.9. Garanta de calidad de software La calidad de un producto software viene determinado por el proceso seguido en su desarrollo. 1.9.1. Factores de calidad Los diferentes enfoques que se pueden aplicar para valorar la calidad de un producto no software, pureza, resistencia, etc., no son aplicables en general en los productos software, no existiendo mtricas precisas que permitan valorar adecuadamente dicho producto. Las mediciones de la calidad se realizan basndose en tres valoraciones: a) factores, que constituyen el nivel superior; b) criterios, que constituyen el nivel intermedio, y; c) mtricas, que constituyen el nivel inferior y son mediciones de ciertos atributos siendo la base para evaluar los criterios intermedios. Factores de calidad Lo son los siguientes: Correccin. Grado en que un producto cumple con su especificacin. Fiabilidad. Grado de ausencia de fallos de un producto durante su operacin. Puede verse como el n de fallos o el tiempo inutilizable durante un perodo dado. Eficiencia. Es la relacin entre la cantidad de resultados obtenidos y los recursos requeridos para ello. Se mide como la inversa de los recursos consumidos para una operacin dada. Seguridad. Es la dificultad de acceso a los datos o a las operaciones por personal no autorizado. Facilidad de uso. Es la inversa del esfuerzo requerido para aprender a utilizar un producto software y usarlo adecuadamente. Mantenibilidad. Es la facilidad para corregir un producto software. Flexibilidad. Es la facilidad para modificar el producto software. Facilidad de prueba. Es la inversa del esfuerzo requerido para ensayar un producto software y comprobar su correccin o fiabilidad. Transportabilidad. Es la facilidad para adaptar el producto software a una plataforma diferente de aquella para la que fue desarrollada inicialmente. Reusabilidad. Es la facilidad para emplear partes del producto en otros desarrollos posteriores. Interoperatividad. Es la facilidad o capacidad del producto software para trabajar en combinacin con otros productos. 1.9.2. Plan de garanta de calidad Una adecuada calidad del producto es inalcanzable sin una buena organizacin del desarrollo. SQAP Acrnimo del ingls Software Quality Assurance Plan o Plan de Garanta de Calidad Software es el documento en el que se ha materializado la organizacin del proceso de desarrollo software. Incluye: Organizacin de los equipos de personas y la direccin y seguimiento del proyecto. Modelo de ciclo de vida a seguir, detallando sus fases y actividades. Documentacin requerida, especificando el contenido de cada documento. Revisiones y auditoras a realizar durante el desarrollo para garantizar la correccin de las actividades y los proyectos. Organizacin de las pruebas a realizar a distintos niveles.
Nuevo desarrollo.
Organizacin de la etapa de mantenimiento, especificando cmo ha de gestionarse la realizacin de cambios sobre el producto en explotacin.
1.9.3. Revisiones Una revisin consiste en inspeccionar el resultado de una actividad para determinar si es aceptable o si contiene defectos a subsanar. Se aplica a la documentacin generada en cada fase del desarrollo. Las revisiones han de ser formalizadas, es decir, deben estar contempladas en el ciclo de vida y debe existir tambin una normativa para su realizacin.. Recomendaciones Las revisiones deben ser realizadas por un grupo de personas y no por un solo individuo. Esto permite diferentes puntos de vista. El grupo que realiza la revisin debe ser reducido. De tres a cinco personas. La revisin no debe ser realizada por los autores del producto para garantizar la imparcialidad de criterio. Se debe revisar el producto, pero no el productor ni el proceso de produccin. Si la revisin ha de decidir si un producto se acepta o no, ha de realizarse antes una lista formal de comprobaciones y atenerse a ella. Debe levantarse acta de la reunin de revisin, conteniendo los puntos importantes discutidos as como las decisiones adoptadas. 1.9.4. Pruebas Las pruebas consisten en hacer funcionar un producto software en condiciones determinadas y comprobar si los resultados obtenidos son correctos. Su objetivo es descubrir errores para subsanarlos. Las pruebas no permiten garantizar la calidad de un producto, pues pueden existir fallos que slo se manifiesten con otras pruebas ms exahustivas. Sin embargo, una prueba tiene xito si descubre algn error, con lo que se sabe que el producto no cumple con algn criterio de calidad. 1.9.5. Gestin de configuracin Configuracin de Software Por configuracin de software se entiende la manera en que diversos elementos se combinan para constituir un producto bien organizado, tanto desde el punto de vista de su explotacin como de su mantenimiento. Los elementos que componen la configuracin son aquellos que forman parte del desarrollo (especificaciones, diseo, cdigo fuente, programas, datos y resultados de pruebas), as como aquellos que forman parte del producto entregado al cliente (programas, manuales de usuario, documentos de mantenimientos, normas del proyecto, etc.). Dado que estos elementos pueden variar a lo largo del tiempo, se puede dar el caso de tener diferentes configuraciones particulares. Para controlar dichas configuraciones se utilizan varias tcnicas: Control de versiones Consiste en almacenar organizadamente las sucesivas versiones de cada elemento de la configuracin, de forma que se pueda acceder a una configuracin concreta cmodamente. Control de cambios Consiste en garantizar que las diferentes configuraciones se componen de elementos compatibles entre s. Lnea base Es una configuracin particular del sistema que se utiliza en el control de cambios. Cada lnea base se construye a partir de otra mediante la inclusin de ciertos cambios. Las lneas bases constituyen configuraciones estables congeladas y no pueden ser modificadas. Si se desea modificar una lnea base se crear otra a partir de aquella. 1.9.6. Normas y estndares Las recomendaciones de la ingeniera de software ha dado lugar a la creacin de normas que algunas organizaciones han recogido dando lugar a estndares. IEEE Institute of Electrical and Electronics Engineer. Ha establecido una coleccin de normas, muchas de ellas tambin admitidas como normas ANSI (American National Standards Institute). DoD Department of Defense. La norma fundamental es la DoD-STD-2167A. Ser sustituida por la norma MIL-STD-SDD y contiene modelos de los documentos a redactar. ESA European Space Agency. Posee la norma ESA91 que es general para el desarrollo de software. ISO International Standards Organization. Integrado por los organismos nacionales de normalizacin de muchos paises (AENOR en Espaa), publica un sinfn de normas para la actividad tcnico-industrial. La norma ISO-9001 contiene normas para la ingeniera de software y establece los criterios que deben cumplir las empresas que desarrollen software para obtener certificaciones de determinados niveles de garanta de calidad. METRICA-2 Norma espaola desarrollada por el CSIC para el Ministerio de las Administraciones Pblicas. Es una norma para el desarrollo de sistemas de informacin de las administraciones pblicas, basada en la metodologa de anlisis y diseo estructurado de Yourdon/DeMarco. 2. ESPECIFICACIN DE SOFTWARE Este tema se dedica a describir la labor de anlisis y definicin de los requisitos que ha de cumplir un proyecto de software, lo que debe dar lugar a la especificacin de software.
2.1. Modelado de Sistemas De la misma forma que en arquitectura se utilizan maquetas para analizar edificios, el desarrollo de sistemas permite la utilizacin de modelos conceptuales que reflejen, por un lado, la organizacin de la informacin y, por otro lado, las diversas transformaciones que han de llevarse a cabo con dicha informacin. Por modelo se entiende un modelo completo y preciso del comportamiento u organizacin del sistema software. No se trata de los modelos vistos en el tema 1. 2.1.1. Concepto de modelo Modelo Un modelo conceptual es todo aquello que nos permite conseguir una abstraccin lgicomatemtica del mundo real de forma que facilite comprender el problema a resolver. Caractersticas Un modelo debe establecer las propiedades y caractersticas del sistema. Ofrece una visin de alto nivel, sin explicar detalles. Debe explicar QU hace el sistema. Objetivos 1. Facilitar la comprensin del problema a resolver. 2. Establecer un marco para la discusin que sistematice las labores de anlisis inicial y revisiones futuras. 3. Fijar las bases para realizar el diseo. 4. Facilitar la verificacin del cumplimiento de los objetivos del sistema. 2.1.2. Tcnicas de modelado La obtencin de un modelo que cumpla los objetivos anteriores es compleja. Puede no existir experiencia previa, o simplemente el sistema a modelar es complejo. Para su realizacin existen diversas tcnicas: 2.1.2.1. Descomposicin. Modelo jerarquizado La tcnica de descomposicin se basa en el axioma divide y vencers y consiste en descomponer el problema original en subproblemas. Descomposicin horizontal Consiste en descomponer funcionalmente un problema. Ejp. un sistema de nminas se puede descomponer en subsistemas de pagos a la seg.soc., pago irpf, pago de nmina, etc. Para que funcione el sistema global se debern establecer interfases entre los subsistemas. Descomposicin vertical Consiste en descomponer un modelo detallando su estructura. Ejp. en el sistema de nminas sera: 1 dar de alta el trabajador, 2 calcular ingresos brutos, 3 calcular retenciones, etc. 2.1.2.2. Aproximaciones sucesivas Cuando se va a desarrollar un sistema se puede utilizar uno ya existente como modelo de partida. Obviamente, el sistema a desarrollar ser diferente. Por el contrario, cuando el sistema a desarrollar sustituya a uno manual se podr utilizar ste como modelo preliminar, de forma que se pueda depurar mediante aproximaciones sucesivas. Esta depuracin es compleja y requiere experiencia y estudio del problema a resolver. Es conveniente contar con la colaboracin de alguien que conozca el sistema anterior. 2.1.2.3. Empleo de diversas notaciones A veces es necesario utilizar diferentes notaciones para elaborar un modelo. Se puede utilizar el lenguaje natural aunque ste adolece de imprecisiones e incorrecciones por lo que es preferible el uso de esquemas. CASE La utilizacin de herramientas CASE permiten la utilizacin de diversas notaciones (texto, tablas, diagramas, grficos, etc.). 2.1.2.4. Considerar distintos puntos de vista La necesidad de adoptar un punto de vista en la creacin de un modelo har que ste se vea necesariamente influido por aquel. Algunos puntos de vista pueden ser: el del usuario, el del mantenedor del sistema, el funcional, etc. A veces un modelo puede estar definido desde varios puntos de vista. 2.1.2.5. Realizar un anlisis del dominio Dominio Se entiende por dominio el campo de aplicacin en el que se encuadra el sistema a desarrollar. Anlisis del dominio Son las consideraciones a tener en cuenta al analizar una aplicacin. Hay que analizar el dominio de la aplicacin para situarla dentro de un entorno mucho ms global. Puede ser la terminologa utilizada en ese campo en concreto, la forma de hacer las cosas, etc. Aspectos a considerar A la hora de realizar el anlisis del dominio ha de tenerse en cuenta: la normativa que afecte al sistema, otros sistemas semejantes, estudios recientes, bibliografa actualizada, etc. Ventajas del enfoque global 1. Facilitar la comunicacin entre analista y usuario del sistema, entendiendo por usuario la persona que utilizar el sistema una vez terminado y que conoce el tema en profundidad. Uso de trminos propios del campo a solucionar. 2. Creacin de elementos realmente significativos del sistema. Esto evita que las aplicaciones queden particularizadas en exceso, adoptando soluciones globales. 3. Reutilizacin posterior del software desarrollado. 2.2. Anlisis de requisitos de software Con el anlisis de requisitos se trata de caracterizar el problema a resolver. Analista Es el ingeniero de software encargado de realizar el anlisis de requisitos de software. Cliente Se entiende por tal el conjunto de personas que conoce en profundidad parte o todo el problema a automatizar. A veces no existir como tal, debiendo investigar el analista por su cuenta; otras veces ser el encargado de elaborar junto con el analista las especificaciones del proyecto software y que ambos verificarn una vez realizado; en otras ocasiones el
cliente es simplemente parte de una especificacin de un problema mayor. 2.2.1. Objetivos del anlisis El objetivo del anlisis es obtener las especificaciones del sistema a desarrollar. Se realiza mediante un modelo vlido que recoga todas las necesidades del cliente y todas las restricciones que el analista considere debe verificar el sistema. Propiedades del modelo Para lograr una especificacin correcta, el modelo global del sistema deber cumplir las siguientes propiedades: 1. Completo y sin omisiones Aunque parezca fcil de cumplir, a veces se omiten los requisitos mnimos del hardware o el sistema operativo sobre el que se ejecutar el sistema. 2. Conciso y sin Si la documentacin es excesiva suele ser por contener repeticiones o trivialidades. Por otro trivialidades lado, si el sistema es muy extenso, puede ocurrir que se pasen por alto partes esenciales. 3. Sin ambigedades Las ambigedades han de evitarse totalmente pues pueden producir problemas tales como: dificultades de diseo, errores en la implementacin, imposibilidad de verificar la especificacin, etc. 4. Sin detalles de diseo o Un buen anlisis nunca debe entrar en CMO resolver el problema sino en el QU. implementacin 5. Fcilmente entendible El cliente debe ser capaz de discutir todos los aspectos. Para ello se debe emplear un por el cliente lenguaje que facilite ese entendimiento. 6. Separando requisitos Los requisitos funcionales establecen el modelo de funcionamiento del sistema y son el funcionales y no fruto de las discusiones del analista con el cliente. Los requisitos no funcionales son ms funcionales tcnicos y no interesan tanto al cliente; se refieren a temas como capacidad mnima y mxima, aspectos de seguridad, fiabilidad, mantenimiento, etc. Ambos requisitos, funcionales y no funcionales, han de ir separados. 7. Dividiendo y La forma ms sencilla de simplificar un modelo es dividindolo y jerarquizndolo en jerarquizando el modelo submodelos. Se ir de lo general a lo particular. 8. Fijando los criterios de Es importante indicar en el modelo los criterios de validacin del sistema. No hay que validacin olvidar el aspecto contractual. Se podra realizar un manual del usuario preliminar. 2.2.2. Tareas de anlisis La realizacin de un anlisis de requisitos conlleva realizar una serie de tareas que por este orden son: 1. Estudio del sistema en su Lo primero que se ha de conocer es el medio hardware en el que se desenvolver el sistema. contexto Habra que hacer un contexto global de funcionamiento del sistema para, posteriormente, hacer una configuracin particular al cliente en concreto. 2. Identificacin de Inicialmente, el cliente pedir ms funciones de las necesarias. El analista debe concretar necesidades las necesidades que se pueden cubrir con los recursos disponibles, respetando el presupuesto y el plazo de entrega. Debe haber una comunicacin fluida con el cliente que permita hacer una propuesta satisfactoria para todos. Se deben descartar las funciones que son muy costosas y no aportan gran cosa al sistema. Si alguna funcin tiene cierto inters pero es excesivamente costosa, se debe proponer alguna solucin parecida o incompleta. El analista ha de convencer a todos de que la solucin propuesta es la adecuada. 3. Anlisis de alternativas. Esta tarea, en la que aparece el enfoque de ingeniero de software que debe tener el analista, Estudio de viabilidad consiste en buscar la alternativa que cubra las necesidades reales detectadas en el paso anterior, teniendo en cuenta su viabilidad econmica y tcnica. Cada alternativa tendr un estudio de viabilidad que ser el que decidir sobre la alternativa. Esta etapa es necesaria en proyectos de alto presupuesto o alta complejidad. 4.Establecimiento del Las conclusiones adoptadas en pasos anteriores se irn plasmando en el modelo del sistema modelo del sistema segn se vaya avanzando. Al final, se obtendr un modelo del sistema global jerarquizado en el que figurarn, a su vez, subsistemas que tendrn que ser desarrollados. Se utilizarn herramientas CASE, procesadores de texto, grficos, etc. 5. Elaboracin del El documento de especificacin de requisitos es el resultado final del anlisis. Es documento de importante sealar que este documento es el documento de partida para el trabajo del especificacin de requisitos diseador. 6. Revisin continuada del Es muy frecuente que se produzcan cambios en la especificacin de requisitos, muchas anlisis veces por cambios de criterio del cliente. Esto obliga a realizar una revisin continuada del anlisis. Es frecuente que dicha revisin no se lleve a cabo y eso da lugar a problemas de verificacin. 2.3. Notaciones para la especificacin Si bien el empleo de diferentes notaciones para especificar un problema debera dar lugar a la misma especificacin, nos vemos con que el empleo de una notacin adecuada para cada caso dar lugar a una mejor especificacin para ese caso. El cliente, usuario y, todos los que participen en el proyecto debern conocer la notacin que se utilice. Existen varias: 2.3.1. Lenguaje natural
El lenguaje natural es la forma ms inmediata de realizar una especificacin, sin embargo presenta los inconvenientes de imprecisiones, repeticiones e incorrecciones. Se utilizar cuando haya que aclarar algo concreto del sistema. Es importante organizar y estructurar los requisitos de la especificacin. Para ello es conveniente concebir cada requisito como una clasula entre el analista y el cliente. Por otro lado, el lenguaje natural estructurado, trata de establecer ciertas reglas para la construccin de frases de forma que tengan una estructura similar a las estructuras de secuencia, condicin e iteracin. 2.3.2. Diagramas de flujos de datos Enfoque de anlisis El enfoque del anlisis estructurado consiste en considerar que un sistema software se estructurado puede modelar mediante el flujo de datos que entra al sistema, las transformaciones realizadas al mismo y el flujo de datos producido en la salida. DFD Diagrama de Flujo de Mediante el diagrama de flujo de datos, se puede Datos modelar de forma sencilla las transformaciones y los flujos de datos utilizando: 1. Flechas, para indicar un flujo de datos, 2. Crculos, para indicar un proceso o transformacin. 3. Rectngulos, para indicar una unidad externa. 4. Una lnea doble para indicar un almacn de datos. DFD de contexto o nivel 0 Es un DFD del sistema global. Contiene un nico proceso. Constituye el nivel 0. Niveles Para refinar un modelo, los DFD se usan de forma jerarquizada por niveles. Explotar Efecto mediante el cual un proceso de un DFD se detalla mediante otro DFD de un nivel ms alto. DFD 0 o de nivel 1 Es el nico DFD que se puede derivar del DFD de contexto. En l figurarn cuantos procesos sean necesarios, pero se respetarn los flujos de entrada y salida existentes en el DFD de contexto. Slo puede exister un DFD 0 o de nivel 1. Refinamientos Cada refinamiento dar lugar a un nuevo nivel en la jerarqua del diagrama. Han de ir numerados con referencia al DFD del que explota. En todos ellos los flujos de datos de entrada y salida antes de la explosin del proceso debe coincidir con los flujos de entrada y salida del DFD resultado de la explosin o refinamiento. El refinamiento no debe ser excesivo. Ventajas La ventaja de los DFD es su fcil comprensin por los clientes. Desventajas Son diagramas estticos, en ningn momento se puede saber el orden de los procesos. 2.3.3. Diagramas de transicin de estados Dinmica del sistema Lo conforman todos los estados y las sucesivas transiciones entre ellos. Diagramas de transicin Se complementan con los DFD y describe el comportamiento dinmico del sistema. Se usan: 1. Los dobles crculos para indicar el inicio o fin de un proceso. 2. Los rectngulos o crculos para indicar un estado intermedio del sistema. 3. Las flechas para indicar los eventos que provocan los cambios de estados. 2.3.4. Descripciones funcionales. Pseudocdigo Estructuras bsicas Esta notacin es esencial en la descripcin de los requisitos funcionales. Mediante pseudocdigo y utilizando un lenguaje natural estructurado se pueden emplear las siguientes estructuras: a) Seleccin (IF); b) Seleccin por casos (SELECT CASE); c) Iteracin con pre-condicin (WHILE); d) Iteracin con post-condicin (REPEAT); e) Nmero de iteraciones conocido (FOR). PDL El PDL (Program Description Language), es un lenguaje pensado para realizar el diseo, es muy parecido al pseudocdigo pero incluye estructuras de lenguajes de alto nivel. 2.3.5. Descripcin de datos Consiste en detallar la estructura interna de los datos (relevantes) que manejar el sistema sin descender a detalles de diseo o codificacin. Diccionario de datos Es una notacin utilizada en la metodologa de anlisis estructurado. Es ms informal que las declaraciones de un lenguaje pero es til para la especificacin. Consta de: 1. Nombre o nombres. Ser la denominacin con la que se referirn a un dato. 2. Utilidad. Se indicarn los procesos en los que se utilizar el dato. 3. Estructura. Se indicarn los elementos de los que est constituido el dato. Se utilizar la notacin: A + B Secuencia o concatenacin de los elementos A y B
[A | B] Seleccin entre los distinos elementos A o bien B {A}N Repeticin N veces del elemento A. Si se ignora N, no se pone / descripcin / Descripcin en lenguaje natural como comentarios = Separador entre el nombre de un elemento y su descripcin.
2.3.6. Diagrama de modelo de datos Modelo entidad-relacin Es el modelo de datos que se considera fundamental para la especificacin. Consta de: 1. Rombo, para indicar la relacin. 2. Rectngulo, para indicar las entidades. 3. Lneas que sirven para unir las relaciones y las entidades. 4. La cardinalidad, que indican entre qu valores mnimo y mximo se mueve la relacin entre entidades. Cardinalidad.
2.4. Documento de especificacin de requisitos SRD El documento de especificacin de requisitos o Software Requirements Document (SRD) o Software Requirements Specification (SRS) es el documento que recoge todo el fruto del trabajo realizado durante el anlisis del sistema. Modelo de SRD de la ESA El modelo general de la Agencia Espacial Europea consta de varias partes: 1. Introduccin 1.1. Objetivo. Describe brevemente el proyecto, destinatarios, calendario. 1.2. mbito. Se dar nombre al producto/ y qu hace cada uno y/o qu no hace. 1.3. Definiciones, siglas y abreviaturas que se utilizarn en el documento. 1.4. Referencias, a otros programas, bibliografa. 1.5. Panormica del documento. Describe la organizacin y contenido del resto del doc. 2. Descripcin general 2.1. Relacin con otros proyectos. 2.2. Relacin con proyectos anteriores y posteriores. 2.3. Objetivos y funciones. Se describir el sistema en su conjunto con los objetivos y funciones principales. 2.4. Consideraciones de entorno. Son caractersticas especiales que debe tener el entorno. 2.5. Relaciones con otros sistemas. Describe si se integrar en otros sistemas, etc. 2.6. Restricciones generales. P. Ejp. metodologa de desarrollo, lenguaje de programacin, restricciones de hardware, de sistema operativo, etc. 2.7. Descripcin del modelo. Debe describir el modelo conceptual que se propone para desarrollar el sistema en su conjunto y para cada una de sus partes ms relevantes. 3. Requisitos especficos Los requisitos han de ser concisos y precisos, no han de incluirse aspectos de diseo o desarrollo. Se puede incluir el grado de cumplimiento segn sea: obligatorio, recomendable u opcional. 3.1. Requisitos funcionales. Son los que describen el QU hace el sistema y est ligado al modelo conceptual. Se concretarn operaciones de tratamiento de informacin, generacin de informes, etc. 3.2. Requisitos de capacidad. Son los volmenes de informacin a procesar. 3.3. Requisitos de interfase. Se refiere a la conexin con otros sistemas (protocolos, formato de ficheros, sistemas operativos, etc.). 3.4. Requisitos de operacin. Incluye los requisitos de interfase de usuario pero adems, el arranque y parada, copias de seguridad, instalacin y configuracin. 3.5. Requisitos de recursos. Elementos hardware, software, instalaciones, etc. 3.6. Requisitos de verificacin. Son los que debe cumplir el sistema para su verificacin. 3.7. Requisitos de prueba de aceptacin. 3.8. Requisitos de documentacin. La que formar parte del producto a entregar. 3.9. Requisitos de seguridad. Confidencialidad, virus, integridad. 3.10. Requisitos de transportabilidad. A otros sistemas operativos. 3.11. Requisitos de calidad. Son aquellos que no estn incluidos en otros apartados. 3.12. Requisitos de fiabilidad. Lmite aceptable de fallos o cadas. 3.13. Requisitos de mantenibilidad. 3.14. Requisitos de salvaguarda. Deben evitar que los errores tengan consecuencias graves en los equipos o personas.
10
3. FUNDAMENTOS DEL DISEO DE SOFTWARE Este tema y el siguiente se dedica a CMO resolver el proyecto de software. En este tema se abordan los fundamentos de la etapa de diseo y se divide en cuatro apartados: a) Qu se entiende por diseo; b) Conceptos fundamentales; c) Notaciones utilizadas, y; d) Formatos propuestos 3.1. Introduccin Diseo La palabra diseo es un trmino mediante el cual se trata de definir y formalizar la estructura del sistema con el suficiente detalle como para permitir su realizacin fsica. Para su realizacin se parte del SRD siendo un proceso creativo nada trivial donde prima el mtodo iterativo de prueba y error. Know-how Es el aprovechamiento del enfoque dado en un proyecto diferente al actual y que puede ser til para el proyecto presente. Adquirir experiencia La nica forma de aprender a disear es adquirir experiencia, participar en muchos proyectos y analizar proyectos existentes. Objetivos actuales Los objetivos actuales del diseo es conseguir que el software sea fcil de mantener y de que su cdigo sea reutilizable. No existe lmite No existe un lmite claro entre el anlisis y el diseo, ya que el paso de aqul a ste se hace de forma gradual. Actividades Son realizadas a lo largo del proceso de diseo y tienen como objetivo sistematizar cada uno de los aspectos o elementos de la estructura del sistema. Con ellas se persigue un refinamiento progresivo del diseo. Algunas de esas actividades son: 1. Diseo arquitectnico En ella se deben abordar los aspectos estructurales y de organizacin del sistema y su posible divisin en subsistemas o mdulos. Esto incluye las interfases entre los mdulos y las relaciones entre los subsistemas. Aporta una visin general del sistema. 2. Diseo detallado Aqu se aborda la organizacin de los mdulos. Se debe determinar cul es la estructura ms adecuada para cada mdulo segn el punto anterior. Mdulos de Definicin 3. Diseo procedimental Aqu se aborda la organizacin de las operaciones o servicios que ofrecer cada mdulo. Se desarrolla en pseudocdigo. Mdulos de Implementacin. 4. Diseo de datos Aqu se aborda la organizacin de la base de datos del sistema, pudindose realizar al mismo tiempo que el diseo detallado y procedimental. Se parte, para ello, del diagrama ER y diccionario de datos del SRD. 5. Diseo de la interfaz de Es la actividad encargada de la organizacin de la interfaz de usuario. usuario Producto del diseo Es el resultado de la aplicacin de las actividades anteriores y se recoger en el SDD (Software Design Document) o (Software Design Description). 3.2. Conceptos de base Los conceptos que se vern a continuacin no se limitan en su mayora a la etapa de diseo sino que sern tiles en otros mbitos, habiendo dado lugar, algunos de ellos, a la creacin de metodologas especficas. 3.2.1. Abstraccin Abstraccin La abstraccin ayuda mucho a conseguir los objetivos de obtener elementos fcilmente mantenibles y reutilizables y consiste, esencialmente, en identificar los elementos realmente significativos de los que consta el nuevo sistema software con el fin de abstraer la utilidad especfica de cada uno, incluso ms all del sistema software para el que se est diseando. El proceso de abstraccin se aplicar en todos los niveles de diseo. Formas de abstraccin Existen tres formas de abstraccin: 1. Abstracciones funcionales, que son aquellas que sirven para crear expresiones parametrizadas mediante la utilizacin de funciones o procedimientos. Se debe fijar los parmetros a facilitar, el algoritmo que resolver el problema y los parmetros de salida o resultados. 2. Tipos abstractos, que sirven para crear los nuevos tipos de datos. Consta de su definicin y de las operaciones que se pueden hacer con l. 3. Mquina abstracta, que sirve para definir formalmente el funcionamiento de una mquina (p.ejp. intrprete de SQL, protocolo de comunicaciones, etc.). 3.2.2. Modularidad Divisin del trabajo La modularidad permite la divisin del trabajo entre diferentes personas de forma que cada una de ellas se dedique a un mdulo bien definido. Ello exige una importante coordinacin debiendo quedar definidas las interfases entre los diferentes mdulos. Otras ventajas Otras ventajas de la modularidad son: 1. Claridad, pues es ms fcil entender cada parte por separado que un todo. 2. Reduccin de costos, siempre que el n de mdulos sea adecuado, resulta ms barato desarrollar, mantener y documentar un sistema modular, que otro que no lo es. 3. Reutilizacin, pues si se realizan teniendo en cuenta otras posibles aplicaciones, se podrn reutilizar.
11
3.2.3. Refinamiento El objetivo de un sistema, consistente en plasmar la especificacin en un lenguaje de alto nivel, se debe refinar en sucesivos pasos hasta que todo quede expresado en el lenguaje de programacin del computador. 3.2.4 Estructuras de datos Las decisiones respecto a las estructuras de los datos son esenciales en el diseo de un sistema software. Tal es as, que se han desarrollado muchas metodologas que tienen como punto de partida la estructura de los datos. Se deben tener en cuenta estructuras tales como: registros, conjuntos, formaciones, listas, pilas, colas, rboles, grafos, tablas, ficheros, etc. 3.2.5. Ocultacin El concepto de ocultacin en el desarrollo de software tiene como objetivo ocultar al usuario de un mdulo todo lo que pueda ser susceptible de cambio en un futuro y que adems es irrelevante para el usuario; por el contrario, se muestra en la interfaz todo aquello que no variar con cualquier cambio. Ello tiene como ventaja: a) Depuracin, pues resulta ms fcil identificar el mdulo que no funciona correctamente, y b) Mantenimiento, pues una modificacin afectar a un mdulo y no a todo el sistema. 3.2.6. Genericidad La genericidad es un concepto mediante el cual se trata de agrupar aquellos elementos del sistema que utilizan estructuras semejantes o tendrn un tratamiento similar. Prescindiendo de detalles particulares, se puede disear un elemento genrico que posteriormente ser tratado para cada caso particular. 3.2.7. Herencia El concepto de herencia est muy ligado a las metodologas de diseo de software orientado a objetos. Se trata de que ciertos elementos, denominados hijos, puedan heredar de otros, denominados padres, que poseen una estructura y operaciones bsicas, sus estructuras y operaciones para, ampliarlos, mejorarlos o simplemente, adaptarlos. A su vez los hijos pueden tener otros hijos. Tiene como ventaja la reutilizacin de software. 3.2.8. Polimorfismo Mediante polimorfismo se entiende la posibilidad de que un producto software adquiera varias formas simultneamente. Algunas de ellas son: a) Concepto de genericidad, cuando se particulariza en cada caso; b) Concepto de herencia, cuando los hijos adoptan formas diferentes de los padres; c) Concepto de sobrecarga, en el que quienes adquieren diferentes formas son los operadores, funciones o procedimientos, p. Ejp. el operador +, pues no es lo mismo sumar un entero que un real. 3.2.9. Concurrencia En sistemas con restricciones de tiempo en el que debe existir una respuesta rpida debe tenerse en cuenta lo siguiente: 1. Tareas concurrentes Determinar qu tareas se deben ejecutar en paralelo para cumplir con las restricciones impuestas. Se debe prestar atencin a las tareas ms comunes y a las tareas con tiempos de respuesta ms crticos. 2. Sincronizacin de tareas Determinar los puntos de sincronizacin entre las distintas tareas. Se pueden utilizar semforos. 3. Comunicacin entre Determinar si la cooperacin se basa en emplear datos compartidos o mediante el paso de tareas mensajes entre las tareas. Se deben definir las tareas productoras y las consumidoras, as como si se pueden modificar datos durante una consulta y la forma de controlarlo (semforos, monitores, regin crtica, etc.) 4. Interbloqueos Estudiar los posibles interbloqueos entre las tareas. 3.3. Notaciones para el diseo Notaciones Al igual que para realizar la especificacin, existen multitud de notaciones. Ha de conocerse qu significa cada cosa en cada notacin, pues puede ocurrir que un mismo smbolo signifique cosas diferentes dependiendo de la notacin utilizada. Objetivos Los objetivos de la notacin es que resulte precisa, clara y sencilla de interpretar. Clasificacin Las notaciones se clasifican en: a) estructurales, b) estticas o de organizacin, c) dinmicas o de comportamiento, y, d) hbridas. 3.3.1. Notaciones estructurales Diagrama de bloques. Sirven para cubrir un primer nivel del diseo arquitectnico y con ellas se trata de desglosar y estructurar el sistema en sus partes fundamentales. Consiste en cajas unidas por lneas. En algunos diagramas las cajas situadas en la parte superior son las cajas de mayor nivel. Cajas adosadas Se denomina as al diagrama en el que las cajas estn pegadas unas a otras. Entre capas adyacentes est definida una interfaz estndar que posibilita su comunicacin. 3.3.1.1. Diagramas de estructura Sirven para representar la organizacin esttica de los mdulos. Fueron propuestos por Yourdon y sus smbolos sirven para describir la estructura de los sistemas software como jerarqua de subprogramas. Emplea los siguientes smbolos:
Rectngulos Lneas
Representan un mdulo o subprograma cuyo nombre se incluye en el interior. Une dos rectngulos e indica que el superior utiliza o llama al mdulo inferior.
12
Rombos Arcos Crculo con flecha 3.3.1.2. Diagramas HIPO Diagramas HIPO
Situados sobre una lnea, indica que esa llamada es opcional. Se sitan sobre una lnea e indican que esa llamada se efecta repetidamente. Se sitan en paralelo a una lnea y representa el envo de unos datos en el sentido de la flecha. Si el crculo es relleno, indica que se enva una informacin de control.
Los diagramas HIPO (Hierarchy-Input-Process-Output) son una notacin propuesta por IBM destinadas a aplicaciones de gestin. Patrn Todos los mdulos pueden adaptarse al patrn de que los datos entran, se procesan y salen. Diagrama de contenido En los diagramas HIPO, existe un diagrama HIPO de contenidos, que establece la jerarqua Diagrama de detalle entre los mdulos del sistema, en el que cada rectngulo que representa un mdulo tiene un nombre y una referencia a otro diagrama de detalle en el que se muestra el patrn I-P-O. En dicho diagrama de detalle se debe indicar el diagrama del que procede y el diagrama o diagramas en los que se desarrolla an ms. 3.3.1.3. Diagramas de Jackson Metodologa de Jackson Esta metodologa, a la que pertenecen estos diagramas, consiste en disear sistemas software a partir de las estructuras de los datos de entrada y salida. Proceso de diseo Es muy sistemtico y se realiza en tres pasos: 1. Especificacin de las estructuras de los datos de entrada y salida. 2. Obtencin de una estructura del programa capaz de transformar las estructuras de datos de entrada en las de salida (tupla, unin, formacin). 3. Expansin de la estructura del programa para lograr el diseo detallado del sistema. Se suele utilizar pseudocdigo. Notacin En la notacin de los diagramas de Jackson los mdulos superiores se detallan segn indican los elementos inmediatamente inferiores. Los elementos siempre van de izquierda a derecha. Si un elemento tiene el smbolo * quiere decir que se repetir 0 o ms veces. Si un elemento contiene el smbolo O quiere decir que forma parte de una seleccin con otro elemento. 3.3.2. Notaciones estticas Las notaciones estticas sirven para describir caractersticas estticas del sistema como son la organizacin de la informacin sin tener en cuenta su evolucin dinmica. En la fase de diseo la organizacin de la informacin debe tener en cuenta aspectos internos como son la utilizacin de datos auxiliares, datos redundantes, etc. As que, en esta fase, se tendr un detalle de la organizacin de la informacin mucho mayor. Se pueden utilizar las mismas notaciones que en la especificacin: Notaciones 3.3.2.1. Diccionario de datos. Sirve para detallar la estructura interna de los datos. Se parte del diccionario de datos del SRD y se ampliar mediante refinamientos. 3.3.2.2. Diagrama Entidad-Relacin. Sirve para definir el modelo de datos, las relaciones entre ellos y la organizacin de la informacin. Se partir del SRD. 3.3.3. Notaciones dinmicas Permiten describir el comportamiento del sistema durante su funcionamiento. Para disear la dinmica del sistema se disear su comportamiento externo y se aadir la descripcin de un comportamiento interno de forma que se cumpla lo especificado en el SRD. Se utilizan las siguientes notaciones: Notaciones 3.3.3.1. Diagramas de flujo de datos. Sern mucho ms exhaustivos que en el SRD. 3.3.3.2. Diagramas de transicin de estados. No se debe ampliar o cambiar los diagramas de transicin de estados del SRD. 3.3.3.3. Lenguaje de Descripcin de Programas (PDL). En la etapa de diseo, la notacin PDL se ampla con estructuras de algn lenguaje de alto nivel como Ada-PDL que ha sido includo como estndar en las normas IEEE. 3.3.4. Notaciones hbridas Estas notaciones sirven para cubrir simultneamente aspectos estructurales estticos y dinmicos (p.ejp. la metodologa Jackson). En concreto, permiten un enfoque globalizado del diseo en el que se aglutinan los aspectos estticos (datos), dinmicos (operaciones) y de estructura del sistema. 3.3.4.1. Diagrama de abstracciones Abstraccin Se compone de: Nombre. Contenido. Es el elemento esttico de la abstraccin y en l se define la organizacin de los datos que constituye la abstraccin (def. de constantes, tipos de datos, variables, etc. en el mdulo de definicin). Operaciones. Es el elemento dinmico de la abstraccin y en l se agrupan todas las operaciones definidas para manejar el contenido de la misma. En Modula-2 seran las definiciones de funciones y/o procedimientos declaradas en el mdulo de definicin. Abstraccin funcional Las abstracciones funcionales las constituyen los subprogramas. Tipo abstracto de datos Es una abstraccin constituida por una estructura de datos y por las operaciones que se
13
Dato encapsulado
pueden hacer con dicha estructura. Tiene una parte de contenido y operaciones. Permiten crear nuevos tipos de datos. Es una forma de abstraccin, que al igual que los tipos abstractos de datos, tiene contenido y operaciones, pero que a diferencia de stos, su definicin est encapsulada en la abstraccin, es decir, se puede operar con ellos, pero no se pueden definir nuevas variables de ese tipo.
Notacin grfica
3.3.4.2. Diagramas de objetos Las equivalencias entre abstracciones (propuestos por progamadores) y objetos (propuestos por la inteligencia artificial) son enormes. Ello hace que se puedan equiparar los trminos de unos y otros. Equivalencias Abstracciones Objetos Tipo abstracto de datos Clase de objeto Abstraccin funcional No hay equivalencia Dato encapsulado No hay equivalencia Dato abstracto (variable o constante) Objeto (ejemplar de la Clase) Contenido Atributos Operaciones Mtodos Llamada a una operacin Mensaje al objeto Relaciones entre objetos Entre los objetos se pueden considerar las siguientes relaciones: 1. Clasificacin, especializacin o herencia (no contemplada en las abstracciones). Esta propiedad de los objetos permite adaptar a los hijos las operaciones heredadas a sus necesidades. No es necesario indicar la cardinalidad entre las clases de objetos. 2. Composicin (tambin vlida entre abstracciones). Permite describir un objeto mediante los elementos que lo forman. Es necesario indicar la cardinalidad en un sentido. Notacin OMT Acrnimo de Object Modelling Technique utiliza el tringulo para indicar que los objetos inferiores heredan los atributos y operaciones del objeto superior, y el rombo para indicar que el objeto superior est formado por los objetos inferiores. 3.4. Documentos de diseo El resultado de la labor de diseo se plasma en un documento denominado Software Design Document (SDD). Veremos a continuacin los utilizados por la ESA, llamados ADD y DDD. 3.4.1. Documento ADD (Arquitectural Design Document) 1. Introduccin Se compone de objetivo, mbito, definiciones, siglas y abreviaturas, referencias. Sern similares al SRD. 2. Panormica del sistema Dar una visin general de los requisitos funcionales del sistema, basndose en el SRD. 3. Contexto del sistema Se debe indicar si existen conexiones con otros sistemas y si debe funcionar de forma integrada con ellos. Se definir la interfase. 4. Diseo del sistema Describe el nivel superior de diseo: 4.1. Metodologa de diseo de alto nivel. 4.2. Descomposicin del sistema. Se describe el primer nivel de descomposicin del sistema en sus primeros componentes. Se nombran las relaciones entre ellos. 5. Diseo de los Cada seccin se repetir para cada componente de 4.2. componentes 5.n. Identificador de componente. 5.n.1. Tipo. Es la clase de componente (mdulo, proceso, datos, etc.). 5.n.2. Objetivo. Se describe la necesidad de este componente. 5.n.3. Funcin. Se describe qu hace el componente. 5.n.4. Subordinados. Componentes usados por ste. 5.n.5. Dependencias. Se enumeran los componentes que usan a ste. Se incluye su naturaleza. 5.n.6. Interfases. Indica cmo interactan con ste otros componentes. 5.n.7. Recursos. Se indican los elementos usados por este componente externos al diseo: impresoras, disco, memoria, etc. 5.n.8. Referencias. 5.n.9. Proceso. Se describen los algoritmos que utiliza el componente para realizar su funcin como un refinamiento de 5.n.3. 5.1.10. Datos. Se describen los datos internos del componente incluyendo el mtodo de representacin, valores iniciales, formato, valores vlidos, etc.
14
6. Viabilidad y recursos estimados Se analiza la viabilidad y se concretan los recursos necesarios. 7. Matriz requisitos / Se muestra una matriz poniendo en las filas los requisitos y en las columnas los componentes componentes, marcando segn corresponda. 3.4.2. Documento DDD (Detailed Design Document) El DDD ir creciendo segn se avance en el desarrollo del proyecto. Es muy aprecido al ADD pero se diferencia de aquel en que el nivel de detalle es mucho mayor. En algunos componentes se llega incluso al nivel de codificacin. De hecho los listados fuente se recogen como un apndice. Seccin de normas Se incluye una seccin de normas, convenios y procedimientos en la que se incluyen normas de diseo de bajo nivel, normas y convenios de documentacin, convenios de nombres, normas de programacin y herramientas de desarrollo de software. Estas normas son muy importantes en proyectos de envergadura y debe ser la primera actividad del diseo detallado antes de iniciar el diseo propiamente dicho. 4. TCNICAS GENERALES DE DISEO DE SOFTWARE El diseo de software es una actividad en la que prima la experiencia; sin embargo es necesario conocer muchas de las tcnicas de diseo que tienen objetivos comunes. Objetivos Los objetivos inmediatos de las tcnicas de diseo son: 1. Descomposicin modular del sistema. Se trata de dividir el sistema en mdulos. 2. La decisin sobre los aspectos de implementacin de los datos. Se trata de decidir las estructuras de los datos y los algoritmos. 4.1. Descomposicin modular La descomposicin modular es una parte esencial del diseo y para hacer su descomposicin de forma correcta se debe: a) identificar los mdulos; b) describir cada mdulo, y; c) describir las relaciones entre los mdulos. Mdulo Se puede definir como el fragmento de un sistema software que se puede elaborar con relativa independencia de los dems. Tipos de mdulos Con la anterior definicin de mdulo se pueden definir diferentes clases: a) Cdigo fuente, tal como son los mdulos de Modula-2. b) Tabla de datos, de forma que dependiendo de cada proceso se pueda utilizar un mdulo patrn de datos, etc. c) Configuracin, p.ejp. cuando se elige un idioma u otro se utiliza un mdulo u otro. d) Otros. Puede utilizarse para agrupar ciertos elementos relacionados entre s que pueden ser tratados de forma separada del resto. Formato de mdulos Depende de cada metodologa o herramienta utilizada. No es lo mismo un mdulo en Modula-2 que en Fortran. Cualidades Basados en la experiencia, una descomposicin modular debe poseer ciertas cualidades mnimas para considerarla vlida. Se trata de la independencia funcional (acoplamiento y cohesin), la comprensibilidad, y la adaptabilidad. 4.1.1. Independencia funcional La matriz de requisitos/componentes del ADD o DDD indica qu componente (mdulo) se encarga de realizar cada uno de los requisitos (funciones) indicados en el SRD. En primer lugar se podra indicar que cada mdulo se puede encargar de una funcin diferente, pero en sucesivos pasos de refinamiento del diseo algunas de esas funciones se agruparn en un solo mdulo o algunos mdulos se dividirn en otros. Independencia funcional Se consigue la independencia funcional cuando un mdulo realiza una funcin concreta o un conjunto de funciones afines, sin apenas relacin con el resto de mdulos del sistema. Ventajas Las ventajas de la independencia funcional es una mayor facilidad de mantenimiento o cambio de mdulos y aumenta las posibilidades de reutilizacin. Criterios Para medir la independencia funcional se utilizan dos criterios: acoplamiento y cohesin. 4.1.1.1. Acoplamiento El grado de acoplamiento entre mdulos es una medida de la interrelacin que existe entre ellos: tipo de conexin y complejidad de la interfase. Se utiliza la siguiente escala en las que figura el grado de acoplamiento: Escala. Grados de Fuerte Acoplamiento por Contenido acoplamiento Acoplamiento Comn Moderado Acoplamiento Externo Acoplamiento de Control Dbil Acoplamiento por Etiqueta Acoplamiento de Datos Sin Acoplamiento Directo Siempre se tratar de buscar un acoplamiento dbil o a lo sumo, moderado. Acoplamiento por Se produce cuando desde un mdulo se pueden cambiar los datos locales e incluso el Contenido cdigo de otro mdulo. Se logra slo con lenguaje ensamblador. Un sistema con este tipo de acoplamiento resulta imposible de mantener e incluso de entender. Acoplamiento Comn Se produce cuando se emplea una zona comn de datos a la que tienen acceso varios
15
Acoplamiento Externo Acoplamiento de Control Acoplamiento por Etiqueta
Acoplamiento de Datos 4.1.1.2. Cohesin El criterio de cohesin es complementario al de acoplamiento. Es necesario lograr que el contenido de cada mdulo tenga coherencia. Tampoco se debe permitir que el n de mdulos crezca desmesuradamente. Se utiliza la siguiente escala: Escala. Grados de Alta Cohesin abstraccional Cohesin Cohesin funcional Media Cohesin secuencial Cohesin de comunicacin Baja Cohesin temporal Cohesin lgica Cohesin coincidental Siempre se tratar de buscar una cohesin alta. Cohesin coincidental Es la peor de todas e indica que cualquier relacin entre los elementos del mdulo es casual. Cohesin lgica Se produce cuando en un mismo mdulo se agrupan elementos que realizan funciones similares desde el punto de vista del usuario. Cohesin temporal Se produce cuando se agrupan en un mismo mdulo elementos que se ejecutarn en un mismo momento (ejp. arrancar o parar dispositivos, etc.) Cohesin de comunicacin Se produce cuando todos los elementos del mdulo operan con el mismo conjunto de datos de entrada o producen el mismo conjunto de datos de salida. Cohesin secuencial Se produce cuando todos los elementos del mdulo trabajan de forma secuencial. Es decir, el resultado de uno es la entrada del siguiente. Cohesin funcional Cada elemento est encargado de una funcin concreta. Cohesin abstraccional Se logra al cohesin abstraccional cuando se disea un mdulo como un tipo abstracto de datos o como una clase de objetos. En los dos casos se asocian un contenido (atributos) con las operaciones (mtodos) que se utilizarn en su manejo. Criterios orientativos Para conocer el grado de cohesin de un mdulo se pueden utilizar los siguientes criterios: Cohesin media Lo ser si la descripcin es una frase compuesta que contiene comas o ms de un verbo. Cohesin secuencial Lo ser si la descripcin contiene palabras relacionadas con el tiempo como: primero, cuando, etc. Cohesin lgica Lo ser si la descripcin no se refiere a algo especfico sino a algo ms general. Cohesin temporal. Si contiene palabras como inicializar o preparar ser probablemente de tipo temporal. 4.1.2. Comprensibilidad Un mdulo debe ser comprensible de forma aislada. Para ello, el factor ms importante es el de independencia funcional (acoplamiento dbil y cohesin alta). Pero hay otros factores: 1. Identificacin Una adecuada utilizacin de los nombres de los mdulos y sus elementos ayuda mucho en su comprensin. 2. Documentacin La documentacin de cada mdulo debe servir para facilitar la comprensin detallando los aspectos de diseo o implementacin. Se deben evitar las explicaciones prolijas. 3. Simplicidad Las soluciones sencillas son siempre las mejores. 4.1.3. Adaptabilidad Un sistema es un traje a medida que si bien trata de disearse de forma que se pueda reutilizar alguna de sus partes, es inevitable que dicho sistema tenga que adaptarse a las imposiciones del cliente. Otros factores que facilitan la adaptabilidad son: 1. Previsin Consiste en hacer un esfuerzo que permita prever las partes que probablemente se vern modificadas en el futuro. P. Ejp. listados, presentaciones en pantalla, podran agruparse en mdulos con un acoplamiento lo ms dbil posible. 2. Accesibilidad Antes de hacer un cambio es necesario conocer en profundidad la estructura global del sistema. Se pueden utilizar CASE, de forma que se puedan crear prototipos. 3. Consistencia Cuando se realiza una adaptacin es necesario cambiar todos los documentos de especificacin, diseo e implementacin. 4.2. Tcnicas de diseo funcional descendente
mdulos del sistema. El acceso es total, por lo que cualquier cambio debe ser tenido en cuenta por el resto de los mdulos. La depuracin es muy difcil y se debe evitar. Es un tipo de acoplamiento comn en el que la zona comn est constituida por algn dispositivo externo (disco, canal de comunicaciones, etc.). En este tipo de acoplamiento se le pasa al mdulo un dato de control que determinar la lnea de ejecucin que seguir. Se produce cuando se realiza un intercambio de los datos por referencia, permitiendo un acceso a la estructura de los datos. Se produce cuando se realiza exclusivamente un intercambio de los datos necesarios.
16
En estas tcnicas se incluyen todas aquellas en las que se atiende fundamentalmente a la funcin o funciones que ha de realizar el sistema. 4.2.1. Desarrollo por refinamiento progresivo (Wirth) Esta tcnica corresponde a la fase de diseo de la metodologa de programacin estructurada (Dijstra). Dicha metodologa recomienda utilizar nicamente las estructuras de control: secuencia, seleccin e iteracin. La tcnica de refinamientos consiste en plantear el problema inicial como una operacin global e irla descomponiendo poco a poco en funcin de otras operaciones ms sencillas. Esas operaciones constituirn en los pasos finales los mdulos parciales que constituirn el sistema. 4.2.2. Programacin estructurada de Jackson Esta tcnica, que sigue las ideas de la programacin estructurada en cuanto a las estructuras (secuencia, seleccin e iteracin) y el mtodo de refinamientos sucesivos, se diferencia de la programacin estructurada en que aqu se ir construyendo la estructura del programa de forma similar a cmo se construyen las estructuras de los datos de entrada y salida. Pasos La tcnica se basa en los siguientes pasos: 1. Analizar el entorno del problema y describir las estructuras de datos a procesar. 2. Construir la estructura del programa basada en las estructuras de los datos. 3. Definir las tareas a realizar en trminos de las operaciones elementales, y situarlas en los mdulos apropiados. 4.2.3. Diseo estructurado (Yourdon) Esta tcnica consiste en pasar de los DFD a los diagramas de estructura. La dificultad estriba en realizar una jerarqua o estructura de control entre los diferentes mdulos, y eso no est descrito en los DFD. Para ello hay que hacer lo que se denomina anlisis de flujo de transformacin y anlisis de flujo de transaccin. Ambos anlisis se realizan mejor si se modifica la estructura jerrquica de los DFD, construyendo un nico diagrama con todos los procesos contenidos en los primeros niveles de descomposicin y se prescinde de los almacenes de informacin. Anlisis de flujo de Consiste en identificar un flujo global de informacin desde los elementos de entrada al transformacin sistema hasta los de salida. Se asignan mdulos para las operaciones del diagrama y se aaden modulos de coordinacin que realizan el control conforme a la distribucin del flujo de transformacin. Anlisis del flujo de Es aplicable cuando el flujo de datos se puede descomponer en varias lneas separadas, transaccin correspondiendo cada una de ellas a una funcin o transaccin distinta, activndose segn el dato entrado. Hay que identificar el centro de transaccin desde el que se ramifican las lneas de flujo. 4.3. Tcnicas de diseo basado en abstracciones Estas tcnicas surgen cuando se precisan los conceptos de abstraccin de datos y de ocultacin y la idea consiste en hacer que los mdulos se correspondan o bien con funciones o bien con tipos abstractos de datos. 4.3.1. Descomposicin modular basada en abstracciones Como tcnica de programacin, esta tcnica consiste en ampliar el lenguaje existente con nuevas operaciones y tipos de datos, definidos por el usuario. Como tcnica de diseo consiste en dedicar mdulos separados a la realizacin de cada tipo abstracto de datos y cada funcin importante. Notacin Para la representacin de la estructura, se utiliza la notacin de diagramas de bloques. Forma descendente En forma descendente, esta tcnica se puede considerar como una ampliacin de la tcnica de refinamiento progresivo, en que al realizar un refinamiento se plantea como alternativa, adems de su descomposicin, el que la operacin a refinar se defina separadamente como abstraccin funcional, o bien como operacin sobre un tipo abstracto de datos. Forma ascendente En esta forma se trata de ir ampliando las primitivas existentes en el lenguaje de programacin y las libreras asociadas con nuevas operaciones y tipos de mayor nivel, ms adecuados para el campo de la aplicacin que se est diseando. 4.3.2. Mtodo de Abbott Con el mtodo anterior no se conocen a priori los mejores candidatos para ser considerados como abstracciones. La idea de este mtodo, que se basa en la aplicacin del lenguaje natural pero que da mejores resultados con un lenguaje ms formal, consiste en identificar en el texto la descripcin de las palabras que puedan corresponder a elementos significativos del diseo, como son, tipos de datos (mediante sustantivos genricos), atributos (mediante sustantivos) y operaciones (mediante verbos o nombre de acciones). Procedimiento Se comienza subrayando los elementos descritos anteriormente y que sean significativos. Se establecen, as, dos listas, una con nombres (datos) y otra con verbos (operaciones). Posteriormente se reorganizan dichas listas extrayendo los posibles tipos de datos, y asocindoles sus atributos y operaciones. En este paso se eliminarn redundancias o trminos irrelevantes y se aadirn trminos no incluidos inicialmente. 4.4. Tcnicas de diseo orientadas a objetos
17
Las tcnicas de diseo orientado a objetos son prcticamente iguales que las basadas en abstracciones. Su casi nica diferencia es que en las basadas en objetos existen las caractersticas de herencia y polimorfismo. Las diversas metodologas tienen como casi nica diferencia la notacin utilizada en los diagramas. La idea de estas tcnicas consiste en que en la descomposicin modular del sistema, cada mdulo contenga la descripcin de una clase de objetos o de varias clases relacionadas entre s. La metodologa se apoya en diagramas ampliados del modelo de datos. 4.4.1. Diseo orientado a objetos Veremos a continuacin una tcnica para derivar el diseo partiendo de la especificacin del sistema. Se compone de los siguientes pasos: 1. Estudiar y comprender el Aunque se haya realizado en la fase de anlisis, puede ocurrir que haya que modificar el problema SRD por imprecisiones o simplemente porque el equipo que desarroll el SRD es diferente al que hace su diseo. 2. Desarrollar una posible Se tendr que completar el trabajo hecho en el SRD. Habr que considerar varias solucin alternativas y elegir la ms apropiada. Puede ser una descripcin informal. 3a. Identificar las clases y Se trata de identificar las clases de objetos y sus atributos. Tambin se definirn las objetos relaciones entre objetos que estn formados por otros objetos. Al final se obtendr un diagrama inicial del modelo de objetos. Se puede usar la tcnica de Abbott. 3b. Identificar las operacio- En este paso hay que identificar las operaciones y lo ms complicado: decidir a qu objeto nes sobre los objetos se asocia cada operacin. Tambin se puede usar la tcnica de Abbott. 3c.Aplicar Herencia Una vez realizado el punto anterior hay que detectar analogas entre los objetos, y establecer las relaciones de herencia apropiadas, reformulando las descripciones de los objetos si fuera necesario. Estas relaciones de herencia se incluirn en el diagrama de objetos que se ir desarrollando. 3d. Describir las As se verifica que el diseo es consistente. Cada operacin se har en pseudocdigo, operaciones refirindose siempre a operaciones o clases de datos definidos en el diseo o predefinidos por el lenguaje de programacin. Podra detectarse aqu la necesidad de aadir nuevas clases de objetos o nuevas operaciones. 3e. Establecer la estructura Se asignarn las clases, objetos y operaciones a mdulos separados. Se intentar que cada modular mdulo corresponda a una clase o, si es muy complicado, ciertas operaciones podran establecerse en mdulos separados. Tambin se pueden agrupar varias clases u objetos relacionados entre s en un solo mdulo. Al final se obtendr el diagrama de estructura del sistema. 4.5. Tcnicas de diseo de datos La informacin que tendr que almacenarse se har probablemente en una base de datos y sta se puede organizar desde la perspectiva clsica de enfocarla en tres niveles correspondiendo a cada uno de ellos un esquema de organizacin de los datos desde un punto de vista concreto: 1. Nivel externo Corresponde a la visin del usuario. La organizacin de los datos se realiza teniendo en cuenta el campo de la aplicacin (su terminologa, etc.). El esquema de usuario ser la ficha del cliente, etc. 2. Nivel conceptual Establece una organizacin lgica independientemente del sentido en el campo de aplicacin. Se resume en un diagrama de modelo de datos o en un diagrama E-R o como diagrama de modelo de objetos. 3. Nivel fsico Organiza los datos segn el sistema de gestin de base de datos elegido. El esquema fsico ser la tabla. Saltos entre pasos El salto del nivel externo al conceptual se realiza en la etapa de anlisis. El salto del nivel conceptual al nivel fsico, en la etapa de diseo. 4.6. Diseo de bases de datos relacionales Partiendo del modelo Entidad-Relacin o bien del modelo de Objetos, es posible obtener el esquema de las tablas de una base de datos relacional. Las reglas que hacen esto posible traducen a esquemas de tablas los atributos de las entidades, y las relaciones entre ellas, incluyendo las de composicin y herencia entre los objetos. Aspectos de eficacia En el modelo relacional la eficacia se contempla de dos formas: 1) forma normal, que evita la existencia de redundancia en los datos, y; 2) mediante el empleo de ndices para aumentar la velocidad de acceso a los datos. 4.6.1. Formas normales Las formas normales de Codd definen criterios para establecer esquemas de tablas que sean claros y no redundantes, se numeran de menor a mayor nivel de restriccin como formas normales 1, 2, 3... 1 forma normal Una tabla est en la 1 forma normal cuando la informacin asociada a cada columna es un valor nico, y no una coleccin de valores en nmero variable. 2 forma normal Ocurre cuando la tabla est en la 1 forma normal y adems, hay una clave primaria (una columna o combinacin de ellas) que distingue cada fila, y cada casilla que no sea de la clave primaria depende de toda la clave primaria. Es decir, no se cumple cuando existe alguna columna en la tabla que no forma parte de la clave y que no depende de toda la clave sino de otra columna en la tabla (forme parte o no de la clave). Esa columna ha de ser
18
3 forma normal
incluida en otra tabla auxiliar cuya clave ser la columna de la que depende. Ocurre cuando la tabla est en la 2 forma normal y adems el valor de cada columna que no es clave primaria depende directamente de la clave primaria, es decir, no hay dependencias entre columnas que no son clave primaria.
4.6.2. 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. Las relaciones entre entidades se hacen incluyendo una columna que contenga un cdigo (clave primaria) que identifique cada elemento de datos (fila de la tabla). 4.6.3. Tratamiento de las relaciones de asociacin En el modelo E-R las relaciones se consideran relaciones de asociacin. Lo que veremos ahora son relaciones binarias entre parejas de entidades. La tcnica consiste en traducir la relacin a una tabla conteniendo referencias a las tablas de las entidades relacionadas, as como los atributos de la relacin, si los hay. Esto vale para cualquier cardinalidad. Relacin N-N La referencia a las entidades relacionadas se har mediante la clave primaria de cada una. Relacin 1-N Aqu es posible incluir los datos de la relacin en la misma tabla de una de las entidades relacionadas. Relacin 1-1 En este caso se pueden fundir las tablas de las dos entidades en una sola. 4.6.4. Tratamiento de las relaciones de composicin Las relaciones de composicin funcionan de la misma forma que las de asociacin, aunque aqu la cardinalidad del lado del objeto compuesto es casi siempre 1. 4.6.5. Tratamiento de la herencia Cuando una clase de objetos (entidad genrica) tiene varias subclases (entidades especficas), la informacin de las entidades se puede almacenar de tres formas: 1. Se usa una tabla de superclase con los atributos comunes, heredados por las subclases, ms una tabla por cada subclase, con sus atributos especficos. 2. Se repiten los atributos comunes en las tablas de cada subclase, despareciendo la tabla de la superclase. 3. Se prescinde de las tablas separadas para cada subclase, y se ampla la tabla de la superclase con todos los atributos de la cada subclase. 4.6.6. Diseo de ndices Los ndices permiten acceder rpidamente a los datos reduciendo el tiempo de acceso pero el espacio de almacenamiento aumenta, de la misma forma que aumenta el tiempo necesario para almacenar un nuevo dato o, an ms, cambiar uno existente. Hay que mantener ndices sobre las claves primarias y columnas de referencia de las entidades relacionadas. 4.7. Diseo de bases de datos de objetos En las bases de datos orientadas a objetos hay una mayor variedad de estructuras disponibles, pero distintas en cada caso. Existen dos enfoques: el primero es apropiado cuando la base de datos de objetos permite utilizar una gran variedad de estructura, en cuyo caso el diseo se puede hacer de la misma forma que para las estructuras de datos en memoria; el segundo enfoque se aplica cuando no existe gran variedad de estructuras de datos, resultando la base de datos de objetos anlogo a una base de datos relacional en la que se establece una tabla por cada clase de objetos. Aqu es innecesaria la existencia de columnas explcitas de cdigos o referencias pues el sistema de gestin de base de datos lo aporta de forma implcita. 5. CODIFICACIN Y PRUEBAS En este tema se repasan las ltimas fases del cliclo de vida: codificacin, prueba de unidades, fase de integracin y pruebas del sistema. 5.1. Codificacin del diseo La fase de codificacin es el ncleo central de cualquiera de los modelos de desarrollo de software (ciclo de vida, prototipos, espiral,...). En pequeos desarrollos es casi la nica actividad que se realiza. La importancia es evidente, pues de esta fase salen los programas fuentes. Un elemento esencial en esta fase es la eleccin del lenguaje de programacin, pues eso impone una determinada forma de trabajo. Es necesario dejar por escrito la metodologa de programacin que utilizar el equipo (suele ser la misma en c/empresa). Para garantizar una adecuada homogeneidad, se deben establecer normas y estilos de codificacin, lo que redundar en un mejor entendimiento, mantenimiento y reutilizacin. La codificacin se debe estructurar para facilitar la depuracin y las modificaciones derivadas de las pruebas. 5.2. Lenguajes de programacin Los lenguajes de programacin son el medio fundamental para realizar la codificacin. No existe un nico lenguaje ideal para todo y a veces hay que utilizar varios en un proyecto. 5.3. Desarrollo histrico De los cientos de lenguajes existentes, slo un nmero relativamente pequeo se utiliza de forma industrial. Es difcil clasificarlos en un grupo concreto. Los lenguajes de las nuevas generaciones coexisten con los de la anterior generacin hasta que aquellos se imponen por tener mejores prestaciones. 5.3.1. Primera generacin (-1959) Cdigo Mquina La programacin se haca introduciendo unos y ceros directamente en la memoria. Ensamblador Surge como solucin a la tediosa tarea de programar en cdigo mquina. El lenguaje
19
ensamblador asocia a cada instruccin del procesador un nemotcnico. Cada procesador tiene su juego de instrucciones, por lo que es un lenguaje que va asociado a la arquitectura. Hoy en da solo se utiliza cuando hay que hacer alguna operacin crtica en tiempo real. 5.3.2. Segunda generacin (1960-1970) Se caracterizan por dar respuesta a un aumento de la capacidad de la memoria y los discos. Debido a ese aumento de capacidad, los programas en ensamblador eran ms grandes y difciles de depurar, entender y mantener. Aparecen as, los primeros lenguajes de alto nivel que no dependan de una arquitectura concreta. Aparecen los primeros elementos abstractos, tipos de datos no soportados directamente por las instrucciones de la mquina, se puede trabajar con variables, (olvidando as la gestin directa de memoria) se dispone de las primeras estructura de control. Algunos de ellos son: FORTRAN FORmula TRANslator. Destinado a programar aplicaciones cientfico-tcnicas. Su principal desventaja es que an maneja directamente la memoria c/la sentencia COMMON. COBOL Destinado a sistemas de procesamiento de informacin. An se utiliza aunque cada vez menos. ALGOL Fue el precursor de lenguajes de 3 generacin como PASCAL, MODULA-2 o ADA. Es el primero que da una gran importancia a los tipos de datos. BASIC Diseado originalmente para la enseanza de la programacin, tuvo gran xito. Hoy en da existen innumerables versiones que incorporan infinidad de herramientas. 5.3.3. Tercera generacin (1970-198-) A principio de los 70 se consolida las bases de la programacin estructurada en la que la programacin se concibe como una actividad metdica sin concesin a la genialidad. Facilitan las estructuras de datos y cdigo con redundancia en declaraciones y el uso de cada tipo de dato. Algunos de ellos son (programacin imperativa): PASCAL (1971) Fue diseado para ensear pero rpidamente tuvo xito porque permite la estructuracin del cdigo mediante procedimientos, que pueden ser recursivos. Los tipos de datos son rgidos y no se contempla de forma apropiada la compilacin separada. MODULA-2 Descendiente directo del Pascal, corrige sus deficiencias. Permite desarrollo a gran escala. Incorpora la estructura de mdulo quedando separada la especificacin y la implementacin lo que facilita la compilacin segura y permite la ocultacin de los detalles de implement. C Aparece en 1975 y se desarrolla en paralelo al Pascal. Se cre para escribir el UNIX. Se utiliza para todo tipo de aplicaciones. Posee caractersticas que lo hacen considerar tambin un lenguaje prximo al ensamblador, lo que si no se utiliza bien puede ser muy peligroso (punteros, matrices). Posee un conjunto de operadores muy potentes que permiten hacer cualquier cosa con los datos. Esto puede hacer difcil la depuracin. ADA Fue patrocinado por el Dpto. de Defensa de los EE.UU. Descendiente del Pascal es mucho ms potente y complejo. No ha tenido mucha aceptacin. Permite el diseo modular y la aplicacin de los conceptos de abstraccin y ocultacin. Tambin permite la definicin de elementos genricos, y tiene mecanismos para la programacin concurrente de tareas y la sincronizacin entre ellas. SMALLTALK Es el precursor de los lenguajes orientados a objetos. C++ Incorpora al lenguaje C los mecanismos de programacin orientada a objetos: ocultacin, clases, herencia y polimorfismo. EIFFEL Es el intento ms serio de hacer un lenguaje de programacin orientado a objetos. Permite la definicin de clases genricas, herencia mltiple y polimorfismo. LISP Es un lenguaje funcional. Se utiliza en inteligencia artificial y sistemas expertos. Los datos se forman en listas a las que se les aplica funciones que pueden ser recursivas. Se utiliza tambin para demostrar teoremas, manipular smbolos, etc. PROLOG Es un lenguaje lgico y se usa en sistemas expertos. Se basa en hechos y reglas. 5.3.4. Cuarta generacin Los L4G ofrecen al programador un mayor nivel de abstraccin. Suelen ser herramientas especficas que permiten a un usuario sin grandes conocimientos, hacer un pequeo sistema. Las aplicaciones complejas desarrolladas con L4G son ineficientes por el cdigo generado, por lo que se utilizan como prototipo para, posteriormente, mejorar con un lenguaje de tercera generacin. Se agrupan principalmente en: Bases de Datos Permiten acceder y manipular la informacin de la base de datos mediante un conjunto de ordenes de peticin (Query) relativamente sencillas. Se pueden hacer listados, consultas, clculos, se pueden seleccionar datos, etc. Generadores de Programas Permiten construir elementos abstractos fundamentales en un cierto campo de aplicacin sin descender a detalles concretos. El programa generado se puede modificar y el lenguaje destino suele ser COBOL. Clculo Son herramientas que han evolucionado hasta el punto de constituir un L4G. Lo son las hojas de clculo, herramientas de clculo matemtico, de simulacin, etc. Otros Lo constituyen las herramientas para la especificacin y verificacin formal, lenguajes de simulacin, etc. 5.4. Prestaciones de los lenguajes
20
Vamos a dividir las prestaciones de los lenguajes en cuatro apartados para estudiar las estructuras ms importantes: 5.4.1. Estructuras de control Se refiere a las instrucciones que se encuadran en la parte ejecutiva de un programa. Las constituyen las estructuras para el manejo de excepciones, para la programacin concurrente, y para la programacin estructurada. 5.4.1.1. Programacin estructurada Cualquier lenguaje imperativo dispone ya de sentencias que permiten la programacin estructurada. En concreto disponen de sentencias que permiten programar: Secuencia; Seleccin (If.. Then..Else..End); Iteracin (While...Do). Lenguaje ms rico El lenguaje debe ser ms rico y deber admitir sentencias de seleccin como (If-then-elsifthen-else) o (Case-of), o sentencias de iteracin como: Repeticin (Repeat until); Bucle con contador (For to do); Bucle indefinido (Loop Exit). Procedimientos La creacin de subprogramas mediante procedimientos o funciones es otra de las caractersticas de que disponen los lenguajes. Las llamadas podrn ser recursivas. 5.4.1.2. Manejo de excepciones Excepcin Lo constituye un error o suceso inusual que puede ser causado por un fallo humano, de software o de hardware. Pueden ser entradas vacas, valores fuera de rango, etc. Errores humanos Si bien los datos se pueden validar por separado, en su conjunto podran ser errneos, p.ejp. cuando el operador introduce un cero que se utilizar como divisor en una divisin. Fallos hardware Los fallos de los perifricos pueden dar lugar a datos errneos. Errores software Son errores no detectados en la fase de pruebas. Datos de entrada vacos P. ejp. un vector vaco. Valores fuera de rango Se trata de operaciones como una divisin por cero o la raz cuadrada de un n negativo. Los errores anteriores pueden ser detectados por el sistema operativo y abortar la ejecucin del programa pero esto es inaceptable en ciertos sistemas. Manejo de excepciones Es la transferencia de control que contemplan ciertos lenguajes en el que se desva automticamente la ejecucin hacia un fragmento de cdigo apropiado cuando ocurre una situacin anormal. 5.4.1.3. Concurrencia Muchos lenguajes han sistematizado estructuras de control que permiten controlar la concurrencia, en concreto permiten controlar: a) Las tareas que deben ejecutarse concurrentemente; b) Sincronizacin de tareas; c) Comunicacin entre tareas. Sin embargo el control de los interbloqueos es un problema que debe estudiarse en cada caso particular. Existen diversas formas en que los lenguajes controlan las tareas concurrentes: Corrutinas No son tareas sino que tienen una estructura semejante a subprogramas pudindose transferir el control entre ellas sin tener la obligacin de respetar la jerarqua. Modula-2. Fork-join Una tarea puede arrancar la ejecucin concurrente de otras mediante una orden fork que finaliza con un join invocado por la misma tarea que ejecut el fork y con el que ambas tareas se funden de nuevo en una nica. La usan UNIX y PL-1. Cobegin-Coend Todas las tareas a ejecutarse de forma concurrente se declaran en una construccin cobegin T1 | T2 | Tn coend. Al alcanzar la orden cobegin se inicia la ejecucin de todas las tareas T1..Tn. La finalizacin de la concurrencia exige que todas las tareas hayan acabado. Algol. Procesos Cada tarea se declara como un proceso. Todos ellos se ejecutan concurrentemente desde que comienza el programa no siendo posible iniciar la ejecucin de uno nuevo. La usa Pascal y Ada, slo que en Ada se puede lanzar un proceso dinmicamente en cualquier instante. Estructuras de control de En los lenguajes, son las que permiten lograr la sicncronizacin y la cooperacin entre las sincronizaciones tareas. Se clasifican en dos grupos: Variables compartidas Lo constituyen los semforos, regiones crticas condicionales y los monitores. Todas las tareas hen de ejecutarse en el mismo computador (multiprogramacin) o al menos que tengan memoria compartida (multiproceso). Paso de mensajes Lo constituyen el Communicating Sequential Processes (CSP), Llamada a procedimientos remotos y el Rendezvous de Ada. Se pueden usar en computadores que no tienen ninguna memoria comn (procesos distribuidos) y que estn conectados en una red que permite el paso de mensajes. Problemas con semforos Los semforos, como estructuras de bajo nivel que son, han de ser utilizados correctamente. La utilizacin incorrecta de los semforos provoca errores dficiles de detectar y depurar. Algunos de esos errores son: a) usar un recurso sin realizar el P(sincro); b) se puede bloquear un recurso si no se libera con el V(sincro); c) Es fcil equivocarse e invertir las instrucciones (P en vez de V, y viceversa); d) no se distingue un semforo para sincronizar de otro para cooperar. 5.4.2. Estructuras de datos 5.4.2.1. Datos simples Rangos Todos los lenguajes permiten declarar valores de tipo entero o real, pero no todos tienen el mismo rango, existiendo rangos denominados normal, corto, largo, etc.
21
Strings Tipos enumerados Tipos subrango 5.4.2.2. Datos compuestos Datos compuestos Vectores o arrays Datos compuestos (tupla)
Igualmente, en todos los lenguajes existe el tipo ristra de caracteres pero su organizacin y forma de operacin suele ser diferente en cada lenguaje. P.ejp. Type Color=(Rojo, Amarillo, Verde). Cada color se puede sustituir por un n entero que comienza por 0. Tambin es enumerado el tipo lgico booleano. Permiten acotar el rango de un tipo de dato ordinal, p.ejp. Type diasmes= [1..31] Son combinaciones de datos simples y compuestos y se permiten en todos los lenguajes. Hay que conocer la sintaxis y semntica de cada lenguaje. En casi todos los lenguajes se utiliza la estructura registro: Type Circulo = Record CentroX, CentroY: Real; Radio: Integer; End; Lo permiten los derivados del Pascal. Type Mezcla = Set of Color;
Tipo conjunto 5.4.2.3. Constantes Constantes literales Son las que se representan directamente por su valor numrico o de caracteres. Constantes con nombre Son constantes simblicas con nombre. Hay lenguajes, como Modula-2, en los que no se pueden declarar constantes de tipos estructurado: formacin o registro. 5.4.2.4. Comprobacin de tipos Las operaciones que se pueden realizar con los datos en un programa dependen del nivel de comprobacin de tipos que permita el lenguaje utilizado. Existen 5 niveles Nivel 0: Sin tipos En estos lenguajes slo existen tipos predefinidos (Basic, Cobol, Lisp, Apl). En ellos el compilador no realiza ninguna comprobacin de tipos siendo responsabilidad del programador. Nivel 1: Tipado automtico En estos lenguajes (PL1) el compilador decide cual es el tipo ms adecuado para cada dato. Tambin tiene en cuenta las operaciones que intervienen con los datos convirtindolas a su tipo correspondiente. Nivel 2: Tipado dbil En este nivel tambin se realiza un tipado automtico pero entre datos que poseen ciertas similitudes (p.ejp. entero a real). Fortran. Cuando se llama a subprogramas no se comprueban ni el n ni el tipo de los argumentos. Nivel 3: Tipado semirrgido En este nivel (Pascal) todos los datos a usar han de ser declarados con sus tipos. Los tipos declarados por separado e idntica estructura son incompatibles no admitindose operaciones entre ellos. En las llamadas a procedimientos se comprueba el n de argumentos y el tipo de cada uno de ellos. Existe una va de escape ya que no se comprueban los tipos de los argumentos de aquellas funciones o procedimientos que son pasados a su vez como argumentos de otros procedimientos. Nivel 4: Tipado fuerte En este nivel no existe ninguna escapatoria estando obligado el programador a hacer explcita cualquier conversin de tipo que necesite realizar. Se comprueba en compilacin, carga y ejecucin. Pertenecen a este nivel Ada y Modula-2. 5.4.3. Abstracciones y objetos 5.4.3.1. Abstracciones funcionales Todos los lenguajes permiten hacer abstracciones funcionales. Los nombres que reciben, subprogramas, subrutinas, procedimientos o funciones, dependen del lenguaje. Todos se definen por un nombre y una interfaz teniendo que codificar la operacin que en algunos lenguajes se puede ocultar. 5.4.3.2. Tipos abstractos de datos Para codificar un t.a.d. se debe agrupar en una nica entidad el contenido o atributos de los datos de la abstraccin y las operaciones definidas para su manejo. Adems debe existir un mecanismo de ocultacin que impida el acceso al contenido por una va diferente a las operaciones definidas. Modula-2 dispone para ello de la estructura MODULE en la que se puede definir de forma separada el contenido y operaciones de un tipo abstracto (Definition Module). Por otro lado las operaciones permanecern ocultas (Implementation Module). 5.4.3.3. Objetos Modula-2 no dispone de mecanismos de herencia o polimorfismo. El lenguaje Ada permite la herencia pero no el polimorfismo. Tan slo los lenguajes orientados a objetos (Objective C, C++, Eiffel, Object Pascal, Smalltalk) permiten la herencia simple o mltiple y polimorfismo. 5.4.4. Modularidad Compilacin separada Es la primera cualidad que se exige a la hora de desarrollar un proyecto importante en el que trabaja un equipo de personas. Compilacin segura Se produce cuando es posible comprobar en tiempo de compilacin que el uso de un elemento es consistente con su definicin. Fortran y Pascal no utilizan compilacin segura. Sin embargo en Modula-2 la compilacin es completamente segura. Ada tambin tiene compilacin segura mediante sus package y sus package body (definicin e implementacin). 5.5. Criterios de seleccin del lenguaje
22
Es uno de los elementos ms importantes de cualquier desarrollo por el n de personas que lo utilizarn, sin embargo, existen otros criterios de seleccin, aparte de los tcnicos que hay que considerar: Imposicin del cliente P. ejp. el Dpto. de Defensa de EEUU ha impuesto Ada para reducir costes de mantenimiento. Tipo de aplicacin Cada vez existen lenguajes ms especializados en un campo concreto. En general se usa: Ensamblador en aplicaciones de tiempo real muy crticas. Cobol, en aplicaciones de gestin, aunque cada vez menos. Fortran o C, en aplicaciones tcnico/cientficas. C, Modula-2 o Ada, en aplicaciones de sistemas y tiempo real. Lisp y Prolog, en aplicaciones de inteligencia artificial. Disponiblidad y entorno Se refiere a la disponibilidad del compilador para el computador elegido pues no existen compiladores para todos los computadores. Por otro lado, hay que tener en cuenta el entorno del compilador (herramientas, editor, montador de enlaces, depurador, control de versiones, etc.). Experiencia previa Normalmente una empresa no cambia de lenguaje, pues la experiencia adquirida con el lenguaje elegido hace aumentar el rendimiento. Reusabilidad Hay que conocer bien las libreras disponibles por lo que hay que tener herramientas dentro del entorno del lenguaje para organizar dichas libreras. Transportabilidad El lenguaje elegido ha de ser transportable a otros computadores. Uso de varios lenguajes La utilizacin de varios lenguajes en un proyecto debe estar convenientemente justificada. 5.6. Aspectos metodolgicos 5.6.1. Normas y estilo de codificacin Al inicio de la fase de codificacin de un proyecto es necesario fijar unas normas que habitualmente sern las mismas que se use con generalidad en la empresa, y que deben ser adoptadas y respetadas por todos los participantes en el proyecto. Estilo Formato y contenido de las cabeceras de cada mdulo. Deben contener: identificacin del mdulo, descripcin del mdulo, autor y fecha, revisiones y fechas de revisin. Formato y contenido para cada tipo de comentario. Seccin, orden, al margen. Utilizacin de encolumnado. Tabulador, mximo indentado, formato seleccin, iteracin. Eleccin de nombres. Convenio para el uso de maysculas y minsculas, nombres de ficheros, identificadores de elementos del programa. Restricciones Tamao mximo de subrutinas (n pginas). Las subrutinas tendrn como mximo n argumentos. Evitar el anidamiento de sentencias IF. Restricciones de lenguaje Evitar el uso de sentencias goto. 5.6.2. Manejo de errores Defecto Son erratas o gazapos de software. Pueden permanecer ocultos hasta que los elementos defectuosos se ejecuten. Fallo Es el hecho de que un elemento del programa no funcione correctamente, produciendo un resultado errneo. Error Es un estado inadmisible de un programa al que se llega como consecuencia de un fallo. Puede ser la salida o almacenamiento de datos errneos. En la fase de codificacin se pueden adoptar diferentes actitudes respecto al tratamiento de los fallos: No considerar los errores Mediante esta actitud se declina toda responsabilidad si se produce algn error. Es la ms cmoda desde el punto de vista de la codificacin pero es poco realista no pudindose garantizar el resultado correcto del programa. Prevencin de errores Se basa en la llamada programacin a la defensiva defensive programming y consiste en que se desconfa sistemticamente de los datos o argumentos que se introducen. Siempre devolver: a) el resultado correcto, si los datos son vlidos, o; b) una indicacin precisa del fallo, si los datos son vlidos. Hay que considerar que se trata de detectar un fallo y evitar que se produzcan y propaguen errores. Esto facilita el diagnstico de defectos. Recuperacin de errores Se produce cuando no se puede detectar un fallo y consiste en tratar el error con el fin de restaurar el programa en un estado correcto y evitar que el error se propague. Consta de dos fases: 1) Deteccin del error, en la que se concretarn las situaciones que se consideran errneas y dnde realizar comprobaciones estratgicas, y; 2) Recuperacin del error, en la que se decidirn que decisiones se adoptarn para corregir el estado del programa y llevarlo a una situacin consistente. A su vez, la recuperacin se puede hacer de dos formas: a) hacia delante, que trata de identificar la naturaleza o tipo del error (fuera de rango, etc.) y tomar las medidas para su correccin mediante el mecanismo de excepciones, y; b) hacia atrs, en el que el estado del programa se trata de corregir restaurndolo a un estado
23
Programas tolerantes fallos 5.6.3. Aspectos de eficiencia En la actualidad no existe prcticamente ningn caso en que haya que sacrificar la claridad en la codificacin por una mayor eficiencia. La eficiencia se puede medir de dos formas: eficiencia en memoria y eficiencia en tiempo. Eficiencia en memoria Se puede mejorar utilizando un compilador que disponga de compresin por memoria. Tambin se puede optimizar el algoritmo que utilice la memoria. Eficiencia en tiempo Es muy importante en sistemas de tiempo real con plazos crticos. En muchas ocasiones se puede aumentar la eficiencia en tiempo a costa de la eficiencia en memoria, consiste pues, en almacenar o tabular datos intermedios en memoria y consultarlos. Tcnicas que permiten el ahorro son: Tabular los clculos complejos (almacenarlos par su consulta). Expansin en lnea. Macros en vez de subrutinas (ahorran la llamada, argumentos, etc.) Desplegado de bucles. La evaluacin de la condicin del bucle se realiza una vez por lo que si el cdigo se repite varias veces, se ahorra tiempo. Simplificar expresiones aritmticas y lgicas. Sacar fuera de los bucles todo lo que no sea necesario repetir. Utilizar estructuras de acceso rpido (vectores en lugar de listas con encadenamiento). Evitar la utilizacin de coma flotante, usar coma fija. Evitar las conversiones innecesarias de tipos de datos. 5.6.4. Transportabilidad de software La realizacin de un programa transportable implica un esfuerzo adicional que se ve recompensado a corto, medio y largo plazo. Los factores esenciales de la transportabilidad son los siguientes: Utilizacin de estndares Un producto software desarrollado exclusivamente sobre elementos estndares es en teora transportable sin ningn cambio, entre plataformas que cuenten con el soporte apropiado para dichos estndares. Si los estndares no estuvieran disponibles se deberan utilizar lenguajes, compiladores y herramientas que se puedan considerar estndares de facto. Aislar las peculiaridades Consiste en destinar un mdulo especfico para cada peculiaridad que ser reprogramada en la nueva plataforma. Algunas de dichas peculiaridades estn vinculadas a: Arquitectura del La arquitectura del computador determina la longitud de palabra (8, 16, 32 o 64 bits) y de computador esto se derivan la representacin interna de los valores enteros o reales. Ello implica que podran haber desbordamientos de los rangos lo que a su vez conlleva a tener que definir tipos abstractos para representar nmeros, lo que significara una disminucin importante del rendimiento. Otro problema es la tabla de representacin de caracteres. Casi siempre est basada en el cdigo ASCII, pero hay que cerciorarse. Sistema Operativo Todos los sistemas operativos ofrecen servicios para acceder a ficheros, teclado, libreras, etc. El lenguaje accede a estos servicios mediante el sistema operativo, en concreto mediante procedimientos o funciones predefinidos para ello. Sin embargo, algunos compiladores en otra plataforma pueden tener funciones o procedimientos diferentes. Esto hace que las especificaciones y las interfaces de dichos procedimientos tengan que estar en mdulos separados. 5.7. Tcnicas de prueba de unidades Antes de entregar al cliente el producto software ha tenido que haberse probado todo el sistema. La forma mejor de probar un proyecto es realizar pruebas a cada unidad o mdulo segn se avanza en la codificacin del proyecto. Esto facilitar las posteriores pruebas de integracin entre mdulos y las pruebas del sistema global. 5.7.1. Objetivos de las pruebas de software El objetivo de las pruebas de software es conseguir que el programa funcione de forma incorrecta con el fin de descubrir sus defectos. Casos de prueba Es el juego de pruebas al que se someter el programa. Se debe tener en cuenta: Una buena prueba es la que encuentra errores y no los encubre Para detectar un error es necesario conocer cul es el resultado correcto Es bueno que no participen en la prueba el codificador y el diseador Siempre hay errores, y si no aparecen se deben disear pruebas mejores
correcto anterior a la aparicin del error. Esto exige guardar peridicamente el ltimo estado correcto. De esta forma se partir de ese ltimo estado para obtener otro nuevo estado. Si ste nuevo estado es correcto, la operacin termina bien, de lo contrario se restaura un estado anterior y se realizar la operacin por un camino diferente del algoritmo. Este esquema se utiliza en sistemas basados en transacciones (b.d., bancos) en el que una operacin puede terminar con xito, modificando el estado del sistema (commit), o con fallo, en cuyo caso la transaccin se aborta (abort) y se restaura el estado anterior, con lo que la operacin no produce ningn efecto. a Son aquellos que realizan una previsin o recuperacin de errores.
24
Al corregir un error se pueden producir otros nuevos Es imposible demostrar la ausencia de defectos mediante pruebas Con las pruebas se explora una parte de todas las posibilidades del programa. Se trata de alcanzar un compromiso para que con el menor esfuerzo posible se puedan detectar el mximo n de defectos. Es importante que el proceso de prueba se realice de la forma lo ms automtica posible con el fin de que una vez detectados y corregidos los defectos se pueda volver a realizar el proceso de prueba y ver si los cambios corrigieron el defecto. Las pruebas han de realizarse en un entorno de ejecucin controlado y deben proporcionar, al menos, un informe con los resultados de las pruebas y un registro de todos los errores detectados con su discrepancia respecto al valor esperado. 5.7.2. Pruebas de caja negra (black box) Es la estrategia que debe adoptar el cliente y consiste en ignorar la estructura interna del programa centrndose exclusivamente en la comprobacin de la especificacin entrada-salida del software. Debe verificar todos los requisitos impuestos al programa. La elaboracin del juego de prueba es muy importante, debiendo acudir a la experiencia del programador para indicar los mdulos sospechosos. Algunos mtodos para la elaboracin de los casos de prueba son: Particin en clases de Consiste en dividir el espacio de ejecucin equivalencia del programa en varios subespacios o clases equivalentes. Cada uno de ellos agrupa a todos aquellos datos de entrada al mdulo que resultan equivalentes desde el punto de vista de la prueba de caja negra. El mtodo se realiza en varios pasos: Determinar las clases equivalentes apropiadas. Definir una prueba que cubra tantos casos vlidos como sea posible de cualquier clase. Marcar las clases cubiertas y repetir el paso anterior hasta cubrir todos los casos vlidos de todas las clases. 4. Definir una prueba especfica para cada caso invlido. Como ejemplo se contempla: a) Rango de valores: contemplar uno vlido, uno menor que el mnimo y uno mayor que el mximo; b) Valor especfico: contemplar uno vlido y otro invlido; c) Conjunto de valores, contemplar uno por elemento y uno fuera del conjunto. Anlisis de valores lmite Este mtodo se utiliza cuando los programas se codifican con una perspectiva general y (boundary analysis) luego son modificardos para adaptarlos a casos especiales. Es en la frontera de estos casos donde con mayor frecuencia se registran los fallos. Este mtodo hace hicapi en el espacio de ejecucin prximo al borde y tambin debe proponer datos vlidos e invlidos en la prueba. Pasos: Los pasos a seguir con este mtodo son: 1. Entradas. Probar con los mismos valores lmite y justo fuera de lmites. 2. Salidas. Probar con los mismos valores lmite y justo fuera de lmites. Ejp. 70 lpp. 3. Memoria. Probar con tamaos nulos, lmite, y superior al lmite de todas las estructuras de informacin. 4. Recursos. Probar con ningn recurso, lmite de recursos y superior al lmite. 5. Pensar en otras situaciones lmite y establecer las pruebas. Comparacin de versiones En mdulos crticos se puede hacer un desarrollo multi-versin (N-version) que consiste en que la codificacin del mdulo la realicen diferentes programadores. Cada versin obtenida ser sometida al mismo juego de pruebas. Cuando todas las versiones produzcan los mismos resultados se podr utilizar cualquiera de ellas. Por el contrario si existen diferencias en los resultados habr que ver cual es el defecto que las ocasiona. Empleo de la intuicin Es conveniente disponer de cierto tiempo para pensar en los estados que podran provocar un error. Tambin es importante, contar con gente ajena al proyecto que pueda aportar una perspectiva ms fresca. 5.7.3. Pruebas de caja transparente (white box, clear box o glass box) Este mtodo, que debe ser complementario con el de caja negra, debe ser propuesto por alguien que haya participado en la codificacin y consiste en elaborar los casos de prueba teniendo en cuenta la estructura interna del programa, es decir, el programa debe transitar por todos los posibles caminos de ejcucin, en particular, debe conseguir: que todas las decisiones se ejecuten en uno u otro sentido; que todos los bucles se ejecuten en los supuestos ms diversos posibles, y; que todas las estructuras de datos se modifiquen y consulten alguna vez. Algunos de estos mtodos son: Cubrimiento lgico Ya que resulta imposible cubrir todas las formas posibles de un programa, se puede intentar cubrir al menos un camino bsico. Para hacer ms fcil este cubrimiento se debe hacer un diagrama de flujo en el que cada rombo, correspondiente a una seleccin, representar la evaluacin de un predicado simple (sin AND ni OR). El n de caminos posibles ser igual al n de predicados ms uno. Se pueden establecer ciertos niveles de cubrimiento: Nivel I. Se trata de elaborar casos de pruebas para que se ejecuten al menos una vez todos Pasos : 1. 2. 3.
25
los caminos bsicos, cada uno de ellos por separado. Nivel II. Se trata de elaborar casos de prueba para que se ejecuten todas las combinaciones de caminos bsicos por parejas. Las pruebas de cada mdulo deben garantizar al menos el nivel I. Ello asegurara al menos el 50% de los errores. Nunca se puede detectar cuando falta un fragmento de cdigo. Prueba de bucles Existen varias situaciones: Bucle con n no acotado de repeticiones. Se harn pruebas para 0, 1, 2, un n moderado y un n elevado de veces. Bucle con n mximo de repeticiones. Se harn pruebas para 0, 1, 2, un n intermedio, M-1, M y M+1 veces. Bucles anidados. Se har: 1) Ejecutar el bucle externo un n mnimo de veces para probar el bucle interno; 2) Para el siguiente nivel de anidamiento, ejecutar los bucles externos en su n mnimo de veces y los bucles internos un n tpico de veces con el algoritmo que le corresponda; 3) Repetir el paso 2 hasta completar todos los niveles. Bucles concatenados. Estudiar cada caso. Empleo de la intuicin La estrategia de caja transparente tambin hace rentable el pararse a pensar en pruebas en las que podra salir un defecto. 5.7.4. Estimacin de errores no detectados Las pruebas no garantizan que un programa no tenga defectos. Se puede hacer una estimacin de los errores segn se describe a continuacin: Estimacin de errores 1. Anotar el n de errores producidos inicialmente con el juego de pruebas. EI. 2. Corregir el mdulo hasta que no salga ningn error con el mismo juego de pruebas. 3. Introducir aleatoriamente en el mdulo un n razonable de errores. EA. 4. Someter el mdulo al juego de pruebas y recontar los errores detectados. ED. 5. Para el juego de pruebas el n estimado de errores sin detectar ser: EE = (EA ED) * (EI ED) 5.8. Estrategias de integracin Los mdulos de un producto software se han de integrar para conformar el sistema completo. Pueden aparecer errores en la interfaz, imprecisiones acumuladas, etc. Para corregir todos estos errores existen varias estrategias: 5.8.1. Integracin Big Bang Consiste en realizar la integracin de todos los mdulos en un nico paso. Es imposible de utilizar en proyectos grandes. 5.8.2. Integracin descendente Con esta estrategia se parte de un mdulo principal que se prueba con mdulos de andamiaje o sustitutos stubs de los otros mdulos usados directamente. Los mdulos sustitutos se van reemplazando por los verdaderos y se realizan las pruebas de integracin correspondientes. La codificacin de los sustitutos se puede hacer de varias formas: no hacer nada y que slo sirva para comprobar la interfaz; imprimir un mensaje de seguimiento con informacin de la llamada; suministrar un resultado fijo; suministrar un resultado aleatorio. Ventajas Desde el inicio se ven las posibilidades de la aplicacin. Permite demostraciones al cliente. Desventajas Limita en cierta forma el trabajo en paralelo. Al conducir la integracin de los nuevos mdulos desde otros ya integrados se tienen bastantes limitaciones para hacer pruebas especiales. 5.8.3. Integracin ascendente Con esta estrategia se comienza por codificar los mdulos de un nivel ms bajo. Luego se escriben los mdulos gestores drivers que los hacen funcionar o en combinaciones sencillas. Los gestores se van sustituyendo posteriormente uno a uno por los mdulos de mayor nivel segn se codifiquen. Al final se obtendr el sistema completo. Ventajas Facilita el trabajo en paralelo y facilita el ensayo de situaciones especiales. Desventajas Resulta difcil ensayar el funcionamiento global. Integracin sandwich Es la mejor solucin y consiste en utilizar una integracin ascendente con los mdulos de nivel ms bajo y una integracin descendente con los mdulos de nivel ms alto. 5.9. Pruebas de sistema Una vez finalizada la integracin hay que probar el sistema completo. Se suele aplicar aqu una estrategia de caja negra. 5.9.1. Objetivos de las pruebas Clases de pruebas Existen diferentes clases de pruebas: Pruebas de recuperacin. Permite comprobar la capacidad del sistema para recuperarse ante fallos. Debe comprobar si el sistema lo detecta y/o lo corrige. Pruebas de seguridad. Comprueba los mecanismos de proteccin contra accesos no autorizados. Pruebas de resistencia. Debe comprobarse el sistema cuando ste se ve forzado por encima de su capacidad. Pruebas de sensibilidad. Cmo responde el sistema ante algoritmos matemticos. Prueba de rendimiento. Comprueba las prestaciones del sistema que son crticas en
26
tiempo. 5.9.2. Pruebas alfa y beta Son pruebas en las que participan los usuarios. Permiten detectar fallos del tipo: mensajes ininteligibles para el usuario; deficiencias en el manual de usuario; procedimientos de operacin inusuales, etc. Pruebas alfa Son aquellas (las primeras) que se realizan en un entorno controlado donde el usuario tiene el apoyo de alguna persona del equipo de desarrollo y a su vez esta misma persona puede seguir muy de cerca la evolucin de las pruebas. Pruebas beta Con estas pruebas, uno o varios usuarios trabajan en un entorno normal y anotan cualquier anomala. Deben advertir al equipo de programadores cul fue el procedimiento que le llev al error. 6. AUTOMATIZACIN DEL PROCESO DE DESARROLLO Este tema se dedica a analizar los elementos de soporte informtico del proceso de desarrollo (herramientas CASE). 6.1. Entornos de desarrollo software Entorno (environment) Con la palabra entorno se designa el contexto en el que se realiza una actividad, y en particular para designar la combinacin de instrumentos disponibles para ello. Hay que hacer especial hincapi en que el entorno engloba todos esos instrumentos de una forma coherente por lo que parece ms una herramienta global que una coleccin de herramientas. SEE Un entorno de desarrollo de software (Software Engineering Environment) es un conjunto de elementos informticos que permiten facilitar el desarrollo. Dichas tcnicas de soporte informtico se designan con CASE (Computer Aided Software Engineering). Diversos enfoques En los ltimos aos han aparecido diversos enfoques en el desarrollo de productos CASE que a veces provoca cierta confusin. 6.2. Panormica de las tcnicas CASE 6.2.1. Soporte de las fases de desarrollo Lo que hoy denominamos entorno fue evolucionando desde las fases centrales del ciclo de vida hasta sus extremos. Dicha evolucin ha ido pareja con la evolucin de los lenguajes. Un entorno de programacin clsico consta de un compilador, un editor de texto y un montador de enlace. Alternativamente existen los intrpretes que en una sola herramienta constaba con funciones de edicin y ejecucin. La aparicin de las herramientas CASE dieron soporte a las metodologas de anlisis y diseo. Para la fase de pruebas existen herramientas que permiten ejecutar programas de prueba. Para la fase de mantenimiento tambin hay herramientas que admiten la gestin de versiones y el control de cambios. En la actualidad no existe una tcnica CASE que controle el ciclo de vida completo, aunque ya se han establecido esquemas generales para integrar diversos elementos en un entorno comn constituyendo lo que se denomina IPSE o ICASE. IPSE Integrated Project Software Engineering ICASE Integrated CASE 6.2.2. Formas de organizacin Entorno de desarrollo Un entorno de desarrollo de software es una combinacin de elementos que automatizan una variedad mayor o menor de funciones. Estos entornos se pueden organizar de varias formas. Una de ellas consiste en que el resultado de un elemento sea la entrada del siguiente (cadenas de trabajos), p.ejp. editor-compilador-montador. Otra forma consiste en disponer de un almacn, denominado repositorio, en el que toda la informacin se guarda en un formato comn, de forma que est disponible para cualquier herramienta (esta es la forma en que se suelen organizar las herramientas CASE en el que los propios datos se utilizan para roturar las flechas de los diagramas, etc.). 6.2.3. Objetivo de un entorno de desarrollo La enorme cantidad de herramientas existentes en la actualidad hace que sea difcil su clasificacin debido a los diferentes objetivos para los cuales se disearon. Uno de los objetivos parciales de los entornos es dar soporte a la programacin en un lenguaje concreto, de hecho ha habido casos en que el entorno es tan importante como el lenguaje (Smalltalk y Ada). Otro objetivo consiste en dar soporte a una metodologa de desarrollo concreta (CASE). Otros entornos se centran en la planificacin y control del proceso de desarrollo de trabajo. 6.3. Una clasificacin pragmtica Se presenta a continuacin una clasificacin de entornos, poco formal, pragmtica, en la que tenemos: entornos asociados a un lenguaje, entornos orientados a estructura, entornos basados en herramienta, entornos asociados a una metodologa,y, entornos de 4 generacin. 6.3.1. Entornos asociados a un lenguaje Los primeros entornos asociados a un lenguaje lo constituyeron los intrpretes de LISP o BASIC. Estos intrpretes permiten modificar, ejecutar, y depurar los programas. Algunos como LISP permiten realizar cambios en variables, ver los valores, parar la ejecucin, ver historial de rdenes, etc. Existen dos lenguajes dignos de mencionar: Smalltalk Un caso especial es el del lenguaje Smalltalk (primer lenguaje orientado a objetos), en el que el programa no constituye un elemento separado del entorno de desarrollo sino que se materializa como una versin modificada del propio entorno, es decir, se pueden utilizar todos los elementos existentes en el entorno, como estructuras, definiciones de clases, objetos, etc. y utilizarlos como propios.
27
Con el lenguaje Ada se ha definido el lenguaje en s y la arquitectura y funciones elementales de los entornos de programacin (el entorno se llama Stoneman). Dispone de: KAPSE (Kernel Ada Program Support Environment) que es el ncleo base y debe estar disponible en cualquier sistema. En la actualidad est disponible de una serie de funciones denominadas CASI (Common APSE Interface Set). MAPSE (Minimal Ada Program Support Environment) que es una serie de herramientas: editor, compilador, montador, etc. APSE (Ada Programming Support Environment) que constituye el sistema completo. 6.3.2. Entornos orientados a estructura En estos sistemas el cdigo del programa se guarda de forma estructurada de forma que no se modificar como un simple texto sino que se guardar su equivalente como rbol de sintaxis abstracta (AST: Abstract Syntax Tree) lo que permite operar con su estructura directamente. Algunas de estas tcnicas han sido desarrolladas para el lenguaje PL/1 (Program Synthesizer y su evolucionado Synthesizer Generator) que basado en plantillas permite modificar la estructura codificada del programa. 6.3.3. Entornos basados en herramientas Son una serie de herramientas (toolkit o toolbox) ms o menos independientes que son compatibles entre s y que funcionan de forma combinada. Un buen ejemplo lo tenemos en Unix que dispone de las utilidades cc (compilador/montador), vi (editor de textos), ar (gestor de libreras), cdb (depurador simblico), etc., adems dispone de otras herramientas para tratar ficheros de texto. El sistema operativo dispone de mecanismos para combinar todas esas utilidades, en particular una de las ms flexibles la constituye el shell o intrprete de rdenes. Este tipo de entornos tiene la ventaja de que son bastante abiertos lo que permite la incorporacin de nuevas herramientas. 6.3.4. Entornos asociados a metodologa Una de las ventajas de utilizar herramientas CASE es que constituyen entornos de trabajo bien integrados y con una interfaz de usuario uniforme. Dicha integracin se consigue con la utilizacin de un repositorio CASE. 6.3.5. Entornos de 4 generacin La mayora de estos entornos, que estn orientados al usuario final, consiste en un sistema de gestin de bases de datos dotado de un lenguaje de consulta, al que se aaden algunas herramientas complementarias. Muchos de estos entornos se pueden considerar como entornos de programacin visuales. 6.4. Una clasificacin por niveles Otro criterio de clasificacin de las herramientas CASE es hacerlo por las funciones realizadas. Con esta clasificacin se utiliza un criterio base que es el nivel de funcionalidad del producto CASE: Nivel de servicio Corresponde a un producto que realiza una operacin de forma automtica y sin interrupcin, p. Ejp. la compilacin de un programa fuente. Nivel de herramienta Corresponde a un producto que permite invocar diferentes servicios u operaciones en una misma actividad dentro del proceso de desarrollo, p. Ejp. un editor (de texto, diagrama). Nivel de banco de trabajo Tambin llamado Workbench, Toolkit o Toolbox corresponde a un producto CASE que soporta un perfil concreto de actividad profesional dentro del proceso de desarrollo, p. Ejp. la actividad del analista. Cuando se trata de la actividad de programacin hablamos de entorno de programacin. Nivel de entorno de Corresponde a un producto CASE que soporta el proceso completo de desarrollo de desarrollo software. Son las IPSE o ICASE. 6.5. Herramientas de software 6.5.1. Herramientas clsicas Editor de texto Permite editar ficheros de texto formado por lneas y caracteres. No atiende a su contenido. Compilador Traduce un fichero de texto fuente a otro de cdigo objeto reubicable, no ejecutable. Montador de enlaces Tambin llamado linker permite construir un programa ejecutable combinando varios ficheros objeto. Maneja libreras de funciones invocadas en los programas. Gestor de librera Permite combinar varios ficheros objetos en una librera nica. Herramienta Make Permite automatizar la actualizacin de un conjunto de ficheros a partir de otros. Utiliza un fichero de dependencias en el que se indica de qu ficheros depende uno dado. Intrprete interactivo Engloba funciones equivalentes a las de edicin, compilacin, montaje y ejecucin. Compilador/Intrprete Es un procesador de lenguaje interpretado en forma no interactiva. Depurador absoluto Permite ejecutar un programa instruccin por instruccin de forma controlada. Permite cambiar cualquier dato en memoria de forma directa. Es incmodo de utilizar. Depurador simblico Idem. Anterior pero trabajando con el cdigo fuente por lo que es ms cmodo. Se accede a las variables simblicas. 6.5.2. Herramientas evolucionadas Editores orientados a lenguaje Suelen ser editores de estructura. Herramienta Make automtica Permite automatizar las funciones del fichero de dependencia, analizando el cdigo fuente.
Ada
28
Permiten almacenar de forma organizada una serie de versiones de un mismo elemento de software. Permiten manejar ficheros de texto (SCCS de Unix). Se suele utilizar una numeracin correlativa 1.1, 1.2, etc. Algunos productos utilizan ficheros separados para cada versin, otras agrupan todas las versiones de un mismo sistema. Procesadores/Analizadores de Son herramientas que analizan el cdigo fuente para obtener mediciones, generar cdigo fuente tablas de referencias, encolumnar segn un estilo normalizado prettyprinters, comprobar consistencia de mdulos, etc. Procesadores de documentos Permiten la edicin de la documentacin. Herramientas de control de pruebas Ayudan a la realizacin de pruebas unitarias o de integracin. Las hay para comprobar el grado de cubrimiento, otros simulan la entrada de datos, etc. Herramientas de control de cambios Ayudan a la realizacin del desarrollo en forma incremental, y al mantenimiento de aplicaciones. Mantiene una configuracin consistente del sistema, llamada lnea base, y slo permite incorporar cambios de forma controlada, garantizando que las modificaciones mantienen el sistema en estado operativo. Procesadores de ficheros de texto A este grupo pertenece gran cantidad de utilidades de Unix, como p. Ejp. awk que es un compilador/intrprete de un lenguaje de manipulacin de ficheros de texto. 6.5.3. Herramientas de 4 generacin Son herramientas destinadas al usuario final permitiendo a ste realizar sus propios desarrollos. Hoja de clculo Facilita la realizacin de lculos basados en una plantilla de tipo matricial. Las casillas se pueden rellenar automticamente o con datos calculados. Las frmulas se editan de forma interactiva. Algunas permiten realizar grficos. Procesadores de documento Ya se mencion. Gestores de bases de datos Permiten definir los esquemas de las bases de datos, y realizar operaciones de consulta y manipulacin. Lenguajes de 4 generacin Permiten programar operaciones de tratamiento de datos. Suelen ir asociados a un gestor de bases de datos (s.g.b.d.) e incluyen un lenguaje de consulta (SQL). Generadores de programas Tambin suelen estar asociados a un s.g.b.d. y permiten la preparacin interactiva de esquemas de informes, formularios, etc.Posteriormente generan programas en un L4G. 6.6. Entornos integrados La integracin puede presentar diferentes aspectos: 6.6.1. Integracin de datos Integracin de datos Significa que la informacin almacenada en el entorno es uniformemente gestionada. Debe lograr: interoperatividad entre herramientas, no redundancia de datos, consistencia de datos, paso de datos de una herramienta a otra. Eso se puede lograr de varias formas: Transferencia directa de datos de una herramienta a otra. Es poco flexible. Transferencia mediante ficheros. Es la forma ms sencilla. Existe incluso un formato. Transferencia basada en comunicacin. Para usar en sistemas distribuidos y abiertos. Repositorio comn. La ms utilizada en entornos modernos. 6.6.2. Integracin del control Consiste en permitir la combinacin flexible de funciones para cumplir con las particularidades del proceso y actividades a informatizar. Ello exige que las herramientas puedan compartir los datos entre ellas y, como consecuencia, debe existir un sistema de gestin de procesos y mensajes 6.6.3. Integracin de la presentacin Integracin de la Trata de realizar la interaccin con el usuario de manera uniforme, independientemente de presentacin la funcin herramienta que use en un momento dado. Esto hace que se reduzca el esfuerzo de memoria y sea un sistema amigable (user-friendly). Para ello se debe: Limitar el n de formas de 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 informacin del avance de la operacin cuando va a tardar mucho. Mantener informacin til a disposicin del usuario. 6.6.4. Integracin del proceso
Manejador de versiones
29
Integracin del proceso
Consiste en que las herramientas se combinan de forma que fuerzan de manera efectiva el uso de una metodologa de desarrollo definida. El proceso de desarrollo se puede definir en base a: Un paso del desarrollo es una unidad de trabajo que produce un resultado. Un evento de desarrollo es una condicin que ocurre durante la ejecucin de un paso y que puede desencadenar la ejecucin de una accin asociada. Una restriccin del desarrollo es una limitacin que debe cumplirse. Un 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. Para ello se requiere: Un servicio metamodelo que permita definir las estructuras de datos que han de almacenarse. Un servicio de consulta y actualizacin (query) que permita acceder a la informacin. Un servicio de vistas, que permita definir subconjuntos de datos y operaciones que constituyan el subentorno de trabajo de ciertas actividades. Un servicio de intercambio de datos, que facilite la importacin y exportacin de informacin mediante ficheros externos. Puede estar constituida por: cdigo fuente, cdigo objeto, cdigo ejecutable, rdenes de compilacin y montaje, dependencias entre mdulos, estructura modular, programas de prueba, datos de prueba, resultados de pruebas, especificaciones de mdulos, informacin de cambios, mtricas de calidad, documentos de diseo, documentos de requisitos, informes de revisiones, definicin de la metodologa de desarrollo, informacin de la planificacin del proyecto, informacin, de la gestin del proyecto, e informacin de la empresa.
6.6.5. El repositorio CASE Repositorio CASE
Informacin a guardar
6.7. Bancos o equipos de trabajo Para que un banco de trabajo se pueda definir como tal, es decir, que cumpla con el trabajo de integrar las herramientas necesarias para dar soporte a un determinado perfil, debe conseguir: a) integracin de la presentacin con una interfaz de usuario homognea y consistente; b) integracin del control, con la posibilidad de invocar cmodamente una herramienta, y; c) integracin de datos, preferiblemente mediante un repositorio comn. Segn la actividad se tendrn diferentes bancos o equipos de trabajo: Equipo de anlisis y diseo Llamados upper CASE deben soportar completamente una determinada metodologa. La modificacin de un elemento se debe apreciar en todos los diagramas o descripciones en donde aparezca. Entorno de programacin Es el banco de trabajo para la actividad de codificacin, y puede extenderse al diseo detallado y a las pruebas de unidades. Equipo de validacin y verificacin Debe ser capaz de facilitar las tareas de inspeccin y pruebas de mdulos y sistemas. Suele estar ligado al entorno de programacin. Equipo de construccin de intefaz de Permite definir cmodamente el esquema de dilogo con el usuario, as como los usuario elementos de interaccin. Equipo de gestin de configuracin Debe permitir almacenar las diversas versiones de los elementos de un proyecto. Equipo de ingeniera inversa Debe facilitar la extraccin de informacin de diseo y los elementos abstractos a partir de un cdigo ya desarrollado. Equipo de gestin de proyectos Facilita la confeccin de planes de trabajo con asignacin de tiempos y recursos, gestin de reuniones, seguimiento, etc. 6.8. Entornos orientados al proceso Un entorno de desarrollo orientado al proceso debe ser capaz de soportar todas las actividades del ciclo de vida de desarrollo conforme a una metodologa concreta (IPSE o ICASE o ISEE Integrated Software Engineering Environment). Este tipo de entornos debera permitir: a) construir la definicin formal del modelo del proceso de desarrollo, y b) asegurar la aplicacin prctica del modelo definido. Muchos de estos entornos son creados en empresas. Algunas propuestas de esta clase de entornos son: PCTE Portable Common Tool Environment. Es una arquitectura de entorno integrado basada en un repositorio comn. En ella lo principal es la interfaz de acceso al repositorio. ESF Eureka Software Factory. Aqu el elemento central de integracin es el software bus que constituye la interfaz normalizada para la interconexin de herramientas, que se dividen en herramientas de interaccin, y servidores. NIST/ECMA Propuesto por varios organismos europeos y americanos se compone de una estructura fija que tiene elementos que proporcionan integracin de datos (repositorio comn), integracin de presentacin (soporte global de interfaz de usuario) e integracin de control (procesos y mensajes). ESSDE Es el entorno utilizado por la ESA y es el resultado de un enfoque pragmtico. Se basa en Concerto (herramienta CASE basada en metodologa HODD) y Rational Ada que es un entorno de programacin en lenguaje Ada.
30
31

Apuntes UNED

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Apuntes UNED

Caricato da

Copyright:

Formati disponibili

U.N.E.D.

Ingeniera Tcnica en Informtica de Gestin

INGENIERA DEL SOFTWARE

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Acoplamiento Externo Acoplamiento de Control Acoplamiento por Etiqueta

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Integracin del proceso

6.6.5. El repositorio CASE Repositorio CASE

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Apuntes realizados por Antonio Reyes. C.A.Tenerife

Potrebbero piacerti anche