CAPÍTULO 4. Paradigmas De La Ingeniería De Software

¿Qué es la Ingeniería del Software?

Liste los diferentes modelos para el desarrollo de software

Describa qué es un lenguaje de programación

Describa las diferencias entre un lenguaje estructurado y uno orientado a objetos

Tratamos de definir que es un paradigma dentro de la ingeniería de software, según varios autores:

Para la Ingeniería de Software, el paradigma es una agrupación de métodos, herramientas y procedimientos con el fin de describir un modelo.

Un paradigma es un modelo para comprender la realidad, que nos permite relacionarnos con el mundo circundante y tener un sentido de identidad dentro de lo que percibimos que es el “mundo real” (Analisis y Diseño de Sistemas, 2011).

Un paradigma de programación es un modelo básico de diseño y desarrollo de programas, que permite producir programas con una directriz específica, tales como: estructura modular, fuerte cohesión, alta rentabilidad, etc. (Olivares, 2011).

En términos generales podemos decir que un paradigma, entendido dentro de la ingeniería de software es una estrategia de desarrollo que acompaña al proceso, los métodos y las herramientas a utilizar.

El paradigma a utilizarse en cada caso de desarrollo se selecciona por los ingenieros de software según la naturaleza del proyecto y la aplicación, los controles y las entregas que se requieren, la complejidad del proyecto y los recursos disponibles.

Tradicionalmente se ha visto la creación del software como una tarea “artesanal” sin una estructura formal o predecible como la que existe en otras disciplinas como por ejemplo la Ingeniería Civil.

Afortunadamente cada vez más se reconoce a la Ingeniería de Software como una disciplina legítima, digna de tener una investigación seria y un estudio cuidadoso. La creación de cuerpos documentales como la guía SWEBOK ha aportado formalidad y estructura a esta disciplina profesional. El ingeniero de software ha sustituido al programador como el título de trabajo preferente y los modelos de procesos de software, métodos de ingeniería de software y herramientas se han adoptado con éxito en un amplio espectro de aplicaciones industriales con lo que los gestores y usuarios reconocen la necesidad de un enfoque más disciplinado.

En un principio, al surgir los primeros lenguajes de programación, se desarrolló una gran cantidad de código. Sin embargo este código era muy difícil de mantener ya que por su naturaleza, estructuras de control de lógica y saltos de ejecución no condicionales, obligaban a saltar de un punto a otro de los programas durante su ejecución o revisión, por lo que este código fue llamado despectivamente código spaghetti.

Ante esto, surgió la necesidad de nuevos métodos para especificar, implantar, comprender y comunicar las estructuras de programación. Surgieron entonces los dos principales paradigmas de la ingeniería de software, el enfoque estructurado y el enfoque orientado a objetos.

El enfoque estructurado.

A finales de los años 1960, Dijkstra estableció las bases de la programación estructurada, demostrando que todo programa podía escribirse utilizando únicamente bloques secuenciales de instrucciones, instrucciones condicionales y bucles.

Los métodos del enfoque estructurado se basan en hacer aproximaciones descendentes donde se descompone el sistema completo en niveles funcionales cada vez más detallados, desde una apreciación global inicial hasta el nivel de detalle necesario para su implementación.

Estos métodos tienen como características primordiales la descomposición funcional del sistema, el modelado de los datos y la representación del flujo de la información. Estos tres aspectos forman las vistas del sistema: La especificación de datos, la especificación de los procesos y la especificación de control. (Pressman R. S., 2002).

Diagramas de Flujo de Datos

El primero de estos métodos en aparecer fue el Diagrama de Flujo de Datos (Data Flow Diagram, DFD), desarrollado por De Marco y popularizado por Yourdan. Este es un método principalmente enfocado a la especificación de los procesos del sistema.

Los diagramas de flujo de datos se asemejan a un grafo que representa los procesos que se realizan con los datos y las transformaciones que se aplican sobre ellos.

Los DFD tienen como característica distintiva el que pueden descomponerse en otros sub-diagramas hasta llegar al nivel de detalle o granularidad que se requiera para completar el diseño, siguiendo una aproximación descendente.

Al nivel más alto o superior, se le denomina nivel de contexto y los procesos que se expresan en los niveles inferiores, donde el detalle es el máximo y ya no pueden descomponerse más, se les conocen como procesos primitivos(Sanchez , Sicilia, & Rodríguez, 2012).

Los Diagramas de Flujo de Datos proporcionan algunas ventajas sobre las explicaciones descriptivas sencillas que pueden hacerse de un sistema y de la forma en que los datos se mueven a través del mismo. Proporcionan libertad para emprender la implementación técnica del sistema en las primeras etapas del análisis. Ofrecen una compresión más profunda de la interrelación entre los sistemas y los subsistemas que lo componen. Permiten una mejor comunicación con los usuarios sobre el conocimiento del sistema actual y facilitan el análisis del sistema propuesto para determinar si se han definido los datos y procesos necesarios.

Simbología

Los diagramas DFD se construyen únicamente con cuatro símbolos básicos, cada uno de ellos representa un componente, Ver Figura 22

Procesos .- Describen las funcionalidades del sistema y se representan con un rectángulo con esquinas redondeadas

Almacenes.- Representan los datos utilizados por el sistema y se muestran con un rectángulo cerrado en el lado izquierdo y abierto en el derecho.

Entidades externas.- Fuentes o destinos de la información del sistema, se representan con un cuadrado doble.

Flujos de datos.- Muestran el trasiego de datos entre las funciones y se representan mediante una flecha.

Figura 22 Simbología de los DFD

El cuadro doble, representa a una entidad externa que puede enviar datos al sistema o recibirlos de él. También se le conoce como origen o destino de los datos y se considera externa al sistema descrito. A cada entidad se le asigna un nombre adecuado. Aunque interactúa con el sistema, se considera fuera de los límites de éste y puede ser otro departamento, un negocio, una persona o una máquina. Se permite repetir la misma entidad en un diagrama con el fin particular de evitar que las líneas de flujo de datos se crucen.

La flecha muestra el movimiento de los datos de un lugar a otro, marcando la punta de la flecha el destino de éstos. Si ocurren flujos de datos simultáneos, se pueden utilizar flechas paralelas. A estos flujos de datos también se les puede describir con un nombre y por lo general representan estructuras de datos, o registros de una base de datos.

El rectángulo con las esquinas redondeadas muestra la presencia de un proceso que transforma los datos. Por lo que los datos que entran a ellos siempre son diferentes a los que salen. Es especialmente delicado el nombrar de manera clara a estos procesos para poder reconocer que es lo que hace. En los diagramas de niveles elevados, estos procesos se nombran según el sistema o sub-sistema que representan. A medida que se profundiza en el detalle se recomienda utilizar una nomenclatura sustantivo-verbo-adjetivo, siendo el sustantivo el resultado del proceso, el verbo el tipo de actividad (calcular, verificar, preparar) y el adjetivo el resultado específico que se produce (nuevo pedido, inventario).

Con lo anterior, algunos ejemplos de nombres de proceso son: Calcular impuestos de ventas, imprimir informe de nuevos pedidos, enviar confirmación al cliente por correo electrónico, etc. (Laudon & Laudon, 2008).

Es una práctica común el asignar un número de identificación a cada uno de los procesos con una nomenclatura que indique su nivel en el diagrama, así por ejemplo, en un primer nivel, encontraremos dos procesos primitivos (1 y 2), en un segundo nivel encontraremos los sub-procesos 1.1 y 1.2 (que son sub-procesos del primitivo 1), 2.1, 2.2 y 2.3 (que son sub-procesos del primitivo 2) y así sucesivamente.

El rectángulo abierto representa el almacén de datos y estos pueden ser manuales, un archivo o una base de datos de computadora. En los Diagramas de Flujo de Datos Lógicos, no se especifica el tipo de almacenamiento ni el lugar. Los almacenes de datos temporales no se incluyen en el diagrama. Al igual que los otros elementos, se le debe asignar un número de referencia única.

Diagrama Entidad-Relación

El modelo de entidad relación es una forma de modelado conceptual donde el mundo se ve como un conjunto de objetos básicos llamados entidades y sus relaciones. Fue desarrollado en 1976 por Peter Chen. Este es un método enfocado a la especificación del control del sistema.

Los elementos fundamentales son por tanto las entidades, sus atributos y sus relaciones.

Una entidad es cualquier objeto que existe y pueden ser concretos o abstractos (un edificio o un evento). La representación de una entidad es un diagrama es un rectángulo etiquetado con el nombre de la entidad.

Un atributo es una propiedad de una entidad como por ejemplo el nombre o el color. Todo atributo tiene un dominio que define el conjunto de valores que puede tomar dicha propiedad en diferentes entidades. Por ejemplo, en la entidad “persona”

...