CAPÍTULO 4. Paradigmas de la Ingeniería de Software

Para comenzar veamos lo que ya sabe

Recuperación de información inicial

¿Qué es la Ingeniería del Software?Liste los diferentes modelos para el desarrollo de softwareDescriba qué es un lenguaje de programaciónDescriba 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 redondeadasAlmacenes.- 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 1 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” un atributo puede ser “nombre” y el dominio es “cadenas de caracteres”.

Otro atributo puede ser “edad” y su dominio “número”. Los atributos pueden ser también valores lógicos (verdadero o falso). En un diagrama los atributos se representan como una elipse que se une a a la entidad a la que califica con una línea continua.

Una relación es una asociación entre dos o más entidades. Un ejemplo de una relación entre las entidades “persona” y “automóvil” puede ser: “propietario”. Generalmente las relaciones se establecen entre entidades y se representan mediante rombos etiquetados con el nombre de la relación. Ver Figura 23 (Sanchez , Sicilia, & Rodríguez, 2012).

Figura 2 Ejemplo de Diagrama Entidad-Relación

Diccionario de Datos

Este es un método enfocado a la especificación de los datos de un sistema. Los diccionarios de datos contienen los datos utilizados en el sistema para que todos los involucrados tengan la misma visión de la información manejada.

El Diccionario de Datos es un listado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tengan una misma compresión de las entradas, salidas, de los componentes de los almacenes y también los cálculos intermedios.

Se relación con los Diagramas de Flujo de Datos en cuanto a que describen a la información entre los flujos de datos y los almacenes del sistema.

Actualmente se utilizan expresiones de SQL para la definición del Diccionario de Datos ya que se ha convertido en la “lingua franca”, pero anteriormente se utilizaban notaciones como la siguiente:

CLIENTE= @IFE + NOMBRE_CLIENTE + DIRECCION + {NUM_TEL}

DIRECCION= [CALLE + NUM + ESTADO | APT_CORREOS]

Donde el símbolo @ precede a todo identificador, la llaves indican iteración, el símbolo + representa composición y los corchetes selección (Sanchez , Sicilia, & Rodríguez, 2012).

El Diccionario de Datos de utiliza para proporcionar documentación y eliminar la redundancia pero además sirve para:

Validar la integridad y exactitud del diagrama de flujo de datos. Proporcionar un punto de partida para desarrollar pantallas e informes. Determinar el contenido de los datos almacenados en archivos. Desarrollar la lógica para los procesos del diagrama de flujo de datos.

Diagramas de Estructura

Este es un método enfocado también a la especificación de control. En estos diagramas se derivan de los DFD y se representa la estructura modular de un sistema y la jerarquía de los módulos que lo componen así como las llamadas entre los mismos. Estos diagramas no sólo muestran la descomposición del sistema si no que agregan información sobre la secuencia de la ejecución (secuencial, repetitiva y alternativa) el control y los datos enviado o recibidos.

Estos diagramas se apoyan con tablas de transiciones y árboles de decisión, para expresar las condiciones en las que las reglas de ejecución se aplican, ya sea en forma de un árbol condicional o mediante matrices de acciones y condiciones(Sanchez , Sicilia, & Rodríguez, 2012).

El enfoque orientado a objetos.

El paradigma de la programación orientada a objetos se inició a finales de los años 1960 en Noruega con el desarrollo de un lenguaje conocido como SIMULA. Actualmente este paradigma es el más utilizado y ha influenciado a prácticamente la totalidad de los lenguajes de programación recientes tales como Smalltalk, C++, C#, Eiffel o Java. Todos estos lenguajes cumplen con un conjunto de propiedades que identifican a la orientación a objetos y que están encaminadas a mejorar la calidad del software producido.

Estas propiedades son:

Abstracción: Se reduce la complejidad del dominio abstrayendo hasta el nivel adecuado. En la orientación a objetos la abstracción se representa mediante el concepto de clase, que representa un conjunto de objetos concretos, llamados instancias, que tienen propiedades y operaciones comunes.Herencia: Esta propiedad permite definir una clase a partir de otras – una o más – clases existentes, de modo tal que la nueva clase hereda las características de la(s) superclase(s), a las que se añadirán ciertas características propias. La herencia consiste en que una clase puede heredar sus variables y métodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, a parte de los atributos y métodos propios, tiene incorporados los

atributos y métodos heredados de la superclase. De esta manera se crea una jerarquía de herencia. La herencia reduce el trabajo de la programación usando fácilmente objetos comunes. Sólo es necesarios declarar que la clase A hereda de la clase B y después proporcionar cualquier detalle adicional. Los atributos y comportamientos de la clase B son parte de la clase A y no requiere ninguna programación adicional.Encapsulamiento: Los datos y operaciones de una clase están organizados para que los clientes de la clase sólo necesiten conocer la interfaz pública de la misma. Así sabrán cómo invocarlas porque conocerán cómo pueden hacerlo, pero no cómo están implementadas. El encapsulamiento significa que toda la información de un objeto se encuentra empaquetada bajo un nombre y puede reutilizarse como una especificación o componente de un programa.Polimorfismo: Propiedad que permite que un mismo nombre de método esté asociado a distintos comportamientos, pudiendo ser de dos tipos: estático o dinámico. El polimorfismo estático consiste en que operaciones con el mismo nombre pueden realizarse sobre distintos tipos de parámetros, lo que se consigue mediante plantillas, elementos genéricos o sobrecarga de operadores. El polimorfismo dinámico está íntimamente relacionado con la herencia y acarrea la asignación tardía o dinámica de memoria, propiedad mediante la cual se determina el método concreto a invocar – de entre un abanico de posibles métodos con la misma interfaz dentro de la jerarquía de clases – en tiempo de ejecución. (Sanchez , Sicilia, & Rodríguez, 2012).

En un principio, al ir apareciendo los lenguajes de programación orientados a objetos, surgieron una serie de métodos de diseño orientado a objetos con distintas herramientas y notaciones. Pasado el tiempo, se han ido aglutinando estas herramientas y se han consolidado en lo que se conoce como UML (Unified Modeling Languaje – Lenguaje unificado de modelado) y en el Proceso Unificado.

Este lenguaje sirve para visualizar, especificar, construir y documentar sistemas en general, pero está especialmente adaptado para sistemas de software construidos mediante el paradigma de la orientación a objetos. UML es independiente del proceso que se siga, pero se liga generalmente a procesos iterativos o incrementales como el Proceso Unificado.

Existen una serie de conceptos dentro del enfoque orientado a objetos, que es necesario definir:

Objeto

Un objeto es una unidad de código compuesto de variables (atributos) y métodos relacionados. Un objeto mantiene en su interior datos, operaciones, otros objetos y constantes. Estos objetos pueden ser entidades externas, ocurrencias, eventos, estructuras, etc. Los objetos tienen características (también llamadas atributos o variables) y comportamientos. Estos comportamientos se implementan en los métodos que son funciones o subrutinas (en el paradigma estructurado) que están asociadas a un objeto.

Clase

Una clase es un modelo o un prototipo (un esqueleto, un molde) que define las variables y métodos comunes a todos los objetos de cierta clase. En algunas ocasiones se ejemplifica con un molde para galletas. La clase es el molde con el que se cortan las galletas a partir de la masa sin forma. Todas las galletas (objetos) aunque son individuales y tienen sus propias características (atributos), comparten una forma genérica y un tamaño uniforme que proviene del molde (la clase) con que fueron cortados.

Una clase es una descripción generalizada que describe una colección de objetos con características similares.

Una superclase es una colección de clases. Por ejemplo, la clase “Automóvil” y la clase “Bicicleta” así como la clase “Tren”, provienen de una superclase llamada “Vehículos de transporte”.

Una instancia de una clase es una forma de llamar a un objeto en particular. Siguiendo la analogía de las galletas, una galleta en particular es una instancia de la clase “galleta”, que fueron cortadas con el mismo molde.

Atributo

Los atributos están asociados a clases y objetos, ellos describen la clase y el objeto de alguna manera. Un atributo puede tomar un valor definido por un dominio enumerado. En la mayoría de los casos, un dominio es simplemente un conjunto de valores específicos. En situaciones más complejas, el dominio puede ser un conjunto completo de clases.

Para citar un ejemplo. Podemos definir una Clase con el nombre “Persona” y que tenga los atributos “Edad”, “Sexo”, “Profesión”. Estos son datos que tiene la clase y que en cada instancia (copia) de esa clase, tendrán valores independientes una de otra. Esta clase pudiera tener los métodos tales como “Dar de alta”, “Subir”, “Contratar”, que son las operaciones (o instrucciones) a las que la clase responde y que por lo general modifican los atributos (datos) que contiene.

Análisis dentro del enfoque orientado a objetos

En el enfoque orientado a objetos, los sistemas se describen utilizando modelos y diagramas. Un modelo captura una vista de un sistema abstrayendo y describiéndolo a un apropiado nivel de detalle. Los modelos a su vez se representan mediante diagramas, que son representaciones gráficas de un conjunto de elementos de modelado y sus relaciones.

En UML los diagramas están clasificados en dos grandes grupos:

Diagramas de estructura, que reflejan la estructura física (estática) del sistema por medio de sus clases, métodos, atributos, interfaces, paquetes, etc. y sus relaciones.Diagramas de comportamiento, que muestran la forma en que los distintos elementos del sistema interaccionan, colaboran y cambian de estado durante la ejecución del sistema para proveer la funcionalidad requerida. (Sanchez , Sicilia, & Rodríguez, 2012).

Diagramas de estructura

Los diagramas de estructuras se construyen con los siguientes componentes, (Sanchez , Sicilia, & Rodríguez, 2012):

Clases: Es el diagrama más importante. Muestra un conjunto de clases, interfaces y colaboraciones con sus relaciones.Objetos: Muestra un conjunto de objetos y sus relaciones en un cierto estado. Generalmente, representan la instanciación de un diagrama de clases en un determinado punto en el tiempo.Componentes: Describe los componentes que conforman una aplicación, sus interrelaciones e interfaces públicas.Estructura compuesta: Permite visualizar de manera gráfica las partes que definen la estructura interna de un clasificador, incluyendo sus puntos de interacción con otras partes del sistema.Paquetes: Muestran la organización en paquetes de los diferentes elementos que conforman el sistema, permitiendo especificar de manera visual el nombre de los espacios de nombres.Despliegue: Muestra la arquitectura física de un sistema, los nodos en sus entornos de ejecución y como se conectan.

Diagramas dinámicos o de comportamiento

Los diagramas dinámicos o de comportamiento contienen los siguientes elementos, (Sanchez , Sicilia, & Rodríguez, 2012):

Actividad: Muestra los procesos de negocio y flujos de datosComunicación: Muestra la organización estructural de los objetos y el paso de mensajes entre ellos.Interacción: Variante del diagrama de actividades para mostrar el flujo de control de un sistema o proceso de negocio.Secuencia: Modela la secuencia temporal lógica de mensajes entre participantes (generalmente clases).Estados: Describe los distintos estados en que puede encontrarse un objeto, junto con las transiciones entre los mismos. Muy útil para representar el comportamiento de clases complejas.Tiempos: Muestra los cambios de estado o condición producidos en los objetos por eventos externos.Casos de uso: Representa funcionalidades del sistema mediante casos de uso, actores y relaciones entre ellos.

Principios del diseño orientado a objetos

En un buen diseño orientado a objetos se aspira a alcanzar una serie de principios que permiten conseguir los objetivos de un bajo acoplamiento y una alta cohesión. Estos principios son:

Principio abierto-cerrado: Expresado por Meyer en 1999 establece que un módulo debería estar a la vez abierto (que siempre sea posible ampliarlo) y cerrado (que no sea posible editar ni modificar funcionalidades del mismo que estén en funcionamiento).Principio de responsabilidad única: Introducido por DeMarco en 1979 en el diseño estructurado, está relacionado con el concepto de cohesión pues aboga por que una clase debe tener sólo una razón para cambiar lo que lleva a que cada clase tenga una única responsabilidad.Principio de separación de la interfaz. Los clientes no deberían ser forzados a depender de interfaces que no utilizan. En otras palabras, es preferible tener muchas interfaces específicas que una sola interfaz de propósito general.Principio de sustitución de Liskov: La herencia ha de garantizar que cualquier propiedad que sea cierta para los objetos de la clase, también lo sea para los objetos de sus subclases. En otras palabras, las subclases deben poder sustituirse por la clase base.Ley de Demeter: Establece que cada unidad debería tener solamente un conocimiento limitado sobre otras unidades – sólo conocer las unidades con quiénes tiene que relacionarse una unidad-. Informalmente descrita como “no hables con extraños”. Esta ley busca mejorar el acoplamiento entre clases.Principio de inversión de dependencias. Establece que:1.- Los módulos de alto nivel no deben depender de los módulos de bajo nivel, pues ambos deben depender de las abstracciones. 2.- Las abstracciones no deben depender de los detalles, si no los detalles de las abstracciones.Principio de dependencias estables: Introducido por Martin en 1995. Las dependencias entre paquetes en un diseño deberían ir encaminadas a la estabilidad de los paquetes, midiéndose la estabilidad por el número de dependencias de entrada y salida de un paquete. Cuantas más dependencias de entrada más estable necesitará un paquete ser, ya que cualquier cambio afectará a todos los paquetes que dependen de él (Sanchez , Sicilia, & Rodríguez, 2012).

Desarrollo de competencias.

Actividad para el portafolio de evidencias

Actividad colaborativa:

En triadas desarrollen los siguientes ejercicios:o Asumiendo la necesidad del desarrollo de un sistema para administrar el préstamo de

libros a los estudiantes de una universidad en una biblioteca. Desarrolle los diagramas DFD para el sistema general de préstamo de libros, los procesos de reserva de libros, cálculo de las multas por retraso en devoluciones, validación de posibilidad de préstamos y consultas en el catálogo de libros.

o Partiendo del ejemplo anterior, describa los objetos, las clases a las que pertenecen estos y los métodos y atributos que tendrán los objetos necesarios para la elaboración de este sistema. Elabore el diagrama de casos de uso, objetos y clases para este sistema