AO DE LA INVERSION PARA EL DESARROLLO RURAL Y LA SEGURIDAD ALIMENTICIA

Universidad Nacional San Luis Gonzaga de Ica

FACULTAD DE INGENIERIA DE SISTEMAS
zz

Anlisis y Diseo
zz

CURSO

: Control de Calidad de Software

INTEGRANTES

: Camana Infanzn Zenn Giovanni Huamani Palacios Kevin Matta Canales Jorge Sotelo Espino Carlos Villafuerte Sotelo Jean

Ica -2013

DEDICATORIA
ESTE TRABAJO ES DEDICADO A TODOS MIS COMPAEROS, EL CUAL PUEDE AYUDAR A CONOCER MAS ACERCA DE ANALISIS Y DISEO DE SOFTWARE.

AGRADECIMIIENTOS
A MI EQUIPO DE TRABAJO, POR EL ESFUERZO Y EL APORTE DE INFORMACION.

Introduccin..........................................................................................................................8
Terminologas .............................................................................................................................. 8

1.
1.1

ANALISIS DE SOFTWARE .........................................................................................9

Modelamiento de requerimientos ............................................................................... 10
1.1.1 Anlisis de requerimientos ................................................................................................................................... 11 1.1.2 Especificacin de requerimientos ...................................................................................................................... 11 1.1.3 Atributos de calidad de la especificacin de los requerimientos del software ............................... 12

1.2 UML como un estndar ..................................................................................................... 12

1.2.1 Diagramas UML ........................................................................................................................................................ 12 1.2.1.1 Diagrama de casos de uso ........................................................................................................................... 13 1.2.1.2 Diagrama de clases ......................................................................................................................................... 14 1.2.1.3 Diagrama de interaccin ............................................................................................................................... 15 1.2.1.4 Diagrama de Estados de maquina ............................................................................................................ 16 1.2.1.5 Diagrama de actividad ................................................................................................................................... 17 1.2.1.6 Diagrama de Comunicacin concurrente .............................................................................................. 18 1.2.1.6.1 Comunicacin de mensajes en el diagrama de comunicacin concurrente ................... 19

2.

DISEO DE SOFTWARE.......................................................................................... 20
2.1.1 Arquitectura orientado a objetos ...................................................................................................................... 21 2.1.1.1 Conceptos, arquitecturas y patrones ................................................................................................. 21 2.1.1.2 Diseo de clases de ocultamiento de informacin .................................................................... 21 2.1.1.3 Diseo de interfaz de clase y operaciones ...................................................................................... 22 2.1.1.4 Clases de abstraccin de datos ............................................................................................................. 22 2.1.1.5 Clases de interaccin graficas con usuarios ................................................................................... 22 2.1.1.6 Clases de lgica de negocio .................................................................................................................... 23 2.1.1.7 Polimorfismo y enlace dinmico ......................................................................................................... 23 2.1.2 Arquitectura Cliente Servidor .............................................................................................................................. 23 2.1.2.1 Conceptos, arquitecturas y patrones ................................................................................................. 24 2.1.2.2 Patrn arquitectnico multicliente/servicio .................................................................................. 24 2.1.2.3 Middleware en sistemas cliente/servicio ......................................................................................... 25 2.1.2.4 Desde modelos estticos a diseo de base de datos relacional .......................................... 25 2.1.3 Arquitectura Orientado a Servicios (SOA) ...................................................................................................... 25 2.1.3.1 Conceptos, arquitecturas y patrones ................................................................................................. 26 Patrones Brker .......................................................................................................................................................... 26 Patrones de transacciones ..................................................................................................................................... 26 2.1.3.2 Principios para disear servicios .......................................................................................................... 26 2.1.3.3 Tecnologas de apoyo para SOA ............................................................................................................... 27 2.1.3.3.1 Protocolos de servicio web .................................................................................................................. 27 4

2.1 Diseo arquitectnico. ...................................................................................................... 20

2.1.3.3.2 Servicios web ............................................................................................................................................. 28 2.1.3.3.3 Servicios de registro ............................................................................................................................... 29 2.1.3.4 Software de arquitectura de patrones transaccionales .................................................................... 29 2.1.3.5 Patrn de negociacin ................................................................................................................................... 30 2.1.3.6 Reutilizacin de servicios .............................................................................................................................. 30 2.1.4 Arquitectura basado en componentes .......................................................................................................... 31 .1.4.1 Conceptos, arquitecturas y patrones ................................................................................................... 31 2.1.4.2 Diseo de una arquitectura basada en componentes .............................................................. 31 2.1.4.3 Subsistemas compuestos y componentes ...................................................................................... 32 2.1.4.4 Modelado de componente con UML ................................................................................................. 33 2.1.4.5 Criterios de estructuramiento de componentes .......................................................................... 33 2.1.4.5 Despliegue de la aplicacin .................................................................................................................... 34 2.1.5 Arquitectura concurrente y en tiempo real ................................................................................................... 34 2.1.5.1 Concepto, arquitectura y patrones ..................................................................................................... 34 2.1.5.2 Caractersticas de los Sistemas en tiempo real ............................................................................. 35 2.1.5.3 Patrones de control de software en las arquitecturas de tiempo real ............................. 35 2.1.5.3.1 Diseo arquitectnico de control centralizado ................................................................... 35 2.1.5.3.2 Diseo arquitectnico de control distribuido ...................................................................... 36 2.1.5.3.3 Diseo arquitectnico de control jerrquico ........................................................................ 36 2.1.5.4 Criterios de estructuracin de tareas de E/S ................................................................................. 36 2.1.5.5 Criterios internos de estructuracin de tareas ............................................................................. 36 2.1.5.5.1 Tareas Peridicas ................................................................................................................................ 37 2.1.5.5.2 Demanda de impulse de tareas .................................................................................................... 37 2.1.5.5.3 Tareas de control ................................................................................................................................. 37 2.1.5.5.4 Tarea de interaccin con el usuario ........................................................................................... 38 2.1.5.6 Tarea de comunicacin y sincronizacin ......................................................................................... 38 2.1.6 Arquitectura de Software para lnea de productos ................................................................................... 39 2.1.6.1 Ingeniera evolutiva del software de lnea de producto ......................................................... 40 2.1.6.2 Requisitos para el modelado de software de lnea de productos ...................................... 40 2.1.6.2.1 Modelado de casos de uso ............................................................................................................. 40 2.1.6.2.2 Modelado de caractersticas .......................................................................................................... 41 2.1.6.3 Modelado de anlisis de SPL.................................................................................................................. 41 2.1.6.3.1 Modelado esttico .............................................................................................................................. 41 2.1.6.3.2 Modelado dinmico ........................................................................................................................... 42 2.1.6.4 Modelado de arquitectura de software SPL .................................................................................. 42 2.1.6.4.1 Modelado de arquitectura basado en componentes ........................................................ 42 2.1.6.4.1 Patrones de arquitectura de software ...................................................................................... 43

2.2 Atributos de calidad de software .................................................................................... 43

2.2.1 Mantenibilidad .......................................................................................................................................................... 44 2.2.2 Modificabilidad ......................................................................................................................................................... 44 2.2.3 Capacidad de prueba ............................................................................................................................................. 44 2.2.4 Trazabilidad ................................................................................................................................................................ 45 2.2.5 Escalabilidad .............................................................................................................................................................. 45 5

2.2.6 Rendimiento............................................................................................................................................................... 45 2.2.7 Seguridad .................................................................................................................................................................... 46 2.2.8 Disponibilidad ........................................................................................................................................................... 46

2.3 Diseo de patrones ............................................................................................................ 47

2.3.1 Catlogo de arquitectura de software ............................................................................................................. 48 2.3.1.1 Patrones arquitectnicos ......................................................................................................................... 48 2.3.1.1.1 Broker Pattern ........................................................................................................................................... 48 2.3.1.1.2 Centralized Control Pattern ................................................................................................................. 49 2.3.1.1.3 Distributed Control Pattern ................................................................................................................. 50 2.3.1.1.4 Hierarchical Control Pattern ................................................................................................................ 51 2.3.1.1.5 Layers of Abstraction Pattern .............................................................................................................. 52 2.3.1.1.6 Mutiple Client/Multiple Service Pattern ......................................................................................... 53 2.3.1.1.7 Multiple Client/Single Service Pattern ............................................................................................. 54 2.3.1.1.8 Multi-Tier Client/Service Pattern ....................................................................................................... 55 2.3.1.2 Patrones de comunicacin ........................................................................................................................... 56 2.3.1.2.1 Asynchronous Message Communication Pattern....................................................................... 56 2.3.1.2.2 Asynchronous Message Communication with Callback Pattern ......................................... 57 2.3.1.2.3 Bidirectional Asynchronous Message Communication Pattern ............................................ 58 2.3.1.2.4 Broadcast Pattern .................................................................................................................................... 59 2.3.1.2.5 Broker Forwarding Pattern ................................................................................................................... 60 2.3.1.2.6 Broker Handle Pattern ........................................................................................................................... 61 2.3.1.2.7 Call/Return Pattern ............................................................................................................................ 62 2.3.1.2.8 Negotiation Pattern ................................................................................................................................ 63 2.3.1.2.9 Service Discovery Pattern ............................................................................................................... 64 2.3.1.2.10 Service Registration Pattern .............................................................................................................. 65 1.3.1.2.11 Subscription/Notification Pattern ............................................................................................... 66 2.3.1.3 Patrones de transaccin ................................................................................................................................ 67 2.3.1.3.1 Compound Transaction Pattern ....................................................................................................... 67 2.3.1.3.2 Long-Living Transaction Pattern ........................................................................................................ 68 2.3.1.3.3 Two-Phase Commit Protocol Pattern .............................................................................................. 69

Conclusin ......................................................................................................................... 70

Bibliografa.......................................................................................................................... 71

Introduccin.
El anlisis y diseo de software se debe dar en un marco de calidad y por calidad se entiende adecuar el software a los requisitos exigidos y estndares a lo largo de la construccin y gestin del software.

Terminologas

Software: Es el equipamiento lgico o soporte lgico de un sistema informtico. Estructura: Es la disposicin y orden de las partes dentro de un todo. Tambin puede entenderse como un sistema de conceptos coherentes enlazados, cuyo objetivo es precisar la esencia del objeto de estudio. Anlisis: Distincin y separacin de las partes de algo para conocer su composicin, y as poder examinar sus caractersticas y funciones. Sistema informtico: Un sistema informtico como todo sistema, es el conjunto de partes interrelacionadas, hardware, software y de humano que permite almacenar y procesar informacin.

1. ANALISIS DE SOFTWARE
El anlisis de software se divide en dos puntos principales: Anlisis de requerimientos de Negocio: Este tipo de anlisis se da desde el lado de la organizacin que trata de obtener una ventaja competitiva controlando los flujos de recursos como: el hardware, el software, especialistas de la informacin y usuarios de la informacin. El enfoque de McLeod que ve el uso de la tecnologas de informacin como una forma de obtener una ventaja competitiva para la organizacin, parte de identificar el entorno de la organizacin y posteriormente identifica las reas bsicas de las organizacin y como los sistemas de informacin interactan con estas reas. El marco de trabajo Zachman define la creacin de software que responda a las necesidades que surgen de las organizaciones. Anlisis de Requerimientos del Software: Este tipo de anlisis son resueltos por los ingenieros de software en un aspecto ms tcnico.se debe establecer lo que el sistema debe hacer de acuerdo a los requerimientos que describen los servicios y restricciones. Pueden desarrollarse dos tipos de anlisis de software: Anlisis esttico.- es un tipo de anlisis de software que se realiza sin ejecutar el programa Anlisis dinmico.- es un tipo de anlisis de software que supone la ejecucin del programa y observar su comportamiento.

Los conceptos orientados a objetos son cruciales para el anlisis de software porque ellos direccionan cuestiones fundamentales de modificabilidad, adaptacin y evolucin del software. Con la proliferacin de notaciones y mtodos para el anlisis y diseo orientado a objetos de aplicaciones de software, el UML (Unified Modeling Language), fue desarrollado para proveer un lenguaje grfico y notaciones estandarizadas para describir los modelos orientados a objetos. Los modernos mtodos de anlisis orientados a objetos son basados en modelos y usan una combinacin de modelado de casos de uso, modelado esttico, modelado de estado de mquina y de interaccin de objetos. Casi todos los modernos mtodos orientados a objetos usan la notacin UML para describir los requerimientos de software, anlisis y diseo de modelos. Modelado de casos de uso: los requerimientos funcionales son definidos en trminos de casos de uso y actores. Modelado esttico: Provee una vista estructural del sistema. Clases son definidos en trminos de sus atributos, as como sus relaciones con otras clases. Modelado Dinmico: provee una vista conductual del sistema.

1.1 Modelamiento de requerimientos

Principalmente existen dos razones por el cual se desarrolla un nuevo sistema de software: para reemplazar un sistema manual o reemplazar el sistema existente. En el primer caso, en el que se registraba en documentos de papel y almacenados en gabinetes y el otro caso para reemplazar un sistema obsoleto quizs porque corre sobre hardware obsoleto o quizs porque ha sido desarrollado en un lenguaje obsoleto como COBOL o porque el sistema tiene poca o ninguna documentacin

10

1.1.1 Anlisis de requerimientos

Como su nombre lo indica, analizar requerimientos obtenidos por ejemplo en entrevistas a usuarios y analizando el sistema actual manual o automatizado. Preguntas a responder por los usuarios incluyen las siguientes: Cul es su rol en el sistema actual? Cmo usa el sistema actual? Qu ventajas o limitaciones tiene el sistema actual? Qu nuevas caractersticas deber tener el nuevo sistema para usted? Analizar un sistema de software existente implica que se necesitara extraer los requerimientos, separando requerimientos funcionales de funcionalidades que resultan del diseo o implementacin de decisiones, identificando requerimientos no funcionales, decidir que funciones no debern ser hechas diferenciadamente y que nuevas funcionalidades debern ser agregadas.

1.1.2 Especificacin de requerimientos

Es el documento donde se pone de acuerdo los analistas de requerimientos y los usuarios. Los requerimientos funcionales y no funcionales necesitan ser especificados. En definicin un requerimiento funcional sirve necesariamente para describir que funcionalmente el sistema necesita proveer, que informacin necesita ser introducida o sacada del sistema desde un ambiente externo Un requerimiento no funcional algunas veces se refiere a los atributos de calidad, por ejemplo que el tiempo de respuesta del sistema sea de 2 segundos o que el sistema est disponible el 99% de tiempo.

11

1.1.3 Atributos de calidad de la especificacin de los requerimientos del software

Los siguientes atributos son considerados aconsejables para una buena especificacin de requerimientos de software: Correcto Completo Sin Ambigedades Consistente Verificable Comprensible para todos Modificable Trazable

1.2 UML como un estndar

UML (Unified Modeling Language), lenguaje unificado de modelado, actualmente en la versin 2.0 es el descrito como el estndar para la visualizacin, construccin y documentacin los artefactos de un sistema de software. Ofrece una manera estndar de escribir planos del sistema, incluyendo aspectos conceptuales tales como el proceso de negocio y funciones del sistema, as como cosas concretas como declaraciones de lenguaje de programacin, esquema de base de datos y componentes de software reusable segn ISO/IEC 19501:2005. La OMG (Object Management Group) mantiene a UML como un estndar.

1.2.1 Diagramas UML

Tenemos los siguientes: Diagrama de casos de uso Diagrama de clases Diagrama de objetos Diagrama de comunicaciones Diagrama de secuencia Diagrama de estados de maquina Diagrama de actividades Diagrama de comunicacin concurrente

12

1.2.1.1 Diagrama de casos de uso

Un actor inicializa un caso de uso. Este diagrama define una secuencia de interacciones entre los actores y el sistema. Un actor es representado como una figura en un diagrama de casos de uso. El sistema es representado como un recuadro. Un caso de uso es representado como una elipse dentro del recuadro. Las asociaciones de comunicacin conectan actores con casos de uso en los que ellos participan. Relacin entre los casos de uso son definidos por medio de relaciones de extensin y ampliacin (Include and Extend)

Figura 1: diagrama de clases de uso

13

1.2.1.2 Diagrama de clases

Las clases son representadas por recuadros, y relaciones estticas entre ellos son representados con lneas de conexin. Existen tres tipos de relacin entre las clases: asociaciones, relaciones parte/todo y relacin de generalizacin/especializacin. Tipos de relacin en los diagrama de clases Es una relacin estructural esttica entre dos o ms clases. Tiene un nombre y opcionalmente una flecha que representa la direccin en Asociacin la que la asociacin debe ser leda. La multiplicidad indica cuantas instancias de una clase son relacionadas a una instancia de otra clase. Agregacin y Estas son relaciones de parte/todo. La composicin es una fuerte composicin forma de relacin parte/todo que la relacin de agregacin. Generalizacin Es una relacin de herencia. Una generalizacin es representada por y una flecha uniendo las subclases hijas a la superclase padre, donde especificacin la punta de la flecha toca el cuadro de la superclase

La visibilidad se refiere a que un elemento es visible desde otra clase, donde visibilidad publica se denota con un smbolo (+) que es visto desde fuera de la clase, la privada (-) que es visible solo desde dentro de la propia clase y la protegida (#) que es visible dentro de la propia clase y todas sus clases hijas.

Figura 2: Diagrama de clases

14

1.2.1.3 Diagrama de interaccin

UML tiene 2 tipos de diagrama de interaccin: el diagrama de comunicacin y el diagrama de secuencia. En estos diagramas los objetos son representados por rectngulos. Sin embargo los nombres de los objetos no son subrayados. Diagrama de comunicacin: Tambin llamado diagrama de colaboracin en UML 1.x. Muestra como los objetos cooperan e interactan dinmicamente los objetos unos con otros, enviando y recibiendo mensajes. Los objetos son mostrados como recuadros y las lneas que unen estos representan objetos de interconexin y las flechas etiquetadas indican el nombre y el mensaje que se transmiten entre objetos. Diagrama de secuencia: representan objetos que interactan organizadamente en secuencia a travs del tiempo. Muestra dos dimensiones donde los objetos participan en la interaccin representado horizontalmente y la dimensin vertical representa el tiempo.

Figura 3: Diagrama de secuencia

15

 1.2.1.4 Diagrama de Estados de maquina

En la notacin UML los estados son representados por cuadros redondeados y las transiciones por flechas que conectan dichos cuadros. El estado inicial del diagrama de estado es representado por una flecha que se origine desde un crculo pequeo negro y opcionalmente el estado final puede ser representado por un pequeo crculo negro dentro de un crculo blanco ms grande. La flechas representan los estados de transicin, la notacin de evento [condicin]/ accin es usada. El evento causa el estado de transicin.

Figura 4: Diagrama de estados de maquina

16

1.2.1.5 Diagrama de actividad

Representa un flujo de control y secuencia entre las actividades. Muestra la secuencia de actividades, nodos de control, bucles e incluso actividades concurrentes. Puede ser usado para representar en pasos secuenciales de un caso de uso, incluyendo la secuencia principal y todas las secuencias alternativas.

Figura 5: Diagrama de actividad

17

1.2.1.6 Diagrama de Comunicacin concurrente

Puede ser usado para representar objetos concurrentes, procesos, hilos o tareas. Se muestra como un recuadro con 2 lneas verticales paralelas a los lados. Tipos de objetos Objeto Activo Tiene su propio hilo de control y se ejecuta concurrentemente con otros objetos.
<<Active object>>

Objeto activo
<<Active object>>

Multiobjeto Activo Objeto Pasivo No tiene hilo de control. Solo se ejecuta cuando otro objeto (activo o pasivo) ejecuta una de sus operaciones.
<<Passive object>>

Objeto pasivo
<<Passive object>>

Multiobjeto pasivo

Los objetos activos son representados en un diagrama concurrente de comunicacin, que representa un punto de vista concurrente del sistema.

Figura 6: Diagrama de comunicacin

18

1.2.1.6.1 Comunicacin de mensajes en el diagrama de comunicacin concurrente

Las interfaces de mensajes entre tareas en este diagrama son Asncrona (dbilmente acoplado) o sncrona (fuertemente acoplado). Simple Asncronas Con respuesta

Sncrona

19

2. DISEO DE SOFTWARE
Se puede interpretar el diseo del software como toda actividad que engloba el desarrollo del software puesto que esta no se crea sino que se desarrolla. En esta etapa del desarrollo se llevan a cabo los bosquejos o diagrama que le permiten comprender la magnitud del software y faciliten a los desarrolladores estructurar su trabajo. En esta etapa se desarrollan los diagramas como los planos del software.

2.1 Diseo arquitectnico.

Una arquitectura de software es considerado principalmente una perspectiva estructural. Para entender la arquitectura se deben incluir las perspectivas estticas y dinmicas. Tambin se debe direccionar de perspectiva funcionales (provistas por la arquitectura en s) y perspectiva no funcional (Calidad de funcionalidad).

Vistas de la arquitectura del software Tambin conocido como vista estructural, la cual no cambia en el tiempo. Son representados por diagrama de clases. Vista de comportamiento que son representados por diagrama de comunicacin. Muestra los mensajes de comunicacin entre los subsistemas Representada por la configuracin fsica de la arquitectura, como los subsistemas son asignados a nodos fsicos en una configuracin distribuida.

Vista Esttica

Vista Dinmica

Vista de despliegue

20

2.1.1 Arquitectura orientado a objetos

La orientacin a objetos es uno de los conceptos fundamentales del diseo del software. Este concepto se refiere a sistemas de software que son diseados usando los conceptos de ocultacin de informacin, clases y herencia, los objetos son instanciados desde las clases y son accedidos a travs de operaciones que tambin se llaman mtodos. Una clase diseada usando el concepto de ocultamiento de informacin para encapsular diferentes tipos de informacin, tales como detalles o una estructura de datos .estas clases son determinadas originalmente durante la fase de estructuramiento de clases y objetos del anlisis de modelado.

2.1.1.1 Conceptos, arquitecturas y patrones

La ocultacin de informacin es un concepto de diseo fundamental en el que las clases encapsulan alguna informacin, tal como una estructura de datos, que es ocultada del resto del sistema. Otro importante concepto es la separacin de las interfaces de la implementacin, tal que la interfaz es un contrato entre el proveedor de la interfaz y el usuario de la interfaz. El concepto orientado a objetos tambin son aplicados y extendidos en el diseo distribuido y arquitectura de software basado en componentes, concurrente y arquitecturas de software de tiempo real, arquitectura orientada a servicios y arquitectura de software de lnea de productos.

2.1.1.2 Diseo de clases de ocultamiento de informacin Las clases son categorizadas en:
Son categorizadas en clases de abstraccin de datos

Clases de entidad

que encapsulan la estructura de datos y las clases envolventes que oculta los detalles de cmo la interfaz

debe acceder a datos almacenados en un archivo de

base de datos.

Clases limitantes

Comunican con una interfaz hacia un ambiente externo, tales como clases de I/O de dispositivos, clases proxy.

Clases de control

Proveen total coordinacin de la coleccin de objetos

Clases de lgica de aplicacin

Encapsula lgica especfica de la aplicacin y algoritmos, pueden ser categorizadas por clases de lgica de negocios, clases de servicio y clases algortmicas.

21

2.1.1.3 Diseo de interfaz de clase y operaciones

Consiste en unas operaciones provistas por cada clase. Cada operacin puede tener parmetros de entra, de salida y valores de retorno. Las operaciones tambin pueden ser determinadas tambin desde el modelo esttico o dinmico. Si dos objetos interactan, es necesario saber cul de los dos objetivos invoca una operacin en el otro objeto. Esta informacin no es usualmente ser determinada desde un diagrama de clase en el modelo esttico porque solo muestra la relacin esttica entre clases. Los modelos de interaccin dinmica muestran la direccin en el que los mensajes se envan.

2.1.1.4 Clases de abstraccin de datos

Cada clase de entidad en el modelo de anlisis que encapsula datos ha sido diseada como una clase de abstraccin de datos. Una entidad de clase almacena alguna data y provee operaciones y acceso a datos para leer o escribir. Estas clases son usadas para encapsular la estructura de los datos. La informacin sobre los atributos encapsulados por la clase de abstraccin de datos debe estar disponible en el modelo esttico del dominio del problema. 2.1.1.5 Clases de interaccin graficas con usuarios

Se debe hacer hincapi en la identificacin de las clases de compuestos de interaccin del usuario y la captura de la informacin que debe ser introducida por el usuario y la informacin que necesita ser mostrada al usuario.
Individuales pantallas de interfaz grfica de usuario tambin pueden ser diseados como parte del modelo de anlisis. En el modelo de diseo para una aplicacin de interfaz grfica de usuario basada, las clases de interfaz grfica de usuario requerido para cada una de las pantallas individuales estn diseados.

22

2.1.1.6 Clases de lgica de negocio

Una clase de lgica de negocio define la toma de decisiones, la lgica de las aplicaciones de negocio especficas para el procesamiento de la solicitud de un cliente. El objetivo es encapsular las reglas de negocio que podran cambiar de forma independiente el uno del otro en clases de lgica de negocios independientes. Por lo general, un objeto de la lgica de negocio accede a varios objetos de entidad durante su ejecucin. 2.1.1.7 Polimorfismo y enlace dinmico

En el diseo orientado a objetos, el polimorfismo se utiliza para indicar que las diferentes clases pueden tener el mismo nombre de la operacin. La especificacin de la operacin es idntica para cada clase, sin embargo, las clases pueden implementar la operacin de manera diferente. Esto permite que los objetos con interfaces idnticas a ser sustituidos por los dems en tiempo de ejecucin. Enlace dinmico se utiliza en conjuncin con el polimorfismo y es la asociacin de tiempo de ejecucin de una peticin a un objeto y una de sus operaciones.

2.1.2 Arquitectura Cliente Servidor

En estos sistemas, un cliente es un solicitante de servicios y un servidor es un proveedor de Servicios. Servidores tpicos como servidores de archivos, servidores de bases de datos y servidores de impresora de lnea, arquitecturas cliente / servidor se basan en patrones de arquitectura cliente / servicio, los ms simple de las cuales consiste en un servicio y varios clientes. Un servidor es un hardware / sistema de software que proporciona uno o ms servicios para varios clientes. Un servicio de en un sistema cliente / servidor es un componente de software de aplicacin que cumple la necesidades de varios clientes. Dado que los servicios se ejecutan en los servidores, a veces hay confusin entre los dos trminos, y los dos trminos se utilizan a veces indistintamente. A veces, un servidor apoyar slo un servicio, o tal vez ms que uno, por el otro lado, un gran servicio podra abarcar ms de un nodo de servidor. En cliente / servidor de sistemas, el servicio se ejecuta en un nodo de servidor fijo (s) y el cliente tiene una conexin fija con el servidor.

23

2.1.2.1 Conceptos, arquitecturas y patrones

La arquitectura cliente / servidor simple tiene un servicio y muchos clientes. Ms sistemas cliente / servidor complejas pueden tener mltiples servicios

En esta seccin se describe una variedad de cliente / software de servicio de la estructura arquitectnica patrones que van desde varios clientes con un nico servicio a mltiples clientes mltiples servicios y arquitecturas cliente / servidor de mltiples niveles. Patrones cliente servidor mltiple cliente/un servicio

Mltiple cliente/ mltiple servicio

Consta de mltiples clientes para un servicio, es decir muestra mltiples clientes conectados a un servicio que se ejecuta en un nodo o nodos del servidor. un cliente puede comunicarse con varios servicios, y los servicios pueden comunicarse entres si, en el que cada servicio reside en un nodo de servidor independiente , y ambos servicios pueden ser invocados por el mismo cliente

2.1.2.2 Patrn arquitectnico multicliente/servicio

El patrn cliente/ servidor de varios niveles tiene un nivel intermedio (es decir la capa) que proporciona a ambos un papel. Una capa intermedia es un cliente de la capa de servicio que tambin ofrece un servicio para sus clientes, es posible tener ms de un nivel intermedio, considerada como una arquitectura en capas, el cliente se considera estar en una capa ms alta que el servicio debido a que el cliente depende y utiliza l servicio.

Figura 7: Patrn arquitectura Multicapa cliente/servicio (3 capas)

24

2.1.2.3 Middleware en sistemas cliente/servicio

Middleware es una capa de software que se sita por encima del sistema operativo heterognea para proporcionar una plataforma por encima del cual las aplicaciones distribuidas, como sistemas cliente / servidor, se puede ejecutar. Existen sistema operativo estndar, tales como Windows, y software de comunicacin de red, tales como TCP / IP (Transmission Control Protocol / Protocolo de Internet), que es el protocolo ms utilizado en Internet. La middleware capa se encuentra por encima del sistema operativo y de la comunicacin en la red software.

2.1.2.4 Desde modelos estticos a diseo de base de datos relacional

La mayora de las bases de datos son bases de datos relacionales, el objetivo es por lo tanto, para llevar a cabo el diseo lgico de la base de datos relacional desde modelo esttico, sobre todo para las clases de entidad que necesitan ser persistente. Se aplican los conceptos de bases de datos relacionales tales como identificacin de claves primarias, asociaciones con claves externas, cardinalidad, etc.

2.1.3 Arquitectura Orientado a Servicios (SOA)

Es una arquitectura de software distribuida que consta de mltiples servicios autnomos. Los servicios se distribuyen de tal manera que se puede ejecutar en nodos diferentes con diferentes proveedores de servicios. Con un SOA, el objetivo es desarrollar las aplicaciones de software que se componen de servicios distribuidos, de tal manera que los servicios individuales pueden ejecutar en diferentes plataformas y se aplicarn en diferentes idiomas. Protocolos estndar se suministran para permitir que los servicios de comunicacin unos con otros y para intercambiar informacin.

25

2.1.3.1 Conceptos, arquitecturas y patrones

Un objetivo importante de SOA es el diseo de los servicios como componentes reutilizables autnomas. Los servicios estn destinados a ser autnomo y dbilmente acoplado, es decir, que las dependencias entre los servicios se reducen al mnimo. Patrones de arquitectura de software se describen para SOA: Patrones Brker: incluyendo registro de servicio, servicio de intermediacin y servicio descubrimiento. Patrones de transacciones: en particular en dos fases, compuesto y Long-living 2.1.3.2 Principios para disear servicios

Muchos de estos conceptos son una buena ingeniera de software y los principios de diseo, que se han incorporado en el diseo de SOA. acoplamiento dbil.- Los servicios deben ser relativamente independientes entre s. Por lo tanto, un servicio debe contener una cantidad mnima de informacin sobre otros servicios idealmente no debe depender de otros servicios. Contrato de servicio.- El servicio ofrece un contrato, que una aplicacin SOA puede confiar. El contrato se define tpicamente en la interfaz de servicio en la forma de un conjunto de operaciones. Cada operacin por lo general tiene parmetros de entrada y de salida, pero puede tambin incluir parmetros de calidad de servicio tales como el tiempo de respuesta y la disponibilidad. Este principio se basa en el concepto de diseo orientado al objeto de separar el interfaz y la implementacin, y el establecimiento de la interfaz como el contrato entre el proveedor del servicio y el usuario del servicio. Autonoma.- Cada servicio es autnomo, de tal manera que puede funcionar de forma independiente sin la necesidad de otros servicios. Este concepto se puede lograr mediante la separacin de los servicios de la coordinacin, de modo que los servicios no se comunican directamente entre s.

26

 Abstraccin.- Al igual que con el diseo orientado a objetos, los detalles de un servicio son escondidos, Un servicio slo revela su interfaz en funcin de las operaciones que proporciona, y para cada operacin, los insumos necesarios y los resultados que devuelve. Reutilizacin.- Un objetivo clave de SOA es el diseo de los servicios que son reutilizables. Los anteriores objetivos de diseo de servicios tienen por objeto facilitar la reutilizacin. Componibilidad.- Los servicios estn diseados para ser capaz de ser montado en servicios compuestos ms grandes. En algunos casos, un servicio compuesto tambin debe proporcionar la coordinacin de los servicios individuales. Sin estado.- Siempre que sea posible, los servicios mantienen poca o ninguna informacin acerca de las actividades especficas de los clientes. Detectabilidad.- El servicio proporciona una descripcin externa para ayudar a permitir que sea descubierto por un mecanismo de descubrimiento.

2.1.3.3 Tecnologas de apoyo para SOA

Aunque SOA son conceptualmente independiente de la plataforma, que se proporcionan actualmente con mucho xito en las plataformas de tecnologa de servicios Web. Un servicio web es un servicio que se accede a travs de protocolos de Internet y basado en XML estndar. En esta seccin se ofrece una breve descripcin de la tecnologa de apoyo para SOA implementado como servicios Web. 2.1.3.3.1 Protocolos de servicio web

Clientes y servicios de aplicacin debe tener un protocolo de comunicacin para la comunicacin entre componentes. Extensible Markup Language (XML) es una tecnologa que permite a los diferentes sistemas para interoperar a travs del intercambio de datos y texto. El Single Object Access Protocol (SOAP), que es un protocolo ligero desarrollado por el World Wide Web Consortium (W3C), se basa en XML y HTTP para permitir el intercambio de informacin en un entorno distribuido. SOAP define un enfoque unificado para el envo de datos codificados en XML y consta de tres partes: un sobre que define un marco para describir lo que est en un mensaje y cmo procesarlo, un conjunto de reglas de codificacin para expresar instancias de aplicacin definidos por los tipos de datos y una convencin para representar llamadas a procedimientos remotos y respuestas.
27

2.1.3.3.2 Servicios web

Las aplicaciones proporcionan servicios para los clientes. Un ejemplo de servicios de aplicacin son los servicios Web, que utilizan la World Wide Web para la comunicacin de aplicacin a aplicacin. Desde la perspectiva del software, los servicios Web son las interfaces de programacin de aplicaciones (API) que proporcionan un medio estndar de comunicacin entre las diferentes aplicaciones de software en el World Wide Web. Desde una perspectiva de aplicacin de negocios, un servicio Web es la funcionalidad del negocio proporcionada por una empresa en la forma de un servicio expreso a travs de Internet para que otras empresas o programas para su uso. Un servicio Web es proporcionado por un proveedor de servicios y puede estar compuesto de otros servicios para formar nuevos servicios y aplicaciones. Un ejemplo de un cliente Web que invoca un servicio Web se da en la figura

Figura 8: Cliente web y servicio Web

28

2.1.3.3.3 Servicios de registro

Un registro de servicios est provisto para que los servicios que se publicarn y sean localizados a travs de la World Wide Web. Los proveedores de servicios registran a sus servicios junto con descripciones de los servicios en un registro de servicios. Los clientes en busca de un servicio pueden consultar el registro de servicios para encontrar un servicio adecuado.

Figura 9: Servicio Web Brker

2.1.3.4 Software de arquitectura de patrones transaccionales

Un servicio encapsula los datos o proporciona acceso a los datos que se deben leer o actualizados por los clientes. Muchos servicios tienen que proporcionar las operaciones de actualizacin coordinados. Una transaccin es una solicitud de un cliente para un servicio que consiste en dos o ms de las operaciones que realizan una nica funcin lgica y que debe ser completado en su totalidad. Las transacciones se generan en el cliente y se envan al servicio para el procesamiento. Las operaciones tienen las siguientes propiedades, a veces referido como propiedades ACID: La atomicidad (A).- Una transaccin es una unidad indivisible de trabajo. Consistencia (C).- Despus de que la transaccin se ejecuta, el sistema debe estar en un estado coherente.

29

 Aislamiento (I).- Comportamiento de una transaccin no debe verse afectada por otras transacciones. Durabilidad (D).- Los cambios son permanentes despus de completar una transaccin. Estos cambios deben sobrevivir a fallos en el sistema. Esto tambin se conoce como persistencia. 2.1.3.5 Patrn de negociacin

En algunos SOA, la coordinacin entre los servicios implica negociaciones entre los agentes de software para que puedan tomar decisiones de forma cooperativa. En el modelo de negociacin (tambin conocida como la negociacin basada en agentes o patrn Negociacin Multi-Agent), un agente de cliente acta en nombre del usuario y hace una propuesta a un agente de servicio. El agente de servicio intenta satisfacer la propuesta del cliente, lo que podra implicar la comunicacin con otros servicios. Tras determinar las opciones disponibles, el agente de servicio se ofrece el agente de cliente de una o ms opciones que ms se acercan a igualar la propuesta agente de cliente original. 2.1.3.6 Reutilizacin de servicios

Una vez que los servicios han sido diseados, pueden ser reutilizados. A pesar de un servicio puede invocar una operacin en un servicio diferente, esto puede hacer que el servicio menos reutilizable, ya que ahora depende de otro servicio. Fomentar la reutilizacin del software, se recomienda que los servicios slo han proporcionado las interfaces y no tener interfaces necesarias (a menos que se utilice la comunicacin asncrona con devolucin de llamada). Esto hace que el servicio sea ms autnomo. Cada uno de los servicios descritos podra ser utilizado en diferentes aplicaciones. En cada caso, se crearan nuevos objetos coordinador para controlar el flujo de trabajo y la secuencia de aplicacin deseada, teniendo el mximo provecho de los servicios prestados

30

2.1.4 Arquitectura basado en componentes

La aplicacin de software es estructurada dentro de componentes y las interfaces entre los componentes son definidas. Los componentes son diseados para ser configurables en cada instancia componente en diferentes nodos en un ambiente geogrficamente distribuido. Son diseados usando criterios de estructuramiento de subsistemas. .1.4.1 Conceptos, arquitecturas y patrones

Describir los criterios de estructuramiento de componentes para disear componentes que puedan ser desplegados y ejecutados sobre plataformas distribuidas en una configuracin distribuida. Son representados con la notacin UML por diagramas de composicin de estructura. Patrones estructurales de comunicacin puede ser usado para incluyendo patrones sncrono, asncrono y brker. Una de las metas de la arquitectura basada en componentes es proveer un concurrente diseo basado en mensajes que son altamente configurables. En otras palabras tambin debe tener la capacidad de ser desplegado en muchas diferentes configuraciones. Puede ser configurada para que un subsistema basado en componentes se aloje en su propio nodo fsico separado o alternativamente todos o algunos de los componentes sean alojados en el mismo nodo. 2.1.4.2 Diseo de una arquitectura basada en componentes esta arquitectura,

Los tres principales pasos en el diseo de arquitectura basado en componentes para una aplicacin distribuida son: Arquitectura de software de diseo distribuido: Estructurar la aplicacin distribuida dentro de componentes constituidos que potencialmente puedan

31

ser ejecutados en nodos separados de un ambiente distribuido. Las interfaces entre los componentes son definidos. Diseo de componentes constituidos: internamente cada simple componente puede ser diseado por medio de diseo de arquitectura orientada a objetos secuencial. Desplegar la aplicacin: Despus de ser diseadas, las instancias pueden ser definidas y desplegadas. 2.1.4.3 Subsistemas compuestos y componentes

Un subsistema compuesto es un componente donde los objetos (componentes) son parte de este y debern residir en la misma locacin, pero objetos en diferentes locaciones nunca son del mismo subsistema compuesto.

Figura 10: Componente Compuesto que anida componentes simples

32

2.1.4.4 Modelado de componente con UML

Modelado de componentes

interfaz de componentes

Interfaz provista y requerida

Conectores e componentes

interconexin

Componentes compuestos

Especifica las operaciones visibles externamente sin revelar la estructura interna de las operaciones Una interfaz provista especifica las operaciones que un componente deber cumplir y una interfaz requerida describe las operaciones que otros componentes deben proveer que este componente opere propiamente en un entorno particular. de Un conector une un puerto requerido de un componente con el proveedor del puerto de otro componente, los cuales deben ser compatibles. Que reside ms de un componente dentro de l y es representado como clases estructuradas en UML.

2.1.4.5 Criterios de estructuramiento de componentes

Ya que se necesitan entender que esta estructura usualmente es diseada sobre ambientes distribuidos, son tomados en cuenta los siguientes criterios. Proximidad al recurso de datos fsicos Autonoma localizada Rendimiento en tiempo real. Hardware especificado Componentes I/O

33

2.1.4.5 Despliegue de la aplicacin

Se deben de tomar decisiones importantes como: Definir instancias de los componentes que pueden ser mltiples. Interconectar instancias de componentes para que se comuniquen con otras. Mapear las instancias de los componentes en nodos fsicos.

2.1.5 Arquitectura concurrente y en tiempo real

Se describe el diseo de arquitecturas de software simultneos y en tiempo real. Arquitecturas de software en tiempo real son arquitecturas concurrentes que por lo general tienen que hacer frente a mltiples flujos de eventos de entrada. Por lo general son dependientes del estado, ya sea de control centralizada o descentralizada. Por lo tanto, el diseo de mquinas de estados finitos, el modelado interaccin dependiente del estado, y los patrones de control, son muy importantes en el diseo de arquitecturas de software en tiempo real.

2.1.5.1 Concepto, arquitectura y patrones

Una actividad importante en el diseo de arquitecturas de software en tiempo real es el diseo concurrente de objetos, que se conocen como tareas concurrentes. Se describe el diseo de objetos pasivos, que no tiene hilos de control. El diseo concurrente y en tiempo real arquitecturas de software consiste en el diseo de las tareas concurrentes. Arquitecturas de software en tiempo real tambin pueden ser distribuidas, por esta razn se pueden considerar un caso especial de arquitecturas de software basadas en componentes. En este contexto, una tarea es equivalente a un componente sencillo. Durante el diseo de software concurrente, se desarrolla una arquitectura de software concurrente en el que el sistema est estructurado en tareas concurrentes, y las interfaces y las interconexiones entre las tareas concurrentes se definen. Para ayudar a determinar las tareas concurrentes, se proporcionan criterios de estructuracin de tareas concurrentes para ayudar en mapeo de un modelo de anlisis orientado a objetos del sistema a un software de arquitectura concurrente. Estos criterios son un conjunto de heursticas, tambin mencionado como directrices, que captura el conocimiento diseador experto en el diseo de software concurrente y sistemas de tiempo real. Entre los patrones usados estn los de control centralizado y descentralizado.
34

2.1.5.2 Caractersticas de los Sistemas en tiempo real

Sistemas en tiempo real son sistemas concurrentes con restricciones temporales. Ellos tienen un amplio uso en aplicaciones industriales, comerciales y militares. El trmino sistema en tiempo real, por lo general se refiere a todo el sistema, incluyendo el tiempo real de aplicacin, el sistema operativo en tiempo real, y el subsistema de E / S en tiempo real, con los controladores de dispositivos de propsito especfico para conectar a los distintos sensores y actuadores. Sin embargo, esta seccin describe tiempo real Aplicaciones en el contexto ms amplio de los sistemas en tiempo real. Sistemas de tiempo real son a menudo complejas, porque tienen que hacer frente a mltiples corrientes independientes de los eventos de entrada y producir mltiples salidas independientes.

2.1.5.3 Patrones de control de software en las arquitecturas de tiempo real

Muchos sistemas de tiempo real tienen una funcin de control. Esta seccin describe los diferentes tipos de patrones de control que se podran utilizar para este propsito: de control centralizado patrones, patrones de control distribuido, y los patrones de control jerrquicos. Para hacer las pautas aplicables a las arquitecturas de software basadas en componentes, as como en tiempo real arquitecturas de software, el componente estereotipo se utiliza en estos patrones.

2.1.5.3.1 Diseo arquitectnico de control centralizado

En el patrn de arquitectura de control centralizada, hay un componente de control, que ejecuta conceptualmente un diagrama de estado y proporciona el control y la secuenciacin del sistema. El componente de control recibe eventos de otros componentes con el que interacta. Estos incluyen eventos de varios componentes de entrada y los componentes de interfaz de usuario que interactan con el ambiente externo. Un evento de entrada a un componente de control por lo general provoca un estado de transicin en su diagrama de estado, lo que resulta en una o varias acciones dependientes del estado.

35

2.1.5.3.2 Diseo arquitectnico de control distribuido

El patrn de Control Distribuido contiene varios componentes de control. Cada uno de estos componentes controla una parte dada del sistema conceptualmente por la ejecucin de un diagrama de estado. El control se distribuye entre los diversos componentes de control, con ningn componente individual en el control general. Para notificar a la otra de los eventos importantes, el control componentes se comunican a travs de la comunicacin punto a punto Tambin interactan con el ambiente externo como en el patrn de control centralizado. 2.1.5.3.3 Diseo arquitectnico de control jerrquico

El patrn de control jerrquico (tambin conocido como el patrn de control multinivel) contiene varios componentes de control. Cada componente controla una parte dada de un sistema conceptualmente por la ejecucin de una mquina de estado. Adems, un componente coordinador proporciona el control global del sistema mediante la coordinacin de varios componentes de control. El coordinador proporciona un control de alto nivel, al decidir el siguiente trabajo para cada componente de control y la comunicacin de esa informacin directamente a la controlar los componentes. 2.1.5.4 Criterios de estructuracin de tareas de E/S

Se deben tomar en cuenta los siguientes criterios para el estructuramiento de tareas E/S: Eventos Impulsados por tareas de E/S Tareas Peridicas de E/S Demanda de tareas de E/S impulsados

2.1.5.5 Criterios internos de estructuracin de tareas

Considerando que los criterios de estructuracin de tareas de E / S se utilizan para determinar las tareas de E / S, el interno criterios de estructuracin de tareas se utilizan para determinar las tareas internas (es decir, no de E / S).
36

2.1.5.5.1 Tareas Peridicas

Muchos sistemas de tiempo real y concurrente tienen actividades que deben ser ejecutados en una base. Estas actividades peridicas se manejan normalmente por tareas peridicas. Aunque las actividades peridicas de E / S se estructuran las tareas de E / S de peridicos, peridicos actividades internas se estructuran las tareas peridicas. Tareas peridicas internas incluyen algoritmo tareas peridicas. Una actividad que necesita ser ejecutado peridicamente (es decir, a intervalos regulares, igualmente espaciados intervalos de tiempo) se estructura como una tarea peridica independiente.

2.1.5.5.2 Demanda de impulse de tareas

Muchos sistemas de tiempo real y concurrente tienen actividades que deben ser ejecutados en demanda. Estas actividades impulsadas por la demanda son manejadas tpicamente por medio de la demanda tareas impulsadas. Un objeto que se activa en la demanda (es decir, cuando se recibe un mensaje interno o evento enviado por una tarea diferente) se estructura como una tarea impulsada por la demanda independiente. La tarea se activa en la demanda por la llegada del mensaje o un evento enviado por la tarea solicita, realiza la solicitud exigida, y luego espera al siguiente mensaje o evento. 2.1.5.5.3 Tareas de control

En el modelo de anlisis, un objeto de control dependiente del estado realiza un diagrama de estado. Uso la forma restringida de grficos de estado mediante el cual no se permite la concurrencia dentro de un objeto, se deduce que la ejecucin de un diagrama de estado es estrictamente secuencial. Por lo tanto, una tarea cuya ejecucin tambin es estrictamente secuencial, se puede realizar la actividad de control.

37

2.1.5.5.4 Tarea de interaccin con el usuario

Un usuario normalmente lleva a cabo un conjunto de acciones secuenciales. Debido a la interaccin del usuario con el sistema es una actividad secuencial, esto puede ser manejado por una tarea de interaccin del usuario. La velocidad de esta tarea a menudo se ve limitada por la velocidad de la interaccin del usuario. Como su nombre implica, un objeto de la interaccin del usuario en el modelo de anlisis est diseado como un usuario tarea de interaccin. Tareas de interaccin de los usuarios suelen ser por eventos, ya que son activados por las aportaciones de los usuarios externos.

2.1.5.6 Tarea de comunicacin y sincronizacin

Despus de la estructuracin del sistema en tareas concurrentes, el siguiente paso es el diseo de la interfaces de tareas. En esta etapa, las interfaces entre las tareas son todava simples mensajes como se muestra en los diagramas de modelo de comunicacin de anlisis. Es necesario asignar estas interfaces a las interfaces de tarea en la forma de comunicacin de mensajes, sincronizacin de eventos, o acceder a los objetos que ocultan informacin.

Comunicacin de mensajes asncronos, tambin se conoce como mensaje impreciso la comunicacin, el productor enva un mensaje COMUNICACIN DE MENSAJE ASNCRONO para el consumidor y contina sin esperar una (ESTRUCTURA FLEXIBLE) respuesta. Es deseable disear esta interfaz de mensajes como el uso de la comunicacin de mensajes asncronos. Comunicacin de mensajes sncrona con la respuesta, tambin conocido como estrechamente acoplado la comunicacin del COMUNICACIN DE MENSAJE SNCRONA mensaje con la respuesta, entre las tareas (RGIDA) CON RESPUESTA concurrentes se basa en la comunicacin con el patrn Mensaje. El productor enva un mensaje para el consumidor y luego espera una respuesta. Comunicacin de mensajes sncrono sin respuesta, tambin conocido como COMUNICACIN DE MENSAJE SNCRONA estrechamente acoplado comunicacin de ( RGIDA ) SIN RESPUESTA mensajes sin respuesta, entre las tareas concurrentes se basa en la comunicacin de mensajes sncrono sin patrn de respuesta.
38

SINCRONIZACIN DE EVENTOS

Tres tipos de sincronizacin de eventos son posibles: un evento externo, un evento de temporizador, y un evento interno. Un evento externo es un evento de un objeto externo, por lo general una interrupcin de un dispositivo de E / S externa. Un evento interno representa interna sincronizacin entre una tarea de origen y de destino de una tarea. Un evento de temporizador representa una activacin peridica de una tarea. Los eventos se representan en UML, usando la notacin de mensajes asncronos para representar una seal de evento.

2.1.6 Arquitectura de Software para lnea de productos

Una lnea de producto de software se compone de una familia de sistemas de software que tienen parte de la funcionalidad comn y parte de la funcionalidad variable. Los problemas de desarrollo de sistemas de software individuales se escalan hacia arriba en el desarrollo de niveles de presin sonora debido a la mayor complejidad debido a la variabilidad gestin. Como con los sistemas individuales, una mejor comprensin de un SPL se puede obtener teniendo en cuenta los mltiples puntos de vista, tales como los modelos de requisitos, modelos estticos y dinmicos. Los modelos de la lnea de productos. Un lenguaje de modelado grfico como UML ayuda al desarrollo, la comprensin y la comunicacin de los diferentes puntos de vista. Una vista clave en los mltiples puntos de vista de un SPL es la vista de modelado caracterstica. El modelo de caractersticas es crucial para la gestin de la variabilidad y la derivacin producto, ya que describe el producto requisitos de la lnea en trminos de similitudes y variabilidad, y define el producto dependencias de lnea. Adems, es deseable tener un enfoque de desarrollo que promueve la evolucin del software, que el desarrollo de un ejemplar original y posterior mantenimiento son ambos tratados usando la evolucin caracterstica de motor.

39

2.1.6.1 Ingeniera evolutiva del software de lnea de producto

El modelo de proceso de software para ingeniera de SPL es un proceso altamente iterativo de software que elimina la tradicional distincin entre el desarrollo y mantenimiento de software. Por otra parte, ya que los nuevos sistemas de software son excrecencias de los ya existentes, el proceso toma una perspectiva SPL, que consiste en dos procesos principales: 1 SPL Ingeniera (tambin conocida como ingeniera de dominio). Una lnea de productos visin mltiple modelo que satisfaga las mltiples vistas de una SPL se desarrolla. El modelo de la lnea de productos de mltiples vistas, arquitectura lnea de productos y reutilizable componentes. 2. Ingeniera de Software de Aplicacin. A mltiples vistas modelo es un miembro de la lnea de productos individuales derivados del modelo mltiple vista SPL. El usuario selecciona las caractersticas requeridas para el producto individual miembro de la lnea. 2.1.6.2 Requisitos para el modelado de software de lnea de productos

Para los sistemas individuales, modelado de caso de uso es el principal vehculo para la descripcin de software requisitos funcionales. Por niveles de presin sonora, la funcin de modelado es una parte importante adicional de modelado de requisitos. La fuerza de la caracterstica de modelado es en la diferenciacin entre la funcionalidad proporcionada por los diferentes miembros de la familia de la lnea de productos en trminos de funcionalidad comn, funcionalidad opcional y alternativo funcionalidad. 2.1.6.2.1 Modelado de casos de uso

Los requisitos funcionales de un sistema se definen en trminos de casos de uso y actores. Para un solo sistema, se requiere que todos los casos de uso. En un SPL, slo algunos de los casos de uso, los cuales se conocen como casos de uso del ncleo, son requeridos por todos los miembros de la familia. Otros casos de uso son opcionales, ya que son requeridos por algunos pero no todos los miembros de la familia. Algunos casos de uso pueden ser alternativas entre s (es decir, las diferentes versiones del caso
40

de uso son requeridos por los diferentes miembros de la familia). En UML, los casos de uso estn etiquetados con el estereotipo ncleo , opcional o Alternativo. 2.1.6.2.2 Modelado de caractersticas

Modelado de caractersticas es una vista de modelado importante para la lnea de productos de ingeniera, porque se refiere a la variabilidad del SPL. Las caractersticas se analizan y clasifican como caractersticas comunes, caractersticas opcionales, las caractersticas de alternativas (una seleccin de funcin est disponible), y las caractersticas de requisitos previos (dependiendo otras caractersticas). El nfasis en la funcin de modelado es la captura de la variabilidad de la lnea de productos, dado por las caractersticas opcionales y alternativa, debido a estas caractersticas diferencian a un miembro de la familia de productos de los dems. Las funciones se utilizan ampliamente en la ingeniera de la lnea de productos, pero no se utilizan normalmente en UML. Con el fin de modelar eficazmente lneas de productos, es necesario incorporar presentar conceptos de modelado en UML. 2.1.6.3 Modelado de anlisis de SPL

Como con los sistemas individuales, modelado de anlisis consiste en modelar tanto esttica como dinmica. Sin embargo, ambos mtodos de modelizacin deben abordar el modelado variabilidad SPL. 2.1.6.3.1 Modelado esttico

En los sistemas individuales, una clase se clasifica por el papel que desempea. Clases de aplicacin son clasificadas de acuerdo con su papel en la aplicacin que utiliza estereotipos, como clase de entidad , clase de control o clase de lmite . En niveles de presin sonora de modelado, cada clase tambin se pueden clasificar de acuerdo con su caracterstica reutilizacin usando los estereotipos ncleo , opcional , y variante . En UML, un elemento de modelado se describir con ms de un estereotipo.

41

2.1.6.3.2 Modelado dinmico

Modelado dinmico para SPL utiliza una estrategia iterativa llama dinmica evolutiva anlisis para determinar el impacto dinmico de cada funcin en la arquitectura de software. Esto da lugar a nuevos componentes que se agregan o componentes existentes que tiene que adaptarse. En algunas lneas de productos, el sistema de ncleo se compone de slo los objetos de ncleo; para otras lneas de productos, pueden ser necesarios algunos objetos predeterminados, adems de los objetos de ncleo. La kernel del sistema se desarrolla teniendo en cuenta los casos de uso del ncleo, que son requeridos por todos los miembros de la lnea de productos. 2.1.6.4 Modelado de arquitectura de software SPL

En el modelo de diseo, la variabilidad se maneja mediante el desarrollo de variantes y param trizar componentes. Ciertos patrones de arquitectura de software son particularmente 2.1.6.4.1 Modelado de arquitectura basado en componentes

La interfaz de un componente de software se especifica por separado de su aplicacin, y, a diferencia de una clase, interfaz requerida del componente est diseado de manera explcita, adems de la interfaz proporcionada. Esto es particularmente importante para el centrado en la arquitectura la evolucin, debido a que es necesario conocer el impacto del cambio a un componente en todos los componentes que interconectan a ella. Esta capacidad para arquitecturas de software basadas en componentes de modelado es particularmente valioso en ingeniera de la lnea de productos, para permitir el desarrollo de kernel, componentes opcionales y variantes, componentes de conexin en "compatibles ", y el componente herencia de interfaces.

42

2.1.6.4.1 Patrones de arquitectura de software

Patrones de arquitectura de software proporcionan el esqueleto o plantilla para la arquitectura de software general o el diseo de alto nivel de una aplicacin. Estos incluir las arquitecturas utilizadas como cliente / servidor y las arquitecturas de capas. Al basar la arquitectura de software de una lnea de productos en uno o ms patrones de arquitectura de software de ayuda en el diseo de la arquitectura original, as como la evolucin de la arquitectura. La mayora de los sistemas de software y lneas de productos pueden estar basados en arquitecturas de software en general bien conocidas, por ejemplo, la arquitectura de software cliente / servidor prevalente en muchas aplicaciones de software. No es el patrn de arquitectura cliente / servicio bsico, con un servicio y muchos clientes, pero hay tambin muchas variaciones sobre este tema, como la mltiple Cliente / Servicios Mltiples patrones de arquitectura y patrones Brker.

2.2 Atributos de calidad de software

Atributos de calidad de software se refieren a los requisitos no funcionales del software, que puede tener un profundo efecto en la calidad de un producto de software. Muchos de estos atributos pueden ser abordados y evaluados en el momento en que se desarroll la arquitectura de software. Atributos de calidad de software incluyen mantenimiento, modificabilidad, capacidad de prueba, la trazabilidad, la escalabilidad, la reutilizacin, el rendimiento, la disponibilidad y la seguridad. En esta seccin se describe cada uno de estos atributos y discute la forma en que son compatibles con el mtodo de diseo de COMET. Algunos atributos de calidad de software tambin son atributos de calidad del sistema, ya que necesitar el hardware y software para lograr una alta calidad

43

2.2.1 Mantenibilidad

Mantenibilidad es la medida en que el software es capaz de ser cambiado despus de despliegue. Puede necesitar ser modificado por las siguientes razones del software: Fijar errores. Esta restantes son errores que no fueron detectados durante la prueba del software antes del despliegue. Rendimiento frente a los problemas cuestiones .Rendimiento no sern aparentes hasta despus de la aplicacin de software se ha desplegado y est en funcionamiento en el campo. Cambios en los requerimientos de software .La principal razn para el cambio de software es los cambios en los requisitos de software.

2.2.2 Modificabilidad

Modificabilidad es la medida en que el software es capaz de ser modificado durante y despus del desarrollo inicial. Un diseo modular consistente en mdulos con interfaces bien definidas es esencial. Es un diseo definido basado en el cambio de informacin el ocultar el concepto, en el que se prev que el cambio y gestionado por cada informacin del mdulo de ocultacin de un secreto que podra cambiar de forma independiente de otras partes del software. 2.2.3 Capacidad de prueba

Capacidad de prueba es el grado en el que el software es capaz de ser probado. Es importante desarrollar un plan de pruebas de software al principio del ciclo de vida del software y para planear en el desarrollo de casos de prueba en paralelo con el desarrollo de software. Estos casos de prueba se pueden desarrollar a partir del modelo de casos de uso, en particular las descripciones de casos de uso. Debido a que las descripciones de casos de uso describen la secuencia de las interacciones del usuario con el sistema, que describen las entradas de usuario que deben ser capturados por los casos de prueba y la salida esperada del sistema.

44

2.2.4 Trazabilidad

Trazabilidad es la medida en que los productos de cada fase se remontan a productos de las fases anteriores. Los requisitos de trazabilidad se utilizan para asegurar que cada requisito de software se ha diseado e implementado. Cada requisito es trazado de la arquitectura del software y de los mdulos de cdigo implementados. Es un enfoque de desarrollo basado los casos de uso y determina los objetos necesarios para realizar cada de casos de uso. Cada caso de uso se describe en los requisitos de software se elabora en un caso basado en el uso diagrama de interaccin , que describe la secuencia de la comunicacin objeto resultante de una entrada externa , tal como se describe en el caso de uso , a travs a la salida del sistema. Estos diagramas de interaccin se integran en la arquitectura de software. Esto significa que cada requisito puede rastrearse a partir de casos de uso de software diseo e implementacin. Por consiguiente, el impacto de un cambio a un requisito puede se determinar siguiendo el rastro del requisito a travs del diseo. 2.2.5 Escalabilidad

La escalabilidad es la medida en que el sistema es capaz de crecer despus de su inicial despliegue. Hay sistemas de software y los factores a considerar en la escalabilidad. De una perspectiva de sistema, hay cuestiones de la adicin de hardware para aumentar la capacidad del sistema. En un sistema centralizado, las posibilidades de escalabilidad son limitadas, como agregar ms memoria, disco o una CPU adicional. Un sistema distribuido ofrece mucho ms posibilidades de escalabilidad, al aadir ms nodos a la configuracin. Desde una perspectiva de software, la aplicacin necesita ser diseado de tal manera que es capaz de un crecimiento. Una arquitectura de software distribuida basada en componentes es mucho ms capaz de hacia arriba de escala que un diseo centralizado 2.2.6 Rendimiento

El rendimiento es tambin una consideracin importante en muchos sistemas. Rendimiento de modelado de un sistema en tiempo de diseo es importante para determinar si el sistema cumplir sus objetivos de rendimiento, tales como el
45

rendimiento y los tiempos de respuesta. Mtodos de modelado de rendimiento y modelos de simulacin. Modelado de rendimiento es especialmente importante en sistemas de tiempo real, en el cual no haya cumplido la fecha lmite podra ser catastrfico. Programacin en tiempo real en relacin con el caso de la secuencia de modelado es un enfoque para el modelado de diseos en tiempo real que se ejecuta en un hardware determinado configuraciones. 2.2.7 Seguridad

La seguridad es una consideracin importante en muchos sistemas. Hay muchas posibilidades de amenazas a los sistemas de aplicaciones distribuidas, tales como el comercio electrnico y la banca de sistemas. Algunas de las posibilidades amenazas son los siguientes: La Penetracin del Sistema: Una persona no autorizada intenta obtener acceso a un sistema de aplicacin y ejecutar transacciones no autorizadas. Violacin de Autorizacin: Una persona autorizada a utilizar un mal uso del sistema de aplicacin. Divulgacin Confidencialidad: Secreto de

informacin como nmeros de

tarjetas bancarias y cuentas se dan a conocer a una persona no autorizada. Comprometer la Integridad: Una persona no autorizada cambia los datos de aplicacin en los datos de la base de datos o comunicacin. 2.2.8 Disponibilidad

Disponibilidad aborda el fracaso del sistema y su impacto en los usuarios u otros sistemas. All a veces cuando el sistema no est disponible para usuarios para el mantenimiento programado del sistema; esta falta de disponibilidad planificada no se cuenta generalmente en medidas de disponibilidad. Sin embargo, el mantenimiento del sistema no planificado necesaria como resultado de un fallo del sistema siempre se cuenta. Algunos sistemas tienen que estar en funcionamiento en todo momento, Ejemplo: por lo que el efecto de un fallo del sistema en un sistema de control de un avin o nave espacial podra ser catastrfico.

46

2.3 Diseo de patrones

Un patrn de diseo describe la forma recurrente de resolver un problema, una solucin a un problema y el contexto en la que una solucin trabaja. Tambin se refieren a un patrn como una microarquitectura. Existen diversos tipos de arquitectura: Patrones de diseo: es un grupo pequeo objetos colaborando Patrones arquitectnicos: Es ms gran de que patrn de diseo, dirigiendo la estructura a un mayor subsistema del sistema. Patrones de anlisis: patrones recurrentes que funcionan en anlisis orientado a objetos y ellos son descritos con modelos estticos expresados en diagrama de clases. Patrones de productos de lnea especificada: Patrones usados en especficas reas, como automatizacin de fabricacin o comercio electrnico. Idiomas: patrones de bajo nivel para un lenguaje de programacin especifico o entorno concreto.

47

2.3.1 Catlogo de arquitectura de software

2.3.1.1 Patrones arquitectnicos Esta seccin describe los patrones de estructura arquitectnica, que se ocupan de la estructura esttica de la arquitectura, por orden alfabtico, con la plantilla estndar. 2.3.1.1.1 Broker Pattern

Nombre patrn Alias Contexto problemas

de Brker Brker intermediario- agente - corredor Diseo de la arquitectura del software, los sistemas distribuidos

Distribuida aplicacin en la que mltiples clientes se comunican con mltiples servicios. Los clientes no saben la ubicacin de los servicios. Resumen de Servicios registra en corredor. Los clientes envan peticiones de solucin servicio a agente. Broker acta como intermediario entre el cliente y el servicio. Fortaleza de la Ubicacin transparencia: Los servicios pueden trasladarse solucin fcilmente. Los clientes no necesitan saber ubicaciones de servicios. Debilidades .- Sobrecarga adicional debido corredor participa en la de la solucin comunicacin del mensaje. Broker puede convertirse en un cuello de botella si hay una carga pesada en el corredor. Cliente puede mantener mango servicio anterior en lugar de desecharlo aplicabilidad Entornos distribuidos: las aplicaciones cliente / servicio y distribucin con mltiples servicios Patrones broker relacionados

Figura 11: Patrn Brker

48

2.3.1.1.2 Centralized Control Pattern Nombre patrn Alias Contexto problemas de Control centralizado Controladores centralizados, controlador de sistema Centralizada de aplicaciones donde se requiere el control general

Varias acciones y actividades dependen del estado y necesitan ser controlados y secuenciado. Resumen de Hay un componente de control, que ejecuta conceptualmente un solucin diagrama de estado y proporciona el control general y la secuenciacin del sistema o subsistema. Fortaleza de la Encapsula todo el control del estado-dependiente en un solucin componente Debilidades Podra llevar a un control sobrecentralizado, en cuyo caso se de la solucin debe considerar el control descentralizado. aplicabilidad Sistemas de control en tiempo real, aplicaciones dependientes del Estado Patrones Control distribuido, Control jerrquico relacionados

Figura 12: Patrn de control centralizado

49

2.3.1.1.3 Distributed Control Pattern Nombre patrn Alias Contexto de Control distribuido

Controladores distribuidos Distribucin de aplicaciones con requerimientos de control en tiempo real. Aplicacin distribuida con el requisito de control en tiempo real problemas Aplicacin distribuida con mltiples lugares en los que se necesita el control localizada en tiempo real en varios lugares Resumen de Hay varios componentes de control, de tal manera que cada solucin componente controla una parte dada del sistema por conceptualmente ejecutar una mquina de estado. El control se distribuye entre los diversos componentes de control; ningn componente individual tiene el control general. Fortaleza de la Supera potencial problema del control sobrecentralizado solucin Debilidades No tiene un coordinador general. Si esto es necesario, considerar de la solucin el uso de patrn de control jerrquico. aplicabilidad Distribuido de control en tiempo real, aplicaciones dependientes del estado distribuidos Patrones Control jerrquico, control centralizado relacionados

Figura 13: Patrn de control distribuido

50

2.3.1.1.4 Hierarchical Control Pattern Nombre patrn Alias Contexto problemas de control jerrquico control de niveles mltiples, control multinivel Aplicacin distribuida con el requisito de control en tiempo real

Aplicacin distribuida con mltiples lugares en los que se necesitan tanto de control localizada en tiempo real y el control general Resumen de Hay varios componentes de control, cada uno controlando una solucin parte determinada de un sistema conceptualmente la ejecucin de un diagrama de estado. Tambin hay un componente coordinador, que proporciona un control de alto nivel, al decidir el siguiente trabajo para cada componente de control y comunicar esa informacin directamente al componente de control Fortaleza de la Supera problema potencial con el patrn de control distribuido, solucin proporcionando el control y la coordinacin de alto nivel Debilidades Coordinador de alto nivel puede convertirse en un cuello de de la solucin botella cuando la carga es alta y es un punto nico de fallo. aplicabilidad Distribuido de control en tiempo real, aplicaciones dependientes del estado distribuidos. Patrones Control distribuido, control centralizado relacionados

Figura 14: Patrn de control jerrquico

51

2.3.1.1.5 Layers of Abstraction Pattern Nombre patrn Alias Contexto problemas de Abstraccin de capas Capas Jerrquicas, capas de abstraccin Diseo de la arquitectura del software

Se necesita una arquitectura de software que promueve diseo para la facilidad de extensin y contraccin. Resumen de Componentes de las capas ms bajas proporcionan servicios solucin para los componentes en capas superiores. Los componentes pueden utilizar slo los servicios proporcionados por los componentes en las capas inferiores. Fortaleza de la Promueve la extensin y contraccin de diseo de software solucin Debilidades Podra dar lugar a la ineficacia si demasiadas capas deben ser de la solucin recorridos aplicabilidad Los sistemas operativos, protocolos de comunicacin, lneas de productos de software Patrones Kernel Software puede ser la capa ms baja de las capas de la relacionados arquitectura de la abstraccin. Las variaciones de este modelo incluyen capas flexibles de la abstraccin.

Figura 15: Patrn de capas de abstraccin

52

2.3.1.1.6 Mutiple Client/Multiple Service Pattern Nombre patrn Alias Contexto problemas de Multicliente/Multiservicio Mltiple cliente/ mltiple servicio Diseo de la arquitectura del software, sistemas distribuidos

se usa en Aplicacin distribuida en el que varios clientes requieren servicios de mltiples servicios Resumen de Cliente se comunica con mltiples servicios, por lo general de solucin forma secuencial, pero tambin podra ser en paralelo. Cada servicio responde a las peticiones de los clientes. Cada servicio se encarga de mltiples solicitudes de clientes. Un servicio puede delegar una solicitud de cliente a un servicio diferente Fortaleza de la Buena forma para el cliente para comunicarse con mltiples solucin servicios cuando se necesita informacin diferente de cada servicio Debilidades El cliente espera indefinidamente si hay una carga pesada en de la solucin cualquier servidor aplicabilidad Procesamiento distribuido: aplicaciones cliente / servicio y distribucin con mltiples servicios Patrones Mltiples clientes/ un servicio y cliente/servicio multicapa relacionados

Figura 16: Patrn multicliente/Multiservicio

53

2.3.1.1.7 Multiple Client/Single Service Pattern Nombre patrn Alias Contexto problemas de Multicliente/servicio Cliente/servicio, cliente/servidor Diseo de arquitectura de software, sistemas distribuidos

Aplicacin distribuida en la que mltiples clientes requieren los servicios de un solo servicio. Resumen de Cliente solicita el servicio. El servicio responde la peticin de los solucin clientes y no inicia solicitudes, el servicio maneja varias solicitudes de los clientes Fortaleza de la Buena manera para el cliente para comunicarse con el servicio solucin cuando se necesita una respuesta del servicio. Forma muy comn de la comunicacin en las aplicaciones cliente/servicio. Debilidades El cliente se queda de manera indefinida si hay mucha carga de la solucin en el servidor. aplicabilidad Procesamiento distribuido : aplicaciones cliente/ servidor Patrones Mltiple cliente/servicios , mltiples cliente/ mltiple servidor relacionados

Figura 17: Patrn multicliente/servicio

54

2.3.1.1.8 Multi-Tier Client/Service Pattern Nombre patrn Alias Contexto problemas de Multicapa Cliente/servicio Cliente/servicio, Cliente/servidor Diseo de la arquitectura del software, los sistemas distribuidos

Aplicacin distribuida en la que hay ms de una capa (layer) de servicio Resumen de Las solicitudes de cliente de servicios, la solucin consta de solucin ms de un nivel de servicios (capas) . Nivel intermedio proporciona ambos roles cliente y servicio. No puede haber ms de un nivel intermedio. Fortaleza de la Buena manera de servicios de capas si se necesitan mltiples solucin servicios para manejar la peticin de un cliente individual y un servicio necesita ayuda de otro servicio. Debilidades El cliente se queda de manera indefinida si hay mucha carga de la solucin en el servidor aplicabilidad Procesamiento distribuido: aplicaciones cliente/servicio y de distribucin con mltiples servicios. Patrones Mltiple Cliente/servicio and Mltiple Cliente/Multiservicio relacionados

Figura 18: Multicapa Cliente/Servicio

55

2.3.1.2 Patrones de comunicacin

Arquitectura patrn de software de comunicacin Esta seccin describe los patrones de comunicacin de arquitectura, que se ocupan de la comunicacin dinmica entre los componentes distribuidos de la arquitectura, por orden alfabtico, con la plantilla estndar.

2.3.1.2.1 Asynchronous Message Communication Pattern

Nombre patrn Alias Contexto problemas de Comunicacin asncrona mensajes Estructura flexible Comunicacin Mensaje Sistemas concurrentes o distribuidos Aplicacin simultnea o distribuido tiene componentes concurrentes que necesitan comunicarse unos con otros. Productor no tiene que esperar a los consumidores. Productor no tiene una respuesta. Usar cola de mensajes entre el componente productor y componente de los consumidores. Productor enva mensaje a los consumidores y contina. Consumidor recibe el mensaje. Los mensajes se ponen en cola FIFO si el consumidor est ocupado. Consumidor se suspende ningn mensaje disponible. Productor necesita notificacin de tiempo de espera si el nodo consumidor se ha reducido
Consumer does not hold up producer

Resumen solucin

de

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

Consumidor no se sostiene productor. Si el productor produce mensajes con mayor rapidez que el consumidor pueda procesarlos, la cola de mensajes con el tiempo se desborde. Entornos centralizados y distribuidos: los sistemas en tiempo real, cliente / servidor y aplicaciones de distribucin Comunicacin asncrona de mensajes con devolucin de llamada

Figura 18: Patrn mensaje de comunicacin asncrona

56

2.3.1.2.2 Asynchronous Message Communication with Callback Pattern

Nombre patrn Alias Contexto problemas de
Asynchronous Message Communication with Callback

Comunicacin de estructura flexible con devolucin de llamada Sistemas concurrentes o distribuidos Aplicacin simultnea o distribuido en el que los componentes concurrentes necesitan comunicarse unos con otros. El cliente no tiene que esperar por el servicio, pero no es necesario para recibir una respuesta ms tarde. Utilice la comunicacin sincrnica entre los clientes y el servicio. El cliente enva solicitud de servicio, que incluye la operacin del cliente (callback) mango. Cliente no espera respuesta. Despus de servicio procesa la peticin del cliente, se utiliza el identificador para llamar a la operacin de cliente de forma remota (la devolucin de llamada). Buena forma para el cliente para comunicarse con el servicio cuando se necesita una respuesta, pero puede seguir ejecutndose y recibir respuesta despus Adecuado slo si el cliente no tiene que enviar varias peticiones antes de recibir la primera respuesta Entornos distribuidos : cliente/ servidor y la distribucin Considerar la comunicacin asncrona mensaje como patrn alternativo

Resumen solucin

de

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

Figura 19: Patrn mensaje de comunicacin asncrona con devolucin

57

2.3.1.2.3 Bidirectional Asynchronous Message Communication Pattern

Nombre patrn Alias Contexto problemas de
Bidirectional Asynchronous Message Communication Comunicacion asincron bidireccional mensaje

Estructura bidireccional flexible comunicacin de mensajes Sistema concurrente o distribuido Aplicacin simultnea o distribuido en el que los componentes concurrentes necesitan comunicarse unos con otros. producer no tiene que esperar a que los consumidores, a pesar de que no necesita recibir respuestas ms tarde. producer puede enviar varias peticiones antes de recibir la primera respuesta. Utilice dos colas de mensajes entre componentes productor y componente de consumo: uno para los mensajes del productor al consumidor, y uno de los mensajes de los consumidores a los productores. Productor enva mensaje a los consumidores de P cola C y contina. Consumidor recibe el mensaje. Los mensajes se ponen en cola si el consumidor est ocupado. Consumidor enva respuestas en C P cola. Productor no quede soportado por los consumidores. Productor recibe respuestas ms tarde, cuando las necesita. Si el productor produce mensajes con mayor rapidez que el consumidor pueda procesarlos, el mensaje (P C) cola con el tiempo se desborde. Si el productor no tiene servicio responde lo suficientemente rpido, la respuesta de la cola (C P) se desbordar. En entornos distribuidos y centralizados : sistema de tiempo real , cliente/servidor y aplicaciones distribuidos. Comunicacin asncrono del mensaje con retorno de llamada.

Resumen solucin

de

Fortaleza de la solucin Debilidades de la solucin

aplicabilidad Patrones relacionados

Figura 20: Patrn mensaje de comunicacin asncrona bidireccional

58

2.3.1.2.4 Broadcast Pattern

Nombre patrn Alias Contexto problemas Resumen solucin de de Broadcast= transmitir Communication broadcast emisin transmitir difundir Sistemas distribuidos Distribuido aplicacin con mltiples clientes y servicios. A veces, un servicio necesita para enviar el mismo mensaje a varios clientes. Forma cruda de comunicacin de grupo en la que el servicio enva un mensaje a todos los clientes, independientemente de si los clientes quieren o no el mensaje. Cliente decide si desea procesar el mensaje o simplemente descartar el mensaje Forma simple de comunicacin en grupo Coloca una carga adicional para el cliente, porque el cliente no puede querer el mensaje Entornos distribuidos : cliente/servidor y aplicaciones distribuidos con multiples servidores . Al igual que en suscripcin / notificacin, salvo que no es selectiva

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

Figura 21: Patrn de transmisin

59

2.3.1.2.5 Broker Forwarding Pattern

Nombre patrn Alias Contexto problemas Resumen solucin de de desvo de broker = broker forwarding Pginas Blancas Forwarding Broker, corredor con diseo Forwarding Sistemas distribuidos Aplicacin distribuida en la que mltiples clientes se comunican con mltiples servicios. Los clientes no saben la ubicacin de los servicios. Servicios registra en corredor. El cliente enva solicitudes de servicio al corredor. Forwards Broker solicitan el servicio. Servicio procesa la solicitud y enva la respuesta al corredor. Forwards Broker responder a cliente. Ubicacin transparencia: Los servicios pueden trasladarse fcilmente. Los clientes no necesitan saber ubicaciones de servicios. Sobrecarga adicional porque broker est involucrado en todas las comunicaciones de mensajes. Broker puede convertirse en un cuello de botella si hay una carga pesada en el corredor. Entorno distribuido: cliente/servidor y aplicacin distribuidos con multiples servidores. Servers Similar al brker handle; mas seguro, pero el rendimiento no es tan bueno.

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

Figura 22: Patrn desvi de brker

60

2.3.1.2.6 Broker Handle Pattern

Nombre patrn Alias Contexto problemas Resumen solucin de de Broker handle Pginas Blancas Broker Handle, Broker con diseo de handle-Driven Sistemas distribuidos Aplicaciones distribuidas en la que mltiples clientes se comunican con mltiples servicios. Los clientes no saben la ubicacin de los servicios. Servicios registra en corredor. El cliente enva solicitudes de servicio al corredor. Broker devuelve handle servicio a cliente. El cliente utiliza manejar servicio para hacer solicitud de servicio. Servicio procesa la solicitud y enva responder directamente a cliente. El cliente puede hacer mltiples peticiones de servicio sin la participacin de broker. Transparencia de locacin: Ubicacin transparencia: Los servicios pueden trasladarse fcilmente. Los clientes no necesitan saber ubicaciones de servicios. Sobrecarga adicional porque broker est involucrado en todas las comunicaciones de mensajes. Broker puede convertirse en un cuello de botella si hay una carga pesada. Entorno Distribuido : cliente/ servidor y aplicaciones con multiples servers. Igual a brker handle, mas segur, pero el rendimiento no es tan bueno.

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

Figura 23: Patrn manejo de brker

61

2.3.1.2.7 Call/Return Pattern

Nombre patrn Alias Contexto problemas Resumen solucin de de Call / return Invocacin de operacin : mtodo de invocacin. Sistema y programa orientado a objeto. Un objeto tiene que llamar a una operacin (tambin conocido como mtodo) en un objeto diferente Una operacin de llamar a un objeto que llama invoca una supuesta operacin en un objeto llamado. Se pasa el control, junto con cualesquiera parmetros de entrada, de la operacin de llamada a la denominada operacin en el momento de la invocacin de la operacin. Cuando la operacin llamada termina de ejecutarse, devuelve los parmetros de salida de control y para la operacin de llamada Este patrn es la nica forma posible de comunicacin entre objetos en un diseo secuencial. Si este patrn de comunicacin no es adecuado, entonces lo ms probable ser necesaria una solucin concurrente o distribuida. Arquitecturas secuenciales orientados a objetos, programas y sistemas. Un servicio diseado como un subsistema secuencial que se comunica con los objetos internos utilizando este patrn.
Software architectural communication patterns in which message passing is used instead of operation invocation.

Fortaleza de la solucin Debilidades de la solucin aplicabilidad

Patrones relacionados

Figura 24: Patrn llamada/retorno

62

2.3.1.2.8 Negotiation Pattern

Nombre patrn Alias Contexto problemas Resumen solucin de de Negociacin Basado en agente de negociado/Multiagente de negociacin Sistemas multiagente distribuida, arquitecturas orientadas a servicios Cliente debe negociar con mltiples servicios para encontrar el mejor servicio disponible. Agente Cliente acta en nombre del cliente y hace una propuesta para un agente de servicio, que acta en nombre del servicio. Agente de servicio intenta satisfacer la propuesta del cliente, lo que podra involucrar a la comunicacin con otros servicios. Tras determinar las opciones disponibles, agente de servicio del agente de cliente se ofrece una o ms opciones que ms se acercan de igualar la propuesta agente de cliente original. Agente Cliente puede solicitar una de las opciones, proponer nuevas opciones, o rechazar la oferta. Si el agente de servicio puede satisfacer la peticin del agente de cliente, el agente de cliente acepta la solicitud, de lo contrario, se rechaza la solicitud.
Provides negotiation service to complement other services Proporciona servicio de negocio complete con otros servicios.

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

La negociacin puede ser larga e inconclusa Entornos distribuidos: las aplicaciones cliente / servicio y distribucin con mltiples servicios, arquitecturas orientadas a servicios. A menudo usado en conjunto con broker patterns (broker forwarding. Broker handle, service discovery)

Figura 25: Patrn de negociacin

63

2.3.1.2.9 Service Discovery Pattern

Nombre patrn Alias Contexto problemas de Descubrimiento de servicio Pginas Amarillas Broker, Trader Broker, Descubrimiento Sistemas distribuidos Aplicacin distribuida en la que mltiples clientes se comunican con mltiples servicios. Cliente conoce el tipo de servicio requerido, pero no el servicio especfico. Use el servicio de descubrimiento del agente. Servicios registra en corredor. El cliente enva solicitud de descubrimiento de servicios de broker. Broker devuelve los nombres de todos los servicios que responden a peticin de descubrimiento de servicios. Cliente selecciona un servicio y lo utiliza Handle Broker o patrn Forwarding Broker para comunicarse con el servicio. Ubicacin transparencia: Los servicios pueden trasladarse fcilmente. Los clientes no necesitan saber servicio especfico, slo el tipo de servicio. Sobrecarga adicional debido broker participa en la comunicacin inicial del mensaje. Broker puede convertirse en un cuello de botella si hay una carga pesada en el broker. Entorno distribuido: cliente servidor y aplicaciones con multiples servicios. Other broker patterns (Broker Forwarding, Broker Handle)

Resumen solucin

de

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

Figura 26: Patrn de descubrimiento de servicio

64

2.3.1.2.10 Service Registration Pattern

Nombre patrn Alias Contexto problemas Resumen solucin de de Servicio de registro Registracin de brker (registro del intermediario) Arquitectura de diseo de software, sistemas distribuidos Aplicaciones distribuidas en la que mltiples clientes se comunican con mltiples servicios. Los clientes no saben la ubicacin de los servicios. Servicios registrar informacin de servicio con el corredor, incluyendo el nombre del servicio, descripcin del servicio, y la ubicacin. Los clientes envan peticiones de servicio a agente. Broker acta como intermediario entre el cliente y el servicio. Ubicacin transparencia: Los servicios pueden trasladarse fcilmente. Los clientes no necesitan saber ubicaciones de servicios. Sobrecarga adicional debido corredor participa en la comunicacin del mensaje. Broker puede convertirse en un cuello de botella si hay una carga pesada en el corredor. Entornos distribuidos: cliente servidor y aplicaciones distribuidas con multiples servicios. Broker, Broker Forwarding, Broker Handle, Service Discovery

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

Figura 27: Patrn de registracin de servicio

65

1.3.1.2.11 Subscription/Notification Pattern

Nombre patrn Alias Contexto problemas Resumen solucin de de Susbcripcion/notification Multicast (multidifusin) Sistemas distribuidos Aplicacin distribuida con mltiples clientes y servicios. Los clientes quieren recibir mensajes de un tipo determinado. Forma selectiva de la comunicacin de grupo. Los clientes se suscriben a recibir mensajes de un tipo determinado. Cuando el servicio recibe el mensaje de este tipo, se notifica a todos los clientes que se han suscrito a la misma. Forma selectiva de la comunicacin de grupo. Ampliamente utilizado en Internet y en aplicaciones World Wide Web. Entornos distribuidos: las aplicaciones de distribucin de cliente / servicio y con mltiple. Entornos distribuidos: las aplicaciones cliente / servicio y distribucin con mltiples servicios. Similar to Broadcast, except that it is more selective

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

Figura 28: Patrn Notificacin/Subscripcin

66

2.3.1.3 Patrones de transaccin

Esta seccin describe los patrones de transacciones arquitectnicos, que se ocupan de la gestin de transacciones en las arquitecturas cliente / servidor, en orden alfabtico, con la plantilla estndar.

2.3.1.3.1 Compound Transaction Pattern

Nombre patrn Alias Contexto problemas Resumen solucin

de

Patrn Transaccin Compuesto/ compound trasaction Pattern Patrn compuesto de transaccin Los sistemas distribuidos, bases de datos distribuidas El cliente tiene la obligacin de transacciones que se pueden dividir en transacciones ms pequeas, planas separadas

de

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

Divida transaccin compuesto en transacciones atmicas ms pequeas, donde cada transaccin atmica se puede realizar por separado y se deshace por separado. Proporciona un apoyo efectivo para las transacciones que pueden dividirse en dos o ms transacciones atmicas. Efectivo si la reversin o el cambio es necesario para slo una de las transacciones. Ms trabajo es necesario para asegurarse de que las transacciones atmicas individuales son coherentes entre s. Se requiere ms coordinacin si necesita la transaccin compuesto entera que revertirse con una antelacin Aplicaciones Procesamiento de transaccin , base de datos distribuidos .
Two-Phase Commit Protocol, Long-Living Transaction

Figura 29: Patrn transaccin compuesta

67

2.3.1.3.2 Long-Living Transaction Pattern

Nombre patrn Alias Contexto problemas de Long_living transaction Patrn de larga duracin -vida Los sistemas distribuidos, bases de datos distribuidas El cliente tiene la obligacin de larga vida transaccin que tiene un ser humano en el circuito y que podra tomar un largo y posiblemente indefinida tiempo para ejecutarse. Dividir una transaccin de larga vida en dos o ms transacciones atmicas separadas de tal manera que la toma de decisiones humana tiene lugar entre cada par sucesivo de las transacciones atmicas. Proporciona un apoyo efectivo para las transacciones de larga vida que pueden dividirse en dos o ms operaciones atmicas Las situaciones pueden variar debido a la larga demora entre sucesivas transacciones atmicas que constituyen la transaccin de larga vida, lo que resulta en una transaccin de larga vida sin xito. Transaction processing applications, distributed databases
Two-Phase Commit Protocol, Compound Transaction.

Resumen solucin

de

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

Figura 30: Patrn de transaccin de larga duracin

68

2.3.1.3.3 Two-Phase Commit Protocol Pattern

Nombre patrn Alias Contexto problemas

de

Two-phase commit protocol Transaccin atmica, , Patrn protocolo de confirmacin de dos fases Sistemas distribuidos , base de datos distribuidas Los clientes generan transacciones y enviarlos al servicio de la transformacin. Una transaccin es atmica (es decir, indivisible). Se compone de dos o ms de las operaciones que realizan una nica funcin lgica, y debe ser completado en su totalidad o en absoluto. Para las transacciones atmicas, los servicios necesarios para confirmar o anular la transaccin. El protocolo de confirmacin en dos fases se utiliza para sincronizar las actualizaciones en nodos diferentes en aplicaciones distribuidas. El resultado es que o bien la transaccin se confirma (en cuyo caso todas las actualizaciones de xito) o la transaccin se cancela (en cuyo caso todas las actualizaciones fallan). Proporciona un apoyo efectivo para las transacciones atmicas Slo es eficaz para las transacciones a corto, es decir, no hay largas demoras entre las dos fases de la operacin. Aplicaciones de procesamiento de transacciones, bases de datos distribuidas
Compound Transaction, Long-Living Transaction

Resumen solucin

de

Fortaleza de la solucin Debilidades de la solucin aplicabilidad Patrones relacionados

Figura 31: Patrn Protocolo dos fases

69

Conclusin

Las fases iniciales del ciclo de vida del software son vitales para el desarrollo posterior, y por eso se hace hincapi en los mtodos y herramientas que son considerados estndares en el rea. La aplicacin de arquitecturas se realiza dependiendo de lo que abarcara el software y donde se trata de mostrar los puntos importantes de cada arquitectura, teniendo como base el modelado en UML y en donde la orientacin a objetos es tambin parte fundamental para el desarrollo de arquitecturas ms complejas. Los atributos de calidad del software son mostrados para evaluar la calidad de la arquitectura de software. El correcto diseo de la arquitectura se ver reflejada en los requerimientos no funcionales que los clientes esperan. Patrones como formas como forma recurrente de resolver un problema son aplicados a mltiples arquitecturas y por supuesto son adaptables de acuerdo a la necesidad del problema.

70

Bibliografa

Hassan Gomaa (2011) Software Modeling and Design Virginia Cambridge University Press ISO/IEC 19501:2005 (2005) Version 1.4.2 Fernando Barraza A. Modelado y diseo de arquitectura de software http://goo.gl/F27GU9

IEEE Std 830-1998 (1998) Recommended Practice for Software Requirements Specications

71