Arquitectura de software

María José Burgos Cabrera

Modelamiento de Soluciones de Software

Instituto IACC

28 Abril 2019
 Desarrollo

1.- La descomposición Modular o Modularización, consiste en 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). La principal característica de la descomposición

modular es la de descomponer los problemas complejos en problemas más sencillos para realizar

de manera más eficiente el desarrollo de sistema, enfocándose en la reutilización de código,

además debido a esta descomposición cada módulo será desarrollado con un fin específico, esta

característica ayudara a que futuros programadores comprendan fácilmente la función de cada

módulo.

Después de elegir la organización del sistema en su totalidad, se deberá decidir cómo

descomponer los subsistemas en módulos, existen dos estrategias para poder descomponer un

subsistema en módulos:

 Descomposición orientada a objetos, aquí se descompone un sistema en un conjunto de

objetos que se comunican entre ellos.

 Descomposición orientada a flujo de funciones, aquí se descompone el sistema en

módulos funcionales que aceptan datos y los transforman en datos de salida.

Para el caso que se plantea, se podrá realizar mediante la descomposición orientada a objetos, ya

que se conforma por un conjunto de objetos que contienen muy bajo acoplamiento e interfaces

bien definidas. Los objetos se comunicaran entre sí mediante llamadas a los servicios ofrecidos

por estos. A diferencia de la descomposición orientada a flujos de funciones siendo una

arquitectura común en sistemas de procesamiento de datos, donde se generan numerosos

informes de salida a partir de los cálculos realizados sobre los datos de entrada.
La descomposición orientada a objetos propone dividir el sistema de juegos en partes

diferenciadas y a su vez se definirá sus interfaces, con el propósito de tener claridad y

reutilización.

Los pasos que se deberán a seguir en la descomposición orientada a objeto serán los siguientes:

 Se deberán identificar los módulos.

 Se deberá describir cada módulo.

 Se deberá describir las relaciones que existirán entre cada módulo.

La descomposición orientada a objetos, se descompone en un conjunto de objetos que se

comunican entre ellos. Para poder utilizar los servicios, los objetos deberán hacer referencia a un

nombre y a otros objetos. Las ventajas que se obtendrán al utilizar este tipo de descomposición

serán:

 Por el débil acoplamiento, la modificación de un objeto no afectaría a otros.

 La comprensión de un sistema bajo este tipo de descomposición será muy sencillo, ya

que se utilizan entidades del mundo real.

 Beneficiará la reutilización del código, al contar con entidades utilizables por otros

sistemas.

 Su implementación resultara directamente de los componentes arquitectónicos, gracias a

los lenguajes de programación orientados a objetos que existen.

Las desventajas que presentan este tipo de descomposición son:

 Para poder utilizar los servicios se deberán referenciar explícitamente al objeto.

 Cuando se requieran representar objetos para entidades complejas, este estilo resulta más

difícil.

Entonces tenemos que las características de la descomposición modular son:

  Tamaño Pequeño.

 Independencia Modular.

 Abstracción.

 Encapsulamiento.

Una descomposición modular deberá poseer ciertas cualidades para que se pueda considerar

suficientemente validad, estas cualidades son:

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.

Acoplamiento, Mide la interrelación entre dos módulos, según su tipo de conexión y la

complejidad de la interface, estas medidas pueden ser las siguientes:

 Fuerte: Por contenido (cuando desde un módulo se pueden cambiar datos locales de otro)

y 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)

y 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, siendo el mejor

posible) y Sin acoplamiento directo (es el acoplamiento que no existe).

Cohesión, Sera necesario lograr que el contenido de cada módulo tenga la máxima coherencia,

para lograr que cada Nro. De módulos no sea demasiado elevado y complique el diseño se tratan

de agrupar elementos afines y relacionados en un mismo modulo, estas medidas pueden ser las

siguientes:
  Alta, Cohesión Abstracta (se lograra cuando se diseñe el modulo como tipo abstracto de

datos o como una clase de objetos) y Cohesión Funcional (el modulo realiza una función

concreta y especifica).

 Media, Cohesión Secuencial (los elementos del módulo trabajan de forma secuencial),

Cohesión de Comunicación (elementos que operaran con el mismo conjunto de datos de

entrada o de salida) y Cohesión Temporal (se agrupan elementos que se ejecutaran en el

mismo momento).

 Baja, Cohesión Lógica (se agruparan elementos que realizan funciones similares) y

Cohesión Coincidental (es la peor y se produce cuando los elementos de un módulo no

guardan relación alguna).

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 esto es bueno que posea

independencia funcional, pero además es deseable que tenga lo siguiente:

 Identificación, el nombre debe ser adecuado y descriptivo.

 Documentación, se deben 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.

Adaptabilidad, la adaptación de un sistema resultara 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 la facilitación de la adaptabilidad son:

 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 de ser 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.

Así sería un ejemplo de la descomposición orientada a objeto del caso planteado:

2.- Los patrones de diseño de software, son los que describen un problema que ocurre una y otra

vez en nuestro medio ambiente y, a continuación describirá el núcleo de la solución a ese

problema, de tal manera que se pueda utilizar esta solución varias veces, sin tener que hacerlo de

la misma manera dos veces.

Entre estos patrones tenemos los de Gof, siendo sus características las siguientes:

 Son soluciones concretas.

 Son soluciones técnicas.

 Se utilizan en situaciones frecuentes.

 Favorecen la reutilización del código.

 El uso de un patrón no se reflejara en el código.

 Es difícil reutilizar la implementación de un patrón.

Estos tipos de patrones se clasifican conforme a su propósito y estas son:

 Patrones de creación, son los que tratan de la inicialización y configuración de clases y

objetos ( Abstract Factory, Builder, Factory Method, Prototype y Singleton).

 Patrones Estructurales, son los que tratan de desacoplar interfaz e implementación de

clases y objetos (Adapter, Bridge, Composite. Decorator, Facade, Flyweight y Proxy).

 Patrones de comportamiento, son los que tratan de las interacciones dinámicas entre

sociedades de clases y objetos (Chain of Responsibility, Command, Interpreter, Iterator,

Mediator, Memeto, Observer, State, Strategy, Template Method y Visitor).

Conforme a lo anteriormente expuesto sobre los patrones de Gof el cuadro que a continuación se

detalla, se refleja aproximadamente la solución al sistema juego planteado en la presente tarea:

Clase Atributos Métodos

Sesión Nombre del juego Registrar Número de sesiones

Sesión del juego

Personajes Nombre del Personaje Registrar y actualizar

Sesión del juego

Puntaje
Categoría Nombre de la categoría Registrar y actualizar

Atributos Nombre Registrar y actualizar

Tipo

Medidas

Cualidades

A continuación se demuestra los tipos de patrones creados para el sistema juego en la siguiente

estructura:

Nota: Espero haber cumplido lo solicitado, ya que es lo que logre entender.

 Bibliografía

Belvel (Jun. 9. 2009). Fundamentos de Desarrollo de Sistemas. Recuperado desde

https://belvel.wordpress.com/2009/06/09/15/

Ecured (s.f). Patrones Gof. Recuperado desde https://www.ecured.cu/Patrones_Gof

IACC (2015). Arquitectura de software. Modelamiento de Soluciones de Software. Semana 4.

Ittgweb (May. 29. 2016). Descomposición modular. Recuperado desde

https://ittgweb.wordpress.com/2016/05/29/descomposicion-modular/

Slideshare (Sept. 27. 2011). Descomposición Modular y Estilos de Control. Recuperado desde

https://es.slideshare.net/jpbthames/descomposicin-modular-y-estilos-de-control

Un poco Java (Ene. 2. 2013). Un poco de patrones de diseño de GoF (Gang of Four).

Recuperado desde https://unpocodejava.com/2013/01/02/un-poco-de-patrones-de-diseno-gof-

gang-of-four/

Wikipedia (Mod. Feb. 10. 2019). Patrón de diseño. Recuperado desde

https://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o