Ingeniería de Sistemas y Computación

Desarrollo de Software a Gran Escala: Desarrollo por

Componentes

Fernando Barraza A., Ms.C fbarraza@javerianacali.edu.co

Agenda •  Objetivo: Exponer los fundamentos básicos y técnicas

más utilizadas para el desarrollo de software por componentes

•  Temas: – Arquitectura de Software – Concepto de Componente – Tecnicas de API’s – Patrones y Estilos de implementación

Definición Arquitectura de Software

•  Es la estructura de alto nivel de un sistema, descrita en términos de componentes y las propiedades y relaciones visibles externamente entre ellos (Bass, Clements, Kamant)

Metáfora: Construcciones Civiles Proyecto para un plan de ciudad y sus diferentes componentes comparten una

estructura común.

Arquitectura Ciudad

Arquitectura Escuela

Arquitectura Iglesia

Arquitectura Transporte

Proyecto grifería

Plano cimientos

  Separación de preocupaciones   Ocultar complejidad   Diseño mediante interfaces   Separación / distribución de

responsabilidades

Principios de arquitectura básicos

 Permite absorber nuevas funciones con un esfuerzo proporcional al tamaño del cambio.

 Soporta el desarrollo paralelo, la construcción incremental y una verificación de las partes por separado.

 Sus componentes están cohesionado por responsabilidades, evitando la redundancia y el rehacer el trabajo.

 Optimiza la infraestructura para poder proveer los niveles de servicio requeridos.

Características de una buena arquitectura

Elementos estructurales de la AS

• Componentes •  Interfaces (puertos) • Conectores

Diagrama de componentes en UML

Componentes Interfaces

Puertos Conectores

Componentes

• Representan elementos computacionales y almacenamientos de un sistema. Por ejemplos: – Servidor de aplicaciones – Unidad física de software – Base de datos relacional

• Un componente se define siempre dentro de una familia de componentes

Detalle de los componentes

•  Puede estar hecho de un conjunto interno de clases, paquetes de clases e interfaces

•  Las interfaces exponen los puntos visibles de entradas a los servicios desde otros componentes

Interfaz (API)

Ejemplo

Interfaces

• Conectan los componentes. •  Los puntos de interfaz se llaman

generalmente puertos (ports) •  Los puertos pueden definir interfaces tanto

simples como complejas, desde una signatura de procedimiento hasta una colección de rutinas a ser invocadas en cierto orden, o un evento de multicast.

Conectores

•  Son entidades que representan interacciones entre componentes.

•  Los conectores también tienen interfaces que están definidas por un conjunto de roles.

•  En la implemenación se utilizan diversas tecnologías, por ejemplo: –  Invocador RPC. – Sockets – Memoria compartida.

Propiedades de una AS

•  Algunas medidas usuales: – Acoplamiento – Cohesión – Desempeño – Escalabilidad – Mantenibilidad – Seguridad – Integrabilidad

Dependencia

Los componentes C1, .. C4 son dependientes del componente de tercera parte, si este ultimo se reemplaza por otro componente on una interfaz diferente, muy seguramente se requeriran cambios en C1, …, C4.

Solo el componente AL depende del Componente del tercero. Si este ultimo Es reemplazado solo AL debe revisar su Interfaz con dicho componente.

Desempeño

• Define el rendimiento de una aplicación en función de la cantidad de trabajo que debe tomar una solicitud en un momento dado, y / o los límites de tiempo que se deben cumplir para su correcto funcionamiento.

• Usualmente tiene dos metricas asociadas: – Troughput – Tiempo de respuesta

Troughput

•  Es la medida que indica la cantidad de trabajo que puede hacer una aplicación en una unidad de tiempo.

•  Ejemplos de medidas: – Transacciones por segundo (tps) – Mensajes procesados por segundo (mps)

Tiempo de respuesta

•  Se refiere a la latencia que una aplicación tiene al procesar una transacción.

•  Frecuentemente es medido en milisegundos, desde el momento que una aplicación recibe una entrada hasta que la procesa, sin incluir su despliege.

•  El tiempo puede estar delimitado por “deadlines”, los cuales indican los tiempos máximos permitidos para una transacción.

Escalabilidad

•  Es la capacidad de la aplicación para funcionar correctamente si el tamaño de procesamiento se incrementa.

•  El tamaño de procesamiento se refiere a: – Requerimientos de carga – Conecciones simultaneas – Tamaño de los datos – Despliegue

Requerimientos de carga

• Una arquitectura escalable debe permitir adicionar capacidad de procesamiento para incrementar el throughput y decrementar el tiempo de respuesta.

• Dos estrategias para escalar una aplicación: – Scale-Up – Scale-Out

Scale Up / Scale Out

Mantenibilidad •  Es una atributo de calidad que mide que tan fácil

es cambiar una aplicación para soportar nuevos requerimientos funcionales y no funcionales.

•  Las medidas de mantenibilidad son relevantes solo en el contexto de una solución y se indican mediante la descripción de los componentes de de la arquitectura y como interactuan entre ellos y con el entorno

Requerimientos de Seguridad Comunes

•  Autenticación: La aplicacion puede verificar la identidad de los usuarios u otras aplicaciones con las cuales se comunica

•  Autorización: Usuarios o aplicaciones autenticadas tienen definidos los derechos de acceso a los recursos del sistema

•  Encripción: Los mensajes enviados y recibidos desde y hacia la aplicación están encriptados

•  Integridad: Asegura que el contenido del mensaje no puede ser alterado durante su tránsito

•  Non-repudiation: Quien envia el mensaje (sender) tiene prueba de entrega y el receptor (receiver) está seguro de la identidad de quien lo envía. Es decir, no puede refutar su participación en el intercambio del mensaje.

Disponibilidad

•  Puede ser medida por la proporción de tiempo requerido que la aplicación es usable. Ej: 99.99%

•  Las arquitecturas redundantes o con alta recuperabilidad son utilizadas para obtener alta disponibilidad

•  Arquitecturas con registro dinámico de componentes facilitan el mantenimiento y favorecen la disponibilidad del sistema

Integrabilidad

• Facilidad con la que una aplicación puede incorporarse en un contexto de sistema más amplio.

• Las estrategias más usada para alcanzar alta integrabilidad de las aplicaciones son a través de: – Integración de los datos – Integración por API

Estrategias de integración

Mecanismos de Interfaz e Integración – Interfaces y Adaptadores

• API’s • Wrapping

– Mediadores (Middleware) • Web Services

SISTEMA

API (Application Program Interface)

• Mecanismo más utilizado actualmente •  Pretende ocultar la complejidad de la

implementación de los recursos • Debe ser publicado y documentado para

ser usable

FUNCIONALIDAD API CLIENTE

API’s Comunes

Plataforma •  Microsoft Win32 API •  Microsoft

Framework .NET •  Java EE •  OpenGL •  Common Object Request

Broker Architecture (CORBA)

•  Symfony para PHP •  DRUPAL

Servicios •  API de newsletter •  Google Web APIs •  Flickr •  Twitter •  Facebook •  Yahoo •  AWS (Amazon Web

Services)

Wrapping

•  Envoltorio virtual alrededor de la aplicación que oculta a los clientes su verdadera implementación y la muestra como una aplicación C/S

• Común en integración de aplicaciones legadas

•  Se puede implementar a nivel de datos, procesos o presentación

Wrapping de BD

Base de datos

  Utiliza una base de datos intermedia como mecanismo de wrapping

  Ejemplo:

Wrapping de API

Screen Scraper

Object Wrapping

•  Mecanismo que permite conectar un del sistema (aplicación o base de datos) con otros componentes haciendo posible la integración entre aplicaciones (EAI)

•  Siguen modelos y patrones de integración – Mensajes – Bases de datos – Objetos –  ...

•  Ejemplos: DCOM, RMI, CORBA.

Middleware

•  Common Object Request Broker Architecture •  Especificación propuesta por el OMG (Object Management

Group) •  CORBA 1.1 fue introducido en 1991 y definido mediante IDL

(Interface Definition Language) y un API (Application Programming Interfaces) que permite una interacción de objetos cliente/servidor dentro de una implementación de un ORB (Object Request Broker)

•  CORBA 2.0, fue adoptado en diciembre de 1994 y define interoperabilidad real especificando como ORB’s de diferentes fabricantes pueden integrarse.

•  CORBA 3.0 es la última versión

Que es CORBA?

Estándares y Técnicas de Middleware

•  Estándares – Java – XML – Otros

•  Técnicas – Objetos remotos – Remote Scripting – Servicios Web – Agentes

Java based Middleware standars

•  JDBC: Database Oriented •  EJB: Transactional Oriented •  JMS: Message Oriented • RMI: Message Oriented •  JAX: Java-to-XML •  JCA: Java Connector Arquitecture

Implementción de AS: Consideraciones típicas

• Que dominio de aplicación vamos a desarrollar?

•  Es nuestra aplicación de misión crítica para el negocio?

• Quienes son nuestros competidores? • Cual es la plataforma candidata?

• Resultado: AS que sigue un Patrón y Estilo de Implementación.

Arquitecturas por Niveles

• Utilizadas para manejar complejidad en sistemas grandes

•  Evoluciona paralelamente a las aplicaciones

•  Implementable en diferentes topologías físicas (capas)

Diferentes Niveles

• Monolítica (ups!)

• Cliente/Servidor

•  3 y n-Capas

Cliente/Servidor

• Muy ligado al término de PC •  Basado en paso de mensajes • Un cliente requiere un servicio • Un servidor provee una serie de servicios • Una única máquina puede ser el cliente y

el servidor a la vez •  Interfaz típicas RPC o SQL

Tres Niveles •  Soluciona limitaciones de la de dos niveles •  El nivel intermedio está entre el cliente y el

servidor •  El nuevo nivel provee lógica de negocio •  Permite extender el numero de usuarios

atendidos •  Generalmente se implementa como:

–  Primer nivel: Cliente –  Segundo nivel: Aplicación –  Tercer nivel: Base de datos

N-Capas

• Mayor flexibilidad • Mayor administración • Mejor rendimiento • Más costosas • Cada capa añade funcionalidad

Web Services

•  Exponen funcionalidad de aplicaciones ocultando la complejidad interna

•  Se basan en estándares de la industria (SOAP, XML)

•  Se puede implementar mediante diversos protocolos de comunicación (JMS, HTTP, RMI, etc.)

•  Es la técnica más utilizada para implementar SOA

Arquitectura en pila de Web Services

Funcionamiento de Web Services

Estructura de WSDL

SOA: Arquitecturas Orientadas por Servicios

• Un sistema que es diseñado usando una Arquitectura orientada por servicios se conoce como un Sistema Orientado a Servicios

•  La práctica de usar sistemas orientados a servicios es conocida como computación orientada a servicios

•  SOA no es lo mismo que Web Services!!

Que es un servicio? •  Es una función que es invocada para cumplir

tareas específicas •  Los servicios …

– Exponen una interfaz bien definida (API) – Esconden detalles de implementación – Se pueden invocar mediante mecanismos con

estándares abiertos •  Se implementan generalmente mediante Web

Services

Arquitectura SOA

Servicios como componentes UML

Diseño orientado a Servicio

Modelo de implementación

Créditos

•  Essential Software Architecture. Ian Gorton. •  Describing Software Architectures. Gert Florijn. •  Workshop de Arquitectura I/T, Bogotá 2005. Carlos

Bittrich. IBM.