roberto

1. DISEÑOEN EL NIVEL DE COMPONENTES
Tiene lugar una vez terminado el diseño de la arquitectura.
 El objetivo es traducir el modelo del diseño a software operativo.
 La traducción es difícil y está abierta a la introducción de errores sutiles que son difíciles
de detectar y de corregir en las etapas posteriores del proceso del software.
¿QUÉ ES UN COMPONENTE?
 Un componente es un bloque de construcción de software de cómputo.
 los componentes forman la arquitectura del software y, en consecuencia, juegan un
papel en el logro de los objetivos y de los requerimientos del sistema.
visiones importantes de lo que es un componente
 Visión orientada a objetos: Un componente contiene un conjunto de clases que
colaboran, Cada clase dentro de un componente se elabora por completo para que
incluya todos los atributos y operaciones relevantes para su implantación.

2.  La visión tradicional: Un componente es un elemento funcional de un programa que incorpora la
lógica del procesamiento, las estructuras de datos internas que se requieren para implantar la
lógica del procesamiento y una interfaz que permite la invocación del componente y el paso de
los datos.
 Dentro de la arquitectura del software se encuentra un componente tradicional, llamado Módulo,
tiene tres funciones importantes.
1) como componente de control que coordina la invocación de todos los demás componentes
del dominio del problema.
2) como componente del dominio del problema que implanta una función completa o parcial que
requiere el cliente.
3) como componente de infraestructura que es responsable de las funciones que dan apoyo al
procesamiento requerido en el dominio del problema.
 Visión relacionada con el proceso: A medida que avanza el trabajo de diseño se dispone de un
catálogo de diseño probado o de componentes en el nivel de código, Conforme se desarrolla la
arquitectura del software, se escogen del catálogo componentes o patrones de diseño y se usan
para construir la arquitectura.

3. DISEÑO DE COMPONENTES BASADOS EN CLASE
 El diseño en el nivel de componentes se centra en la elaboración de clases específicas del
dominio del problema y en el refinamiento de las clases de infraestructura contenidas en el
modelo de requerimientos.
 La descripción detallada de los atributos, operaciones e interfaces que emplean dichas clases es
el detalle de diseño que se requiere como precursor de la actividad de construcción.
Principios básicos del diseño.
 Principio Abierto-Cerrado (PAC): Debe especificarse el componente en forma tal que permita
extenderlo sin necesidad de hacerle modificaciones internas. Para lograr esto, se crean
abstracciones que sirven como búfer entre la funcionalidad que sea probable extender y la clase
de diseño en sí.
 Principio de sustitución de Liskov (PSL): Sugiere que un componente que use una clase de
base debe funcionar bien si una clase derivada de la clase base pasa al componente.

4.  Principio de Inversión de la Dependencia (PID). Como se vio en el estudio del PAC, las
abstracciones son el lugar en el que es posible ampliar un diseño sin muchas dificultades. Entre
más dependa un componente de otros componentes concretos (y no de abstracciones tales como
una interfaz),más difícil será ampliarlo.
 Principio de segregación de la interfaz (psi): Es mejor tener muchas interfaces específicas del
cliente que una sola de propósito general. sugiere que debe crearse una interfaz especializada
que atienda a cada categoría principal de clientes. En la interfaz de ese cliente, sólo deben
especificarse aquellas operaciones que sean relevantes para una categoría particular de clientes.
 Principio de equivalencia de la liberación de la reutilización (PER): “El gránulo de
reutilización es el gránulo de liberación” Cuando las clases o componentes se diseñan para ser
reutilizables, existe un contrato implícito que se establece entre el desarrollador de la entidad
reutilizable y las personas que la emplearán.

5. LINEAMIENTOS DE DISEÑO EN EL NIVEL DE COMPONENTES.
 Componentes:Deben establecerse convenciones para dar nombre a los componentes que
se especifique que forman parte del modelo arquitectónico, para luego mejorarlos y
elaborarlos como parte del modelo en el nivel de componentes. Los nombres de los
componentes arquitectónicos deben provenir del dominio del problema y significar algo para
todos los participantes que vean el modelo arquitectónico.
 Interfaces:Las interfaces dan información importante sobre la comunicación y la
colaboración .Sin embargo, la representación sin restricciones de las interfaces tiende a
complicar los diagramas de componentes.
 Dependencias y herencia: Para tener una mejor legibilidad, es buena idea modelar las
dependencias de izquierda a derecha y la herencia de abajo (clases obtenidas) hacia arriba
(clases base). Además, las interdependencias de componentes deben representarse por
medio de interfaces y no con la dependencia componente a componente.

6. COHESIÓN.
Implica que un componente o clase sólo contiene atributos y operaciones que se relacionan de cerca uno con el
otro y con la clase o componente en sí.
tipos diferentes de cohesión:
 Funcional: Lo tienen sobre todo las operaciones; este nivel de cohesión ocurre cuando un componente
realiza un cálculo y luego devuelve el resultado.
 De capa: Lo tienen los paquetes, componentes y clases; este tipo de cohesión ocurre cuando una capa más
alta accede a los servicios de otra más baja, pero ésta no tiene acceso a las superiores.
 De comunicación. Todas las operaciones que acceden a los mismos datos se definen dentro de una clase.
En general, tales clases se centran únicamente en los datos en cuestión, acceden a ellos y los guardan.

7. ACOPLAMIENTO.
En el estudio anterior del análisis y el diseño, se dijo que la comunicación y la
colaboración eran elementos esenciales de cualquier sistema orientado a objetos. Sin
embargo, esta característica tan importante (y necesaria) tiene un lado oscuro. A medida
que aumentan la comunicación y colaboración (es decir, conforme se eleva la
“conectividad” entre las clases), la complejidad del sistema también se incrementa. Y si la
complejidad aumenta, también crece la dificultad de implantar, probar y dar
mantenimiento al software.

8. • Acoplamiento de contenido. tiene lugar cuando un componente “modifica
subrepticiamente datos internos en otro componente” [let01]. esto viola el ocultamiento
de la información, concepto básico del diseño.
• Acoplamiento común. Sucede cuando cierto número de componentes hacen uso de
una variable global. Aunque a veces esto es necesario (por ejemplo, para establecer
valores definidos que se utilizan en toda la aplicación), el acoplamiento común lleva a la
propagación incontrolada del error y a efectos colaterales imprevistos cuando se hacen
los cambios.
• Acoplamiento de datos. Ocurre si las operaciones pasan cadenas largas de
argumentos de datos. El “ancho de banda” de la comunicación entre clases y
componentes crece y la complejidad de la interfaz se incrementa. Se hace más difícil
hacer pruebas y dar mantenimiento