martes, 23 de julio de 2013

UNIDAD 3 PARADIGMA ORIENTADO A COMPONENTES




INSTITUTO TECNOLÓGICO DE OAXACA


UNIDAD 3


PARADIGMA ORIENTADO A
COMPONENTES



CATEDRÁTICO: LIC. JAIME R. LAGUNAS PIÑON



NICOLÁS MENEZ  REYNA SONIA


LICENCIATURA EN INFORMÁTICA


22/07/2013
 

ÍNDICE


3 PARADIGMA ORIENTADO A COMPONENTES



3.1 CONCEPTO Y USO DE LOS COMPONENTES DE SOFTWARE



3.2 REVISIÓN



3.2.1 TIPOS


3.2.2 CARACTERÍSTICAS


3.2.3 TECNOLOGÍAS


3.3 INTERFAZ

 

3.4 DISEÑO


 

 

3.1 CONCEPTO Y USO DE LOS COMPONENTES DE SOFTWARE


El objetivo de la tecnología de componentes software es construir aplicaciones complejas mediante ensamblado de módulos (componentes) que han sido previamente diseñados por otras personas a fin de ser reusados en múltiples aplicaciones.

Conceptos:

·        Un componente es una unidad de composición de aplicaciones software, que posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio.( Szyperski [1998])

·        Un componente de software individual es un paquete de software, un servicio web, o un módulo que encapsula un conjunto de funciones relacionadas (o de datos).

·        Un componente de software: Es una unidad de composición con interfaces especificadas en forma de contrato y con dependencias de contexto explícitas. Un componente de software puede ser desplegado o instalado independientemente y es sujeto a ser composición por terceras entidades".

·        Un componente de software se define como un paquete de software (grupo de archivos) o modulo, que realiza un proceso en específico, obteniendo unos resultados acordes con el proceso realizado. Un componente de software se presenta por lo general en dos:

o   Componentes ejecutables: Que son los componentes los cuales  han sufrido  procesos de compilación y ligado.

o   Componentes basados en código fuente: Los cuales  sufren el proceso de compilación(o interpretación según sea el caso), indirectamente (ejemplo de estos componentes son los archivos hosteados en un servidor web, los cuales son “compilados” por el servidor al enviar una respuesta al cliente).

Un componente de software por lo general está compuesto de uno o varios archivos, los cuales puede estar compilados o sin compilar.

UTILIDAD

Es utilizado para reducir los costos, tiempo y esfuerzos de desarrollo del software, y de esta manera incrementar el nivel de productividad de los grupos desarrolladores y minimizar los riesgos; a su vez ayuda a optimizar la fiabilidad, flexibilidad y la reutilización de la aplicación final.
De esta manera, las pequeñas empresas pueden tener una mayor confiabilidad a la hora de realizar una inversión tecnológica.

7 criterios [Meyer, 1999]:

•      Puede ser usado por otros elementos de SW
•      Puede ser usado por los clientes sin la necesidad de la intervención del desarrollador.
•      Incluye las especificaciones de todas las dependencias.
•      Incluye documentación de las funcionalidades que ofrece
•      Se puede entender su funcionamiento en base a las especificaciones.
•      Se puede acoplar a otros componentes
•      Puede ser incorporado a un sistema de manera suave y rápida

3.2 REVISIÓN

3.2.1 TIPOS


Componentes de despliegue o distribución (Deployment)

Estos componentes se usan para formar un sistema ejecutable. Un ejemplo de tal componente es la librería de enlace dinámico y los archivos ejecutables. Otros ejemplos son los componentes COM+, Enterprise Java Beans, componentes CORBA y objetos de base de datos.

Componentes de Producto de Trabajo
Estos componentes son parte del proceso de desarrollo que es esencial para el sistema. Algunos ejemplos de componentes de producto de trabajo son los archivos fuente, archivos de datos y tablas. Ellos son los archivos fuente y archivos de datos que se usan para crear los componentes de distribución como Agente Analizado.Java y AnalizadorDatos.txt.

Componentes de Ejecución
Estos componentes son el resultado de un sistema que se está ejecutando. Cuando un DLL es instanciado como un componente COM+, es un ejemplo de un componente de ejecución.

Componentes utilizados en la elaboración de software:
*      Componentes de acceso trabajo y conexión a datos
*      Componentes de interfaz con el usuario
*      Componentes para tratamiento de imágenes
*      Componentes de envió de notificación (Email,sms, etc.)
*      Componentes de manejo avanzado de interfaz con el usuario
*      Componentes de generación de estadísticas de usuario
*      Componentes de enlace a otros tipos de software
*      Componentes para trabajo y comunicación con diversos protocolos de red

3.2.2 CARACTERÍSTICAS


Las  características principales de un componente software son:

Aislamiento: Un componente puede ser instalado de forma independiente en una plataforma.

Composición: Un componente puede ser compuesto con otros para formar aplicaciones. Es decir, una compañía o un desarrollador puede llegar y tomar el componente y agregarlo a lo que esté haciendo, o sea haría una composición de componentes.

Opacidad: Un componente se maneja siempre de forma opaca, sin que los diseñadores de aplicaciones que lo manejan ni el entorno tengan que acceder a sus detalles internos para hacer uso de él.

Reutilización: La capacidad de ser reutilizado es una característica importante de los componentes de software de alta calidad. Un componente debe ser diseñado e implementado de tal forma que pueda ser reutilizado en muchos programas diferentes.

Simplifica el mantenimiento del sistema: Cuando existe un débil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.

Mayor calidad: Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.

Es una unidad ejecutable: que puede ser implantada independientemente (esto de implantado es que puede ser instalado).

Un componente no tiene estado (al menos externamente visible)
Se puede tomar a los componentes de software como una analogía a los componentes electrónicos, la idea de esto es tener diversos componentes que puedan ser tomados para hacer un sistema más grande, así como tomar procesadores, integrados, memorias, etc. para hacer una computadora por ejemplo.


Definir interfaces: La característica fundamental de un componente es la habilidad de definir interfaces.

Es genérico: Sus servicios deben servir para varias aplicaciones.

3.2.3 TECNOLOGÍAS


La forma concreta de especificar, implementar, o empaquetar un componente depende de la tecnología utilizada.

·         Una tecnología de componentes incluye:
o    Modelo de componentes: Define un marco conceptual para el desarrollo de componentes y de aplicaciones generadas por ensamblado:
§  Define de forma exacta que se entiende por componente, y como se especifica el componente y sus interfaces
§  Define los modos de interacción entre componentes
o    Plataforma de componentes: Entorno que de una infraestructura de soporte para la ejecución de aplicaciones basadas en componentes
§  Se basa en un determinado modelo de componentes
§  Incluyen servicios de soporte para los componentes: gestión de su ciclo de vida,  persistencia, comunicación entre ellos, etc.
EJEMPLOS DE TECNOLOGÍAS

3.3 INTERFAZ


Se llama interfaz a la parte del software del ordenador que tiene por misión la comunicación con el usuario, así como también se llama interfaz a los dispositivos de hardware que se encargan de interconectar a diferentes dispositivos entre sí. Es una conexión e interacción entre el hardware y el software, entre el hardware y el usuario o bien entre el software y el usuario.

Especificación de una interfaz

La interfaz representa el conjunto de operaciones y modelo de información que se requiere para definir completamente el servicio que se espera del componente que las oferte y lo que el cliente debe espera de su uso.

La especificación de una interfaz contiene:

·        El identificador de la declaración de la interface al que se hace referencia en su instanciación dentro de un componente.
·        El modelo de información, esto es, los atributos, tipos, asociaciones, etc. Definidos unos en función de otros hasta proporcionar un modelo completo y cerrado.
·        La descripción de las operaciones a través de los que el usuario puede acceder al servicio proporcionado por la interfaz. Esto supone definir la especificación completa de cada operación (identificador, parámetros, precondiciones y post condiciones, etc.).
·        Conjunto de invariantes y restricciones del modelo de información de la interfaz.
·        Otras interfaces con las que tiene establecidas relaciones de dependencia o de herencia.

Los servicios que ofrece o requiere un componente se expresan mediante interfaces

 

Representan el contrato entre el componente cliente y el componente  servidor

Concepto base en desarrollo basado en componentes => Separación entre interfaz e implementación



 



3.4 DISEÑO


El diseño a nivel de componentes establece los datos algorítmicos que se requieren para manipular las estructuras de datos, efectuar la comunicación entre los componentes del software por medio de las interfaces.

Se puede definir y usar componentes desde 3 puntos de vista:
*      Orientado a Objetos
*      “Convencional”
*      Relacionado a procesos

Punto de vista orientado a objetos

·        Desde este punto de vista, un componente contiene un conjunto de clases que colaboran entre sí.
·        El diseño de un componente implica añadir a la definición de clases en el análisis (dominio del problema) información para su implementación en software.

Punto de vista “convencional”
·        Desde este punto de vista, un componente es un elemento funcional de un programa que incluye lógica de procesamiento, estructuras de datos internas requeridas para implementar dicha lógica y una interfaz que permite que el componente sea invocado y que se le puedan pasar datos.
·        Normalmente llamado “módulo”

Roles de un componente “convencional”
·        Componente de control: Coordina el llamado a otros componentes del dominio del problema
·        Componente del dominio del problema: implementa una función completa o parcial que es requerida por el usuario
·        Componente de infraestructura: responsable de las funciones que apoyan el procesamiento requerido en el dominio del problema
·        Utilizan cartas de estructura para describir sistemas

Punto de vista relacionado al proceso
·        Reutiliza software
·        Cuando se desarrolla la arquitectura, se escogen componentes o patrones de diseño de un catálogo, los cuales fueron creados para ser reutilizados

Diseñando componentes basados en clases

Hay 4 principios básicos de diseño que se pueden aplicar:

·        Principio “abierto-cerrado”: Un componente debe estar abierto a extensiones pero debe estar cerrado para modificaciones.  El/la diseñador(a) debe especificar el componente de manera que puede extenderse sin necesidad de hacer modificaciones internas al código.

·        Diseñando componentes basados en clases (2)
o   Principio de substitución de Liskov: Las subclases deben ser sustituibles por sus clases bases. Cualquier clase derivada de una clase base debe cumplir con cualquier contrato implícito de la clase base con respecto a los componentes que la usan. Un “contrato” es una precondición que debe ser verdadera antes de que el componente use la clase base, y una post-condición debe ser verdadera después de que el componente usa la clase base.

·        Diseñando componentes basados en clases (3)
o   Principio de dependencia de inversión: “Se debe depender de abstracciones, no de eventos concretos”
o   Principio de segregación de interfaces: “Varias interfaces dependientes del cliente son mejor que una interfaz de propósito general”

·        Principios de empaquetado
o   Principio de equivalencia de liberación y reusó: “La granularidad del reusó es la granularidad de liberación.” Agrupar clases reusables en paquetes que se puedan administrar y controlar cuando una nueva versión se genere.
o   Principio de agrupamiento común: “Las clases que cambian al mismo tiempo deben agruparse”
o   Principio de reusó común: “Las clases que no se reúsan al mismo tiempo no deben agruparse”.
 
Guías de diseño

ü  Establecer convenciones para poner nombres
ü  Utilice notación de interfaces siempre que pueda, dibújelas en el lazo izquierdo de los diagramas y solo las que sean relevantes
ü  Modele las dependencias de izquierda a derecha y la herencia de abajo (clase derivada) hacia arriba (clase base)

Cohesión y acoplamiento

ü  La cohesión implica que un componente o clase encapsula solo atributos y operaciones que están altamente relacionados entre ellas y con la clase. Se busca la máxima cohesión en una clase
ü  Acoplamiento es la medida cualitativa del grado en que una clase está conectada con otra. Se busca el mínimo acoplamiento entre clases

Pasos para diseño de componentes

  1. Identifique todas las clases de diseño que correspondan al dominio del problema
  2. Identifique todas las clases de diseño que correspondan al dominio de la infraestructura (GUI, sistemas operativos, administración de datos etc.)
  3. Elabore todas las clases que no provienen de clases reusadas
a)      Especifique detalles de los mensajes entre clases que colaboran
b)      Identifique las interfaces de cada componente
c)      Elabore atributos y defina tipos de datos y estructuras de datos requeridas para implementarlas
d)      Describa el flujo de procesamiento de cada componente en detalle

Pasos para diseño de componentes (2)

  1. Describa fuentes de datos persistentes (bases de datos y archivos) e identifique las clases requeridas para manipularlos
  2. Desarrolle y elabore representaciones del comportamiento de una clase o componente (diagramas de estados)
  3. Elabore diagramas de liberación (deployment) para dar detalles adicionales de implementación
  4. Revise cada representación de diseño de los componentes y siempre considere alternativas

Diseñando componentes “convencionales”

Hay 3 estructuras básicas:
Secuencia, selección e iteración
ü  Los diagramas de flujo son los predecesores de los diagramas de actividades (ver figura 11.10)
ü  Las tablas de decisión se utilizan para definir procesos con una gran cantidad de condiciones y acciones
ü  Los lenguajes de diseño de programas (PDL) también llamados ingles estructurado o pseudocódigo permiten definir el detalle de un algoritmo. [Pressman 2010]

BIBLIOGRAFÍA

Martínez, Luis F. Iribarne. Modelo de Mediacion para el Desarrollo de Software basado en Componentes COTS. Universidad de Almería : s.n., 2003.
Mendez, Oscar. Desarrollo de Software basado en Componentes. msdn.microsoft.com. [En línea] http://msdn.microsoft.com/es-es/library/bb972268.aspx

www.Desarrollo de Software basado en Componentes.htm


www.Ingenier%C3%ADa%20de%20software%20basada%20en%20componentes%20-%20Wikipedia,%20la%20enciclopedia%20libre.htm
Publicado por en No hay comentarios:
Suscribirse a: Entradas (Atom)