UNIDAD 3 INGENIERIA DE SOFTWARE

3.1  DESCOMPOSICIÓN MODULAR.

 
Descomposición Modular o Modularización es el proceso de descomposición de un sistema en un conjunto de elementos con un índice bajo acoplamiento (independientes) y alto índice de cohesión (con significado propio).
 

Consiste en descomponer el problema a resolver en módulos o tareas más simples. Cada tarea representa una actividad completa y se codifica de manera independiente. Facilita el diseño descendente del problema, centrándonos cada vez en la resolución de subproblemas de magnitud inferior.

A la resolución de cada uno de estos subproblemas de complejidad inferior se denomina refinamiento por pasos. Los módulos pueden ser planificados, codificados, comprobados y depurados independientemente, y a continuación se combinan uno a uno con otros módulos.

 

Abstracción procedimental.

Con este concepto se hace referencia a la necesidad de separar el propósito de un subprograma de suimplementación.

 Consideraciones:

• Cada algoritmo que resuelve el diseño de un módulo equivale a una caja negra que ejecuta una tarea determinada.
• Cada caja negra especifica lo que hace pero no cómo lo hace.
• Cada caja negra puede utilizar a cualquiera de las demás cajas negras.

Normalmente, estas cajas negras se implementan como subprogramas: procedimientos y funciones.

Abstracción de datos.

Pretende separar el concepto de datos y operaciones necesarias para operar con los datos, de su representación e implementación respectivamente. La materialización de este concepto son los Tipos de Datos Abstractos (TDA) que se definen como una colección de datos y un conjunto de operaciones sobre estos datos.

Ocultamiento de información.

Facilitará las diversas abstracciones, ocultando y evitando que se pueda acceder a la representación e implementación de los módulos y TDA. Se consigue haciendo uso de facilidades aportadas por el lenguaje de programación.

Programación orientada a objetos

Paradigma de programación que hace uso de todos conceptos anteriores y algunos más para el desarrollode software.

 
Descomposición modular mediante diseño descendente.

Cuando crece un programa las tareas de programación se hacen más difíciles. La diferencia entre un programa modular grande y pequeño influye solamente en el número de módulos.

 Tiene un impacto positivo en los siguientes aspectos de programación:

     Construcción del programa. Pueden trabajar diversos desarrolladores gracias a la independencia de los módulos.

     Depuración del programa. Se centrará en cada uno de los módulos por separado y posteriormente se comprobará la interacción.

     Legibilidad del código.

     Eliminación de código redundante.

 
Ideas fundamentales.

     Reducir el esfuerzo de desarrollo.

     Separación entre estructuras de datos y procedimientos.

     Independencia funcional: Cada módulo debe realizar una tarea concreta que afecte lo menor posible al resto.

     Ocultamiento de Información: La información de un módulo es inaccesible para el resto de módulos.

 

Ventajas:

§  Evita la propagación de errores

§  Facilita las interfaces e independiza la codificación

 

Conceptos:

§  Acoplamiento: Grado de interdependencia de los módulos

§  Cohesión: Grado del alcance de la tarea de un módulo

 

Criterios a seguir durante el diseño:

v Reducir acoplamiento

v Aumentar la cohesión

v Conseguir módulos con interfaces sencillas

 

Abstracción y encapsulamiento

Idea principal: Definir una parte de un sistema de modo que puede ser comprendido por si mismo, como una unidad, sin conocimiento de sus detalles específicos. Solo será necesario saber el modo de interaccionar con dicha unidad.

Dos tipos:

• Abstracción procedimental

Los módulos se ven como cajas negras con una determinada funcionalidad que a su vez pueden hacer uso de otras cajas negras.

 
• Abstracción de datos

Los datos son vistos como elementos sobre los que se pueden realizar un conjunto de operaciones predefinidas. En ningún momento se tiene conocimiento de su representación o implementación de las operaciones.

 
Modificabilidad

Una buena descomposición modular facilitará la modificabilidad del código. Pequeños cambios en los requisitos de un programa modular normalmente requieren un cambio pequeño sólo en algunos de sus módulos.

Vendrá condicionado por los siguientes aspectos:

–      Acoplamiento débil. Los módulos deben ser independientes entre sí.

–      Cohesión fuerte. Las tareas de cada módulo deben estar bien definidas.

 

Se debe perseguir que los cambios debidos a modificaciones afecten a la menor cantidad de módulos posible.

3.2 PATRÓN DE DISEÑO

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Objetivos de los patrones                                                                   

Los patrones de diseño pretenden:

Ø  Proporcionar catálogos de elementos reusables en el diseño de sistemas software.

Ø  Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.

Ø  Formalizar un vocabulario común entre diseñadores.

Ø  Estandarizar el modo en que se realiza el diseño.

Ø  Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Asimismo, no pretenden:

• Imponer ciertas alternativas de diseño frente a otras.
• Eliminar la creatividad inherente al proceso de diseño.

No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".

Categorías de patrones

Según la escala o nivel de abstracción:

      Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software.

      Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas de software.

      Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.

Además, también es importante reseñar el concepto de "antipatrón de diseño", que con forma semejante a la de un patrón, intenta prevenir contra errores comunes de diseño en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseños muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejón sin salida por haber cometido los mismos errores.

Además de los patrones ya vistos actualmente existen otros patrones como el siguiente:

• Interacción: Son patrones que nos permiten el diseño de interfaces web.

Estructuras o plantillas de patrones

Para describir un patrón se usan plantillas más o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicación uniforme entre diseñadores. Varios autores eminentes en esta área han propuesto plantillas ligeramente distintas, si bien la mayoría definen los mismos conceptos básicos.

La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados:

      Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).

      Clasificación del patrón: creacional, estructural o de comportamiento.

      Intención: ¿Qué problema pretende resolver el patrón?

      También conocido como: Otros nombres de uso común para el patrón.

      Motivación: Escenario de ejemplo para la aplicación del patrón.

      Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.

      Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.

      Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.

      Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.

      Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.

      Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.

      Código de ejemplo: Código fuente ejemplo de implementación del patrón.

      Usos conocidos: Ejemplos de sistemas reales que usan el patrón.

      Patrones relacionados: Referencias cruzadas con otros patrones.

 

3.3 ARQUITECTURAS DE DOMINIO ESPECÍFICO (DSSA).

 

Son arquitecturas diseñadas para cubrir un sistema o una familia de sistemas pero muy centradas en un área o dominio determinado y enfocadas a la reutilización.
 
Pasos para su construcción:

1. Definición del dominio.

2. Definición de requisitos y conceptos del dominio específico.

3. Definición de restricciones de implementación del dominio.

4. Desarrollo de modelos y arquitecturas del dominio.

5. Generación de productos reutilizables.

 
Arquitecturas de Software Reutilizables

El objetivo principal es poder reutilizar partes de una arquitectura, modelos arquitectónicos, arquitecturas de referencia o componentes de la misma de manera que no sea necesario volver a diseñar el modelo completo. Utilizan componentes reutilizables y se obtienen, generalmente, mediante procesos de Ingeniería del Dominio. De esta forma es posible obtener un ahorro de costes y tiempo en la creación de nuevos sistemas de software.

 

3.4  DISEÑO SOFTWARE ARQUITECTURA MULTIPROCESADOR

Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razón es porque actualmente la mayoría de las CPU’s sólo pueden ejecutar un proceso cada vez. La única forma de que se ejecuten de forma simultánea varios procesos es tener varias CPU’s (ya sea en una máquina o en varias, en un sistema distribuido.
La ventaja de un sistema multiproceso reside en la operación llamada cambio de contexto. Esta operación consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.El multiproceso no es algo difícil de entender: más procesadores significa más potencia computacional.

 

 Un conjunto de tareas puede ser completado más rápidamente si hay varias unidades de proceso ejecutándolas en paralelo. Esa es la teoría, pero otra historia es la práctica, como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del hardware como del software.

Es necesario conocer ampliamente como están interconectados dichos procesadores, y la forma en que el código que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y software que aproveche al máximo sus prestaciones.

3.5  ARQUITECTURAS CLIENTE SERVIDOR.

 Esta arquitectura un modelo para el desarrollo de sistemas de información en el que las transacciones se dividen en procesos independientes que cooperan entre sí para intercambiar información, servicios o recursos.

 Se denomina cliente al proceso que inicia el diálogo o solicita los recursos y servidor al proceso que responde a las solicitudes.

En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente permanece sólo lo particular de cada usuario.Los clientes realizan generalmente funciones como:

 

• Manejo de la interfaz de usuario.

• Captura y validación de los datos de entrada.

• Generación de consultas e informes sobre las bases de datos.

• Por su parte los servidores realizan, entre otras, las siguientes funciones:

• Gestión de periféricos compartidos.

• Control de accesos concurrentes a bases de datos compartidas.

• Enlaces de comunicaciones con otras redes de área local o extensa.

 

Siempre que un cliente requiere un servicio lo solicita al servidor correspondiente y éste le responde proporcionándolo. Normalmente, pero no necesariamente, el cliente y el servidor están ubicados en distintos procesadores. Los clientes se suelen situar en ordenadores personales y/o estaciones de trabajo y los servidores en procesadores departamentales o de grupo.

Entre las principales características de la arquitectura cliente/servidor se pueden destacar las siguientes:

• El servidor presenta a todos sus clientes una interfaz única y bien definida.

• El cliente no necesita conocer la lógica del servidor, sólo su interfaz externa.

• El cliente no depende de la ubicación física del servidor, ni del tipo de equipo físico en el que se encuentra, ni de su sistema operativo.

• Los cambios en el servidor implican pocos o ningún cambio en el cliente

 

3.6 DISEÑO DE SOFTWARE DISTRIBUIDO

Sistemas cuyos componentes hardware y software, que están en ordenadores conectados en red, se comunican y coordinan sus acciones mediante el paso de mensajes, para el logro de un objetivo.

Se establece la comunicación mediante un protocolo prefijado por un esquema cliente-servidor.

Características:

• Concurrencia.- Esta característica de los sistemas distribuidos permite que los recursosdisponibles en la red puedan ser utilizados simultáneamente por los usuarios y/o agentes que interactúan en la red.

 
• Carencia de reloj global.- Las coordinaciones para la transferencia de mensajes entre los diferentes componentes para la realización de una tarea, no tienen una temporización general, esta más bien distribuida a los componentes.

• Fallos independientes de los componentes.- Cada componente del sistemapuede fallar independientemente, con lo cual los demás pueden continuar ejecutando sus acciones. Esto permite el logro de las tareas con mayor efectividad, pues el sistema en su conjunto continua trabajando.

 

Evolución:

Procesamiento central (Host).- Uno de los primeros modelos de ordenadores interconectados, llamados centralizados, donde todo el procesamiento de la organización se llevaba a cabo en una sola computadora, normalmente un Mainframe, y los usuarios empleaban sencillos ordenadores personales.

 
Los problemas de este modelo son:

• Cuando la carga de procesamiento aumentaba se tenía que cambiar el hardware del Mainframe, lo cual es más costoso que añadir más computadores personales clientes o servidores que aumenten las capacidades.

 
• El otro problema que surgió son las modernas interfases gráficas de usuario, las cuales podían conllevar a un gran aumento de tráfico en los medios de comunicación y por consiguiente podían colapsar.

 

3.7 DISEÑO DE SOFTWARE DE TIEMPO REAL.

El software de tiempo real esta muy acoplado con el mundo externo, esto es, el software de tiempo real debe responder al ámbito del problema en un tiempo dictado por el ámbito del problema. Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseño del software esta conducido frecuentemente, tanto por la arquitectura del hardware como por la del software, por las características del sistema operativo, por los requisitos de la aplicación y tanto por los extras del lenguaje de programación como prospectos de diseño.

La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, así como contar el tiempo, optimizar el gasto de gasolina de nuestras ultimas generaciones de coches y programar a nuestros aparatos.

Todas estas interacciones con las computadoras sean útiles o intrusivas son ejemplos de computación de tiempo real. La computadora esta controlando algo que interactua con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interacción.

Los sistemas de tiempo real generan alguna acción en respuesta a sucesos externos. Para realizar esta función, ejecutan una adquisición y control de datos a alta velocidad bajo varias ligaduras de tiempo y fiabilidad.

 

Debido a que estas ligaduras son muy rigurosas, los sistemas de tiempo real están frecuentemente dedicados a una única aplicación.