Cap3 2en1

Parte I: El computador y el proceso de programacin
1.Introduccin a los computadores y su programacin 2. Introduccin al anlisis y diseo de algoritmos 3. Introduccin al anlisis y diseo de programas 4. Verificacin de programas
UNIVERSIDAD DE CANTABRIA
DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN 4
Michael Gonzlez Harbour 19/ma/09
Notas:
1. Introduccin a los computadores y su programacin
Arquitectura bsica de un computador.El software del sistema. Lenguajes de Alto Nivel. El proceso de compilacin. El ciclo de vida del software. 2. Introduccin al anlisis y diseo de algoritmos. Diseo de un programa. Concepto de algoritmo. Descripcin de algoritmos: el pseudolenguaje. Tiempo de ejecucin de algoritmos. La notacin O(n). Ejemplos de anlisis. 3. Introduccin al anlisis y diseo de programas Actividades del ciclo de vida del software. Paradigmas de desarrollo de programas. Anlisis y especificacin. Diseo arquitectnico. Tcnicas de diseo detallado. 4. Verificacin de programas Importancia de la verificacin. Estrategias de prueba. Depuracin. Eleccin de datos para la prueba.
DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN
1. Actividades del ciclo de vida del software

Anlisis y Especificacin Diseo de la Arquitectura Diseo Detallado Codificacin y Desarrollo Integracin y Verificacin o Prueba Operacin y Mantenimiento
Notas:
Anlisis y especificacin. En esta etapa se analiza la naturaleza del problema, y se establecen los requerimientos del sistema. En la especificacin se desarrollan las descripciones del sistema, de sus restricciones, y de los recursos necesarios. Diseo de la Arquitectura. A partir de las especificaciones funcionales, se disea la estructura del sistema que resuelve el problema. Esta estructura representa las partes importantes del sistema y sus relaciones, as como las estructuras de datos ms importantes. Diseo Detallado. Las partes importantes del sistema se disean en detalle, describiendo los algoritmos y estructuras de datos concretas. Se detallan las interfaces entre las diferentes partes. Las etapas de diseo suelen requerir varios niveles de refinamiento. Codificacin y Desarrollo. Produccin de una realizacin fsica del diseo. Integracin y Verificacin. Suelen ser fases cclicas, en las que de forma incremental se van probando e integrando las diversas partes del sistema. Operacin y Mantenimiento. Reparacin de problemas, adaptacin a nuevas condiciones, mejoras, etc.
Actividades en Cada Etapa

Etapa
Anlisis Especificacin
Entradas
Necesidades iniciales, contexto, problemas del usuario Requerimientos, contexto del sistema
Salidas
Definicin de requerimientos Especificaciones funcionales, diseo externo del sistema Definicin de mdulos e interfaces Descripcin de la estructura de los programas
Diseo de la Arqui- Especificaciones, contexto, tectura experiencia previa Diseo Detallado Descripcin de la arquitectura, detalles del entorno
Notas:
Anlisis:
Identificacin de las funciones ms importantes, recoleccin de informacin y de restricciones. Especificacin: Conversin de las necesidades en funciones explcitas, seleccin de las restricciones que son operativas, descripcin de las interfaces al usuario. Diseo de la Arquitectura: Determinar la estructura del problema, identificar las partes importantes del sistema, establecer las relaciones entre las partes, abstraccin, y descomposicin. Diseo Detallado: Abstraccin, elaboracin, seleccin de alternativas.
Actividades en Cada Etapa (cont.)

Etapa
Codificacin y Desarrollo
Entradas
Descripcin de la arquitectura, detalles del entorno
Salidas
Cdigo de unidades de programa y documentacin Cdigo del programa o programas completos, ficheros de datos, sistema completo Sistema mejorado
Integracin y Verifi- Descripcin de la arquitectura cacin y cdigo de las unidades de programa con su documentacin Operacin y Mantenimiento Documentacin del sistema, requerimientos de operacin, peticiones de cambios
Notas:
Codificacin y Desarrollo: Codificacin de algoritmos y estructuras de datos Integracin y Verificacin:
Depuracin y verificacin de unidades de programa y de prototipos del sistema global cada vez ms elaborados, hasta llegar al sistema completo Operacin y mantenimiento: Reprogramacin, mejora, depuracin del rediseo, etc.
Validacin Paso a Paso del Proceso

El usuario firma: Si las especificaciones se implementan, los requerimientos se alcanzarn Los encargados de la especificacin firman: Si el diseo se implementa, las especificaciones de satisfarn Los diseadores firman: Si el programa se escribe, el diseo quedar implementado
Requerimientos
Los analistas aceptan la descripcin de los requerimientos, que es clara y realizable
Especificaciones
Los diseadores firman: Las especificaciones estn claras y se pueden convertir en un diseo Los programadores firman: El diseo es claro y se puede convertir en cdigo
Diseo
Programa
Notas:
Cuando se trabaja en asociacin con otras personas para realizar un proyecto relativamente grande y utilizando tcnicas avanzadas, debe de existir una filosofa y metodologa de direccin que gue el proyecto, para su terminacin con xito. Este xito ser fuertemente dependiente de la calidad del proceso de direccin. El software desarrollado puede ser interno, para uso por el propio organismo que lo desarrolla, o externo, realizado para ser utilizado por otras personas. En ambos casos, las tcnicas de direccin empleadas deben de ser muy similares (aunque en muchas ocasiones en el desarrollo interno esta medida no se tenga en cuenta). Es importante, en ambos casos, tener presente todo el ciclo de vida, teniendo especial cuidado con los lmites entre las distintas fases. Cada uno de los lmites entre las fases de desarrollo deber estar claramente representado mediante un documento que deber establecer claramente lo que se ha realizado en la etapa precedente. Esto, junto con una revisin del diseo, ayudar a la evaluacin y validacin. En la figura se muestra el mtodo de validacin paso a paso del proceso de desarrollo. Al comienzo de cada etapa se documenta y se cierra la etapa anterior, de modo que se minimiza la cantidad de iteracin y de cambios estructurales.
10
Validacin por Comparacin con los Requerimientos

Requerimientos
Especificacin
Diseo
Programa
11
Notas:
En la figura se muestra el mtodo de validacin del programa por comparacin con los requerimientos. Este caso, en el que se utiliza el programa para realizar la validacin, llevar desafortunadamente a que cualquier error serio detectado en la validacin implique un costo muy elevado, al estar el programa ya muy avanzado.
12
Paradigmas del Proceso Software

Anlisis de Requerimientos Anlisis de la Especificacin Diseo de la Arquitectura Diseo Detallado Codificacin y Depuracin Pruebas e Integracin
Paradigma clsico (en cascada) del ciclo de vida del software:
Operacin y Mantenimiento
13
Notas:
El paradigma clsico constituye la herramienta actual ms potente para el desarrollo del software. Se basa en la secuencia de pasos lgicos que aparece en la figura, y que son optimizados a nivel individual, uno a uno. Actualmente se considera que este paradigma limita la calidad del proceso, por las siguientes razones: 1. Exige la toma de decisiones en fases iniciales, sin conocer su efecto en fases sucesivas 2. Considera que los requerimientos del programa estn definidos antes de que ste haya sido diseado. 3. Considera la especificacin del programa como algo previo y no interaccionante con el diseo. 4. Se basa en criterios tales como la experiencia del programador, y es difcil de automatizar 5. El paradigma hace muy difcil y costoso el proceso de mantenimiento del software. Sin embargo, el uso de un paradigma como este reporta muchos beneficios con respecto a un proceso desordenado, en el que no se siga una metodologa clara.
14
Objetivos de los Nuevos Paradigmas
Los nuevos paradigmas tratan de: Proporcionar a los usuarios un objeto ejecutable en las etapas iniciales del proceso Analizar y reducir el riesgo Automatizar la produccin del software Se pueden utilizar en combinacin con el paradigma clsico, o una combinacin de varios de ellos
15
Notas:
Objetivos de los nuevos paradigmas: 1. Automatizar el proceso de desarrollo del programa 2. Minimizar los errores cometidos en las etapas iniciales del desarrollo 3. Posibilitar que el usuario acte como analista 4. Analizar y reducir el riesgo 5. Eliminar las tareas rutinarias en las que se posibilite introducir errores 6. Incrementar la capacidad de optimizacin 7. Facilitar el mantenimiento 8. Mantener actualizada la especificacin
En la prctica, es habitual mezclar varios paradigmas, uno para cada una de las fases del proyecto, con objeto de obtener las mejores ventajas de cada uno. Por ejemplo, es habitual hacer las fases iniciales del proyecto segn la metodologa orientada a prototipo, y luego seguir con una metodologa clsica para llegar al programa final.
16
Paradigma Basado en Prototipo

Desarrollo del sistema final por evolucin del prototipo Determinar mbito y objetivos del prototipo Requerimientos del sistema (informales e incompletos) Diseo de la arquitectura del prototipo Construir el prototipo y drselo al usuario Refinar Lista de Cambios Probar Refinar y extender el prototipo
Especificacin del prototipo
Arquitectura del prototipo
Prototipo
...
Sistema Final
Especificacin acorde a los deseos del usuario
Diseo de la Arquitectura
...
Sistema Final
Desarrollo del sistema final mediante paradigma clsico
Disear el Sistema
Implementar el Sistema
17
Notas:
En el paradigma basado en prototipo se construye a partir de las especificaciones un modelo de trabajo del programa que se est desarrollando. El objetivo del prototipo es clarificar las caractersticas y operaciones de un sistema que se est desarrollando, practicando con un modelo previamente construido. Los prototipos pueden generase reduciendo el tamao o la funcionalidad. Los prototipos ayudan a establecer los requerimientos del usuario cuando el sistema no es an bien comprendido. (Yo sabr lo que quiero cuando lo vea). Cuando el sistema a nivel de prototipo ha sido aceptado, es necesario definir cmo continuar: Transformar el prototipo en un sistema completamente operativo. Se corre el peligro de que el diseo del prototipo no sea adecuado al producto final, por lo que ste no tendr la calidad suficiente Iniciar un proceso de desarrollo clsico basndose en la experiencia del prototipo. Es una aproximacin ms costosa, pero normalmente ms segura.
18
Paradigma de desarrollo en espiral
Recoleccin inicial de requisitos y planificacin inicial del proyecto Planificacin basada en los comentarios del cliente Evaluacin del cliente
Planificacin
Anlisis de riesgo
Anlisis de riesgo basado en los requisitos iniciales Anlisis de riesgo basado en la reaccin del cliente
Decisin de seguir o no Prototipo inicial Prototipo del siguiente nivel Hacia el sistema final Evaluacin del cliente Implementacin 1 versin sistema completo
19
Notas:
El modelo en espiral para la ingeniera de software fue ideado por B. Bohem (1988) y trata de agrupar las mejores ideas del paradigma clsico y del basado en prototipos, aadiendo adems un nuevo elemento que faltaba en ambos: el anlisis de riesgos. El modelo en espiral trata de realizar un desarrollo evolutivo del producto, desde un prototipo inicial hasta llegar al sistema final, a travs de varias etapas. En cada una de las etapas se siguen, por este orden, las siguientes cuatro actividades principales: Planificacin: Determinacin de objetivos, alternativas, y restricciones, de acuerdo con la etapa actual. Salvo en la primera etapa, se tendrn en cuenta las valoraciones del cliente. Anlisis de riesgo: Anlisis de las alternativas, e identificacin y valoracin de riesgos. Como resultado se eligen las alternativas de menor riesgo, o si el riesgo es demasiado alto se abandona el proyecto. Implementacin: Desarrollo del producto del siguiente nivel Evaluacin del cliente: valoracin de los resultados por parte del cliente En la representacin grfica del modelo en espiral, la curva se sita ms cercana al centro en las primeras etapas del diseo, y se aproxima a los bordes en las etapas finales. El borde representa el sistema final.
20
Diseo basado en modelos

Visualizacin del cdigo Modelo Ingeniera de "ida y vuelta" Modelo Centrarse en el modelo Modelo Slo modelo Modelo
Cdigo Qu es un modelo?
Cdigo El cdigo es el modelo
Cdigo El cdigo y el modelo coexisten
Cdigo El modelo es el cdigo Pensemos slo en el diseo
21
Notas:
El modelado tiene una tradicin muy importante en la ingeniera del software Antiguamente se usaba el modelado slo para tener una idea de cmo era el diseo del cdigo
Actualmente se utiliza UML para hacer el diseo, y luego se hace el cdigo de acuerdo a ese diseo. A veces es difcil mantenerlos coherentes porque la transformacin es manual A medida que se dispone de herramientas de transformacin de modelos es posible centrarse en el modelo y generar casi todo el cdigo de manera automtica. Slo algunas partes pequeas necesitarn codificarse a mano En el futuro, probablemente se trabajar slo a nivel de modelo.
22
Tcnicas de diseo dirigido por modelos (MDD, MDA, MDE)

Escribir la la especificacin formal
Planificar cmo se va a hacer la especificacin Requerimientos del sistema (informales e incompletos)
Cambiar
Lista de Cambios
Probar
Estrategia de diseo
Modelo Independiente de la plataforma (PIM)
Modelo especfico para una plataforma (PSM)
Modelo de la plataforma (PM)
Generacin automtica de cdigo
23
Notas:
Las tcnicas de diseo basado en modelos en el uso de lenguajes de modelado (principalmente UML, lenguaje universal de modelado) que permiten realizar una especificacin funcional del programa a alto nivel, de manera independiente de la plataforma (modelo PIM). Usando luego una herramienta de generacin de cdigo que parte del modelo de la plataforma (PM) y de la especificacin funcional (PIM) se generar el programa automticamente para una plataforma concreta (PSM). Posteriormente el programa puede ser evaluado, y los cambios que se realicen en la especificacin se vern implementados de forma automtica. Ello permite adems adaptarse fcilmente a varias plataformas diferentes. El desarrollo del modelo independiente del lenguaje es la principal dificultad para la generalizacin de este mtodo. La especificacin formal debe presentar los siguientes aspectos contradictorios: formal, para que admita con xito las transformaciones automticas. comprensible para el usuario que debe validar el comportamiento previsto del sistema. La especificacin formal es el aspecto central de este paradigma: La especificacin formal es el nico aspecto que es validado respecto de las especificaciones del usuario Es el punto de arranque de la generacin automtica de cdigo Cuando se mantiene el programa, este mantenimiento se lleva a cabo a partir de la modificacin de la especificacin formal.
24
2. Introduccin a la Etapa de Anlisis y Especificacin

Objetivos: Formular un conjunto correcto y completo de los requerimientos del sistema Producir un conjunto de especificaciones, que:
-
describe el comportamiento externo describe restricciones sobre la implementacin debe servir de referencia para los usuarios debe servir de referencia para el mantenimiento describe las respuestas aceptables ante situaciones anmalas
25
Notas:
Uno de los problemas clave de cualquier diseo software o hardware es el formular un conjunto correcto y completo de los requerimientos del sistema. A partir de estos requerimientos deber producirse un conjunto de especificaciones que, cuando sea propiamente implementado, verificar los requerimientos. A menudo es difcil determinar donde acaban los requerimientos y donde comienzan las especificaciones. La idea es que los requerimientos indican qu se ha de conseguir, mientras que las especificaciones muestran cmo se va a conseguir. Inicialmente se realiza una formalizacin (en un documento) de las necesidades. A partir de estas necesidades se elaboran los documentos de requerimientos, especificaciones, diseo inicial, etc.
26
Modelo de Formulacin de Requerimientos

Establecer las Necesidades Estudio de Viabilidad Modelado del Sistema
Pliego de Necesidades
Informe de Viabilidad
Definicin de Requerimientos
Documento de Requerimientos
Especificacin del Sistema
Documento de Especificacin
27
Notas:
Existen dos destinatarios del proceso de anlisis de requerimientos y especificacin. Unos son los potenciales usuarios del sistema. Estos exigen una definicin de requerimientos que indique las funciones del sistema sin detalles de implementacin. Los otros son los diseadores del sistema, que requieren una especificacin con abundancia de detalles y restricciones. El proceso de anlisis comienza con un documento que describe brevemente las necesidades, y un estudio de viabilidad. Posteriormente se modela el sistema a programar y se describen todos sus requerimientos detallados, generndose los siguientes documentos: Documento de Requerimientos. Es una definicin en lenguaje natural de los servicios que el usuario del sistema va a recibir. Debe estar escrito en lenguaje no tcnico, de forma que los gestores del desarrollo y los clientes puedan comprender su alcance. Este documento, debe ser lo suficientemente preciso para que sobre l se establezca la relacin contractual. Especificacin del diseo. Es una descripcin formal y detallada que sirve de base para el diseo e implementacin del software. Va a ser utilizado por los diseadores, pero debe de ser tambin comprensible para el usuario. En general, los requerimientos expresan lo que el sistema debe hacer, sin explicar cmo, y la especificacin indica cmo se va a hacer, aunque sin entrar en detalles de la implementacin informtica (que forman parte de la siguiente etapa, la de diseo).
28
Estructura del Documento de Requerimientos

1. Introduccin 2. Caractersticas del computador y del sistema 3.Descripcin de la informacin 4. Descripcin de las funciones del software
5. Descripcin del comportamiento ante sucesos diversos 6. Criterios de validacin 7. Cambios
29
Notas:
1. Introduccin. Modelo conceptual del sistema. Principios de organizacin, resmenes de otras secciones, gua de notacin, etc. 2. Caractersticas del computador y del sistema. Si el computador est predeterminado, una descripcin general. En caso contrario un sumario de las caractersticas requeridas. Interfaces Hardware. Concisa descripcin de la informacin recibida o transmitida por el computador. 3. Descripcin de la Informacin: representacin del flujo de informacin. Contenido de la informacin y su representacin. 4. Descripcin de las funciones del software. Qu debe de hacer el software en diversas situaciones y respuesta ante eventos. Restricciones y requisitos de rendimiento. 5. Descripcin del comportamiento ante sucesos diversos. Respuesta a eventos indeseados. Qu debe de hacer el software ante errores, fallos de alimentacin, etc. 6. Criterios de validacin. Lmites de rendimiento. Clases de pruebas a realizar. Consideraciones especiales. 7. Cambios. Tipos de cambios realizados o por realizar.
Michael Gonzlez Harbour 19/ma/09 30
Anlisis Orientado a Objetos

Las metodologas orientadas a objetos son cada vez ms populares, porque facilitan la reutilizacin de cdigo (y de su diseo) son fciles de comprender, modificar, y extender
En el anlisis orientado a objetos se realiza la especificacin del sistema descomponindolo en objetos o clases de objetos Cada objeto o clase tiene tres componentes: nombre: identifica al objeto atributos: valores que almacena operaciones: modifican los atributos y pueden invocar operaciones de otros objetos
31
Notas:
Desde principio de los aos 80 se han venido generalizando los mtodos orientados a objeto tanto para el anlisis y diseo, como para la codificacin de programas. El mtodo hace el software ms fcil de entender, al existir una relacin directa entre su estructura y la del sistema o problema a resolver. Asimismo, el encapsulamiento de todos los aspectos relacionados con cada objeto en un mismo lugar hacer el software ms fcil de modificar, de extender, y de ser reutilizado. En un sistema orientado a objetos los objetos que tienen las mismas caractersticas se agrupan en las llamadas clases de objetos. Por ejemplo, en un proceso industrial, un sensor de posicin puede ser una clase de objetos, ya que puede haber muchos sensores de posicin en diversos lugares de la maquinaria. Cada uno de los sensores individuales ser un objeto. En una metodologa orientada al objeto las clases de objetos o los objetos individuales suelen tener tres componentes: nombre: identifica al objeto o a la clase atributos: existe un atributo por cada uno de los datos o valores que el objeto puede almacenar; el conjunto de los valores de los atributos de un objeto determina su estado operaciones: cada objeto tiene un conjunto de operaciones que se pueden invocar desde el exterior; al invocarse una operacin se le pueden pasar parmetros (datos de entrada o salida) al objeto; la ejecucin de la operacin normalmente implica el cambio de los atributos y, posiblemente, la invocacin de operaciones de otros objetos.
32
Extensin de Objetos y Herencia
Uno de los conceptos fundamentales en las tcnicas orientadas al objeto es la posibilidad de extender un objeto o una clase para obtener otro similar. el objeto o clase extendido hereda todos los atributos y operaciones de su antecesor adems, puede aadir ms atributos y operaciones Otro de los conceptos fundamentales es la comunicacin entre objetos, que se realiza al invocar sus operaciones Por tanto, una metodologa orientada a objetos se basa en: objetos + clases + herencia + comunicacin
33
Notas:
Los objetos o las clases se pueden derivar unos de otros, si presentan elementos comunes. Al crear un objeto o clase como extensin de otro, el nuevo objeto suele heredar todas las operaciones y atributos de su antecesor. El nuevo objeto puede definir nuevos atributos, nuevas operaciones, y redefinir las operaciones heredadas si se considera necesario. Otro de los componentes importantes de una metodologa orientada a objetos es la comunicacin entre objetos. Esta comunicacin se lleva a cabo cuando un objeto invoca una operacin de otro objeto. Al invocar la operacin el objeto invocante puede pasar parmetros de entrada al objeto invocado. Al finalizar la operacin, se pueden devolver parmetros de salida.
34
Modelado mediante UML
El lenguaje unificado de modelado (UML) permite representar el sistema mediante diagramas a niveles diferentes: modelo de objetos: mediante diagramas de objetos que representan las clases de objetos y su jerarqua modelo dinmico: mediante diagramas de estados que representan el comportamiento dinmico de cada objeto modelo funcional: mediante diagramas de flujo de datos que expresan las entradas, salidas y funciones de cada objeto En la fase de anlisis no se entra en los detalles informticos; debe ser entendible por el usuario.
35
Notas:
El lenguaje Unificado de MOdelado (UML) permite la descripcin de un modelo de un sistema software mediante diagramas que permiten describir diversos aspectos. El sistema se descompone en objetos y se modela desde varios puntos de vista diferentes (de forma parecida a los planos de un edificio, que se representan desde diferentes puntos de vista): Modelo de objetos: mediante diagramas de objetos que presentan las clases de objetos y los objetos. Cada objeto se representa con su nombre, sus atributos y sus operaciones. Se muestra asimismo la jerarqua entre objetos y las relaciones que hay entre ellos. Modelo dinmico: mediante diagramas de estados que representan los estados en los que puede estar cada objeto, y las transiciones entre estos estados, causadas por la activacin de eventos. Modelo funcional: mediante diagramas de flujo de datos que representan para cada objeto las entradas, salidas, y funciones que realizan. El documento final de anlisis se compone del planteamiento inicial del problema (requerimientos), ms los modelos de objetos, dinmico y funcional. En ocasiones la frontera entre el anlisis y diseo no est clara. Como norma general, el anlisis debe ser entendible por el usuario, y el diseo contiene los detalles de la implementacin.
36
Ejemplo: Sistema de Alarma:

Diagrama de objetos
Sensor Umbral_de_alarma Estado_de_alarma Cambiar_Umbral Hay_Alarma 1+ Sistema de alarma Modo_de_operacin Tiempo_activacin Tiempo_Sirena Contrasea
Panel de control Estado_de_luces Estado_de_teclas Encender_Luz Apagar_Luz Leer_Tecla
Sensor de proximidad Umbral_de_alarma Estado_de_alarma Cambiar_Umbral Hay_Alarma
Sensor de humo Umbral_de_alarma Estado_de_alarma Estado_pila Cambiar_Umbral Hay_Alarma Est_Pila_Cargada
Sirena Encendida Encender Apagar
37
Notas:
En el diagrama de objetos de la figura superior se muestra una descomposicin de un sistema de alarma en clases de objetos. Como puede verse, la clase sensor se ha extendido para dar lugar a una clase sensor de proximidad y una clase sensor de humos. Ambas heredan los atributos y operaciones de su antecesor y, el sensor de humos, aade adems una operacin para conocer el estado de carga de las pilas. La herencia se muestra en el diagrama por medio de un pequeo tringulo sobre una barra horizontal, con lneas verticales que indican la relacin de parentesco. El resto de las clases de objetos no tiene herencia, aunque la posterior descomposicin interna que se realice puede traer la definicin de nuevas clases y, quizs la herencia. Por ejemplo, el panel de control tiene varias luces, y varias teclas, que se podran especificar cada uno como un objeto individual; las teclas se podran especializar despus en teclas luminosas y no luminosas. Las lneas que aparecen uniendo diferentes objetos representan las relaciones entre objetos. Las marcadas mediante un rombo representan la agregacin, es decir indican que un objeto se compone de otros objetos ms elementales. As el sistema de alarma, que representa al sistema total, es una agregacin de s mismo ms uno o ms sensores, mas un panel de control, y una sirena. A este diagrama habra que aadirle el modelo dinmico y el modelo funcional, que se expresan de forma similar a lo visto para el anlisis estructurado.
38
3. Tcnicas de diseo
La naturaleza del proceso de diseo es altamente iterativa, y se basa en los principios de abstraccin, refinamiento sucesivo, modularidad, y ocultamiento de informacin
Especificacin
Diseo Preliminar
Anlisis
Validar
Producto final
Nuevo Diseo
Diagnosticar eficiencia
Iterar todas las veces necesarias
39
Notas:
Las tcnicas de diseo de programas han de tener en cuenta la naturaleza del proceso de diseo, que generalmente es altamente iterativo. Normalmente el diseo se realiza en varias etapas, y se progresa por refinamientos sucesivos. Primero se realiza un diseo preliminar, de alto nivel. Posteriormente se van realizando otros diseos, ms detallados, y con diferentes niveles de abstraccin. El diseo se hace siempre modular, con objeto de dividir el programa en trozos de tamao manejable. Luego, cada trozo o mdulo se puede descomponer en nuevos mdulos. Al dividir un sistema en mdulos se expresan sus componentes externas, y se ocultan los detalles internos. Slo a la hora de disear el mdulo concreto, se presta atencin a los detalles internos. Esta separacin de los detalles internos y de los elementos visibles desde fuera se denomina ocultamiento de informacin.
40
Etapas del diseo

Generalmente suele hacerse el diseo en dos etapas: Diseo de la arquitectura
- diseo de las estructuras de datos - estructura general del programa - interfaces entre los diferentes mdulos
Diseo detallado
- diseo detallado de las estructuras de datos - diseo de los algoritmos o procedimental
41
Notas:
Aunque el diseo se realiza en varias etapas, por refinamientos sucesivos, suele dividirse en dos grandes bloques: el diseo de la arquitectura, y el diseo detallado. En el diseo de la arquitectura se divide el sistema en mdulos y se expresan las funciones de cada mdulo, sus operaciones, y las interfaces necesarias para usar el mdulo desde el exterior. Asimismo se disean las estructuras de datos que se van a utilizar, definiendo los mdulos en que se van a situar, y sus interfaces (pero no su estructura interna). La arquitectura del sistema se puede expresar con varios niveles de abstraccin. Una vez finalizado el diseo de la arquitectura comienza el diseo detallado, en el que se especifican para cada mdulo los algoritmos que se van a utilizar para cada operacin o procedimiento, y las estructuras de datos concretas que se van a utilizar para el almacenamiento de informacin. A menudo, el diseo detallado se va realizando en paralelo a la codificacin. Sin embargo es necesario que el diseo de la arquitectura se haga antes de escribir el software, para garantizar la calidad del producto final.
42
Algunas tcnicas de diseo

Diseo de la arquitectura: diseo modular diseo descendente y ascendente diseo estructurado diseo orientado a objetos Diseo detallado: programacin estructurada programacin orientada al objeto programacin redundante programacin defensiva
43
Notas:
En la transparencia superior se muestran algunas de las tcnicas de diseo que se utilizan ms habitualmente en el diseo de la arquitectura y el diseo detallado de un programa. Estas tcnicas de diseo no son excluyentes, sino que aparecen generalmente unidas, en los diferentes niveles de diseo. diseo modular: descomposicin del programa en mdulos independientes diseo descendente y ascendente: la particin en mdulos se puede realizar de lo general a lo ms detallado (descendente), o de lo ms detallado a lo general (ascendente) diseo estructurado: asociado al anlisis estructurado diseo orientado a objetos: asociado al anlisis orientado a objetos programacin estructurada: tcnicas de programacin que evitan los saltos incondicionales (Go To) programacin orientada al objeto: ayudan a programar diseos orientados a objetos programacin redundante: para detectar y corregir fallos (tolerancia a fallos) programacin defensiva: para detectar todos los fallos que sea posible y garantizar un mejor funcionamiento del programa.
44
Diseo modular
Un mdulo realiza una funcin especfica e independiente
Debe ser autocontenido y evitar los acoplos: Acoplo por datos. Acoplo por control. Paso de nombres de mdulos o variables de control entre mdulos. Acoplo por estructuras de datos globales declaradas como externas. Acoplo por estructuras de datos globales. Acoplo por contenido. Un mdulo hace un salto al interior de otro.
45
Notas:
Un mdulo de un programa se puede definir como un subprograma de unas dimensiones no muy grandes, que realiza una funcin especfica e independiente. Un mdulo es por naturaleza autocontenido. Ello significa que su eliminacin de un sistema solamente deshabilita la funcin nica realizada por ese mdulo. Igualmente, si sustituimos el mdulo por una versin ms actualizada de ste, sin modificaciones sobre las variables de entrada y salida, el sistema debe funcionar bsicamente igual. Cuando diseamos software basado en mdulos que operan segn estos principios, el diseo es denominado modular. La principal dificultad de la programacin modular consiste en evitar el acoplo entre los mdulos (hacerlos independientes). Como gua para los distintos acoplos posibles, de mejor a peor, puede utilizarse la de MYERS (1978), que se muestra en la transparencia superior.
46
Caractersticas de la programacin modular

Ms fcil escribir el programa Proceso de direccin ms sencillo Facilita el ocultamiento de informacin y la abstraccin
Requiere esfuerzo y cuidado en el diseo, para hacer los mdulos independientes Modificacin ms sencilla Ms fcil probar el programa
47
Notas:
La programacin modular presenta innumerables ventajas. En primer lugar, al permitir la descomposicin del programa en trozos de tamao manejable hace ms fcil de escribir y probar el programa, y hace el proceso de direccin ms sencillo. Asimismo, la estructura de los mdulos facilita el ocultamiento de informacin ya que se pueden especificar los detalles internos por un lado, y la parte visible por otro. La programacin modular facilita la abstraccin, ya que se puede describir el sistema con varios niveles de abstraccin, de forma jerrquica, con mdulos compuestos a su vez por otros mdulos. Sin embargo, la programacin modular requiere esfuerzo y cuidado en el diseo, para hacer los mdulos independientes. Si los mdulos no son independientes no se consigue una verdadera programacin modular. Si el programa es modular, su modificacin es ms sencilla, ya que la independencia entre los mdulos facilita el que un cambio en un mdulo no afecte al resto. Adems, el programa es ms fcil de probar, ya que podemos hacer las pruebas de cada mdulo por separado, y luego realizar la prueba del programa conjunto separadamente (prueba de integracin). De esta forma es mucho ms fcil localizar y corregir los errores, la hacerse la prueba paso a paso.
48
Diseo ascendente y descendente
Diseo Descendente o top-down: La estructura de control del programa se fracciona en mdulos El diseo de estos mdulos principales se hace en primer lugar Los mdulos se dividen en submdulos, de forma jerrquica Los detalles de diseo de mdulos inferiores permanecen escondidos
49
Notas:
El diseo top-down o descendente es un proceso de descomposicin focalizado principalmente en el flujo de control o la estructura de control del programa. El primer paso es el estudio de todos los aspectos del programa y el fraccionamiento de ste en un nmero (3 a 10) de mdulos independientes. El segundo paso es la divisin de cada uno de estos mdulos en submdulos independientes, repitindose el proceso hasta obtener mdulos suficientemente pequeos como para su fcil retencin mental, y as poder realizar su diseo detallado y codificacin sin complicaciones. Una de las caractersticas ms importantes de esta tcnica es que los detalles del diseo de los niveles inferiores aparecen escondidos. Solamente es necesario definir los datos y el control que actan sobre las interfaces entre cada mdulo. Por tanto, la programacin Top-down permite olvidarse de los detalles en los niveles superiores del diseo, aunque esto puede impedir darse cuenta a tiempo de que el camino elegido no es el correcto para alcanzar las especificaciones.
50
Desarrollo de un diseo top down
stub
stub
stub
stub
51
Notas:
En la figura superior se muestra un instante en el desarrollo de un programa diseado mediante la tcnica top-down. En este desarrollo, los mdulos que an no se han implementado se sustituyen por stubs, o prototipos sencillos. Esto permite construir prototipos de un sistema incompleto, para probar parte de la funcionalidad, y que el usuario pueda validar el proceso.
52
Tcnica de diseo ascendente
Diseo ascendente o bottom-up: Primero se hace una planificacin de los mdulos de bajo nivel que se vayan a necesitar Se desarrollan las partes ms detalladas y con mayor nivel de dificultad en primer lugar Se realiza el diseo del resto del sistema, acomodando los diseos previos, hasta llegar finalmente al diseo del sistema final. Puede resultar una estructura de control inadecuada
53
Notas:
En un diseo bottom-up, o ascendente, primero se idea un diseo tpico del sistema, por experiencia, intuicin o un anlisis rpido, y se decide qu partes del diseo son ms difciles o con mayores limitaciones. Estas partes esenciales se desarrollan en primer lugar, y el resto del diseo es confeccionado para acomodar los diseos, ya escogidos, de las partes esenciales. En el diseo bottom-up el principal problema puede ser la acomodacin de los diferentes mdulos en una estructura de control inadecuada. En muchas ocasiones se utilizan juntas las tcnicas de programacin top-down y bottom-up mezcladas, intentando aprovechar las mejores caractersticas de cada una. El tipo de aproximacin utilizada presenta una gran influencia no slo en la fase de diseo, sino en la metodologa de desarrollo y prueba del programa.
54
Desarrollo de un diseo bottom-up
Driver
Driver
55
Notas:
En la figura superior se muestra un instante en el desarrollo de un programa diseado mediante la tcnica bottom-up. En este desarrollo, los mdulos que an no se han implementado, que son los del nivel superior, se sustituyen por drivers, o programas principales sencillos, cuya funcin es llamar a los mdulos que estn desarrollados, y permitir su prueba. Esto permite crear prototipos que ensayan parte de las funciones del sistema final, para su validacin por parte del usuario.
56
Ejemplo de programacin top-down y bottom-up

a)
Races de una ecuacin cbica
b)
Mostrar races y clasificacin
Clasificar las races Leer coeficientes A, B, C, D Comprobar casos singulares Calcular las races Clasificar las races Mostrar races y clasificacin
Resolver ecuacin 2 grado
Leer coeficientes A, B, C, D
Calcular raz real (Met. Newton)
57
Notas:
Este ejemplo representa el diseo de un programa para obtener las races de una ecuacin cbica. En el apartado (a), se realiza el diseo del mdulo principal, y posteriormente se disean los mdulos del nivel inferior. Durante la implementacin algunos de los mdulos inferiores pueden ser sustituidos por prototipos, con los que se comunica el mdulo principal. En el apartado (b) se comienza por el mdulo que representa el algoritmo esencial del problema: clculo de una raz real mediante el mtodo de Newton. Posteriormente se procede con la frmula cuadrtica, etc., para finalizar con la salida de resultados. Durante su implementacin, se realizar la prueba del programa mediante un programa principal prototipo, que se comunica con los mdulos que se van desarrollando.
58
Diseo orientado a objetos

Si el anlisis es orientado a objetos, es lgico hacer diseo orientado a objeto
En el diseo de la arquitectura se realizan las siguientes etapas: se divide el sistema en subsistemas se identifica la concurrencia entre objetos se eligen las estrategias de almacenamiento de datos se elige la estrategia general de programacin: mquinas de estados abstractas, tareas concurrentes, etc. En el diseo detallado se desarrollan los detalles de cada objeto: operaciones, atributos, relaciones entre objetos, etc.
59
Notas:
Si el anlisis del sistema es un anlisis orientado a objeto, lo lgico es hacer el diseo tambin mediante una metodologa orientada al objeto. En el anlisis de la arquitectura se realizan las siguientes actividades: organizar el sistema en subsistemas identificar la concurrencia entre objetos asociar objetos a recursos (por ejemplo a procesadores) elegir la estrategia bsica de almacenamiento de informacin (ficheros, sistemas distribuidos, datos en memoria, etc.) elegir la estrategia general de implementacin, que puede ser una mquina de estados abstracta, tareas concurrentes, etc. considerar los aspectos del entorno establecer prioridades En el diseo detallado lo que se pretende es una definicin detallada de cada objeto. Generalmente se hacen diagramas ms detallados que en el anlisis tanto para los objetos, como para su comportamiento dinmico y funcional. Para cada objeto se eligen los algoritmos para sus operaciones, las representaciones concretas de cada atributo, y la forma de implementar las diferentes relaciones entre los objetos.
60
Programacin orientada a objetos
Existen lenguajes de programacin orientada a objetos que facilitan la implementacin de un diseo orientado a objetos. Los principales mecanismos son: encapsulamiento herencia polimorfismo Tambin es posible implementar un diseo orientado a objetos mediante lenguajes normales pero se repite mucho cdigo y no se aprovechan todas las ventajas del diseo
61
Notas:
La programacin orientada al objeto se halla facilitada en los lenguajes de programacin orientada al objeto, que soportan los siguientes mecanismos: Encapsulamiento de los objetos o clases de objetos junto a su estado y sus operaciones, con el ocultamiento de todos los detalles internos del objeto. Creacin de nuevos objetos a partir de otros existentes por medio de la herencia de todos sus atributos y operaciones. El polimorfismo, que permite invocar a una operacin de una determinada categora de objetos si saber expresamente el tipo concreto del objeto que se va a usar. En el instante de la ejecucin, cuando ya se sabe el tipo concreto del objeto, se ejecuta la operacin adecuada a ese objeto de forma automtica. La programacin orientada al objeto para determinados tipos de sistemas tambin se facilita si el lenguaje permite la ejecucin concurrente de mltiples objetos, mediante la utilizacin de tcnicas de multitarea. Esto permite la creacin de objetos o clases de objetos activos.
62
Programacin redundante
Muchos de los sistemas basados en computador deben de ser tolerantes a fallos: controladores de vehculos controladores de sistemas crticos (centrales nucleares, control de trfico areo, etc.) bases de datos (bancos, etc.) La tolerancia a fallos se consigue mediante la redundancia: fsica: varios computadores haciendo lo mismo lgica: varios algoritmos haciendo los mismos clculos de forma diferente Esta ltima es la programacin redundante
63
Notas:
Existen muchos sistemas que deben de construirse de forma que sean tolerantes a fallos. Tpicamente los controladores de vehculos son as (coches, aviones, satlites, etc.). Tambin hay sistemas de seguridad crtica que requieren tolerancia a fallos, como controladores de centrales nucleares o del trfico areo. Asimismo algunas aplicaciones de bases de datos contienen datos muy valiosos y deben funcionar aunque haya algn fallo (por ejemplo, las bases de datos de los bancos) La tolerancia a fallos se consigue replicando diversas partes del equipo: Redundancia fsica. Permite evitar los efectos de errores del hardware. Para ello se replican la CPU, los discos, memoria, etc. Generalmente es preciso tener un sistema de deteccin de los fallos para que, si son repetitivos, se sustituya la unidad que funciona mal mientras las dems siguen realizando su labor. Redundancia lgica. Permite evitar fallos del software. Consiste en repetir los mismos algoritmos pero escritos de forma distinta. Para ello se suelen desarrollar los algoritmos por dos equipos totalmente diferentes, para que la probabilidad de que tengan el mismo fallo sea muy baja. Tambin es necesario un sistema que sincronice los resultados del clculo y determine los errores que puedan darse para desechar esos resultados. Si los resultados son muy diferentes se puede utilizar el que ms se acerque a los valores esperados.
64
Programacin defensiva
Hay que suponer siempre que va a haber errores
Hay que comprobar: datos de entrada de perifricos (rango y atributos) datos proporcionados por otros programas consistencia de las estructuras de datos entradas de operadores (naturaleza, secuencia,...) lmites de stacks lmites de arrays posibilidad de divisin por cero u otras operaciones aritmticas incorrectas en las expresiones. salidas hacia otros programas o perifricos
65
Notas:
Una de las estrategias ms importantes para generar software seguro es la programacin defensiva, que puede ser activa o pasiva. La programacin defensiva pasiva comprueba la informacin en determinados puntos del programa, para detectar la existencia de errores. La programacin defensiva activa opera de forma peridica o durante perodos de actividad baja del computador analizando la informacin almacenada para verificar la presencia o no de errores. En general la programacin defensiva requiere que el programador tenga presente que la aparicin de errores es muy probable, y por tanto debe de introducir los elementos de comprobacin que considere necesarios. Los elementos de informacin que tpicamente deben de comprobarse en programacin defensiva son los que se indican en la transparencia de arriba.
66

Cap3 2en1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Cap3 2en1

Cargado por

Copyright:

Formatos disponibles

Parte I: El computador y el proceso de programacin

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN 4

Michael Gonzlez Harbour 19/ma/09

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

1. Actividades del ciclo de vida del software

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

Actividades en Cada Etapa

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

Actividades en Cada Etapa (cont.)

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

Validacin Paso a Paso del Proceso

Los analistas aceptan la descripcin de los requerimientos, que es clara y realizable

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

Validacin por Comparacin con los Requerimientos

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

Paradigmas del Proceso Software

Paradigma clsico (en cascada) del ciclo de vida del software:

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

Objetivos de los Nuevos Paradigmas

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

Paradigma Basado en Prototipo

Especificacin del prototipo

Arquitectura del prototipo

Especificacin acorde a los deseos del usuario

Desarrollo del sistema final mediante paradigma clsico

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

Paradigma de desarrollo en espiral

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

Diseo basado en modelos

Cdigo El cdigo es el modelo

Cdigo El cdigo y el modelo coexisten

Cdigo El modelo es el cdigo Pensemos slo en el diseo

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN

Michael Gonzlez Harbour 19/ma/09

DEPARTAMENTO DE MATEMTICAS, ESTADSTICA Y COMPUTACIN