DISEÑO EN EL NIVEL DE COMPONENTES
DESARROLLO BASADO EN COMPONENTES
Clasificación y recuperación de componentes
Una gran biblioteca universitaria contiene miles de libros, revistas y otras fuentes de información. Para acceder a estas fuentes, se define un esquema de clasificación que incluye un código del Congreso, palabras clave, nombres de autores y entradas de índice. Esto permite a los usuarios encontrar rápidamente la información necesaria. Un gran repositorio de software contiene miles de componentes reutilizables. La descripción ideal incluye el modelo 3C de Tracz: concepto, contenido y contexto. El concepto describe la interfaz y la semántica del componente, mientras que el contenido describe cómo se ejecuta el concepto. El contexto coloca el componente en su dominio de aplicación, lo que permite a los ingenieros de software encontrar el componente apropiado para los requisitos de la aplicación.
La clasificación permite encontrar y recuperar componentes que son candidatos a la reutilización, pero debe existir un ambiente propicio para integrarlos con eficacia. Éste tiene las características siguientes:
• Una base de datos capaz de almacenar componentes de software y la información de
clasificación necesaria para recuperarlos.
• Un sistema de administración de la biblioteca que dé acceso a la base de datos.
• Un sistema de recuperación de componentes de software (por ejemplo, un agente de
solicitud de objetos) que permita que la aplicación de un cliente recupere componentes y
servicios del servidor de la biblioteca.
• Herramientas de ISBC que apoyen la integración de componentes reutilizados en un
diseño o implantación nuevos.
Análisis y diseño para la reutilización
El ISBC fomenta el uso de componentes de software existentes, pero a veces es necesario desarrollar otros nuevos para integrarlos con CCS disponibles y otros productos. A medida que estos nuevos componentes se convierten en miembros de la biblioteca de componentes reutilizables, se debe realizar ingeniería para su reutilización. Conceptos de diseño como abstracción, ocultamiento, independencia de funciones, refinamiento y programación estructurada contribuyen a la creación de componentes de software reutilizables. Se analiza el modelo de requisitos para determinar qué elementos apuntan hacia componentes reutilizables existentes. Si el ajuste de especificaciones se alinea con un componente existente, la biblioteca de reutilización (repositorio) se utiliza para el diseño de un nuevo sistema. Si no se encuentra el componente, se crea uno nuevo. El diseño para la reutilización (DPR) se considera al crear un nuevo componente.
Aspectos Claves
Plantillas de programa
Se elige un estilo arquitectónico (véase el capítulo 9) que sirve como plantilla para el diseño de la arquitectura del nuevo software.
Protocolos de interfaz estándar
Deben establecerse tres niveles de protocolos de interfaz: la naturaleza de las interfaces intramodulares, el diseño de las interfaces externas técnicas (no humanas) y la interfaz humano-computadora.
Datos estándar
El dominio de la aplicación debe investigarse y tienen que identificarse las estructuras de datos globales estándar (como las de archivos o una base de datos completa). Todos los componentes del diseño se caracterizan para hacer uso de estas estructuras de datos estándar.
Combinación
La combinación de componentes crea componentes calificados, adaptables y necesarios para la arquitectura de una aplicación. Una infraestructura vincula componentes de un sistema operativo, permitiendo la coordinación y tareas comunes. Debido al potencial de la reutilización y del ISBC en la industria del software, empresas y consorcios proponen estándares de software.
Estandares
Componentes JavaBeans de Sun
JavaBeans es una infraestructura portátil e independiente del ISBC, desarrollada utilizando el lenguaje de programación Java. Incluye una herramienta Kit of Development Bean (KDB) que permite a los desarrolladores analizar la funcionalidad de componentes existentes, personalizar su comportamiento y apariencia, establecer mecanismos de coordinación y comunicación, desarrollar componentes especiales para aplicaciones específicas y probar y evaluar su comportamiento.
MCO de Microsoft y .NET
Microsoft ha desarrollado un modelo de componentes de objetos (MCO) que proporciona especificaciones para el uso de componentes producidos por múltiples proveedores dentro de un campo de aplicación y compatibles con el sistema operativo Windows. La atención se centra no en implementar objetos MCO, sino en su interfaz con el sistema y su uso en el sistema componente para comunicarse con otros objetos MCO. La estructura .NET de Microsoft incluye MCO y una biblioteca reutilizable que cubre una amplia gama de dominios de aplicaciones.
GAO/ATOCS
El Grupo de Administración de Objetos ha publicado un documento titulado "Arquitectura de Intercambio de Objetos Comúnmente Solicitados" (GAO/ATOCS), que describe servicios que permiten compartir componentes reutilizados con otros sin afectar su ubicación dentro de un sistema.
Adaptación
En el escenario ideal, la ingeniería de dominio crea una biblioteca de componentes que se integra fácilmente en la arquitectura de una aplicación. Esta integración implica métodos consistentes de gestión de recursos, actividades comunes como la administración de datos e interfaces consistentes dentro y con el entorno. Sin embargo, incluso si un componente ha sido calificado para su uso dentro de una aplicación, pueden surgir conflictos. Para evitarlos se aplica una técnica llamada envoltura de componentes. Esta técnica estudia los detalles del procesamiento interno de un componente y realiza modificaciones para eliminar o anular conflictos.
Calificación
La calificación de componentes garantiza que un componente ejecute la función requerida, encaje adecuadamente en el estilo arquitectónico y tenga las características de calidad requeridas para la aplicación. La descripción de la interfaz proporciona información útil sobre la operación y uso del componente, pero no todo lo que requiere para la reutilización. Entre los
muchos factores que se consideran durante la calificación de un componente se encuentran
los que se mencionan a continuación [Bro96]:
• Aplicación de programación de la interfaz (API).
• Herramientas de desarrollo e integración requeridas por el componente.
• Requerimientos durante la puesta en marcha, incluidos el uso de recursos (como la
memoria de almacenamiento), sincronía o velocidad y protocolo de redes.
• Requerimientos de servicio, incluidos interfaces del sistema operativo y apoyo de otros
componentes.
• Características de seguridad, incluidos controles de acceso y protocolo de autentificación.
• Suposiciones incrustadas en el diseño, incluido el empleo de algoritmos, numéricos o
no, específicos.
• Manejo de excepciones.
Ingeniería del dominio
La ingeniería del dominio es una disciplina que busca identificar, construir, catalogar y diseñar componentes de software aplicables en un dominio de aplicaciones, incluyendo análisis, construcción y diseminación. El enfoque general del análisis del dominio se caracteriza con frecuencia dentro del contexto
de la ingeniería de software orientada a objetos. Los pasos de este proceso se definen como
sigue:
1. Definir el dominio que se va a investigar.
2. Clasificar los aspectos extraídos del dominio.
3. Reunir una muestra representativa de aplicaciones en el dominio.
4. Analizar cada aplicación en la muestra y definir clases de análisis.
5. Desarrollar un modelo de los requerimientos para las clases.
La ingeniería de software basada en componentes (ISBC) se centra en el diseño y construcción de sistemas informáticos utilizando componentes de software reutilizables. Adopta la filosofía de "comprar, no tener" propuesta por Fred Brooks y otros. El ISBC combina la programación con la integración de sistemas de software, abordando preguntas sobre la construcción de sistemas complejos, eficiencia de costos y tiempo, incentivos para la reutilización, costos adicionales asociados con la creación de componentes reutilizables y la disponibilidad de los componentes necesarios. La respuesta es sí, y se necesita más investigación para garantizar el éxito en la organización de ingeniería de software.
DISEÑO DE COMPONENTES TRADICIONALES
Lenguaje de diseño del programa
El lenguaje de diseño del programa (LDP), también llamado castellano estructurado o seudocódigo, incorpora la estructura lógica de un lenguaje de programación y la expresividad de forma libre de un lenguaje natural. Se incrusta el texto de la narración en una sintaxis de programación parecida al idioma. Para mejorar la aplicación del LDP, se utilizan herramientas automatizadas. La sintaxis básica del LDP incluye construcciones para definir componentes, describir la interfaz, declarar datos, estructurar bloques, hacer construcciones condicionales, de repetición y de entrada y salida.
Notación del diseño tabular
Una tabla de decisiones es una herramienta utilizada en aplicaciones de software para evaluar combinaciones complejas de condiciones y seleccionar acciones apropiadas en función de un conjunto de reglas. Es difícil de malinterpretar y una máquina puede utilizarlo como entrada legible en un algoritmo. La tabla está dividida en cuatro secciones y cada columna representa una regla de procesamiento. Para desarrollar una tabla de decisión se emplean los pasos siguientes: 1. Enlistar todas las acciones asociadas con un procedimiento (o componente) específico.
2. Enlistar todas las condiciones (o decisiones tomadas) durante la ejecución del procedimiento.
3. Asociar conjuntos específicos de condiciones con acciones específicas, con la eliminación de las combinaciones o con condiciones imposibles; de manera alternativa, desarrollar toda posible permutación de las condiciones.
4. Definir reglas indicando qué acciones suceden para un conjunto dado de condiciones.
Notación gráfica de diseño
El diagrama de actividades y diagrama de flujo son herramientas gráficas útiles para ilustrar detalles de procedimientos. Sin embargo, el uso de las herramientas gráficas puede provocar una imagen equivocada y conducir al software equivocado. El diagrama de actividades representa la secuencia, condición y repetición, y es descendiente de un diagrama de flujo. La secuencia es una línea de procesamiento, la condición es un rombo de decisión, y la repetición es una construcción seleccionar. El uso dogmático de construcciones estructuradas puede introducir ineficiencia en el procesamiento y aumentar la posibilidad de errores. Hay dos opciones: 1) rediseñar la representación del procedimiento en una ubicación anidada en el flujo del control o 2) violar las construcciones estructuradas controladas.
El diseño en el nivel de componentes para el software tradicional se estableció en la década de 1960 y se formalizó con el trabajo de Edsger Dijkstra et al., que propone el empleo de un conjunto de construcciones lógicas restringidas para elaborar cualquier programa. Estas construcciones son secuencia, condición y repetición, fundamentales para la programación estructurada. La utilización de las construcciones estructuradas limita el diseño del software y mejora la legibilidad y la facilidad de realizar pruebas y mantenimiento. Sin importar el área de aplicación o complejidad técnica, el uso dogmático con frecuencia puede ocasionar dificultades en las prácticas.
DISEÑO EN EL NIVEL DE COMPONENTES PARA WEBAPPS
Diseño de las funciones en el nivel de componentes
Las aplicaciones web modernas ofrecen funciones de procesamiento sofisticadas que generan contenido dinámico, calculan datos, brindan acceso avanzado a datos y establecen interfaces de datos con sistemas externos. Estas funciones están diseñadas para ser consistentes con la arquitectura de la información, comenzando con el modelo de solicitud del usuario y la arquitectura de la información inicial. Durante el proceso de diseño, el contenido y las funciones se combinan para crear una arquitectura funcional, que representa las funciones de la aplicación y define los componentes funcionales clave y los modos de interacción. Por ejemplo, las funciones de zoom y rebobinado de vídeo para CasaSeguraAsegurada.com se implementan como operaciones de cámara.
Diseño del contenido en el nivel de componente
El diseño del contenido en el nivel de componentes se centra en objetos de contenido y la forma en la que se empacan para su presentación a un usuario final de webapps. Para la capacidad de vigilancia con video, se pueden definir varios componentes potenciales: 1) objetos de contenido que representan la distribución del espacio con íconos adicionales, 2) el conjunto de imágenes instantáneas de video (cada uno es un objeto de datos separado) y 3) la ventana del vídeo de una cámara específica. La formalidad del diseño del contenido en el nivel de componentes debe adaptarse a las características de la webapp que se va a elaborar.
Un componente de aplicación web es una función definida que manipula contenido o procesa datos para un usuario final, o un paquete coherente de contenido y funciones que proporciona capacidades solicitadas. El diseño de los componentes de las aplicaciones web a menudo incorpora elementos de contenido y diseño de funciones, lo que lo convierte en un problema común en los sistemas y aplicaciones basados en la web. Por tanto, es fundamental comprender qué es un componente de una aplicación web.
REALIZACIÓN DEL DISEÑO EN EL NIVEL DE COMPONENTES
1.Definición y Especificación de Componentes:
Enumera y define cada uno de los componentes que formarán parte del sistema. Esto puede incluir clases, módulos, bibliotecas y otros elementos.
2.Diseño de Interfaces:
Especifica las interfaces que permitirán la interacción con otros componentes. Define los métodos, atributos y eventos que estarán disponibles.
3.Desarrollo Detallado de Componentes:
Implementa los detalles de cada componente, incluyendo el código y las estructuras de datos necesarias.
4.Aplicación de Principios de Diseño:
Aplica principios de diseño como SRP, OCP, LSP, etc., para asegurar que cada componente cumple con los estándares de diseño.
5.Pruebas Unitarias:
Cada componente debe ser probado individualmente para asegurarse de que funciona correctamente según sus especificaciones.
6.Documentación Detallada:
Crea documentación exhaustiva para cada componente. Esto incluye descripciones de funciones, diagramas de clases y cualquier otra información relevante.
7.Integración de Componentes:
Una vez que los componentes individuales han sido diseñados y probados, se procede a integrarlos en el sistema completo.
DISEÑO DE COMPONENTES BASADOS EN CLASE
Acoplamiento
La comunicación y la colaboración son elementos esenciales en los sistemas orientados a objetos, pero su importancia puede ser oscura. A medida que aumenta la conectividad, aumenta la complejidad del sistema, lo que dificulta la implementación, prueba y mantenimiento del software. El acoplamiento es la medida cualitativa del grado de interdependencia entre clases, con el objetivo de mantener una baja superposición.
Acoplamiento externo
Sucede si un componente se comunica o colabora con componentes de infraestructura (por ejemplo, funciones del sistema operativo, capacidad de la base de datos, funciones de telecomunicación, etc.). Aunque este tipo de acoplamiento es necesario, debe limitarse a un número pequeño de componentes o clases dentro de un sistema.
Acoplamiento de inclusión o importación
Pasa cuando el componente A importa o incluye un paquete o el contenido del componente B.
Acoplamiento de tipo de uso
Ocurre si el componente A usa un tipo de datos definidos en el componente B (esto ocurre siempre que “una clase declara una variable de instancia o una variable local como si tuviera otra clase para su tipo” . Si cambia la definición de tipo, también debe cambiar todo componente que la utilice.
Acoplamiento de rutina de llamada
Tiene lugar cuando una operación invoca a otra. Este nivel de acoplamiento es común y con frecuencia muy necesario. Sin embargo, aumenta la conectividad del sistema.
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.
Acoplamiento de molde
Se presenta cuando se declara a ClaseB como un tipo para un argumento de una operación de ClaseA. Como ClaseB ahora forma parte de la definición de ClaseA, la modificación del sistema se vuelve más compleja.
Acoplamiento del control
La Operación A() invoca la Operación B() y pasa una banda de control a B, causando que la banda "dirige" fluya dentro de B. El problema con este enfoque es que un cambio no relacionado en B puede resultar en la necesidad de cambiar la significado de la banda de control que pasa por A, lo que lleva a un error.
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 contenido
Es el nivel más alto de acoplamiento y ocurre cuando un componente tiene acceso directo a la implementación interna o lógica de otro componente. Esto significa que un componente con acoplamiento de contenido está altamente dependiente de los detalles internos de otro componente.
Cohesión
la cohesión se define como la "unidad objetiva" de un componente en el contexto de diseño de sistemas orientados a objetos. Implica que un componente o clase solo contiene atributos y operaciones relacionadas entre sí y con el componente.
Comunicación
Todas las operaciones que acceden a los mismos datos están definidas. dentro de una clase. En general, estas clases se centran únicamente en acceder a los datos en cuestión y guardarlos. Sin embargo, es importante señalar que a veces hay aspectos pragmáticos de diseño e implementación que nos obligan a optar por niveles más bajos de cohesión.
Capa
Los paquetes, componentes y clases lo tienen; este tipo de cohesión se produce cuando una capa superior accede a los servicios de una inferior, pero ésta no tiene acceso a las superiores. Los paquetes ocultos contienen componentes de infraestructura. Es posible acceder al paquete del panel de control hacia abajo.
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.
Lineamientos de diseño en el nivel de componentes
Dependencias y herencia
Para una mejor legibilidad, es una buena idea modelar las pendientes de izquierda a derecha y la herencia de abajo (clases obtenidas) hacia arriba (clases obtenidas). base). Además, las interdependencias de los componentes deben estar representadas por interfaces y no por dependencias de componente a componente. Según la filosofía del PAC, este ayudará a que sea más fácil mantener el sistema
Interfaces
Las interfaces proporcionan información crucial de comunicación y colaboración, lo que ayuda a cumplir con el PAC. Sin embargo, su representación puede complicar los diagramas de componentes. Ambler recomienda representar las interfaces con una paleta, que fluye desde el lado izquierdo de la parte posterior del componente y excluir solo las interfaces relevantes para el componente que se está considerando.
Componentes
Las convenciones de nombres de componentes en el modelo arquitectónico deben ser especificadas para mejorarlos y elaborarlos. Los nombres de componentes deben provenir del dominio del problema y significar algo para todos los participantes. Los estereotipos pueden ayudar a identificar la naturaleza de los componentes en el nivel de diseño detallado, como el <> para identificar un componente de infraestructura, una base de datos o una tabla.
Principios básicos del diseño
Principio de la reutilización común (PRC)
El texto explica que las clases que no se reutilizan juntas no deben agruparse juntas, ya que cuando cambia una o más clases en un paquete, todas las demás clases o paquetes deben actualizarse con la versión más reciente y ser pruebas para garantizar que la nueva versión ópera sin problemas. Por lo tanto, sólo las clases que se reutilen juntas deben incluirse en un paquete.
Principio de cierre común (PCC)
Las clases deben empacarse en forma cohesiva, agrupando como parte de un diseño y dirigidas a la misma área de funciones o comportamiento. Si cambiar una característica, sólo las clases dentro del paquete requieren modificación, lo que le permite un control de cambios y un mejor manejo de la liberación.
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' [Mar00]. Cuando las clases o componentes están diseñados para Para ser reutilizable, existe un contrato implícito que se establece entre el desarrollador de la entidad reutilizable y las personas que la utilizarán. En lugar de abordar cada clase individualmente, a menudo es mejor agrupar aquellas que son reutilizables en paquetes que se pueden gestionar y controlar a medida que evolucionan nuevas versiones.
Principio de segregación de la interfaz (PSI)
El PSI sugiere que una interfaz especializada de clientes debe ser creada para atienda cada categoría principal de clientes. Por ejemplo, la clase PlanodelaCasa utiliza en funciones de seguridad y vigilancia de CasaSegura. La interfaz para la seguridad operaciones incluye SituarDispositivo, MostrarDispositivo, AgruparDispositivo y QuitarDispositivo, mientras que la interfaz para vigilancia incorporará esas operaciones. Los componentes del sistema deben tener interfaces específicas para satisfacer a cada cliente. Estos principios adicionales de agrupamiento son aplicables en el diseño de componentes.
Principio de Inversión de la Dependencia (PID).
Los módulos de alto nivel no deben depender de módulos de bajo nivel, ambos deben depender de abstracciones. Además, las abstracciones no deben depender de los detalles, sino los detalles de las abstracciones.
Principio de sustitución de Liskov (PSL).
El PSL exige que cualquier clase derivada de una La clase base debe respetar cualquier contrato implícito entre la clase base y los componentes que la utilizan. En el contexto de este análisis, un "contrato" es una condición previa que debe cumplirse. true antes de que el componente utilice una clase base y una poscondición que debe ser cierto después de eso. Al crear clases derivadas, debe asegurarse de que Respetar la condición previa y poscondición.
Principio Abierto-Cerrado (PAC)
Los componentes deben estar abiertos a la ampliación pero cerrados a la modificación, ya que ésta es una característica crucial de un buen diseño a nivel de componente. El componente debe especificarse de modo que pueda ampliarse sin modificaciones internas. Se deben crear abstracciones entre la funcionalidad esperada y la clase de diseño. Por ejemplo, una función de seguridad como CasaSegura debería revisar el estado de cada sensor de seguridad, evitando una violación del PAC.
El diseño en el nivel de componentes se basa en la información desarrollada como parte del modelo de requisitos y se representa como parte del modelo arquitectónico, enfocándose en ingeniería orientada al software y elaborando clases específicas del dominio del problema y refinamiento de las clases de infraestructura.
¿QUÉ ES UN COMPONENTE?
Vision del proceso
La visión objetiva y la tradicional del diseño en el nivel de componentes se basan en la creación de nuevos componentes basados en el modelo de requerimientos. La ingeniería de software se ha enfocado en elaborar sistemas que utilizan componentes de software o patrones de diseño y se escogen en el catálogo componentes o patrones de diseño para construir la arquitectura.
Vision Tradicional
El texto explica el proceso y la interfaz de la arquitectura del software, incluido el componente modular tradicional con tres funciones: control, dominio del problema e infraestructura. También ilustra el diseño de componentes tradicionales para mesas de impresión avanzadas como ImprimirTrabajo.
Vision orientada a Objetos
En desarrollo de software para ingeniería de objetos, un componente consta de clases que colaboran para incluir todos los atributos y operaciones de instalación. Cada clase define interfaces para la colaboración con otras clases de diseño. Los ejemplos incluyen software de impresión avanzado, cuyo objetivo es obtener las solicitudes de los clientes, predecir el trabajo de impresión y automatizar las instalaciones de producción.
Concepto
En Ingeniería de Software, un componente es una unidad independiente y reutilizable de software que cumple una función específica dentro de un sistema más grande. Los componentes son piezas modulares de un programa o sistema que se pueden ensamblar y combinar para construir aplicaciones complejas.
