13. Seleccione una aplicación con la que esté familiarizado. Responda: Control.

¿Cómo se
administra el control dentro de la arquitectura? ¿Existe una jerarquía de control distinta?

Datos. ¿Cómo se comunican los datos entre los componentes? ¿El flujo de datos es continuo o los
objetos de datos pasan al sistema en forma esporádica?

14. En ocasiones resulta difícil definir el término componente. Primero dé una definición general y
luego otras más explícitas para el software orientado a objetos y para el tradicional. Por último,
elija tres lenguajes de programación con los que esté familiarizado e ilustre la manera en la que
cada uno define un componente.

Componente: es un elemento de un sistema de software que ofrece un conjunto de servicios, o

funcionalidades, a través de interfaces definidas. También puede definirse como un paquete de
software, un servicio web, o un módulo que encapsula un conjunto de funciones relacionadas (o
de datos).

- Según JAVA: Unidad de lógica de software desde la que se crean aplicaciones distribuidas.
Un componente de aplicación se desarrolla de forma personalizada y normalmente se
adhiere a un modelo de componente distribuido (como por ejemplo CORBA y la plataforma
J2EE) y realiza algunas funciones informáticas específicas.

- Según C++: Son elementos genéricos con funcionalidades concretas, cuya finalidad es la
reutilización. Cada uno de ellos está destinado a realizar una tarea típica en una aplicación.

- Según PHP: Son paquetes de lógica que son compartidos entre los controladores. Si tiene
ganas de copiar y pegar código de un controlador a otro, debería antes considerar agrupar
algunas funcionalidades en un componente

15. ¿Por qué son necesarios los componentes de control en el software tradicional y por qué en
general no se requieren en el orientado a objetos?

En un diseño de software tradicional, los componentes (o módulos) son elementos funcionales que
incorporan un procesamiento lógico, estructuras de datos y una interfaz lógica para interactuar con
el entorno externo. Los módulos pueden clasificarse como componentes de control, dominio de
problemas e infraestructura. El componente de control se encarga de la invocación de los
componentes del dominio del problema.

En contraste con esto, la arquitectura orientada a objetos consta de componentes colaboradores

(objetos definidos en clases), cada uno de los cuales encapsula todo el procesamiento lógico, las
estructuras de datos y los requisitos de interfaz necesarios para ejecutar su función. Por lo tanto, no
se requiere un componente de control, ya que los datos y la funcionalidad se definen implícitamente
para cada componente.

16. Investigue sobre los tipos de cohesión y los tipos de acoplamiento.

Tipos de cohesión (criterios de agrupamiento)

* Cohesión funcional: Los elementos de la unidad de software están relacionados en el desarrollo

de una única función. Es decir, las unidades de software trabajan juntas con un mismo fin. En
general, es el criterio de agrupación más deseable. Probablemente haya entre las unidades un
acoplamiento relativamente alto, por lo tanto, es conveniente que estén juntas.

* Cohesión secuencial: Una unidad de software realiza distintas tareas en secuencia, de forma que
las entradas de cada tarea son las salidas de la tarea anterior. En otras palabras, se agrupan las
unidades que cumplen que los resultados o salidas que produce una sirven como entrada para que
la próxima continúe trabajando.

* Cohesión comunicacional o de datos: La unidad de software realiza actividades paralelas usando

los mismos datos de entrada y salida. En otras palabras, cuando todas las unidades agrupadas
trabajan sobre el mismo conjunto de datos.

* Cohesión procedimental: La unidad de software tiene una serie de funciones relacionadas por un
procedimiento efectuado por el código. Es similar a la secuencial, pero incluyendo el paso de
controles.

* Cohesión lógica: Cuando las unidades de software agrupadas realizan un trabajo en una misma
categoría lógica, pero no necesariamente tienen relación entre sí. Por ejemplo: bibliotecas de
funciones matemáticas, sólo se agrupan porque realizan cálculos matemáticos, pero no tienen
necesariamente relación entre ellas.

* Cohesión temporal: Los elementos de la unidad de software están implicados en actividades

relacionadas con el tiempo. En otras palabras, se agrupan unidades de software que tienen que
ejecutarse más o menos en el mismo período de tiempo, sin que haya otro tipo de relación entre
ellas. En general debe evitarse.
* Cohesión casual o coincidente: Los elementos de la unidad de software contribuyen a las
actividades relacionándose mutuamente de una manera poco significativa. En otras palabras, es
cualquier criterio que no caiga dentro de los anteriores. Este tipo de cohesión viola el principio de
independencia y de caja negra de las unidades de software, por lo tanto, debe evitarse.

Tipos de acoplamiento

* Acoplamiento normal: una unidad de software llama a otra de un nivel inferior y tan solo
intercambian datos (por ejemplo: parámetros de entrada/salida). Dentro de este tipo de
acoplamiento podemos encontrarnos 3 subtipos, dependiendo de los datos que intercambien las
unidades de software. Para más información ver Acoplamiento normal.

* Acoplamiento externo: las unidades de software están ligadas a componentes externos, como por
ejemplo dispositivos de entrada/salida, protocolos de comunicaciones, etc.

* Acoplamiento común: dos unidades de software acceden a un mismo recurso común,

generalmente memoria compartida, una variable global o un fichero.

* Acoplamiento de contenido: ocurre cuando una unidad de software necesita acceder a una parte
de otra unidad de software.