Unidad 6 Diseño y Arquitectura de Software

 

INTRODUCCION

 

A continuación les mostraremos los diferentes conceptos y características de diferentes autores y páginas de internet del diseño y características de software así como la descomposición modular y arquitectura de dominio específico.

EL diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño de software que se utilice.

La arquitectura de Software han estado implícitas –bien como accidentes en la implementación, bien como sistemas legados del pasado-. Los buenos desarrolladores de software han adoptado, a menudo, uno o varios patrones arquitectónicos como estrategias de organización del sistema, pero utilizaban estos patrones de modo informal y no tenían ningún interés en hacerlos explícitos en el sistema resultante.

La descomposición modular es un método de diseño proporciona un mecanismo sistemático para descomponer el problema en subproblemas, reducirá la complejidad de todo el problema, consiguiendo de esta manera una solución modular efectiva.

La arquitectura de dominio especifico Existen dos modelos de dominio específico el modelo genérico que son abstracciones de varios sistemas reales y el modelo de referencia que son modelos abstractos y describen a una clase mayor de sistemas.

En el transcurso del contenido le explicaremos mas detalladamente cada uno de estos temas.

 

Unidad IV: Diseño y arquitectura de software

El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño de software que se utilice. Una vez que se analizan y especifican los requisitos del software, el diseño del software es la primera de las tres actividades técnicas -diseño, generación de código y pruebas- que se requieren para construir y verificar el software. Cada actividad transforma la información de manera que dé lugar por último a un software de computadora validado.

Shaw y Garlan [SHA96], en su libro de referencia sobre la materia, tratan la arquitectura del software de la siguiente forma:

Incluso desde que el primer programa fue dividido en módulos, los sistemas de software han tenido arquitecturas, y los programadores han sido responsables de sus interacciones a través de módulos y de las propiedades globales de ensamblaje. Históricamente, las arquitecturas han estado implícitas –bien como accidentes en la implementación, bien como sistemas legados del pasado-. Los buenos desarrolladores de software han adoptado, a menudo, uno o varios patrones arquitectónicos como estrategias de organización del sistema, pero utilizaban estos patrones de modo informal y no tenían ningún interés en hacerlos explícitos en el sistema resultante.

Hoy, la arquitectura de software operativa y su representación y diseño explícitos se han convertido en temas dominantes de la ingeniería de software.

 

¿Qué es arquitectura?

Cuando hablamos de la «arquitectura» de un edificio, nos vienen a la cabeza diferentes atributos. A nivel más básico, pensamos en la forma global de la estructura física. Pero, en realidad, la arquitectura es mucho más. Es la forma en la que los diferentes componentes del edificio se integran para formar un todo unido. Es la forma en la que el edificio encaja en su entorno y con los otros edificios de su vecindad. Es el grado en el que el edificio consigue su propósito fijado y satisface las necesidades

de sus propietarios. Es el sentido estético de la estructura 4 1im pacto visual del edificio- y el modo

en el que las texturas, los colores y los materiales son combinados para crear la fachada externa y el «entorno vivo» interno. Son los pequeños detalles – e l diseño de las instalaciones eléctricas, del tipo de suelo, de la colocación de tapices y una lista casi interminable-. Y, finalmente, es arte.

Pero, ¿qué pasa con la arquitectura de software? Bass y sus colegas [BAS98] definen este esquivo término de la siguiente forma:

La arquitectura de software de un sistema de programa o computación es la estructura de las estructuras del sistema, la cual comprende los componentes del software, las propiedades de esos componentes visibles externamente, y las relaciones entre ellos.

La arquitectura no es el software operacional. Más bien, es la representación que capacita al ingeniero del software para: (1) analizar la efectividad del diseño para la consecución de los requisitos fijados, (2) considerar las alternativas arquitectónicas en una etapa en la cual hacer cambios en el diseño es relativamente fácil, y (3) reducir los riesgos asociados a la construcción del software.

¿Por qué es importante la arquitectura?

En su libro dedicado a la arquitectura de software, Bass y sus colegas [BAS98] identifican tres razones clave por las que la arquitectura de software es importante:

• Las representaciones de la arquitectura de software facilitan la comunicación entre todas las partes (partícipes) interesadas en el desarrollo de un sistema basado en computadora.
• La arquitectura destaca decisiones tempranas de diseño que tendrán un profundo impacto en todo el trabajo de ingeniería del software que sigue, y es tan importante en el éxito final del sistema como una entidad operacional.
• La arquitectura «constituye un modelo relativamente pequeño e intelectualmente comprensible de cómo está estructurado el sistema y de cómo trabajan juntos sus componentes» [BAS98].

El modelo de diseño arquitectónico y los patrones arquitectónicos contenidos dentro son transferibles. Esto es, los estilos y patrones de arquitectura pueden ser aplicados en el diseño de otros sistemas y representados a través de un conjunto de abstracciones que facilitan a los ingenieros del software la descripción de la arquitectura de un modo predecible.

6.1 Descomposición modular

Capacidad de descomposición modular. Si un método de diseño proporciona un mecanismo sistemático para descomponer el problema en subproblemas, reducirá la complejidad de todo el problema, consiguiendo de esta manera una solución modular efectiva.

Capacidad de empleo de componentes modulares. Si un método de diseño permite ensamblar los componentes de diseño (reusables) existentes en un sistema nuevo, producirá una solución modular que no inventa nada ya inventado.

Capacidad de comprensión modular. Si un módulo se puede comprender como una unidad autónoma (sin referencias a otros módulos) será más fácil de construir y de cambiar.

Continuidad modular. Si pequeños cambios en los requisitos del sistema provocan cambios en los módulos individuales, en vez de cambios generalizados en el sistema, se minimizará el impacto de los efectos secundarios de los cambios.

Protección modular. Si dentro de un módulo se produce una condición aberrante y sus efectos se limitan a ese módulo, se minimizará el impacto de los efectos secundarios inducidos por los errores.

Finalmente, es importante destacar que un sistema se puede diseñar modularmente, incluso aunque su implementación deba ser «monolítica». Existen situaciones (por ejemplo, software en tiempo real, software empotrado) en donde no es admisible que los subprogramas introduzcan sobrecargas de memoria y de velocidad por mínimos que sean (por ejemplo, subrutinas, procedimientos). En tales situaciones el software podrá y deberá diseñarse con modularidad como filosofía predominante.

El código se puede desarrollar «en línea». Aunque el código fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofía y el programa proporcionará los beneficios de un sistema modular.

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

Descomposición Modular: Independiente Funcional

• Al final de los documentos ADD y DDD debe haber una matriz REQUISITOS/COMPONNETES. En principio, cada función será realizada en un módulo distinto. Si las funciones son independientes los módulos tendrán 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.

Descomposición Modular: Acoplamiento

 

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 pueden 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 afecta a todos estos módulos
    • POR ETIQUETA, en 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 posible
      • SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe

Descomposición Modular: Cohesión

 

Es necesario lograr que el contenido de cada módulo tenga la máxima coherencia. Para que el 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 le 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. Ejs.: módulos de E/S o de tratamiento de errores
      • 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 específico (Ej. Todos los errores), cohesión lógica
• Si aparece “inicializar”, “preparar”, “configurar”, probablemente sea temporal.

Descomposición Modular: 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

Descomposición Modular: 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 posible
• 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

6.2 Arquitectura de dominio especifico

Existen dos modelos de dominio específico:

1. Modelos genéricos que son abstracciones de varios sistemas reales.

2. Modelos de referencia que son modelos abstractos y describen a una clase mayor de sistemas.

Modelo genérico: flujo de datos de un compilador

Modelo de Referencia: La arquitectura OSI

La arquitectura cliente-servidor es una forma de dividir las responsabilidades de un Sistema de Información separando la interfaz de usuario (Nivel de presentación) de la gestión de la información (Nivel de gestión de datos).

Esta arquitectura consiste básicamente en que un programa, el Cliente informático realiza peticiones a otro programa, el servidor, que les da respuesta.

Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema multiusuario distribuido a través de una red de computadoras.

La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.

Ventajas de la arquitectura cliente-servidor

›  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.

Se reduce el tráfico de red considerablemente. Idealmente, el cliente se comunica con el servidor utilizando un protocolo de alto nivel de abstracción como por ejemplo SQL

CONCLUSION

Como pudimos notar en el contenido y desarrollo de los diferentes temas, se explico detalladamente cada uno de los puntos a tratar y encontramos sus diferentes características que hacen cada uno ellos así como imágenes para dejar mas en claro el tema.

REFERENCIAS

Libro Roger Pressman- Ingenieria en sistemas un enfoque practico

http://www.mitecnologico.com/Main/DescomposicionModular

http://www.mitecnologico.com/Main/ArquitecturasDeDominioEspecifico

Equipo:

Luis Manuel Menacho Ramirez

Ivan de Jesus Castellanos Hernandez

Radiel Rodríguez Reyes

 

1. 

   KEYSS Said:

   on junio 3, 2010 at 1:47 pm

   eS UNIDAD VI NO UNIDAD IV ….. DATO XD

   Responder
2. 

   Andrés Rivera Montoya Said:

   on junio 12, 2011 at 1:43 am

   Hola, abundaron mucho sobre la descomposición modular pero dejaron áridos los temas de Arquitectura de dominio específico.

   Saludos.

   Responder
3. 

   gildardo Said:

   on septiembre 2, 2013 at 7:51 pm

   Muy buen documento. Vale la pena que lo lean todos los quieren aspirar a ser arquitectos de software.

   Responder
4. 

   Mauricio Said:

   on septiembre 2, 2013 at 9:03 pm

   MUY BUEN APORTE AMIGO ESTA MUY SUSTENTADO CON AUTORES 🙂

   Responder

{ RSS feed for comments on this post} · { TrackBack URI }