unidad VI Diseño y arquitectura de Software

INTRODUCCIÓN

A continuación les mostraremos en el transcurso del tema los conceptos, descripciones y ejemplos explícitos del diseño y arquitectura de software así como la descomposición modular y arquitectura de dominio especifico.

El diseño y arquitectura de software se podría definir como a las técnicas de ingeniería para crear un portafolio de sistemas de software similares, a partir de un conjunto compartido de activos de software, usando un medio común de producción según Krueger.

Mas adelante también hablaremos acerca de la descomposición modular que es el diseño modular que propone dividir el sistema en partes diferenciadas y definir sus interfaces.

Al igual que la arquitectura de domino especifico que nos da a entender que se tratan de dos tipos genéricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-servidor y los servidores y los clientes se tratan de forma diferente en estos sistemas.

En el contenido del tema se dejará mas claro y de forma sencilla y coherente cada uno de los puntos a seguir.

UNIDAD 6:  DISEÑO Y ARQUITECTURA DE SOFTWARE

La idea básica:

*Ensamblaje de partes de software previamente elaboradas

*Inspirada en los procesos de producción de sistemas físicos

*Producción de aviones, vehículos, computadores, aparatos electrónicos, etc.

*Fundamentada en la Reutilización de Software

*Asume la existencia de una industria de partes

Definición:

*Se refieren a técnicas de ingeniería para crear un portafolio de sistemas de software similares, a partir de un conjunto compartido de activos de software, usando un medio común de producción” (Krueger, 2006)

*Es un conjunto de sistemas de software que comparten un conjunto común y gestionado de aspectos que satisfacen las necesidades específicas de un segmento de mercado o misión y que son desarrollados a partir de un conjunto común de activos fundamentales [de software] de una manera prescrita” (Clements and Northrop, 2002)

*Consiste de una familia de sistemas de software que tienen una funcionalidad común y alguna funcionalidad variable” (Gomma, 2004)

Beneficios

*La entrega de productos de software de una manera

*más rápida,

*económica y

*con una mejor calidad

*Las LPS producen mejoras en:

*Tiempo de entrega del producto (time to market)

*Costos de ingeniería

*Tamaño del portafolio de productos

*Reducción de las tasas de defectos

*Calidad de los productos

*Beneficios tácticos y estratégicos (Krueger, 2006):

*Beneficios tácticos de ingeniería:

*Reducción en el tiempo promedio de creación y entrega de nuevos productos

*Reducción en el número promedio de defectos por producto

*Reducción en el esfuerzo promedio requerido para desarrollar y mantener los productos

*Reducción en el costo promedio de producción de los productos

*Incremento en el número total de productos que pueden ser efectivamente desplegados y mantenidos Aspectos fundamentales

*El paradigma de desarrollo de software LPS requiere que las empresas que lo adopten consideren:

*Aspectos conceptuales

*Conceptos en los que las LPS se fundamentan

*Aspectos tecnológicos

*Qué tecnologías son fundamentales para desarrollar y mantener activos y productos de software

*Aspectos metodológicos

*Cómo desarrollar y mantener los activos y productos de software

*Aspectos organizativos

*Cómo debe la empresa organizarse internamente

*Aspectos gerenciales

*Cómo gestionar los proyectos de desarrollo de activos y productos

6.1 DESCOMPOSICION MODULAR

El diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. sus ventajas: claridad, reducción de costos y reutilización.

Los pasos a seguir son:

1. Identificar los módulos

2. Describir cada módulo

3. Describir las relaciones entre módulos

Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficiente validad.

1. Independencia funcional

2. Acoplamiento

3. Cohesión

4. Comprensibilidad

5. Adaptabilidad

a) Independencia funcional

Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre módulos al mínimo.

Para medir la independencia funcional hay dos criterios: acoplamiento y cohesión

b) Acoplamiento

El acoplamiento es una medida de la interconexión entre módulos en la estructura del programa. Podemos graduar en un amplio espectro, pero por lo general se tiende a que el acoplamiento sea lo menor posible, esto es a reunir las interconexiones entre los distintos módulos en que se estructure nuestra aplicación. El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la complejidad de la interface:

. Fuerte

– Por contenido, cuando desde un módulo se puede cambiar datos locales de otro.

– Común, se emplea una zona común de datos a la que tienen acceso varios módulos.

. Moderado

– De control, la zona común es un dispositivo externo al que están ligados los módulos, esto implica que un cambio en el formato de datos los afecta a todos.

– Por etiqueta, en o intercambio de datos se realiza mediante una referencia a la estructura completa de datos(vector, pila, árbol, grafo,…)

. Débil

– De datos, viene dado por los datos que intercambian los módulos. Es el mejor.

– Sin acoplamiento directo , es el acoplamiento que no existe

c) Cohesión

Un módulo coherente ejecuta una tarea sencilla en un procedimiento de sw y requiere poca interacción con procedimientos que se ejecutan en otras partes de un programa. podemos decir que un módulo coherente es aquel que intenta realizar solamente una cosa.

Para que n° de módulos no sea demasiado elevado y complique el diseño se tratan de agrupar elementos afines y relacionados en un mismo módulo.

• ALTA

. Cohesión abstraccional, se logra cuando se diseña el módulo como tipo abstracto de datos o como una clase de objetos

. Cohesión funcional, el módulo realiza una función concreta y específica

• MEDIA

. Cohesión secuencial, los elementos del módulo trabajan de forma secuencial

. Cohesión de comunicación, elementos que operan con el mismo conjunto de datos de entrada o de salida

. Cohesión temporal, se agrupan elementos que se ejecutan en el mismo momento. Ej. Arrancar o parar dispositivos

• BAJA

. Cohesión lógica, se agrupan elementos que realizan funciones similares.

. Cohesión coincidental, es la peor y se produce cuando los elementos de un módulo no guardan relación alguna

La descripción del comportamiento de un módulo permite establecer el grado de cohesión:

– Si es una frase compuesta y contiene más de un verbo la cohesión será MEDIA

– Si contiene expresiones secuenciales (primero, entonces, cuando…), será temporal o secuencial

– Si la descripción no se refiere a algo especifico(Ej. Todos los errores), cohesión lógica

– Si aparece “inicializar”, “preparar”, “configurar”, probablemente sea temporal.

d) Comprensibilidad

Para facilitar los cambios, el mantenimiento y la reutilización de módulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero además es deseable:

– Identificación, el nombre debe ser adecuado y descriptivo

– Documentación, debe aclarar todos los detalles de diseño e implementación que no queden de manifiesto en el propio código

– SIMPLICIDAD, las soluciones sencillas son siempre las mejores

e) Adaptabilidad

La adaptación de un sistema resulta más difícil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible. Otros factores para facilitar la adaptabilidad:

– Previsión, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte al menor número de módulos posibles

-Accesibilidad, debe resultar sencillo el acceso a los documentos de especificación, diseño, e implementación para obtener un conocimiento suficiente del sistema antes de proceder a su adaptación

– Consistencia, después de cualquier adaptación se debe mantener la consistencia del sistema, incluidos los documentos afectados

Arquitectura del software

La Arquitectura de Software(As) constituye una disciplina de reciente aparición y forma parte del paradigma de la Ingeniería del Software. . Representa la versión moderna de un diseño software y es apta para describir sistemas complejos.

Definición: Arquitectura de Software

• “Una arquitectura de software es un conjunto de elementos arquitectónicos que tiene una determinada forma. Las propiedades restringen la elección de los elementos de la arquitectura mientras que la lógica captura la motivación de la elección de los elementos y la forma.”

(Perry y Wolf 1992)

• “Una arquitectura de software incluye la descripción de elementos a partir de los cuales se constituyen los sistemas de software, interacciones entre esos elementos, patrones que guían la composición y restricciones sobre esos patrones. En general, un sistema de software particular se define en términos de una colección de componentes e interacciones entre dichos componentes. Tal sistema puede ser utilizado como un elemento en un sistema más grande.”(Garlan y Shaw 1996)
• “Una arquitectura de software de un programa o sistema de computación es la estructura o estructuras del sistema, el cual comprende componentes, las propiedades visibles externas de dichos componentes y las relaciones entre ellos.”(Bass, Clements y Kazman 1998).

6.2 ARQUITECTURAS DE DOMINIO ESPECÍFICO

El reto para el diseño es diseñar el software y hardware para proporcionar características deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos sistemas. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. Aquí se tratan dos tipos genéricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-servidor. En este caso el sistema puede ser visto como un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas.

Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. No hay distinción entre un proveedor de servicios y el usuario de estos servicios.

Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización. La distribución soportada es, por lo tanto, intraorganizacional. También se pueden tomar dos tipos más de arquitecturas distribuidas que son más adecuadas para la distribución interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios. Los sistemas peer-to-peer han sido usados principalmente para sistemas personales, pero están comenzando a usarse para aplicaciones de empresa.

Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representación de la información y los protocolos de comunicación pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El término middleware se usa para hacer referencia a ese software; se ubica en medio de los diferentes componentes distribuidos del sistema. Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar computación distribuida. El middleware es un software de propósito general que normalmente se compra como un componente comercial más que escribirse especialmente por los desarrolladores de la aplicación. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicación. Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. Estos sistemas están formados por partes independientes pobremente integradas, cada una de las cuales puede interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos software reflejan estas características; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos.

DISEÑO DE SOFTWARE ARQUITECTURA Cliente / Servidor:

Este modelo es un prototipo de sistemas distribuidos que muestra como los datos y el procesamiento se distribuyen a lo largo de varios procesadores. Es una forma de dividir las responsabilidades de un sistema de información separando la interfaz del usuario de la gestión de la información. El funcionamiento básico de este modelo consiste en que un programa cliente realiza peticiones a un programa servidor, y espera hasta que el servidor de respuesta.

Características de un cliente En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus características son: • Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo). • Espera y recibe las respuestas del servidor. • Por lo general, puede conectase a varios servidores a la vez. • Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.

Características de un servidor En los sistemas C/S el receptor de la solicitud enviada por cliente se conoce como servidor. Sus características son: • Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo). • Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente. • Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado). • No es frecuente que interactúen directamente con los usuarios finales.

Ventajas • Centralización del control: Los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda dañar el sistema. • Escalabilidad: Se puede aumentar la capacidad de clientes y servidores por separado. • Fácil mantenimiento

Desventajas • La congestión del tráfico (a mayor número de clientes, más problemas para el servidor). • El software y el hardware de un servidor son generalmente muy determinantes. Un hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. Normalmente se necesita software y hardware específico, sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto aumentará el costo.

CONCLUSIÓN

Como pudimos ver en el contenido de los diferentes temas ya mencionados en el trabajo, observamos los conceptos, características así como sus ventajas y desventajas del diseño y arquitectura de software así como la descomposición modular y la arquitectura de dominio especifico de esta forma queda más entendible y claro de lo que realmente hace y significa.

REFERENCIAS

http://www.mitecnologico.com/Main/Fundamentos de desarrollo de sistemas

Equipo:

Marina Aguilera Azamar

Sergio Chaparro Sandoval

Fernando Morales Rangel