DESARROLLO RÁPIDO DE APLICACIONES

Las técnicas de desarrollo rápido (RAD) de aplicaciones evolucionaron de los llamados lenguajes de cuarta generación y se utiliza para desarrollar aplicaciones con un uso intensivo de datos. Por consiguiente, normalmente están organizadas como un conjunto de herramientas que permiten crear datos, buscarlos, visualizarlos y presentarlos en informes.

Las herramientas que se incluyen en un entorno RAD son:

o   Un lenguaje de programación de base de datos, que contiene conocimientos de la estructura de la base de datos y que incluye las operaciones básicas de manipulación de base de datos.

o   Un generador de interfaces, que se utiliza para crear formularios de introducción y visualización de datos.

o   Enlace a aplicaciones de oficina, como una hoja de cálculo para el análisis y manipulación de información numérica o un procesador de texto para la creación de plantillas de información.

o   Un generador de informes, que se utiliza para definir y crear informes a partir de la información de la base de datos.

Muchas de las aplicaciones de negocio se apoyan en formularios estructurados para las entradas y salidas, por los que los entornos RAD proporcionan recursos potentes para la definición de pantallas y generación de informes.

PROTOTIPADO DEL SOFTWARE

Se pueden conseguir algunos de los beneficios de un proceso de desarrollo incremental creando un prototipo del software. Este enfoque se denomina a veces prototipado desechable debido a que el prototipo no es entregado al cliente o mantenido por el desarrollador.

Es una versión inicial de un sistema software que se utiliza para demostrar conceptos, probar opciones de diseño y, en general, informarse más del problema y sus posibles soluciones.

REUTILIZACIÓN DEL SOFTWARE

Basan su diseño en componentes que han sido utilizados y probados en otros sistemas. Estos componentes no son solamente pequeños componentes, como tuercas y válvulas sino que incluyen subsistemas mayores, como motores, condensadores y turbinas.

Es una aproximación del desarrollo que intenta maximizar la reutilización del software existente. Las unidades del software que se reutilizan pueden ser de tamaños totalmente diferentes.

La ventaja obvia de la reutilización de software es que los costes totales de desarrollo deberían reducirse.

PROGRAMACIÓN EXTREMA

La programación extrema es posiblemente el método ágil más conocido y ampliamente utilizado. Todos los requerimientos se expresan como escenarios (historias de usuarios), los cuales se implementan directamente como una serie de tareas.

La programación extrema implica varias prácticas que se ajustan a los principios de los métodos ágiles:

1.    El desarrollo incremental se lleva a cabo a través de entregas del sistema pequeñas y frecuentes, y por medio de un enfoque para la descripción de requerimientos basados en las historias de cliente o escenarios que pueden ser la base para el proceso de planificación.

2.    La participación del cliente se lleva a cabo a través del compromiso a tiempo completo del cliente en el equipo de desarrollo.

3.    El interés de las personas, en vez de los procesos, se lleva a cabo a través de la programación en parejas, la propiedad colectiva del código del sistema y un proceso de desarrollo sostenible que no implique excesivas jornadas de trabajo.

4.    El cambio se lleva a cabo a través de las entregas regulares del sistema, un desarrollo previamente probado y la integración continua.

5.    El mantenimiento de la simplicidad se lleva a cabo a través de la refactorización constante para mejorar la capacidad del código y la utilización de diseños sencillos que no prevén cambios futuros en el sistema.

PRUEBAS EN PROGRAMACIÓN EXTREMA

Una de las diferencias importantes entre el desarrollo interactivo y el desarrollo basado en la planificación es la forma de probar el sistema. Algunos enfoques para el desarrollo interactivo tienen un proceso de pruebas muy informal.

Las características clave de las pruebas en programación externa son:

ü  Desarrollo previamente probado.

ü  Desarrollo de pruebas incremental a partir de los escenarios.

ü  Participación del usuario en el desarrollo de las pruebas y en la validación.

ü  El uso de bancos de pruebas automatizados.

PROGRAMACIÓN EN PAREJAS

Otra práctica innovadora que se ha introducido es que los programadores trabajan en parejas para desarrollar el software. De hecho se sientan juntos en la misma estación de trabajo para desarrollar el software. Tiene las siguientes ventajas:

·         Apoyar la idea de la propiedad y responsabilidad comunes del sistema. Esto refleja la idea de Weinberg de la programación sin ego, en la que el equipo como un todo es dueño del software y las personas individuales no tienen la culpa de los problemas con el código.

·         Actúa como un proceso de revisión informal ya que cada línea de código es vista por al menos dos personas. Las inspecciones y revisiones del código consiguen descubrir un alto porcentaje de errores del software.

·         Ayuda en la refactorización, la cual es un proceso de mejora del software. Es decir, se debe escribir nuevamente partes del código para mejorar su claridad y estructura.

DESARROLLO RÁPIDO DE SOFTWARE

Actualmente los negocios operan en un entorno global que cambia rápidamente. Tienen que responder a nuevas oportunidades y mercados, condiciones económicas cambiantes y la aparición de productos y servicios competidores. Actualmente el desarrollo y entrega rápidos son a menudo los requerimientos más críticos de los sistemas de software.

Están diseñados para producir software útil de forma rápida. Generalmente, son procesos interactivos en los que se entrelazan la especificación, el diseño, el desarrollo y las pruebas.

Aunque existen muchos enfoques para el desarrollo rápido de software, comparten las mismas características fundamentales:

·         Los procesos de especificación, diseño e implementación son concurrentes. No existe una especificación del sistema detallada, y la documentación del diseño se minimiza o es generada automáticamente por el entorno de programación utilizando para implementar el sistema.

·         El sistema se desarrolla en una serie de incrementos. Los usuarios finales del sistema participan en la especificación y evaluación de cada incremento posterior del sistema.

·         A menudo se desarrollan las interfaces de usuario del sistema utilizando un sistema de desarrollo interactivo que permite que el diseño de la interfaz se cree rápidamente dibujando y colando iconos en la interfaz.

El desarrollo incremental, implica producir y entregar el software en incrementos más que en un paquete único. Cada interacción del proceso produce un nuevo incremento del software.

Las dos ventajas principales son:

·         Entrega acelerada de los servicios del cliente.

·         Compromiso del cliente con el sistema.

Sin embargo, puede haber verdaderos problemas con este enfoque, particularmente en las grandes compañías con procedimientos bastantes rígidos y en organizaciones donde el desarrollo del software normalmente se subcontrata con un contratista exterior. Los principales problemas son:

1.    Problemas de administración. Los sistemas desarrollados incrementalmente cambian tan rápido que no es rentable producir una gran cantidad de documentación del sistema.

2.    Problemas contractuales. Se basa en la especificación del sistema. Cuando no existe tal especificación, puede ser difícil diseñar un contrato para el desarrollo del sistema.

3.    Problema de validación. La verificación y la validación están pensadas para demostrar que el sistema cumple su especificación. Los procesos de desarrollo interactivo intentan minimizar la documentación y entrelazan la especificación y el desarrollo. Por lo tanto la validación independiente de los sistemas desarrollados incrementalmente es difícil.

4.    Problemas de mantenimiento. Esto significa que cualquiera, aparte de los desarrolladores originales, puede tener dificultades para entender el software.

NOTACIÓN BÁSICA DE LOS DIAGRAMAS DE COLABORACIÓN

El U.M.L. ha adoptado un método simple y uniforme de describir visualmente las instancias para distinguirlas de los tipos. Una instancia utiliza el mismo símbolo grafico usados para representar el tipo, pero se subraya el texto. Además en un diagrama de colaboración, al nombre de la clase se le anteponen dos puntos.

El vinculo es una trayectoria de conexión entre dos instancias; indica alguna forma de navegación y visibilidad entre las instancia, es una instancia de asociación.

Los mensajes entre objetos pueden representarse por medio de una flecha con un nombre y situada sobre una línea del vinculo. A través de este puede fluir un número indefinido de mensajes.

Los parámetros de un mensaje pueden anotarse dentro de paréntesis después del nombre del mensaje. Puede incluirse un valor de retorno anteponiéndole al mensaje un nombre de variable de esa instrucción y un operador de asignación. Es opcional incluirlos.

Puede enviarse de un objeto así mismo. Esto lo muestra gráficamente un vínculo consigo mismo, donde el mensaje fluye a lo largo del vínculo.

La interacción se indica posponiendo un asterisco al número de secuencia. Este símbolo significa que, dentro de un ciclo, el mensaje va a ser enviado repetidamente al receptor. También es posible incluir una capsula de interacción que indique los valores de recurrencia.

El mensaje de creación independiente del lenguaje es crear, que se muestra en el momento de ser enviado a la instancia que vamos a generar. El mensaje crear puede contener parámetros, lo cual indica la transferencia de los valores iniciales.

El orden de los mensajes se indica con un número de secuencia donde el primer mensaje no se numera.

Un mensaje condicional se indica posponiendo al número de la secuencia una cláusula condicional entre corchetes, en forma parecida a como se hace con una cláusula de interacción.

Un multiobjeto, o conjunto de instancias, puede dibujarse como un icono de pila; un multiobjeto suele implementarse como un grupo de instancias guardadas en un contenedor u objeto colección.

DIAGRAMA DE COLABORACIÓN

En los contratos de colaboración se incluye una primera conjetura óptima sobre las pos condiciones referentes al inicio de las operaciones del sistema. Sin embargo los contratos no muestran una solución de cómo los objetos de software van a cumplir con ellos.

El U.M.L. contiene diagramas de interacción que explican gráficamente como los objetos interactúan a través de mensajes para realizar las tareas.

ACTIVIDADES Y DEPENDENCIAS

Los diagramas de interacción se realizan en la fase de diseño de un ciclo de desarrollo. No se pueden preparar si antes no se generan los siguientes artefactos:

·         Un modelo conceptual: El diseñador podrá definir las clases del software correspondientes a los conceptos.

·         Contratos de la operación del sistema: El diseñador identifica las responsabilidades y las pos condiciones que han de llenar los diagramas de interacción.

·         Casos de usos reales: El diseñador recaba información sobre las tareas que realizan los diagramas de interacción, además de lo estipulado en los contratos.

DIAGRAMA DE INTERACCIÓN

Un diagrama de interacción explica gráficamente las interacciones existentes entre las instancias del modelo de estos. El U.M.L. define dos tipos de estos diagramas; ambos sirven para expresar interacciones semejantes o idénticas del mensaje:

Ø  DIAGRAMA DE COLABORACIÓN: Describen las interacciones entre los objetos en un formato de grafo o red.

Ø  DIAGRAMA DE SECUENCIA: Describen las interacciones en una especie de formato de cerca o muro.

COMO PREPARAR DIAGRAMAS DE COLABORACIÓN

Para preparar diagramas de colaboración se debe:

1.    Elaborar un diagrama por cada operación del sistema durante el ciclo actual de desarrollo.

a.    En cada mensaje del sistema, dibuje un diagrama incluyéndolo como mensaje inicial.

2.    Si el diagrama se torna complejo, divídalo en diagramas más pequeños.

3.    Diseñe un sistema de objetos interactivos que realicen las tareas, usando como punto de partida las responsabilidades del contrato de operación, las pos condiciones y la descripción de casos de uso.

DEL ANÁLISIS AL DISEÑO

INICIO DE LA FASE DE DISEÑO

Durante el ciclo de desarrollo interactivo es posible pasar a la fase de diseño, una vez terminados estos documentos del análisis. Durante este paso se logra una solución lógica que se funda en el paradigma orientado a objetos.

Su esencia es la elaboración de Diagramas de Interacción, que muestran gráficamente cómo los objetos se comunicarán entre ellos a fin de cumplir con los requerimientos.

El advenimiento de los diagramas de interacción nos permite dibujar Diagramas de Diseño de clases que resumen la definición de las clases implementables en software.

DESCRIPCIÓN DE LOS CASOS REALES DE USO

Los casos reales de uso presentan un diseño concreto de cómo se realizará el caso. La definición de los casos de uso reales es una de las primeras actividades dentro de un ciclo de desarrollo. Su creación depende de los casos esenciales conexos que hayan sido generados antes.

Describe el diseño concreto del caso de uso a partir de una tecnología particular de entrada y salida, así como de su implementación global. Por ejemplo, si interviene una interfaz gráfica para el usuario, el caso de uso real incluirá diagramas de las ventanas en cuestión y una explicación de la interacción de bajo nivel con los artefactos de la interfaz.

Tal vez no sea necesario generarlos. Una alternativa podría consistir en que el diseñador realizara secuencias de las pantallas de la interfaz general para el usuario y que después fuera incorporando los detalles durante la implementación.

DISEÑO ARQUITECTÓNICO

Es un proceso multiface en el que sintetizan representaciones de la estructura de los datos, la estructura del programa, las características de la interfaz y los detalles procedimentales desde los requisitos de la información.

En un sistema de programa o computación es la estructura de las estructuras del sistema, la cual comprende los componentes del software, las propiedades de esos componentes visibles externamente y las relaciones entre ellos. La arquitectura de software es importante por:

ü  Facilitan la comunicación entre todas las partes interesadas en el desarrollo de un sistema basado en computadora.

ü  Destaca decisiones tempranas de diseño que tendrá un profundo impacto en todo el trabajo de ingeniería del software, y es tan importante en el éxito final del sistema como una entidad operacional.

ü  Constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo está estructurado el sistema y de cómo trabajan juntos sus componentes.

MODELOS DE DATOS, ESTRUCTURA DE DATOS, BASE DE DATOS, ALMACÉN DE DATOS

Hay muchas características diferenciales entre un almacén de datos y base de datos:

·         Orientación por materia.

·         Integración.

·         Restricciones de tiempo.

·         No volatibilidad.

DISEÑO DE DATOS A NIVEL DE COMPONENTES

Es la representación de estructuras de datos a la que se acceden directamente a través de uno o más componentes del software. Sus principales principios son:

·         Los principios del análisis sistemático aplicado a la función y al comportamiento deberían aplicarse también a los datos.

·         Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberían estar claramente identificadas.

·         Se debería establecer un diccionario de datos y usarlo para definir el diseño de los datos y del programa.

·         Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del proceso de diseño.

·         La representación de las estructuras de datos deberían conocerla solo aquellos módulos que deban hacer uso directo de los datos contenidos dentro de la estructura.

·         Debería desarrollarse una biblioteca de estructura de datos útiles y de las operaciones que se les puede aplicar.

·         Un diseño del software y un lenguaje de programación debería soportar la especificación y realización de los tipos abstractos de datos.

ESTILOS ARQUITECTÓNICOS

ü  A. CENTRADA DE DATOS: En el centro se encuentra un almacén de datos al que otros componentes acceden con frecuencia para actualizar, añadir, borrar o bien modificar los datos del almacén.

ü  A. FLUJO DE DATOS: Se aplica cuando los datos de entrada son transformados a través de una serie de componentes computacionales o manipulativos en los datos salida.

ü  A. LLAMADA Y RETORNO: Permite al diseñador del software construir una estructura de programa relativamente fácil de modificar y ajustar a escala.

ü  A. ORIENTADA A OBJETOS: Los componentes de un sistema encapsulan los datos y las operaciones que se deben realizar para manipular los datos.

ü  A. ESTRATIFICADA: Se cran diferentes capas y cada una realiza operaciones que progresivamente se aproximan más al cuadro de instructores de la máquina.

PRINCIPIOS DEL DISEÑO

·         En el proceso de diseño no deberá utilizarse “orejeras”.

·         El diseño deberá poderse rastrear hasta el modelo de análisis.

·         El diseño no deberá inventar nada que ya este inventado.

·         El diseño deberá minimizar la distancia intelectual entre el software y el problema como si de la misma vida real se tratara.

·         El diseño deberá presentar uniformidad e integración.

·         El diseño deberá estructurarse para degradarse poco a poco, incluso cuando se enfrenta con datos, sucesos o condiciones de operación aberrantes. Adaptabilidad.

·         El diseño no es escribir código, y escribir código no es diseñar.

·         El diseño deberá evaluarse en función de la calidad mientras se va creando, no después de tomarlo.

·         El diseño deberá revisarse para minimizar los errores conceptuales.

CONCEPTOS DEL DISEÑO

o   ABSTRACCIÓN: Permite concentrarse en un problema a algún nivel de generalizaciones sin tener en consideración de la abstracción, también permite trabajar con conceptos y términos que son familiares en el entorno del problema sin tener que transformarlos en una estructura no familiar.

o   REFINAMIENTO: Una jerarquía se desarrolla descomponiendo una sentencia macroscópica de función paso a paso hasta alcanzar las sentencias del lenguaje de programación.

o   MODULARIDAD: El software se divide en componentes nombrados y abordados por separado llamados módulos que se integran para satisfacer los requisitos del problema.

o   ARQUITECTURA DEL SOFTWARE: Es la estructura jerárquica de los componentes del programa, la manera en que los componentes interactúan y la estructura de datos que van a utilizar los componentes.

o   JERARQUÍA DE CONTROL: Representa la organización de los componentes de programa e implica una jerarquía de control. No representa los aspectos procedimentales del software.

o   DIVISIÓN ESTRUCTURAL: Se puede dividir tanto Horizontal como verticalmente.

o   ESTRUCTURA DE DATOS: Es una representación lógica entre elementos individuales de datos.

o   OCULTACIÓN DE INFORMACIÓN: Los módulos se caracterizan por las decisiones de diseño que oculta al otro. En otras palabras los módulos deberán especificarse y diseñarse de manera que la información que está dentro de un módulo sea inaccesible a otros módulos que no necesiten esa información.

CONCEPTOS Y PRINCIPIOS DE DISEÑO

DISEÑO DEL SOFTWARE E INGENIERÍA DEL SOFTWARE

EL PROCESO DEL DISEÑO

Es un proceso interactivo mediante el cual los requisitos se traducen en un plano para construir el software.

Con el fin de evaluar la calidad de una representación de diseño, deberán establecerse los criterios técnicos para un buen diseño. Por ahora se presentarán las siguientes directrices:

1.    Presentar una estructura arquitectónica:

a.    Creada mediante patrones de diseño reconocibles.

b.    Formada por componentes que exijan características de buen diseño.

c.    Que se puedan implementar de manera evolutiva.

2.    Deberá ser modular.

3.    Deberá contener distintas representaciones de datos, arquitectura, interfaces y componentes.

4.    Conducirá estructuras de datos adecuadas para los objetos que se van a implementar y que procedan de patrones de datos reconocibles.

5.    Deberá conducir a componentes que presenten características funcionales independientes.

6.    Conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y con el entorno externo.

7.    Deberá derivarse mediante un método repetitivo y controlado por la información obtenida durante el análisis de los requisitos del software.

MODELADO DEL ANÁLISIS

Es la primera representación técnica de un sistema, sin embargo ahora hay dos tendencias que dominan el panorama del modelado del análisis.

ELEMENTOS DEL MODELADO DEL ANÁLISIS

Debe lograr tres objetivos:

1.    Describir lo que requiere el cliente.

2.    Establecer una base para la creación de un diseño de software.

3.    Definir un conjunto de requisitos que se pueda validar una vez que se construye el software.

MODELOS DE DATOS

El diagrama de Entidad-relación se centra solo en los datos. El modelado de datos estudia los datos independientemente del procesamiento que los transforma.

El modelado de datos se compone de tres piezas de información interrelacionadas:

Ø  Objetos de datos.

Ø  Atributos: Propiedades de un objeto.

Ø  Relaciones.

CONCEPTOS Y PRINCIPIOS DE ANÁLISIS

La ingeniería de requisitos es el uso sistemático de procedimientos, técnicas, lenguajes y herramientas para obtener con un coste reducido el análisis, documentación, evolución continua de las necesidades del usuario y la especificación del comportamiento externo de un sistema que satisfaga las necesidades del usuario. Tenga en cuenta que todas las disciplinas de la ingeniería son semejantes, la ingeniería de requisitos no se guía por conductas esporádicas aleatorias o por modas pasajeras, sino que se debe basar en el uso sistemático de aproximaciones contrastadas.

ANÁLISIS DE REQUISITOS

El análisis de requisitos es una tarea de ingeniería de software que cubre el hueco entre las definiciones del software a nivel sistema y el diseño del software. El análisis de requisitos permite al ingeniero der sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interface del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

Puede dividirse en 5 áreas de esfuerzo:

·         Reconocimiento del problema.

·         Evaluación y síntesis.

·         Modelado.

·         Especificación.

·         Revisión.

La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño.

Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global.

PRINCIPIOS DEL ANÁLISIS

Todos los métodos de análisis se relacionan por un conjunto de principios operativos:

1.    Debe representarse y entenderse el dominio de información de un problema.

2.    Debe definirse las funciones que debe realizar el software.

3.    Debe representarse el comportamiento del software.

4.    Debe dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas.

5.    El proceso de análisis deriva ir desde la información esencial hasta el detalle de la implementación.

Davis sugiere un conjunto de principios directrices para la Ingeniería de Requisitos:

·         Entender el problema antes de empezar a crear el modelo del análisis.

·         Desarrollar prototipos que permitan al usuario entender cómo será la interacción hombre-máquina.

·         Registrar el origen y la razón de cada requisito.

·         Usar múltiples planteamientos de requisitos.

o   Reduce probabilidad de que se olvide algo.

o   Aumenta probabilidad de reconocer inconsistencias.

·         Dar prioridad a los requisitos. Cronogramas.

·         Trabajar para eliminar la ambigüedad.

CREACIÓN DE PROTOTIPOS DE SOFTWARE

Se construyen un modelo del software a fabricar denominado prototipo para que lo valore el cliente y el desarrollador.

·         Selección del enfoque de creación de prototipo.

o   Área de aplicación.

o   Complejidad.

o   Características del cliente y del proyecto.

·         Métodos y herramientas. Desarrollo del prototipo.

o   Técnicas de cuarta generación.

o   Componentes de software reutilizable.