CAPTULO 4.

Paradigmas de la Ingeniera de Software

Para comenzar veamos lo que ya sabe Recuperacin de informacin inicial Qu es la Ingeniera del Software? Liste los diferentes modelos para el desarrollo de software Describa qu es un lenguaje de programacin Describa las diferencias entre un lenguaje estructurado y uno orientado a objetos

Tratamos de definir que es un paradigma dentro de la ingeniera de software, segn varios autores: Para la Ingeniera de Software, el paradigma es una agrupacin de mtodos, 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 Diseo de Sistemas, 2011). Un paradigma de programacin es un modelo bsico de diseo y desarrollo de programas, que permite producir programas con una directriz especfica, tales como: estructura modular, fuerte cohesin, alta rentabilidad, etc. (Olivares, 2011). En trminos generales podemos decir que un paradigma, entendido dentro de la ingeniera de software es una estrategia de desarrollo que acompaa al proceso, los mtodos y las herramientas a utilizar. El paradigma a utilizarse en cada caso de desarrollo se selecciona por los ingenieros de software segn la naturaleza del proyecto y la aplicacin, los controles y las entregas que se requieren, la complejidad del proyecto y los recursos disponibles. Tradicionalmente se ha visto la creacin del software como una tarea artesanal sin una estructura formal o predecible como la que existe en otras disciplinas como por ejemplo la Ingeniera Civil. Afortunadamente cada vez ms se reconoce a la Ingeniera de Software como una disciplina legtima, digna de tener una investigacin seria y un estudio cuidadoso. La creacin de cuerpos documentales como la gua SWEBOK ha aportado formalidad y estructura a esta disciplina profesional. El ingeniero de software ha sustituido al programador como el ttulo de trabajo preferente y los modelos de procesos de software, mtodos de ingeniera 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 ms disciplinado. En un principio, al surgir los primeros lenguajes de programacin, se desarroll una gran cantidad de cdigo. Sin embargo este cdigo era muy difcil de mantener ya que por su naturaleza, estructuras de control de

lgica y saltos de ejecucin no condicionales, obligaban a saltar de un punto a otro de los programas durante su ejecucin o revisin, por lo que este cdigo fue llamado despectivamente cdigo spaghetti. Ante esto, surgi la necesidad de nuevos mtodos para especificar, implantar, comprender y comunicar las estructuras de programacin. Surgieron entonces los dos principales paradigmas de la ingeniera de software, el enfoque estructurado y el enfoque orientado a objetos.

El enfoque estructurado.

A finales de los aos 1960, Dijkstra estableci las bases de la programacin estructurada, demostrando que todo programa poda escribirse utilizando nicamente bloques secuenciales de instrucciones, instrucciones condicionales y bucles. Los mtodos del enfoque estructurado se basan en hacer aproximaciones descendentes donde se descompone el sistema completo en niveles funcionales cada vez ms detallados, desde una apreciacin global inicial hasta el nivel de detalle necesario para su implementacin. Estos mtodos tienen como caractersticas primordiales la descomposicin funcional del sistema, el modelado de los datos y la representacin del flujo de la informacin. Estos tres aspectos forman las vistas del sistema: La especificacin de datos, la especificacin de los procesos y la especificacin de control. (Pressman R. S., 2002).

Diagramas de Flujo de Datos

El primero de estos mtodos en aparecer fue el Diagrama de Flujo de Datos (Data Flow Diagram, DFD), desarrollado por De Marco y popularizado por Yourdan. Este es un mtodo principalmente enfocado a la especificacin 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 caracterstica distintiva el que pueden descomponerse en otros sub-diagramas hasta llegar al nivel de detalle o granularidad que se requiera para completar el diseo, siguiendo una aproximacin descendente. Al nivel ms alto o superior, se le denomina nivel de contexto y los procesos que se expresan en los niveles inferiores, donde el detalle es el mximo y ya no pueden descomponerse ms, se les conocen como procesos primitivos(Sanchez , Sicilia, & Rodrguez, 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 travs del mismo. Proporcionan libertad para emprender la implementacin tcnica del sistema en las primeras etapas del

anlisis. Ofrecen una compresin ms profunda de la interrelacin entre los sistemas y los subsistemas que lo componen. Permiten una mejor comunicacin con los usuarios sobre el conocimiento del sistema actual y facilitan el anlisis del sistema propuesto para determinar si se han definido los datos y procesos necesarios.

Simbologa

Los diagramas DFD se construyen nicamente con cuatro smbolos bsicos, cada uno de ellos representa un componente, Ver Figura 22 Procesos .- Describen las funcionalidades del sistema y se representan con un rectngulo con esquinas redondeadas Almacenes.- Representan los datos utilizados por el sistema y se muestran con un rectngulo cerrado en el lado izquierdo y abierto en el derecho. Entidades externas.- Fuentes o destinos de la informacin 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 Simbologa de los DFD

El cuadro doble, representa a una entidad externa que puede enviar datos al sistema o recibirlos de l. Tambin 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 interacta con el sistema, se considera fuera de los

lmites de ste y puede ser otro departamento, un negocio, una persona o una mquina. Se permite repetir la misma entidad en un diagrama con el fin particular de evitar que las lneas 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 simultneos, se pueden utilizar flechas paralelas. A estos flujos de datos tambin se les puede describir con un nombre y por lo general representan estructuras de datos, o registros de una base de datos. El rectngulo 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 segn 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 especfico 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 confirmacin al cliente por correo electrnico, etc. (Laudon & Laudon, 2008). Es una prctica comn el asignar un nmero de identificacin 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 subprocesos del primitivo 1), 2.1, 2.2 y 2.3 (que son sub-procesos del primitivo 2) y as sucesivamente. El rectngulo abierto representa el almacn de datos y estos pueden ser manuales, un archivo o una base de datos de computadora. En los Diagramas de Flujo de Datos Lgicos, 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 nmero de referencia nica.

Diagrama Entidad-Relacin

El modelo de entidad relacin es una forma de modelado conceptual donde el mundo se ve como un conjunto de objetos bsicos llamados entidades y sus relaciones. Fue desarrollado en 1976 por Peter Chen. Este es un mtodo enfocado a la especificacin 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 representacin de una entidad es un diagrama es un rectngulo 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 nmero. Los atributos pueden ser tambin valores lgicos (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 lnea continua. Una relacin es una asociacin entre dos o ms entidades. Un ejemplo de una relacin entre las entidades persona y automvil puede ser: propietario. Generalmente las relaciones se establecen entre entidades y se representan mediante rombos etiquetados con el nombre de la relacin. Ver Figura 23 (Sanchez , Sicilia, & Rodrguez, 2012).

Figura 2 Ejemplo de Diagrama Entidad-Relacin

Diccionario de Datos

Este es un mtodo enfocado a la especificacin 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 visin de la informacin 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 compresin de las entradas, salidas, de los componentes de los almacenes y tambin los clculos intermedios. Se relacin con los Diagramas de Flujo de Datos en cuanto a que describen a la informacin entre los flujos de datos y los almacenes del sistema. Actualmente se utilizan expresiones de SQL para la definicin 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 smbolo @ precede a todo identificador, la llaves indican iteracin, el smbolo + representa composicin y los corchetes seleccin (Sanchez , Sicilia, & Rodrguez, 2012). El Diccionario de Datos de utiliza para proporcionar documentacin y eliminar la redundancia pero adems 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 lgica para los procesos del diagrama de flujo de datos.

Diagramas de Estructura

Este es un mtodo enfocado tambin a la especificacin de control. En estos diagramas se derivan de los DFD y se representa la estructura modular de un sistema y la jerarqua de los mdulos que lo componen as como las llamadas entre los mismos. Estos diagramas no slo muestran la descomposicin del sistema si no que agregan informacin sobre la secuencia de la ejecucin (secuencial, repetitiva y alternativa) el control y los datos enviado o recibidos. Estos diagramas se apoyan con tablas de transiciones y rboles de decisin, para expresar las condiciones en las que las reglas de ejecucin se aplican, ya sea en forma de un rbol condicional o mediante matrices de acciones y condiciones(Sanchez , Sicilia, & Rodrguez, 2012).

El enfoque orientado a objetos.

El paradigma de la programacin orientada a objetos se inici a finales de los aos 1960 en Noruega con el desarrollo de un lenguaje conocido como SIMULA. Actualmente este paradigma es el ms utilizado y ha influenciado a prcticamente la totalidad de los lenguajes de programacin recientes tales como Smalltalk, C++, C#, Eiffel o Java. Todos estos lenguajes cumplen con un conjunto de propiedades que identifican a la orientacin a objetos y que estn encaminadas a mejorar la calidad del software producido. Estas propiedades son: Abstraccin: Se reduce la complejidad del dominio abstrayendo hasta el nivel adecuado. En la orientacin a objetos la abstraccin 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 ms clases existentes, de modo tal que la nueva clase hereda las caractersticas de la(s) superclase(s), a las que se aadirn ciertas caractersticas propias. La herencia consiste en que una clase puede heredar sus variables y mtodos a varias subclases (la clase que hereda es llamada superclase o clase padre). Esto significa que una subclase, a parte de los atributos y mtodos propios, tiene incorporados los

atributos y mtodos heredados de la superclase. De esta manera se crea una jerarqua de herencia. La herencia reduce el trabajo de la programacin usando fcilmente objetos comunes. Slo es necesarios declarar que la clase A hereda de la clase B y despus proporcionar cualquier detalle adicional. Los atributos y comportamientos de la clase B son parte de la clase A y no requiere ninguna programacin adicional. Encapsulamiento: Los datos y operaciones de una clase estn organizados para que los clientes de la clase slo necesiten conocer la interfaz pblica de la misma. As sabrn cmo invocarlas porque conocern cmo pueden hacerlo, pero no cmo estn implementadas. El encapsulamiento significa que toda la informacin de un objeto se encuentra empaquetada bajo un nombre y puede reutilizarse como una especificacin o componente de un programa. Polimorfismo: Propiedad que permite que un mismo nombre de mtodo est asociado a distintos comportamientos, pudiendo ser de dos tipos: esttico o dinmico. El polimorfismo esttico consiste en que operaciones con el mismo nombre pueden realizarse sobre distintos tipos de parmetros, lo que se consigue mediante plantillas, elementos genricos o sobrecarga de operadores. El polimorfismo dinmico est ntimamente relacionado con la herencia y acarrea la asignacin tarda o dinmica de memoria, propiedad mediante la cual se determina el mtodo concreto a invocar de entre un abanico de posibles mtodos con la misma interfaz dentro de la jerarqua de clases en tiempo de ejecucin. (Sanchez , Sicilia, & Rodrguez, 2012). En un principio, al ir apareciendo los lenguajes de programacin orientados a objetos, surgieron una serie de mtodos de diseo 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 orientacin 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 cdigo compuesto de variables (atributos) y mtodos 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 caractersticas (tambin llamadas atributos o variables) y comportamientos. Estos comportamientos se implementan en los mtodos que son funciones o subrutinas (en el paradigma estructurado) que estn asociadas a un objeto.

Clase

Una clase es un modelo o un prototipo (un esqueleto, un molde) que define las variables y mtodos 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 caractersticas (atributos), comparten una forma genrica y un tamao uniforme que proviene del molde (la clase) con que fueron cortados. Una clase es una descripcin generalizada que describe una coleccin de objetos con caractersticas similares. Una superclase es una coleccin de clases. Por ejemplo, la clase Automvil y la clase Bicicleta as como la clase Tren, provienen de una superclase llamada Vehculos de transporte. Una instancia de una clase es una forma de llamar a un objeto en particular. Siguiendo la analoga de las galletas, una galleta en particular es una instancia de la clase galleta, que fueron cortadas con el mismo molde.

Atributo

Los atributos estn 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 mayora de los casos, un dominio es simplemente un conjunto de valores especficos. En situaciones ms 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, Profesin. Estos son datos que tiene la clase y que en cada instancia (copia) de esa clase, tendrn valores independientes una de otra. Esta clase pudiera tener los mtodos 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.

Anlisis 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 describindolo a un apropiado nivel de detalle. Los modelos a su vez se representan mediante diagramas, que son representaciones grficas de un conjunto de elementos de modelado y sus relaciones. En UML los diagramas estn clasificados en dos grandes grupos:

Diagramas de estructura, que reflejan la estructura fsica (esttica) del sistema por medio de sus clases, mtodos, 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 ejecucin del sistema para proveer la funcionalidad requerida. (Sanchez , Sicilia, & Rodrguez, 2012).

Diagramas de estructura Los diagramas de estructuras se construyen con los siguientes componentes, (Sanchez , Sicilia, & Rodrguez, 2012): Clases: Es el diagrama ms 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 instanciacin de un diagrama de clases en un determinado punto en el tiempo. Componentes: Describe los componentes que conforman una aplicacin, sus interrelaciones e interfaces pblicas. Estructura compuesta: Permite visualizar de manera grfica las partes que definen la estructura interna de un clasificador, incluyendo sus puntos de interaccin con otras partes del sistema. Paquetes: Muestran la organizacin 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 fsica de un sistema, los nodos en sus entornos de ejecucin y como se conectan.

Diagramas dinmicos o de comportamiento Los diagramas dinmicos o de comportamiento contienen los siguientes elementos, (Sanchez , Sicilia, & Rodrguez, 2012): Actividad: Muestra los procesos de negocio y flujos de datos Comunicacin: Muestra la organizacin estructural de los objetos y el paso de mensajes entre ellos. Interaccin: Variante del diagrama de actividades para mostrar el flujo de control de un sistema o proceso de negocio. Secuencia: Modela la secuencia temporal lgica 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 condicin 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 diseo orientado a objetos

En un buen diseo orientado a objetos se aspira a alcanzar una serie de principios que permiten conseguir los objetivos de un bajo acoplamiento y una alta cohesin. Estos principios son: Principio abierto-cerrado: Expresado por Meyer en 1999 establece que un mdulo debera estar a la vez abierto (que siempre sea posible ampliarlo) y cerrado (que no sea posible editar ni modificar funcionalidades del mismo que estn en funcionamiento). Principio de responsabilidad nica: Introducido por DeMarco en 1979 en el diseo estructurado, est relacionado con el concepto de cohesin pues aboga por que una clase debe tener slo una razn para cambiar lo que lleva a que cada clase tenga una nica responsabilidad. Principio de separacin de la interfaz. Los clientes no deberan ser forzados a depender de interfaces que no utilizan. En otras palabras, es preferible tener muchas interfaces especficas que una sola interfaz de propsito general. Principio de sustitucin de Liskov: La herencia ha de garantizar que cualquier propiedad que sea cierta para los objetos de la clase, tambin 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 debera tener solamente un conocimiento limitado sobre otras unidades slo conocer las unidades con quines tiene que relacionarse una unidad-. Informalmente descrita como no hables con extraos. Esta ley busca mejorar el acoplamiento entre clases. Principio de inversin de dependencias. Establece que: 1.- Los mdulos de alto nivel no deben depender de los mdulos 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 diseo deberan ir encaminadas a la estabilidad de los paquetes, midindose la estabilidad por el nmero de dependencias de entrada y salida de un paquete. Cuantas ms dependencias de entrada ms estable necesitar un paquete ser, ya que cualquier cambio afectar a todos los paquetes que dependen de l (Sanchez , Sicilia, & Rodrguez, 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 prstamo de libros a los estudiantes de una universidad en una biblioteca. Desarrolle los diagramas DFD para el sistema general de prstamo de libros, los procesos de reserva de libros, clculo de las multas por retraso en devoluciones, validacin de posibilidad de prstamos y consultas en el catlogo de libros. o Partiendo del ejemplo anterior, describa los objetos, las clases a las que pertenecen estos y los mtodos y atributos que tendrn los objetos necesarios para la elaboracin de este sistema. Elabore el diagrama de casos de uso, objetos y clases para este sistema