Diseño del Sistema I: Descomposición del Sistema

Diseño del Sistema I:
Descomposición del
Sistema
Ejercicio de Diagrama de Secuencia
• Diagrama 1
Crear Usuario
Cargar Perfil y asociarlo al usuario
Cargar deporte y asociarlo a Perfil
Crear Plan y asociarlo al usuario
Cargar todos los ejercicios de la bd en una colección l1.
Para cada uno de los ejercicios de l1 se les debe
asociar la colección de deportes desde la bd..
• Seleccionar 7 ejercicios de l1 aleatoriamente y
asignarlos a la lista de ejercicios de los planes. El
ejercicio seleccionado debe cumplir que: a) tiene el
mismo deporte del perfil y la misma meta del perfil
• Guardar Plan y sus ejercicios en la bd.
•
•
•
•
•
Subsistemas y Servicios
• Subsistema
• Colección de clases, asociaciones, operaciones, eventos
que están cercanamente interrelacionados con otros
• Servicio
• Operaciones externamente visibles provistas por un
subsistema (también llamado interfaz del subsistema)
User Interface
Maneja banners de
publicidad &
patrocinantes
Maneja torneos,
promociones,
aplicaciones
Tournament
Advertisement
Component
Management
Ejemplo: Servicios
provistos por los
Subsistemas ARENA
Administra cuentas
de usuario
User Management
Añade juegos,
LosServicios
Servicios
estilos, y expert
Los
sondescritos
descritos
rating formulas
son
porinterfaces
interfacesdel
delsubsistema
subsistema
por
User Directory
Session
Management
Mantiene el estado
durante los juegos
Tournament
Statistics
Almacena
resultados de
torneos
Almacena perfiles
de usuario (info
contacto &
subscripciones)
Interfaz del Subsistema
• interfaz del Subsistema:
• Especifica la interacción y flujo de información desde y hacia
los limites del subsistema, pero no dentro del subsistema
• Interfaces del Subsistema son definidas durante el diseño
objeto
• Application programmer’s interface (API)
• El API es la especificación de la interfaz del subsistema en un
lenguaje de programación especifico
• APIs son definidas durante la implementación
• Los términos interfaz de subsistema y API se confunden
frecuentemente entre si
• El termino API no debe ser usado durante el diseño del sistema
y diseño objeto, sino solamente durante la implementación.
Es un Buen Diseño?
User Interface
Component
Management
Advertisement
Tournament
Tournament
Statistics
No, tiene demasiado
acoplamiento
(diseño “espagueti”)
Session
Management
User Management
Respuesta de Dijkstra al “diseño espagueti”
• Idea revolucionaria de Dijkstra in 1968
• Un sistema debe ser diseñado y construido como una
jerarquía de capas: Cada capa usa solamente los
servicios ofrecidos por las capas mas bajas
• El sistema T.H.E.
• T.H.E. = Technische Hochschule Eindhoven
• Un SO para una sola operación de usuario
• Soportar modo batch
• Multitarea con un número fijo de procesos que comparten
el CPU
Edser W. Dijkstra, 1930-2002
Formal verification: Proofs for programs
Dijkstra Algorithm, Banker’s Algorithm,
Gotos considered harmful, T.H.E.,
1972 Turing Award
Las capas del sistema T.H.E.
“Un SO es una jerarquía de capas, cada capa usa
servicios ofrecidos por las capas mas bajas”
capa 4: User Programs
capa 3: I/O Device Manager
capa 2: Communication with
Console
capa 1: Pager
capa 0: Scheduler
Retrospectivamente,
T.H.E fue el primer
sistema que uso un
Estilo arquitectural!
Ejemplos de Estilos Arquitecturales
• Estilo arquitectural en Capas
• Arquitectura Orientada a Servicios (SOA)
• Cliente/Servidor
• Peer-To-Peer
Capas y Particiones
• Una capa es un subsistema que provee un servicio a otro
subsistema con las siguientes restricciones:
• Una capa solamente depende de los servicios de las capas
mas bajas
• Una capa no tiene conocimiento de las capas mas altas.
• Una capa puede ser dividida horizontalmente en distintos
subsistemas independientes llamados particiones
• Particiones proveen servicios a otras particiones en la misma
capa
• Particiones son llamadas también subsistemas “debilmente
acoplados” .
El estilo arquitectural en Capas
Client
uses
capa N
calls
capa N-1
calls
capa N-2
. calls
.
.
capa 1
calls
capa 0
Relación
Jerárquica
Relaciones Jerárquicas entre Subsistemas
• Hay dos tipos principales de relaciones jerárquicas
• La capa A “depende de” la capa B (dependencia en tiempo de
compilación)
• Ejemplo: Construir dependencias (make, ant, maven)
• La capa A “llama” a la capa B (dependencia en tiempo de ejecución)
• Ejemplo: Un web browser llama a un web server
• Convención UML:
• Relaciones en tiempo de ejecución son asociaciones con líneas
punteadas
• Relaciones en tiempo de compilación son asociaciones con líneas
sólidas.
Ejemplo de un Sistema con mas de una
relación jerárquica
Relaciones de capa
“depende de”
A:Subsystem
capa 1
Relaciones de capa
“llama”
B:Subsystem
E:Subsystem
C:Subsystem
F:Subsystem
Relaciones de capa
“llama”
D:Subsystem
capa 2
G:Subsystem
capa 3
Arquitectura Cerrada (Capas Opacas)
• Cada capa puede llamar
solamente operaciones de
la capa de abajo (llamado
“direccionamiento directo”
by Buschmann et al)
Metas de diseño:
Mantenibilidad,
Flexibilidad.
C1ass1
attr
C1ass2
attr
C1ass3
attr
op
op
op
Class A
attr
op
C1assE
attr
C1assF
attr
op
op
C1assC
attr
C1assD
attr
op
op
C1ass B
attr
op
L4
L3
L2
L1
Capas Opacas en ARENA
capa 3
capa 2
capa 1
Arquitectura Abierta (Capas Transparentes)
• Cada capa puede
llamar operaciones de
cualquier capa de
abajo
(“direccionamiento
indirecto”)
Meta de Diseño:
eficiencia en tiempo de
ejecución.
C1ass1
attr
C1ass2
attr
C1ass3
attr
op
op
op
Class A
attr
op
C1assE
attr
C1assF
attr
op
op
C1assC
attr
C1assD
attr
op
op
C1ass B
attr
op
L4
L3
L2
L1
SOA es un estilo arquitectural en capas
Service Oriented Architecture (SOA)
• Idea Básica: Un proveedor de servicio (“negocio”) ofrece servicios
de negocio (“procesos de negocios”) a un consumidor de servicios
(aplicación, “cliente”)
• Los servicios de negocios son descubiertos dinámicamente,
usualmente ofrecidos en aplicaciones basadas en el Web
• Los servicios de negocios son creados por composición
(choreographing) de servicios de capas mas bajas (servicios básicos)
• Los servicios básicos están basados usualmente en legacy systems
• Adaptadores son usados para proveer el “glue” entre servicios básicos
y los legacy systems.
(Web-)Application
Business Services (Composite Services)
Basic Services
Adapters to Legacy Systems
Legacy Systems
Vista de IBM de una Arquitectura Orientada a
Servicios
Source http://www.ibm.com/developerworks/webservices/library/ws-soa-design1/
Interfaz de Usr
(Portal Web)
Servicios de
Negocios
Servicios
Basicos
Adaptadores
Legacy Systems
Propiedades de Sistemas en Capas
• Sistemas en capas son jerárquicos.
• Jerarquía reduce la complejidad
• Arquitecturas cerradas son más portables
• Proveen muy bajo acoplamiento
• Arquitecturas Abiertas son más eficientes
• Modelo de Referncia
OSI de ISO
• ISO = International
Standard Organization
• OSI = Open System
Interconnection
• Modelo de Referencia
que define 7 capas y
protocolos de
comunicación entre las
capas
Nivel de abstracción
Otro Ejemplo de Estilo Arquitectural en
Capas
Application
Presentation
Session
Transport
Network
DataLink
Physical
Ejemplos de Estilos Arquitecturales
Estilo arquitectural en Capas
Arquitectura Orientada a Servicios (SOA)
• Cliente/Servidor
• Peer-To-Peer
Arquitectura Cliente/Servidor
• Usadas frecuentemente en el diseño de sistemas
de base de datos.
• Front-end: Aplicación del usuario (cliente)
• Back end: Acceso y manipulación a base de datos
(servidor)
• Funciones ejecutadas por el cliente:
• Entrada del usuario (interfaz de usuario personalizada)
• Front-end procesando los datos de entrada
• Funciones ejecutadas por el servidor de base de
datos :
• Manejo de datos centralizado
• Integridad y consistencia de los Datos
• Seguridad de base de datos
Estilo Arquitectural Cliente/Servidor
• Caso especial del estilo Arquitectural en capas
• Uno o muchos servidores proveen servicios a las
instancias de subsistemas, llamadas clientes
• Cada cliente llama al servidor, quien ejecuta algún
servicio y devuelve el resultado
Los clientes conocen la interfaz del servidor
El servidor no necesita conocer la interfaz del
cliente
• La respuesta en general es inmediata
• Usuarios finales interactúan solamente con el
cliente.
Server
Client
*
requester
*
provider
+service1()
+service2()
+serviceN()
Estilo Arquitectural Peer-to-Peer
Generalización del Estilo Arquitectural Cliente/Servidor
“Los clientes pueden ser servidores y los servidores pueden ser clientes”
Introducción a una nueva abstracción: Peer
“Clientes y servidores pueden ser ambos peers”
Cómo se puede modelar esta afirmación? Con herencia?
Propuesta 1: “Un peer puede ser un cliente o un servidor”
Propuesta 2: “Un peer puede ser tanto un cliente como un
servidor”.
Relación Cliente/Servidor & Peer-to-Peer
Modelo 1: “Un peer puede ser un cliente o un servidor”
Modelo 2: “Un peer puede ser tanto un cliente como un
servidor”
?
Modelo 1
Client
Server
Modelo 2
✔