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

1

Universidad Nacional de Educacin a Distancia (UNED) Ingeniera Tcnica en Informtica de Gestin Ingeniera del Software. RESUMENConcepto 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


2

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


3

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:


4

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.


5

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.


6

2.1. Modelado de Sistemas De la misma forma que en arquitectura se utilizan maquetas para analizar edificios, el desarrollo de sistemas permite la 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


7

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


8

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


9

[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

Apuntes UNED

Documents

Transcript of Apuntes UNED