INGENIER

1
INGENIERÍA DEL SOFTWARE

• Javier Martín
• Centro Asociado de Móstoles / Tres Cantos
• UNED

2
Introducción

• JAVIER MARTIN (jmartin_at_escet.urjc.es)
• TUTORIAS JUEVES/VIERNES de 7 a 9
• PLAN DE TRABAJO
• Exposición de los temas y mediante transparencia,
  abundando en los puntos más importantes.
• Resolución de dudas
• Propuesta y resolución de ejercicios y problemas

3
Temas

• INTRODUCCIÓN
• ESPECIFICACIÓN DEL SOFTWARE
• FUNDAMENTOS DEL DISEÑO SOFTAWARE
• TÉCNICAS GENERALES DE DISEÑO SOFTWARE
• CODIFICACIÓN Y PRUEBAS
• AUTOMATIZACIÓN Y PROCESO DE DESARROLLO

4
Tema 1 INTRODUCCIÓN
5
Concepto de Ingeniería de Sistemas

• Concepto de sistema, conjunto de cosas que
  ordenadamente relacionadas entre sí contribuyen a
  un determinado objeto. De forma recursiva, las
  partes de un sistema pueden ser consideradas como
  nuevos sistemas (subsistemas).
• Los sistemas informáticos están compuestos por
  ordenadores y sus periféricos. Entre ellos
  podemos distinguir dos tipos de subsistemas
• Sistemas Hardware, son los elementos materiales,
  los que se pueden tocar.
• Sistemas Software, los programas que gobiernan el
  funcionamiento del computador.
• El objetivo de los sistemas informáticos es el
  tratamiento de la información almacenamiento,
  elaboración y presentación de datos. De esta
  forma se automatizan determinadas acciones.
• En la concepción del sistema informático no solo
  se decide el trabajo a realizar, sino también
  cómo ha de ser utilizado por los usuarios.

6
Concepto de Ingeniería del Software

• Características del software (lo contrario para
  el hardware)
• No se desgasta ni envejece, y por este motivo no
  requiere reparaciones ocasionales
• Su duplicación es poco costosa, lo caro es el
  desarrollo
• Puede ser modificado fácilmente, tanto que es
  necesario un control de versiones
• La Ingeniería del Software comprende las técnicas
  y procedimientos ingenieriles para el desarrollo
  del software.
• La IS no se plantea solo una actividad de
  programación, previamente son necesarias las
  fases de análisis y diseño y posteriormente la
  integración y la verificación, incluso el
  manteniendo cuando el producto ya está en
  explotación. (CICLO DE VIDA).
• Inicialmente la tarea de desarrollo era realizada
  individualmente por hábiles creativos, de forma
  poco disciplinada. El trabajo en equipo supone la
  división y organización del trabajo utilizando
  metodologías de desarrollo.
• En los 70 y los 80 empiezan a usarse herramientas
  CASE (Computer Aided Software Engineering). En
  los 90 IPSE e ICASE.

7
La crisis del Software

• Se produce cuando surge la necesidad de
  desarrollar aplicaciones software demasiado
  complejas, a mediados de los 60.
• Para superar la crisis
• Aparición de metodologías concretas de desarrollo
• Concepción de la Ingeniería del Software como
  disciplina
• Trabajo en equipo y especialización (analistas,
  programadores, ...)
• No se ha llegado a una situación estable, sino a
  una evolución permanente con avances continuos en
  la IS, forzados por el rápido abaratamiento y
  aumento de capacidad del hardware.

8
Mitos del Software

• El hardware es mucho más importante que el
  software
• El software es fácil de desarrollar
• El software consiste exclusivamente en programas
  ejecutables
• El desarrollo del software es sólo una labor de
  programación
• Es natural que el software contenga errores

9
Formalización del proceso de desarrollo

• La ingeniería supone la existencia de procesos
  bien establecidos para la realización de
  actividades de desarrollo, construcción,
  fabricación, etc.
• El ciclo de vida es el proceso de desarrollo y
  mantenimiento del software. Según el modelo
  elegido se describen un conjunto de actividades
  para llevar a cabo el ciclo de vida,
• Los modelos clásicos
• MODELO EN CASCADA
• MODELO EN V
• Prácticamente identifican actividades similares y
  sólo se diferencian en la forma de presentación.

10
MODELO EN CASCADA
11
MODELO EN CASCADA

• ANÁLISIS, determinar qué debe hacer el software
  -gt especificación
• DISEÑO, descomponer y organizar el sistema para
  que los módulos puedan ser desarrollados por
  separado
• CODIFICACIÓN, escribir el código fuente de cada
  módulo y realizar sobre ellos las pruebas
  necesarias
• INTEGRACIÓN, combinar todos los módulos y probar
  el sistema completo antes de pasar a su
  explotación
• MANTENIMIENTO, durante la explotación es
  necesario realizar cambios ocasionales bien para
  corregir errores o para introducir mejoras,
• Se trata de aislar cada fase de las otras, lo que
  facilita la especialización de los
  desarrolladores. Al final de cada fase se
  requiere un proceso de revisiónpara evitar que
  los errores se propaguen a fases posteriores
  provocando la vuelta atrás.

12
MODELO EN CASCADA AMPLIADO
13
MODELO EN CASCADA

• Cada fase debe generar una información de salida
  precisa y suficiente
• DOCUMENTOS DE REQUISITOS DEL SOFTWARE (SRD), es
  una especificación precisa y completa a partir de
  los requisitos establecidos por el cliente.
• DOCUMENTO DE DISEÑO DEL SOFTWARE
  (SDD),descripción de la estructura global del
  sistema, especificación de qué debe hacer cada
  uno de los módulos y de cómo se combinan.
• CÓDIGO FUENTE, el programa debidamente comentado
  (documentación interna).
• SISTEMA SOFTWARE, el ejecutable producto dela
  fase de integración y la documentación de las
  pruebas realizadas.
• DOCUMENTOS DE CAMBIOS, después de cada
  modificación realizada en la fase de
  mantenimiento problema detectado y solución
  adoptada

14
MODELO EN V
15
MODELO EN V AMPLIADO
16
MODELO EN V

• Incluye fases similares a las del modelo en
  cascada pero de forma jerárquica. En horizontal
  se representa el avance en el desarrollo y en
  vertical el nivel de detalle.
• VERIFICACIÓN, comprobación de que una parte del
  sistema cumple con sus especificaciones.
• VALIDACIÓN, comprobación de que un elmento
  satisface las necesidades del usuario
  identificadas durante el análisis.

17
PROTOTIPOS

• En los modelos clásicos se insiste en las
  actividades de revisión de resultados al final de
  cada fase para evitar la vuelta atrás, que no se
  contempla de una forma organizada y resulta muy
  costosa. Están orientados a una forma de
  desarrollo lineal.
• PROTOTIPO, es un sistema auxiliar que permite
  probar experimentalmente soluciones parciales a
  los requisitos del sistema
• Para que el coste de desarrollo del prototipo sea
  bajo en relación al del sistema final podemos
• Limitar las funciones
• Limitar su capacidad
• Limitar su eficiencia
• Evitar limitaciones de diseño, utilizando un
  hardware más potente que el que ejecutará el
  sistema final
• Reducir la parte a desarrollar

18
PROTOTIPOS RÁPIDOS

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

19
PROTOTIPOS RÁPIDOS
20
PROTOTIPOS EVOLUTIVOS

• En este caso se intenta aprovechar al máximo el
  código del prototipo, y para ello se emplea el
  mismo hardware/software del sistema final.
• Se realizan fases de análisis y diseño parcial,
  que se van ampliando hasta construir el sistema
  final mediante adiciones sucesivas.
• Se puede considerar un modelo en cascada en
  bucle, de manera que en cada iteración se va
  avanzando en el desarrollo.
• HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS, se
  emplean lenguajes de 4ª generación, que son de
  alto nivel y de tipo declarativo. También se
  emplean lenguajes de especificación, como VDM y
  Z. Si disponemos del compilador correspondiente
  podemos obtener automáticamente el código del
  prototipo.
• En el desarrollo de prototipos es clave la
  reutilización de software.

21
PROTOTIPOS EVOLUTIVOS
22
MODELO EN ESPIRAL

• Puede considerarse como un refinamiento del
  modelo evolutivo general que introduce el
  análisis de riesgo como elemento fundamental para
  guiar la evolución del proceso de desarrollo.
• En la dimensión radial se representa el esfuerzo
  realizado en el desarrollo (siempre creciente)
• En cada iteración 4 fases
• PLANIFICACIÓN, determina que parte del desarrollo
  se abordará en ese ciclo.
• ANALISIS DE RIESGO, evaluar diferentes
  alternativas para esa parte del desarrollo
  seleccionando la más ventajosa y tomando
  precauciones para evitar los posibles
  inconvenientes.
• INGENIERÍA, las actividades de los modelos
  clásicos
• EVALUACIÓN, se analizan los resultados de la fase
  de ingeniería.

23
MODELO EN ESPIRAL
24
MANTENIMIENTO DEL SOFTWARE

• El mantenimiento no representa una actividad
  específica, sino que consiste en rehacer parte de
  las actividades correspondientes a las otras
  fases del desarrollo para introducir cambios
  sobre una aplicación ya en fase de explotación.
• MANTENIMIENTO CORRECTIVO, su finalidad es
  corregir errores que no fueron detectados en el
  desarrollo del producto.
• MANTENIMIENTO ADAPTATIVO, modificar una
  aplicación para adaptarla a las nuevas
  necesidades del entorno.
• MANTENIMIENTO PERFECTIVO, se trata de ir
  obteniendo versiones mejoradas del producto

25
GESTIÓN DE CAMBIOS

• El mantenimiento supone la realización de una
  serie de cambios sucesivos
• Si afectan a la mayor parte del sistema se puede
  plantear como un nuevo desarrollo.
• Cada cambio debe ser documentado con
• INFORME DEL PROBLEMA, que ocasiona el cambio.
  Suele ser propuesto por el cliente.
• INFORME DE CAMBIO, describe la solución dada al
  problema y el cambio realizado
• REINGENIERÍA, es necesaria cuando el desarrollo
  de una aplicación no está documentado y se
  dispone solamente del código. Se llama también
  ingeniería inversa porque supone reconstruir y
  documentar las fases de análisis y diseño
  llegando a la estructura modular de la aplicación
  y las dependencias entre módulos y funciones.
  Estas actividades organizan y documentan un
  sistema deficiente.

26
GARANTÍA DE CALIDAD

• Para evaluar la calidad son necesarias técnicas
  de aplicación de métricas precisas tanto sobre
  los productos software como a sus procesos de
  desarrollo.
• McCall propone un esquema basado en valoraciones
  a 3 niveles
• FACTORES, valoración significativa de la calidad
  en base a los criterios establecidos
• CRITERIOS, aspectos de nivel intermedio que
  influyen en los factores de calidad
• MÉTRICAS, mediciones puntuales de determinadas
  características del producto.
• Entre los factores de calidad tenemos
• CORRECCIÓN, grado en que cumple con las
  especificaciones
• FIABILIDAD, grado de ausencia de fallos
• EFICIENCIA, reilación entre la cantidad de
  resultados y los recursos requeridos
• SEGURIDAD, dificultad para el acceso a datos por
  personas no autorizadas
• FACILIDAD DE USO, esfuerzo requerido para el
  aprendizaje de la aplicación
• MANTENIBILIDAD. Facilidad para corregir el
  producto en caso necesario.
• FLEXIBILIDAD, facilidad para modificar el
  producto
• FACILIDAD DE PRUEBA, depende del esfuerzo
  requerido para comprobar su corrección o
  fiabilidad
• TRANSPORTABILIDAD, facilidad para adaptar el
  producto a otra plataforma
• REUSABILIDAD, facilidad para usar partes del
  producto en otros desarrollos
• INTEROPERATIVIDAD, facilidad del producto para
  trabajar con otros

27
PLAN DE GARANTÍA DE CALIDAD (SQAP)

• Es un documento formal para organizar el proceso
  de desarrollo software de manera que se asegure
  la calidad del producto final. Debe contemplar
• Organización, dirección y seguimiento de los
  equipos de desarrollo
• Modelo de ciclo de vida a seguir, detallando
  fases y actividades
• Documentación requerida, determinando contenido y
  guión de cada documento
• Revisiones y auditorias, para garantizar que las
  actividades y los documentos son correctos
• Organización de las pruebas, a distintos niveles
• Organización de la etapa de mantenimiento,
  determinando cómo gestionar la realización de
  cambios

28
REVISIONES

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

29
PRUEBAS

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

30
GESTIÓN DE CONFIGURACIÓN

• CONFIGURACIÓN, disposición de las partes que
  componen una cosa y le dan su peculiar figura.
• La CONFIGURACÏÓN SOFTWARE se refiere a la manera
  en que diversos elementos se combinan para
  construir un producto software.
• Se han de combinar todos los elementos que
  intervienen en el desarrollo
• Documentos del desarrollo
• Código fuente
• Programas, datos y resultado de las pruebas
• Manuales de usuario
• Documentos de mantenimiento, informes de
  problemas y cambios
• Prototipos intermedios
• Normas particulares del proyecto
• Dado que los elementos software van evolucionando
  a lo largo del desarrollo se requiere
• Control de versiones, almacenar de forma
  organizada las sucesivas versiones de cada
  elemento de la configuración.
• Control de cambios, garantizar que las diferentes
  configuraciones del software se componen de
  elementos compatibles entre sí (línea base).

31
NORMAS Y ESTÁNDARES

• IEEE, Institute of Electrical and Electronics
  Engineer de USA IEEE93
• DoD, Departament od Defense de USA DoD88
• ESA, Agencia Europea del Espacio ESA91
• ISO, organismo internacional de normalización
  (International Standars Organization). En España
  AENOR.
• METRICA-2, desarrollada por el Consejo Superior
  de Informática del MAP. Se basa en la metodología
  de análisis y diseño de Yourdon/DeMarco.

32
Tema 2 ESPECIFICACIÓN DE SOFTWARE
33
MODELADO DE SISTEMAS

• El análisis y la definición de los requisitos
  debe dar lugar a la especificación software, en
  la que se concretan las necesidades que se desean
  cubrir y se fijan las restricciones con las que
  debe trabajar el software.
• El modelado de los sistemas tiene como objetivo
  entender mejor el comportamiento requerido y
  facilitar la comprensión de los problemas
  planteados. Se trata de establecer modelos
  conceptuales que reflejen la organización de la
  información y las diversas transformaciones que
  se deben llevar a cabo con dicha información.
• Las metodologías de análisis de requisitos tratan
  de facilitara obtención de uno o varios modelos
  que detallen el comportamiento deseado del
  sistema.

34
CONCEPTO DE MODELO

• Un modelo conceptual es una abstracción
  lógico-matemática del mundo real que facilita la
  comprensión del problema a resolver. Se trata de
  ofrecer una visión de lato nivel, sin descender a
  explicar detalles concretos del mismo. Indica QUÉ
  hace el sistema y no CÓMO lo debe hacer.
• Los OBJETIVOS a cubrir con los modelos son
• Facilitar la comprensión de l problema
• Establecer un marco para la discusión que
  simplifique y sistematice el análisis
• Fijar las base para el diseño
• Facilitar la verificación del cumplimiento de los
  objetivos del sistema

35
TÉCNICAS DE MODELADO (I)

• DESCOMPOSICIÓN. MODELO JERARQUIZADO, aplica el
  divide y vencerás, y así el problema queda
  dividido en un subconjunto de subproblemas. Se
  trata de una descomposición funcional que se
  denomina horizontal o bien se descompone tratando
  de detallar la estructura, de forma vertical.
  Para completar el modelado es necesario
  establecer los interfaces entre las partes del
  sistema para posibilitar el funcionamiento del
  sistema global.
• APROXIMACIONES SUCESIVAS, podemos tomar como
  partida el modelo de un sistema similar, y luego
  mediante la experiencia del analista y el
  conocimiento del problema que proporciona el
  experto se irán proponiendo modelos intermedios,
  discutiendo sus ventajas e inconvenientes.
• EMPLEO DE DIVERSAS ANOTACIONES, el lenguaje
  natural introduce imprecisiones, repeticiones e
  incluso incorrecciones en el modelo. Es
  recomendable emplear notaciones gráficas que sean
  entendibles por todos los que participan en el
  proyecto. Se suele recurrir a notaciones precisas
  que combinan texto, tablas, diagramas y gráficos.

36
TÉCNICAS DE MODELADO (II)

• CONSIDERAR DISITNTOS PUNTOS DE VISTA, en la
  elaboración del modelo es necesario adoptar un
  determinado punto de vista. Si así la descripción
  es insuficiente conviene adoptar más de uno.
• REALIZAR UN ANÁLISIS DEL DOMINIO, es decir en
  campo de aplicación en que se enmarca el sistema
  a desarrollar. Hay que considerar
• Normativa que afecta al sistema
• Otros sistemas semejantes
• Estudios recientes en el campo de la aplicación,
  bibliografía, etc.
• Las ventajas de realizar un modelos más general
  son
• Facilitar la comunicación entre el analista y el
  usuario del sistema, p.e. usando la misma
  terminología.
• Creación de elementos realmente significativos
  del sistema, si se ajusta a la normativa
  específica establecida.
• Reutilización posterior del software desarrollado.

37
ANÁLISIS DE REQUISITOS DE SOFTWARE

• El análisis es la fase de definición del futuro
  sistema y tiene una importancia decisiva en el
  desarrollo de todas las etapas posteriores.
• Con el análisis de requisitos se trata de
  caracterizar el problema a resolver. El cliente
  trabaja con el analista para elaborar las
  especificaciones y posteriormente se encargarán
  de verificar el cumplimiento de las mismas
  (contrato).
• El análisis debe producir un modelo válido
  necesario y suficiente para recoger todas las
  necesidades y exigencias del sistema, así como
  las restricciones que los limiten. Para una
  especificación correcta se requiere
• Completo y sin omisiones
• Conciso y sin trivialidades
• Sin ambigüedades
• Sin detalles de diseño o implementación
• Fácilmente entendible por el cliente
• Separando requisitos funcionales u no funcionales
  (capacidades mínimas y máximas, interfaces
  estándares, recursos necesarios, seguridad,
  fiabilidad, mantenimiento, etc.
• División y jerarquía del modelo global, con el
  fin de simplificar su comprensión
• Incluyendo los criterios de validación del
  sistema, para comprobar si se ajusta al contrato
  inicial.

38
TAREAS DEL ANÁLISIS

• Dependiendo de las características y complejidad
  del sistema se podrán seguir los siguientes
  pasos
• ESTUDIO DEL SISTEMA EN SU CONTEXTO, análisis del
  dominio en un contexto globalizador
• IDENTIFICACIÓN DE NECESIDADES, detectar
  necesidades de medios dentro de plazos y
  presupuestos
• ANÁLISIS DE ALTERNATIVAS Y ESTUDIO DE VIABILIDAD,
  tanto técnica como económica
• ESTABLECIMIENTO DEL MODELO DEL SISTEMA, para lo
  que podemos usar técnicas gráficas, texto,
  herramientas CASE, etc.
• ELABORACIÓN DEL DOCUMENTO DE ESPECIFICACIÓN DE
  REQUISITOS, dónde se recogen las conclusiones del
  análisis y sirve de punto de partida para el
  diseñador.
• REVISIÓN CONTINUADA DEL ANÁLISIS, a menudo en las
  etapas de diseño e implementación se hace
  necesaria la revisión de alguno de los
  requisitos, o bien por cambios de criterio del
  cliente

39
NOTACIONES PARA LA ESPECIFICACIÓN

• La especificación es una descripción del modelo
  del sistema a desarrollar.
• Se debe usar una notación fácil de entender por
  el cliente
• Lenguaje natural, utilizando explicaciones más o
  menos precisas y exhaustivas. Es posible limitar
  precisiones y ambigüedades si se establecen
  reglas de uso del lenguaje.
• Diagramas de flujo de datos
• Diagramas de transición de estados
• Descripciones funcionales. Pseudocódigo. Se
  emplea un preciso lenguaje natural estructurado.
  No se debe detallar demasiado el cómo, pues esto
  corresponde a la fase de diseño, donde se usan
  lenguajes estructurados como PLD.
• Descripción de datos, de trata de detallar la
  estructura interna de los datos que maneja el
  sistema. En la metodología Yourdon se conoce como
  diccionario de datos, incluyendo nombre de cada
  dato, utilización y estructura.
• Diagramas de modelos de datos

40
DIAGRAMAS DE FLUJO DE DATOS (DFD)

• Se trata de realizar un modelo gráfico para
  representar el flujo de datos que entra en el
  sistema, las transformaciones que debe realizar y
  la salida producida. También se representan las
  entidades externas la sistema que producen o
  consumen datos. El DFD inicial es el de contexto,
  posteriormente y de forma jerárquica se van
  desarrollando otros DFDs que detallan las
  transformaciones, las entradas y salidas del
  diagrama detallado deben coincidir con el proceso
  correspondiente.
• Recoge de forma estática los procesos, dónde en
  el último nivel de refinamiento se especifican en
  lenguaje natural estructurado, y su interrelación.

41
DIAGRAMAS DE TRANSICIÓN DE ESTADOS

• Describe el comportamiento dinámico del sistema
  basándose en sus estados más importantes.
• Al igual que en los autómatas de estados finitos,
  los eventos motiva el cambio de estado del
  sistema.

42
DIAGRAMAS DE MODELO DE DATOS

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

43
DOC. DE ESPECIFICACIÓN DE REQUISITOS

• El documento o la especificación de requisitos
  (SRD o SRS) recoge de forma integral los
  resultados del análisis.
• Puede haber documentos previos al SRD, como
  estudios de viabilidad o de alternativas
  posibles.
• El SRD debe ser revisado con cierta frecuencia
  durante el desarrollo y debe facilitar la
  varificación de las especificaciones (contrato).
• Diversos organismos de estandarización hacen
  propuestas sobre la estructura del SRD IEEE,
  DoD, etc. Vemos el modelo de SRD de la Agencia
  Espacial Europea. Dependiendo de las
  características y complejidad del proceso tal vez
  no sea necesario cubrir todos los apartados.

44
MODELO DE SRD

• Introducción
• Objetivo objetivos, participantes,
  calendario,...
• Ámbito, identificará y dará nombre al producto
• Definiciones, siglas y abreviaturas
• Referencias, la descripción bibliográfica de los
  documentos referenciados.
• Panorámica del documento
• Descripción general
• Relación con otros proyectos, similares o
  complementarios
• Relación con proyectos anteriores o posteriores
• Objetivo y funciones
• Consideraciones de entorno
• Relaciones con otros sistemas, que utilicen
  entradas o salidas indirectas de información
• Restricciones generales metodologías,
  lenguajes, de hardware,...
• Descripción del modelo, es el apartado más
  extenso y más importante. Se utilizan todas las
  notaciones y herramientas disponibles

45
MODELO DE SRD

• Requisitos específicos, lista detallada y
  completa de los requisitos del sistema, indicando
  su grado de cumplimiento (obligatorio,
  recomendable, opcional. No incluir aspectos de
  diseño o desarrollo, ni tampoco soluciones
  particulares que no sean obligadas
• Requisitos específicos, QUÉ debe hacer el
  sistema especificando el tratamiento de la
  información.
• Requisitos de interfase, conexión con otros
  sistemas con los que interactúa (bases de datos,
  ficheros, SSOO,...).
• Requisitos de operación, es decir, del interfaz
  de usuario
• Requisitos de capacidad, volumen procesador,
  tiempo respuesta, tamaño ficheros. Se debe
  cuantificar para el peor, el mejor y el caso más
  habitual.
• Requisitos de verificación, que debe cumplir el
  sistema para que se posible verificar su
  corrección
• Requisitos de pruebas de aceptación
• Requisitos de recursos, instalaciones y
  elementos necesarios para el funcionamiento del
  sistema
• Requisitos de documentación
• Requisitos de transportabilidad, para adaptalo a
  otras plataformas
• Requisitos de calidad, que no hayan sido
  recogidos en otros apartados
• Requisitos de fiabilidad, imponiendo un límite
  aceptable de fallos
• Requisitos de mantenibilidad
• Requisitos de seguridad, contra utilización
  indebida
• Requisitos de salvaguarda, para evitar
  consecuencias graves en equipos o en personas
• APENDICES, para complementar el contenido del
  documento

46
VIDEOJUEGO DE LAS MINAS
47
SISTEMA DE GESTIÓN DE BIBLIOTECA
48
SISTEMA DE GESTIÓN DE BIBLIOTECA
49
SISTEMA DE GESTIÓN DE BIBLIOTECA
50
SISTEMA DE GESTIÓN DE BIBLIOTECA
51
SISTEMA DE GESTIÓN DE BIBLIOTECA
52
Tema 3 FUNDAMENTOS DEL DISEÑO DEL SOFTWARE
53
CONCEPTO DE DISEÑO

• Descripción o bosquejo de alguna cosa hecho por
  palabras.
• En un sistema software la realización del diseño
  parte del SRD y no es nada trivial. Cuando no se
  tiene experiencia en el desarrollo concreto se
  hace de forma iterativa mediante ensayo y error,
  en caso contrario se aprovecha el know-how
  (saber hacer).
• Las técnicas para realizar diseños nuevos son
  empíricas y no están suficientemente
  formalizadas, mientras que para proyectos ya
  conocidos, como los de gestión, existen
  herramientas tales como lenguajes de 4ª
  generación.
• En el diseño se establece el CÓMO debe funcionar
  el sistema, determinando la organización y la
  estructura del software.

54
ACTIVIDADES DE UN DISEÑO SISTEMÁTICO

• DISEÑO ARQUITECTÓNICO, se abordan los aspectos
  estructurales y de organización del sistema, y su
  posible división en subsistemas
• DISEÑO DETALLADO, organización y estructura de
  los módulos
• DISEÑO PROCEDIMENTAL, organización de las
  operaciones o servicios que ofrecerá cada módulo.
  Se suele realizar en pseudocódigo o PDL, pero
  desarrollando sólo los aspectos más relevantes
  del algoritmo
• DISEÑO DE DATOS, organización de la base d edatos
  del sistema. Se parte de los diagramas E-R.
• DISEÑO DE LA INTERFAZ DE USUARIO, organizar y
  facilitar la utilización del sistema por parte
  del usuario
• El resultado de estas actividades debe plasmarse
  en el Documento d Diseño Software (SDD)

55
CONCEPTOS PARA EL DISEÑO

• ABSTACCIÓN, identificar los elementos
  significativos del sistema y abstraer la utilidad
  específica de cada uno
• ABSTRACCIONES FUNCIONALES, sirven para crear
  expresiones parametrizadas usando funciones o
  procedimientos
• TIPOS ABSTRACTOS, junto con el tipo de datos se
  deben crear los métodos que manejan estos datos
• MÁQUINAS ABSTRACTAS, definición formal del
  comportamiento de una máquina
• MODULARIDAD, el diseño modular propone dividir el
  sistema en partes diferenciadas y definir sus
  interfaces. Sus ventajas claridad, reducción de
  costos y reutilización
• REFINAMIENTO, a partir de una idea no muy
  concreta se va refinando mediante aproximaciones
  hasta el detalle
• ESTRUCTURAS DE DATOS, para organizar la
  información que maneja el sistema registros,
  conjuntos, listas, pilas, colas, árboles, grafos,
  tablas, ficheros, ...
• OCULTACIÓN, de la organización de los datos
  internos y de los detalles del algoritmo, se
  muestra en el interfaz sólo aquello que resultará
  invariable ante cambios. Ventajas depuración,
  mantenimiento, ...
• GENERICIDAD, consiste en diseñar un elemento
  genérico, con las características comunes a todos
  los elementos agrupados
• HERENCIA, los elementos hijos heredan del padre
  su estructura y operaciones para ampliarlos,
  mejorarlos o adaptarlos. Es conveniente utilizar
  un lenguaje de programación orientado a objetos
• POLIMORFISMO, es la propiedad de los elementos
  que pueden variar su formar sin cambiar su
  naturaleza. Se emplea el concepto de genericidad.
  En los hijos se puede producir la anulación de
  una operación. A veces en el padre interesa
  declarar un método sin implementarlo, lo harán
  los hijos en diferido
• CONCURRENCIA, se trata de aprovechar al máximo el
  procesador garantizando unos tiempos máximos de
  respuesta para tareas críticas. Problemas de los
  sistemas con restricciones
• Tareas concurrentes, asegurar que todas cumplen
  sus restricciones
• Sincronización de tareas, determinando los puntos
  de sincronización entre ellas
• Comunicación entre tareas, unas serán productoras
  de datos y otras consumidoras. Para evitar la
  corrupción de datos compartidos permitir sólo
  concurrencia en lectura con semáforos, monitores
  y regiones críticas
• Interbloqueos (deadlock) cuando varias tareas
  esperan un evento que nunca se producirá

56
NOTACIONES PARA EL DISEÑO

• Debe resultar precisa, clara y fácil de
  interpretar. Se emplean notaciones formales
  cuasimatemáticas
• NOTACIONES ESTRUCTURALES, se desglosa y
  estructura el sistema en sus partes
• DIAGRAMAS DE BLOQUES
• CAJAS ADOSADAS

57
DIAGRAMAS DE ESTRUCTURA (Yourdon)
Describen la estructura de los sistemas software
como una jerarquía de módulos, reflejando sólo su
organización estática
RECTÁNGULO, módulo LÍNEA, relación entre
módulos, el superior utiliza el módulo
inferior ROMBO, opcional ARCO, repetitiva CIRCULO
CON FLECHA, envio de datos o información de
control (correcto, repetir, desconectar, etc)
58
DIAGRAMAS HIPO (Hierachy-Input-Process-Output)
Se muestra primero la jerarquía entre los módulos
del sistema
Y en los diagramas HIPO de detalle hay 3 zonas
Entrada, Proceso y Salida
59
DIAGRAMAS DE JACKSON

• El proceso de diseño es sistemático y se lleva a
  cabo en tres pasos
• Especificación de la estructura de datos de
  entrada y de salida
• Obtención de la estructura del programa
• Expansión de la estructura del programa para
  lograr el diseño detallado

60
NOTACIONES ESTÁTICAS

• Describen las características estáticas del
  sistema, tales como la organización de la
  información, sin tener en cuenta su evolución
  durante el funcionamiento del sistema.
• Las notaciones son las mismas que se emplean en
  la especificación
• DICCIONARIO DE DATOS, dónde se detalla la
  estructura interna de los datos que maneja el
  sistema. En el diseño se amplía y se completa el
  diccionario de la especificación hasta el nivel
  de detalle necesario para iniciar la
  codificación.
• DIAGRAMAS ENTIDAD-RELACIÓN, definiendo las
  relaciones entre datos y la organización de la
  información. Se amplia y detalla el diagrama de
  la especificación con las nuevas entidades y
  relaciones.

61
NOTACIONES DINÁMICAS

• Permiten describir el funcionamiento del sistema
  durante su funcionamiento.
• Las notaciones son las misma utilizadas en la
  especificación
• DIAGRAMAS DE FLUJO DE DATOS, serán mucho más
  exhaustivos que los de la especificación.
• DIAGRAMAS DE TRANSICIÓN DE ESTADOS, más
  detallados que reflejen las transiciones entre
  estados internos.
• LENGUAJE DE DESCRIPCIÓN DE PROGRAMAS (PLD),
  permite realizar la especificación funcional del
  sistema.

62
NOTACIONES HIBRIDAS DIAGRAMAS DE ABSTRACCIONES
Permiten un enfoque globalizado del diseño
atendiendo a aspectos estáticos (datos),
dinámicos (operaciones) y de estructura del
sistema.
DIAGRAMAS DE ABSTRACCIONES, se contemplan dos
tipos de abstracciones las funciones y los tipos
abstractos de datos. En una abstracción se
distinguen 3 partes NOMBRE, es su
identificador CONTENIDO, dónde se define la
organización de los datos OPERACIONES, para
manejar el contenido de la abstracción Las
abstracciones funcionales (funciones o
procedimientos), sólo tiene la parte de
operación. El dato encapsulado tiene como el tipo
abstracto contenido y operaciones, pero no
permite declarar otras variables de su mismo tipo.
En los diagramas se muestra la relación
jerárquica entre abstracciones, de manera que la
abstracción superior utiliza la inferior.
63
NOTACIONES HIBRIDAS DIAGRAMAS DE OBJETOS

• Se emplea una terminología distinta, pero las
  similitudes con los diagramas de abstracciones es
  muy grande, excepto que
• No existe nada equivalente a los datos
  encapsulados ni a las abstracciones funcionales
  en el modelo de objetos
• En los diagramas de objetos hay relaciones de
  herencia

• De acuerdo con las propiedades de los objetos
  podemos tener relaciones especiales entre ellos
• CLASIFICACIÓN, ESPECIALIZACIÓN O HERENCIA

• COMPOSICIÓN, permite describir un objeto mediante
  los elementos que lo forman

64
DOCUMENTOS DE DISEÑO ADD

• 1. INTRODUCCIÓN Para dar una visión general de
  todo el documento. Los contenidos de los
  apartados como en el SRD
• 1.1 Objetivo ...
• 1.2 Ámbito
• 1.3 Definiciones, siglas y abreviaturas
• 1.4 Referencias
• 2. PANORÁMICA DEL SISTEMA, visión general de los
  requisitos funcionales y de otro tipo del sistema
  a diseñar
• 3. CONTEXTO DEL SISTEMA, si posee conexiones con
  otros
• 3.n Definición de interfaz externa
• 4. DISEÑO DEL SISTEMA, se describe el nivel
  superior del diseño del sistema
• 4.1 Metodología de diseño de alto nivel
• 4.2 Descomposición del sistema , primer nivel de
  descomposición del sistema en sus componentes
  principales
• 5. DISEÑO DE LOS COMPONENTES, se procede a la
  decripción detallada de l,os componentes
  mencionados en 4.2
• 5.n Identificador del componente
• 5.n.l Tipo (subprograma, módulo, procedimiento,
  proceso, datos
• 5.n.2 Objetivo, o necesidad de que exista el
  componente
• 5.n.3 Función , lo que hace el componente
• 5.n.4 Subordinados, se enumeran todos los
  componentes que utiliza
• 5.n.5 Dependencias y su naturaleza invocación de
  operación, datos compartidos, inicialización,
  creación, etc.
• 5.n.6 Interfases, de cómo otros componentes
  interactúan con éste

65
DOCUMENTOS DE DISEÑO DDD

• Parte 1. DESCRIPCIÓN GENERAL
• 1. INTRODUCCIÓN
• 1.1 Objetivo
• 1.2 Ámbito
• 1.3 Definiciones, siglas y abreviaturas
• 1.4 Referencias
• 1.5 Panorámica
• 2. NORMAS, CONVENIOS y PROCEDIMIENTOS
• 2.1 Normas de diseño de bajo nivel
• 2.2 Normas y convenios de documentación
• 2.3 Convenios de nombres (ficheros, programas,
  módulos, etc.)
• 2.4 Normas de programación
• 2.5 Herramientas de desarrollo de software
• Parte 2. ESPECIFICACIONES DE DISEÑO DETALLADO
• n. Identificador del componente
• n.l Identificador
• n.2 Tipo
• n.3 Objetivo
• n.4 Función

66
Tema 4 TÉCNICAS GENERALES DE DISEÑO SOFTWARE
67
TÉCNICAS DE DISEÑO

• Los objetivos de las técnicas de diseño software
  son fundamentalmente
• La descomposición modular del sistema
• Los diseños de los algoritmos y estructuras de
  datos fundamentales que se deben usar en el
  sistema
• Primero veremos las características deseables de
  una buena descomposición modular del sistema, y
  luego se presentarán técnicas de diseño
• Diseño funcional descendente
• Diseño orientado a objetos
• Diseño de datos

68
DESCOMPOSICIÓN MODULAR

• Los pasos a seguir son
• Identificar los módulos
• Describir cada módulo
• Describir las relaciones entre módulos
• Tipos de módulos
• Código fuente, en el lenguaje de programación
  usado
• Tabla de datos, para datos de inicialización u
  otros
• Configuración, se agrupa en un módulo toda la
  información de configuración en el entorno de
  trabajo
• Otros ficheros de ayuda en línea, manuales, etc.
• Una descomposición modular debe poseer ciertas
  cualidades mínimas para que se pueda considerar
  suficientemente válida
• Independencia fucional
• Acoplamiento
• Cohesión
• Comprensibilidad
• Adaptabilidad

69
DESCOMPOSICIÓN MODULAR INDEPENDENCIA FUNCIONAL

• Al final de los documentos ADD y DDD debe haber
  una matriz REQUISITOS/COMPONNETES. En principio,
  cada función será realizada en un módulo
  distinto. Si las funciones son independientes los
  módulos tendrán independencia funcional.
• Cada módulo debe realizar una función concreta o
  un conjunto de funciones afines. Es recomendable
  reducir las relaciones entre módulos al mínimo.
• Para medir la independencia funcional hay dos
  criterios acoplamiento y cohesión.

DESCOMPOSICIÓN MODULAR ACOPLAMIENTO

• El grado de acoplamiento mide la interrelación
  entre dos módulos, según el tipo de conexión y la
  complejidad de la interfase
• FUERTE,
• POR CONTENIDO, cuando desde un módulo se pueden
  cambiar datos locales de otro
• COMÚN, se emplea una zona común de datos a la que
  tienen acceso varios módulos
• MODERADO,
• DE CONTROL, la zona común es un dispositivo
  externo al que están ligados los módulos, esto
  implica que un cambio en el formato de datos
  afecta a todos estos módulos
• POR ETIQUETA, en ontercambio de datos se realiza
  mediante una referencia a la estructura completa
  de datos (vector, pila, árbol, grafo, ...)
• DÉBIL,
• DE DATOS, viene dado por los datos que
  intercambian los módulos. Es el mejor posible
• SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que
  no existe

70
DESCOMPOSICIÓN MODULAR COHESIÓN

• Es necesario lograr que el contenido de cada
  módulo tenga la máxima coherencia. Para que el nº
  de módulos no sea demasiado elevado y complique
  el diseño se tratan de agrupar elementos afines y
  relacionados en un mismo módulo.
• ALTA
• COHESIÓN ABSTRACCIONAL, se logra cuando se diseña
  el módulo como tipo abstracto de datos o como una
  clase de objetos
• COHESIÓN FUNCIONAL, el módulo realiza una función
  concreta y específica
• MEDIA
• COHESIÓN SECUENCIAL, los elementos del módulo
  trabajan de forma secuencial
• COHESIÓN DE COMUNICACIÓN, elementos que operan
  con le mismo conjunto de datos de entrada o de
  salida
• COHESIÓN TEMPORAL, se agrupan elementos que se
  ejecutan en el mismo momento. Ej. Arrancar o
  parar dispositivos
• BAJA
• COHESIÓN LÓGICA, se agrupan elementos que
  realizan funciones similares. Ejs. módulos de
  E/S o de tratamiento de errores
• COHESIÓN COINCIDENTAL, es la peor y se produce
  cuando los elementos de un módulo no guardan
  relación alguna
• La descripción del comportamiento de un módulo
  permite establecer el grado de cohesión
• Si es una frase compuesta y contiene más de un
  verbo la cohesión será MEDIA
• Si contiene expresiones secuenciales (primero,
  entonces, cuando...), será temporal o secuencial
• Si la descripción no se refiere a algo específico
  (Ej. Todos los errores), cohesión lógica
• Si aparece inicializar, preparar,
  configurar, probablemente sea temporal.

71
DESCOMPOSICIÓN MODULAR COMPRENSIBILIDAD

• Para facilitar los cambios, el mantenimiento y la
  reutilización de módulos es necesario que cada
  uno sea comprensible de forma aislada. Para ello
  es bueno que posea independencia funcional, pero
  además es deseable
• IDENTIFICACIÓN, el nombre debe ser adecuado y
  descriptivo
• DOCUMENTACIÓN, debe aclarar todos los detalles de
  diseño e implementación que no queden de
  manifiesto en el propio código
• SIMPLICIDAD, las soluciones sencillas son siempre
  las mejores

DESCOMPOSICIÓN MODULAR ADAPTABILIDAD

• La adaptación de un sistema resulta más dificil
  cuando no hay independencia funcional, es decir,
  con alto acoplamiento y baja cohesión, y cuando
  el diseño es poco comprensible. Otros factores
  para facilitar la adaptabilidad
• PREVISIÓN, es necesario prever que aspectos del
  sistema pueden ser susceptibles de cambios en el
  futuro, y poner estos elementos en módulos
  independientes, de manera que su modificación
  afecte al menor número de módulos posible
• ACCESIBILIDAD, debe resultar sencillo el acceso a
  los documentos de especificación, diseño, e
  implementación para obtener un conocimiento
  suficiente del sistema antes de proceder a su
  adaptación
• CONSISTENCIA, después de cualquier adaptación se
  debe mantener la consistencia del sistema,
  incluidos los documentos afectados

72
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE

• La descomposición del sistema se hace desde un
  punto de vista funcional.
• Desde el punto de vista de la codificación, cada
  módulo corresponde esencialmente a un subprograma.

TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE
DESARROLLO POR REFINAMIENTO PROGRESIVO

• Esta técnica consiste en la aplicación de la fase
  de diseño de la programación estructurada. Las
  estructuras básicas son la secuencia, la
  selección entre alternativas y la iteración.
• Cada paso en la descomposición consiste en
  refinar o detallar una parte del programa global
  u operación, que a su vez podrá ser descompuesta
  en otras operaciones. Los refinamientos se basan
  en la aplicación de estructuras de control en el
  programa. Veamos como ejemplo obtener las raíces
  de una ec. de 2º grado
• Obtener raíces -gt
• Leer coeficientes
• Resolver ecuación --gt
• Calcular discriminante
• Calcular raíces --gt
• SI el discriminante es negativo ENTONCES
• Calcular raíces complejas
• SI-NO
• Calcular raíces reales
• FIN-SI
• Imprimir raíces

73
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE
PROGRAMACIÓN ESTRUCTURADA DE JACKSON

• Esta técnica sigue las ideas de la programación
  estructurada (secuencia, selección, iteración) y
  el método de refinamientos sucesivos pàra
  construir la estructura del programa en forma
  descendente.
• Se recomienda construir la estructura del
  programa de forma similar a las estructuras de
  datos de entrada y de salida
• Pasos de la técnica JSP
• Analizar el entorno del problema y describir las
  estructuras de datos a procesar
• Construir la estructura del programa basándose en
  las estructuras de datos
• Definir las tareas a realizar en cada módulo de
  la estructura del programa
• Este tercer paso corresponde en su detalle a la
  fase de codificación
• Ej. Programa para justificar el texto, es decir,
  reagrupar las palabras en líneas e intercalar los
  espacios adecuados para que se ajusten a los
  márgenes
• PASO 1. Las estructuras de datos que reconocemos
  son
• Texto de entrada separador de párrafo
  palabra
• Texto de salida línea ajustada línea final
  línea en blanco

74
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE
PROGRAMACIÓN ESTRUCTURADA DE JACKSON

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

75
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE DISEÑO
ESTRUCTURADO

• Según esta técnica, la tarea de diseño consiste
  en pasar de los DFDs a los diagramas de
  estructura.
• Hay que establecer una jerarquía o estructura de
  control entre los diferentes módulos, que no está
  implícita en el modelo funcional descrito en los
  DFDs
• Para dos módulos relacionados en el DFD (A)
  tenemos 3 posibilidades de organización modular
  diferentes.

76
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE DISEÑO
ESTRUCTURADO

• Para establecer la jerarquía de control entre
  módulos se recomienda hacer ciertos análisis en
  el flujo de datos de flujo de transformación y
  de flujo de transacción. Para ello es
  recomendable construir un DFD con todos los
  procesos contenidos en los primeros niveles
  prescindiendo de los almacenes.

El análisis de flujo de transformación consiste
en identificar un flujo global de información
desde los elementos de entrada hasta los de
salida. Los procesos se agrupan en 23 regiones
flujo de entrada, de transformación y de salida.
77
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE DISEÑO
ESTRUCTURADO
El flujo de transacción es aplicable cuando el
flujo de datos se puede descomponer en varias
líneas separadas. El análisis consiste en
identificar el centro de transacción a partir del
cual se ramifican las líneas de flujo a las
regiones correspondientes a cada una de las
transacciones
78
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE DISEÑO
ESTRUCTURADO. EJ. GESTIÓN DE BIBLIOTECA
79
TÉCNICAS DE DISEÑO BASADO EN ABSTRACCIONES

• La idea es que los módulos corresponden a
  funciones o a tipos abstractos de datos.
• Los lenguajes que dan más facilidades para la
  implementación son los orientados a objetos

TÉCNICAS DE DISEÑO BASADO EN ABSTRACCIONES
DESCOMPOSICIÓN MODULAR BASADA EN ABSTRACCIONES

• Se trata de ampliar el lenguaje de programación
  con nuevas operaciones y tipos de datos definidos
  por el usuario, de forma que se simplifique la
  escritura de los niveles superiores del programa,
  basándose en módulos que realicen estas
  operaciones
• Podemos identificar los tipos abstractos
  correspondientes a un número
• complejo y a una ecuación de 2 grado y definir
  sobre dichos tipos abstractos las siguientes
  operaciones
• Ecuación de 2 grado Número complejo
• Leer ecuación Escribir
• Escribir ecuación Sumar, Restar,
  etc..
• Obtener raíces Raíz cuadrada
• La estructura modular del programa sería

80
TÉCNICAS DE DISEÑO BASADO EN ABSTRACCIONES
MÉTODO DE ABBOTT

• A partir de la descripción o especificación de
  los módulos es posible identificar las palabras o
  términos que puedan corresponder a elementos
  significativos del diseño
• Tipos de datos, que aparecen como sustantivos
  genéricos
• Atributos, son sustantivos en general
• Operaciones, tienen la forma de verbos o nombres
  de acciones
• Se subrayan en la descripción las palabras
  significativas haciendo una lista de nombres y
  otra de verbos u operaciones. Hay que eliminar
  los términos irrelevantes o los sinónimos de
  palabras ya aparecidas

DATO Atributos Operaciones
Palabra Caracteres Imprimir
Párrafo Separador Línea salida Iniciar párrafo Poner palabra Terminar párrafo
Separador de párrafo Líneas en blanco Sangrado
Línea Sangrado Palabras Iniciar línea cabe palabra? Poner palabra Imprimir sin ajustar Imprimir ajustada
81
TÉCNICAS DE DISEÑO ORIENTADAS A OBJETOS

• Es esencialmente igual al diseño basado en
  abstracciones, añadiendo la herencia y el
  polimorfismo.
• En la descomposición modular del sistema cada
  módulo contiene la descripción de una clase de
  objetos o de varias clases relacionadas entre sí.
  
• PASOS
• Estudiar y comprender el problema a resolver
• Desarrollar en líneas generales uan posible
  solución, al menos informal
• Formalizar dicha estrategía en términos de
  clases, objetos y sus relaciones
• Identificar los objetos, sus atributos y sus
  componentes
• Identificar las operaciones sobre los objetos y
  asociarlas a la clase adecuada
• Aplicar herencia donde convenga
• Describir cada operación en función de las otras,
  y subsanar posibles omisiones
• Asignar clases y objetos a los módulos del
  sistema

82
TÉCNICAS DE DISEÑO DE DATOS

• Muchas aplicaciones necesitan almacenar
  información de forma permanente y la mejor forma
  de hacerlo es crear una base de datos subyacente
• Podemos enfocar la organización de la base de
  datos de 3 formas
• Nivel externo Esquemas de usuario
• Nivel conceptual Esquemas lógicos
• Nivel interno Esquemas físicos
• El nivel externo corresponde a la visión del
  usuario, en la fase de análisis de pasa al nivel
  conceptual, que establece la organización de los
  datos, y finalmente en la etapa de diseño se pasa
  al nivel interno.
• DISEÑO DE BASES DE DATOS RELACIONALES, en este
  modelo la eficiencia se basa en
• Las FORMAS NORMALES, que tienden a evitar las
  redundancias en los datos almacenados
• FN1, la información asociada a cada columna de la
  tabla es un único valor, y no una colección
• FN2, si hay una clave primaria que distingue e
  identifica cada fila, el resto de los datos
  dependen de toda la clave primaria
• FN3, el valor de cada columna que no es clave
  primaria depende directamente de la clave
  primaria. Se puede conseguir si se separan las
  tablas.
• Los INDICES, que mejoran la velocidad de acceso a
  los datos

83
TÉCNICAS DE DISEÑO DE DATOS DISEÑO DE LAS
ENTIDADES

• En el modelo relacional cada entidad del modelo
  E-R se traduce en una tabla por cada clase de
  entidad, con una fila por cada elemento de esa
  clase y una columna por cada atributo de esa
  entidad.
• Entre las entidades relacionadas se puede incluir
  una columna con un número de referencia o
  identificador que las relaciona, sirve como clave
  primaria.
• En el modelo E-R todas las relaciones se
  consideran de asociación, y la manera de
  trasladar esto a las tablas depende de la
  cardinalidad de la relación. La relación se
  convierte en una tabla que contiene referencias a
  las tablas de las entidades relacionadas, así
  como los atributos de la relación (cale para
  cualquier cardinalidad, incluso NN). Si es 1N
  es posible incluir los datos de la relación en la
  tabla con cardinalidad 1. Si la cardinalidad es
  11 se pueden fundir las tablas de las dos
  entidades.

84
TÉCNICAS DE DISEÑO DE DATOS COMPOSICIÓN Y
HERENCIA

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

85
Tema 5 CODIFICACIÓN Y PRUEBAS
86
CODIFICACIÓN DEL DISEÑO

• Nos vamos a referir a las últimas fases del ciclo
  de vida codificación, pruebas de unidades,
  integración y pruebas de sistema.
• Cuando alguna de las pruebas no resulta positiva
  es necesario repetir la codificación o la
  integración y probar de nuevo.
• La fase de codificación constituye el núcleo
  central en cualquiera de los modelos y tiene una
  importancia fundamental ya que elabora los
  programas fuente.
• Previamente a la codificación es necesario elegir
  el lenguaje que se empleará así como la
  metodología de programación. También se pueden
  establecer en el equipo unas normas y un estilo
  de programación común, lo que mejorará la
  coordinación y facilitará el trabajo. Además se
  consigue facilitar el mantenimiento y mejorar la
  reusabilidad del software.
• Cuando el resultado de las pruebas no sea
  satisfactorio será necesario modificar el código,
  lo que podrá introducir nuevos errores. Si la
  programación es estructurada será más fácil
  localizar la disfunción y la posterior
  modificación y las pruebas del código, dónde
  podemos introducir puntos de test.

87
LENGUAJES DE PROGRAMACIÓN

• Aunque los lenguajes han evolucionado mucho desde
  los años 50 todavía están más próximos a la
  máquina que al pensamiento humano. Los lenguajes
  suelen adoptar los avances metodológicos que se
  producen en el desarrollo del software. Ej. C y
  C
• DESARROLLO HISTÓRICO, muchos han sido
  desarrollados con fines experimentales y muy
  pocos han llegado a ser utilizados
  industrialmente
• 1ª GENERACIÓN muy próximos al lenguaje máquina
• Ensamblador, asocia a cada instrucción de la
  máquina un nemónico
• 2ª GENERACIÓN no dependen de la CPU, se programa
  de manera simbólica, en alto nivel.
• FORTRAN (FORula TRANslator), para aplicaciones
  científicas
• COBOL, para procesamiento de información. Supone
  el 70
• ALGOL, da gran importancia a la tipificación de
  datos