Sie sind auf Seite 1von 51

Ingeniería de Software

Clase 7:
Arquitectura de Software

Hugo R. Cordero S.
Clase 1
Objetivos
2

 Conocer las definiciones de la Arquitectura de Software


 Entender la importancia de la Arquitectura de Software
 Entender el rol del Arquitecto de Software
 Conocer las principales arquitecturas y tecnologías
Temas
3

1. Introducción
2. ¿Qué es la Arquitectura de Software?
3. El rol del Arquitecto de Software
4. Arquitecturas y tecnologías
5. Middleware
Introducción
4

Antecedentes
 Los ingenieros de software siempre han empleado
arquitecturas de software, muy a menudo sin darse
cuenta
 Orientado a problemas identificados por los
profesionales e investigadores
 Dificultades propias de la Ingeniería de software
 Características particulares para la programación en conjunto
 Necesidad de reutilización del software
 Muchas ideas se originaron en otros dominios (no
informáticos)
Introducción
5

Dominio de los sistemas


 Los sistemas de TI están en todos lados:

 Bancos
 Tiendas
 Militares
 Juegos
 Pueden ser Grandes, complejos, heterogéneos,
distribuidos
 Diferentes tipos: ERP, CRM, SCM, DSS, GIS, etc.
Introducción
6

Dominio de los sistemas


 Uso comercial de plataformas como middleware, base
de datos, servidores web, paquetes de aplicaciones,
familias de productos de software
 Los mayores problemas están en el diseño de la

arquitectura, selección de la tecnología, integración de


aplicaciones y de negocio
¿Qué es la Arquitectura de Software?
7

 Es hablar de diseño de software


 Toda arquitectura es diseño de software, pero no todo diseño es
una arquitectura de software
 Es parte del proceso de diseño
 La arquitectura se enfoca en los problemas que serán
difíciles/imposibles de cambiar cuando el sistema esté
construido
 Atributos de calidad como la seguridad y performance
 Requerimientos no funcionales como costos, entorno de
despliegue
¿Qué es la Arquitectura de Software?
8

Definiciones - ANSI/IEEE Std 1471-2000


 “Arquitectura es la organización fundamental de un sistema,
representado por sus componentes, sus relaciones entre ellos
y con el entorno, y los principios que guían su diseño y
evolución.”
¿Qué es la Arquitectura de Software?
9

Definiciones – Garlan and Shaw


 “[La arquitectura de software va] más allá de los
algoritmos y estructuras de datos de la computación;
diseñando y especificando la estructura general del sistema
que emerge como un nuevo tipo de problema. Problemas
de estructura, incluyen protocolos de comunicación;
sincronización y acceso a datos; asignaciones de funciones
para el diseño de elementos; distribución física; agrupación
de elementos de diseño; escalamiento y performance; y
selección sobre alternativas de diseño.”
¿Qué es la Arquitectura de Software?
10

Definiciones - SEI
 “La arquitectura de software de un programa o un sistema
computacional es la estructura o estructuras del sistema, la
cual comprende elementos de software, las propiedades
externas visibles de estos elementos, y las relaciones entre
ellos.”
La Arquitectura define la estructura
11

 Descomposición del sistema en


componentes/módulos/subsistemas
 La arquitectura define:
 Interfaces de los componentes
 Qué puede hacer un componente
 Dependencias y comunicaciones de los componentes
 Cómo un componente se comunica
 Responsabilidades de los componentes
 Precisa lo que hará un componente cuando lo llamen
Estructura y dependencias
12

 Excesiva dependencia C1 C2 C3 C4 C1 C2 C3 C4
de componentes no es
bueno
 Principales problemas AL

 Identificar componentes Third Party


que pueden cambiar Component

 Reducir la dependencia
Third Party
directa de estos Four components are directly
Component

componentes dependent on a third party


component. If the third party
Diagram Key
component is replaced with a new Only the AL (abstraction layer) component
component with a different
 Crear sistemas más interface, changes to each
component are likely.
Component is directly dependent on the third party
component. If the third party component is
replaced, changes are restricted to the AL

modificables
C component only
Dependency
Comunicaciones de componentes
13

 Comunicación involucra:
 Mecanismos de traspaso de datos, ejemplo:
 Llamada de funciones
 Invocación remota de métodos
 Mensajes asincrónicos
 Control del flujo
 Flujo de mensajes entre componentes requeridos por la funcionalidad
 Secuenciamiento
 Concurrencia/Paralelismo
 Sincronización
La Arquitectura direcciona los RNFs
14

 Son los requerimientos no funcionales que definen


“como” el sistema trabaja
 RNFs son raramente incluidos en los requerimientos
funcionales
 Deben ser identificados por el arquitecto
 RNFs incluyen:
 Restricciones técnicas
 Restricciones de negocio
 Atributos de calidad
Vistas de la Arquitectura
15

 Una arquitectura de software representa un complejo


artefacto de diseño
 Hay muchas posibles vistas de la arquitectura
 Como para la construcción de un edificio – diseño de planta,
externo, eléctrico, plomería, etc.
 Modelos de 4+1, SEI, Siemens
Vistas de la Arquitectura
16
Vistas de la Arquitectura
17

Modelo del SEI


 Módulo: vista estructural de la arquitectura, que
comprende los módulos de código tales como clases,
paquetes y subsistemas.
 Componente y conector: describe los aspectos del
comportamiento de la arquitectura. Componentes son
objetos, hilos o procesos, y los conectores describen como
interactúan los componentes.
 Asignación: muestra como los procesos son mapeados con
el hardware y dan la vista del código fuente en la
configuración del sistema.
Contexto del Sistema
18

 Un sistema siempre estará relacionado con el contexto que


lo rodea
 Conjunto de objetos exteriores al sistema, pero que
influyen decididamente a éste, y a su vez el sistema influye,
aunque en una menor proporción, sobre el contexto
 Es una entrada necesaria para la definición de la
Arquitectura del sistema
Stakeholders en la Arquitectura
19

 Desarrolladores
 Analistas
 Diseñadores
 Probadores
 Arquitectos
 Administradores
 Usuarios
 Clientes
 Vendedores
El rol del Arquitecto
20

 El rol del arquitecto de edificaciones y el arquitecto de


software parecen enfrentar los mismos retos
El rol del Arquitecto
21

 Por lo que es claro, que se debe contar, con un conjunto


básico de habilidades y conocimientos para ejercer este
tipo de roles
 Y es que no es

lo mismo
construir esto…
El rol del Arquitecto
22

 Que esto:
¿Qué hace el Arquitecto?
23

 Muchas responsabilidades:
 Definir, documentar y comunicar la arquitectura
 Enlace con los Stakeholders
 Asegurarse que todos la entiendan y la sigan
 Conocimiento de la tecnología
 Resolver los problemas técnicos
 Plantear iniciativas sobre cuestiones de herramientas y
selección de entornos
 Administración de riesgos relacionados con la arquitectura
 Extensa lista en:
 http://www.sei.cmu.edu/architecture/research/previousresear
ch/duties.cfm
¿Qué hace el Arquitecto?
24

 Es el encargado de establecer a que nivel, con que


estrategias, y que herramientas son necesarias para
realizar una implementación que satisfaga los requisitos
funcionales y no funcionales de los sistemas
• Debe ser una persona capaz
de identificar las necesidades
de los negocios, las habilidades
de su equipo de trabajo y la
viabilidad de las tecnologías
disponibles para el desarrollo.
Habilidades para el Arquitecto
25

 Tener buen conocimiento de los procesos del ciclo de vida del


desarrollo del software
 Poseer conocimiento de arquitecturas de TI y metodologías
de diseño sobre diferentes plataformas
 Tener dominio sobre áreas no funcionales, como rendimiento,
escalabilidad, interacción con usuarios
 Tiene claridad sobre lo que el negocio necesita y la
capacidad de transformarlo en resultados
 Habilidades para razonamiento crítico y toma de decisiones
 Pensamiento líder proactivo
 Comprometido con la calidad
Tipos de Arquitecto
26
Arquitecturas y Tecnologías
27

Diferentes estilos arquitectónicos


 De flujo de datos

 Tuberías y filtros
 De llamada y retorno
 Programa principal / subrutina
 Basado en componentes
 Cliente / Servidor
 Arquitectura de capas
 Modelo Vista Controlador
 Entre Pares
 Broker
 Orientado a servicios
Arquitecturas y Tecnologías
28

Diferentes tecnologías
 Plataformas de desarrollo: Java / .NET / PHP

 Middlewares
 Servidores de aplicaciones, MOM, BPMs, Message Brokers
 Herramientas de desarrollo / pruebas
 Lenguajes de programación
 Gestores de versiones
 Gestores de contenidos y portales
 Base de datos
 Frameworks
 Etc.
Arquitecturas y Tecnologías
29

 La arquitectura reduce el riesgo por el uso de patrones


de diseño probados
 Debe mapear un patrón de diseño abstracto para
concretar la implementación
 Vendedores de software tienen creadas tecnologías que
explícitamente soportan patrones ampliamente usados.
 Hacen la implementación de los patrones más fácil
 Reduce el riesgo si la tecnología está bien construida
Arquitecturas y Tecnologías
30

Abstract

Architectural Patterns/Styles

Application Messaging Message Object Process


Servers Brokers Brokers Orchestration

Concrete COTS technologies

 Cada tecnología tiene múltiples vendedores/versiones


open source
 Arquitectos necesitan seleccionar la tecnología
sabiamente
Arquitecturas
31

Cliente / Servidor
 Denota generalmente muchos Cliente
clientes y un solo servidor
subsistema
 Hay diferentes variantes Cliente

subsistema
Servidor

Servidor
Arquitecturas
32

Arquitectura de N niveles
 Surgió de un "cliente-servidor" de
sistemas de información de
negocio
 En estos días es un estilo
arquitectónico que se puede
aplicar a sistemas donde existen
clientes, procesamiento y
persistencia de datos
Arquitecturas
33

Arquitectura 2 niveles típico


 Muchas aplicaciones con lenguajes Cliente
de tercera generación
Aplicación/
Interfaz Gráfica

Almacén
Datos

Servidor
Arquitecturas
34

Arquitectura de 3 niveles Cliente


cliente
rico

Servidor de
Aplicaciones
Lógica de
Aplicación

Servidor
Base Datos Almacén
de Datos
Arquitecturas
35

Arquitectura de 3 niveles “lógicos”


Muestra información al
Client usuario

Formatea la información
Presentation que se mostrará.
Recepciona los eventos
de interación.
Application
Ejecuta la lógica de la
aplicación.
Data
Almacena y provee
acceso a los datos

• La distinción conceptual entre los niveles es importante


Arquitecturas
36

3 niveles con Cliente “Rico”


Framework IU
componentes de
Presentación

componentes de
• Es una implementación Aplicación
de la arquitectura
• Separación entre la presentación
Almacén
y componentes de la aplicación de Datos

es todo un esfuerzo
Arquitecturas
37

3 niveles con Cliente “Delgado”


Visualización de cliente

Visualización componentes componentes


De Servidor de Presentación de Aplicación
Framework IU

• El servidor genera “como se verá”


Almacén
la presentación de los componentes de Datos

• El tráfico de red se incrementa


Arquitecturas
38

Arquitectura con Capas


 Una arquitectura con capas es

usada para separar un nivel de


alta abstracción de uno de bajo
nivel
Arquitecturas
39

Los sistemas operativos por ejemplo:


Servicios y programas de usuario.
Ventanas, buffering, y
administración de pantallas.

Applications
Soporte de sistemas de
archivos, red, y administración
UI Services de procesos.
System Services
Kernel Administración de
interrupciones, programación de
Hardware eventos, y manejador de
dispositivos.

Ejecución de código binario, interfaces con


periféricos.
Arquitecturas
40

Las sistemas con máquinas virtuales Java por ejemplo:

Servicios y programas de usuario


Applications
Gráficos, servicios, UI,
utilitadades
JRE Libs

Ejecuta bytecode Java


JVM
Ejecuta el intérprete de Java.
Provee servicios del sistema
Platform
Middleware
41

Integración y evolución de los sistemas


Middleware
42

 Es un software de conectividad que consiste en un


conjunto de servicios que permiten la ejecución de
múltiples procesos en una o más máquinas para
interactuar unos con otros.
 Ayuda a una aplicación para interactuar o comunicarse
con otras aplicaciones, software, redes, hardware y/o
sistemas operativos.
 Simplifica el trabajo de los programadores en la
compleja tarea de generar las conexiones que son
necesarias en los sistemas distribuidos.
Middleware
43
Características de Middleware
44

 Provee formas de conectar componentes de software en


una aplicación, permitiendo que ellas intercambien
información utilizando mecanismos relativamente fáciles
de usar.
 Puede ser usado ampliamente junto a numerosos
componentes y topologías bastante conocidas
Características de Middleware
45

 Desde las perspectiva del usuario, el middleware está


completamente oculto. Los usuarios interactúan con una
aplicación y no se preocupan por cómo la información es
intercambiada
 Los usuarios nuevos de la aplicación son sólo conscientes
del papel del middleware cuando falla. Esto es por
supuesto muy parecido a la plomería y el cableado real.
Características de Middleware
46

 Los servicios de middleware proporcionan un conjunto más


funcional de APIs que el SO y los servicios de red,
permitiendo que una aplicación:
 Busque transparentemente a través de la red, proveyendo
interacción con otras aplicaciones o servicios
 Sea independiente de los servicios en la red
 Sea confiable y disponible
 Pueda escalar en capacidad sin perder funcionalidad
Uso de middleware reduce la
47
complejidad
Clasificación de Middleware
48

 De la capa de Transporte
 Objetos distribuidos
 Orientados a mensaje
 Servidores de aplicaciones
 JEE y .NET
 Message Brokers
 Orquestadores de Procesos de
Negocio
 Workflows
 BPMS
Resumen
49

 La arquitectura se enfoca en los problemas que serán


difíciles/imposibles de cambiar cuando el sistema esté
construido. Involucra complejas decisiones de diseño
 El rol de arquitecto es mucho más que un diseñador técnico

 “La vida de un arquitecto de software es un larga sucesión


de decisiones de apoyo óptimas, hechas parcialmente en la
oscuridad”
 La arquitectura reduce el riesgo por el uso de patrones de
diseño probados
 Diferentes arquitecturas han ido evolucionando

 La complejidad de los sistemas requiere de tecnologías que


simplifiquen su desarrollo
¿Preguntas?
50

 ¿Por qué es importante la Arquitectura de


Software?
Referencias
51

 Ian Gorton , Essential Software Architecture (2nd Edition)


 Chapter 1, Understanding Software Architecture
 Len Bass, Paul Clements, Rick Kazman , Software Architecture
in Practice (3rd Edition)
 Chapter 1, What is Software Architecture?
 Chapter 13, Architectural Tactics and Patterns
 Sommerville, Ingeniería de Software (9na. Edición)
 Capítulo 6, Diseño arquitectónico
 Links:
 http://www.sei.cmu.edu/architecture/research/previousresearch/duties.cfm
 http://www.epidataconsulting.com/tikiwiki/tiki-
read_article.php?articleId=7&comments_parentId=171&comments_per_pag
e=1&thread_style=commentStyle_plain

Das könnte Ihnen auch gefallen