Embed Size (px)
DESCRIPTION
Informacion
Citation preview
SISTEMAS I
ARQUITECTURA DE SOFTWARE
2
Arquitectura de Software
Especificación de Requerimientos del sistema (SRS)
Sistema instalado y funcionando
- Arquitectura de Software- Diseño detallado- Implementación- Verificación
Arquitectura de Software
Arquitectura de Software(Concepto)• IEEE 1471
El nivel conceptual más alto de un sistema en su ambiente.
• Arquitectura es la organización fundamental de un sistema descrita en: – Sus componentes.– Relación entre ellos y con el ambiente.– Principios que guían su diseño y evolución.
Software Architecture in Practice - Kazman
“La estructura de estructuras de un
sistema, la cual abarca componentes de
software, propiedades externas visibles de
estos componentes y sus relaciones”.
Arquitectura de software
En los años 1960 ya se acercaba el concepto de arquitectura de software en los círculos de investigación. No obstante, toma popularidad en los años 1990 tras reconocerse la denominada crisis del software y como tema de interés de la incipiente disciplina de la ingeniería del software.
La Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema.
Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco
Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, flexibilidad e interacción con otros sistemas de información.
No es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto.
Arquitectura de software
Monolítica. Donde el software se estructura en grupos funcionales muy acoplados.
Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes independientes pero sin reparto claro de funciones.
Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relación con la siguiente.
7
ImportanciaVentajas de diseñar y documentar explícitamente una arquitectura de software:
– Comunicación entre stakeholders– Decisiones tempranas de diseño– Reuso a gran escala
Arquitectura Vs. DiseñoLa arquitectura y el diseño difieren en tres áreas:
Arquitectura Diseño
Nivel de Abstracción Alto nivel Bajo nivel. Enfoque específico en detalles
Entregables Planear subsistemas, interfaces con sistemas externos, servicios horizontales, frameworks, componentes reutilizables, prototipo arquitectónico
Diseño detallado componentes.
Especificaciones de codificación
Áreas de Enfoque Selección de tecnologías, Requerimientos no funcionales (QoS), Manejo de riesgos
Requerimientos funcionales
Arquitectura Vs. Diseño• La arquitectura envuelve un conjunto de decisiones
estratégicas de diseño, lineamientos, reglas y patrones que restringen el diseño y la implementación de un software.
Las decisiones de arquitectura causan un alto impacto en los proyectos de IT
Arquitectura
Diseño
Implementación
Código
La arquitectura de software forma la columna vertebral para construir un sistema de software, es en gran medida responsable de permitir o no ciertos atributos de calidad del sistema entre los que se destacan la confiabilidad y el rendimiento del software. Además es un modelo abstracto reutilizable [1] que puede transferirse de un sistema a otro y que representa un medio de comunicación y discusión entre participantes del proyecto, permitiendo así la interacción e intercambio entre los desarrolladores con el objetivo final de establecer el intercambio de conocimientos y puntos de vista entre ellos.
9
TIPOS DE ARQUITECTURAS
• Shared Data (Datos Compartidos)– Pizarrón (Blackboard)
• Cliente-Servidor• Capas Jerárquicas• Descomposición Orientada a Objetos• Tubos y Filtros• Control Centralizado• Control Basado en Eventos• Arquitecturas de Sistemas Distribuidos
– Cliente-Servidor– Objetos Distribuidos– Peer-To-Peer– Service Oriented Architecture (SOA)
Aplicaciones Monolíticas
• Interfaces gráficas de usuario (GUI).• Servicios de presentación, negocios y persistencia en la misma
máquina.
• No hay concurrencia de usuarios.• Alto acoplamiento entre tiers.
11
Shared-Data• Generalidades
– Hay un almacenamiento central de datos y un conjunto de componentes que operan sobre éste.
– Interacción - intercambio de datos persistentes– Múltiples accesos a los datos– Al menos un almacenamiento compartido– Si se avisa al consumidor de nuevos datos de interés es un Pizarrón
(Blackboard)– Si es el consumidor quien busca los datos es un Repositorio
VENTAJAS Y DESVENTAJAS• Forma eficiente de compartir grandes cantidades de datos.
– No se transmiten datos de un componente a otro.• Sin embargo, los subsistemas deben estar de acuerdo en el modelo de datos del
repositorio.• Las componentes que producen datos no necesitan conocer como van a ser
usados esos datos.• Actividades como respaldos, seguridad, control de acceso y recuperación están
centralizadas.• Sin embargo, diferentes componentes podría tener distintas políticas de
recuperación, respaldo, etc.
12
Pizarrón (Blackboard)• Fuentes de Conocimiento
– Procesos independientes que corresponden a particiones del conocimiento del mundo y del dominio dependientes de la aplicación
– Responden a cambios en el pizarrón• Estructura de datos del Pizarrón
– Estado completo de la solución del problema– único medio por el cual las Fuentes de conocimiento interactúan para
llegar a la solución• Control
– Guiado enteramente por el estado del pizarrón– Las Fuentes de conocimiento responden oportunamente cuando los
cambios en el pizarrón aplican– Puede implementarse en las FC, en el pizarrón, en un componente
separado o cualquier combinación de éstos.
13
Pizarrón (Blackboard)
14
Cliente-Servidor• El sistema se descompone en servicios y sus servidores asociados y en clientes
que acceden y usan dichos servicios.• Estilo compuesto por:
– Servidores que ofrecen servicios.– Clientes que usan servicios ofrecidos por los servidores.– Una red que permite que los clientes accedan a los servidores.
• Esto no es estrictamente necesario ya que clientes y servidores pueden estar en una misma máquina.
• Los clientes conocen a los servidores pero no a otros clientes y los servidores no tienen porqué conocer a los clientes
• la asignación de procesos a procesadores no tiene porqué ser 1:1
Arquitectura Cliente-Servidor
+ Clientes pesados, no estándar+ Conexiones dedicadas a BD+ Protocolos pesados+ Ejecución remota de SQLs
+ Alta administración+ Bajo rendimiento+ Alto tráfico de red+ Baja accesibilidad
15
Cliente-Servidor
Network
SC1SC2
CC1 CC2 CC3
CC5 CC6CC4
Servercomputer
Clientcomputer
s1, s2 s3, s4
c5, c6, c7
c1 c2 c3, c4
c8, c9 c10, c11, c12
Ci = clientes
Si = servidores
16
Cliente-Servidor
17
Cliente-Servidor
Evolución de Arquitecturas• Arquitectura Cliente-Servidor
Mejorada
• Lógica de negocios en BD• Clientes pesados, no estándar.• Conexiones dedicadas a la BD.• Mejora en rendimiento• Alta administración• Baja escalabilidad• Baja flexibilidad• Baja portabilidad
Arquitectura de 3 niveles
+ Reutilización de lógica de negocio para
diferentes clientes o sistemas.+ Mejora la escalabilidad.+ Mejora la flexibilidad.+ Independencia de la base de datos.
Evolución de Arquitecturas
• Arquitectura de N-niveles
100.000+
+ Bajo costo de administración de clientes.+ Alta accesibilidad.+ Alta flexibilidad.+ Alta disponibilidad y tolerancia a fallos.+ Alta escalabilidad.+ Independencia de DB
Evolución de Arquitecturas
• Arquitectura de N-niveles
Evolución de Arquitecturas
100.000+
Arquitectura de 3 niveles
Evolución de Arquitecturas
100.000+
Arquitectura de N niveles
23
Capas Jerárquicas• El sistema se organiza en capas.• Cada una provee un conjunto de servicios a las capas superiores y requiere
servicios de las inferiores.
• Modelo estricto: una capa sólo utiliza servicios de la inmediata inferior.• Modelo relajado: se pueden “saltar” capas.• Definición de protocolos mediante los que interactúan las capas
24
Capas Jerárquicas• Ventajas
– Facilita la comprensión – Facilita mantenimiento– Facilita reutilización– Facilita portabilidad
• Desventajas– No siempre es fácil estructurar en capas ni identificar los niveles de
abstracción a partir de los Requerimientos.– la interpretación de comandos en múltiples niveles puede afectar el
desempeño.
25
Descomposición O.O.• Se descompone el sistema en un conjunto de objetos que se comunican.• Representación de datos y operaciones asociadas se encapsulan en un
objeto.• Herencia, polimorfismo, sobrecarga de operadores, enlace dinámico.
• Ventajas– La implementación de los objetos puede ser cambiada sin afectar a
otros objetos.– Promueve la reutilización de componentes.– Muchos objetos representan entidades de la realidad por lo que es fácil
entender la estructura del sistema.• Desventajas
– Para usar servicios se debe conocer el nombre de la interface de otro objeto.
– Los cambios en las interfaces afectan a todos los objetos que la usan.
26
Descomposición O.O.
Process View Deployment View
Logical View
Use-Case View
Implementation View
End-user
Functionality
Programmers Software management
PerformanceScalabilityThroughput
System integrators
System topology Delivery, installation
communication
System engineering
Analysts/DesignersStructure
27
Tubos y Filtros• Se descompone el sistema en módulos funcionales• Interacción - sucesiva transformación de flujos de datos• Los datos llegan a un filtro, se transforman y son pasados a través
de tubos al siguiente filtro• Un único filtro puede pasar datos a múltiples tubos y recibir datos de
múltiples tubos• Cada filtro es independiente del resto y no conoce la identidad de los
otros filtros• La transformación del filtro puede comenzar antes de terminar de
leer la entrada• Respetando el grafo, no importa la secuencia (paralelismo)
Filtro
Tubo
28
Ventajas y Desventajas(Tubos y Filtros)• Ventajas
– Se pueden reutilizar los filtros.– Es intuitivo pensar en secuencias de procesamientos de datos.– Agregar nuevas transformaciones de forma que el sistema
evolucione es sencillo.• Desventajas
– Acordar cuál es el formato de los datos.• Tiene que ser “genérico” si las componentes son reusadas.
– Sistemas interactivos son difíciles de construir con este estilo.– Ineficiente si hace más de lo que debe o si los filtros repiten
chequeos
29
Modelos de Control• Modelos de control a nivel de la arquitectura se preocupan del flujo
de control entre subsistemas– Control centralizado
• Un subsistema controla al resto– Control basado en eventos
• Cada subsistema puede responder a eventos externos– Eventos generados por otros subsistemas– Eventos generados por el ambiente del sistema
30
Control Centralizado (1)
• El control centralizado se puede dividir en dos clases– Llamada-Retorno
Principal
Subr. A Subr.B Subr.C
Subsistema
Llamado/Retorno
31
Control Centralizado (2)• Modelo Gerente
– Una componente es el gerente del sistema y controla a los otros procesos del sistema
Controlador del Sistema
A
B
F
E
C
D
32
Control Basado en Eventos• En los modelos centralizados las decisiones de control suelen estar
determinadas por valores de alguna variable de estado del sistema• En cambio, el control basado en eventos es guiado por eventos
generados externamente• Ejemplos
– Modelos emisión (broadcast). Se emiten los eventos a todos los subsistemas.
– Modelos guiados por interrupciones. Se usan en sistemas de tiempo real. Las interrupciones son pasadas por un manejador de interrupciones a otras componentes para su procesamiento.
33
Arquitecturas de Sistemas Distribuidos
• Ventajas– Se comparten recursos.– Apertura. Normalmente estos sistemas están diseñados con protocolos
estándar.– Concurrencia.– Escalabilidad– Tolerancia a fallas
El procesamiento de la información es distribuido entre varias computadoras.
• Desventajas– Complejidad– Seguridad– Difíciles de gestionar– Muy poco predecibles
• Ejemplos– Cliente-servidor– Objetos distribuidos– Peer-to-peer– Service oriented architecture (SOA)
34
Objetos Distribuidos• En la arquitectura cliente-servidor los clientes y los servidores son distintos
– Los clientes reciben servicios de los servidores y no de otros clientes– Los servidores pueden actuar como clientes de otros servidores pero no
requieren servicios de clientes– Los clientes deben conocer los servicios ofrecidos por servidores
específicos y deben conocer como contactar a estos servidores• Enfoque más general
– Remover la distinción entre clientes y servidores– Diseñar la arquitectura como una de objetos distribuidos
35
Objetos Distribuidos• Se compone de objetos que proveen servicios a otros objetos y usan
servicios de otros objetos– No hay distinción entre clientes y servidores– Pueden ser distribuidos entre distintas computadoras en una red y
se comunican a través de middleware• Este tipo de middleware se conoce como Object Request
Broker (ORB), por ejemplo, CORBA.– Es más complejo de diseñar que cliente-servidor
Software bus
o1 o2 o3 o4
o5 o6
S (o1) S (o2) S (o3) S (o4)
S (o5) S (o6)
36
Peer-to-Peer• Sistemas descentralizados donde las computaciones pueden ser realizadas
en cualquier nodo de la red– En principio no hay distinción entre clientes y servidores– El sistema se diseña para usar el poder de almacenamiento y
procesamiento de múltiples computadoras en una red– Los protocolos que permiten la comunicación entre nodos están
embebidos en la propia aplicación• Cada nodo debe correr una copia de la aplicación
• Ejemplos– Sistemas para compartir archivos– Mensajería instantánea– Seti@home
• Y otros @home– Se está comenzando a usar también en el área de negocios
• Intel y Boeing han implementado sistemas intensivos en las computaciones con arquitecturas p2p
• Se pueden clasificar en sistemas descentralizados o semi-centralizados
37
Service Oriented Architecture (SOA)• Organizaciones que quieren hacer su información accesible a otros programas
pueden hacerlo definiendo y publicando una interface de servicio web
• Un servicio web es una representación estándar para algún recurso computacional o de información que puede ser usado por otros sistemas
El servicio es independiente de las aplicaciones que lo usanSe pueden construir aplicaciones mediante el uso de distintos serviciosHay varios modelos de servicios distintos. Conceptualmente todos operan de acuerdo al siguiente modelo
Evolución de Arquitecturas• Visión de Arquitectura Orientada a
Servicios (SOA)
Cluster deServidores de Aplicaciones
AplicacionesLegadas
Servidor de Procesos
(BPM)
Base de Datos
SistemaBatch
Portal deServicios Integrados
+ Requerimientos
Arquitectónicos
+ Heterogeneidad+ Escalabilidad+ Disponibilidad+ Distribución+ Manejabilidad de Procesos+ Administración y monitoreo de procesos,
servicios e infraestructura
Definición de Arquitectura en RUPFase de Inicio+ Con respecto a la arquitectura, en la fase de inicio
de los proyectos se establece:
– Requerimientos no-funcionales– Lista de riesgos y restricciones– Arquitectura inicial
Fase de Elaboración+ Con respecto a la arquitectura, en la fase de
elaboración se establece:– Arquitectura línea base.
+ Entregables:– Documento de Definición de
Arquitectura.– Prototipo evolutivo de arquitectura.
– Guías y Estándares de Diseño.
Definición de Arquitectura en RUP• Modelo de Vista 4+1• Framework para Descripción de Arquitectura, basado en
vistas lógicas y físicas UML y una vista funcional de casos de uso.
Process View Deployment View
Logical View
Use-Case View
Implementation View
End-user Functionality
Programmers Software management
PerformanceScalabilityThroughput
System integratorsSystem topology
Delivery, installationcommunication
System engineering
Analysts/DesignersStructure
41
Ejemplo• Un sistema de información para un auto provee al conductor con
información acerca del clima, las condiciones del tráfico, información local, etc. Esto está vinculado con la radio del auto de forma que la información es entregada como una señal en un canal específico de la radio
• El auto está equipado con un recibidor GPS para conocer su posición y, basado en esa posición, el sistema accede a un rango de servicios de información. La información debe ser entregada en el lenguaje especificado por el conductor
42
Ejemplo
User interface
Locator
Discovers carposition
Weatherinfo
Receives requestfrom user
Receiver
Receivesinformation stream
from services
Transmitter
Sends position andinformation request
to services
Radio
Translates digitalinfo stream toradio signal
In-car software system
Mobile Info Service
Facilitiesinfo
Translator
Roadlocator
Trafficinfo
Collates information
Road traffic info
commandgps coord
gpscoord gps coordgps coord
Languageinfo
Infostream
Service discovery
Finds availableservices
43
Evaluación de Arquitecturas
• Cambiar la arquitectura de un producto ya construido requiere mucho esfuerzo
• Entonces, es importante evaluar la arquitectura antes de implementarla completamente
• Verificar los requisitos de calidad establecidos• Evaluaciones a posteriori resultan útiles como forma de
aprendizaje y estudio de posibilidades de mejora, por ej. para una nueva versión del producto
• Software Engineering Institute (SEI) propone:– Architecture Tradeoff Analysis Method (ATAM)– Software Architecture Analysis Method (SAAM)
Ejemplo de Definición de Arquitectura
• eBank Trusted Hosting• Workshop de Arquitectura y Diseño de Aplicaciones J2EE• Curso WS50I - Lucasian Labs Ltda.
• Entidad que presta el hosting de los servicios de banca personal en Internet para un grupo de bancos.
Ejemplo de Definición de Arquitectura
• Dado un conjunto de requerimientos primarios
Ejemplo de Definición de Arquitectura
• Identificación de requerimientos funcionales y de calidad de servicio (QoS)
Ejemplo de Definición de Arquitectura
• Identificación de supuestos, riesgos y restricciones
Ejemplo de Definición de Arquitectura
• Identificación de Actores y Casos de Uso primarios
Ejemplo de Definición de Arquitectura
• Arquitectura Lógica. Identificación de tiers lógicos, subsistemas y paquetes
Ejemplo de Definición de Arquitectura
• Diseño de Arquitectura Runtime. Diagrama de Despliegue.
Ejemplo de Definición de Arquitectura
• Plataforma Tecnológica. Definición de la matriz tecnológica de layers y tiers
Discusión
+ Los requerimientos no funcionales son fuentes comunes de riesgo…
Calidades Sistémicas+ El manejo inadecuado de los requerimientos no funcionales, es una de
las fuentes más importante de riesgo en los proyectos:
– Reglas de negocio de alta complejidad.– Calidades sistémicas
- Seguridad- Rendimiento- Escalabilidad- Disponibilidad- Extensibilidad
+ La calidad de servicio (QoS = Quality Of Service) es un riesgo primario
relacionado con la arquitectura.
Calidades Sistémicas
• Definición
• Propiedades que establecen la calidad de servicio (QoS) que un sistema expone.
• Son globales a toda la arquitectura
• Influencian el diseño.
• Son no-funcionales pero observables.
+ Familias de Calidades
Sistémicas
+ Manifiestas+ Operacionales+ Desarrollo + Evolutivas
Calidades Sistémicas - Manifiestas
• Observables por los usuarios del sistema.
• Performance. Tiempo de respuesta desde el punto de vista del usuario.
• Reliability. Grado de probabilidad de realizar operaciones correctamente.
• Availability. Porcentaje de tiempo que un sistema puede procesar solicitudes.
Calidades Sistémicas - Operacionales
• Throughput. Solicitudes atendidas por unidad de tiempo.
• Manageability. Cantidad inversa de esfuerzo para realizar labores administrativas.
• Serviceability. Esfuerzo para actualizar el sistema para reparar errores.
+ Security. Prevención de uso indeseado, por abuso o uso inapropiado:
– Identidad– Autoridad– Confidencialidad– Auditabilidad– Integridad
+ Testability. Esfuerzo invertido para detectar y aislar errores.
Observables cuando el sistema está operando en producción.
Calidades Sistémicas - Evolutivas
• Relacionadas con el comportamiento del sistema cuando sufre algún cambio.
+ Escalability. La habilidad para soportar la calidad de servicio requerida conforme la carga aumenta.
+ Flexibility. Esfuerzo ahorrado cuando
se hace un cambio de configuración.
+ Portability. Esfuerzo ahorrado cuando
se migra a una infraestructura
diferente.
+ Reusability. Esfuerzo ganado en la
utilización de componentes existentes.
+ Extensibility. Esfuerzo ahorrado para
adicionar nuevas funcionalidades.
+ Mantainability. Esfuerzo ahorrado para
revisar y corregir errores.
