24/08/2014

Arquitectura de software Unidad 2. Diseño de arquitecturas

Introducción a los estilos y patrones arquitectónicos

Estilos arquitectónicos
 2.2.1 Estilos influenciados por los lenguajes tradicionales (programa principal y subrutinas, orientado
a objetos)
 2.2.2 Estilos en capas (Máquinas virtuales, cliente/servidor)
 2.2.3 Estilos por flujo de datos (batch-secuencial, tubos y filtros)
 2.2.4 Estilos de estado compartido (blackboard, basados en reglas/sistema experto)
 2.2.5 Estilos de interpretación (intérprete básico, código móvil)
Dr. Giner Alor Hernández  2.2.6 Estilos de invocación implícita
 Aplicaciones basadas en componentes (definición de conceptos fundamentales).
 Líneas de productos software (software product lines)

Patrones arquitectónicos
UNIDAD 2
 2.2.1 SLD – State/Logic/Display
 2.2.2 MVC- Model/View/Controller
 2.2.3 SCC – Sensor/Compute/Control

Estilo arquitectónico Estilos arquitectónicos [Shaw y Garlan]

Sistemas de flujo de Procesamiento por lotes

Un estilo arquitectónico expresa los datos Filtros y pipes
componentes y las relaciones entre ellos, con
Sistemas de llamada Programa principal y subrutinas
las limitaciones de su aplicación, así como la
retorno Orientado a objetos
composición y el diseño de normas
Organizado en capas
asociadas a su construcción.
Sistemas de componentes Comunicación entre procesos
independientes - Cliente/ servidor
Basados en eventos

Arquitecturas de Software 3 Arquitecturas de Software 4

1
 24/08/2014

Estilos arquitectónicos Estilos arquitectónicos influenciados por los

lenguajes tradicionales
Sistemas centrados en Repositorios
Estilo arquitectónico de llamada y respuesta,
los datos Pizarras

Máquinas virtuales Intérpretes

Basados en reglas

Sistemas heterogéneos Localmente heterogéneos

Jerárquicamente heterogéneos
Simultáneamente heterogéneos

Arquitecturas de Software 5 Arquitecturas de Software 6

Estilos arquitectónicos influenciados por los Estilos en capas

lenguajes tradicionales Capas
• Los componentes son las capas o niveles

Orientado a objetos (conceptualmente) que pueden estar
implementadas internamente por objetos o
procedimientos.
• Cada nivel tiene asociado una funcionalidad:
– Niveles bajos: Funciones simples, ligadas
al hardware o al entorno.
– Niveles altos: Funciones más abstractas.
• Mecanismos de interacción entre
componentes:
– Llamadas a procedimientos.
– Llamadas a métodos.
• Restricciones
-Solo llamadas de niveles superiores a
inferiores
-(variante) sólo llamadas entre niveles
adyacentes

Arquitecturas de Software 7 Arquitecturas de Software 8

2
 24/08/2014

Máquinas virtuales Máquina virtual

Intérprete

Intérprete

Arquitecturas de Software 9 Arquitecturas de Software 10

Sistemas de componentes independientes Cliente-Servidor en Web

Cliente-Servidor

El estilo arquitectónico cliente-servidor es
preferentemente un modelo de aplicación distribuida en
el que las tareas se reparten entre los proveedores de
recursos o servicios, llamados servidores, y los
demandantes, llamados clientes. Un cliente realiza
peticiones a otro programa, el servidor, quien le da
respuesta.

Esta idea también se puede aplicar a programas que se
ejecutan sobre una sola computadora, aunque es más
ventajosa en un sistema operativo multiusuario
distribuido a través de una red de computadoras.

Arquitecturas de Software 11 Arquitecturas de Software 12

3
 24/08/2014

Estilos de flujo de datos Sistemas centrados en los datos

Tubos y filtros (Pipes & Filters)
Pizarra

Arquitecturas de Software 13 Arquitecturas de Software 14

Sistemas centrados en los datos Tarea para entregar.

En esta arquitectura hay dos componentes principales: una

estructura de datos que representa el estado actual y una colección

Unid2_Act. 1.- Investigar y discutir las
de componentes independientes que operan sobre los datos de características de los diferentes estilos de
forma directa.
arquitectura software

En base a esta distinción se han definidos dos subcategorías
principales del estilo:
 Repositorio. Los tipos de operaciones definen los procesos a

ejecutar, el repositorio es una base de datos tradicional.
Entregar en clase, dos días después de la
 Pizarra. Si el estado actual de la estructura de datos dispara los fecha actual
procesos a ejecutar, el repositorio es lo que se llama una pizarra
pura o un tablero de control.

Arquitecturas de Software 15 Arquitecturas de Software 16

4
 24/08/2014

Estilo arquitectónico de componentes Definición de componente

independientes
“Un componente es una unidad de composición de

Este tipo de estilo de arquitectura se enfoca en la
descomposición del diseño en componentes funcionales aplicaciones software, que posee un conjunto de interfaces y
o lógicos que expongan interfaces de comunicación bien un conjunto de requisitos, y que ha de poder ser desarrollado,
definidas.
adquirido, incorporado al sistema y compuesto con otros
componentes de forma independiente, en tiempo y espacio”
[Szyperski, 1998].

Arquitecturas de Software 17 Arquitecturas de Software 18

Estructura de Componente Desarrollo basado en componentes

(Modelo y plataforma)

Interfaz
La estructura de componentes de .NET,

Métodos diseñado por Microsoft para plataforma Windows.

Funcionalidad privada
Enterprise JavaBeans y el modelo de
Interfaz componentes de Java EE.

CORBA 3 y el modelo de componentes de
Cliente CORBA (CCM)(Common Object Request Broker Architecture)
Objetos arquitectura común de distribución de objetos.
Firma
del
Método Público func. privada

Arquitecturas de Software 19 Arquitecturas de Software 20

5

Caso de estudio: CORBA
¿Qué es CORBA? (como Modelo)

Es un conjunto de especificaciones
gestionadas por el OMG y cuya finalidad es
facilitar la interoperabilidad entre
componentes software implementados en
cualquier lenguaje para que se ejecuten en
cualquier sistema y plataforma hardware.
Arquitecturas de Software
Arquitectura CORBA
ORB
IIOP
Internet
Arquitecturas de Software
24/08/2014
Ventajas de CORBA

Existen servicios CORBA disponibles para una treintena
de plataformas, desde DOS o Linux hasta mainframes
pasando por todas las versiones Windows.

Es una tecnología que lleva utilizándose y depurándose
más de una década.

Es un estándar controlado por la OMG (Object
Management Group) asociación conformada por más de
ochocientas empresas.
21 Arquitecturas de Software 22
El ORB

El ORB (Object Request Broker), en el lado del cliente actúa como
intermediario entre el stub ,la red y sistema operativo local.

Los ORB´s de ambos extremos son capaces de resolver las
diferencias existentes en lo referente a lenguajes de programación,
así como las relativas a las plataformas (red y sistema operativo),
para de esta forma ayudar a la comunicación entre los dos
extremos.
ORB
IIOP
23 Arquitecturas de Software 24
6
 24/08/2014

Compilador IDL El compilador IDL

IDL, lenguaje de definición de interfaces de
El compilador IDL sí es dependiente del

programación.
lenguaje, es decir, existen compiladores que
traducen IDL a Java, C++, Cobol, etc.

Un compilador IDL traduce la descripción del archivo en
IDL a un determinado lenguaje, generando los módulos,

Java (a partir del JSDK 1.3) cuenta con un
clases o interfaces que proceden y a partir de las cuales
se comienza a trabajar. traductor (idlj) que pasa de IDL a Java
idlj –fall miArchivo.idl

** Dependiendo del lenguaje con el cual se desea desarrollar componentes

Corba se debe tener un compilador IDL

Arquitecturas de Software 25 Arquitecturas de Software 26

Ejemplo del programa Agenda

Tarea
El siguiente código corresponde al archivo IDL que contiene la interfaz
del componente AgendaServer.

Unid2_Act2. Elaborar la implementación de
la arquitectura de software de un caso //agenda.idl
module AgendaEjemplo{
práctico. interface Agenda{
//no hay tipos especiales
string buscarTelefono(in string nombre);
};
};

Utilice el código en diapositivas y modifique
el programa cliente para que presente una 2. Crear stubs y skeletons
 El segundo paso es compilar el IDL para crear el código stub (para el cliente) y el skeleton
interfaz amigable. (para el servidor)
idlj –fall agenda.idl

Fecha de entrega: viernes 28 de marzo

Arquitecturas de Software 27 Arquitecturas de Software 28

7
 24/08/2014

Salida del compilador idlj 3. Implementar el servidor y el cliente

(Código del lado servidor para la aplicación remota)

Al ejecutar el traductor de Java (idlj) se generan los archivos import AgendaEjemplo.*;
import org.omg.CosNaming.*;

Para el servidor import org.omg.CosNaming.NamingContextPackage.*;
 x import org.omg.CORBA.*;

Interfaz en java (definición de métodos que alguien tendrá que implementar) import org.omg.PortableServer.*;
import org.omg.PortableServer.POA;
 xOperations import java.util.Properties;

Interfaz en java para las operaciones del componente
class AgendaImpl extends AgendaPOA {
 xPOA private ORB orb;

Clase abstracta de la que hereda la clase que implementa las operaciones de
la interfaz. public void setORB(ORB orb_val) {
orb = orb_val;

Para el cliente }
 _xStub // Implementación de método de la interfaz

Clase en java para implementar el uso del componente del lado del cliente public String buscarTelefono(String nombre) {
String retorno = new String();
 xHolder

Clase en java, sirve para pasar parámetros del tipo del componente; la usa el if (nombre.equals(“Maria")){
cliente retorno = “11-11-11-11";
 xHelper } else{
retorno = "Desconocido";

Clase en java, sirve para pasar los parámetros de los métodos definidos en el }
componente; la usa el cliente para enviar sus parámetros y para recibir los return retorno;
valores de retorno } //Lo que está en negritas depende de cada componente
}
Donde x es el nombre indicado en la sección interface del archivo idl
Arquitecturas de Software 29 Arquitecturas de Software 30

Escucha (servidor) para agenda Código cliente para agenda

import AgendaEjemplo.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
import org.omg.PortableServer.*; import AgendaEjemplo.*;
import org.omg.PortableServer.POA; import org.omg.CosNaming.*;
import java.util.Properties; import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
public class AgendaServer {
public static void main(String args[]) {
try{
public class AgendaCliente
ORB orb = ORB.init(args, null); // org.omg.CORBA.ORB.init iniciar el ORB {
static Agenda agendaImpl;
POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA")); //Obtener una referencia al POA raíz
rootpoa.the_POAManager().activate(); // activar el gestor del POA raíz public static void main(String args[])
{
AgendaImpl agendaImpl = new AgendaImpl(); // instanciar al objeto servant try{
agendaImpl.setORB(orb); ORB orb = ORB.init(args, null); // org.omg.CORBA.ORB.init método para conectar al cliente con el ORB
org.omg.CORBA.Object ref = rootpoa.servant_to_reference(agendaImpl); // el objeto servant se asocia a una referencia a objeto, se registra en el pOA
Agenda href = AgendaHelper.narrow(ref);
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");

org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); // se genera la dirección del objeto NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
agendaImpl = AgendaHelper.narrow(ncRef.resolve_str("Agenda"));
NameComponent path[] = ncRef.to_name( "Agenda" );
ncRef.rebind(path, href); System.out.println(agendaImpl.buscarTelefono(“Maria"));
} catch (Exception e) {
System.out.println("AgendaServer listo y en escucha ..."); System.out.println("ERROR : " + e) ;
orb.run(); // con el metodo run() el servidor se queda en espera de peticiones
}
e.printStackTrace(System.out);
catch (Exception e) { }
System.err.println("ERROR: " + e); }
e.printStackTrace(System.out); }
}
System.out.println("AgendaServer Exiting ...");
}
}

Arquitecturas de Software 31 Arquitecturas de Software 32

8
 24/08/2014

Ejecución Tarea

idlj -fall Agenda.idl

Traduce de IDL a java

javac *.java AgendaEjemplo/*.java
Unid2_act3.- Investigar y discutir las

Compila todos los archivos características del estilo arquitectónico

start orbd -ORBInitialPort 1050 basado en componentes

Levanta el “canal de comunicaciones” ORB (Servidor de nombres)

start java AgendaServer -ORBInitialPort 1050 -
ORBInitialHost localhost
Entrega en clase, tres días después de la

Levanta el “servidor” (escucha) en un puerto y host determinado

(ejecutar en otra consola) fecha actual

java AgendaCliente -ORBInitialPort 1050 -
ORBInitialHost localhost

Ejecuta el cliente para buscar en un puerto y host determinado

(ejecutar en otra consola)

Arquitecturas de Software 33 Arquitecturas de Software 34

Líneas de productos de software Líneas de productos de software

La idea básica es el ensamble de partes de
"Se definen las líneas del producto de software como un
conjunto de sistemas software, que comparten un
software previamente elaborados
conjunto común de características, las cuales satisfacen
las necesidades específicas de un dominio o segmento
particular de mercado, y que se desarrollan a partir de
un sistema común de activos base de una manera
preestablecida”[Clemenst 2001].

Arquitecturas de Software 35 Arquitecturas de Software 36

9
 24/08/2014

Líneas de productos de software Líneas de productos de software

El paradigma de desarrollo de software LPS requiere
Evolución de la reutilización de software
que las empresas que lo adopten consideren:
 Aspectos conceptuales. Conceptos en los que las LPS se
fundamentan

 Aspectos tecnológicos. Qué tecnologías son fundamentales para

desarrollar y mantener activos y productos de software

 Aspectos metodológicos. Cómo desarrollar y mantener los

activos y productos de software

 Aspectos organizativos. Cómo debe la empresa organizarse

internamente

 Aspectos gerenciales. Cómo gestionar los proyectos de

desarrollo de activos y productos.

Arquitecturas de Software 37 Arquitecturas de Software 38

Patrones Arquitectónicos MVC Model-View-Controler

Uno de los patrones de arquitectura que más se utilizan para el

El patrón arquitectónico especifica un 

desarrollo de aplicaciones Web es el Modelo-Vista-Controlador

conjunto predefinido de subsistemas con (MVC).

sus responsabilidades y una serie de  La aportación más importante de este patrón es la separación de
los componentes relacionados con los datos de la aplicación de
recomendaciones para organizar los los componentes de la interfaz de usuario.
distintos componentes.  La separación de las capas permite tener, a nivel de desarrollo,
un código más claro, flexible y reusable.

 Formalmente MVC descompone la aplicación en tres capas,

permitiendo tener una separación entre la lógica de negocio de la
aplicación, el control y la presentación

Arquitecturas de Software 39 Arquitecturas de Software 40

10
 24/08/2014

MVC Model-View-Controler MVC Model-View-Controler

Al separar la presentación, los datos y la lógica de
negocio se tiene una idea más clara de lo que necesita
la aplicación, se desarrollan los componentes y se
establecen las relaciones necesarias.

Se tiene menor acoplamiento, se modifica sólo las
partes involucradas (se modifica sólo lo que se
necesita), siendo transparente para las demás partes.

Al utilizar MVC tenemos la capacidad de representar la
información de varias formas. Es decir diferentes vistas.

Arquitecturas de Software 41 Arquitecturas de Software 42

SCC Sensor-Compute-Control

Para aplicaciones que interactúan con un ambiente

Arquitecturas de Software 43 Arquitecturas de Software 44

11
 24/08/2014

Patrón multicapa
(variante de SLD)

El término capa se utiliza para

referenciar a las distintas
partes en las que una
aplicación se divide desde el
punto de vista lógico. Mientras
que nivel corresponde a la
forma física en que una
aplicación se organiza.

Arquitecturas de Software 45 Arquitecturas de Software 46

Tarea

Unid2_act4.- Investigar y discutir las características de

los patrones arquitectónicos.
 1.- MVC Model/View/Controler
 2.- SLD State/Logic/Display
 3.- SCC Sensor/Compute/Control

 Entregar en clase, dos días después de la fecha actual

Arquitecturas de Software 47

12