1
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
2
Tema 1: INTRODUCCIÓN
3
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.
4
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.
5
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.
6
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
7
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.
8
MODELO EN CASCADA
9
MODELO EN CASCADA
ANÁLISIS, determinar qué debe hacer el software -> 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ón`para evitar que los errores se propaguen a fases posteriores provocando la vuelta atrás.
10
MODELO EN CASCADA AMPLIADO
11
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
12
MODELO EN V
13
MODELO EN V AMPLIADO
14
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.
15
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
16
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.
17
PROTOTIPOS RÁPIDOS
18
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.
19
PROTOTIPOS EVOLUTIVOS
20
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.
21
MODELO EN ESPIRAL
22
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
23
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.
24
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
25
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
26
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
27
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.
28
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).
29
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.
30
Tema 2: ESPECIFICACIÓN DE SOFTWARE
31
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.
32
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
33
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.
34
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.
35
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.
36
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
37
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
38
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 DFD’s 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.
39
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.
40
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.
41
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.
42
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
43
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
44
VIDEOJUEGO DE LAS MINAS
45
SISTEMA DE GESTIÓN DE BIBLIOTECA
46
SISTEMA DE GESTIÓN DE BIBLIOTECA
47
SISTEMA DE GESTIÓN DE BIBLIOTECA
48
SISTEMA DE GESTIÓN DE BIBLIOTECA
49
SISTEMA DE GESTIÓN DE BIBLIOTECA
50
Tema 3: FUNDAMENTOS DEL DISEÑO DEL SOFTWARE
51
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.
52
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)
53
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á
54
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
55
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)
56
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
57
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
58
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.
59
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.
60
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.
61
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
62
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
5.n.7 Recursos , elementos usados por el componente
5.n.8 Referencias, que se han utilizado en el texto
5.n.9 Proceso, algoritmos o reglas que utiliza el componente para realizar su función
5.n.l0 Datos, descripción de los datos, su tipo, sus valores iniciales, se puede realizar con un diccionario de datos
6. VIABILIDAD y RECURSOS ESTIMADOS
7. MATRIZ REQUISITOS/COMPONENTES, se pone en las filas los requisitos y en las columnas los componentes
63
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
n.5 Subordinados
n.6 Dependencias
n.7 Interfases
n.8 Recursos
n.9 Referencias
n.l0 Proceso
n.ll Datos
APÉNDICE A. LISTADOS FUENTE
APÉNDICE E. MATRIZ REQUISITOS/COMPONENTES
64
Tema 4: TÉCNICAS GENERALES DE DISEÑO SOFTWARE
65
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
66
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
67
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
68
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.
69
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
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
DESCOMPOSICIÓN MODULAR: ADAPTABILIDAD
70
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 ->
Leer coeficientes
Resolver ecuación –>
Calcular discriminante
Calcular raíces –>
SI el discriminante es negativo ENTONCES
Calcular raíces complejas
SI-NO
Calcular raíces reales
FIN-SI
Imprimir raíces
71
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]}
72
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
73
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.
74
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.
75
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
76
TÉCNICAS DE DISEÑO FUNCIONAL DESCENDENTE: DISEÑO ESTRUCTURADO. EJ. GESTIÓN DE BIBLIOTECA
77
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
Página siguiente  |